On Sun, Feb 19, 2012 at 12:54 PM, Andy Hefner ahef...@gmail.com wrote:
I've attached a patch which changes the conditional in config.h to
test GCC's __GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__ macros for
deciding ECL_CAN_INLINE. I've tried ECL built in default (gnu90) and
c99 modes, and in
I think I will do without the configuration flag and just remove the #ifdef
_WIN64 completely
On Sat, Feb 18, 2012 at 3:16 PM, red plait redpl...@gmail.com wrote:
Hi
I believe there is a simpler way to achieve this: just teaching ECL (not
GMP) that there exist long long integers in
On Fri, Feb 17, 2012 at 8:53 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
I see that this is similar to an adaptive spinlock, that'll spin, and
then sleep if the lock cannot be obtained when in blocking mode.
However, it naturally cannot magically awaken immediately when a lock
is freed,
On Fri, Feb 17, 2012 at 8:30 PM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
I'm unfortunately not familiar enough with boehm-gc, but is it possible
that it still uses OS-provided mutexes when ECL uses its own locks? If
so, could it cause issues? Or can ECL feed boehm-gc its own locking
On Tue, Feb 14, 2012 at 8:21 PM, bob bobat...@gmail.com wrote:
I am trying to compile this code into a standalone executable, but all I
am getting is an error:
(defun callme () (format t hello))
(callme)
(sleep 3)
(quit)
The compilation phase gets over fine, emtting hello.obj. But while
On Tue, Feb 14, 2012 at 3:04 PM, red plait redpl...@gmail.com wrote:
It seems that now bitness of gmp (and size of ECL_LONG_LONG_BITS)
depends on building architecture of ECL. But it`s possible to build
gmp under 32bit with
#define __GMP_BITS_PER_MP_LIMB64
#define
On Thu, Feb 16, 2012 at 10:38 PM, red plait redpl...@gmail.com wrote:
Yes, but I want to embed ECL in 32bit application which operate with
64bit numbers. So I want to have functions ecl_to_uint64_t
ecl_to_int64_t for binding making. Unfortunately in current time it
seems only possibility to
This does look like Windows, am I wrong? Did you load (require :cmp) before
doing all this? It would be nice to have a few more details about what you
are doing
* Operating system version
* Compiler toolchain version
* Configuration and compilation flags of ECL
* The file that you want to compile
On Tue, Feb 14, 2012 at 3:04 PM, red plait redpl...@gmail.com wrote:
So why ECL don`t have separate bitness option for integer size ? How
hard it can be added ?
Not too hard, given that ECL controls how gmp is built. Maybe you will have
to change the gmp makefiles to add further flags and
I have finally convinced myself that there is no way to reuse the operating
system mutexes from pthreads or Windows if we still want to have
interruptible threads.
As a possible fix I have uploaded to git/CVS an implementation based on
libatomics' CAS (compare-and-swap) combined with some
On Sat, Feb 11, 2012 at 4:48 PM, Stian Sletner st...@sletner.com wrote:
Configuring with --disable-longdouble didn't change anything.
With --disable-longdouble ECL should not use those functions at all. Could
you send only to me the files ecl/config.h end config.log from the build
directory?
I have had a little bit more of time to think about this.
There is apparently no lisp implementation out there that relies on
operating system mutexes or locks. The degree of control that is needed to
properly handle interrupts forces SBCL and CCL to use their own spinlocks
or to rely on futexes.
On Sat, Feb 11, 2012 at 10:14 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
I believe this would still work in the Windows implementation, where locks
are always recursive, but it strongly relies on having libatomics compiled
in for CAS support.
Sorry, I mixed up
I do not mean that this solves all the issues, but I have managed to put
together a bunch of fixes for the last release and I just want to warn you.
This includes:
* Fixes contributed by Jerry James, red plait, R. M. Kreuter for various
things, from C code to macro characters
* Changes in the
As I said, ECL is not thought to be ran *from the build directory*. Some
time ago we introduced a patch that sets the include directory and adds the
local one -- this was needed for OpenAxiom. This broke compilation of code
when you are placed in ECL's build directory. I just cannot remove that
On Wed, Feb 8, 2012 at 6:21 AM, KDr2 killy.d...@gmail.com wrote:
Thanks for your reply, my env:
* OS: macosx 10.7.3, Darwin Kernel Version 11.3.0
* compiler: gcc-mp-4.6/gcc-4.2.1(from xcode)
* configure arguments: ./configure --enable-threads --with-x
* source git reversion:
On Wed, Feb 8, 2012 at 8:18 AM, KDr2 killy.d...@gmail.com wrote:
I got this backtrace with ecl_min:
ecl_min is not a Common Lisp. The appropriate way to run ecl_min is to use
first make mini_ecl and then ./mini_ecl This ensures that ecl_min loads
all functions from the lisp library which are
On Tue, Feb 7, 2012 at 9:44 AM, KDr2 killy.d...@gmail.com wrote:
* compiler: gcc-mp-4.6
Sorry, I saw the 4.2 elsewhere and only noticed the 4.6 now. What version
is this? XCode ships with llvm-gcc, am I wrong?
BTW, gcc-4.6 is known to miscompile ECL on Windows. I already filed a bug
report for
On Wed, Feb 8, 2012 at 6:05 PM, Raymond Toy toy.raym...@gmail.com wrote:
On Wed, Feb 8, 2012 at 6:01 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Wed, Feb 8, 2012 at 6:59 AM, Raymond Toy toy.raym...@gmail.comwrote:
Does ecl have the equivalent of cmucl's
On Mon, Feb 6, 2012 at 5:36 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Thanks. I have found a bug in the type propagator for EXPT and committed a
fix to my local tree. It will be uploaded tonight or tomorrow, depending on
how the test of other fixes proceeds
On Sun, Feb 5, 2012 at 3:11 PM, red plait redpl...@gmail.com wrote:
Hi
I hope that fixed building subject with GMP_TYPE = p4 or p3
Patched msvc\gmp\Makefile is in attach
Hi, thanks for the fix, but is this line correct?
E:\src\yasm-1.2.0-win32.exe -O9 -Xvc -f win32 -i $(@D)\ -o $@ $?
This
On Sun, Feb 5, 2012 at 6:46 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
On Sun, 5 Feb 2012 00:12:42 +0100
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com wrote:
There are some issues left, but since it is going to take some time to
track them down, I have decided
On Sat, Feb 4, 2012 at 10:18 PM, Waldek Hebisch hebi...@math.uni.wroc.plwrote:
Of course, I am not sure that error is in generated code, because
I can not get reasonable backtrace. Is there a place in ECL so
that after attaching gdb I could set a breakpoint there and
get control passed to
There are some issues left, but since it is going to take some time to
track them down, I have decided not to delay the release any longer.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
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.
Since all other bugs seem to be solved, I will also try to produce the
scheduled release, perhaps along this weekend or on Monday.
On Fri, Feb 3, 2012 at 4:45 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
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
On Fri, Feb 3, 2012 at 5:24 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
This confusese two things: (1) the existence of a stack; (2) the
direction of growth.
The test for (2) is invoking an undefined behaviour. Therefore, the
outcome of
that test does not say anything about
On Thu, Feb 2, 2012 at 8:43 PM, Waldek Hebisch hebi...@math.uni.wroc.plwrote:
This code got mangled in the mail, but AFAICS the change is
to remove 'echo' command at the beginning and add 'touch' at
the end. Still fails:
etags: Unknown language none in language option
The problem is that
On Fri, Feb 3, 2012 at 12:37 AM, Raymond Toy toy.raym...@gmail.com wrote:
(I was surprised to see ecl choose the smallest string type to fit a
literal string.)
Why? I mean, an ordinary unicode string without utf-8 packing takes 4 times
the room of a base string. Since ECL is using a string
On Fri, Feb 3, 2012 at 12:08 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
Building ECL from the git HEAD today results in an error:
My apologies again. I was fixing bugs that were just reported after the RC
and you two downloaded it between two consecutive commits. It should all be
back
On Tue, Jan 31, 2012 at 11:58 PM, Marko Kocić marko.ko...@gmail.com wrote:
Hi Juan,
In order to try windows build without installing older gcc, I tried to
build it using clang.
It built C code fine, but failed in linking phase.
I opened a bug at
Would this work?
TAGS:
if test x$(ETAGS) != x; then \
srcfiles=`find $(srcdir)/c $(srcdir)/h -name '*.[chd]'` \
$(ETAGS) --language=c-o $@ $$srcfiles \
$(ETAGS) --language=none -o $@ --append \
--regex='/@\([-:*a-zA-z]+\)/\1/' \
--regex='/@(defun \([-:*a-zA-z]+\)/\1/' \
Hi Dmitrii,
we need more information. All we know is that there are errors and that
they happen when you use ECL with Fricas, but so far there is no conclusive
evidence as to how and why. Questions one should answer before filing a bug
report
* What is the version number? Not just release
On Sun, Jan 22, 2012 at 3:30 PM, Xiaofeng Yang n.akr.aki...@gmail.comwrote:
I checkout the newest ECL from GIT today. And it miscompiled in MinGW(gcc
4.5.0). I saw it failed with a compiled-function BUILDER was called with
odd keyword parameters.
I fixed it and it compiled after that.
Hi!
On Tue, Jan 17, 2012 at 3:44 PM, Didier Verna did...@lrde.epita.fr wrote:
the CHANGELOG file in src/ mentions version 11.7.1, which I don't
understand. The latest compiled version from git says current version is
11.1.1 (so sez the webpage). What's this 11.7.1 thing ?
Sorry, I did not notice
. The last commit:
commit 10dea13a5122cb1f07bce98f674b4b6574dbd922
Author: Juan Jose Garcia Ripoll jjgar...@users.sourceforge.net
Date: Sun Jan 15 19:54:06 2012 +0100
Unicode strings were not properly saved in C compiled code.
(See http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl
On Tue, Jan 17, 2012 at 5:21 PM, Didier Verna did...@lrde.epita.fr wrote:
but then, after a reset --hard HEAD and a new pull, I indeed got more
changes. Sorry for the noise.
No problem. Please continue reporting any problem or inconsistency you may
find
Juanjo
--
Instituto de Física
I also need the operating system version. Could you also try with ecl
-norc, just to make sure?
On Sun, Jan 15, 2012 at 7:49 AM, Stas Boukarev stass...@gmail.com wrote:
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:
What configuration and version (see first lines
On Sun, Jan 15, 2012 at 9:28 AM, Philipp Marek phil...@marek.priv.atwrote:
I've had strace running on ECL, and got this:
cl-user (open /tmp/a :direction :output :if-exists :overwrite)
open(/tmp/a, O_RDONLY
I see. I did not notice the line where gdb stopped. It seems this is legacy
code
2012/1/12 Anton Vodonosov avodono...@yandex.ru
Take into account, that right after ECL startup,
compiler:*compiler-break-enable* is NIL:
So I suppose something sets it to T during compile-file.
I stand corrected. There is a function, FIX-READ-ONLY-VARIABLE-TYPE that
contained a debug
On Sun, Jan 15, 2012 at 8:46 PM, Gabriel Dos Reis
g...@integrable-solutions.net 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 HEAD. I just checked with tonight's build and
I also verified that the sources in my
What configuration and version (see first lines of ECL's prompt) are you
using?
On Mon, Jan 9, 2012 at 8:34 PM, Stas Boukarev stass...@gmail.com wrote:
(require 'sockets)
;;; Loading #P/home/stas/lisp/impl/ecl/build/sockets.fas
Condition of type: SIMPLE-TYPE-ERROR
The value of ASDF::NAME
Hmm, I do not know much about pipes. Inspecting a running ECL, I see that
it does not hang in ECL, but in the C library: in open()
Attaching to program: `/Users/jjgarcia/bin/ecl', process 49213.
Reading symbols for shared libraries ++.. done
0x7fff86e3543e in open ()
(gdb) info threads
2
Works here. What version is this? What platform? What configuration flags?
2012/1/11 Jędrzej Nasiadek jedrzej.nasia...@gmail.com
Hi!
I tried to build ecl with --disable-shared option, it fails however
with the following error:
;;; Note:
;;; Invoking external command:
;;; ranlib
On Mon, Jan 9, 2012 at 11:40 AM, Anton Vodonosov avodono...@yandex.ruwrote:
Juan Jose, do you have plans to make a new release?
There were significant changes since the last release. And some bugs
fixed.
In particular, the old release doesn't work with the last quicklisp.
I have to bring
On Thu, Jan 5, 2012 at 9:55 PM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
There is an extra while(1) in ecl_to_int64_t().
Thanks for spotting this. I have uploaded a patch.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
On Fri, Dec 30, 2011 at 11:36 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
* Along this line, *EXT:CHECK-VALUE* is a new primitive that inserts
those checks. Roughly the syntax is (EXT:CHECK-VALUE value
non-evaluated-type-name), as in (CHECK-VALUE X INTEGER).
I
Fixed in CVS.
On Sat, Dec 31, 2011 at 4:02 PM, Sylvain Ageneau agen...@gmail.com wrote:
Hello,
I'm seeing the following problem when compiling the latest trunk
(15d1c6dfdf74b171bc79477d1d0105cde8297219):
./configure --with-cmp=no --disable-shared
make
...
;;; Note:
;;; Invoking
2011/12/31 Gábor Balázs gab...@gmail.com
And links having relative paths seem to be problematic too.
This should be fixed in CVS.
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
* The Microsoft Windows port works again. It also contains code to download
the tests, accessible via the make check target, just like in the Unix
ports.
* ECL now sponsors *a more strict type checking* of assignments to
variables. The philosophy is similar to that in SBCL: when a variable is
On Wed, Dec 21, 2011 at 4:26 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
I synced my local copy of ECL to match trunk.
Then I issued 'make clean'. The result is an
infinite loop:
I never managed to reproduce this, but I have removed the lines that might
cause that infinite
This has been fixed in the set of patches I uploaded tonight.
Juanjo
On Tue, Dec 20, 2011 at 2:00 AM, Anton Vodonosov avodono...@yandex.ruwrote:
The latest quicklisp.
ECL build with msvc/Makefile containing
ECL_THREADS = 1
ECL_UNICODE = 1
ECL_CMP = 1
ECL_SOCKETS = 1
(all other
2011/12/31 Gábor Balázs gab...@gmail.com
The truename function doesn't resolve some of the . and .. directories
along the path, so it doesn't provide a canonical path.
They were actually two unrelated bugs. One was that . is normally removed
by ECL from pathnames at construction time. This
On Mon, Dec 19, 2011 at 7:00 PM, Waldek Hebisch hebi...@math.uni.wroc.plwrote:
Put the the following line in a file:
(DEFUN |nangenericcomplex| () (PROG () (RETURN (/ 1.0 (COMPLEX 0.0)
And then try to compile-file it:
(compile-file sfsfun.clisp)
;;; Loading
I have uploaded a fix. ECL will only constant fold a function when the
output is an externalizable value or the function which is evaluated
signals an error.
Juanjo
On Mon, Dec 19, 2011 at 7:00 PM, Waldek Hebisch hebi...@math.uni.wroc.plwrote:
Put the the following line in a file:
(DEFUN
I think we have discussed this before in the mailing list. EQL uses EQL for
type checking and two constants need not be EQL. For instance, two
bitvectors which are EQUAL are not EQL because they are read at different
times
$ ecl -norc
ECL (Embeddable Common-Lisp) 11.1.1
On Sun, Dec 18, 2011 at 8:09 PM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
If I remember SBCL inlines flet/labels by default, yet I'm unsure if
this is always done or only for small functions, I assume the latter.
I am not very keen on this, at least not with the current code, because
On Sun, Dec 18, 2011 at 10:37 PM, Paul Bowyer pbow...@olynet.com wrote:
Thanks for easing my doubts. I assume the unfinished Unless the was
meant to convey that there is no reason to assume there are problems in the
64-bit install that I need to worry about.
Sorry, I did not notice I
On Sat, Dec 17, 2011 at 5:58 PM, Waldek Hebisch hebi...@math.uni.wroc.plwrote:
It seems that recent changes to ECL broke FriCAS build.
Below is minimized version of the problem.
Thanks for reporting. There was a problem with the new code in
DEFMACRO/DESTRUCTURING-BIND. I believe they are
Hi, it would really help if you could tell me the version of ECL which you
are using (is it the last release, git/CVS, which commit?) and the
configuration flags. I cannot reproduce that problem in any of the
computers I have with ECL from the git repository.
jjgarcia@quinfog:~/build$ ecl -norc
As explained here
http://lists.common-lisp.net/pipermail/pro/2011-December/000659.html
and completed by Steve Haflich here
http://lists.common-lisp.net/pipermail/pro/2011-December/000675.html
compiler macros should behave differently with respect to errors.
ECL is now closer to that
On Sat, Dec 10, 2011 at 2:02 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
I noticed that it is expected that ecl be in PATH.
I tried removing that dependency, but the fact that ECL typically builds
with a hardcoded library path means that we can not run ECL from the build
directory --
On Fri, Dec 9, 2011 at 1:41 PM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
To run tests, is only ecl/src/tests/ necessary? If so, is that
dependent on the --with-rt configure option? Because I do see a
Makefile.in there but no Makefile. I've never personally used the
tests but would
On Sat, Dec 10, 2011 at 12:07 AM, Matthew Mondor
mm_li...@pulsar-zone.netwrote:
I have built it, but unfortunately there is no check target in the
top-level Makefile, and I could only find an unprocessed Makefile.in in
src/tests/ (no Makefile).
Sorry, I added the make check target to
I have removed some dependencies. ECL now ships with minitar and deflate as
modules and thus needs not download quicklisp unless the quicklisp tests
are run.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
I have made various changes in ECL that reder the ecl-tests repository
obsolete. These are the changes:
* ECL now ships with a tiny little library, ecl-curl, which can download
arbitrary files via http connections.
* There is a new tests directory that keeps the regression tests and
routines to
On Wed, Dec 7, 2011 at 10:54 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
** Build and run a selection of quicklisp libraries (to be done)
Done. Use make do-quicklisp from inside the tests directory. To test some
other implementation, use environment variables
On Tue, Dec 6, 2011 at 1:44 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
On Tue, 6 Dec 2011 00:27:26 +0100
The few tests to look closer at seem to be: BIGNUM/PARI-200-5,
MANDELBROT/DFLOAT, FACTORIAL, FFT, WALK-LIST/SEQ, SUM-PERMUTATIONS.
I can also see a very slight preformance
On Tue, Dec 6, 2011 at 10:16 AM, Dima Pasechnik dimpase+...@gmail.comwrote:
Sage (www.sagemath.org) project perhaps might help with testing
infrastructure.
(Im not speaking for Sage here, although I think this will be welcome).
ECL is released as a part of Sage, and this happens on a regular
On Tue, Dec 6, 2011 at 11:38 AM, Dima Pasechnik dimpase+...@gmail.comwrote:
I am afraid I did not explain myself very well in the last emails: ECL
does not fix fork() it simply avoids using it in cygwin. This means we have
to use system(), which is only useful in some contexts and may even
Out of curiosity, I have produced some plots comparing the performance of
ECL with a recent copy of SBCL (the one that came with Ubuntu). The goal is
not really to compare implementations, but to see the evolution of ECL and
how it works in different modes: interpreted, multithreaded, compiled,
ECL = single threaded ECL, compiled code
ECLTHR = multithreaded ECL compiled code
*i = interpreted code
Everything running on Ubuntu 11.10, 64 bits
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
On Fri, Dec 2, 2011 at 11:47 AM, Eric Marsden eric.mars...@free.fr wrote:
I had to replace a few calls to cl_alloc_adjustable_base_string by calls
to ecl_alloc_adjustable_base_string to make ECL build without
--enable-unicode.
Eric, you must have some obsolete version of the code. This
On Fri, Dec 2, 2011 at 1:11 PM, Eric Marsden eric.mars...@free.fr wrote:
Hi,
The following is ECL compiled from current git, on Linux/AMD64.
,
| (lisp-implementation-version)
| 9.8.4
Obsolete.
(lisp-implementation-version)
11.1.1
(ctypecase :foo (integer 1) (keyword 2))
[Sorry for possible duplicates]
I just realized that compiler macros might be too restrictive in some
implementations. Take for instance
(define-compiler-macro foo (a key key-arg) ...)
This is assuming that FOO is only going to be invoked with _constant_
keyword arguments. I know, I know, most
On Thu, Dec 1, 2011 at 11:22 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
ECL now inlines forms with constant arguments.
BTW, this also means that now ECL should be able to eliminate dead code
branches, such as
(if (plusp (cos 1.0)) some-code some-unreachable-code
On Tue, Nov 29, 2011 at 3:30 PM, Marko Kocić marko.ko...@gmail.com wrote:
Hi, when building ecl head on mingw I get the following error.
;;; Emitting code for ELIMINATE-REFERENCES.
c:/development/cvstree/ecl/build/cmp/cmpform.c: In function
'L19c1form_unmodified_p':
On Fri, Nov 25, 2011 at 12:51 AM, Paul Bowyer pbow...@olynet.com wrote:
On 11/23/2011 11:56 PM, Juan Jose Garcia-Ripoll wrote:
Hi Paul, have you tried adding :clx to the dependencies list of your ASDF
file? If that is not present, there is no way ECL knows that CLX must be
part of your
Hi Paul, have you tried adding :clx to the dependencies list of your ASDF
file? If that is not present, there is no way ECL knows that CLX must be
part of your system. An alternative is to insert an explicit (require :clx)
at the beginning of your program, but then you will have to ship clx.fas
On Tue, Nov 22, 2011 at 10:47 AM, Stas Boukarev stass...@gmail.com wrote:
I don't see how that's a bug, b isn't required to be EQL to b. It
can be, especially when coalesced by the compiler, but the reader
usually constructs a new string each time.
I agree. Compare that with
(lambda (a)
Anyone has such a function? I would like to plug it into ECL for
downloading the ANSI test suite.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
On Sun, Nov 20, 2011 at 3:12 PM, Zach Beane x...@xach.com wrote:
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:
Anyone has such a function? I would like to plug it into ECL for
downloading
the ANSI test suite.
Quicklisp's http.lisp has something like that, but it's
On Sun, Nov 20, 2011 at 9:16 PM, Paul Bowyer pbow...@olynet.com wrote:
Since I already have quicklisp installed and it's accessible from slime,
or via clbuild using a command shell, it would be redundant to have it
(re-)installed by the ECL test suite unless it was isolated to the ecl-test
On Sat, Nov 19, 2011 at 7:44 PM, Paul Bowyer pbow...@olynet.com wrote:
Since you find the problem in both the standard library and the one
shipped with ECL, and the standard library seems to be OK when used with
SBCL, I would presume the problem to be somewhere in ECL rather than in CLX
On Fri, Nov 18, 2011 at 12:45 AM, Paul Bowyer pbow...@olynet.com wrote:
I've been running ECL in slime to experiment with some CLX test code.
In a fresh instance of slime, the first compilation of the code produces:
[...]
;;; Note:
;;; Unknown type (VALUES NUMBER). Assuming it is T.
;;;
On Sun, Nov 13, 2011 at 7:18 PM, Eric Marsden eric.mars...@free.fr wrote:
,
| (disassemble '(lambda (p1 p2) (declare (optimize (safety 0)) (type
(member #\U00FE) p2)) (equalp p1 p2)))
|
| ;;; Compiling (DEFUN C::GAZONK ...).
| ;;; Emitting code for C::GAZONK.
| /*function
On Sat, Nov 12, 2011 at 1:10 PM, Eric Marsden eric.mars...@free.fr wrote:
The following illustrates a bug in the handling of compound type
specifiers in the compiler. The byte-compiler handles them correctly.
The problem is not really in the compiler, but in the type checks it emits,
which
On Sun, Nov 13, 2011 at 4:38 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
The problem is not really in the compiler, but in the type checks it
emits, which rely on TYPEP
Fixed in git/CVS
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid
On Sat, Nov 12, 2011 at 12:47 PM, Eric Marsden eric.mars...@free.fr wrote:
The following transcript illustrates a bug (on Linux/AMD64) when
compiling code with low safety and type declarations involving unicode
characters.
A few things would be helpful
- Configuration flags for ECL
- Value
Until recently, ECL computed a unique identifier corresponding to the git
repository using .git/ORIG_HEAD. It turns out that this is wrong. Now ECL
uses .git/log/HEAD which contains a history of commits. I hope this will
provide a more accurate information when producing bug reports.
Juanjo
--
On Sun, Nov 13, 2011 at 7:06 PM, Eric Marsden eric.mars...@free.fr wrote:
The bytecode disassembly of my function is below. However, the function
works fine when byte-compiled, only segfaulting when using the C
compiler. I haven't managed to obtain disassembly when compiled via C.
Sorry,
On Sun, Nov 13, 2011 at 10:27 PM, Paul Bowyer pbow...@olynet.com wrote:
I downloaded yet again ecl-test (after saving copies of ansi.log and
bugs.log) and re-ran the test suite. This time everything seemed to run
without problems and I had complete files for ansi.log and bugs.log.
I switched
On Sun, Nov 13, 2011 at 12:26 AM, Paul Bowyer pbow...@olynet.com wrote:
However, the bugs.log file still shows that an error occurred during its
run so I'm attaching it for your inspection in case it is not part of the
yet to be fixed problem mentioned in your reply.
If you delete
On Sat, Nov 5, 2011 at 7:06 PM, Павел Соловейчик paul.soloveyc...@gmail.com
wrote:
'IDB' is illegal extension for PDB file:
This does not seem to be related to ECL but to your installation. From this
bug report
On Sat, Nov 5, 2011 at 6:05 PM, Robert Dodier robert.dod...@gmail.comwrote:
On 11/5/11, Raymond Toy toy.raym...@gmail.com wrote:
Sounds like a bug in ecl. I did a very quick test with writefile using
maxima and cmucl. The output file is not empty.
I just tried (dribble /tmp/foo.log) in
On Sat, Nov 5, 2011 at 11:08 PM, Oliver Kullmann
o.kullm...@swansea.ac.ukwrote:
compiled it, and built Maxima with it, however nothing changed:
writefile still just creates the empty file, and otherwise nothing
happens.
Please understand that my email was not an answer of whatever writefile
Gábor, when you say 11.1.1 yo do not mean 11.1.1 + development from CVS, do
you? I am using the git/CVS version for the tests I mention and they work
in Linux/amd64
The official release is now too old. I should make a new one because of the
many changes, but travel and work prevented me from
Ok, several things. The first one, which I noticed right now, is that ECL
defaults to :RESOLVE-SYMLINKS NIL. This may be unusual and I will change
it. The second one is that I do not get your results with
:RESOLVE-SYMNLINKS NIL (See below).
What type and version of the operating system is this?
2011/10/26 Gábor Balázs gab...@gmail.com
Is there a way with ECL not to resolve symlinks in directory listings?
Like other Lisp implementations (eg. SBCL) usually have an option like :
(directory
/tmp/* :resolve-symlinks nil)
Same syntax (:resolve-symlinks) should work.
Juanjo
--
I have found it quite annoying lately having to think whether I want to use
EXT:RMDIR or DELETE-FILE on a path. Would you find it ok if I merge both?
The only implementation that seems to support this is ABCL.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006
301 - 400 of 633 matches
Mail list logo
