innovati has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
karswell has joined #lisp
innovati has joined #lisp
Cymew has joined #lisp
Guest5068 has quit [Remote host closed the connection]
itruslove has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
innovati has quit [Ping timeout: 245 seconds]
karswell has quit [Read error: Connection reset by peer]
Cymew has quit [Ping timeout: 260 seconds]
mange has joined #lisp
pierpal has joined #lisp
Cymew has joined #lisp
jason_m has joined #lisp
karswell has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
ZombieChicken has joined #lisp
Cymew has joined #lisp
pierpal has quit [Ping timeout: 260 seconds]
<Xach>
yes
Oladon has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
fikka has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
Pixel_Outlaw has joined #lisp
fikka has joined #lisp
eli_oat has quit [Quit: Leaving.]
<jason_m>
I am working on a system and had a compile time error in one of my source files. When I quickload (asdf load) the system, I land in the debugger with a condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR.
<jason_m>
I know I can look at the error in the inspector, but I don't see the actual underlying compile error.
<jason_m>
Can I get to that in the debugger/inspector?
Cymew has quit [Ping timeout: 245 seconds]
<jason_m>
If I compile and load the particular file, I get a SB-INT:COMPILED-PROGRAM-ERROR which better directs me to the problem, but to get it, I abort from the debugger, open the file, and load that (or sometimes C-c C-c form by form) to get the more specific message.
phadthai has joined #lisp
Cymew has joined #lisp
elfmacs has joined #lisp
Cymew has quit [Ping timeout: 256 seconds]
Cymew has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
thuffir has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
EvW1 has joined #lisp
Cymew has quit [Ping timeout: 252 seconds]
fikka has quit [Ping timeout: 252 seconds]
phadthai has quit [Ping timeout: 260 seconds]
thuffir has quit [Ping timeout: 245 seconds]
zazzerino has joined #lisp
Cymew has joined #lisp
varjag has joined #lisp
terpri has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
pierpal has quit [Remote host closed the connection]
markong has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
varjag has quit [Ping timeout: 252 seconds]
Cymew has quit [Ping timeout: 245 seconds]
comborico1611 has quit [Quit: Konversation terminated!]
EvW1 has quit [Ping timeout: 252 seconds]
Cymew has joined #lisp
pierpa has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
Cymew has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
fikka has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
giraffe has joined #lisp
giraffe is now known as Guest29863
epony has quit [Ping timeout: 260 seconds]
fyodost has joined #lisp
eli_oat has joined #lisp
terpri has joined #lisp
Cymew has quit [Ping timeout: 248 seconds]
pjb` has joined #lisp
itruslove has joined #lisp
pjb has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
fikka has joined #lisp
pjb`` has joined #lisp
zazzerino has quit [Quit: ERC (IRC client for Emacs 25.1.1)]
pjb` has quit [Ping timeout: 245 seconds]
pjb``` has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
Cymew has quit [Ping timeout: 245 seconds]
pjb`` has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
pjb```` has joined #lisp
pjb``` has quit [Ping timeout: 245 seconds]
pjb````` has joined #lisp
fikka has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
jonh has quit [Quit: WeeChat 1.4]
pjb```` has quit [Ping timeout: 245 seconds]
makomo has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
pjb`````` has joined #lisp
pjb````` has quit [Ping timeout: 245 seconds]
fikka has quit [Ping timeout: 245 seconds]
Cymew has quit [Ping timeout: 245 seconds]
pjb`````` has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
surya has joined #lisp
fikka has joined #lisp
d4ryus2 has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
innovati has joined #lisp
surya has quit [Ping timeout: 252 seconds]
Cymew has joined #lisp
phadthai has joined #lisp
d4ryus1 has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 252 seconds]
Cymew has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
charh has quit [Quit: zZzZzZz]
MasouDa_ has quit [Quit: No Ping reply in 180 seconds.]
Cymew has quit [Ping timeout: 245 seconds]
MasouDa has joined #lisp
Cymew has joined #lisp
Oladon has quit [Quit: Leaving.]
thuffir has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrob_ has joined #lisp
kajo has quit [Ping timeout: 245 seconds]
fikka has joined #lisp
Cymew has quit [Ping timeout: 245 seconds]
kajo has joined #lisp
fyodost has quit [Quit: Leaving]
Cymew has joined #lisp
thuffir has quit [Ping timeout: 252 seconds]
fikka has quit [Ping timeout: 248 seconds]
Cymew has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
Mutex7 has quit [Quit: Leaving]
Cymew has quit [Ping timeout: 245 seconds]
Cymew has joined #lisp
smurfrob_ has quit [Remote host closed the connection]
smurfrobot has joined #lisp
Cymew has quit [Ping timeout: 252 seconds]
Cymew has joined #lisp
fikka has joined #lisp
milanj_ has quit [Quit: This computer has gone to sleep]
epony has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 252 seconds]
Cymew has joined #lisp
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
Cymew has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
Cymew has quit [Ping timeout: 252 seconds]
smurfrobot has quit [Read error: Connection reset by peer]
Cymew has joined #lisp
smurfrobot has joined #lisp
smurfrob_ has quit [Read error: Connection reset by peer]
vtomole has joined #lisp
smurfrob_ has joined #lisp
fikka has joined #lisp
smurfrob_ has quit [Read error: Connection reset by peer]
smurfrob_ has joined #lisp
smurfrob_ has quit [Read error: Connection reset by peer]
<jdz>
akr: no, I mean something that a JavaScript implementation (e.g., browser) would write to the console when an object is converted to a string instead of writing the object itself.
<jdz>
akr: also, instead of printing the value, you can use BREAK, and the inspector to inspect it.
<jdz>
I still wonder which library has customised the printing to print objects like that...
<akr>
oh, cool, didn't know about break
<akr>
shrdlu68: thanks, that helps me a bit
<shrdlu68>
Very unhelpful print-object method.
<akr>
okay I see there is an issue on the frontend javascript, jdz was right all along
nirved has joined #lisp
<akr>
thank you for the help
igam has quit [Remote host closed the connection]
energizer has quit [Ping timeout: 252 seconds]
python476 has joined #lisp
_cosmonaut_ has joined #lisp
Negdayen has quit [Ping timeout: 245 seconds]
python476 has quit [Ping timeout: 260 seconds]
m00natic has joined #lisp
<jack_rabbit>
Is it good or practice to (declaim (optimize ...)) inside library packages?
<jack_rabbit>
good or bad*
<loke>
jackdaniel: Bad
<loke>
Well, it's acceptable as long as SAFETY isn't reduced
<loke>
(to 0)
<jack_rabbit>
If I declaim it in my repl, will that apply to packages I load with quicklisp and asdf?
nika_ has quit [Quit: Leaving...]
f1gurehead has joined #lisp
<loke>
jack_rabbit: Hmm.. I don't think so.
<jack_rabbit>
hmm. :(
<jack_rabbit>
I didn't think so either.
<jack_rabbit>
It would be nice for a user to be able to specify that, so the library writer doesn't have to.
zaquest has quit [Quit: Leaving]
<loke>
jack_rabbit: You can, but it's an implementation-specific extension
<jack_rabbit>
mmm
<loke>
For SBCL, look up SB-EXT:RESTRICT-COMPILER-POLICY
<jack_rabbit>
Sweet, thanks!
zaquest has joined #lisp
megalography has quit [Ping timeout: 252 seconds]
<antoszka>
Guys, would you be able to point me towards Peter Norvig's note about his PAIP book being not anymore very useful for AI but still considered a very good CL book?
milanj_ has quit [Quit: This computer has gone to sleep]
malgrand has joined #lisp
ludston has joined #lisp
nowhere_man has quit [Ping timeout: 245 seconds]
<malgrand>
hey this is my first time using irc and this just seemed to ask lisp related questions. I was looking to learn a new language and make a text-adventure for fun in that language. Do you guys think that would be a good idea in lisp?
<edgar-rft>
malgrand, there's a book for learning lisp with lots of games: <http://landoflisp.com/>
<edgar-rft>
and there's a #lispgames channel full of lisp game programmers :-)
lukego has joined #lisp
<lukego>
Hello bastards. ;-)
<malgrand>
edgar-rft, oh thanks! I'll look into it
<lukego>
edgar-rft: How appropriate, you fight like a cow!
<flip214>
people, calm down -- and talk lisp.
<lukego>
Hey I'm looking at USOCKETS and wondering whether people have already been running this with lots of sockets and e.g. adopting the more hardcore platform-specific select()-like system calls. Anybody been up to such mischief already?
<jdz>
lukego: what brings you to lisp this fine day?
<jdz>
lukego: such thing is on my todo-list.
<lukego>
I'm actually hacking Lisp on a fun project. Story for another time :). But it's jolly pleasant.
<jdz>
lukego: I seem to remember Fukamachi's webserver (woo?) used libevent at some point.
<lukego>
I'm peeking in the USOCKETS code (do we still capitalize symbol names like that? :-)) and I see that on LispWorks Linux it's delegating to a builtin mechanism (MP:NOTICE-FD, MP:UNNOTICE-FD), and on LispWorks Windows it's doing scary Win32 API calls, and on CCL it's calling select() via FFI. Seems quite nice that there is a backend for each platform that provides an easy point to hack. Just vaguely wondering if there are git branches aro
<jdz>
It probably does not integrate too well with implementation's streams.
<lukego>
I've looked briefly at lev. Seems like USOCKET would be the simplest integration point for that? Since you can already access things like file descriptors there to bridge the domain between streams and system calls.
<jdz>
Yes, I totally agree. Just mentioning as another option.
<jdz>
I don't like extra dependencies, especially foreign ones.
<lukego>
That doesn't suit me because I want something portable. So the best option so far sounds like starting with usocket and hacking one or more backends to use libev.
beach has joined #lisp
<beach>
Good afternoon everyone!
thuffir has joined #lisp
<jdz>
lukego: Sure, distracting you from your plan was not my intention. Sorry for all the noise.
<beach>
lukego: Long time no see.
<lukego>
jdz: no this has been very helpful, thank you :)
ebzzry has left #lisp ["WeeChat 1.9.1"]
milanj_ has joined #lisp
<lukego>
Hello beach!
iqubic` has joined #lisp
<lukego>
beach: are you still in Bordeaux or did you end up sticking around in Vietnam? :)
<beach>
I am still in Bordeaux. Though, right now, I am in the airport in Amsterdam waiting for a flight home. What about you? Where are you these days?
iqubic has quit [Ping timeout: 260 seconds]
<lukego>
I'm nowadays in a little dairy farming village in the Swiss Alps with a wife, two small boys, and a jack russell. Change of pace :).
<beach>
Indeed. Congratulations!
makomo has quit [Ping timeout: 252 seconds]
<theemacsshibe[m]>
I somehow slipped into using closures a lot and it's great.
<lukego>
Thanks :).
megalography has joined #lisp
bbobb has quit [Quit: bbobb]
bbobb has joined #lisp
<beach>
Crap! My flight home is delayed (at least) 1.5 hours.
thuffir has quit [Ping timeout: 245 seconds]
megalography has quit [Ping timeout: 248 seconds]
<fe[nl]ix>
hi lukego :)
<sjl>
jackdaniel: wasn't aware of that particular one. serapeum has something similar, apparently so does arc
sellout has joined #lisp
thuffir has joined #lisp
<shrdlu68>
beach: The trials and tribulations of the 21st-century hominid.
pierpal has quit [Read error: Connection reset by peer]
<beach>
Yeah. Also known as first-world problems.
<shrdlu68>
At least we don't have to deal with predation risk, most of the time.
<beach>
Indeed.
<lukego>
Howdy fe[nl]ix! I was just thinking it would be awfully nice to use IOLib if I were a little less sensitive to portability at the moment :)
fikka has quit [Ping timeout: 260 seconds]
elfmacs has joined #lisp
sjl has quit [Quit: WeeChat 2.1]
BitPuffin has joined #lisp
sjl has joined #lisp
pierpal has joined #lisp
shrdlu68 has quit [Ping timeout: 248 seconds]
thuffir has quit [Ping timeout: 260 seconds]
shrdlu68 has joined #lisp
SenasOzys has quit [Ping timeout: 252 seconds]
aindilis has quit [Remote host closed the connection]
thuffir has joined #lisp
aindilis has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
fikka has joined #lisp
pierpal has joined #lisp
<Xach>
just a bit more polish and you can use slitch?
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
* jackdaniel
has in mind some jokes about polish-polish homonyms, probably bad ones though
MasouDa has joined #lisp
lukego has quit [Ping timeout: 260 seconds]
beach has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
oleeo has left #lisp [#lisp]
SenasOzys has joined #lisp
terpri has joined #lisp
fikka has joined #lisp
MasouDa has quit [Ping timeout: 256 seconds]
aindilis has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 245 seconds]
aindilis` has joined #lisp
beach has joined #lisp
aindilis` has quit [Remote host closed the connection]
MasouDa has joined #lisp
nika_ has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
makomo has joined #lisp
fikka has joined #lisp
beach has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
mindCrime has joined #lisp
alexistp has joined #lisp
light2yellow has joined #lisp
aindilis has joined #lisp
Bike has joined #lisp
<makomo>
any recommendations for stuff i might read to get an idea/understanding of environment objects?
orivej has joined #lisp
nowhere_man has joined #lisp
<nowhere_man>
Hi all
<nowhere_man>
I recently published a new draft of BULK, a binary format inspired by Erik Narggum's rant on XML
iqubic` has left #lisp ["ERC (IRC client for Emacs 25.3.1)"]
<Bike>
makomo: they're pretty undefined. you can pass them to functions that accept them and that's it. no accessors or anything.
<Colleen>
Bike: Kevslinger said 35 minutes, 21 seconds ago: Kevin has a linux question
<nowhere_man>
I'm wondering if the way I deal with definition is sensible, so anyone with an interest in PL theory and lexical scoping would be very welcome to criticize my work :-)
fikka has quit [Ping timeout: 260 seconds]
<makomo>
Bike: so the thing that CLTL2 says about them is just a proposed interface
<Bike>
yes.
<Bike>
some implementations kind of support it, but not entirely
megalography has joined #lisp
fikka has joined #lisp
TCZ has joined #lisp
warweasle has joined #lisp
pierpal has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 268 seconds]
pierpal has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
fikka has joined #lisp
TCZ has quit [Quit: Leaving]
<shrdlu68>
nowhere_man: How does this compare with ASN?
EvW1 has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
fikka has quit [Ping timeout: 264 seconds]
<nowhere_man>
I I understand ASN right, with ASN you define an inflexible ad hoc binary format with it
<nowhere_man>
no two ASN-defined formats are mutually-compatible
<nowhere_man>
BULK formats all are
<nowhere_man>
(which makes it possible for ASN to create a more compact format, I guess)
<shrdlu68>
What do you mean "inflexible"?
snits has quit [Quit: leaving]
<shrdlu68>
I don't understand the mutual compatibility thing either.
snits has joined #lisp
vtomole has joined #lisp
cage_ has joined #lisp
wheelsucker has joined #lisp
fikka has joined #lisp
__rumbler31 has joined #lisp
schjetne has quit [Quit: No Ping reply in 180 seconds.]
schjetne has joined #lisp
thuffir has quit [Ping timeout: 245 seconds]
matijja has quit [Ping timeout: 245 seconds]
fikka has quit [Ping timeout: 245 seconds]
fikka has joined #lisp
FreeBirdLjj has joined #lisp
scymtym has quit [Ping timeout: 245 seconds]
fikka has quit [Ping timeout: 252 seconds]
thuffir has joined #lisp
comborico1611 has joined #lisp
fikka has joined #lisp
oleo has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
BitPuffin has quit [Remote host closed the connection]
fikka has joined #lisp
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
kami has joined #lisp
<kami>
Hello #lisp
<oleo>
sup sup
<makomo>
hi
<dlowe>
how does BULK compare with protobufs and thrift?
MasouDa_ has joined #lisp
<nowhere_man>
dlowe: IIUC, like ASN, they define ad hoc formats, not mutually-compatible formats
MasouDa has quit [Ping timeout: 252 seconds]
<oleo>
hello
smurfrobot has quit [Remote host closed the connection]
<oleo>
how would i be able to tell what the current output-translations are ?
<oleo>
for asdf ?
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
<oleo>
ah got it
<oleo>
asdf:*output-translation-parameter*
<oleo>
asdf:*output-translations-parameter*
<oleo>
and asdf:*user-cache*
xaxaac has joined #lisp
DonVlad has joined #lisp
innovati has joined #lisp
flamebeard has quit []
BitPuffin has joined #lisp
<White_Flame>
nowhere_man: what's the actual use case for BULK? it seems awfully generic, and might not be much smaller in practice than a "minified" plain sexpr representation
thuffir has quit [Ping timeout: 245 seconds]
<White_Flame>
we have a generic binary protocol, which does lists, maps, numbers, UTF-8 strings, and a few other bits & bobs, that we use for encoding messages in a distributed system. We considered having a JSON serializer instead of dealing with our own. But converting our types to a JSON type, eg ["map", "key", "val", 123, "val", "123", "val"] or something of the like means that we first convert from our objects to JSON style lists/objects,
<White_Flame>
then from JSON to byte stream. That's much more cruft to drag around than just serializing to binary in the first place
fikka has quit [Ping timeout: 252 seconds]
<White_Flame>
also, generic formats aren't ever really "mutually compatible". The only thing you can do with XML and its ilk is to deserialize it. Your code has no idea how to work with it if it isn't of the node shapes that it expects
<White_Flame>
and in modern usage, XML/JSON/etc are bringing such immense loads of fine-grained details that they're not effectively human readable anyway
vtomole has quit [Quit: Page closed]
kmurphy4 has joined #lisp
thuffir has joined #lisp
shrdlu68 has quit [Ping timeout: 264 seconds]
vtomole has joined #lisp
fikka has joined #lisp
MasouDa has joined #lisp
<phoe>
White_Flame: take into account that "human-readable" does not mean "not complex"
MasouDa_ has quit [Ping timeout: 248 seconds]
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
<phoe>
theoretically all macroexpansions are human-readable, even in case of LOOP or TRIVIA/OPTIMA patternmatching stuff.
fikka has quit [Ping timeout: 268 seconds]
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrob_ has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
vtomole has quit [Ping timeout: 260 seconds]
smurfrobot has joined #lisp
fikka has joined #lisp
<nowhere_man>
White_Flame: the goal is to provide a framework for formats like file archives, images, XML documents, with compactness and decentralization
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
lumm has joined #lisp
<nowhere_man>
the decentralization part needs some semantics that do beyong just binary sexpr
<White_Flame>
phoe: right, same thing. The _use_ of data formats means they're no longer effectively human friendly anymore
smurfrobot has joined #lisp
smurfrob_ has quit [Read error: Connection reset by peer]
smurfrobot has quit [Read error: Connection reset by peer]
elfmacs has quit [Ping timeout: 245 seconds]
smurfrobot has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
vlatkoB has quit [Remote host closed the connection]
smurfrob_ has joined #lisp
vlatkoB has joined #lisp
<White_Flame>
nowhere_man: effectively, would you say that it basically allows you to build an ASN-style packed binary format with a format declaration specifier included?
smurfro__ has joined #lisp
fikka has joined #lisp
smurfr___ has joined #lisp
smurfrobot has quit [Ping timeout: 260 seconds]
smurfr___ has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrob_ has quit [Ping timeout: 252 seconds]
smurfro__ has quit [Read error: Connection reset by peer]
smurfrobot has quit [Remote host closed the connection]
cage_ has quit [Ping timeout: 245 seconds]
fikka has quit [Ping timeout: 260 seconds]
comborico1611 has quit [Quit: comborico1611]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
thuffir has quit [Remote host closed the connection]
cage_ has joined #lisp
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
fikka has joined #lisp
smurfrob_ has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
asarch has joined #lisp
<nowhere_man>
White_Flame: somewhat, yes
<nowhere_man>
you can always parse a BULK stream without prior knowledge
smurfrobot has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 248 seconds]
smurfrobot has joined #lisp
<nowhere_man>
and if you know a BULK image vocabulary and you parse a BULK stream that is such an image with a metadata vocabulary in it that you don't know, you'll still get the image
smurfrob_ has joined #lisp
_cosmonaut_ has quit [Ping timeout: 245 seconds]
smurfrob_ has quit [Read error: Connection reset by peer]
smurfro__ has joined #lisp
smurfrobot has quit [Ping timeout: 260 seconds]
smurfro__ has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrob_ has joined #lisp
EvW1 has quit [Ping timeout: 245 seconds]
smurfrob_ has quit [Read error: Connection reset by peer]
smurfrob_ has joined #lisp
<dlowe>
it seems like the primary innovation here is the namespace with a guid. Is that reasonable?
smurfrobot has quit [Ping timeout: 260 seconds]
smurfrobot has joined #lisp
<dlowe>
from my experience with protobufs, there are rather huge wins involved if you have a partially-parseable format that is uniformly used everywhere
<oleo>
what happens when you unbind a binding in a lexical env say let
smurfrob_ has quit [Read error: Connection reset by peer]
<oleo>
global-variable here -> subscope-where-it-gets-unbound-> reswitch to the surrounding env
<White_Flame>
(let ((*global-var* nil)) ..call stuff that has use of that var scoped)
<oleo>
s/env/scope/
<White_Flame>
or (let ((*global-var* *global-var*)) ...) if you want to pass through the existing value
<White_Flame>
I do a lot of this sort of thing in thread pooling. Load up a bunch of dynamic bindings like that for the current context, and let some job rip
<oleo>
well i have a problem with maxima
<oleo>
i looked at the code today and was wondering why output-translations were deleted for it
<oleo>
and it seems it does that for some reason only for sbcl and asdf version 2
<oleo>
what is done there is (push 'asdf:clear-configuration *save-hooks*)
<oleo>
that means while maxima gets built my output-translations are gone, that's fine so far
hhdave has quit [Ping timeout: 252 seconds]
<oleo>
but i'm loading an asdf system which calls the maxima compilation, and after maxima compiles it looses cause the output-translations are gone
igemnace has quit [Remote host closed the connection]
<oleo>
and it doesn't matter obviously if i upgraded to version 3 of asdf on the go....
MasouDa has quit [Ping timeout: 260 seconds]
pjb has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
scymtym has joined #lisp
nowhere_man has joined #lisp
<oleo>
so thread1->thread2->thread1
<oleo>
thread2 is maxima compilation, but that phase deletes a global needed value, afaiu
pierpal has joined #lisp
<oleo>
i have to think more about that somehow......
<oleo>
not sure how to proceed
schweers has quit [Ping timeout: 245 seconds]
kami has quit [Ping timeout: 245 seconds]
puchacz has joined #lisp
<oleo>
having saved the output-translations to *init-hooks* wouldn't work either in that case i think
<oleo>
cause it's not restarting a new instance of sbcl upon return from thread2
kmurphy4 has quit [Quit: Leaving]
dacoda has joined #lisp
<oleo>
that stuff was thought for pure maxima toplevel compilation, not some environment around it
tcr has joined #lisp
dkrm has joined #lisp
SenasOzys has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 240 seconds]
SenasOzys has joined #lisp
smurfrobot has quit [Remote host closed the connection]
nowhere_man has quit [Remote host closed the connection]
smurfrobot has joined #lisp
nowhere_man has joined #lisp
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
jmercouris has joined #lisp
fikka has joined #lisp
<jmercouris>
Hey everyone, I made some really simple survey software in Lisp if anyone is interested in using it /building off of it: https://github.com/atlas-engineer/survey
<jmercouris>
it is pretty cool because you can make http requests with XML bodies to the service to dynamically create surveys
smurfrob_ has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
markong has quit [Ping timeout: 245 seconds]
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
<White_Flame>
why XML and not sexpr?
<oleo>
survey question numero un: "do you think you are you?!"
<oleo>
lol
margeas has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
<jmercouris>
White_Flame: I figured XML is more universal
<jmercouris>
White_Flame: I'm toying with the idea of expanding this into a platform like DISQUS where it is open source, and you can run your own service, or you can use mine
cage_ has quit [Remote host closed the connection]
cage_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
<jmercouris>
White_Flame: anyways, this software was actually developed to answer the question that we talked about earlier, is there a demand for a service to group the packages/ship them cheaper
smurfrobot has joined #lisp
<White_Flame>
that would be good to know
smurfrobot has quit [Read error: Connection reset by peer]
<jmercouris>
having said all of this, making it work with sexpr wouldn't be a huge leap in logic, the xml is already transformed via s-xml:parse-xml-string
smurfrobot has joined #lisp
<jmercouris>
s/transformed/interpreted
<White_Flame>
or JSON-in, JSON-out
<jmercouris>
yeah or that, I guess the input data can be abstracted
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
<jmercouris>
anyways, not a super huge priority right now, for now I just plan to use the tool
puchacz has quit [Quit: Konversation terminated!]
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
margeas has quit [Ping timeout: 256 seconds]
energizer has joined #lisp
markong has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
m00natic has quit [Remote host closed the connection]
cage_ has quit [Read error: Connection reset by peer]
Trystam has joined #lisp
Trystam has quit [Remote host closed the connection]
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
mflem has joined #lisp
cage_ has joined #lisp
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
Tristam has quit [Remote host closed the connection]
smurfrobot has joined #lisp
puchacz has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
alexistp has quit [Remote host closed the connection]
smurfrobot has quit [Read error: Connection reset by peer]
smurfro__ has joined #lisp
smurfrob_ has quit [Ping timeout: 245 seconds]
Tristam has joined #lisp
smurfro__ has quit [Remote host closed the connection]
smurfrobot has joined #lisp
nika_ has quit [Quit: Leaving...]
sz0 has joined #lisp
Khisanth has quit [Ping timeout: 260 seconds]
Tristam has quit [Remote host closed the connection]
BitPuffin has quit [Remote host closed the connection]
Tristam has joined #lisp
karswell has quit [Read error: Connection reset by peer]
karswell has joined #lisp
MasouDa has joined #lisp
smurfrobot has quit [Remote host closed the connection]
eschatologist has quit [Ping timeout: 276 seconds]
eschatologist has joined #lisp
smurfrobot has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
rumbler31 has quit [Ping timeout: 245 seconds]
Khisanth has joined #lisp
rumbler31 has joined #lisp
alexistp has joined #lisp
<aeth>
White_Flame: I've brought this up in the past, but I don't like any current JSON library that I'm aware of
<aeth>
They mostly seem to be designed to make lisp <-> json hard.
<aeth>
I think XML is probably a better choice from a Lisp perspective.
<aeth>
I guess JSON and YAML support are probably on the weaker side for Lisp compared to comparable languages because with a lot of the use cases people just use s-expressions as data
pierpal has quit [Quit: Poof]
mathrick has quit [Ping timeout: 268 seconds]
pierpal has joined #lisp
alexistp has quit [Read error: Connection reset by peer]
alexistp has joined #lisp
beach has joined #lisp
pierpal has quit [Ping timeout: 245 seconds]
<White_Flame>
aeth: one of the biggest problems is true/false/null/[]
<White_Flame>
and that muddles with lisp-side representation choices
<aeth>
White_Flame: You can solve that by not allowing bare lists. When decoding, simply tag it with an extra cons like e.g. [] => '(json-array)
<flip214>
I'd like to have a set of functions give the caller notice of some conditions, and thought I'd just (THROW :no-filter-found nil) and CATCH that (as NIL already means "no data").
<aeth>
And require the same thing when encoding because otherwise you can't disambiguate between lists-as-sequences and lists-as-alists/plists
<White_Flame>
right, and that goes down the territory of "seem to be designed to make lisp <-> json hard" ;)
<flip214>
but a simple (CATCH ...) doesn't allow me to return something different, does it?
<White_Flame>
CATCH will act like a PROGN on normal return, and return the respective THROWn value otherwise
<flip214>
I'd have to (BLOCK nil (CATCH :no-filter-found (return (some-function))) (code-for-no-filter))
<aeth>
(list 1 2 3) => error; (list 'json-array 1 2 3) => [1, 2, 3]; (list 'plist :foo 42) => {"foo" : 42} or {"FOO" : 42} depending on settings and/or print-case. Default for symbols to JSON strings probably should be to :upcase into CL and :downcase into JSON strings, although obviously that won't work for arbitrary JSON, where case sensitivity might matter.
<flip214>
and that RETURN in there hurts my aesthetics...
<aeth>
Probably should allow any arbitrary function, e.g. cffi:translate-camelcase-name
<flip214>
White_Flame: so I'd still have to bind the result and check that against EQuality of some keywords?
<White_Flame>
depends on what you're throwing
<flip214>
currently I just return :no-filter-found and check for that - once.
<White_Flame>
and what the normal return case is
<White_Flame>
would nil/non-nill suffice?
<flip214>
White_Flame: no. NIL means "no data".
<aeth>
White_Flame: But lisp <-> json can't be perfect because you'd have to decide on the default for json -> lisp. I'd choose json array to Lisp vector (not list!) and json object to hash table (not plist or alist!) as the default, personally. Closest semantic match. But json objects are also equally valid as plists, alists, structs, and CLOS objects and json arrays could also be lists.
<flip214>
White_Flame: that means that I have to pass :no-filter-found at least three times - in the THROW, in the CATCH, and in a CASE clause. that doesn't feel so nice.
sauvin has quit [Remote host closed the connection]
<aeth>
flip214: macro
<White_Flame>
aeth: yeah, I know. I've dealt with a lot of that. I was just reinforcing that anything you come up with equals your assessment of "seems to be designed to make lisp <-> json hard"
<White_Flame>
flip214: what other values are there?
<flip214>
White_Flame: currently the "main" return value is a list of records - or NIL for "no records".
<White_Flame>
also, the catch doesn't need the value thrown, only the tag
<White_Flame>
so the tag is in throw/catch, the value is in throw/case
_death has left #lisp ["ERC (IRC client for Emacs 27.0.50)"]
<flip214>
White_Flame: you've had :no-filter-found in the CASE as well!
<flip214>
as I said, 3 times.
<White_Flame>
that's because I thought it was the value you wanted to return
<White_Flame>
maybe you'd be better served with handler-case
<flip214>
from the inner function - yes. the outer one needs to catch that [sic ;] and replace with another data set.
<aeth>
White_Flame: I guess the solution is probably more JSON (no comments!) as metadata that could be used to override (library or program) default choices and allow for a round trip even when e.g. a struct and a CLOS object are both serialized.
<flip214>
well, currently I'm just _directly_ returning :no-filter-found - and check for that, so the keywords is only used two times.
eschatologist has quit [Ping timeout: 252 seconds]
<White_Flame>
or the inner function should just return the replacement set instead of a tag indicating the replacement set should be used
MichaelRaskin has joined #lisp
<flip214>
but it felt so clean to THROW the special CONDITION...
<White_Flame>
or use multiple values like GETHASH
<flip214>
White_Flame: the thing is, there is not _one_ inner function - it's a set of methods, and I don't want each to have to know the default.
<flip214>
yeah, I was pondering that too
<flip214>
perhaps that would be better still - either return data, or (values NIL :no-filter-found) etc.
<White_Flame>
(values nil t) would suffice. It's a boolean, right?
<White_Flame>
are there other values for that flag?
orivej has quit [Ping timeout: 240 seconds]
<White_Flame>
the value is only special if it's intermixed with other things. If you have a set-aside value slot for it, it need only be boolean
<flip214>
White_Flame: there may be, in the future.
<flip214>
don't know yet.
<flip214>
so right now I could simply pass :no-filter-found and treat that as a generalized boolean.
<White_Flame>
also, why CATCH instead of just returning a keyword in the first place?
<White_Flame>
does it need to abort from inside the body?
<White_Flame>
then (if (listp ...) ...) would distinguish your return values
<flip214>
White_Flame: yeah, that's about what I'm doing right now.
<flip214>
as I said, THROWing a special CONDITION seemed like an appropriate use -- I don't use them that often ;)
<flip214>
thanks for all the help, anyway!
<White_Flame>
you're not throwing a "condition" in CL-speak though
<White_Flame>
unless you're actually manifesting a condition object
<eschulte_>
is there an easy way to search quicklisp for all packages which use a particular package?
<flip214>
well, it's a nonlocal transfer of the control flow - I put that in the same box as conditions.
<aeth>
White_Flame: except with undefined behavior
* White_Flame
undefines aeth ;)
pjb has quit [Read error: Connection reset by peer]
<flip214>
eschulte_: does (defgeneric dependency-tree (system)) help?
<flip214>
eschulte_: or you want (who-depends-on)
<flip214>
not sure whether that works recursively, though
eschatologist has joined #lisp
karlosz has joined #lisp
<flip214>
thank you!
<eschulte_>
I'd like to supply a system name and get back a list of every system in quicklisp which :depends-on that system. Just first-level (non-transitive) dependencies would be fine.
<flip214>
eschulte_: try (who-depends-on)
<eschulte_>
flip214: oh, perfect, thanks
dieggsy has joined #lisp
SenasOzys has quit [Ping timeout: 252 seconds]
pierpal has joined #lisp
pierpal has quit [Ping timeout: 252 seconds]
pierpal has joined #lisp
mathrick has joined #lisp
rumbler31 has quit [Ping timeout: 245 seconds]
nickenchuggets has joined #lisp
nickenchuggets has joined #lisp
nickenchuggets has quit [Changing host]
pierpal has quit [Read error: Connection reset by peer]
python476 has joined #lisp
orivej has joined #lisp
ebrasca has left #lisp ["ERC (IRC client for Emacs 25.2.1)"]
MasouDa_ has joined #lisp
isBEKaml has joined #lisp
MasouDa has quit [Ping timeout: 245 seconds]
SenasOzys has joined #lisp
pierpal has joined #lisp
SenasOzys has quit [Remote host closed the connection]
milanj_ has quit [Quit: This computer has gone to sleep]
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
<oleo>
so to be thread-local one has to create the bindings....
fikka has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
shka_ has quit [Ping timeout: 256 seconds]
smurfrobot has joined #lisp
asarch has quit [Quit: Leaving]
<mfiano>
Considering threads are not part of the standard, it is undefined behavior whether they will be thread-local or not.
<oleo>
will there be a new spec soon ?
milanj_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
varjagg has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
<pierpal>
no
fikka has joined #lisp
<aeth>
You'd not only need to pay for it, you'd first have to convince the majority of the community decision makers that it's necessary. The easiest way would probably be to hire as many as possible.
<aeth>
You could probably get away with just getting the developers of SBCL, CCL, and ECL on board.
<Bike>
it's not undefined, it's just defined by bt
pierpal has quit [Quit: Poof]
<aeth>
But you'd probably also want the Clasp and SICL developers, too.
<oleo>
err, the previous spec makers didn't gather together because of payment i suppose
smurfrobot has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
smurfrob_ has joined #lisp
<oleo>
or ?
<oleo>
lol
<aeth>
oleo: How many of the people involved in the CL spec were employed by companies that used CL commercially? How many such companies exist today?
Mutex7 has joined #lisp
cage_ has quit [Quit: Leaving]
smurfrobot has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
smurfrobot has joined #lisp
comborico1611 has joined #lisp
smurfrob_ has quit [Ping timeout: 256 seconds]
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
<jmercouris>
I wish the spec would advance in backwards compatible ways
<jmercouris>
like it would be nice if threads were considered part of it
<jmercouris>
I guess it doesn't really matter so much since bt threads exists
<aeth>
The main thing that would have to be worked on in a spec would probably be the type system.
<jmercouris>
yeah, probably
smurfrob_ has quit [Read error: Connection reset by peer]
<jmercouris>
I see a lot of complaints about that
smurfrobot has joined #lisp
<aeth>
One simple example: make SBCL's gradual-typing-via-declare the standard, expected behavior. It's already assumed in a bunch of places. No need for syntax changes. Macros can create more convenient syntax.
<dlowe>
it'd also be nice if there were a standard scheduler
<jmercouris>
has anyone else noticed a downturn in activity since ELS? did something happen?
<jackdaniel>
yes, we have moved to #lisp-secret-channel ;-)
<aeth>
all of the people involved in CL implementations go to #anti-standards-committee where they plot about ways to prevent CL's standard from getting an update
<jmercouris>
jackdaniel: are you being serious?
<jmercouris>
jackdaniel: why didn't you call it #lisp-cabal?
<White_Flame>
there's CL2.1. all it takes for there to be a standard is for somebody to write it up, and others to use it
<White_Flame>
so obviously it's best when there's concensus, like the lisp industry getting together to create Common Lisp
mindCrime has quit [Ping timeout: 252 seconds]
<jmercouris>
True, but standards without some powerful leader behind them are just documents
<aeth>
White_Flame: All it takes for there to be a standard is SBCL, CCL, and ECL agreeing on something.
<aeth>
At least until there's another popular FOSS implementation.
<jmercouris>
getting lisp programmers to agree on anything is like herding cats
<White_Flame>
yep, and in many ways that's how CL formed in the first place: consolidating existing "ad hoc" features that were popular
<jackdaniel>
to agree and to have time to implement agreed *thingey* are two different things
<jmercouris>
I think what would be best would be an extension of the language in the form of macros
<jmercouris>
these things wouldn't require duplicated implementation efforts
<dlowe>
standards without government, corporate, or academic support are just paper.
<MichaelRaskin>
Well, there is a reserve of implemented things where agreeing on naming is almost equal to implementing
<jmercouris>
so it's just increasing the standard lib, so to speak
<jackdaniel>
things which doesn't require implementation support (as in: writing macros) would be hard to justify as part of the standard
<jackdaniel>
since they may be implemented as a library
mathrick has quit [Ping timeout: 260 seconds]
<jackdaniel>
consolidating some features is another story: i.e agree on common interface to semaphores, or threads (in fact: agree on something what portability layers try to unify)
<White_Flame>
jmercouris: well, the "standard lib" is defined by the cl spec
<White_Flame>
I often liken this part to C (at least pre modern updates), where the language is small, but the industry has standardized on popular libraries
<aeth>
One easy thing to do in an upcoming spec would be to bump the minimums. Some docstrings are probably non-portable because array-total-size-limit (the maximum size of an array, including a string) has a minimum at 1024
<aeth>
Probably the way to do it would be to define minimums for 32-bit implementations and minimums for 64-bit implementations, and a way to detect which minimum the implementation is following.
<White_Flame>
one would think that a way to detect the limits would be... array-total-size-limit
<White_Flame>
not sure detecting the minimum would be super useful
<aeth>
A harder, but related, thing would be to *lower* a minimum. short-float cannot be IEEE half-precision floating point. The minimum precision is too high (13 instead of 11).
MasouDa_ has joined #lisp
mindCrime has joined #lisp
DonVlad has quit [Remote host closed the connection]
<aeth>
long float is probably still too uncommon to specify concretely. Do people want it to be quad float? 80-bit extended-precision? arbitrary precision?
sjl has quit [Ping timeout: 252 seconds]
<aeth>
or just double?
MasouDa has quit [Ping timeout: 245 seconds]
<aeth>
(I'm sure some people's code would break if SBCL added a long-float because pi is long-float, not double-float!)
<White_Flame>
we need infinite-float for pi
DonVlad has joined #lisp
<Xach>
The new power supply in the quicklisp build hardware did not help :(
<White_Flame>
it would be nice to compile all the complaints people have about the current lisp spec
dacoda has quit [Quit: ERC (IRC client for Emacs 25.3.1)]
<White_Flame>
obviously there are issues raised & recorded in the spec itself
<White_Flame>
but there's been 30+ years of history since then
eschatologist has quit [Ping timeout: 276 seconds]
<dlowe>
That's kinda what the CDR was supposed to be.
<aeth>
Characters (we can be more specific these days), paths (same thing), type system, more sequences (extensible sequences?), threads, maybe networking, possibly typed arrays/hash-tables/lists/etc. (lists are the only trivial one to implement yourself, but even then only your code would know your way)
<dlowe>
all you have to do is get implementations to follow it and you win
mathrick has joined #lisp
<aeth>
Oh, and various functional programming things that you could technically do by writing a language in Lisp that compiles to Lisp and isn't compatible with anything anyone else uses either.
<aeth>
Lisp isn't particularly FP by today's standards even though it was by the standards of 25+ years ago.
innovati has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<jmercouris>
jackdaniel: lots of things in the standard are macros though
innovati has joined #lisp
eschatologist has joined #lisp
<aeth>
jmercouris: If the standard were written today, dotimes wouldn't make it
<jackdaniel>
you miss the point, but I'm too busy with talking on #lisp-secret-room to explain myself :p time for sleep, good night
<edgar-rft>
let's include in the new standard infinite hardware power for Xach
<aeth>
Make Quicklisp part of the standard!
<White_Flame>
should a new CL deprecate symbol property lists?
DonVlad has quit []
<aeth>
Considering a new standard would be a once-every-30-year event, I don't think deprecation would mean much
manualcrank has joined #lisp
<White_Flame>
fine, then should it eliminate them? ;)
<aeth>
Can't remove anything, not even the currently-deprecated stuff, since people used them assuming they wouldn't be removed
<White_Flame>
I've only ever seen them used in ancient lisp code
* edgar-rft
is deprecated since birth
<aeth>
I've only seen prog in ancient lisp code but someone probably generates it with a macro somewhere in Quicklisp instead of using tagbody for some reason.
<mfiano>
I'd be happy with just threads, Unicode, PLN, and extensible sequences being added
<aeth>
mfiano: definitely unicode because there isn't even (afaik) a major unicode portability library
<mfiano>
PLN is the big one in my opinion. As the CL ecosystem grows, and in certain cases where it makes sense to have short package names/nicknames, transitive dependencies colliding out of a user's control except only their choice of direct dependencies is a huge problem.
<White_Flame>
yeah, I fully agree
<White_Flame>
the flat package namespace isn't scalable
<aeth>
White_Flame: The solution is... metapackages
<aeth>
Packages for packages.
vlatkoB has quit [Remote host closed the connection]
kushal has quit [Ping timeout: 250 seconds]
<White_Flame>
well, with PLN, in theory nesting comes for free
<White_Flame>
as long as reader syntax is extended to support it
<White_Flame>
not actually technically nesting, but traversal along locally named links
FreeBirdLjj has quit [Remote host closed the connection]
<aeth>
Oh, forcing specific optimizations would be nice. (declare (optimize (tco t))) and if the compiler recognizes tco it's enabled.
<aeth>
I have a feeling that a lot of people want that. Just for TCO.
<aeth>
You'd probably need some extra debug thing to override it, though.
kushal has joined #lisp
<White_Flame>
yeah, I've fiddled with SBCL internals to enable it while debug & safety are high, so the stack doesn't blow during testing
<mfiano>
defpackage-plus has in my opinion a very bad hack to support package-local nicknames in a way that gracefully falls back to global nicknames if an implementation doesn't support it. This is very wrong. At best, which an implementation supports them, you have non-portable code. At worst, you silently have global nicknames. It's not a "pure" solution.
<mfiano>
s/non-portable/non-conforming/
<aeth>
Oh, I almost forgot. The next CL standard should sneak in a full implementation of Prolog as well. Put it in an appendix as a mandatory thing. Or maybe a long footnote.
<mfiano>
I consider that worse than just using global nicknames, because you don't know how it will behave from a user standpoint.
<nirved>
isn't it easier to put a layer on top of CL instead of redefining the language?
<mfiano>
You just described every implementation
<aeth>
nirved: I'm trying to specifically talk about things where a layer wouldn't be too useful.
<aeth>
You can implement anything in any turing complete language, but not necessarily efficiently.
<nirved>
imo implementing a custom language on top of CL is quite easy and efficient
sjl has joined #lisp
sjl has quit [Client Quit]
<aeth>
yes, the Prolog was a joke, but actually apparently there are some things an implementation must do in order to coexist with Prolog. iirc dmiles was talking about that a while ago
sjl has joined #lisp
<aeth>
the latter would be more of an idea to specify as an extension or something, not actually all of Prolog
<aeth>
Perhaps the future of a CL environment is as a runtime for many languages. Then there'd be lots of interesting things that could be added.
<nirved>
if necessary CL can spit out machine code as well, and with CL writing a compiler is relatively easy
<White_Flame>
nirved: that would be more in the realm of creating a new language separate from CL, not necessarily modifying/extending CL itself
<White_Flame>
as at that level, you're working with individual implementation specifics, not anything CL-specified
<aeth>
nirved: afaik the define-vop thing is just SBCL
<aeth>
But there are already lots of constructs in CL that don't really make sense to directly use, like tagbody
<White_Flame>
and if CL wants to be a modern runtime, it really needs feedback-based recompilation in my opinion
<aeth>
Lisp is a language for languages.
<aeth>
White_Flame: you might be able to do that
<White_Flame>
yes, a new CL implementation could do that and stay in spec
<White_Flame>
just nothing has done so so far
rumbler31 has quit [Read error: Connection reset by peer]
<aeth>
You might be able to get enough meaningful feedback in a DSL to recompile those DSL functions at runtime, if that's what you mean.
<aeth>
Obviously not CL itself, though
rumbler31 has joined #lisp
<White_Flame>
I mean CL itself
tcr has quit [Ping timeout: 260 seconds]
<aeth>
It would be interesting to do that only for generics
<White_Flame>
right, that sort of architecture would allow making the base langauge more generic, while still finding location-specific speed decisions
<White_Flame>
and "generics" also include things like #'+
<White_Flame>
and sequence operations
<aeth>
not sure how you'd do this without first (1) making the MOP standard and then (2) also making what you're talking about standard
<aeth>
Sequence and numeric generics are... special
<White_Flame>
it would have to be a fully new implementation
<mfiano>
Sounds like Julia
mindCrime has quit [Ping timeout: 256 seconds]
<aeth>
It would be nice if something like specialization-store wasn't necessary for when you wanted generics for e.g. (simple-array single-float (3))s
<jmercouris>
White_Flame: what is feedback based recompilation?
<White_Flame>
it's how the JVM and javascript can run code so fast
foom has quit [Ping timeout: 260 seconds]
<jmercouris>
yeah, but what is it?
<White_Flame>
track how many times various types run through the code paths
<jmercouris>
Oh I see
<jmercouris>
and then so like "run-time" optimization?
<White_Flame>
recompile your code to inline the type decisions that actually occurred the most
<jmercouris>
sounds extremely complex
<White_Flame>
including the ability to inline virtual function calls
jeosol has joined #lisp
<White_Flame>
for instance, (mapc (lambda (x) ...) list) is unrolled in SBCL to a plain loop, instead of literally calling that function every iteration
<White_Flame>
because that's all known at compile time
<White_Flame>
but (mapc #'some-other-function list) couldn't be inlined, because that function might be redefined, or be passed in as a variable, or whatever
<White_Flame>
in theory, if the code notices that the same function is always given to that mapc, it could be recompiled to a loop with that function inlined
<jmercouris>
but could you depend on that?
<jmercouris>
you just said it above yourself
<jmercouris>
that function might be redfined
<White_Flame>
such languages tend to have a "warm up" period
<White_Flame>
as the system discovers where it's slow and tries to work on those places
<White_Flame>
s/languages/environments/
<White_Flame>
the functionality should be maintained throughout its optimization; only the speed should be affected
<White_Flame>
(else it's a bug)
<White_Flame>
also, if the invariant that was optimized is violate (ie, you pass in a different function than what was inlined) then it either undoes that optimization or run a separate fallback "slow path" for the more generic case
<White_Flame>
*violated
<White_Flame>
you can see how it would increase the speed of math operations, and do things like flip from baked-in fixnum to bignum processing automagically
<White_Flame>
without declaring any types ahead of time
<White_Flame>
I'm not a fan of Java, and only somewhat of JavaScript, but man I respect the tech they've put in those VMs
dvdmuckle has quit [Quit: Bouncer Surgery]
dvdmuckle has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
hhdave has joined #lisp
pierpa has joined #lisp
foom has joined #lisp
pierpal has quit [Ping timeout: 264 seconds]
hhdave has quit [Read error: Connection reset by peer]
kmurphy4 has joined #lisp
alexistp has quit [Remote host closed the connection]
hhdave has joined #lisp
katco has quit [Ping timeout: 252 seconds]
Guest6374 has quit [Remote host closed the connection]
<comborico1611>
I just learned what setf stands for.
<comborico1611>
Why is "form" also used, and not just "expression". "Expression" does predate "form", correct?
megalography has quit [Quit: Leaving.]
<White_Flame>
(setf (car foo) 3)
<White_Flame>
it doesn't evaluate (car foo) first as an expression, it dispatches on the form (car ???)
<White_Flame>
if foo was (1 . 2), then evaluating the experession would yield (setf 1 3) which doesn't make sense