freenode/#lisp - IRC Chatlog
Search
5:04:02
jackdaniel
uh oh, a nice lisp quote: "Common #Lisp has no philosophy. We are held together only by a shared disgust for all the alternatives." -- Scott Fahlman
5:07:16
jackdaniel
it may be also a fake quote; not trusting random quotes on the internet is a websurfing 101 these days ,)
5:07:25
moon-child
https://ftp.distorted.org.uk/pub/mdw/its-ai/common/lins.463 contains it without the #
5:08:24
moon-child
and that file has a modification date from 1990. So I would say that, real or not, it far predates twitter
6:34:59
contrapunctus
pjb: a lot of the post and also your responses are beyond my knowledge level...but what can a CL programmer writing for Linux do about this today? 🤔
8:00:39
pjb
beach: the objective would be to unify the view of memory. To avoid having to program explicit I/O. To use memory mapped files in Lisp. Of course, we could just use FFI to access the memory mapped file, (or if the implementation provides it, accessing the memory mapped file as a vector of octet), but we would then have to serialized and deserialize lisp objects onto those octets.
8:02:02
pjb
In C, they can access directly the memory mapped blocks (the only thing is to use offsets instead of pointers). In lisp, we have a different data model, so we need to obtain lisp objects from a memory mapped file. This means that some lisp objects are not in the main heap.
8:03:57
beach
pjb: But, Common Lisp already treats everything as primary memory. The virtual memory system takes care of the rest.
8:04:10
pjb
But if we don't attempt to solve it one way or another then we will still have to distinguish lisp image memory from secondary memory and serialize/deserialize and doing I/O. Hence we won't be able to benefit from the optimizations of the kernel.
8:05:21
beach
Oh, you are assuming a stupid OS like Unix and you want your Common Lisp system to use its stupid file system? That's different. I see.
8:11:07
pjb
Not especially. For one thing using memory mapped files goes in the right direction: we don't have to write explicit I/O, but we just work with (partial) process images.
8:12:30
pjb
beach: but the core of the difficulty would happen also with other OSes. For example, with EROS, which allowed to "mount" memory images thru capabilities from remote systems, we'd still have to solve the problem of unified resources such as symbols.
8:13:23
pjb
beach: When we have the "same" symbol in two different lisp images, if those two images are put in common, now we have to resolve the inconsistencies that may exist between the copies of this same symbol.
8:13:44
phoe
which would be akin to interning everything internable from one into the other, e.g. symbols
8:13:51
pjb
beach: we of course intern the symbol itself and the packages, but its value, function and plist are in conflict.
8:14:11
beach
pjb: I am having a hard time thinking in those terms. To me, there would be a single Lisp image.
8:14:54
pjb
In the case of FASL this is solved by NOT saving those slots in the FASL, and by providing load-time-value and eval-when :load-toplevel :execute, to let the programmer perform the required mutations.
8:16:04
pjb
beach: even if conceptually you assert that there's a single lisp image (covering the whole Universe), you still have to deal with the fact that parts of this image are not accessible, and to deal with the synchronization when several processes access this unique universal lisp image.
8:17:40
pjb
beach: on the other hand, given those difficulties, perhaps this means that the blog article referenced earlier about memory mapping and I/O is actually wrong, and that there is indeed still a difference between core memory and secondary memory, despite the effort of unix to present one as the cache of the other.
8:19:56
beach
I don't feel smart enough to solve problems related to running Lisp on "modern" operating systems, which is why I wrote the CLOSOS specification instead.
8:32:37
pjb
beach: actually, you may be fundamentaly right: most of the problem comes from the separate addressing space for the separate processes. If ther was a single lisp image for all lisp processes on a system, then we could just persist this lisp image, and there wouldn't be problems, at least in the scope of a single system. With 64-bit addresses, the lisp image could encompass all the local storage.
8:37:38
lukego
splittist: hey I wonder what key/mouse bindings we want on CLIME images. I'm doing a first keymap now so that left-click can answer ACCEPT calls. But could be neat to pan/zoom on large images, open objects in the SLIME inspector, grab references for the REPL...
8:39:08
lukego
splittist: oh I see your PRs now! Sorry I was drowning in too many github notifications and missed 'em
8:40:16
splittist
lukego: Hmm. I'm about to send a PR with more stuff - basically finishing initial implementations of the medium-draw-foo* methods. Some things not quite right yet - text directionality and arcs of ellipses (which make my head hurt), but it's pretty (: (Still need to handle transformations and clipping, I think.)
8:40:52
lukego
keep 'em coming :) I'll merge liberally and try to quickly push fixes to whatever I break in the process
8:46:48
perdent
How would I convert these 40 16 bytes hex strings/plaintext to uint8_t raw format, without \n? https://bpa.st/BD2A
8:51:03
pjb
perdent: (com.informatimago.common-lisp.data-encoding.hexadecimal:bytes-from-hexadecimal-string (text-file-contents "/tmp/data.hex")) #| --> #(235 210 251 238 234 79 122 132 5 197 192 … 211 78 240 0) |#
8:51:31
pjb
(length (com.informatimago.common-lisp.data-encoding.hexadecimal:bytes-from-hexadecimal-string (text-file-contents "/tmp/data.hex"))) #| --> 340 |#
8:52:07
flip214
pjb: ah, understood. but it's one large vector instead of a list of vectors, one per line.
8:52:21
flip214
(w-o-f (stream #P"aa") (loop for line = (read stream nil nil) while line collect (ironclad:h-s-t-b-a line)))
8:53:14
pjb
Then: (mapcar (function bytes-from-hexadecimal-string) (string-list-text-file-contents "/tmp/data.hex")) #| --> (#(235 210 251 238 234 79 122 132) … #(47 252 143 15 141 52 239 0)) |#
8:55:43
pjb
and to store: (setf (string-list-text-file-contents "/tmp/data2.hex") (mapcar (lambda (bytes) (bytes-to-hexadecimal-string bytes :element-type '(unsigned-byte 8))) '(#(235 210 251 238 234 79 122 132) #(47 252 143 15 141 52 239 0))))
8:57:39
lukego
ACTION notes that his ratmouse can generate at least six different click events for Emacs... this could get nasty...
9:00:57
perdent
(16:46:56) dave0: ,cc char s[] = "EBD2FBEEEA4F7A84"; unsigned char a[8]; if(sscanf(s, "%2hhx%2hhx%2hhx%2hhx%2hhx%2hhx%2hhx%2hhx", a+0,a+1,a+2,a+3,a+4,a+5,a+6,a+7) != 8) perror("sscanf error");
9:00:58
perdent
(16:46:58) candide: dave0: no output: s = "EBD2FBEEEA4F7A84"; a = "\353\322\373\356\352Oz\204"
9:01:35
lukego
bounding boxes are an interesting one. I mean ideally Emacs would work this out from the SVG and we wouldn't have to spell out the viewBox bounding box for the whole drawing but I didn't see an obvious way to make it so
9:02:41
splittist
lukego: or (with-output-to-emacs (s) (draw-circle* s 100 100 75 :ink +magenta+ :start-angle (/ pi -4) :end-angle 0))
9:03:17
pjb
perdent: Then: (mapcar (compose (lambda (x) (map 'string 'code-char x)) bytes-from-hexadecimal-string) (string-list-text-file-contents "/tmp/data.hex")) #| --> ("ëÒûîêOz" "\\\\qâ¿" "ËÃö=«" … "/ü4ï
9:03:22
splittist
lukego: then (with-output-to-emacs (s) (draw-circle* s 100 100 75 :ink +magenta+ :start-angle (/ pi -4) :end-angle 0 :filled nil :line-dashes t))
9:07:45
lukego
splittist: circle example is working but I'm getting an error on the first one due to some stream-position missing method, looking closer, maybe just a compilation issue
9:14:32
lukego
splittist: hm but mine doesn't look quite right compared with yours: https://snipboard.io/EnkxDl.jpg
9:14:35
splittist
lukego: yay. Although it seems that despite the SVG spec referring to the content of text elements as 'character data', it actually needs to be xml-escaped.
9:16:03
perdent
pjb: and how would it look if the values were not infact hex but ascii/text charachters instead?
10:08:02
beach
pyc: There is no agreed-upon definition of "Lisp", so the question can't be answered.
10:09:33
beach
pyc: It is worse than that. Many people who invent their own programming language for some reason desperately want it to be a dialect of Lisp, so they simply declare it so and then they come here to show it off.
10:09:47
no-defun-allowed
The definition I usually see is the same as what people who dislike Lisp say, that "it's anything with a lot of parentheses which looks like (f (g x))".
10:11:08
pyc
no-defun-allowed: okay. Logo does not have parens. Logo has fixed number of arguments per command (called "word" in Logo), so very unlike Lisp then. Still I read on Wikipedia and other places that Logo is a dialect of Lisp. it didn't look like Lisp when I first learnt Logo.
10:11:13
beach
pyc: If I were you, I would stop trying to put labels like that on Logo or any other programming language. What would the purpose be?
10:12:45
phoe
it does seem kinda pointless to me, given the similarity to Plato's "man is a featherless biped" type of argument
10:12:56
no-defun-allowed
Right. Can you make a definition which excludes Smalltalk or JavaScript then (unless you feel that they should be included)? Though I agree with beach, mostly because I generally dislike Lisp apparently.
10:13:11
beach
pyc: Discussions related to "dialects of Lisp" are better conducted in ##lisp, which is not as strict about the kind of Lisp being talked about.
10:13:59
no-defun-allowed
As for Lisp with late binding and introspection, aye I'll take that, but that's mostly for the late binding and introspection.
10:18:33
no-defun-allowed
pyc: So what can I say, if you like Logo, that's all the justification you need. If you don't, again that's all the justification you need. No need to play language taxonomist.
10:39:04
pjb
pyc: Logo is not really a lisp. It can be implemented in lisp easily enough. But it has a specific program syntax, different from a syntax to write logo data.
10:39:10
pjb
pyc: https://dspace.mit.edu/bitstream/handle/1721.1/6226/AIM-313.pdf?sequence=2&isAllowed=y
11:18:08
splittist
jdz: yeah. This probably isn't quite right. But I'll leave lukego to handle that (:
11:22:12
jackdaniel
splittist: you may compare with tests in clim-examples (drawing tests -> text align)
11:22:55
jackdaniel
drawing tests have a headless run mode for pdf, postscript and raster image backends, so perhaps emacs could be added to that too
11:49:52
lukego
jdz: The way it works is that CLIM records all the drawing operations into a tree of "output records" and then at the end the Emacs backend traverses this to convert them into SVG elements. So in principle we have control over the order in which the elements are collected. I'm not sure if we're exercising that control properly yet though :-). Code: https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/emacs.lisp#L384
12:06:56
jackdaniel
a naive approach would be changing the last line to (reverse (remove nil shapes))
12:07:50
jackdaniel
also: (with-bounding-rectangle* (x-min y-min x-max y-max) root …) seems to be less verbose than m-v-b
13:09:21
flip214
Is there something like strace for CL? So that I get the tree of function calls with their arguments, timestamps, and runtime?
13:12:57
phoe
you'd need to trace all the functions, which might not be a good idea, and then also record timestamps
13:13:26
flip214
also, reconstructing the tree means reading backtraces all the time, destroying the performance
13:14:11
flip214
phoe: to see that FOO calls BAR I need to fetch the stack in BAR and relate back to the outer FOO frame -- and that for every call...
13:14:37
phoe
do you? can't you encapsulate FOO so that you get some code that runs before and after calling it?
13:15:02
phoe
there's no stack reconstruction there I think, just dynamic rebinding and printing I guess
13:18:40
flip214
phoe: not necessarily... perhaps I just want to collect data and report latency percentiles
13:19:27
phoe
I wonder if you can hack something together using the http://www.sbcl.org/manual/#Function-Tracing options
14:02:07
rpg
What's the right approach for multi-line string constants that are NOT format strings? Put tildes in to break them up and then wrap in format nil?
14:05:58
beach
rpg: That's what I do, and then I use tilde-newline with a @ modifier so that I can indent subsequent lines.
14:07:13
rpg
beach: Thanks! Kind of ugly to embed in an ASDF defsystem form. Tempting to extend ASDF's parser for description and long-description to accept the tilde-newline FORMAT operator.
14:07:58
rpg
lukego: That gives you a multi-line string with hard line breaks in it, which is what I was trying to avoid.
14:57:08
lukego
holy shoes I finally got ACCEPT working in CLIME i.e. you (accept 'string) and then click a string in an image and it gets returned to Lisp
14:57:51
rpg
lukego, beach: If you are at all interested, feel encouraged to comment on https://gitlab.common-lisp.net/asdf/asdf/-/issues/70
14:58:46
lukego
a few unsightly hacks involved on the Emacs side but it's nearly knocking-off time so I'll pretend not to notice them until tomorrow
15:04:36
jackdaniel
ACTION cheers on lukego, however he is wondering why the same effect on emacs generates approximately PI-times more wow than natively in CL ;)
15:07:04
lukego
maybe partly "ha ha only serious" hack value and partly that many of us are living inside Emacs and anything we can do there might get 100x more usage than stuff outside
15:07:48
lukego
for example every time I figure up the McCLIM listener I think "that's awesome!" and then within a minute or two I kill it to get my "real" REPL back.
15:08:27
jackdaniel
perhaps we should call the listener slime-repl and play dumb when someone tries to close it ^_^
15:09:20
lukego
credit here is to McCLIM anyway because it is doing all the real work, CLIME is just making it more accessible to emacs nerds.
15:10:36
lukego
jackdaniel: well it doesn't work. a minute in Drei is enough to drive me to distraction. Some people think of Emacs as a stop-gap hopelessly inferior Lisp machine, but I'm in the other camp that thinks Emacs is basically the most powerful program every made.
15:11:09
beach
rpg: I am trying to teach ASDF to use my custom LOAD function during SICL bootstrapping, and I am reading the ASDF manual. But I can't figure out what I am missing. Is there a convenient time for me to ask you how to do this?
15:12:41
lukego
ACTION wonders whether to push the code now or test it while actually having more than one type of presentation...
15:13:05
rpg
Here is fine, but if it would stomp on other discussions too much, I could hop over to #sicl. But will need a little time for me to finish up something. On the half hour?
15:19:03
lukego
splittist: I pushed rough initial ACCEPT support. Emacs side changes only. Some notes on the caveats @ https://github.com/nuddyco/slime/commit/8b1ea319b9d2522445454ec7b9de2e10180474bc
15:21:55
lukego
jackdaniel: btw it's pretty exciting in splittist's demo to start seeing existing CLIM code able to render into Emacs - and will have working ACCEPT. This could potentially create a two-way street where CLIM code written for the "Emacs world" and "CLIM native world" works on both sides and people can build on each others' stuff.
15:22:34
lukego
for example if clim-listener presentations could render into Emacs, then Emacs users could make clim-listener extensions of their own, and that could get folded into the upstream native clim listenre
15:23:04
lukego
ok maybe obvious :) it's a bit of a revelation to me to truly see CLIM as a flexible set of user-interfacing protocols rather than a monolithic "lisp machine user interface"
15:23:47
lukego
I know that it's always been described as such but I've never used e.g. PDF backend etc before so I never experienced that.
15:25:39
lukego
(Maybe I'm also squeamish but it's also really comforting that CLIM is not running a whole bunch of threads and event loop machinery behind the scenes here i.e. it's all the usual threads belonging to SLIME and my application that are driving execution. knowing that lifts a weight from my shoulders.)
15:26:49
lukego
yeah I don't know what's really happening in e.g. x11 mode but it seems a bit scary and opaque to me. I say that as someone who does not dare to use threads in my Lisp programs.
15:26:53
beach
jackdaniel: Don't worry, once we have the planned IDE, it will be irresistible for Common Lisp programming.
15:59:44
_death
basically inspired by http://www.karlsims.com/papers/siggraph91.html (which used starlisp on the connection machine..)
16:09:46
scymtym
flip214: if you feel adventurous, you can use https://github.com/scymtym/clim.flamegraph/tree/advice-backend to capture the kind of deterministic call tree with arguments and timing you describe
16:26:48
_death
phoe: oh, I misinterpreted your question.. the mutation is done on the genotype, i.e. an s-expression.. like (abs (and x y))
16:36:16
lukego
beach, jackdaniel: it's actually really nice the way you guys have structured projects like sicl and mcclim in such a way that they can drive towards a grand ambition but also be modular enough to act as components of other people's less ambitions systems e.g. emacs hacks, existing lisp compilers, etc. kudos :)