freenode/#lisp - IRC Chatlog
Search
3:14:28
beach
jcowan: What phoe and no-defun-allowed said. There would have to be some way of "serializing" part of the object graph in a way that makes sense when it is de-serialized on the other end. I haven't worked out the details yet, because that's not the (to me) interesting part of CLOSOS.
3:18:36
no-defun-allowed
See https://bluishcoder.co.nz/self/transporter.pdf for an idea of how one can transport objects between images. Some of it would not be relevant to CLOS, as it assumes a prototype-based single-dispatch and message-passing language, whereas CLOS is class-based with generic functions with multiple dispatch. But it should give an idea of what would be done to make transporting work.
3:21:27
beach
In several places, including the saving/loading of ASTs in Cleavir, I have used an idea i basically got from the CLIM specification, which is that the class structure should not be used. Instead I rely on the relevant protocol items, namely initargs and accessors.
3:21:57
beach
Doing it that way has the additional advantage that it is less sensitive to updates of the class hierarchy.
3:23:23
beach
This mechanism is used for saving an AST to file and from creating an AST from a file, but we use it also to clone an AST in memory.
3:25:24
beach
The format of the serialization is particularly simple and it works quite well. We use Common Lisp PRINT and READ. The reader is programmed so that the charater #\[ has special meaning. The format is [<package>::class-name :<initarg1> :<value1> ... :<initargn> :<valuen>]
3:26:41
beach
The reader macro for #\[ simply does (apply #'make-instance (read-delimited-list #\[ <stream>))
3:27:30
no-defun-allowed
Yes, "abstract initialization" is also a topic of the paper. Though it also handles preserving object identity (unless marked as unnecessary by the programmer), and transporting code.
3:28:52
no-defun-allowed
Hm. Would (#1=[blah] #1#) give you a list with the same object (by EQ) in the list twice?
3:28:54
beach
The technique I described preserves object identity automatically within a "file" through the use of #= and ##.
3:30:32
no-defun-allowed
The code generator maintains a table of temporary bindings for objects and reuses them. A written out Self module is a program which installs it into the system.
3:31:08
beach
But the mechanism requires the user to explicitly say, for each class involved, what initargs are relevant, and what accessors to use to fetch values for those initargs.
3:32:02
beach
That kind of mechanism would be excellent to use in order to install viruses and other stuff on your system.
3:32:04
no-defun-allowed
Indeed. That is quite similar to the "annotations" used in Self, and generally the transporter design struck me as a slightly more abstracted-away MAKE-LOAD-FORM.
3:33:10
no-defun-allowed
Yes, you probably would not want to do transporting exactly like that if you don't trust the author of the module.
3:34:22
beach
Exactly. So some slightly safer mechanism would be preferable. The one we use for ASTs does not execute arbitrary code.
3:36:24
no-defun-allowed
(The other approach, which I always mention when someone tells me that running random bytecode in a client program is going to lead to the client getting hacked, is to sandbox the program and put limits on execution time and space.)
3:38:07
beach
Sure but that technique doesn't always work. For instance, if what you are loading into your system is just data that you want to use in some other code, like a text document or a music score.
3:43:26
no-defun-allowed
Right. As I see it, a safe version of the transporter would return the objects produced, allowing them to be used outside the sandbox.
3:47:32
no-defun-allowed
If we allow for transporting code still, we could still produce objects which do undesirable things. For example, an attacker might write out code to subclass MUSIC-SCORE, then define a method specialized on that subclass, for a generic function which the score reader calls.
3:47:55
no-defun-allowed
Then the transporter would return an instance of that new class. However, in my opinion, that is an argument for running the score reader (and really any program) with as few capabilities as possible.
3:50:42
beach
It is a bit too early for me (I haven't finished my morning coffee yet) to think through all cases. But it is an interesting problem, and I will be happy to include a chapter in the CLOSOS specification if someone would like to work out the details.
4:21:29
no-defun-allowed
Most proposals for readable hash tables I've seen forget about the test function.
4:21:52
no-defun-allowed
Not to say that adding somewhere to put a test function isn't easy, but most people forget it.
4:23:05
Nilby
and implemntation specific things like :weakness, and that it won't work with *read-eval* nil
5:20:30
splittist
FWIW, my current thinking on CLIME is to use it as an enhanced PRINT-OBJECT etc. for development. There are times when a cool visualisation of what is happening would assist. If I have a kewl-project/clime system for development (just as I have a kewl-project/test), and there is a library of visualisations to build on (CLIME:AS-CONS-TREE etc) then the slime repl would have even more superpowers.
5:28:54
fiddlerwoaroof
splittist: cool, I don't know if you were influenced by my slime-media demos, but I was hoping those demos would produce something like this :)
5:31:38
splittist
lukego is the one. But, yes, seeing all the clim goodness folks are doing makes me want to have it NOW (:
5:40:57
lukego
this close --> <-- to getting ACCEPT to respect the requested type but time for brekky and getting 7yo to school
6:00:39
fiddlerwoaroof
lukego: I contributed this a while ago to slime as well: https://github.com/slime/slime/blob/master/contrib/slime-buffer-streams.el
6:01:40
fiddlerwoaroof
It only provides text streams, basically, but the use-casees overlap slightly
6:02:15
fiddlerwoaroof
I usually use this from things like drakma:*header-stream* where I want to see some debugging info, but I don't want to clutter the repl
6:27:30
fiddlerwoaroof
Cool stuff, I'm getting weird rendering on my Mac at the moment, but I'll be watching with interest
6:54:10
lukego
fiddlerwoaroof: yeah that sounds like the sort of feature you could use many times per day. I do basically the same thing in emacs lisp code quite a lot.
6:55:12
lukego
I think this would play well with CLIME i.e. to be able to output presentations to such buffers instead of just the REPL.
6:59:42
lukego
I don't think there's actually anything at all currently tying CLIME to the REPL except that's where images happen to be printed by default. you can also e.g. copy/paste them into other buffers and they still work. The presentation enable/disable code is globally searching all buffers for the special slime-clime-foo text property that marks an image to update.
7:17:43
lukego
we should also have a way to assign images IDs like (with-output-to-emacs (s :id :foo) ...) such that when you use the same ID again it updates the existing image(s) in Emacs rather than inserting a new one. that way you can do animation-like things.
7:25:14
lukego
pushed @ https://github.com/nuddyco/slime/commit/a4b9bc2c82fc2ce6cf6c8983acaaf437583cf65b
7:43:46
lukego
I might take a breather before continuing onto the next major topic which is commands
7:50:49
lukego
Yeah seems like there's a mismatch somewhere. I think the visual bounding box is being calculated by McCLIM but then the differently-sized image is being rendered by SVG. So they are not in agreement somehow..
7:52:52
lukego
splittist: I pushed jackdaniel's suggested fix for the output records ordering issue i.e. to reverse the records. So you will need to update your demos to draw the background first rather than last :)
7:53:33
lukego
fiddlerwoaroof: if you want a nasty workaround you could just draw a black rectangle at the beginning to define a minimum canvas size
8:05:53
fiddlerwoaroof
When I inspected a generated SVG, the text was being placed too closeto the top of the bock
8:42:43
lukego
one more idea rattling around my brain is to somehow make (with-output-to-emacs (s) ...) optional. So if you'd just call e.g. (draw-rectangle* ...) directly in the REPL it would still give you the graphics when the evaluation ends. Somehow implicitly have a CLIM canvas for the extent of a SLIME invocation.
8:44:44
jackdaniel
draw-rectangle* takes the stream argument either way (and it is not default), you need to bind it somehow
8:46:25
jdz
lukego: How about merging that into WITH-ROOM-FOR-GRAPHICS (if I remember the name correctly)?
8:51:27
lukego
jackdaniel: true but maybe T could work? *standard-output* still be bound to a SLIME-OUTPUT-STREAM and we could hang CLIM methods on that?
8:53:38
lukego
jdz: hm not sure how that would work exactly. I guess the listener has a bunch of code all painting onto the same canvas and having to avoid clobbering each other here. in Emacs each drawing is a separate object and they are patched together like a collage
8:54:14
jackdaniel
it won't in this case I think. also, slime output stream does not have output recording
8:55:19
jackdaniel
you specialize the method invoke-with-room-for-graphics on slime-output-stream and wrap in with-output-to-emacs-stream instead
8:57:16
jackdaniel
instead of before you could make a trampoline, but that will work only for functions you provide methods for
9:06:03
jackdaniel
it was meant to abbreviate prodigy, but someone made a typo and it stands for a progidy ,)
9:23:43
splittist
I would be surprised if there weren't problems with the text stuff. It was working, then I tried to get smart (:
9:46:56
splittist
fiddlerwoaroof: if you used draw-text* directly, does the same thing happen? Also, generally, we should apply the transformations and clipping
11:39:55
lotuseater
hi there, after updating emacs and sbcl, then invoking slime i got a mysterious error
11:43:48
lukego
lotuseater: I think that I had this recently too, and the solution was to upgrade to a newer SLIME (or I suppose alternatively downgrade SBCL)
11:44:38
lukego
git clone https://github.com/slime/slime ~ && echo '(load "~/slime/slime.el")' >> ~/.emacs