On Thu, Dec 1, 2011 at 3:38 AM, Dima Pasechnik <dimp...@gmail.com> 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: > 0x530000 != 0x810000 > Stack trace: > Frame Function Args > 0022A118 6102796B (0022A118, 00000000, 00000000, 00000000) > 0022A408 6102796B (6117EC60, 00008000, 00000000, 61180977) > 0022B438 61004F1B (611A7FAC, 6124E2FC, 00530000, 00810000) > 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 #<compiled-function EXT::BC-COMPILE> > (compile 'foo '(lambda (x) (print x))) FOO NIL NIL > (foo 2) 2 2 > #'foo #<bytecompiled-closure #<bytecompiled-function 00000001039b9000>> 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
