[gentoo-lisp] stabilization of ecls-9.12.3 and clozurecl-1.4

[gentoo-lisp] stabilization of ecls-9.12.3 and clozurecl-1.4

[Andrey G. Grozin]

Hello *,

Does anybody have objections against filing stabilization requests for the 
above packages at the end of January (for x86 and amd64)? It would be good 
to get rid of old versions of ecls in the tree.

Andrey

Re: [gentoo-lisp] stabilization of ecls-9.12.3 and clozurecl-1.4

[Andrey G. Grozin]

And what about removing openmcl from the tree (it became clozurecl)?

Andrey

Re: [gentoo-lisp] stabilization of ecls-9.12.3 and clozurecl-1.4

[Julian Stecklina]

"Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> writes:

> And what about removing openmcl from the tree (it became clozurecl)?

ClozureCL 1.4 works fine for me on x86 and ECL 9.12.* is better than
most of the preceding versions. ;) So I am all for stabilizing them.

Regards,
-- 
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

Re: [gentoo-lisp] stabilization of ecls-9.12.3 and clozurecl-1.4

[Stelian Ionescu]

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

On Sun, 2010-01-10 at 16:29 +0600, Andrey G. Grozin wrote:
> And what about removing openmcl from the tree (it became clozurecl)?

Fine for me.

-- 
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] stabilization of ecls-9.12.3 and clozurecl-1.4

[Stelian Ionescu]

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

On Sun, 2010-01-10 at 16:03 +0600, Andrey G. Grozin wrote:
> Hello *,
> 
> Does anybody have objections against filing stabilization requests for the 
> above packages at the end of January (for x86 and amd64)? It would be good 
> to get rid of old versions of ecls in the tree.

No objection, but somebody needs to fix big #299763 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 --]

[gentoo-lisp] stabilization of ecls-9.12.3

[Andrey G. Grozin]

Hello *,

ecls-9.12.3 is now stable on x86. I propose to remove all ecls-0.9.* and 
9.8.4 from the tree. Any objections?

ecls-10.2.1 has appeared in the overlay. Have not tried it yet. The ebuild 
is based on the ecls-9.12.3 from the overlay, not from the tree. I made 
some QA changes in the ebuild which is in the tree. The old one tried to 
install the absent html documentation, and did neither build nor install 
the present info documentation (I introduced the doc USE flag). The old 
ebuild called econf with an absent configure flag. Could we please use a 
single line of ecls ebuilds in the overlay and in the tree, instead of two 
parallel lines? I'll put 10.2.1 to the tree soon, but I have to do this QA 
cleanup again.

Andrey

Re: [gentoo-lisp] stabilization of ecls-9.12.3

[Andrey G. Grozin]

OK, so I've committed 10.2.1 to the tree. I removed the dependency on 
app-text/texi2html because we no longer generate html.

10.2.1 successfully compiles maxima; gives 2 unexpected failures in the 
maxima testsuite. I think 9.12.3 produced the same 2 failures, so, no 
change here.

What's the reason of ecls-10.2.1_rc1 in the overlay? 10.2.1 is available 
for download from sourceforge, why _rc1?

Andrey

Re: [gentoo-lisp] stabilization of ecls-9.12.3

[Stelian Ionescu]

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

On Sat, 2010-02-20 at 12:14 +0600, Andrey G. Grozin wrote:
> OK, so I've committed 10.2.1 to the tree. I removed the dependency on 
> app-text/texi2html because we no longer generate html.
> 
> 10.2.1 successfully compiles maxima; gives 2 unexpected failures in the 
> maxima testsuite. I think 9.12.3 produced the same 2 failures, so, no 
> change here.
> 
> What's the reason of ecls-10.2.1_rc1 in the overlay? 10.2.1 is available 
> for download from sourceforge, why _rc1?

Upstream made the mistake of uploading a release candidate as 10.2.1,
but that's not an "official" nor a "final" release.

-- 
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 --]

[gentoo-lisp] ecls-10.3.1

[Andrey G. Grozin]

Hello *,

After upgrading ecls to 10.3.1 and re-compiling maxima with it, I found a 
large number of testsuite failures which were not present with earlier 
ecls versions (including 10.2.1). It seems that maxima cannot find any 
package at all. So, either some file-related stuff got broken, or 
string-related stuff (used for paths to files). It seems we should not put 
this version to the main tree, because it breaks a major client (maxima). 
Have not tried to compile fricas with this version of ecls, so, don't know 
about it.

Andrey

Re: [gentoo-lisp] ecls-10.3.1

[Stelian Ionescu]

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

On Sun, 2010-03-07 at 20:50 +0600, Andrey G. Grozin wrote:
> Hello *,
> 
> After upgrading ecls to 10.3.1 and re-compiling maxima with it, I found a 
> large number of testsuite failures which were not present with earlier 
> ecls versions (including 10.2.1). It seems that maxima cannot find any 
> package at all. So, either some file-related stuff got broken, or 
> string-related stuff (used for paths to files). It seems we should not put 
> this version to the main tree, because it breaks a major client (maxima). 
> Have not tried to compile fricas with this version of ecls, so, don't know 
> about it.

Could you please report this on the ECLS mailing list ?

-- 
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 --]

[gentoo-lisp] sbcl-1.0.38 with USE=threads: test failures in sb-concurrency

[Andrey G. Grozin]

Emerging sbcl-1.0.38 with default USE flags fails for me. Several tests of 
sb-concurrency fail (I get some timeouts, this differs from expected 
results). Maybe, my single-core pentium-m is too slow to run these tests? 
Anyway, I don't need threads in sbcl, because maxima doesn't use them. Now 
I'm trying to emerge with USE=-threads.

Andrey

Re: [gentoo-lisp] sbcl-1.0.38 with USE=threads: test failures in sb-concurrency

[Andrey G. Grozin]

On Sat, 1 May 2010, Andrey G. Grozin wrote:
> Now I'm trying to emerge with USE=-threads.
OK, with USE=-threads emerge succeeds; sbcl-1.0.38 compiles maxima-5.21.1; 
no unexpected errors in the testsuite. Maybe, it would be better to remove 
+ from IUSE="... +threads ..." ?

Andrey

[gentoo-lisp] clozurecl-1.5 in the tree

[Andrey G. Grozin]

I've just committed 1.5 to the tree (for x86 and amd64). I delayed this 
because it caused many testsuite failures in maxima. After consulting the 
openmcl mailing list, I inserting a simple workaround into 
maxima-5.21.1-r1; now clozurecl-1.5 gives 0 unexpected errors.

It would be interesting to see if it will compile on the flameeyes 
tinderbox :-)

Andrey

Re: [gentoo-lisp] clozurecl-1.5 in the tree

[Stelian Ionescu]

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

On Sat, 2010-05-01 at 20:40 +0700, Andrey G. Grozin wrote:
> I've just committed 1.5 to the tree (for x86 and amd64). I delayed this 
> because it caused many testsuite failures in maxima. After consulting the 
> openmcl mailing list, I inserting a simple workaround into 
> maxima-5.21.1-r1; now clozurecl-1.5 gives 0 unexpected errors.
> 
> It would be interesting to see if it will compile on the flameeyes 
> tinderbox :-)

Thanks, I removed clozurecl from the overlay

-- 
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 --]