* Madhu [2010-10-22 11:50] writes:

• Helmut Eller m2mxq6buaf.fsf@common-lisp.net :

Wrote on Fri, 22 Oct 2010 08:44:56 +0200: |> when (slime-compile-and-load-file) notices harmless Warnings during |> compilation, it prompts with |> (y-or-n-p "Compilation failed. Load fasl file anyway? ") |> |> There is no way for the user to scroll the *slime-compilation* window |> to see if the warnings are harmless or not, before he can answer `y' |> |> I would suggest giving the user an option like like in the appended |> patch, |

<snip>

|> and would find it simpler to add a new keymap for this situation, |> with new functions to scroll the buffer and also remap [next-line] and |> [previous-line] to the new functions so any user level override without |> modifying slime.el is impossible. | | Perhaps not quit that, but it seems that changing y-or-n-p to | yes-or-no-p would solve the problem more elegantly than introducing a | customization variable.

The tradeoffs aren't that simple for emacs users with experience:

• In the face of (fset 'yes-or-no-p 'y-or-n-p) which saves a few microseconds of developer time.

??? You mean there are people who execute (fset 'yes-or-no-p 'y-or-n-p)? Whoever does that deserves to lose.

• Implementations like lw and ccl refuse to find source via M-. (sldb-`v', etc) unless the file is compiled --- (C-M-x or C-c C-c will not cut it).

That's true for C-M-x but not for C-c C-c. Both CCL and Lispworks handle C-c C-c and C-c C-k similarly: in both cases we use COMPILE-FILE but for C-c C-c we give an extra parameter to say from which file it came from.

So if one wants M-. to work with slime, one is forced to compile that form in a file and load it, even if one knows that large parts of the file contain errors and will not be work or be called.

So what are you criticizing? that you need to use C-c C-k or that you can't be bothered to press y?

Refactoring one's work to a traditional C-style edit-compile-load cycle already hits development speed which lisp's Incremental Development supposedly provides. Now this `feature' adds another distraction during the "development-cycle", requiring more cognitive processing cycles and time on the part of the developer.

I don't disagree with what you said, but this, (like other features) does not pass the cost/benefit.

You mean, pressing y on false positives is more distracting than landing in the debugger on true positives? Or what "feature" are you taking about?

Helmut

In article m37hha9w0v.fsf@leonis4.robolove.meer.net, Madhu enometh@meer.net wrote:

• Helmut Eller m2hbge9yqm.fsf@common-lisp.net :

Wrote on Fri, 22 Oct 2010 14:51:45 +0200:

|> - Implementations like lw and ccl refuse to find source via |> M-. (sldb-`v', etc) unless the file is compiled --- (C-M-x or C-c C-c |> will not cut it). | | That's true for C-M-x but not for C-c C-c. Both CCL and Lispworks | handle C-c C-c and C-c C-k similarly: in both cases we use COMPILE-FILE | but for C-c C-c we give an extra parameter to say from which file it | came from.

I meant exactly what I wrote. It does not work with C-c C-c. CCL goes off goes looking for a logical file.newest. lw appends (instead of replacing) an entry with wrong dspec info that shows up in the xref buffer, and can mostly find the file correctly (but not the location).

You're saying that C-c C-c'ing

(defun bar (x) x)

and then pressing M-. bar RET will not get you to the right location on ccl and lw?

-T.

[see upthread for more context I have already given]

* Madhu m339rx9x1e.fsf@leonis4.robolove.meer.net : Wrote on Sat, 23 Oct 2010 13:10:45 +0530: | | You're saying that C-c C-c'ing | | | | (defun bar (x) x) | | | | and then pressing M-. bar RET will not get you to the right location | | on ccl and lw? | | With CCL, maybe Takehiko Abe's 2010-10-21 patch in | http://permalink.gmane.org/gmane.lisp.openmcl.devel/6452 | fixes it, (I don't know. I was using a binary only ccl-1.5 without any | sources.)

