A patch has been uploaded to ECL's bug tracker. Please report whether it
works for you.
--
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://gr
understand what Maxima is doing here. Thanks for the
clarification.
Juanjo
--
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:/
e lisp form that is shown there, (format t "~21v"
1.7e+17)
So you have not provided me with convincing evidence that anything in
particular is broken. Anything can be wrong, beginning with your
assumptions about how "1.7e+17" is converted by maxima() to floating point
format.
Jua
BTW, I rarely read this group. If you need some quick answer, please Cc
your message to me or contribute to the bug report.
--
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 op
to reconstruct a floating point number
representation which is accurate, but does not recover the right number (C
library does the wrong rounding).
* Maxima is using some other function for output of floating point numbers
and the bug report was thus inaccurate.
Juanjo
--
To post to this grou
On Thursday, March 15, 2012 5:25:13 PM UTC+1, Nils Bruin wrote:
>
> On Mar 15, 12:21 am, "syd.lavas...@gmail.com"
> wrote:
> > The problem is that my home directory is:
> >
> > /files3/home/sahosse/
> >
> > but I only have execution permission to the directory "home":
>
> I confirm:
>
> $
Is it so surprising given that ECL is trying to read out your customization
~/.eclrc as described in the manual page? I do not follow the Sage build
methods in detail but ecl should always be invoked with -norc when used as
a compiler for third-party applications and not by a casual user.
Juanjo
I think you do not get it: he is doing an effort for isolating Maxima
because the needs of his interface is multi-user. Currently, Maxima is very
ugly from this point of view: since it depends on many global variables, it
is difficult to isolate it as a library that can be embedded in other
pro
nd greater program.
Juanjo
--
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
.
Does this all sound reasonable? Any volunteer?
Thanks for your attention,
Juanjo
--
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
pyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.
Top level.
>
iently compiled -- and normally
denotes a problem in the configuration of the system or in the options
passed to ECL.
Juanjo
--
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
Fo
On Dec 21, 8:34 am, William Stein wrote:
> On Sun, Dec 20, 2009 at 6:08 PM, kcrisman wrote:
>
> > On Dec 20, 4:16 pm, Robert Dodier wrote:
> >> Please distribute this message as you see fit.
>
> >> Announcing Maxima 5.20
>
> >> Maxima is a GPL'd branch of Macsyma, the venerable symbolic
> >> c
On Nov 3, 7:55 pm, Nils Bruin wrote:
> It is just a separate python module, not explicitly placed in the sage
> tree. It depends on two tickets that are ready for review. Kcrisman
> has already looked at them, but they could use some attention from
> someone familiar with lisp.
> http://trac.sage
w and msvc, so cygwin
has never been on my priority list.
Juanjo
On Oct 29, 5:08 am, Mike Hansen wrote:
> Hello,
>
> On Thu, Oct 29, 2009 at 4:29 AM, Juan Jose Garcia-Ripoll
>
> wrote:
>
> > The fix for this particular problem with HP-UX make is in the
> > repository
ease is 9.10.2
As I said, I believe this has to do more with how ECL is integrated
into a Sage package, than with the standard uses and abuses of
autoconf'ed programs.
Juanjo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegrou
That's great news! Thanks a lot for your work on testing and
integrating ECL and sorry for all the annoyances that these problems
may have caused you.
Juanjo
On Sep 15, 1:20 pm, "Dr. David Kirkby"
wrote:
> I've created a new .spkg from a CVS snapshot.
>
> http://
On Sep 9, 12:13 pm, "Dr. David Kirkby"
wrote:
> I think the issue is that gcc is not such a good linker as 'ld'.
I really do not care. The important thing is: if you use a particular
C compiler, it is most likely that you will have to use that compiler
for linking. This was pointed out before in
er option is to change CC, but
I would say that is a bit more dangerous.
Juanjo
--~--~-~--~~~---~--~~
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 mo
X-D
On Sep 8, 6:21 pm, William Stein wrote:
> On Tue, Sep 8, 2009 at 9:15 AM,
>
>
>
>
>
> Juanjo wrote:
>
> > On Sep 8, 2:36 pm, David Kirkby wrote:
> >> I will be impossible to convince!!!
> >> I have no problem accepting the *compiler* need
, GCC may have TWO
different runtime libraries, one for 32 bits and another one for 64
bits. If you do not tell GCC that you need 64-bits binaries, problems
will arise. So it is not only the linker that matters when considering
LDFLAGS.
Juanjo
--~--~-~--~~~---~--~~
To
ld Sage in 64-bits
mode, then ECL has to be built in 64-bits mode as well.
Juanjo
--~--~-~--~~~---~--~~
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 m
;s makefiles do not work well with -jn (n>=2) In any case, it will
bring you absolutely nothing, for most of the time is spent in a
sequential process which is compiling the lisp library.
Juanjo
--~--~-~--~~~---~--~~
To post to this group, send an email to sag
it for linking because there
are libraries that I would miss and which GCC or any other compiler (g+
+, IBM's,...) takes care of adding when used for linking.
Juanjo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscrib
l tested.
I plan to make a release in September, just like in August, July, etc.
I just need some more days for the testing platforms to complete all
regression tests and for your feedback and that of other users.
Juanjo
--~--~-~--~~~---~--~~
To post to this group,
On Sep 5, 9:22 pm, Nils Bruin wrote:
> couldn't convince the C compiler that two mpz_t's were really of the
> same type)
mpz_t's are not designed to be copied around.
> WARNING: ecl is written to provide only one instance of its workspace.
> So whatever code is run will have to play nice with o
fails to produce the right binaries for the Boehm-
Weiser assembly files.
Juanjo
On Aug 31, 11:30 pm, "Dr. David Kirkby"
wrote:
> Juanjo wrote:
> > On Aug 31, 6:37 pm, "Dr. David Kirkby"
> > wrote:
> >> I just tried to build Sage (part of which is MPI
On Aug 31, 6:37 pm, "Dr. David Kirkby"
wrote:
> I just tried to build Sage (part of which is MPIR) on a Sun Ultra 80
> SPARC) machine I set up for testing Sage on the first release of Solaris
> 10.
> It appears this was fixed in Solaris patch 123647-01 (August 2006),
> though the latest version o
S="-O2 -g" so he was probably giving the defaults + what is
needed for 64 bits.
Juanjo
--~--~-~--~~~---~--~~
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...@
or
details left -- makefiles, autoconf --.
Juanjo
--~--~-~--~~~---~--~~
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
On Aug 28, 8:04 pm, rjf wrote:
> On Aug 27, 5:16 pm, Juanjo
> wrote:
>
> > On Aug 27, 11:24 pm, rjf wrote:
>
> > > perhaps ECL does not have something like schedule-finalization. I
> > > think this is present in CMUCL, SBCL, Lispworks, and AllegroCL, at lea
On Aug 28, 3:41 am, Nils Bruin wrote:
> On Aug 27, 5:16 pm, Juanjo
> wrote:
>
> > I have just uploaded some patches to our source repositories that
> > allow ECL coexist with a GMP library which uses other memory
> > allocation functions. The changes are a
On Aug 27, 11:24 pm, rjf wrote:
> perhaps ECL does not have something like schedule-finalization. I
> think this is present in CMUCL, SBCL, Lispworks, and AllegroCL, at least.
ECL does have finalization but this is an overkill for the problem in
question -- it would slow down all bignum arithme
On Aug 27, 4:06 am, Nils Bruin wrote:
> mpz_init(&c)
> mpz_add(&c,&a,&b)
> d=ecl_alloc( (c->_mp_size )*sizeof(limb))
> memcpy(d,c->_mp_alloc,c->_mp_size * sizeof(limb))
> r=ecl_alloc(sizeof(mpz_t))
> r->_mp_size = c->_mp_size
> r->_mp_d = d
> r->_mp_alloc = c ->_mp_size
> mpz_clear(&c)
> now we h
On Aug 25, 9:59 pm, Jason Moxham wrote:
> On Tuesday 25 August 2009 20:35:48 Juanjo wrote:
> > I think that the cheapest solution is the one you suggested: allocate
> > the bignums manually and hope that GMP does not reallocate them. This
> > can be easily done in ECL, beca
clude these
changes in upstream, with the only constraint that it would be
selected by some configuration flag.
Juanjo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-dev
routine.
As a side note, no sensible signal handler would do any other thing
than returning, for POSIX interrupts do not guarantee reentrancy of
code. However, I do not know what is the quality of Sage's interrupt
handling right now.
Juanjo
--~--~-~--~~~---~--~~
On Aug 22, 9:12 pm, Nils Bruin wrote:
> On Aug 22, 2:23 am, Juanjo
> wrote:
>
> > A C function can be used to deactivate trapping of signals
>
> Thanks! that is probably a more elegant way.
There is only one thing that worries me, though. ECL installs its own
signal ha
his should be easy to fix.
Thanks for your great work!
Juanjo
--~--~-~--~~~---~--~~
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,
gt; #3 0x004933b5 in PyEval_EvalFrameEx (f=0x1c92d8d0,
> throwflag=) at Python/ceval.c:3690
> [...]
Why is Sage calling an ECL function at all?
Juanjo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegrou
t of object files. The last step is
now a build-program (see maxima/src/maxima.system). If instead of that
you use build-fasl, you will get a big binary file maxima.fasl, that
you can load using ECL's library function (cl_load).
Juanjo
--~--~-~--~~~---~--~~
To p
41 matches
Mail list logo
