[gentoo-science] maxima-5.14.0 and related stuff

[gentoo-science] maxima-5.14.0 and related stuff

[Andrey G. Grozin]

Hello *,

As you may have noticed, I committed maxima-5.14.0 to the science overlay. 
The 5.13.0 ebuild in the main tree is not good, from my point of view, 
because it does not allow one to build maxima with several lisps, and I 
definitely want this (to compare running times and, sometimes, behaviour 
too). The new ebuild is much cleaner and more systematic in the sense that 
it is trivial to add (or remove) any lisp to the set of supported lisps.

Speaking of lisps, the current Gentoo gcl is broken (this fact is not 
related to maxima). I am currently in contact with the authors, and hope 
the authors, and hope to understand what goes wrong when it is built in 
Gentoo - in Debian, for example, it works fine.

As usual, a new version of maxima requires a patch in TeXmacs. It was much 
simpler than I thought - large changes in strings implementation in maxima 
were taken into account already in TeX generation functions, and from the 
TeXmacs point of view nothing changed. I committed texmacs-1.0.6.12-r1 to 
the science overlay, it works with maxima-5.14.0.

Recently a user reported a problem with the TeXmacs-maxima interface (he 
was not on Gentoo, but the problem is platform-neutral). I have a fix 
already; will commit it to the overlay (and send to Joris) soon.

maxima-5.14.0 does not work properly with the previous version of 
wxmaxima. I committed wxmaxima-0.7.4 which is for the new maxima. The 
author of wxmaxima says that there is a bug in wxwidgets-2.8.6 which 
upsets wxmaxima; therefore, I depend on >=wxmaxima-2.8.7 (haven't checked 
that the bug mentioned is really absent in this case, though).

Also the previous version of imaxima cannot be used with 5.14.0. 
imaxima-0.99 was created for this. It depends on >=breqn-0.97a (the 
current breqn in the tree is 0.94).

The situation with breqn has changed recently: its license has been at 
last clarified (it's LaTeX public license), and it got a new maintainer, 
Morten Hoegholm (as you probably know, Michael Downes died a few years 
ago). It is now part of a set of math tools for LaTeX maintained by 
Morten, http://www.ctan.org/tex-archive/macros/latex/contrib/mh/
I've written an ebuild for this mathtools LaTeX package. I depend on 
!dev-tex/breqn; however, I heard that breqn is also in texlive, and this 
conflict should be resolved, but I don't use texlive yet. There are a few 
problems:

1. Files constituing the package have no version numbers in their names, 
and change rather often. If I use individual files from ctan, the ebuild 
will break quickly. The proper hing to do is to make a snapshot (with a 
version number given by the date, like 20080112) and mirror it somewhere. 
But I cannot do this with the science overlay.

2. Naturally, I inherited latex-package eclass. But it does not process 
*.dtx files, only *.ins ones. I had to re-define src_compile; the proper 
thing to do is to add *.dtx processing to latex-package.eclass.

So, this ebuild is not yet committed, it is in my local tree. And so is 
imaxima-0.99.ebuild. It builds, but I somehow cannot make imaxima work; I 
never used it before, and probably I'm doing something stupid.

Best wishes,
Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] maxima-5.14.0 and related stuff

[M. Edward (Ed) Borasky]

Andrey G. Grozin wrote:
> Hello *,
> 
> As you may have noticed, I committed maxima-5.14.0 to the science 
> overlay. The 5.13.0 ebuild in the main tree is not good, from my point 
> of view, because it does not allow one to build maxima with several 
> lisps, and I definitely want this (to compare running times and, 
> sometimes, behaviour too). The new ebuild is much cleaner and more 
> systematic in the sense that it is trivial to add (or remove) any lisp 
> to the set of supported lisps.

Thanks!!


> Speaking of lisps, the current Gentoo gcl is broken (this fact is not 
> related to maxima). I am currently in contact with the authors, and hope 
> the authors, and hope to understand what goes wrong when it is built in 
> Gentoo - in Debian, for example, it works fine.

gcl is a disaster waiting to happen from what I've heard. The project 
seems stalled, and if you want a Common Lisp, your "viable" open source 
choices appear to be clisp and sbcl.

[snip]

Sounds good ... I'll check all this out (with sbcl) :)
-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] maxima-5.14.0 and related stuff

[Andrey G. Grozin]

On Sat, 12 Jan 2008, M. Edward (Ed) Borasky wrote:
> gcl is a disaster waiting to happen from what I've heard. The project seems 
> stalled, and if you want a Common Lisp, your "viable" open source choices 
> appear to be clisp and sbcl.
Here I disagree. gcl development is not stalled. 2.7.0 will have a lot of 
new exciting stuff (including speed improvements). Camm Maguire is very 
helpful and responsive.

