Re: Items blocking release 1.6.1 (2002-04-21)

Re: Items blocking release 1.6.1 (2002-04-21)

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 22 Apr 2002 20:44:36 +0200

   [ice-9/optargs.scm bound? removal]

   Ok, I'll looker closer into this, and I now have to say that we can't
   'fix' it.  We would be changing the default default value from '#f'
   to something else.  That would be an unacceptable interface change.

but removing `bound?' is acceptable?

   Since it is easy for the user to provide the functionality on its
   own, we can just leave it as it is.

to provide out of band info, you can use out of band methods (in fact,
this is the fix i thought you were going to consider).

cc'ing guile-user to see who complains (besides me).  maybe someone can
send a patch to do a clean fix, and explain it.  maybe it's time to fork
guile (again).

thi

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> cc'ing guile-user to see who complains (besides me).  maybe someone can
> send a patch to do a clean fix, and explain it.  maybe it's time to fork
> guile (again).

If you think it's worth forking guile over this, please do.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Mon, 22 Apr 2002 15:15:34 -0500

   If you think it's worth forking guile over this, please do.

you missed the irony: the act of introducing gratuitous incompatibility
(and subsequently allowing it to fester) is de facto "forking guile".
guile credibility is down because it has been f**ked so, many times.

paraphrased from some sig: it's not foolish to do foolish things, it's
foolish if we don't see the folly.  personally, i was foolish to think i
could help guile improve w/o seeing the folly that it is the guile
maintainers who need to improve (which is outside my control).

thi

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> personally, i was foolish to think i could help guile improve w/o
> seeing the folly that it is the guile maintainers who need to
> improve (which is outside my control).

Of course you can help guile improve -- your past history and good
work is proof of that.

I can't speak for everyone else, but I'd really like to try to work
*with* the other maintainers to resolve our outstanding issues.  If I
wasn't interested in that I wouldn't be taking the time to do the
things I've been doing, including trying to work out a release process
everyone can agree on that will hopefully help avoid the disagreements
we recently had on the subject.

In this particular case, instead of the response you posted, I'd like
to hear what your specific complaints are wrt bound?, and to hear what
fix you have in mind, if any.  For example, you mention using
out-of-band communications, but can this be done in a way that doesn't
force everyone to change their code anyway?  If not, then how is it
any different than just removing bound?

Note that these aren't rhetorical questions.  I'm not all that
familiar with the issue since it wasn't my bug, and so I'd like to
understand all the considerations.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> In this particular case, instead of the response you posted, I'd like
> to hear what your specific complaints are wrt bound?, and to hear what
> fix you have in mind, if any.  For example, you mention using
> out-of-band communications, but can this be done in a way that doesn't
> force everyone to change their code anyway?  If not, then how is it
> any different than just removing bound?

Also FWIW the guile 1.4 info pages don't mention bound? AFAICT, and
anyone who found the mention of it in NEWS also saw:

  The optional argument module also exports the macros `let-optional',
  `let-optional*', `let-keywords', `let-keywords*' and `bound?'. These
  are not documented here because they may be removed in the future,
  but full documentation is still available in optargs.scm.

So bound?'s status was somewhat ambiguous in our last release.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> So bound?'s status was somewhat ambiguous in our last release.

Just to clarify -- that doesn't mean I think we *should* drop it.  I
just want us to try and figure out what the "right" answer is with as
much relevant information at hand as possible.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Mon, 22 Apr 2002 16:12:23 -0500

   Note that these aren't rhetorical questions.  I'm not all that
   familiar with the issue since it wasn't my bug, and so I'd like to
   understand all the considerations.

these were all discussed before.  when you ask people to repeat
themselves, they tend to reply obliquely at best, just to keep
interested.

part of maintaining the bugs database is to add relevant discussion to
the file so that everyone can see the thinking process clearly (which
reduces rehash).  alternatively we can be wombats, completely forgetting
that research can be viewed as a proper supserset of search.

for example, i recently asked about difference between characterset
designs, w/o doing the requisite digging.  the resulting silence tells
me this was unwise.

thi

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> for example, i recently asked about difference between characterset
> designs, w/o doing the requisite digging.  the resulting silence tells
> me this was unwise.

Or perhaps (at least wrt to my input) poorly timed -- I've seen the
(very long) character set discussion come up more than once, and
though I'm no expert, I'd be more than happy to try and work out a
good solution, but I'm not personally likely to do it before 1.6.1 is
released.  If others want to work on this right now, and can still
deal with the release critical issues then as far as I'm concerned,
that's fine.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Bill Gribble]

On Mon, 2002-04-22 at 15:05, Thien-Thi Nguyen wrote:
> cc'ing guile-user to see who complains (besides me).  maybe someone can
> send a patch to do a clean fix, and explain it.  maybe it's time to fork
> guile (again).
  
Is it a coincidence that 'Thien-Thi' could be pronounced close to
'TNT'?  It seems like you're jumping right to the discussion-ending
threat to fork Guile well before the diplomatic channels have been
exhausted.  Your emissaries are still trying to get through the
receiving line at the opening night cocktail party!  

b.g.
 


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

Re: Items blocking release 1.6.1 (2002-04-21)

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 22 Apr 2002 15:29:42 -0500

   Is it a coincidence that 'Thien-Thi' could be pronounced close to
   'TNT'?

well, they say destruction is the first step in optimization...

   It seems like you're jumping right to the discussion-ending threat to
   fork Guile well before the diplomatic channels have been exhausted.
   Your emissaries are still trying to get through the receiving line at
   the opening night cocktail party!

i hope they get loaded so i can steal their shoes for more podium
pounding (mine are worn out at the "heal" ;-).

thi

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    Ok, I'll looker closer into this, and I now have to say that we can't
>    'fix' it.  We would be changing the default default value from '#f'
>    to something else.  That would be an unacceptable interface change.
> 
> but removing `bound?' is acceptable?

