brokkoli_origin has quit [Ping timeout: 260 seconds]
brokkoli_origin has joined #commonlisp
dayday72 has joined #commonlisp
dayday17 has quit [Ping timeout: 256 seconds]
JuanDaugherty has joined #commonlisp
dayday72 has quit [Quit: Client closed]
istewart has joined #commonlisp
screwlisp has quit [Ping timeout: 252 seconds]
kevingal has quit [Ping timeout: 264 seconds]
mon_key_phn has joined #commonlisp
Akbar-Birbal has joined #commonlisp
brokkoli_origin has quit [Ping timeout: 252 seconds]
brokkoli_origin has joined #commonlisp
chrcav has quit [Quit: leaving]
chrcav has joined #commonlisp
semz has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
jonatack has joined #commonlisp
semz has joined #commonlisp
pestctrl has quit [Ping timeout: 260 seconds]
DragonMaus has quit [Read error: Connection reset by peer]
DragonMaus has joined #commonlisp
JuanDaugherty has quit [Quit: JuanDaugherty]
<beach>
It is not that all patterns are obsolete in Common Lisp. It is just that some of the common ones published are, because of the additional features of Common Lisp. But then, other patterns exist.
istewart has quit [Quit: Konversation terminated!]
ingeniot has joined #commonlisp
Pixel_Outlaw has quit [Quit: Leaving]
wacki has joined #commonlisp
bitspook has joined #commonlisp
ingeniot has quit [Ping timeout: 256 seconds]
shka has joined #commonlisp
jadzi has joined #commonlisp
Pixel_Outlaw has joined #commonlisp
Pixel_Outlaw has quit [Client Quit]
wacki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
chomwitt has joined #commonlisp
chomwitt has quit [Ping timeout: 245 seconds]
JuanDaugherty has joined #commonlisp
<JuanDaugherty>
could there have been two jaime carbonell s ?
<JuanDaugherty>
(selected this as best place to ask for reasons)
<JuanDaugherty>
just one of those super weird things maybe, in Representation and Understanding, a preface which appears to be written by bobrow and a collegue eulogizes him as having died in '73
prokhor has quit [Remote host closed the connection]
younder has quit [Remote host closed the connection]
_Posterdati_ has joined #commonlisp
younder has joined #commonlisp
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
bobcave has joined #commonlisp
chkhd has quit [Remote host closed the connection]
chkhd has joined #commonlisp
chkhd has quit [Quit: ZZZzzz…]
<paulapatience>
I have a dynamic variable *client* in a certain package which is used in a few ordinary functions which call their respective generic variants with the *client* as argument, which is used for dispatch. Normally this variable is unbound, and we don't want packages to set it since it is supposed to be bound only locally, via LET. However, for interactive use, I'd like it to be bound so that I can evaluate subforms which use it.
<paulapatience>
My question is: is there some way for *client* to be automatically set when loading up the package in Slime/Sly so that I don't have to evaluate the SETF form setting it, but that outside of such interactive use it is not set?
<paulapatience>
Or are there any alternatives to what I'm trying to do?
<paulapatience>
Not sure if I made myself clear
<jackdaniel>
paulapatience: you can provide it as an initial binding for selected threads
<jackdaniel>
I don't know whether there's a slime hook available somewhere though
<paulapatience>
jackdaniel: Thanks, I'll look into it
decweb has joined #commonlisp
<contrapunctus>
Wasn't there a Common Lisp implementation featuring arenas?
<jackdaniel>
sbcl introduced memory area allocator
<pranav>
Yes, SBCL.
<contrapunctus>
Thanks.
AndreiDuma has joined #commonlisp
decweb has quit [Ping timeout: 248 seconds]
random-nick has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
mwnaylor has quit [Ping timeout: 246 seconds]
<pve>
paulapatience: Would a simple "session.lisp" file that you load with C-c C-l work? It would load the system, set up the client and whatever else you might need during development.
pestctrl has joined #commonlisp
<paulapatience>
pve: Hah, that's a pretty good idea. I think I'll do that.
<pve>
paulapatience: Great! You may want to do something like (swank:eval-in-emacs '(slime-repl-set-package "MYPACKAGE")) at the end of the session file.
<paulapatience>
Neat, thanks.
skeemer has joined #commonlisp
<jackdaniel>
fe[nl]ix: is there a reason why atomic-cas is not exported from bt2?
<jackdaniel>
is it because of lack of the implementation from clisp maybe?
yitzi has joined #commonlisp
attila_lendvai has joined #commonlisp
lucasta has joined #commonlisp
edgar-rft` has joined #commonlisp
edgar-rft_ has quit [Ping timeout: 260 seconds]
skeemer has quit [Ping timeout: 246 seconds]
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
pranav has quit [Remote host closed the connection]
pranav has joined #commonlisp
rogersm has joined #commonlisp
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
bitspook has quit [Ping timeout: 248 seconds]
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
szkl has joined #commonlisp
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
AndreiDuma has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bitspook has joined #commonlisp
AndreiDuma has joined #commonlisp
bitspook has quit [Ping timeout: 246 seconds]
AndreiDuma has quit [Client Quit]
bitspook has joined #commonlisp
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
cage has joined #commonlisp
cage has quit [Excess Flood]
cage has joined #commonlisp
AndreiDuma has joined #commonlisp
bitspook has quit [Ping timeout: 246 seconds]
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
bitspook has joined #commonlisp
rogersm has quit [Quit: Leaving...]
chomwitt has joined #commonlisp
jadzi has quit [Ping timeout: 252 seconds]
bitspook has quit [Ping timeout: 272 seconds]
reb has quit [Remote host closed the connection]
bitspook has joined #commonlisp
reb has joined #commonlisp
rogersm has joined #commonlisp
chomwitt has quit [Ping timeout: 272 seconds]
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
JuanDaugherty has joined #commonlisp
cmack has quit [Remote host closed the connection]
<JuanDaugherty>
no comments on the matter with jaime carbonell (posted about 7 hr ago)?
cmack has joined #commonlisp
<bike>
this isn't really an ai history channel and i don't know that any of us are terribly familiar
<bike>
according to wikipedia this guy didn't even have his BS in 1973, so presumably it's a different person (father, perhaps). or the eulogy is a joke. who knows
<beach>
I had never heard of him, so I had to look him up on Wikipedia. And I don't think I understood what the issue was supposed to be.
decweb has joined #commonlisp
<beach>
Oh, I think I see.
<bike>
the issue is on wikipedia he's listed as dying in 2020, but in this 1975 book there's a eulogy for him, dead in 1973
<ixelp>
Obituary information for Nelly Juri Carbonell
<bike>
"Nelly was pre-deceased by her husband, Jaime; daughter, Dina; and son, Jaime (Guillermo)."
NotThatRPG has joined #commonlisp
<JuanDaugherty>
now it makes sense
<JuanDaugherty>
two individuals both in AI in the early '70s with the same name and appearance
<JuanDaugherty>
suddenlly sensical from father and son in the sam field
<JuanDaugherty>
that hadn even occurred to me, and will verify that it is, but assume at this point it is the case
<bike>
the obituary also mentions the father dying in 1973
<JuanDaugherty>
the latter carbonell has made a number of important contributions and is well known in AI progper outside the crap of the current bs/grift/hype cycle
wacki has joined #commonlisp
<JuanDaugherty>
relatively early deaths from presumably related causes also gives it the ring of truth so will be lazy on the follow up
<JuanDaugherty>
a lot of carbonnels lisp code is variously available
<JuanDaugherty>
although he was basically just a profilic and inflential collaborator, rather than sole author of anything
<phantomics>
In this case, I have a dynamic var that gets shadowed in a function. I also have a (collect) macro that expands to something pushing to it (with it initialized as nil).
meaty has joined #commonlisp
<phantomics>
In practice, the stuff inside the (foo) function will be generated using macros as well. I'm using this dynamic var setup because I want to use the (collect) macro in the macros that generate (foo) so I can use a known symbol to reference the accumulator list
<phantomics>
Are there any dangers to this approach? (foo) basically does a series of things that includes pushing symbols to *sym-list*. Doing any of it in parallel with lparallel would probably cause problems. Are there any better approaches?
<bike>
do you mean (push ,i *sym-list*) or am i misunderstanding something
<phantomics>
Oops, correct, (push ,i *sym-list*)
<bike>
if all the collect forms are lexically in FOO, the variable doesn't particularly need to be dynamic
<bike>
but even if it is dynamic, if each thread is executing its own FOO, there's no problem: special variable bindings are thread-local
<dlowe>
If you're going to be pushing in multiple threads to the same *sym-list*, you'll need an atomic operation or a mutex there
<phantomics>
The reason I'm using a dynamic var is that in practice, foo is not specified through a simple (defun) but actually generated by a bunch of macros containing code snippets
<dlowe>
if the generation occurs in the same lexical space you don't need a dynamic var there
<bike>
yeah, how you generate the forms is not relevant
<phantomics>
Also, in practice (foo) is actually many different functions whose structure is specified by another macro. If that macro wraps every body with (let ((*sym-list*)) ) it allows me to use (collect) to consistently push things to a local accumulator list for the function
<dlowe>
you only need a dynamic var if called functions are going to use it as such
<phantomics>
So let's say I generate one of the foo functions like this: (generate-foo-function fn-name (do thing1) (do thing2) (do (collect 'a)) (do (collect 'b)))
<phantomics>
(generate-foo-function will wrap those things in its body in (let ((*sym-list*)) ) so for each function, (collect) will push things into its accumulator list
<phantomics>
That's the reasoning behind use of the dynamic var, is there a better way to approach this?
<bike>
all i'm saying is, if the (collect whatever) forms end up within the definition of foo only, you don't need a dynamic variable. you're clearly doing something pretty complicated to generate the code so I can't be sure if that's the case.
<bike>
and you shouldn't have any thread safety issues if you're only pushing to a local binding. That is, if only FOO does the (let ((*sym-list* ...)) ...), and each thread calls FOO, each thread gets its own variable binding so there's no contention.
<phantomics>
They end up in the declaration of many functions whose definitions are generated using macros. So the singluar (foo) function is an abstraction, there are actually lots of them generated using macros
<phantomics>
(foo) wouldn't be called by multiple threads, most likely there would be multithreaded handling of the tasks happening within it, splitting it between threads
<bike>
You only need *sym-list* to be dynamic if you have code like (let ((*sym-list*)) (bar)) where bar is actually some other function. If the collect forms are lexically within the body of the let it doesn't need to be dynamic.
meaty has quit [Quit: touch grass]
<bike>
and bar actually does (collect ...), i mean
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bike>
anyway, if multiple threads are collecting to the same binding, you do actually need to worry about contention regardless of whether it's dynamic
<bike>
locks, atomics, whatever
<phantomics>
That is the case for this application
<phantomics>
(foo) is doing a series of actions that include calling outside functions that have (collect) inside them
meaty has joined #commonlisp
<phantomics>
Then I could look at more thread-safe data structures, the feasibility of threading for this is TBD
X-Scale has joined #commonlisp
rogersm_ has joined #commonlisp
<phantomics>
There may also be another way to expose a foo-level API to functions called inside it, thanks for the info
danieli2 has joined #commonlisp
BierLiebHaber_ has joined #commonlisp
saturn3 has joined #commonlisp
benkard has joined #commonlisp
jonatack has quit [Ping timeout: 264 seconds]
mrvdb has joined #commonlisp
kg7ski- has joined #commonlisp
Eoco_ has joined #commonlisp
pyook has joined #commonlisp
loke has joined #commonlisp
dnhester26 has joined #commonlisp
mesaoptimizer has quit [Quit: zzz]
rogersm has quit [*.net *.split]
lieven has quit [*.net *.split]
saturn2 has quit [*.net *.split]
BierLiebHaber has quit [*.net *.split]
puke has quit [*.net *.split]
rakka has quit [*.net *.split]
mulk has quit [*.net *.split]
kg7ski has quit [*.net *.split]
gjvc has quit [*.net *.split]
fitzsim has quit [*.net *.split]
patrix has quit [*.net *.split]
alanz has quit [*.net *.split]
kopiyka has quit [*.net *.split]
danieli has quit [*.net *.split]
Eoco has quit [*.net *.split]
mrvdb- has quit [*.net *.split]
loke___ has quit [*.net *.split]
benkard is now known as mulk
danieli2 is now known as danieli
kmroz has quit [*.net *.split]
susam has quit [*.net *.split]
gjvc has joined #commonlisp
alanz has joined #commonlisp
susam has joined #commonlisp
kopiyka has joined #commonlisp
kmroz has joined #commonlisp
rakka has joined #commonlisp
lieven has joined #commonlisp
patrix has joined #commonlisp
JuanDaugherty has joined #commonlisp
<fe[nl]ix>
jackdaniel: atomic-cas is not exported because its behaviour is so inconsistent that the only way I've found to provide consistent behaviour is to create specific functionality like atomic-integer
triffid has quit [Remote host closed the connection]
<fe[nl]ix>
I believe I've seen a compatibility table somewhere (maybe by Shinmera ?) and it wasn't pretty
bitspook has quit [Read error: Connection reset by peer]
zxcvz has joined #commonlisp
bitspook has joined #commonlisp
bitspook has quit [Remote host closed the connection]
bitspook has joined #commonlisp
mgl_ has quit [Ping timeout: 260 seconds]
mgl_ has joined #commonlisp
zxcvz has quit [Quit: zxcvz]
bobcave has quit [Quit: Leaving]
mgl_ has quit [Ping timeout: 246 seconds]
JuanDaugherty has quit [Quit: JuanDaugherty]
random-nick has quit [Ping timeout: 252 seconds]
<alcor>
2 days ago we had a discussion about using keywords instead of symbols in (LOOP …) e.g. (LOOP :WITH x = … :FOR y :IN …). Now I have a silly OCDish question here. Wouldn't the same argument apply to the "=" symbol? I mean technically if we REALLY wanted to apply that logic to its maximum, shouldn't we write (LOOP :WITH x := … :FOR y :IN …) ?
mgl_ has joined #commonlisp
<dlowe>
I've definitely seen people do it
<alcor>
I don't want to make a mountain out of molehill, but I'm tempted to do it for entirely um, aesthetic reasons. := (aka the Walrus) looks like a Pascalish/Wirthian assignment operator (I know it totally isn't comparable in a CL context) but it looks acceptable + avoids polluting the package namespace.
<bike>
= is in the CL package, so if you're using the CL package you're not doing anything to your own by writing it, unlike how it is with WITH or FOR
<dlowe>
alcor: absolutely no one will care what you do
<zyd>
:= looks out of place to me
<mrcom>
But they'll notice :)
<dlowe>
it will be overshadowed by more important inconsequential differences of style
<alcor>
bike: Right, that will only make a difference if you don't have a (:use :cl) in your defpackage.
<mrcom>
What's that quote? "A foolish consistency is the hobgoblin of little minds." Never did figure out if little minds were supposed to be foolishly consistent, or were getting bothered by other people being foolishly consistent. So I settled on doing both,\
<mrcom>
and figuring Dr. Johnson was just being procedurely lazy.
X-Scale has quit [Ping timeout: 256 seconds]
<dlowe>
it's something people trot out when they want to be smug
<mrcom>
Pascal has ":=" for assignment. Brings back warm and fuzzies.
<zyd>
this will give more fuel to the LOOP haters
random-nick has joined #commonlisp
<alcor>
:= is just a tiny droplet of fuel being added to a raging fire
traidare has joined #commonlisp
pyook has quit [Ping timeout: 245 seconds]
pyook has joined #commonlisp
<mrcom>
CL doesn't have raging arguments about tabs-vs-spaces, so all that latent energy has to go into something else.
X-Scale has joined #commonlisp
<mrcom>
And emacs-vs-vim is pretty moot too. More pent-up fire.
<mrcom>
Slime-vs-slime is too miniscule for anybody to get worked up.
<mrcom>
Er/ slime-vs-sly
<mrcom>
Everybody used SBCL except for special purposes.
<zyd>
so sad, our very limited opportunities for flame wars
<mrcom>
What you're trying to microbenchmark is dispatch time? The framework is a bit complex for that, IMHO. You're building an enormous tree of test data (I think?), so that's going to mix into the results.
<bike>
the building part isn't timed
<paulapatience>
skin: I would add a little nuance to your conclusion. If you are looking for maximum performance, you probably won't use a slower implementation than SBCL, and then you demonstrated that classes are slower than structs are slower than etypecase on it.
<mrcom>
No, I'm talking about data locality.
<mrcom>
It's also difficult for me to reason about exactly how much of what is happening. Not enough coffee, perhaps.
<mrcom>
It's kind of suspicous that SBCL isn't cons when doing the COLLECTs in the loops.
<mrcom>
s/consing/
<mrcom>
And ECL and ABCL are doing huge amounts; that's probably where most of the elapsed time is going.
<mrcom>
So in those cases he's measure the memory subsystem.
<mrcom>
A simple "(loop :for i :from 0 :below 1000000 :sum (foo))" would be much clearer to reason about, and much less confounded by other things.
<younder>
Is it possible to use the Command line 'perf' tool for metering execution metrics?
<mrcom>
Yes, that's probably a good idea for double-checking what you're actually testing. I wouldn't do it during the actual measurement run, though. Even in stat mode would be one more confounder.
<mrcom>
You're talking about something like sbcl's perf tools?
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
<ixelp>
GitHub - brendangregg/perf-tools: Performance analysis tools based on Linux perf_events (aka perf) and ftrace
<mrcom>
I'd also like to see some variations, to judge how the measurements might actually apply. For example, does it matter no-subclassed vs. subclassed 5-deep? 1 slot vs. 10?
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
jadzi has joined #commonlisp
<mrcom>
younder: I wouldn't expect much more than (time) would give you.
<younder>
I'm more wondering as I could 'patch' them into SBCL as a library that would then be called at the REPL's discretion
<mrcom>
You're much better off with sbcl's perf tools. It's aware of the idiosyncracies in stack useage, function dispatch, etc.
cage has quit [Quit: rcirc on GNU Emacs 29.4]
<mrcom>
It's got two types; one is deterministic, counting each time a function is called, and the other is statistical, sampling. It's aware of call stacks and chains. Still pretty obscure, sometimes.
<younder>
I can't seem to find any information about SBCL perf. Where is it mentioned?
<younder>
Perf is different as it records things like cache misses and branch mis-predictions which matter if you are tuning the compiler
mgl_ has quit [Ping timeout: 265 seconds]
attila_lendvai_ has joined #commonlisp
meaty has joined #commonlisp
attila_lendvai has quit [Ping timeout: 244 seconds]
mwnaylor has joined #commonlisp
attila_lendvai_ has quit [Ping timeout: 244 seconds]
<jasom>
younder: I'd love to see CPU specific performance counters in the output to CL:TIME
X-Scale has quit [Ping timeout: 256 seconds]
saturn3 is now known as saturn2
jadzi has quit [Ping timeout: 265 seconds]
<skin>
The memory subsystem is an important part of it, but I think the point still stands. Different implementations use the memory subsystem more or less for dispatch evaluation, and that showed up in the numbers.
kevingal has joined #commonlisp
<skin>
I mean, I didn't tell those implementations to do all that consing. The consing I did myself to build the tree was not measured; only running the recursive evaluate methods were measured. So I think it's about as good a test as `(loop for 1 to 1000 do ...)`. I think the results are imperfect, but still mean a lot.
attila_lendvai has joined #commonlisp
<scymtym>
in at least some implementations, calling a generic function for the first time after its definition or after some change to its methods may invoke the compiler and thus add one-time consing and runtime
wacki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Guest32 has joined #commonlisp
Guest32 has quit [Quit: Client closed]
Guest32 has joined #commonlisp
<aeth>
On the earlier discussion, yes, I use := in my LOOPs, not just :for, etc. That is the fully consistent way to use keywords in LOOP.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
pve has quit [Quit: leaving]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
NotThatRPG has joined #commonlisp
mwnaylor has quit [Ping timeout: 246 seconds]
attila_lendvai has quit [Ping timeout: 265 seconds]
JuanDaugherty has joined #commonlisp
Guest32 has quit [Quit: Client closed]
varjag has joined #commonlisp
pyook has quit [Read error: Connection reset by peer]
<zyd>
Seems to me that structs vs classes comes down to the use case of them rather than an absolute "just use classes" or "always use structs". If you intend to make say, a bullet hell game, might make sense to represent bullets as structs, right? Especially because that kind of data will likely be just numbers. If I'm thinking about it right.
alcor has quit [Ping timeout: 255 seconds]
<paulapatience>
zyd: Exactly.
mesaoptimizer has quit [Quit: zzz]
X-Scale has quit [Quit: Client closed]
dayday17 has quit [Quit: Client closed]
<skin>
I would pull that a part a little bit
<skin>
If class is really were faster then maybe we should just use them because they're also more fully featured and there would be no tradeoffs
<skin>
however, there are tradeoffs, as I discovered
skeemer has quit [Ping timeout: 252 seconds]
alternateved has quit [Remote host closed the connection]
dayday17 has joined #commonlisp
<younder>
In SBCL using struc and ecase is twice as fast., but that doesn't matter because all the other implementations are slow.
shka has quit [Ping timeout: 252 seconds]
Bubblegumdrop_ is now known as Bubblegumdrop
<aeth>
Generally speaking, structs have a different purpose. This is mostly when putting a :type in a slot to give type information to the compiler, which can compound beyond simple access for numbers (remove generic arithmetic) and specialized (with :element-type) arrays of numbers (which have the arithmetic benefits mixed with the removal of bounds checking if you provide the length in the type)
<younder>
My conclusion is that of the free Lisp's only SBCL and CCL have good performance. Compared with the commercial compilers CLOS is not heavily optimized, but structs are in SBCL. That is why structs are twice as fast. Of course in most cases the uses of class are quite different.
<JuanDaugherty>
you think LW is a dog, performance wise?
<younder>
LW didn't make it into this test. It is slower than SBCL for calculations, but CLOS should perform better.
traidare has quit [Ping timeout: 252 seconds]
<JuanDaugherty>
ack
<aeth>
younder: Whether or not structs or standard-objects are more optimized isn't particularly relevant because structs by their nature _can_ be optimized more.
<aeth>
Whether implementations bother to do so is on them.
<younder>
A lot of the optimizations can only be performed at link time when you know all the virtual methods and that methods will not be overloaded., but in SBCL one rarely compiles to a executable. This is mostly done in the commercial Lisps.
<aeth>
You cannot know that things won't be overloaded more or recompiled or whatever in general. Although you can probably do so if you compile everything at once, yes, if you check for the presence of problematic calls and optimize only in their absence.
<younder>
Remember LispWorks doesn't normally include the compiler in the executable.
<aeth>
Yes, that helps, but it also restricts what you can do.'
<younder>
Well I'm off to bed
dayday17 has quit [Ping timeout: 252 seconds]
JuanDaugherty has quit [Quit: JuanDaugherty]
pyook has quit [Read error: Connection reset by peer]
yitzi has quit [Read error: Connection reset by peer]
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #commonlisp
dayday17 has joined #commonlisp
<fe[nl]ix>
Shinmera: thank you
<fe[nl]ix>
jackdaniel: so the only accessors that work across all implementations' CAS are CAR, CDR, SVREF and special vars
Bubblegumdrop has quit [Quit: ZNC 1.9.1+deb1 - https://znc.in]
X-Scale has joined #commonlisp
Bubblegumdrop has joined #commonlisp
Bubblegumdrop has quit [Client Quit]
Bubblegumdrop has joined #commonlisp
Bubblegumdrop has quit [Client Quit]
Bubblegumdrop has joined #commonlisp
<jasom>
younder: I compile to an executable all the time; the two reasons being ease of delivery and decreased startup time.