<ixelp>
GitHub - splittist/printfcl: A configurable printf implementation for Common Lisp
<jackdaniel>
:)
<mi6x3m>
I won't lol :D
<mi6x3m>
format is OK
<beach>
You can also just put the TAB in the string.
<mi6x3m>
that's the most practical advice i heard all year actually
<mi6x3m>
sometimes we get lost in our ways
<pony>
there's also this if it's what you're looking for: (format t "~8t~a~%" 1999)
<pony>
1999
<beach>
,(char "ab" 1)
<ixelp>
(char "ab" 1) => #\Tab
rgherdt has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life_ is now known as Lord_of_Life
jeosol has quit [Quit: Client closed]
<jackdaniel>
splittist: how is your pdf reader going? I'm waiting with anticipation because I like the idea very much :)
<splittist>
I have paused briefly to work on other stuff. But it can render some PDFs, as you have seen. And there is progress in font-format reading.
<jackdaniel>
cool, thanks for the on demand update :p
<mi6x3m>
is it a good idea to use keywords for plists or symbols are more customary?
<beach>
It doesn't matter. And KEYWORD is a subtype of SYMBOL.
<beach>
But sometimes you might want to use the plist as a list of keyword arguments to a function, and then it is more common for the function to take keywords.
rgherdt has quit [Ping timeout: 248 seconds]
<mi6x3m>
ah, i see
<beach>
I suggest you start looking things up in the glossary of the Common Lisp HyperSpec. In this case, look under "property list".
rgherdt has joined #commonlisp
attila_lendvai has quit [Ping timeout: 268 seconds]
<mi6x3m>
It's often of little help to me
<mi6x3m>
the most useful thing so far are the examples to the functions
<mi6x3m>
but in terms of idiomatic usage the doc is useless
<beach>
I was suggesting the glossary specifically, because it contains definitions of things.
<mi6x3m>
ah, in that case I'm often there yeah :))
<mi6x3m>
the documentation is really great
occ has quit [Ping timeout: 240 seconds]
varjag has joined #commonlisp
waleee has joined #commonlisp
<jackdaniel>
mi6x3m: do you know about pcl? a very good introductory book
<jackdaniel>
minion: tell mi6x3m about pcl
<minion>
mi6x3m: look at pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<ixelp>
Practical Common Lisp
<mi6x3m>
jackdaniel, I'm waiting for the price to drop below $70 to get it :))
<jackdaniel>
I see
<jackdaniel>
you still may start reading it online
<mi6x3m>
yeah i started on my tablet
<mi6x3m>
it's really good
<jackdaniel>
Peter Seibel was magnanimous enough to publish it on the internet
<mi6x3m>
everybody is suggesting that book
<jackdaniel>
yeah, because it is a very good introductory material
<jackdaniel>
and it is rather new, so it emphasizes techniques used today, not in early 90' or earlier
<mi6x3m>
i really dig the lisp culture beyond the fact that the language is really impressively designed and every aspect carefully thought through
karlosz has joined #commonlisp
mi6x3m has quit [Remote host closed the connection]
<nij->
(I know it's not recommended to do this.. I'm just curious.)
<edwlan[m]>
The best you can do is throw/catch, I think
<edwlan[m]>
or conditions
euandreh has joined #commonlisp
<beach>
nij-: You can use RETURN-FROM and GO only when the BLOCK name or TAGBODY tag is in the lexical scope. So as edwlan[m] says, you need to use CATCH/THROW.
nij- has quit [Ping timeout: 246 seconds]
<beach>
nij-: You can't use condition signaling, because if signaling does a non-local control transfer, it is because it uses either RETURN-FROM, GO, or THROW.
<beach>
That's how the entire condition system can be written as portable code. It needs only special variables and those non-local control-transfer primitives to work.
dev001 has quit [Ping timeout: 240 seconds]
dre has quit [Ping timeout: 246 seconds]
edgar-rft has quit [Quit: Leaving]
mgl has quit [Quit: Client closed]
attila_lendvai has joined #commonlisp
mgl has joined #commonlisp
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<Nilby>
Does anyone have experience with a debian or brew package for Lisp software?
abrantesasf has joined #commonlisp
<yitzi>
For packaging lisp systems or lisp implementations?
<yitzi>
If you don't care that it "freezes" the dependencies.
<Nilby>
That's what I'm thinking, but I'm wondering if there's examples of how people have done that with brew or debian.
<Nilby>
Maybe I'm not good enough at searching the package archives for Lisp software.
<yitzi>
I have used it in building maxima-jupyter and common-lisp-jupyter kernels, but distributed Lisp source code via brew and especially debian is a bad idea, IMHO.
<Nilby>
Right. My package is going to be just a binary, but for those systems they seem to prefer a source package which build to a binary package.
<yitzi>
Are the users of your package going to load their own quicklisp packages? Or just run your binary?
<Nilby>
Just run the binary.
<Nilby>
Of course they could always use Quicklisp separately.
<yitzi>
Then quicklisp bundles would work just fine. One problem you may have with Debian is that you are effectively distributing the source code of all of your dependents so you'll need to include all of the licenses in the copyright file. For brew you could always make your own tap, so you don't really need to worry about getting approval from the brew folks.
ronald has joined #commonlisp
<Nilby>
Right. The big pile of liscenses thing. I guess just getting a .deb or tap that people can install would be good. I see the common-lisp-jupyter and maxima-jupyter repo, but I don't see any packaging artifacts.
<ixelp>
GitHub - ktp-forked-repos/slowlisp: A staging repository for Fedora bound spec files based on Zach Beane's quicklisp pro [...]
<Nilby>
The whole common-lisp-controller was a very admirable attempt by great people, but it seems to have languished.
<green_>
Nilby.. you could also look at just bundling a ocicl systems.csv file and users could pull the dependencies with ocicl! It uses the same distribution backend infrastructure as homebrew.
<Nilby>
I'd be glad to add to ocicl, which seems promising, but I was hoping to get to a point of a single command install with a familiar/native packager.
<Bike>
the inner catch, but it's intercepted before it reaches
<nij->
@@.. why would it be intercepted? Shouldn't the inner catch returns immediately?
<nij->
after catching the first throw?())
<Bike>
because interception is what unwind-protect does
<Bike>
the first throw never "reaches" the inner catch. before it can, it has to execute the unwind-protect cleanup. the cleanup initiates another throw, aborting the first.
<beach>
green_: Not sure, but this could just be ASDF that converts warnings during compilation to an error to load the system.
<green_>
I don't think so. Every other package has a ton of warnings.
mgl has quit [Quit: Client closed]
<beach>
Oh, OK.
<nij->
You can customize a certain system to be more sensible.
<Bike>
that is the error you'd get from asdf if it was failing on a warning, tho.
<nij->
So maybe in that failing system it's explicitly said that warnings are converted into errors.
dev001 has joined #commonlisp
<nij->
bike - Oh, that's why unwind-protect is not a macro..
NicknameJohn has joined #commonlisp
<nij->
Hmm bike still weird - (unwind-protect (pprint 1) (pprint 2)) prints 1 first and then 2..
<Bike>
yeah?
<Bike>
and with the throws, it does the first throw, then the second throw. it's just that the first throw is, as i said, aborted by the second.
abrantesasf has quit [Remote host closed the connection]
<Bike>
with pprint, the pprint call doesn't transfer control. it's just a normal call and that completes without trying to escape the unwind-protect.
<nij->
I see.
<nij->
Thanks.
<nij->
This kind of catch/throw mechanism only works when the throw form is nested in the catch form, right?
<beach>
No.
<nij->
And if I want to remove this nesting requirement, I need call/cc?
<nij->
? oh no
<beach>
CATCH/THROW use the dynamic environment.
<beach>
Whereas BLOCK and TAGBODY use the static environment to find exit points.
<Bike>
you can do (defun foo (f) (catch 'fizzbuzz (funcall f))) (defun bar () (throw 'fizzbuzz 23)) (foo #'bar)
<Bike>
i think this is actually why beach mentioned catch/throw to you yesterday, because you were trying to do it with block/return-from
<beach>
nij-: Like I said to you before: You can use RETURN-FROM and GO only when the BLOCK name or TAGBODY tag is in the lexical scope. So as edwlan[m] says, you need to use CATCH/THROW.
<nij->
Oh wow, there's such difference! Note taken :)
<nij->
How about call/cc? What sort of magic is that?
dev001 has quit [Remote host closed the connection]
<Bike>
well it doesn't exist in lisp, mainly
<beach>
nij-: That's very different. It basically remembers the entire call stack.
<Bike>
if you're curious you can read SICP or something.
<Alfr>
While we're at this ... something related: Is it possible to implement coroutines using CL only?
<beach>
nij-: The call stack is actually not a call stack, but a representation of what computations to do next. So if that stack is remembered and re-established later, then you can do the future computation again.
<Bike>
Alfr: i don't think you could do it without a code walker/compiler extension of some kind
<Alfr>
Hm ... guess that's a no. As getting at surrounding env is a problem in making a code walker.
<Bike>
i basically meant that as a no, yeah
<nij->
Alfr how are they related? I thought coroutines are just routines that run in threads @@?!
<Alfr>
bike, nevertheless thanks for telling me this. :)
<Alfr>
nij-, if you have call/cc you can easily implement coroutines.
<nij->
What are coroutines really? I can't implement them using threads?
<Alfr>
nij-, you essentially make a continuation and yield, invoking the continuation later will resume the computation where you left off; and there you essentially have coroutines.
<beach>
nij-: Sure, threads are more powerful that coroutines, but since threads are not part of Common Lisp, you can't implement them using just Common Lisp.
<Alfr>
An other problem w/ threads is that they are quite expensive to create.
<beach>
Alfr: That would depend on the operating system, no?
<nytpu>
nij-: coroutines are non-preemptive (i.e. the coroutine decides when to interrupt itself) while threads typically are preemptive (the OS or runtime decides to interrupt them); and threads are often parallel while coroutines are never parallel
<Alfr>
beach, sure. But I think the CL out in the wild utilize OS threads and for at least Windows and Linux both creation and switching to/from is expensive.
<beach>
Sure, for the disastrous Unix-likes (which includes Windows), it is very likely expensive.
<nytpu>
the synchronization to emulate being non-preemptive is trivial, the main thing is ensuring callers block while the coroutine is running so you don't have the caller and the coroutine running simultaneously (if the system supports parallelism/true multithreading)
<Alfr>
beach, I've played with Erlang the last few days, so yeah, I do understand that it seems possible to make it rather cheap. :)
<beach>
Right!
<nytpu>
Alfr: that's done by language threads not being 1:1 with os threads; IIRC you have a pool of (potentially short-lived) language threads that a set of long-lived OS threads handle, so you're not constantly creating and destroying OS threads but instead lightweight language-specific objects
Cymew has quit [Ping timeout: 240 seconds]
<hayley>
"Hello Joe." "Hello Mike."
<hayley>
OTP uses a "scheduler" per core, from memory, and some other OS threads for performing I/O, as it's difficult to do non-blocking file I/O in Unix.
<nij->
I see. Thanks beach Alfr.
<nij->
I wonder, how do coroutines and the dynamic stack coexists?
<nij->
Does the coroutine remember the dynamic context as well?
<nij->
Or would a later change of the dynamic context alters the behavior in a coroutine?
citizenajb has joined #commonlisp
<hayley>
I think it is reasonable that a coroutine should remember its dynamic environment (which code-walkers tend to fail at, too).
johnjaye has quit [Ping timeout: 256 seconds]
<Bike>
i have not really used coroutine, but my understanding is that the yield operator essentially saves the current continuation and then returns, and then calling the coroutine again resumes from that saved continuation.
<Bike>
probably gets exciting if the coroutine nonlocally exits or something
* Nilby
got baited into crashing my O/S with 1M lisp threads the other day.
<Alfr>
nytpu, begs the question, why can't an OS handle threads in a similar fashion?
johnjaye has joined #commonlisp
mgl has joined #commonlisp
<nij->
Nilby 1M threads? How was that possible? I remember the limit on my local machine is around 9000.
<Alfr>
nytpu, or what's the difference as beam thread have their own stack and heap etc. I know that beam it also imposes rather draconic restrictions.
<Alfr>
nytpu, and beam also preemptively schedules its processes.
morganw has joined #commonlisp
chrcav has quit [Ping timeout: 264 seconds]
<Nilby>
nij-: it's potentially possible, but in my case practically impossible, hence the crash
<Alfr>
bike, that's essentially why gilberth hates continuations, especially in combination w/ unwind-protect.
<citizenajb>
Alfr: don't people generally just use thread pools instead of creating / destroying threads (just addressing your initial comment that thread creation is expensive)? You can use coroutines in Common Lisp by combining something like the cl-cont library with a thread pool pretty straightforwardly, but it has a lot of downsides. Debugging is very
<citizenajb>
hard, coroutines are contagious (meaning you need to wrap everything with call/cc all the way down, as you have to do with standard async/await usage), exception handling is hard... I understand the appeal of the "seeming single threadedness" of async/await coding, but I've never felt it's quite the silver bullet as everyone now-a-days seems to
<citizenajb>
think.
<Nilby>
nij-: I had to adjust some limits
chrcav has joined #commonlisp
<nij->
cool, Nilby
<hayley>
If it seems single threaded, that's because you haven't ever wanted to hold any state consistent across an await. scnr
mgl has quit [Quit: Client closed]
<Alfr>
citizenajb, don't know, never touched the async/await stuff myself, sorry.
<hayley>
Coroutines also waste the other 11 cores (or 23 logical cores); thread pools are good for short-lived tasks, but I couldn't use a pool to manage a large number of long-lived connections, without breaking up the code to manage one connection.
<Bike>
Alfr: i have seen a pretty good attempt at reconciling continuations with unwind-protect, in that it's well-defined, but also like an order of magnitude more complicated than CL's rules
<Bike>
which are already quite arcane
citizenajb has quit [Quit: Client closed]
<Alfr>
citizenajb, hayley said what I'm after nicely, in particular keeping related code in one place.
citizenajb has joined #commonlisp
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
<hayley>
Each thread should (in my opinion) do something like (loop (handle-message (read-message))), but that loop would not map to a thread pool nicely.
<Alfr>
bike, interesting, as I certainly would love to have both. xD
nij_ is now known as nij-
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
nij_ is now known as nij-
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
nij_ is now known as nij-
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
nij_ is now known as nij-
<Alfr>
hayley, beam! ;)
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
nij_ is now known as nij-
nij_ has joined #commonlisp
nij- has quit [Killed (NickServ (GHOST command used by nij_))]
nij_ is now known as nij-
nij- has quit [Client Quit]
nij_ has joined #commonlisp
nij_ has left #commonlisp [#commonlisp]
<Alfr>
hayley, you also may have lispy syntax w/ https://lfe.io .
<ixelp>
(LFE:Lisp Flavoured Erlang)
<hayley>
And (again in my opinion) cooperative scheduling is very anti-modular, as one misbehaving module which never yields/awaits/etc can deadlock the system, and relying on yields makes for very all-or-nothing concurrency control.
<hayley>
Alfr: I already did some university work in Erlang. Seemingly I am the only person on the planet who is fine with Erlang syntax (maybe after being exposed to Prolog before).
<jackdaniel>
scheduler may also use interrupts that respect critical sections, then yield is optional
<jackdaniel>
(i.e unix timers)
Fare has joined #commonlisp
citizenajb93 has joined #commonlisp
<citizenajb93>
nij- on your early question about non local exits: Here's what I would do if I wanted callees to be able to cause a non-locally exit in my function... https://bpa.st/M4BWC (has an example of using #'call-next-method also which isn't non-local, but contains the same idea)
<ixelp>
View paste M4BWC
citizenajb has quit [Ping timeout: 245 seconds]
<beach>
citizenajb93: What do you have against CATCH and THROW?
<citizenajb93>
beach: nothing, it's just another way of expressing this.
NicknameJohn has quit [Ping timeout: 240 seconds]
rgherdt_ is now known as rgherdt
azimut has quit [Ping timeout: 240 seconds]
szkl has quit [Quit: Connection closed for inactivity]
<Nilby>
(documentation 'sb-ext:with-timeout 'function) has a point
morganw has left #commonlisp [ERC 5.5 (IRC client for GNU Emacs 28.2)]
citizenajb93 has quit [Quit: Client closed]
cage has joined #commonlisp
Fare has quit [Ping timeout: 248 seconds]
tyson2 has joined #commonlisp
NicknameJohn has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
occ has quit [Ping timeout: 250 seconds]
NicknameJohn has quit [Ping timeout: 248 seconds]
xaltsc has joined #commonlisp
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
<beach>
I seem to recall there is a compatibility library for thing that are needed to inspect the call stack, like a backtrace, and frame contents. Maybe by Shinmera?
<beach>
I was just looking into the CLIM debugger, and it uses SWANK which I am not very happy about.
<Shinmera>
Dissect could use an overhaul. It's been stale for a long time.
<Shinmera>
it does still work, it's just not... pretty.
<beach>
I see.
<beach>
Maybe if I work on the CLIM debugger, or a replacement of it, that will prompt some updates.
<Shinmera>
Sure, would be happy to review.
<beach>
I am in fact working on a portable condition system that is much more complete (in terms of documentation, comments, etc.) than that of phoe, and I just couldn't see myself writing a line-oriented debugger.
<beach>
Not only more complete, but that can be built to be used intrinsically.
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
igemnace has joined #commonlisp
jurassic has quit [Ping timeout: 256 seconds]
tyson2 has joined #commonlisp
rgherdt has quit [Read error: Connection reset by peer]
rgherdt has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
rgherdt has quit [Ping timeout: 256 seconds]
rgherdt has joined #commonlisp
Inline has joined #commonlisp
alcor has joined #commonlisp
<beach>
Brucio-61: I am about to leave for the day (so I'll read your answer tomorrow). Do you have strong opinions about whether the CLIM debugger uses SWANK or Dissect?
<yitzi>
If you intended to use SWANK then a portable version such as conium would be better. If it wasn't bit-rotted.
scymtym has joined #commonlisp
edgar-rft has joined #commonlisp
mgl has joined #commonlisp
Fare has joined #commonlisp
<scymtym>
beach: if you are asking whether the McCLIM debugger currently uses swank, the answer is yes. regarding the question whether it should use swank or dissect, i'm not sure. one thing to keep in mind is that swank provides things other than analyzing the stack: utilities for conditions, functions for working with restarts and eval in frame
<scymtym>
swank provides return from frame and restart frame as well but i don't think the McCLIM debugger uses those at the moment
igemnace has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 264 seconds]
amb007 has joined #commonlisp
<Shinmera>
yitzi: dissect is the maintained replacement for the stack parts.
<Shinmera>
and some other parts of swank are in Definitions, for instance.
<yitzi>
I understand. I use in common-lisp-jupyter
<Shinmera>
dissect currently doesn't do eval-in-frame, but it's been on the todo for ages.
<Shinmera>
so far, mysteriously, nobody seems to have remedied that. How curious! :)
mgl has quit [Quit: Client closed]
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 240 seconds]
MichaelRaskin has joined #commonlisp
MichaelRaskin has quit [Client Quit]
akoana has joined #commonlisp
jurassic has joined #commonlisp
<jackdaniel>
perhaps people work on their own personal dissects because they don't want to spend time on other people projects ,)
euandreh has quit [Ping timeout: 256 seconds]
euandreh has joined #commonlisp
enzuru has quit [Ping timeout: 264 seconds]
dcb has joined #commonlisp
zyni-moe has joined #commonlisp
zyni-moe has quit [Client Quit]
scymtym_ has joined #commonlisp
kevingal has quit [Ping timeout: 268 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
scymtym has quit [Ping timeout: 248 seconds]
Brucio-61 has joined #commonlisp
abrantesasf has joined #commonlisp
NicknameJohn has joined #commonlisp
msavoritias has quit [Ping timeout: 240 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
scymtym_ has quit [Ping timeout: 248 seconds]
cage has quit [Remote host closed the connection]
alcor has quit [Read error: Connection reset by peer]
yottabyte has joined #commonlisp
son0p has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
attila_lendvai has quit [Ping timeout: 240 seconds]
ec has quit [Ping timeout: 240 seconds]
ec has joined #commonlisp
mgl has joined #commonlisp
chrcav has quit [Ping timeout: 240 seconds]
chrcav has joined #commonlisp
mgl has quit [Quit: Client closed]
rgherdt_ has quit [Remote host closed the connection]
son0p has joined #commonlisp
Fare has quit [Ping timeout: 250 seconds]
tyson2 has joined #commonlisp
<copec>
I've been setting up dnsdist loadbalancers at my work, it is mostly written in C++ but with LUA JIT bindings, and the config for it is a LUA source file that ends up creating the live running image, which you can alter in most ways in the live server - add/remove backend servers or front end services or routing mechanisms or blocks.
<copec>
Just makes me think how well a CL image would be as a load balancer