headers
Robert Lehr | 1 Nov 2003 18:23

v0.9c => problem with compiled source

I am currently trying to fix a problem with lisp files compiled with
v0.9c. Both files use the same work in the same package.

I receive this error

    bozzio $ ecl  
    ECL (Embeddable Common-Lisp) 0.9c
    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.
    > (load "b")
    ;;; Loading "b.fas"
    ;;; Loading "a.fas"
    loading/compiling a: package => #<COMMON-LISP-USER package>,
    (("A" . #<"A" package>)) is not of type CHARACTER.
    Broken at LOAD.
    A>> 

after doing this

    bozzio $ ecl -compile a
    ;;; Loading "/usr/lib/ecl/cmp.fas"
    ;;; Warning: PROCLAIM is being redefined.
    ;;; Warning: COMPILE-FILE-PATHNAME is being redefined.
    ;;; Warning: COMPILE-FILE is being redefined.
    ;;; Warning: COMPILE is being redefined.
    ;;; Warning: DISASSEMBLE is being redefined.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Juan Jose Garcia-Ripoll | 3 Nov 2003 10:46
Picon

Re: v0.9c => problem with compiled source

On Saturday 01 November 2003 18:23, Robert Lehr wrote:
> I am currently trying to fix a problem with lisp files compiled with
> v0.9c. Both files use the same work in the same package.
>     ===> in a.lsp
>         (defpackage #:a (:use #:cl))
>
>     ===> in b.lsp
>         (eval-when (:compile-toplevel :load-toplevel :execute)
>           (load "a"))
>         (in-package #:a)
>         (defun asd (a) nil)

Fixed. This was a problem of the new way packages are handled by binary files: 
When you load "b.lsp", the symbol ASD is read in the not-yet-existent package 
A. This package is stored on a list of packages to be created, and later on 
eliminated from this list when "a.lsp" creates the package. Due to a 
misdesign of the routines which are responsible for this, the package was not 
entirely removed, and an error message produced.

Juanjo

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Permalink | Reply | 1 comment |
headers
Julian St. | 3 Nov 2003 17:05
Picon

New manual page

Hello,

as you may have noticed, the man page supplied is slighty *cough*
outdated. I tried my best to write a new one, with information available
in the documentation, homepage, sourcecode.

It's attached. Don't beat me, it's the first I've ever written. :)

Regards,
Julian
--

-- 
		 You hold 'em off, I'll go for help.
Attachment (ecl.1): application/octet-stream, 2646 bytes
Permalink | Reply | 3 comments |
headers
Julian St. | 3 Nov 2003 18:18
Picon

Re: New manual page

On Mon, 3 Nov 2003 17:05:19 +0100
"Julian St." <der_julian@...> wrote:

> It's attached. Don't beat me, it's the first I've ever written. :)

Sorry, for the MIME type. But btw, what are the other files in src/etc/
good for? It looks as there is no need for ecl.sh, ecl.csh and ecls.1
anymore.

Regards,
Julian
--

-- 
	  Alone in a bank at night is a pleasant experience.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Permalink | Reply | 1 comment |
headers
Juan Jose Garcia-Ripoll | 3 Nov 2003 18:25
Picon

Re: New manual page

On Monday 03 November 2003 18:18, Julian St. wrote:
> On Mon, 3 Nov 2003 17:05:19 +0100
>
> "Julian St." <der_julian@...> wrote:
> > It's attached. Don't beat me, it's the first I've ever written. :)

Thansk for the manual page! I had completely forgotten about it :-)

> Sorry, for the MIME type. But btw, what are the other files in src/etc/
> good for? It looks as there is no need for ecl.sh, ecl.csh and ecls.1
> anymore.

Yes, they are not used at all, and the manual page should probably reside with 
the documentation in src/doc/.

Juanjo

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Permalink | Reply | 0 comments |
headers
Robert Lehr | 3 Nov 2003 19:59

Re: v0.9c => problem with compiled source

