TODO for 2.0

TODO for 2.0

[Andy Wingo]

Hi all,

I would like to share my personal list of things to do before 2.0.

  * some bytecode tweaks
     - function prologues can be shorter in the common case
     - perhaps docstrings should take less space in objcode, by allowing
       them to be specified positionally in the program metadata,
       removing need to embed 'documentation symbol in meta-procedure

  * documentation for the repl

  * update tree-il/vm docs

  * some sort of resolution on the module namespace issue

  * guile-lib release

  * guile-gnome release

  * better source filenames for out-of-tree builds ("ice-9/foo.scm"
    instead of e.g. "../ice-9/foo.scm")

  * merge program-properties into procedure-properties

Please feel free to reply with your own lists. Please reply only with
things that you feel must be dealt with before 2.0, by somebody, or
things that you personally plan to work on (blocker or not).

Keep in mind that if you miss 2.0, there is the whole 2.0.x series in
which you can introduce compatible changes; and that 2.2 shouldn't take
more than a year or so to get out, depending on what goes in to it.

The endgame is at hand!

Andy
-- 
http://wingolog.org/

Re: TODO for 2.0

[Mike Gran]

Hi Andy,

> From: Andy Wingo wingo@pobox.com

> Please reply only with things that you feel must 
> be dealt with before 2.0, by somebody, or
> things that you personally plan to work on (blocker or 
> not).

Reenable Turkish casing tests in i18n.test.

Check for a BOM if the encoding is UTF-16 or UTF-32.

-Mike

Re: TODO for 2.0

[Julian Graham]

Hi Andy,


> Please feel free to reply with your own lists. Please reply only with
> things that you feel must be dealt with before 2.0, by somebody, or
> things that you personally plan to work on (blocker or not).

Unless R6RS-lib is something that can be merged in a subsequent 2.0.x
stable release, I'd really like to get that `wip-r6rs-libraries'
branch merged to master.  As mentioned in a separate thread [0], the
only thing standing in the way is the behavior I described that leads
to "Unbound variable" errors during `make' but not when compiling from
the REPL.  (I'm not totally convinced that it's not my code's fault,
but I'm pretty much stumped at this point in terms of debugging.)


Regards,
Julian

[0] - http://www.mail-archive.com/guile-devel@gnu.org/msg05278.html

Re: TODO for 2.0

[Ludovic Courtès]

Hi Andy,

Andy Wingo <wingo@pobox.com> writes:

>   * some bytecode tweaks
>      - function prologues can be shorter in the common case
>      - perhaps docstrings should take less space in objcode, by allowing
>        them to be specified positionally in the program metadata,
>        removing need to embed 'documentation symbol in meta-procedure

Likewise: review bytecodes; for instance, most of time integers are
written in native endianness, but sometimes they are in big endian, and
sometimes the width of integers seems quite arbitrary.

Besides:

  * Add Scheme code coverage.

  * Add tests for untested parts.

  * Fix ES compiler (but note, I’m not really volunteering on this one
    :-)).

  * Walk the bug tracker; fix incompatibility & portability bugs listed
    there.

  * Test on various platforms, fix fix fix.

  * Review the list of exported C symbols.  Possibly keep internal some
    of the C symbols introduced in 1.9 (aka. move away from C).

  * Investigate the precedence of “coding:” cookies vs. current locale
    (currently the current locale seems to have higher precedence.)

There’s also a wealth of optional things on my to-do list, of course.
;-)

Thanks,
Ludo’.

Re: TODO for 2.0

[Andy Wingo]

Hi Julian,

On Sun 18 Apr 2010 17:57, Julian Graham <joolean@gmail.com> writes:

> "Unbound variable" errors during `make' but not when compiling from
> the REPL.

> [0] - http://www.mail-archive.com/guile-devel@gnu.org/msg05278.html

I'll add this to my list, then. Is there no smaller test case than
compiling the entire wrapper module? Does this problem occur with
smaller libraries as well? I would love to have a simple test case that
I can run on master. I'll spelunk on your branch, though, if that's
necessary.

Andy
-- 
http://wingolog.org/

Re: TODO for 2.0

[Andy Wingo]

Hi,

On Sun 18 Apr 2010 22:53, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>>   * some bytecode tweaks
>>      - function prologues can be shorter in the common case
>>      - perhaps docstrings should take less space in objcode, by allowing
>>        them to be specified positionally in the program metadata,
>>        removing need to embed 'documentation symbol in meta-procedure
>
> Likewise: review bytecodes; for instance, most of time integers are
> written in native endianness, but sometimes they are in big endian, and
> sometimes the width of integers seems quite arbitrary.

Dunno. To be able to write in native endianness and actually see
benefits, the data needs to be aligned, too. Integer widths are
generally chosen as some point in the size/speed vs generality tradeoff.
I would be very hesitant about poking some of these; and I'd like an
opportunity to comment on patches :-)

> There’s also a wealth of optional things on my to-do list, of course.
> ;-)

Hehe, indeed.

Cheers,

Andy
-- 
http://wingolog.org/

Re: TODO for 2.0

[Julian Graham]

Hi Andy,


> I'll add this to my list, then. Is there no smaller test case than
> compiling the entire wrapper module? Does this problem occur with
> smaller libraries as well? I would love to have a simple test case that
> I can run on master. I'll spelunk on your branch, though, if that's
> necessary.

Thanks!  I've been trying to create a more discrete test case -- no
luck as yet, but I'll let you know if I come up with one.


Regards,
Julian

Re: TODO for 2.0

[Ken Raeburn]

On Apr 19, 2010, at 05:33, Andy Wingo wrote:
> Dunno. To be able to write in native endianness and actually see
> benefits, the data needs to be aligned, too. Integer widths are
> generally chosen as some point in the size/speed vs generality tradeoff.
> I would be very hesitant about poking some of these; and I'd like an
> opportunity to comment on patches :-)

For maximal benefit, yes, aligned values are best, but many processors can do unaligned loads with more efficiency than reading individual bytes and then assembling them together via logical operations -- x86, for example, can load from an unaligned address, and if I recall correctly, SPARC has a separate unaligned-load instruction.  It's not automatically supported by C compilers, which will assume that an object of a given type has at least the required alignment of that type, so when working on such things in my last job (for network protocol messages), I put together a bunch of inline functions for "read unaligned 32-bit value" etc., using GCC's support for packed (and only byte-aligned) structures when available, and doing the byte-by-byte version otherwise.  But except for the byte-by-byte version, they need the data to be in native order.

Of course, that doesn't work too well for 24-bit values directly, but you could use it for a 16-bit portion, or a 32-bit value if you know there's an extra byte available (e.g., the opcode itself) and which end it occurs on (to eliminate it).

Ken