somehow belatedly, I created a ticket to document this weirdness:
http://trac.sagemath.org/sage_trac/ticket/13343
On Tuesday, 29 November 2011 01:49:59 UTC+8, Nils Bruin wrote:
>
> My apologies for the last message. That didn't tell you anything you
> didn't already know. A little digging in the s
On Thursday, December 1, 2011 4:27:56 PM UTC+8, Juanjo wrote:
>
> 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.
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
On Thursday, 1 December 2011 10:57:21 UTC+8, kcrisman wrote:
>
> On Nov 30, 9:38 pm, Dima Pasechnik wrote:
> > On Thursday, 1 December 2011 05:40:35 UTC+8, Juanjo wrote:
> >
> > > On Wed, Nov 30, 2011 at 9:32 PM, kcrisman wrote:
> >
> > >> That is weird that you have to do this. Juanjo suggest
On Nov 30, 9:38 pm, Dima Pasechnik wrote:
> On Thursday, 1 December 2011 05:40:35 UTC+8, Juanjo wrote:
>
> > 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 w
On Thursday, 1 December 2011 05:40:35 UTC+8, Juanjo wrote:
>
> 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
On Nov 30, 4:40 pm, Juan Jose Garcia-Ripoll
wrote:
> 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?
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 u
On Nov 30, 12:55 pm, Dima Pasechnik wrote:
> I guess I figured this out. This problem was in weird behavior of
> capitalization of filenames and directory names, and/or in the fact that
> I was building in a subdirectory of the home directory of a WIndows domain
> user...
>
> Moving the build tr
I guess I figured this out. This problem was in weird behavior of
capitalization of filenames and directory names, and/or in the fact that
I was building in a subdirectory of the home directory of a WIndows domain
user...
Moving the build tree to a saner place fixed this weirdness.
And then I wa
Hi Juanjo,
On Tuesday, November 29, 2011 5:57:04 AM UTC+8, Juanjo wrote:
>
> Hi Dima,
>
> I am sorry, but I do not read this group frequently -- too much work to do
> --. Following your request I just built ECL from CVS/git on a cygwin box
> and definitely I do not see the problems you seem to e
Hi Dima,
I am sorry, but I do not read this group frequently -- too much work to do
--. Following your request I just built ECL from CVS/git on a cygwin box
and definitely I do not see the problems you seem to experience.
On Monday, November 28, 2011 10:29:28 AM UTC+1, Dima Pasechnik wrote:
>
>
On Nov 28, 11:12 am, Dima Pasechnik wrote:
> I also tried to set the argument of :move-to to an absolute path, but
> this did not help.
And just removing the ":move-here ..."? The normal behaviour of ASDF
should just place the result somewhere in a local tree. The variable
asdf::*user-cache* spe
On Tuesday, November 29, 2011 1:49:59 AM UTC+8, Nils Bruin wrote:
>
> My apologies for the last message. That didn't tell you anything you
> didn't already know. A little digging in the source got me to:
>
>
> http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=src/c/pathname.d;h=d
My apologies for the last message. That didn't tell you anything you
didn't already know. A little digging in the source got me to:
http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=src/c/pathname.d;h=d35bcc58eeeb1f3766b8fc25140253852d94e216;hb=HEAD#l736
which tries to define the
On Nov 28, 1:29 am, Dima Pasechnik wrote:
> I guess the root of the problem is here:
> here is another weirdness, which might explain the PATHNAME error message
> On Cygwin, ECL gives
>
> > (directory "")
>
> NIL
>
>
>
> while on supported systems (MacOSX, Linux) you get the current directory:
>
>
I guess the root of the problem is here:
here is another weirdness, which might explain the PATHNAME error message
On Cygwin, ECL gives
> (directory "")
NIL
>
while on supported systems (MacOSX, Linux) you get the current directory:
> (directory "")
(#P"/private/tmp/")
>
And on Cygwin director
On Nov 27, 11:59 pm, Dima Pasechnik wrote:
> I just checked, and saw that under Sage's ECL lisp (i.e. sage -lisp),
> (pathname "")
> produces an error (illegal seek) on Cygwin, while on MacOSX and Linux it's
> perfectly OK.
I'd say that's a bug for ECL/Cygwin (which of the two is at fault I do
n
I just checked, and saw that under Sage's ECL lisp (i.e. sage -lisp),
(pathname "")
produces an error (illegal seek) on Cygwin,
while on MacOSX and Linux it's perfectly OK.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sag
by running ecl stand-alone on the maxima spkg, I can confirm that the error
comes from
(asdf:make-build :maxima :type :fasl :move-here ".")
Unfortunately I cannot find any information on how to use the ecl's
debugger.
Any pointers much appreciated.
By the way,
In maxima.asd I see plenty of :pa
20 matches
Mail list logo