On Mon, Nov 03, 2003 at 10:46:40AM +0100, Juan Jose Garcia-Ripoll wrote:
> On Saturday 01 November 2003 18:23, Robert Lehr wrote:
> > I am currently trying to fix a problem with lisp files compiled with
> > v0.9c. Both files use the same work in the same package.
> >     ===> in a.lsp
> >         (defpackage #:a (:use #:cl))
> >
> >     ===> in b.lsp
> >         (eval-when (:compile-toplevel :load-toplevel :execute)
> >           (load "a"))
> >         (in-package #:a)
> >         (defun asd (a) nil)
> 
> Fixed. This was a problem of the new way packages are handled by binary files: 
> When you load "b.lsp", the symbol ASD is read in the not-yet-existent package 
> A. This package is stored on a list of packages to be created, and later on 
> eliminated from this list when "a.lsp" creates the package. Due to a 
> misdesign of the routines which are responsible for this, the package was not 
> entirely removed, and an error message produced.

Thank you for the rapid response, Juan.  I confirmed that your fix works.

--

-- 

Robert Lehr
bozzio@...

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian St. | 3 Nov 2003 21:07
Picon

FreeBSD port

Hello again,

I would like to add ECL to the FreeBSD ports tree at the next release.
For that to work ECL should compile out-of-the-box with libgmp and libgc
from the ports tree. Lisp support on FreeBSD is growing and I think
this would attract some experienced people.

The following issues stand in the way:

I. GMP

./configure --enable-local-gmp
...
gmake
...

if [ -f CROSS-COMPILER ]; then \
        touch ecl_min; \
else \
        gcc  -o ecl_min c/cinit.o -L./ libecl.a -lgmp libgc.a -lgmp 
-lm;\ fi
/usr/bin/ld: cannot find -lgmp
gmake[1]: *** [ecl_min] Fehler 1

So I add some info for configure...

env LDFLAGS='-L/usr/local/lib' ./configure --enable-local-gmp
...
gmake
...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Topp | 4 Nov 2003 11:40
Picon

Re: Examples of successful integration in applications.


Robert Lehr wrote:
| Juan, et. al.,
|
| Is anybody actually using ECL?  What applications are being written
with it?
| Besides unicorp (http://unicorp.sourceforge.net/).  Even on that
project, ECL
| integration seems to be in a holding-pattern.
|
| Does anybody have any examples that they can share?  Since the
documentation is
| so sparse, they would be more useful if some examples of successful
integration
| of ECL into pre-existing or new applications were available.
|
| The actual ECL code does not actually use much of the documented API.
  The CLX
| and pvm code that is included is outdated.  Some of the more commonly used
| functions are not documented.  I have in mind, some functions
discussed on the
| mailing list, like cl_def_c_function_va(), e.g.,
|
|
http://sourceforge.net/mailarchive/forum.php?thread_id=2546679&forum_id=1307
|
| and others used in ECL and unicorp code.
|
| I would contribute some myself.  But I am having too much trouble
conjuring a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 4 Nov 2003 17:11
Picon

Re: New manual page

On Monday 03 November 2003 17:05, Julian St. wrote:
> Hello,
>
> as you may have noticed, the man page supplied is slighty *cough*
> outdated. I tried my best to write a new one, with information available
> in the documentation, homepage, sourcecode.

The man page is very good: concise and full of information. I have only added 
an undocumented option -shell, which is used for shell scripting, like in
	#!/home/juanjo/bin/ecl -shell
	(print "This is my first lisp script")
and the option -norc, which prevents loading ~/.ecl or ~/.eclrc at the 
beginning (-shell automatically sets -norc). I hope that people will find 
both of them useful.

Regards,

Juanjo

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 4 Nov 2003 17:27
Picon

Re: FreeBSD port

On Monday 03 November 2003 21:07, Julian St. wrote:
> I would like to add ECL to the FreeBSD ports tree at the next release.
> For that to work ECL should compile out-of-the-box with libgmp and libgc
> from the ports tree. Lisp support on FreeBSD is growing and I think
> this would attract some experienced people.

Thanks for your effort. I am a great fan of *BSD. In Spain my main box was a 
NetBSD, and afterwards I used a FreeBSD. I only stopped using FreeBSD because 
at work we require AFS.

> The following issues stand in the way:
>
> I. GMP
> env LDFLAGS='-L/usr/local/lib' ./configure --enable-local-gmp
> "gcc -shared -o libecl.so -L/usr/home/blitz/src/ecls/build/ c/main.o
> libecl.a -lgc -lgmp --no-undefined  -lgmp  -lm"/usr/bin/ld: cannot find
> -lgmp LAMBDA: Too many arguments to function CONTINUE.

This is a bug. The LDFLAGS you passed are not being used.

> II. Garbage Collector
> env CFLAGS="-I/usr/local/include" ./configure --enable-local-boehm
> ...
> gmake
> ...
> gcc -c -I../h -I/usr/home/blitz/src/ecls/src/c
> -I/usr/home/blitz/src/ecls/src/h  -I/usr/local/include -Dfreebsd -fPIC
> -fstrict-aliasing -o alloc_2.o
> alloc_2.c/usr/home/blitz/src/ecls/src/c/alloc_2.d:18:29:
> private/gc_priv.h: No such file or directory
(Continue reading)

Permalink | Reply | 0 comments |

Gmane