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 c
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 li
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 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 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 _n
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
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
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 t
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 parall
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 stan
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 po
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 gu
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 thi
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 provid
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
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/
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 beginnin
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:
>>
>>
, 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, Willi
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.
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
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 t
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.washingto
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.
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 wit
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
integ
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
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, bu
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 beli
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
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 l
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 a
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 seri
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
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 t
35 matches
Mail list logo
