Kevin Ryde escreveu:
>> I think it is reasonable to let deprecated interfaces live for one stable
>> release,
>
> You yourself have complained about things changed and removed, no?
> SCM_STRING_CHARS perhaps ... :-)
Perhaps, but I'm for cleaner code. Having to keep deprecated stuff
around (and w
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> If not now, is there any sort of timescale for when this is scheduled?
Hopefully never for many bits. I think several things have been
tagged unnecessarily.
If something is not very nice, then by all means shunt it off to a
corner of the manual a
Kevin Ryde escreveu:
>> does this also mean that we can (finally!) summarily throw away anything
>> that is marked as "deprecated GUILE 1.7" ?
>
> The short answer would be no, much too soon. The whole idea of
If not now, is there any sort of timescale for when this is scheduled?
I think it
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> (trap-enable 'memoization)
> ?
My remark on "test_flag" was just that set-test-flag sounds like it
could be anything, and could perhaps be more cleanly handled in the
debug-options. trap-options would be also ok.
_
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> The idea is that eventually we could plug in `localeconv' support
> transparently, i.e., the user-visible API would remain the same but it
> would become capable of using `localeconv' when `nl-langinfo' is not
> available (that would work only for mon
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> 4. No attempt is made to convert to a different encoding the strings
> returned by `nl_langinfo ()'.
Good.
> 5. High-level procedures for locale-dependent number output are
> provided, namely `number->locale-string' and
> `monetar
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> Should this be fixed,
No, that'd be an incompatible change (it's in the manual).
Slightly unfortunate, but not the end of the world.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> It's ok for 1.9 to break binary compatibility,
Don't do it gratuitously though, just because something will look
better.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listi
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> does this also mean that we can (finally!) summarily throw away anything
> that is marked as "deprecated GUILE 1.7" ?
The short answer would be no, much too soon. The whole idea of
discouraged etc is really bad. Forcing everyone to change their
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> can you be more specific? According to the URL that you posted, all GUILE
> multiline comments are non-GNU conformant, wrt. the opening * on each line.
Yes, the `*' opening on each line (many comments in Guile have it, not
all), the empty first
Ludovic Courtès escreveu:
>> I would like to change this order, and if possible move this out of
>> the global namespace. Are there any objections?
>
> It's ok for 1.9 to break binary compatibility, and it's also probably a
> good thing to not export things that are not documented. So I think
I
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> This is now in CVS, along with a couple of other changes.
>
> Thanks!
>
> Just a minor note: Could you make sure you follow the GNU style for,
> e.g., comments [0]?
can you be more specific? According to th
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> this order is awkward when a new trap option has to be added.
>>
>> The problematic thing is that this is exported to GUILE users, through
>>
>> #define SCM_ENTER_FRAME_P scm_evaluator_trap_table[1].val
>
13 matches
Mail list logo
