MichaelRaskin has quit [Ping timeout: 240 seconds]
<aeth>
drmeister: What's wrong with clnuplot? It should just be generating text based on s-expressions, right? I could probably write one in a weekend since I've already written maybe 4-5 of those.
semz has joined #lisp
semz has joined #lisp
<drmeister>
I'm trying eazy-gnuplot
<drmeister>
clnuplot spat up an error the first example I tried.
Fare has joined #lisp
<drmeister>
Thank you.
dented42 has joined #lisp
dented42 has quit [Client Quit]
<drmeister>
I just wrote a Factorio-like simulator for a complex chemical process that generates lots of outputs. I wanted to graph some quantities.
<drmeister>
I could write one but bleh.
<drmeister>
one = gnuplot interface.
<drmeister>
Hi Fare - what's cookin'?
<Fare>
Programming languages are cooking.
<drmeister>
Fare: Has cracauer been in touch? We'd like to talk seriously about parallelizing asdf.
<Fare>
Currently using #gerbil-scheme though.
<Fare>
I haven't had contact with Martin for months, when I last invited him to speak at the Boston Lisp Meeting next time he's in town.
<Fare>
I have plenty of ideas on how to parallelize ASDF the right way
<Fare>
OR, you could use Bazelisp...
<drmeister>
Is baselisp written in Common Lisp?
EvW1 has joined #lisp
<Fare>
hahahaha
<drmeister>
Right
anewuser has joined #lisp
<Fare>
no, it's written in a reduced python dialect written in Java
<Fare>
but it compiles Common Lisp code.
<Fare>
and I suppose you could write a backend for SBCL targetting "Skylark" (the name of that Python subset supported by Bazel)
<drmeister>
We got our phase II grant from the DOE and we are hiring programmers to work in Common Lisp - we need to speed up building quicklisp code.
<Fare>
the TODO file in asdf/ has many ideas on how to extend ASDF into a ASDF4 that would do the Right Thing™ wrt cross-compilation, buying you parallelization for free.
<Fare>
I mean, real deterministic distributed build, not mere parallelization on a multiprocessor like POIU.
<drmeister>
We are very interested in that - as in we might even be able to put money into it.
<Fare>
POIU kind of works, BTW. Not sure where the bugs are.
<Fare>
I'm willing to consult.
<drmeister>
Hmm, cracauer went to bed - I'll ask him to get in touch with you again.
<drmeister>
We've got some crazy exciting things going on here.
holycow has quit [Quit: leaving]
<Fare>
If you just want parallelization on a multiprocessor, POIU is good.
<drmeister>
Does it work now with the latest ASDF? I thought it was sort of locked to an older version?
<Fare>
Not sure anymore.
<Fare>
Let me just try it...
atgreen_ has quit [Ping timeout: 276 seconds]
<drmeister>
Clasp is running 3.3.1.2
atgreen_ has joined #lisp
<Fare>
Is there anything wrong with 3.3.3.3 ?
milanj has quit [Quit: This computer has gone to sleep]
<drmeister>
I don't think so - other than that's a lot of 3's
<drmeister>
Are you suggesting that if we upgrade to 3.3.3.3 POIU will work?
<Fare>
I tried to run the poiu test, and it failed for unobvious reason. I'm not sure whether it's supposed to work at all with the 3.3 series.
<Fare>
3.3 introduces changes to deal with multi-stage builds properly. Some of these changes might have to be reflected in POIU.
<Fare>
although the error I see looks like failure to create a directory.
<Fare>
sorry, no time to look into it.
<drmeister>
My laptop just froze - back in a few min
Arcaelyx has joined #lisp
<drmeister>
Hello
<drmeister>
That was unusual
renzhi has quit [Ping timeout: 240 seconds]
<Fare>
WTF aedp — apparently, ASDF 3.3 violates one of the previous invariants of POIU early on. What other invariants are broken, I can't say.
<Fare>
Do you want POIU-style parallelism, or Bazel-style distribution?
<Fare>
In the latter case, why not "just" use Bazel?
<Fare>
that said, if you hack ASDF into reimplementing the key parts of bazelisp as ASDF4 — yay.
<Fare>
My guess is that POIU needs to be told about the multi-phase plan structure of ASDF 3.3
<Fare>
but this is all out of my cache.
pfdietz80 has joined #lisp
Guest84233 has joined #lisp
Guest84233 has quit [Quit: rcirc on GNU Emacs 27.0.50]
slyrus_ has joined #lisp
slyrus has quit [Ping timeout: 240 seconds]
davepdotorg has joined #lisp
oni-on-ion has joined #lisp
davepdotorg has quit [Ping timeout: 276 seconds]
<drmeister>
I don't know about POIU-style parallelism vs Bazel-style
<drmeister>
But integrating another program Bazel into our build system doesn't seem that attractive
<drmeister>
How does the parallelism of Bazel differ from POIU?
equwal has joined #lisp
shifty has quit [Ping timeout: 268 seconds]
semz has quit [Ping timeout: 246 seconds]
semz has joined #lisp
davr0s__ has joined #lisp
davr0s has quit [Ping timeout: 240 seconds]
davr0s_ has quit [Ping timeout: 252 seconds]
davr0s has joined #lisp
EvW1 has quit [Ping timeout: 250 seconds]
gravicappa has joined #lisp
equwal has quit [Quit: rcirc on GNU Emacs 27.0.50]
montxero has joined #lisp
Bike has quit [Quit: Lost terminal]
<Fare>
drmeister, Bazel actually runs every "build action" in its own process, in its own sandbox, where it only has access to the declared inputs and can only create the declared outputs
<Fare>
it is deterministic (assuming actions are deterministic also), and can farm the build actions on a large number of servers
<drmeister>
Can it work with asdf systems?
<Fare>
there is or was a converter from simple asdf systems to bazel files
<Fare>
but in general, no
<Fare>
there was a collection of build files for some systems
<Fare>
that include corresponding pinned versions of the source code (that's the bazel way)
<drmeister>
It doesn't sound appropriate then. We aren't building a standalone application - we want quicklisp systems to be integrated as needed.
<drmeister>
We have a slow compiler (because of llvm) and parallel compilation would be valuable.
<Fare>
bazel is as parallel as it gets
<Fare>
are you trying to farm out to many compilation servers?
<Fare>
or only to one large multiprocessor?
<drmeister>
All of the cores of the current processor.
<Fare>
ok, so POIU-style is what you want
<drmeister>
Yeah - I've read the documentation for POIU and we parallelize clasp's compilation already.
<drmeister>
When I load our chemistry code - it's a lot of asdf systems with dependencies.
<drmeister>
That drops back to serial, single core compilation - very painful.
<Fare>
POIU drops back to serial??
<drmeister>
No - we'
<Fare>
because POIU isn't stable enough with 3.3 ?
<drmeister>
We've never gotten POIU working. I haven't tried to drop back to the old version of ASDF to run it.
<Fare>
ok
<Fare>
well, I know it can be made to work with a bit of effort.
Oladon has joined #lisp
vlatkoB has joined #lisp
ggole has joined #lisp
equwalp has left #lisp ["Changed major mode"]
quazimodo has joined #lisp
montxero has quit [Ping timeout: 240 seconds]
Fare has quit [Ping timeout: 268 seconds]
housel has joined #lisp
Arcaelyx has quit [Quit: Arcaelyx]
poet` has joined #lisp
ebrasca has quit [Remote host closed the connection]
poet has quit [Ping timeout: 276 seconds]
atgreen_ has quit [Ping timeout: 240 seconds]
pfdietz80 has quit [Ping timeout: 260 seconds]
torbo has quit [Remote host closed the connection]
Arcaelyx has joined #lisp
sindan has quit [Remote host closed the connection]
sindan has joined #lisp
poet` has left #lisp ["ERC (IRC client for Emacs 26.3)"]
<drmeister>
That's our new website. More news soon.
froggey has joined #lisp
<no-defun-allowed>
I will have to check if Cando is on the authorised material list.
Arcaelyx has joined #lisp
<drmeister>
Authorized material list?
<no-defun-allowed>
And I will have to check if that's the name of that list either. Probably not, but I mean the list of things you can take into the exam.
<no-defun-allowed>
"Students are permitted to bring into the examination room: pens, pencils, highlighters, erasers, sharpeners, rulers and one scientific calculator." Doesn't look like it, sadly.
<drmeister>
Ah
<beach>
Exams with no documents allowed should be banned.
<no-defun-allowed>
Absolutely. My greatest fear is that I cannot remember the reaction pathways for organic compounds, which are not in the data booklet.
<ebzzry>
Does anyone have experience with ceramic.github.io?
Arcaelyx has quit [Ping timeout: 268 seconds]
matijja has joined #lisp
slyrus_ has joined #lisp
raghavgururajan has quit [Remote host closed the connection]
scymtym has quit [Ping timeout: 268 seconds]
slyrus__ has quit [Ping timeout: 240 seconds]
slyrus__ has joined #lisp
flamebeard has joined #lisp
slyrus_ has quit [Ping timeout: 276 seconds]
<LdBeth>
*no-defun-allowed*: acidic alkali
<no-defun-allowed>
The laws of quantum physics^W^Wchemistry forbid this (I think).
_whitelogger has joined #lisp
nowhere_man has joined #lisp
<LdBeth>
there's a thing called acidic alkali chloroaluminate I remember
davepdotorg has joined #lisp
raghavgururajan has joined #lisp
davepdotorg has quit [Ping timeout: 265 seconds]
<Cymew>
I tried to load woo, clack and teepeedee2 and all fail on different asdf errors. Have they all bit rotted, or should I start to question my quicklisp setup? Suggestions?
<jasom>
Cymew: are you using sbcl?
<Cymew>
Yes.
<Cymew>
1.5.x on Fedora.
ym has quit [Ping timeout: 240 seconds]
<Cymew>
sbcl-1.5.7 even.
shka_ has joined #lisp
gxt has joined #lisp
<jasom>
1 sec, I'm updating my dists to see if it works...
<jasom>
Clack worked for me as recently as sbcl 1.4.x
<jasom>
and clack just loaded with an up-to-date quicklisp and sbcl-1.5.0
<jasom>
woo didin't load because no libev installed...
<jasom>
fixing more deps of woo...
<jasom>
woo just loaded fine
<Cymew>
It sounds like I have a distry environment in that case. Thanks for the reality check!
raghavgururajan has quit [Read error: Connection reset by peer]
<Cymew>
s/distry/dirty/
<Cymew>
I watched Fare's walkthrough video of asdf3 last night. Man is that a complex piece of machinery! I guess it just failed...
scymtym has joined #lisp
brettgilio has joined #lisp
<jasom>
Cymew: you can always remove ~/.cache/common-lisp and try again. also (ql:update-all-dists) to make sure you're up-to-date...
<jasom>
lastly, teepeedee2 loaded correctly.
<jasom>
oh, after wiping .cache/common-lisp if it still fails, check to see if there is anything in ~/.cache/common-lisp/sbcl-$VERSION/ other than your home quicklisp directory; you may have an old (or modified) version installed somewhere that asdf is picking up. quicklisp is the source of last-resort, when doing a quickload.
<Shinmera>
projects don't get rolled out into quicklisp unless they load
makomo has joined #lisp
<Cymew>
jasom: Thanks. I never seem to be able to find all those cache directories. I will do some wiping.
<Cymew>
Shinmera: True, but sometimes if you also use local projects it can be a bit hard to follow the chain of dependencies to make sure you're just using the quicklisp dist.
ym has joined #lisp
<Cymew>
I have a develop branch of teepeedee2 for example. Maybe I should just wipe that as well.
Oladon has quit [Quit: Leaving.]
Duuqnd has joined #lisp
ravenousmoose has joined #lisp
<Cymew>
A better question is why there are no small and nimble web server in cl that aren't the undocumented mess that comes from fukamachi.
<jasom>
Cymew: does hunchentoot count?
<jasom>
I guess I could write a webserver. I maintain one written in C (that I use for my own lisp web projects).
zaquest has quit [Quit: Leaving]
zaquest has joined #lisp
raghavgururajan has joined #lisp
<Cymew>
jasom: I think hunchentoot is a bit heavier and feature complete for many occations. If you just want to have an endpoint to GET data from, as more and more software these days use HTTP as a transport protocol.
<Cymew>
That being said, I have a lot of respect for Edi as a lisp hacker, so maybe I should just use hunchentoot.
<Shinmera>
If only HTTP was as simple to implement as it pretends to be
<Cymew>
God, my grammar is worse than ever...
<jasom>
hmmm; my impression was that clack is way feature-y (is that a word?) thatn hunchentoot.
<Cymew>
jasom: Could be. There's not a lot of documentation to read and compare.
<jasom>
Shinmera: HTTP/1.1 is pretty straightforward, particularly if you limit yourself to supporting the 5 or 6 most popular clients subset of the features.
<Cymew>
Shinmera: Yeah, I did notice that as I started down the path myself.
<Cymew>
It's the corner cases that kills it. Many odd corners in the HTTP RFCs out there.
<jasom>
doing it efficiently in the face of many connections gets hard quickly though.
<Cymew>
Maybe just doing the basics would be a start.
<jasom>
Cymew: reset the connection in a corner case. It will still work with curl, firefox, safari, chromium and wget...
<Cymew>
jasom: You might be right.
<Cymew>
...actually why am I not just using hunchentoot? :)
<Cymew>
I think it was considered a bit slow when it was first released. Maybe I should benchmark it.
<Shinmera>
It is slow, but that doesn't really matter in most cases.
<jasom>
Cymew: My recollection is that it scales poorly to 1000s of simultaneous connections, but is fine for smaller usage.
<flip214>
that got me to an answer time of <100µsec (if there's no external dependency like a database) and that should be good enough for a first try
<Cymew>
So the empty space in the "market" is for something that just implements GET and PUT and can do thousands of connections per second as a API gateway or data transport.
<Cymew>
flip214: Nice. I'll look into that.
raghavgururajan has quit [Remote host closed the connection]
<flip214>
and getting much more performance means using userspace threads (fibers, coroutines, or whatever you want to call them), and that means rewriting the processing to use call/cc...
fivo has joined #lisp
<jasom>
flip214: does quux-hunchentoot allow persistent data in the thread pools? Not opening a new DB connection for each request is a *huge* win performance wise when a DB is in the picture (and most (all?) of the clack backends I've seen don't support this even when they are thread-pooled).
<jasom>
flip214: and implementing call/cc needs to be done first :)
<flip214>
jasom: cl-cont is already there
<jasom>
flip214: does it offer a performance profile that one might expect from a call/cc or green-thread implementation?
varjag has joined #lisp
<flip214>
well, I've understood that the basic problem is that the database connection needs to be tied to the _object_ you're editing, not to a thread or so.
<flip214>
so that the "SELECT FOR UPDATE" is on the right database handle
<flip214>
so for thousands of simultaneous connections you might end up with thousands of simultaneous db-connections (unless handled more sanely), and that way lies madness
<jasom>
flip214: typically your database request will not exceed the dynamic scope of your http request. This means that so long as a single thread completes the http request before handling more work, a single DB connection per thread is sufficient.
<Cymew>
Indeed.
<flip214>
jasom: no idea. I just use quux, and I've had a green-thread implementation in C under my fingertips for a few years
<flip214>
jasom: oh yes, it will! a user clicks "edit" on the wiki page
<flip214>
and that means you should lock it in the database...
<Cymew>
Databases does makes things harder.
<Cymew>
Almost all things, actually.
<jasom>
flip214: and this needs a persistent DB handle because?
<flip214>
a single PUT (for create) or DELETE might just use any connection, right
<flip214>
jasom: because doing an UPDATE on a different database handle than the one you did SELECT FOR UPDATE on is a bad idea
<flip214>
if you don't use database locks, you'll have fun considering all possible merge conflicts that can happen in your code...
<fivo>
Hey, I have some questions concerning reader syntax.
jackdaniel has joined #lisp
<fivo>
Is there a way to tell SLIME how to indent multiline reader syntax?
<jasom>
flip214: it really seems like a bad idea to have a single DB transaction require multiple http requests
<fivo>
I have some print-object specialization which I only want to kick in when the new syntax is enabled, how do I best go about that?
<flip214>
jasom: if you don't do that, you'll write a "locked-by" user and a "locked-at" timestamp field and process timeouts manually...
<jasom>
flip214: most applications I've seen are usually "first writer wins" or "merge" not "first requester locks"
<flip214>
fivo: that sounds like a bad idea. the object printing might happen to _any_ output stream, there's no connection to the input syntax reader.
<flip214>
jasom: well, it depends on the use case, of course. Just sayin' that it's complicated - sometimes.
<jasom>
flip214: it honestly never occured to me to have a transaction with a lifetime longer than a single http request, so I'll have to ruminate on this.
<jasom>
http has such a strong "stateless" bias after all...
<jasom>
fivo: your best bet might be to just add a new minor-mode for when you will be using the custom syntax. IIRC slime doesn't have much support for custom reader macros.
<jasom>
fivo: and my current preferred method for enabling reader macros is to use named-readtables. The enable- was preferred when named-readtables did not yet exist.
<fivo>
flip214: ok, so either have the new print-object method defined whenever the lib is loaded or not at all?
<jasom>
fivo: oh if it wasn't clear the "minor-mode" suggestion was to make a minor mode for emacs that you can use when the read-table is sufficiently foreign for slime to be confused.
davepdotorg has joined #lisp
<fivo>
jasom: yes got that. I guess I look into named-readtables then.
<jasom>
flip214: 1. continuations rarely encapsulate all state. 2. IMO, Allowing arbitrary state flow across http requests from a client causes more problems than it solves. I have tried things both ways and have preferred to push the server-side state to the database and keep the application code state-free.
jonatack has quit [Quit: jonatack]
<flip214>
jasom: depends on the use-case... if serialization to the database is too costly (because of network latency) you'll have to keep it locally, for example. but yes, the less state the better.
hhdave has joined #lisp
<jasom>
flip214: agreed. There are times when keeping state in a particular place can make big wins in either reducing complexity or increasing performance, so it's a preference rather than a hard rule. I have found over the years that I've moved from "Databases does make things harder" as Cymew said to "Any state outside the database needs to be justified."
jonatack has joined #lisp
<flip214>
Is there a function that compares strings but also allows symbols, but won't crap out on CONS cells? I've got nested alists and alexandria:assoc-value; :test #'EQUAL doesn't work with :|foo|, and #'STRING= breaks at a sub-alist.
<jasom>
flip214: don't forget anything you do find will likely be wrong in the case of "nil" compared to ()
<flip214>
jasom: well, NIL is not a keyword, and nobody should write try to find a :|nil| key ;)
<flip214>
jasom: yeah, of course I can provide a lambda. I didn't know whether one of the existing comparison functions already works that way.
<jasom>
flip214: perhaps I'm confused; do you want people to be able to match :|foo| with "foo" because thats how I read it...
<loke>
Or 'NIL with "NIL
<loke>
I mean "NIL
<loke>
argh
<loke>
"NIL"
<loke>
(I'm soooo bloody used to Paderit that I never type closing quotes/parens)
<jasom>
first-world IDE problems...
<flip214>
jasom: after parsing a JSON struct I have some nested structure, and want to find data in there. I'd like to use keywords for matching, because if the structure is returned by other code it's just a pointer comparison.
<flip214>
ie. (alexandria:assoc-value tree :|foo|) instead of "foo"
<jasom>
ah
<jasom>
yeah, I think writing your own test is likely the best.
<flip214>
thanks!
<jasom>
b/c you want :|foo| to match :|foo| efficiently, but also still be able to match "foo", but don't care about the inverse of "foo" matching :|foo|
davepdotorg has quit [Remote host closed the connection]
<jasom>
perhaps (typecase y (symbol (eql x y)) (string (string= (string x) y)) (t nil))
<loke>
flip214: If the things you are matching against are strings, why don't you just stringify the argument?
<jasom>
loke: the things he is matching against might be strings or might be keywords; flip214 wants an efficient compare if they are keywords.
davepdotorg has joined #lisp
<loke>
jasom: should be a trivial things to write? :-)
shka_ has quit [Ping timeout: 268 seconds]
Jesin has quit [Ping timeout: 265 seconds]
jonatack has quit [Ping timeout: 276 seconds]
lavaflow has quit [Read error: Connection reset by peer]
lavaflow has joined #lisp
aasmundo has joined #lisp
aasmundo is now known as Mandus
davepdotorg has quit [Remote host closed the connection]
davepdotorg has joined #lisp
<remexre>
with SBCL, how do I set floating-point flags back to where C might expect them to be? I've got some foreign code that I think is trapping on a divide by zero, in this case.
kommandotolken has joined #lisp
<remexre>
nvm, foudn it
<remexre>
you'd think this'd be in the manual
<no-defun-allowed>
(sb-int:set-floating-point-modes :traps nil) looks like a good start.
<remexre>
yeah, that's what I'm trying (after wrapping it in a macro so it's a with-* thing)
<no-defun-allowed>
Or maybe (sb-int:with-float-traps-masked (:overflow :invalid :divide-by-zero) ...) if you just want that in a small part of your code.
<remexre>
oh, didn't see that
<remexre>
Yeah, I'll do that; it's only for foreign calls, and the relevant ones already have a wrapper macro for error handling anyway
<leo_song>
how to define type specifier alias? For example, define a "u32" to make (make-array 5 :element-type 'u32) == (make-array 5 :element-type '(unsigned-int 32))
kommandotolken has quit [Quit: This computer has gone to sleep]
kommandotolken has joined #lisp
gabiruh_ has joined #lisp
gabiruh has quit [Ping timeout: 268 seconds]
random-nick has joined #lisp
m00natic has joined #lisp
_whitelogger has joined #lisp
benkard has joined #lisp
nowhere_man has quit [Ping timeout: 268 seconds]
mulk has quit [Ping timeout: 240 seconds]
benkard is now known as mulk
Lycurgus has quit [Quit: Exeunt]
orivej has joined #lisp
gxt has quit [Ping timeout: 260 seconds]
rumbler31 has joined #lisp
m00natic has quit [Remote host closed the connection]
rumbler31 has quit [Ping timeout: 245 seconds]
m00natic has joined #lisp
pfdietz32 has joined #lisp
<pfdietz32>
It's better if you can arrange all the strings to be converted to keywords first. This is what I do for json (at least, for the names to left of the colons).
<pfdietz32>
Somewhat surprisingly, just calling INTERN was not the fastest way to do that.
<jackdaniel>
and what was the fastest way?
<jackdaniel>
pfdietz32: ^
<pjb>
make-symbol can be faster, but it's less useful.
<pfdietz32>
In the json some of those strings appear a lot. Use a string-case macro to handle those, and call INTERN if nothing matched.
<shka_>
one can instead generate something like qp trie for every case
<shka_>
and that would work fine, i think
<shka_>
should be fairly simple as well
davepdotorg has quit [Remote host closed the connection]
atgreen_ has joined #lisp
jackdaniel has quit [Ping timeout: 268 seconds]
<pjb>
pfdietz32: read again what I wrote! ultimately, it has to check only ONE!
ravndal has quit [Quit: WeeChat 2.6]
ravndal has joined #lisp
fivo has quit [Ping timeout: 245 seconds]
jackdaniel has joined #lisp
milanj has joined #lisp
fivo has joined #lisp
EvW has joined #lisp
anewuser has quit [Quit: anewuser]
_paul0 has joined #lisp
<pfdietz32>
In the case where it will not take the default branch, it has to confirm all the characters match. You are right if it's going to fall through with the first character not matching any of the cases.
<pfdietz32>
BTW, string-case finds it faster to match more than one character, even there.
paul0 has quit [Ping timeout: 276 seconds]
milanj_ has joined #lisp
<shka_>
you can match multiple characters at once with bit manipulation
<pfdietz32>
It generates checks like (= (logior (logxor (char-code (schar s 0)) (char-code #\f)) …) 0) for chunks of up to 4 (?) characters.
<shka_>
makes sense
milanj has quit [Ping timeout: 276 seconds]
toorevitimirp has joined #lisp
davepdotorg has joined #lisp
raghavgururajan has joined #lisp
frgo has joined #lisp
Bike has joined #lisp
nowhere_man has joined #lisp
<Bike>
pfdietz32: sbcl's case is using jump tables now?
<pfdietz32>
Yes, a bunch of commits over the last week. It should show up in release at the end of the month.
<Bike>
neat.
<pfdietz32>
These will work on the common cases of fixnums, characters, and symbols. For cases returning constants, it will get optimized to vector accesses.
<Bike>
symbols all get a hash, i see
toorevitimirp has quit [Ping timeout: 265 seconds]
<pfdietz32>
(looks at history) last two weeks
Fare has quit [Ping timeout: 246 seconds]
<Bike>
yeah, i was trawling through
raghavgururajan has quit [Read error: Connection reset by peer]
matijja has quit [Remote host closed the connection]
gareppa has quit [Quit: Leaving]
cosimone has joined #lisp
anewuser has joined #lisp
<Bike>
is CL-LLVM still like, usable? it looks like it hasn't got any commits since 2017, and llvm has changed in that time
jgkamat has joined #lisp
vaporatorius has joined #lisp
lucasb has joined #lisp
davepdotorg has quit [Remote host closed the connection]
davepdotorg has joined #lisp
cosimone has quit [Quit: Quit.]
cosimone has joined #lisp
jackdaniel has quit [Read error: Connection reset by peer]
rumbler31 has joined #lisp
jackdaniel has joined #lisp
Duuqnd has quit [Quit: Leaving]
Oddity has joined #lisp
rumbler31 has quit [Ping timeout: 245 seconds]
cracauer has joined #lisp
<cracauer>
hello
<cracauer>
fare/tunes, are you here?
warweasle has joined #lisp
jonatack has quit [Ping timeout: 246 seconds]
<Cymew>
cracauer: I've not seen him around lately.
<Shinmera>
He was here earlier.
<luis>
cracauer: fare was Last seen : Nov 11 13:17:03 2019 (41m 9s ago)
<flip214>
ALEXANDRIA:IF-LET says "sequentially binds", but the first bound variable is not available for the second form. Shouldn't there be an IF-LET* too?
grabarz has joined #lisp
<Bike>
looks like it says "All initial-forms are executed sequentially in the specified order. Then all the variables are bound to the corresponding values." which is a bit different from "sequentially binds"
<Bike>
but there's also a when-let*, so i i guess if-let* could be ok too
<cracauer>
My parallel pipe dream is that top-level s-expressions that are defuns and have no side-effects are compile or load time are all done in fork()ed processes.
<flip214>
Bike: yeah, sorry, I may have misquoted.
<Bike>
looks like when-let* may screw up declarations tho
<beach>
cracauer: Why would you want to do that?
<Bike>
it's harder because when-let* is supposed to actually stop if anything is false
<cracauer>
For programs that are highly parallel at runtime you typically have lots of side-effect functions. Such a source code should also be suitable for parallel compilation of those defuns.
<Bike>
that might be the reason, really, with a bunch of ifs do they all go to the same else clause or what
<beach>
cracauer: You could do that with threads and first-class global environments.
<Bike>
oh. that's what phoe's page says. cool
<Bike>
i am Smart
<beach>
cracauer: Then, the compilation environment would be created for each compilation.
<cracauer>
Yes. Fork isn't much more overhead, though.
<phoe>
Bike: I just recalled this question being asked on #lisp before
<phoe>
and that I noted this down earlier
warweasle has quit [Quit: back later]
pfdietz32 has quit [Ping timeout: 260 seconds]
<flip214>
phoe: yeah, I wouldn't need the (potentially) bound variables in the ELSE part... because I don't have any ;) I just switched to WHEN-LET*.
jonatack has joined #lisp
cods has quit [Ping timeout: 276 seconds]
<flip214>
thanks!
<phoe>
flip214: yes, you wouldn't need them, but the semantics would need them - IF-LET* would require a well-defined false branch
<phoe>
and we can't really well-define them in this case due to unbound variables
cods has joined #lisp
<flip214>
well, so just define it to have _none_ of the variables available
<Bike>
could you define if-let* so that in the else branch- yeah that.
<Bike>
might be more inconvenient to write the macro, tho.
<flip214>
Bike: well, just have a gensym bound to a (lambda () ,else) before doing anything with variables
<Bike>
i guess that works. i was thinking in terms of tagbodies
<cracauer>
Another crazy parallel compilation thing is to compile defuns without (much) inlining at first and fire up an inlined version's compilation in the background at the same time. Depending on what loading the first one does to the environment you can then either abandon the background compile, or let it go through and re-load the function. Speculative computing.
<cracauer>
fork(2) is life. Nothing can convince me otherwise :-)
<flip214>
cracauer: try clone(2), that has even more interesting options available
<cracauer>
It is just so useful to safely fire up speculative computing and pick up the work, or not, based on outcome.
<Bike>
microsoft paper quoting the BeBook. how about that
<Bike>
er, citing
<cracauer>
I use clone(2). With all the options that turn it into a fork(2) equivalent.
fivo has quit [Quit: WeeChat 1.9.1]
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cracauer>
I think I would like to have fasl files where changes to the environment on load have hooks.
<cracauer>
That way I could determine whether loading the same file in an optimized version later is safe or not.
jonatack has quit [Ping timeout: 265 seconds]
<luis>
cracauer: the other day I read about how Google compiles Lisp code on their compile farm... It's... insane. :)
<flip214>
cracauer: please help to parallelize ASDF first... and QL second, before talking about form-level concurrency ;/
<cracauer>
luis: I did not like Lisp in blaze/basel much.
Bike has quit [Remote host closed the connection]
<luis>
flip214: would you be willing to write header-like files (that declare functions, types, classes, defines macros) etc as a way to parallelize system compilation?
<cracauer>
Yes. -ish
<cracauer>
But you don't need to.
<flip214>
luis: is that needed? my understanding is that lots of things could be compiled in parallel already.
<cracauer>
Before blaze/bazel QPX was compiled by loading all files into the interpreter.
<cracauer>
Then fork the actual compilation per file.
Bike has joined #lisp
<cracauer>
Some forms of environment modifications had to be managed by hang, though.
<luis>
I'm not interested in solutions that require fork() :(
<cracauer>
So, the interpreter loads fast enough that you can load all the inline/macros right along with defuns.
<flip214>
luis: and furthermore, recent SBCL could export the (derived) types of functions after a single sequential compilation
<cracauer>
Keep in mind that many side-effect defuns might be used by compile-time computing.
<luis>
cracauer: sure. Does would need to be in the header file as well.
<luis>
s/Does/Those
<cracauer>
So if you were to do header-like files you don't only have to move inlined things in and out, but you also need a repository of defuns used at compile time.
<luis>
In CFFI's case for instance, the whole thing would need to be available at compile time, pretty much.
<cracauer>
Right, but that would work in the scheme of loading interpreted first, then do compilation in the background in parallel.
clothespin has quit [Ping timeout: 276 seconds]
<luis>
cracauer: are you going to sbcl20?
<cracauer>
So to speak, you use the entire Lisp file as "header file" in that you load everything interpreted, and while you have the defuns in there the defuns are not intended to be used that way and will be "fixed up" by compilation later.
<cracauer>
I will go to Vienna. Looking forward to seeing everybody.
<cracauer>
There's also a Nighwish show the Wednesday afterwards in case anybody is interested in an outing.
<luis>
Symphonic metal. Hmm. Not the first genre that comes to mind when thinking of Vienna. :-)
<cracauer>
\m/
<trittweiler>
luis: are you going too?
<cracauer>
Symphonic is symphonic, no? :-)
<luis>
trittweiler: yes!
<trittweiler>
Happy to hear. Me too
<cracauer>
cool
pfdietz has quit [Remote host closed the connection]
<Shinmera>
I'm very sad I won't be able to make it
<cracauer>
I still think that speculative computing is a way to parallel compile improvements. Do something quick, see if it has side effects, if not you are free to do a long compilation in the background and reload.
<cracauer>
Of course that only works good if you have more CPUs than current parallelism.
<cracauer>
Which is almost always the case in quicklisp compilation right now.
<cracauer>
And even Clasp's core doesn't nearly fill out a 32-core machine, not to mention 48 cores which you can have for < $200 now.
<cracauer>
(plus RAM)
<luis>
I'm actually more interested in being able to do incremental compilation (i.e., reuse as many fasls as possible) rather than compiling in parallel. But, of course, the two problems are related.
<luis>
(Particularly when it comes to dependencies across systems.)
<cracauer>
luis: that doesn't solve out Clasp problems, when we rebuild the base compiler and recompile everything because we don't know what is actually required.
ljavorsk has quit [Ping timeout: 265 seconds]
<cracauer>
However, again, it would help if fasls would be marked for their load-time side effects.
<cracauer>
I guess that can be proven "harmless" fasls or sub-fasls.
<cracauer>
A pure code-only fasl is much more re-usable in a safe manner.
<pjb>
or fast fasl.
<Bike>
i feel like you really have to fight the language semantics here
<Bike>
something as simple as a constant with a make-load-form means side effects
shallotfan87 has joined #lisp
pfdietz has joined #lisp
<pfdietz>
Any fasl that refers to a symbol that might not already exist has load time side effects.
FreeBirdLjj has joined #lisp
<cracauer>
Yes, but the trick is that I don't have to magically figure that out. With speculative computing I get the yes/no on side effects when loading the result of the foreground quick compilation. If it was "clean", I will load the result of the background compilation later. If not, I abandon the background compilation and compile "good enough" in the foreground.
<flip214>
I don't think you can _know_ whether it was clean.... how about #+feature and this being only available after loading a library?
<cracauer>
But wouldn't that have sequential semantics anyway?
vaporatorius has quit [Read error: Connection reset by peer]
<cracauer>
The dependency graph would always place users of that #+feature sequentially after whatever is providing it.
<pfdietz>
I want a build system with this property: I can write rules so that if I've loaded system FOO, and also system BAR, then at that point I want to load some system FOO+BAR. And FOO and BAR can be loaded in either order.
<cracauer>
pfdietz: I guess you would have to be clean wrt load time order. All referenced symbols must exist for the background compilation's result to be picked up.
<cracauer>
I guess that would limit parallelism for quicklisp quite severely.
EvW has quit [Ping timeout: 245 seconds]
Inline has joined #lisp
Inline__ has quit [Ping timeout: 264 seconds]
dddddd has joined #lisp
vaporatorius has joined #lisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
milanj_ has quit [Quit: Leaving]
milanj has joined #lisp
<beach>
Is there a publication that is mainly about PCL (as in Portable Common Loops)?
<beach>
... with emphasis on "mainly".
vaporatorius has quit [Ping timeout: 268 seconds]
jackdaniel has quit [Ping timeout: 252 seconds]
cosimone has quit [Quit: Quit.]
vaporatorius has joined #lisp
<Bike>
i tried looking at the CMU archived PCL and the text file in it that I think is dated latest advertises "Even less documentation than ever before"
<beach>
Hmm, OK. Thanks.
vaporatorius has quit [Read error: Connection reset by peer]
<Bike>
also that the runtime architecture and MOP have been rewritten for the release, and that there are no more versions because they're working on AMOP
<Bike>
or well, the metaobject protocol, i guess
<beach>
I see.
<Bike>
kind of interesting seeing the changelogs though. "MAJOR CHANGES IN THIS RELEASE: [...] it is possible to forward reference classes in a defclass form"
<beach>
OK, but I was interested in finding a bibliographic reference to include in my new paper.
<Bike>
right, i know. i thought this might have pointers to an actual publication but this is more like, well, an experimental software release
jackdaniel has joined #lisp
<Bike>
in google scholar... here's a 1990 article that mentions PCL but has no citation for it. that would have been contemporaneous with the text file
<Cymew>
It would be interesting if someone published an explanation of how Common Loops and New Flavors and CLOS relate to each other.
<Cymew>
I have never managed to figure that out.
<beach>
Cymew: The Wikipedia page on CommonLoops mentions that.
<Bike>
oh yeah, there's "Efficient Method Dispatch in PCL"
<Bike>
i think you already cited that one
<Cymew>
beach: Thanks. I must have missed that.
<beach>
Bike: That article, and the AMOP book both have some PCL material in them.
<beach>
Bike: But I was looking at a publication that essentially is entirely about PCL.
davepdotorg has quit [Remote host closed the connection]
h116 has quit [Client Quit]
schweers has quit [Ping timeout: 245 seconds]
jonatack has quit [Quit: jonatack]
varjag has joined #lisp
h116 has joined #lisp
matijja has quit [Ping timeout: 265 seconds]
atgreen_ has quit [Ping timeout: 240 seconds]
cods_ has joined #lisp
jonatack has joined #lisp
cods_ has quit [Client Quit]
gxt has joined #lisp
hhdave has quit [Quit: hhdave]
matijja has joined #lisp
srji has joined #lisp
gxt has quit [Ping timeout: 260 seconds]
xuxuru has joined #lisp
EvW1 has joined #lisp
gxt has joined #lisp
matijja has quit [Ping timeout: 276 seconds]
buffergn0me has joined #lisp
kommandotolken has quit [Quit: This computer has gone to sleep]
nowhere_man has quit [Ping timeout: 240 seconds]
matijja has joined #lisp
adip has quit [Ping timeout: 265 seconds]
adip has joined #lisp
kommandotolken has joined #lisp
Necktwi has quit [Ping timeout: 240 seconds]
random-nick has quit [Ping timeout: 240 seconds]
cosimone has joined #lisp
cosimone has quit [Client Quit]
grabarz has joined #lisp
cosimone has joined #lisp
brettgilio has quit [Ping timeout: 250 seconds]
emys has joined #lisp
sjl has joined #lisp
scymtym has joined #lisp
emys has quit [Ping timeout: 245 seconds]
emys has joined #lisp
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgherdt has joined #lisp
kommandotolken has quit [Quit: Leaving]
grabarz has joined #lisp
Bike has quit [Remote host closed the connection]
Bike has joined #lisp
<pfdietz>
I had an annoyance with the pcl in sbcl recently. If you mind *macroexpand-hook*, it affects the on-the-fly code generation in the pcl implementation, and if the function you bound uses generic functions, a vicious metacircularity could crash the whole thing.
random-nick has joined #lisp
davepdotorg has joined #lisp
<Bike>
does it do code generation like that other than for make/allocate instance?
milanj has quit [Quit: This computer has gone to sleep]
<Bike>
i didn't know pcl invoked the compiler there.
<Bike>
wonder if there's anything besides macroexpand hook that would be implicated there... that isn't implementation specific, anyway, i'm sure there's a trillion variables that could affect it
cosimone has quit [Quit: Quit.]
igemnace has quit [Remote host closed the connection]
<sjl>
Seemed to work well for my (admittedly small) needs
<montxero>
sjl: I'm just browsing through the documentation now
<montxero>
sjl: my needs are tiny as well. I thought there might be a way to do everything on the lisp side in a lispy dsl, which then compiles to sqlite strings at the very end
<sjl>
by "sqlite strings" you mean the actual SQL query strings?
<montxero>
yeah
<sjl>
There's probably a library for turning sexps into SQL strings, but I personally prefer just writing the SQL myself.
<sjl>
(unsure if that thing only works with postmodern or is a separate component that you could use independently)
<sjl>
I just write the SQL as strings myself.
<montxero>
My needs are small enough that I'll just write the strings.
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bendersteed has joined #lisp
lucasb has quit [Quit: Connection closed for inactivity]
akoana has joined #lisp
<montxero>
sjl: thank you. For your work, tutorials, and blog. They have been invaluable to me over the years. First it was bad wolf and vim related stuff in 2016, then I found your blog last year when I started Common lisp. When I started whith mercurial on bitbucket, your work turned up again: the tutorial post you made on the subject was illuminating. Your repos, help me understand how to structure my Common Lisp Code. Thank you, you're a
<phoe>
sjl: montxero: regarding SQL, I find CL-YESQL to be very useful for my own use cases
<phoe>
these allow me to write individual queries as pure SQL and then have them automatically wrapped as Lisp functions with keyword arguments and annotated return types
jackdaniel has quit [Quit: jackdaniel]
Achylles has joined #lisp
emys has joined #lisp
emys has quit [Ping timeout: 246 seconds]
sjl has quit [Ping timeout: 240 seconds]
yvy has quit [Quit: Leaving]
yvy has joined #lisp
anon987321 has joined #lisp
Josh_2 has joined #lisp
sjl has joined #lisp
random-nick has quit [Ping timeout: 268 seconds]
shka_ has quit [Remote host closed the connection]
anon987321 has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
Bike has quit [Quit: Bike]
frgo has joined #lisp
yvy has quit [Remote host closed the connection]
quazimodo has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]
lavaflow has quit [Quit: WeeChat 2.6]
lavaflow has joined #lisp
<montxero>
phoe: This looks promising!
ebrasca has quit [Read error: Connection reset by peer]
ebrasca has joined #lisp
buffergn0me has quit [Ping timeout: 245 seconds]
hiroaki has quit [Ping timeout: 240 seconds]
hiroaki has joined #lisp
lavaflow has quit [Quit: WeeChat 2.6]
lavaflow has joined #lisp
bendersteed has quit [Remote host closed the connection]