Heads up: Releasing 1.8.2

Heads up: Releasing 1.8.2

[Ludovic Courtès]

Hi,

I think we should release 1.8.2 soon.  A number of compile-time and
run-time bugs have been fixed in the 1.8 branch, most of which
(hopefully) appear in the `NEWS' file.

Last time I asked him, Rob told me he was not able to handle it for the
moment, but maybe this has changed since then.  Otherwise, someone else
will have to take care of this.  I could do it but I'm not familiar with
the whole process, so maybe I'm not the best candidate for this.

Suggestions welcome!

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Heads up: Releasing 1.8.2

[Greg Troxel]

Sounds good, and it would be really nice to fix the slib support.


> guile
guile> (use-modules (ice-9 slib))
WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provide'
WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provided?'
guile> (version)
"1.8.1"
guile> 

The problem is that native guile has provide/require, and so does slib.
Guile used to use different words, and they were changed for some
reason.  My view is that slib is a de facto reserved namespace :_)




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Heads up: Releasing 1.8.2

[Ludovic Courtès]

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> Sounds good, and it would be really nice to fix the slib support.

I'll look into it "one of these days", but I think we need to release
ASAP, with or without it.  Personally, I'd like to increase the stable
release pace.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Heads up: Releasing 1.8.2

[Mikael Djurfeldt]

2007/6/25, Greg Troxel <gdt@ir.bbn.com>:
> > guile
> guile> (use-modules (ice-9 slib))
> WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provide'
> WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provided?'
> guile> (version)
> "1.8.1"
> guile>
>
> The problem is that native guile has provide/require, and so does slib.
> Guile used to use different words, and they were changed for some
> reason.  My view is that slib is a de facto reserved namespace :_)

Isn't the original and only purpose of Guile's provide/require to be
part of support for slib?  I think the idea was to tell slib (and
other code) what feature sets are already present in Guile.  My guess
is that the original was simply a clone of the corresponding parts of
slib, so that they could simply replace the slib version.

With time, however, slib has developed independently of Guile.  I
think what needs to be done is to come to an agreement with Aubrey
Jaffer of how the interface to slib should look like and how it should
be maintained.  When I last looked at it, slib's Guile interface was
based on heavily outdated assumptions.  Preferably, the Guile part of
slib should be minimal, giving larger freedom for development on both
sides.

When doing this, it is important that the result works well with
Guile's module system.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Heads up: Releasing 1.8.2

[Greg Troxel]

"Mikael Djurfeldt" <mikael@djurfeldt.com> writes:

> Isn't the original and only purpose of Guile's provide/require to be
> part of support for slib?  I think the idea was to tell slib (and
> other code) what feature sets are already present in Guile.  My guess
> is that the original was simply a clone of the corresponding parts of
> slib, so that they could simply replace the slib version.

That sounds believable to me.  A quick grep shows that it's a bit messier.  If provides/require and friends are only internal to guile, and not part of the inerface to the user, and are for  a different purpose, it seems easy enough

I should note that the 1.8.1 I'm using replaces ice-9/slib.scm:

# scmconfig.h will be rebuilt first thing.  This hack is here because
# gen-scmconfig.c includes string.h (from /usr/include) which in turn
# tries to include /usr/include/strings.h but instead the compiler picks
# up ./strings.h which tries to include scmconfig.h which doesn't exist
# yet.  While not a clean fix, this seems to work around the problem.
#
# 
# for info on the slib part, see
# http://lists.gnu.org/archive/html/guile-user/2006-11/msg00035.html
post-patch:
        ${TOUCH} ${WRKSRC}/libguile/scmconfig.h
        echo "(define-module (ice-9 slib))" > ${WRKSRC}/ice-9/slib.scm
        echo "(load-from-path \"slib/guile.init\")" >> ${WRKSRC}/ice-9/slib.scm 
> With time, however, slib has developed independently of Guile.  I
> think what needs to be done is to come to an agreement with Aubrey
> Jaffer of how the interface to slib should look like and how it should
> be maintained.  When I last looked at it, slib's Guile interface was
> based on heavily outdated assumptions.  Preferably, the Guile part of
> slib should be minimal, giving larger freedom for development on both
> sides.

I agree.  The above is pretty minimal, except that there's a definition
of provide and require.

Probably slib should have a procedure that's callable just after init to
give it a list of names that the native implementation provides.  I see
no need for provide native guile to have provide/require.

> When doing this, it is important that the result works well with
> Guile's module system.

Yes, but I think now all the slib symbols end up in (ice-9 slib), and
get exported, and that's ok.

I think that fixing the requires confusion and slib/module system
interaction are orthogonal, and that we might as well do the requires
stuff first.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Heads up: Releasing 1.8.2

[Mikael Djurfeldt]

2007/6/26, Greg Troxel <gdt@ir.bbn.com>:
> I should note that the 1.8.1 I'm using replaces ice-9/slib.scm:
> [...]
>         echo "(define-module (ice-9 slib))" > ${WRKSRC}/ice-9/slib.scm
>         echo "(load-from-path \"slib/guile.init\")" >> ${WRKSRC}/ice-9/slib.scm
> >  Preferably, the Guile part of
> > slib should be minimal, giving larger freedom for development on both
> > sides.
>
> I agree.  The above is pretty minimal, except that there's a definition
> of provide and require.

It's not minimal at all.  guile.init contains over 600 lines of code,
many of which refers to peculiarities and internals of specific
versions of Guile.  A lot of that code belongs more naturally to the
Guile side of the interface to slib.  What you should try to achieve
is a minimal *interface* towards slib which is not likely to change.
The Guile side of this interface can then be voluminous as long as
that code is maintained by the Guile developers.

Things like (guile.init):
;;; Hack to make syncase macros work in the slib module
(if (nested-ref the-root-module '(app modules ice-9 syncase))
    (set-object-property! (module-local-variable (current-module) 'define)
			  '*sc-expander*
			  '(define)))

should not be used in an interface to all versions of Guile and should
not be maintained by Aubrey Jaffer.

> Probably slib should have a procedure that's callable just after init to
> give it a list of names that the native implementation provides.  I see
> no need for provide native guile to have provide/require.

Right.  In any case, the list of features should not, as it is now, be
provided in slib's guile.init, because it is bound to be false for
some Guile versions.

> I think that fixing the requires confusion and slib/module system
> interaction are orthogonal, and that we might as well do the requires
> stuff first.

Sounds reasonable.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Heads up: Releasing 1.8.2

[Kevin Ryde]

"Mikael Djurfeldt" <mikael@djurfeldt.com> writes:
>
> Isn't the original and only purpose of Guile's provide/require to be
> part of support for slib?

It wasn't a clone of what's in emacs was it?  And/or a way to have
built-time optional bits present or not in the guile core, like threads?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel