libera/#sicl - IRC Chatlog
Search
3:08:24
beach
Yesterday, due to better organization of the module that implements the package system, I split the existing system (which contained code for both the package system and for symbols) into two, one for symbols and one for the package system.
3:08:25
beach
Today is Monday, and Monday mornings are chaotic around here, but I will start imagining a test suite for the package system, since I now have an "extrinsic" version of it too.
3:14:42
beach
The package system is interesting for SICL in terms of metacircularity. I mean (in-package #:sicl-package) ... (defclass package...)
3:22:05
zephyr
beach i found your observation of practical vs theoretic great. i would add that the reason the theoreticians keep making this mistake is because practitioners would always rather practice than explain to a (stubborn) theoretician
3:22:33
zephyr
of course, the impatience of the practioner bites them in other ways, and it all evens out :-)
3:23:25
beach
Maybe so. But it works out well for the theoreticians. They get published and admired by their colleagues. I don't think they care whether what they do is practically useful. They leave that aspect to others.
3:27:54
beach
Either way, I have a bit more than 6 month until I retire, so I don't have to deal with them anymore. :)
3:40:29
beach
I once saw a presentation by a mathematician colleague who aspired to become part of our group doing analysis and synthesis of sound, and he explained a way to do frequency analysis using linear algebra.
3:40:33
beach
After several blackboards of matrix manipulations, he made an assumption about eigenvalues that he then said was an assumption about the phases of the partials being statistically independent.
3:40:41
beach
But then I pointed out to him that for most sounds we deal with, the phases are in lockstep. Only for some instruments, like piano, are the phases independent.
3:40:42
beach
He had made this assumption so that he could solve the equations that came up, but without considering the practical implications.
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.