vegansbane6963 has quit [Read error: Connection reset by peer]
vegansbane6963 has joined #lisp
pankajsg has joined #lisp
karlosz has quit [Ping timeout: 245 seconds]
kevingal has quit [Remote host closed the connection]
kevingal_ has quit [Remote host closed the connection]
matryoshka has quit [Ping timeout: 272 seconds]
karlosz has joined #lisp
kam1 has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
CrazyPython has joined #lisp
<beach>
Good morning everyone!
Alfr is now known as Guest35071
Alfr has joined #lisp
CrazyPython has quit [Read error: Connection reset by peer]
Guest35071 has quit [Ping timeout: 260 seconds]
kam1 has joined #lisp
orivej has joined #lisp
Sheilong has quit []
kam1 has quit [Read error: Connection reset by peer]
<sxmx>
good morning beach
anticrisis has quit [Read error: Connection reset by peer]
matryoshka has joined #lisp
kam1 has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
brad22_ has quit [Ping timeout: 276 seconds]
<beach>
White_Flame: WHILE LINE would violate the expectations of the person reading the code, as indicated on page 13 or the LUV slides.
toorevitimirp has joined #lisp
<beach>
sxmx: Are you new here? I don't recognize your nic.
rickygee has joined #lisp
Bike has quit [Quit: Lost terminal]
rumbler31 has joined #lisp
mindCrime_ has quit [Remote host closed the connection]
mindCrime_ has joined #lisp
really2 has quit [Ping timeout: 256 seconds]
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
Lycurgus has joined #lisp
toorevitimirp has quit [Ping timeout: 256 seconds]
toorevitimirp has joined #lisp
rumbler31 has quit [Remote host closed the connection]
Lycurgus has quit [Quit: Exeunt]
rumbler31 has joined #lisp
anticrisis has joined #lisp
contrapunctus has left #lisp ["Disconnected: closed"]
contrapunctus has joined #lisp
kaiwulf has quit [Ping timeout: 264 seconds]
aartaka has joined #lisp
contrapunctus has left #lisp ["Disconnected: closed"]
contrapunctus has joined #lisp
bitmapper has quit [Quit: Connection closed for inactivity]
<White_Flame>
beach: trying to figure out what you mean. maybe implying that using a line-or-nil field directly as a nil check is supposed to be bad form, and "until (null line)" would be better?
<beach>
The NIL returned is not a Boolean. It is a default value. So using it as a Boolean violates the expectations, as indicated on page 13 of the LUV slides.
<beach>
White_Flame: I am not talking about semantics. I am talking software engineering.
<White_Flame>
yeah, I know. I don't really agree with that particular, though
<beach>
Of course.
<beach>
I mean, of course you don't.
<White_Flame>
lisp is pretty clear in its nil vs non-nil semantics for booleans, while something like C is more ambiguous with its int 0 and NULL pointer equivalence as boolean
<beach>
Yes, but, again, my argument is not related to semantics.
<White_Flame>
*effective equivalence
kam1 has joined #lisp
<beach>
If every semantically correct program were also acceptable in terms of style, we would have a big mess.
<White_Flame>
I know it's a style issue raised
<White_Flame>
in the linked clhs page, it does "while stack" in its loop construct. Would you say that that's also a bad use of a list variable, and it should be a specific (null stack) as well?
<beach>
Yes, that's bad style.
<beach>
In fact, since it's a stack, it should probably be abstracted to (emptyp stack) or something similar.
kam1 has quit [Read error: Connection reset by peer]
<White_Flame>
(and really, it should be (cons (length stack) stack) to achieve the effect of the code, as the loop is really roundabout :) )
<beach>
I didn't look at the code.
gaqwas has joined #lisp
gaqwas has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
akoana has left #lisp ["Leaving"]
aartaka_d has joined #lisp
aartaka has quit [Ping timeout: 276 seconds]
asarch has joined #lisp
aartaka_d has quit [Ping timeout: 256 seconds]
aartaka has joined #lisp
juliusdeane has joined #lisp
<juliusdeane>
so I'm trying to write cffi bindings to a c library I wrote
<juliusdeane>
and using dynamically allocated structs is causing memory faults
<juliusdeane>
so I was wondering if there's a good method for debugging/avoiding these memory faults
<juliusdeane>
(I'm fairly new to lisp and cffi btw)
kam1 has joined #lisp
toorevitimirp has quit [Remote host closed the connection]
kam1 has quit [Read error: Connection reset by peer]
aartaka_d has joined #lisp
aartaka has quit [Ping timeout: 246 seconds]
<beach>
juliusdeane: Yes, don't use FFI.
waleee-cl has quit [Quit: Connection closed for inactivity]
<beach>
juliusdeane: If you are unfamiliar with Common Lisp programming, that's a really bad way of getting started.
<beach>
juliusdeane: Unlike something like Python, you don't need to write your libraries in C to get decent performance out of a good Common Lisp implementation.
juliusde` has joined #lisp
madage has quit [Remote host closed the connection]
madage has joined #lisp
juliusde` has left #lisp [#lisp]
juliusdeane has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 276 seconds]
kam1 has joined #lisp
attila_lendvai_ has joined #lisp
<fiddlerwoaroof>
beach: I've never been entirely convinced by that part of LUV
<fiddlerwoaroof>
The equivalent idiom is pretty widespread and well-known in languages with falsy values, and it reads nicely
mindCrime_ has quit [Ping timeout: 245 seconds]
<beach>
Of course.
<beach>
And by that, I mean "of course you have never been entirely convinced..."
mindCrime_ has joined #lisp
<fiddlerwoaroof>
Well, ultimately, my question would be what is the evidence that code like (loop for line = (read-line nil) while line ...) actually causes problems in understanding
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
* splittist
is with fiddlerwoaroof
<beach>
Conventions exist in order to make it faster for a person reading the code to understand what it means. Just as with natural languages, if you violate the expectations, then the text may still be possible to understand, but it is going to take longer.
<splittist>
Our first evidence is our expectations; then actual practice - surely.
<beach>
I personally have to pause and think about what code like that means. I end up understanding it, but it takes longer.
<splittist>
'Keep going while there is something to do' seems as least as natural to me - I make no claims about others - than 'Keep going until there is nothing to act upon'. I do not hold myself out as being representative, or even a good example.
<beach>
But I have made this argument over and over again, and I am getting tired of arguing.
<beach>
splittist: Sure, you can do (loop ... while (stringp line)...) that's fine. But the argument is not between WHILE and UNTIL.
aggin has joined #lisp
<splittist>
Oh.
wilfredh has joined #lisp
<beach>
It's about treating a default value (that happens to be NIL in this case) as a Boolean. The code logic should not have to change if the default value changes to (say) :NONE.
matryoshka has quit [Ping timeout: 272 seconds]
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
<splittist>
Hmm.
aggin has quit [Quit: WeeChat 3.0.1]
kam1 has quit [Read error: Connection reset by peer]
<jdz>
beach: Just a thought: what about (read-line stream nil nil)?
<jdz>
In this case a literal nil as a boolean is given.
<beach>
Why do you say that? NIL is perfectly good as a default value.
anticrisis has quit [Read error: Connection reset by peer]
<jdz>
I mean using NIL as the eof-value, and looping with WHILE.
<beach>
It is still a default value, and not a Boolean.
shka_ has joined #lisp
<jdz>
OK, I think my intuition might be starting to adjust.
<jdz>
I'm also one of those using the mentioned READ-LINE loops.
<jdz>
Have never stopped to think.
<jackdaniel>
(when-let ((foo (something))) …) also violates that expectation, because it conflates "null" with "false" since while takes a test; still I think that it is easier to read for the programmer accustomed to the macro than (let ((foo (something))) (unless (null foo) …)); maybe expecting the <test> in if/while etc as "either false or null value" would embrace both uses
<jackdaniel>
(expectation-wise)
<jackdaniel>
boolean or object-nullness ,)
<fiddlerwoaroof>
I generally agree that nil as a default value shouldn't be treated as a boolean in every case.
<fiddlerwoaroof>
e.g. (when (car list) ...) is probably better written (when (null (car list) ...) or something
<fiddlerwoaroof>
In this case the default value signifies something very close semantically to false "no more input or something", so the reading "assign line to the next line, while there is a line ..." is pretty straightforward, given the semantics of the functions involved
<fiddlerwoaroof>
argh, I'm tired and can't get my parentheses right :)
<moon-child>
what about (when (cdr list)), though? 'when the list has a cdr' vs 'when the list's cdr is not null' - those two seem pretty close in meaning to me
<beach>
A list always has a CDR.
<fiddlerwoaroof>
I'm not sure, I think I usually write (when (null (cdr list))) for "real" code.
<beach>
moon-child: Again, it is not about meaning (= semantics), it is about avoiding surprises to the person reading your code.
surabax has joined #lisp
contrapunctus has left #lisp ["Disconnected: Replaced by new connection"]
contrapunctus has joined #lisp
contrapunctus has left #lisp ["Disconnected: closed"]
contrapunctus has joined #lisp
pve has joined #lisp
ficl has joined #lisp
attila_lendvai_ has quit [Ping timeout: 256 seconds]
rgherdt has joined #lisp
<flip214>
using postmodern, how would I get the comments associated to fields in the DB?
<flip214>
(pomo:table-description-plus) doesn't return them, is there another high-level function?
<flip214>
(yeah, I can always query PG internal tables...)
aartaka_d has quit [Ping timeout: 264 seconds]
hendursaga has joined #lisp
hendursa1 has quit [Ping timeout: 268 seconds]
sabrac has joined #lisp
mindCrime_ has quit [Ping timeout: 264 seconds]
<sabrac>
flip214: Postmodern does not have a high level function to get comments associated with a database. I could add something tomorrow if you PM me what you would like.
surabax has quit [Read error: Connection reset by peer]
_whitelogger has joined #lisp
andreyorst has quit [Read error: Connection reset by peer]
cage_ has joined #lisp
<White_Flame>
beach: you keep using the term "default value", but I don't think that's what it is in these cases. It's an intentional value for a particular state, not some uninitialized fallback, unless I'm understanding the label incorrectly
<White_Flame>
and intentionally selected to be easy to use in tests
<White_Flame>
of course, when NIL is ambiguous with data, we do things like :eof or a 2nd boolean returned value
<White_Flame>
but even then, those aren't defaults, they're alternates
<beach>
Like I said, I am getting tired of arguing this thing. I am definitely a member of the group that is referred to by the LUV slides in that I must pause and think when I see such code. If you don't want to cater to that group of people, that is of course entirely your choice.
<White_Flame>
well, I'm asking in particular about the term "default value"
<beach>
It doesn't say "default value", but EOF-VALUE.
<beach>
Can you remind me what the example was?
<White_Flame>
(loop for line = (get-line s) while (peek-char nil s) collect line)
<beach>
My term "default value" was meant to be relative to read-line.
<White_Flame>
and he was doing his own peeking around the char stream, presumably not with read-line
<White_Flame>
ah, k
<beach>
Let me check the Common Lisp HyperSpec page for PEEK-CHAR...
<White_Flame>
similar to read-line in terms of the eof-value
<beach>
Same thing. PEEK-CHAR returns a character or the EOF-VALUE which is a default value to be returned when the stream is at end of file.
<beach>
So WHILE (PEEK-CHAR...) violates the expectations that WHILE should take a Boolean value.
<White_Flame>
but while (peek-char ... :eof-value nil) is okay?
asarch has quit [Quit: Leaving]
<beach>
No.
<beach>
NIL is a default value here. Not a Boolean.
<White_Flame>
I simply mean that if it's explicitly provided, it might no longer be classified as a default
<beach>
I don't see the difference.
<White_Flame>
and thus while <- NIL is explicitly linking a boolean value to the test
aartaka has joined #lisp
<White_Flame>
(although obviously the non-eof case is still a non-boolean)
<_death>
personally I like generalized booleans :)
<beach>
Sure, but this is not a Boolean, and not a generalized Boolean.
<beach>
It's a character or a default value.
<_death>
well, all objects can be generalized booleans
<_death>
do you use (when (member ...) ...) by the way?
amb007 has quit [Read error: Connection reset by peer]
gareppa has joined #lisp
amb007 has joined #lisp
<White_Flame>
there's also no single formto convert a value into a non-inverted boolean, is there? eg (when (not (null x)) ...)
<_death>
(setf (fdefinition 'truep) #'identity)
<White_Flame>
well, that's simply renaming, not calling a CLHS function that returns a stated boolean
<White_Flame>
comparable to NULL which takes a value and returns a boolean
<_death>
I also wonder how much booleans (as opposed to generalized booleans) are used in CL.. and why did they pick NIL as default eof-value for example.. why not :EOF? :)
<White_Flame>
easy testing
<_death>
White_Flame: exactly
frost-lab has quit [Quit: Connection closed]
<_death>
White_Flame: if you look at the glossary entry for "true", you see that it's not limited to T, so a TRUEP that returns NIL or T would be misnamed
<_death>
*accepts NIL or T
<White_Flame>
right, again it's not the data semantics, but the notional semantics
<_death>
I guess you want it to return T or NIL like NULL does?
<White_Flame>
NOT and NULL do the exact same thing, but deal with the notions differently
<White_Flame>
oh right, NULL does return T
<_death>
but NULL returns T arbitrarily.. they could just as well make it return :YEAH.. so the glossary entry for T says it's the "canonical generalized boolean"
<White_Flame>
AND and OR with a single value are somewhat comparable, though misused in this sense when given a non-boolean
sauvin has joined #lisp
<White_Flame>
and they don't snap true to T
<_death>
because Lisp is pragmatic
<_death>
otherwise we'd have #T and #F and remove generalized booleans
<White_Flame>
the spec does define notions of boolean, and according to these arguments, those notions should be followed. I'm exploring that space
<_death>
according to what arguments?
<White_Flame>
from the LUV etc
<_death>
well, I'm not sure LUV is cut-and-dry against generalized booleans.. but I've not checked it recently
<White_Flame>
heh, I'm wrong about AND and OR. the clhs pages don't mention boolean at all
<White_Flame>
only NILness
<White_Flame>
so (when (and ...) ..) fails the LUV understandability test
<_death>
which page of LUV are you referring to
<White_Flame>
as does member, as you mentioned above
<White_Flame>
page 13 is what beach brought up
<White_Flame>
and these are mostly extrapolated from there, not literal
<_death>
maybe they meant something slightly different, like "don't use and, or as a progn"
<White_Flame>
and yeah, this casts more assumptions upon the language than the clhs defines
gareppa has quit [Quit: Leaving]
<White_Flame>
(and (numberp x) (cos x)) is listed as bad because (cos x) is not a boolean
<White_Flame>
(but AND is not defined to take or return booleans anyway per the spec)
<_death>
well, instead of COS, let's say it's NULL
<_death>
(and instead of NUMBERP, let's say FOOP)
<White_Flame>
it really comes down to "expectation" which is not universal for such extrapolated concepts
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
<_death>
then still, they may say it's better to (if (foop x) (null x) nil) than (and (foop x) (null x)), even though NULL returns a boolean
vaporatorius has quit [Quit: Leaving]
vaporatorius has joined #lisp
<White_Flame>
nah, those both return booleans. (and (numberp x) (> x 3)) is listed as "follows expectations"
<_death>
White_Flame: I know they both return booleans.. I set up this example on purpose
<White_Flame>
in any case, their expectations are not defined by the CLHS
<_death>
I am saying, maybe they didn't mean "and, or for boolean value only", but something like "don't use and, or to do something other than test"
<White_Flame>
it reads pretty literally, including in light of the examples
wilfredh has quit [Quit: Connection closed for inactivity]
<White_Flame>
the notions are reasonable, but the specifics here are certainly arguable
<White_Flame>
my "expectations" are that there are NIL checks in CL, and especially teh definitions of AND and OR project that, completely ignoring the notion of "boolean" completely in their definition
* White_Flame
edits poorly but should get the point across :-P
varjag has joined #lisp
zaquest has quit [Quit: Leaving]
zaquest has joined #lisp
cchristiansen has quit [Remote host closed the connection]
qing has joined #lisp
qing has quit [Remote host closed the connection]
<_death>
they can't help but use OR that way, by the way.. for example in page 64 they have (or ... (member ...))
<White_Flame>
that's assuming that member is a generalized boolean return
<White_Flame>
the spec calls it "tail -- a list"
<_death>
it's true that they pass it to remove-if and not do something with what it returns, there
<_death>
*do something more
<White_Flame>
so yeah, this is just subjective assumptions of what things "should be" boolean, and certainly there will be disagreements on its reach
vaporatorius has quit [Ping timeout: 256 seconds]
<White_Flame>
and if they "shouldn't be" boolean, then it's by definition ununderstandble
<White_Flame>
in a "should be" boolean location
karlosz has quit [Quit: karlosz]
<White_Flame>
I would rather harp on comments explaining why code is written the way it is
<_death>
maybe they did actually mean it.. I don't see examples to contradict outright
<White_Flame>
the terse style of the document leaves it wide open to interpretation and extrapolation
<_death>
so beach is right to give LUV as a source of support.. I guess I'm a bit farther than LUV's point on this continuum
kslt1 has joined #lisp
ldb has joined #lisp
terpri has quit [Remote host closed the connection]
<beach>
I always thought of myself as a reasonably good teacher. But my complete failure to get the point across every time it is brought up must either mean that I have been wrong about myself all these years, or that I am losing my teaching abilities.
<_death>
beach: I think it's just a subtle point
Inline has quit [Quit: Leaving]
<White_Flame>
to be fair to yourself, we only get a little snippet here & there, and you rightly don't want to repeat the entire lecture every time
<_death>
beach: it may also be that some people don't see anything out of the ordinary in forms like (loop for line = (read-line ...) while line ...)
<beach>
_death: That is definitely true. And I seem to fail spectacularly to explain the point to those people.
<beach>
I think the origin of the problem is that most people here don't have much experience with large projects in collaboration with many others, so to them, there is no need for conventions.
<_death>
beach: "hell is other people's code" :)
<beach>
So anything that respects the semantics of the language is OK to them.
<White_Flame>
I'll take that as a misdirected slight ;)
<_death>
beach: I'm not sure there's a need to go that far.. it's possible for them not to see an issue there and to see tons of issues elsewhere
<beach>
This is why I invoke the LUV slides, written by highly experienced people in this respect, rather than stating the point as my personal opinion. These other people always end up stating their personal opinion that WHILE LINE is fine for them, but that is so totally beside the point in terms of conventions, which are precisely NOT a question of personal opinions.
<White_Flame>
just yesterday, I had to get into untouched-for-years code in a large commercial project, and good comments in the source code made it easy
<White_Flame>
there are no "weird" conventions in the source code, but different teams have different levels of familiarity
Inline has joined #lisp
<White_Flame>
those teams where there's large turnover and documentation describing conventions, those conventions stil have to be learned
<_death>
beach: right, but it's one thing to give LUV as an example of support, written by experts, and it's another thing to expect that everyone adopts it
<White_Flame>
"the only intuitive interface is the nipple, all else is learned", I do maintain that there is no universal workable "expectation" set for conventions
<White_Flame>
and that is either specified to a team, or tribal knowledge within it
orivej has joined #lisp
really2 has joined #lisp
<beach>
_death: I have never asked for everyone to adopt the advice. I keep saying over and over again, that people should feel free to not respect conventions, as long as they also don't expect others to then read and debug their code for them.
<White_Flame>
which set of conventions?
<White_Flame>
have you seen help-givers here confused by (and value (op value)) ?
<beach>
Yes, me.
<beach>
I said that already.
<beach>
I have to stop and think about it for a few seconds.
<beach>
And that is the point that I am apparently still unable to get across.
<White_Flame>
is (when value (op value))'s potential return value of NIL also confusing to read?
<beach>
That these conventions exist to avoid surprises to the person reading the code and to speed up the process of understanding it.
<White_Flame>
to those familiar with such style, it is neither surprising nor unexpected
<_death>
beach: yeah, but some things are subtle, like this point, and some things are less subtle, like one closing paren per line.. so I'm guessing more people would make a fuss reading the code doing the latter
<White_Flame>
and arguably the (or (foo) (member ...)) falls under the same classification
<White_Flame>
yes, I do see much more agreement on poor indentation and paren style making code unreadable
<White_Flame>
and conventions are artifacts of groups
<beach>
I find it hard to believe that two highly experienced people like Norvig and Pitman would be completely unfamiliar with these examples, and that this unfamiliarity is the basis for the conventions they expose in the LUV slides.
really2 has quit [Ping timeout: 264 seconds]
<White_Flame>
oftentimes, these are imposed to a large group of developers to keep the least experienced on a limited track
<White_Flame>
(generally speaking, not necessarily specific to that doc)
<beach>
And I myself am certainly familiar with code like that. Nevertheless I am a member of the target group for the LUV slides, namely the group of people who have to pause to figure out what it means.
<beach>
And, sure, maybe I am one of the least experienced people here when it comes to Common Lisp programming. It is entirely possible.
<White_Flame>
well, it's certainly a lot to do with environment
<White_Flame>
commercial, academic, and self-learning need to hold different considerations
vegansbane6963 has joined #lisp
<ldb>
the sin is start coding without a complete understand of the problem to tackle
<beach>
I never think of myself as unique. So if Norvig and Pitman claim that there are people who are slowed down by code like this, there must be quite a few of us.
skapata has quit [Remote host closed the connection]
<White_Flame>
there's a lot of judgment vs pedantry in how such things are determined, collected, and thrust upon others
<_death>
beach: the LUV is an excellent document.. I think I read it at least once a year
<White_Flame>
in the scenario of trying to control code problems within a team
<White_Flame>
eg, somebody writes a good idea, and it gets treated by the letter of the law
<_death>
I guess there also needs to be a "suspension of belief" part, where you just follow a convention, even if you don't like it or see the point at first.. after a while, it may (or may not..) become preferable.. I guess one point of resistance is that (not (null line)) is more verbose, but maybe it's worth trying to follow for a while
<White_Flame>
yep, and that depends on what team you're on
<White_Flame>
in a place like this, there's a collision of conventions
<_death>
White_Flame: even without a team, just to make up a personal style decision
<White_Flame>
yep, and that's very pick-and-choose
<White_Flame>
and there's certainly a difference between a newbie who is trying stuff, vs somebody who has developed conventions elsewhere
<_death>
in that particular case "until (null line)" could avoid the "double-negative" feel
random-nick has joined #lisp
toorevitimirp has joined #lisp
Noisytoot has joined #lisp
kingcons has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
<pranavats>
Hello, is there any simple way to compare two standard objects for equality of their slot values without writing a special function for each class?
<_death>
in general, no
<pranavats>
I want to write test for a function that returns a standard object composed of many other such objects. Is writing special functions for each class the only option to test for equality of slots?
<_death>
and in general, it doesn't depend just on the class, but also on what you want to use it for
<pranavats>
I see
<White_Flame>
equality in general is too general to have some singular general operation. Even the standard CL stuff has 4 generic equality operations, and even those don't suffice for every case
<pranavats>
Yes, but some functions like MEMBER accept equality test functions to mitigate that.
<_death>
the MOP can give you introspective capabilities like that, so that may work in a particular domain
<pranavats>
Thanks
Cthulhux has quit [Ping timeout: 246 seconds]
Cthulhux has joined #lisp
shifty has joined #lisp
klltkr has joined #lisp
frodef has quit [Ping timeout: 260 seconds]
JokerAscensionEx has joined #lisp
JokerAscensionEx has quit [Remote host closed the connection]
toorevitimirp has quit [Quit: Konversation terminated!]
frodef has joined #lisp
xanderle has quit [Ping timeout: 256 seconds]
toorevitimirp has joined #lisp
drl has joined #lisp
JokerAscensionEx has joined #lisp
JokerAscensionEx has quit [Remote host closed the connection]
<phoe>
pranavats: as long as you know what you are doing, you can write your own equality predicate that uses mapcar #'slot-value over mop:class-slots for standard objects and defers to whichever predicate you want (eq/eql/equal/equalp/???) for non-standard-objects
<phoe>
and that's going to be a single function
<phoe>
but remember that this is going to work only as long as you know what you're doing
<phoe>
that's the way I'd approach it; maybe with a custom metaclass for transient slots if I ever need those, and the equality predicate being a GF so I can define custom methods if I need those
<phoe>
but as _death and White_Flame already wrote, equality is not a well-defined term so there's no well-defined solution; you'll need to suit yourself
SumoSud0 has quit [*.net *.split]
stux|RC has quit [*.net *.split]
cg505_ has quit [*.net *.split]
dim has quit [*.net *.split]
gabc has quit [*.net *.split]
cpape`` has quit [*.net *.split]
shinohai has quit [*.net *.split]
jxy_ has quit [*.net *.split]
sukaeto1 has quit [*.net *.split]
guaqua_ has quit [*.net *.split]
Patternmaster has quit [*.net *.split]
lonjil has quit [*.net *.split]
jealousmonk has quit [*.net *.split]
mrSpec has quit [*.net *.split]
cross has quit [*.net *.split]
tgbugs has quit [*.net *.split]
Mandus has quit [*.net *.split]
grfn has quit [*.net *.split]
tychoish has quit [*.net *.split]
glamas has quit [*.net *.split]
yottabyte has quit [*.net *.split]
XachX has quit [*.net *.split]
srji has quit [*.net *.split]
|3b| has quit [*.net *.split]
jgkamat has quit [*.net *.split]
eagleflo has quit [*.net *.split]
guaqua has joined #lisp
gabc_ has joined #lisp
Mandus has joined #lisp
glamas has joined #lisp
lonjil2 has joined #lisp
eagleflo has joined #lisp
shinohai_ has joined #lisp
cpape``` has joined #lisp
srji has joined #lisp
Patternmaster has joined #lisp
jxy has joined #lisp
tgbugs has joined #lisp
sukaeto1 has joined #lisp
XachX has joined #lisp
yottabyte has joined #lisp
mrSpec has joined #lisp
grfn has joined #lisp
jealousmonk has joined #lisp
cross has joined #lisp
stux|RC has joined #lisp
mrSpec is now known as Guest14581
cg505 has joined #lisp
Lycurgus has joined #lisp
thijso has quit [Ping timeout: 245 seconds]
|3b| has joined #lisp
<pranavats>
Thank you phoe
tychoish has joined #lisp
jgkamat has joined #lisp
dim has joined #lisp
Nilby has joined #lisp
<_death>
you may also want to make use of slot-boundp first ;)
<phoe>
and this is going to break the moment you try to descend into slots of an object that is not meant to be compared in such a way; hence, ideally, you control all standard objects that you compare, or you trust that the users of your code follow some comparison protocol that you establish and leave that to them
<phoe>
oh right, there's the case of two slots that are unbound
notzmv has quit [Ping timeout: 264 seconds]
<phoe>
which opens another can of worms
<_death>
and then, the slot could be lazily initialized, so again it's not a general answer
<phoe>
do we treat those as "equally unbound" or do we treat those as "SQL NULL is never equal to another NULL"
<phoe>
lots of ways to get burned
SumoSud0 has joined #lisp
<_death>
and then, the slot may disappear at some point, because the value will become computed..
<phoe>
slot? you mean the class will be redefined or something?
<phoe>
or do you mean the value will become unbound
<White_Flame>
or lazy initialization of clos slots might mean a slot dynamically appearing
<_death>
yeah, the class may be redefined for example.. yet it may still be true that the objects should be "equal"
<phoe>
that's yet another can of worms :D
<phoe>
nope, I'm not touching this one
* phoe
afk
* White_Flame
runs back to the relative safety of unification
thijso has joined #lisp
drl_ has joined #lisp
<edgar-rft>
maybe the universe will explode during the test...
aartaka_d has joined #lisp
drl_ has quit [Quit: Leaving]
drl_ has joined #lisp
aartaka has quit [Ping timeout: 264 seconds]
matryoshka has joined #lisp
shifty has quit [Ping timeout: 264 seconds]
<Nilby>
Sometimes I think there should be a gc-equal which just compares the bits of what the gc would have to copy, but that's a surprisingly Very Heavy thing, especially if you have an object with some kind of *all-packages* value.
contrapunctus has left #lisp ["Disconnected: Replaced by new connection"]
contrapunctus has joined #lisp
drl_ has quit [Quit: Leaving]
kaiwulf has joined #lisp
<_death>
pequal returns the probability that two objects are equal
surabax has joined #lisp
Lycurgus has quit [Quit: Exeunt]
drl has quit [Quit: Leaving]
<_death>
it is conditional on the types, but otherwise assumes uniform distribution.. so for example, if passed two bignums it will return (/ (sq (- (- most-positive-bignum most-negative-bignum) (- most-positive-fixnum most-negative-fixnum))))
<Nilby>
_death: You comments have a high probability of sending me on research rabbit hole
<_death>
what kind of research?
<Nilby>
probabilistic theorem provers this time
<_death>
ah.. then maybe dequal, which returns a probability distribution instead of a point probability, is better :)
kslt1 has quit [Remote host closed the connection]
notzmv has joined #lisp
Guest14581 has joined #lisp
Guest14581 has quit [Changing host]
Guest14581 is now known as mrSpec
long4mud has quit [Quit: WeeChat 3.0.1]
<drmeister>
Hey lispers - I'm implementing save-lisp-and-die in clasp and I have a question.
<drmeister>
Does it make sense to provide a facility where the programmer can register callbacks that get called at image-save time to clear dynamic variables and shutdown things so that when the image is loaded they can be lazily recreated. It does right?
McParen has joined #lisp
<Nilby>
I think so. Also asdf has *image-dump-hook*
<Nilby>
oh and sbcl has *save-hooks* or something
<splittist>
uiop's generalisation of image-saving might be worth a look
<flip214>
phoe: does the comment about sharing storage with old list items no longer hold?
<phoe>
flip214: I'm just a messenger, it's _death commit :D
<flip214>
_death: ^^
<drmeister>
I've added to Clasp the ability to debug JITted code within GDB and LLDB.
<drmeister>
This lets me use the time-traveling debugger "Undo" to debug Common Lisp and C++.
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<drmeister>
It's been invaluable for debugging image save/load.
CrazyPython has joined #lisp
notzmv has quit [Ping timeout: 264 seconds]
VeeBoi has joined #lisp
<phoe>
easye: boop
Necktwi has quit [Ping timeout: 245 seconds]
supercoven has joined #lisp
CrazyPython has quit [Ping timeout: 246 seconds]
toorevitimirp has quit [Remote host closed the connection]
VeeBoi has quit [Ping timeout: 240 seconds]
andreyorst has joined #lisp
<phoe>
Xach: I think you'd like to join #quicklisp
ljavorsk has joined #lisp
edgar-rft has quit [Quit: Leaving]
renzhi has joined #lisp
mindCrime_ has joined #lisp
attila_lendvai_ has joined #lisp
notzmv has joined #lisp
Vra has joined #lisp
dilated_dinosaur has quit [Ping timeout: 245 seconds]
notzmv has quit [Ping timeout: 256 seconds]
dilated_dinosaur has joined #lisp
notzmv has joined #lisp
Vra is now known as zomq
nullx002 has quit [Ping timeout: 276 seconds]
charles` has joined #lisp
rickygee has quit [Ping timeout: 264 seconds]
charles` has quit [Ping timeout: 264 seconds]
mindCrime_ has quit [Ping timeout: 246 seconds]
nullx002 has joined #lisp
charles` has joined #lisp
charles` has quit [Ping timeout: 264 seconds]
mindCrime_ has joined #lisp
engblom has quit [Read error: Connection reset by peer]
engblom has joined #lisp
nullx002 has quit [Quit: qicr for android: faster and better]
long4mud has joined #lisp
CrazyPython has joined #lisp
davisr has quit [Remote host closed the connection]
rogersm has joined #lisp
v0|d has joined #lisp
<v0|d>
any update regarding els2021?
<v0|d>
heisig around?
Oladon has joined #lisp
elusive has joined #lisp
charles` has joined #lisp
zomq has quit [Ping timeout: 240 seconds]
Sheilong has joined #lisp
cosimone has joined #lisp
matryoshka has quit [Ping timeout: 272 seconds]
ldb has quit [Ping timeout: 256 seconds]
rogersm has quit [Remote host closed the connection]
klltkr has joined #lisp
Vra has joined #lisp
waleee-cl has joined #lisp
random-nick has quit [Quit: quit]
kaiwulf has joined #lisp
random-nick has joined #lisp
rogersm has joined #lisp
cosimone has quit [Remote host closed the connection]
charles` has quit [Ping timeout: 264 seconds]
gigetoo has quit [Ping timeout: 260 seconds]
<flip214>
does someone have a PostgreSQL check constraint => common lisp converter lying around? is something useful for that in PGLOADER?
gigetoo has joined #lisp
Oladon has quit [Quit: Leaving.]
warweasle has quit [Quit: gotta run]
Bike has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
Vra has quit [Ping timeout: 240 seconds]
amb007 has quit [Read error: Connection reset by peer]
McParen has left #lisp [#lisp]
amb007 has joined #lisp
rixard has quit []
amb007 has quit [Read error: Connection reset by peer]
rogersm has quit [Quit: Leaving...]
amb007 has joined #lisp
rogersm has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
rixard has joined #lisp
shifty has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #lisp
yitzi has quit [Quit: yitzi]
shifty has quit [Ping timeout: 256 seconds]
shifty has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
vaporatorius has joined #lisp
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
rogersm has quit [Remote host closed the connection]
rogersm has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
rogersm has quit [Remote host closed the connection]
cage_ has quit [Quit: Leaving]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
karlosz has joined #lisp
anticrisis has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
karlosz has quit [Client Quit]
amb007 has joined #lisp
corpix has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
shifty has quit [Ping timeout: 256 seconds]
amb007 has quit [Read error: Connection reset by peer]
shifty has joined #lisp
amb007 has joined #lisp
pankajsg has quit [Ping timeout: 256 seconds]
corpix has quit [Quit: corpix]
amb007 has quit [Read error: Connection reset by peer]
corpix has joined #lisp
amb007 has joined #lisp
attila_lendvai_ has quit [Quit: Leaving]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
orivej has quit [Ping timeout: 246 seconds]
shifty has quit [Ping timeout: 256 seconds]
shifty has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
bendersteed has joined #lisp
gitgood has joined #lisp
tinhatcat has joined #lisp
mindCrime_ has quit [Ping timeout: 256 seconds]
shifty has quit [Ping timeout: 256 seconds]
amb007 has quit [Read error: Connection reset by peer]
shifty has joined #lisp
amb007 has joined #lisp
shifty has quit [Ping timeout: 256 seconds]
sm2n has quit [Ping timeout: 256 seconds]
Jesin has quit [Quit: Leaving]
tinhatcat has quit [Quit: Leaving]
sm2n has joined #lisp
<_death>
phoe: hmm, not sure what that has to do with my commit?
Jesin has joined #lisp
Vra has joined #lisp
Jesin has quit [Remote host closed the connection]
<_death>
flip214: I removed that part of the sentence because it was redundant (you expect that with destructive operators) and a bit poorly worded (and contained a typo)
bendersteed has quit [Ping timeout: 260 seconds]
Jesin has joined #lisp
Jesin has quit [Remote host closed the connection]
bendersteed has joined #lisp
aartaka_d has quit [Read error: Connection reset by peer]
Jesin has joined #lisp
Jesin has quit [Client Quit]
Jesin has joined #lisp
ficl has quit [Ping timeout: 264 seconds]
tiwEllien has quit [Ping timeout: 264 seconds]
tiwEllien has joined #lisp
supercoven has quit [Ping timeout: 264 seconds]
<phoe>
_death: this is your commit that was cherrypicked onto clnet, that's all
shifty has joined #lisp
<_death>
phoe: oh, ok.. I took it you linked some comment about the test results so I didn't understand
<phoe>
nope, just mentioned the cherrypick
<phoe>
tests all seem to pass, the test framework does not complain.
warweasle has joined #lisp
shifty has quit [Ping timeout: 256 seconds]
cosimone has joined #lisp
theruran has quit [Quit: Connection closed for inactivity]
FennecCode has quit [Ping timeout: 258 seconds]
FennecCode has joined #lisp
theruran has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
pve has quit [Quit: leaving]
<drmeister>
I have image save/load working now in Clasp - with the boehm garbage collector.
cosimone has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
cosimone has joined #lisp
cosimone has quit [Remote host closed the connection]
rpg has quit [Read error: Connection reset by peer]
surabax has quit [Quit: Leaving]
Vra has quit [Quit: Connection closed]
elusive has quit [Quit: Leaving]
curtosis[away] has joined #lisp
bendersteed has quit [Quit: bye]
kslt1 has joined #lisp
kslt1 has quit [Quit: leaving]
rumbler31 has quit [Ping timeout: 245 seconds]
corpix has quit [Remote host closed the connection]
corpix has joined #lisp
curtosis[away] has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]