seninha has quit [Remote host closed the connection]
rob_w has joined #picolisp
<abu[m]>
beneroth: I checked the change history of +Dep. Now I remember. There were some changes to +Dep in pil21
<abu[m]>
The main reason was that it did not work correctly if one of the dependent relations was an +Aux
<abu[m]>
But: *if* you have an +Aux there, then +Dep gives trouble if the +Dep relation is also indexed
<abu[m]>
So I decided to recommend +Dep olny for joints
<abu[m]>
All my use cases were joints so far, except for that (new) case where I noticed the problem
<beneroth>
abu[m], thanks. Yeah my case is not an +Aux. Still, I wonder how the problem manifests. At least in the pil64 implementation +Dep just executes a 'put> NIL
<abu[m]>
yes, but this may trigger an +Aux, which in turn triggers the +Dep
<abu[m]>
and if this +Dep is an index, it triggers the +Aux and so on
<abu[m]>
I also do nor remember what exactly happened ;)
<abu[m]>
But as all my use cases before were only joints, I thought this is the sane case
<beneroth>
ah, the +Dep gets circularly triggered. I see.
<abu[m]>
Thus I wrote that recommendation into the reference
<abu[m]>
Yeah. Could probably be handled somehow, but I thought it not worth the trouble
<beneroth>
why not catch the situation? e.g. adapting the +Dep implemention to something like (unless *+DepRecur (let *+DepRecur T (do the +Dep stuff))
<beneroth>
yeah
<beneroth>
(+Aux +Joint) doesn't make sense. But so the problem is not Non-+Joint per se
<abu[m]>
yes, something like that
<beneroth>
+List +Bag might be a problem... not sure
<abu[m]>
but kind of ugly ;)
<beneroth>
not really, but yeah... ;-)
<beneroth>
anyway, so it means by use case should be stable also in pil21 :)
<beneroth>
*my use case
<abu[m]>
No, it is the other side of the +Dep
<abu[m]>
If you have a (+Dep +Ref +Link)
<beneroth>
yeah the target of +Dep which gets cleared, no?
<beneroth>
the target relation
<abu[m]>
and the deps are one or more +Aux
<abu[m]>
With target you mean the dependent relations? Those in the list argument.
<beneroth>
I don't see the circular call. But I haven't run the code.
<beneroth>
this is two independent cases, right?
<abu[m]>
Yes, two cases
<beneroth>
I would have expected the +Join being part of the depended +Aux might be the problem. But that is not the situation here.
<abu[m]>
Here it is not circular, because the +Deps are Joint or Link
<beneroth>
in the second case, 'usr gets NILed two times.
<beneroth>
ah
<beneroth>
yeah
<beneroth>
this multiple NILings and +Dep give neverending NILings
<beneroth>
because the check if old and new value are the same happens later.
<abu[m]>
Yes
<abu[m]>
So I wanted to discourage this
<beneroth>
well if the +Joint relation would be used in another +Aux relation (as part of the aux) you would run into the same problem again, no?
<beneroth>
ofc using a +Joint in an +Aux might be rather.. silly.
<abu[m]>
Yes, this is the assumption
<beneroth>
a bit of a stretch tbh
<abu[m]>
The other assumption was about te purpose of +Dep
<abu[m]>
It assumes it triggers when the remote object of a +Joint clears its part
<beneroth>
good point. What is your definition of the purpose of +Dep ?
<beneroth>
hmm
<abu[m]>
Manipulating an object locally does not need +Dep
<beneroth>
for me the fact that it's a +Joint is not significant, even though the primary use case. For me its just (having rels 'a und 'b) that whenever 'a is cleared, 'b must be cleared too.
<beneroth>
I use it exactly for manipulating object locally xD
<beneroth>
instead of two put> NIL at every location where this put> NIL could happen
<abu[m]>
But why then just upon clear? I think local modifications and side effects are better handled in 'upd>', it is more general
<beneroth>
I see your point. My use case is unusual - when you have interdependent relations you often model them in their entity, and then the case vanishes again.
<abu[m]>
yes, a single put>, but upd> can do anything with it
<abu[m]>
So you can well ignore the recommendation and use +Dep
<abu[m]>
just be careful ;)
<abu[m]>
be careful not to have an +Aux involved
<beneroth>
in my case, I have two relations, 'a is a +Date and 'b a +Symbol. The business case is, that I can know the 'a date precisely, or just the month, or just the year. I use the secondary +Symbol relation to track if its month or year.
<beneroth>
yes I know :)
<beneroth>
rules are made to THINK before breaking them, it's not about never breaking them (unless its rules of physics, then the rules are false)
<abu[m]>
I just thought targeting +Dep as a +Joint prefix makes things simpler
<beneroth>
only because you assume nobody mixes +Joint and +Aux :D
<beneroth>
(no I don't do that! xD)
<abu[m]>
Yeah, +Joint never makes sense with an index
<abu[m]>
(+Ref +Link) is a kind of equivalent of +Joint, and it *would* make sense in an +Aux, but here (in my mind) a +Dep is not meaningful as it is never triggered indirectly
<beneroth>
T
<abu[m]>
The original idea of +Dep was a joint, and when the remote objects changes or modifies its part of the Joint, the local object becomes garbage and should therefore clear all its dependencies
<beneroth>
yeah makes sense
<beneroth>
I guess your use case is mostly header with multiple body lines
<beneroth>
Kopf und Posten :)
<abu[m]>
Yes, I think of them as sub-objects, never directly searchable in dialogs
<abu[m]>
But in fact the first case in the above example is not
<abu[m]>
these objects exist independently
<abu[m]>
Still they need to clear some context if the opposite guy goes off
<beneroth>
yeah
<beneroth>
a complete other topic
<beneroth>
I think I'm a bit unhappy with (udp> . +List). I got this correctly, that in (udp> . +List) the New parameter can be both a whole list (replacing the list) or a single value (to be added to the +List).
<beneroth>
?
<beneroth>
can be handled, but I think I have a case where I overlooked that special case of +List vs. udp> calls with atomic values.
<Regenaxer>
Oh, your messages "I think I'm a bit ..." did not show up in matrix :(
<Regenaxer>
I resort to here ;)
<Regenaxer>
Right, in case of a changed list it may be unclear
<abu[m]>
Ah, now the messages appeared
<abu[m]>
Grr, a bit unreliable
<abu[m]>
hmm, but wait. No, a list is not a problem
<abu[m]>
The first parameter 'X' tells what we get
<abu[m]>
It may be T, NIL, atomic or list
<abu[m]>
If it is a list, the object's class was changed
<beneroth>
I'm talking about (upd> . +relation) not (upd> . +Entity)
<beneroth>
it's about changed +List relation, not class changes :)
* beneroth
still thinks that matrix approach is BS and separate messengers are okay. :P
<abu[m]>
So you overrode upd> of +List?
<abu[m]>
I handle all upd> on the entity level
<abu[m]>
(I still prefer matrix, much more convenient handling of media)
<abu[m]>
(and I don't need to be logged in, most of all)
<beneroth>
(hmm.. media, T. logged in.. well technically you are logged in..maybe a pilbox IRC client would be an idea...)
<beneroth>
I made additional prefix classes I prefix +List with
<abu[m]>
Back to upd>, neither in entity nor relation is a "New" value passed
<beneroth>
you're right, I'm mixing something up
<beneroth>
right, I use (rel> . +relation).
<beneroth>
and (upd> . +Entity)
<beneroth>
nevermind :)
<beneroth>
my point applies to (rel> . +relation) I think.. but no problem
<abu[m]>
yes, rel> is the main workhorse of all
<beneroth>
yeah, same in +Dep
<abu[m]>
and here we indeed may get an atom or a list, and rel> tries to be clever
<beneroth>
it must be clever :)
<abu[m]>
And in +Bag it is extended to two levels I think. It does not work an all pathological situations.
<beneroth>
how did you end up with this elegant mechanic (+relation methods I mean).. just evolution, bit by bit? or multiple iterations with other approaches?
<beneroth>
yeah +Bag is kinda ugly
<abu[m]>
Fortunately the +Chart in the gui always sends whole bags
<beneroth>
can get tricky quickly
<beneroth>
ah I see
<beneroth>
I have some code which does low level destructive modifying of +Bag
<beneroth>
(not general code, specific)
<abu[m]>
I think this relation structure was there since beginning
<abu[m]>
Specific modifications or bags are best
<beneroth>
I think it's a very nice illustration of what (I think) Alan Kay intended with OOP
<abu[m]>
Even worse is "bagBag" :D
<abu[m]>
I use it more and more often
<beneroth>
the +relation prefix method calling, I mean
<beneroth>
not the bag
<beneroth>
yeah bagBag
<beneroth>
oh no >.<
<abu[m]>
Yes, I understood your question that way
<beneroth>
combining +List and +Bag has the (not so) nice effect that you cannot be sure if you handle an list element or the whole thing
<beneroth>
but yeah
<abu[m]>
right
<beneroth>
+Bag is useful
<beneroth>
in small doses :)
<abu[m]>
So bag tries to do some matching, but it is not really guaranteed to succeed
<abu[m]>
yep, small doses ;)
<abu[m]>
What is bad in the matrix client is that it does not have monospaced fonts
<abu[m]>
Not good for code snippets
<beneroth>
so it has media, but these developers didn't think of adding a codeblock feature? :/
<beneroth>
normal markdown notation has it
<abu[m]>
Ideal would be to configure it per room
<beneroth>
that could actually compete with IRC for dev communication, a codeblock element with language setting and syntax highlighting
<abu[m]>
Should put a feature request to Fluffy
<abu[m]>
or Element
<beneroth>
too many seemingly-unrelated names :(
<abu[m]>
well, too many clients for Matrix
<abu[m]>
I'm using Element and FluffyChat
<abu[m]>
The names "Matrix" and "Element" are *very* poor decisions
<abu[m]>
Impossible to search for them, you get millions of unrelated hits
<beneroth>
T
<beneroth>
well Riot was also bad naming
<abu[m]>
true
seninha has joined #picolisp
rob_w has quit [Quit: Leaving]
kced has joined #picolisp
clacke has quit [Read error: Connection reset by peer]
chexum has quit [Remote host closed the connection]