libera/#sicl - IRC Chatlog
Search
7:21:55
hayley
I am a bit fed up with my naive arrangement adaptation code generator, so I am writing a better one with the original algorithm I had planned.
7:22:16
MichaelRaskin
beach: you are actually describing the _better_ case. I can see solving a simplified case to get understanding what's going on. But then they try to add effects to get closer to practical cases, and oh how their idea of «closer to practice» goes in the wrong direction.
7:22:24
hayley
Would it be possible to spill the current value of RSP to the stack, then use that as a temporary while performing stack-to-stack copies, then restore RSP?
7:25:27
hayley
("that" being RSP rather) If I could use RSP, then it would be unnecessary to find an unused register or spill a register, as otherwise RSP is not going to be used. And I don't think anyone is looking for the value of RSP during an adaptation.
7:31:41
beach
MichaelRaskin: It is fine with me to have them solve their theoretical approximations and get published for it. But it is not fine with me when they then claim to have solved the practical problem, and lament the practitioners for being stupid enough not to use their beautiful solutions.
7:33:06
beach
hayley: How about not allocating some register, say RAX, at all and use it as a scratch register.
7:34:44
hayley
beach: I'm pretty sure it is not too hard to spill a register for adaptation. So that shouldn't be necessary.
7:45:01
MichaelRaskin
beach: reality: they solve the approximation, and a solution of more practically interesting approximation is too annoying to sell because it is not enough improvement over theoretical status quo.
7:45:28
MichaelRaskin
(_then_ optionally act surprised practitioners don't use the theoretical solutions)
13:32:59
yitzi
beach: I've managed to get SBCL stepping and breakpoints to work in my debugger. The stepping is solid, but breakpoints are really shakey. I can confirm some of your statements in your SICL debugging paper. It is not easy to use or find the code locations.
13:35:56
yitzi
Stepping doesn't use breakpoints in SBCL. It uses a separate step-condition that raised when stepping is enabled via dynamic variable.
13:36:44
beach
Right, I knew that, but then your stepping facility works just like the one that the standard requires, i.e., you have to determine from the beginning what form to evaluate and step.
13:37:14
beach
Whereas in a real debugger, you would set a breakpoint, run the program, and then step from there.
13:37:58
yitzi
I can do that also. I add an ENABLE-STEPPING restart in my debugger which toggles the dynamic var and restarts.
13:47:13
beach
yitzi: So how are the roles divided between Jupyter and the Common Lisp implementation?
13:48:11
yitzi
Jupyter is using an abreviated version of the Debug Adapter Protocol. https://microsoft.github.io/debug-adapter-protocol/
13:48:56
yitzi
It the common lisp kernel has to receive and process various messages in that protocol. Jupyter handles all of the UI stuff.
13:50:36
yitzi
The biggest problem with that protocol is that it was clearly writted from a C debugging perspective. So no CL restarts. I had to come up with an extension to the "stopped" event to implement that along with my own Restart UI panel.
13:52:13
beach
That's what I feared, i.e., that it would have the same problem as the LSP so not adapted to the way Common Lisp works at all.
13:53:50
yitzi
Yeah, my workaround is decent, but there are still some issues b.c. interactive restarts will only work with code executed from a jupyter lab cell. The debugger is not currently installed on code that responds to button clicks, etc since there is no *query-io* there.
13:56:11
yitzi
And you can only debug the user execution thread b.c. their debugging panel can't switch to another stopped thread. The DAP supports that, but Jupyter debugging doesn't yet.
13:59:05
yitzi
Some of the limitations I maybe able to fix in time, but considering that only three other kernels support debugging and two of them are Python I think it works well considering that.
13:59:53
yitzi
And I will also try to support it in maxima-jupyter eventually also, since Maxima has a debugging facility.
16:22:21
beach
I am going to call it a day, but I'll stick around until my (admittedly small) family announces that dinner is ready in half an hour or so.
16:22:27
beach
I spent most of the day separating CLEAVIR-CODE-UTILITIES into separate, smaller, modules. That way, I don't have to load the entire system when I load the new SICL-PACKAGE system and I avoid some problems this way.
16:22:33
beach
The lambda-list parsing part of the code utilities have been problematic from the start. I import most of the functions during bootstrapping, which is fine. But loading that system is problematic because it parses lambda list types that it also contains, and it does it using instances of standard classes and generic functions. So I need to rethink the structure of that part.
16:25:25
beach
Currently, I think the solution might be to use higher-level functions to do the job. Right now I call parse-...-lambda-list, and I assume that it returns a standard object on which I can use accessor generic functions.