sdumi has quit [Remote host closed the connection]
sdumi has joined #lisp
hendursaga has joined #lisp
bilegeek has quit [Quit: Leaving]
<mfiano>
Speaking of compiler macros, I don't remember the last time I needed to write one, but I have a question related to them: Do I have to gensym when introducing a new lexical variable as part of its expansion to prevent unwanted capture in the same case as for regular macros?
judson_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<lotuseater>
I would say so, but also didn't need them yet so much
<lotuseater>
I would use them extensively for programming mathematical identities
igemnace has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
Kundry_W_ has quit [Ping timeout: 260 seconds]
kaftejiman_ has quit [Remote host closed the connection]
aeth_ has joined #lisp
aeth has quit [Disconnected by services]
aeth_ is now known as aeth
bitmapper has quit [Quit: Connection closed for inactivity]
sdumi has quit [Ping timeout: 240 seconds]
hlisp has joined #lisp
ex_nihilo has joined #lisp
hlisp has quit [Ping timeout: 264 seconds]
judson_ has joined #lisp
Inline has quit [Ping timeout: 272 seconds]
ex_nihilo has quit [Quit: Leaving]
hlisp has joined #lisp
ex_nihilo has joined #lisp
froggey has quit [Ping timeout: 260 seconds]
msk has quit [Remote host closed the connection]
msk has joined #lisp
msk has quit [Max SendQ exceeded]
msk has joined #lisp
msk has quit [Max SendQ exceeded]
msk has joined #lisp
msk has quit [Max SendQ exceeded]
msk has joined #lisp
msk has quit [Max SendQ exceeded]
hlisp has quit [Ping timeout: 256 seconds]
andreyorst has quit [Quit: WeeChat 2.9]
andreyorst has joined #lisp
jello_pudding has quit [Ping timeout: 264 seconds]
Kundry_Wag has joined #lisp
jello_pudding has joined #lisp
green_ has quit [Ping timeout: 260 seconds]
green_ has joined #lisp
Kundry_Wag has quit [Ping timeout: 240 seconds]
drl has quit [Quit: Leaving]
Lord_of_Life has joined #lisp
Lord_of_Life_ has quit [Ping timeout: 240 seconds]
galex-713 has quit [Ping timeout: 260 seconds]
galex-713 has joined #lisp
lotuseater has quit [Remote host closed the connection]
<fiddlerwoaroof>
Just got that when I tried to setup quicklisp
<fiddlerwoaroof>
(CCL)
<aeth>
have you tried SBCL?
<fiddlerwoaroof>
Yeah
<aeth>
does it work?
<fiddlerwoaroof>
mmap: Cannot allocate memory / ensure_space: failed to validate 1073741824 bytes at 0x1000000000
<fiddlerwoaroof>
I assume ABCL works
<fiddlerwoaroof>
And ECL, probably?
<no-defun-allowed>
aeth: A funny coincedence, while I'm reading about how refcounting is faster on a M1 processor.
<no-defun-allowed>
It takes 6.5ns to create and free a NSObject on M1/Objective-C, and 6.7ns to create and eventually free a standard-object on x86-64/SBCL. That's a 3% performance increase; something you'd expect from Intel marketing these days :)
<no-defun-allowed>
fiddlerwoaroof: Seriously though, do you find it any faster? Most articles I find say it's much faster than an Intel MacBook.
gxt has quit [Remote host closed the connection]
gxt has joined #lisp
judson_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aeth>
no-defun-allowed: that's not a high bar...
gproto023 has joined #lisp
theemacsshibe has joined #lisp
gproto23 has quit [Ping timeout: 256 seconds]
<theemacsshibe>
aeth: It doesn't have to be; we're comparing one Apple laptop to another.
<fiddlerwoaroof>
I haven't used it enough to really tell
<fiddlerwoaroof>
The battery life is the most significant difference so far
<fiddlerwoaroof>
And, things like being able to use iOS Slack instead of whatever
<theemacsshibe>
I see.
<oni-on-ion>
iOS on M1?
<aeth>
oni-on-ion: Apple is migrating to ARM because (1) its ARM chips are competitive with Intel's x86-64 chips and (2) Apple wants to eventually merge macOS (a cost) with iOS (where all of their profit is)
<aeth>
Not surprisingly, niche languages aren't emulated well in the transition
<aeth>
They probably use different instructions than LLVM does
<theemacsshibe>
Do "they" have to port a JVM to AArch64/macOS then?
<fiddlerwoaroof>
Well, it's a bit more complex than that aeth
<fiddlerwoaroof>
Apple's software all runs on the Objective-C VM (more or less)
<aeth>
theemacsshibe: who knows?
<fiddlerwoaroof>
for macOS 11, they've made the iOS frameworks available on normal computers
<aeth>
on the one hand, JVM would also be hard to emulate; on the other, there might actually be Java apps on macOS worth emulating
<theemacsshibe>
An interesting headline: "Microsoft contributes to Java port for Apple silicon Macs"
<aeth>
fiddlerwoaroof: Yes, a disturbing trend. iOS is the world's most popular locked-down platform.
<fiddlerwoaroof>
I think this is actually good news for iOS
<fiddlerwoaroof>
It's better than the Android trajectory
<fiddlerwoaroof>
Rosetta isn't exactly emulation
<fiddlerwoaroof>
It's a combination of a JIT and dynamic binary translation
<oni-on-ion>
aeth, yeah i know that stuff .
<oni-on-ion>
fiddlerwoaroof, ahh, cool !
<aeth>
fiddlerwoaroof: maybe it's good news for iOS, but it's bad news for macOS, and I'm not looking forward to getting bug reports from Mac users.
<fiddlerwoaroof>
I don't know
<oni-on-ion>
technically iOS users if accurate simu/emu
<fiddlerwoaroof>
Apple's always been a pain to support :)
<fiddlerwoaroof>
Especially if you don't have Apple hardware
gproto023 has quit [Remote host closed the connection]
gproto023 has joined #lisp
<aeth>
no, there was a good 5 or so years when it was basically just an odd x86-64 BSD
<fiddlerwoaroof>
So far, there's always been a workaround
toorevitimirp has quit [Remote host closed the connection]
<fiddlerwoaroof>
And, the basic path is straightforward: sign the sbcl executable and always launch your app through that executable
mbomba has joined #lisp
saganman has quit [Read error: Connection reset by peer]
frost-lab has joined #lisp
theemacsshibe has quit [Quit: /me hangs up]
<oni-on-ion>
put the core in the .app folder
<fiddlerwoaroof>
Yeah, the .app stuff is really cool on macos, and trivial to use from lisp
<aeth>
That's basically saying to avoid save-lisp-and-die exporting even if you do that on every other platform.
<oni-on-ion>
NeXT brought a lot of nice tech into the world
<fiddlerwoaroof>
Yeah, although I've started just doing fasls in docker containers
<fiddlerwoaroof>
The objective-c runtime as a whole is a much nicer thing to interact with than the low-level APIs of alternative platforms
<fiddlerwoaroof>
Anyways, this is what abstraction is for: something like ASDF could make a "thing" that works on whichever platform you're targeting
<oni-on-ion>
objective-c is one of my top favorite languages, there was a point i made my own runtime. it talked to gnu smalltalk =)
<oni-on-ion>
isnt it uiop's job to do system-specific stuff ?
<aeth>
fiddlerwoaroof: afaik, you can't sign it in a way that doesn't have scary warnings without paying Apple 100 $/year
skapata has quit [Remote host closed the connection]
<fiddlerwoaroof>
I’m thinking of program-op
<fiddlerwoaroof>
Aeth it depends
<fiddlerwoaroof>
I’m pretty sure the notarization process is free
<fiddlerwoaroof>
And that's all most people need
<aeth>
According to the article, "Mac developers must sign up for the Apple Developer Program, sign a legal agreement, and pay an annual fee of USD $99 plus tax in order to obtain a Developer ID code signing certificate and upload software to Apple for notarization."
<aeth>
Anything unsigned or locally signed will have a "this might be malware" popup
gproto023 is now known as gproto23
<aeth>
The only thing that saves CL here is that most non-commercial applications will just be distributed in .lisp source code form for local compilation and running on a presumably-signed already-installed CL compiler
<fiddlerwoaroof>
The thing is, most applications you could just pop up a loading screen and compile the code on the fly
<fiddlerwoaroof>
even for a commercial app
<fiddlerwoaroof>
Or, distribute FASLs
<fiddlerwoaroof>
Or cores
<aeth>
Any end-user application written in CL (which can't assume that the user has their own CL installed) will either have to be commercial or money-losing.
<aeth>
Unless you distribute and install the CL like it's the JVM or something.
<fiddlerwoaroof>
You're already doing that when you save-lisp-and-die
<aeth>
That's not really the common workflow, though. Generally, you export an executable if you don't expect the user to have CL installed.
<fiddlerwoaroof>
Really, on macOS a GUI application should have a .app bundle
<aeth>
No, the output of save-lisp-and-die would, afaik, have to be signed, which costs 100 USD/year.
<fiddlerwoaroof>
Only if you do :executable t
<fiddlerwoaroof>
If you just save a core and load it when sbcl starts up, it won't
<aeth>
Now you have to distribute a matching SBCL version. Java can get away with this because lots of things use Java.
<fiddlerwoaroof>
You do this: foo.app/Contents/MacOS/foo (sbcl)
<aeth>
This also is assuming that SBCL signs the macOS executables, idk if it does
<oni-on-ion>
hmm lisp (fasl) can be disasm quite easily ? can one only distribute the fasl/core and are those somewhat protected ?
<fiddlerwoaroof>
Also, $99/year is like three cups of coffee a month
<aeth>
Alternatively, $99/year is like an entire computer a decade, on top of having to actually buy an entire Apple computer a decade in order to test/build the application.
<aeth>
while every other OS can just be run in a VM
<fiddlerwoaroof>
You can run macOS in a VM :)
<fiddlerwoaroof>
It's not exactly legal
<fiddlerwoaroof>
But it's fairly trivial
<fiddlerwoaroof>
(it's not legal on non-apple hardware, that is)
<aeth>
well, it won't be trivial for long now that the transition to ARM is underway
<aeth>
Breaking the law in the process of making your software is essentially a non-starter for distributing software, anyway.
<fiddlerwoaroof>
I mean, if you're going the commercial route, you're not going to worry about $99/year
<aeth>
If you're going the commercial route and not supporting iOS, then there's a very good chance that the money you make from macOS will not be enough to make up for the increased expense for supporting macOS.
<aeth>
Especially when Apple goes out of the way to act like they're in Microsoft's position, not a < 5% position.
<fiddlerwoaroof>
Well, that depends on your target market
<aeth>
At least with CL, in theory everything is portable, within reason.
<oni-on-ion>
Chmm
<fiddlerwoaroof>
Ok, when building abcl, my 2015 mac isn't even close to the new one
<fiddlerwoaroof>
(not entirely fair, for sure, but...)
<aeth>
My main concern with macOS, though, would be if they require everything to go through the App Store, like with iOS. Obviously not literally, since you wouldn't be able to develop for macOS (or iOS!) if they did, but contractually, it could be required.
<aeth>
Every indication is that they're moving to a macOS-iOS merger in the long run (except touch support, which afaik is still missing from macOS, unlike, say, Windows)
<fiddlerwoaroof>
I don't know, iOS is being split
<fiddlerwoaroof>
They're spliting ipadOS from the phone system, for example
<aeth>
Considering how long everything I do takes, I wouldn't be surprised if Apple locks down their desktop/laptop platform before I even complete anything that I would want to export as a binary.
<fiddlerwoaroof>
There's going to be some kind of merger
<oni-on-ion>
tvOS, watchOS
<fiddlerwoaroof>
So, ABCL build on my new laptop:
<fiddlerwoaroof>
ant 97.38s user 3.70s system 159% cpu 1:03.33 total
<fiddlerwoaroof>
I accidentally C-ced the other one, but it was like 5 minutes
<fiddlerwoaroof>
I'm going to try on my 2019 work mac next
terpri has quit [Remote host closed the connection]
<fiddlerwoaroof>
My work mac looks like this: 166.41s user 9.68s system 165% cpu 1:46.50 total
<fiddlerwoaroof>
My 16 core Ryzen 2 box like this: 140.36s user 2.52s system 202% cpu 1:10.62 total
<fiddlerwoaroof>
My 2015 MBP like this: 323.80s user 20.27s system 141% cpu 4:03.64 total
terpri has joined #lisp
Blukunfando has quit [Ping timeout: 265 seconds]
<aeth>
Not surprising... it's only going to be competitive to roughly contemporary AMD going forward unless Intel can turn themselves around. And I wouldn't be surprised if Intel finds a way to fall into #4 or #5 by 2023.
Kundry_Wag has joined #lisp
andreyorst has joined #lisp
<fiddlerwoaroof>
Yeah
<fiddlerwoaroof>
I should upgrade to the new Ryzen chips
<fiddlerwoaroof>
A 5950 or something
<aeth>
We should do a gofundme to make a Lisp machine CPU on TSMC 5 nm so we can be #3 ahead of Intel
<aeth>
Because at least like 70% of the work is TSMC
<fiddlerwoaroof>
I sort of wonder how much Apple's CPUs are tuned for their frameworks
<fiddlerwoaroof>
Since everything is built on the Objective-C runtime (more or less), Apple devices are more like a Lisp Machine than most Linux devices
bilegeek has quit [Quit: Leaving]
<fiddlerwoaroof>
Anyways, know that I have ABCL, time to try to port SBCL :)
Kundry_Wag has quit [Ping timeout: 256 seconds]
igemnace has joined #lisp
<no-defun-allowed>
aeth: I want to make a list of (reasonable, RISC-y) things to put in a Lisp-oriented extension to RISC-V.
Kundry_Wag has joined #lisp
<beach>
no-defun-allowed: That's tricky stuff.
<fiddlerwoaroof>
Javascript got its own CPU instruction
<beach>
no-defun-allowed: I have probably said this before, but my bet would be on some write barrier or read barrier.
<fiddlerwoaroof>
beach: to optimize GC?
<beach>
Yeah.
<beach>
Everything else is fairly easy to do on any old modern architecture.
<no-defun-allowed>
That's usually done with the MMU, marking pages as read-only and trapping writes (for a write barrier), no?
<no-defun-allowed>
I guess it's still fiddly to do.
<beach>
no-defun-allowed: That is very costly.
Kundry_Wag has quit [Ping timeout: 256 seconds]
<fiddlerwoaroof>
The newest JVM GCs take advantage of the MMU in a clever way
kiroul has quit [Ping timeout: 246 seconds]
<fiddlerwoaroof>
a 64 bit pointer can address more memory than we'll ever have (probably)
<beach>
fiddlerwoaroof: And what do you conclude from that observation?
<fiddlerwoaroof>
So, if I understand correctly, they reserve several bits for information about where the pointer points to
<fiddlerwoaroof>
and then map multiple addresses to one physical memory location
<beach>
Wow, so EQ would break?
<fiddlerwoaroof>
I guess so, if EQ doesn't know about the trick
<no-defun-allowed>
You would have to normalize pointers before testing EQ.
narimiran has joined #lisp
<beach>
Well, it means EQ would be more costly.
<fiddlerwoaroof>
You just compare the lower 42 bits of the pointers, it sounds like
<no-defun-allowed>
I recall a similar thing happens with Nettle's replicating copying collector, but it's worse as that normalization requires a memory read (to follow the forwarding pointer).
<fiddlerwoaroof>
The goal is to minimize pause time here
<beach>
Oh, that's easy.
<no-defun-allowed>
But in applicative languages like ML, which it was designed for, EQ supposedly is rarely used; though testing reference equality is favourable to testing structural equality.
<beach>
Just use a small per-thread nursery, and a concurrent global collector.
<fiddlerwoaroof>
Yeah, this is how they're implementing the concurrent collector
<beach>
no-defun-allowed: Yes, there are tendencies like that, e.g. "Our language semantics makes everything expensive anyway, so using an inefficient mechanism here doesn't matter much".
<aeth>
no-defun-allowed: make CAR and CDR instructions again
<beach>
aeth: Absolutely not.
<beach>
That's a terrible idea.
<fiddlerwoaroof>
I'd think some hardware acceleration for dynamic dispatch would be useful?
<beach>
fiddlerwoaroof: We know how to do that now on stock hardware.
<aeth>
no-defun-allowed: I personally wouldn't make extensions unless you actually had real programs from real implementations running and profiled them and determined what the bottlenecks are that are addressable with new instructions rather than with better compilers
<no-defun-allowed>
aeth: Absolutely.
<aeth>
I'm curious as to if e.g. making a 68 bit architecture with 4 tag bits might be the way to go, not for performance, but for 64-bit fixnums and unboxed double-float.
shifty has quit [Ping timeout: 256 seconds]
<no-defun-allowed>
Now you have the problem of finding 68-bit memory. And you may want another bit for incremental marking.
shifty has joined #lisp
<beach>
It is entirely possible that any useful extension would not be RISC-y enough to be considered.
<beach>
I mean, they don't even have arithmetic overflow for integer ADD.
<beach>
So then, write a barrier would just be two comparisons.
<no-defun-allowed>
Yes, I'm trying to find the ideas that would be sufficiently simple.
jonatack has quit [Ping timeout: 260 seconds]
<beach>
Maybe something that would help with inlining of generic functions.
<beach>
Not that I know what it would be. I already know how to do it in a not-too-costly way.
jonatack has joined #lisp
andreyorst_ has joined #lisp
incidentist has quit [Quit: incidentist]
shifty has quit [Ping timeout: 272 seconds]
<no-defun-allowed>
Would inline caching be useful in Common Lisp?
<beach>
What do you mean by "inline caching"?
gaqwas has joined #lisp
gaqwas has quit [Changing host]
gaqwas has joined #lisp
gaqwas has quit [Remote host closed the connection]
<fiddlerwoaroof>
caching method dispatch at the call site?
<no-defun-allowed>
The code that calls a generic function would be replaced with a call to the last effective method (with a prologue that calls the generic function as usual, if the last method is no longer applicable).
<beach>
Hmm.
<no-defun-allowed>
It has been done on normal CPUs with Smalltalk, Self, Java and JavaScript at the least; so it may not be necessary to provide any processor support.
<beach>
The technique I was thinking of consists of using type information in the caller to create a call-site-specific discriminating function, and change it when the generic-function changes.
<no-defun-allowed>
Right.
<beach>
But your suggestion is different.
<beach>
... since it takes run-time information into account.
<no-defun-allowed>
The polymorphic inline cache described in <https://bibliography.selflanguage.org/_static/pics.pdf> is a bit closer to your technique, but it still picks the most common methods from runtime information.
<fiddlerwoaroof>
Yeah, this is how the JVM dispatches
<no-defun-allowed>
The only support that needs is that you need to be able to overwrite the call site, but that's not a big deal; and also doable on stock hardware.
<beach>
It is, yes.
orivej has quit [Ping timeout: 260 seconds]
<no-defun-allowed>
The one idea I have which may be better done in hardware (which gilberth gave me) is computing the address of an element in arrays of different element types when performing a generic AREF. (SBCL calls that "hairy", which is much more fun to say than "generic" though.)
saganman has joined #lisp
<aeth>
no-defun-allowed: the lookup process should be called shaving
<beach>
no-defun-allowed: I am thinking that things like AREF and CAR/CDR are usually done in a loop. So then, it is possible to make the type of the object a loop invariant.
<no-defun-allowed>
That is true, yes.
<beach>
I am not sure it is worthwhile trying to optimize single accesses.
<beach>
Plus, application writers who care that much about performance would stick in a type declaration that could then be verified quite easily.
<beach>
Speaking of which, I am convinced that Common Lisp implementations and their compilers are full of "optimizations" that are basically useless.
<aeth>
all compilers are
<beach>
But I don't care about the others.
<beach>
The representation of NIL in SBCL comes to mind.
<aeth>
I guess the issue is that basically useless optimizations can add up.
<beach>
They add up in that they often make the system harder to maintain.
<beach>
In the case of SBCL NIL, it makes it necessary to do two tests in a loop over a list, rather than a single test, in order to determine the end.
aartaka has joined #lisp
aartaka has joined #lisp
<beach>
And that special case I am guessing is present in a lot of places in SBCL.
<beach>
Though stassats assures me that there is no performance penalty for making two tests rather than one.
<aeth>
What I'm more concerned about that maintenance is compilation times. A lot of compilers are incredibly slow to get that extra speedup at the end, and it's questionable if it's worth it, especially if you translate that sort of approach to a CL compiler, which will be compiling more. (Yes, CL has optimization levels, but they're not that flexible)
<aeth>
s/that maintenance/than maintenance/
<aeth>
People have complained about SBCL compilation times, but I don't really see that, except with a few edge case libraries (is Ironclad still really slow?)
<beach>
I have the exact opposite assessment.
<beach>
Especially for Common Lisp where the maintenance burden is a real problem, given the limited resources we have.
<moon-child>
what's sbcl's nil representation?
<moon-child>
is it a global (nil . nil)?
<beach>
It is represented so that you can take the CAR/CDR of it and get NIL.
<beach>
But it is obviously also a symbol.
saganman has left #lisp ["WeeChat 1.6"]
nostoi has joined #lisp
nostoi has quit [Quit: Verlassend]
<pfdietz>
You don't want to make the generated code for car and cdr check if the thing is nil. That way lies madness. So what's the alternative?
<pfdietz>
You do car and cdr a lot in a lisp program, much more than you do symbol-name, symbol-plist, symbol-value, (typep ... 'symbol), etc.
<beach>
I claim it is not madness and that most CAR/CDRs are done in loops so the test has to be made anyway.
<beach>
And you still have to test for non-NIL atoms anyway.
<beach>
So a single test for CONSP is almost always going to be TRUE which is the same number of tests you need in order to check for non-NIL atoms.
<beach>
But the thing that bothers me is that "optimizations" like this are put in as a result of intuition, and we know for a fact that our intuitions are frequently wrong when it comes to performance bottlenecks.
<beach>
And as a result we have, like I said, systems that are harder to maintain without any good reason for it.
<aeth>
I never directly call car or cdr... destructuring-bind is almost always the better solution.
<beach>
And what do you think destructuring-bind does?
<aeth>
whatever the compiler wants it to do :-)
<aeth>
maybe it has an unsafe %car and %cdr
<beach>
That would be a violation of semantics.
<pfdietz>
(destructuring-bind (a . b) nil ...) ==> error
<beach>
Oh?
<beach>
Sorry about that.
<beach>
But the same number of tests have to be made.
<beach>
So it can't use an "unsafe" version of CAR and CDR anyway.
<pfdietz>
Admittedly, the spec is not clear on exactly what that case is supposed to do.
<beach>
Yeah, I am reading the Common Lisp HyperSpec page now.
pve has joined #lisp
<pfdietz>
"it's just like a macro lambda list" (looks) "the pattern is a sample object of the type to be decomposed."
<pfdietz>
I think we can safely criticize the language definition about this, though. It would have been ok for car/cdr of nil to be an error. I think this was inherited from Interlisp when CL was being defined. For that matter, punning () and false is also bad.
gproto023 has joined #lisp
<beach>
Note to self: specify the behavior of destructuring-bind in WSCL.
gproto23 has quit [Ping timeout: 240 seconds]
<pfdietz>
I see about 26000 occurrences of car in quicklisp. Picking a few at random, they don't seem to be in loops, at least not in tight ones. On the other hand that's not all that many tests to add, especially if many could be optimized out anyway. Real data on the impact would be interesting.
h4ck3r9696 has joined #lisp
kaftejiman has joined #lisp
<beach>
And, like I said, even if it is not in a loop, you still need to test for non-NIL atoms.
<pfdietz>
That's just from a simple grep; it ignores implicit car/car from destructuring or looping forms.
gproto0023 has joined #lisp
<pfdietz>
If you just want an error to be signaled in that case you don't need an explicit check.
<beach>
You suggest trapping on unaligned memory accesses?
<pfdietz>
Yes, I believe that's what happens.
<pfdietz>
(in sbcl)
Lord_of_Life has quit [Changing host]
Lord_of_Life has joined #lisp
<beach>
I suppose you could do that, sure.
kaftejiman_ has joined #lisp
gproto023 has quit [Ping timeout: 240 seconds]
<beach>
The CAR/CDRs in loops would not be explicit though.
<beach>
They would be in (loop for element in list do...)
iskander- has joined #lisp
<pfdietz>
Right
iskander has quit [Ping timeout: 240 seconds]
<phoe>
pfdietz: (loop for (a b c) in list ...) has implicit CAR/CDRs
<beach>
And even more implicit in MAPxxx.
<pfdietz>
Also mapcar and the like, and iterate.
<beach>
Yep.
<phoe>
a lot of list accesses are hidden like that
<phoe>
also all sequence operations have implicit car/cdr calls when called with list arguments
Kundry_Wag has joined #lisp
kaftejiman has quit [Ping timeout: 256 seconds]
<beach>
That too.
jonatack has quit [Ping timeout: 272 seconds]
jonatack has joined #lisp
rumbler31 has joined #lisp
Kundry_Wag has quit [Ping timeout: 260 seconds]
Kundry_Wag has joined #lisp
<pfdietz>
assoc is interesting. The spec explicitly says that a nil in an alist is ignored by assoc (and assoc-if, assoc-if-not). So (assoc nil '(nil (nil . a))) ==> (nil . a)
<phoe>
this seems like a malfomed alist to me anyway
<phoe>
you shouldn't have an atom in a list of conses
imode has quit [Ping timeout: 256 seconds]
rumbler31 has quit [Ping timeout: 260 seconds]
Kundry_Wag has quit [Ping timeout: 256 seconds]
<pfdietz>
cons n.v. 1. n. a compound data object having two components called the car and the cdr.
<pfdietz>
So, is nil a cons?
<pfdietz>
It has a car and a cdr.
<pfdietz>
But it is not of type cons.
<pfdietz>
Or should it be?
<phoe>
it won't be an atom then
<phoe>
which means that we'll have a single symbol that is magically not an atom
<beach>
I don't think it "has a car and a cdr".
hendursa1 has joined #lisp
<beach>
I think CAR and CDR are just defined to return something when applied to NIL.
<phoe>
^
<phoe>
beach: but, under the hood, you know...
<phoe>
"On PPC32 and X86-64, NIL is basically a weird CONS cell that straddles two doublenodes; the tag of NIL is unique and congruent modulo 4 (modulo 8 on 64-bit) with the tag used for CONS cells."
<pfdietz>
"The types cons, symbol, array, number, character, hash-table, function, readtable, package, pathname, stream, random-state, condition, restart, and any single other type created by defstruct, define-condition, or defclass are pairwise disjoint"
<beach>
phoe: That's the kind of "optimization" I was referring to earlier in this discussion.
<pfdietz>
So nil cannot be of type cons.
<beach>
phoe: Thanks for confirming that CCL has it as well.
hendursaga has quit [Ping timeout: 240 seconds]
<pfdietz>
So: the question becomes what is the actual impact of this design choice, vs. adding a check at each car/cdr. I suppose one could also trap car/car on nil and insert do the right thing in the trap handler.
<pfdietz>
s/insert //
<beach>
And I think the main impact is an increased maintenance burden. Especially since modern Common Lisp code uses standard objects where in the past lists were used.
<phoe>
well, unless your internal representation somehow manages to handle NIL being both a symbol and a valid argument to CAR/CDR, checks need to be somewhere
<phoe>
either it's internally represented as an atom and therefore CAR/CDR need to check, or it's internally represented as a cons and symbol accessors need to check
<pfdietz>
I wonder how ABCL does it.
<phoe>
or maybe there's yet another creative way to handle this
<beach>
So it is entirely possible that using a sub-optimal algorithm for generic dispatch is going to be much more detrimental to performance than having an explicit CONSP test.
<beach>
phoe: Did you read the previous conversation?
amb007 has quit [Read error: Connection reset by peer]
<pfdietz>
Surely inlining the test like that makes sense here. car/cdr are not extensible with new methods, after all.
<phoe>
beach: yes
akoana has quit [Quit: leaving]
amb007 has joined #lisp
<beach>
pfdietz: That's not what I meant. I meant that, with a limited amount of person-power for maintenance, it would be wise to add complication where they have the most positive impact on performance.
igemnace has quit [Quit: WeeChat 2.9]
<beach>
But I can also see how design choices like this were made when the implementation was a CLtL1 implementation so that lists were used a lot more than they are these days.
<pfdietz>
Sure. I was just wondering what the increased maintenance burden is buying, with reference to actual code in quicklisp. If it's not much, your argument becomes strong.
<beach>
Right. But we have no way of measuring this. We have to rely on imperfect intuition.
<beach>
We could try to measure the performance impact, of course.
<phoe>
unless we have some sort of an implementation that we can modify and then benchmark on code
mbomba has quit [Quit: WeeChat 3.0]
<phoe>
right
<phoe>
by "code" I mean both synthetic benchmarks that measure the performance impacts of raw operation and real applications that do little/moderate/lots of cons operations
<phoe>
s/operation/operations/
<pfdietz>
One could shadow car/car in your code's packages (and, perhaps, library packages) with something that is inlined and does the checks, and see what effect that has.
<pfdietz>
To handle all the libraries, use a macroexpand hook to intercept defpackage and add the shadowing.
Inoperable has quit [Excess Flood]
<pfdietz>
(and cadr, etc.)
<pfdietz>
This would not handle car/cdr introduced in loops and mapping form, but as Beach argued those should not matter.
<phoe>
also destructuring
Inoperable has joined #lisp
<pfdietz>
But that's throwing an error in sbcl in that case, not doing car/cdr through nil.
<pfdietz>
destructuring-bind at least
<phoe>
yes, but those use cons operations too, and therefore need to make checks anyway
<phoe>
is destructuring-bind using a different kind of CAR than everything else?
<pfdietz>
Hmm. The destructing in LOOP *does* go through NIL.
<phoe>
or does it just perform CONSP checks to ensure list lengths?
<phoe>
I assume the latter
<pfdietz>
(loop for (a . b) in '(nil) collect a collect b) ==> (nil nil)
ldbeth has joined #lisp
<aeth>
the destructuring in LOOP is useless ime
<aeth>
I essentially always just destructuring-bind and setf because d-b handles the edge cases in the way I want, unlike LOOP's destructuring.
iskander- has quit [Ping timeout: 256 seconds]
<ldbeth>
just aware that the issue bothered me is due to namespace pollution of emacs lisp
iskander has joined #lisp
<pfdietz>
destructuring-bind macroexpands to code that invokes sb-c::check-ds-list and sb-c::check-ds-list/&rest. I hope those are inlined.
<Demosthenex>
so i'm tinkering with clsql and the [] notation for sql, but emacs paredit isn't recoginzing those and indentation is a problem. any suggestions?
<pfdietz>
You can add hints for paredit.
<beach>
phoe: As I recall, in SBCL CONSP requires two tests, like LIST and not NULL.
<phoe>
I would not expect this on the stack trace if it was inlines
<ldbeth>
Demosthenex: do you want paredit to tread [] as a pair of bracket or just an token?
<phoe>
inlined*
<pfdietz>
Yes, and disassemble shows the call is there.
<Demosthenex>
ldbeth: [] should be treated like any other ()'s
<pfdietz>
I have [ and ] mapped to paredit-open-parenthesis / paredit-close-parenthesis in the paredit-mode-map, but I use curry-compose-reader-macros where [ and ] represent function composition.
Codaraxis has quit [Remote host closed the connection]
Codaraxis has joined #lisp
<ldbeth>
Demosthenex: I guess you might want some behavior from emacs-lisp-mode
<pfdietz>
ISLISP does not have (car nil) and (cdr nil) being valid. It's mostly historical at this point, though.
<ldbeth>
Demosthenex: https://github.com/cireu/sly-el-indent here's some hack on sly (SLIME) to indent emacs lisp code, you might want to see if thoses hacks apply to your problem
<ldbeth>
pfdietz: neither Scheme treat '() as pair
<pfdietz>
Right
dmc00 has quit [Ping timeout: 246 seconds]
<ldbeth>
It could be confusing (cdr nil) and (car nil) are nil while (cons nil nil) is (nil)
<pfdietz>
trivia:ematch seems to generate faster code that destructuring-bind, for equivalent forms.
rippa has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
Inoperable has quit [Excess Flood]
rumbler31 has joined #lisp
Inoperable has joined #lisp
rumbler31 has quit [Ping timeout: 264 seconds]
orivej has joined #lisp
karlosz has quit [Quit: karlosz]
<pfdietz>
(scrolling up) The inlining of dispatch is made more exciting by the possibility that classes and methods can be dynamically modified. What if you need to recompile a function to reflect these changes while a call to that function is on the stack?
ldbeth has quit [Quit: ERC (IRC client for Emacs 27.1)]
<beach>
Exciting indeed.
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<pfdietz>
I figure you want to compile such functions with some sort of standardized stack frame, so you can return back to an unoptimized, or differently optimized, version of it if that happens.
treflip has joined #lisp
<aeth>
pfdietz: I think, in general, you want to be fast assuming no dynamic redefinitions, although obviously permit the slow path to happen
green_ has joined #lisp
<aeth>
most dynamic redefinitions will be user-defined, and infrequent, at least if you're assuming e.g. running in aloop
<aeth>
I do wonder how much of this is handled by CPU's branch prediction these days, though.
Cymew has joined #lisp
<no-defun-allowed>
The dispatch has been done, so it's handled as per usual.
<no-defun-allowed>
self
<no-defun-allowed>
Amazing, I was looking to see if Self had come up in #lisp before. Someone didn't reach for the search button.
<no-defun-allowed>
Perhaps it's too late for #lisp-ing, but I needed something to do while rebuilding SBCL with the higher internal-time-units-per-second so I can get less-than-awful variance with metering.
<phoe>
wired: (destructuring-bind (&aux (a 42) (b (1+ a))) '() (list a b))
<phoe>
so equality checks can be performed on &aux
<beach>
What do you mean?
<phoe>
uh - sorry, scratch this last line
<beach>
Done!
<aeth>
phoe: In my Lisp, let* will just expand to destructuring-bind with an &aux since having both is unnecessary!
<phoe>
thanks!
<phoe>
;; I thought I was on #lispcafe
<phoe>
;; but instead I posted to #lisp
<aeth>
;; my joke has been moved as well
aartaka has quit [Ping timeout: 256 seconds]
aartaka has joined #lisp
andreyorst_ has quit [Ping timeout: 256 seconds]
<phoe>
Is there a portable implementation of destructuring lambda list parser somewhere?
<phoe>
beach: have you perhaps written such a thing as a part of SICL?
<phoe>
yes, it seems so
<phoe>
thanks :)
Lycurgus has quit [Quit: Exeunt]
aorst has joined #lisp
andreyorst has quit [Ping timeout: 240 seconds]
h4ck3r9696 has quit [Ping timeout: 272 seconds]
iskander- has joined #lisp
iskander has quit [Ping timeout: 265 seconds]
gproto0023 has quit [Remote host closed the connection]
gproto0023 has joined #lisp
gproto023 has joined #lisp
galex-713 has quit [Ping timeout: 272 seconds]
iskander has joined #lisp
iskander- has quit [Ping timeout: 265 seconds]
gproto0023 has quit [Ping timeout: 240 seconds]
galex-713 has joined #lisp
iskander has quit [Ping timeout: 246 seconds]
iskander has joined #lisp
narimiran has quit [Ping timeout: 240 seconds]
frost-lab has quit [Quit: Ping timeout (120 seconds)]
green_ has quit [Ping timeout: 240 seconds]
green_ has joined #lisp
iskander- has joined #lisp
iskander has quit [Ping timeout: 265 seconds]
aartaka has quit [Read error: Connection reset by peer]
aartaka has joined #lisp
gproto023 is now known as gproto23
green_ has quit [Ping timeout: 256 seconds]
gaqwas has joined #lisp
gaqwas has joined #lisp
edgar-rft has quit [Quit: Leaving]
Inoperable has quit [Excess Flood]
rippa has quit [Ping timeout: 264 seconds]
Inoperable has joined #lisp
iskander- has quit [Quit: bye]
CEnnis91 has quit [Read error: Connection reset by peer]
CEnnis91 has joined #lisp
iskander has joined #lisp
Kundry_Wag has joined #lisp
gproto23 has quit [Ping timeout: 264 seconds]
zxcvz has joined #lisp
iskander has quit [Ping timeout: 240 seconds]
iskander has joined #lisp
EvW has joined #lisp
gproto23 has joined #lisp
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 264 seconds]
Lord_of_Life_ is now known as Lord_of_Life
gproto23 has quit [Ping timeout: 240 seconds]
gproto0023 has joined #lisp
edgar-rft has joined #lisp
_mecairS` has joined #lisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #lisp
Cymew has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
Lord_of_Life has quit [Read error: Connection reset by peer]
rippa has joined #lisp
amb007 has joined #lisp
Lord_of_Life has joined #lisp
Lord_of_Life has quit [Changing host]
Lord_of_Life has joined #lisp
_mecairS` has quit [Quit: Hi. If i ever be an Angel of Light to guide you, to lead you in every way, will you also think of me at night and day.. https://bit.ly/36blphN]
gproto023 has joined #lisp
Blukunfando has joined #lisp
cosimone has joined #lisp
gproto0023 has quit [Ping timeout: 272 seconds]
green_ has joined #lisp
Kundry_Wag has quit [Ping timeout: 256 seconds]
ym has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
amb007 has joined #lisp
asdflkj has quit [Ping timeout: 240 seconds]
Kundry_Wag has quit [Ping timeout: 240 seconds]
<Josh_2>
afternoon
<phoe>
hey
skapata has joined #lisp
Cymew has quit [Ping timeout: 246 seconds]
dmc00 has joined #lisp
pfdietz has quit [Ping timeout: 245 seconds]
andreyorst has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
aorst has quit [Ping timeout: 240 seconds]
cosimone has quit [Read error: Connection reset by peer]
Cymew has joined #lisp
segmentationfaul has joined #lisp
segmentationfaul has quit [Client Quit]
pillton has quit [Read error: Connection reset by peer]
pillton has joined #lisp
aartaka has quit [Ping timeout: 264 seconds]
lucasb has joined #lisp
EvW has quit [Ping timeout: 260 seconds]
gothnbass has joined #lisp
RukiSama_ has joined #lisp
RukiSama has quit [Ping timeout: 264 seconds]
makomo has joined #lisp
aartaka has joined #lisp
Lycurgus has joined #lisp
galex-713 has quit [Ping timeout: 272 seconds]
aorst has joined #lisp
andreyorst has quit [Ping timeout: 246 seconds]
Inoperable has quit [Excess Flood]
Lycurgus has quit [Quit: Exeunt]
green_ has quit [Ping timeout: 264 seconds]
Inoperable has joined #lisp
aartaka has quit [Read error: Connection reset by peer]
green_ has joined #lisp
Nilby has joined #lisp
green_ has quit [Ping timeout: 246 seconds]
Inoperable has quit [Excess Flood]
ex_nihilo has quit [Quit: Leaving]
makomo has quit [Quit: WeeChat 2.9]
Inoperable has joined #lisp
luckless_ has quit [Ping timeout: 240 seconds]
Cymew has quit [Ping timeout: 240 seconds]
luckless_ has joined #lisp
Kundry_Wag has joined #lisp
andreyorst has joined #lisp
Kundry_Wag has quit [Ping timeout: 240 seconds]
aorst has quit [Ping timeout: 260 seconds]
Codaraxis_ has joined #lisp
Codaraxis has quit [Ping timeout: 240 seconds]
gproto0023 has joined #lisp
treflip has quit [Remote host closed the connection]
gproto023 has quit [Ping timeout: 256 seconds]
gproto0023 is now known as gproto23
Codaraxis_ has quit [Read error: Connection reset by peer]
ibinderwolf_ has quit [Ping timeout: 260 seconds]
McParen has joined #lisp
ibinderwolf has joined #lisp
uniminin has quit [Quit: Leaving]
Codaraxis has joined #lisp
judson_ has joined #lisp
FreeBirdLjj has joined #lisp
emys has quit [Remote host closed the connection]
judson_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TwoNotes has joined #lisp
TwoNotes has left #lisp [#lisp]
judson_ has joined #lisp
andreyorst_ has joined #lisp
Alloc has joined #lisp
Inoperable has quit [Excess Flood]
EvW has joined #lisp
judson_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
renzhi has joined #lisp
Inoperable has joined #lisp
Inoperable has quit [Excess Flood]
matijja has quit [Quit: bye]
matijja has joined #lisp
kiroul has joined #lisp
Inoperable has joined #lisp
bitmapper has joined #lisp
narimiran has joined #lisp
<Josh_2>
I have subclassed hunchentoot:acceptor and written a version oh acceptor-dispatch-request, is it possible to also use the default method ie (define-easy-handler ..) as well? currently I can only create new routes with the mechanism I have created, ideally I'd like both
Inoperable has quit [Excess Flood]
galex-713 has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
Inoperable has joined #lisp
<gothnbass>
Josh_2: I'm working on some code involving a subclass of acceptor myself right now, and... probably? To ask the annoyingly dumb question, what happens when you try it?
FreeBirdLjj has quit [Ping timeout: 260 seconds]
<gothnbass>
My use-case is relatively simple, though, so I just (setf tbnl:*dispatch-table* (list (create-regex-dispatcher "/url" 'function)...))
<Josh_2>
hmm
<Josh_2>
I might be able to modify my new route system to simply add a route like that to *dispatch-table*
<gothnbass>
OTOH, if you have any tips about round-tripping Unicode from Drakma to Neo4j and back, I'd love to hear 'em. Thought I'd solved it by handing Drakma a :content parameter to force it to pass through some pre-encoded data, but I'd swear Neo4j is mangling it, so I'm closing on table-flip.
<Josh_2>
when I use (define-easy-handler ..) I simply get a 404
<gothnbass>
Damn.
cer0 has joined #lisp
<Josh_2>
ah
<Josh_2>
maybe I need to subclass easy-acceptor instead idk