This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile docstrings---should Guile code be ANSI C compatible?


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

<snip>

> But in configure.in, I've written:
> 
> AC_CACHE_CHECK([for long longs], scm_cv_long_longs,
> 	       AC_TRY_COMPILE(,
> 			      [long long a],
> 			      scm_cv_long_longs=yes,
> 			      scm_cv_long_longs=no))
> if test "$scm_cv_long_longs" = yes; then
>   AC_DEFINE(HAVE_LONG_LONGS)
> fi
> 
> I hope I'm strictly using it only if HAVE_LONG_LONGS is defined.

I don't see where that guard is for the uses around __scm.h:114.

<snip>

> > Alternatively, some good Emacs tools for managing the docstrings \n\
> > terminators (e.g., reformatting a docstring, adding the \n\ lines, etc.)
> > might be really useful.
> 
> I'm used to using the bleading edge of Guile development.  Until now
> that hasn't actually been any big problem.  I think it is a good
> principle to try to let the repository always represent as close as
> possible what is finally going to go out in the release---that way we
> get a lot of valuable testing and early bug fixing done.
> 
> I can volunteer to make Emacs tools for removing/adding the \n\.

That'd be great!

> 
> > > Maciej, could you please make a decision which route we should take.
> > 
> > Again, I think it'd be insane to not have the docstrings properly
> > terminated by release time, but my script shows that we can get there
> > pretty easily whenever we want to, and I think it wiser to fall on the
> > side of convenience to developers in the short term.  Anyone using guile 
> > from CVS better be competent enough to apply the script to make a more
> > ANSI-like version to compile on a stricter compiler.
> 
> I fully understand that it creates a lot of unnecessary work to edit
> the strings by hand with the \n\ in the code.
> 
> I prefer the Emacs solution before the script solution, though,
> because of the above reason and because it is conceptually simpler.

I agree, but I'd rather wait until there is the Emacs solution before
changing the code in the repo;  the script can then change the code for
the repo when the Emacs commands are working and tested.

> > I'd feel a little differently if there are lots of folks contributing
> > who do their main dev work on systems w/ the stricter rules (since
> > committing for them will be annoying; maybe then we'd need a script to
> > undo the \n\ terminators, too), but I don't have any evidence to believe 
> > that that's the case.
> 
> I'm trying to report it (it once worked) to our supercomputer right
> now...

Hopefully won't be too hard... 

> 
> /mdj
> 
> P.S. It's great, Greg, it's great! (it truly is) :)


Thanks :-)

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]