jackdaniel changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/>
louis77 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Odeqlmd has joined #commonlisp
jmdaemon has joined #commonlisp
lisp123 has joined #commonlisp
pve has quit [Quit: leaving]
morganw has quit [Remote host closed the connection]
jeosol has joined #commonlisp
random-jellyfish has quit [Quit: Client closed]
jolby has quit [Quit: Client closed]
azimut has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
speskk has quit [Ping timeout: 264 seconds]
scymtym__ has quit [Ping timeout: 246 seconds]
jeosol has quit [Ping timeout: 260 seconds]
lisp123 has quit [Remote host closed the connection]
agent1011001 has quit [Quit: Client closed]
dipper has joined #commonlisp
agent1011001 has joined #commonlisp
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #commonlisp
lisp123 has joined #commonlisp
dipper has quit [Remote host closed the connection]
dipper has joined #commonlisp
holycow has joined #commonlisp
avocadoist has quit [Ping timeout: 260 seconds]
avocadoist has joined #commonlisp
tyson2 has joined #commonlisp
dipper has quit [Remote host closed the connection]
dipper has joined #commonlisp
azimut has quit [Remote host closed the connection]
tyson2 has quit [Remote host closed the connection]
azimut has joined #commonlisp
paul0 has joined #commonlisp
azimut has quit [Ping timeout: 255 seconds]
azimut has joined #commonlisp
lispnik has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lispnik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
pranavats has left #commonlisp [Disconnected: Hibernating too long]
<hayley> The "Notes" section of the HyperSpec page on EQ states "An implementation is permitted to make copies of characters and numbers at any time". Is there a normative section describing this behaviour?
<hayley> Can an implementation coalesce numbers at any time?
<beach> I am pretty sure it can. Since numbers are immutable, there is no problem.
<hayley> Okay. Is there a normative definition of how EQ behaves on numbers, or what "identical" means other than "the same under EQ"?
<hayley> I believe you, but I'm looking for what to reference.
<beach> I don't know. Sorry.
<hayley> No worries then.
<hayley> The glossary entry for "same" states "Note that eq might be capable of distinguishing some numbers and characters which eql cannot distinguish, but the nature of such, if any, is implementation-dependent."
ClickHacker has quit [Ping timeout: 264 seconds]
aartaka has joined #commonlisp
aartaka has quit [Ping timeout: 268 seconds]
aartaka has joined #commonlisp
shka has joined #commonlisp
pranavats has joined #commonlisp
<edgar-rft> hayley: As far as I know the practical problem with EQ was that FIXNUMs can be stored in proessor registers what technically can be a potential "copy" of a FIXNUM in memory, so a simple memory-pointer comparison can fail for FIXNUMs. This includes all characters that can be represented by FIXNUMs internally. Stupily I have no idea where this is documented.
<beach> edgar-rft: FIXNUMs can be compared with EQ in most implementations, because they are typically entirely represented in a machine word. So a copy of a FIXNUM is then identical to the original. The problem is with bignums.
<beach> Of course, my idea for BOCL involves not having a special representation for FIXNUMs, in which case EQ could not be used reliably for them.
agent1011001 has quit [Quit: Client closed]
lucerne has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.7.1]
lucerne has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 246 seconds]
perrierjouet has joined #commonlisp
rgherdt has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
lisp123 has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
Odeqlmd has quit [Remote host closed the connection]
louis77 has joined #commonlisp
louis77 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
random-nick has joined #commonlisp
louis77 has joined #commonlisp
louis77 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
louis77 has joined #commonlisp
mrcom_ has joined #commonlisp
mrcom has quit [Ping timeout: 272 seconds]
Lycurgus has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 255 seconds]
Lord_of_Life_ is now known as Lord_of_Life
cage has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
tane has joined #commonlisp
tane has quit [Changing host]
tane has joined #commonlisp
louis77 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
louis77 has joined #commonlisp
Kingsy has joined #commonlisp
Lycurgus has quit [Quit: Exeunt: personae.ai-integration.biz]
pranavats has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
prokhor_ has quit [Ping timeout: 246 seconds]
louis77 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azimut has quit [Ping timeout: 255 seconds]
azimut has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
dipper has quit [Remote host closed the connection]
tane has quit [Quit: Leaving]
louis77 has joined #commonlisp
louis77 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 260 seconds]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 260 seconds]
aartaka has quit [Ping timeout: 272 seconds]
aartaka has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
pve has joined #commonlisp
aartaka has joined #commonlisp
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #commonlisp
louis77 has joined #commonlisp
<Shinmera> hayley: iirc ABCL/Java have weird integer caches, so fixnums may not be EQ.
<hayley> Right. My question was if an implementation may then coalesce integers, like the JVM does for Strings.
<jackdaniel> some fun with implementing xkb in common lisp: http://turtleware.eu/static/paste/f7d40fa1-keys.mp4
<hayley> The specification appears to allow such behaviour, although the notes phrase it as allowing "copying at any time" which is a different statement.
<beach> That phrase says that they might not be EQ. You are asking the inverse it seems.
<hayley> My interpretation of "copying at any time" was that EQ on two numbers may return true at some point in time, and then return false at some later point in time.
<beach> Yes, that's the right interpretation.
<hayley> My interpretation of coalescing is indeed the inverse; if EQ may return false at some point, and then return true at some later point.
<beach> Oh, that's different. You are asking whether (defparameter *a* <some-number>) (defparameter *b* <some-number>) and then (list (eq *a* *b*) (eq *a* *b*)) may return (nil t)? I don't think that is possible.
<beach> It would require the implementation to alter at least one of the values without any explicit form being executed to do so.
<hayley> The glossary definition of "same" suggests there are no restrictions on what EQ may return on numbers.
<beach> True, but that's not the same question.
<hayley> I think a similar argument would hold for that form evaluating to (T NIL); the values are never copied by any form.
<pjb> hayley: it seems to me that the standard allows: (let ((x 42)) (list (eq x x) (eq x x))) --> (nil t)
<pjb> Note: I'm not sure one could distinguish whether the implementation first copied one 42, and then coalested them, or just first copied the 42, and next didn't copy it.
<pjb> (list (eq (+ 21 21) 42) (eq 42 42)) could return all combinations (nil nil) (nil t) (t nil) and (t t)
<pjb> In ccl 64-bit on darwin, (list (eq (+ 21 21) 42) (eq 42 42)) #| --> (t t) |#
<hayley> The Notes on EQ state "An implementation is permitted to make ``copies'' of characters and numbers at any time" (but Notes are non-normative). This is a different statement to "EQ may arbitrarily return true or false on numbers or characters which are nonetheless the same under EQL" or somesuch, as previously described.
<pjb> On the other hand, in ccl 64-bit on darwin: (list (eq (+ 1152921504606846975 1152921504606846975) 2305843009213693950) (eq 2305843009213693950 2305843009213693950)) #| --> (nil nil) |#
<pjb> hayley: copying at any time includes copying when passed as parameter to any function, including EQ.
<hayley> Yes, I don't know of any Common Lisp implementation which would coalesce while the program is running. SBCL may during a SAVE-LISP-AND-DIE; I would need to consult coalesce.c to check.
<pjb> (let ((x 2305843009213693950)) (list (eq (+ 1152921504606846975 1152921504606846975) x) (eq x x))) #| --> (nil t) |#
mathrick has joined #commonlisp
<pjb> perhaps these results indicate that ccl doesn't coalesce non-fixnum integers?
<beach> But does "any time" allow for, say, a separate thread to do arbitrary copying of bindings in another thread?
<pjb> But you'd also have to compile those code, to verify that it doesn't coalesce the literals (which would be possible at compilation-time whatever their types).
<pjb> beach: I'd say yes.
<pjb> Of course, we're in 100% implementation dependent stuff, so it's up to the implementation do document if and when.
<hayley> pjb: It would not be surprising. But I am not interested in how Common Lisp implementations behave; I am interested in if coalescing is allowed by the specification.
<pjb> hayley: it's allowed at compilation-time at least, for literals. (not for results computed at run-time).
<beach> hayley: That's again a different question. Coalescing is probably allowed when a number is created, for instance.
<beach> Like "hashed CONS for bignums".
<pjb> But I guess it's not forbidden either for results computed at run-time, since it's not specified what EQ shall return for characters and numbers.
<pjb> So this allows an implementation to coalesce characters and numbers computed at run-time.
<pjb> hayley: I say it's allowed, because there's nothing else in the specification that would be contradicted if an implementation did it. Or did not.
<pjb> (list (eq (+ 21 21) 42) (eq 42 42)) could return all combinations (nil nil) (nil t) (t nil) and (t t) and that's it. (and it's not a feature of EQ, but of computing and referencing numbers (or characters).
<pjb> same with: (list (eq (code-char 41) #\A) (eq #\A #\A))
<hayley> beach: Sure. I refer to coalescing, say, after a bignum is created, like Appel's "hash-consing garbage collection" scheme.
<beach> hayley: I see. That wasn't clear from your initial question.
cage has quit [Quit: rcirc on GNU Emacs 28.2]
<pjb> hayley: as an implementer, you have to ask yourself (and perform benchmarks and statistics), to see whether memory could be saved, and whether this wouldn't take too long, to try to coalesce bignums.
aartaka has quit [Ping timeout: 272 seconds]
<hayley> Appel didn't get great results himself. But I was warned to be careful about specifying how "pointer equality" should behave with immutable objects.
<pjb> hayley: nowadays, most-positive-fixnum #| --> 1152921504606846975 |# is rather high, so numbers in the range (most-positive-fixnum (* 2 most-positive-fixnum)) have a probability of 1/1152921504606846975 ~= 8.673617379884035D-19 rather low of already existing in the memory… You'd have to compute a lot of bignums to find the same once again… remember, there are only 31e6 second in a year, and only 31e15 nanosecond in
<pjb> a year. So you have a chance to compute the same bignum about once every 3000 or 10000 years.
<pjb> (assuming you compute a bignum each nanosecond, which is not yet).
<pjb> And this is for very small bignums. You often compute much bigger bignums, so the probability is even lower.
<hayley> This assumes that bignums are uniformly distributed, which I would not expect.
aartaka has joined #commonlisp
<pjb> Even adjusting for the distribution of computed bignums, my feeling is that you wouldn't find duplicate often enough to warrant spending the time to try to unify them.
<jackdaniel> if we summarize all common lisp programs the most commonly used bignum is (1+ most-positive-fixnum), and it is usually used in tests ,)
<hayley> There was a study of a computer algebra system, where smaller bignums were more common. I also would imagine "interesting" numbers like powers of two are disproportionately common too.
<selwynning> bignums cant be uniformly distributed anyway
<hayley> pjb: Ultimately I am trying to work out semantics for immutable objects in a language that is not Common Lisp. Common Lisp has few immutable types, but they exist and their behaviour is specified.
<pjb> As literals, you could coalesce them at compilation time, that would seem reasonable. But at run-time I'd be surprised if you gained much memory and didn't lose a lot of time.
perrierjouet has quit [Ping timeout: 272 seconds]
<hayley> I never asked if it was a good idea.
<hayley> But is it allowed by the specification? I'm now not sure if I read the glossary entry for "same" correctly, or if that's the correct section of the specification to read to understand how EQ behaves.
<Bike> my interpretation has always been that EQ on numbers/characters returns an undefined value (to the point of not having to be stable over time or anything), so coalescing would be ok.
<Bike> but the standard does not exactly rigorously define how eq works.
<Bike> the glossary "same", in particular, does not seem applicable to eq's description as determining if its arguments are the "same, identical object"
<hayley> Thanks. I don't know what to interpret though; the glossary entry only states "Note that eq might be capable of distinguishing some numbers and characters which eql cannot distinguish, but the nature of such, if any, is implementation-dependent" which is rather indirect way of putting things.
<Bike> and it looks like "identical" is just defined to mean "the same under eq" so that doesn't help either.
<Bike> oops, i mean that eq on numbers that are eql is undefined, of course. if they're not eql they're definitely not eq
<Bike> defining the semantics of pointer equality more formally would probably be pretty involved
speskk has joined #commonlisp
speskk has quit [Changing host]
speskk has joined #commonlisp
<Bike> practically speaking, eq is an implementation hack. it's eql but faster because it's allowed to give answers that would be wrong under eql sometimes. that's basically what my interpretation is based on, rather than anything the standard outright says
<hayley> Could one define where copying is allowed? I understand the usual formal approach is that you have a partial function as a "heap" but I am too lazy to go that deep.
<hayley> Yeah. I ask as I had asked around about if providing any kind of pointer equality for immutable objects was a good idea, and Cliff Click said he depends on some pointer equality for fast equality tests, as you describe.
<hayley> But then he is doing his own hash consing, and so he probably should use objects with identity and manage the identity himself. There's an annoying name idea - "mutable objects" have manual object identity management.
<Bike> there's an old paper called "The Semantics of Destructive Lisp" that might help, but i haven't read it, because I am also lazy
<Bike> and, because of my being lazy, i would also say that pointer equality for immutable objects might be more trouble than it's worth. if you want to distinguish otherwise indistinguishable objects you can just add an id field (so manual identity management, i guess)
<Bike> for mutable objects you can at least define pointer equality in a sort of empirical sense - two objects are eq if mutations to one are visible in the other
<Bike> (well, "two objects" might not be the best phrase)
<Bike> "pointer equality" sort of means using the underlying machine address as that extra id field
<Bike> so it's a little abstraction breaking
<Bike> and sure seems to cause some weirdness in GC work.
<hayley> I mean, I am aware that pointer equality for immutable objects is completely a performance hack. But, as I would like the user to be able to write their own equality predicates, is it worth having such a hack?
<hayley> (Compare to, say, ML data having The One Equality Predicate which uses structural equality, but may as well do a pointer test beforehand to save time.)
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<pjb> hayley: the point here is that the standard tries to formalize practice.
<pjb> hayley: the practice is that lisp use internally tagged words.
jmdaemon has quit [Ping timeout: 252 seconds]
<pjb> a word with a tag of fixnum (or positive-fixnum negative-fixnum as often to get one more bit off the tag for the value) and a value can be used as "generalized reference" as well as a word with a tag of pointer to object and an address, with the object being pointed having a "subtag" of integer and a value.
<pjb> Both values can represent the same integer!
<pjb> EQ compares the words, so in that case they would be not EQ, while they'd be EQL and =.
<pjb> an implementation could have no tag for fixnum in the words. It could use only pointers to an integer object on the heap.
<pjb> Or it could be impossible to have such an integer object with a fixnum value, if the implementation "boxes" fixnum into such tagged word, when it compute a new integer, instead of allocating it on the heap as an integer object.
<pjb> To allow all those implementations (and possibly others), EQ cannot be used to compare numbers or character. It's an implementation hack that compares implementation words.
tyson2 has joined #commonlisp
<pjb> and it concerns numbers in general, since such optimization can also be applied to ratio, complex (and obviously floats, particularly single-float).
<pjb> On a 64-bit system with 32-bit single-float, you can store a float and a 32-bit tag in a 64-bit word!
<pjb> Or you can easily store two integer values to make small ratios or complexes: 1/2 or #C(1 2) could be stored as t tag bit (different tags for ratio and for complex), (64-t)/2 bits for 1 (64-t)/2 bits for 2.
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 272 seconds]
<Bike> hayley: i think defining a pointer equality operator explicitly as "this is like the well-defined, possibly-structural equality operator that also exists, but on this category of objects it can just do whatever". i don't think you want or need to define copying semantics in detail unless you want to be C++, which hopefully you don't
waleee has joined #commonlisp
jeosol has joined #commonlisp
aartaka has quit [Ping timeout: 252 seconds]
aartaka has joined #commonlisp
aartaka has quit [Ping timeout: 264 seconds]
aartaka has joined #commonlisp
Devon has joined #commonlisp
<Devon> How to access fan speed, temperature, etc. in CL?
<beach> Devon: The Common Lisp language does not define any such operators. You would have to consult the implementation manual.
<Devon> LOL, of course, no language would. "I don't know" would have been a better answer.
<beach> Not really, since it depends on the Common Lisp implementation you are using.
<_death> there's probably some procfs interface
<Devon> death: Thanks, as I happen to be on Debian at the moment, I soo /proc exists.
<Devon> /soo/see
<_death> there's also the `sensors` program.. that's what I usually use to check these values
<Devon> I want my fans off so as not to stress the undercooled laptop.
son0p has quit [Read error: Connection reset by peer]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #commonlisp
aartaka has quit [Ping timeout: 265 seconds]
aartaka has joined #commonlisp
son0p has joined #commonlisp
Devon has quit [Ping timeout: 264 seconds]
cage has joined #commonlisp
<waleee> was there some changes to sly recently? I got a surprise "make client error" at M-x sly
<waleee> hm looks more likely that it was a distro-local emacs change
<waleee> (since sly's last commit was in November)
<waleee> wtf it worked normally on a retry
<pjb> hayley: in other programming languages, notably OOP, you have all references are pointers to objects, and the type tag (or class tag) is stored in the object itself. Lisp is different in that it has often the type tag stored along with the "pointer" or value of the object when this value is smaller than a pointer.
<pjb> hayley: this implies this difficulty that EQ now compares both a pointer (with tag) or a value (with tag).
ldb has joined #commonlisp
<pjb> hayley: which implies that for some objects, those that are immutable and that can therefore be copied with no consequence, EQ now becomes an implementation detail instead of a valuable operator.
<pjb> hayley: the other aspect that interests you is that immutable objects may also be coalesced (explicitely by the compiler). The standard explicitely consider objects that are immutable because they're literal objects (even if there exist mutating operators, as for example, cons cells), but I don't see why the rule cannot apply to immutable objects because they're essentially immutable, and therefore at run-time too. (if that was an
<pjb> efficient choice).
<ldb> waleee: likely, your localhost port is blocked temporarily
<ldb> I see basically you want a pre-baked hashconsing library, hayley
<ldb> or just memoization?
aartaka has quit [Ping timeout: 272 seconds]
jolby has joined #commonlisp
aartaka has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
aartaka has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
<Josh_2> :trumpet:
aartaka has quit [Ping timeout: 265 seconds]
aartaka has joined #commonlisp
<mfiano> GM :sunglasses:
epony has quit [Read error: Connection reset by peer]
ldb has quit [Remote host closed the connection]
varjag has joined #commonlisp
<Josh_2> :sunglasses:
Posterdati has quit [Ping timeout: 265 seconds]
molson_ has quit [Remote host closed the connection]
molson_ has joined #commonlisp
epony has joined #commonlisp
Posterdati has joined #commonlisp
<remexre> if I'm building a binary with asdf:make (via program-op), is there a non-hackish way to run some code to "warm up" the method lookup caches?
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
<Shinmera> That'll be an implementation question.
<remexre> which part? I guess I haven't measured, but I assumed compute-applicable-methods-using-classes would update the caches
<mfiano> the part that methods have lookup caches
vxe420 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
Inline has joined #commonlisp
<remexre> hm, I guess
<remexre> is there something convenient that exists for those implementations that do, though? (or at least something for SBCL I can gate behind #+sbcl)
<Josh_2> What about running some tests that use those generic functions when you load the image?
<remexre> yeah that was my idea "of last resort;" ideally I could say "here's the list of classes this could possibly be, just fill the cache" without having to load (much) extra code...
<Josh_2> Or just leave it :sunglasses:
random-jellyfish has joined #commonlisp
tane has joined #commonlisp
tane has joined #commonlisp
tane has quit [Changing host]
jolby has quit [Quit: Client closed]
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #commonlisp
Lycurgus has joined #commonlisp
Lycurgus has quit [Quit: Exeunt: personae.ai-integration.biz]
morganw has joined #commonlisp
emacs-dwim has quit [Ping timeout: 264 seconds]
aartaka has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
ec_ has joined #commonlisp
ec has quit [Ping timeout: 255 seconds]
drainpipe has joined #commonlisp
azimut has quit [Ping timeout: 255 seconds]
jmdaemon has joined #commonlisp
drainpipe has quit [Ping timeout: 255 seconds]
louis77 has quit [Remote host closed the connection]
<Josh_2> Has anyone here deployed a lisp image using kubernetes?
drainpipe has joined #commonlisp
drainpipe has quit [Client Quit]
<jeosol> Josh_2: Yes, I have, it was a daunting experience at first, given how large K8s it, but it does help resolve a lot of my problems
<jeosol> but of course, at the cost of added complexity. I am not sure which of the service provides you plan to use or self-hosted (minikube and K3s for learning). With that said, I used GKE (Google GCP)
<Josh_2> Did you use any of the health checking probes?
epony has quit [Ping timeout: 268 seconds]
<jeosol> Yeah, I did. Just create some route that is checks at long as it returns the response back. It just helps K8s check that the pod is not dead.
<jeosol> *is -> it ...
<jeosol> Josh: Apologies if I understand your health check probe part. Perhaps we can take it to the lispcafe room
<Josh_2> That is what I was asking
<Josh_2> Lisp images do a good job of remaining alive even when everything is not going to plan
<Josh_2> You could have 10 threads that are dying and hunchentoot will still respond to a health check :joy:
<Josh_2> only exception is getting thrown into ldb
<jeosol> Josh_2: Very much true and that helps
<Josh_2> I was just wondering what you used to declare that your image was "healthy"
epony has joined #commonlisp
<Josh_2> I could do something like make sure my database is reachable :thinking:
<jeosol> Let me check
<jeosol> What I did was define a route and just return some parameters of the machine instance. I don't think it matters much as long as that request (I am using the request option) returns a response. And I think you want this to be fast too
asarch has joined #commonlisp
<jeosol> So it sends a request to an api like "[domain-here]/health" and it gets a response back.
<Josh_2> Yeh
<Josh_2> Guess I'll just keep it trivial
<Josh_2> thanks :thumbsup:
<jeosol> Josh_2: no worries, that's what I did, just a simple response back, some text will suffice
Inline has quit [Quit: Leaving]
asarch has quit [Quit: Leaving]
attila_lendvai has joined #commonlisp
jolby has joined #commonlisp
aartaka has quit [Ping timeout: 272 seconds]
aartaka has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 28.2]
<Josh_2> I did not know about :argument-precedence-order until yesterday, and today I have made use of it :sunglasses:
jolby has quit [Quit: Client closed]
aartaka has quit [Ping timeout: 260 seconds]
speskk has quit [Ping timeout: 252 seconds]
<jeosol> Josh_2: You are using this in conjunction with defgeneric generate to force a default argument precedence?
<jeosol> Josh_2: I guess not force, but set I suppose
<hayley> ldb: I'm looking for prior art on how to specify the behaviour of pointer equality for immutable objects.
<hayley> pjb: Thanks, I've never looked at how Lisp implementations represent data before.
<hayley> Bike: No need for copying, fortunately. But I think pointer equality has to be a primitive in some sense of the word.
<hayley> (I ignore Baker's "can I see an update to X from Y" rule, because I can, and even though that helps with intuition, it's not something I want the user to try due to threads.)
seletz_ has quit [Ping timeout: 272 seconds]
mrcom_ has quit [Remote host closed the connection]
mrcom_ has joined #commonlisp
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
<Bike> hayley: yeah, it's kind of a... non-constructive idea of equality, i guess
rgherdt has quit [Remote host closed the connection]
<Josh_2> jeosol: ya
tane has quit [Quit: Leaving]
tibfulv has quit [Remote host closed the connection]
attila_lendvai has quit [Ping timeout: 255 seconds]
tibfulv has joined #commonlisp
epony has quit [Ping timeout: 268 seconds]
random-jellyfish has quit [Quit: Client closed]
jolby has joined #commonlisp