Embeddable Common-Lisp

On Mon, Mar 17, 2008 at 12:53 PM, Juan Jose Garcia-Ripoll
<jjgarcia@...> wrote:
>  The change of package name, which is essential to provide the generic
>  functions, might break code that imported these classes from the EXT
>  package.

SLIME did this. I added the following to swank-ecl which seems to work:

(if (find-package :gray)
  (import-from :gray *gray-stream-symbols* :swank-backend)
  (import-from :ext *gray-stream-symbols* :swank-backend))

now SLIME works again with ecl...

On Wed, Mar 19, 2008 at 3:35 AM, Geo Carncross <geocar@...> wrote:
> On Mon, Mar 17, 2008 at 12:53 PM, Juan Jose Garcia-Ripoll
>  <jjgarcia@...> wrote:
>  >  The change of package name, which is essential to provide the generic
>  >  functions, might break code that imported these classes from the EXT
>  >  package.
>
>  SLIME did this. I added the following to swank-ecl which seems to work:

Thanks! Did you commit these changes to slime? I think I have a
developer account, but have not used in more than one year.

Juanjo

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

"Juan Jose Garcia-Ripoll" writes:

> On Wed, Mar 19, 2008 at 3:35 AM, Geo Carncross wrote:
> 
> >  SLIME did this. I added the following to swank-ecl which seems to work:
>
> Thanks! Did you commit these changes to slime? I think I have a
> developer account, but have not used in more than one year.

Out of interest, how do you use ECL?

  -T.

On Wed, Mar 19, 2008 at 11:06 AM, Tobias C. Rittweiler <tcr@...> wrote:
>  Out of interest, how do you use ECL?

I develop noninteractively in emacs. I write my programs and they
normally just run :-) I use it mostly for prototyping mathematical and
programming algorithms I need at work, simple scripting and cron jobs,
and CGI scripting in one very simple case.

Development of ECL itself is also done without slime/ilisp/etc. And it
has to be so, because most of the time I am working with an incomplete
image or a broken executable that I have to run inside GDB.

Juanjo

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

On 3/19/08, Juan Jose Garcia-Ripoll <jjgarcia@...> wrote:
> On Wed, Mar 19, 2008 at 11:06 AM, Tobias C. Rittweiler <tcr@...> wrote:
> >  Out of interest, how do you use ECL?
>
> I develop noninteractively in emacs. I write my programs and they
> normally just run :-) I use it mostly for prototyping mathematical and
> programming algorithms I need at work, simple scripting and cron jobs,
> and CGI scripting in one very simple case.
>
> Development of ECL itself is also done without slime/ilisp/etc. And it
> has to be so, because most of the time I am working with an incomplete
> image or a broken executable that I have to run inside GDB.

You are aware there's a debugging mode in Emacs which interacts with
gdb? I must say I didn't use it for a long time, expecting very little
of it, but when I started using it, I found that having the 'execution
pointer' in C sources really adds clarity.

Bye,

Erik.

On Wed, Mar 19, 2008 at 11:20 AM, Erik Huelsmann <ehuels@...> wrote:
>  You are aware there's a debugging mode in Emacs which interacts with
>  gdb? I must say I didn't use it for a long time, expecting very little
>  of it, but when I started using it, I found that having the 'execution
>  pointer' in C sources really adds clarity.

Oh, yes, I get that far :-) At some point I was even using the five
windows display, but I went back to two windows and C-c C-n to jump to
the next line etc, etc. I only miss some scripting languange in GDB,
so that for instance I can write functions (CDR, CAR, etc) that help
me in debugging ECL.

Juanjo

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

On 3/19/08, Juan Jose Garcia-Ripoll <jjgarcia@...> wrote:
> On Wed, Mar 19, 2008 at 11:20 AM, Erik Huelsmann <ehuels@...> wrote:
> >  You are aware there's a debugging mode in Emacs which interacts with
> >  gdb? I must say I didn't use it for a long time, expecting very little
> >  of it, but when I started using it, I found that having the 'execution
> >  pointer' in C sources really adds clarity.
>
> Oh, yes, I get that far :-) At some point I was even using the five
> windows display, but I went back to two windows and C-c C-n to jump to
> the next line etc, etc. I only miss some scripting languange in GDB,
> so that for instance I can write functions (CDR, CAR, etc) that help
> me in debugging ECL.

