[gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[grozin]

Hello *,

Today I've committed to the tree the following packages (all pmasked):

dev-lisp/asdf-2.33-r4
dev-lisp/uiop-2.33-r1
dev-lisp/sbcl-1.1.6-r4
dev-lisp/clisp-2.49-r7.ebuild
dev-lisp/clozurecl-1.9_p1
dev-lisp/ecls-12.12.1-r4
dev-lisp/cmucl-20d-r3
sci-mathematics/maxima-5.30.0
sci-mathematics/fricas-1.2.0

The lisp stuff is from the lisp overlay. I haven't used the overlay 
specific eclasses, just the standard helpers (doins etc.).

clozurecl-1.9-r3 from the overlay is a live ebuild; are some of the recent 
updates essential? I replaced it by the today's snapshot (I've put it to 
dev.gentoo.org).

In clisp, I've corrected the dependency on pari (alas, it has to be 
<pari-2.5), and added an upstream patch which may be needed for new gcc 
versions.

All abuilds are EAPI=5. Now, when a lisp used for maxima or fricas is 
upgraded, these CASs will be upgraded automatically - this is exactly the 
main point of EAPI5. It would be great to unmask all these packages soon, 
not to wait for years. Any specific reasons not to do so for any of these 
packages? Should something be improved before unmasking? Please, test! And 
inform me. Testsuites of maxima and fricas are OK, so, the lisps cannot be 
broken. But I am not so sure about the asdf stuff.

Andrey

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[Stelian Ionescu]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Sat, 2013-04-20 at 22:13 +0700, grozin@gentoo.org wrote:
> Hello *,
> 
> Today I've committed to the tree the following packages (all pmasked):
> 
> dev-lisp/asdf-2.33-r4
> dev-lisp/uiop-2.33-r1
> dev-lisp/sbcl-1.1.6-r4
> dev-lisp/clisp-2.49-r7.ebuild
> dev-lisp/clozurecl-1.9_p1
> dev-lisp/ecls-12.12.1-r4
> dev-lisp/cmucl-20d-r3
> sci-mathematics/maxima-5.30.0
> sci-mathematics/fricas-1.2.0
> 
> The lisp stuff is from the lisp overlay. I haven't used the overlay 
> specific eclasses, just the standard helpers (doins etc.).
> 
> clozurecl-1.9-r3 from the overlay is a live ebuild; are some of the recent 
> updates essential? I replaced it by the today's snapshot (I've put it to 
> dev.gentoo.org).

clozurecl-1.9-r3 is not a live ebuild, what makes you think that ?
Please don't put snapshots in portage unless really necessary, and this
is not the case since upstream makes regular releases.


> In clisp, I've corrected the dependency on pari (alas, it has to be 
> <pari-2.5), and added an upstream patch which may be needed for new gcc 
> versions.
> 
> All abuilds are EAPI=5. Now, when a lisp used for maxima or fricas is 
> upgraded, these CASs will be upgraded automatically - this is exactly the 
> main point of EAPI5. It would be great to unmask all these packages soon, 
> not to wait for years. Any specific reasons not to do so for any of these 
> packages? Should something be improved before unmasking? Please, test! And 
> inform me. Testsuites of maxima and fricas are OK, so, the lisps cannot be 
> broken. But I am not so sure about the asdf stuff.

What are you unsure about ?

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[A.G.Grozin]

On Sat, 20 Apr 2013, Stelian Ionescu wrote:
> clozurecl-1.9-r3 is not a live ebuild, what makes you think that ?
src_prepare() {
         svn upgrade >/dev/null || die
         cp /usr/share/common-lisp/source/asdf/build/asdf.lisp tools/ || die
}

This is not acceptable in the main tree.

> Please don't put snapshots in portage unless really necessary, and this
> is not the case since upstream makes regular releases.
So why 1.9-r3 gave something unpredictable which varies with time?

> What are you unsure about ?
How to test if asdf works or not?

