<blunder>
I'm using a 2D array to store a few constant instances of an ad-hoc data structure. The structure has no instances outside of this sequence. Is that a reasonably correct use of a (2D) array or is there a more correct way to go about that?
blunder has quit [Quit: leaving]
<mfiano>
I'm not sure what rank has to do with storing things, so sure?
blunder has joined #commonlisp
<blunder>
I'll try to clarify: I'm using an array as a struct because there's no other place the structure appears so I don't know if a defstruct is warranted. I have seven instances in an array. Is a 2D array semantically appropriate in this situation or should I define a real structure?
thuna` has quit [Remote host closed the connection]
habamax has joined #commonlisp
<mfiano>
defstruct is rarely ever warranted, especially as it is clear this is not an optimization pass over a finished idea.
<LispTyro>
lol, i now know enough Common Lisp to get the pun of the /topic
<LispTyro>
#1, as number 1 but #1=(progrommable . #1#) is also circular list
<LispTyro>
s/progrommable/programmable
<LispTyro>
yay, understanding
<fitzsim>
hi mfiano, what do you think of my pull requests for ppc64 support for cl-sdl2?
<mfiano>
blunder: What yu are asking is if a rank-2 (but let's ignore the rank) array is an appropriate data structure to store adhoc data in. It depends on the problem domain and consumers of this protocol among other things. You will get different answers depending on who you ask.
<mfiano>
A list is a good choice, as is a closure, or pretty much anything else. But what are the access patterns, who uses it and cares, etc, are the real questions.
blunder has quit [Ping timeout: 246 seconds]
<mfiano>
fitzsim: Let me check
<mfiano>
Hold on, something's up with my GH notifications. I've been away too long and for some reason I'm no longer getting notified on the Web or in email.
<fitzsim>
ah, OK
Gleefre has quit [Remote host closed the connection]
<fitzsim>
let me know if you want me to comment on one of my PRs to test your notifications
<mfiano>
Do you mean cl-sdl2-image
<mfiano>
?
<fitzsim>
yeah
<fitzsim>
and also cl-sdl2 and cl-sdl2-ttf
<fitzsim>
roughly the same change for all three of those
<fitzsim>
oh, I can get the PR numbers, one sec
<mfiano>
ttf I do not maintain.
<fitzsim>
oh, OK; I wonder who maintains the one I get from quicklisp
<ixelp>
Add ppc64 and ppc64le support by fitzsim · Pull Request #2 · lispgames/cl-sdl2-ttf · GitHub
<fitzsim>
that's the ttf one, yeah
<mfiano>
lispgames/cl-sdl2-ttf somehow never got deleted years ago when there was a missing depends-on entry in the system that i patched.
<fitzsim>
ahhh, OK
<mfiano>
but the upstream url is failproofshark/cl-sdl2-ttf
<mfiano>
and
<fitzsim>
gotcha, will resubmit there
<mfiano>
This person is unresponsive. cl-sdl2-ttf _does not_ work with cl-sdl2 as of like 5 years ago
<fitzsim>
oh, OK
<fitzsim>
lem-sdl2 seemed to pull in cl-sdl2-ttf
<fitzsim>
let me double-check that
<mfiano>
Well I am going to delete it right now because that is even behind
<fitzsim>
sure
<mfiano>
and the 1 commit is merged upstream
<mfiano>
This might clear the confusion
<mfiano>
I was wondering why people were always asking me about cl-sdl2-ttf
<fitzsim>
oh yeah, there's "Renamed SDL_ttf.h to SDL2_ttf.h", in Failproofshark's PRs
<fitzsim>
maybe you should be its maintainer if Failproofshark has disappeared :-)
<fitzsim>
(but I'm never sure how to get quicklisp pointed to a new upstream; had this same situation with unix-opts too)
<mfiano>
I am not interested in maintaining any foreign library wrappers, sorry. I am only maintaining cl-sdl2 because the original author handed it to me on his way out of Lisp
<fitzsim>
sure, fair enough
blunder has joined #commonlisp
<mfiano>
I also don't think cl-sdl2 is very viable in the long term, and I would recommend a more lightweight set of bindings like the one zulu-innuoe has
<fitzsim>
ok; lem-sdl2 is using cl-sdl2 though
<fitzsim>
which is what got me debugging cl-sdl2 on ppc64
<mfiano>
This is because of its dependency on c2ffi, a C++ program that uses llvm to dump everything
<fitzsim>
yeah
<mfiano>
and the same author that left lisp wrote that
<fitzsim>
ah, darn
<mfiano>
Actually, jackdaniel (not here right now) is working on SDL support for McCLIM, so you can ask what he uses over in #clim maybe
<fitzsim>
I'm more interested in just patching cl-sdl2 for now
<fitzsim>
so lem-sdl2 works on my machine
<fitzsim>
it'd be great if lem had a mcclim backend though
<ixelp>
Add ppc64 and ppc64le support by fitzsim · Pull Request #165 · lispgames/cl-sdl2 · GitHub
<mfiano>
Seems to be just specs so no problem with that. It's better than no spec for that target triplet
<mfiano>
Merged
<fitzsim>
thanks!
<mfiano>
Sure
<fitzsim>
do you maintain cl-sdl2-image too?
<mfiano>
Sorry to be so unresponsive. I am always on IRC though, whether active or not, and actually get notified when pinged ;)
<fitzsim>
oh no problem, thanks for maintaining cl-sdl2
<mfiano>
Not really. I only 'maintained' that to remove the finalizers (why cl-sdl2-ttf doesn't work anymore), which were a MAJOR source of bugs internal to cl-sdl2 and to users following along with official documentation with the Free* API's, resulting in...double-frees
<mfiano>
finalizers are generally a bad idea, especially in cases like this with multiple threads
<mfiano>
scheme invented something called guardians i have to read about
<mfiano>
I don't know. I don't do much foreign code programming. I like Lisp :)
<fitzsim>
yeah
* fitzsim
digs into quicklisp to figure out where a given systems's upstream repo is
<fitzsim>
I can't find a function in quicklisp to return this
<mfiano>
when you use quicklisp with the quicklisp distribution, you are using a snapshot that was downloaded at a specific point in time by the quicklisp maintainer
<fitzsim>
right
<fitzsim>
but is it published somewhere what repo the quicklisp maintainer pulled the snapshot from?
<mfiano>
you would have to look at the date, and then compare the code to find out which (if there are multiple) commit it was for that day
<mfiano>
(if it was published with revision control system; some quicklisp projects are just pulled as zips or tarballs from http)
<mfiano>
Oh
<fitzsim>
"git remote" doesn't work in ~/quicklisp/dists/quicklisp/software/cl-sdl2-image-20190202-git, for example
<mfiano>
The quicklisp-projects repository is what you want to look at
<ixelp>
Add ppc64 and ppc64le support by fitzsim · Pull Request #10 · lispgames/cl-sdl2-image · GitHub
<fitzsim>
(unless you see something wrong with it)
<fitzsim>
oh, look, quicklisp pulls from sharplispers for cl-sdl2-ttf.git
<mfiano>
Ah that might be _death's doing
<mfiano>
I remember talking to them about it
<fitzsim>
great! sharplispers are active maintainers as I remember from their prior repos
<mfiano>
Ah guess it was zulu
<mfiano>
zulu has good sdl2 bindings if you just want raw bindings not generated automatically and easy to hack on
<fitzsim>
nice
<fitzsim>
oh darn, lem is on Discored
<mfiano>
Any of the WITH-* macros in cl-sdl2 shouldn't be used in my opinion, and replace INIT/QUIT with INIT*/QUIT*.
<fitzsim>
*Discord; otherwise I would ask them about that
<mfiano>
Then it works fine, and is low level without the buggy threading stuff the original author implemented
<mfiano>
But it is still autogenerated mess to maintain :)
<fitzsim>
yeah, the autogenerated files are huge
<fitzsim>
and also encode system paths, which I thought was weird
<mfiano>
I was talking about the code you're actually supposed to read. Those are blobs to me :)
<fitzsim>
c2ffi wasn't too bad to build from source, and it did work though, FWIW
<fitzsim>
I'm checking lem code for usage of with-* now...
<mfiano>
This requires you to use sdl2 like the official documentation (sdl2 wiki) instructs.
<fitzsim>
seems to use them: sdl2:with-rects
<mfiano>
Call free for the types yourself
<mfiano>
free-rect, etc
<fitzsim>
ah, I see; yeah, I can imagine with-* being problematic when different threads are involved, unless the wrapper code is really careful
<mfiano>
that might not be a problem
<mfiano>
I think with-init and the event loop one especially imply sdl2:init which splits off a thread
<mfiano>
if you use init* (with the *) and it works, then you don't have weird bugs to worry about (and also easier to live code without threading nonsense, since you can do things like: https://joaotavora.github.io/sly/#REPLs-and-game-loops
<ixelp>
SLY User Manual, version 1.0.42
<mfiano>
)
<fitzsim>
just found: (defun create-display (function) (sdl2:with-init (:video) ...
<fitzsim>
oh have to drop for tonight; if you can review cl-sdl2-image/pull/10 and maybe add me to lispgames so I can commit it if it looks ok, that'd be great!
<fitzsim>
thanks for all your help, mfiano!
<fitzsim>
I'll submit the cl-sdl2-ttf ppc64 support to sharplispers
<fitzsim>
ttyl
<mfiano>
then again people use with-* without issues, so ymmv
blunder has quit [Ping timeout: 246 seconds]
<mfiano>
But all the issues I had to look into were because of the threading code, and removing finalizers helped my sanity most of the way. There's still this certain popular OS that likes to mess things up each update, screwing up SBCL all the time though.
<mfiano>
among just the main thread management code that needs to disappear or be put behind another less prominent API
<mfiano>
fitzsim: (i already added you to lispgames; you should have an invite in your email)
<ixelp>
adding load-texture to the mix... by serialhex · Pull Request #3 · lispgames/cl-sdl2-image · GitHub
<fitzsim>
I'd have to test it out, I guess
<fitzsim>
commented on the outstanding PR too; it became unmergeable so probably should just be closed at this point, unless the original submitter is still interested
<ixelp>
Add ppc64 and ppc64le support by fitzsim · Pull Request #1 · sharplispers/cl-sdl2-ttf · GitHub
<fitzsim>
going offline for real now
elderK has joined #commonlisp
habamax has quit [Remote host closed the connection]
l4q has joined #commonlisp
<l4q>
Hi, I was wondering why it seems that people are not /that/ concerned with generic function performance in Lisp (compared to say C++, Rust, or Julia communities, where this is a big selling point)?
<l4q>
I am aware of the static-dispatch (and the earlier inlined-generic-functions) library, but I think actually I am missing some "intuition" or lisp usage best practice, because it seems there is not really an effort to, say, add a JIT to SBCL to deal with this
<hayley>
In Common Lisp, C++ and Rust one can just not write code with ad-hoc polymorphism.
<hayley>
And that's usually the "fix" to generic function performance.
<l4q>
my understanding of C++ templates and Rust traits is that they don't cost any performance penalty...
<hayley>
They implement "parametric polymorphism", not "ad-hoc polymorphism".
goober has quit [Remote host closed the connection]
goober has joined #commonlisp
<hayley>
A generic function in Common Lisp is more like a virtual method in C++, or using a dyn «trait» type in Rust. Those aren't very fast either.
<l4q>
hayley: that's fair, but many uses of generic functions are compatible with "parametric polymorphism", and while I also know there are packages in Lisp that attempt to add that as well, I am asking if actually I should just "not want it" :)
<hayley>
It's a fine thing to want.
<l4q>
I am assuming compiler writers/language designers (especially for something as thought-out as Lisp) took this shortcoming into account, and I just haven't completely understood the rationale.
<hayley>
To paraphrase, "write excellent programs, then mold compilers and machines to make these programs efficient, rather than vice versa".
<hayley>
I assume lack of manpower to implement spiffier compilers, personally.
<|3b|>
keep in mind cl was "thought-out" quite a while ago, and similarly most CL implementations are very old
<|3b|>
and CL (and its users) generally favors interactivity and flexibility over performance by default
<l4q>
makes a lot of sense :) more specifically, I end up writing lots of numerical code which should operate on a few types (for example matrix methods that operate on sparse and dense matrices, over real/complex/finite fields, etc), which is in general much more convenient/reasonably performant in SBCL than Python (when there isn't something pre-packaged), and am trying to come up with reasonable best-practices for the future
<hayley>
I am working on a JIT compiler (currently designing, not so much programming it) for another language. Though a Common Lisp frontend would be interesting.
<|3b|>
refitting ancient compilers like sbcl to effectively use a JIT would probably be a lot of work, and there is still plenty of stuff just on the AOT compiler to take up the available dev time :/
<hayley>
|3b|: At some point those become one and the same. For example I get to my final project for university is all Common Lisp, and fast code is crucial for fast turnaround, in turn crucial for fast iteration.
rtypo has quit [Ping timeout: 260 seconds]
<|3b|>
hayley: yeah, i've had that problem a few times too :/
<hayley>
It is pretty damn fast, and gave me an excuse to invent a SIMD-based algorithm for pretty much no reason.
<hayley>
The extreme of the (logxor interactive fast) mindset would be CPython: either write dynamic Python or fast C, but you can't have both, and managing the distinction is a nuisance.
<|3b|>
l4q: also the fact that the AOT compiler is generally available at runtime, and compile-time is particularly flexible in CL means that a lot of the people who do need that performance can optimize things themselves, reducing the pressure for the compilers to get faster
<|3b|>
(as for example the various static/sealed/etc clos things)
<|3b|>
for the specific case of numerical code, my advice is keep clos out of the hot path, and try to reduce your need for a wide variety of element types (for example always use double or always singles)
<hayley>
SBCL can take its time to compile the code I generate for regular expressions, which isn't amazing. I twiddle the internal variables to get a worse compile than (declare (optimize (speed 0) (compilation-speed 3))) [which doesn't hurt here], and added a metaphorical mirror (linter) outside the elevator to keep users happy.
<hayley>
If someone asked me very nicely, I might have to Greenspun lazy compilation.
<|3b|>
but for example you could have clos classes for sparse etc matrixes, if they are usually reasonably large (presumably the case if you care about sparse)
<char[m]>
blunder: You can make a struct use an array instead of the usual object. Then you get nice accessor and constructors, but it is represented as an array.
<aeth>
Personally, I usually just create them with my own macro because the defstruct generation doesn't generate what I want generated and generates some stuff I don't care about
<aeth>
e.g. it doesn't generate a type, while I can easily add a DEFTYPE in the macro
<aeth>
(normal structs do generate a type)
* |3b|
usually does that manually too, in particular i usually want inlined constructors with coerce so i can pass 1 to things that store floats
<l4q>
Thanks for the input!
<l4q>
|3b|: so what is the preferred solution when numerical algorithms can work over several types? they can be quite different, for example sometimes the same algorithm works for finite fields (i.e. bits and so on) and real numbers
<l4q>
or say you have a shortest path algorithm; it's very convenient to have "get-weight" as a generic function, as well as most of the graph traversal functions
* |3b|
hasn't found good answers for that yet :/
<|3b|>
i tend to end up trying to write a compiler at some point and give up :p
<ixelp>
GitHub - alex-gutev/static-dispatch: Static generic function dispatch for Common Lisp
<aeth>
oh that's "new"
<l4q>
anyway, I was hoping for an answer like "you're probably worrying about some tiny effect" or that in reality dispatch is actually crazy fast because of some caching or something :)
<|3b|>
it sounds like your problems might be fairly coherently generic though, so maybe you could have the "generic" part return specialized functions, and pass those into the bulk code
<l4q>
what does "coherently generic" mean? and are you suggesting returning a lambda (or function symbol) from generic functions?
<|3b|>
(with some macros and/or structs hiding things to make it look nicer)
<l4q>
is it really faster to return a function object from a generic and then use that in an inner loop?
<l4q>
that I thought branch prediction would obviate
<|3b|>
i mean you probably always have the same type of values in a matrix, or always use the same get-weight within a particular search
<|3b|>
so calling the generic function once at the beginning and it returns specialized code that is called N times
* |3b|
might be estimating wrong though, since my biases are more towards things where even normal functions are expensive :)
<|3b|>
(relatively small operations on single-floats or small integers, etc)
habamax has joined #commonlisp
<l4q>
oh but here I have a very specific question. I am choosing between (1) implementing get-weight as a generic function that returns the weight and (2) implementing get-weight-getter, which returns (fundamentally) an address to another compiled function, or a lambda expression, right?
<l4q>
it's not obvious to me that in an inner loop (2) is better than (1)
<l4q>
because the address of the call may be cached somewhere, effectively doing the same thing as (2)? or branch prediction might make (1) better somehow, I don't know. but if you agree with my understanding of your suggestion and you say (2) is better generally than (1) that's great advice, thanks!
<|3b|>
even optimized generic function dispatch is at least checking the types of any arguments with specializers
<|3b|>
and maybe some checks for methods having been added, etc
<|3b|>
(and for that matter, calls through names in general usually add an indirection because CL allows things to be redefined at any point)
<|3b|>
and the important part is that 2 happens outside the loop, so that only the returned value is called inside the loop
<|3b|>
calling (funcall (get-weight-getter ..) ...) in a loop would probably be slower than calling get-weight
<|3b|>
the other missing part of the answer is "wait until it gets too slow to worry about it too much" :)
<|3b|>
call it "prototyping" if that makes writing something you "know" will be slow easier
<l4q>
|3b|: of course I would call get-weight-getter outside the loop, i was more worried about calling through a variable which is saved outside the loop being slower than dispatch because the latter is somehow more heavily optimized, but it seems you are suggesting it's not. thanks!
<|3b|>
much less painful to decide you hate the api of a "quick prototype" than of a "years of work super optimized"
<l4q>
I guess I am actually surprised that generic functions would check the types repeatedly in an inner loop
<|3b|>
CL likes passing functions around, so it is fairly optimized too :)
<|3b|>
well, how else would you know you are calling the correct method?
<l4q>
I understand that in general you probably always have to check, but if you have some relatively simple loop you could imagine that the compiler could factor the check out
<|3b|>
only if it knows the types of all the values in advance (and even then the fact that you can redefine the gf or add methods while the loop is running makes it harder)
<l4q>
or at least that the types are not checked /inside/ the generic function call; if they are just used for dispatch again I would have thought there could be some tricks with caching. anyway SBCL is already way beyond anything I imagined for volunteer effort, I'm not complaining just trying to get a feel for performance :)
<l4q>
thanks a lot for your input
<|3b|>
just checking the types /is/ the trick with caching :p
<|3b|>
(remember the last used method, see if it matches the current call, etc)
* |3b|
doesn't know exact details though, so might be better or worse on any particular implementation
<|3b|>
and it all has to happen inside the generic function due to both redefinition/adding methods and due to passing them around as function objects
azimut has quit [Ping timeout: 240 seconds]
habamax has quit [Remote host closed the connection]
l4q` has joined #commonlisp
l4q has quit [Ping timeout: 260 seconds]
l4q`` has joined #commonlisp
l4q` has quit [Ping timeout: 260 seconds]
l4q`` has quit [Ping timeout: 260 seconds]
shka has joined #commonlisp
triffid has joined #commonlisp
Gleefre has joined #commonlisp
alcor has joined #commonlisp
jsomedon has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
amb007 has quit [Ping timeout: 250 seconds]
amb007 has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
randm has quit [Remote host closed the connection]
randm has joined #commonlisp
pve has joined #commonlisp
mgl has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
AetherWind has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
Algernon69 has joined #commonlisp
Algernon69 has quit [Client Quit]
amb007 has quit [Ping timeout: 250 seconds]
amb007 has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
cage has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
rgherdt has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
randm has quit [Remote host closed the connection]
habamax has joined #commonlisp
randm has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
dino_tutter has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
<jcowan>
|3b|: CL wasn't really designed either; a great many features in it are the products of long evolution. The last time the CL tradition (excluding Scheme, Clojure, Dylan, etc.) was *designed* was about 1958.
Demosthenex has quit [Ping timeout: 260 seconds]
Demosthenex has joined #commonlisp
nij- has quit [Ping timeout: 246 seconds]
nij- has joined #commonlisp
<mgl>
Judging by the end result, I reckon a lot of design must have been done either at standardization or by individual implementations, likely both.
nij- has quit [Ping timeout: 246 seconds]
rtypo has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
<beach>
mgl: What makes you think that? I mean, CLtL1 already existed, and CLOS also existed independently.
<mgl>
beach: In 1958?
<beach>
Oh, I thought by "standardization" you meant the work that gave the standard.
mgl has quit [Quit: Client closed]
attila_lendvai has joined #commonlisp
blunder has joined #commonlisp
tyson2 has joined #commonlisp
waleee has joined #commonlisp
rbcarleton has joined #commonlisp
blunder has quit [Ping timeout: 240 seconds]
blunder has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
blunder has quit [Ping timeout: 246 seconds]
azimut has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
dino_tutter has joined #commonlisp
igemnace has joined #commonlisp
rtypo has quit [Quit: WeeChat 4.0.1]
rtypo has joined #commonlisp
ezakimak has quit []
McParen has left #commonlisp [#commonlisp]
tevo has quit [Read error: Connection reset by peer]
tevo has joined #commonlisp
thuna` has quit [Ping timeout: 260 seconds]
thuna` has joined #commonlisp
morganw has joined #commonlisp
Lycurgus has joined #commonlisp
justache is now known as reddit-boat
reddit-boat is now known as justache
igemnace has quit [Quit: WeeChat 4.0.2]
Lycurgus has quit [Quit: Tschüss]
igemnace has joined #commonlisp
ezakimak has joined #commonlisp
igemnace has quit [Quit: WeeChat 4.0.2]
igemnace has joined #commonlisp
cosimone has joined #commonlisp
blackshuck has joined #commonlisp
jmdaemon has joined #commonlisp
cosimone has quit [Ping timeout: 240 seconds]
cage has quit [Quit: rcirc on GNU Emacs 28.2]
akoana has joined #commonlisp
bjorkintosh has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
bjorkintosh has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
yvm has quit [Ping timeout: 260 seconds]
Krystof has quit [Ping timeout: 245 seconds]
blackshuck has quit [Remote host closed the connection]
zaymington has joined #commonlisp
blackshuck has joined #commonlisp
attila_lendvai has quit [Ping timeout: 246 seconds]
shka has quit [Ping timeout: 260 seconds]
igemnace has quit [Quit: WeeChat 4.0.2]
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
l4q`` has joined #commonlisp
l4q`` is now known as l4q
alcor has quit [Ping timeout: 246 seconds]
pranavats has left #commonlisp [Error from remote client]
dino_tutter has quit [Ping timeout: 246 seconds]
pranavats has joined #commonlisp
anticomputer has quit [Ping timeout: 240 seconds]
anticomputer has joined #commonlisp
lucasta has joined #commonlisp
lucasta has quit [Remote host closed the connection]
lucasta has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
sunarch has quit [Quit: WeeChat 3.8]
nij- has joined #commonlisp
<gilberth>
nij-: (directory "**/*.pdf")
<nij->
Wow!
<nij->
Does it support regex in someway?
waleee has quit [Ping timeout: 246 seconds]
<gilberth>
nij-: It doesn't. CMUCL used to support glob patterns though, but that's outside of ANSI-CL.
zaymington has quit [Ping timeout: 246 seconds]
morganw has quit [Remote host closed the connection]
habamax has joined #commonlisp
pve has quit [Quit: leaving]
Gleefre has quit [Ping timeout: 246 seconds]
son0p has joined #commonlisp
Josh_2 has quit [Remote host closed the connection]