Sorry for that piece of nonsense. That was a dumb conjecture on my part. Looking at the contents of that patch, it cannot address the situations where I am seeing the bug; I have seen at least 2 situations, here is a test scenario for one.

? (setf (logical-pathname-translations "TMP") '(("*.*.*" #P"/tmp/*.*") ; <-line1 ("**;*.*.*" #P"/tmp/**/*.*"))) ; <-line2

;; The Bug probably is that CCL can only handle translations of the form ;; in line2

echo '(defun bar (x) x)' > /tmp/bar.lisp

? (load (compile-file "TMP:bar.lisp"))

? (bar 10)

Then in Emacs use M-. to find the (defun bar) form, then C-c C-c the (defun bar) form, then retry M-. bar

-- Madhu

* Tobias C Rittweiler [2010-10-22 16:24] writes:

In article m37hha9w0v.fsf@leonis4.robolove.meer.net, Madhu enometh@meer.net wrote:

...

| | So what are you criticizing? that you need to use C-c C-k or that you | can't be bothered to press y?

I wish to use slime-compile-and-load-file to compile and load and a file. Period. If I just want to load a file, I'd use slime-load-file. If I just wanted to see warnings/errors I'd use `slime-compile-file'.

The short discussion which eventually resulted in the current behaviour can be viewed here:

http://thread.gmane.org/gmane.lisp.slime.devel/9905

So there are at least 3 ways of doing things:

1. C-c C-k compiles and loads the resulting fasl file unconditionally.

   You can compile-only a file (C-c M-k), look at warnings and then explicitly load the file (C-c C-l), too.

   This kind of was the original behaviour except it was not entirely clear to me that all backends actually really implement that behaviour.

2. C-c C-k compiles a file, and loads the resulting fasl IF AND ONLY IF the compilation was successful.

   You can then look at warnings, and explicitly load the file via (C-c C-l) as an explicit after step.

3. C-c C-k compiles a file, and loads the resulting fasl IF AND ONLY IF the compilation was successfull.

   If compilation failed, the user is queried if the resulting fasl should be loaded, or not.

   That's the current behaviour. Using Y-OR-N-P makes it impossible to look at warnings. Using YES-OR-NO-P would kind of allow for that but would still make it a bit awkward (as you're kind of inside a recursive input loop)

Is that an accurate description?

Another way to say it: 1 and 2 are the same except that 1 uses a non-nil fasl file as success indicator and 2 uses the third return value of COMPILE-FILE. There is also an abort restart to return the current compiler messages to Emacs.

Are there more viable options?

Perhaps variant 0: try to load non-existing fasl files when COMPILE-FILE didn't create one.

For me, it's 2) that sounds most reasonable. I don't like

1. because I am totally entrenched in using C-c C-k.

OTOH, 2) might annoy people who're deeply used to the unconditionally loading bit -- in which case 3) is a compromise except it makes looking at warnings somewhat unwieldly.

3 does in fact display the warnings buffer; so if the important warning is (one of) the first there's no need to scroll. And of course it's possible to look at warnings simply by pressing n and use C-c C-l later as in 2.

I also find it surprising that C-c C-c does /not/ do the query bit at the moment. Unconditionally loading is annoying in case you're working with precious image state (running application), and then render your application useless (and lose your state) because you recompiled a crucial function with, say, a typo in it.

In my mind C-c C-c means compile-to-memory without fasl file. The compile-to-temp-file meaning probably also makes sense, but it's not what C-c C-c was originally intended for. It's probably also bit tricky to load a temp-file with C-c C-l.

In these precious-state circumstances I seldomly use C-c C-k in the first place, though, but rather use C-c C-c on a few key parts.

What about you?

Make no typos? Don't write crucial apps? Or more realistically: complain to compiler writers not to create/load fasl files for input with read errors?

Helmut