| 1 |
Hello *, |
| 2 |
|
| 3 |
As you may have noticed, I committed maxima-5.14.0 to the science overlay. |
| 4 |
The 5.13.0 ebuild in the main tree is not good, from my point of view, |
| 5 |
because it does not allow one to build maxima with several lisps, and I |
| 6 |
definitely want this (to compare running times and, sometimes, behaviour |
| 7 |
too). The new ebuild is much cleaner and more systematic in the sense that |
| 8 |
it is trivial to add (or remove) any lisp to the set of supported lisps. |
| 9 |
|
| 10 |
Speaking of lisps, the current Gentoo gcl is broken (this fact is not |
| 11 |
related to maxima). I am currently in contact with the authors, and hope |
| 12 |
the authors, and hope to understand what goes wrong when it is built in |
| 13 |
Gentoo - in Debian, for example, it works fine. |
| 14 |
|
| 15 |
As usual, a new version of maxima requires a patch in TeXmacs. It was much |
| 16 |
simpler than I thought - large changes in strings implementation in maxima |
| 17 |
were taken into account already in TeX generation functions, and from the |
| 18 |
TeXmacs point of view nothing changed. I committed texmacs-1.0.6.12-r1 to |
| 19 |
the science overlay, it works with maxima-5.14.0. |
| 20 |
|
| 21 |
Recently a user reported a problem with the TeXmacs-maxima interface (he |
| 22 |
was not on Gentoo, but the problem is platform-neutral). I have a fix |
| 23 |
already; will commit it to the overlay (and send to Joris) soon. |
| 24 |
|
| 25 |
maxima-5.14.0 does not work properly with the previous version of |
| 26 |
wxmaxima. I committed wxmaxima-0.7.4 which is for the new maxima. The |
| 27 |
author of wxmaxima says that there is a bug in wxwidgets-2.8.6 which |
| 28 |
upsets wxmaxima; therefore, I depend on >=wxmaxima-2.8.7 (haven't checked |
| 29 |
that the bug mentioned is really absent in this case, though). |
| 30 |
|
| 31 |
Also the previous version of imaxima cannot be used with 5.14.0. |
| 32 |
imaxima-0.99 was created for this. It depends on >=breqn-0.97a (the |
| 33 |
current breqn in the tree is 0.94). |
| 34 |
|
| 35 |
The situation with breqn has changed recently: its license has been at |
| 36 |
last clarified (it's LaTeX public license), and it got a new maintainer, |
| 37 |
Morten Hoegholm (as you probably know, Michael Downes died a few years |
| 38 |
ago). It is now part of a set of math tools for LaTeX maintained by |
| 39 |
Morten, http://www.ctan.org/tex-archive/macros/latex/contrib/mh/ |
| 40 |
I've written an ebuild for this mathtools LaTeX package. I depend on |
| 41 |
!dev-tex/breqn; however, I heard that breqn is also in texlive, and this |
| 42 |
conflict should be resolved, but I don't use texlive yet. There are a few |
| 43 |
problems: |
| 44 |
|
| 45 |
1. Files constituing the package have no version numbers in their names, |
| 46 |
and change rather often. If I use individual files from ctan, the ebuild |
| 47 |
will break quickly. The proper hing to do is to make a snapshot (with a |
| 48 |
version number given by the date, like 20080112) and mirror it somewhere. |
| 49 |
But I cannot do this with the science overlay. |
| 50 |
|
| 51 |
2. Naturally, I inherited latex-package eclass. But it does not process |
| 52 |
*.dtx files, only *.ins ones. I had to re-define src_compile; the proper |
| 53 |
thing to do is to add *.dtx processing to latex-package.eclass. |
| 54 |
|
| 55 |
So, this ebuild is not yet committed, it is in my local tree. And so is |
| 56 |
imaxima-0.99.ebuild. It builds, but I somehow cannot make imaxima work; I |
| 57 |
never used it before, and probably I'm doing something stupid. |
| 58 |
|
| 59 |
Best wishes, |
| 60 |
Andrey |
| 61 |
-- |
| 62 |
gentoo-science@l.g.o mailing list |
Archives