NicknameJohn has quit [Read error: Connection reset by peer]
<beach>
And for those of you with a little more time on your hands, please consider either turning one of the GitHub issues on that site into a real WSCL issue, writing a WSCL issue for some problem in the standard, or submitting a short GitHub issue for such a problem.
ymir has quit [Ping timeout: 252 seconds]
infos has joined #commonlisp
<beach>
Of course, if anybody has questions related to WSCL, please don't hesitate to ask.
amb007 has joined #commonlisp
infos has quit [Remote host closed the connection]
dnhester has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
<zyd>
I am pleased to know that my intuition to pronounce it "whistle" was correct.
ymir has joined #commonlisp
dnhester has quit [Ping timeout: 260 seconds]
<beach>
Heh, yes.
azimut has quit [Ping timeout: 260 seconds]
pve has joined #commonlisp
NicknameJohn has joined #commonlisp
akoana has quit [Quit: leaving]
NicknameJohn has quit [Ping timeout: 255 seconds]
Lycurgus has quit [Quit: leaving]
zetef has joined #commonlisp
zetef has quit [Client Quit]
<younder>
beach the low level compiler is mostly interested in the 26 special forms of common-lisp yes? Whats left after the macro expander has done it's thing.
<younder>
I just used the list from 'Lisp in Small Pieces'
<beach>
Correct.
* beach
is off for an hour or so.
traidare has joined #commonlisp
FragmentedCurve has quit [Remote host closed the connection]
Pixel_Outlaw has quit [Remote host closed the connection]
ymir has quit [Ping timeout: 264 seconds]
igemnace has joined #commonlisp
istewart has quit [Quit: Konversation terminated!]
kurfen has quit [Ping timeout: 240 seconds]
elderK has quit [Quit: WeeChat 4.1.1]
amb007 has joined #commonlisp
kurfen has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<beach>
Turning a program into intermediate representation is not terribly hard. The hard part is applying optimizations to the intermediate representation. And that's just the compiler. There are tons of other things to take care of in a Common Lisp system.
dnhester has joined #commonlisp
dnhester has quit [Ping timeout: 246 seconds]
notzmv has quit [Ping timeout: 260 seconds]
<younder>
From my perspective. I need a IL and on the other side a general assembly. This in turn goes to the registry optimizer and the code generator. I need to have a format in 'both ends'
<beach>
You don't need assembly. You need machine code. Assembly is a notation with a surface syntax to make it easier for humans to write machine code. But there are no humans involved here.
shka has joined #commonlisp
<younder>
Obviously, but I thought I would use you assembler module
<beach>
The intermediate language to start with can be something like MIR (Medium-level Intermediate Representation) that is discussed in Muchnick's book. It has explicit instructions for simple arithmetic, memory operations, and conditional and unconditional branches.
<beach>
Cluster isn't really an assembler. It has no surface syntax.
<younder>
It is a line-by-line assembler not a macro assembler
<beach>
Neither. It takes a graph of instances of standard objects that represent operations and operands.
<beach>
Cluster currently does only X86, and only partially. I would start with something that doesn't even require much of the functionality that Cluster supplies, namely instruction selection. Something like RISC-V is much simpler.
Equill has quit [Quit: Gone offline]
<younder>
Well I and phantomics were already looking at cluster as a basis for SPIR-V bytecode generation a while back.
<beach>
I see.
<younder>
So I guess the idea was more to extend cluster to handle many different types of machine code. By 'many' I mean mainly AMD-X86, ARM64 and RISC-V
<beach>
Maybe. But there won't be much left of Cluster for the simpler machines. Maybe ARM which is not exactly a RM anymore. And Cluster already does AMD64.
<beach>
Wait, I think someone here already planned to work on Cluster. Now I can't remember who it was. Maybe searching the logs would help.
wacki has joined #commonlisp
<younder>
probably phantomics
<beach>
Yes.
rgherdt has joined #commonlisp
igemnace has quit [Quit: WeeChat 4.2.1]
<younder>
SPIR-V comes with a json file of instructions that can be used to generate the instructions. I suspect I can find something similar of the other architectures.
igemnace has joined #commonlisp
<younder>
A generator is desirable as it is easier to keep up to date and less error-prone.
<younder>
The original SPIR architecture is based on LLVM IR. This is no longer the case with SPIR-V. Still I keep thinking it is a bit to 'high level' for the assembler
bilegeek has quit [Quit: Leaving]
jonatack has joined #commonlisp
jon_atack has quit [Ping timeout: 264 seconds]
<beach>
As I recall, either the Intel or the AMD documentation comes with some kind of formal semantics of the instructions. But it is so complicated that I can't see it integrated into any software. I might be wrong of course.
<beach>
Anyway, those are small problems compared to all the optimizations that must be implemented.
<paulapatience>
beach: s/and :method-class,/and :method-class/ near the top?
<beach>
Remove a comma?
<beach>
Let me check...
<paulapatience>
Comma after "say code that results from the expansion of the DEFMETHOD macro"
<paulapatience>
s/can not/cannot/ nearby
danza has joined #commonlisp
<beach>
I'll rewrite the sentence that prompted the first remark.
<paulapatience>
Are you using parameters and arguments synonymously?
<beach>
If I do, it is wrong.
<beach>
Parameters are the variables in the lambda list. Arguments are what the caller supplies.
<paulapatience>
"keyword argument :generic-function-class" at some point, whereas previously you say parameter for some of the keywords
<aeth>
I personally don't use the JSON file for SPIR-V
<aeth>
it's probably more useful for the gigantic dump of (mostly-useless) enums that make up half of the specification rather than the instructions themselves
<beach>
paulapatience: I say "argument" if I mean what the caller supplied, and I say "parameter" if I refer to something that is present in the lambda list.
<beach>
So the parameter can have a value. If it is a keyword parameter, it can have the value NIL if there is no init-form and the corresponding argument was not supplied.
<beach>
This terminology is consistent with the glossary of the standard. But I may have made mistakes of course.
<paulapatience>
beach: You use mandatory once, required everywhere else. Is it worth consolidating the term?
wacki_ has joined #commonlisp
wacki has quit [Ping timeout: 272 seconds]
<beach>
The term "required" is a technical term for a parameter preceding every lambda-list keyword, so I didn't want to use that word for the keyword arguments.
<paulapatience>
Ah, I see
<paulapatience>
So let me get this right (I knew the difference between parameter and argument, but I was never really able to figure out how to use them in text in this manner)
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
<paulapatience>
In "If function-name specifies a generic function that has a different value for any of the following arguments, the generic function is modified to have the new value: :argument-precedence-order, ..." (from the spec), 'arguments' is used because it supposes the caller supplied them?
<beach>
Let me check...
<beach>
Yes, but that phrase is pretty bad. It says "that has a different value", but a generic function does not have a value.
<beach>
I think I prefer to use "argument" when something is supplied.
<paulapatience>
Ok, I'm preparing a diff with some more changes, I'll swap parameter and argument around according to how I've understood you recommend using it, and you'll let me know what you think
<paulapatience>
It has been some thing I've wanted to learn how to do for some time; until now I just used argument everywhere
alcor has joined #commonlisp
<paulapatience>
beach: What is the convention for case for symbols in the proposal section?
<beach>
I don't know.
danza has quit [Ping timeout: 264 seconds]
<beach>
:(
<beach>
I should probably use lower case everywhere, because if the phrase ends up as marked up, it will be in lower case, but perhaps in typewriter font or italics.
<paulapatience>
The stream-error-stream-type-error proposal uses uppercase for symbols
<paulapatience>
I assumed that being in uppercase would allow it to be automatically converted to lowercase typewriter font
<beach>
That's a good argument, but I couldn't see myself quoting the standard wrong.
<beach>
But I guess it is wrong anyway since it has the wrong font.
<beach>
So I guess I can use uppercase for everything that should be in typewriter font.
<paulapatience>
Also, that X3J13 uses uppercase in its suggested replacement text for the standard
green__ has joined #commonlisp
<beach>
I am convinced. Thank you1
<beach>
!
<paulapatience>
What will you do for what needs to become italics, for example function-name, and symbol in ‘(setf symbol)’?
<beach>
I won't do anything. If this becomes part of a suggested dictionary entry, then it would need markup.
<beach>
... and I don't think it can be automated.
<paulapatience>
The X3J13 issue I linked is inconsistent. On the one hand, it uses uppercase OBJECT for the object parameter, which is marked up in italics at the end, but lowercase file-stream in (FILE-POSITION file-stream)
<beach>
I am not surprised.
<paulapatience>
Supposing we used that convention, however, it might be possible to automatically mark it up. If it is uppercase and is the same as one of the parameters in the syntax section, it becomes italic.
<paulapatience>
If it is lowercase in a form like (FILE-POSITION file-stream), the it would become italic. If uppercase, typewriter.
<beach>
That might work.
<paulapatience>
mgl-pax (the documentation system I mentioned to you in the past), does this, to great effect: just uppercase everything that needs special handling, and it detects whether it is an existing symbol or a parameter
alcor has quit [Ping timeout: 264 seconds]
<beach>
Either gilberth or scymtym might have opinions about it.
<paulapatience>
Some of those changes are stylistic suggestions, take them as you wish
<beach>
Thank you!
<paulapatience>
You're welcome
notzmv has joined #commonlisp
dcb has quit [Quit: Connection closed for inactivity]
<paulapatience>
beach: You can ping me in the future for more proofreading of WSCL issues.
<beach>
Excellent! I will definitely do that.
<paulapatience>
beach: While you're here, what is your opinion on the order of parameters that CALL-WITH-style functions should have? In particular, should the function parameter be first, second, last?
<paulapatience>
I used to think there was a convention, but I've looked around and seen all those possibilities
<beach>
I don't think I have given it enough thought to have an opinion.
<paulapatience>
Obviously if there are keyword parameters, they must go after the function
<paulapatience>
One argument for putting it second is if the first parameter is a client, as Eclector does it
<paulapatience>
Rather, that is an argument for not putting it first
<beach>
Yes, I agree.
<paulapatience>
The CLIM spec usually puts it second, from what I've seen
<paulapatience>
(Calling the functions INVOKE-WITH instead)
<beach>
Right.
<paulapatience>
Putting it last means that the order is consistent with that of the corresponding macro (excluding any keyword parameters), even including the function, since it is essentially the body of the macro.
<paulapatience>
On the other hand, in mapping functions, the function usually goes first or second, to allow lists as &rest arguments
<beach>
My hunch is to put it second if there is a CLIENT parameter, and first if not.
<paulapatience>
I imagine that influences people's tendency to put such functions near the beginning
<beach>
But, again, I haven't given it much thought.
<paulapatience>
That's what I think I'm leaning towards as well. CLIM doing it sets some kind of precedence I suppose.
<beach>
paulapatience: Excellent proofreading work! I think I will take all your suggestions!
<paulapatience>
Glad to hear it.
Guest99 has joined #commonlisp
<paulapatience>
I believe we are similarly picky. It is only recently that I developed the ability to read papers rife with mistakes.
Guest99 has quit [Client Quit]
<beach>
Congratulations! I haven't been able to do that.
<beach>
The RVSDG paper I read (as I said above) was a tough one to read for me.
<paulapatience>
I actually co-wrote a book on writing scientific papers with my father.
<paulapatience>
So I have spent quite some time thinking about these issues
<beach>
Do you mean that the book was about writing scientific papers with your father, or did you write the book with your father? :)
<beach>
Anyway, congratulations!
<paulapatience>
Hah
<beach>
Yes, I see.
<paulapatience>
One thing I see in almost every (engineering, at least) paper is incorrect mathematical notation and use of SI units
<beach>
Oh, interesting. I though engineering was better than CS. In CACM, I often see stuff like "bla bla 100mph (x kph)". I mean "kph"?
<paulapatience>
Stuff like descriptive suffixes being italicized (and likely treated as multiplied, if LaTeX was used), units italicized, lack of space between value and unit, etc.
<beach>
Yes, I see.
<paulapatience>
s/suffixes/subscripts/
aurelius_nero has quit [Quit: Leaving]
<paulapatience>
Anyway, this is getting slightly off-topic
<beach>
For my part, I can't stand the traditional US use of "voltage", "mileage", "amperage", etc., instead of "tension", "distance", and "current".
X-Scale has joined #commonlisp
<beach>
I mean, you ask a person "how tall are you" and not "what is your inchage".
<paulapatience>
Haha
<danza>
:D
elderK has joined #commonlisp
<danza>
distance and voltage sound similar though
tane has joined #commonlisp
tane has quit [Changing host]
tane has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
<beach>
The term "voltage" confuses quantity and unit. The name of the quantity is "tension".
anticomputer has joined #commonlisp
<danza>
yeah something relevant especially with big countries not adopting a standard
<beach>
The US is pretty bad overall with those things.
<beach>
paulapatience: I very much appreciated the book "A Sense of Style" by Pinker.
<beach>
Anyway, time for a lunch break.
<paulapatience>
beach: We cite that one quite a bit
<chsasank>
paulapatience: I just went through LLVM's actual IR and it's actually quite complex. Nothing like simplicity of x86. I wanna try my hand my hand at backend. Any advice?
<paulapatience>
You mean you want to try generating x86 directly?
<ixelp>
Scheme Compiler in Incremental Steps: Compiling Integers - Sasank's Blog
<paulapatience>
Ah, you want to write a JIT?
<chsasank>
yes :)
<chsasank>
don't wanna leave the CL unless I have to
<paulapatience>
When you say 'use subprocess to run the generated assembly', are you referring to your need to invoke gcc in your earlier design?
<chsasank>
yes
random-nick has joined #commonlisp
dino_tutter has joined #commonlisp
dnhester has joined #commonlisp
<paulapatience>
I would expect that Cluster would allow you to generate x86 directly, and if you follow C ABI calling conventions, you could load your generated code and call it via CFFI
Equill has joined #commonlisp
<chsasank>
ok got it
<chsasank>
so CFFI will allow me to directly run C code? It'll invoke compiler on the fly?
<paulapatience>
It will not automatically invoke the compiler
<paulapatience>
It needs to know the signature of the functions you want to call
<paulapatience>
However, since you're the one generating those functions, you could define them directly on the Lisp side with defcfun
<paulapatience>
It has a C API, so you would have to wrap that with CFFI, possibly CFFI.C2FFI, but it seems like it would work
<chsasank>
ok
<paulapatience>
Note that I am not at all a JIT expert
<chsasank>
The issue with subprocess call is that it seems to be a bit slow
<chsasank>
but I guess I am over optimizing here 😅
<paulapatience>
I would agree that invoking a subprocess for the purposes of JIT seems off
<paulapatience>
I don't know how JIT compilation is normally implemented, though, so I cannot really help much
<chsasank>
ok
smlckz has left #commonlisp [WeeChat 4.1.1]
<random-nick>
if you have valid machine code in foreign memory then you can probably get a function pointer and call it via FFI?
<random-nick>
though I don't know if you have to do something extra to mark the memory pages executable
<random-nick>
regarding libgccjit, I think it can generate functions and call them directly without having to write anything to disk, but you can probably also generate a shared object and then load it into the CL system's process with FFI
<random-nick>
but emacs always uses libgccjit in a subprocess due to memory leaks iirc
<paulapatience>
random-nick: How does it use it in a subprocess?
<random-nick>
I don't know, but it uses the .so generation to write it to disk and then the main emacs process loads it with dlopen
<ixelp>
language agnostic - How could I generate and execute machine code at runtime? - Stack Overflow
<paulapatience>
(and even mentions SBCL)
<paulapatience>
chsasank: I suppose the machine code you are generating you wish to be able to call from Python too?
<chsasank>
paulapatience: thanks for these links. it would be nice to be able to call from python, yes
elderK has quit [Quit: WeeChat 4.1.1]
notzmv has quit [Ping timeout: 240 seconds]
<chsasank>
thanks for these links, will checkout
<paulapatience>
Then it seems to me like you would *have* to follow the C ABI in the machine code you generate
<paulapatience>
From what I gathered reading the stackoverflow answer, if you want performance you are better off using libgccjit or LLVM
<chsasank>
yeah following C ABI is kinda required. Else gcc segfaults. Learn a lot of ABI the hard way 😅
Inline has quit [Quit: Leaving]
<chsasank>
> A trick I often use on Linux is to emit some C (or C++) code at runtime in some temporary file (that is compiling some domain specific language to C or to C++), fork a compilation of it as a plugin, and dynamically load it. With current (laptops, desktops, servers) computers it is fast enough to stay compatible with an interactive loop.
<chsasank>
so it's kinda legitimate to do gcc subprocess lol
<paulapatience>
Yeah, exactly what you did, I saw
<random-nick>
oh yeah, and the overhead of starting a subprocess would probably be dwarfed by gcc's compilation time
monospod has quit [Quit: Konversation terminated!]
Farooq has joined #commonlisp
<Farooq>
Hello IRC! Long time no see!
<Farooq>
beach, Hello. I remember you because you helped me a lot back in my CL learning days. I see people have moved to LiberaChat now.
dnhester has quit [Ping timeout: 264 seconds]
<Farooq>
So I've been using Rust lately. And now I am coming to the conclusion that CL might've been a better choice for my research. I'm doing Genetic Programming, we evolve programs to become "fit" for a certain job. The reason I chose Rust over Lisp was because Rust is used in industry, there is job for it and there isn't for Common Lisp. But for research, the choice of language is free. I remember something regarding "code vs data" in Lisp. You can treat
<Farooq>
your code as data or vice versa. Am I right?
<beach>
Sort of. Code is represented as data in the language, and you can turn such code into something executable by using EVAL.
<Farooq>
In that case, Lisp can be extremely useful for me. Back to Genetic Programming, what if I could treat my data(programs to evolve) as code? And execute them? In any other language, you either have to interpret them or compile them and then execute them. I think CL has an advantage here? I can get compile step for free.
<beach>
But you can't turn compiled code into any useful data.
<beach>
The compile step is not free, you have to invoke either EVAL or COMPILE.
<beach>
And EVAL might call COMPILE.
<Farooq>
free as in I don't write a compiler myself
<Farooq>
I have to do this step with Rust, or just interpret the code as I do now.
<beach>
Yes, the Common Lisp standard requires the compiler to be part of any conforming Common Lisp implementation.
<Farooq>
BTW, is this room bridged to Matrix?
<Farooq>
beach, so I have some programs in memory and I want to see for a given input, what output they'll give. Simply EVAL?
<beach>
Sure ,(eval '(+ 3 4))
<ixelp>
(eval '(+ 3 4)) => 7
<Farooq>
very good
<Farooq>
I never thought I would return back to Lisp
<beach>
Here (+ 3 4) is a list of 3 elements, so it's data. EVAL turned it into code.
<Farooq>
Okay how can I mutate this list?
<Farooq>
If I remember correctly, we had to use LET for lexical things. Then we have lexical variables we can mutate
<Farooq>
If it's just a list, this means I can simply use list elements. Right?
<beach>
You can't mutate a literal list like that, but if you build the list, you can mutate it. ,(let ((code (list '+ 3 4))) (setf (third code) 5) (eval code))
<Farooq>
Actually, Common Lisp was used in the early days of Genetic Programming. Then people turned into other languages like Java, C++ and Python
<Farooq>
Like before 2000 my birth year
<beach>
I am sorry to hear that they did that.
<beach>
It was probably the new people using those languages.
<beach>
Like I often say, people go to a lot of trouble to avoid learning Common Lisp.
<danza_>
:D
<Farooq>
Not sure. I'm not up with history. But I know that authors of Tree Genetic Programming and Stack Genetic Programming used Common Lisp
<Farooq>
Or some other Lisp maybe
Guest99 has joined #commonlisp
<Farooq>
But in newer papers, I see people using other languages. Or that code is not mentioned at all.
<Farooq>
Actually, Rust has macros which are similar to Common Lisp macros. Unfortunately, Rust hasn't got data as code feature of Common Lisp as far as I know
<beach>
Then its macros must be way more complicated than those of Common Lisp, because Common Lisp macros depend precisely on the fact that code is represented as data in the language.
Guest99 has quit [Client Quit]
danza_ has quit [Read error: Connection reset by peer]
<scymtym>
i think rust has multiple kinds of macros. if i recall correctly, least one kind works as a preprocessor that accepts a stream of tokens and emits a modified stream of tokens
<beach>
So that kind is definitely not like Common Lisp macros.
<Farooq>
Rust macros are good. Maybe not as good as Common Lisp but definitely better than C's
<Farooq>
Re: Is this room bridged to Matrix?
dcb has joined #commonlisp
<Farooq>
Now that I have to use Lisp. What other options are out there other than Common Lisp and with the same performance? Common Lisp performance can be as good as C, I remember this.
<Farooq>
Actually, I translated Verna's paper to Persian myself
<beach>
Performance is a matter of implementation rather than language, and I believe Didier was using SBCL.
<beach>
SBCL might be the one that generates the fastest code at the moment. I don't know of any other Lisp-like languages with an implementation that generates code this fast, but then, I haven't looked very closely.
<beach>
There might be some good Scheme implementations out there.
<Farooq>
No Didier wasn't using SBCL. But as we both tested back then, SBCL was as fast, too.
<Farooq>
Unfortunately, it wasn't fast on ARM
<Farooq>
We tested on x86_64
Oddity has quit [Ping timeout: 256 seconds]
<beach>
So what implementation was Didier using?
edgar-rft has quit [Remote host closed the connection]
<Farooq>
Lemme see
<beach>
I was convinced his papers used SBCL.
<Farooq>
CMUCL I think?
<beach>
Hmm.
<Farooq>
yeah CMUCL it was
<Farooq>
I am not a fish memory \:D/
<beach>
I see.
<Farooq>
Yes you must see. All friends call me fish memory. This proves they are gravely wrong
<Farooq>
I will show them how much camel memory I am
a51 has quit [Ping timeout: 256 seconds]
wacki_ has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
azimut has joined #commonlisp
deadmarshal_ has quit [Ping timeout: 272 seconds]
X-Scale has quit [Quit: Client closed]
wacki has joined #commonlisp
Farooq has quit [Remote host closed the connection]
Inline has joined #commonlisp
jjnkn has quit [Ping timeout: 252 seconds]
ronald_ has quit [Ping timeout: 272 seconds]
iska` has quit [Ping timeout: 252 seconds]
cage has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
jjnkn has joined #commonlisp
jonatack has quit [Ping timeout: 246 seconds]
fitzsim has quit [Ping timeout: 260 seconds]
dnhester has joined #commonlisp
dnhester has quit [Ping timeout: 268 seconds]
igemnace has joined #commonlisp
igemnace has quit [Quit: WeeChat 4.2.1]
igemnace has joined #commonlisp
notzmv has joined #commonlisp
josrr has joined #commonlisp
deadmarshal_ has joined #commonlisp
traidare has quit [Ping timeout: 268 seconds]
chomwitt has joined #commonlisp
chomwitt has quit [Max SendQ exceeded]
chomwitt has joined #commonlisp
waleee has quit [Ping timeout: 272 seconds]
zetef has joined #commonlisp
szkl has joined #commonlisp
tane has quit [Remote host closed the connection]
azimut has quit [Ping timeout: 260 seconds]
chomwitt has quit [Ping timeout: 246 seconds]
zetef has quit [Remote host closed the connection]
ebrasca has joined #commonlisp
occ has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
Guest99 has joined #commonlisp
holycow has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
dnhester has quit [Ping timeout: 246 seconds]
msavoritias has quit [Remote host closed the connection]
<thuna`>
How do you see what sources asdf is currently looking at?
pranavats has joined #commonlisp
dnhester has joined #commonlisp
deadmarshal_ has quit [Ping timeout: 264 seconds]
rtypo has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
<jjnkn>
Has anybody used the SERIES facility and had a need to generate a series imperatively? I want to construct a series of pathnames by recursively traversing a file tree and it must be done lazily. I gather that I can do this using the PRODUCING macro, but I'd rather not since it imposes a lot of restrictions on its users.
dnhester has quit [Ping timeout: 268 seconds]
dnhester has joined #commonlisp
<josrr>
thuna`: you can get the source directory of a system with (asdf:system-source-directory (asdf:find-system "system-name"))
ymir has quit [Ping timeout: 264 seconds]
<thuna`>
I imagine if you can see a particular asd file in (ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY), ASDF:LOAD-SYSTEM should be able to find it. But in my case, it doesn't. What gives?
<thuna`>
josrr: I would do that but I can't find the system
<thuna`>
I'm trying to understand why
dnhester has quit [Ping timeout: 264 seconds]
istewart has joined #commonlisp
deadmarshal_ has joined #commonlisp
<foretspaisibles>
Question about "defined objects" and their identifiers. Say I have a class outcome and create the function
<thuna`>
Ok, ASDF:*SOURCE-REGISTRY* is populated so I guess that is the problem. Setting it to nil seems to make it work.
<josrr>
foretspaisibles: That's a guess, I've never used it.
dnhester has quit [Ping timeout: 252 seconds]
traidare has quit [Ping timeout: 255 seconds]
chomwitt has joined #commonlisp
<younder>
Does parenscript allow macro's? When I tried (defmacro wait-doc (&body body) (chain ($ document) (ready ,body))) it generated waitDoc in the output.
nij- has joined #commonlisp
<nij->
Why is lisp's interactivity praised so much? I mean, say, in python, we can also redefine the function (for a name) on the fly, and the result applies elsewhere too. https://plaster.tymoon.eu/view/4164#4164
dnhester has joined #commonlisp
<younder>
nij, that's fine, Python can too. However Lisp has macro's
<foretspaisibles>
josrr: Thanks, this looks good!
<nij->
I understand that lisp has other advantages (e.g. macros). But I have heard this several times.. and I can't make sense of it. Some praises maybe irrational, so I want to find out.
<thuna`>
The restart system is a big part of what people refer to when they say "lisp is interactive" I think
zetef has quit [Ping timeout: 252 seconds]
<nij->
thuna` Yeah, I appreciate the restart system part. :) It doesn't unwind the stack when shits happen.
<younder>
joshrr thanks. It seems they have their own macro definition functions.
<foretspaisibles>
It is very possible to develop interactively in CL. That can be seens as test-driven development. To me it os a real strength of CL. First, because it's fun, second because it's fast, third because it leads to simpler and more beautiful programs.
<nij->
foretspaisibles I totally agree :) CL is awesome <3
<younder>
nij common-lisp also generates code that runs about 25 times faster than python's
<foretspaisibles>
Programs developed interactively are simpler and more beautiful because the API is more used, and is used by a human :-)
<nij->
Thanks for the input. Still, I wish to stick with my original question.
<foretspaisibles>
If you write a webapp in CL, you can change the server while it's running. In many languages that's unreliable black magic -- I had to do that with C++ in Viausl Studio years ago.
<foretspaisibles>
Quite a sad memory.
<foretspaisibles>
I never ever saw people work the same way with Python.
<younder>
joshrr (defpsmacro wait-doc (&body body) `(chain ($ document) (ready ,body))) works like a charm :)
<aeth>
nij-: it's not just about redefining, it's about how you develop your program
<aeth>
Python is still batch-oriented, driven by running script files from the command line
<ixelp>
Stop Writing Dead Programs, Strange Loop 2022
<nij->
When writing python programs, I also have a running repl.. and I can redefine stuff there.
<aeth>
In Common Lisp, you're expected to grow an image from the REPL (and from recompiling files that go to the REPL)... it's also recompiling, i.e. a compiler
<foretspaisibles>
It really focuses around interactivty, and Jack Rusher does a great presentation.
<aeth>
On the spectrum of redefining, there's C/C++ on one end (where "hot [re]loading" is a difficult feature that C++ things advertise)
<aeth>
and Smalltalk on the other end (where it's basically all image)
<aeth>
CL is very close to, but not quite at, Smalltalk
chsasank8 has joined #commonlisp
<nij->
foretspaisibles: Thanks, I will rewatch that later.
<aeth>
Python's probably solidly mid, still batch-oriented in its thinking, but compared to C++ it's very interactive
<josrr>
younder: good to know, it never occurred to me to use macros in parentscript.
<aeth>
it's a bit more interactive when using something like Jupyter
<nij->
aeth : Yeah, I feel the same too. But what's the reason behind that python is still "less interactive" than lisp?
<aeth>
nij-: because Python's still batch-oriented.
<aeth>
rather than image-oriented
<aeth>
it's not quite as obvious because it's an interpreter so there's no compilation step at all, but it's still about driving things from the shell
<nij->
aeth BY compilation do you mean compilation to native code?
<aeth>
consider e.g. that you do pip install (if that's still the way to do it?) from the command line, mess with virtualenvs from the command line, etc.
rtypo has quit [Ping timeout: 268 seconds]
<foretspaisibles>
yes
<nij->
python does compile to its byte machine.
<foretspaisibles>
try disassemble in sbcl
<aeth>
meanwhile, Common Lisp exposes an actual native code compiler (in most implementations, anyway) from the REPL
chsasank has quit [Ping timeout: 272 seconds]
chsasank8 is now known as chsasank
<aeth>
so Common Lisp winds up being more REPL-driven than most popular interpreted languages
<foretspaisibles>
more than technical the question is also cultural
<nij->
(Some implementations compile to C, but yeah, many do for native code.)
rtypo has joined #commonlisp
<aeth>
and CLISP (which fortunately isn't very popular anymore because the only thing it really has going for it is readline in the in-terminal REPL) is bytecode interpreted
<nij->
aeth, How do you jump to this conclusion? "so Common Lisp winds up being more REPL-driven than most popular interpreted languages"
<foretspaisibles>
I write full programs in CL interactively and I only write itneractively. That's a common thing with CL. I never ever saw people doing the same with other languages even if that seems possible.
<foretspaisibles>
Python, Scala, OCaml, or Perl if you want
<nij->
foretspaisibles : me too, and me too :)
<aeth>
nij-: because in Common Lisp, you bring up something like SLIME, and then do everything through the REPL that you'd do through the Unix POSIX shell in interpreted languages, all running multithreaded within one process, constantly recompiling native code, etc.
<aeth>
and you can even save and reload this image, smalltalk-style
<nij->
aeth Yes! Could SLIME/SLY be the true reason?
<aeth>
but image-oriented programming is the point of a Lisp like Common Lisp, with only Smalltalk leaning into it more
<nij->
I mean, it's not about the nature of the language. It's that CL has mrepls, but JS or python don't.
<aeth>
JS is probably pretty close these days, too, with its JavaScript console integrated into a browser. Though it's sandboxed and one-process-per-tab with async threading in one system thread afaik.
<foretspaisibles>
The culture of developping interactively was here before slime/sly. The CL community values this approach so there are quality tools to do that. Other do not value that, so they lack the tooling.
<aeth>
The closest you get to something like this in Python would be Jupyter notebooks, but you don't drive everything through them, or at least it's not really a good development experience for that, in part because you're constantly reevaluating arbitrary sections of code so it doesn't read top-to-bottom so it's easy to get an image spaghetti from it that can't even be reproducible
<foretspaisibles>
aeth: The Java folks now have GraalVM :-D
<aeth>
The cleanest way to handle Jupyter with Python is to mostly just load libraries written in some traditional editor
<nij->
aeth - python also has a thing called python-manhole. After installing it into a project, the python runtime is exposed to a socket, waiting for instructions. This is pretty much like mrepl.
<foretspaisibles>
aeth: Yes, Jupyter notebooks are great for discovery and experimentation not really for solid software development.
<nij->
So after seeing this example, I'm shaky on whether CL is truly more interactive. Or is it just about the culture and ecosystem.
<aeth>
Though just like with CAS (computer algebra system) notebooks or Jupyter notebooks, sometimes you just want to restart and reload the whole thing just to make sure you're evaluating on current state. Though the linear REPL makes it less likely to get bad state. Mostly happens when you rename a function and some things are still calling the old name.
cage has quit [Quit: rcirc on GNU Emacs 29.1]
<aeth>
nij-: It's both. Because there are things like save-lisp-and-die in SBCL, but in general, ways to save the image so in theory you'd never have to restart from source (but that's kind of a bad idea to use it that interactively because then there's no authoritative copy of the source code at all)
<nij->
(Emacs with python mode also acts like an mrepl too.)
<aeth>
Smalltalk prefers saving-image more than CL
<aeth>
nij-: But also note that Common Lisp is a native AOT compiler being compared to interpreters/JIT in terms of interactivity.
<aeth>
Because, sure, maybe you could hack together something like SLIME in Python (but nobody uses it and libraries might break because nobody develops that way)
<aeth>
But it's still a slow bytecode interpreter at the end of the day
<nij->
Thanks :) I'm convinced that it's just culture and ecosystem - not about the nature of the language.
<aeth>
CL really tries to make you have your cake (interpreter-style dynamism) and eat it too (performance).
wacki has joined #commonlisp
<aeth>
Though it breaks down in a few places, like structs, which are undefined behavior to redefine but are good for performance in places.
<aeth>
And this is without the far more recent developments in JIT.
jjnkn has quit [Quit: leaving]
<nij->
CL is AOT but not JIT?
<nij->
I can see the code compiled at the moment I "evaluate" it..
<aeth>
compile function (SBCL uses the compiler at the REPL!) or file or compilation-unit AOT -> immediately run function or file or compilation-unit
<aeth>
a fast enough compiler (though it means you can't be quite as optimized as compilers who let you take all of the time in the world) means it feels interpreted (on modern machines, anyway)
<aeth>
(it also means that the optimization barrier is generally the file)
<aeth>
(the equivalent of "link time optimization" between files would be very hard to do in CL)
<aeth>
There is a price to pay, though. A bit of indirection. If you can recompile any function, that means that there has to be some indirection so you look up name->address every time.
<aeth>
Because you're calling the name, and the name refers to a function that can be recompiled at any time.
<_death>
nij: what happens to existing python instances when you redefine a class? does python have a defvar operator?
<nij->
_death Oh, that too. Right.
<_death>
nij: I don't expect an answer to these questions, because python (the language) is off topic
<nij->
I actually don't know..
<aeth>
the only place where CL would really benefit from JIT is in method calls
<aeth>
except the CLs that compile to bytecode
pve has quit [Quit: leaving]
zetef has joined #commonlisp
Inline has quit [Quit: Leaving]
zetef has quit [Remote host closed the connection]
dra has joined #commonlisp
Inline has joined #commonlisp
Inline has quit [Quit: Leaving]
<thuna`>
zlib's inflate.cl has a VERSION= but what is that from?
<thuna`>
Hmm, I really can't get asdf (in stumpwm) to find the appropriate systems. I do (asdf:clear-configuration) with the systems directory present in both the root and user source-registry.conf and source-registry.conf.d's and none of it works.
akoana has joined #commonlisp
<thuna`>
...and even when I do it tries to access a non-existing directory due to gentoo jank so this might just be beyond the scope of #commonlisp. I'll see what I can do I guess :shrug:
<josrr>
It seems that stumpwm also populates asdf:*central-registry*.
<thuna`>
It does, but clearing it out doesn't help, unfortunately
<thuna`>
(I set it to nil manually as well, but I expect ASDF:CLEAR-CONFIGURATION to handle it in the first place)
<zyd>
thuna`: I usually run `(asdf:clear-source-registry)` when I add new systems. Then I can load them as asdf find them.
<thuna`>
zyd: Yeah, I tried that as well, but it did not help.
<zyd>
In ~/.config/common-lisp/source-registry.conf.d/projects-lisp.conf I have this line: (:tree (:home "projects/lisp/"))
<zyd>
Does yours look similar? just double checking
<thuna`>
Mine is (:directory (:home ".local/share/common-lisp/systems"))
<zyd>
Hm, I wonder if you might need the :tree part assuming there as directories inside the systems dir there.
<thuna`>
Nope, it's flat
<zyd>
Gotcha
<thuna`>
I think something broke when the image was dumped, because this is happening in stumpwm
<zyd>
Oh, StumpWM. IIRC when I tried it I had to yank my teeth trying to get asdf to work. Its very weird.
<thuna`>
If it threw me into debugger this would be so much faster too
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
bilegeek has joined #commonlisp
rgherdt has quit [Quit: Leaving]
tyson2 has joined #commonlisp
rendar has quit [Ping timeout: 268 seconds]
amb007 has quit [Ping timeout: 264 seconds]
josrr has quit [Remote host closed the connection]