[Ecls-list] Internal error when compiling the Snark theorem prover with ECL 12.7.1

2012-10-30 Thread Matthias Hölzl 
Hello,

when compiling the Snark theorem prover 
(, or with ASDF system definition at 
),  ECL (version 12.7.1 on OSX 10.8.2, 
installed using homebrew) fails with an internal error:

silverbird:Snark tc$ ecl
;;; Loading "/Users/tc/Prog/Lisp/Quicklisp/setup.lisp"
;;; Loading #P"/usr/local/Cellar/ecl/12.7.1/lib/ecl-12.7.1/cmp.fas"
;;; Loading #P"/usr/local/Cellar/ecl/12.7.1/lib/ecl-12.7.1/asdf.fas"
ECL (Embeddable Common-Lisp) 12.7.1 (git:UNKNOWN)
Copyright (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 in: #.
> (asdf:compile-system :snark)

;;; Loading "/Users/tc/Prog/Lisp/Hacking/Snark/snark.asd"
;;; Loading "/Users/tc/Prog/Lisp/Hacking/Snark/src/snark-implementation.asd"
[...]
;;; Emitting code for UNIFY-IDENTITY.
;;; Emitting code for #:G1290.
/Users/tc/.cache/common-lisp/ecl-12.7.1-unknown-macosx-x86/Users/tc/Prog/Lisp/Hacking/Snark/src/ASDF-TMP-unify-bag.c:7252:10:
 error: 
  use of undeclared identifier 'aux_closure'
value0=(aux_c...
^
/Users/tc/.cache/common-lisp/ecl-12.7.1-unknown-macosx-x86/Users/tc/Prog/Lisp/Hacking/Snark/src/ASDF-TMP-unify-bag.c:7252:26:
 error: 
  use of undeclared identifier 'env0'
value0=(aux_closure.env=e...
^
[...]
/Users/tc/.cache/common-lisp/ecl-12.7.1-unknown-macosx-x86/Users/tc/Prog/Lisp/Hacking/Snark/src/ASDF-TMP-unify-bag.c:7276:65:
 error: 
  use of undeclared identifier 'aux_closure'
value0=(aux_closure.env=env0,cl_env_copy->function=(cl_object)&aux_c...
   ^
9 errors generated.
;;; Internal error:
;;;   ** Error code 1 when executing
;;; (RUN-PROGRAM "cc" ("-I." "-I/usr/local/Cellar/ecl/12.7.1/include/" "-g" 
"-O2" "-fPIC" "-fno-common" "-D_THREAD_SAFE" "-Ddarwin" "-O2" "-w" "-c" 
"/Users/tc/.cache/common-lisp/ecl-12.7.1-unknown-macosx-x86/Users/tc/Prog/Lisp/Hacking/Snark/src/ASDF-TMP-unify-bag.c"
 "-o" 
"/Users/tc/.cache/common-lisp/ecl-12.7.1-unknown-macosx-x86/Users/tc/Prog/Lisp/Hacking/Snark/src/ASDF-TMP-unify-bag.o"))
Condition of type: COMPILE-ERROR
Error while invoking # on #

The first offending function in unify-bag.c is the following

/*  local function G1253  */
/*  optimize speed 3, debug 0, space 0, safety 2  */
static cl_object LC39__g1253(cl_object V1)
{ VT46 VLEX46 CLSR46 STCK46
const cl_env_ptr cl_env_copy = ecl_process_env();
cl_object value0;
ecl_cs_check(cl_env_copy,value0);
{
TTL:

value0=(aux_closure.env=env0,cl_env_copy->function=(cl_object)&aux_closure,LC49bind_yterm(2,ecl_make_fixnum(0),V1))
 /*  BIND-YTERM */;
return value0;
}}

where the problem seems to be that the definition of STCK46 in unify-bag.eclh is

#define STCK46
static cl_object LC40__g1254(cl_object );

which does not include the definition of aux_closure.  As far as I can tell by 
looking at the C output, LC39__g1253 is part of the definition of the 
BIND-XTERM function, which is pretty hairy and defined inside a LABELS form.  
Unfortunately I have no simple test case that triggers the error, so this is 
probably not be a particularly useful bug report.  Sorry about that.

Best regards,

  Matthias


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Too few arguments for proclaimed function MAP-INTO

2012-10-30 Thread Juan Jose Garcia-Ripoll 
On Thu, Oct 25, 2012 at 5:09 AM, Matthew Mondor wrote:

> And then noticed that the PROCLAMATION indeed has an extra SEQUENCE:
>
> (proclamation map-into (sequence function-designator sequence &rest
> sequence)
>

Fixed in CVS/git. Thanks!

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] SLIME, WITH-OPEN-FILE: error in process filter: Wrong number of arguments: nil, 127

2012-10-30 Thread Matthew Mondor 
On Tue, 30 Oct 2012 11:50:17 +0100
Juan Jose Garcia-Ripoll  wrote:

> The original code works for me just fine
> 
> (defimplementation arglist (name)
>   (multiple-value-bind (arglist foundp)
>   (ext:function-lambda-list name)
> (if foundp arglist :not-available)))
> 
> Does it not in your system?

I confirm it works fine again, thanks!
-- 
Matt

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] SLIME, WITH-OPEN-FILE: error in process filter: Wrong number of arguments: nil, 127

2012-10-30 Thread Matthew Mondor 
On Tue, 30 Oct 2012 11:50:17 +0100
Juan Jose Garcia-Ripoll  wrote:

> The original code works for me just fine
> 
> (defimplementation arglist (name)
>   (multiple-value-bind (arglist foundp)
>   (ext:function-lambda-list name)
> (if foundp arglist :not-available)))
> 
> Does it not in your system?

I did not notice that function-lambda-list was modified to work again
with macros.  I'll test this later on as well.

Thanks,
-- 
Matt

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] SLIME, WITH-OPEN-FILE: error in process filter: Wrong number of arguments: nil, 127

2012-10-30 Thread Juan Jose Garcia-Ripoll 
On Tue, Oct 30, 2012 at 2:41 AM, Matthew Mondor wrote:

> With in swank-ecl.lisp:
>
> (defimplementation arglist (name)
>   (let ((arglist (ext:get-annotation name :lambda-list nil)))
> (if (null arglist)
> :not-available
> arglist)))
>
> And your latest changes, it's very nice so far.
>

The original code works for me just fine

(defimplementation arglist (name)
  (multiple-value-bind (arglist foundp)
  (ext:function-lambda-list name)
(if foundp arglist :not-available)))

Does it not in your system?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] ECL performance with respect to OpenAxiom

2012-10-30 Thread Juan Jose Garcia-Ripoll 
On Tue, Oct 30, 2012 at 11:01 AM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:

> 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
> same machine SBCL takes approximately the same time.
> So, whatever you've done lately, that was great!  (Is it because
> of better IO or GC implementation?)  I thought I should
> report that impressive improvement :-)
>

Wow, this is really encouraging. I can see various reasons why the build is
now faster. Some optimisations were accidentally deactivated in the past,
and slot accessors is now way way faster thanks to specific dispatch code.
Does Axiom use a lot of structures and CLOS objects? If so, it can also
profit from a more relaxed safety level which is similar to that of SBCL's
and which also prevented certain inline code...

It was always on my todo list to have a look at the OpenAxiom builds again,
but job gets in the way so often!

Now, if only debugging with ECL could be just as pleasant
> as with SBCL... ;-)


Yeah, *I* would also love that :-)

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[Ecls-list] ECL performance with respect to OpenAxiom

2012-10-30 Thread Gabriel Dos Reis 
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
same machine SBCL takes approximately the same time.
So, whatever you've done lately, that was great!  (Is it because
of better IO or GC implementation?)  I thought I should
report that impressive improvement :-)

Now, if only debugging with ECL could be just as pleasant
as with SBCL... ;-)

-- Gaby

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list