Juan Jose Garcia-Ripoll | 2 Aug 2007 22:24
Picon

Re: Very strange problem loading cmp.fsl

The error below has been hopefully solved. It was made of two problems:

1) When *read-suppress* was not nil, the package of a symbol might not
be ignored.

2) When loading a binary file, ECL creates a list of packages that
appear in interned constants and waits for the program to create them.
This list should be emptied after loading that file, but it was not
always so.

Both problems combined in the bug report that Dan sent. Sorry for the
big delay -- it was not easy to find out the real problem.

Juanjo

2007/1/27, Dan Corkill <corkill@...>:
> This bug has been around for a while (so it's not related to the recent
> sets of CVS changes), but until recently I didn't have time to whittle
> it down to a simple case.  It is a very strange bug, as it is triggered
> by conditional input lines that should be ignored by ECL!
>
> Here goes:
>
> $ ecl -norc
> ECL (Embeddable Common-Lisp) 0.9i
> 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.
(Continue reading)

Juan Jose Garcia-Ripoll | 4 Aug 2007 15:28
Picon

Re: trouble with si:load-foreign-module

I am sorry for the delay on solving this problem. I have just found
out that there was no lisp builtin type associated to the dynamically
loaded libraries. I mean that there was a data structure, but it had
no name that was known to functions like class-of, type-of, etc.

This is fixed in CVS now.

Juanjo