Yes.  The way the old 'bound?' was implemented was a bug.  The mistake
(my mistake) back then was to fix this bug in a sub-optimal way, by
just removing the functionality.  Now it is too late to change it
again; and changing it would be quite gratuitous, too.

Using #f as the default default value is a sensible thing, I'd say,
and should even be recommended.  From a robustness standpoint,
distinguishing between explicitely specifying a keyword with its
default value in a function call, and not specifying it, should not be
done.  That is, it is better to say "When you don't specify the :foo
keyword, it's value is defaulted to #f.  A value of #f means bla."
instead of "When you don't specify the :foo keyword, it means bla."

>    Since it is easy for the user to provide the functionality on its
>    own, we can just leave it as it is.
> 
> to provide out of band info, you can use out of band methods (in fact,
> this is the fix i thought you were going to consider).

Yes, but we would have to change the semantics of (ice-9 optargs) in a
way that could lead to silent failures.  Removing 'bound?' did not do
that.

> cc'ing guile-user to see who complains (besides me).  maybe someone can
> send a patch to do a clean fix, and explain it.  maybe it's time to fork
> guile (again).

I think it would be smarter to just fork (ice-9 optargs), if you can
make such fine distinctions.

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

Re: Items blocking release 1.6.1 (2002-04-21)

[tomas]

Hi,

it's not my intention to complicate further an already
delicate discussion, but just to supply an user's point
of view:

On Tue, Apr 23, 2002 at 08:16:20PM +0200, Marius Vollmer wrote:
[...]
> Yes.  The way the old 'bound?' was implemented was a bug.  The mistake
> (my mistake) back then was to fix this bug in a sub-optimal way, by
> just removing the functionality.  Now it is too late to change it
> again; and changing it would be quite gratuitous, too.
> 
> Using #f as the default default value is a sensible thing, I'd say,
> and should even be recommended.

As a provider of some functionality I'd sometimes like to be able
to distinguish between `value was provided' and `value was not
provided at all'. It'd be perfectly reasonable to agree on a
value which means `not provided' (like Perl's undef or Pythons
None): an user providing *such* a value hopefully knows what
she's doing...

>                                  From a robustness standpoint,
> distinguishing between explicitely specifying a keyword with its
> default value in a function call, and not specifying it, should not be
> done.  That is, it is better to say "When you don't specify the :foo
> keyword, it's value is defaulted to #f.  A value of #f means bla."
> instead of "When you don't specify the :foo keyword, it means bla."

...but #f seems to be just wrong, since it's an often-used `logical'
value. Unspecified seems nice for something ``you don't specify'',
doesn't it? (I know, you were against that on a previous posting).

