From: <sm...@sp...> - 2004-04-06 06:40:27
|
Hi all, It's been some time since I've played with sbcl, thought I'd give it a shot. So I compiled 0.8.9 on fedora fc1, and started compiling a program when I ran into this problem in one of my files... ; in: DEFUN PQ-LOOKAHEAD ; (VALUES (DISCRETE-EVENT-SIMULATOR::PEL-OBJECT FIRST) ; (DISCRETE-EVENT-SIMULATOR::PEL-PRIORITY ; DISCRETE-EVENT-SIMULATOR::QUEUE)) ; ; note: deleting unreachable code ; (AREF (DISCRETE-EVENT-SIMULATOR::PQ-ELEMENTS DISCRETE-EVENT-SIMULATOR::QUEUE) ; 0) ; --> LET* ; ==> ; (SB-KERNEL:HAIRY-DATA-VECTOR-REF ARRAY SB-INT:INDEX) ; ; note: unable to ; avoid runtime dispatch on array element type ; because: ; Upgraded element type of array is not known at compile time. ; (DISCRETE-EVENT-SIMULATOR::PEL-PRIORITY DISCRETE-EVENT-SIMULATOR::QUEUE) ; --> TRULY-THE SB-KERNEL:%INSTANCE-REF ; ==> ; (THE DISCRETE-EVENT-SIMULATOR::PRIORITIZED-ELEMENT ; DISCRETE-EVENT-SIMULATOR::QUEUE) ; ; caught WARNING: ; Asserted type PRIORITIZED-ELEMENT conflicts with derived type ; (VALUES PRIORITY-QUEUE &OPTIONAL). Here's the source for this function: (defun pq-lookahead (queue) (unless (pq-empty-p queue) (let ((first (aref (pq-elements queue) 0))) (values (pel-object first) (pel-priority queue))))) Never mind the optimization warnings, the one that's causing problems is the asserted type warning at the end of the console output snippet. I never asserted a type for this function, and I can't figure out how SBCL decided on these two return types. One of the consequences from this warning is at the end of the file compilation result... ; WSIM:SIMULATORS;DESIM;PQUEUE.FASL.NEWEST written ; compilation finished in 0:00:01 #P"/home/smishra/svn/sase/wsim/simulators/desim/pqueue.fasl" T T I've checked the output, and the warning above is the only error or warning that is output for this file. sbcl produces two apparently contradictory pieces of feedback, that the fasl file was written, and that the compile file failed (as indicated by the third return value of compile-file). Can anyone suggest what might be going on here? This is causing severe problems in using asdf, as it fails on seeing the compile failure result. There is also a suggestion I could make that would simplify debugging with sbcl/asdf here. It would be nice if sbcl produced a list of error and warning conditions rather than t/nil as the second and third values. This would allow asdf to actually present useful information on compile failure, rather than bailing with a generic message. It would also make possible, say, the collection of all warning messages produced through the compile of a system for presentation at the end of the compilation. Thanks! Sunil |
From: Christophe R. <cs...@ca...> - 2004-04-06 07:41:11
|
sm...@sp... writes: > ; caught WARNING: > ; Asserted type PRIORITIZED-ELEMENT conflicts with derived type > ; (VALUES PRIORITY-QUEUE &OPTIONAL). > > Here's the source for this function: > > (defun pq-lookahead (queue) > (unless (pq-empty-p queue) > (let ((first (aref (pq-elements queue) 0))) > (values (pel-object first) (pel-priority queue))))) I'm just guessing, but don't you mean (values (pel-object first) (pel-priority first))? The warnings are due to the fact that the compiler has proved that QUEUE must be a PRIORITY-QUEUE, from the call to PQ-ELEMENTS; therefore, it can prove that calling (PEL-PRIORITY QUEUE) is an error, because (presumably) a PRIORITY-QUEUE is not a PRIORITIZED-ELEMENT. If this isn't the case, could you provide enough code to reproduce the problem? > There is also a suggestion I could make that would simplify > debugging with sbcl/asdf here. It would be nice if sbcl produced a > list of error and warning conditions rather than t/nil as the second > and third values. Something along those lines might be possible, but as a first suggestion I recommend using an IDE such as slime, which presents all compilation notes in a clickable buffer, sorted by severity, for ease of bug fixing. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: <sm...@sp...> - 2004-04-06 17:23:36
|
Christophe Rhodes wrote: > sm...@sp... writes: > > >>; caught WARNING: >>; Asserted type PRIORITIZED-ELEMENT conflicts with derived type >>; (VALUES PRIORITY-QUEUE &OPTIONAL). >> >>Here's the source for this function: >> >>(defun pq-lookahead (queue) >> (unless (pq-empty-p queue) >> (let ((first (aref (pq-elements queue) 0))) >> (values (pel-object first) (pel-priority queue))))) > > > I'm just guessing, but don't you mean > (values (pel-object first) (pel-priority first))? > > The warnings are due to the fact that the compiler has proved that > QUEUE must be a PRIORITY-QUEUE, from the call to PQ-ELEMENTS; > therefore, it can prove that calling (PEL-PRIORITY QUEUE) is an error, > because (presumably) a PRIORITY-QUEUE is not a PRIORITIZED-ELEMENT. > If this isn't the case, could you provide enough code to reproduce the > problem? Fair enough, this would be an error in my code :-) But there are still issues here: 1. Is this the sort of thing that should rise to the level of compile *failure*? This function for example is not used anywhere, and I don't really care if it is at present correct or not. I don't think my compile should be failing. On the other hand, calling this warning a style warning would be questionable too... 2. The warning is really obscure. My instinct on seeing this was to look at the values form in my function, not the argument to pel-priority. >>There is also a suggestion I could make that would simplify >>debugging with sbcl/asdf here. It would be nice if sbcl produced a >>list of error and warning conditions rather than t/nil as the second >>and third values. Should have read the standard a little bit more carefully first. That should be a list of errors and warnings as the second value from compile-file. > Something along those lines might be possible, but as a first > suggestion I recommend using an IDE such as slime, which presents all > compilation notes in a clickable buffer, sorted by severity, for ease > of bug fixing. I am using slime. And I don't see the behavior you have described. I don't get a list of warnings in a clickable buffer, they all just scroll by. All I get from ASDF when it tries to compile my file with the above function is a statement saying that my compile has failed. It doesn't seem to have the mechanisms to figure out what error there was in the compile file that caused the failure. Outside of normal development, extending the return value of compile-file would also allow things like testing through nightly builds and presenting compile result summaries. At present I haven't yet delved into the sbcl codebase. In time I shall do so, and shall contribute patches myself. For now I'm only reporting :-) Thanks! Sunil |
From: Christophe R. <cs...@ca...> - 2004-04-06 17:57:24
|
sm...@sp... writes: > Christophe Rhodes wrote: >> sm...@sp... writes: >> >> I'm just guessing, but don't you mean >> (values (pel-object first) (pel-priority first))? > > Fair enough, this would be an error in my code :-) But there are still > issues here: > > 1. Is this the sort of thing that should rise to the level of compile > *failure*? I think absolutely, yes. > This function for example is not used anywhere, and I don't > really care if it is at present correct or not. I don't think my > compile should be failing. If you don't care, why do you have it there in the first place? I think SBCL, the system, has to start by assuming that anything it's given is important... > 2. The warning is really obscure. My instinct on seeing this was to > look at the values form in my function, not the argument to > pel-priority. Conceded, it's not completely clear. >> Something along those lines might be possible, but as a first >> suggestion I recommend using an IDE such as slime, which presents all >> compilation notes in a clickable buffer, sorted by severity, for ease >> of bug fixing. > > I am using slime. And I don't see the behavior you have described. I > don't get a list of warnings in a clickable buffer, they all just > scroll by. All I get from ASDF when it tries to compile my file with > the above function is a statement saying that my compile has > failed. Hmm. Are there any slime people listening? I suspect this is because the compilation hasn't finished... is there any way of getting the annotations one-at-a-time, rather than all at the end, if indeed this is the problem? > Outside of normal development, extending the return value of > compile-file would also allow things like testing through nightly > builds and presenting compile result summaries. > > At present I haven't yet delved into the sbcl codebase. In time I > shall do so, and shall contribute patches myself. For now I'm only > reporting :-) The kind of thing you seem to want to do here could be done portably by binding handlers for STYLE-WARNING and WARNING around whatever drives your compilation; I believe this is how SLIME does it, for instance. Setting *BREAK-ON-SIGNALS* to 'WARNING and asking for the RECOMPILE restart might also help. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: <sm...@sp...> - 2004-04-06 21:02:57
|
Christophe Rhodes wrote: > sm...@sp... writes: > > >>Christophe Rhodes wrote: >> >>>sm...@sp... writes: >>> >>>I'm just guessing, but don't you mean >>> (values (pel-object first) (pel-priority first))? >> >>Fair enough, this would be an error in my code :-) But there are still >>issues here: >> >>1. Is this the sort of thing that should rise to the level of compile >>*failure*? > > > I think absolutely, yes. Perhaps we're defining failure differently. In this case, sbcl does write out a fasl file. It doesn't *fail*. Fail to me is something like a missing parenthesis, where it often becomes impossible to compile the file. To me it doesn't seem reasonable that sbcl would both generate a fasl file and claim that compilation has failed. >>This function for example is not used anywhere, and I don't >>really care if it is at present correct or not. I don't think my >>compile should be failing. > > > If you don't care, why do you have it there in the first place? I > think SBCL, the system, has to start by assuming that anything it's > given is important... The feeling I'm left with, as compared to other lisps, is that sbcl is being far too strict. I've written some code, some of it works, some of it doesn't. I'd like to be able to compile and test some of the functionality I have implemented as soon as possible. If the basic functionality I have doesn't work as expected, I may have to make significant revisions. Fixing a bug like this may turn out to be a waste of time in that case. sbcl in this case seems to be getting in the way. Yes, the fact that sbcl *can* detect such errors is great. But one of the reasons I'm working in lisp and not C or Java is that I don't have to worry about getting everything just right before I can do some testing on my code. ... > >>Outside of normal development, extending the return value of >>compile-file would also allow things like testing through nightly >>builds and presenting compile result summaries. >> >>At present I haven't yet delved into the sbcl codebase. In time I >>shall do so, and shall contribute patches myself. For now I'm only >>reporting :-) > > > The kind of thing you seem to want to do here could be done portably > by binding handlers for STYLE-WARNING and WARNING around whatever > drives your compilation; I believe this is how SLIME does it, for > instance. Setting *BREAK-ON-SIGNALS* to 'WARNING and asking for the > RECOMPILE restart might also help. So your take in this case is that it would be an asdf problem and not an sbcl one? (Since I'm using asdf to do my compiling?) I have other problems too with asdf, and I'd be happy to take this up with Dan (and others?). Sunil |
From: David L. <da...@li...> - 2004-04-06 21:12:41
|
Quoting sm...@sp... (sm...@sp...): > Perhaps we're defining failure differently. In this case, sbcl does=20 > write out a fasl file. It doesn't *fail*. Fail to me is something like a= =20 That is not the terminology used be the Common Lisp specification. Non-style warning count as failures. > The feeling I'm left with, as compared to other lisps, is that sbcl is=20 > being far too strict. I've written some code, some of it works, some of= =20 The opposite is true, I believe. Other Lisps signal so many non-style warnings in harmless situations that any defsystem relying on them would be unusable on those implementations. That must be why asdf.lisp defines: (defvar *compile-file-failure-behaviour* #+sbcl :error #-sbcl :warn) So if you want the behaviour seen on other Lisps, use :warn. d. --=20 Common Lisp is the Borg of programming languages -- Bill Clementson |
From: <sm...@sp...> - 2004-04-06 21:28:03
|
Hmmm, I can see the merit of exercising this level of control in the defsystem. Another enhancement request for asdf :-) Sunil David Lichteblau wrote: > Quoting sm...@sp... (sm...@sp...): > >>Perhaps we're defining failure differently. In this case, sbcl does >>write out a fasl file. It doesn't *fail*. Fail to me is something like a > > > That is not the terminology used be the Common Lisp specification. > Non-style warning count as failures. > > >>The feeling I'm left with, as compared to other lisps, is that sbcl is >>being far too strict. I've written some code, some of it works, some of > > > The opposite is true, I believe. Other Lisps signal so many non-style > warnings in harmless situations that any defsystem relying on them would > be unusable on those implementations. > > That must be why asdf.lisp defines: > (defvar *compile-file-failure-behaviour* #+sbcl :error #-sbcl :warn) > > So if you want the behaviour seen on other Lisps, use :warn. > > > d. |
From: Daniel B. <da...@te...> - 2004-04-06 21:43:57
|
sm...@sp... writes: > Hmmm, I can see the merit of exercising this level of control in the > defsystem. Another enhancement request for asdf :-) Colour me slightly confused by this comment, because David Lichteblau wrote: >> That must be why asdf.lisp defines: >> (defvar *compile-file-failure-behaviour* #+sbcl :error #-sbcl :warn) >> So if you want the behaviour seen on other Lisps, use :warn. David's pointing out here that asdf already /has/ this level of control: adjust *compile-file-failure-behaviour* to your taste. Unfortunately it seems I never got as far as documenting this, but it's an exported symbol, so consider it fair game. -dan -- "please make sure that the person is your friend before you confirm" |
From: <sm...@sp...> - 2004-04-06 22:00:25
|
Didn't think I'd be hearing from you this quick... What I had mind was more like the -W flags in gcc, where you can exercise fairly fine grain control over what warnings you consider significant. I should experiment with this idea on at least a couple of lisps before I put forth a more specific proposal. Sunil Daniel Barlow wrote: > sm...@sp... writes: > > >>Hmmm, I can see the merit of exercising this level of control in the >>defsystem. Another enhancement request for asdf :-) > > > Colour me slightly confused by this comment, because > > David Lichteblau wrote: > >>>That must be why asdf.lisp defines: >>>(defvar *compile-file-failure-behaviour* #+sbcl :error #-sbcl :warn) >>>So if you want the behaviour seen on other Lisps, use :warn. > > > David's pointing out here that asdf already /has/ this level of > control: adjust *compile-file-failure-behaviour* to your taste. > Unfortunately it seems I never got as far as documenting this, but > it's an exported symbol, so consider it fair game. > > > -dan > |
From: David L. <da...@li...> - 2004-04-06 23:05:10
|
Quoting sm...@sp... (sm...@sp...): > What I had mind was more like the -W flags in gcc, where you can=20 > exercise fairly fine grain control over what warnings you consider=20 > significant. You can change ASDF behaviour as a user without even touching the system file by defining your own operation class, e.g. like this: (defclass lenient-compile-op (asdf:compile-op) () (:default-initargs :on-failure :warn)) Then try (asdf:operate 'lenient-compile-op ...) And for suppressing certain warnings, the standard boilerplate for the lazy developer's system file goes like this: -------- (defclass silent-source-file (cl-source-file) ()) (defmethod perform :around ((o compile-op) (s silent-source-file)) (handler-bind (#+sbcl (sb-ext:compiler-note #'muffle-warning)) (call-next-method))) (defsystem :cloak :default-component-class silent-source-file ...) -------- d. --=20 Common Lisp is the Borg of programming languages -- Bill Clementson |
From: Christophe R. <cs...@ca...> - 2004-04-06 21:54:47
|
sm...@sp... writes: > Christophe Rhodes wrote: >> sm...@sp... writes: >>>1. Is this the sort of thing that should rise to the level of compile >>> *failure*? >> I think absolutely, yes. > > Perhaps we're defining failure differently. In this case, sbcl does > write out a fasl file. It doesn't *fail*. Fail to me is something like > a missing parenthesis, where it often becomes impossible to compile > the file. To me it doesn't seem reasonable that sbcl would both > generate a fasl file and claim that compilation has failed. There is a distinction between generating a possibly-bogus fasl (indicated by a normal return from COMPILE-FILE and a failurep set to true), and getting sufficiently confused that it's had to give up completely (which causes a non-continuable error during COMPILE-FILE). >> If you don't care, why do you have it there in the first place? I >> think SBCL, the system, has to start by assuming that anything it's >> given is important... > > The feeling I'm left with, as compared to other lisps, is that sbcl is > being far too strict. I've written some code, some of it works, some > of it doesn't. I'd like to be able to compile and test some of the > functionality I have implemented as soon as possible. If the basic > functionality I have doesn't work as expected, I may have to make > significant revisions. David Lichteblau has pointed you at asdf's specialisation for sbcl, but that is only because sbcl actually pays attention to the meaning of conditions. The asdf variable in question is, I believe, documented and customizeable, so if early warning doesn't suit your style the behaviour can be tweaked, but it is in no way sbcl's issue; I believe it was perfectly correct to warn on your code. While we're at it, I will defend asdf's sbcl-only default to cause a break when it is running on a system where the return values from COMPILE-FILE are meaningful; encouraging lazy developers (me particularly :-) to deal with problems as they arise, no matter how trivial they seem, I believe leads to more robust, more portable and less buggy code at the end of the day. People with the opposite philosophy are welcome to turn off all sorts of diagnostics by whatever means they see fit (including by not using sbcl at all :-) but if people haven't yet had the chance to develop a philosophy at all maybe they can be influenced in the direction of good practice. > Fixing a bug like this may turn out to be a waste of time in that > case. sbcl in this case seems to be getting in the way. Again, what has happened is that your build tools have a default that seems not to be to your style. Fair enough, they are sufficiently customizeable that the default can be changed. On the other hand, if you truly have a warning (-> failurep) in a function you don't care about, simply #+nil it out and recompile, and come back to it later. >> The kind of thing you seem to want to do here could be done portably >> by binding handlers for STYLE-WARNING and WARNING around whatever >> drives your compilation; I believe this is how SLIME does it, for >> instance. Setting *BREAK-ON-SIGNALS* to 'WARNING and asking for the >> RECOMPILE restart might also help. > > So your take in this case is that it would be an asdf problem and not > an sbcl one? (Since I'm using asdf to do my compiling?) I have other > problems too with asdf, and I'd be happy to take this up with Dan (and > others?). As you allude, it's not specifically asdf, though it does have the default behaviour that seems to have irked you; more generally, whatever you use to build your system has the responsibility of informing you if it has failed to get it right. I should also point out that asdf has an accept restart associated with the condition, so you could simply choose that (either programmatically or interactively) if you are not supported by your IDE. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2004-04-07 19:22:29
|
Luke Gorrie writes: > sm...@sp... writes: > > > Is C-c C-k an option if you are loading a system through asdf? > > There is a command `slime-load-system' that compiles/loads a system > through ASDF, you could give that a try. > > Currently it's undocumented because I think we need sister commands > for load/compile/compile-:force-t, but haven't gotten around to adding > them. It might make more sense to have a slime-operate-on-system command that by default loads the system it finds in the current directory, but when given a prefix argument, prompts you for the operation class and system name. |
From: Luke G. <lu...@bl...> - 2004-04-08 13:42:53
|
"Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> writes: > One thing that slime does wrong in SBCL, is if you use > slime-eval-defun, you don't get any of the fancy tracking of errors, > warnings, and notes. The problem is that since SBCL compiles > everything, there's no distinction between "eval" and "compile". One > of the first things I did with slime was to change M-C-x to > slime-compile-defun, but IMO this is the wrong default on SBCL. Why not just press C-c C-c instead of C-M-x if you want notes? That is consistent across all Lisps. I'm not sure if this is about the semantics of our 'eval' command or particularly about the binding of C-M-X. |
From: Luke G. <lu...@bl...> - 2004-04-06 18:20:53
|
sm...@sp... writes: > I am using slime. And I don't see the behavior you have described. I > don't get a list of warnings in a clickable buffer, they all just > scroll by. All I get from ASDF when it tries to compile my file with > the above function is a statement saying that my compile has > failed. It doesn't seem to have the mechanisms to figure out what > error there was in the compile file that caused the failure. Are you compiling via REPL commands? To get fancy notes in SLIME you have to compile using Emacs commands. `C-c C-k' compiles and loads the current file, and `C-c C-c' compile and loads the current function (top-level form). Also, SLIME was a bit slow if you had a lot of notes (e.g. over a hundred). That was fixed a couple of weeks ago. Cheers, Luke |
From: <sm...@sp...> - 2004-04-06 20:46:47
|
Is C-c C-k an option if you are loading a system through asdf? Another type of loader or defsystem? I don't know if it is feasible to generally trap a call to compile-file for slime to examine. But seems like that is exactly what one would have to do to get the effect that Christophe was expecting. Sunil Luke Gorrie wrote: > sm...@sp... writes: > > >>I am using slime. And I don't see the behavior you have described. I >>don't get a list of warnings in a clickable buffer, they all just >>scroll by. All I get from ASDF when it tries to compile my file with >>the above function is a statement saying that my compile has >>failed. It doesn't seem to have the mechanisms to figure out what >>error there was in the compile file that caused the failure. > > > Are you compiling via REPL commands? To get fancy notes in SLIME you > have to compile using Emacs commands. `C-c C-k' compiles and loads the > current file, and `C-c C-c' compile and loads the current function > (top-level form). > > Also, SLIME was a bit slow if you had a lot of notes (e.g. over a > hundred). That was fixed a couple of weeks ago. > > Cheers, > Luke > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2004-04-07 19:20:10
|
Luke Gorrie writes: > sm...@sp... writes: > > > I am using slime. And I don't see the behavior you have described. I > > don't get a list of warnings in a clickable buffer, they all just > > scroll by. All I get from ASDF when it tries to compile my file with > > the above function is a statement saying that my compile has > > failed. It doesn't seem to have the mechanisms to figure out what > > error there was in the compile file that caused the failure. > > Are you compiling via REPL commands? To get fancy notes in SLIME you > have to compile using Emacs commands. `C-c C-k' compiles and loads the > current file, and `C-c C-c' compile and loads the current function > (top-level form). > > Also, SLIME was a bit slow if you had a lot of notes (e.g. over a > hundred). That was fixed a couple of weeks ago. One thing that slime does wrong in SBCL, is if you use slime-eval-defun, you don't get any of the fancy tracking of errors, warnings, and notes. The problem is that since SBCL compiles everything, there's no distinction between "eval" and "compile". One of the first things I did with slime was to change M-C-x to slime-compile-defun, but IMO this is the wrong default on SBCL. |
From: <sm...@sp...> - 2004-04-07 04:11:22
|
Thanks for the boilerplate, I'll use it as a starting point! BTW, is there an asdf mailing list? Home page? Something other than cll? Sunil David Lichteblau wrote: > Quoting sm...@sp... (sm...@sp...): > >>What I had mind was more like the -W flags in gcc, where you can >>exercise fairly fine grain control over what warnings you consider >>significant. > > > You can change ASDF behaviour as a user without even touching the system > file by defining your own operation class, e.g. like this: > > (defclass lenient-compile-op (asdf:compile-op) () > (:default-initargs :on-failure :warn)) > > Then try (asdf:operate 'lenient-compile-op ...) > > > And for suppressing certain warnings, the standard boilerplate for the > lazy developer's system file goes like this: > -------- > (defclass silent-source-file (cl-source-file) ()) > > (defmethod perform :around ((o compile-op) (s silent-source-file)) > (handler-bind (#+sbcl (sb-ext:compiler-note #'muffle-warning)) > (call-next-method))) > > (defsystem :cloak > :default-component-class silent-source-file > ...) > -------- > > > d. |
From: Daniel B. <da...@te...> - 2004-04-08 10:51:50
|
sm...@sp... writes: > Thanks for the boilerplate, I'll use it as a starting point! > > BTW, is there an asdf mailing list? Home page? Something other than cll? Try cclan-list (it's a sourceforge list; I imagine google should furnish subscription details) > Something other than cll? I stopped reading cll when I realised that I would rather be doing almost anything else, so posting anything there is a bad idea at least if you want me to see it. -dan -- "please make sure that the person is your friend before you confirm" |
From: Luke G. <lu...@bl...> - 2004-04-07 07:27:38
|
sm...@sp... writes: > Is C-c C-k an option if you are loading a system through asdf? There is a command `slime-load-system' that compiles/loads a system through ASDF, you could give that a try. Currently it's undocumented because I think we need sister commands for load/compile/compile-:force-t, but haven't gotten around to adding them. -Luke |
From: Nikodemus S. <tsi...@cc...> - 2004-04-09 12:04:39
|
On Wed, 7 Apr 2004, Thomas F. Burdick wrote: > It might make more sense to have a slime-operate-on-system command > that by default loads the system it finds in the current directory, > but when given a prefix argument, prompts you for the operation class > and system name. Just a thought: it might be feasible to ask ASDF "to what system does this file belong to", so slime-*-system could work independent of directory, defaulting to the system the current buffer/file corresponds to. This behaviour could be overridden with buffer local (if that's the right term) variable: ;; -*- System: foo -*- Cheers, -- Nikodemus |
From: Daniel B. <da...@te...> - 2004-04-09 14:54:29
|
Nikodemus Siivola <tsi...@cc...> writes: > Just a thought: it might be feasible to ask ASDF "to what system does > this file belong to", so slime-*-system could work independent Not easily in the current state of asdf, unfortunately. If you reach into its internals, I suppose you could find all the systems registered and then loop through each of their files, stopping when you reach the current file (but watch out for symlinks). I think you'd probably get just as good an answer by looking for *.asd in ., .., ../.. etc -dan -- "please make sure that the person is your friend before you confirm" |