<aw->
<Regenaxer> The problem with RISC-V is that pil64 is designend in such a way that it absolutely *depends* on CPU flags
<aw->
what is this "CPU flags" ?
<razzy>
Hi all. I joined in on conference. Hope you do not mind :]
<razzy>
I do not see computer screen on jitsi conference. Is it problem on my side?
<razzy>
yeah, problem on my side
<razzy>
solved
<Regenaxer>
aw-, most importantly the carry flag
<Regenaxer>
pil64 also uses sign flag and zero flag a lot
<Regenaxer>
razzy, welcome of course
<razzy>
Thank you, bye :]
<Regenaxer>
:)
mtsd has quit [Quit: Leaving]
rubdoslj has joined #picolisp
rubdoslj has quit [Connection closed]
<aw->
Regenaxer: hi
<aw->
but that's not an issue anymore with pil21?
rob_w has quit [Quit: Leaving]
<Regenaxer>
No, llvm has at least the carry control
<Regenaxer>
ok, concerning RISC-V, the runtime logic is different then
<Regenaxer>
it compares register values
<Regenaxer>
but PilAsm is oriented to branch on these condition code register bits
<Regenaxer>
For pil21 it is not an issue because it compiles to a different architecture (not a normal CPU like emulated by PilAsm, but an SSA architecture)
HobbyLM has joined #picolisp
HobbyLM has quit [Remote host closed the connection]
razzy has quit [Quit: Connection closed]
Torgeir has joined #picolisp
Torgeir has quit [Remote host closed the connection]
MEPBZL has joined #picolisp
MEPBZL has quit [Remote host closed the connection]
orivej has joined #picolisp
razzy has joined #picolisp
<aw->
ok i see
<aw->
thank you!
<beneroth>
Regenaxer, do you have some time for pilog troubles?
<beneroth>
1) I wondered select/3 optimizes index/generator usage also on partial matches, or only on full matches (all filter clauses satisfied), maybe you know? Asking because I consider using select/3 with (prove), wondering if that is meaningful
<beneroth>
I would think even if select/3 only optimizes based on full matches, using select/3 with (prove) might still be faster than traversing a single index, if the used indexes/generators happen to have very different lengths/sizes
<beneroth>
2) Secondly I have trouble with writing generator clause for +Aux, I can get it working but get I invalid matches. So my generator is wrong, or my filter clause (using bool predicate)
<Regenaxer>
Hi beneroth
<beneroth>
\o/
<Regenaxer>
It always puts matches in front of the search, hes
<Regenaxer>
and a match is always if all non-empty search criteria are fulfilled
<beneroth>
ok
<beneroth>
I expect (prove) to stop at the first match (all criteria fulfilled)
<Regenaxer>
Yes, that's right
<beneroth>
so select/3 generator optimization is not happening when using it with (prove)
<Regenaxer>
Why not?
<beneroth>
only 1 match?
<beneroth>
so its round robin, until the shortest generator is exhausted?
<Regenaxer>
Not necessarily the shortest
<Regenaxer>
the first one exhausted
<beneroth>
T, on a match
<Regenaxer>
Yes, or no matches
<beneroth>
when no match is can be found, then it stops on shortest generator, no?
<Regenaxer>
yes
<beneroth>
ok
<Regenaxer>
I understand
<Regenaxer>
when it never has a full match
<Regenaxer>
then the order is never re-arranged, right?
<beneroth>
so the advantage with multiple length indexes still plays out when using select/3 with prove, should be better than using the not-shortest index
<beneroth>
then again the shortest index can maybe be decided by looking at the counter values, right?
<beneroth>
except for +Aux, which I want to use here :D
<beneroth>
<Regenaxer> when it never has a full match
<beneroth>
<Regenaxer> then the order is never re-arranged, right?
<Regenaxer>
Aux later, it is a different issue
<beneroth>
T
<Regenaxer>
I still did not get your problem with prove
<Regenaxer>
There is no need to determine the shortest index
<beneroth>
order not arranged.. I would expect it to switch generator on every iteration/candidate? just an assumption
<beneroth>
what I mean is
<Regenaxer>
as soon as *one* index is exhausted, there is no need to continue
<beneroth>
T
<Regenaxer>
so, ok
<beneroth>
that is the benefit in using select/3 in (prove) over traversing only a single index
<beneroth>
I assume
<Regenaxer>
it does not switch always
<Regenaxer>
only when a full match
<beneroth>
ok
<beneroth>
so without a full match, it uses the first generator clause to exhaustion?
<Regenaxer>
a full match means we are on the right way
<Regenaxer>
hmm, wait
<beneroth>
yes, but I believe (prove) stops at first full match, right?
<Regenaxer>
of course it rotates
<Regenaxer>
sorry, I forgot
<Regenaxer>
would make no sense
<beneroth>
yes, but on every iteration (checking a possible match) or only after a successful match?
<beneroth>
yeah well "I don't know anymore" is an acceptable response to this question :D
<Regenaxer>
It must rotate on every step
<beneroth>
so I would assume
<Regenaxer>
otherwise it would hang forever in the first index which may be verrrry long
<beneroth>
exactly
<beneroth>
T
<Regenaxer>
yeah
<Regenaxer>
For an +Aux search, you must give a FROM and a TO
<Regenaxer>
They must be both lists
<beneroth>
so then a (prove) with a select/3 which uses multiple generators will do maximum (+ <length of shortest generator> + <number of generators -1>) rounds
<beneroth>
ok, about Aux
<beneroth>
that is already a good input
<beneroth>
I understood I had to make lists, but not a FROM and TO
<Regenaxer>
yeah
<Regenaxer>
Best way is to (trace 'init)
<Regenaxer>
That way you see what is actually used
<beneroth>
can the lists be inline within the pilog generator clause code? or do the lists have to be first bound to pilog variables @From @To which then are used in the generator code?
<beneroth>
Regenaxer> Best way is to (trace 'init
<beneroth>
right, I forgot!
<Regenaxer>
They can be inline
<beneroth>
ok
<Regenaxer>
Pilog anyway first expands variables
<beneroth>
second.. I search a code example
<beneroth>
so pilog code for Aux generator should like this?
<beneroth>
@A A @B B (select (@X) ((auxprop Entity ((@A @B) . (@A @B)))))
<beneroth>
an aux value can be partial (shorter than the index keys) ? e.g. (auxprop Entity ((@A @B) . (@A @B))) even when the relation is (+Aux +Ref +Sym) (a b c))) ?
<beneroth>
ah, ok that also answers my last question
<beneroth>
an incomplete aux from/to value has to end with T or NIL
<Regenaxer>
Yes, but this comes actually from +Ref
<beneroth>
T
<Regenaxer>
+Ref needs this
<beneroth>
because it just compares CDRs, and this way T/NIL matches both atomic values and also lists
<beneroth>
bad wording, but don't know
<beneroth>
maybe you understand what I mean :D
<Regenaxer>
not really. It compares all, not just CDRs?
<beneroth>
we have a lack of terminology for such a detail level
<beneroth>
yes
<beneroth>
but the key has not all, but then T/NIL are well comparable to a list of more values
<beneroth>
e.g. aux with 3 properties, and the search value is only 2 values
<Regenaxer>
This works because T is infinite
<Regenaxer>
(a T) is bigger than (a b c d)
<beneroth>
yep, that I meant
<beneroth>
tried to say
<beneroth>
exactly
<Regenaxer>
:)
<beneroth>
:)
<beneroth>
thank you very much!!!
<beneroth>
I try out now
<Regenaxer>
No problem :)
<Regenaxer>
great
<beneroth>
I have multiple +Aux with up to 3 indexed properties on the same object
<beneroth>
and one select/3 clause with multiple generators
<Regenaxer>
very advanced
<beneroth>
and the aux filter values might be shorter or the same length as the indexed values
<beneroth>
T
<beneroth>
the point of it is a kind of +Annotation which can be attached to a large number of other data
<Regenaxer>
I see
<beneroth>
and then to efficiently check if there are any annotations at all for given criteria (therefore (prove), I'm not interested in the values but if something exists or not))
<beneroth>
(of course sometimes also get the values with more traditional pilog)
<beneroth>
because I use +Aux (for other reasons.. because also doing exact (aux) calls), I cannot tell which index/generator is the shortest (without +Ref, I could check the object count on the index)
<beneroth>
so I believe select/3 will do the optimal thing here, even when used with (prove)
<beneroth>
makes sense?
<Regenaxer>
right, but with select/3 it is not an issue, right?
<Regenaxer>
yes, I think so
<beneroth>
thanks =D
<beneroth>
yeah I believe my aux values were just wrong
<Regenaxer>
never tried with bool in the first position
<beneroth>
that might be the issue
<Regenaxer>
but should be ok
<beneroth>
yes, so we thought
<beneroth>
I will first try with correct generator
<Regenaxer>
The index would be (T ...) or (NIL ...)
<beneroth>
but my filtere is correct, no ?
<beneroth>
yes should be so
<Regenaxer>
(scan (tree 'foo ...
<beneroth>
right, I should do that!
<Regenaxer>
yes, the (bool @Foo ... is good
<beneroth>
ok
<Regenaxer>
if @X is the object
<beneroth>
yes
<Regenaxer>
(select (@X)
<Regenaxer>
ok
<beneroth>
T
<beneroth>
I try out
<beneroth>
interestingly, my wrong code worked except for one combination of property values where it matched in violation of the filter clause
<beneroth>
or so it looked to me
<Regenaxer>
hmm
<beneroth>
I will test now with corrected generator clauses and then look at the tree if the issue is still there
<beneroth>
(yes cannot be, no ideas, maybe I tested wrong - that's also possible...)
<Regenaxer>
Sometimes it helps to do 'msg' between the filter clauses
<beneroth>
ah nice idea
<beneroth>
another question
<Regenaxer>
(@ ^ (msg (-> @X))) or so
<beneroth>
(+Aux +Ref) -> generator clause: do I need to prove FROM and TO even when only looking at a single value, right? then ((@Val NIL) (@Val . T)) ?
<Regenaxer>
or try the whole select/3 call in the repl
<beneroth>
yeah I always try around in the repl.
<beneroth>
I'm getting more used to pilog, but still I often have trouble to do the right amount of parentheses ^^'
<beneroth>
it's all logical, but many details
<Regenaxer>
I always test the single values in the filters
<Regenaxer>
In the above case (same @Kd @@ gp)
<beneroth>
do I need to prove FROM and TO even when only looking at a single value, right? then ((@Val NIL) (@Val . T)) ?
<beneroth>
or can it then also just be (prop Entity @Val) even when its an +Aux +Ref relation?
<Regenaxer>
Not explicitly in the filter
<beneroth>
generator
<Regenaxer>
because the variable is a pair
<Regenaxer>
ok
<Regenaxer>
misunderstood
<beneroth>
I know I have to check in the filters, except when it is a criteria which is part of all generators
<Regenaxer>
If a single value, I think you can use it directly
<beneroth>
ok
<beneroth>
thx
<Regenaxer>
hmm, mot sure not
<Regenaxer>
now
<beneroth>
collect works that way
<Regenaxer>
ah, ok
<beneroth>
iter always needs a list
<Regenaxer>
but collect calls iter
<beneroth>
yeah collect builds a list value if necessary
<Regenaxer>
ok, that's why
<Regenaxer>
yes, a list is needed, otherwise it doesn't match the index keys
<beneroth>
yippiee
<beneroth>
no everything seems to work as I expected
<beneroth>
Regenaxer, I looked at the tree with scan. Secondary +Bool in a +Aux get indexed. But if the primary +Bool of a (+Aux +Ref +Bool) is NIL, then no index entry exists
<beneroth>
makes sense, naturally, when one keeps in mind that the index structures are updated by the relation prefix classes, which don't get called when the property is NIL
<beneroth>
secondary +Bool properties in a +Aux relation also get their changed value properly changed in the index key when their value change
<Regenaxer>
Thanks, good to know
<Regenaxer>
yes, it is natural that primary aools are not indexed