Re: Status page

Juan Jose Garcia Ripoll wrote:

>>
>> > (require 'sockets)
>> ;;; Loading #P"/usr/local/lib/ecl/sockets.fas"
>> LOAD: Could not load file #P"/usr/local/lib/ecl/sockets.fas" (Error: 
>> "/usr/local/lib/ecl/sockets.fas: undefined symbol: ecl_symbol_slot")
>> Broken at LAMBDA. 
>
>
> This means you are using threads. 

What would be the right way to disable threads on Linux? I tried rebuilding
using  ./configure --disable-threads , unfortunately it gives me the 
same error.

Ury

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: How do I determine if *standard-input* is coming from an interactive terminal

On 6/30/05, Juan Jose Garcia Ripoll <jlr@...> wrote:
> William Bland wrote:
> 
> >I'm using ECLS to write some command-line unix programs, and I need to
> >determine if *standard-input* is coming from an interactive terminal,
> >e.g. someone said:
> >
> >$ myprogram arg1 ... argn
> >
> >or if *standard-input* is being redirected from a pipe or a file, e.g.
> >
> >$ myprogram arg1 ... argn < file
> >or
> >$ otherprogram | myprogram arg1 ... argn
> >
> INTERACTIVE-STREAM-P should be enough (See below). The problem is that
> the unix port was missing some code in the configuration to detect
> whether the C function which implements this functionality (isatty())
> exists. I am committing now a fix.
> 
> Juanjo
> 

Hi, thanks for the quick response.

Unfortunately the latest ecls from cvs returns NIL in both cases for
(interactive-stream-p *standard-input*) for me on Linux (Gentoo).  Any
suggestions?

Thanks again,

Latest changes

Hi,

a major reorganization of the compiler is taking place. Roughly, the old 
{K,G,E}CL lisp-to-C translators were designed as three layers, called 
T1, T2 and T3, which do

(T1) Process each top-level form and translate it into some internal 
representation (C1FORMs).

(T2) Process the C1FORMs, removing unreachable code and finally 
producing C/C++ code for each form.

(T3) Similar to T2, but for each of the local/global functions which 
were created in each of the toplevel forms.

The major problem is that, as you see, everything is organized around 
the notion of toplevel form. For each of these, there is a processing 
function which compiles it. However, many of the lisp forms can appear 
both as toplevel and non-toplevel: for instance PROGN, SYMBOL-MACROLET, 
or even DEFUN. This leads to a horrible duplication of code and with 
time it has meant that the improvements for non-toplevel forms have not 
been propagated to the toplevel compiler.

