On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll
wrote:
> * MAKE-PATHNAME reimplemented to ensure that :CASE is only applied to the
> user arguments.
>
> * NAMESTRING will refuse to produce a string when :NAME is nil and :TYPE is
> not. The reason is ".txt" = (make-pathname :name ".txt" :t
Hi Juanjo,
Is the ECL compilation scheme of functions defined by
labels likely to yield better codes than those functions
defined at toplevel?
-- Gaby
--
This SF.net email is sponsored by Sprint
What will you do first
On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll
wrote:
> * Proclamations are also used to deduce the type of a function's arguments
> and create argument type checks.
Now that ECL is getting good at using function proclamations for
arguments types, is there away to report functions name
On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll
wrote:
> * Proclamations are also used to deduce the type of a function's arguments
> and create argument type checks.
>
Hi Juanjo,
The function arguments checking seems to have a bug. The attached
testcase (distilled from OpenAxiom) pr
On Mon, Jun 28, 2010 at 9:13 PM, Matthew Mondor
wrote:
> I rebuilt an ECL from ECL HEAD to test these new changes.
> While building some code which uses function proclamations, there also
> was a new problem:
I forgot to mention that I could not build OpenAxiom. I do not know whether
Maxima uses
On Thu, Jul 1, 2010 at 4:39 PM, Juan Jose Garcia-Ripoll
wrote:
> On Tue, Jun 29, 2010 at 2:12 AM, Gabriel Dos Reis
> wrote:
>>
>> On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll
>> wrote:
>> > * Proclamations are also used to deduce the type of a f
On Mon, Jul 12, 2010 at 5:09 PM, Juan Jose Garcia-Ripoll
wrote:
> On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov
> wrote:
>>
>> (defmethod foo ((bar t)) (declaim (optimize (speed 1
>
> I did not change anything since yesterday and this works for me.
>
Maybe Alexander did not rebuild fro
On Tue, Jul 13, 2010 at 4:20 PM, Juan Jose Garcia-Ripoll
wrote:
> On Tue, Jul 13, 2010 at 9:43 AM, Alexander Gavrilov
> wrote:
>>
>> > On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov
>> > wrote:
>> >
>> > > (defmethod foo ((bar t)) (declaim (optimize (speed 1
>> > >
>> >
>> > I did not ch
On Tue, Jul 13, 2010 at 5:12 PM, Juan Jose Garcia-Ripoll
wrote:
> On Wed, Jul 14, 2010 at 12:04 AM, Gabriel Dos Reis
> wrote:
>>
>> well there is still the pending issue that ECL now leaves lots of tempory
>> files ecl* or ECL* in the /tmp directory...
>
> I
Hi Juanjo,
Do you have a documentation for ECL's FASL format (and data structures)?
-- Gaby
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- htt
On Thu, May 20, 2010 at 1:11 AM, Gabriel Dos Reis
wrote:
> On Fri, May 14, 2010 at 5:44 PM, Gabriel Dos Reis wrote:
>> Hi Juanjo,
>>
>> As I cannot build OpenAxiom with ECL HEAD, despite commits from today,
>> I tried to see the effect of the improvement on build
On Sat, Jul 17, 2010 at 4:41 PM, Juan Jose Garcia-Ripoll
wrote:
> On Thu, Jul 15, 2010 at 3:08 AM, Gabriel Dos Reis
> wrote:
>>
>> Do you have a documentation for ECL's FASL format (and data structures)?
>
> Not really: read.d and more precisely read_VV document th
Hi Juanjo,
By way of necessity I ended up with only a Windows 7 64-bit machine
on travel. I managed to have mingw-w64 up and running flawlessly
(so far.) I tried to compile ECL, but only to realize that it supports only
ILP or LP data model. The windows box I am running is LLP-64.
Was that restr
Hi Juanjo,
While I was looking at the configure issue of ECL on Windows 64-bit, I
noticed that the tests for sized integer types were
(1) duplicating what Autoconf already does for free (and more)
(2) copy-n-pasted duplicates
The patch below refactors the boilerplate into a single macro:
E
Juan Jose Garcia-Ripoll writes:
| Hi Gabriel,
|
| thanks a lot for the refactoring. I wrote those tests at a time when I
| was not sure that they existed and did the proper job. BTW, regarding
| your previous question about stdint.h, some platforms define that
| header but they do not provide an
On Wed, Aug 11, 2010 at 3:41 AM, Juan Jose Garcia-Ripoll
wrote:
> Hi Gabriel,
>
> ECL just needs an integer type that fits a pointer. That type is used
> for defining cl_fixnum / cl_index, and in various places you will find
> conversions to and from cl_object. In the LLP model, which I did not
>
On Wed, Aug 11, 2010 at 5:16 PM, Juan Jose Garcia-Ripoll
wrote:
> On Wed, Aug 11, 2010 at 4:39 PM, Gabriel Dos Reis
> wrote:
>>
>> I did try last night to get ECL use intptr_t, when available, for
>> cl_fixnum.
>> That discovered some overflow arithmetics in the C c
On Thu, Aug 12, 2010 at 12:35 PM, Juan Jose Garcia-Ripoll
wrote:
> For Mingw you should use a more recent (alpha) release of the garbage
> collector, install it and then build ECL. Sorry for the inconvenience, but
> the GC people do not yet dare to produce a stable release.
> Juanjo
That is what
ecls-list-boun...@lists.sourceforge.net writes:
| "Gabriel, your message was too large for the mailing list, but it was
| automatically forwarded to me this morning. I will commut the changes
| to number.h and have a look at the rest. Thanks a lot for your help.
|
| Juanjo"
Hi Juanjo,
After hav
Juan Jose Garcia-Ripoll writes:
| On Fri, Aug 13, 2010 at 11:35 AM, Gabriel Dos Reis wrote:
|
| So, I am wondering why ECL is making that distinction? That is, why does
| ECL need to distinguish 'long' from ECL_FIXNUM_TYPE? Should not
| the distinction between GMP_LI
Gabriel Dos Reis writes:
[...]
| Index: big.d
| ===
| RCS file: /cvsroot/ecls/ecl/src/c/big.d,v
| retrieving revision 1.43
| diff -p -r1.43 big.d
| *** big.d 1 Feb 2010 13:55:16 - 1.43
| --- big.d 13 Aug 2010 09
hi,
Has anybody been successful building ECL from CVS trunk on Windows
32-bit using msys/mingw? For me it fails with:
In file included from
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/
unistd.h:13,
from c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/file.d:29:
c:\mingw\bi
Juan Jose Garcia-Ripoll writes:
[...]
| I started the week with an abundance of patience and hope for ECL on
| Windows boxes, but it seems to be drying up very quickly.
|
|
| Some ideas
|
| - the windows 32 bit port worked. if something broke in the mean time and
| nobody reported it
Juan Jose Garcia-Ripoll writes:
| On Wed, Aug 18, 2010 at 5:03 PM, Gabriel Dos Reis wrote:
|
| Has anybody been successful building ECL from CVS trunk on Windows
| 32-bit using msys/mingw? For me it fails with:
|
| In file included from
| c:\mingw\bin\../lib/gcc/mingw32
"aeri...@xs4all.nl" writes:
| Hi,
|
|
| Date: Wed, 18 Aug 2010 10:03:44 -0500
| From: Gabriel Dos Reis
| Subject: [Ecls-list] ECL on Windows 32-bit with msys/mingw
| To: ecls-l...@lists.sf.net
| Message-ID: <87eidwarov@gauss.cs.tamu.edu>
| Co
Juan Jose Garcia-Ripoll writes:
| On Wed, Aug 18, 2010 at 11:15 PM, Juan Jose Garcia-Ripoll <
| juanjose.garciarip...@googlemail.com> wrote:
|
| On Wed, Aug 18, 2010 at 6:37 PM, Gabriel Dos Reis
wrote:
|
| libeclmin.a(ffi.o): In function `si_make_dynamic_callback':
Juan Jose Garcia-Ripoll writes:
[...]
| --with-dffi is only useful when combined with --enable-shared, because the
| later allows finding out shared libraries, loading them and retrieving
pointers
| to their C functions, which DFFI may then use as described before.
|
| --with-dffi is only need
Juan Jose Garcia-Ripoll writes:
| BTW, I just finished configuring the Windows64 virtual image and right now all
| tests are run through it:
| http://ecls.sourceforge.net/logs.html
Great!
| However, I still have not managed installing mingw64, nor setting up the MSVC
| port to use LLP.
I wi
In fact I have a question I should ask now.
I am introducing a CPP macro, say ECL_MS_WINDOWS_HOST, that tells where
ECL is being built as a native Windows program (this includes using MS
compiler, GNU MinGW/MSYS or mingw-w64, but excludes Cygwin). This is
easily done by configure. And all is w
Hi Juanjo,
The new header file src/c/features.h appears to break builds on Linux.
Indeed, on many linux distributions there already exists a header file
named feature.h. In the ECL case, it looks like is picking
the new (ECL) file as opposed of the (linux) system supplied header.
This is on
Juan Jose Garcia-Ripoll writes:
| On Sat, Aug 21, 2010 at 10:02 PM, Gabriel Dos Reis wrote:
|
| The new header file src/c/features.h appears to break builds on Linux.
| Indeed, on many linux distributions there already exists a header file
| named feature.h. In the ECL case, it
Hi Juanjo,
I am looking at this snippet from ecl_make_stream_from_fd in src/c/file.d:
#if defined(ECL_WSOCK)
if (smm == smm_input_wsock || smm == smm_output_wsock || smm ==
smm_io_wsock)
fp = (FILE*)fd;
else
fp = fdopen(fd, mod
Hi Juanjo,
Yesterday, I tried to cross build a native Windows ECL compiler but it
looks as if the current configure/build infrastructure puts far more
burdens than it ought to be -- and this goes back to some discussions we
had last month. More on that later.
I then decided to use Wine to comp
On Thu, Sep 16, 2010 at 5:30 AM, Dr. David Kirkby
wrote:
> I thought I'd reported this before, but can't see to find the email. So I'll
> have another go.
>
> When I'm building ecl-10.2.1 as part of Sage I get too warning messages from
> gcc.
I fear nothing can be done about ECL-10.2.1. It has
On Sat, Sep 18, 2010 at 3:51 PM, Dr. David Kirkby
wrote:
> I'm sure you wont consider this a high priority, but ECL appears to be linking
> unnecessarily to libintl.so at least on OpenSolaris.
>
> An intersting blog post here
>
> http://blogs.sun.com/rie/entry/tt_dependencies_tt_define_what
>
> sh
On Mon, Sep 20, 2010 at 1:27 AM, Daniel Herring wrote:
> On Sun, 19 Sep 2010, Juan Jose Garcia-Ripoll wrote:
> If the test passes without -lintl, then that library is not used. If it
> only passes with -lintl, then you don't care what OS you're on until
> somebody else finds a case where this br
On Wed, Sep 22, 2010 at 4:27 PM, Anton Vodonosov wrote:
> 2.a) Add CL_INT_BITS and CL_LONG_BITS declaration (similar to CL_FIXNUM_BITS)
> 2.b) The declaration ECL_LONG_LONG_BITS=no geneted by default doesn't work
> (the
> relevant build error log is attached). Probably it was meant to have _
On Thu, Sep 30, 2010 at 11:03 AM, Samium Gromoff
<_deepf...@feelingofgreen.ru> wrote:
> On Thu, 30 Sep 2010 19:08:48 +0400, Samium Gromoff
> <_deepf...@feelingofgreen.ru> wrote:
>> However, @libdir@ is @prefix@/lib, which somehow works on Linux, and
>> breaks on MinGW.
>
> Ok, so "*mingw" have INS
On Sun, Oct 3, 2010 at 3:16 PM, Juan Jose Garcia-Ripoll
wrote:
> It seems that "configure" does not work when one of the directories contains
> a space in the name. Is this a known limitation?
> Juanjo
Hmm, I don't understand what you mean...
But, I usually invoke the configure script with a rela
Hi Juanjo,
Attached is a patch I had needed (and that has been sitting on my hard-drive
for a while now.) It addresses some pesky issues related to
cross-compiling ECL.
1. ECL hard-codes the name of the program `ranlib'. That should not be.
Rather, like the compiler,the name should be dete
Juanjo,
this patchlet fixes a typo in src/Makefile.in that breaks "make install".
-- Gaby
Index: src/configure.in
===
RCS file: /cvsroot/ecls/ecl/src/configure.in,v
retrieving revision 1.241
diff -p -r1.241 configure.in
*** src/con
Gabriel Dos Reis writes:
| Juanjo,
|
| this patchlet fixes a typo in src/Makefile.in that breaks "make install".
Wrong patch :-(
Here is the right patch.
-- Gaby
Index: src/Makefile.in
===
RCS file: /cvsroot/ec
Juan Jose Garcia-Ripoll writes:
| On Mon, Oct 4, 2010 at 9:39 PM, Gabriel Dos Reis wrote:
|
| Attached is a patch I had needed (and that has been sitting on my
| hard-drive
| for a while now.) It addresses some pesky issues related to
| cross-compiling ECL.
|
|
| Hi Gabriel
On Fri, Oct 29, 2010 at 8:48 AM, Paul Goins wrote:
> Hi,
>
> New to the list, so please forgive me if I've missed a thread that
> covers this.
>
> I'm trying to compile ECL 10.4.1 under Windows 7 64-bit.
> Unfortunately, I'm having problems, and the "Windows with
> Mingw/Cygwin" section of the ref
On Fri, Oct 29, 2010 at 12:48 PM, Paul Goins wrote:
> Hello,
>
> On 10/29/2010 11:43 PM, Gabriel Dos Reis wrote:
>> Add --enable-boehm=system so that ECL picks up the GC library
>> you just installed.
>>
>> PS: I have not been able to build ECL on windows
On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić wrote:
> Just wanted to ask the same question, but you beat me to it :)
> I'm using mingw64, Win7 64, similar to you.
I have been using mingw64, windows 7 64-bit, and I have not been able
build full ECL. However, I can build ecl_min.exe, but it crashe
On Fri, Oct 29, 2010 at 3:20 PM, Juan Jose Garcia-Ripoll
wrote:
> Regarding more generally Win64 support, I have built ECL with Windos64
> support using Microsoft's compilers. Indeed this is the regular build in
> ECL's test farm whenever it is not off the grid (ecls.sf.net/logs.html). I
> was ne
On Fri, Oct 29, 2010 at 3:32 PM, Marko Kocić wrote:
> On Fri, Oct 29, 2010 at 10:28 PM, Gabriel Dos Reis
> wrote:
>> On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić wrote:
>>> Just wanted to ask the same question, but you beat me to it :)
>>> I'm using mingw6
On Fri, Oct 29, 2010 at 3:34 PM, Juan Jose Garcia-Ripoll
wrote:
> I did not find such a thing. All I found were several mingw64 packages and
> various naming conventions for them, no msys and thus no apparent support
> for Unix-like builds and an overall lack of instructions. It was pretty
> frus
On Sat, Oct 30, 2010 at 10:51 PM, Paul Goins wrote:
> I've looked into things a bit further here. Perhaps now it's not
> problems with ECL per se, but with compiling the Boehm GC.
Is this GC from CVS as of today?
-- Gaby
-
Hi Juanjo,
ECL trunk (CVS) fails to compile on x86_64 running openSUSE-11.3 (GCC 4.5.0)
;;; Note:
;;; Invoking external command:
;;; gcc -I. "-I/home/gdr/src/ecl.cvs/build/" -DECL_API
-I"/home/gdr/src/ecl.cvs/build/c" -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -Dlinux
-I"/home/gdr/sr
On Sat, Nov 6, 2010 at 1:19 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sat, Nov 6, 2010 at 10:31 AM, Gabriel Dos Reis
> wrote:
>>
>> Hi Juanjo,
>>
>> ECL trunk (CVS) fails to compile on x86_64 running openSUSE-11.3 (GCC
>> 4.5.0)
>
> This has been fixed
On Sun, Nov 7, 2010 at 2:54 PM, Dr. David Kirkby
wrote:
> It's a shame it can't be configured, but I understand your reasons.
Not every tiny bit of unportable code should be candidate for
configure. Some are
best just avoided.
>
>> Juanjo
>>
>
> Unless I am mistaken, this problem is only seen w
On Mon, Nov 8, 2010 at 2:45 AM, Dr. David Kirkby
wrote:
> I assumed the fact the Sun compiler was compiling this without problems,
> that the code was standard C, but I take your word for the fact the bit of
> code is not. I don't actually know precisely the bit of affected code, so I
> was unawa
Hi Juanjo,
I reported this issue a couple of months ago, but I don't think anything
has happened. ECL builds leave behind lot of temporary files in the
temporary directory (this happens both on linux and windows, I've not
built ECL on macs for a while.)
For example, I have
gauss[14:46]% ls /tm
On Wed, Dec 22, 2010 at 5:50 AM, Juan Jose Garcia-Ripoll
wrote:
> On Wed, Dec 22, 2010 at 2:48 AM, David Kirkby
> wrote:
>>
>> Removing the compiler options
>> -G -Bdynamic
>> and replacing with
>> -shared -Wl,-soname,libcliquer.so
>> solved another text relocation issue in Sage
>> http://trac.
On Fri, Dec 24, 2010 at 6:35 AM, Juan Jose Garcia-Ripoll
wrote:
> I have fixed this by wrapping c:safe-run-program in a form that changes the
> process current directory to the one dictated by *default-pathname-defaults*
> I am not yet sure that this is the right solution.
>
> The problems you wer
On Mon, Dec 27, 2010 at 5:07 PM, Juan Jose Garcia-Ripoll
wrote:
> Testing and bug fixing proceeds. While I would love to make the release
> before the 31st, I find it is more important getting it right. I say this
> because it is 27th and I still have not managed to reactivate testing of
> Axiom a
Hi Juanjo,
Attached is the patch for the typo I was talking about earlier.
The way I discovered it was a bit unusual: I forgot that my existing ECL
build tree was 32-bit, but when I reconfigured and relaunched the build
with 64-bit compiler, it took a different path and GCC chocked.
After this
Hi,
Happy New Year everybody!
The message below is an ackward way of starting the new year, but
it seems there is no way around it. So, I'll try to be brief.
I have a hectic schedule ahead of me but I'll try to follow the
discussion, to the extent I can and also depending on whether it leads
t
On Sat, Jan 1, 2011 at 2:23 PM, DS wrote:
>
> On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
>
>> Anyway, I do no believe that the suggestion for ECL to make available
>
>> its binary flavor is equivalent to building and maintaining a database
>
>> of all imagin
On Sat, Jan 1, 2011 at 2:41 PM, DS wrote:
>
> On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
>
>> What happens on macintel 64-bit with ECL is that ECL
>
>> puts out I686 instead there -- even when it is clearly a 64-bit binary
>
>> program.
>
>> ...
>
On Sat, Jan 1, 2011 at 3:51 PM, David Brown wrote:
> On Sat, Jan 01 2011, Gabriel Dos Reis wrote:
>
>> On POSIX systems, ECL can just issue `file
>> test-program-linked-against-required-c-lib' and use the output to
>> determine the binary flavour. On non-posix sy
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis
> wrote:
>>
>> > Extracting the information from there might be easier and more portable.
>>
>> Yes, that is what I suggested in private convers
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> Now let's put this in context. Should OpenAxiom or any other ECL user want
> to link against a preinstalled GMP, or gnome library, would they demand that
> the library supplies this information? How would they obtain that
> informat
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> * Autoconf triplets. ECL currently exports them as *features* and as the
> output of other functions but they do not work. They are unreliable and OS
> X, where OpenAxiom failed to build because of this, is an example.
Autoconf rep
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> This seems to be the current attitude in the Autoconf'ed world, where
> uniform build environments are assumed and deviations from them are a
> responsibility of the packager or builder.
I don't know what you mean by that. I don't
On Sun, Jan 2, 2011 at 10:58 AM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 10:39 AM, Gabriel Dos Reis
> wrote:
>>
>> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
>> wrote:
>> > On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis
>>
On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis
> wrote:
>>
>> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
>> wrote:
>>
>> > This seems to be the current attitude in the Auto
On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
> On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
>
>> On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
>
>> Of course, the number of combinations will be always limited, in practice.
>> I never asked for an unl
On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
> Most Lisp compilers take significant amounts of work to make them build
> on a different configuration. ECL often just works. Asking it to try
> and deduce a bunch of information about that configuration would make it
> much less portable tha
On Sun, Jan 2, 2011 at 4:04 PM, David Brown wrote:
> On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
>
>> On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
>>
>>> Most Lisp compilers take significant amounts of work to make them build
>>> on a different
On Sun, Jan 2, 2011 at 4:06 PM, David Brown wrote:
> Then, what exactly, are you asking for? There are an unbounded number
> of combinations that ECL can support,
"can support" is very different from "actually support". For example, using
your criteria, there is an unbounded set of standard C
On Sun, Jan 2, 2011 at 4:55 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 11:25 PM, Gabriel Dos Reis
> wrote:
>>
>> However, we are all happy because for the limited set of platforms that
>> ECL *actually* runs, we can expect most C compilers to be blin
On Sun, Jan 2, 2011 at 4:53 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis
> wrote:
>>
>> Because of ECL's design decision to target the C programming language,
>> and the C programming language has lots ot parameters left to
On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff
<_deepf...@feelingofgreen.ru> wrote:
> I am replying to several mails, by different authors here, sorry for
> that.
>
> On Sat, 01 Jan 2011 13:13:36 -0600, Gabriel Dos Reis wrote:
>> At the moment, since the discussion
On Tue, Jan 4, 2011 at 8:17 AM, Samium Gromoff
<_deepf...@feelingofgreen.ru> wrote:
> On Tue, 4 Jan 2011 05:10:55 -0600, Gabriel Dos Reis
> wrote:
>> On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff
>> <_deepf...@feelingofgreen.ru> wrote:
>> > My impression
ECL fails to build on Windows 7 64-bit using
msys and MinGW64. The symbols FFI_SYSV and SYS_UNIX64
appear not be defined when they are referenced in
src/c/ffi.d:145
src/c/ffi.d:147
Configure command line was
./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
I'm using
Nick Walters writes:
| Hello,
|
| I am trying to get a working build of Open Axiom on Mac OS X. My requirements
| are such this must be built with ECL as opposed to one of the other Lisp
| compilers. I am building Open Axiom 1.4.1 with the latest ECL (11.1.1). I am
| able to build but when I try
I synced my local copy of ECL to match trunk.
Then I issued 'make clean'. The result is an
infinite loop:
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4426]: Entering directory `/home/gdr/src/ecl.cvs/build'
for i in lsp cmp clos clx tk ext; do rm -f lib$i.a
$
Hi,
A fresh update of my local copy of ECL CVS version shows a regression
involving macro expansion, GETHASH, SETF and HASH-SET. In short, after
expansion, the arguments to HASH-SET seems to be switched.
To reproduce this, issue the following in a fresh ECL session
(compile-file "ht-test.l
Juan Jose Garcia-Ripoll writes:
| On Sun, Jan 1, 2012 at 7:34 PM, Gabriel Dos Reis wrote:
|
| A fresh update of my local copy of ECL CVS version shows a regression
| involving macro expansion, GETHASH, SETF and HASH-SET. In short, after
| expansion, the arguments to HASH-SET seems
On Sun, Jan 1, 2012 at 1:14 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 1, 2012 at 7:34 PM, Gabriel Dos Reis wrote:
>>
>> A fresh update of my local copy of ECL CVS version shows a regression
>> involving macro expansion, GETHASH, SETF and HASH-SET. In short, af
On Sun, Jan 15, 2012 at 2:29 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 15, 2012 at 8:46 PM, Gabriel Dos Reis
> wrote:
>>
>> Hi Juanjo,
>> did you get a chance to commit the patch? It appears I may have missed it.
>
>
> Yes, indeed, it is in git/CVS HE
On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll
wrote:
> I just noticed that some cleverly optimizing compilers broke the code I used
> to detect whether the stack grows upwards or downwards. I will upload a
> patch tonight.
Hmm.
The code in question invoked an undefined behaviour. So,
On Fri, Feb 3, 2012 at 10:13 AM, Juan Jose Garcia-Ripoll
wrote:
> ECL is assuming that local variables are kept in the stack. Is this wrong?
What is undefined behaviour isn't assuming the notion of "stack" -- which the
C standard effectively does not know about.
The crucial point is that it is
On Thu, Feb 9, 2012 at 8:24 PM, Daniel Herring wrote:
> On Fri, 3 Feb 2012, Juan Jose Garcia-Ripoll wrote:
>
>> I just noticed that some cleverly optimizing compilers broke the code I used
>> to detect whether the stack grows upwards or downwards. I will upload a
>> patch tonight.
>
> Wouldn't t
* fresh check out of CVS trunk
* configure option: --build=x86_64-w64-mingw64
First failure appeared while compiling c/ffi.d.
Reason: the symbol :WIN64 appears not to be defined anywhere
so that the '@' translation could do something meaningful. Instead
it replaced it with unknown, which of cour
> On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis
> wrote:
>>
>> * fresh check out of CVS trunk
>> * configure option: --build=x86_64-w64-mingw64
>
>
> Is this really enough? Or do I have to also change the value of CC?
that should be enough. That is all I h
On Sun, Aug 19, 2012 at 1:44 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis
> wrote:
>>
>> After modifying c/symbols_list.h and c/symbols_list2.h to include
>> a definition for :WIN64,
>
>
> I uploaded a fix for thi
On Sun, Aug 19, 2012 at 2:27 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Aug 19, 2012 at 9:14 PM, Gabriel Dos Reis
> wrote:
>>
>> No, it wasn't. Browse to the source code for number.d
>>
>>
>> http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/c/numbe
On Sun, Aug 19, 2012 at 3:46 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis
> wrote:
>>
>> Unfortunately, it failed to execute properly, apparently for the
>> same reasons as 2 years ago.
>
>
> There were not so many t
Hi Juanjo,
I've reported, on several occasions, in the past that
an ECL-based build of OpenAxiom takes a very long time
(usually over 2 or 4 hours.) Well, with current CVS
mainline, ECL builds OpenAxiom about 20min on my machine.
It could be argued that it is just a better machine, but on the
sa
is there a prettier name than "gazonk"? :-)
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on de
On Sat, Dec 8, 2012 at 4:01 AM, Juan Jose Garcia-Ripoll
wrote:
> On Sat, Dec 8, 2012 at 2:05 AM, Gabriel Dos Reis
> wrote:
>>
>> is there a prettier name than "gazonk"? :-)
>
>
> And it is so old that I bet it dates back to KCL days :-)
yes, I suspected so -
> I have given it a try https://github.com/juanjosegarciaripoll/cl-cxx
>
> It is indeed not that hard to define wrappers for C++ functions using
> templates as they seem to properly dispatch among functions with different
> arities. Implicit or explicit conversions are also easy to implement, given
On Wed, Aug 7, 2013 at 1:42 AM, Juan Jose Garcia-Ripoll
wrote:
> I am _very_ slowly transitioning all my data and processes to the new
> Windows computer. Due to the changes in the Windows interface it is much
> slower tan I anticipated and found a few surprises.
>
> One surprise is that GMP does
97 matches
Mail list logo
