freenode/#sicl - IRC Chatlog
Search
11:47:32
scymtym
when i looked at LSP, it focused on static analysis, refactoring (e.g. rename variable) and navigation (e.g. goto definition, find references). the specification was rapidly changing at the time, so it might do a very different set of things now. there are also language-specific extensions as well as a separate, similar protocol for integration of external debuggers into IDEs
11:49:25
scymtym
here is a somewhat outdated version of my implementation: https://github.com/scymtym/protocol.language-server/tree/future
11:52:09
scymtym
i think this is the most comprehensive demo of what a system using this LSP implementation could do in Emacs: https://techfak.de/~jmoringe/eclector-context-completion.ogv
11:54:12
scymtym
ACTION should get back to that. with current eclector all of that should work without carefully avoiding syntax errors and incomplete inputs
12:02:51
scymtym
heisig: pay me to work on it full-time. but seriously, i'm not releasing most of this because it is a collection of prototype-level software that i have no hope of supporting with my currently available time
12:08:04
heisig
I fully understand. I'd volunteer to help, but my time is also not what it used to be. Have you tried to attract other contributors, e.g., from #lisp?
12:10:49
heisig
Oh, and while I can't pay you full-time, I could at least make some donations. Do you have some flattr or whatever account?
12:11:10
scymtym
my development style and slow pace for this prototype stuff makes it unsuitable for collaboration, i think. it is also easy to waste what little time i have on collaboration overhead
12:13:29
scymtym
thanks for the offer, but the problem is time not money so only a more radical change would have an effect. my contract will run out soon (again), though :)
12:15:56
heisig
ACTION wonders how much money we could raise in the CL community for such an endeavor.
12:17:40
scymtym
when i last looked into this, i have read about a model in which an organization collects the funds and employs or contracts individuals for specific projects
12:25:27
MichaelRaskin
Also, maybe ask around if someone is willing to accept stewardship and Do Something with submited patches?
12:38:44
beach
selwyn: Right. That's not possible for SICL, though someone else might slip it in for their own personal use, now that we know that we can do everything with generic functions.
12:47:10
Bike
shouldn't sicl have the ability to work with "unboxed" 64 bit integers anyway? i mean, you can change bignums later, of course
12:53:48
heisig
SICL should definitely support unboxed 64bit integers. There are plenty of algorithms that require power-of-two sizes, and there are exactly zero machines that don't provide them.
12:55:01
beach
Right. I would need to give some serious thought to how such support would be provided.
13:05:31
froggey
I use ub64-based bignums but didn't have any compiler support for unboxed ub64 arithmetic until recently. I had to write a significant part of the bignum code in assembly, seriously not recommended
13:09:41
beach
So how would that be done? Insist that any function that takes unboxed arguments or return unboxed values be inlined?
13:13:16
lonjil
You could have a special calling convention for functions on unboxed values, but it would only work for some function signatures and only if the function can't be redefined.
13:13:19
beach
And then perhaps write the code so that bignums are possible when inlining does not happen, and count on pairs of box/unbox to be removed?
13:14:33
heisig
beach: I don't understand what you mean with 'bignums are possible when inlining does not happen'.
13:15:15
beach
heisig: There might be a declaration and a type check for (unsigned-byte 64), but no particular action to prevent bignums from happening.
13:15:52
beach
So then box/unbox would be inserted normally, and should the function not be inlined, there will be a BOX in there and a bignum would be created.
13:17:06
beach
But when the function is inlined, there will be an unboxed value with type (unsigned-byte 64), and then a BOX instruction and then an UNBOX instruction, so that the result is again an unboxed (unsigned-byte 64).
13:19:22
heisig
That would be one way. The other way would be that box/unbox instructions are only inserted after inlining and type inference.
13:19:55
heisig
Either way, it will be possible to implement bignum+ on a vector of element type (unsigned-byte 64).
13:21:58
heisig
Absolutely. As they say, the biggest speedup is when a code goes from "not working" to "working" :)