freenode/#clim - IRC Chatlog
Search
12:34:39
lukego
and maybe dive into the Emacs sources a bit to understand why it's so cagey about problems with (create-image ...) arguments seemingly just ignoring stuff that has no obvious deficiencies
12:35:04
lukego
thanks! and thanks for the poke to do one, I hadn't considered it would be possible, they really had great organization
12:36:25
lukego
I guess anyway that if you're stuck in the pergatory of Emacs for an extended period then it behoovs you to give it a coat of paint now and again even if you would like to move into a new place later :)
12:37:23
lukego
I hadn't really done the remote conference thing, and only partly attended because the kids were home from school, but I was surprised how well the whole thing worked. good MC'ing to give it all a sense of cohesion and continuity. (my thought had been that a remote conference is basically just a youtube playlist but it's definitely more than that)
12:38:20
beach
Last year, it was pretty much like that. This year, they did a much more ambitious job, and with great results.
12:41:38
jackdaniel
the name clime may be slightly confusing, becalue it is also a nicname of the package clim-extensions
12:41:47
scymtym
lukego: i missed the conference but watched the recordings. i didn't see your lightning talk. when did you give it?
12:42:37
lukego
scymtym: yesterday. i put a copy up if you're interested, there are links in the desc. https://www.youtube.com/watch?v=XOaVm7EQZAM
12:44:56
jackdaniel
I've looked into the specification of svg the other day and it looks that it is a tremendous format that requires implementing around 40% of the web browser (including js)
12:45:27
lukego
jackdaniel: ah hadn't thought of that. I'm not using the name CLIME anywhere on the lisp side atm though, it's mcclim-emacs package
12:47:13
jackdaniel
from other historical curiosities, the clim client meant to talk with swank developed before I've even knew about CLIM was called SWINE
13:03:34
lukego
jackdaniel: Emacs just takes the SVG and calls out to imagemagick to convert it into a bitmap before doing anything with it. so in the context of CLIME SVG is just an efficient compression method for bitmaps that happen to be made up of geometric shapes and text.
13:04:21
lukego
makes the backend drawing code simple e.g. (format stream "~&<ellipse cx='~F' cy='~F' rx='~F' ry='~F' fill='~A' stroke='~A'/>~%" ...)
13:06:25
jackdaniel
I know; I'm just disappointed that it is not a vector graphics + animations format
13:07:04
lukego
I think animation will work pretty okay in CLIME btw albeit at modest framerates e.g. 2fps :)
13:07:40
lukego
okay maybe "animation" is an overstatement but I do plan to add support for in-place updates of the panes by sending a new SVG with an ID.
13:08:18
lukego
there's actually some list-of-frames type support for animation built into emacs too come to think of it, might be usable, not sure
13:09:36
lukego
can do neat stuff with emacs sometimes. I did a slime talk using emacs slideware at ECLM way back when and I got smooth fade-in/fade-out between slides by "animating" the rgb values in the emacs color palette
13:10:25
lukego
(old trick from the amiga which also had limits on the number of colors that can be addressed at one time)
13:46:11
lukego
(presentation-typep foo 'string) => NIL ;; foo is a STANDARD-PRESENTATION of type string ?
13:47:56
jackdaniel
presentation-typep is like typep except that the *second* argument is a presentation type, not a common lisp type
13:47:58
lukego
ah okay. i guess this is a reasonable first approximation for deciding whether a presentation is suitable for (accept 'string) ?
13:50:37
jackdaniel
it is a 'naive' approximation; what you really should do is to check translators in the current command table
13:51:45
jackdaniel
if you ignore the right thing (that is the function test-presentation-translator), then you can (as an approximation) do
13:52:31
jackdaniel
because, say, you have a presentation object 42, presented as, say, (present 42 'answer-to-everything)
13:52:51
jackdaniel
when you accept integer, you don't want that 42 to be applicable (unless the answer-to-everything is a subtype of integer)
13:59:54
jackdaniel
lukego: you may want to read a file in Documentation/Notes/presentation-types.org
14:06:48
lukego
hm, *input-context* is not bound in the call I get to STREAM-ACCEPT, guess I need to trace where ACCEPT-1 comes into this
14:07:15
lukego
I seem to recall thinking that ACCEPT-1 was too specific and choosing a different inheritance class but maybe that was mistaken
14:10:53
lukego
I'm currently inheriting EXTENDED-INPUT-STREAM rather than STANDARD-EXTENDED-INPUT-STREAM so I don't get the default method for STREAM-ACCEPT. Is this right and I just need to look at ACCEPT-1 for inspiration?
14:11:37
lukego
(do I even need to set *input-context*? Emacs won't see that Lisp special variable anyway)
14:12:04
lukego
ok thanks I'll peek at the code and have a think, err on the side of oversimplification for now
14:12:43
lukego
okay thanks for the explanation, I now understand better & also why my question didn't mean quite what I thought it did :)
14:30:03
lukego
I'm also tempted to put a STREAM-ACCEPT method straight onto SLIME-INPUT-STREAM but I'll put that to one side and insist on a proper CLIM stream
15:00:18
lukego
progress? now ACCEPT calls Emacs and Emacs always chooses the presentation with id 1 :-)
15:00:44
lukego
but Emacs knows the presentation IDs that are acceptable so let's see what we can do with that..
15:05:50
jackdaniel
it is not even a replacement, schedule-timer-event was a wrapper around schedule-event
15:14:45
lukego
hm I wonder if there is a way to define a CLIM:STREAM-ACCEPT method specialized on SWANK:SLIME-INPUT-STREAM but without knowing which is loaded first between SWANK and McCLIM...
15:16:30
jackdaniel
(defmethod initialize-instance :after ((class standard-class) &key name) (when (lukego-symbolp name "SLIME-INPUT-STREAM" "SWANK") (defmethod …)))
15:17:56
lukego
Maybe the swank side of CLIME could poll for McCLIM being loaded on each request. not that unreasonable since this code would only be loaded if clime is enabled in the emacs config.
15:38:40
lukego
I really have this stuff swapped out... the interactions between Emacs and Lisp when you can have multiple Emacs connections, multiple Lisp connections, multiple threads, multiple requests from the same thread in Lisp recursive debugs and Emacs recursive edits... better find some existing code that matches closely the ACCEPT workflow if there is some...
15:40:07
lukego
it's very tempting for ACCEPT to be synchronous in Emacs, or at least to follow stack discipline by entering recursive edits such that the most recent ACCEPT is answered first, but not clear that this works with the Lisp side e.g. what if two threads - or even two separate Lisp processes - are both doing ACCEPT at once...
15:40:40
lukego
and synchronous accept is generally awkward in that you might well want to go scrolling around your buffers to find the object you want
15:40:45
jackdaniel
when you edit a lisp file then at most one inferior lisp (and slime connection) is associated with it
15:41:56
lukego
So at the moment ACCEPT calls (SWANK:CLIME-ACCEPT-IN-EMACS ACCEPTABLE-ID-LIST) which sends (:ACCEPT THREAD TAG ACCEPTABLE-ID-LIST) over the socket.
15:42:54
lukego
Then Emacs can take the acceptable-id-list and turn that into an input context i.e. suppress unacceptable presentations. then when a presentation is accepted Emacs can see which SLIME connection that presentation is associated with i.e. where to send the reply. THREAD and TAG could be associated with that connection.
15:43:58
lukego
How about if multiple ACCEPT requests are pipelined? input context is per-connection so ACCEPT from different Lisp processes wouldn't be weird but from two threads of the same process is harder -- which will be the "current" input context?
15:44:42
lukego
tempting to say that the most recent request is the current input context. that would at least work for recursive stuff on the Lisp side e.g. if you interrupt the thread that's blocked in ACCEPT and then do a further ACCEPT call in the debugger
15:45:31
lukego
eventually I'll probably need to expose the input context to the user e.g. if you select an object that's acceptable for multiple input contexts then you are prompted to say which one you want to dispatch it to
15:45:38
jackdaniel
but McCLIM is not there yet (I didn't even think how we could incorporate that into existing infrastructure - probably with some frame manager magic)
15:46:04
lukego
thanks for indulging the braindump, I think there's a simple initial solution up there ^^^
15:47:15
lukego
I think that I'll keep a stack of input contexts for each connections, on a list and separate from the Emacs stack, and ACCEPT responses will be dispatched to the top of that stack
15:48:08
lukego
one other "later" thing is that at the moment presentations will be associated with a specific SLIME connection but I'd prefer to associate them with a Lisp process. that way Emacs presentations would still be valid if you reconnect to the same process later. but one thing at a time
16:37:59
loke[m]
jackdaniel: Yeah, that's why I didn't want to go into it until I have something concrete (probably need to do a bisection).
16:38:47
loke[m]
Anyway, time to sleep. I will try to get Cimaxima back to a functioning state this weekend.
17:55:01
lukego
I dunno. If I were in my 20s I'd say that Wednesday is "little saturday" and time to hit the bars. I'm not sure these days.
17:56:07
lukego
(I'm sure that Sweden's Taco Friday originates in an advertising campaign from whatever is the company that supplies the Taco isle at the main supermarket chains)