(BTW. I just resisted the temptation to propose '(), because
that's quite another thread ;->

Thanks
-- tomas

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

Re: Items blocking release 1.6.1 (2002-04-21)

[rm]

On Thu, Apr 25, 2002 at 11:09:14AM +0200, tomas@fabula.de wrote:
> On Tue, Apr 23, 2002 at 08:16:20PM +0200, Marius Vollmer wrote:
> [...]
> > Yes.  The way the old 'bound?' was implemented was a bug.  The mistake
> > (my mistake) back then was to fix this bug in a sub-optimal way, by
> > just removing the functionality.  Now it is too late to change it
> > again; and changing it would be quite gratuitous, too.
> > 
> > Using #f as the default default value is a sensible thing, I'd say,
> > and should even be recommended.
> 
> As a provider of some functionality I'd sometimes like to be able
> to distinguish between `value was provided' and `value was not
> provided at all'. It'd be perfectly reasonable to agree on a
> value which means `not provided' (like Perl's undef or Pythons
> None): an user providing *such* a value hopefully knows what
> she's doing...
> 
> >                                  From a robustness standpoint,
> > distinguishing between explicitely specifying a keyword with its
> > default value in a function call, and not specifying it, should not be
> > done.  That is, it is better to say "When you don't specify the :foo
> > keyword, it's value is defaulted to #f.  A value of #f means bla."
> > instead of "When you don't specify the :foo keyword, it means bla."

I'd like to second Tomas here. Default values are essential for some
applications (esp. if guile want's to be used as a scripting language).
I don't want to force my users to have to specify all possible keywords
and i can well imagine that i need to have keywords with boolean values:

 (read-text :convert-newline #f) =/= (read-text) 

 (foo-create-window )  =?= (foo-create-window :map #f)

> 
> (BTW. I just resisted the temptation to propose '(), because
> that's quite another thread ;->

   ... not to mention NIL :-)

 Thanks
  ralf
  

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Marius Vollmer]

rm@fabula.de writes:

> I'd like to second Tomas here. Default values are essential for some
> applications (esp. if guile want's to be used as a scripting language).

Yes, of course.  The quibbling is over the default default value,
i.e. the value to use as a default value when no default value has
been specified explicitely.

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 28 Apr 2002 18:00:00 +0200

   Yes, of course.  The quibbling is over the default default value,
   i.e. the value to use as a default value when no default value has
   been specified explicitely.

no the quibbling is over removal of `bound?' (see summary field in the
bug report).  if you can expand the problem-solving process to solve
this (original) problem, that would be best.

remember to cover the case where an arg may be bound and have a
(internally consistent) value of #f.  i.e., whether or not an arg is
bound is indepdendent of its value.

thi

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 28 Apr 2002 18:00:00 +0200
> 
>    Yes, of course.  The quibbling is over the default default value,
>    i.e. the value to use as a default value when no default value has
>    been specified explicitely.
> 
> no the quibbling is over removal of `bound?' (see summary field in the
> bug report).  if you can expand the problem-solving process to solve
> this (original) problem, that would be best.

Yes, right.  I would propose to follow Common Lisp here:

    (define* (foo :optional (bar #f bar-bound?))
      (if bar-bound?
          ...))

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Marius Vollmer]

tomas@fabula.de writes:

> On Tue, Apr 23, 2002 at 08:16:20PM +0200, Marius Vollmer wrote:
> [...]
> > Yes.  The way the old 'bound?' was implemented was a bug.  The mistake
> > (my mistake) back then was to fix this bug in a sub-optimal way, by
> > just removing the functionality.  Now it is too late to change it
> > again; and changing it would be quite gratuitous, too.
> > 
> > Using #f as the default default value is a sensible thing, I'd say,
> > and should even be recommended.
> 
> As a provider of some functionality I'd sometimes like to be able
> to distinguish between `value was provided' and `value was not
> provided at all'. It'd be perfectly reasonable to agree on a
> value which means `not provided' (like Perl's undef or Pythons
> None): an user providing *such* a value hopefully knows what
> she's doing...

Yes.  You can do this easily when defining such a function.  I.e.

    (define not-provided (cons* 'not-provided))

    (define* (foo :optional (bar not-provided))
      (if (eq? not-provided bar)
          ...))

> ...but #f seems to be just wrong, since it's an often-used `logical'
> value.

To me, it seems just right as a default default value...

> Unspecified seems nice for something ``you don't specify'',
> doesn't it? (I know, you were against that on a previous posting).

You might use the 'unspecified value' (which is different from
SCM_UNDEFINED which was used previously) as the value of not-provided
above, but it seems to be too obscure, for my taste.  It doesn't feel
right to me to give #<unspecified> any specific meaning.

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

Re: Items blocking release 1.6.1 (2002-04-21)

[spu]