You mean like "Canned sequences of commands"
(http://sourceware.org/gdb/current/onlinedocs/gdb_21.html#SEC229) ?


Bye,

Erik.

On Wed, Mar 19, 2008 at 11:48 AM, Erik Huelsmann <ehuels@...> wrote:
>  You mean like "Canned sequences of commands"
>  (http://sourceware.org/gdb/current/onlinedocs/gdb_21.html#SEC229) ?

Hmm, that is not exactly what I have in mind, though it helps. What
GDB would really need is some programming abilities and macros. Those
are just chained commands, AFAI can tell. But there is currently no
way (correct me if I am wrong), that given a C expression, such as
x->cons.car, I can build another one, x->cons.car->cons.cdr, etc, etc.
Hey, maybe ECL has a niche here, or maybe one can just teach Emacs to
reparse one's commands.

Cheers,

Juanjo

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

On Wed, Mar 19, 2008 at 4:22 AM, Juan Jose Garcia-Ripoll
<jjgarcia@...> wrote:
> On Wed, Mar 19, 2008 at 3:35 AM, Geo Carncross <geocar@...> wrote:
>  > On Mon, Mar 17, 2008 at 12:53 PM, Juan Jose Garcia-Ripoll
>  >  <jjgarcia@...> wrote:
>  >  >  The change of package name, which is essential to provide the generic
>  >  >  functions, might break code that imported these classes from the EXT
>  >  >  package.
>  >
>  >  SLIME did this. I added the following to swank-ecl which seems to work:
>
>  Thanks! Did you commit these changes to slime?

Yes.

Hello Juanjo,

<jjgarcia@...> writes:

> On Wed, Mar 19, 2008 at 11:48 AM, Erik Huelsmann <ehuels@...> wrote:
>>  You mean like "Canned sequences of commands"
>>  (http://sourceware.org/gdb/current/onlinedocs/gdb_21.html#SEC229) ?
>
> Hmm, that is not exactly what I have in mind, though it helps. What
> GDB would really need is some programming abilities and macros. Those
> are just chained commands, AFAI can tell. But there is currently no
> way (correct me if I am wrong), that given a C expression, such as
> x->cons.car, I can build another one, x->cons.car->cons.cdr, etc, etc.
> Hey, maybe ECL has a niche here, or maybe one can just teach Emacs to
> reparse one's commands.

Emacs' source (at least the CVS version) comes with a .gdbinit in the
"src" directory which might contain some inspiring macros for a
specialized .gdbinit for ECL. Those "canned sequences" look pretty
primitive, but you get quite far with them.


Regards,

Marco

>   - Gray streams are now implemented in a separate package, called GRAY, which
>    exports symbols such as FUNDAMENTAL-STREAM or STREAM-READ-CHAR.
>
>   - The functions CLOSE, {OPEN,INPUT,OUTPUT}-STREAM-P, STREAM-P and
>    STREAM-ELEMENT-TYPE are now offered in two flavors. The versions exported by
>    the COMMON-LISP package are ordinary functions, the versions in the GRAY
>    package are generic functions that can be specialized to new classes. The
>    ordinary functions will invoke the generic version when passed a generic
>    stream. Note that, for instance, CL:CLOSE and GRAY:CLOSE are not the same
>    symbol. This means you might need to shadow-import the symbols associated to
>    generic versions in the packages where methods on these functions are
>    defined.

Is this going to be that way in future versions of ECL, or will these
symbols in CL: be replaced by the generics someday (which would make
it much more compatible with most other CL-Implementations)?

On Sun, Mar 30, 2008 at 5:00 PM, css <css@...> wrote:
>  >   - The functions CLOSE, {OPEN,INPUT,OUTPUT}-STREAM-P, STREAM-P and
>  >    STREAM-ELEMENT-TYPE are now offered in two flavors. The versions exported by
>  >    the COMMON-LISP package are ordinary functions, the versions in the GRAY
>  >    package are generic functions that can be specialized to new classes.[...]
>
>  Is this going to be that way in future versions of ECL, or will these
>  symbols in CL: be replaced by the generics someday (which would make
>  it much more compatible with most other CL-Implementations)?

Two powerful reasons favor the ordinary functions approach: speed and
size of compiled code that invokes these functions and strict adoption
of the standard. It will remain so until somebody convinces me that
the contrary is better.

Juanjo

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

>  Two powerful reasons favor the ordinary functions approach: speed and
>  size of compiled code that invokes these functions and strict adoption
>  of the standard. It will remain so until somebody convinces me that
>  the contrary is better.

It's a fair compromise, but you could make it transparantly selected
by the following method.

If you were to rename the COMMON-LISP package to the ECL-CL package
(or whatever), and then place a COMMON-LISP package which used this,
then you could control what other packages receive when they use
COMMON-LISP:CLOSE (for example), and GRAY:CLOSE could still use
ECL-CL:CLOSE for its default case.

I suspect that that might involve changing a lot of strings, though. :)

A cheaper option for the implementor is for the user to shadowing
import gray:close, etc into each package which wants to use it.

Regards,
Brian.

On Mon, Mar 31, 2008 at 6:40 AM, Brian Spilsbury
<brian.spilsbury@...> wrote:
>  If you were to rename the COMMON-LISP package to the ECL-CL package
>  (or whatever), and then place a COMMON-LISP package which used this,
>  then you could control what other packages receive when they use
>  COMMON-LISP:CLOSE (for example), and GRAY:CLOSE could still use
>  ECL-CL:CLOSE for its default case.

My brain must be a bit dense today, but I miss the point. GRAY:CLOSE
only has to be used when defining a method that specializes CLOSE. The
user is free to use CL:CLOSE on a Gray stream: it will simply work.
Let me illustrate it:

(defclass my-stream (fundamental-character-input-stream)
  ((a-stream :initarg :stream)))

(defmethod gray:close (stream &key abort)
  (close (slot-value stream 'a-stream) :abort abort))

(let ((a (make-instance 'my-stream :stream (open "foo.txt" :direction :input))))
  ...
 (close a)) ; Here, GRAY:CLOSE would also work

Notice that the standard function will work on your stream if you have
specialized the Gray generic function for it. Similarly for
STREAM-ELEMENT-TYPE and other functions. The important point is that
the standard functions only perform a method dispatch when the
argument is a CLOS object, thus avoiding this expesive process for
ordinary streams.

>  I suspect that that might involve changing a lot of strings, though. :)

More than that, it changes the home package of a standard symbol.

>  A cheaper option for the implementor is for the user to shadowing
>  import gray:close, etc into each package which wants to use it.

This is what I intended to write in the changelog, but probably I was
not clear enough.

Juanjo

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

I have introduce a change that might make someone's life easier. The
GRAY package now reexports all public symbols in COMMON-LISP, so that
if you want to use the generic functions CLOSE, STREAM-ELEMENT-TYPE,
STREAMP, etc, you can just use the GRAY package and not use CL.

Juanjo

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