Steel Bank Common Lisp

On Wed, Jul 18, 2007 at 12:38:25AM +0300, Nikodemus Siivola wrote:
> Our TODO file is quite out of date. Unless there are objections
> I'm going to replace it with the following in a few days:

That makes sense to me. I probably should've deleted the TODO stuff I
wrote long ago of letting it drift so far out of date, but if you have
the knack for putting together an uncontroversial list, that's even
better.

-- 
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph

Nikodemus Siivola wrote:
> Our TODO file is quite out of date. Unless there are objections
> I'm going to replace it with the following in a few days:

*snip*

Looks great to me. It looks like you got interrupted in the middle of an 
edit here:

>   The items are in no particular order. In addition to this file, there
>   is the BUGS file, hundreds of FIXME notes in the sources. (Things
                     ^ "and there are also" or so

-- 
Brian Mastenbrook
brian@...
http://brian.mastenbrook.net/

On 7/17/07, Nikodemus Siivola <nikodemus@...> wrote:
> Our TODO file is quite out of date. Unless there are objections
> I'm going to replace it with the following in a few days:

This is great.  Just a comment or two along the way.

> FINISHING EXTERNAL FORMATS
>
>   Byte order marks. Newline conventions. A way to specify an external
>   format without needing to duplicate code. Fixing the inefficiencies.

Unifying the stream code's idea of an external format and string-to-octets/
octets-to-string would be a good idea--not that the stream code has to use
octets-to-string, but that there'd be OAOO place where we talk about what
external formats we support.  Declaring high-level properties of external
formats (e.g. is this a single-byte encoding?) might help here too.

Redoing the stream code in general would probably be good to stick here.

Stackable streams (basically external-format support for streams that's
not tightly integrated with fd-streams).

The list is really quite long, isn't it? :(

-Nathan

> external formats we support.  Declaring high-level properties of external
> formats (e.g. is this a single-byte encoding?) might help here too.

it might be worth mentioning that Babel has such features and may be
useful for this in one way or another:

http://common-lisp.net/~loliveira/soc07/babel/

-- 
 attila

Attila Lendvai wrote:
>  > external formats we support.  Declaring high-level properties of 
> external
>  > formats (e.g. is this a single-byte encoding?) might help here too.
> 
> it might be worth mentioning that Babel has such features and may be
> useful for this in one way or another:
> 
> http://common-lisp.net/~loliveira/soc07/babel/

Why not add use of libiconv (optionally)?

-- 
WBR, Yaroslav Kavenchuk.

On 7/19/07, Yaroslav Kavenchuk <kavenchuk@...> wrote:
> Attila Lendvai wrote:
> >  > external formats we support.  Declaring high-level properties of
> > external
> >  > formats (e.g. is this a single-byte encoding?) might help here too.
> >
> > it might be worth mentioning that Babel has such features and may be
> > useful for this in one way or another:
> >
> > http://common-lisp.net/~loliveira/soc07/babel/
>
> Why not add use of libiconv (optionally)?

libiconv is GPL. ICU (http://icu-project.org/) has a much more SBCL
compatible license.

bye,

Erik.

Erik Huelsmann wrote:
 > On 7/19/07, Yaroslav Kavenchuk <kavenchuk@...> wrote:
 >  > Attila Lendvai wrote:
 >  > >  > external formats we support.  Declaring high-level properties of
 >  > > external
 >  > >  > formats (e.g. is this a single-byte encoding?) might help 
here too.
 >  > >
 >  > > it might be worth mentioning that Babel has such features and may be
 >  > > useful for this in one way or another:
 >  > >
 >  > > http://common-lisp.net/~loliveira/soc07/babel/
 >  >
 >  > Why not add use of libiconv (optionally)?
 >
 > libiconv is GPL. ICU (http://icu-project.org/) has a much more SBCL
 > compatible license.
 >

libiconv is LGPL

But it is possible to build sbcl with use of libiconv or ICU (or own
encoding) over `make.sh` options.

-- 
WBR, Yaroslav Kavenchuk.

William Harold Newman wrote:
> On Wed, Jul 18, 2007 at 12:38:25AM +0300, Nikodemus Siivola wrote:
>> Our TODO file is quite out of date. Unless there are objections
>> I'm going to replace it with the following in a few days:
> 
> That makes sense to me. I probably should've deleted the TODO stuff I
> wrote long ago of letting it drift so far out of date, but if you have
> the knack for putting together an uncontroversial list, that's even
> better.

Well, I'm not going to make any claims to the list being uncontroversial,
but after I've committed it we at least have something to talk about. :)

Cheers,

  -- Nikodemus

Nathan Froyd wrote:
> On 7/17/07, Nikodemus Siivola <nikodemus@...> wrote:
>> Our TODO file is quite out of date. Unless there are objections
>> I'm going to replace it with the following in a few days:
> 
> This is great.  Just a comment or two along the way.
> 
>> FINISHING EXTERNAL FORMATS
>>
>>   Byte order marks. Newline conventions. A way to specify an external
>>   format without needing to duplicate code. Fixing the inefficiencies.
> 
> Unifying the stream code's idea of an external format and string-to-octets/
> octets-to-string would be a good idea--not that the stream code has to use
> octets-to-string, but that there'd be OAOO place where we talk about what
> external formats we support.  Declaring high-level properties of external
> formats (e.g. is this a single-byte encoding?) might help here too.
> 
> Redoing the stream code in general would probably be good to stick here.
> 
> Stackable streams (basically external-format support for streams that's
> not tightly integrated with fd-streams).

I'll let you edit the entries to suit -- the new TODO has now been committed.
(Perhaps a bit quick, but the response was so overwhelmingly positive that
I decided to jump the gun.)

> The list is really quite long, isn't it? :(

It's just an existence proof of the compiler writer's full employment
theorem extending to all aspects of a lisp system.

I mean, you didn't seriously think SBCL was ever going to run out of
TODOs? :)

Cheers,

  --- Nikodemus