freenode/#lisp - IRC Chatlog
Search
17:23:32
contrapunctus
beach: https://varnish-cache.org/docs/trunk/phk/notes.html#so-what-s-wrong-with-1975-programming ?
18:30:46
pjb
contrapunctus: beach: to be profitable in lisp, we need to be able to talk with the GC to manage zones that are mapped to files, and to specify file-local root-sets (since files could be used by several processes, the objects in memory mapped files cannot be collected willy-nilly).
18:31:32
pjb
the question is what to do when an object is referenced from the root sets of two different files? In what zone should it be moved/stored?
18:33:23
pjb
file 1 rootset = {#1=(a . nil)} file 2 rootset = {#2=(a . nil)} (setf (get 'a :k) 42) should the plist (symbol-plist 'a) be stored in file 1, in file 2?
18:39:36
pjb
or a dynamic scope? (with-zone (file1) (push (list 1 2 3 4) (root-set file1))) for explicit allocation in the memory mapped zone. Otherwise (push (list 1 2 3 4) (root-set file1)) would imply moving the objects.
18:40:12
pjb
Of course, great care must be applied to avoid moving the whole lisp image into a memory mapped file (unless this is what we want).
18:43:09
pjb
This could be used instead of fasl files. Compiling could generate such partial lisp images that would just be memory mapped when "loaded".
18:51:25
pjb
In ccl, if we compile this file, restart and load it, https://termbin.com/fsre then the symbol-value and the plist are lost, while the uninterned symbol itself is still referenced by foo::*foo*. Is this conforming? Is this acceptable?
18:52:02
pjb
Of course, if the symbol wasn't uninterned, we could have conflicts between values, functions, and plists coming from different files…
18:56:23
pjb
Lisp images don't have load-time-values, but there are extension hooks to run code when loading a lisp image in some implementations.
18:57:06
pjb
the advantage of load-time-value is that it gives a clear semantic (the side effects are applied when the file is loaded/mapped).
18:57:44
pjb
But this means that we have to specify a list of objects that are not saved (entirely) in the memory mapped file…
19:29:24
jmercouris
I'm trying to run the CLIM demos and when I try to (ql:quickload :clim-examples), get this: http://dpaste.com/CVVXAHKUN
19:45:14
phoe
AFAIK you need to quickload one more system that contains the fonts, but I don't remember the details
19:45:52
jmercouris
and I see the following: (defparameter *truetype-font-path* (find-if #'probe-file '(#p"/usr/share/fonts/truetype/ttf-dejavu/" ...)))
19:46:09
jmercouris
seems those paths are hardcoded... UNLESS I get to that restart and handle it myself
19:46:49
jmercouris
I guess I need to convince NixOS to have fonts at that path or something, not sure
19:53:17
waleee-cl
jmercouris: isn't it ostensibly possible to use clim on windows? If so it must be ways to configure the font paths or another mechanism
19:53:47
phoe
then fill in that variable yourself with the value of (uiop/pathname:pathname-parent-directory-pathname (cl-dejavu:font-pathname (first (cl-dejavu:list-fonts))))
19:54:06
waleee-cl
ah, xserver dependeny. Ok, so technically possible to run on windows, but a hassle
19:55:47
jmercouris
phoe: I don't see this system anywhere, that's OK, I'll specify the path in the restart
23:33:57
|3b|
phoe: is there any reason https://github.com/phoe/damn-fast-priority-queue/blob/main/damn-fast-priority-queue/src.lisp#L109-L112 uses fixnum for PRIORITY instead of prio-type ?
23:38:59
|3b|
would you be likely to accept a PR for a version that supports deleting arbitrary elements and updating priorities? if so, any better name ideas than damn-fast-updatable-priority-queue?
23:40:36
phoe
though I'm kind of wary of combinatorial explosion because then we'll have DFPQ, DFSPQ, DFUPQ, and DFUSPQ
23:41:30
|3b|
ACTION somewhat avoids that problem by being too lazy to implement the US version until i need it :p
23:47:28
|3b|
does the stable version just keep an extra serial# to break ties for each entry? (and then get confused if there are more than 2^32 insertions in a given table)
23:49:40
phoe
feel free to adjust the queue to use ub64 instead of ub32 for that if you think you can run out
23:52:21
|3b|
ACTION is more likely to have a problem with ub32 priority, might like single-float instead (though i think single-floats are still ordered the same if the bits are compared as ub32, so close enough)
23:57:40
|3b|
(i guess using bits of float directly might only work if sign is the same, but i think that is true for my current needs)
1:01:42
sm2n
I have a bunch of methods that are constantly being called on the same special variable, it'd be nice if I could omit that parameter
1:09:38
xTriixrx
Does anyone here have experience using the usocket and/or general tcp server/client experience with Common Lisp? I am attempting to create a persistent TCP connection for a server/client thread which will eventually be used for a distributed message bus application written in Common Lisp. All of the usocket / tcp cl documentation online is very
2:02:22
|3b|
phoe: should these be <= https://github.com/phoe/damn-fast-priority-queue/blob/main/damn-fast-priority-queue/src.lisp#L171-L174 ? i think with < you will do more swaps than needed with duplicated priorities
3:12:35
beach
contrapunctus: That's a cute one. I am not surprised. A lot of people here still talk about RAM.