I never had problems with gcl until recently. I always used it as my main 
common lisp for maxima and other things. Recently, I uninstalled it, and 
installed again (the same version). And after that, it is broken. It seems 
that there is some serious flaw in the gcl Gentoo ebuild (this never 
happens on Debian, for example; but Camm is a Debian developer :-)

Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] maxima-5.14.0 and related stuff

[Denis Dupeyron]

On Jan 13, 2008 7:40 AM, Andrey G. Grozin <A.G.Grozin@inp.nsk.su> wrote:
> It seems
> that there is some serious flaw in the gcl Gentoo ebuild (this never
> happens on Debian, for example; but Camm is a Debian developer :-)

Debian usually publish whatever patch they use so it could be
interesting to have a look. I'd provide you with a link but
packages.debian.org seems to be down right now. :o/

You may also want to check ubuntu, fedora, etc...

Denis.
-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] maxima-5.14.0 and related stuff

[M. Edward (Ed) Borasky]

Andrey G. Grozin wrote:
> maxima-5.14.0 does not work properly with the previous version of 
> wxmaxima. I committed wxmaxima-0.7.4 which is for the new maxima. The 
> author of wxmaxima says that there is a bug in wxwidgets-2.8.6 which 
> upsets wxmaxima; therefore, I depend on >=wxmaxima-2.8.7 (haven't 
> checked that the bug mentioned is really absent in this case, though).

It looks like wxmaxima-0.7.4 needs the "~amd64" keyword. On my AMD64,

  emerge -pv =wxmaxima-0.7.4

These are the packages that would be merged, in order:

Calculating dependencies |
!!! All ebuilds that could satisfy "=sci-mathematics/wxmaxima-0.7.4" 
have been masked.
!!! One of the following masked packages is required to complete your 
request:
- sci-mathematics/wxmaxima-0.7.4 (masked by: missing keyword)

For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.

-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] maxima-5.14.0 and related stuff

[Andrey G. Grozin]

I can build and test stuff only on x86. wxmaxima-0.7.4 is rather 
experimental - it now uses wxGTK-2.8, not 2.6. Therefore, I feeled I can 
only write ~x86. But now I included ~amd64 for convenience of those who 
would like to try it on amd64 (and tell me the result).

Good news: there is an overlay http://repo.or.cz/w/gentoo-lisp-overlay.git 
which contains gcl-2.6.7-r6 ebuild. This ebuild produces a working gcl, 
and I can build maxima with it. Now waiting when a broken ebuild in the 
tree will be replaced by this working one.

(By the way, gcl is the only common lisp which builds and works on all 
Debian architectures, there are 14 or something about that of them.)

Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] maxima-5.14.0 and related stuff

[M. Edward (Ed) Borasky]

Andrey G. Grozin wrote:
> I can build and test stuff only on x86. wxmaxima-0.7.4 is rather 
> experimental - it now uses wxGTK-2.8, not 2.6. Therefore, I feeled I can 
> only write ~x86. But now I included ~amd64 for convenience of those who 
> would like to try it on amd64 (and tell me the result).
> 
> Good news: there is an overlay 
> http://repo.or.cz/w/gentoo-lisp-overlay.git which contains gcl-2.6.7-r6 
> ebuild. This ebuild produces a working gcl, and I can build maxima with 
> it. Now waiting when a broken ebuild in the tree will be replaced by 
> this working one.
> 
> (By the way, gcl is the only common lisp which builds and works on all 
> Debian architectures, there are 14 or something about that of them.)
> 
> Andrey
> 

Ah ... OK ... I'll test it tonight. On a related note (I forget the bug 
number) I built Axiom Silver November 2007 from the upstream tarball 
yesterday. It builds its own gcl, and the version of gcl 2.6.8 that it 
uses doesn't work on AMD64. 2.6.7 does work.
-- 
gentoo-science@lists.gentoo.org mailing list

[gentoo-science] mathgl octave bindings

[Andrey G. Grozin]

Hello *,

Math Graphics Library (mathgl), when emerged with USE=octave, installs 
mathgl.tar.gz in /usr/share/mathgl/octave/ . This tarball contains

grozin@localhost /usr/share/mathgl/octave $ tar tf mathgl.tar.gz
mathgl/
mathgl/INDEX
mathgl/COPYING
mathgl/PKG_ADD
mathgl/inst/
mathgl/inst/i686-pc-linux-gnu-api-v32/
mathgl/inst/i686-pc-linux-gnu-api-v32/mathgl.oct
mathgl/DESCRIPTION

This is supposed to be mathgl bindings for octave.

How to install this as an octave package? Perhaps, octave-forge.eclass can 
be used? Should I hack the mathgl ebuild so that it does this octave 
installation (when USE=octave)? Or, maybe, there should be a separate 
octave-mathgl ebuild (perhaps, inheriting octave-forge) which depends on 
mathgl[octave]?

