<beneroth>
abu[7], ah btw (we could also discuss on Friday) why is there no ==-variant of lup ?
<beneroth>
any reason or just didn't come up in the past?
<beneroth>
something like lupq or so
<abu[7]>
I think it *is* non-==
<abu[7]>
It uses 'compare' internally
<beneroth>
yeah, it's like assoc
<beneroth>
my question is, why is there no asoq-equivalent for lup
<abu[7]>
assoq uses '=' (equal)
<beneroth>
assoc uses =
<beneroth>
asoq uses ==
<abu[7]>
yeah
<beneroth>
any reason why 'lupq' doesn't exist?
<abu[7]>
No reason, could be built
<abu[7]>
but lup is focused on ranges
<beneroth>
ok :)
<abu[7]>
range needs compare
<beneroth>
true, lupq could not use ranges
<abu[7]>
but you are right
<abu[7]>
Same for 'idx'
<abu[7]>
idx is quite big, so the question is if it is worth the effort
<beneroth>
currently I use 'lup' alot like 'assoc'/'asoq', for 1:1 mappings based on simple cons pairs, but in an idx because I think its more efficient than a list, especially because for the building I would need to use push1 or push1q
<beneroth>
but I haven't actually benchmarked it
<abu[7]>
For lupq to make sense, also idxq is needed
<beneroth>
not necessarily, but yeah
<beneroth>
one current use case I have (no use of lup): going through a symbol tree structure, collecting certain objects into an idx (unique collection, but I might run into the same objects multiple times), and then on a second run I go through the elements of the idx
<beneroth>
instead I could also use a list/stack and fill it with push1/push1q
<abu[7]>
or a coroutine
<beneroth>
I think idx is faster for the uniqueness-check and if it (potentially) grows very big
<beneroth>
T coroutine could also be used to model it, but I want strictly collect all cases in a first step and process them in a separate second step
<abu[7]>
Makes sense
<beneroth>
otherwise infinite circular cause / effects cannot be ruled out
<abu[7]>
push1q sounds best
<beneroth>
you would prefer push1q over idx? even when the collection can possibly become very large (hundredthousands)
<beneroth>
?
<beneroth>
My understanding / rule of thumb is: list is good enough for few hundred / low thousand cases, with bigger number of elements better use a tree structure
<abu[7]>
I mean to collect unique stuff while traversinp
<beneroth>
yeah currently I just do (idx 'Var Obj T), possibly multiple times with the same Obj, and then afters do practically (for E (idx 'Var) ...)
<abu[7]>
good
<beneroth>
you right, I should probably test it and compare with push1q, maybe the == comparison saves more than the tree doing =
<beneroth>
not sure
<beneroth>
I will do some tests later
<abu[7]>
Are there more than thousand items?
<beneroth>
this here I want to optimize for speed, not necessarily space
<beneroth>
abu[7], yes, can be hundredthousands
<beneroth>
<beneroth> My understanding / rule of thumb is: list is good enough for few hundred / low thousand cases, with bigger number of elements better use a tree structure
<abu[7]>
T, but often space relates to speed
<beneroth>
T
<abu[7]>
I do the same
<abu[7]>
same rule
<beneroth>
well I got it from you :D
<abu[7]>
;)
<beneroth>
<3
<beneroth>
another case, where I use idx and lup: I have a big tree/graph structure of runtime objects (internal symbols with properties) and I want to copy it. So I first iterate through all unique objects (I have a global list of them) and create a new object (new 'lst ...) for each of them, and while doing that (which could also be done with simple 'copy') I also do (idx 'Var (cons Old New) T) as a assoc-mapping (but idx instead of list)
<abu[7]>
ok
<beneroth>
then I go through the whole nested structure of objects and their properties, and complete the new copied structure by looking up the old objects in the idx mapping tree and and insert them into the new structure accordingly
<beneroth>
so the new structure is a complete deep copy of the old structure, buth might be used and diverge from each other later
<beneroth>
(main reason is: its faster, also measured, to copy the structure instead of building it completely fresh, and I need to work with many mostly similar such structures)
<abu[7]>
You can traverse idx'es also manually of course
<abu[7]>
instead of (idx 'X)
<beneroth>
yes. but the idx I build is for mapping, similar how to assoc/rassoc can be used with simple lists of two-element cons-pairs
<beneroth>
a dictionary from OldObject to NewObject
<abu[7]>
ok
<beneroth>
ah
<beneroth>
yeah a bit like *ObjIdx when doing database imports based on (obj) lists
<beneroth>
I guess that is an idx too, according to the name :D
<beneroth>
ah it's built using 'cache'
<beneroth>
yeah same thing
<beneroth>
but yeah, this is an instance where 'idxq' and 'lupq' might make sense.. maybe
<abu[7]>
Yes
<beneroth>
when the programmer is sure that all elements have pointer-identity
<abu[7]>
Or *wants* to handle objects which are ==
<beneroth>
so whenever elements are external objects, or internal symbols
<beneroth>
abu[7], T
<abu[7]>
are = but not ==
<abu[7]>
Sometimes even cells
<beneroth>
yeah might also be a scenario, especially in caching/memnoziation
<abu[7]>
eg. circular loop detection
<beneroth>
T
<beneroth>
circular loops in bigger tree/graph structures :D
<abu[7]>
T
<abu[7]>
This cannot be handled with =
<beneroth>
in my structures here I can legitimaley have indirect circular relations, that's why I first gather elements to process, and their process might cause again elements getting 'dirty' and needing another processing later, but it's finite
<beneroth>
therefore I think coroutines would be no benefit for the added complexity
<abu[7]>
I thought only as generators
<abu[7]>
traversals
<beneroth>
but in other scenarions coroutines could be used to speed up by quasi-parallelization..getting the first results earlier while processing still runs... and maybe also prevent doing multiple iteration
<beneroth>
ah I see
<beneroth>
good point, for generation not handling/processing
<abu[7]>
iterating more than one tree in parallel
<beneroth>
that could produce shorter and more elegant code I guess
<abu[7]>
hard without coroutines
<beneroth>
T
<abu[7]>
because recursive
<beneroth>
yeah
<abu[7]>
init + step do that without coroutine
<beneroth>
well in this computation I do here I only work within a single structure that one is very big and heavily interconnected. But not multiple graphs, just one big network.
<abu[7]>
ok
<beneroth>
but I plan to do difference calculations between two (or more) such structures
<beneroth>
that sounds like coroutines
<abu[7]>
T
<beneroth>
many thanks sensei for this discussion, as always :)
<abu[7]>
np :)
<beneroth>
I will let you know if/when I do some benchmarking and come to the conclusion that idxq/lupq should be added ;-)
<beneroth>
not sure yet :)
<abu[7]>
yes, would be good to know
<beneroth>
idx and lup source looks indeed a bit heavy (compared to most in pil) :D
<abu[7]>
yes, mainly idx
<beneroth>
might be a good excercise if I would try my hands on idxq/lupq to better understand pil llvm source
<beneroth>
I keep you updated.. for now, no time/capacity to properly benchmark it, maybe in 2 weeks or so...
<abu[7]>
no hurry
<beneroth>
ah btw. regarding the "Special Build Modes" thread.. you sure that removal of 'native in the .so makes always sense? Maybe it would allow to use callbacks from the picolisp vm back into the main process?
<beneroth>
and then signal handling is removed, does that mean that 'abort' is also removed in the .so picolisp build?
<beneroth>
well 'abort' and 'alarm'
<beneroth>
no need to discuss now if you don't have time :)
<abu[7]>
I removed things for demo. Adding back later is easy, just remove the name from src/lib/so.l
<beneroth>
ok, understood
<abu[7]>
alarm is still there
<abu[7]>
the periodic sig check is removed
<beneroth>
got it
<abu[7]>
(kill SIGTERM) also is kept
<beneroth>
no handling of SigHUP or such in picolisp..
<beneroth>
ok
<beneroth>
(kill Pid 0) would also work in the shared mode?
<beneroth>
(checking if another process is alive)
<abu[7]>
I removed signal handling because typically the host C program does its own
<beneroth>
yeah, makes absolutely sense
<abu[7]>
so all kill's work
<beneroth>
the host programm can always call picolisp code where needed
<abu[7]>
yep
<taleon>
Matrix seems to be down according to the news sites. So you wisely switched from Matrix to SimpleX.
<abu[7]>
Indccd :)
<abu[7]>
At least matrix.org - I have my own matrix server
<taleon>
Yes, me too, but many users can no longer log in if they are registered via matrix.org. At least, that's how I understood it.
<abu[7]>
right
<taleon>
The next hurdle will be the mandatory update of Synapse, which not all distributions provide. Then, many users will once again be unable to join if they are using an older version of Synapse on their own server.
<taleon>
Matrix is very strange with all the JSON/Python/whatever. The protocol seems to be good, but the implementation has many flaws and, above all, all clients feel very sluggish.
<abu[7]>
And there are too many concepts I do not understand
<taleon>
The situation is expected to become significantly worse with Matrix 2.0.
<beneroth>
taleon, yeah the matrix.org database died with a RAID failure
<taleon>
When I read terms such as blockchain payments, AI marketplaces, etc. in Matrix 2.0, it's clear where the journey is headed.
* beneroth
thinks matrix is a dead end.. good intentions, medium-bad execution, and now factually being taken over by the elements company
<taleon>
T
<beneroth>
taleon, yeah sounds like the road ahead is scamming and fraud ¯\_(ツ)_/¯
<taleon>
Not worth reading, though. The headlines are enough to quickly delete it again. ;-)
<beneroth>
lol 'green paper'
<abu[7]>
updated 2 years ago
<beneroth>
taleon, just had an eye on the index.. that is all cringe bullshit
<beneroth>
abu[7], RIP
<taleon>
Aye
<abu[7]>
Perhaps "Energy Friendliness" is a good thing
<taleon>
:-)
<abu[7]>
but NeuraMATRIX
<abu[7]>
MATRIX AI Network
<abu[7]>
huh
<beneroth>
the goal should be: a good, simple (!), meaningful standard. multiple implementation. federatability - meaning small local and big servers can be used and hosted distributed and independently, and work together or not according to server and client preferences
<abu[7]>
beneroth, you have not tried SimpleX yet :)
<beneroth>
abu[7], yeah, but blockchain and "energy friendliness" doesn't fit into the same box. Assuming that "energy friendliness" means "green IT" and saving energy and not "corporate energy industry friendliness"
<beneroth>
abu[7], I have last Friday, it didn't work :P
<beneroth>
not sure whos fault it is
<abu[7]>
F-Droid
<beneroth>
but yeah, haven't set it up properly yet, T ;-)
<beneroth>
abu[7], probably
<abu[7]>
Perhaps first fix F-Droid. Is needed anyway
<abu[7]>
re-install?
<beneroth>
aye
<beneroth>
yeah I should try that
<taleon>
SimpleX has its own F-Droid repository that can be used.