freenode/#sicl - IRC Chatlog
Search
5:37:24
beach
And it now looks to me like we could design a bunch of panes each with its own display function. Then those panes could be assembled in different ways according to the taste of the programmer.
5:42:33
beach
Now, I am asking myself, is there any purpose in showing compilation messages the way they are done when I compile in a terminal. I would think that in an IDE, the programmer would rather want them in some code pane as tool tips on annotated code.
5:43:57
beach
I can see myself clicking on a button that then starts (asdf:load-system...) and no messages like "compiling this or that". Just (say) a bunch of tabs (or something better), one for each file containing a compilation message.
6:16:09
jackdaniel
so opening a pane for each file when you only want to load your system with these botched dependencies would be suboptimal
6:17:27
jackdaniel
if the file is opened and it is feasible, then annotations could be added and that pane/tab should gain some highlight that something has changed; but that shouldn't substitute "traditional" compilation stream log
6:19:06
beach
I guess we would have to make such a pane as well, and let the user choose whether to include it.
6:21:10
beach
But I think pjb is right in that I need to determine some workflow first, and then see how that workflow would be best supported with a bunch of panes.
6:24:36
jackdaniel
where each tool is a separate frame, and then adopt these frames in a single frame and add some piping (not ready in McCLIM yet)
6:24:58
jackdaniel
adoption of frames is not ready yet* but I have a working proof of concept with a shared pointer documentation, menu etc
6:46:59
beach
I think the solution with multiple frames is great when you have to add a program that was written as an independent application, but when you can design the entire thing from scratch, my hunch is that a single application frame is better.
7:01:34
jackdaniel
having integrated environment provides, well, better integration :) so I believe that your hunch is correct
7:01:57
jackdaniel
by piping I mean: "adding necessary plumbing so independent components communicate with each other"
7:02:28
jackdaniel
re designing from independent comopnents: a benefit of having such design is that you may rip one component for your purpose and easily reuse it
7:14:29
beach
So this discussion seems to suggest a design like Drei/Climacs, i.e., a pane class that does most of the stuff that needs to be done in a pane, and then an application frame that uses that pane as its main component, possibly adding functionality that a complete application needs.
7:18:47
jackdaniel
beach: what I'm thinking is more a monolithic climacs (a frame), that is adopted as a frame-pane in the ide as an editor
7:20:44
beach
I understand your idea. And I am saying that, if integration of a single pane is easier, then having an editor written as a pane class plus an application could make it possible to choose. A separate application can then use the pane class or the entire application.
7:21:24
beach
The idea of Drei was that it wasn't necessarily useful, say in the listener, to have a mode line, commands for finding files, splitting panes, etc.
7:21:52
beach
So that part became part of the complete Climacs application, and the pane class could be used independently.
7:23:04
jackdaniel
I think that drei is specific in many regards (i.e in that it implements i.e the input editing pane and relies on some mcclim-specific behaviors), so it is not a good example for such design (or maybe it is since it was reused in many places)
7:23:59
beach
Sure, it is entirely possible that I overgeneralize the usefulness of this kind of design.
7:24:07
jackdaniel
but yes, if you want to have ide, then pane classes and single frame provides the best integration
7:24:46
jackdaniel
on the other hand, it makes sense to have each component to have its own command table and translators (in other words - to be a frame that can be adopted as a pane)
7:25:24
jackdaniel
possibly such adopted frames would have multiple layouts where one is specifically tailored for embedding (i.e a single pane withotu toolboxes and the interactor)
7:25:53
jackdaniel
a frame that acts as a frame manager could have a non-standard command table which dynamically inherits from all adopted frames
7:26:11
jackdaniel
so you would have one interactor for all command tables (and one set of translators etc) for integration
7:27:28
jackdaniel
you could think of panes as widgets in other toolkits, while the frame stands fro an application
7:32:35
beach
I don't think splittist meant literally "the same thing"; just that the protocols would be the same and the choice could go either way then.
7:36:02
jackdaniel
yes, but if each component is meant to be an application then extra work is required to ensure, that it works without sibling components
9:00:09
scymtym
regarding yesterday's discussion of source information and condition reports: i my experience with in-buffer indicators and output for batch tools, this has worked best: the condition report mentions things by name (function FOO, variable BAR, fourth argument, etc.) but does not involve locations. the condition contains a list of "annotations", each consisting of a kind (error, warning, context, etc.), a "role" ("first definition",
9:00:09
scymtym
"second definition", "superfluous argument", "form of incompatible type", etc.) and a location. example of multiple source locations for a single condition in a batch setting: https://techfak.de/~jmoringe/bad-reader-conditionals-2.png the condition report is in the first line, the kind determines the underline color and the role is the text besides the underline. for in-buffer indication, the annotations are applied directly to the
9:00:09
scymtym
source as in the second climacs example: https://techfak.de/~jmoringe/second-climacs-error.png
9:06:02
scymtym
this is another (very old) example: https://techfak.de/~jmoringe/eclector-cst-toy.png
9:26:41
beach
In your batch output, do you list the entire input file, or just the places with issues, surrounded by some lines of context?
9:28:07
beach
And, in what situation(s) would you use information about the name of a function or a variable?
9:30:10
beach
The list "(error, warning, context)" seems strange to me. The first two appear to be condition subclasses, but what is the meaning of "context"?
9:31:53
beach
I also don't understand what a "role" is from your description, and none of the roles in the list is in the example output, so it is hard to tell what a role such as "superfluous argument" would be.
9:33:13
beach
I mean, the word "superfluous" suggests "it's OK to have it, but you really don't need it", but I see no such possible situations.
9:34:37
beach
Does "second definition" mean that there is more than one definition of the same name in one file?
9:40:07
scymtym
to answer the first question, only excerpts are shown. if annotations are close to each other, the excerpts are merged. otherwise locations in different files or far apart locations are shown as separate excerpts
9:41:58
scymtym
for the second question, names of variables or functions are things that could be mentioned in condition reports - as opposed to locations. so "In function BAR, call to undefined function FOO" as apposed to "In function BAR, in file bar.lisp, line 100, call to undefined function FOO"
9:44:33
scymtym
the (non-exhaustive) list (error, warning, context) characterizes an annotation as pertaining to something that is definitely wrong, that is suspicious/possibly wrong/problematic or something that is not itself wrong but is involved in a problem
9:50:06
scymtym
for the role, i have failed to give consistent examples. the idea is that the role explains what an annotation means in the context of "its" condition. if the condition is MULTIPLE-DEFINITIONS-WITHIN-A-SINGLE-FILE, the report could be "The function ~A is defined ~R times within a single file". this condition would have multiple annotations and the role of the i-th annotation would be (format nil "~:R definition" i). in this scenario,
9:50:07
scymtym
would probably use the kind "context" for the first annotation and the kind "error" for the subsequent ones
12:00:07
beach
heisig: Did you say you are about to modify the SICL specification? If so, what chapter (so that we can avoid creating GIT conflicts)?
12:01:51
heisig
Oh, have chapters disappeared? I am still viewing the PDF I generated a few days ago.