On Sun, Apr 28, 2002 at 05:58:34PM +0200, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 
> > On Tue, Apr 23, 2002 at 08:16:20PM +0200, Marius Vollmer wrote:
> > [...]
[...]
> Yes.  You can do this easily when defining such a function.  I.e.
> 
>     (define not-provided (cons* 'not-provided))
> 
>     (define* (foo :optional (bar not-provided))
>       (if (eq? not-provided bar)
>           ...))

Ah, I see now. Sorry for being ummm... thick.
-- 
tomas

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

Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Since I've had no negative feeback regarding my release management
posts, I'm planning to add those to our policy documentation and
proceed accordingly.

If you haven't read those messages yet, please do, but the summary is
that the stable TODO section and the bugs tagged release critical
represent the *complete* set of items holding up the release, and you
should not change this set after the stable release has branched
without discussing it with the release manager first (i.e. me).

Whenever we're near a stable release, I'll be posting this "blocking
list" on a regular basis as a reminder.  NOTE: if you're working on
something that's listed below, please contact me.  If your bit is not
in the TODO or bugs and marked appropriately, I may release without
it.

Items currently listed as holding up the 1.6 release are listed below.
More information needed from: [mvo], [ttn].

(The bugs listed as belonging to me I can fix in a day, so please
don't wait on me.)

(1) bugs/optargs-bound-gone [mvo?]

  Marius: you discussed a fix for this in email, but also mention that
  it's functionality is fairly easily worked around via default value
  -- so are we fixing it for 1.6, or are we adding a NEWS entry
  recommending the alternative approach?  If we are fixing it, and if
  you can describe the fix, I can do the work.

(2) bugs/intructions-to-distributors [rlb]

  I'll handle this one -- I'll either have full fledged instructions
  by the release, or I'll include some information and a request for
  packagers to contact guile-devel before packaging.  This will depend
  on how far I get before all the other release critical bugs are
  finished.

(3) tasks/TODO - document libtool conventions [rlb]

  Needs to be done -- will do.

(4) tasks/TODO - convert bug tracking/summarization process

  Is this really 1.6 release critical?  It seems like it could be
  moved to a 1.8 section or "Eventually" to me, but I may be missing
  something.  For 1.6, it seems like we can easily just create copy
  BUGS by hand if this is likely to hold things up any longer.

(5) tasks/TODO - write build/bugs-triage.text
               - complete build/stability.text [ttn]
               - make sure all bugs have required headers

  Are these really 1.6 release critical?  I'm inclined to want to move
  these to the 1.8 section as well.  While I think these improvements
  are important, and should certainly be finished by 1.8, they don't
  seem like anything that can't wait until 1.6.2, etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Sun, 21 Apr 2002 11:22:22 -0500

   Since I've had no negative feeback regarding my release management
   posts, I'm planning to add those to our policy documentation and
   proceed accordingly.

i'm making my way up to a full response (w/ some hopefully constructive
feedback)...  gist is: good first stab!  however, you risk bad PR karma
if you write policy that you don't follow.  that is akin to writing code
that you don't use.

adding these writings to workbook/ in present form is fine -- any
required refinements can only benefit from early publishing and the
consequently wider review.  don't let my pending response (probably done
tomorrow) gate your cvs commits.

thi

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> i'm making my way up to a full response (w/ some hopefully constructive
> feedback)...  gist is: good first stab!  however, you risk bad PR karma
> if you write policy that you don't follow.  that is akin to writing code
> that you don't use.

Totally agreed.  Have I been doing that since last week?

> adding these writings to workbook/ in present form is fine -- any
> required refinements can only benefit from early publishing and the
> consequently wider review.  don't let my pending response (probably
> done tomorrow) gate your cvs commits.

I may not be able to get to this for a day or so regardless.  We'll
see.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> (1) bugs/optargs-bound-gone [mvo?]

Yes, it's [mvo].

>   Marius: you discussed a fix for this in email, but also mention that
>   it's functionality is fairly easily worked around via default value
>   -- so are we fixing it for 1.6, or are we adding a NEWS entry
>   recommending the alternative approach?  If we are fixing it, and if
>   you can describe the fix, I can do the work.

I'll fix this this evening.

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Yes, it's [mvo].
>
>>   Marius: you discussed a fix for this in email, but also mention that
>>   it's functionality is fairly easily worked around via default value
>>   -- so are we fixing it for 1.6, or are we adding a NEWS entry
>>   recommending the alternative approach?  If we are fixing it, and if
>>   you can describe the fix, I can do the work.
>
> I'll fix this this evening.

Great.  I'll fix my bugs soon too, and then depending on what
Thien-Thi thinks about the other items in the list, we may be ready
for a new beta release.  After that (according to the new policy) if
nothing too bad happens, the stable release will be a week or so
later.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> >   Marius: you discussed a fix for this in email, but also mention that
> >   it's functionality is fairly easily worked around via default value
> >   -- so are we fixing it for 1.6, or are we adding a NEWS entry
> >   recommending the alternative approach?  If we are fixing it, and if
> >   you can describe the fix, I can do the work.
> 
> I'll fix this this evening.

Ok, I'll looker closer into this, and I now have to say that we can't
'fix' it.  We would be changing the default default value from '#f' to
something else.  That would be an unacceptable interface change.
Since it is easy for the user to provide the functionality on its own,
we can just leave it as it is.

Sorry, this didn't occur to me before.

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

Re: Items blocking release 1.6.1 (2002-04-21)

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Ok, I'll looker closer into this, and I now have to say that we can't
> 'fix' it.  We would be changing the default default value from '#f' to
> something else.  That would be an unacceptable interface change.
> Since it is easy for the user to provide the functionality on its own,
> we can just leave it as it is.
>
> Sorry, this didn't occur to me before.

OK, I saw you marked it fixed, I'll take off the release critical
tag.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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