2007/4/17, Luis Oliveira <luismbo <at> gmail.com>:
> Hello,
>
> While trying to bring CFFI's ECL backend up to date, I stumbled across a
> crash caused by trying to place the result si:load-foreign-module in a
> CLOS slot.
>
>   > (defclass foo () ((x :initarg :x)))
>   #<The STANDARD-CLASS FOO>
>   > (make-instance 'foo :x (si:load-foreign-module "/usr/lib/libz.so"))
>
>   Internal or unrecoverable error in:
>   not a lisp data object
>   Aborted
>
> Doing the same thing with, e.g., a struct works fine but whenever I try
> to put a "codeblock" object in a CLOS slot, ECL gets upset.  This
> happens with latest CVS, running on linux/x86-64.  HTH.
>
> --
> Luís Oliveira
(Continue reading)

Juan Jose Garcia-Ripoll | 4 Aug 2007 15:55
Picon

Re: C compiler errors during compile-file

The piece of code below failed to be compiled by ECL because of a
missing C declaration in the output file. Fixed in CVS.

Juanjo

(defvar *ls* nil)

(let ((*ls* '(1 2 3 4 5 6 7)))
 (let ((the-list (cons nil *ls*)))
   (let ((prev the-list))
     (flet ((cut () (let (kill)
              (setf kill (cdr prev)
                    (cdr prev) (cdr kill)
                    prev (cons nil prev)))))
       (cut)
     (format t "~S" the-list)))))

--

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
martin | 9 Aug 2007 20:27

CL-ncurses

Has anyone used this with ECL? I need some basic terminal functionality
like user selectable menus. Tried loading cl-ncurses it and got a bunch 
of errors, and there's nothing in the mail archives..

TIA

!DSPAM:1890,46bb5c8777691290541531!

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Juan Jose Garcia-Ripoll | 9 Aug 2007 22:59
Picon

Re: CL-ncurses

Hi Martin,

I just made some changes to ECL right now, solving some problems such
as a missing DEF-CONSTANT macro from the UFFI package. This and the
patch to cl-ncurses which I attach are enough to compile and load
cl-ncurses using ECL, but I did not try whether it works at all.

Juanjo

2007/8/9, martin@... <martin@...>:
> Has anyone used this with ECL? I need some basic terminal functionality
> like user selectable menus. Tried loading cl-ncurses it and got a bunch
> of errors, and there's nothing in the mail archives..
>
> TIA

--

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Juan Jose Garcia-Ripoll | 9 Aug 2007 23:00
Picon

Re: CL-ncurses

The promised file is attached.

2007/8/9, Juan Jose Garcia-Ripoll <jjgarcia@...>:
> Hi Martin,
>
> I just made some changes to ECL right now, solving some problems such
> as a missing DEF-CONSTANT macro from the UFFI package. This and the
> patch to cl-ncurses which I attach are enough to compile and load
> cl-ncurses using ECL, but I did not try whether it works at all.
>
> Juanjo
>
>
> 2007/8/9, martin@... <martin@...>:
> > Has anyone used this with ECL? I need some basic terminal functionality
> > like user selectable menus. Tried loading cl-ncurses it and got a bunch
> > of errors, and there's nothing in the mail archives..
> >
> > TIA
>
> --
> Facultad de Fisicas, Universidad Complutense,
> Ciudad Universitaria s/n Madrid 28040 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>

--

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com
(Continue reading)

martin | 10 Aug 2007 01:24

building on OpenBSD again..

Am having problems building on OpenBSD right now with the following 
build script (and have tried building both with included and system
boehm-gc and gmp). I do have a working ECL from August 1st so 
something has changed since then affecting the build.

#!/bin/ksh
CFLAGS="-I/usr/local/include/ -I/usr/local/include/gc/"
LDFLAGS="-L/usr/local/lib/"
export CFLAGS LDFLAGS
./configure --enable-boehm=system --prefix=/usr/local/

Switching to directory `build' to continue configuration.
checking build system type... pentium4-unknown-openbsd4.2
checking host system type... pentium4-unknown-openbsd4.2
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
(Continue reading)

Brian Spilsbury | 18 Aug 2007 21:38
Picon

experimental patch for review (unboxed functions and some misc socket fixes)

Hello,

Yesterday I thought that I'd have another go and unboxed functions.
This is the result. It seems a lot cleaner than before, and seems to
work nicely.

There is one big issue, which is how to deal with boxed and unboxed
versions of the same function.

In this patch, I'm using a rather ugly hack to bind the boxed version
as an anonymous function directly to the symbol-function of the name,
and ignoring (setf ...) functions -- this is not a viable approach,
but it should be sufficient to test and verify the meat of the
compiler changes.

I think that it would probably be better to have the boxed version as
the primary function, and to use a property to refer direct calls to a
different function. This would also allow the unboxed interface to
have a specific C name.

When I produced this cvs diff I also noticed two other changes that I
had forgotten about, but they're small, so I've left them in.

When using sockets, I found that short reads weren't being handled
properly -- also the built-in socket server code was leaking
descriptors.

Regards,
Brian.

(Continue reading)

Steve Smith | 19 Aug 2007 06:14
Favicon

Problems with clines

Hi,

Can someone tell me what is wrong with the following:

  (defpackage "select-test"
    (:use "CL" "FFI"))
    (in-package "select-test")

  (clines "#include <sys/select.h>")

  (defun test-fun ()
    (clines "fd_set read_fds, write_fds;"
            "FD_ZERO(&read_fds);"
            "FD_ZERO(&write_fds);")
    ;; ....
    ;; Some other code resulting in an fd, but we'll use stdin here
    ;; ....
    (c-inline (fd) (:int) :void 
              "FD_SET(#0, &read_fds);"
              :one-liner nil
              :side-effects t))

Compiling this fails with errors, as all the 'clines' code is placed
into the header rather than inline.  Is this deliberate?

Converting the clines to c-inline fixes this issue but raises another
one; the resulting C source ends up like:

    static cl_object L1test_fun()
    { VT2 VLEX2 CLSR2
(Continue reading)

Juan Jose Garcia-Ripoll | 19 Aug 2007 09:38
Picon

Re: experimental patch for review (unboxed functions and some misc socket fixes)

Hi Brian,

thanks for the patch. I will review in the coming days, though I
cannot promise how long it will take until I incorporate the patches.

2007/8/18, Brian Spilsbury <brian.spilsbury@...>:
> Hello,
> I think that it would probably be better to have the boxed version as
> the primary function, and to use a property to refer direct calls to a
> different function. This would also allow the unboxed interface to
> have a specific C name.

Yes, that is more reasonable.

> When using sockets, I found that short reads weren't being handled
> properly -- also the built-in socket server code was leaking
> descriptors.

Can you be more specific about this? Is this related to the sb-sockets code?

Juanjo

--

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
(Continue reading)


Gmane