Re: [sage-devel] Re: Help with automated testing of ECL
On Tue, Dec 20, 2011 at 3:27 PM, kcrisman wrote: > Because Sage may sometimes have custom patches to ECL that weren't in > upstream at the time but are now, I don't know if it can be done 100% > automatically. I really wonder what those patches are about. AFAIK they are related to backporting changes to releases, but the need for this disappears completely if the upstream sources are all the time consistent with Sage. > But what you *could* do is the following: > [...] > and see what happens. > Hmm, again, it is not something that I would like to do on my own computer, but rather provide a daily tarball or "spkg" to be tested in that bot. However, I don't see that you'd be able to "just test ECL" inside of > Sage, because of the very specific config and deleting of tons of > stuff we don't use, and linking against Sage-specific things. > There is not so much stuff that you can delete: just the libraries that ECL ships with it (GMP, Boehm-GC, libffi). Assuming that they are already available in Sage, they are not even needed in a normal build -- for instance, on my copy of Ubuntu, I rarely use the versions that come with ECL, as the operating system already provides better versions --. The rest is very much integrated and is what has to be tested. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Help with automated testing of ECL
On Wed, Dec 21, 2011 at 4:23 AM, Dima Pasechnik wrote: > do you like this to pull updates/patches from somewhere for testing, too? > That's what the Sage's patchbot does, pulls patches from Sage's trac, and > tests them. > Or only "full releases"? > No, as I said in my original email, I would like to test the consistency of the current git/CVS tree, or of a tagged release with Sage's buildbot. If this does make sense at all, I really do not know. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: another problem building maxima on cygwin
On Thu, Dec 1, 2011 at 3:38 AM, Dima Pasechnik wrote: > I don't see how you managed to completely avoid it (I hope we talk about > the same ECL version, do we?! We use > http://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg). > I do not know what stage of change this includes. What I meant is that ECL does not, by itself, call execve(), fork(), or relatives at all when using Cygwin, and instead relies on "system". What cygwin does under the hood (for instance if it is so unfortunate to use fork() when executing system()) is a mistery to me. > Without the hack I found, one still often gets things like this one: [...] > 3 [main] ecl 2880 > C:\cygwin\usr\local\sage\sage-4.7.2\local\bin\ecl.exe: *** fatal error - > unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll to same address as parent: > 0x53 != 0x81 > Stack trace: > Frame Function Args > 0022A118 6102796B (0022A118, , , ) > 0022A408 6102796B (6117EC60, 8000, , 61180977) > 0022B438 61004F1B (611A7FAC, 6124E2FC, 0053, 0081) > End of stack trace > Seems again fork has been used. > The reason my hack helps fork() to work is due to these temporary DLLs (I > still don't know where they come from, by the way) being placed in memory > in a more favourable way, which does not give Windows a reason to move them > around (and moving them around is exactly the reason for that "*** fatal > error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll" things) > I find that hack questionable. Will it work everywhere with any library loaded? Does it block other user's software from running? Hardcoding memory addresses is what has been pestering all Common Lisp implementations in the history and prevented not only portability but also maintainability. Regarding the "due to these temporary DLLs (I still don't know where they come from, by the way)", the explanation is simple. Maxima is asking ECL to compile fragments of code via the C compiler, probably using the Common Lisp function COMPILE. A way to circumvent this problem (which makes sense for it also eliminates the use of the C compiler when Sage is used) is to replace this function with the bytecodes compiler, which is cheaper and does not invoke gcc. > (progn (ext:package-lock "CL" nil) (setf (fdefinition 'compile) #'ext::bc-compile) (ext:package-lock "CL" t)) #<"COMMON-LISP" package> > #'compile # > (compile 'foo '(lambda (x) (print x))) FOO NIL NIL > (foo 2) 2 2 > #'foo #> The first four lines may be inserted in Maxima's code, probably at the end of ECL's portability section. #+cygwin (progn (ext:package-lock "CL" nil) (setf (fdefinition 'compile) #'ext::bc-compile) (ext:package-lock "CL" t)) Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: another problem building maxima on cygwin
On Wed, Nov 30, 2011 at 9:32 PM, kcrisman wrote: > That is weird that you have to do this. Juanjo suggested that he had > made a bunch of changes to totally change how forking works in ECL > this summer, but maybe they weren't merged? I'm cc:ing him on this. I did not change the way fork is used: fork is broken in cyginw, period. However, I managed to avoid using fork() altogether, at least when compiling programs. This does not solve the problem; it just hides it. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] Problems building Maxima with ECL on Cygwin.
On Thu, Apr 28, 2011 at 7:30 AM, Dr. David Kirkby wrote: > Hi, > it has been reported that there are issues in trying to build Maxima on > Cygwin > using ECL. Does this look like an ECL issue. See error message at > > http://trac.sagemath.org/sage_trac/ticket/11260 > I can confirm that this is _not_ specific to Windows XP. On a different virtualbox image I am getting the same errors. It seems that the problem is related to the use of fork() in cygwin, which is very fragile. I am considering various possibilities. The obvious one is to reuse the code in RUN-PROGRAM that we already have for Windows/Mingw+MSVC in the Cygwin builds. I am not sure how easy this is -- still investigating. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] Problems building Maxima with ECL on Cygwin.
I know about these bug reports -- similar ones appeared on a different context --. Unfortunately I am at a peak of work load and will solve them slower than usual. Thanks for reminding. Juanjo On Thu, Apr 28, 2011 at 8:13 AM, Dr. David Kirkby wrote: > On 04/28/11 06:30 AM, Dr. David Kirkby wrote: > > Hi, > > it has been reported that there are issues in trying to build Maxima on > Cygwin > > using ECL. Does this look like an ECL issue. See error message at > > > > http://trac.sagemath.org/sage_trac/ticket/11260 > > > > > > Note this is Windows 7, not XP or Vista. It works under XP - I don't know > about > Vista. > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > Dave > > > > -- > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > ___ > Ecls-list mailing list > ecls-l...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] OpenSolaris issue : Error: suffix or operands invalid for `mov'
On Sat, Jun 19, 2010 at 9:59 AM, David Kirkby wrote:
> It does not look to me like Maxima is being compiled - at least not in
> the sense of using a compiler like gcc.
>
Tthen it means that ECL itself is not capable of loading. If I interpret
that the error is due to the causes shown in the link you mentioned, that
would mean the compiler is broken, because ECL does not have 2GB data and
nevertheless Sun's linker is not capable of handling the relocation of its
statically addressed data.
Since all that does not make sense, the problem must be somwhere else. This
suggests that GCC may be missing a flag when building the shared library:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7791
Currently we use (src/configure.in)
SHARED_LDFLAGS="-dy -G ${LDFLAGS}"
BUNDLE_LDFLAGS="-dy -G ${LDFLAGS}"
but maybe we should instead used -shared
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] OpenSolaris issue : Error: suffix or operands invalid for `mov'
On Sat, Jun 19, 2010 at 12:22 AM, Dr. David Kirkby wrote: > I should have added, the option > --without-dffi > was already added to ECL - without it, ECL would not build. Of course, because of the error message you showed before, which was due to not using --without-dffi. > However, although the option allowed ECL to build, Maxima failed to build > very quickly. The error message generated by Maxima looks quite similar to > that which ECL generates if that option is not given. > I think you are quite confused with this. If you do not use --without-dffi, then you get the previous messages which are due to problems with the inline assembly /var/tmp//cclaaOtH.s: Assembler messages: /var/tmp//cclaaOtH.s:49: Error: suffix or operands invalid for `mov' /var/tmp//cclaaOtH.s:51: Error: suffix or operands invalid for `mov' /var/tmp//cclaaOtH.s:140: Error: suffix or operands invalid for `mov' This is not at all what you showed in the ticket. In the ticket you used --without-dffi and thus the DFFI was not linked in and ECL built, but then Maxim afailed to link ld.so.1: ecl: fatal: relocation error: R_AMD64_PC32: file /export/home/drkirkby/sage-4.4.2/local/lib//libecl.so: symbol main: value 0x22800097de04 does not fit The only thing I can think of is that Maxima is being compiled with some other flags that are not the same used to build ECL. For instance if some object model option (-fPIC?) disappears when compiling files vs. when building ECL. That should not happen, but I can not see it from your ticket. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] Build of ECL breaks for parallel builds.
On Fri, Jun 18, 2010 at 6:12 PM, Dr. David Kirkby wrote: > If one attempts to build ECL 10.4.1 (latest available stable release) in > parallel, so the build goes wrong Yes, this is known, but I do not have time / skills to track the dependencies that break this. In general I run away from parallel builds for my software because they cause headaches, forcing one to really sort the dependency graph manually so as not to break anything. Incidentally you complain about ECL's long build time, but parallel build will NOT help you. Since in Sage you already use a previously built GMP library (or whatever variant) the largest chunk of time is spent in running ECL's compiler, a process that CAN NOT be parallelized, due to delicate dependencies in bootstrapping code. In any case I am surprised to read that ECL's build time is the bottleneck. On my laptop it takes just 1+2 minutes to build it and it is a slow OS X machine (32 bits). What build flags are you using? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] OpenSolaris issue : Error: suffix or operands invalid for `mov'
On Fri, Jun 18, 2010 at 7:58 PM, Dr. David Kirkby wrote: > Is this dynamic foreign function interface needed for Maxima? Would you > advise > us to disable this on all platforms, or just OpenSolaris, given we do not > have > libffi in Sage? > I frankly do not know. I suspect Maxima just uses standard Common Lisp so you could disable the FFI. > If you would advise disabling this unless libffi is installed, would it not > be > preferable for the default behaviour of whether to install the dffi depends > on > whether the relevant library is installed? Yes, that was supposed to happen at some point, but was in a low priority list. Since it is impeding your builds I will try something tonight. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: maxima-5.20.1.p0 fails to build on t2.math with Sage 4.4.2.alpha0
On Tue, May 11, 2010 at 6:17 AM, Dr. David Kirkby wrote: > Has the version of ECL been updated recently? > I insist that this is not a regression, it is just a misinterpretation on our side of how mkstemp() should work (adding characters other than letters seems stupid but it is specified as a possibility), so reverting wouldn't help 3) A long term solution is to fix the bug in ECL. I can produce a patch but it will take me some time. Could you please confirm that you received these emails, because some of my answers do not seem to permeate into your responses. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: maxima-5.20.1.p0 fails to build on t2.math with Sage 4.4.2.alpha0
I hope I am not causing a lot of trouble by the space of the ECLINIT files I create -- incidentally they should all get deleted unless weird conditions happen (for instance, a crash, failure to load a file, etc) As for the problem that you are reporting I think this was perfectly spotted by the guy who submitted this bug report https://sourceforge.net/tracker/?func=detail&atid=398053&aid=2999335&group_id=30035 Apparently the OpenGroup allows mkstemp() to create names with dots (!). That is bad because then ECL interprets whatever comes after the dot as a filename extension and discards it. This happens 1 out of 48 files (Sun's system is simply rotating names) and that causes the name collision. I will look for possible solutions that do not involve foregoing mkstemp(), Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Maxima & ECL 10.4.1
ECL will introduce an incompatible change that will break building of Maxima. The change is not gratuitous: it basically locks all functions in the core package COMMON-LISP preventing them from being redefined. This is mandated by the ANSI standard and it was just an unfortunate typo that made this lock inactive in all but a few of previous versions. The file lisp-utils/defsystem.lisp that is shipped with Maxima assumes that this lock does not exist and it has been working so far without problems. >From this version of ECL on this utility will stop working and will prevent Maxima from building. I attach a small patch that solves this problem. This patch and the latest fixes between ECL 10.3.1 and the upcoming 10.4.1 make Maxima build without further problems. All tests pass except the one known case. I would advise upgrading Sage when the release process is finished. I backported this patch to maxima-5.20.1 -- a diff file for that is also attached. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org To unsubscribe, reply using "remove me" as the subject. maxima-5.20.1.diff Description: Binary data maxima.diff Description: Binary data
[sage-devel] Re: [Ecls-list] ECL reads sysfun.lsp one byte at a time, was: Maxima stats huge numbers of files at startup?
On Sat, Dec 12, 2009 at 11:29 PM, Juan Jose Garcia-Ripoll < juanjose.garciarip...@googlemail.com> wrote: > Streams may be opened with either ANSI C streams (fopen) or with C file > descriptors (open). The later is needed for sockets and certain devices, > while the formers provide buffering and may be better in some systems. > That's all. The difference is that ECL did not allow C file descriptors to > be used before. There was also another rationale for not using buffered files, which is that the system does buffer already. On ordinary file systems I see no performance difference between using ANSI C streams and file descriptors, as shown by the little script below. In both cases my Mac uses 0.177s to read and parse the file 10 times. However, since it seems that there are some filesystems around in which a call to read() may be expensive, LOAD now uses buffered streams. Given that there is also a relevant bug fixed that affects Maxima, I will produce a patch release soon. Juanjo (compile 'foo '(lambda () (with-open-file (s "~/src/ecl/src/cmp/sysfun.lsp" :cstream t) (loop for i = (read s nil nil) while i (time (dotimes (i 10) (foo))) (compile 'foo '(lambda () (with-open-file (s "~/src/ecl/src/cmp/sysfun.lsp" :cstream t) (loop for i = (read s nil nil) while i (time (dotimes (i 10) (foo))) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Ecls-list] ECL reads sysfun.lsp one byte at a time, was: Maxima stats huge numbers of files at startup?
Streams may be opened with either ANSI C streams (fopen) or with C file descriptors (open). The later is needed for sockets and certain devices, while the formers provide buffering and may be better in some systems. That's all. The difference is that ECL did not allow C file descriptors to be used before. Juanjo On Sat, Dec 12, 2009 at 11:22 PM, Robert Dodier wrote: > On 12/10/09, William Stein wrote: > > > 2. The user reports that "maxima reads the file > > local/lib/ecl-9.10.2/sysfun.lsp one character at a time doing 72K > > read() calls of one > > character each. The sys admin doubts that is anywhere near the > > problem of the NFS stat calls, but it does seem inefficient." > > OK, I've confirmed this w/ a recent version of ECL (9.12.2). > It didn't happen with an older version (I don't remember which version). > I am working on Linux with an ordinary file system (not NFS). > > Other calls to read have block size = 512 or 1024 or 8096. > Dunno what's going on. Not really so much of a problem, > but it is a curiosity. > > FWIW > > Robert Dodier > > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > ___ > Ecls-list mailing list > ecls-l...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [Ecls-list] [sage-devel] Maxima fails to build with ECL on Cygwin
I have found out that the function that acts as entry point in FASLs (compiled lisp files) was not exported by cygwin. That prevents LOAD from working. A quick fix has been uploaded, but I still do not know whether there are other issues left. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [Ecls-list] [sage-devel] Re: Maxima fails to build with ECL on Cygwin
The fix for this particular problem with HP-UX make is in the repository (GIT/CVS). Juanjo On Wed, Oct 28, 2009 at 8:38 PM, Juan Jose Garcia-Ripoll wrote: > This problem is trivial and does not have to do with cygwin. Just edit > the file src/c/Makefile.in and remove the lines beginning with # Seems > HP-UX is not really POSIX compatible. > > Juanjo > > On Wed, Oct 28, 2009 at 8:30 PM, Dr. David Kirkby > wrote: >> Martin Rubey wrote: >>> Mike Hansen writes: >>> >>>> Hello, >>>> >>>> Currently when I try to build Maxima with ECL on Cygwin, I get the >>>> following error: >>> >>> it is the same error with FriCAS. ECL cannot compile-file on cygwin :-( >>> >>> would be nice indeed. >>> >>> Martin >>> >>>> ecl -norc -eval '(progn (load "../lisp-utils/defsystem.lisp") (load >>>> "../lisp-utils/make-depends.lisp") (funcall (intern >>>> "CREATE-DEPENDENCY-FILE" :mk) "binary-ecl/maxima" "ecl-depends.mk") >>>> (quit))' >>>> ;;; Loading >>>> "/home/mhansen/sage-4.2/spkg/build/maxima-5.19.1.p0/src/src/../lisp-utils/defsystem.lisp" >>>> ;;; Loading #P"/home/mhansen/sage-4.2/local/lib/ecl/cmp.fas" >>>> An error occurred during initialization: >>>> LOAD: Could not load file >>>> #P"/home/mhansen/sage-4.2/local/lib/ecl-9.8.4/cmp.fas" (Error: "No >>>> error"). >> >> >> FWIW, there is a problem building ECL on HP-UX. The error might give just >> give >> some clue to the Cygwin issue, though I admit is is unlikely. >> >> http://trac.sagemath.org/sage_trac/ticket/7167 >> >> >> >> >> -- >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> ___ >> Ecls-list mailing list >> ecls-l...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ecls-list >> > > > > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [Ecls-list] [sage-devel] Re: Maxima fails to build with ECL on Cygwin
This problem is trivial and does not have to do with cygwin. Just edit the file src/c/Makefile.in and remove the lines beginning with # Seems HP-UX is not really POSIX compatible. Juanjo On Wed, Oct 28, 2009 at 8:30 PM, Dr. David Kirkby wrote: > Martin Rubey wrote: >> Mike Hansen writes: >> >>> Hello, >>> >>> Currently when I try to build Maxima with ECL on Cygwin, I get the >>> following error: >> >> it is the same error with FriCAS. ECL cannot compile-file on cygwin :-( >> >> would be nice indeed. >> >> Martin >> >>> ecl -norc -eval '(progn (load "../lisp-utils/defsystem.lisp") (load >>> "../lisp-utils/make-depends.lisp") (funcall (intern >>> "CREATE-DEPENDENCY-FILE" :mk) "binary-ecl/maxima" "ecl-depends.mk") >>> (quit))' >>> ;;; Loading >>> "/home/mhansen/sage-4.2/spkg/build/maxima-5.19.1.p0/src/src/../lisp-utils/defsystem.lisp" >>> ;;; Loading #P"/home/mhansen/sage-4.2/local/lib/ecl/cmp.fas" >>> An error occurred during initialization: >>> LOAD: Could not load file >>> #P"/home/mhansen/sage-4.2/local/lib/ecl-9.8.4/cmp.fas" (Error: "No >>> error"). > > > FWIW, there is a problem building ECL on HP-UX. The error might give just give > some clue to the Cygwin issue, though I admit is is unlikely. > > http://trac.sagemath.org/sage_trac/ticket/7167 > > > > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > Ecls-list mailing list > ecls-l...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Building Maxima (on ECL) on Itanium
I have found that the GNU C library routines for controlling the signalling of floating point exceptions, which are not really C standard but GNU extensions, do not work in the itanium. Well, they work in the sense that they can suppress the signalling but when activating it, saving and restoring exceptions, etc, they break. The solution is taking src/h/config.h and surrounding the line that contains #undef HAVE_FEENABLEEXCEPT with something like #ifndef __ia64__ #endif I must say I tested this with ECL 9.10.2 but I think the fix should also work in the versions that Sage is using. BTW, I do not have access to my development machine so this fix has not yet been committed. Juanjo On Sun, Oct 25, 2009 at 9:26 AM, Juan Jose Garcia-Ripoll wrote: > I got an itanium account recently. I am testing on that right now > > Juanjo > > On Sun, Oct 25, 2009 at 5:44 AM, William Stein wrote: >> On Sat, Oct 24, 2009 at 10:49 AM, Robert Dodier >> wrote: >>> On 10/24/09, William Stein wrote: >>> >>>> I can't get Maxima--5.19.1 to build on Itanium on top of ECL. The >>>> build fails with: >>>> >>>> ... >>>> ;;; Emitting code for DO-MERGE-SYMM. >>>> ;;; Emitting code for DO-MERGE-ASYM. >>>> ;;; Internal error: # >>>> ; - Loading binary file "binary-ecl/clmacs.fas" An error occurred >>>> during initialization: >>> >>> clmacs.lisp has a lot of floating point stuff in it, to calculate >>> extreme values and what-not. Do you have a working build from >>> an earlier version of Maxima? If so, try >>> :lisp (load "path/to/clmacs.lisp") >>> in Maxima. That should fail with a more informative message. >>> >>> If you don't have a working version, try reverting clmacs.lisp. >>> I don't know how far back you'll have to go. >> >> Thanks for your suggestions. It turns out that even the last working >> Maxima on that machine (5.16) doesn't build anymore on ECL-9.8. So >> the problem is with ECL (or GCC, which has also been upgraded). I'll >> let you know if I'm unable to resolve this by using either an older or >> newer ECL or GCC. >> >> William >> > > > > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Building Maxima (on ECL) on Itanium
I got an itanium account recently. I am testing on that right now Juanjo On Sun, Oct 25, 2009 at 5:44 AM, William Stein wrote: > On Sat, Oct 24, 2009 at 10:49 AM, Robert Dodier > wrote: >> On 10/24/09, William Stein wrote: >> >>> I can't get Maxima--5.19.1 to build on Itanium on top of ECL. The >>> build fails with: >>> >>> ... >>> ;;; Emitting code for DO-MERGE-SYMM. >>> ;;; Emitting code for DO-MERGE-ASYM. >>> ;;; Internal error: # >>> ; - Loading binary file "binary-ecl/clmacs.fas" An error occurred >>> during initialization: >> >> clmacs.lisp has a lot of floating point stuff in it, to calculate >> extreme values and what-not. Do you have a working build from >> an earlier version of Maxima? If so, try >> :lisp (load "path/to/clmacs.lisp") >> in Maxima. That should fail with a more informative message. >> >> If you don't have a working version, try reverting clmacs.lisp. >> I don't know how far back you'll have to go. > > Thanks for your suggestions. It turns out that even the last working > Maxima on that machine (5.16) doesn't build anymore on ECL-9.8. So > the problem is with ECL (or GCC, which has also been upgraded). I'll > let you know if I'm unable to resolve this by using either an older or > newer ECL or GCC. > > William > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Building Maxima (on ECL) on Itanium
An error happens while compiling clmacs: ;;; Emitting code for DO-MERGE-SYMM. ;;; Emitting code for DO-MERGE-ASYM. ;;; Internal error: # ; - Binary file binary-ecl/clmacs.fas is old or does not exist. ;Compile (and load) source file /home/wstein/screen/cleo/build/sage-4.2.alpha1/spkg/build/maxima-5.19.1.p0/src/src/clmacs.lisp instead? y ; - Should I bother you if this happens again? y ; - Compiling source file ; "/home/wstein/screen/cleo/build/sage-4.2.alpha1/spkg/build/maxima-5.19.1.p0/src/src/clmacs.lisp" > If you don't have access to Itanium, I can get you an account on a > well-maintained machine. Anyway, any thoughts/hints/ideas/crazy > guesses? This is a major blocker for the next Sage release. It > happens on both RHEL 5 Itanium *and* SUSE Itanium, using GCC 4.4.2. I can try building a more recent version of ECL in that machine. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ucontext.h
On Mon, Sep 21, 2009 at 12:37 AM, William Stein wrote: > Could you consider changing src/gc/mach_dep.c in ECL so that it > includes sys/ucontext.h instead of ucontext.h. This fixes a build > issue on OS X 10.6, as described here: I will try with this hack. This is a recently solved problem in the Boehm-Weiser garbage collector. I was hoping to add an newer version before releasing ECL, but it is taking them a lot of time to produce a release. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] How can we build ECL on OS X in 64-bit
Arrrgh, connection problems again. I will need another 15 minutes or so to upload the patches :-/ Juanjo 2009/9/7 Juan Jose Garcia-Ripoll : > 2009/9/7 Dr. David Kirkby : >> As you know, we are having some problems building ECL on 64-bit OS X (on >> the machine bsd.math.washington.edu). > > Yes, I have seen the emails. I am trying different builds here in my > laptop, since I did not ask for an account at bsd -- I thought I > would not need it. > >> 1) Will version 9.8.4 build, or do I need to check out the CVS? > > 9.84 will not build in 64 bit mode because OSX wrongly reports to use > a 32-bit operating system and processor (uname). This confuses the > configuration process. I had to manually patch this in src/aclocal.m4 > and src/configure.in > >> 2) Does one need to add -m64 to CFLAGS and CXXFLAGS? > > No. Just use ./configure ... ABI=64 or export ABI=64 as an environment > variable. ECL will add the right flag for OS X. Incidentally, as I > told you in the other email, OS X needs -m64 _also_ when linking. > Otherwise gcc will try to use 32-bits binaryes. > > Incidentally I just fixed another problem with our old version of GMP: > it does not build in OS X when ABI=64 is used. I did not notice before > this because I use a locally configured version, but I have fixed this > today. It should solve the problems with the error message "Do not > know how to make install". > > Unfortunately such a change involves also verifying that no other port > broke, and for this I must wait until all automated builds have > finished. Feel free to try, though. > >> 3) Does one need to set the ABI - and if so what to? > > ABI=64 for 64-bits build. Not setting it will use just the default > values of the operating system -- which for Snow Leopard seem to > depend on which mode the OS was booted. > >> I've tried a CVS checkout, and 9.8.4, with every combination of ABI and >> CFLAGS I can think of, but I can't seem to generate any 64-bit >> libraries. If I add the compiler option -m64 to CFLAGS, the configure >> script seems to remove it. > > No, this should not happen. ECL is preserving _whatever_ flags you > pass to CFLAGS. > > Juanjo > > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] How can we build ECL on OS X in 64-bit
2009/9/7 Dr. David Kirkby : > As you know, we are having some problems building ECL on 64-bit OS X (on > the machine bsd.math.washington.edu). Yes, I have seen the emails. I am trying different builds here in my laptop, since I did not ask for an account at bsd -- I thought I would not need it. > 1) Will version 9.8.4 build, or do I need to check out the CVS? 9.84 will not build in 64 bit mode because OSX wrongly reports to use a 32-bit operating system and processor (uname). This confuses the configuration process. I had to manually patch this in src/aclocal.m4 and src/configure.in > 2) Does one need to add -m64 to CFLAGS and CXXFLAGS? No. Just use ./configure ... ABI=64 or export ABI=64 as an environment variable. ECL will add the right flag for OS X. Incidentally, as I told you in the other email, OS X needs -m64 _also_ when linking. Otherwise gcc will try to use 32-bits binaryes. Incidentally I just fixed another problem with our old version of GMP: it does not build in OS X when ABI=64 is used. I did not notice before this because I use a locally configured version, but I have fixed this today. It should solve the problems with the error message "Do not know how to make install". Unfortunately such a change involves also verifying that no other port broke, and for this I must wait until all automated builds have finished. Feel free to try, though. > 3) Does one need to set the ABI - and if so what to? ABI=64 for 64-bits build. Not setting it will use just the default values of the operating system -- which for Snow Leopard seem to depend on which mode the OS was booted. > I've tried a CVS checkout, and 9.8.4, with every combination of ABI and > CFLAGS I can think of, but I can't seem to generate any 64-bit > libraries. If I add the compiler option -m64 to CFLAGS, the configure > script seems to remove it. No, this should not happen. ECL is preserving _whatever_ flags you pass to CFLAGS. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] ECL + OSX + 64bits
It seems that in OS X, when using "gcc" to link the object files into an executable, the flag -m64 is needed _again_ to specify that it is a 64-bits build. This is regarding David's question in the sage-devel group. Now, this is one of the reasons why ECL does not build on OS X when compiling with CFLAGS="-m64" Since the linker needs the -m64 flag, ECL is not capable of finding your copy of the MPIR library. To avoid this problem, ECL now understands an ABI=64 configuration option. It only works with OS X but it does not hurt other ports. There were other problems, though, which involve misusing the C calling conventions. This can be done for Intel/32 bits ABI, but not in other modes. Since OS X misidentifies the operating system as 32 bits (uname -a), ECL was thinking it could use this optimization. I have changed it. Now ECL builds on my MacBook using ABI=64 Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [mpir-devel] Re: [sage-devel] Re: Fwd: [Maxima] mpmath + sage + hypergeometric numerics
On Mon, Aug 17, 2009 at 12:20 PM, Bill Hart wrote: > So it seems Lisp is actually a bit mpz_add heavy. I'd write to the > authors and complain about that. Sorry to sound rude, but I am afraid you have no idea what you are talking about. Common Lisp does not support destructive operations on integer numbers. Therefore ECL can not use anything other than mpz_add to perform additions of what in the Common Lisp speak are called bignums. And just for once and so that you understand it: ECL has life outside Sage, even though we really want to support this project and its relatives, OpenAxiom, Fricas and Maxima. As for the switch to MPIR, I already said that ECL can be linked with any library that is compatible with GMP. The fact that we ship GMP with ECL is just a mere convenience to the users and it is not in my priority list _right now_ to spend time on code reorganization. Finally, I do not know what is all the fuzz about mpz_add occurrences vs line number counts. You people seem to be missing the point of what is optimizable and what is not. Did anybody care to profile what is being used and how it impacts performance? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [mpir-devel] Re: [sage-devel] Re: Fwd: [Maxima] mpmath + sage + hypergeometric numerics
On Mon, Aug 17, 2009 at 11:28 AM, William Stein wrote: >> Ah, that makes sense. It never occurred to me to check if any of the >> lisp implementations actually used GMP or MPIR. Now I just recalled >> that you recently encouraged ECL to switch from GMP to MPIR. Did they >> do so? I recall PHP did switch. > > I don't know what happened. ECL definitely works with MPIR, since we > build it on MPIR as part of Sage. Just for the record, ECL can build using ANY LIBRARY that implements the GMP API, at least v4.2. Since MPIR is compatible with this library, then ECL can be compiled and linked using MPIR and in particular with the libraries that Sage contains. Currently ECL ships with a terribly outdated copy of GMP v4.2. The reasons are historical and also motivated by the need of support for Microsoft Visual C++ compilers, which is now implemented via some patches. Given that MPIR supports Windows and Microsoft Compilers I am seriously considering switching the library we ship ECL with from GMP to MPIR. That would not affect any of the ports, since FreeBSD, NetBSD and Linuxes ship GMP with it and ECL can link against those versions, but would help us in getting faster and better supported numerical code for OS X, Windows and Solaris. However, performing any upgrade is something that requires time and careful rearrangement of the build process, so as not to break ECL on any platform. Currently my list of priorites is produce a very stable release that can be easily maintained for several months >> improve compiler >> get a later version of Boehm-Weiser gc > upgrade to MPIR Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Test failures with sage-4.1.1.rc0 with Maxima 5.19.0
On Tue, Aug 11, 2009 at 10:31 PM, Juan Jose Garcia-Ripoll wrote: > On Tue, Aug 11, 2009 at 10:23 PM, Dr. David > Kirkby wrote: >>> maxima seemed to install fine on an intel macbook running 10.4.11.[...] >>> However, the ecl install failed. There were a lot of errors, but here are >>> some near the tail: >> >> Perhaps Juanjo has some idea, as he is the maintainer. I believe he tests >> this on OS X. > > There is a small problem: I work with OS X 10.5.8, and the bug > reported is for 10.4, with no indication of the Xcode/gcc versions. > I will look into the issue, though, for it seems that there is a > machine running OS X Tiger in the Sage cluster. I did a full build and test in Sage's G5 running OS X Tiger. ECL builds and runs just fine using the following versions of the operating system and compiler. I ignore why the user is getting those problems -- my only conjecture is that his/her copy of ECL is too old. Juanjo varro:~/src/ecl jjgarcia$ uname -a Darwin varro 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc varro:~/src/ecl jjgarcia$ gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5370) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Test failures with sage-4.1.1.rc0 with Maxima 5.19.0
On Tue, Aug 11, 2009 at 10:23 PM, Dr. David Kirkby wrote: >> maxima seemed to install fine on an intel macbook running 10.4.11.[...] >> However, the ecl install failed. There were a lot of errors, but here are >> some near the tail: > > Perhaps Juanjo has some idea, as he is the maintainer. I believe he tests > this on OS X. There is a small problem: I work with OS X 10.5.8, and the bug reported is for 10.4, with no indication of the Xcode/gcc versions. This is important, because assembler, register names, headers and a lot of things have changed from Tiger (10.4) to Leopard (10.5). Indeed I already got reports of problems with the upcoming 10.6. I will look into the issue, though, for it seems that there is a machine running OS X Tiger in the Sage cluster. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] How might this elliptic_e issue on SPARC hardware with ECL be debugged?
On Mon, Aug 10, 2009 at 7:29 PM, David Kirkby wrote: > Was this bit of code executed only on Solaris, and not linux or OS X? No, the problem must have been universal. It was located in ecl/src/cmp/sysfun.lsp, a list of translations from lisp forms to C equivalents. I was working on that some days ago, removing wrong or unsafe translations... Funny enough, I introduced some more mistakes, hehe. I want to produce a patched release that fixes this problem, but I have problems to connect to the compiler farm right now -- paranoid sysadm I am forced to work with :-/ Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] How might this elliptic_e issue on SPARC hardware with ECL be debugged?
On Mon, Aug 10, 2009 at 6:16 PM, Robert Dodier wrote: > > The code in question is function ELLIPTIC-E in maxima/src/ellipt.lisp. > (Note that there are several similarly-named functions in there, > so be careful.) I have spotted a problem in the inline code generated by ECL at the lowest safety levels. There was a typo and sometimes sin got replaced with sinh. I am uploading a patch that solves this, but before making a new release I would like to add a configuration flag (--with-rpath) to ECL. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] How might this elliptic_e issue on SPARC hardware with ECL be debugged?
On Mon, Aug 10, 2009 at 9:42 AM, Dr. David Kirkby wrote: > You probably see my previous posts on the fact that elliptic_e is giving > incorrect results on SPARC hardware using ECL. If not, > http://sagetrac.org/sage_trac/ticket/6716 > has the details. I will remove maxima mailing list from this answer to spare me the usual despective comments about ECL. > Is there anything else that could be suspected, and so narrow down the > list of possible causes somewhat? > * Hardware fault on the particular machine. > * Design flaw in Sun UltraSPARC CPU > * ECL > * Solaris library bug > * Maxima > * gcc > * I screwed up compiling Maxima or ECL. There are two potential sources of error I can think of. One is the fact that special function computations with integers/rationals will be done using short floats in Common-Lisp. It may well be that at some places this coercion is taking place, etc, etc. The other possibility is that ECL is inlining the functions using the C library. I systematically appreciate errors in rounding, results and accuracy due to this. See http://ecls.sourceforge.net/logs.html and how the failed ansi tests change from platform to platform. I do not know whether this is essential to using the C library, or whether it is associated to the code that the compiler generates. For instance, gcc may produce code that is less accurate than the C library itself, or it may use _more_ accuracy than expected by the IEEE standard. The way to determine whether it is the compiled code that is responsible is to execute the same function interpreted and compiled. But of course, for that we need the particular expression that Maxima is using. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Patches for building Maxima with ECL
The patches attached cover the following to problems: 1) Due to different fixes towards better ANSI compliance, ECL's compile-file-pathname has changed behavior and when passed :output-file it preserves the pathname. This breaks the current assumptions in Maxima's build process 2) There is a serious bug in src/db.lisp, passing an integer as an argument to CAR. ECL's new type propagation code has detected it. I have provided a reasonable fix. The patch file has been created against the CVS version of Maxima. Using these patches, Maxima builds and installs just fine using the unstable (git/CVS) sources of ECL, which will conform the upcoming 9.8.1 release. Please take them into consideration. This release has important fixes and includes support for Solaris on SPARC and Intel, and this is essential for Sage's aims. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~--- maxima.patches Description: Binary data
[sage-devel] Re: [Ecls-list] We have an 'ecl' which builds on Solaris SPARC !!!
On Mon, Aug 3, 2009 at 9:28 AM, Dr. David Kirkby wrote: > I believe he still has some issues on Solaris Intel using gcc 4.4.1. > That version of gcc was only released on 22nd July 2009 (< 2 weeks ago). Seems 4.4.1 is doing fine after I reverted some changes from MPIR back into GMP. The tests are also running fine and should pop up in http://ecls.sourceforge.net/logs.html in a couple of hours. > The .spkg, which I've called a '.p0' is really more than a patch, as its > a complete checkout of the CVS. It has things we have no use for in > Sage (the .spkg is over twice the size of the original one). So I am NOT > proposing this particular .spkg goes into Sage. As I told David, there will be a new release, probably before the beginning of next week. You can use that in the spkg instead of the unstable sources. I would like, though, that some developers of Sage keep a copy of the unstable tree so that I can quickly answer back with fixes to the problems you may find, giving me back your feedback on those builds. > For whatever reason, Maximum and this ecl don't get on too well as > friends!! The obvious thing for me to do is to run the ecl test suite. > But this is certainly progress. > [...] > /export/home/drkirkby/sage/sage-4.1.1.rc0/spkg/build/maxima-5.16.3.p2/src/src/db.lisp, > position 5563, and form > ;;; (FSET 'QUEUE+P #'(LAMBDA-BLOCK QUEUE+P # ...)) > ;;; In the argument 1 of a call to CAR, the type of the form (LOGIOR > LAB-HIGH-BIT (UNLAB LAB)) is INTEGER, not LIST. Ooops, ECL now implements a better type propagator, which has detected an error in the following function (defun queue+p (nd lab) (cond ((null (setq *db* (+labs nd))) [...](t (iorm *db* (logior +lab-high-bit+ (unlab lab)) Based on this definition (defmacro iorm (cell n) `(rplaca ,cell (logior (car ,cell) (car ,n the second argument to (IORM *db* ...) should be a cons, not an integer. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] Solaris SPARC issues with Sun complier - location of gmp specified.
On Sun, Aug 2, 2009 at 12:50 AM, Dr. David Kirkby wrote: > Juan Jose Garcia-Ripoll wrote: >> >> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David >> Kirkby wrote: >>> >>> Following from my mail half an hour or so ago, here is what happens on >>> t2 if the Sun compiler is used, but the location of the gmp library and >>> header files are specified. >>> Undefined first referenced >>> symbol in file >>> __gmpn_perfect_square_p dpp.o >>> ld: fatal: Symbol referencing errors. No output written to dpp >>> I've seen very similar error messages about __gmp undefined, when >>> using the GNU compiler too. >> >> Yes, I have seen this, and I can not tell what this is about. GMP is >> not used or referenced in the dpp program at all and those symbols >> should not be linked in. There must be a problem with the GMP headers >> and the Solaris versions of the compiler or something like that. > > Is dpp part of ECL or one of the libraries? dpp is just a preprocessor for C code. It is used to translate the code that makes the core of ECL. It is very basic C, using at most fopen, fclose, strcpy, etc. I am thus surprised that the GMP symbols ever got linked in. > The libraries in /usr/local on 't2' have passed all self-tests and were > built with an ABI of 32. Ok, I presume that ECL should also be built with an ABI of 32 bits. I mean, the best thing would be to build exactly as the rest Sage > However, since Sage uses a huge range of things, it just includes > *everything* needed - including a replacement for GMP. So we are not > actually using GMP. GMP seems to be the stopper here, but from what you say thee replacement is building fine on all platforms that Sage supports. I would say the right thing would be to let ECL use that replacement. Eventually ECL might also evolve in the direction of using it: support for OSX and Windows seems complete in MPIR. > That builds headers and libraries with the name gmp (or at least can do). It > is 100% compatible version. This should do it: if the library names, headers and functions are identical, we do not need to change anything in ECL to use that replacement. > Inside Sage, the includes go to SAGE_LOCAL/local/include ,the libraries to > $SAGE_LOCAL/local/lib. Se we know EXACTLY where things are. Configure ECl using --with-system-gmp=yes CPPFLAGS=-I$SAGE_LOCAL/local/lib LDFLAGS=-L$SAGE_LOCAL/lib CFLAGS="..." LDFLAGS="..." where CFLAGS and LDFLAGS is an appropriate choice for the ABI that MPIR is using. Regarding sources, I would use the CVS tree. You can insert it in the Sage tree that you have. This way, if I make any changes, you will get them immediately and we can test different combinations. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
