freenode/#sicl - IRC Chatlog
Search
13:34:23
Bike
for the purposes of debugging the compiler it is sort of useful to associate source information with the first kind of condition too. so that e.g. if you compile a big file and the compiler screws up on a form, you know which form it screwed up on. that can be done with handler-bind and a wrapper condition in the right places
13:34:57
Bike
ideally i'd probably throw something in so that if the compiler signals anything but a program-condition it's wrapped in a condition BUG or something
13:35:56
beach
Now, when we report a run-time condition, we end up in the so-called "debugger". If SICL is executed in a dumb terminal, we need such a debugger, and it is not terribly hard. In fact, the portable condition system supplies one.
13:37:05
beach
But I am not particularly interested in that case, and when we report a run-time condition in some IDE we get the backtrace inspector and that should work OK.
13:38:47
beach
In SICL for the terminal, the source information contains the program text as a string, so it can be reported that way. Again not terribly interesting as long as it is possible.
13:39:32
beach
For the IDE, I imagine a source buffer being created (unless it already exists) and the problematic forms being annotated in some way.
13:41:11
beach
So does that mean that we must duplicate large parts of the text in the condition handler in the IDE?
13:42:55
beach
But the tool tip is essentially the same as the condition reporter in the terminal minus the source information.
13:44:29
Bike
well, i guess the way clasp does it there is some duplication between clasp and slime, i think
13:45:11
beach
I guess if the condition reporter does not include source information, then it can be used in both the terminal and the IDE, but the terminal would have a condition handler that also presents the source information as text.
13:48:04
beach
And the analogous condition handler in the IDE would instead use the source information to annotate the code.
13:49:07
Bike
yeah, i think i get it. that's pretty much how it works in clasp. source info is displayed by a handler in compile-file.
13:51:16
beach
And I should go look at the condition reporters to see that they make sense both with a terminal and as a tool tip or similar.
13:56:19
beach
Oh, and I also want to "get rid of" Acclimation, in the sense that I don't want English-language condition reporters to depend on it. For SICL, that would mean to structure the condition reporting so that it trampolines to methods like the ones we now define with a LANGUAGE parameter.
13:56:19
beach
For SICL-specific code, I would still write the condition reporters separately in most cases, but the English-language ones would not refer to Acclimation. And we could accept condition definitions with a :REPORT option for code written elsewhere, rather than depending on everyone using Acclimation.
14:02:30
beach
I would still like to be able to accommodate such a library, and have it report conditions normally, while being able to write new condition reporters for other languages.
14:03:15
beach
And, I would like for our own libraries like Clostrum, Trucler, etc. to be usable for other Common Lisp implementations that have no desire to use Acclimation.
14:04:51
beach
So, somehow, I want the English-language condition reporters to look "normal", i.e. the way they would if Acclimation were not present, while still retaining the possibility of adding condition reporters for other languages. It may not be possible, or easy. That's what I am trying to figure out.
14:09:52
jackdaniel
condition reporting is mediated through the print-object; perhaps a slight abuse by specializing the stream (or defining an around method) could be used
14:11:22
Bike
i don't understand the looking normal thing. all acclimation does is define a generic function that the condition report calls. it doesn't impose any kind of formatting
14:12:20
jackdaniel
Bike: yes, but you must specify :report that-function; it is hard to expect i.e alexandria to depend on acclimation to specify that report function
14:12:42
beach
Right. But if (say) Alexandria does not respect this protocol, then we can't create condition reporters for Alexandria conditions in other languages.
14:13:26
jackdaniel
alternatively expand :report foo to something like (lambda (c s) (if *lang* (that-function c s *lang*) (foo c s))
14:14:38
beach
I.e., does the standard say that the :REPORT results in a call to PRINT-OBJECT? Or is it more vague about it.
14:15:06
jackdaniel
there is even: specyfing (:report foo) in the definition is equivalent to (and the code snippet)
14:16:17
jackdaniel
so it seems that a more conforming solution would be adding an around method to the print-object
14:29:42
jackdaniel
another way which I'm not sure about is using the pretty printer dispatch; however I've never used it extensively
14:30:14
Bike
i think you're supposed to be able to print conditions human-readably even when *print-pretty* is false.
16:43:58
beach
So one common complaint about Emacs is that it creates buffers and windows in a way that can neither be predicted nor controlled. Whether that is true or not I don't know, but the default behavior annoys me as well. So suppose we have an IDE with a REPL, and we want to keep the configuration of the different, let's call them panes, way more fixed than Emacs does.
16:43:59
beach
Now suppose I start a compilation (asdf:load-system...) in the REPL, and there are compilation errors/warnings in several files. How should this situation be presented to the programmer? Maybe a tab for each file in *the* pane that shows source code?
16:57:51
splittist
Some IDEs have a compilation results tab in the 'repl' pane that shows errors, warnings etc. There are often also indications against file-names in the project tree pane, and indications in the margin of each buffer at the offending line.
17:00:09
splittist
Sometimes there is a visual/spatial differentiation between interactive 'terminal' areas and editing areas (although obviously one at least 'line edits' in a terminal).
17:00:18
pjb
beach: It's a diffcult question. Basically in emacs, windows belong to the user. In more structured IDE, windows belong to the IDE. Perhaps some people like that, I find it more difficult to work with such IDEs…
17:00:56
pjb
beach: the thing is that emacs is highly non-modal. So, compilation results are not integrated in a work flow. They're just dumped in a buffer, show in a window, and let the user deal with it.
17:01:30
pjb
beach: more structured IDEs impose, or strongly hint at specific workflows, hence a structure of windows. (I keep emacs terminology).
17:02:16
pjb
beach: so perhaps we could start with that, define some workflows, and a set of specfic windows that will be used by the different inputs or outputs of the workflow.
17:03:40
splittist
There's the whole windows in registers thing, too. Although it's always C-x 2 - no wait, I meant C-x 3; C-x 4 'where will this appear'; next window, no, not that one, this one; C-x 0 - start again (:
17:03:45
pjb
Now, tab are a good idea, until they're not. Ie when there is a small number of tabs, they're ok, but soon enough there are a lot of them and they become unmanageable… So be careful with them.
17:04:22
pjb
yes, and there's the split horizontally or vertically, depending on the task or the size (aspect ratio) of the frame!
17:04:49
splittist
Perhaps one should be thinking of multi-monitor from the ground up. If not multi-monitor+multi-virtual-desktop
17:07:36
beach
ACTION is still here because his (admittedly small) family is in a virtual meeting so is unable to serve dinner on schedule.
17:09:44
beach
The other thing I have been thinking of is to structure the workflow around "modules" as defined by ASDF system definitions. Then, the position of files in the file system would be less important. But I suppose not everybody works the way i do with such things, so it would have to be some kind of option.
17:10:57
pjb
I wouldn't mind if a new workflow would create a new frame with its fixed windows inside.
17:11:41
pjb
What people complain is probably when emacs changes the windows they've careful set up for their own workflow.
17:39:34
beach
I guess the way to go would be to let the user configure the different panes. Like we just propose different panes that work in different ways, and the user can build a custom IDE out of those.
17:47:27
pjb
I like when systems have memory. If the user moves a window, next time we can create a similar window in the same place.
18:21:17
jackdaniel
(format-graph-from-roots (list "clim-basic") #'print (lambda (s)(ignore-errors(asdf/system:system-depends-on(asdf/system:find-system s)))))
18:21:38
jackdaniel
this ignore-errors is because I didn't bother to parse dependencies like (:version "flexichain" "1.5.1") or (:require "sb-introspect")