Pascal J. Bourguignon | 1 Jun 2010 10:51
Face
Favicon

debugging ecl?


I'm trying to patch ecl (I'd want it to behave like clisp translating
logical pathnames, downcasing the full uppercase names on unix
systems).

Unfortunately, it seems that I wrote bugs, since build/ecl_min breaks
when I invoke the code I modified:

[pjb <at> kuiper :0.0 ecl]$ build/ecl_min 
;*** Lisp core booted ****
ECL (Embeddable Common Lisp)

> (setf (logical-pathname-translations "TEST") '(("TEST:**;*.*" "/tmp/**/*.*")))

Internal or unrecoverable error in:

Lisp initialization error.

  [22: Invalid argument]
Aborted
[pjb <at> kuiper :0.0 ecl]$ 

How should I proceed to debug ecl_min?

I tried gdb on ecl_min, but it fails miserably:

(gdb) handle SIGSEGV pass nostop
Signal        Stop	Print	Pass to program	Description
SIGSEGV       No	Yes	Yes		Segmentation fault
(gdb) run
(Continue reading)

Alessandro Serra | 1 Jun 2010 12:50
Picon

Re: debugging ecl?

Hi Pascal,
you can try:
(gdb) bt
It will show you the function call backtrace. Use it instead of quit.
Alessandro

On Tue, Jun 1, 2010 at 10:51 AM, Pascal J. Bourguignon
<pjb@...> wrote:
>
> I'm trying to patch ecl (I'd want it to behave like clisp translating
> logical pathnames, downcasing the full uppercase names on unix
> systems).
>
> Unfortunately, it seems that I wrote bugs, since build/ecl_min breaks
> when I invoke the code I modified:
>
>
> [pjb <at> kuiper :0.0 ecl]$ build/ecl_min
> ;*** Lisp core booted ****
> ECL (Embeddable Common Lisp)
>
>> (setf (logical-pathname-translations "TEST") '(("TEST:**;*.*" "/tmp/**/*.*")))
>
> Internal or unrecoverable error in:
>
> Lisp initialization error.
>
>  [22: Invalid argument]
> Aborted
> [pjb <at> kuiper :0.0 ecl]$
(Continue reading)

Juan Jose Garcia-Ripoll | 1 Jun 2010 13:30

Re: debugging ecl?

On Tue, Jun 1, 2010 at 10:51 AM, Pascal J. Bourguignon <pjb <at> informatimago.com> wrote:
Unfortunately, it seems that I wrote bugs, since build/ecl_min breaks
when I invoke the code I modified:


[pjb <at> kuiper :0.0 ecl]$ build/ecl_min
;*** Lisp core booted ****
ECL (Embeddable Common Lisp)

> (setf (logical-pathname-translations "TEST") '(("TEST:**;*.*" "/tmp/**/*.*")))

Run it with

$ cd build; ./ecl_min bare.lsp

so that it loads the rest of Common Lisp first! Without the rest of the library you do not even have SETF and thus your statement does not work.

Juanjo 

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
------------------------------------------------------------------------------

_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Erik Winkels | 1 Jun 2010 14:23
Picon
Picon
Favicon
Gravatar

Return values sometimes missing on REPL

I'm starting a REPL by doing this in C++:

    cl_object obj = ecl_read_from_cstring("si:top-level");
    cl_funcall(1, obj);

Now when calling functions that have been created with ecl_def_c_function
I almost never get the return value back at the REPL, but they are set
when I call the same function with setf or defparameter.  Like so:

    ECL (Embeddable Common-Lisp) 10.4.1
    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: #<process SI:TOP-LEVEL 09f32fc0>.
    OGRE[1]> (get-actual-height *viewport*)
    OGRE[2]> (defparameter height (get-actual-height *viewport*))
    HEIGHT
    OGRE[3]> height
    480
    OGRE[4]> (camera-get-position *camera*)
    #(100.0 100.0 100.0)

As you can see, the last form did return a value.  That one returns a
cl_object created with cl_vector(...).  All the others are generally
created with ecl_make_... function or are just plain Ct or Cnil.  Could
that be the issue?

It would make REPL life a little easier if all of them returned values
at the REPL.  Any ideas?

------------------------------------------------------------------------------
Raymond Toy | 2 Jun 2010 00:21
Picon

(expt 2 #c(-2d0 -1d0)) is inaccurate

Although it seems the spec allows this, ecl produces an answer that only
has single-float accuracy for (expt 2 #c(-2d0 -1d0)).  I think the
issues arises because the result is computed as (exp (* #c(-2d0 -1d0)
(log 2))).  That (log 2) gives single-precision accuracy that is coerced
to double-float.

This issue causes some tests in maxima to fail.

(Should I use the bug tracker for this?)

Ray

------------------------------------------------------------------------------
Pascal J. Bourguignon | 2 Jun 2010 03:42
Face
Favicon

patch *translate-pathname-hook* Was: debugging ecl?

Juan Jose Garcia-Ripoll <juanjose.garciaripoll@...> writes:

> On Tue, Jun 1, 2010 at 10:51 AM, Pascal J. Bourguignon
<pjb@...> wrote:
>
>     Unfortunately, it seems that I wrote bugs, since build/ecl_min breaks
>     when I invoke the code I modified:
>
>     [pjb <at> kuiper :0.0 ecl]$ build/ecl_min
>     ;*** Lisp core booted ****
>     ECL (Embeddable Common Lisp)
>    
>     > (setf (logical-pathname-translations "TEST") '(("TEST:**;*.*" "/tmp/**/*.*")))
>
> Run it with
>
> $ cd build; ./ecl_min bare.lsp
>
> so that it loads the rest of Common Lisp first! Without the rest of
> the library you do not even have SETF and thus your statement does
> not work.

Thank you.  Indeed with the .gdbinit that's in build/ it's easier.

I couldn't load bare.lsp either because it does the very thing that
broke in error, but I could define a test logical host directly with:

(si::pathname-translations "TEST" `(("TEST:**;*.*.*" "/tmp/**/*.*")))

Anyways, a suggestion from Geo Carncross, and my preference with lisp
coding over C coding, made me implement a lighter and more general
solution, namely a hook in TRANSLATE-PATHNAME.

If the variable si:*translate-pathname-hook* is not NIL,
translate-pathname calls it with the source pathname, the from and to
pathnames, and three expected results are used in place of source,
from and to.

This allows me to implement the downcasing of logical pathnames as:

(setf SI:*TRANSLATE-PATHNAME-HOOK*
    (lambda (src from to)
       (when (and (typep src 'logical-pathname)
                  (or (not (pathname-directory src))
                      (every (lambda (item) (string= (string-upcase item) item))
                             (rest (pathname-directory src))))
                  (or (not (pathname-name src))
                      (string= (string-upcase (pathname-name src)) (pathname-name src)))
                  (or (not (pathname-type src))
                      (string= (string-upcase (pathname-type src)) (pathname-type src))))
         (setf src (make-pathname :defaults src
                                  :directory (when (pathname-directory src)
                                                 (cons (first (pathname-directory src))
                                                       (mapcar (function string-downcase)
                                                             (rest (pathname-directory src)))))
                                  :name (when (pathname-name src) (string-downcase (pathname-name src)))
                                  :type (when (pathname-type src) (string-downcase (pathname-type src))))))
      (values src from to)))

So that:

> (translate-logical-pathname "TEST:ABC;DEF;GHI.KL")

#P"/tmp/abc/def/ghi.kl"

> (translate-logical-pathname "TEST:Abc;Def;GHI.kl")

#P"/tmp/Abc/Def/GHI.kl"

Here is the patch:
----------------------------------------------------------------------
diff --git a/src/c/pathname.d b/src/c/pathname.d
index cf439ea..2cf6ed2 100644
--- a/src/c/pathname.d
+++ b/src/c/pathname.d
 <at>  <at>  -1580,6 +1580,12  <at>  <at>  copy_list_wildcards(cl_object *wilds, cl_object to)
 	/* The pattern which says what the output should look like */
 	to = cl_pathname(to);

+  if(!Null(ecl_symbol_value( <at> 'si::*translate-pathname-hook*'))){
+          source=funcall(4,ecl_symbol_value( <at> 'si::*translate-pathname-hook*'),source,from,to);
+          from=VALUES(1);
+          to=VALUES(2);
+  }    
+
 	if (source->pathname.logical != from->pathname.logical)
 		goto error;
 	out = ecl_alloc_object(t_pathname);
diff --git a/src/c/symbols_list.h b/src/c/symbols_list.h
index e1b3edf..5b3e765 100755
--- a/src/c/symbols_list.h
+++ b/src/c/symbols_list.h
 <at>  <at>  -1056,6 +1056,7  <at>  <at>  cl_symbols[] = {
 {SYS_ "*INTERRUPTS-ENABLED*", SI_SPECIAL, NULL, 1, Ct},
 {SYS_ "*KEEP-DEFINITIONS*", SI_SPECIAL, NULL, -1, Ct},
 {SYS_ "*LOAD-HOOKS*", SI_SPECIAL, NULL, -1, OBJNULL},
+{SYS_ "*TRANSLATE-PATHNAME-HOOK*", SI_SPECIAL, NULL, -1, Cnil},
 {SYS_ "*LOAD-SEARCH-LIST*", SI_SPECIAL, NULL, -1, Cnil},
 {SYS_ "*MAKE-CONSTANT", SI_ORDINARY, si_Xmake_constant, 2, OBJNULL},
 {SYS_ "*MAKE-SPECIAL", SI_ORDINARY, si_Xmake_special, 1, OBJNULL},
diff --git a/src/c/symbols_list2.h b/src/c/symbols_list2.h
index b7e00fb..b88284f 100755
--- a/src/c/symbols_list2.h
+++ b/src/c/symbols_list2.h
 <at>  <at>  -1056,6 +1056,7  <at>  <at>  cl_symbols[] = {
 {SYS_ "*INTERRUPTS-ENABLED*",NULL},
 {SYS_ "*KEEP-DEFINITIONS*",NULL},
 {SYS_ "*LOAD-HOOKS*",NULL},
+{SYS_ "*TRANSLATE-PATHNAME-HOOK*",NULL},
 {SYS_ "*LOAD-SEARCH-LIST*",NULL},
 {SYS_ "*MAKE-CONSTANT","si_Xmake_constant"},
 {SYS_ "*MAKE-SPECIAL","si_Xmake_special"},
diff --git a/src/lsp/iolib.lsp b/src/lsp/iolib.lsp
index 36c9e6e..3b8d76f 100644
--- a/src/lsp/iolib.lsp
+++ b/src/lsp/iolib.lsp
 <at>  <at>  -13,6 +13,14  <at>  <at> 

 (in-package "SYSTEM")

+(defvar *translate-pathname-hook* nil
+  "May be bound to a (FUNCTION (PATHNAME PATHNAME PATHNAME) (VALUES PATHNAME PATHNAME PATHNAME))
+that is called with the source pathname, the from wildcard and the to wildcard, and that must
+return three values, the new source, the new from and the new to, to be processed by TRANSLATE-PATHNAME
+instead.");; see translate-pathname in xpathname.d
+(export '*translate-pathname-hook*)
+
+
 (defmacro with-open-stream ((var stream) &rest body)
   "Syntax: (with-open-stream (var stream-form) {decl}* {form}*)
 Evaluates FORMs with VAR bound to the value of STREAM-FORM.  The stream is

----------------------------------------------------------------------

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

------------------------------------------------------------------------------
Gabriel Dos Reis | 2 Jun 2010 17:10

Re: Type propagation

On Fri, May 28, 2010 at 3:47 PM, Gabriel Dos Reis
<gdr@...> wrote:
> On Fri, May 28, 2010 at 3:37 PM, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll@...> wrote:
>> On Fri, May 28, 2010 at 10:28 PM, Gabriel Dos Reis
>> <gdr@...> wrote:
>>>
>>> Ok, thanks for the update!  I'll build OpenAxiom later and report
>>> whatever I found.
>>
>> One thing I have done is to implement more aggressive warnings about type
>> incompatibilities: when the type propagator finds that an argument to a
>> function does not have the expected type, it will issue a warning. Not a
>> style warning, but one that will force compilation to abort.
>> I did this to minimize the risk of wrong optimizations and also to detect
>> bugs in the proclamations and in the functions that do the guessing. I
>> already spotted a few problems thanks to this policy.
>> What I really want to say is just that OpenAxiom, Maxima and other large
>> programs might fail to build, ending with one of those warnings, even though
>> ECL swallowed them before.
>
> That is fine: I am on the side of loud failure than silent miscompilation.

I have to report a form of "regression" in an attempt to build SBCL with ecl.
The build failed much earlier with:

;;; Compiling src/code/defbangtype.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Compiling (DEFMACRO DEF!TYPE ...).
;;; Compiling (DEFVAR *DELAYED-DEF!TYPES* ...).
;;; Compiling (DEFUN FORCE-DELAYED-DEF!TYPES ...).
;;; End of Pass 1.
In function STRUCTURE-REF, the value of the first argument is
  NIL
which is not of the expected type C1FORM

Available restarts:

1. (ABORT) ABORT
2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SB-COLD::LOAD-OR-CLOAD-XCOMPILER.
 File: #P"/home/gdr/src/sbcl.cvs/src/cold/defun-load-or-cload-xcompiler.lisp"
(Position #NIL)
SB!KERNEL>>

I do not know whether this is due to the better checking, but I thought I should
report it.

-- Gaby

------------------------------------------------------------------------------
Pascal J. Bourguignon | 3 Jun 2010 02:50
Face
Favicon

generation of invalid C code (type cast)


When compiling raiden-decipher (from
http://git.informatimago.com/viewgit/?a=viewblob&p=public/lisp&h=728fe900a2cbf2a6dab2f7bbfcca92a6f36645a4&hb=5b22e7eab73f004ef00d478a119d5f4582174018&f=common-lisp/raiden.lisp
), ecl-10.4.2 (obtained from git yesterday) fails with:

;;; Emitting code for AUTO-TEST.
;;; Note:
;;;   Invoking external command:
;;;   gcc "-I/home/pjb/opt-planner-ecl/include/"  -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC 
-D_THREAD_SAFE -Dlinux -O -w -c
"/home/pjb/.fasls/ecl-10.4.2-linux-unknown/data/lisp/packages/com/informatimago/common-lisp/OBJ-ECL-1042-X86_64/raiden.c"
-o "/home/pjb/.fasls/ecl-10.4.2-linux-unknown/data/lisp/packages/com/informatimago/common-lisp/OBJ-ECL-1042-X86_64/raiden.o"
;;;
/home/pjb/.fasls/ecl-10.4.2-linux-unknown/data/lisp/packages/com/informatimago/common-lisp/OBJ-ECL-1042-X86_64/raiden.c:
In function
‘L4raiden_decipher’:
/home/pjb/.fasls/ecl-10.4.2-linux-unknown/data/lisp/packages/com/informatimago/common-lisp/OBJ-ECL-1042-X86_64/raiden.c:235:
error: lvalue required as left operand of assignment
[pjb <at> kuiper :0.0 lisp]$ 

The line 235 is:

	V10= ((cl_fixnum)(V6)->vector.self.b32[V11]= V12);}}

and the problem is that a typecast is not a lvalue.

The source expression is:

           (setf (aref sks i)
                 (setf (aref k (mod i 4))
                       (32bit (+ (aref k 0) (aref k 1)
                                 (logxor (+ (aref k 2) (aref k 3))
                                         (32bit (ash (aref k 0)
                                                     (mod (aref k 2) 32))))))))

The vectors are declared to contain (unsigned-bit 32) elements, and 
the host is a 64-bit linux:
Linux kuiper 2.6.32-xen-r1-nfs #6 SMP Tue May 18 23:25:57 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU 950  <at> 
3.07GHz GenuineIntel GNU/Linux

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Ecls-list mailing list
Ecls-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Marko Kocić | 3 Jun 2010 11:44
Picon

Slime compilation error

Latest changes to type-propagator seems to break slime. Here's the
excerpt from the log:

;;; Warning:
;;;   in file swank-arglists.lisp, position 35661
;;;   at (DEFMETHOD COMPUTE-ENRICHED-DECODED-ARGLIST ...)
;;;   ! The variable OPERATOR-FORM is not used.
;;; Warning:
;;;   in file swank-arglists.lisp, position 36307
;;;   at (DEFMETHOD COMPUTE-ENRICHED-DECODED-ARGLIST ...)
;;;   ! The variable OPERATOR-FORM is not used.
;;; Warning:
;;;   in file swank-arglists.lisp, position 41264
;;;   at (DEFMETHOD ARGLIST-DISPATCH ...)
;;;   ! The variable OPERATOR is not used.
;;; Warning:
;;;   in file swank-arglists.lisp, position 42437
;;;   at (DEFMETHOD ARGLIST-DISPATCH ...)
;;;   ! The variable OPERATOR is not used.
;;; Warning:
;;;   in file swank-arglists.lisp, position 53544
;;;   at (DEFGENERIC EXTRACT-LOCAL-OP-ARGLISTS ...)
;;;   ! The variable OPERATOR is not used.
;;; Warning:
;;;   in file swank-arglists.lisp, position 53544
;;;   at (DEFGENERIC EXTRACT-LOCAL-OP-ARGLISTS ...)
;;;   ! The variable OPERATOR is not used.
;;; Warning:
;;;   in file swank-arglists.lisp, position 53544
;;;   at (DEFGENERIC EXTRACT-LOCAL-OP-ARGLISTS ...)
;;;   ! The variable OPERATOR is not used.
;;; End of Pass 1.
;;; Note:
;;;   Refusing to propagate FUNCTION
;;; Note:
;;;   Refusing to propagate PSETQ
;;; Note:
;;;   Refusing to propagate FUNCALL
;;; Note:
;;;   Refusing to propagate C-INLINE
;;; Note:
;;;   Refusing to propagate LOAD-TIME-VALUE
;;; Note:
;;;   Refusing to propagate LOAD-TIME-VALUE
;;; Note:
;;;   Refusing to propagate C-INLINE
;;; Note:
;;;   Refusing to propagate FUNCTION
;;; Note:
;;;   Refusing to propagate FUNCTION
;;; Note:
;;;   Refusing to propagate FUNCTION
;;; Note:
;;;   Refusing to propagate RPLACD
;;; Note:
;;;   Refusing to propagate RPLACD
;;; Error:
;;;   * The argument 2 of function GETHASH has type
;;; NULL
;;; instead of expected
;;; HASH-TABLE;;
;; Error while compiling
/home/markko/.emacs.d/slime/contrib/swank-arglists.lisp:
;;   COMPILE-FILE returned NIL.
;; Aborting.
;;

Restart ABORT is not active.

Available restarts:

1. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SWANK-LOADER::HANDLE-SWANK-LOAD-ERROR. In: #<process
SI:TOP-LEVEL 0000000000743f60>.
 File: #P"/home/markko/cvstree/clbuild/source/slime/swank-loader.lisp"
(Position #NIL)
>>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Juan Jose Garcia-Ripoll | 3 Jun 2010 16:10

Re: Return values sometimes missing on REPL

On Tue, Jun 1, 2010 at 2:23 PM, Erik Winkels <aerique-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
I'm starting a REPL by doing this in C++:

   cl_object obj = ecl_read_from_cstring("si:top-level");
   cl_funcall(1, obj);

Now when calling functions that have been created with ecl_def_c_function
I almost never get the return value back at the REPL, but they are set
when I call the same function with setf or defparameter.  Like so:

   OGRE[1]> (get-actual-height *viewport*)

This toplevel does not seem to be the standard toplevel, for you have a different prompt, to begin with. Then, you are not showing the code of the functions you define and how they return multiple values. Most likely you are just using a "return only-value" statement and do not set the counter for the returned values, which is needed by ECL to know the number of returned values. If you look at toplevel.c, the compiled version of the toplevel you will see

cl_env_copy->values[0]=si_eval_with_env(2,ecl_symbol_value(ECL_SYM("-",15)),ecl_symbol_value(VV[2])) /*  EVAL-WITH-ENV */;
ecl_stack_frame_push_values(V1);cl_env_copy->values[0]=ecl_apply_from_stack_frame(V1,ECL_SYM("LIST",479));

this evaluates the form stored in the variable '-, saving the first value in the multiple values register and then copying the rest of values.

It would make REPL life a little easier if all of them returned values
at the REPL.  Any ideas?

More information. An ordinary REPL works just fine as shown in daily life. Obviously there is some problem with either the functions you define (not because of the way you defined them), or in the interface to those functions.

Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list

Gmane