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.