Re: i guess we're frozen & stuff
http://mail-index.netbsd.org/tech-userlevel/2009/08/thread1.html#002545 http://savannah.gnu.org/support/?106973 My conclusion so far is that "(void *)0" is a legal value for NULL (even given as an example in POSIX 2008 glossary), and that just because an expression E evaluates to an integer constant one can not assume that "sizeof E" is valid. gnulib has changed to sizeof(NULL) and I think NetBSD is going to change NULL to add the () as well (to make it less likely people will have trouble, not because the current value is wrong). pgpWazPE3UdNM.pgp Description: PGP signature
Re: i guess we're frozen & stuff
Hello! Greg Troxel writes: > My conclusion so far is that "(void *)0" is a legal value for NULL Whether "legal" or not, under-parenthesized expression-like macros are likely to cause troubles one day or another. Thanks for your work with the upstream people! Ludo'.
Re: i guess we're frozen & stuff
l...@gnu.org (Ludovic Courtès) writes: >> My conclusion so far is that "(void *)0" is a legal value for NULL > > Whether "legal" or not, under-parenthesized expression-like macros are > likely to cause troubles one day or another. > > Thanks for your work with the upstream people! I now have a pointer to something in POSIX 2008 that says expression-like macros have to be parenthesized. pgp0Lm8VeFV1C.pgp Description: PGP signature
Pre 1.9.2 bugfixes
Hi- I hope that master is closer to building cleanly today w.r.t. strings. - Added a cast in SCM_MAKE_CHAR. If that doesn't work, then maybe SCM_MAKE_CHAR should become an inline function. - Removed some signed/unsigned comparisons and conversions - Applied Greg Troxel's patch to cast all input to tolower to int. (Crap. I should have committed this under your name. Sorry.) - Added a scheme data type to mimic a uniconv data type, so that doesn't appear in the Guile public headers - removed calls to the local-independent uc_tolower for now. Hope this helps, -Mike
scm_t_string_failed_conversion_handler
Hi Mike!
"Michael Gran" writes:
> commit ca2858c6ba827675af1e348b740b868abc1fdc8d
> Author: Michael Gran
> Date: Wed Aug 12 07:49:16 2009 -0700
>
> Don't include libunistring headers in Guile public headers
>
> This requres the creation of a new type
> scm_t_string_failed_conversion_handler to replace libunistring's
> enum iconveh_ilseq_handler.
Thanks for doing this! (And the other fixes, too.)
> + pf ("/* Constants from uniconv.h. */\n");
> + pf ("#define SCM_ICONVEH_ERROR %d\n", (int) iconveh_error);
> + pf ("#define SCM_ICONVEH_QUESTION_MARK %d\n",
> + (int) iconveh_question_mark);
> + pf ("#define SCM_ICONVEH_ESCAPE_SEQUENCE %d\n",
> + (int) iconveh_escape_sequence);
[...]
> +typedef enum
> +{
> + SCM_FAILED_CONVERSION_ERROR = SCM_ICONVEH_ERROR,
> + SCM_FAILED_CONVERSION_QUESTION_MARK = SCM_ICONVEH_QUESTION_MARK,
> + SCM_FAILED_CONVERSION_ESCAPE_SEQUENCE = SCM_ICONVEH_ESCAPE_SEQUENCE
> +} scm_t_string_failed_conversion_handler;
> +
Nice trick!
Thanks,
Ludo'.
Re: entering and leaving guile mode, and GC stack protection
Hi Ken, On Thu 06 Aug 2009 18:30, Ken Raeburn writes: > On Aug 5, 2009, at 10:06, I wrote: >> (3) My four-year-old comments on scm_enter/leave_guile, recorded in >> threads.c around line 300, still stand Those functions really >> ought to go away. At least they're confined to one file, now. Some >> of it looks a little messy, but I can probably get rid of some of the >> uses > > I've made a bit of progress on this. The patches look good to me; my only wonder is what relation they have to the BDW-GC branch Ludovic was working on. If BDW will land before 2.0, then perhaps all this mess can go away (wishful thinking); otherwise we should apply it now (after the release). Ludovic? :) Cheers, Andy -- http://wingolog.org/
Re: Guile 2.x and `pkg-config'
Hi,
On Sun 09 Aug 2009 22:24, l...@gnu.org (Ludovic Courtès) writes:
> A recent thread on `guile-user' [0] raises an important concern: what
> should we do with `guile-1.8.pc' when 2.x is out?
IMO, guile-1.8.pc is only provided by the guile-1.8 package. 1.8 and 2.0
are parallel-installable. Technically, we should be installing
guile-2.0.pc now.
> How about shipping `guile-1.8.pc' for compatibility, along with
> `guile.pc' (which would then become the Right One), both with
> "Version: 2.0"?
I think this is a bad idea. Only Guile 1.8 should claim to be Guile 1.8.
Packages that can compile against either need to select their version in
their configure.ac. GStreamer-depending apps did this successfully in
their transitions (0.{6,8,10}).
See http://www106.pair.com/rhp/parallel.html.
Regards,
Andy
--
http://wingolog.org/
Re: review/merge request: wip-array-refactor
Hello Ludovic :) On Sun 09 Aug 2009 18:41, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo writes: > >> The second model is when you already have a wide deployed base. You can >> make additions to your API and ABI, and deprecated old API or ABI, but >> you can't remove old API or change the ABI. Incompatible breaks are >> painful, and the switching-over time is somewhere between a year and >> three years. The right length of a stable series seems to be about 4 or >> 5 years. > > I'm in favor of sticking to this model, i.e., paying attention to both > source and binary compatibility. That sounds important to me as Guile > is an old piece of software for which users may expect a relative > stability and clear upgrade path when that is needed. I agree. >> I've written lots of code that deals with srfi-4 vectors. I have three >> kinds of use cases. First is data being shoved around in a >> dynamically-typed system: dbus messages, gconf values, a system we >> at work, etc. Second, but related, is dealing with chunks of data that >> come from elsewhere, like GDK pixbufs, or GStreamer buffers. Third is >> hacking compilers, as in Guile itself, or emitting machine code for >> other machines. > > My feeling is that the 1st and 3rd use cases are what bytevectors were > written for in the first place. Agreed. > SRFI-4 is a good fit for the 2nd use case as you're dealing with > fixed-width native-endianness numbers coming from C code. Agreed, modulo the possibility for this data to be embedded within some other stream. > But in this case, I don't think bytevectors are needed at all. I think they are needed whenever you want to *do* something with this data -- i/o for example. >> In summary... I don't mean to be a bore, but I really don't like the >> existing unif.c and srfi-4.c. They are painful to understand and to hack >> on. I think those bits should be merged. > > Agreed. OK, I'll see about merging up until the polymorphic change after the release. >> I also think that srfi-4 vectors should be implemented in terms of >> bytevectors, for the reasons above. > > I'm not convinced, but OTOH, I don't think it hurts. > > Like Neil, the one thing that I'm not fond of is the switch from > disjoint SRFI-4 types to polymorphic types, because programming errors > that currently yield a `wrong-type-arg' error will be silently ignored. > The SRFI text allows it, but the rationale says that "the use of > homogeneous vectors allows certain errors to be caught earlier." OK. Hopefully when I do my merge, the advantages/disadvantages of the various approaches will be more clear to all of us (including myself). Cheers, Andy -- http://wingolog.org/
Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled
Heya, On Sat 08 Aug 2009 23:52, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo writes: > >> Perhaps the deal is that 1+ is not being inlined. It seems to be calling >> out to the 1+ procedure, which is a primitive, actually making it a >> bit slower. I'll see what I can do. > > Currently, invoking subrs conses, which is Bad(TM). Indeed. > Code that keeps invoking `1+' and `1-' must suffer from this. Not any more! There are add1 and sub1 instructions now. A -- http://wingolog.org/
Re: Updated Guile Tutorial
On Thu 06 Aug 2009 20:34, Daniel Kraft writes: > the last days, I worked on a rewrite of the Guile Tutorial (with the > Tortoise package); just for fun, but also to update some stuff to my > liking and last but not least change the API usage from the deprecated > GH routines to the current scm_ ones. This is great work. Thanks for bringing our tutorial up to date! I just looked over the existing tutorial, and wow, anything that mentions Lotus 1-2-3, and fvwm... A few comments, IMO of course. Neil probably has a better perspective. 1) It would be better to have a more neutral narrator -- not a first-person narrator. If you feel like you need to speak from the first person, use "we". OTOH your style is infectious :), so perhaps it would work as "Guile Tutorial, by Daniel Kraft" :) 2) Don't mention the history of the tutorial. Just have it be a current document. 3) In general, use short sentences. Let your words breathe. 4) If you're forking to run gnuplot, why not do so from Scheme? Of course if you did that it would obviate the whole "extending C" story, but still, if given this particular problem, that's what I'd do. 5) Running a main loop (as gtk+ does) and a REPL is indeed an interesting problem. See event-repl.scm or graphical-repl.scm in guile-gnome for a couple of takes. 6) I wish we had a better Scheme->C story; our C->Scheme story is fine, but a better FFI would be nice. Anyway, IMO, FWIW, etc. If you don't reply, I'll probably just commit your tutorial more-or-less as-is to the repo :) A -- http://wingolog.org/
