Menu
▾
▴
ilisp-devel — This is the list for discussion on the developement of ILISP.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(25) |
Feb
(13) |
Mar
(8) |
Apr
(20) |
May
(24) |
Jun
(12) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(20) |
Nov
(35) |
Dec
(27) |
| 2002 |
Jan
(17) |
Feb
(25) |
Mar
(16) |
Apr
(3) |
May
(35) |
Jun
(35) |
Jul
(10) |
Aug
(23) |
Sep
(23) |
Oct
(16) |
Nov
(31) |
Dec
(7) |
| 2003 |
Jan
(8) |
Feb
(12) |
Mar
(6) |
Apr
(28) |
May
(52) |
Jun
(12) |
Jul
(18) |
Aug
(3) |
Sep
(3) |
Oct
(11) |
Nov
(31) |
Dec
(31) |
| 2004 |
Jan
(4) |
Feb
(2) |
Mar
(5) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Brian M. <bma...@cs...> - 2003-11-28 03:44:12
|
On Nov 27, 2003, at 1:31 AM, Bil...@pe... wrote: > 2. Effort is put into creating more complete LEP implementations for > different CL's so that ELI can be used effectively on multiple CL > implementations. The benefit of this option is that ELI is very > full-featured as it is and just the port of the underlying > communication > layer would need to be done. Also, since the largest commercial CL > vendor > supports ELI and actively enhances it, we can take advantage of both > commercial and open source development efforts. As far as I understand it, LEP won't work on non-threaded lisps, which means there will always be room for a solution that doesn't require threading. Of course taking advantage of it where present is great, but right now SBCL lacks threads on anything but x86. If you want to help out, I'm sure that we'd take any code patches towards getting gencgc working on PowerPC - it's not a trivial matter though, and in the meantime I enjoy having a development environment that works on SBCL/OS X. -- Brian Mastenbrook bma...@cs... http://cs.indiana.edu/~bmastenb/ |
|
From: Bill C. <bil...@ya...> - 2003-11-27 22:58:21
|
>> 3. Flesh out SLIME with the functionality that is available today in ILISP >> and ELI. This is the "clean slate" option. It would allow for a new Emacs >> CL mode to be developed utilizing the best ideas from ILISP & ELI. It also >> requires the greatest amount of effort. >s/effort/fun/ :-) Yes, that's a valid reason. However, if I do a wc of the elisp files in the different packages, I get the following results (lines/words/chars): SLIME: 4345/14463/161611 ILISP: 15466/63798/565273 ELI: 19801/77244/743786 According to these figures, you've still got a lot of fun ahead of you to get feature parity with ILISP/ELI :-) >This is firmly the path we've taken, except that we're primarily >stealing ideas from Emacs Lisp's development environment. And some of the stuff that I've seen come out of SLIME looks pretty neat. So far, I've only been able to drool over screen shots as I primarily use MS Windows. >> 4. Integrate SLIME and ILISP. This would add multiprocessing support to >> ILISP and would allow SLIME to take advantage of the rich functionality >> already built into ILISP. >As Dan mentioned, we don't do any multiprocessing yet, though we hope >our infrastructure will permit it with minimal rewriting. >If you guys are interested in using TCP for your connection, the >socket code is pretty easy. I don't think merging with SLIME would be >a practical way to do it though. I'm not advocating adding TCP socket code to ILISP or merging ILISP and SLIME. I just consider that another option. As I said, it could be a "win-win option" but it might also be a "Frankenstein". Since ILISP was built on top of comint mode, it would probably be too much effort to retrofit socket communication support as an alternative. In any case, good luck with SLIME. I look forward to seeing what further developments you make in improving Emacs<->CL development environments. Cheers, Bill __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Bill C. <bil...@ya...> - 2003-11-27 22:35:14
|
Nic...@iw... writes: >Bill_Clementson writes: >> I would be interested in hearing what others think about these different >> scenarios. In all probability, scenario #1 will prevail; however, I would >> like to hear what others think about the different options (as well as >> options that I haven't thought of). >One question: is the license status of ILISP now completely clear? If not, >there might be an advantage from building things anew as SLIME does. I'm not sure. I know that Kevin Rosenberg went through quite an extensive effort a while ago to try to clear up the license status. In any case, the license issue is probably only going to be important to you if (a) you have religious convictions in this area or (b) you want to bundle ILISP and need to ensure that it's license is conformant with what you are trying to create. For Joe Hacker who just wants a tool to help him develop software with, ILISP is "free" enough. >I would have preferred the option of LEP being supported by the free Lisp >implementations (CMUCL, SBCL, CLISP, GCL). Is LEP too complicated or >otherwise bad, so that SLIME became necessary? AFAIK, there is nothing that prevents anyone from porting LEP (ELI) to any other CL implementation. The header on most of the ELI files reads: ;; Permission is granted to any individual or institution to use, copy, ;; modify, and distribute this software, and to distribute modified ;; versions, provided that this complete copyright and permission notice is ;; maintained, intact, in all copies and supporting documentation. Some of the ELI files contain the GNU copyright notice in them, so I assume that means all of ELI comes under the GNU license. However, I'm not a lawyer, so you can make your own assumptions. I have used both ELI and ILISP and I prefer ELI because it is more stable and it supports multiprocessing (the latter is very hard to do without once you get used to the advantages it offers). However, on MS Windows, ACL is the only CL implementation that ELI has support for. On Linux, there has been some work at porting ELI to SBCL and CMUCL. There was also a fairly extensive port of ELI done for Scieneer CL. -- Bill Clementson __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Luke G. <lu...@bl...> - 2003-11-27 15:05:07
|
Bil...@pe... writes: > 3. Flesh out SLIME with the functionality that is available today in ILISP > and ELI. This is the "clean slate" option. It would allow for a new Emacs > CL mode to be developed utilizing the best ideas from ILISP & ELI. It also > requires the greatest amount of effort. s/effort/fun/ :-) This is firmly the path we've taken, except that we're primarily stealing ideas from Emacs Lisp's development environment. > 4. Integrate SLIME and ILISP. This would add multiprocessing support to > ILISP and would allow SLIME to take advantage of the rich functionality > already built into ILISP. As Dan mentioned, we don't do any multiprocessing yet, though we hope our infrastructure will permit it with minimal rewriting. If you guys are interested in using TCP for your connection, the socket code is pretty easy. I don't think merging with SLIME would be a practical way to do it though. BTW, the interesting aspect of SLIME is the depth of our Emacs/Lisp integration. For example, we have rewritten parts of the Common Lisp top-level and debugger in Elisp, and made Emacs understand Lisp compiler messages very well. The socket stuff is just a boring implementation detail. Cheers, Luke |
|
From: Nicolas N. <Nic...@iw...> - 2003-11-27 14:39:39
|
Bil...@pe... writes: > I would be interested in hearing what others think about these different > scenarios. In all probability, scenario #1 will prevail; however, I would > like to hear what others think about the different options (as well as > options that I haven't thought of). One question: is the license status of ILISP now completely clear? If not, there might be an advantage from building things anew as SLIME does. I would have preferred the option of LEP being supported by the free Lisp implementations (CMUCL, SBCL, CLISP, GCL). Is LEP too complicated or otherwise bad, so that SLIME became necessary? Nicolas. |
|
From: Daniel B. <da...@te...> - 2003-11-27 14:15:43
|
Bil...@pe... writes: > 4. Integrate SLIME and ILISP. This would add multiprocessing support to > ILISP and would allow SLIME to take advantage of the rich functionality > already built into ILISP. Perhaps comint mode support could be retained and > the SLIME TCP socket communication protocol is provided as just another > option (not all CL's support multiprocessing and ILISP also supports a lot > of Scheme implementations that don't support multiprocessing so not > everyone would benefit from ILISP moving away from comint mode). This might > be a win-win option. It might also be a "Frankenstein" approach that could > hurt both. SLIME does not currently have any special support for multithreaded Lisp (although I'm currently using it with one and speculating on how it could be arranged). It does need an asynchronous TCP socket, that is true, but that can be done without threads if some other mechanism is available: in CMUCL and SBCL it hooks the event loop with SERVE-EVENT. The out-of-band communication is for me SLIME's biggest selling point over ILISP, architecture-wise: the chance of it getting confused is so much less (although it should be admitted that it can quite happily get confused for other reasons, but that's at least partly because I'm using it to develop itself). There are regexps in the ilisp support for SBCL than I don't understand the purpose of, and I put them there ... -dan -- http://web.metacircles.com/ - CL custom development and SBCL support |
|
From: Hannu K. <az...@ik...> - 2003-11-27 09:00:13
|
Luke Gorrie <lu...@bl...> writes: > First, I grabbed the second-newest revision (1.4). The latest adds > this: > > +;; Necessary when loading completer.el, but have not yet loaded ilisp > +(require 'ilcompat) > > So version 1.4 is stand-alone, but 1.5 depends on another small but > ILISP-specific file. What it seems to want is the definition of > +ilisp-emacs-version+ for this code: > > (not (memq +ilisp-emacs-version-id+ > '(xemacs lucid-19 lucid-19-new))) > > But in my copy I replaced this with (not (featurep 'xemacs)), just to > cut the dependency. > > Any comments? I don't want installing SLIME to somehow break ILISP. Looks ok to me. I think the same modification should be done to the ILISP version of it as well. It seems to me that the ILISP project is The Place where completer.el is "maintained" these days, so it would be good if it stayed independent of ILISP so that it could be used stand-alone. -- Hannu |
|
From: <Bil...@pe...> - 2003-11-27 06:31:39
|
Hi Luke,
I've been following "SLIME" with some interest.
Historically, the three main Emacs modes that people have used for CL
development were Inferior Lisp Mode (ILM), ILISP and ELI (developed by
Franz). ILM & ILISP worked with most CL implementations but were
constrained by having been built on top of comint mode (This sometimes
results in lock-ups. Also, since comint mode has a single line of
communication between Emacs and the CL implementation, it is not possible
to take advantage of multiprocessing if the CL implementation supports MP).
ELI doesn't have the comint heritage of ILM and ILISP. It (like SLIME) uses
a TCP socket to talk to CL and you can have multiple threads of
communication open to the CL implementation. Although ELI was developed by
Franz, it was released under the GPL and some people have done some work
towards porting it to CMUCL and SBCL. I think that the approach taken by
ELI and SLIME is the preferable approach; however, ILISP and ILM are both
widely used simply because they are the only option available with many CL
implementations (for people who want to use Emacs) .
I think there are a number of different possible scenarios that might
develop:
1. Status quo: ILM, ILISP, ELI and SLIME all coexist. Having multiple Emacs
CL modes is in some ways a benefit as it gives people choice; however, it
also means that multiple people are all working on divergent efforts to
achieve a similar result.
2. Effort is put into creating more complete LEP implementations for
different CL's so that ELI can be used effectively on multiple CL
implementations. The benefit of this option is that ELI is very
full-featured as it is and just the port of the underlying communication
layer would need to be done. Also, since the largest commercial CL vendor
supports ELI and actively enhances it, we can take advantage of both
commercial and open source development efforts.
3. Flesh out SLIME with the functionality that is available today in ILISP
and ELI. This is the "clean slate" option. It would allow for a new Emacs
CL mode to be developed utilizing the best ideas from ILISP & ELI. It also
requires the greatest amount of effort.
4. Integrate SLIME and ILISP. This would add multiprocessing support to
ILISP and would allow SLIME to take advantage of the rich functionality
already built into ILISP. Perhaps comint mode support could be retained and
the SLIME TCP socket communication protocol is provided as just another
option (not all CL's support multiprocessing and ILISP also supports a lot
of Scheme implementations that don't support multiprocessing so not
everyone would benefit from ILISP moving away from comint mode). This might
be a win-win option. It might also be a "Frankenstein" approach that could
hurt both.
I would be interested in hearing what others think about these different
scenarios. In all probability, scenario #1 will prevail; however, I would
like to hear what others think about the different options (as well as
options that I haven't thought of).
Bill Clementson
"Luke Gorrie"
<lu...@bl...> To: ili...@li...
Sent by: cc: sli...@co...
ili...@li...ur Subject: [Ilisp-devel] SLIME
ceforge.net
11/26/2003 05:55 PM
G'day ILISP hackers,
I should've written earlier to introduce our project called "SLIME" to
you guys. It's similar to ILISP, the main differences are that we use
a TCP socket to talk to Lisp and we generally try to imitate the Emacs
Lisp programming interface.
It started out a few months ago as a hack by Eric Marsden for
highlighting CMUCL's compiler warnings in Emacs buffers, but other
people started playing with it and now it's snowballed. The main page
is on Cliki at http://www.cliki.net/SLIME if you want to know more.
I'm not sure how all this relates to ILISP exactly, but I just wanted
to shoot you a note to say hello and invite you to play around with
it!
Cheers,
Luke
-------------------------------------------------------
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/
_______________________________________________
Ilisp-devel mailing list
Ili...@li...
https://lists.sourceforge.net/lists/listinfo/ilisp-devel
|
|
From: <Bil...@pe...> - 2003-11-27 05:40:12
|
If you put the following line in your .emacs file, this might fix the
problem of tab completion in the minibuffer not working:
(define-key minibuffer-local-map [tab] 'comint-dynamic-complete)
Bill Clementson
rif <rif@MIT.EDU>
Sent by: To: "Luke Gorrie" <lu...@bl...>
ili...@li...ur cc: ili...@li...
ceforge.net Subject: Re: [Ilisp-devel] completer.el
11/26/2003 05:35 PM
> Hi guys!
>
> I've just imported a copy of completer.el into SLIME (our
> ILISP-a-like). I've got a couple of questions about it.
> Any comments? I don't want installing SLIME to somehow break ILISP.
> BTW, is there some sordid history to completer.el and why it didn't
> make it into Emacs and XEmacs properly?
There's some problem I don't really have a grasp on. I think that
modern emacs use complete.el (not completer), and that this can
sometimes badly interact with completer.el as provided by ILISP. For
instance, on at least one machine of mine, starting ILISP under CMUCL
causes my emacs to break in the sense that tab-completion in the
minibuffer no longer works --- I can no longer find files or buffer by
matching, I can no longer kill individual buffers (the minibuffer just
always says "no match"), it's just badly broken. I haven't fully
tracked this down (it's on my todo list), but it has something to do
with interactions between complete.el and completer.el.
rif
-------------------------------------------------------
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/
_______________________________________________
Ilisp-devel mailing list
Ili...@li...
https://lists.sourceforge.net/lists/listinfo/ilisp-devel
|
|
From: Bob R. <rog...@rg...> - 2003-11-27 03:42:46
|
I have patched this as suggested, more or less; it's not necessary in the current snapshot, nor was it necessary in 18e, but I seem to have thought it made a difference when I was developing it in 18d, so I'd like to keep it in for the sake of older CMUCL versions. But there are other problems with M-. in the development version of CMUCL. For instance (so to speak), finding the source for methods doesn't work at all. So I still have something to do this holiday . . . ;-} -- Bob |
|
From: Bob R. <rog...@rg...> - 2003-11-27 02:51:31
|
From: rif <rif@MIT.EDU>
Date: Wed, 26 Nov 2003 12:39:40 -0500
I now have an actual fix (but no understanding) of the problem. The
offending coe is, in find-src.lisp, lines 45-49
;; [necessary in cmucl 18d, but not in 18f (we expect). -- rgr, 19-Feb-03.]
#+cmu
(defmethod class-name ((class structure-class))
(kernel::structure-class-name class))
I have no idea what this is actually doing, but it seems that in both
CMUCL 18e and 19a, this code causes find-src.lisp to only load
successfully when compiled, not when interpreted, which causes all the
problems discussed yesterday. I came upon the solution just by
randomly poking around in the files, so I guess this is a cargo cult
solution . . .
But it does narrow the problem very effectively; thanks for doing the
leg work!
If anyone would care to explain what this code actually does/means,
I'd be grateful.
Cheers,
rif
I wrote this (I'm "rgr", BTW) so that the rest of find-src.lisp wouldn't
have to worry so much about the distinction between standard-class and
structure-class instances. In 18d/e, class-name does the right
thing for structure classes, so I can share more of the method-finding
code than I would otherwise be able to do.
Based on a cursory test, it seems to work in the interpreter if I do
(slot-value class 'pcl::name) here. This might also be more portable --
between CMUCL versions, that is. I'll give this a try; thanks again for
getting me started.
-- Bob
|
|
From: Luke G. <lu...@bl...> - 2003-11-27 00:55:57
|
G'day ILISP hackers, I should've written earlier to introduce our project called "SLIME" to you guys. It's similar to ILISP, the main differences are that we use a TCP socket to talk to Lisp and we generally try to imitate the Emacs Lisp programming interface. It started out a few months ago as a hack by Eric Marsden for highlighting CMUCL's compiler warnings in Emacs buffers, but other people started playing with it and now it's snowballed. The main page is on Cliki at http://www.cliki.net/SLIME if you want to know more. I'm not sure how all this relates to ILISP exactly, but I just wanted to shoot you a note to say hello and invite you to play around with it! Cheers, Luke |
|
From: rif <rif@MIT.EDU> - 2003-11-27 00:35:49
|
> Hi guys! > > I've just imported a copy of completer.el into SLIME (our > ILISP-a-like). I've got a couple of questions about it. > Any comments? I don't want installing SLIME to somehow break ILISP. > BTW, is there some sordid history to completer.el and why it didn't > make it into Emacs and XEmacs properly? There's some problem I don't really have a grasp on. I think that modern emacs use complete.el (not completer), and that this can sometimes badly interact with completer.el as provided by ILISP. For instance, on at least one machine of mine, starting ILISP under CMUCL causes my emacs to break in the sense that tab-completion in the minibuffer no longer works --- I can no longer find files or buffer by matching, I can no longer kill individual buffers (the minibuffer just always says "no match"), it's just badly broken. I haven't fully tracked this down (it's on my todo list), but it has something to do with interactions between complete.el and completer.el. rif |
|
From: Luke G. <lu...@bl...> - 2003-11-27 00:20:35
|
Hi guys!
I've just imported a copy of completer.el into SLIME (our
ILISP-a-like). I've got a couple of questions about it.
First, I grabbed the second-newest revision (1.4). The latest adds
this:
+;; Necessary when loading completer.el, but have not yet loaded ilisp
+(require 'ilcompat)
So version 1.4 is stand-alone, but 1.5 depends on another small but
ILISP-specific file. What it seems to want is the definition of
+ilisp-emacs-version+ for this code:
(not (memq +ilisp-emacs-version-id+
'(xemacs lucid-19 lucid-19-new)))
But in my copy I replaced this with (not (featurep 'xemacs)), just to
cut the dependency.
Any comments? I don't want installing SLIME to somehow break ILISP.
BTW, is there some sordid history to completer.el and why it didn't
make it into Emacs and XEmacs properly?
Cheers,
Luke
|
|
From: rif <rif@MIT.EDU> - 2003-11-26 17:39:49
|
I now have an actual fix (but no understanding) of the problem. The offending coe is, in find-src.lisp, lines 45-49 ;; [necessary in cmucl 18d, but not in 18f (we expect). -- rgr, 19-Feb-03.] #+cmu (defmethod class-name ((class structure-class)) (kernel::structure-class-name class)) I have no idea what this is actually doing, but it seems that in both CMUCL 18e and 19a, this code causes find-src.lisp to only load successfully when compiled, not when interpreted, which causes all the problems discussed yesterday. I came upon the solution just by randomly poking around in the files, so I guess this is a cargo cult solution. Suggested fix, change the #+cmu to #+(and cmu (not (or cmu18e cmu18f cmu19))) If anyone would care to explain what this code actually does/means, I'd be grateful. Cheers, rif |
|
From: Paolo A. <am...@mc...> - 2003-11-10 17:02:07
|
I would like to resign as maintainer of ILISP. Marco can delete my SourceForge ID from the list of maintainers. I am no longer able to work on the project as much as I would have hoped, and I have not become familiar enough with the ILISP internals to do useful contributions. This has been a valuable learning experience for me. Thanks, Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
|
From: rif <rif@MIT.EDU> - 2003-11-07 15:10:32
|
Can someone please modify ilisp.emacs in CVS so that ilisp.emacs, lines 170-171 (suggested instructions for getting Naggum's HyperSpec package working) reads ; (setq common-lisp-hyperspec-symbol-table ; "/home/joe/HyperSpec/Data/Map_Sym.txt") Currently, the suggested file is Map_Sym.Txt, which does not exist as part of the hyperspec, and if you set this wrong, it doesn't give an error message that allows one to easily track the problem. Cheers, rif |
|
From: Bob R. <rog...@rg...> - 2003-11-03 04:37:19
|
From: Hannu Koivisto <az...@ik...> Date: Mon, 03 Nov 2003 01:37:22 +0200 Bob Rogers <rog...@rg...> writes: > It still works in ilisp HEAD with SBCL 0.8.4, after cursory testing, but > it doesn't recompile cleanly if you just do "M-x ilisp-recompile-inits", > since recompiling them doesn't reload the new binaries, and so sbcl.lisp Heh, I've actually never tried to use ilisp-recompile-inits before launching the listener. This certainly needs to be fixed. I did it afterwards, but without flushing the old binaries. I get the impression that this worked for you earlier. I wonder how that can be, since sbcl.lisp used the-function-if-defined and friends and they are in cl-ilisp.lisp. It's kinda hokey. If you don't have binaries lying around, i.e. in a fresh installation or CVS checkout, invoking (e.g.) M-x sbcl loads the appropriate *.lisp sources, so the current versions are available to the interpreter during M-x ilisp-recompile-inits. So it's hackish, but not too hackish, and does avoid having to think very hard about bootstrapping. > doesn't have the new maybe-function definition. If it were up to me, I > would make the sbcl.lisp change do more at runtime, or add reader > conditionalization for old vs. new behavior, but other possibilities Had I had extra time, I would have rewritten the whole mess. Note that find-src.lisp is broken as well. Not surprised. I probably would have reorganized things between it and implementation specific modules a bit. I would also have replaced the-function-if-defined and friends with something more usable. Anyway. I don't see how reader conditionalizing would buy anything in this case, it would just pollute *features*. In general, I try to avoid reader conditionalization. Use of it easily leads to abominations like mk-defsystem. Hmm. mk-defsystem doesn't seem bad at all to me, but that's probably from having had to write portable Lisp before CLtL, never mind ANSI. In particular, reader conditionalization avoids abominations like the-function-if-defined. But of course, both are matters of taste. > include moving maybe-function to sbcl.lisp (with eval-when) and having The reason I put it in cl-ilisp.lisp was that I thought it might be useful elsewhere. This was of course just speculation. And it indeed assumes that cl-ilisp.lisp is loaded before the implementation specific module. Both are good speculations/assumptions, they just didn't work from my particular state. > ilisp-recompile-inits load after compilation (which is probably a good > thing to do anyway). Opinions? Yeah, I agree this is probably a good thing in any case. -- Hannu OK, so what I'll do is commit your patch as-is, then maybe worry about cleaning up ilisp-recompile-inits later, and worry about the other issues not at all. Thanks, -- Bob Rogers http://rgrjr.dyndns.org/ |
|
From: Hannu K. <az...@ik...> - 2003-11-02 23:37:24
|
Bob Rogers <rog...@rg...> writes: > It still works in ilisp HEAD with SBCL 0.8.4, after cursory testing, but > it doesn't recompile cleanly if you just do "M-x ilisp-recompile-inits", > since recompiling them doesn't reload the new binaries, and so sbcl.lisp Heh, I've actually never tried to use ilisp-recompile-inits before launching the listener. This certainly needs to be fixed. I get the impression that this worked for you earlier. I wonder how that can be, since sbcl.lisp used the-function-if-defined and friends and they are in cl-ilisp.lisp. > doesn't have the new maybe-function definition. If it were up to me, I > would make the sbcl.lisp change do more at runtime, or add reader > conditionalization for old vs. new behavior, but other possibilities Had I had extra time, I would have rewritten the whole mess. Note that find-src.lisp is broken as well. I probably would have reorganized things between it and implementation specific modules a bit. I would also have replaced the-function-if-defined and friends with something more usable. Anyway. I don't see how reader conditionalizing would buy anything in this case, it would just pollute *features*. In general, I try to avoid reader conditionalization. Use of it easily leads to abominations like mk-defsystem. > include moving maybe-function to sbcl.lisp (with eval-when) and having The reason I put it in cl-ilisp.lisp was that I thought it might be useful elsewhere. This was of course just speculation. And it indeed assumes that cl-ilisp.lisp is loaded before the implementation specific module. > ilisp-recompile-inits load after compilation (which is probably a good > thing to do anyway). Opinions? Yeah, I agree this is probably a good thing in any case. -- Hannu |
|
From: Bob R. <rog...@rg...> - 2003-11-02 16:47:22
|
From: Hannu Koivisto <az...@ik...> Date: Sun, 02 Nov 2003 01:48:19 +0200 Greetings, ILISP cannot be used (sbcl.lisp doesn't even load/compile) with the CVS HEAD version of SBCL, because the current arglist discovery method relies on internals that have changed. I have modified arglist discovery to support sb-introspect, which is the way to do this in the bleeding edge SBCL versions. Support for older versions is of course still there but hasn't been tested. It still works in ilisp HEAD with SBCL 0.8.4, after cursory testing, but it doesn't recompile cleanly if you just do "M-x ilisp-recompile-inits", since recompiling them doesn't reload the new binaries, and so sbcl.lisp doesn't have the new maybe-function definition. If it were up to me, I would make the sbcl.lisp change do more at runtime, or add reader conditionalization for old vs. new behavior, but other possibilities include moving maybe-function to sbcl.lisp (with eval-when) and having ilisp-recompile-inits load after compilation (which is probably a good thing to do anyway). Opinions? -- Bob Rogers http://rgrjr.dyndns.org/ |
|
From: Hannu K. <az...@ik...> - 2003-11-01 23:48:22
|
Greetings, ILISP cannot be used (sbcl.lisp doesn't even load/compile) with the CVS HEAD version of SBCL, because the current arglist discovery method relies on internals that have changed. I have modified arglist discovery to support sb-introspect, which is the way to do this in the bleeding edge SBCL versions. Support for older versions is of course still there but hasn't been tested. 2003-10-31 Hannu Koivisto <az...@ik...> * sbcl.lisp: * Now tries to require sb-introspect. * (arglist) Modified to support sb-introspect. * cl-ilisp.lisp: * (maybe-function) New function. -- Hannu |
|
From: Marco A. <ma...@cs...> - 2003-10-29 16:42:38
|
On Wednesday, Oct 29, 2003, at 11:36 America/New_York, Martin Cracauer wrote: > Marco Antoniotti wrote on Wed, Oct 29, 2003 at 11:32:39AM -0500: >> >> At a certain point there was a web page available in the cons.org >> site. >> I guess that got lost in all the moving around, isn't it? > > Hm, I cannot find anything in my CVS tree. > > I think I just set up a directory and somebody else placed a page. Yes. That was me several years ago. I may still have the original laying around. I will welcome anything new (hint, hint) Cheers -- Marco -- Marco Antoniotti NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
|
From: Martin C. <cra...@co...> - 2003-10-29 16:38:00
|
Marco Antoniotti wrote on Wed, Oct 29, 2003 at 11:32:39AM -0500: > > At a certain point there was a web page available in the cons.org site. > I guess that got lost in all the moving around, isn't it? Hm, I cannot find anything in my CVS tree. I think I just set up a directory and somebody else placed a page. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. |
|
From: Marco A. <ma...@cs...> - 2003-10-29 16:32:42
|
That will help. At a certain point there was a web page available in the cons.org site. I guess that got lost in all the moving around, isn't it? Cheers Marco On Wednesday, Oct 29, 2003, at 11:26 America/New_York, Martin Cracauer wrote: > Marco Antoniotti wrote on Wed, Oct 29, 2003 at 11:11:47AM -0500: >> Hi >> >> it looks like the only page available to get to ILISP is now >> >> http://sourceforge.net/projects/ilisp/ >> >> The link in cons.org is broken. > > I added a redirect from ilisp.cons.org to the SF page. > > Is that what you need? > > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ > No warranty. This email is probably produced by one of my cats > stepping on the keys. No, I don't have an infinite number of cats. > > > ------------------------------------------------------- > 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/ > _______________________________________________ > Ilisp-devel mailing list > Ili...@li... > https://lists.sourceforge.net/lists/listinfo/ilisp-devel > -- Marco Antoniotti NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
|
From: Martin C. <cra...@co...> - 2003-10-29 16:27:20
|
Marco Antoniotti wrote on Wed, Oct 29, 2003 at 11:11:47AM -0500: > Hi > > it looks like the only page available to get to ILISP is now > > http://sourceforge.net/projects/ilisp/ > > The link in cons.org is broken. I added a redirect from ilisp.cons.org to the SF page. Is that what you need? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. |
24 messages has been excluded from this view by a project administrator.