Andrey

Re: [gentoo-science] mathgl octave bindings

[Markus Dittrich]

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

"Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> writes:
> Hello *,
>
> Math Graphics Library (mathgl), when emerged with USE=octave, installs 
> mathgl.tar.gz in /usr/share/mathgl/octave/ . This tarball contains
>
> grozin@localhost /usr/share/mathgl/octave $ tar tf mathgl.tar.gz
> mathgl/
> mathgl/INDEX
> mathgl/COPYING
> mathgl/PKG_ADD
> mathgl/inst/
> mathgl/inst/i686-pc-linux-gnu-api-v32/
> mathgl/inst/i686-pc-linux-gnu-api-v32/mathgl.oct
> mathgl/DESCRIPTION
>
> This is supposed to be mathgl bindings for octave.
>
> How to install this as an octave package? Perhaps, octave-forge.eclass can 
> be used? Should I hack the mathgl ebuild so that it does this octave 
> installation (when USE=octave)? Or, maybe, there should be a separate 
> octave-mathgl ebuild (perhaps, inheriting octave-forge) which depends on 
> mathgl[octave]?
>
> Andrey
>
>

This looks pretty much like a generic octave-forge package as far as
I can tell. Simply renaming one of the octave-forge ebuilds
in the overlay should probably work out of the box. 

Best,
Markus

-- 
-- 
Markus Dittrich (markusle)
Gentoo Linux Developer
Scientific applications

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] mathgl octave bindings

[Andrey G. Grozin]

On Tue, 9 Dec 2008, Markus Dittrich wrote:
> "Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> writes:
>> How to install this as an octave package? Perhaps, octave-forge.eclass can
>> be used? Should I hack the mathgl ebuild so that it does this octave
>> installation (when USE=octave)? Or, maybe, there should be a separate
>> octave-mathgl ebuild (perhaps, inheriting octave-forge) which depends on
>> mathgl[octave]?
> This looks pretty much like a generic octave-forge package as far as
> I can tell. Simply renaming one of the octave-forge ebuilds
> in the overlay should probably work out of the box.
Yes, thanks, this works for me. But the problem is: mathgl.tar.gz is a 
generated file (it is actually a target in the mathgl's Makefile). It can 
be different on different systems (at least, the directory name 
i686-pc-linux-gnu-api-v32 will be different). So, it cannot have a fixed 
checksum. Is it possible to write some octave-forge-* like ebuild which 
will take /usr/share/mathgl/octave/mathgl.tar.gz and install it into 
/usr/share/octave/packages/ without checking checksums etc.?

Andrey

Re: [gentoo-science] mathgl octave bindings

[Markus Dittrich]

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

"Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> writes:
> On Tue, 9 Dec 2008, Markus Dittrich wrote:
>> "Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> writes:
>>> How to install this as an octave package? Perhaps, octave-forge.eclass 
>>> can
>>> be used? Should I hack the mathgl ebuild so that it does this octave
>>> installation (when USE=octave)? Or, maybe, there should be a separate
>>> octave-mathgl ebuild (perhaps, inheriting octave-forge) which depends on
>>> mathgl[octave]?
>> This looks pretty much like a generic octave-forge package as far as
>> I can tell. Simply renaming one of the octave-forge ebuilds
>> in the overlay should probably work out of the box.
> Yes, thanks, this works for me. But the problem is: mathgl.tar.gz is a 
> generated file (it is actually a target in the mathgl's Makefile). It can 
> be different on different systems (at least, the directory name 
> i686-pc-linux-gnu-api-v32 will be different). So, it cannot have a fixed 
> checksum. Is it possible to write some octave-forge-* like ebuild which 
> will take /usr/share/mathgl/octave/mathgl.tar.gz and install it into 
> /usr/share/octave/packages/ without checking checksums etc.?
>
> Andrey

Maybe, instead of moving mathgl.tar.gz onto the live filesystem
we should just install the octave_forge like package via the
octave_forge.eclass when we build and install mathgl itself 
(via a useflag). I am not sure at the moment if the 
octave_forge.eclass is organized in a way that allows
this, but it could probably be done by re-arranging some bits
in the eclass. I'll check.

Best,
Markus


-- 
-- 
Markus Dittrich (markusle)
Gentoo Linux Developer
Scientific applications

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] mathgl octave bindings

[Andrey G. Grozin]

On Sat, 13 Dec 2008, Markus Dittrich wrote:
> Maybe, instead of moving mathgl.tar.gz onto the live filesystem
> we should just install the octave_forge like package via the
> octave_forge.eclass when we build and install mathgl itself
> (via a useflag).
This would be the best thing. mathgl already has the USE flag octave - 
without this flag, the ebuild will not produce this interface.

Andrey