clisp-devel

modules in base

[Bruno H. <br...@cl...>]

Hi Sam,

> 2005-01-12  Sam Steingold  <sd...@gn...>
>
>        * makemake.in (BASE_MODULES): added syscalls and regexp

Can you please explain convincingly why syscalls and regexp would need to be
in the default image?

I added BASE_MODULES because
  - the gettext/ngettext functions were in the base linking-set in clisp 2.33,
  - moving them to a separate module (thanks - it's beneficial for the
    code structure) causes internationalized programs to not work any more
    without "-K full", whereas internationalization is a basic feature,
  - the gettext testsuite was broken by that move as well.

Whereas syscalls
  - was not in base in clisp 2.33 - why should it be?
  - is full of OS dependent stuff that doesn't help portability.

And regexp
  - was not in base in clisp 2.33 - why should it be?
  - still doesn't support Unicode correctly when operating in a non-UTF-8 locale.

Bruno

Re: modules in base

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2005-01-13 14:51:34 +0100]:
>
>> 2005-01-12  Sam Steingold  <sd...@gn...>
>>
>>        * makemake.in (BASE_MODULES): added syscalls and regexp
>
> Can you please explain convincingly why syscalls and regexp would need
> to be in the default image?

Nope.
Sorry.
I have not been able to convince _you_ of anything. :-(

> I added BASE_MODULES because
>   - the gettext/ngettext functions were in the base linking-set in clisp 2.33,
>   - moving them to a separate module (thanks - it's beneficial for the
>     code structure) causes internationalized programs to not work any more
>     without "-K full", whereas internationalization is a basic feature,

what "internationalized Lisp programs" are there?

>   - the gettext testsuite was broken by that move as well.

gettext testsuite is not not a part of CLISP.
gettext maintainer can call CLISP with "-K full".

> Whereas syscalls
>   - was not in base in clisp 2.33 - why should it be?

it was in base until 2.31.

it contains several functions (resolve-host, copy-file, file-stat) which
are extremely useful for scripting.

it contains PHYSICAL-MEMORY that _you_ asked for in
<http://sourceforge.net/tracker/index.php?func=detail&aid=959586&group_id=1355&atid=351355>.
that RFE is now closed.

>   - is full of OS dependent stuff that doesn't help portability.

autoconf should handle that.
all binary CLISP distributions (see CLISP home page: fedora, suse,
debian, slackware, *BSD &c &c) include the syscall module - which
testifies to both its importance and portability

> And regexp
>   - was not in base in clisp 2.33 - why should it be?

because regexp is perceived as critical functionality for scripting.

>   - still doesn't support Unicode correctly when operating in a
>   non-UTF-8 locale.

this is a bug which should be fixed.
are you sure the i18n module does not contain bugs?

I bet there will be more users interested in syscalls and regexp
functionality than in i18n.


My (static) view is this:

boot: only things necessary for bootstrap.
      e.g., sockets should be in base, not boot (if possible)

base: everything necessary for normal day-to-day operations
      (similar to Perl without any loaded modules)
      must not rely on libraries which might not be included in a
      minimal installation (e.g., no X, no PostgreSQL)

full: everything and a kitchen sink; may rely on things present in
      "most" non-minimal installations (X, Berkeley-DB, rawsock, PCRE,
      maybe PostgreSQL, but NOT matlab, netica or oracle)

dynamically, things in "full" should be available via REQUIRE, one by
one, so that the user can run PostgreSQL without installing X and Oracle.


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Type louder, please.

Re: modules in base

[Bruno H. <br...@cl...>]

Sam wrote:
> what "internationalized Lisp programs" are there?

None so far. This is very deceiving :-(

> > Whereas syscalls
> >   - was not in base in clisp 2.33 - why should it be?
>
> it contains several functions (resolve-host, copy-file, file-stat) which
> are extremely useful for scripting.

OK.

> > And regexp
> >   - was not in base in clisp 2.33 - why should it be?
>
> because regexp is perceived as critical functionality for scripting.

OK.

> My (static) view is this:
>
> boot: only things necessary for bootstrap.
>       e.g., sockets should be in base, not boot (if possible)
>
> base: everything necessary for normal day-to-day operations
>       (similar to Perl without any loaded modules)
>       must not rely on libraries which might not be included in a
>       minimal installation (e.g., no X, no PostgreSQL)
>
> full: everything and a kitchen sink; may rely on things present in
>       "most" non-minimal installations (X, Berkeley-DB, rawsock, PCRE,
>       maybe PostgreSQL, but NOT matlab, netica or oracle)

Agreed. Sockets are in base, because stream.d is not extensible from
outside.

> dynamically, things in "full" should be available via REQUIRE, one by
> one, so that the user can run PostgreSQL without installing X and Oracle.

With libtool, this might actually become true...

Bruno

Re: modules in base

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...t> [2005-01-13 14:51:34 +0100]:
>
>> 2005-01-12  Sam Steingold  <sd...@gn...>
>>
>>        * makemake.in (BASE_MODULES): added syscalls and regexp
>
> I added BASE_MODULES because
>   - the gettext/ngettext functions were in the base linking-set in clisp 2.33,
>   - moving them to a separate module (thanks - it's beneficial for the
>     code structure) causes internationalized programs to not work any more
>     without "-K full", whereas internationalization is a basic feature,
>   - the gettext testsuite was broken by that move as well.
>
> Whereas syscalls
>   - was not in base in clisp 2.33 - why should it be?
>   - is full of OS dependent stuff that doesn't help portability.
>
> And regexp
>   - was not in base in clisp 2.33 - why should it be?
>   - still doesn't support Unicode correctly when operating in a non-UTF-8 locale.

Additionally, your change broke the mingw build because there is no
gettext on woe32 and thus the i18n module does not build,
while both syscalls and regexp are platform-independent
(build on all unix and w32 platforms).

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
If You Want Breakfast In Bed, Sleep In the Kitchen.

Re: modules in base

[Bruno H. <br...@cl...>]

Sam wrote:
> Additionally, your change broke the mingw build because there is no
> gettext on woe32 and thus the i18n module does not build

What are the #ifdef GNU_GETTEXT good for in this module then? I fixed this
module now.

The BASE_MODULES and the set of functions defined by these modules should
*not* be platform dependent. Portability between operating systems is a
requirement for things in 'base'. If a platform cannot provide some
functionality, use a dummy replacement / approximation that does something
useful instead.

Bruno

Re: modules in base

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...t> [2005-01-25 10:54:34 +0100]:
>
> Sam wrote:
>> Additionally, your change broke the mingw build because there is no
>> gettext on woe32 and thus the i18n module does not build
>
> I fixed this module now.

Thanks!

> The BASE_MODULES and the set of functions defined by these modules
> should *not* be platform dependent. Portability between operating
> systems is a requirement for things in 'base'. If a platform cannot
> provide some functionality, use a dummy replacement / approximation
> that does something useful instead.

yes.



-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);}