On Sat, Dec 8, 2012 at 4:01 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@gmail.com wrote:
On Sat, Dec 8, 2012 at 2:05 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
is there a prettier name than gazonk? :-)
And it is so old that I bet it dates back to KCL days :-)
yes, I
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
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
* 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
.
On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis
g...@integrable-solutions.net 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 had to do
On Sun, Aug 19, 2012 at 1:44 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@gmail.com wrote:
On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
After modifying c/symbols_list.h and c/symbols_list2.h to include
a definition for :WIN64,
I uploaded
On Sun, Aug 19, 2012 at 2:27 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@gmail.com wrote:
On Sun, Aug 19, 2012 at 9:14 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
No, it wasn't. Browse to the source code for number.d
http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/c
On Sun, Aug 19, 2012 at 3:46 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@gmail.com wrote:
On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
Unfortunately, it failed to execute properly, apparently for the
same reasons as 2 years ago.
There were
On Thu, Feb 9, 2012 at 8:24 PM, Daniel Herring dherr...@tentpost.com 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.
On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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
On Fri, Feb 3, 2012 at 10:13 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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.
On Sun, Jan 1, 2012 at 1:14 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sun, Jan 1, 2012 at 7:34 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote:
A fresh update of my local copy of ECL CVS version shows a regression
involving macro expansion, GETHASH, SETF and HASH
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:
| On Sun, Jan 1, 2012 at 7:34 PM, Gabriel Dos Reis g...@cs.tamu.edu 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
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
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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
On Sun, Jan 2, 2011 at 10:58 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sun, Jan 2, 2011 at 10:39 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote
On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote
On Sun, Jan 2, 2011 at 3:27 PM, David Brown l...@davidb.org 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 unlimited combinations
On Sun, Jan 2, 2011 at 3:27 PM, David Brown l...@davidb.org 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
On Sun, Jan 2, 2011 at 4:53 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
Because of ECL's design decision to target the C programming language,
and the C programming language has
On Wed, Dec 22, 2010 at 5:50 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Wed, Dec 22, 2010 at 2:48 AM, David Kirkby david.kir...@onetel.net
wrote:
Removing the compiler options
-G -Bdynamic
and replacing with
-shared -Wl,-soname,libcliquer.so
solved another
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
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
On Sat, Nov 6, 2010 at 1:19 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sat, Nov 6, 2010 at 10:31 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
Hi Juanjo,
ECL trunk (CVS) fails to compile on x86_64 running openSUSE-11.3 (GCC
4.5.0)
This has been
On Sat, Oct 30, 2010 at 10:51 PM, Paul Goins gene...@vultaire.net 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
On Fri, Oct 29, 2010 at 8:48 AM, Paul Goins gene...@vultaire.net 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
On Fri, Oct 29, 2010 at 12:48 PM, Paul Goins gene...@vultaire.net 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 7, so let me know
how it went
On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić marko.ko...@gmail.com 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
On Fri, Oct 29, 2010 at 3:20 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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
On Fri, Oct 29, 2010 at 3:34 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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
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
***
Gabriel Dos Reis g...@cs.tamu.edu 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/ecls
On Sun, Oct 3, 2010 at 3:16 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com 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
On Mon, Sep 20, 2010 at 1:27 AM, Daniel Herring dherr...@tentpost.com 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
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
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,
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:
| On Wed, Aug 18, 2010 at 5:03 PM, Gabriel Dos Reis g...@cs.tamu.edu wrote:
|
| Has anybody been successful building ECL from CVS trunk on Windows
| 32-bit using msys/mingw? For me it fails with:
|
| In file
On Thu, May 20, 2010 at 1:11 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Fri, May 14, 2010 at 5:44 PM, Gabriel Dos Reis g...@cs.tamu.edu 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 Tue, Jul 13, 2010 at 5:12 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Wed, Jul 14, 2010 at 12:04 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
well there is still the pending issue that ECL now leaves lots of tempory
files ecl* or ECL* in the /tmp
On Mon, Jul 12, 2010 at 5:09 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov angavri...@gmail.com
wrote:
(defmethod foo ((bar t)) (declaim (optimize (speed 1
I did not change anything since yesterday and this
On Thu, Jul 1, 2010 at 4:39 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Tue, Jun 29, 2010 at 2:12 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote
42 matches
Mail list logo