Right now I am working on reorganizing/redesigning the compiler so that 
there is no notion of toplevel form, but just of lisp form. The idea is 
that in a near future you will be able to write code as follows

    (with-compiler-environment
       ;; Process all forms into C1 intermediate representation
       (let* ((*compile-toplevel* 'T))

CFFI

Hi,

just in case somebody is interesting, there is a lot of development 
around a new FFI called CFFI. It is based on a very minimalistic API 
which provides enough functionality to create CLOS classes for the 
foreign data and even a UFFI compatibility layer

    http://common-lisp.net/project/cffi/

The focus is on performance, with lots of operations (memory copying, 
for instance; raw pointer operations; etc) which are missing in UFFI.

The funny thing is that the low-level API from CFFI is so similar to 
ECL's that it has been quickly ported to our lisp. Also, in case further 
development happens along this line (for instance Kenny Tilton's Hello-C 
mentored project), it would be very easy to replace ECL's UFFI 
compatibility layer with the full power of CFFI.

Regards,

    Juanjo

ecl-0.9f

Hello,

I have enjoyed using ecl on my linux box, and now I'm
trying to install it on my sparc solaris machine. I
get the attached error message during 'make'. Does
anyone know how I can fix this?

Thanks,

Eric

In file included from /usr/include/sys/signal.h:34,
                 from /usr/include/signal.h:26,
                 from /home/eric/ecl-0.9f/src/gc/alloc.c:23:
/usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:292: error: parse error before '}' token
/usr/include/sys/siginfo.h:294: error: parse error before '}' token
/usr/include/sys/siginfo.h:390: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'
/usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'
/usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'
/usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'
/usr/include/sys/siginfo.h:404: error: conflicting types for `__file'
/usr/include/sys/siginfo.h:273: error: previous declaration of `__file'
/usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'
/usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'
/usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'
/usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'
/usr/include/sys/siginfo.h:426: error: parse error before '}' token

Re: How do I determine if *standard-input* is coming from an interactive terminal

On Sat, 2005-07-02 at 06:41 -0700, William Bland wrote:
> Unfortunately the latest ecls from cvs returns NIL in both cases for
> (interactive-stream-p *standard-input*) for me on Linux (Gentoo).  Any
> suggestions?

Sorry, I forgot to commit one of the patches (src/c/file.d). It should
work now.

Juanjo

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: ecl-0.9f

On Wed, 2005-07-06 at 15:16 -0700, Eric wrote:
> I have enjoyed using ecl on my linux box, and now I'm
> trying to install it on my sparc solaris machine. I
> get the attached error message during 'make'. Does
> anyone know how I can fix this?

> In file included from /usr/include/sys/signal.h:34,
>                  from /usr/include/signal.h:26,
>                  from /home/eric/ecl-0.9f/src/gc/alloc.c:23:
> /usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
> /usr/include/sys/siginfo.h:292: error: parse error before '}' token
> /usr/include/sys/siginfo.h:294: error: parse error before '}' token
> [...]

This seems to be a bug in the Boehm-Weiser garbage collector. Could you
try building the CVS tree? It has a newer version of the library, which
solves many fixes.

I also need help with this port. All machines I have in Sourceforge are
64 bits and it seems that the configuration process is failing to detect
the flags for compiling the whole of ECL in 64 bit mode. Currently ECL
relies on the GMP library for that. It would be nice if somebody fixed
this.

Regards,

Juanjo

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening

Re: How do I determine if *standard-input* is coming from an interactive terminal

On 7/8/05, Juan Jose Garcia Ripoll <jlr@...> wrote:
> On Sat, 2005-07-02 at 06:41 -0700, William Bland wrote:
> > Unfortunately the latest ecls from cvs returns NIL in both cases for
> > (interactive-stream-p *standard-input*) for me on Linux (Gentoo).  Any
> > suggestions?
> 
> Sorry, I forgot to commit one of the patches (src/c/file.d). It should
> work now.
> 

Thanks Juanjo.

Unfortunately CVS still shows the last commit date on that file as
being six weeks ago:

http://cvs.sourceforge.net/viewcvs.py/ecls/ecls/src/c/

Am I looking at the wrong CVS repository or something?

Best wishes,
Bill.

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: How do I determine if *standard-input* is coming from an interactive terminal

On 7/8/05, William Bland <doctorbill@...> wrote:
> On 7/8/05, Juan Jose Garcia Ripoll <jlr@...> wrote:
> > On Sat, 2005-07-02 at 06:41 -0700, William Bland wrote:
> > > Unfortunately the latest ecls from cvs returns NIL in both cases for
> > > (interactive-stream-p *standard-input*) for me on Linux (Gentoo).  Any
> > > suggestions?
> >
> > Sorry, I forgot to commit one of the patches (src/c/file.d). It should
> > work now.
> >
> 
> Thanks Juanjo.
> 
> Unfortunately CVS still shows the last commit date on that file as
> being six weeks ago:
> 
> http://cvs.sourceforge.net/viewcvs.py/ecls/ecls/src/c/
> 
> Am I looking at the wrong CVS repository or something?
> 
> Best wishes,
> Bill.
> 

Perhaps I was lagging behind the current CVS in some way.  I've
re-checked out the tree and can confirm that INTERACTIVE-STREAM-P now
does exactly the right thing for me.

Thanks again for your help.

ecl binary for sparc solaris10

Does anyone have an ecl binary for sparc solaris10?

Thanks!

Eric

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar