[Fwd: PPL questions (GGCC related)]
-------- Original Message -------- Subject: PPL questions (GGCC related) Date: Tue, 16 Sep 2008 08:52:28 +0200 From: Basile STARYNKEVITCH basile@starynkevitch.net To: Roberto Bagnara bagnara@cs.unipr.it CC: Basile.starynkevitch@cea.fr
Hello Roberto
(Feel free to forward this email to the PPL mailing list if you feel it could be interesting)
Some simple PPL questions.
First, a rather selfish complain. The GCC compiler is requiring some precise old versions of autoconf (2.59 IIRC). Changing that is hard (but I'm sure the GCC community would welcome patches!). PPL apparently requires 2.61
It is painful for me to have to use many incompatible autoconf (and I hate all the auto{conf,make,local} stuff).
May I suggest a simple, but ugly, solution: put the generated configure files inside your CVS repository (btw, do you consider switching to SVN?) - perhaps just as configure.generated and add inside README.configure a small note about that (saying that mv configure.generated configure could be used as an alternative to autoconf).
We had an interesting exchange about debugprinting into a string in PPL. From my point of view, debugprinting into a string means putting (or appending) into a string (not a FILE*) a textual representation of PPL data, for debugging purposes... Ideally, I would dream of being able to transmit to the debugprinting routines an indentation (so that any newline is followed by some given number of spaces), but I could manage without.
What is the quickest way to achieve that? I would prefer avoiding fmemopen or open_memstream if possible (it is too GNUlibc specific).
Regards.
Roberto Bagnara wrote:
We had an interesting exchange about debugprinting into a string in PPL. From my point of view, debugprinting into a string means putting (or appending) into a string (not a FILE*) a textual representation of PPL data, for debugging purposes... Ideally, I would dream of being able to transmit to the debugprinting routines an indentation (so that any newline is followed by some given number of spaces), but I could manage without.
What is the quickest way to achieve that? I would prefer avoiding fmemopen or open_memstream if possible (it is too GNUlibc specific).
[CC to the GGCC mailing list since this work has been done in our quality of GlobalGCC partners.]
Dear Basile,
one possibility is now available in the PPL 0.10 snapshot available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
In the interfaces/C/tests directory, you will find a prototype of what you are looking for. The interface is in print_to_buffer.h (with a comment that, I see only now, has not been updated... see below for the correct one), the implementation is in print_to_buffer.cc, and an example of use is in cxxoutput.c.
In PPL 0.11 we may make a variation of this feature available directly from the C and the other interfaces. Some design is required though. If you believe it is really important to have such a feature in the C interface starting from PPL 0.10, we can perhaps refine the design for the C interface only and try to stick it in this release. But, first, please try it and let us know how it goes and if you believe this is adequate for the debugging purposes you have in mind.
If there are any other features that could help the GlobalGCC project to succeed, please let us know. All the best,
Roberto
/* Returns a buffer allocated with malloc() containing a printable representation of the PPL object referenced by `p', where each newline is followed by `indent_depth' blank spaces and the preferred maximum length of the first and the following lines are given by `preferred_first_line_length' and `preferred_line_length', respectively. */ #define DECLARE_PRINT_TO_BUFFER(Type) \ char* print_ppl_##Type##_t_to_buffer(ppl_##Type##_t p, \ unsigned indent_depth, \ unsigned preferred_first_line_length, \ unsigned preferred_line_length);
participants (1)
-
Roberto Bagnara