morganw` has quit [Remote host closed the connection]
euandreh has quit [Ping timeout: 246 seconds]
euandreh has joined #commonlisp
nij- has quit [Ping timeout: 246 seconds]
nij- has joined #commonlisp
waleee has quit [Ping timeout: 246 seconds]
akoana has quit [Quit: leaving]
triffid has quit [Remote host closed the connection]
<nij->
How do I interact with a running (sb-)thread?
<nij->
For example, I now have a thread running a task in the background. If certain event happens, i want to have an option to *manually* tell it (from the repl) to switch to another task.
<pjb>
nij-: in general, you will want the thread to be programmed to have a controlled interaction.
<recordgroovy>
Sounds like you'd want message-passing rather than thread control
<pjb>
nij-: you will use mutexes (locks) and condition-variables to let them communicate when events occur.
<recordgroovy>
^
<pjb>
nij-: and of course, you can use those mutexes and condition-variables, to build higher level constructs such as mailboxes, or message queues.
<pjb>
nij-: that said, it's possible to use bt:destroy-thread and bt:interrupt-thread to have some asynchronous interaction.
<recordgroovy>
sb-thread has all the useful multithreading primitives you should need
<pjb>
nope. Use bordeaux-threads instead!
<pjb>
recordgroovy: this isnot #sbcl.
<recordgroovy>
pjb: nij mentioned sb-threads, which is why I mentioned them. Though you're right, bordeaux-threads has those primitives as well
<pjb>
nij-: if you want a sbcl specific answer, ask in #sbcl.
<nij->
recordgroovy ok.. lets see.. how to pass message?
<pjb>
nij-: you may find some multi-threading libraries.
<nij->
pjb how to pass message with bordeax-thread?
<nij->
Oh, so I can make the thread return a "queue" before it starts running.
<nij->
And when it runs, it will constantly check the queue.
<nij->
If queue has something, it reacts accordingly?
<pjb>
nij-: not really, threads can return a value only when they terminate, and you can collect it with bt:join-thread.
<pjb>
nij-: instead, the main program will create the queue and other such data structures, and will create the threads, the consummer(s) and the producer(s).
<pjb>
nij-: the use of condition-variables ensure that the thread doesn't "constantly" check the queue. It only checks it when it receive a condition notification. But otherwise, yes, the code of the thread will be a loop getting a message from the queue, and processing it (for the consummer), or generating a message and enqueueing it (for the producer).
<nij->
condition-variable is only for LW?
justPardoned has quit [Quit: ZNC 1.8.2 - https://znc.in]
Lord_of_Life_ has joined #commonlisp
justache has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 255 seconds]
Lord_of_Life_ is now known as Lord_of_Life
lisp123 has joined #commonlisp
euandreh has quit [Ping timeout: 260 seconds]
euandreh has joined #commonlisp
euandreh has quit [Client Quit]
drakonis has quit [Quit: WeeChat 3.6]
drakonis has joined #commonlisp
lisp123 has quit [Ping timeout: 255 seconds]
causal has quit [Quit: WeeChat 3.7.1]
<hayley>
No, condition variables are provided in Bordeaux threads.
<hayley>
I recommend using safe-queue for mailboxes and queues though.
<aeth>
I didn't even know you could write a wayland client in the same style as e.g. clx
corinroyal has quit [Read error: Connection reset by peer]
<aeth>
I wonder if it would make things more portable to e.g. mezzano or to an attempt to replace pid 1 on Linux with Lisp
corinroyal has joined #commonlisp
<recordgroovy>
I think it would be funny to replace pid 1 with lisp, just to see if one can
<recordgroovy>
I would not be the one to do that, though
Inline_ has quit [Quit: Leaving]
<recordgroovy>
I should study clx, maybe I'll get some insight to improve the API here
<aeth>
comes up a lot
<beach>
recordgroovy: Nah! CLX does not use standard classes nor generic functions, so it feels old.
<recordgroovy>
Oh
Inline has joined #commonlisp
<recordgroovy>
What makes it clx-like?
<aeth>
(I mean replacing pid 1 comes up a lot)
<beach>
recordgroovy: I think it is similar in spirit to what you are doing in that it implements the protocol directly in Common Lisp.
<recordgroovy>
Holy baloney, some of these files are three decades old
<phoe>
welcome to Common Lisp
<phoe>
a language with legacy™
<Nilby>
I've tried lisp as pid 1 and my sad conclusion is, there isn't a suitable free implementation.
<beach>
The one good thing about CLX is that it was written by people who seem to know how to take advantage of Common Lisp features to maximize maintainability.
<phoe>
Nilby: what do you mean?
<phoe>
what sort of implementation traits are required?
<aeth>
SBCL doesn't work?
<Nilby>
sbcl has problems with memory and signal handling
<recordgroovy>
Wayland is pretty straightforward as a protocol beach, just a couple quirks like passing fd's over
<aeth>
jackdaniel and Duuqnd (and others) had a similar conversation in #lispcafe (iirc) yesterday
<beach>
recordgroovy: I see.
<phoe>
wrt signals, there are solutions like https://github.com/Yelp/dumb-init which work around the "unix signaling for PID 1 is special" thing
<recordgroovy>
The hard part is making the compositor, since you don't have a companion server like Xorg to do lots of the hard part for you
<phoe>
wrt memory, you mean high memory use or GC or something else?
corinroyal has quit [Ping timeout: 248 seconds]
corinroyal has joined #commonlisp
<Nilby>
phoe: the signal thing has to do with how sbcl runtime deals with with unix signals on a deep level. I wasn't even concenred with init systems, because I was doing a lisp busybox like thing. The memory problem, is the fixed dynamic space thing as usual.
<Nilby>
phoe: there's also a few patches i had to do for stack overhead
<phoe>
yes, I see
<beach>
Hmm, that sounds like we need to work on a new implementation. :)
<Nilby>
sbcl does a lot of interceding with signals, file descriptors, and threads, which is somewhat necessary, but troublesome. My dream is to someday have a sbcl patch set which can run as pid 1, but I keep getting tempted to rewrite the C runtime to lisp.
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
corinroyal has quit [Ping timeout: 248 seconds]
corinroyal has joined #commonlisp
amb007 has joined #commonlisp
<hayley>
If only there was an implementation written entirely in Common Lisp.
<Nilby>
I'm ready for it.
<Nilby>
hayley: I'm curious, what would you guess is the percent of your sbcl GC work, in C vs Lisp.
amb007 has quit [Ping timeout: 252 seconds]
<hayley>
The only Lisp code I've written is to make MAP-ALLOCATED-OBJECTS work with the new heap layout.
<Nilby>
hayley: thanks. I know that's a dumb question since the other GCs are C
<Nilby>
Heh, thanks. I think I've looked a bit through that. "Enjoy" not the word I would used :|
corinroyal has quit [Ping timeout: 252 seconds]
corinroyal has joined #commonlisp
dipper has quit [Remote host closed the connection]
dipper has joined #commonlisp
<Nilby>
But there's something calm about it, compared to the GCs in most current CLs
dipper has quit [Remote host closed the connection]
Inline_ has joined #commonlisp
dipper has joined #commonlisp
Madsy__ has joined #commonlisp
Madsy_ has quit [Ping timeout: 260 seconds]
Inline has quit [Ping timeout: 260 seconds]
d4ryus has quit [Ping timeout: 260 seconds]
Fade has quit [Ping timeout: 260 seconds]
Fade has joined #commonlisp
d4ryus has joined #commonlisp
<Nilby>
I wish we had even %10 of the work/research that goes into Java or Javascript GC
<hayley>
My motto for myself has always been "bringing SBCL up to late 00's Java." Which perhaps is a bit too cruel.
micro has quit [Ping timeout: 260 seconds]
snits_ has quit [Ping timeout: 260 seconds]
micro has joined #commonlisp
snits has joined #commonlisp
<aeth>
hayley: so you're selling your work to Oracle soon, then?
<hayley>
I wish.
<Nilby>
It seems like you're doing the most Lisp GC work currently. So we need to 100x you.
Inline_ has quit [Ping timeout: 260 seconds]
<hayley>
My approach is to bug Doug Katzman a lot.
<Nilby>
sounds reasonable, they might just have to grab you into the googplex
Inline has joined #commonlisp
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
igemnace has joined #commonlisp
amb007 has joined #commonlisp
Inline_ has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
Inline has quit [Ping timeout: 252 seconds]
lisp123 has joined #commonlisp
kg7ski has quit [Ping timeout: 272 seconds]
<hayley>
Eh, not sure if I want to work at Google. But it's the time of year when everyone bugs me to get a job.
<Duuqnd>
Nilby: Any reason why SBCL should need to run as PID 1 specifically? In my attempt, /init is a shell script (need busybox or similar to mount filesystems anyway) that does nothing but start SBCL, and that works fine. Of course it would be ideal to run only SBCL, but practically I don't see much difference. What am I missing?
Inline__ has joined #commonlisp
<jackdaniel>
recordgroovy: check out work by cmack on wayland vackend for mcclim (it is in the repository pull requests)
Inline__ is now known as Inline
<aeth>
Duuqnd: Good point. As I mentioned in #lispcafe (and a bunch of times before on IRC over the years) I definitely think a top-down approach is the way to go here. Well, I mean top-down from something like stumpwm (or a wayland compositor), but even just top-down in your sense could work, too.
Inline has quit [Client Quit]
<aeth>
i.e. get something that works on top of your init (or even on top of systemd). Maybe replace it later. Instead of starting about how to rewrite/fork SBCL or write a new CL or whatever
Inline_ has quit [Ping timeout: 260 seconds]
<aeth>
I definitely try to have something that works every step of the way. It's hard for some projects that are massive and interconnected (e.g. game engines), but those tend to be more successful imo
pve has joined #commonlisp
Inline has joined #commonlisp
<Nilby>
Duuqnd: You're right. It's just that I wanted a system with only the Lisp shell where I didn't need to have any old shell code. A system with a simple init and a lisp shell works now, although I wish I had a lisp DHCP and power monitor, ntpd, etc.
<Nilby>
wifi, bluetooth, etc
<Duuqnd>
I did look for ways to ditch busybox for a bit, but mounting file systems turned out to be a not-so-nice task to do from Lisp. I also wanted to minimize any changes I made to software to keep it simple to set up, so I didn't really feel like building that into SBCL.
<Duuqnd>
I think keeping some C programs around will be necessary until either drivers start being written in Lisp (currently considering how that might be done in Linux, or at least hacked together) or if something like a unikernel is used.
<Nilby>
someday maybe I'll have enough of the pieces.
<Nilby>
unfortunately when writing unix-like utilities i keep wishing i had a transactional file system, so you could do nice "safe" (with-dangerous-thing macros
Inline_ has joined #commonlisp
<aeth>
well, Linux finally is allowing some Rust code after being strictly C for a very long time
<aeth>
so perhaps a low-level subset of Common Lisp could one day, maybe in 10 or so years, get used for drivers, too
<phoe>
one without runtime, I suppose
<phoe>
so it would be a separate dialect of CL rather than CL itself
<hayley>
Why can't it have a runtime?
<aeth>
no runtime, no GC; since it's for kernel code and kernel drivers in this hypothetical
<aeth>
could have GC at macroexpansion and compilation time, though
<phoe>
hayley: try convincing the linux people that adding a gc and lisp runtime to the kernel is a good idea
<phoe>
aeth: yes, that's no problem, that's what Carp does
<aeth>
it would be a strange reversal of some languages that have restricted compilation-time evaluation
Inline has quit [Ping timeout: 260 seconds]
<hayley>
And, honestly, why settle for not-Common Lisp? Can't reuse any code, and why bother with the endeavor.
<phoe>
there is a GC and unbounded allocation at macroexpansion/compilation time in there
<aeth>
no different than e.g. the shader languages
<phoe>
yep
<phoe>
but then you'd need CL at compilation time available for building the linux kernel
<Nilby>
heh, I also tried sbcl as a bsd rumpkernel a long time ago, but that had runtime problems too
<aeth>
phoe: just a small technicality
<phoe>
which is another dependency, for building this time
amb007 has joined #commonlisp
<phoe>
adding rust is a small technicality and it took years for it to happen
<phoe>
adding a language like CL that is completely alien™ to C and Rust is nothing I can imagine
<aeth>
Nilby: as far as your file system though that wouldn't even be an issue here though
<aeth>
userspace filesystems. FUSE
<aeth>
seems dangerous, though. Those things take years and years to trust with your data
<aeth>
so it's more of a life's work type of thing
<Nilby>
aeth: right, it's just hard when you're coding lisp to try to do thing the unix way, and just panic on error with handlers or unwind-protect
amb007 has quit [Ping timeout: 260 seconds]
<phoe>
yeah, depends on the error handling system of the outerlying layer
<phoe>
working with lisp in the erlang world would also be a major pain because a process is usually expected to completely die upon encountering any error, after sending an appropriate exit message to the processes it's linked with
<phoe>
but then again, that's different styles of interacting with "the world outside"
<Duuqnd>
What I imagined trying in terms of drivers is exposing whatever a driver needs to use (idk I haven't written many drivers) through the file system so drivers could be written straight in Lisp. Of course, I don't see much practical use for this, all I want is to see how this could work.
<aeth>
as a... uh... kmod or something?
<Duuqnd>
Maybe? I don't know what kmod is
<phoe>
kernel modules?
ttree has quit [Ping timeout: 272 seconds]
<Nilby>
Duuqnd: at least in linux, most things can be done like that at user level. depending on the hw, some drivers are developed at user level and then later put in the kernel.
<Duuqnd>
I'm thinking that if it's exposed through the file system I wouldn't need to modify SBCL's runtime
<phoe>
if anything there's a ton of stuff you can do while just being root, accessing devices with root-owned programs would be one of them I think
<phoe>
a lisp image running as root that talks to the filesystem or accesses some foreign memory that's actually a device DMA region would be one of them
<phoe>
s/one of them/such a usecase/
lisp123 has quit [Ping timeout: 252 seconds]
enzutwo has joined #commonlisp
enzuru has quit [Ping timeout: 260 seconds]
Inline_ is now known as Inline
amb007 has joined #commonlisp
dipper has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 248 seconds]
dipper has joined #commonlisp
cage has joined #commonlisp
corinroyal has quit [Remote host closed the connection]
Inline_ has joined #commonlisp
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
Inline has quit [Ping timeout: 260 seconds]
<jackdaniel>
Nilby: do you remember what the problems with rumpkernel and sbcl were?
cosimone has joined #commonlisp
prokhor__ has joined #commonlisp
amb007 has joined #commonlisp
prokhor_ has quit [Ping timeout: 248 seconds]
amb007 has quit [Ping timeout: 260 seconds]
notzmv has quit [Ping timeout: 268 seconds]
aartaka has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
McParen has joined #commonlisp
lisp123 has joined #commonlisp
waleee has joined #commonlisp
<Nilby>
jackdaniel: It was 8 or 9 years ago, but I think I booted it and got a repl, and it did have some crashes, but I think I wasn't so happy with the approach.
pve has quit [Ping timeout: 260 seconds]
aartaka has quit [Ping timeout: 248 seconds]
pve has joined #commonlisp
amb007 has joined #commonlisp
Inline__ has joined #commonlisp
thuna` has joined #commonlisp
Inline_ has quit [Ping timeout: 248 seconds]
amb007 has quit [Ping timeout: 252 seconds]
_cymew_ has joined #commonlisp
Inline__ is now known as Inline
<jackdaniel>
I see, thanks
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest3845
random-nick has joined #commonlisp
_cymew_ has quit [Ping timeout: 248 seconds]
morganw has joined #commonlisp
makomo has quit [Quit: WeeChat 3.6]
genpaku has quit [Remote host closed the connection]
genpaku has joined #commonlisp
Inline_ has joined #commonlisp
Inline has quit [Ping timeout: 260 seconds]
azimut has quit [Ping timeout: 255 seconds]
chip_x has quit [Remote host closed the connection]
Inline__ has joined #commonlisp
amb007 has joined #commonlisp
Inline_ has quit [Ping timeout: 252 seconds]
amb007 has quit [Ping timeout: 252 seconds]
Inline_ has joined #commonlisp
nij- has joined #commonlisp
<nij->
I just learned that merge-sort algorithm is better for list data structure, and so sbcl probably uses that for #'sort and #'stable-sort.
<nij->
I now have a long list, from which I only want to select the 3 best ones.
<nij->
The usual sorting algorithm "quicksort" has a selecting cousin for this, which is caleld "quickselect".
<nij->
Is there anything like that for merge sort? I can't find any by searching "mergeselect"..
Inline__ has quit [Ping timeout: 260 seconds]
jmdaemon has quit [Ping timeout: 255 seconds]
<phoe>
sort the sequence and then take the first three elements?
<phoe>
that would be O(nlogn)
<phoe>
I wonder if it could be done in O(n) since you don't need to sort the whole list to pick three maximal elements
<nij->
So quickselect is basically quicksort, but it cleverly stops doing the rest when there's a proof that the first 3 have been found.
<nij->
I can't think of one for merge sort though..
Inline__ has joined #commonlisp
<empwilli>
I think you approach the issue from the wrong direction
<nij->
Or maybe I should just copy my list to a vector, quickselect there, and backport..
<nij->
empwilli me?
<empwilli>
yup
<empwilli>
ask yourself why mergesort is for lists better and what you really have to do for quickselect
<empwilli>
afaik quickselect is a: pick the ~ n/2 elements that are lower/higher some element and do this recursively
<Nilby>
getting the top 3 is O(n 3) vs O(n log n) so will be quicker for anything above 20 or so
<nij->
Yeah my list could have length 2000
<nij->
Hmm.. I start to wonder why I use lists in the first place.
Inline_ has quit [Ping timeout: 260 seconds]
<nij->
Oh, but I don't have a good upper bound of how long my list will be.
<nij->
Nilby, do you think copying my list to a vector and run quickselect, would be better?
<nij->
I'm worried that copying takes a long time.
<empwilli>
why can't you do quickselect on the list?
<empwilli>
(of course, other questions arise as well: how often do you plan to perform the operation? is it worth to maintain an ordered list to begin with, ...)
<Nilby>
2000 is so small you don't have to worry about anything really
<nij->
Nilby, the problem is that the comparer takes more time than #'>
<nij->
it actually is the bottleneck now
<nij->
empwilli I see. I think I can, it's just not optimal for lists.
aartaka has joined #commonlisp
rumgzy is now known as Sauvin
<empwilli>
why so?
<Nilby>
nij-: just getting the top 3 is faster than any sort
<phoe>
maybe you could even only traverse the array once using some clever comparisons, but no idea if that would perform better
<nij->
phoe oh that's actually pretty nice. since I only need to get 3, which is a small number.
prokhor_ has joined #commonlisp
<Nilby>
yes, no need to be clever, just one traversal of max3
<empwilli>
tbh. I guess you are really overthinking the issue: if you read the data once at application start, simply sort it---you can reuse battleproof library sources and don't have to worry about fixing bugs in there. If you do it several times implement a quickselect probably (or still sort it, just hit benchmarks)
<empwilli>
last resort: try to implement this iterative approach with a single loop but behold: some assmuptions about code (input size, "the number will always be 3") change sooner than later and then you have to throw things away
prokhor__ has quit [Ping timeout: 260 seconds]
<empwilli>
(of course I don't want to interrupt philosophical/theoretical discussions :))
<empwilli>
but Nilby already showed an example and I'd guess its best to benchmark and consider readability/maintainability
<empwilli>
(Also: considering that you write your code as modularized as possible, this part can be changed later as soon as everything else works, if you find it to be a source of slowdowns)
<nij->
Great advice :) Thanks!
Major_Biscuit has joined #commonlisp
amb007 has joined #commonlisp
<nij->
Ah.. I used #'uiop:launch-program to run a program, but I didn't "save" the returned process-info. Now I lose the handle to interrupt/terminate it. Is there anyway for me to kill that from lisp, without killing lisp?
<phoe>
the standard unix way, find the pid, send it a signal
<nij->
Oh, uiop didn't maintain a history list of all processes created, so I can only kill it externally..
amb007 has quit [Ping timeout: 248 seconds]
notzmv has joined #commonlisp
_cymew_ has joined #commonlisp
Major_Biscuit has quit [Ping timeout: 248 seconds]
pve has quit [Ping timeout: 260 seconds]
waleee has quit [Ping timeout: 248 seconds]
pve has joined #commonlisp
tyson2 has joined #commonlisp
thuna` has quit [Ping timeout: 260 seconds]
Inline_ has joined #commonlisp
<beach>
nij-: Finding the N largest elements in a list is a standard algorithm in the textbooks on algorithms and data structures.
Inline__ has quit [Ping timeout: 248 seconds]
waleee has joined #commonlisp
Inline__ has joined #commonlisp
epolanski has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
Inline_ has quit [Ping timeout: 252 seconds]
son0p has quit [Read error: Connection reset by peer]
<nij->
beach there are several
<beach>
Like what?
<nij->
quickselect, or the method phoe mentioned
<beach>
That would be in a book only as an example of what not to do.
<nij->
or in some scenarios it maybe easier to just sort and select the first
<beach>
That one as well.
<phoe>
easier, sure, probably not the most efficient
<nij->
There's a unique efficient selecting algorithm that suits all cases?!
<phoe>
what do you mean by "all cases"
pjb has joined #commonlisp
<phoe>
you have an array of unsorted data, that's what I understood
<phoe>
and you want to find the N greatest elements in it
<nij->
I have a list of unsorted data.
<nij->
not array nor vector
<beach>
nij-: The books on algorithms always assume that the list has a large number of elements, and they usually give the algorithm with the best asymptotic complexity.
<phoe>
sure, that doesn't matter because the traversal is going to be linear anyway
<nij->
phoe if we use quickselect, than the traversal isn't linear
<phoe>
the solution is not to use quickselect if you have a list then
<beach>
nij-: If the traversal is not linear, you are not looking at every element, so that can't work.
<phoe>
quicksort-style algorithms often assume O(1) random access time, which lists don't have
<beach>
nij-: This is fairly elementary stuff. I suggest you read one of those books I recommend.
<phoe>
you can traverse a list and maintain the three greatest elements at any time
<beach>
phoe: No, quicksort has the same complexity on lists as on vectors.
thuna` has joined #commonlisp
<beach>
The optimal algorithm for finding the K largest elements in a list of N elements seems to be the one that uses a heap of size K, and its complexity is O(N log K).
<nij->
Cormen - Introduction to Algorithms ?
<nij->
Ok, I think it's time for me to get one book to stay around me.
<beach>
That is one of the standard books, but I haven't checked it for this particular algorithm.
<nij->
Which book actually covers most cases?
<nij->
I think a dictionary-like index would be nice.
<beach>
Like I said, there is only one "case" as far as algorithms go, namely one where the list has a large number of elements.
<phoe>
beach: huh, I need to re-read
<beach>
phoe: Pick the first element as the pivot. Traverse the list and divide it into two according to comparison with the pivot. Then sort the two lists recursively. Finally, append the two lists.
<nij->
What I'm worrying is that I may get one book, which doesn't cover a case I need in the future.
<Nilby>
phoe is right, it's well known that mergesort is better for lists, and quicksort for arrays
<nij->
I also read that mergesort is better for lists.
<nij->
But that doesn't mean quicksort is worse on lists than on arrays.
<phoe>
beach: I see, there's no need to have random list access then
<beach>
phoe: Exactly.
<beach>
Merge sort is better for arrays too, but in the standard version requires O(N) additional space. But there has been a lot of research on merging for arrays to get the additional space down to O(1).
<nij->
interesting
<nij->
since space is cheap, i wonder why quicksort is still more standardish than merge sort
amb007 has joined #commonlisp
<nij->
(time is expensive though)
<pjb>
nij-: perhaps because of cache memory.
<beach>
You have to allocate that space, so the constant factor is larger than for Quicksort. On the other hand, Quicksort is not great in the worst case.
<nij->
Very good to know.
<nij->
Quicksort isn't as quick as I thought!
<beach>
And it is quick only on the "average".
<nij->
n^2 isn't acceptable especially in production..
Bungg has joined #commonlisp
<nij->
I appreciate this conversation. Thanks Nilby pjb beach phoe .
<Nilby>
and don't forget timsort from as recent as 2002
<nij->
Gosh.. too many sorts..
<Nilby>
it's actually not such a simple topic
<nij->
There's not a single bible which records many (if not most) practical solutions for different cases, and which makes the comparison easy?
amb007 has quit [Ping timeout: 248 seconds]
<nij->
is tim better than merge?
<Nilby>
yes, because it's tuned based on the parameters
<nij->
Wow.. and I wonder how that compares with phoe-sort.
<nij->
Oh sorry, phoe-select.
<nij->
Actually I only need a selection algorithm, not sort. =_= almost forgot
<nij->
I have to leave for now. I will use phoe-select in my case as there are only 3 to be picked. I cannot imagine any other algorithm that could beat it.
<nij->
Thanks folks!
<beach>
I gave you the optimal algorithm for selecting the K largest elements from a list of N.
<beach>
*sigh*
genpaku has quit [Ping timeout: 260 seconds]
<nij->
beach I think I may have missed some of your message. Looking back, I didn't see which book you mentioned, nor any algorithm.
<beach>
The optimal algorithm for finding the K largest elements in a list of N elements seems to be the one that uses a heap of size K, and its complexity is O(N log K).
<nij->
The one?
genpaku has joined #commonlisp
<beach>
I can't see how anything could be better.
Bungg has quit [Remote host closed the connection]
Bungg has joined #commonlisp
<nij->
phoe-select worst case is O(NK)
<nij->
i wonder which algorithm you meant, beach.
<beach>
The one that constructs a heap of size K is the one I meant.
<nij->
hmmm ok I will search for what exactly that is. gotta go. Thank you :)
<beach>
nij-: A heap is a standard data structure that is also described in those books.
nij- has left #commonlisp [#commonlisp]
<beach>
It is used by heapsort for instance.
Inline_ has joined #commonlisp
<phoe>
a heap of size 3 would be O(3N) which is O(N) at that point
<phoe>
so, yes, a priority heap that also automatically drops the smallest elements upon finding a new maximum
<beach>
Yes, I don't think the books treat the particular case of 3.
Inline__ has quit [Ping timeout: 252 seconds]
<phoe>
yeah, there's no need to treat it differently
<phoe>
for any constant K the complexity becomes linear
<beach>
Right.
hamza has joined #commonlisp
<hamza>
Hello Everyone!
<phoe>
henlo
<hamza>
I hope I am on the right channel now.
<beach>
Hello hamza.
<hamza>
Yay
<hamza>
Been a long time.
<phoe>
hamza: this is the Common Lisp channel on Libera Chat
<hamza>
I had to move to ERC.
<hamza>
Yes.
<hamza>
So anyways,
<hamza>
I want to ask you how to write an object that is showing an unreadable object error
<hamza>
for example:
<hamza>
(with-open-file (out "~/myfile.txt" ...)
<hamza>
(with-standard-io-syntax
<hamza>
(print object out)))
<hamza>
However, this shows me the unreadable object error
<hamza>
unless I remove the with-standard-io-syntax or change the print to princ or format
<hamza>
The objects are also from StumpWM
<hamza>
It's a window manager made in common lisp123
<hamza>
oops
<hamza>
didn't mean to ping
<Demosthenex>
stumpwm rocks ;]
<hamza>
Yeahhhhh
<hamza>
However, the channel on irc is dead
<beach>
hamza: Instances of standard classes can't be printed readably.
<hamza>
standard classes?
lisp123 has quit [Read error: Connection reset by peer]
<hamza>
Is that like a specific term or just like normal classes
<beach>
I assume that's what you are trying to print.
<beach>
It's the ones you typically get when you use DEFCLASS.
<hamza>
The default class of classes?
<hamza>
so basically everything?
<beach>
No, not the default.
<Demosthenex>
hamza: what kind of object are you trying to print?
<Demosthenex>
and the stump channel's not completely dead ;]
<hamza>
Demosthnex: Maybe I have just joined the wrong channel agian.
<phoe>
hamza: *print-readably*?
<hamza>
Yeah, that was a solution.
<hamza>
However, I want to read it back too.
<hamza>
Basically, I am trying to save all of the opened windows to a file to open later.
<phoe>
objects printed out with *print-readably* being true should be possible to read back
<hamza>
However, all the windows are clos objects.
<hamza>
phoe: so it is true.
<hamza>
but that produces error
<phoe>
yes, because no readable print is defined for these objects
<phoe>
hm, I'd grab some values you consider important from these objects and print these out, and upon reading re-create the window objects with proper values
<Demosthenex>
there's no default print to serialize and reload objects.
<hamza>
So do I have to define it or can I just read it again with with-open-file?
<hamza>
Demosthenex: Why though?
<hamza>
nvm
<hamza>
thats dumb
<hamza>
so basically, how?
<hamza>
like I just define my own format?
<phoe>
yep
<Demosthenex>
sure
<hamza>
or maybe it's something like Java's toString() function
<hamza>
or some serializable class to extend?
<hamza>
Or it's not that complicated. Just write anyway and read creating custom functions wherever just to use the values?
<Nilby>
This case is exactly why objects don't print readably, becase to read them back would have to create complex state. For example you'd have to have the window system set up to read it.
<Demosthenex>
hamza: got a better question. if you're saving "all open windows to a file to open later", how would you "reopen" those?
<hamza>
Demosthenex
<hamza>
Just read from the file
<Demosthenex>
is mah name.
<hamza>
lol
<hamza>
Nilby: ohhh yeah, I forgot how smart cl is
<Demosthenex>
so, i have 3 browser windows open, with 2 popups for ads for M$'s V$Code, a terminal, and libreoffice. how the heck would you automatically restore those windows?
<hamza>
Basically, I would write (all-windows) to a file (which is the current probelm and first step)
<hamza>
then,
<Demosthenex>
the complexity of the window/application state you aren't capturing.
<Demosthenex>
and even if you ran firefox, libreoffice, a terminal, you can't restore where they were
<Demosthenex>
just from the window information
<hamza>
I will loop through the windows, and launch-program./
<Nilby>
But, you could print objects as a bunch of create-instance things which would re-create the windows, given that everything is set up right.
<Demosthenex>
you could at best open the same binary at the same window location, and hope.
<hamza>
? REally?
<hamza>
let me try a xprop
<hamza>
WM_CLASS(STRING) = "emacs", "Emacs"
<hamza>
That's how XMonad did it
<Demosthenex>
hamza: so, xprop against my terminal, only useful item is the binary name "urxvt".
<hamza>
It matched for WM_class
<hamza>
yeah
<Demosthenex>
it won't store my PWD, history, or any commands i was running at the time.
<Demosthenex>
so i get you're trying to do a rough save/restore state
<hamza>
That's done by ~/.zshhistory
<Demosthenex>
i think you'll have to dump the binary names and windows to your own format, and then read it in and launch them yourself
aartaka has quit [Ping timeout: 252 seconds]
<hamza>
Demosthenex: Yeah, basically, in Pakistan There are 4 poweroutages in 24 hours 2-5 hours each
<hamza>
so I hate to restart my computer and launch everything again.
<Demosthenex>
i have perhaps 15 urxvt windows open right now. history doesn't help.
<nij->
I actually want to call python libs from CL.
<pjb>
it's bidirectional.
<nij->
I will take a look. Thank you.
<nij->
In any case, I'm still curious what options I have theoretically.
<nij->
HTTP is more robust but slower than TCP. In general, how much slower could it be?
amb007 has quit [Ping timeout: 252 seconds]
shka has joined #commonlisp
prokhor_ has quit [Ping timeout: 252 seconds]
Inline_ has joined #commonlisp
Inline__ has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 246 seconds]
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
<Josh_2>
HTTP is pretty darn slow
<Josh_2>
Theres a lot of overhead when parsing the HTTP protocol that you wouldn't have with a simple TCP protocol. Perhaps you could use rpc instead
<Josh_2>
If its Lisp <-> Lisp perhaps you could use Swank :thinking:
tyson2 has joined #commonlisp
karlosz has joined #commonlisp
tibfulv_ is now known as tibfulv
perrierjouet has quit [Quit: WeeChat 3.7.1]
kg7ski has joined #commonlisp
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
nij_ is now known as nij-
danieli has quit [Quit: Ping timeout (120 seconds)]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
nij- has left #commonlisp [Using Circe, the loveliest of all IRC clients]
Cymew has quit [Ping timeout: 260 seconds]
Inline__ has joined #commonlisp
danieli has joined #commonlisp
Bung has quit [Quit: Leaving]
Inline_ has quit [Ping timeout: 248 seconds]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
amb007 has joined #commonlisp
dipper has quit [Remote host closed the connection]
dipper has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
perrierjouet has joined #commonlisp
CptKirk has joined #commonlisp
Cymew has joined #commonlisp
jeosol has quit [Ping timeout: 260 seconds]
dipper has quit [Remote host closed the connection]
dipper has joined #commonlisp
Bungg has joined #commonlisp
puchacz has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.7.1]
tyson2` has joined #commonlisp
Bungg has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
tyson2 has quit [Ping timeout: 260 seconds]
amb007 has quit [Ping timeout: 248 seconds]
tyson2` has quit [Remote host closed the connection]
ixelp has joined #commonlisp
amb007 has joined #commonlisp
Inline_ has joined #commonlisp
causal has joined #commonlisp
Inline__ has quit [Ping timeout: 260 seconds]
causal has quit [Ping timeout: 248 seconds]
amb007 has quit [Ping timeout: 248 seconds]
causal has joined #commonlisp
Bungg has joined #commonlisp
pfd has quit [Quit: Client closed]
pfd has joined #commonlisp
amb007 has joined #commonlisp
tyson2 has joined #commonlisp
azimut has joined #commonlisp
amb007 has quit [Ping timeout: 248 seconds]
puchacz13 has joined #commonlisp
puchacz has quit [Ping timeout: 260 seconds]
nij- has joined #commonlisp
<nij->
What's the easiest way to launch an external program asynchronously, while letting lisp and that program communicate through a bidirectional socket? #'uiop:run-program seems to use pipes which are uni-directional.
_cymew_ has joined #commonlisp
Cymew has quit [Ping timeout: 260 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<gilberth>
nij-: [I suppose uiop:run-program is the usual API] You get both a stream for the stdin and the stdout of the child. If you want to have that as something bidirectional MAKE-TWO-WAY-STREAM is your friend.
rogersm has joined #commonlisp
euouae has joined #commonlisp
<euouae>
Hello, with asdf, I want to define a variable in my asd file. Instead of going to ASDF-USER, the manual recommends to define my own package. I'm having trouble putting a defpackage & in-package at the top of the .asd file. I think it's symbol conflicts and such, is there an idiom for this?
<minion>
euouae, memo from phoe: you can upgrade to a newer ASDF seamlessly, ASDF does a lot of testing to ensure upgrades like that
<minion>
euouae, memo from phoe: download a new asdf version or clone the git repo (without submodules), put it in your local projects, (asdf:load-system :asdf) at the start of your image, and you are no longer dependent on what SBCL ships
<euouae>
That's good to know, I'll save that. In case we go with the inferred systems solution
<phoe>
symbol conflicts? like what?
<euouae>
Let me show you a piece of code
<phoe>
yes please, feel free to post it at plaster or somewhere similar
<phoe>
the name of this PDF is crude, but the contents are good
<euouae>
I've read that, it's good indeed
<euouae>
Ah I see what you mean, okay
<phoe>
this PDF contains an answer to the question "why do I have a name conflict between CL:REMOVE-IF and my package's REMOVE-IF"
<euouae>
Yeah I get it
<phoe>
:D
<aeth>
phoe: well, I think run-program is sync and nij- wants an async version of it so... good news, that's launch-program. iirc. it has been years.
<phoe>
if anything, delete your package and recreate it, except remember to :USE :CL and :ASDF
<phoe>
aeth: yes, it's present on recent enough versions of ASDF
<aeth>
yes, recent enough versions that implementations might not have yet
<phoe>
at which point it's up to you to upgrade asdf
<aeth>
I still think that launch-program effectively superseded run-program, though, because you can build a more capable sync run-program on top of the async launch-program