freenode/#sicl - IRC Chatlog
Search
15:27:00
scymtym
for my current employment: as before. that exceedingly likely to end at the end of october
15:29:13
scymtym
when we last talked, that depended on whether he would be able to acquire certain kinds of funding. we agreed to talk again later which would be about now i guess
15:39:33
scymtym
beach: regarding second climacs: my approach has been building from the reader upwards, trying to keeps modules small and reusable. for the user-interface i have used CLIM for debugging and demo UIs and LSP for basically the same
15:40:40
scymtym
when i looked at second climacs (briefly), it seemed complicated to me, too. but that could just be me not putting in enough time, of course
15:41:42
scymtym
my current feeling is that it would be best to make some kind of IDE service module that can be used from second climacs as well as an LSP implementation
15:42:45
scymtym
the hard problem with that would probably be incremental parsing and synchronization in general
15:43:16
beach
So it would be used over a wire protocol for other editors and in the same image for Second Climacs?
15:44:34
scymtym
for now, i will probably continue to build modules on top of the reader towards such an IDE service module
15:47:00
beach
I imagine that for long-term support you would need a serious goal, but you would also need intermediate results with planned dates.
15:48:41
scymtym
beach: yes and there seem to be frameworks for integrating roadmaps and financial aspects, but i'm still investigating
16:10:26
beach
I guess write a Cleavir-based compiler for SBCL, and just allow Clordane to debug code compiled by that compiler?
16:14:50
scymtym
what is the goal? making a clordane prototype? or improving the debugging situation for regular development?
16:17:49
scymtym
i'm not sure i understand. are you talking about a replacement for Python that would generate code which would work in SBCL's runtime system?
16:19:07
beach
And, like I said, it is unlikely that I can convince the SBCL maintainers to add such support.
16:19:39
scymtym
to be perfectly honest, that seems like a lot of work for uncertain benefits. i say uncertain because i suspect people would be wary about changing other characteristics of their compiler "just" for better debugging
16:21:08
scymtym
maybe SBCL can be patched to add such support. the compiler support for code coverage and allocation profiling is a bit like that
16:24:06
beach
I just can't see myself investing the time to understand the SBCL compiler. But it sound like you are saying that, if Clordane turns out to be a significant improvement, then some SBCL maintainer might be convinced to patch the compiler.
16:24:48
scymtym
now that i think more about it, this strategy would at best solve the poll-point/call-into-debugger-loop problem. it would not allow access to e.g. more lexical variable than is currently the case
16:26:22
scymtym
it could also be a patch in the more literal sense, or a separate branch. but as i said, preserving values for inspection would require more fundamental changes
16:27:49
beach
I don't see why lexical variables are not accessible. They are when a function calls another function, as is evident from the backtrace.
16:29:45
scymtym
you mean lexical variables are already made available by SBCL's debugger support? or they are not but should be?
16:32:34
scymtym
i sometimes think variables that should be available are not, but i can't come up with an example right now