freenode/#lisp - IRC Chatlog
Search
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.
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.