Bug#702623: Maxima in sage is built against ecl
Le 10/03/2013 09:10, Julien Puydt a écrit : How easy is it to make the same maxima to run on several common-lisps? Considering: jpuydt@newton:~$ dpkg -L maxima |grep lib /usr/lib /usr/lib/maxima /usr/lib/maxima/5.29.1 /usr/lib/maxima/5.29.1/binary-gcl /usr/lib/maxima/5.29.1/binary-gcl/maxima /usr/lib/maxima/5.29.1/mgnuplot I would say that it looks like maxima makes it pretty easy to support several common lisp backends. Now, that doesn't make everything perfect at once, since the /usr/bin/maxima shell script can't magically know which variant we want, but if there's a maxima-ecl available, that would definitely make things manageable for the sage packaging effort. What do the maxima maintainers think? Snark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702623: Maxima in sage is built against ecl
Le 09/03/2013 11:09, Sylvestre Ledru a écrit : On 09/03/2013 10:14, Julien Puydt wrote: Package: maxima Version: 5.29.1-1 The maxima used in sage is built with ecl, while the sage in debian isn't. That will of course be a problem to package sage ; a very simple fix would be to just compile maxima with ecl in debian. But of course, simple doesn't mean correct : I saw #661803 where someone asks for an sbcl-built maxima, so the situation is going to be a pain if each and everyone wants maxima built against some variant of common lisp... I don't know how to handle the situation gracefully, so I open this bug CCing debian-science to discuss the matter. Usually, during the package creation workflow, you rebuild the application against the various implementation and you provide: maxima-implementationX maxima-implementationY maxima-implementationZ It takes a X time more time to build and it is harder to maintain: paths have to be different or packages have to conflict one against the other (causing issues for the packages depending on this). (example: hdf5) More time to build, bigger size in the repository, and a general pain, I know ; that's why it has to be discussed and good choices have to be made. My advice: see if sage can work without this. Here is how I see things looking at the code from high above : (1) sage/libs/ecl.pyx has some code to convert between ecl and sage basic types, initialize some things, control the gc... (2) sage/interfaces/maxima_lib.py makes the interface between sage and maxima, and heavily uses ecl. In fact, the impression I have is that sage isn't using ecl through maxima (which would make it quite easy to hide something else behind maxima), but is using maxima through ecl. That means getting ecl out of sage is basically a fork... How easy is it to make the same maxima to run on several common-lisps? Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702623: Maxima in sage is built against ecl
On 10/03/2013 09:10, Julien Puydt wrote: Le 09/03/2013 11:09, Sylvestre Ledru a écrit : On 09/03/2013 10:14, Julien Puydt wrote: Package: maxima Version: 5.29.1-1 The maxima used in sage is built with ecl, while the sage in debian isn't. That will of course be a problem to package sage ; a very simple fix would be to just compile maxima with ecl in debian. But of course, simple doesn't mean correct : I saw #661803 where someone asks for an sbcl-built maxima, so the situation is going to be a pain if each and everyone wants maxima built against some variant of common lisp... I don't know how to handle the situation gracefully, so I open this bug CCing debian-science to discuss the matter. Usually, during the package creation workflow, you rebuild the application against the various implementation and you provide: maxima-implementationX maxima-implementationY maxima-implementationZ It takes a X time more time to build and it is harder to maintain: paths have to be different or packages have to conflict one against the other (causing issues for the packages depending on this). (example: hdf5) More time to build, bigger size in the repository I don't think these are real issues. and a general pain, This one is :p Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702623: Maxima in sage is built against ecl
Package: maxima Version: 5.29.1-1 The maxima used in sage is built with ecl, while the sage in debian isn't. That will of course be a problem to package sage ; a very simple fix would be to just compile maxima with ecl in debian. But of course, simple doesn't mean correct : I saw #661803 where someone asks for an sbcl-built maxima, so the situation is going to be a pain if each and everyone wants maxima built against some variant of common lisp... I don't know how to handle the situation gracefully, so I open this bug CCing debian-science to discuss the matter. Thanks, Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702623: Maxima in sage is built against ecl
On 09/03/2013 10:14, Julien Puydt wrote: Package: maxima Version: 5.29.1-1 The maxima used in sage is built with ecl, while the sage in debian isn't. That will of course be a problem to package sage ; a very simple fix would be to just compile maxima with ecl in debian. But of course, simple doesn't mean correct : I saw #661803 where someone asks for an sbcl-built maxima, so the situation is going to be a pain if each and everyone wants maxima built against some variant of common lisp... I don't know how to handle the situation gracefully, so I open this bug CCing debian-science to discuss the matter. Usually, during the package creation workflow, you rebuild the application against the various implementation and you provide: maxima-implementationX maxima-implementationY maxima-implementationZ It takes a X time more time to build and it is harder to maintain: paths have to be different or packages have to conflict one against the other (causing issues for the packages depending on this). (example: hdf5) My advice: see if sage can work without this. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