Andrey

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[Stelian Ionescu]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Sun, 2013-04-21 at 09:49 +0700, A.G.Grozin@inp.nsk.su wrote:
> On Sat, 20 Apr 2013, Stelian Ionescu wrote:
> > clozurecl-1.9-r3 is not a live ebuild, what makes you think that ?
> src_prepare() {
>          svn upgrade >/dev/null || die
>          cp /usr/share/common-lisp/source/asdf/build/asdf.lisp tools/ || die
> }
> 
> This is not acceptable in the main tree.

Why not ?


> > Please don't put snapshots in portage unless really necessary, and this
> > is not the case since upstream makes regular releases.
> So why 1.9-r3 gave something unpredictable which varies with time?

What varies ?


> > What are you unsure about ?
> How to test if asdf works or not?

It has a test suite, but it needs a working implementation first.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[A.G.Grozin]

On Sun, 21 Apr 2013, Stelian Ionescu wrote:
> On Sun, 2013-04-21 at 09:49 +0700, A.G.Grozin@inp.nsk.su wrote:
>> On Sat, 20 Apr 2013, Stelian Ionescu wrote:
>>> clozurecl-1.9-r3 is not a live ebuild, what makes you think that ?
>> src_prepare() {
>>          svn upgrade >/dev/null || die
>>          cp /usr/share/common-lisp/source/asdf/build/asdf.lisp tools/ || die
>> }
>> This is not acceptable in the main tree.
> Why not ?
>
>>> Please don't put snapshots in portage unless really necessary, and this
>>> is not the case since upstream makes regular releases.
>> So why 1.9-r3 gave something unpredictable which varies with time?
> What varies ?
The result of
     svn upgrade
of course! It upgrades the source directory to the current 
(time-dependent) state of the upstream svn. So, this is a live ebuild. 
Also, it requires an internet connection at the emerge time.

>>> What are you unsure about ?
>> How to test if asdf works or not?
> It has a test suite, but it needs a working implementation first.
I suppose dev-lisp/asdf (which I ported from the overlay not to use 
common-lisp-3) provides one. I'll have a look how to run the test suite.

Andrey

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[Stelian Ionescu]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

On Mon, 2013-04-22 at 14:11 +0700, A.G.Grozin@inp.nsk.su wrote:
> On Sun, 21 Apr 2013, Stelian Ionescu wrote:
> > On Sun, 2013-04-21 at 09:49 +0700, A.G.Grozin@inp.nsk.su wrote:
> >> On Sat, 20 Apr 2013, Stelian Ionescu wrote:
> >>> clozurecl-1.9-r3 is not a live ebuild, what makes you think that ?
> >> src_prepare() {
> >>          svn upgrade >/dev/null || die
> >>          cp /usr/share/common-lisp/source/asdf/build/asdf.lisp tools/ || die
> >> }
> >> This is not acceptable in the main tree.
> > Why not ?
> >
> >>> Please don't put snapshots in portage unless really necessary, and this
> >>> is not the case since upstream makes regular releases.
> >> So why 1.9-r3 gave something unpredictable which varies with time?
> > What varies ?
> The result of
>      svn upgrade
> of course! It upgrades the source directory to the current 
> (time-dependent) state of the upstream svn. So, this is a live ebuild.

That command upgrades the metadata format to the most recent because
upstream uses a very old version of subversion.

> Also, it requires an internet connection at the emerge time.

No it doesn't.


-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[A.G.Grozin]

On Mon, 22 Apr 2013, Stelian Ionescu wrote:
> That command upgrades the metadata format to the most recent because
> upstream uses a very old version of subversion.
I am sorry. You are right.

Why do we need a modern format of the stuff inside .svn directories? To my 
knowledge, some information from .svn is used to produce the greating line

Welcome to Clozure Common Lisp Version 1.9-r15769M  (LinuxX8664)!

