somewun has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
Fare has joined #lisp
igemnace has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
rumbler31 has quit [Read error: Connection reset by peer]
energizer has quit [Remote host closed the connection]
rumbler31 has joined #lisp
igemnace_ has joined #lisp
igemnace has quit [Ping timeout: 240 seconds]
dessm has quit [Remote host closed the connection]
damke has quit [Ping timeout: 260 seconds]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
damke has joined #lisp
shifty has joined #lisp
<drmeister>
Hello
<drmeister>
I'm just becoming hip to how well docker works with Common Lisp. Say you have a lot of ASDF systems and you have a slowish compiler - just build everything in a docker container and ship it. Compiled asdf systems are all bundled up with it.
dented42 has joined #lisp
<drmeister>
Fare: Are you still online?
<Fare>
drmeister, kind of
fourier has joined #lisp
<bjorkintosh>
docker huh?
energizer has joined #lisp
Quetzal2 has joined #lisp
fikka has joined #lisp
Jen has joined #lisp
SuperJen has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 255 seconds]
fikka has joined #lisp
<stylewarning>
drmeister: we do that and it works fine
DataLinkDroid has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
pyericz has joined #lisp
damke_ has joined #lisp
damke has quit [Ping timeout: 264 seconds]
nmajo has quit [Ping timeout: 264 seconds]
Murii has quit [Remote host closed the connection]
Murii has joined #lisp
fikka has joined #lisp
Tristam has quit [Read error: Connection reset by peer]
Tristam has joined #lisp
nmajo has joined #lisp
jmercouris has joined #lisp
<jmercouris>
I'm looking to use lisp for generating API stubs in a variety of languages
<jmercouris>
any place I should start?
<jmercouris>
has someone done something similar before?
<jmercouris>
is anyone awake right now?
wigust has joined #lisp
<fourier>
probably you can roll out something on basis of c-mera for C. otherwise maybe SWIG could help, design API in C and generate all bindings for all languages you want via SWIG
<jmercouris>
fourier: swig is a good idea, but I wanted to do it in Lisp
<jmercouris>
I'll look into C-mera, maybe has some ideas I can take
<jmercouris>
thanks
<fourier>
why limit yourself, there are tons of corner cases which were already solved in swig. and to prepare truly portable api better to start with C anyway I believe
<fourier>
but it would be awesome to have some generator in CL I must admit.. c-mera is a good step forward but to low-level imho
<jmercouris>
definitely, lots of corner cases, and supporting each language will be a huge pain for sure
<jmercouris>
I just thought it would be something fun to do
angavrilov has joined #lisp
shka_ has joined #lisp
<jmercouris>
admittedely, the domain I'm trying to solve is far simpler and would be something like what swagger provides
milanj has quit [Quit: This computer has gone to sleep]
fikka has joined #lisp
milanj has joined #lisp
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amerlyq has joined #lisp
amerlyq has quit [Ping timeout: 240 seconds]
dilated_dinosaur has quit [Ping timeout: 256 seconds]
Karl_Dscc has joined #lisp
amerlyq has joined #lisp
nowhere_man has joined #lisp
amerlyq has quit [Ping timeout: 260 seconds]
pyericz has joined #lisp
Karl_Dscc has quit [Ping timeout: 248 seconds]
amerlyq has joined #lisp
makomo has quit [Ping timeout: 268 seconds]
disumu has joined #lisp
fikka has quit [Ping timeout: 276 seconds]
amerlyq has quit [Ping timeout: 268 seconds]
amerlyq has joined #lisp
azahi has quit [Changing host]
azahi has joined #lisp
makomo has joined #lisp
puchacz has quit [Read error: Connection reset by peer]
amerlyq has quit [Ping timeout: 268 seconds]
milanj has quit [Quit: This computer has gone to sleep]
thinkpad has quit [Ping timeout: 248 seconds]
pyericz has quit [Quit: This computer has gone to sleep]
puchacz has joined #lisp
amerlyq has joined #lisp
Kundry_Wag has joined #lisp
DVSSA has joined #lisp
fourier has joined #lisp
Kundry_Wag has quit [Ping timeout: 256 seconds]
damke has joined #lisp
patrixl has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
oleo has quit [Quit: Leaving]
jjkola has quit [Quit: Ex-Chat]
thinkpad has joined #lisp
Satou has quit [Quit: Cya soon guys!]
oleo has joined #lisp
pyericz has joined #lisp
orivej has quit [Ping timeout: 264 seconds]
salva has quit [Remote host closed the connection]
<adlai>
would the correct term for 'ware such as XCVB be "kamikazeware", since it ultimately never went anywhere itself, but strengthened what remnained?
<adlai>
or perhaps, chickenware - last library standing eats the one that falls by the wayside.
Bike has joined #lisp
fikka has joined #lisp
orivej has joined #lisp
python476 has joined #lisp
fikka has quit [Ping timeout: 255 seconds]
thinkpad has quit [Quit: lawl]
milanj has joined #lisp
DVSSA has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 268 seconds]
thinkpad has joined #lisp
fikka has joined #lisp
nika has quit [Remote host closed the connection]
random-nick has quit [Ping timeout: 256 seconds]
<shka>
hello
<shka>
how can i coerce double-float to single-float while allowing floating point overflow?
fikka has quit [Ping timeout: 276 seconds]
<Bike>
Allowing?
<shka>
well, i want to lose precision
<Bike>
sure
<Bike>
i mean, (float double 1f0) will do it
puchacz has quit [Quit: Konversation terminated!]
<Bike>
but i don't know what you want to happen if the double is too big
<shka>
well, let me just check
puchacz has joined #lisp
<shka>
Bike: this also signals overflow in sbcl
<Bike>
yes.
<Bike>
what would you prefer it to do.
<shka>
hmm
pioneer42 has left #lisp [#lisp]
<shka>
actually, this shouldn't overflow like this to begin with
random-nick has joined #lisp
<shka>
so i rather fix this
thinkpad has quit [Ping timeout: 276 seconds]
thinkpad has joined #lisp
Folkol has joined #lisp
fikka has joined #lisp
DVSSA has joined #lisp
fourier has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 256 seconds]
thinkpad has quit [Ping timeout: 240 seconds]
fourier has joined #lisp
DVSSA has quit [Ping timeout: 256 seconds]
m00natic has quit [Remote host closed the connection]
rpg has joined #lisp
fikka has joined #lisp
igemnace has quit [Quit: WeeChat 2.1]
fikka has quit [Ping timeout: 260 seconds]
m00natic has joined #lisp
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lnostdal has quit [Ping timeout: 260 seconds]
thinkpad has joined #lisp
lnostdal has joined #lisp
fikka has joined #lisp
random-nick has quit [Ping timeout: 264 seconds]
DVSSA has joined #lisp
pjb has joined #lisp
fikka has quit [Ping timeout: 264 seconds]
DVSSA has quit [Ping timeout: 256 seconds]
ancient_dog has quit [Ping timeout: 264 seconds]
DVSSA has joined #lisp
random-nick has joined #lisp
void_pointer has joined #lisp
DVSSA has quit [Ping timeout: 260 seconds]
thinkpad has quit [Quit: lawl]
fikka has joined #lisp
k-stz has joined #lisp
thinkpad has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
BlueRavenGT has joined #lisp
shrdlu68 has joined #lisp
python476 has quit [Remote host closed the connection]
dilated_dinosaur has joined #lisp
shrdlu68 has quit [Ping timeout: 246 seconds]
fikka has joined #lisp
DVSSA has joined #lisp
warweasle has joined #lisp
shrdlu68 has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
DVSSA has quit [Ping timeout: 256 seconds]
pyericz has quit [Quit: This computer has gone to sleep]
jmercouris has quit [Remote host closed the connection]
jmercouris has joined #lisp
Kundry_Wag has joined #lisp
zaquest has quit [Read error: Connection reset by peer]
zaquest_ has joined #lisp
khisanth_ has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
disumu has quit [Quit: ...]
Bike_ has joined #lisp
TCZ has joined #lisp
khisanth_ has joined #lisp
DVSSA has joined #lisp
DVSSA has quit [Ping timeout: 240 seconds]
nirved has quit [Ping timeout: 256 seconds]
raynold has quit [Quit: Connection closed for inactivity]
milanj has quit [Quit: This computer has gone to sleep]
Bike has quit [Disconnected by services]
Bike_ is now known as Bike
Kevslinger has joined #lisp
stefany_ has joined #lisp
shifty has quit [Read error: Connection reset by peer]
nirved has joined #lisp
damke_ has joined #lisp
damke has quit [Ping timeout: 264 seconds]
fikka has quit [Ping timeout: 240 seconds]
makomo has quit [Ping timeout: 256 seconds]
stefany_ has quit [Quit: Leaving]
damke_ has quit [Read error: Connection reset by peer]
damke has joined #lisp
soma1257 has joined #lisp
ancient_dog has joined #lisp
TCZ has quit [Quit: Leaving]
jmercouris has quit [Ping timeout: 256 seconds]
eSVG has joined #lisp
DVSSA has joined #lisp
aeth has quit [Ping timeout: 248 seconds]
aeth has joined #lisp
eSVG has quit [Ping timeout: 255 seconds]
DVSSA has quit [Ping timeout: 264 seconds]
fikka has joined #lisp
msb has quit [Read error: Connection reset by peer]
ancient_dog has quit [Ping timeout: 246 seconds]
somewun has joined #lisp
ancient_dog has joined #lisp
msb has joined #lisp
sjl__ has joined #lisp
<soma1257>
Hi beautiful lisp community! Today I'm here for a career advice. Currently I'm making 669.97usd/month after taxes as a full time erlang programmer. And I'm starting to get sick and I can't pay for doctors, nothing terrible, i *believe* is just food deficiency. I would love to make 1k-1.5k/usd month working remotely, and i don't care how many hours or day i should work to get that.
<soma1257>
What i want from you guys is some advice, What market should i focus in? Where can i find a better job? Is any real chance for a remote job for a normal programmer?
<beach>
soma1257: You are kind of in the wrong channel.
<beach>
This channel is dedicated to discussions around the Common Lisp language.
python476 has joined #lisp
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
oleo has quit [Quit: Leaving]
<TMA>
soma1257: #lispcafe is for the offtopic discussion
Kundry_Wag has quit [Remote host closed the connection]
makomo has joined #lisp
Kundry_Wag has joined #lisp
al-damiri has joined #lisp
nsrahmad has joined #lisp
fikka has joined #lisp
oleo has joined #lisp
nsrahmad has quit [Remote host closed the connection]
nsrahmad has joined #lisp
<jeosol>
Morning
<beach>
Hello jeosol.
fikka has quit [Ping timeout: 240 seconds]
<jeosol>
I happy to say my cl-application is somewhat stable now, but my local 64gb box with 32 jobs in parallel is using all my memory, will have to get something online
milanj has joined #lisp
<jeosol>
morning beach
fikka has joined #lisp
DVSSA has joined #lisp
python476 has quit [Ping timeout: 240 seconds]
damke has quit [Ping timeout: 264 seconds]
<phoe>
jackdaniel: I just stumbled upon the handler-case thing that you were talking about some time ago.
<phoe>
Time for me to sit down and actually write a handler-case* myself.
wigust has joined #lisp
<Bike>
the star does what?
raynold has joined #lisp
<phoe>
in handler-case, first you do a NLToC, then you execute the handler function.
<Bike>
sure.
<phoe>
in handler-case*, first you execute the handler function, and only then make a NLToC.
patrixl has quit [Ping timeout: 276 seconds]
<Bike>
so, handler bind but the syntax is like handler case?
Jesin has joined #lisp
<phoe>
yep, and there's a non-local exit afterwards by default unlike in handler-bind.
<Bike>
then how do you decline to handle the condition? or, you can't?
<phoe>
you don't
<phoe>
handler-case never declines after all
Kundry_Wag has quit [Remote host closed the connection]
<phoe>
Bike: I actually went the lazy way and rewrote my stuff using handler-bind.
jack_rabbit has quit [Ping timeout: 276 seconds]
crsc has quit [Quit: leaving]
damke has joined #lisp
jcowan has joined #lisp
<jcowan>
In case it's news to anyone, the Reddit 1.0 codebase is now published on Github.
fikka has joined #lisp
Jesin has quit [Quit: Leaving]
asarch has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
<phoe>
jcowan: not anymore, I think. I've already raged a little too much over the quality of their code.
<jcowan>
They admitted it was crap at the time, typical technical-debt-ridden startup code
disumu has joined #lisp
<jcowan>
"[Expletive deleted]s can write Fortran in any language", even CL
jack_rabbit has joined #lisp
DVSSA has quit [Ping timeout: 256 seconds]
<jcowan>
Out of curiosity, does anyone know what CL is used for at Google? When I was there (2007-10) it was no more than a rumor and a style guide.
<Shinmera>
If I remember correctly CCL during development and SBCL in production.
<jcowan>
Seems reasonable, but for what purpose(s)?
fikka has joined #lisp
<Shinmera>
CCL compiles much faster.
<Shinmera>
And it's used for QPX, or Google Flights
<jcowan>
Ah.
<jcowan>
Thanks.
<jcowan>
I note that the published Intercal style guide ends in "When to use Intercal: Only if you absolutely have to! Good grief, has it really come to this?"
<jcowan>
rather than the internal version, which read "Never. What are you, high?"
<pjb>
Actually, I could list several cases where I would advise Intercal.
DVSSA has joined #lisp
<shka>
pjb: so people won't be able to get anything done?
<pjb>
soma1257: the only career advise we could give you is to follow Paul Graham's steps: start up a company, write a nice web app in clisp, well your startup to yahoo or google for $100+M, become venture capitalist.
fikka has quit [Ping timeout: 276 seconds]
<pjb>
shka: win obfuscation contests, ensure long term employment, answer silly questions, and more.
jack_rabbit has quit [Ping timeout: 264 seconds]
<pjb>
soma1257: but if you want to earm more money, learn kotlin or swift and write mobile apps, it's where the easy money is nowadays.
<fourier>
wrong chat for career advice tbh, but pjb's advice is on point
crsc has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
jack_rabbit has joined #lisp
Kundry_Wag has joined #lisp
fikka has joined #lisp
EvW has joined #lisp
frgo has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
<shka>
pjb: i can do all those things with good old C pretty well ;-)
EvW2 has joined #lisp
EvW has quit [Read error: Connection reset by peer]
EvW2 is now known as EvW
<pjb>
shka: or even with lisp! :-)
fikka has joined #lisp
<rpg>
aeth, Shinmera: you can build a lisp image with ASDF for delivery as an application. I think there's enough difference between systems that ASDF will *not* build you a command-line executable. It will get pretty close, though.
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
<rpg>
drmeister: I've used dribble in non-interactive experiments, or experiments that produce a truckload of output that I need to grovel over later.
fikka has quit [Ping timeout: 260 seconds]
<Shinmera>
rpg: I'm aware, but that does not first concatenate things into a single file.
karswell has quit [Read error: Connection reset by peer]
Kaisyu has quit [Quit: Connection closed for inactivity]
<rpg>
Typically only for not-so-well structured systems where I don't want to bother figuring out how to redirect output myself.
<rpg>
Shinmera: Correct.
karswell has joined #lisp
<rpg>
Shinmera: But I thought the question was about executable delivery, for which source delivery is not necessary, and might even be A Bad Thing.
<Shinmera>
I think aeth wanted to have things as a single source file for better optimisation.
<Shinmera>
As for binary deployments using ASDF, I think it's currently the best way to create deployments for Lisp applications.
<Shinmera>
It's a shame most people are unaware of it, though.
__rumbler31 has joined #lisp
* jcowan
mourns the loss of Interlisp culture with its image/logfile program representation
amerlyq has quit [Ping timeout: 248 seconds]
fikka has joined #lisp
amerlyq has joined #lisp
frgo has joined #lisp
<beach>
jcowan: Patience. Some people are working on bringing it back.
<rpg>
jcowan: ? You can still build images for your programs. It's not clear what are the limits on shipping them around, though, because of possible incompatibilities with shared libraries where you deploy.
fikka has quit [Ping timeout: 240 seconds]
<rpg>
Or do you mean something like Smalltalk, with its "there is no source file" philosophy?
EvW has quit [Ping timeout: 276 seconds]
lnostdal has quit [Ping timeout: 240 seconds]
<beach>
The latter was my interpretation.
<jcowan>
Exactly. Interlisp and Smalltalk of course are two sides of one coin
<rpg>
I had to work with some code from... that expert systems vendor -- I think an outgrowth of LMI or possibly symbolics -- they had no source files. I really hated it, because they used it to chain you to them
damke_ has joined #lisp
* jcowan
nods
EvW1 has joined #lisp
<jcowan>
Any technology can be used for evil.
<shka>
"there is no source file" requires bucket load of stuff to work
<shka>
like diff tools, version controls…
<jcowan>
Sure.
<jcowan>
Interlisp specialized in those tools rather than in enhancing the actual language.
damke has quit [Ping timeout: 245 seconds]
<jcowan>
(I worked for a while with Lyric, the first full implementation of CL-IL coexistence)
fikka has joined #lisp
<jcowan>
And of course there is a source file, it's a log.
<jcowan>
But I agree that you don't want to work directly with that.
<rpg>
I can't imagine working without `diff`, imperfect though it is. Or the ability to work with git. Using jupyter now, which has a similar feature (bug?)
<jcowan>
beach: What are you referring to specifically?
<jcowan>
It's clear from reading the JLS that the Java people expected classes to be stored in a database in production, rather than in the file system.
<jcowan>
beach: thanks, queued to read
<phoe>
jcowan: you can commit a popular heresy and treat the FS as a semistructured database
fikka has quit [Ping timeout: 276 seconds]
<jcowan>
Oh yes, I have
<jcowan>
built a rather large bespoke CMS storing all the text in individual files
<jcowan>
It is after all pretty robust technology. Today I might have used SQLite instead.
damke has joined #lisp
<beach>
rpg: Things like diff and git sort of work, but only because we represent everything as text. And even then, it doesn't work that well. It would be interesting to investigate how similar tools could be created for more complex data like structured documents, graphs, etc.
<beach>
rpg: But you are right of course. Given that we do not have any tools that work on more complex objects, then it is hard to imagine doing without those tools today.
damke_ has quit [Ping timeout: 264 seconds]
<rpg>
beach: Agreed, but I am pessimistic since how long has there been microsoft word? And I still can't put a word document in git and track modfications.
<rpg>
or powerpoint which consumes a dismaying amount of my output
pagnol has joined #lisp
<beach>
Yes, I see what you mean.
<rpg>
I don't know, there may be some for-pay system from MS that handles this kind of guff.
<pagnol>
is there a way to just export/publish everything when defining a package with defpackage?
<beach>
pagnol: "everything"?
<pagnol>
while prototyping I find it tedious to keep everything in sync with defpackage
<beach>
pagnol: Why on earth would you want to do that?
<shka>
pagnol: you CAN iterate over all symbols in package and export but i have no idea why would you want to do that
<beach>
pagnol: Like if you do (let ((x ...)) would you want X to be exported?
<fourier>
rpg: you can track modifications in word
<fourier>
it has some mode you can turn on for this
<rpg>
fourier: Yes, but not in a way that subversion, git, etc. can use
<pagnol>
of course not
<pagnol>
...
<jcowan>
you could write some git porcelain that unpacks .docx/.pptx/etc., which is basically zipped XML, and store the individual files, reassembling them on checkout.
<shka>
pagnol: just use package::symbol if you want to write unit test or something
<beach>
pagnol: So perhaps you should define "everything"?
<fourier>
but it is self contained and you just give someone else a file and he will read these modifications
<jdz>
fourier: the "track changes" thing does not exactly work when different people do changes independently.
pagnol has quit [Client Quit]
<rpg>
my colleagues all make horrible directories with my-final-report-v287.docx and similar snot in them.
<fourier>
yes it assumes sequental access to the document
<jcowan>
people who work in hierarchical companies can't use hierarchical file systems
<jdz>
rpg: I know some people who do than with their software projects.
<fourier>
for simultanious access ms invented sharepoint. so everyone who is workng with management documents has to use it in big corps...
<rpg>
jcowan: It's not that, it's because they can't easily pull out old versions to diff them: it's easier to leave all the versions around and use compare revisions.
<rpg>
jcowan: My company is (a) not hierarchical and (b) staffed substantially with CS Ph.D.s who are just fine with tree structured directories, thank you very much
<jcowan>
Glad to hear it
onion has joined #lisp
<rpg>
fourier: SharePoint is kind of like a wiki, but with everything done wrong.
<jcowan>
the hierarchy remains where it belongs, governing things, not people
mflem has joined #lisp
<rpg>
but this is a big detour from talking about interlisp and smalltalk! Just my explanation for why languages with no file representation scare me!
<rpg>
gotta run...
<fourier>
rpg: not really, it has a lot of stuff, but what I've used it is to work with the documents simultaniously with other managers. so they were normal doc and excel documents, just with versions, checkin/checkout like in vcs
<jcowan>
I have in fact taken Word documents, unzipped them as described, made global changes to styling, rezipped them, et voila.
fikka has joined #lisp
nullman has quit [Ping timeout: 256 seconds]
nullman has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
fourier has quit [Remote host closed the connection]
m00natic has quit [Remote host closed the connection]
fourier has joined #lisp
lnostdal has joined #lisp
<jcowan>
beach: I note that the beginning of that document says Unix was designed to run without an MMU, but this is not true
Satou has joined #lisp
<cgay>
rpg: Intellicorp, maybe. (re: 12:26 EDT)
siraben` has joined #lisp
* cgay
is just throwing out the name of a random expert systems provider related to Symbolics and no specific knowledge of their lack of source files or lack of lack of source files, as the case may be.
<pjb>
jcowan: it's true that early unices could run without a MMU, and the first one didn't have one. THe PDP-7 didn't have a MMU, and The 11/20 lacks any kind of memory protection hardware unless retrofitted with a KS-11 memory mapping add-on.
siraben has quit [Ping timeout: 264 seconds]
shrdlu68 has quit [Read error: Connection reset by peer]
shrdlu68 has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
onion is now known as whoman
whoman is now known as onion
FreeBirdLjj has quit [Ping timeout: 260 seconds]
TCZ has joined #lisp
energizer has joined #lisp
<pjb>
rpg: the problem is that files are sequences of bytes (or at best, sequences of characters); therefore diff provides you with a difference in characters, which is not meaningful for software development purposes. Then you have all kind of problems, such as commits with only indentation changes, or worse, commits mixing indentation changes and semantic modifications.
<pjb>
rpg: I'm not saying that a system built on structured code "data bases" would be better, but it has at least an opportunity to make it better. At least, indentation is left to the pretty printer…
omilu has quit [Remote host closed the connection]
ryanbw has quit [Quit: WeeChat 2.0.1]
python476 has joined #lisp
terpri has joined #lisp
Karl_Dscc has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
<semz>
Does Slime use the FFI internally for interprocess shenanigans? I'm trying to figure out the cause of a segfault.
<cgay>
Isn't it all a matter of tools? With text files you can always apply a reparse+pprint step before diffing, for example. Or parse and diff the ASTs or whatever. It's just that there's a boatload of text-based tools lying around and the other tools would necessarily be more language-specific, I think? (Sorry if I missed some context.)
SaganMan has quit [Quit: laters]
<Xach>
semz: not especially
Kundry_Wag has joined #lisp
jcowan_ has joined #lisp
<semz>
Xach, are you somewhat familiar with Slime's internals and could you help me track down the cause?
<Xach>
semz: no to the former, maybe to the latter!
<Xach>
semz: what implementation and platform are you using?
jcowan has quit [Ping timeout: 260 seconds]
<semz>
ECL on Linux with musl. All on newest version.
<semz>
Problem is that starting Slime sometimes (but not always!) produces a segfault
<phoe>
semz: crash dump tells you anything? the stack trace especially
<Xach>
ah, sorry, can't help at all, I don't use ecl.
<phoe>
#ecl does use ecl though
<semz>
phoe: ECL seems to catch the segfault, so I don't think there even is a dump. It doesn't crash itself and just returns to the toplevel. Then (again, only sometimes) the connection dies out of nowhere.
<semz>
it's really bizarre and definitely doesn't happen on glibc
<semz>
maybe i'll try #ecl, thanks
random-nick has quit [Remote host closed the connection]
<khrbt>
semz: can you share details on how you set up your system so someone can try to reproduce what you are seeing?
cpc26 has quit [Remote host closed the connection]
cpc26 has joined #lisp
cpc26 has quit [Changing host]
cpc26 has joined #lisp
fourier has quit [Ping timeout: 268 seconds]
energizer has quit [Ping timeout: 260 seconds]
shrdlu68 has quit [Read error: Connection reset by peer]
damke_ has joined #lisp
shrdlu68 has joined #lisp
Quetzal2 has quit [Quit: No Ping reply in 180 seconds.]
damke has quit [Ping timeout: 264 seconds]
<semz>
khrbt: Sure. It's a clean install of Emacs (25.3.1, from Gentoo's musl overlay), Slime (2.20) and ECL (16.1.3). Musl is on 1.1.19.
amerlyq has quit [Ping timeout: 256 seconds]
damke_ has quit [Ping timeout: 264 seconds]
dented42 has joined #lisp
TCZ has quit [Quit: Leaving]
damke_ has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
fourier has joined #lisp
makomo has quit [Read error: Connection reset by peer]
equwal has joined #lisp
makomo has joined #lisp
equwal has quit [Read error: Connection reset by peer]
sauvin has quit [Ping timeout: 264 seconds]
Naergon has quit [Ping timeout: 256 seconds]
equwal has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
amerlyq has joined #lisp
dyelar has joined #lisp
amerlyq has quit [Ping timeout: 264 seconds]
dyelar has quit [Client Quit]
fikka has joined #lisp
amerlyq has joined #lisp
<rpg>
cgay: I think you were right: intellicorp. They did a bunch of work in the petroleum industry back when I was working at the Honeywell labv.
equwal has quit [Remote host closed the connection]
<rpg>
semz: Is there some particular reason that ECL is appropriate to what you are doing?
dyelar has joined #lisp
<phoe>
semz: you might also do a trick
nowhereman_ has joined #lisp
<semz>
rpg: It was the easiest to get. Glibc can't statically link so the bootstrap binaries for say SBCL don't work on my system.
<phoe>
get your ECL ready to load slime, attach a debugger to it, try loading slime. you'll get the sigsegv and will be able to print its stacktrace.
random-nick has joined #lisp
random-nick has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 240 seconds]
Naergon has joined #lisp
<rpg>
semz: I think you will find that you will be happier using Clozure CL or SBCL. ECL is a tool with a very specific niche and in my experience does not work well as a general purpose CL implementation.
<rpg>
It has many idiosyncracies, and code of mine that really exercises CL makes it error out all the time, despite working successfully on ACL, CCL, and SBCL.
<rpg>
ECL and ABCL are in my "special purpose" list, and clisp in my "just don't."
nowhere_man has quit [Ping timeout: 248 seconds]
Kundry_W_ has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
fikka has joined #lisp
<Xach>
If the primary goal is to get CL stuff done, ecl can be a tough start. But if you're playing around and aren't under time pressure or whatever, trying ecl and reporting bugs is helpful in making it better.
fikka has quit [Ping timeout: 240 seconds]
Satou has quit [Quit: Cya soon guys!]
fikka has joined #lisp
random-nick has joined #lisp
vap1 has quit [Ping timeout: 240 seconds]
<rpg>
Xach: True, but I guess I would suggest getting your footing using a more normal CL would be a better experience.
damke has joined #lisp
<puchacz>
I think clisp is not maintained.
fikka has quit [Ping timeout: 264 seconds]
<rpg>
puchacz: It's maintained, but for whatever reason, it hasn't been possible for the project to manage a release in years and years.
<puchacz>
rpg: I see
<rpg>
I don't have the energy to build it from source, but I hear that the head version is much better than the release
<puchacz>
SBCL has monthly releases, ABCL maybe once a year, clisp, no release for a long time as you say
damke_ has quit [Ping timeout: 265 seconds]
<rpg>
CCL is also quite active. ECL is still, AFAICT, recovering from loss of its main maintainer and need to restructure as a project
varjag has joined #lisp
<puchacz>
what's the benefit of CCL over say SBCL?
<puchacz>
I only used SBCL, ABCL and Lispworks
<dlowe>
it has some very nice inspection and debugging.
<dlowe>
I think sbcl has closed some of the gap over the years.
<puchacz>
ah, ok. SBCL never had stepper except for trivial cases
<puchacz>
however it has useful debug information on stack in slime
<pierpa>
Many years ago to build clisp all the energy required was to type 'make'. Is it not so anymore?
<pjb>
puchacz: you think wrong. clisp is maintained.
<puchacz>
pjb: I was corrected already :)
<pjb>
it cannot be stressed enough. clisp is maintained.
<puchacz>
okidoki. are you a committer?
<pjb>
I'm not. Not enough time for that :-(
Kundry_W_ has quit [Remote host closed the connection]
comborico1611 has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
amerlyq has quit [Ping timeout: 260 seconds]
amerlyq has joined #lisp
vaporatorius has joined #lisp
Kundry_Wag has joined #lisp
<Xach>
pierpa: I haven't found that to be the case for many, many years. I always have to fetch some extra libraries.
fikka has joined #lisp
random-nick has quit [Quit: quit]
<pierpa>
Good to know
random-nick has joined #lisp
random-nick has quit [Client Quit]
random-nick has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
equwal` has joined #lisp
makomo has quit [Ping timeout: 256 seconds]
pierpa_ has joined #lisp
angavrilov has quit [Remote host closed the connection]
makomo has joined #lisp
scymtym_ has joined #lisp
scymtym has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
<puchacz>
btw, is ABCL good enough for 24/7 server? I know SBCL is a default go-to Lisp for this, but if I ever need to interact with large amount of Java?
<puchacz>
I know it has no delivery like SBCL
<puchacz>
and I only use it at work to tinker and interact with existing software
<jcowan_>
pjb: Yes, if you count PDP-7 Unix. The PDP-11/20 ran only Mini-Unix, not Unix itself
<phoe>
puchacz: ELS 2016 had a lightning talk where AFAIR there was a Java application deployed to production with ABCL included. AFAIR it was a server application, but I might not know the details.
<phoe>
easye: ^
<phoe>
puchacz: easye was the speaker, he could have some details.
Kundry_Wag has quit [Read error: Connection reset by peer]
Mutex7 has joined #lisp
Kundry_Wag has joined #lisp
<puchacz>
thanks. easye, are you around :) ?
<rpg>
puchacz: I have found ABCL to be substantially slower than conventional lisps. I have used it very successfully as a way of scripting a Java application, but I don't think I would use it as my "main" lisp
shrdlu68 has left #lisp ["Goodnight."]
<phoe>
puchacz: this is IRC, he'll respond in due time.
<phoe>
(:
<puchacz>
sure :)
fikka has quit [Ping timeout: 240 seconds]
<puchacz>
rpg: yes, I think it is slower especially around string processing. I parsed logs with it.
<puchacz>
and yes, my main server Lisp is SBCL
<puchacz>
ABCL is also the only Lisp I can have at work.... it is just jar to be downloaded. but I can't have quicklisp because our proxy is authenticated
<puchacz>
in Eclipse for Java I have to put my corporate username and password for updates to work etc.
<puchacz>
so I had to download Lisp libraries one by one, manually.
<puchacz>
it would help if we had a single directory with all current quicklisp bz2 or whatever libraries
<phoe>
something like a standalone quicklisp instance?
<puchacz>
not descriptions, just links for odwloading
<puchacz>
yes
<jcowan_>
Are mkcl and cmucl still maintained?
<Xach>
cmucl is still maintained. mkcl not as much.
<Xach>
puchacz: you could bundle every library into a quicklisp bundle, i suppose
<puchacz>
Xach: I don't understand....
<random-nick>
what happened to that other armed bear common lisp?
fikka has joined #lisp
<random-nick>
the one which didn't use java
<jcowan_>
random-nick: On CLR, you mean?
<random-nick>
no, native
<phoe>
random-nick: huh? you mean xcl?
<Xach>
random-nick: I don't think there was something like that.
<pjb>
I would use %make-mystructure because you may have other options such as :named, etc…
milanj has joined #lisp
* didi
nods
fikka has quit [Ping timeout: 240 seconds]
<oleo>
oleo: is there a way to get local files processed like html for display purposes ?
<oleo>
<oleo> i think drakma:http-request does not do "file:///blah"
<Bike>
drakma doesn't do html
<Bike>
it does http that's why it says "http request"
<pjb>
there is at least one html processor written in CL, but I don't remember its name. Probably too old, and not supporting javascript, so basically useless.
<pjb>
cliki has a better memory than me.
shka has quit [Ping timeout: 264 seconds]
<rpg>
oleo: You could use portable allegroserve (paserve)
Bindler has quit [Remote host closed the connection]
random-nick has quit [Read error: Connection reset by peer]
random-nick has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
hiroaki has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
puchacz has quit [Quit: Konversation terminated!]
amerlyq has quit [Ping timeout: 260 seconds]
amerlyq has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
pjb has quit [Quit: ERC (IRC client for Emacs 25.1.1)]
equwal` has quit [Remote host closed the connection]
Jesin has quit [Quit: Leaving]
makomo has quit [Ping timeout: 268 seconds]
hiroaki has joined #lisp
amerlyq has quit [Ping timeout: 264 seconds]
<aeth>
rpg: Shinmera's right. There are three levels of compiler information. Function (compiler can do everything), compilation unit (compiler can do fancy tricks), everything else (compiler can't do that much). Generally, file == compilation unit, so putting everything in a file *should* in general make things faster. It could slow some things down by adding type checks, but, in general it's better for a final executable.
<aeth>
Of course, it kills a lot of the live coding so it's not good except as a build step.
amerlyq has joined #lisp
<aeth>
It also seems to not work with certain libraries. I'm going to have to think about how to replace them to make it work. At the moment, it only works if I load the all-in-one file after already loading the system normally, because CL culture overrelies on fragile global *foo* variables that can break in cases like this, and in threads, etc.
fikka has joined #lisp
<aeth>
(CL is the only programming language culture I know of that doesn't shun globals.)
<onion>
stomach flora biocolture
<Shinmera>
The problem isn't global variables but simply compile-time dependencies.
<aeth>
Dynamically scoped globals slow down your code by killing pretty much all compiler optimizations. And they are problematic enough that they have to be earmuffed by convention.
<Shinmera>
They're not problematic.
<Shinmera>
The earmuffs are simply there because they behave differently.
<rpg>
aeth: Is putting everything in a single file equivalent to WITH-COMPILATION-UNIT, or not? I don't claim to know.
<aeth>
They're not particularly problematic in single threaded programs when earmuffed. They are absolutely problematic when not earmuffed because you'll accidentally have a dynamic variable when you expect a lexical variable if you do not earmuff.
<Shinmera>
That's not a problem with dynamic variables in and of themselves.
<aeth>
They *do* kill compiler optimizations, though, because they could be literally anything.
<Shinmera>
Macros aren't "problematic" either just because you can't funcall them.
<aeth>
I'm not sure even a compiler with global program analysis could make dynamic variables fast because you could redefine a function at runtime or in the REPL or whatever to suddenly set that value.
<aeth>
I used to use globals as a quick hack when I didn't want to (at the moment) rewrite the function signature of a bunch of functions along the call stack, but... I got unexpected results because they don't necessarily sync between threads the way I thought they might. Now I essentially never use them, except for input/output/etc. where a bad value isn't the end of the world.
<aeth>
Rebinding *standard-output* (or similar things) seems to be the main use for them.
amerlyq has quit [Read error: Connection reset by peer]
amerlyq has joined #lisp
<didi>
I like globals. I usually use them to store data that I manipulate using the REPL.
__rumbler31 has quit [Ping timeout: 264 seconds]
<aeth>
Well, I can use them *in the REPL* rather than in the program, such as (defparameter *window* (function-call-that-returns-a-window)) and then I can use method calls on the window object
equwal` has joined #lisp
<onion>
aeth, can use CLOS objects to solve that sync problem ?
<didi>
aeth: I use defvar for that.
disumu has quit [Quit: ...]
<aeth>
didi: Iirc: defparameter overwrites it, though. If I do defvar, wouldn't the first one have to be the defvar, and then subsequent ones setf?
<aeth>
Then I can't use SLIME history to be lazy
amerlyq has quit [Ping timeout: 264 seconds]
<aeth>
onion: I think at that point it no longer becomes simpler, though.
<didi>
aeth: Yeap. It's more of a concept thing, I read. defparameter if for program definitions, defvar for variables.
<didi>
s/if/is
<aeth>
In the REPL I always use defparameter because defparameter is what I expect (especially since I mostly use backwards history search in the REPL)
<onion>
hm yeah. this is also something that writing a C lisp runtime with SDL , could solve. for eg. it would take care of any globals that need to be around, like the SDL window, audio context
<_death>
when there's pervasive context, use of special variables makes sense.. also makes for a much better experience when using the repl.. other languages tend not to have special variables, so there's no comparison
amerlyq has joined #lisp
<didi>
aeth: I usually use defparameter in programs when I hardcode paths.
<aeth>
onion: I put the things that need to be around in one window object (e.g. the SDL window, the GL context, etc.).
wigust has quit [Ping timeout: 256 seconds]
Karl_Dscc has quit [Remote host closed the connection]
msb has quit [Ping timeout: 256 seconds]
<aeth>
It's very, very easy to wind up with way too many things in general, so I heavily use both CLOS objects and structs all over the place, and probably need at least twice as many as I do use because there are just too many things. I think at one point, one function said something like "function foo expects twenty-one arguments but only twenty were provided", but I think I've halved it since then
<aeth>
Yeah, globals could probably help, too, but it doesn't actually tidy up the mess: it puts the mess in 20+ globals
<didi>
aeth: Maybe you need more clumping? I mean, aggregate values into a single concept.
<_death>
well, maybe the solution isn't globals in that case, but redesign
<aeth>
_death, didi: It's hard, though, because large applications just have a ton of stuff.
<aeth>
There's a ridiculous amount of state.
orivej has quit [Ping timeout: 240 seconds]
<onion>
aeth: i think that is what i will do as well. i only really need the GL/AL context and SDL stuff
<onion>
...not that any apps make more than one SDL window or anything else... overdesigned i think =)
msb has joined #lisp
<aeth>
onion: That's one reason I write my own stuff instead of using libraries. Libraries have to handle every case, my own stuff on the raw CFFI only need to handle my case, and are about equally verbose.
<aeth>
More than one SDL window? Nope! I can say that will absolutely never be permitted, at least for now.
<aeth>
If I didn't build everything heavily integrated, that just couldn't work.
<aeth>
If you handle more than 1 use case when there is more than 1 possibility, you will never get past that area, and you probably won't test all code paths.
<onion>
im just saying it seems like an overdesign for SDL2 to just about force globals "just in case" someone needed more SDL in the same thread
<_death>
aeth: yes, good design is hard.. btw, curious, what do you consider "large" to be
<onion>
and yeah
<aeth>
_death: In CL, large seems to start at around 7k. I'm absolutely astonished when I see some CL things above 100k (SBCL?) because that's probably equivalent to about 5M in other languages.
<aeth>
Although I expect that when it's finally working it will be around 25k. I spent about 2 years around 5k, though, because with macros it's hard to actually have forward progress in line count.
<aeth>
But it's not really line count in CL, it's what you're doing. There's a lot of stylistic freedom.
<_death>
right, good design may be hard, but good design to lisp standards is harder ;)
<Shinmera>
Doing a primitive line count on my projects directory (which doesn't have everything) I get around 200'000 lines. Neat.
<rme>
I think CCL has about 400kloc (lisp files only).
<rme>
Looks like about another 70kloc of C and assembly.
<rme>
I consider that pretty big.
damke has quit [Ping timeout: 264 seconds]
<aeth>
Running "cloc ." on my outdated SBCL git checkout (cloc cuts out comments and blank lines, but not the docstrings) says SBCL is 401130 lines of Lisp and 26921 of C and 3817 of C headers and 3681 of sh and 2382 of asm
<aeth>
Without cutting out the comments and blank lines, it looks closer to 500k for Lisp
<onion>
easier to have worse design and also better design, with the stylistic freedom
<aeth>
SBCL might be the largest Lisp application.
<aeth>
(well, in public)
amerlyq has quit [Ping timeout: 256 seconds]
dmh has quit [Read error: Connection reset by peer]
<aeth>
I think the really massive Lisp applications are Lisp implementations and Maxima.
dmh has joined #lisp
<Shinmera>
QPX
* onion
computes emacs src tree
<aeth>
Well, of course most Lisp in the wild is Emacs Lisp, and probably a lot of that eventually makes its way into Emacs itself.
<onion>
1,336M lisp .....
<aeth>
(and iirc cloc doesn't distinguish between EL and CL, so it might not be 100% accurate for projects that have Emacs modes in their source tree)
<onion>
yea
<onion>
282K C
<onion>
+58K headers
<aeth>
Emacs Lisp isn't particularly well-written Lisp, though. In general. I think a lot of it is working around the limitations of the language, and a lot of it is Lisp written by people who have no CL or Scheme experience.
<onion>
yea, and old style lisp
<aeth>
I'm not sure how the standard of the core compare to some of the horrifying add-ons whose source I've read, though
<onion>
lots of random stuff is included too, random emacs games and easter eggs etc
<aeth>
Modern CL probably uses more macros than EL, too.
<aeth>
And other things that get the line count down.
* onion
counts SWI-Prolog
<onion>
yea, not sure if ocmments were counted
<aeth>
If you're normally a C programmer and you write an EL file, you're probably not going to abstract as much as a seasoned CL programmer writing a CL application. And many common abstractions might introduce too much of a runtime penalty in EL vs. in SBCL or CCL.
<aeth>
If you know how to make an AOT compiled CL perform, you can get away with writing a lot of "zero cost" abstractions that probably don't work in other Lisps.
<onion>
ECL: 64K lisp, 500K C ^_^
<onion>
yes, definately
<aeth>
onion: Sounds like a lot of ECL could be moved to CL
<phoe>
onion: it's actually been the other way, for performance.
<onion>
eh oh? how come?
<phoe>
...at least from what I've heard
<onion>
cant we write C with CL now, with ECL? ^_^
<jcowan>
Yes, but it's still C, not really CL.
Kundry_Wag has quit [Remote host closed the connection]
<bjorkintosh>
but the input is CL!
<onion>
i did cl-bench on SBCL and ECL the other day , i dont see what it gains; they could just compile with SBCL. =)
<onion>
hm , yeah =P
<aeth>
I generate GLSL strings from CL macros at compile time. It probably wouldn't take *that* much to also support C given the major similarities.
<phoe>
onion: ECL is compilable as a static library into C projects, and SBCL can't do that.
<onion>
hm that is a nice feature
<_death>
onion: many of those 500K is generated C
Kundry_Wag has joined #lisp
<aeth>
_death: Why isn't it generated as part of the build process?
<onion>
_death: ohhh. my bad, i should have done 'make clean'
<phoe>
xD
<aeth>
onion: Ah, maybe it is
<_death>
aeth: dunno, maybe it dosen't change that much
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_death>
maybe it wasn't generated by ECL developers
<onion>
210K C
<aeth>
Is it C with { on its own line or C with { at the end of the line?
<aeth>
That makes a huge difference.
<onion>
i would prefer one tyrannical implementation
<phoe>
onion: you have one, it's called SBCL
<_death>
onion: now, ECL also includes a bunch of 3rd party modules, like gmp/libffi/bdwgc
<onion>
i wonder if 'cloc' could be configured to ignore single-character lines =)
<aeth>
onion: SBCL is an order of magnitude more popular than CCL, which is an order of magnitude more popular than the rest.
<onion>
_death: is that good? can SBCL still include those ?
<aeth>
If you cover SBCL and CCL, you cover most people.
<onion>
i am thinking why not SBCL do the things ECL can, or somehow minimally. or hmm
<phoe>
onion: it does not need to include those
<onion>
aeth: ah =)
<phoe>
it has its own implementations of math, FFI, and garbage collection
<onion>
ECL does ?
<phoe>
SBCL does, so it does not need to depend on gmp/libffi/bdwgc
<onion>
oh, sbcl, yeah. aside from being able to make a little runtime library
<onion>
er static lib*
<aeth>
Personally, I only try to support SBCL, CCL, and ECL. The other popular FOSS ones are CLISP and ABCL, which are both problematic in various ways when making assumptions that work on the rest (especially on SBCL and CCL). And for LispWorks/Allegro, well, they can always pay me if they want me to support their really expensive implementations. Or at least give me free copies.
<onion>
= ) fair enough
<aeth>
It's probably hard to judge the relative popularity of the long tail but still used implementations (ECL, ABCL, CLISP, LW, Allegro)
jmercouris has joined #lisp
karswell has quit [Remote host closed the connection]
equwal` has quit [Ping timeout: 256 seconds]
<onion>
i've read some of their geneology
<onion>
SBCL from kyoto afaik
karswell has joined #lisp
<onion>
(i have affinity to japanese things)
<phoe>
SBCL is a fork of CMUCL
k-stz has quit [Remote host closed the connection]
jmercouris has quit [Remote host closed the connection]
rpg has joined #lisp
jmercouris has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
makomo has joined #lisp
void_pointer has joined #lisp
<aeth>
Oh, I might have been unclear. SBCL is an order of magnitude more popular than CCL, which is an order of magnitude more popular than any remaining individual implementation... Not necessarily an order of magnitude more popular than all of the rest combined.
Bike has quit [Ping timeout: 260 seconds]
<aeth>
I suspect that getting more exact numbers than that relation would be hard.
<_death>
someone should start writing libraries exclusively for GCL ;)
<jmercouris>
CCL is great
<aeth>
And no matter what it'd probably undercount commercial implementations, which are kind of in their own world.
<jmercouris>
I actually prefer it to SBCL
<void_pointer>
When I first heard that, I found it quite surprising. I was under the impression that the gaps between 2nd and 3rd was much narrower, and 1st and 2nd a bit narrower
<aeth>
void_pointer: Things were probably narrower 10 years ago when CLISP was extremely popular. Years of no release has made it decline significantly afaik
<_death>
aeth: if you think about the primary feature of ECL, being embeddable, then the number of users (developers) is also more tricky to determine
<aeth>
_death: Same with ABCL and possibly LW
<void_pointer>
that would explain it. I had tried picking up common lisp a first time back in 2013 and then put it down until just late last year
<aeth>
I'm guessing 10 years ago CLISP was up there with SBCL and LW might have been up there as well
<aeth>
It's really hard to compete with SBCL, though. It's both the fastest *and* the most informative.
<void_pointer>
depends on the specific needs
<jmercouris>
why is CLISP even a thing?
<aeth>
(In general, of course. I still catch things that SBCL tolerates and CCL does not, for instance.)
<jmercouris>
why would anyone use it when objectively every other implementation is better?
<_death>
aeth: yes, CLISP was more popular
<aeth>
jmercouris: CLISP is a bytecode implementation, so it's probably the first to every new platform. (Not a big deal when everyone is on x86-64 or ARM, and maybe RISC V in the future.)
<phoe>
jmercouris: popularity, readline integration, it's fast and useful for scripting
<jmercouris>
aeth: I find it the other way around, SBCL is constantly complaining about things that CCL accepts unquestioningly, what platform are you running on?
<aeth>
jmercouris: And, yes, as phoe said, readline
<aeth>
CLISP is very approachable from the terminal. With SBCL, you have to rlwrap
<jmercouris>
why does readline matter? we are all using slime anyway
<aeth>
well, now we are
<phoe>
jmercouris: hah, you *wish*
<aeth>
Most of us started in the terminal, especially back in the day.
<phoe>
#lisp isn't all of lisp users.
<jmercouris>
I can't imagine developing in Lisp directly from the terminal
<void_pointer>
ECL has some major advantages when working with lots of C code back and forth. That is one area where SBCL has some disadvantages
<phoe>
void_pointer: you mean the FFI cost?
<aeth>
It also takes a *long* time for accurate and up to date information to spread. A lot of old material tells people to use CLISP or the free LW.
<aeth>
The common wisdom today is probably something along the lines of: "Try SBCL then CCL then ECL in that order." That wasn't the advice from 1998 to 2010. And those sites and books are still there.
<jmercouris>
I would say go CCL -> SBCL -> ECL
<jmercouris>
CCL is the most user friendly and easiest to install
<aeth>
macOS might reverse the SBCL and CCL, but only on macOS
<phoe>
>easiest to install
<jmercouris>
at least on a Mac, it is
<jmercouris>
I didn't type quick enough ;)
<aeth>
Fedora has SBCL and ECL, and maybe one or two more obscure ones. But does not have CCL.
<void_pointer>
phoe: yes, in its various facets. Different GC helps a lot, even though it hurts performance in many ways.
<aeth>
Pretty much every Linux (or other Unix) distro that has a packager who cares about CL is going to have SBCL
<phoe>
aeth: I do not think any Linux has CCL in its repos. not from the popular ones at least.
<void_pointer>
I have only SBCL and ECL on my computer. Have looked into getting CCL on here
<void_pointer>
if for no other reason than to make sure my code runs on multiple implementations OK
<aeth>
Oh, Fedora also has clisp
<phoe>
void_pointer: your OS?
<void_pointer>
GNU/Linux, but the project I am working on would target other OSes as well - specifically Windows, Max OS X, and possibly FreeBSD
<aeth>
I use roswell to get the latest SBCL and ECL and CLISP (hah, like they'll update it), and to get any access to CCL, ABCL, Clasp (roswell fails to compile it, which is annoying because the failure happens after at least 10 minutes; maybe it works now), etc.
<aeth>
I then use this for testing
<aeth>
I develop on Fedora's SBCL, though, because it's recent enough. Fedora seems to treat every SBCL release as potentially breaking, so it only updates when the distro updates, which is every 6 months. Current enough, though.
<jmercouris>
phoe: ubuntu has it
<phoe>
void_pointer: just grab a ccl package from the website and ln /opt/ccl/lx86cl64 /usr/bin/ccl
<phoe>
jmercouris: oh, really? that's news for me
<jmercouris>
yeah, it is in apt-get iirc
<jmercouris>
I don't have a linux machine to test it on at the moment, but I believe so
<void_pointer>
between that and having to worry about both amd64 and arm, I have to stay rather flexible with respect to implementation still
<phoe>
jmercouris: ...can't find it
<jmercouris>
strange
<jmercouris>
maybe I added some multiverse to my system
<jmercouris>
or whatever the term is, I always forget
<jmercouris>
I'm not a linux user
<dTal>
what do you use?
<jmercouris>
bsd
asarch has quit [Quit: Leaving]
<dTal>
sweet which one
<jmercouris>
freebsd/macOS
* didi
keeps forgetting `:initial-value nil' and no :initial-value are different for reduce
<dTal>
I retract my "sweet"
<jmercouris>
lol, that's fine, perhaps I'm not cool enough to be using open or dragonfly
<dTal>
heh, FreeBSD is fine, MacOS doesn't get to be called a BSD
<aeth>
I've been waiting for a cheap (< $250), low power RISC V for years at this point (lowRISC used to say that it would release sometime in 2017). It's close enough to MIPS that I think CCL and SBCL will support it fairly quickly.
<void_pointer>
aeth: been waiting for one as well
<jmercouris>
aeth: complete system, or just the cpu?
<dTal>
I'd run OpenBSD on my laptop if it didn't suck for all practical purposes
<aeth>
jmercouris: I only need the CPU and ethernet
<aeth>
home server
<aeth>
I currently run my IRC on a raspberry pi
<void_pointer>
I would like something somewhat akin to a raspberry pi
<void_pointer>
but risc-v
<aeth>
I don't use the graphical part of the raspberry pi
didi has left #lisp ["there are always reasons to /part"]
Kundry_Wag has quit [Remote host closed the connection]
pmc_ has joined #lisp
<void_pointer>
funny thing, just ordered one yesterday - pi 3 B+. Getting it for common lisp development actually. Want project to run on low end ARMs with decent enough performance. If it can work well enough on it, then it will work quite a bit better on higher end ones. Also, reduce ISA assumptions
<aeth>
Is it ARM 64 yet?
<jmercouris>
void_pointer: a good way to test how good your code is to run it in a VM with low resources
<jmercouris>
it is very easy to deploy, and you can use something like vagrant with some provisioning system behidn it
<aeth>
I make one architecture assumption: 64-bit, with a large enough implementation fixnum size (60ish is fine; this is something that both 64-bit CLISP (48ish bits) and ABCL (uses 32-bit int) fail afaik)
<void_pointer>
aeth: on risc-v, more likely to see a cheaper board from sifive soon than lowrisc, I think
<jmercouris>
you will have to use a masterless provision for a single vm of course...
<void_pointer>
aeth: as far as arm64, raspbian is still 32-bit
<void_pointer>
aeth: however, other distros do have arm64 ports for the pi 3
<aeth>
The problem with 32-bit is that the size of everything depends on fixnum, and 32-bit is a *much* lower fixnum size. Also, single-floats are boxed. There goes the performance of anything that uses single-floats.
<void_pointer>
aeth: I have used 64bit SUSE on a pi 3 already (port had a lot of work left to do, sadly)
<aeth>
I write double-floats with care, and at least SBCL knows that it doesn't have to box them if they're stored in arrays (or structs) of the right type and accessed the right way. I don't write single-floats with care, because that would be annoying.
<aeth>
So while stuff I write that use floats could run in 32-bit, it will absolutely destroy the GC if in a hot loop
<void_pointer>
jmercouris: a VM is useful for that, and I do plan on using some VMs for some more extensive tests across more processor families
msb has quit [Ping timeout: 248 seconds]
<jmercouris>
what is the software you are writing that is CPU bound?
<void_pointer>
jmercouris: though, one thing a VM doesn't provide, is a physical GPU, though admitedly the pi's is quite pathetic (which in some ways is ideal for what I am working with)
<aeth>
jmercouris: The big CL program I'm writing is a game engine. It's not CPU bound, it only uses about 2% to 8% (mostly on the low range) of my i7-4790k (might already be too slow for a pi3) because it runs the logic at 100 FPS and the rendering vsynced. (I don't have networking yet, but if used on a headless game server, it'd probably use a lot less CPU because the rendering takes up a lot of the CPU)
<aeth>
But it's a game engine, or possibly a game framework. Depends on how I market it in the end. The CPU overhead has to be low because that means that the users can do more things with it.
<aeth>
2% CPU means 98% CPU for the user.
<aeth>
I'm told that the CPU% thing might not be 100% accurate because the modern computer might go into a lower power mode. And my engine might be low enough in CPU usage that it might send the computer into low power mode. Idk.
<void_pointer>
on a pi 3, it might work ok if game logic and graphics run on separate threads
<aeth>
I'm not aware of a more accurate measurement, though. FPS can't really work.
<void_pointer>
not possible with every kind of game, though
<void_pointer>
or well, not necessarily easily
<aeth>
FPS is too influenced by the renderer, and FPS only really tells you when it's under the cap.
LiamH has quit [Quit: Leaving.]
<void_pointer>
aeth: funny coincidence, but that is the sort of project I am working on as well
<void_pointer>
aeth: though I suspect it is of a very different nature
<aeth>
void_pointer: Common Lisp seems to be increasingly popular, at least on Freenode, for this sort of thing. I even see it show up from time to time in #reddit-gamedev, not just in the Lisp-specific #lispgames (although I haven't seen it in #gamedev yet)
<aeth>
I guess people want something Pythonish, but without absolutely terrible performance for this sort of thing.
<aeth>
(Or even Schemish)
<aeth>
(The fast Schemes are not the Scheme with all of the libraries, at least at the moment.)
<void_pointer>
had similar reasoning here - that and a better package situation than scheme (honestly, would have preferred scheme otherwise)
<k-hos>
is there someone other than me and you aeth that use lisp in reddit-gamedev? :p
<aeth>
k-hos: I think there are at least two other people who have mentioned it, actually.
<jcowan>
void_pointer: Cloud CPUs do provide GPUs, if you pay for them
<jcowan>
aeth: Chicken is plenty fast, though not as fast as Chez or Stalin, and is certainly not short of libraries
<aeth>
jcowan: Chicken is the only one where I'm not aware of a gamedev community. Racket obviously has games. And davexunit represents Guile in #lispgames and has actually made patches to Guile to improve its performance in gamedev
<aeth>
(The only one of the big three)
Sveaker has joined #lisp
somewun has quit [Remote host closed the connection]
<aeth>
jcowan: I think that at least for the specific performance requirements of games, though, that source-to-source compiling r7rs Scheme to SBCL (with CCL as a backup implementation) will get the best performance.
<void_pointer>
jcowan: I did not think about that. That might be useful later on if I need access to various nvidia cards or older amds (got access to two intel integrateds, a newish high end amd, and well, what the pi 3 will have)
<jcowan>
I'd love to do that, although presumably one would need to take precautions around call/cc.
<aeth>
jcowan: My cl-scheme is essentially on hold until I can think of a fast, elegant call/cc
<phoe>
with unwind-protect you can't really have easy call/cc
<aeth>
It's about 50% of a Scheme atm
<jcowan>
I wrote a clean-room CL implementation of T years ago but had to punt on tail recursion (not commonly provided then) and call/cc.
<void_pointer>
also, might have to do chicken style MTA due to the recursion, which might not be pretty in common lisp (honestly have no idea, but wouldn't want to try it myself)
<aeth>
phoe: The way I do it in cl-scheme, it wouldn't matter. It's not like Pseudoscheme where it compiles to CL and drops the Scheme features that don't fit. It's more like... it adds a very small runtime so that it can handle all Scheme features.
<phoe>
aeth: I see.
<aeth>
At the moment, I use a trampoline to get tail recursion, although I guess I could make non-portable assumptions to bypass the trampoline. It's hard, though, because it's not a matter of implementations, it's a matter of implementations *and* optimization level
* jcowan
wonders if CLTAU is still in the comp.lang.misc archives
<aeth>
A trampoline to get tail recursion is actually very small in CL, maybe a dozen or two dozen lines, and it isn't noticably slower than actually doing tail recursion. (It probably is slower, it's just not slow enough to be detected when I benchmarked in SBCL)
<jcowan>
aeth: I think most non-CLISP implementations provide tail calling nowadays, though others here probably know better than I.
<aeth>
jcowan: The problem is that SBCL with (optimize (debug 3)) afaik turns that off, and a lot of people use debug 3.
<jcowan>
Umph.
<aeth>
And if the point of transpiling is maximum speed, the main focus will be getting it to work on SBCL
<aeth>
At least, as things stand in 2018 and probably at least for the next 5 years.
<jcowan>
"What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?" --C. A. R. Hoare
<aeth>
I started out with an interpreter approach and quickly moved to source-to-source compilation, but if I return to the project I might add back the interpreter because apparently a lot of people (literally several!) were interested in the sandboxing aspects.
<aeth>
It might also be possible to (eventually) write a cl-cl with some common code with cl-scheme, to get a similar result but for CL
patrixl has joined #lisp
<phoe>
jcowan: that's why I never drop safety below 1
patrixl has quit [Client Quit]
Bike has joined #lisp
<aeth>
Iirc, the two things that stalled cl-scheme were (1) call/cc and (2) a mutable global lexical environment (which outside of the REPL is afaik optional, but probably nice to have).
<jcowan>
I'd like the reverse, the ability to compile CL to Scheme, but the main cost there is library cost.
<jcowan>
Leveraging SICL would be great, but apparently it's not finished enough.
<aeth>
By global I mean "global" because it would be contained to the cl-scheme runtime. I could just do something like wrap that in one big let, but then you can't add to it.
<phoe>
jcowan: you'd need to be able to provide a lot of non-standard features
Sveaker has quit [Quit: Leaving]
nowhere_man has joined #lisp
<jcowan>
aeth: I don't understand the issue with globals, can you explain?
<aeth>
jcowan: In CL, you can define new functions at runtime.
<jcowan>
True
<void_pointer>
jcowan: well, if you can compile common lisp to emacs lisp, then you get pretty close since Guile can compile that into one of its intermediate representations which is scheme like and could possibly be compiled to scheme without that much effort
<aeth>
void_pointer: That sounds like a lot of performance would be lost, though. At every step.
<jcowan>
*Can* you compile CL to elisp?
<Bike>
the compiler parts of sicl work
<Bike>
not the backend, but you don't need that for scheme
<void_pointer>
aeth: yes, but running at all is a first step
<jcowan>
What matters is the SICL library
<void_pointer>
jcowan: not that I know of. But emacs lisp is closer to common lisp than scheme is, so it should be easier
<jcowan>
CL itself (that is, the special forms) would be straightforward to compile to Scheme.
<Bike>
you want to compile sicl's implementation of common lisp into scheme?
<random-nick>
guile doesn't do a really good job of compiling emacs lisp, since it doesn't have many optimisations for dynamic scope
<jcowan>
Bike: Yes, but for the purpose of providing a CL library so that CL code compiled into Scheme will get the environment it expects
nowhereman_ has quit [Ping timeout: 276 seconds]
<aeth>
What I want in the long run, although it's kind of on hold until I make significant progress in my game engine (I chose to prioritize that project), is a lot of languages running in one CL runtime. Starting with Scheme because it's close to CL, although it has some significant differences (nil vs. #f and '() is actually one of the more annoying ones to work with)
<Bike>
right
<jcowan>
If SICL were fully working it would just be a matter of replacing the SICL back end with one that generates Scheme.
<aeth>
Ideally, I could spin off a bunch of libraries from cl-scheme and other people could port languages that they want, like JavaScript or Lua.
<void_pointer>
if performance didn't matter at all, would take clisp which can make gnu lightning bytecode and then compile the resulting bytecode to scheme
Kundry_Wag has joined #lisp
<Bike>
well, i mean, sicl also uses lisp, at compile time
<Bike>
the loop implementation uses clos and such
<jcowan>
aeth: You know about Guile's solution to the nil problem?
<aeth>
jcowan: My solution is to make #f :false (although I will have to change that if I add keyword support) so I can completely use the host CL's lists without issue. This requires every CL predicate to be wrapped when called from Scheme, though.
<aeth>
jcowan: It has been a long time since I read about Guile's solution but I think I was inspired by it
<jcowan>
#nil is false but answers true to null?, and is not eq? to either #t or #f.
<jcowan>
that works as long as you don't rely on the precise behavior of eq?/eq.
jmercouris has quit [Ping timeout: 252 seconds]
<jcowan>
sorry, is not eq? to either () or #f
<aeth>
jcowan: I think it's actually easier to do such a thing from a Scheme host instead of from a CL host
* jcowan
thinks about the :false idea
ancient_dog has quit [Ping timeout: 256 seconds]
<aeth>
I want to use as many CL built-ins as possible, for performance. Anything that's built-in will probably be faster than anything I write myself. Or, at worst, equally as fast and much more concise to write.
<jcowan>
Certainly.
<aeth>
It will also leave a clear path for using Quicklisp libraries. Just wrap them the same way as CL built-in functions/macros.
ancient_dog has joined #lisp
<aeth>
Handling CLOS methods might be trickier.
<jcowan>
Bike: I don't understand your comment
vibs29 has quit [Ping timeout: 264 seconds]
fikka has quit [Ping timeout: 264 seconds]
<jcowan>
Not really, because all that stuff is just various flavors of records in Scheme
vibs29 has joined #lisp
<Bike>
sicl is written in common lisp, so you need a common lisp implementation to build and to load it
<aeth>
As for the performance of :false, I think the disassembly is essentially identical in SBCL with comparisons to NIL. It just compares to a different magic number, representing :false, than the magic number representing NIL.
<aeth>
It has been a while since I checked, though.
<aeth>
Any performance penalty would be at the conversion barrier when interfacing the two languages.
<jcowan>
Bike: Right, but that's a bootstrap problem, which many Lisps have
<jcowan>
Chicken, e.g., is distributed with both source code and compiler-generated C for that reason
<Bike>
"just be a matter" sounded overly optimistic, is all
<Bike>
also, there's no backend
sjl has quit [Ping timeout: 260 seconds]
<jcowan>
yes, I was conflating SICL and Clasp there
<Bike>
and boy does clasp have bootstrap problems
<jcowan>
It could be delivered with bitcode
Tahlwyn has left #lisp [#lisp]
<Bike>
loading is... ok, building is not. but that's not what you're talkin bout
<jcowan>
right
<jcowan>
aeth: You're saying that (if (eq? foo :false) this that) compiles to the same thing, modulo a constant, as (if foo this that) in SBCL?
<aeth>
I'll check again
<void_pointer>
Bike: how bad is its bootstrap problem?
<Bike>
with respect to what criteria
makomo has quit [Quit: WeeChat 2.0.1]
<jcowan>
Almost any Scheme would trivially provide all the SICL primops, from the list I saw, and it would already have a GC and so on.
<phoe>
jcowan: (if foo that this)
<aeth>
(defun foo (foo this that) (if (eql foo :false) this that)) (defun bar (foo this that) (if (null foo) this that)) ; the only difference in disassemble is one line: ; 302: 4981F86FA94F20 CMP R8, #x204FA96F ; :FALSE vs. ; 92: 4981F817001020 CMP R8, #x20100017 ; NIL
<aeth>
This makes sense, they're both symbols internally.
<jcowan>
Ah
<void_pointer>
Bike: I guess one criteria is whether it can, if you just download the source, whether it can be built without having to already have a built version or another common lisp implementation
<rme>
on some ccl ports, nil is just a really popular constant. on other ports, it has its own tag.
<jcowan>
the latter is the case I had in mind
<void_pointer>
Bike: GCC, for example, requires a working C or C++ compiler to already be there
<Bike>
that doesn't seem like a problem
<jcowan>
aeth: can you check a simple (if foo this that) without invoking any predicate?
<phoe>
jcowan: yes
<phoe>
you compare FOO with NIL
<phoe>
and branch to THAT if it is NIL, and to THIS otherwise
<jcowan>
I guess that makes sense if it's internally represented as a symbol
<phoe>
NIL is a symbol, yes
<aeth>
(defun foobar (foo this that) (if (not (eql foo :false)) this that)) (defun barfoo (foo this that) (if foo this that)) ; essentially the same, it's still testing against :FALSE or NIL
* jcowan
remembers when NIL was internally represented as all-bits-zero and there were zeros at locations 0 and 2
<jcowan>
of course symbol-string had to treat it specially then
<jcowan>
2, heh, 16-bit thinking
fikka has joined #lisp
<void_pointer>
Bike: depends on who one asks. There is this one project https://gitlab.com/janneke/mes whose part of a collection of tools whose goal is to bootstrap GCC from a small assembler (assembler to build minimal scheme implementation and C compiler (in scheme) to then build tcc and then try to build gcc)
<Bike>
what for
<jcowan>
I guess to port gcc to new OSes (new chips would need more than that)
<Bike>
"Maxwell Equations of Software" okay, so just because
<jcowan>
tcc is something that all HLLs should come with
<aeth>
There is an idiom where :false as #f is going to cause problems, though. You can type something in CL as (or foo null) and it'll behave exactly as you would expect it to behave. Either it's false or it's a foo.
<Bike>
gcc can cross compile, so you don't need to pull yourself out of the muck
<jcowan>
Bike: True, but it's not easy to add a new cross-compiler FWIU
<Bike>
not easy to write the entire sequence from assembly either, you know?
<jcowan>
you would need a new bfd library
<jcowan>
Well, that's why staging it makes sense
<jcowan>
if you all you need for your new chip is an assembler sufficient to assemble a (macro-assembler version of) Scheme, you are in business
<void_pointer>
I'm waiting till someone writes a C compiler in brainfuck
rumbler31 has quit [Remote host closed the connection]
<aeth>
no need to wait
<Bike>
i'm pretty sure that's been done
<void_pointer>
then bootstrapping is easy
<phoe>
void_pointer: d'oh
<void_pointer>
if one has years of CPU time to throw at the problem
<phoe>
you can transpile C into BF
<jcowan>
Better than writing a C compiler in Malebolge
<phoe>
so you can transpile a thing like tcc to BF
<Bike>
aeth: you misread
comborico1611 has quit [Quit: Konversation terminated!]
<jcowan>
aeth: Why is "or" a problem?
<void_pointer>
not compiling to BF, but writing it straight up in BF
<jcowan>
eurgh
<phoe>
welllll
<Bike>
ok so anyway, clasp's problem is that it mostly builds from C++ without lisp, and along with a few other things this makes the build a stupid process
<aeth>
jcowan: I think "esolang" is a bit... lacking of a term. There are two kinds of esolang. "artistic/simplistic" ones and "malicious" ones. Brainfuck is a simplistic one, not an actively malicious one (although the way it jumps makes it hard to do anything useful)
<Bike>
now you know
<Bike>
esolang has classified brainfuck as not an esolang for a while
<Bike>
i mean, it's mathematically useful
<Bike>
i'm speaking informally from when i used to hang out in their irc
<jcowan>
In that case Malebolge is an eso^2lang
<aeth>
Bike: The problem is that everything eventually becomes mathematically useful. Ask pure mathematicians.
<aeth>
(Well, that's a similar case... where pure math gets applications in comp sci or physics)
<Bike>
pure mathematicians, when was the last time you used the lennard jones potential
<Bike>
run c2bf on itself, now the circle of stupidity is complete
<Bike>
brainfuck didn't "become" useful anyway, it's essentially identical to P'', invented in 1964
fourier has quit [Ping timeout: 256 seconds]
<aeth>
I tried writing a CL in Brainfuck, but then I realized that it's at least 10x harder than writing one in asm, and asm would at least be useful to someone.
python476 has quit [Ping timeout: 260 seconds]
<void_pointer>
Bike: sounds like clasp's bootstrapping situation isn't that bad, unless it takes forever as C++ often does (now reminded of how bootstrapping Guile can take well over an hour)
<aeth>
Writing directly to some VM's register machine or stack machine is probably considerably easier than BF.
<Bike>
it takes forever
<Bike>
it would be far more sensible to build from something else, and i've done some work in that direction, but that's still hard
<aeth>
I think the only way to have useful BF as a compilation target is to move the world around some central area (so it's always close by) as you walk through the BF tape. Or perhaps have two BFs talk to each other.
<aeth>
Definitely not a worthwhile use of time to build Lisp on that.
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rme>
ccl rebuilds itself in 30 seconds on my iMac.
<aeth>
does CCL have any C++?
<rme>
nope
<aeth>
Afaik, C usually compiles quickly, C++ usually does not.
<k-hos>
it's all that manglin'
<aeth>
C++'s focus is on adding very many "zero cost" (at runtime! not at compile time!) abstractions.
<Bike>
that's not why clasp's build is slow
<aeth>
An extended macro system could probably do something very similar to what C++ does in a Lisp without the massive time penalties of C++ compilation.
<Bike>
how does ccl build, anyway? i've never been quite clear
random-nick has quit [Remote host closed the connection]
<rme>
It bootstraps by writing a minimal image file (which it constructs in memory), and alsocompiling (or cross-compiling) additional source files that comprise the rest of the lisp. You can then start the bootstrap image, which will then load those fasl files. Then you save an image of the lisp you just made.
<Bike>
how does it write the minimal image?
<rme>
From an existing CCL.
<Bike>
right, i see.
damke has joined #lisp
<Xach>
learn these secrets and more at ELS!
<phoe>
so basically, as soon as someone can create a minimal image file outside CCL, then CCL becomes sanely bootstrappable?
<Bike>
you say that like it's simple
<phoe>
of course it's not
<phoe>
if it was simple we'd already have it
fikka has quit [Ping timeout: 256 seconds]
<rme>
I don't think the existing bootstrapping process is totally insane.
Folkol has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<phoe>
rme: I mean "sane" as "not needing a CCL before it".
fikka has joined #lisp
<phoe>
I looked at CCL's bootstrapping process some time ago and I wouldn't call it mad, if that's what I accidentally implied.
<phoe>
But yes, it's time for me to go to sleep.
damke_ has joined #lisp
<Xach>
xof just called it sanely bootstrappable for a cute pun
<aeth>
Ahah! At least in SBCL, I can do this: (deftype false () `(member :false)) and then these are essentially identical: (defun foo (x) (typep foo 'nil)) (defun foobar (x) (typep x 'false))
<phoe>
aeth: 'null
<phoe>
not 'nil
<aeth>
At least one more point in favor of using a keyword or symbol when embedding a language that requires separating false and '()
<aeth>
phoe: you are absolutely correct, I typoed that
<Bike>
typep nil is going to be very fast indeed
<aeth>
phoe: 'nil is an error 'null gets the disassembly I am looking for
<phoe>
aeth: not really an error
<aeth>
again, one line of difference in SBCL's disassembly
<phoe>
just, well, will get very optimized
<phoe>
since (typep foo 'nil) ;=> nil
fikka has quit [Ping timeout: 240 seconds]
<aeth>
Ahah! At least in SBCL, I can do this: (deftype false () `(member :false)) and then these are essentially identical: (defun foo (x) (typep foo 'null)) (defun foobar (x) (typep x 'false))
fikka has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
damke_ has joined #lisp
Pixel_Outlaw has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
rpg has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kaisyu has joined #lisp
Mutex7 has quit [Remote host closed the connection]
fikka has joined #lisp
Kundry_Wag has joined #lisp
rumbler31 has joined #lisp
pmc_ has quit [Quit: Leaving]
siraben` has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 256 seconds]
rumbler31 has quit [Ping timeout: 264 seconds]
damke_ has quit [Ping timeout: 264 seconds]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]