[petsc-dev] Symbol visibility

[Jed Brown]

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.


>    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.
 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101206/cb3eca4e/attachment.html>