Does this fail with the very old format? Is the information from .svn used 
for something else?

Another question. asdf and uiop are used together; installed from the same 
tarball; cannot be installed separately (asdf PDEPENDs on uiop, uiop 
RDEPENDs on asdf). What's the advantage of having two separate packages? 
Why not install both subsets of files from the asdf ebuild?

About testing asdf. test/run-tests.sh works fine inside the source tree. 
Not all files are installed by the asdf and uiop ebuilds; they are 
installed into different places. Simple-minded attempts to tune 
*asdf-directory*, *uiop-directory*, *build-directory* etc. in 
script-support.lisp fail because directory structures are too dissimilar 
(contrib/debug.lisp is a simlink to ../uiop/contrib/debug.lisp, etc.). So, 
I cannot test the installed stuff using run-tests.sh (inside the asdf 
source tree, all tests succeed for sbcl, cmucl, clisp, ccl, ecl).

Some observations:
1. In sbcl and cmucl, asdf is already loaded (the system init files, I 
suppose)
2. In ccl, ecl I can load it by (require :asdf)
3. In all these 4 cases (require :uiop) works
4. In clisp (require "asdf") fails (this is the form suggested by the asdf 
documentation).

By the way, I've just added the doc USE flag to the asdf ebuild.

What do common-lisp users expect to have? I mean, are all necessary asdf 
and uiop files installed? Are they installed into the most natural 
locations?

It seems to me that the stuff pmasked "for testing" is not being tested at 
all. The only way is to unmask it; there are many ~arch users who will 
report bugs. So, let's say we plan to unmask all this stuff, say, on May 
1. If anybody will report problems before this date, excellent! If not - 
the users will have to find these problems the hard way.

Andrey

Re: [gentoo-lisp] common lisps overlay -> tree; maxima, fricas

[grozin]

On Mon, 22 Apr 2013, Stelian Ionescu wrote:
> That command upgrades the metadata format to the most recent because
> upstream uses a very old version of subversion.
I am sorry. You are right.

Why do we need a modern format of the stuff inside .svn directories? To my 
knowledge, some information from .svn is used to produce the greating line

Welcome to Clozure Common Lisp Version 1.9-r15769M  (LinuxX8664)!

Does this fail with the very old format? Is the information from .svn used 
for something else?

Another question. asdf and uiop are used together; installed from the same 
tarball; cannot be installed separately (asdf PDEPENDs on uiop, uiop 
RDEPENDs on asdf). What's the advantage of having two separate packages? 
Why not install both subsets of files from the asdf ebuild?

About testing asdf. test/run-tests.sh works fine inside the source tree. 
Not all files are installed by the asdf and uiop ebuilds; they are 
installed into different places. Simple-minded attempts to tune 
*asdf-directory*, *uiop-directory*, *build-directory* etc. in 
script-support.lisp fail because directory structures are too dissimilar 
(contrib/debug.lisp is a simlink to ../uiop/contrib/debug.lisp, etc.). So, 
I cannot test the installed stuff using run-tests.sh (inside the asdf 
source tree, all tests succeed for sbcl, cmucl, clisp, ccl, ecl).

Some observations:
1. In sbcl and cmucl, asdf is already loaded (the system init files, I 
suppose)
2. In ccl, ecl I can load it by (require :asdf)
3. In all these 4 cases (require :uiop) works
4. In clisp (require "asdf") fails (this is the form suggested by the asdf 
documentation).

By the way, I've just added the doc USE flag to the asdf ebuild.

What do common-lisp users expect to have? I mean, are all necessary asdf 
and uiop files installed? Are they installed into the most natural 
locations?

It seems to me that the stuff pmasked "for testing" is not being tested at 
all. The only way is to unmask it; there are many ~arch users who will 
report bugs. So, let's say we plan to unmask all this stuff, say, on May 
1. If anybody will report problems before this date, excellent! If not - 
the users will have to find these problems the hard way.

Andrey