1. Sergey Kolos
  2. lispdev


lispdev / org.lispdev.main / todo.txt

TODO: indenting in editor


Project (or just a file). Can load whole project or just a file into a lisp runtime (swank).
Can use new already started runtimes. With each runtime we have associated repl (console).

When project is created ask which which runtime to load.
Project tracks which runtime it is loaded to, but removes them from track list
when runtime is stopped (disconnected)
The project can be loaded into many runtimes, but it can be associated with
just one. 

Breakpoints in the project are activated for all runtimes.

Warning, errors, coloring, help in infopops and autocompletions
will depend on which runtime project currently is associated.

------- debugger

See page 42 of basic debug tutorial:
Will need to implement IProcess

IProcess -> lisp with swank?
IDebugTarget -> repl?, contains
  - IThreads
    - IStackFrames
      - IVariable
        - IValue
Debug capabilities:
 The standard debug capabilities are
  Step (over, into, return) IStep
  Terminate ITerminate
  Suspend & Resume ISuspendResume
  Disconnect IDisconnect
  Drop to Frame IDropToFrame
 The standard debug elements implement standard capabilities
IDebugTarget extends ITerminate, ISuspendResume, IDisconnect
IThread extends ITerminate, ISuspendResume, IStep
IStackFrame extends ITerminate, ISuspendResume, IStep
 The debug toolbar buttons/actions operate against these interfaces

 A debug event describes something that has happened in a program
being debugged or in a running process. 
  An event has a type (kind) and detail code
  The user interface requires debug model elements and process 
implementations to generate the debug events. For example:
  Required events are specified in the DebugEvent class

Detail codes describe why an event occurred:
  A suspend could be caused by: STEP_END, BREAKPOINT, 
  A resume could be caused by: STEP_INTO, STEP_OVER, STEP_RETURN, 
 The debug platform provides event notification
  DebugPlugin.fireDebugEventSet(DebugEvent[] events)

Debug platform provides LaunchConfigurationDelegate

 The debugger provides a console to display the standard I/O streams of 
a process
  For each IProcess added to an ILaunch, the debug platform allocates a 
console attached to its I/O streams
 std.out and std.err are written in blue and red
 Keyboard is attached to std.in - input is buffered and written to std.in
when <Enter> is pressed

Checklist: Create Your Debug Model
1.   Create implementations of IDebugTarget, IThread, IStackFrame, 
IVariable, and IValue
  Also create classes to support communication with the actual target
2.   If your target is not a standard operating system process, then also 
create an implementation of IProcess.
3.   Instantiate your IDebugTarget in your lLaunchConfigurationDelegate


launcher starts lisp process (with swank) and attaches to it
debug target ...
debug target is a bridge to lisp: i.e. sends requests and generates events
once responses for requests received back

swank runnable will be used for services. main functionality is done
through events

events change states of subscribers


ui for launch/debugTarget/process:
debug + variables view,

so - several views

state is maintained by debugTarget - not really, debugTarget sends
info to listeners

description of states, what is available in each state and how to get from
one state to another:

repl prints results or in two waiting states:
eval and read

each thread-frame maintains its own eval or read state and corresponding
repl console

the main thread is repl thread

each repl can be only in two states: eval and read

once debug suspend events appear, debugTarget suspends one of the threads
and (the thread should become selected - so have selection queue, since
once done with one debugging might start another debugging
however selection queue can be modified if thread no longer suspended

even though a thread can be waiting for user input, it is not considered
to be suspended (i.e. suspended is different than working)
if thread is in suspended state or eval/read - can get values of variables


how to deal with swank protocol?

- given event and a result, produce corresponding structure 
to be used by lispdev

to decouple the rest of plugin from swank protocol, make ISwank to
specify a limited set of send commands, each of them can produce a bunch of
signals - either to passed runnables or to registered listeners.
By specification of which command produce which signals will specify
rigit interface between lispdev and swank.

So all infos will be swankrunnables, but result node is private,
can be set, but cannot be read. Instead get result values through 
lispimplementation transformation functions.

asyncExec - will call run at appropriate time
right before calling run, locks runnable, sets value of result LispNode,
then calls run

runner class - takes in runnable and


- start eclipse with lispedv
- create new lisp file
- input:
(defun f (x)
  (+ 3 x))

(defparameter a 3)
- defun part can be collapsed, but when this happens, there is
spurious duplicate (defparameter a 3) in the editor

// next step 

internals of inspector:

on hover calls resolve() function of varResolver field of repl (LispConsoleViewer)
and sends variable name and id (as described in inspectable)

resolve() function calls LispImplementation.inspectReplResult()
(see ReplConsolePage.createControl)

The function returns a LispVariable.
LispVariable creates its LispValue. Each LispVariable and LispValue
knows which other LispValue or LispVariable is its parent.
There are two constructors for LispValue: the one where value string is
supplied and without. When value is not supplied, inspect is called to
find it out.

To inspect a variable which is not at top level, the swank inspector has
to be walked to corresponding level of inspecting tree (at each branch
it goes deeper with inspeckNthPart command). So when the inspect is called
on a value, it first calls inspect of its parent (which is corresponding
variable), which first calls inspect of its parent (which is a value) etc.
until root of the tree. Root of the tree is entered through inspectable, which
has unique id.


Add swank event viewer.

Change thread label to reflect why paused (through presentation model - see


Add automatic Repl scroll down


Frames do not disappear when resumed. Need to close and open tree for them
to disappear.


If just one lisp is opened, default to load etc. in it


There is one lisp active at any time. It is selected by selecting which
repl to show. Once it is shown, whole environment is changed for it.
Lisps are identified through ILaunchConfiguration.

Each project can be associated with many processes. Actually should be launchers.
Each launch can be launched just once.
Can change association on the fly. When changing association, compile
markers should be updated. I.e. each project should keep list of markers
for each launcher. The easiest, keep all markers, but change their attributes?

Bugs - odd behavior:
Load a project in sbcl. One comment contains #<PACKAGE "ASDF0">
Inspect it - get into debugger (this should not happen)
Once in debugger inspect first frame - new debugger started? but
nothing showed this. Sending frames for locals doesn't produce anything (no
return from swank).


Active lisp connects with each other:
repl, process (with its swank), config
given config should be able to get repl or process. process can get through
SwankPlugin, repl should be able to get through repl plugin


How to switch markers:
Two types of compile markers: one is subtype of regular ones, that are
displayed, second type is not a subtype of regular ones, so hopefully
they are not displayed. Each marker has attribute, which identifies
config it is related to.
When a marker is created its resource is noted in markers map.
When switch from config1 to config2:
- check resources for config1 and replace all markers with same markers but
not visible ones.
- if a resource doesn't have markers, remove it from resources for config1
- check resources for config2 and replace all markers with same markers but
visible ones. If 

 All this info is stored in a marker when it is
created. Have map, which tracks resources, where compile markers were created
for which config. When change active config:
- Save all info on markers associated with current config (for each associated
resource), also remove associated resources, if they don't have markers.
- Delete all saved markers from resources.
- Get resources associated with new config and add markers from new config.


General structure:

Create console interface, so that can replace by others, and make extension
(maybe later)


main - extensions, interfaces