freenode/#lisp - IRC Chatlog
Search
13:50:31
jcowan
The main difference is that SRFIs don't get finalized until there is an implementation, preferably a portable one, or at the very least a strong implementation sketch (at the editors' discretion). A SRFI can't be a naked idea.
14:50:03
luis
Ahrg. I suck at remembering names. I was discussing some vlime/swank ideas with someone here the other day but I don't remember their nickname.
15:21:11
luis
sjl, flip214: in discussion at $WORK it occurred to me that another interesting use-case for thinking about the conversion from SWANK sexps to JSON would be the implementation of an LSP server (langserver.org). I suppose the hook we were discussing could be used to convert between SWANK sexps and LSP messages as well (but there might be other proto
15:21:12
luis
col requirements). In any case, I don't if this langserver protocol is a good match for Lisp; maybe it's fine for some features.
15:21:59
luis
But, maybe an LSP server just needs to call SWANK operations and massage the messages into the LSP format.
15:22:36
sjl_
I think an LSP server for Lisp would be good, because it would add editor support to a ton of other editors for free. People could ease their way into things instead of hitting the "you must learn emacs" wall immediately.
15:23:44
Xach
I'm really curious about the capability. I hope it's not like other situations where the relatively rare features of Lisp make a generic underlying thing unsuitable (or at least difficult)
15:23:55
sjl_
And yeah, I'd imagine an LSP server would mostly just use SWANK as a utility library to do the heavy lifting on the backend. LSP has a pretty specific set of messages it wants, I don't think it corresponds 1:1 with swank's protocol
15:25:52
dim
LSP is about a “language server that can provide code completion, hover tooltips, jump-to-definition, find-references, and more”
15:26:07
fe[nl]ix
luis: I doubt it has any support for restarts, restarting frames in the debugger, etc...
15:26:49
dim
I'd be surprise that there's something so strange about editing lisp code that the LSP protocol wouldn't make sense, it's just that they won't probably include the listener?
15:27:05
luis
Sure, but it's probably good to have those features handled the IDE's LSP-aware functionality and focus on Lisp-specific features.
15:28:38
dim
then later when they see what SLIME offers with a full REPL including debugging and the listener they might want to reconsider the traditional edit/compile/run cycle, but well
15:29:50
luis
dim: my point is that you want to write a Lisp plugin for cool-editor-of-the-day, you can get the LSP features for free and focus on implementing Lisp-specific features like the REPL/restarts/whatever
15:30:17
jackdaniel
I think it didn't provide any means for interactive development. otoh I don't think they would object if someone would propose such features for the next version of this protocol
15:34:08
sjl_
It doesn't have to have feature parity with emacs immediately -- there's value in having *some* support in other editors even if it's not perfect.
15:39:59
sjl_
When I looked at LSP it didn't have anything REPL-related in it. But of course you can use the vanilla SBCL REPL for the server process (with rlwrap or linedit or whatever).
15:41:03
sjl_
And LSP does have some capability negotiation built-in, so you could have the LSP server advertise an "evaluateForm" action and if the editor plugin supports it, cool. Or the user could map it themselves.
15:41:12
dim
yeah you could have the REPL on the side and just reload the whole project each time you want to play in there, with (ql:quickload "current-project") after editing
15:42:05
dim
when doing extensive changes, or changes in exported symbols in several packages, then I often do that anyway at the REPL before continuing with my testing/fiddling around
15:42:57
luis
Some of LSP's messages are things like "user opened this file" or "here are the whole/changed contents of this opened file". We probably don't want to do anything in that case. BTW, this is not just for cool-editor-of-the-day, apparently there are some LSP-aware packages for Emacs, though it seems sad to use JSON-RPC instead of Elisp/sexps in that
15:44:28
sjl_
heck, just (bt:make-thread (lambda () (watch-for-changes-with-inotify-or-something (ql:quickload :current-project)))
15:48:01
sjl_
luis: the file changed messages could help swank fix its line locations when you edit a file to move stuff around without evaluating
15:50:51
jdz
I personally save files way more often than they are in a compile-able state. Probably a habit from the old days when I've lost half-a-day work because of not saving files.
15:51:57
sjl_
an alternative is to use tmux or whatever and have a key in your editor to send the (quickload foo) to the REPL split
15:51:58
jdz
LispWorks also has a feature (at least had) that tracked changes in files and could recompile only the changed expressions.
15:52:55
sjl_
LSP not having everything you could possibly want for lisp development built-in doesn't mean it's not worth using.
15:54:28
jdz
Emacs itself has a mode that tracks changed parts of files, but I've found it more troublesome than useful back in the day.
15:54:50
sjl_
Anywhere, there's a 2-year old repo at https://github.com/cxxxr/cl-lsp that has a license now. Unsure if it's worth using as a base, or if the protocol has changed too much since then to make it viable.
16:24:56
pfdietz
I will also sometimes use methods as a way to check argument types. And in SBCL, type declarations are assertions at safety 3.
16:35:23
asarch
How would you write an application just like "tail -f" work? (I mean, it would inspect for new content of a file)
16:37:34
flip214
asarch: seek to the end of the file, remember the position, seek to the end of the file, check whether the position changed.
16:43:14
anamorphic__
asarch, perhaps use an existing implementation as a guide, eg. https://git.busybox.net/busybox/tree/coreutils/tail.c#n340
17:33:30
pfdietz
Use defgeneric as you might use the declaration of a function signature in C. Also, it's a place to hang the :documentation string for the whole function.
17:34:07
pfdietz
SBCL used to issue style warnings if it encountered a defmethod without first having seen the defgeneric.
18:17:15
jackdaniel
I'd even say taht for exported interfaces you should have defgeneric for accessors/readers too
18:19:00
pfdietz
SBCL did not issue style warnings for those in the absence of defgeneric, but the documentation would be good.
18:20:56
jackdaniel
I'm saying that, because with time readers may deteriorate and become normal methods anyway, but the interface doesn't change
18:22:13
jcowan
Makes sense to me. For every method a defgeneric, even methods not created by defmethod.
18:32:22
pfdietz
The interesting style question to me is: what to name these accessors? The potential for collisions of short names is high.
18:34:04
shka_
personally i name accessors access-size, read-size, write-size but this is NOT mainstream
18:34:36
jcowan
I guess that within the scope of an app the accessors should be named after the domain objects of the design
18:45:55
Xach
I consider the notion that they are associated with a slot to be an implementation detail
19:06:36
pfdietz
I often use slots as exactly that, populating the cache with a slot-unbound method.
22:28:41
no-defun-allowed
okay i finally realised something very very stupid about disassembling car/cdr
23:14:14
pfdietz
That's right. And the low order bits of fixnums are zero, so addition and subtraction work just fine.
0:57:08
sjl
cl-ppcre:all-matches returns a list of (start1 end1 start2 end2 start3 end3 ...) but I only want to print the starts
1:18:45
Bike
"A common trick is to use capturing technique inside an unanchored positive lookahead" oh god, what the hell