aindilis has quit [Remote host closed the connection]
astalla has joined #lisp
aindilis has joined #lisp
orivej has joined #lisp
<LdBeth>
Stared
<aeth>
of course Shinmera wrote one
<Shinmera>
What's that supposed to mean
<aeth>
Shinmera is prolific
<Shinmera>
Statistically, compared to the things I haven't written yet, I have not written anything at all :)
<aeth>
158 repos. I would have guessed 400
<LdBeth>
#'no-defun-allowed: yes there are whole pages of them
<Shinmera>
aeth: It's missing the 59 repos from Shirakumo
jack_rabbit has joined #lisp
<aeth>
Shinmera: did you write an infix library? it would be interesting to compare the various solutions people have for implementing one
<Shinmera>
I have no interest in infix, so no
<Shinmera>
glsl-toolkit parses infix formulas of course, but that's not for Lisp source.
<aeth>
I have no use for infix, but I got distracted by it because I think there can be some elegant solutions there.
cage_ has joined #lisp
<aeth>
I made a solution that at the moment is only designed to work with binary operators with no precedence rules (it's an error to write 1 + 2 - 3 because there's no precedence). https://gitlab.com/snippets/1747132
<aeth>
e.g. (infix 1 + 2 + (3 - 4))
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
DataLinkDroid has quit [Ping timeout: 240 seconds]
<aeth>
Technically (infix 1 cons 2) would also work if someone wanted to create a monster.
nsrahmad has quit [Remote host closed the connection]
<aeth>
I do exactly the reverse
<aeth>
(I generate GLSL strings given s-expressions)
<Shinmera>
My approach allows me to copypasta shader files from the internet :)
<Shinmera>
Hopefully at some point I can convince Baggers to make Varjo output to glsl-toolkit's AST so that the two can be combined easily.
<aeth>
there are afaik two more mature attempts than mine at generating GLSL, if not three
<aeth>
including varjo
<Shinmera>
I don't doubt it. Writing an sexpr syntax is very tempting (and not too difficult)
<Shinmera>
I'm only really interested in Varjo because it does more than that
DataLinkDroid has joined #lisp
<aeth>
The other GLSL generators' goals are actually to make it interchangeable with CL for easy refactoring afaik.
<aeth>
My goal is to eventually move my backend to SPIR-V and make it a proper language.
<aeth>
I can definitely see why Varjo's integration with a math library has it's users, though.
orivej has quit [Ping timeout: 268 seconds]
<aeth>
Shinmera: was 2018 your first ELS?
<Shinmera>
I've been to ELS since 2015.
* Ober
images ELS to be the same crowd of folks who would rush to greet an Alien saucer landing.
<Ober>
.oO(are these the people we want the aliens to meet first...)
<aeth>
Ober: It's unlikely that an alien visitor to Earth would still be biological, so of course everyone would want to know what their source code looks like.
bendersteed has joined #lisp
FreeBirdLjj has joined #lisp
<beach>
Ober: Quite normal people if you ask me. Lots of variation though.
gitfaf has joined #lisp
bendersteed has quit [Remote host closed the connection]
housel has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
gitfaf has quit [Remote host closed the connection]
<edgar-rft>
Isn't anything a variation of normal?
smokeink has joined #lisp
taof has joined #lisp
taof has quit [Ping timeout: 252 seconds]
mkolenda has quit [Remote host closed the connection]
mkolenda has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
random-nick has joined #lisp
bendersteed has joined #lisp
light2yellow has joined #lisp
igemnace has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
makomo has joined #lisp
orivej has joined #lisp
gitfaf has joined #lisp
gitfaf has quit [Ping timeout: 264 seconds]
moei has joined #lisp
defaultxr has quit [Ping timeout: 264 seconds]
vlatkoB has quit [Remote host closed the connection]
<makomo>
but isn't that a separate problem? i guess i wasn't too clear. what i was getting at with "it must be in the same file" was for the case when all of the macro's dependencies are within the same file as that macro
<makomo>
that's when you need to use EVAL-WHEN
taof has quit [Ping timeout: 264 seconds]
<Shinmera>
If the dependencies are in separate files, but the files are all compiled without being loaded, you still need to use eval-when.
<makomo>
ah, right, that's true
<_death>
again, no.. if you move the macro-using forms to another file that gets loaded afterwards, then you don't need eval-when
<Shinmera>
In the general case of an ASDF sequential-plan, this case won't occur, but it really has nothing to do with files, but simply with the order in which the phases happen to which parts of code.
<makomo>
_death: i'm talking about the macro itself and its dependencies, not the dependents
gitfaf has quit [Ping timeout: 264 seconds]
<_death>
makomo: me too. if you have a macro and a function that it calls when expanded, there's no need for eval-when if there's no expansion of it happening in the same file
<Shinmera>
defun is specified to only have load-time side-effects, so you need to eval-when it if you need it to have compile-time side-effects, that's all.
<Shinmera>
*load-time/execute
<pjb>
It's worse than that! If you compile the files without loading them, then it's possible that no compiled definition is known after compile-file returns!
<makomo>
Shinmera: yeah, true, it isn't intrinsically related to files. it's just that i think of it that way since the lisp compilation process specifically mentions files
<makomo>
_death: oh hm, i see what you mean
<pjb>
The compilation environment is not necessarily the same as the startup environment! It can be a new environment created by compile-file, and thrown away once compilation of the compilation-unit is finished.
random-nick has quit [Ping timeout: 268 seconds]
<pjb>
(with-compilation-unit (compile-file "a.lisp")) (compile-file "b.lisp") would let the compiler know what has been compiled in a.lisp while compiling b.lisp, but it wouldn't be sufficient, since the result of that former compilation may be not available. You would still have to wrap the functions definition in a needed by b in an eval-when.
<makomo>
pjb: was that supposed to be (w-c-u () (c-f ...) (c-f ...))?
gitfaf has joined #lisp
<pjb>
Exact.
gitfaf has quit [Ping timeout: 264 seconds]
Kundry_Wag has joined #lisp
<pjb>
makomo: the thing is that even inside the compilation environment (and this is why it's a distinguished concept), compiling eg. a defun doesn't insert into the compilation environment the body of the function, but only the declaration that the name will be fbound at run-time (and possibly other notations such as types of arguments and results, etc).
<pjb>
This is why loading into the environment before calling compile-file, or using eval-when is required.
gitfaf has joined #lisp
<pjb>
It may seem strange when you think about usual CL implementation, but consider ecl, where the compiler calls gcc to generate an object file. Without an explicit dynamic linking of those object files at run-time, there's no way the compiled definitions would be available in the lisp process.
<pjb>
This allows also the compiler to be non-atomic and to take its time to compile and optimize. Then loading a fasl can be made atomic, and replace in a consistent way a set of functions.
<makomo>
pjb: i'm half familiar with that. i read about the compilation environment being distinct and the various uses for EVAL-WHEN but have forgotten some of it by now.
<makomo>
pjb: that bit about ecl is pretty interesting
angeru has joined #lisp
<pjb>
makomo: that's where asdf (or other system definition systems) come about. It manages the dependencies between the files, and ensure they're loaded before they're needed.
gitfaf has quit [Ping timeout: 264 seconds]
trittweiler has quit [Ping timeout: 244 seconds]
<makomo>
when the spec says "The evaluation environment is a run-time environment ..." and "The run-time environment is the environment ...", are the uses of the word "run-time environment" here distinct?
<makomo>
the former is a characterization of the "evalution environment", while the latter is an actual name for a distinct environment?
<makomo>
so technically a run-time environment is a run-time environment too? :-D
<pjb>
Yes.
<pjb>
There's a category of environments called "run-time environment", and there is a current environment that is a "run-time environment" and that is called the run-time environment.
gitfaf has joined #lisp
<pjb>
(There may be several run-time environments, but in usual implementations, they're all the same; but it's not necessary).
<makomo>
right. a bit convoluted but oh well. i have nothing against such terminology really because it's natural to overload words, but i don't like when it's not mentioned/clarified by a document
<pjb>
The important point here, is that the environment where macroexpansions are evaluated (which is a run-time environment), MAY BE DIFFERENT from the startup environment (which is a run-time environment).
<pjb>
This means that: (defvar *m* 0) (defmacro m () (incf *m*) nil) (m) *m* -> 0 is possible.
<pjb>
even at the REPL.
<no-defun-allowed>
Goodnight everyone!
<makomo>
no-defun-allowed: night
<pjb>
It will surely occur if you put (defvar *m* 0) (defmacro m () (incf *m*) nil) in a file and use compile-file, then load the fasl in a new image.
random-nick has joined #lisp
<pjb>
I would advise in general, to replicate the side effects in the expansion: (defmacro m () (incf *m*) `(progn (incf *m*) nil))
<pjb>
(like, when you want to store metadata in tables, that you want to be available both at compilation time and at run time).
gitfaf has quit [Ping timeout: 264 seconds]
moei has joined #lisp
<makomo>
pjb: and could the same problem be solved using EVAL-WHEN?
<pjb>
Yes, in a way. But often the side effects are used by the macro itself to determine the expansion, so eval-when wouldn't do.
<pjb>
(defmacro m () `(eval-when (:compile-toplevel :execute) (incf *m*) nil))
<pjb>
in practice you can also have the case: (defmacro m () (incf *m*) `(progn (incf *m*) ',*m*)) where (m) returns the value of *m* from macroexpansion time.
<pjb>
Of course, *m* is just an example, it could be some type information, some grammar rule compiled at macroexpansion time, real stuff.
gitfaf has joined #lisp
<pjb>
Also, it is better if you can just define simplier macros and functions in separate files and load them and compile in the right order, rather than using eval-when and sophisticated plays between the environments like that. But it's not always possible.
<pjb>
From a software engineering point of view, I'm not saying that having a single environment and mutating at will at any time is worse. It can simplify things. But it is much less reproduceable, since dependencies can easily become circular. Nowadays, we prefer to have reproducible builds, where dependencies are clear and explicit.
<pjb>
So we can have automatic tests, Continuous Integrations, etc.
<makomo>
pjb: i see. and DEFVAR doesn't need any EVAL-WHEN treatment for this incrementing at compile-time?
gitfaf has quit [Ping timeout: 264 seconds]
Kundry_Wag has quit [Ping timeout: 252 seconds]
<makomo>
so the relation between the environments is compilation >= evaluation >= startup. the fact that it's an inequality is where the portability issues appear
gitfaf has joined #lisp
<makomo>
and how is the "startup environment" different from the "run-time environment"? the "startup environment" is a "snapshot" of the "run-time environment" before compilation took place, but can anything change the "run-time environment" during compilation?
<pjb>
makomo: defvar and defparameter initialize the variable at run-time. At compilation time, only the fact that those symbols are special (dynamic binding) is noted.
gitfaf has quit [Ping timeout: 264 seconds]
<pjb>
If a defvar or defparameter form appears as a top level form, the compiler must recognize that the name has been proclaimed special. However, it must neither evaluate the initial-value form nor assign the dynamic variable named name at compile time.
<pjb>
well the startup environment can be the run-time environment, or can be a copy of it.
<pjb>
For example, since any form can be evaluated at compilation time, it would be a perfectly good design, to fork a new unix process into a chroot jail at the beginning of compile-file. Then you could compile code obtained from the wild. In that case, the startup environment would technically be the runtime environment in the new unix process, but it would also be a clone of the original runtime environment in the calling image.
<makomo>
pjb: right, so with the first *m* example above, the name *m* is unbound at compile-time (assuming a clean startup environment, even if startup == compilation, *m* would still be unbound). how is the macro able to incf it then?
<pjb>
makomo: A lot of those definitions are actually legalese written to allow different kinds of implementations.
<pjb>
makomo: good point. It's bug, I would have to use eval-when :compile-toplevel around the defvar.
<makomo>
that's what i'm interested at
<makomo>
i didn't see how *m* could be available at compile-time
<pjb>
This is important. The problem is that it is not a problem until you use compile-file and a clean environment.
<pjb>
In the repl, or in slime, it would work, because we don't use compile-file.
<makomo>
right, because the compilation environment inherits stuff from the startup environment?
<pjb>
yep.
<makomo>
i was a bit thrown off by the "even at the REPL", because i thought that somehow the REPL case was the curious one
<pjb>
Interactively, it's COMPILE that's used, not COMPILE-FILE, and with slime if we use compile-file, it's called from the interactive runtime environment where such toplevel forms have already been evaluated. (C-x C-e or loading the file).
<makomo>
well both are, because you were demonstrating the relationship between the environments
<pjb>
makomo: in a way, yes, it's the curious one. But it's also the usual case for lispers.
<makomo>
mhm
<pjb>
We usually work at the repl (or in slime, same thing).
<makomo>
yeah, of course :-D
<makomo>
i still don't see the exact difference between "startup environment" and "runtime environment", or rather, i don't see how "startup environment" is a new "type" of environment when it's just a particular instance of the run-time environment
<pjb>
But when it's time to generate the application, I use a generate.lisp script that is loaded without the rc files, and that will load ~/quicklisp/setup.lisp and quickload the system to compile and load it (often after having cleaned up ~/.cache/common-lisp/ for a clean build), and to save the lisp image. This clean environment is quite different from the development repl/slime environment where we accumulate cruft. So often such
<pjb>
startup environment is the "runtime environment" where (compile-file …) is called.
<pjb>
It's just to distinguish it from eg. the "runtime environment" where macroexpansion occurs.
<pjb>
If they are different, then side effects from macroexpansion won't be seen after compilation.
<pjb>
If they're the same, then side effects from macroexpansion will be seen after compilation.
<pjb>
(defun compile-file (…) (let* ((startup-environment (current-environment)) (evaluation-environment (clone-environment startup-environment)) (compilation-environment (clone-environment evaluation-environment))) (compile-with-environments evaluation-enviroment #| = for macroexpansion |# compilation-environment #| for eval-when :compile-toplevel and compilation-time effects |# …)))
<pjb>
clone-environment can effectively duplicate the environment or can be identity, returning the same, depending on the implementation.
<makomo>
pjb: just to dig a little deeper: the fact that this potentially new environment inherits from the startup environment means that it shares the variables (the bindings). however, the name *m* exists in different namespaces (environments) so when (incf *m*) is done, it changes the binding only in this new environment?
<makomo>
a thing that ties into this and that's been bugging me for a while is how exactly "value cells" behave, namely how the assignment vs. binding thing fits into that picture
<makomo>
i know that "value cells" are traditional terminology and that the "cell" doesn't really belong to the symbol but to the environment, right?
<makomo>
but when you do (setf *m* 10), what exactly happens? is it even assignment if it changes the symbol-value of *m* which is supposedly part of the environment, not the symbol?
Patternmaster has joined #lisp
<makomo>
why this confuses me is the fact that, if the environments share the bindings (assuming this is even correct) and point to the same integer 0, and if SETF does in fact assign (which it surely does, but i'm confused again) wouldn't SETF-ing either of the *m*s then change the underlying integer?
<makomo>
something in this picture is obviously wrong, but i don't know what exactly
<makomo>
(cont.) ... change the underlying integer? the side-effect would then surely be visible in both environments whether or not the environments were independent or not?
ebrasca has quit [Ping timeout: 272 seconds]
bendersteed has joined #lisp
<makomo>
were independent?*
trittweiler has joined #lisp
mason has joined #lisp
bendersteed has quit [Remote host closed the connection]
<beach>
makomo: The standard is written so that it is possible to have a slot in the symbol for the global value as a special variable.
<beach>
makomo: If an implementation does that, then all global environments are basically the same.
<beach>
Put differently, there is only one global environment in the system. And it is "spread out" in that part of it is symbol slots, part of it in hash tables that are the values of global variables, etc.
<beach>
makomo: But, a better way of thinking about it is that there is some kind of first-class global environment object that contains the bindings.
<beach>
makomo: Then you could separate the compilation environment, the startup environment etc.
razzy has quit [Read error: Connection reset by peer]
<beach>
makomo: I invented it so that I could cross compile SICL in a "natural" way.
<makomo>
beach: what would be the difference between "symbol slots" and "the values of global variables"? aren't these values contained within these slots?
<makomo>
beach: that's exactly where i got the idea from :-), we mentioned it before
razzy has joined #lisp
<beach>
makomo: In a system where symbols have slots for special variable values, the symbol slot would contain the global value of the variable.
<Bike>
if you write a simple metacircular lisp interpreter, you'll usually have a separate environment object with the values in it, rather than storing them in the symbol itself (since there's no way to do that yourself exactly)
<Bike>
same deal as that
SaganMan has joined #lisp
<beach>
makomo: In a system like SICL, there is no slot in symbols that have anything to do with the global value of that symbol as a variable.
<makomo>
beach: right, so in a system like that you wouldn't have the hash tables? in other words, the slots and the hash tables can't coexist, right?
<makomo>
either you pick one or the other technique
<beach>
Oh, the environment contains hash tables instead.
<beach>
You still have to map a symbol name to a binding.
<beach>
So in fact, the first-class global environments of SICL contain several hash tables.
<beach>
One for mapping symbols to variable bindings.
<beach>
One for mapping symbols to type definitions.
<beach>
One for mapping symbols to method-combination objects.
<beach>
etc. etc.
<makomo>
ohhh, now i see. it never occured to me that you could have stuff other than variables/functions in the environment :-D
on_ion is now known as oni-on-ion
<makomo>
that's why it's spread out if you decide to use slots -- value/function cells as part of the symbols, but then the type definitions, etc. within the hash tables?
<beach>
Yeah, it's weird.
<makomo>
and i guess you could go full on with the "slot implementation" and for example store type definitions as part of the symbol too?
<makomo>
i understand it's purely an implementation thing, but you could do it theoretically i guess
<beach>
In some systems it is even the case that the function names corresponding to symbols have slots in the symbols, but the ones that have names like (setf <symbol>) are contained in a separate hash table.
<Bike>
you could, but then you start having a lot of empty slots in every symbol.
<makomo>
Bike: mhm
<makomo>
beach: oh interesting
kajo has quit [Remote host closed the connection]
<beach>
In SICL, a symbol has only a PACKAGE slot and a NAME slot.
<makomo>
the confusing thing now is that thinking in terms of these "cells"/"slots" gives you a "location"/"place" to think about when talking about assignment
kajo has joined #lisp
<makomo>
but when you get rid of these slots and go the "hash table way", what happens when you SETF a symbol?
<makomo>
the binding is replaced within the environment?
<beach>
Yes, it is not very good on the part of the Common Lisp HyperSpec to use terminology that suggests this kind of implementation.
<beach>
So, in SICL, the bindings associated with variables etc are "cells", mainly just an indirection. I use CONS cells for that.
<beach>
So when you SETF a variable or (setf (fdefinition ...)) of a function, then you change the contents of that cell.
<makomo>
i was thinking of that idea just a moment ago!
<makomo>
huh, wow
<trittweiler>
beach: No hash-code in a symbol?
<beach>
trittweiler: I may have to add that.
<beach>
makomo: Think of it as moving the slot in the symbol to the environment.
<makomo>
so something like "<name> -> <cons cell> (the "cell") -> <the value>"?
<beach>
trittweiler: Then maybe not.
<beach>
I can use the address of the symbol.
<beach>
makomo: If someone asks for (symbol-value <symbol-name>), yes.
<beach>
makomo: But in code, if you just do *variable-name* then the first part is resolved at load time.
<beach>
So there is no loss of performance.
<makomo>
beach: i was going to ask about that. very nice
<beach>
trittweiler: The plan is to promote symbols used as hash keys to the global heap.
<beach>
... where they won't move.
<makomo>
so then indeed SETF-ing a symbol is assignment and not some binding erasing sorcery
<beach>
No, no.
<beach>
Just change the contents of the slot.
<Bike>
binding erasing...?
<makomo>
beach: yes, "assigning that slot", is that not correct terminology?
<beach>
makomo: Assigning "to" a slot perhaps.
<beach>
Changing its contents sounds better.
taof has joined #lisp
<beach>
makomo: There are probably two reasons that most existing implementations use the "spread out" environment. One is that they were implemented before the standard was finalized, so there was not the concept of compilation environment, etc. The other is that people probably couldn't figure out how to do it without doing a hash-table lookup for each variable reference.
<beach>
As I recall some implementations of environments in Scheme (where apparently performance is not essential) use a hash-table lookup on every reference.
makomo has quit [Ping timeout: 252 seconds]
<beach>
It would slow things down by a factor 100 or so.
<beach>
Though maybe not compared to an interpreted implementation, as Bike explained.
<beach>
"metacircular"
makomo has joined #lisp
<makomo>
finally! -- got disconnected
<makomo>
beach: reading the log
<beach>
I noticed.
taof has quit [Ping timeout: 252 seconds]
<makomo>
Bike: if going the "hash table way" (and before i knew about beach's "trick" with using cons cells as "cells"/"slots") i thought of "value cells" as just bindings and therefore that SETF-ing a symbol just replaced that binding
<Bike>
that's not erasing though, it's just setf gethash
<makomo>
Bike: true i guess, replacing is a better name
<beach>
makomo: The hash table very likely contains "cells" as well.
<beach>
makomo: So you would just change the value of the cell in question.
<makomo>
beach: hm, so how exactly do you implement variable references?
<makomo>
beach: mhm. i've been looking at a hash table in a black box way
<beach>
I turn the reference into (car (load-time-value (find-variable-cell 'name)))
<beach>
Well, not quite, because there might be bindings on top.
<beach>
A better example would be a global function.
<beach>
A global function call turns into (funcall (car (load-time-value (find-function-cell '<function-name>))) arg1 ...)
renzhi_ has quit [Quit: WeeChat 2.1]
<makomo>
beach: cool, i'll have to read about load-time-value again :-). do you use the cdr for anything?
<beach>
Not at the moment.
<Bike>
it's only a cons cos there's no one-element structure built into lisp. could save some memory by making one, but that's about it
<beach>
But I could.
<beach>
makomo: What Bike said.
<makomo>
that's what i figured :-)
<beach>
But that would completely ruin my garbage collector. :)
<beach>
makomo: LOAD-TIME-VALUE just evaluates the form (or a pre-compiled version of it) at load-time and treats the result as a literal object.
<makomo>
the assignment/binding confusion is finally clear to me now. i think i also mixed up the specification and a hypothetical implementation which kept throwing me off -- i was thinking concretely instead of looking at what exactly the spec guaranteed about "cells"
quipa has joined #lisp
angeru has left #lisp [#lisp]
<Bike>
it's not like the implementation has any reaosn to mandate a memory layout or whatever
<beach>
Yeah, like I said, it's unfortunate that the standard kept that terminology.
<makomo>
but for that i would have to do a much more detailed reading of the spec so i never bothered, i guess?
<beach>
makomo: It would also take a lot of thinking. :)
<makomo>
yeah, exactly :D
<beach>
And then you would end up with SICL first-class global environments.
<beach>
makomo: I invented them for bootstrapping purposes. What SBCL does (for instance) is to use different package names at bootstrapping time so that there is no confusion between the host and the target. The Cleavir compiler does not access the host environment at all. It works with a first-class global environment to look up all the information it needs.
<beach>
makomo: In fact, I can even create a REPL that works in a particular environment, so I can execute SICL code inside SBCL.
<beach>
I can have part of the environment inherited from the host (like CONS, CAR, CDR) and the other defined by SICL-specific code.
smokeink has quit [Ping timeout: 244 seconds]
Fare has joined #lisp
<makomo>
beach: oh that's very nice
<beach>
Thanks.
<beach>
It allows me to debug SICL code without having a finished system yet. That makes the entire thing faster, because I can use SLIME, the inspector, etc.
<makomo>
pjb: what i wrote above is clear to me now but the run-time environment in which macroexpansion occurs is the evaluation environment, right? i was thinking of *the* run-time environment, but now it's clear to me also that compiled code doesn't have to be loaded within the same system that compiled it
<beach>
makomo: Actually, there are some severe restrictions to respect for that situation.
<makomo>
so the startup environment is the run-time environment which initiated the compilation, as you said, and the run-time environment is whichever environment the code is executed in (perhaps a completely different lisp image)
<makomo>
beach: hadn't thought of that. truly nice when you can steal parts from other implementations while you work on your own :-)
<beach>
As I recall there is some restriction that the environment into which a FASL file is loaded must be very similar to the one it was compiled in.
<makomo>
i remember reading this when we had that discussion about clisp not compiling a function :-)
<Bike>
there's also a few implied by the externalization rules, like that packages have to still exist
<makomo>
so if compiling and loading within the same lisp image, are the startup environment and the run-time environment going to be the same thing (in the sense that they contain the equivalent <variable/function/etc.> bindings)?
<beach>
Not necessarily.
<makomo>
they're distinct environments, but since neither is modified during compilation, they're equivalent?
<beach>
I hope to make it that way in SICL.
<beach>
But in a typical system, compile-time evaluations may alter the global environment.
Roy_Fokker has joined #lisp
<makomo>
how can that happen? can something modify the run-time environment during compilation?
<makomo>
hm, doesn't that happen in the "evaluation environment"?
<beach>
If (as is allowed) all environments are the same, yes.
<beach>
Four different environments relevant to compilation are distinguished: the startup environment, the compilation environment, the evaluation environment, and the run-time environment.
<makomo>
yup, that's what i've been reading :-)
<makomo>
and the startup environment *is* the run-time environment before the compilation, not a copy of some sort?
<beach>
The compilation environment inherits from the evaluation environment, and the compilation environment and evaluation environment might be identical. The evaluation environment inherits from the startup environment, and the startup environment and evaluation environment might be identical.
<makomo>
i.e. it's just a synonym/term
housel has joined #lisp
<beach>
makomo: So what made you contemplate all this stuff?
t3hyoshi has joined #lisp
Kundry_Wag has joined #lisp
<makomo>
beach: i asked a question an hour or more ago relating to EVAL-WHEN and then went to read about compiling again
<makomo>
i read about it before and formed an idea about the various environments but it wasn't completely fleshed out in my mind
<makomo>
so now i took to chance to do that
<beach>
I see.
nowhere_man has quit [Remote host closed the connection]
nowhere_man has joined #lisp
Fare has quit [Ping timeout: 264 seconds]
Roy_Fokker has quit [Read error: Connection reset by peer]
<makomo>
beach: hah, it was actually more than 3 hours ago. oh well :-)
<beach>
It was a good exchange though.
SenasOzys has quit [Ping timeout: 272 seconds]
<makomo>
yeah, definitely
Fare has joined #lisp
<pjb>
Well, historically the additionnal bindings, such as types, etc, were stored in the symbol-plist.
SenasOzys has joined #lisp
Kundry_Wag has quit [Ping timeout: 252 seconds]
anewuser has joined #lisp
orivej has joined #lisp
<beach>
That's true.
<beach>
I have seen even functions stored there.
<beach>
And macros.
cage_ has quit [Quit: Leaving]
quipa_ has joined #lisp
<AeroNotix>
given a value, can I find what it is bound to?
edgar-rft has quit [Remote host closed the connection]
quipa has quit [Ping timeout: 244 seconds]
<Bike>
only by exhaustive search
<AeroNotix>
Okay
<Bike>
why do you want to do that?
itruslove has joined #lisp
<AeroNotix>
Bike: I had redefined something but the symbol I had thought it should be bound to wasn't. I wanted to see what, if anything, the value was bound to
<Bike>
ah, yeah, thats hard to chec k
<AeroNotix>
a roundabout way of checking, I didn't really need it in this case but given the above discussion, thought I'd ask.,
taof has joined #lisp
taof has quit [Ping timeout: 276 seconds]
doubledup has joined #lisp
gitfaf has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
jack_rabbit has quit [Ping timeout: 264 seconds]
quipa_ is now known as quipa
Kundry_Wag has joined #lisp
quipa has quit [Quit: Leaving]
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 264 seconds]
taof has joined #lisp
Jesin has joined #lisp
taof has quit [Ping timeout: 252 seconds]
Oladon has joined #lisp
astalla has quit [Ping timeout: 264 seconds]
Inline has quit [Read error: Connection reset by peer]
Jesin has quit [Remote host closed the connection]
Inline has joined #lisp
Jesin has joined #lisp
jack_rabbit has joined #lisp
cage_ has joined #lisp
caltelt has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
razzy has quit [Ping timeout: 268 seconds]
razzy has joined #lisp
Kundry_Wag has joined #lisp
dented42 has joined #lisp
kristof has joined #lisp
<kristof>
what does the standard say about redefinition of toplevel functions?
<kristof>
not symbols in the common-lisp package
<kristof>
user defined ones
dented42 has quit [Ping timeout: 272 seconds]
ebrasca has joined #lisp
anewuser has quit [Quit: anewuser]
varjagg has joined #lisp
<beach>
Mostly no problem.
<beach>
But if the existing function was inlined, or if it was part of some compilation unit that treated it specially, then things might not work as expected.
<kristof>
Can you elaborate? Does the standard say anything about, say... if g called f, and f was redefined, should g be expected to retain its semantics or is it "anything goes"?
<kristof>
I gave the hyperspec a good end to end read a couple of months ago (minus the glossary and issues) and remembered something about this so I thought I would ask
<beach>
Sure.
<beach>
I suspect most implementations would either allow the redefinition, or the new version would only be visible when called from outside the compilation unit.
<beach>
I would be surprised if some implementation would crash or something like that.
<kristof>
The more I learn about common lisp the more I am impressed about the careful considerations for performance. It really grows on you, like a good wine. Or something.
<beach>
Yes, they were definitely concerned about performance.
taof has joined #lisp
dieggsy has joined #lisp
atgreen has quit [Ping timeout: 244 seconds]
Kundry_Wag has quit [Ping timeout: 244 seconds]
sjl_ is now known as sjl
taof has quit [Ping timeout: 264 seconds]
azimut has quit [Ping timeout: 240 seconds]
azimut has joined #lisp
hifitim has joined #lisp
<Demosthenex>
any tips on profiling in sbcl w/ slime/emacs? i've already found M-x slime-profile-package... but i'm not seeing enough information.
razzy has quit [Ping timeout: 264 seconds]
<_death>
maybe you want the statistical profiler..
Inline has quit [Read error: Connection reset by peer]
Inline has joined #lisp
<Demosthenex>
well, i'm trying to make sure i'm not wasting time in my list processing and data ordering...
Inline has quit [Read error: Connection reset by peer]
razzy has joined #lisp
Inline has joined #lisp
Inline has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
Inline has joined #lisp
hifitim has quit [Ping timeout: 276 seconds]
pjb has joined #lisp
<stacksmith>
Demosthenex: If you have lots of small functions and let it run for like 10 seconds, the quality of information is more usable...
defaultxr has joined #lisp
taof has joined #lisp
froggey has quit [Remote host closed the connection]
taof has quit [Ping timeout: 252 seconds]
m3tti has joined #lisp
gitfaf has quit [Remote host closed the connection]
taof has joined #lisp
<Demosthenex>
_death: thanks, once i had the name it was a fast find
doubledup has quit [Remote host closed the connection]
doubledup has joined #lisp
<Demosthenex>
haha, hairy-data-vector-ref
cage_ has quit [Quit: Leaving]
nopolitica has joined #lisp
gitfaf has joined #lisp
danielxvu has joined #lisp
danielxvu has quit [Remote host closed the connection]
danielxvu has joined #lisp
m3tti has quit [Ping timeout: 272 seconds]
buffergn0me has joined #lisp
<AeroNotix>
Is there anything to be done about typos in CLHS?
<_death>
you could modify your local copy
<AeroNotix>
right, I just mean there's probably nowhere that'll accept a PR or similar. It's set in stone at this point?
<PuercoPop>
The first item is a typo esearch -> research
<AeroNotix>
oh neat
<PuercoPop>
phoe has a project to 'wikify'? the clhs (among other docs). If typos would be fixable there, but the CLHS is owned by Lispworks so we are not free to modify it afaik
<AeroNotix>
How much would they take for ownership?
<_death>
nowadays research begins with esearch rather than ends with it :)
<AeroNotix>
I've got half a box of celebrations I could put up for it
<jackdaniel>
AeroNotix: you may publish your own version based on dpans, clhs is just some domain with standard draft compiled to html
<pjb>
makomo: well all of clhs is description of the interpreter!
<makomo>
hm yeah, i guess
<makomo>
so, since the compiler is formally specified, the spec basically requires the existance of a compiler. does the same hold for the interpreter?
<makomo>
from what i gathered, all of LOAD, COMPILE, EVAL, COMPILE-FILE and even the REPL can be implemented just by a lisp compiler
<pjb>
Actually, no. The specs only requires minimal compilation. Which is just macroexpanding the macros, basically.
<pjb>
What remains is of course the interpreter.
<pjb>
but the repl is (loop (print (eval (read)))) no compile in there. So the interpreter is EVAL.
<pjb>
Just implement EVAL and you're good to go.
<makomo>
yes, but isn't it true that the existance of a REPL doesn't necessarily imply the existance of an interpreter?
<pjb>
Of course, because you can also implement eval as (defun eval (form) (funcall (compile nil `(lambda () ,form)))) :-)
<makomo>
i mean, the code could be compiled and run on the fly, without direct interpretation
<makomo>
of course we're talking about the "lisp interpreter" specifically in this case. in the end the machine's processor still interprets and runs the machine code (or bytecode, etc.)
<_death>
that's also why the deprecation sections are errors
gitfaf has quit [Read error: Connection reset by peer]
robotoad has joined #lisp
<pjb>
_death: indeed, you can ignore this sentence. However, you may notice that implementations all print structures using keyword instead of symbols for the slot names.
<_death>
yes, because that's the specified behavior..
buffergn0me has quit [Remote host closed the connection]
random-nick has joined #lisp
X-Scale has quit [Ping timeout: 264 seconds]
shifty has quit [Ping timeout: 268 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
nopolitica has quit [Ping timeout: 252 seconds]
X-Scale has joined #lisp
edgar-rft has joined #lisp
kristof has quit [Ping timeout: 244 seconds]
acolarh has joined #lisp
kristof has joined #lisp
jurov has joined #lisp
<emaczen>
How do we use errno with CFFI?
<Shinmera>
Colleen: tell emaczen look up cffi defcvar
housel has quit [Read error: Connection reset by peer]
m3tti has joined #lisp
<emaczen>
Shinmera: I can't get errno to work... I keep getting dropped into the CCL kernel debugger for some reason
<emaczen>
If I remove the defcvar form, my code runs like it was before
nopolitica has joined #lisp
housel has joined #lisp
m3tti has quit [Remote host closed the connection]
jasmith has quit [Quit: Leaving]
Fare has quit [Ping timeout: 272 seconds]
Kundry_Wag has quit [Remote host closed the connection]
kristof has quit [Ping timeout: 252 seconds]
taof has left #lisp ["ERC (IRC client for Emacs 26.1)"]
jinkies has joined #lisp
kristof has joined #lisp
Fare has joined #lisp
Inline has quit [Remote host closed the connection]
Inline has joined #lisp
jlarocco has quit [Ping timeout: 244 seconds]
maarhart has joined #lisp
maarhart has quit [Excess Flood]
maarhart has joined #lisp
maarhart has quit [Excess Flood]
maarhart has joined #lisp
maarhart has quit [Excess Flood]
maarhart has joined #lisp
maarhart has quit [Excess Flood]
maarhart has joined #lisp
maarhart has quit [Excess Flood]
Oladon has quit [Quit: Leaving.]
pyx has joined #lisp
astalla has joined #lisp
pyx has quit [Client Quit]
Volt_ has quit [Quit: exit();]
varjagg has quit [Ping timeout: 268 seconds]
FreeBirdLjj has quit [Read error: Connection reset by peer]
nowhereman has joined #lisp
nowhere_man has quit [Read error: Connection reset by peer]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
Fare has quit [Ping timeout: 252 seconds]
doubledup has quit [Quit: Leaving]
FreeBirdLjj has joined #lisp
jinkies has quit [Ping timeout: 264 seconds]
FreeBirdLjj has quit [Ping timeout: 252 seconds]
<no-defun-allowed>
Good morning
light2yellow has quit [Quit: light2yellow]
zooey has quit [Remote host closed the connection]
zooey has joined #lisp
Pixel_Outlaw has joined #lisp
<pjb>
emaczen: errno is not a variable nowadays. It's a thread-dependent function. In C, it's declared as macro. extern int * __error(void); #define errno (*__error())
<pjb>
<pjb>
have fun!
<pjb>
(Just say NO! to FFI!)
<pjb>
If you insist in FFI, you'll have learn way more about C and unix that you (should) care!
<pjb>
And for those who are not rich enough for a vt420 terminal, there's always Cathode.app on macOS… :-)
<no-defun-allowed>
*cool-retro-term
<stylewarning>
pjb: That won’t emulate the experience of getting RSI and burning sensations in your hands from the terrible LK201 keyboard!
aindilis has quit [Ping timeout: 252 seconds]
random-nick has quit [Ping timeout: 244 seconds]
johnsurprice has joined #lisp
kristof has quit [Ping timeout: 272 seconds]
froggey has joined #lisp
<AeroNotix>
(eql '(#\A) '(#\A)) => NIL
<AeroNotix>
What gives^?
<pierpa>
it's undefined
<pierpa>
but NIL is the most obvious answer. Why are you surprised?
<johnsurprice>
hi lispers ! I'm benchmarking Hunchentoot with `ab` tool like that -- ab -s 60 -n100000 -c900 http://127.0.0.1:8888/. The default Hunchentoot page deployed at URL "/". Unfortunately, "ab" occasionally reports apr_socket_recv: Connection reset by peer (104) after 50000 requests. What could be the reason? PS. Node.js works without errors under similar load. :-(
<AeroNotix>
pierpa: nevermind
<pierpa>
k
<pjb>
AeroNotix: it depends, it could be T if you compile-file it, and the compiler performs the optimiation of coalescing literals.
<AeroNotix>
Interesting, ok
asarch has joined #lisp
<no-defun-allowed>
That's a lot of connections.
<no-defun-allowed>
I remember I usually did -c4
<no-defun-allowed>
If you're going to put Lisp in production, you should put nginx in front of it, which will also handle compression, rate limits and static files faster.
jlarocco has joined #lisp
<johnsurprice>
no-defun-allowed: I see. But I would like to fix it, but I don't know where to start.
<AeroNotix>
johnsurprice: are you running SBCL?
<no-defun-allowed>
If it's threaded, it might be failing to fork.
<johnsurprice>
AeroNotix: yes
<no-defun-allowed>
That's my first guess with no context.
<AeroNotix>
Just wanted to check
<johnsurprice>
no-defun-allowed: I'm creating Taskmaster in the following way: (make-instance 'hunchentoot:one-thread-per-connection-taskmaster :max-accept-count 30000 :max-thread-count 400)
<AeroNotix>
johnsurprice: how does it behave with -c400?
<no-defun-allowed>
I think it's out of threads.
<AeroNotix>
yeah^
<johnsurprice>
But the documentation says: If both :max-thread-count and :max-accept-count are supplied, then max-thread-count must be less than max-accept-count; if more than max-thread-count requests are being processed, then requests up to max-accept-count will be queued until a thread becomes available.
<johnsurprice>
So, it's cannot be out of threads by definitions
<no-defun-allowed>
50000 is almost double 30000. Maybe the queue is full.
<johnsurprice>
do you think that max-accept-count means the queue size?
<johnsurprice>
let me try
froggey has quit [Remote host closed the connection]
<no-defun-allowed>
You're giving it around double the requests it can handle, so it will continue to accumulate.
<johnsurprice>
okay, I've tested with max-accept-count == 150000
<johnsurprice>
same error
<AeroNotix>
If both :max-thread-count and :max-accept-count are supplied, then max-thread-count must be less than max-accept-count
<johnsurprice>
AeroNotix: yes, max-thread-count == 400, max-accept-count == 150000 now
<AeroNotix>
sorry misclicked
<AeroNotix>
meant to paste something else
<no-defun-allowed>
I think the queue is being filled either way. Did it take longer to overwhelm?
<johnsurprice>
no, Total of 49342 requests completed
<johnsurprice>
I think there is a low level bug...
<no-defun-allowed>
I still think the queue is being flooded.
<johnsurprice>
but the queue size is now bigger than the total count of requests -- it's 150000 vs 100000