[petsc-dev] Symbol visibility

[Barry Smith]

On Dec 6, 2010, at 1:50 PM, Jed Brown wrote:

> On Mon, Dec 6, 2010 at 20:13, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Nonsense!  Clang/LLVM preprocesses the CPP directives out and gives you the AST for the resulting C code. This is definitely not what we want because we cannot even go back from this form to the original code, and the first thing I want with any source to source translator is the identity operator.  Now if I am wrong and Clang/LLVM does preserve all the CPP constructs (which I believe is pretty much impossible) then that is FANTASTIC and we are half-way to nirvana already and we can laden PETSc with as many complicated CPP macros as we want :-). Please tell me I am wrong.
> 
> Actually, look at their error messages (http://clang.llvm.org/diagnostics.html)
> 
> double *x,y;
> 
> bar.c:6:3: error: invalid operands to binary expression ('double **' and 'double')
>   PetscPrefetchBlock(&x,y,0,PETSC_PREFETCH_HINT_NTA);
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from bar.c:1:
> /home/jed/petsc/include/petscsys.h:1862:64: note: instantiated from:
>     const char *_p = (const char*)(a),*_end = (const char*)((a)+(n));   \
>                                                             ~~~^~~~
> 
> (These are also in color.)  The translation back through the macro is certainly still available to the type checker.

  This is nice but doesn't demonstrate that the compiler keeps all the information; for example does it keep in the AST all the information in the unvisited #else of an #if?

>   
>   I want a language that people actually use and that plays well with other languages but I want the advantage of languages that support more than the edit file--run compiler paradigm and if no one else wants to develop that then we need to develop it.
> 
> Just make compilation fast enough that it can happen automatically while you edit.  C cannot be as dynamic as a Lisp or Smalltalk, you necessarily have to restart the program to change the definition of a struct, for example.  PFString-style tricks get you a little ways, but it's still far less interactive.  Having source reside in plain text files is a significant part of "plays well with other languages/tools".  We just need good tools for navigating the source so that the existence of files is mostly transparent.

   I disagree. That still relies on us editing source code which is a very inefficient way of developing code (though it is the only way I know). The only reason for plain text files is because that is what the compilers and RCS want to see; it doesn't have anything to do with working with Fortran/python etc easily. We should generate plain text files only when we need to for other tools like compilers.

   Barry


>  IDEs like Eclipse do this more reliably than Emacs (even with CEDET and global), but I still can't stand using them.  My biggest complaint about these tools is that the amount of analysis that I can turn on is limited by interactive performance (mostly due to silly database decisions).
> 
> It's insane that it's 2010 and I'm complaining that my editor is too slow.  I can do full text search of my 6 GB mail archive in under a second, but it takes many seconds for my editor to find every place that MatGetSubMatrix is used (plain grep is faster, but without semantic analysis -- it's only searching text).  We should have the compiler spitting out semantic information and the editor should put it in a decent database with an index, then semantic queries (both forward and reverse) would be answered in under 100ms and we could get on with life.  Duplicating a slow, buggy, incomplete parser inside the editor is insane.  Clang/LLVM is something Apple has been behind that I think is unambiguously good.  Now we just need a way to have Emacs use it correctly (or a replacement for Emacs, but that seems even less likely).
> 
> Jed