freenode/#sicl - IRC Chatlog
Search
9:24:26
beach
In less than an hour, my favorite coauthor will come over for lunch, so I'll be a bit busy for the next few hours.
9:45:30
beach
Technically yes, but she has been largely unable to do any useful work for quit some time. She is too busy with other stuff. :(
9:46:16
beach
So I need to think about either finding someone else to work with, or take the time to do it myself.
14:47:12
beach
scymtym: It looks good. Am I right that, in order to use it, I would handle the specific conditions, pop the top of my explicit stack of pending parse results and create a specific one according to the condition, and then invoke the recover restart?
15:01:34
beach
scymtym: You seem to have all the code that is required for parsing Common Lisp in a text editor, and you seem to have a better system than I do for computing indentation. So I have a suggestion. It is fine with me if you ditch all the contents in the Syntax/Common-Lisp directory of Second Climacs and replace it with yours. It is only a bit more than 2k lines of code. And I am sure your code is smaller and better anyway.
15:03:05
beach
scymtym: Alternatively, you can ditch all the rest as well. That's just another 3k lines. And, while I did my best to make it modular, I think I overdid it, so I was not that happy with the result anyway.
15:04:36
beach
scymtym: Plus, at this point, you are more familial with McCLIM than I am, so I am sure you would do a better job on the GUI code as well.
15:05:07
beach
scymtym: I am not particularly attached to my code. I just want to see this thing done.
15:07:39
beach
I have no plans to work on it for the next few months, though I may get bored with SICL and do something.
15:09:21
beach
I know that scymtym is working on a few pieces of the puzzle, as is obvious from his demos, but I also know that he is unwilling to announce public commitments to specific results.
15:10:30
ck_
Okay, thank you. I just wondered whether there was some grand plan with dates and everything.
15:10:42
beach
Another piece of the puzzle will require the first passes of Cleavir, namely the incremental analysis of the code in a Second Climacs buffer.
15:11:43
beach
So for the Cleavir part, I need incremental first-class global environments, which I haven't implemented yet.
15:12:19
beach
And It is still unknown whether Cleavir performance is good enough to handle this stuff.
15:12:57
beach
And the conditions that Cleavir signal would have to be turned into data that Second Climacs can present to the user.
15:15:17
ck_
I feel hurt on the performance-oriented-personality side :) "... but I already _know_ emacs"
15:16:36
beach
I would still use it for most other things, at least until Second Climacs acquires most of the other features I use in Emacs.
15:17:52
beach
What I am hoping is that the accuracy of the analysis will be so good that it will be irresistible. If that happens, a lot more contributions will happen.
15:18:44
beach
Plus, performance will be much better, provided a decent Common Lisp compiler is used to compile the code.
15:19:48
beach
And I use better data structures than Emacs does. The buffer is better for instance. And the Common Lisp parser does not use regular expressions.
15:21:20
beach
So the plan for Second Climacs seems clear. I am a lot more worried about Clordane because it will require support from the implementation that I am convinced the maintainers of existing implementation won't be willing to work on.
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