Re: Patch: New section "Invoking Guile" for chapter "Programming in Scheme"

[Andy Wingo <wingo@pobox.com>]

Hi Mark,

On Sun 24 Apr 2011 23:58, Mark Harig <idirectscm@aim.com> writes:

> On Sun, Apr 24, 2011 at 11:00:16PM +0200, Andy Wingo wrote:
>> 
>> Right, at the end of applying all of your patches, I'm sure that's the
>> case; however the first patch adds an @include without adding the
>> appropriate file, so applying just the first patch without the following
>> two would yield a project that doesn't compile.  I just meant that you
>> need to squish the first two or three of them together.  I can do that
>> when I apply them, though.
>> 
>
> What do guile developers normally do when generating the
> patches?  ('git format-patch origin' is generating three
> separate files.  Do you concatenate the patch files that
> 'git' emits?)  Please let me know if there is a documented
> recipe that guile-devel uses that I can follow for future
> changes.

We use git-format-patch, yes.  The separate files that it generates
correspond to the separate git commits that you made.  In order to
generate an atomic commit, you will need to squash your patches
together.  To do this, do an interactive rebase in git.

Interactive rebase is described here:

    http://book.git-scm.com/4_interactive_rebasing.html

You would "pick" the first patch, then "squash" the next two.  That
would yield one atomic commit, which would then be written by
git-format-patch into one atomic patch.

I highly recommend reading more, experimenting, making backups, etc;
rebase is wonderful once you get the hang of it, but it is a sharp
tool.  Good luck!

>> > +For compatibility with some versions of Guile 1.4, you can also use the
>> > +form @code{(symbol ...)} (that is, a list of only symbols that doesn't
>> > +start with @code{@@}), which is equivalent to @code{(@@ (symbol ...)
>> > +main)}, or @code{(symbol ...)  symbol} (that is, a list of only symbols
>> > +followed by a symbol), which is equivalent to @code{(@@ (symbol ...)
>> > +symbol)}.  We recommend to use the equivalent forms directly since they
>> > +correspond to the @code{(@@ ...)}  read syntax that can be used in
>> > +normal code.  See @ref{Using Guile Modules} and @ref{Scripting
>> > +Examples}.
>> 
>> Again, probably worth eliding the deprecated 1.4 stuff...
>> 
>
> It's not clear to me what you mean here.  Please provide the
> text that you would like.  (I did not review the
> "command-line options" section for content because my
> original proposal was to keep that section and add a missing
> "environment variables" section.)

I recommend removing this paragraph, or removing mentions of Guile 1.4.
But as you note, that could be a separate atomic commit, and you don't
have to take care of that now.

>> > +@item --auto-compile
>> > +Compile source files automatically (default behavior).
>> > +
>> > +@vnew{2.0}
>> > +
>> > +@item --no-auto-compile
>> > +Disable automatic source file compilation.
>> > +
>> > +@vnew{2.0}
>> 
>> Need --fresh-auto-compile here too
>> 
>> > +@item GUILE_AUTO_COMPILE
>> > +@vindex GUILE_AUTO_COMPILE
>> 
>> Need to note GUILE_AUTO_COMPILE=fresh, and @ref to Compilation
>> 
>
> I do not know what that option does (other than a guess).
> There has been no update to the Guile manual page or the
> reference manual mentioning it.

Are you working off of the "stable-2.0" branch?  There are updates there
for --fresh-auto-compile and GUILE_AUTO_COMPILE=fresh.

To rebase your work onto that branch, you would do a "git rebase
origin/stable-2.0".

Regards,

Andy
-- 
http://wingolog.org/