Re: [PATCH] Verify Size of Objcode Headers

2010-06-20 Thread Noah Lavine
Thanks for the corrections. I think this patch addresses them. Noah Add static checks to make sure that the statically-generated object code headers in continuations.c, control.c, foreign.c, gsubr.c and smob.c are the same length as the struct scm_objcode data type in objcodes.h. --- libguile/co

Re: fmatch

2010-06-20 Thread Ludovic Courtès
Hi! stefan writes: > I think that the match-define logic is something that is missing in the > Shinn version although I don't know how much this construct is used. Yes, I left a comment about it in ice-9/match.scm. > Basically $ is using the order of the records like ($ person? Rec1 Rec2 , ..

Re: when to #:replace

2010-06-20 Thread Ludovic Courtès
Hi! Andy Wingo writes: > Q: I have a module that overrides a core binding (like > make-hash-table). Should I #:export that binding or #:replace it? > > A: #:replace. Presumably the user knows what she is doing when she > uses your module. If she really cares she can change the duplicate

Re: r6rs library documentation

2010-06-20 Thread Julian Graham
Hey Andy, > I think that Neil would probably have the most useful feedback, as I > think he has the most global view of the manual. I am inclined to think > that the level of detail is appropriate, though I imagine that Neil and > Brian are cringing at the weight of the extra pages on the press ;

Re: [PATCH] Verify Size of Objcode Headers

2010-06-20 Thread Ludovic Courtès
Hi Noah, Thanks for the patch! Noah Lavine writes: > + scm_t_uint8 dummy[] = { OBJCODE_HEADER(5,5) }; > + VERIFY_OBJCODE_HEADER_SIZE(dummy); I think that: verify (sizeof (dummy) == sizeof (struct scm_objcode)); would be enough (see below). Perhaps the ‘SCM_UNUSED’ attribute is needed he

when to #:replace

2010-06-20 Thread Andy Wingo
Hello, As you probably know, Guile is fairly flexible when dealing with duplicate bindings -- one can warn, error, choose the last one, first one, etc. But currently there are lots of warnings, way too many. For example just using srfi-69 gives you a warning: WARNING: (guile-user): imported mo

Re: fmatch

2010-06-20 Thread stefan
On Wednesday 16 June 2010 11:31:14 pm Ludovic Courtès wrote: > Hi Stefan! > > Sorry for the late late reply. > > stefan writes: > > Anyway git diff --cached gives the attached patch file. > > > > Also I made the code less hacky by using define-syntax in stead > > of a defmacro and macroexpand f

Re: [PATCH] Verify Size of Objcode Headers

2010-06-20 Thread Andy Wingo
On Sun 20 Jun 2010 21:44, Noah Lavine writes: > Add static checks to make sure that the statically-generated object code > headers in continuations.c, control.c, foreign.c, gsubr.c and smob.c are the > same length as the struct scm_objcode data type in objcodes.h. I'd be happy to apply these. Wo

[PATCH] Verify Size of Objcode Headers

2010-06-20 Thread Noah Lavine
Add static checks to make sure that the statically-generated object code headers in continuations.c, control.c, foreign.c, gsubr.c and smob.c are the same length as the struct scm_objcode data type in objcodes.h. --- libguile/continuations.c |4 libguile/control.c |3 +++ libgui

[PATCH] Verify size of object code headers.

2010-06-20 Thread Noah Lavine
Add static checks to make sure that the statically-generated object code headers in continuations.c, control.c, foreign.c, gsubr.c and smob.c are the same length as the struct scm_objcode data type in objcodes.h. --- libguile/continuations.c |4 libguile/control.c |3 +++ libgui

Re: Static Asserts

2010-06-20 Thread Ludovic Courtès
Hi, Noah Lavine writes: > I discovered that my previous build failure was not because of a > Makefile issue but because my modifications had changed the size of > struct scm_objcode, which broke other parts of the program. I found > several files where structs are cast from bytes using #define'd

Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-11-112-g37620f3

2010-06-20 Thread Ludovic Courtès
Hi Andy, One small remark regarding the manual: "Andy Wingo" writes: > +A @code{set!} to a variable transformer may only expand to an expression, > not a > +definition -- even if the original @code{set!} expression was in definition > +context. This should read (in Texinfo) “not a definition-