<beneroth>
I hate the current fashion for flat keyboards
<beneroth>
I need some haptic grip
<Nistur>
My favourite keyboard to use is my Model M, but I don't have one with USB, and few PCs have PS/2 these days, so I'm using a Cherry G80-3000 with MX Blue, which was the closest I could get to my Model M
mmamkin has joined #picolisp
<Regenaxer>
<Regenaxer>
Hi beneroth
<beneroth>
Nistur, PS/2 to USB adapters are a thing :)
<beneroth>
or were xD
<Nistur>
I know
<beneroth>
Hi Regenaxer :)
<Nistur>
I've tried a few, but they didn't work with my Model M for some reason
<beneroth>
Nistur, I miss the old corded keyboard from logitech (from 10+ years ago, apparently they don't produce it anymore). I recently got some new lenovo keyboards, I love them.
<beneroth>
oh, didn't know that PS/2 is so involved. :(
<beneroth>
Regenaxer, best way to deal with a big list of boolean flags? idx, right?
<beneroth>
I would even consider a bittable (as number), but I guess they aren't that much faster than idx (when >64bit), and this flag-list needs changes from time to time
<beneroth>
use case: an involved permission system
<Regenaxer>
Yes, idx should be good
<Regenaxer>
ah
<Regenaxer>
There is a table with 'mark'
<Regenaxer>
could be abused ;)
<beneroth>
yeah, but than mark cannot be used otherwise anymore, right?
<beneroth>
ah per process
<Regenaxer>
yes, but it is used implicitly only in dbgc
<beneroth>
I see
<beneroth>
good idea, but not the right thing for my use case, I believe
<Regenaxer>
and the keys are external symbols, so not so good
<beneroth>
yeah mark is kinda a flag on the external symbol metadata/proxy
<Regenaxer>
yes
<Regenaxer>
but uses a linear bit table internally
<Regenaxer>
(iirc)
<beneroth>
the other way would be to have no memory structure, just using normal db indexing, as obviously I like to store the permissions in the db somehow
<Regenaxer>
the booleans are permissions?
<beneroth>
aye
<Regenaxer>
ok
<Regenaxer>
So you want to store the big idx in the db?
<beneroth>
I want to build a "capability" system, not mere user/group permission lists
<beneroth>
no
<Regenaxer>
ok
<beneroth>
idx is to be generated from stored objects on load
<Regenaxer>
good
<beneroth>
I work still with a forking server, so it is not so optimal, but I want to switch to a non-forking server eventually
<Regenaxer>
How about the volatile property?
<beneroth>
NIL ?
<beneroth>
or another one
<Regenaxer>
yep
<beneroth>
hm
<Regenaxer>
NIL
<beneroth>
the thing is, my permissions are not limited to DB stuff.
<Regenaxer>
store the flags directly
<Regenaxer>
ah, ok
<beneroth>
we first wanted to make it that way, but I had the insight that this is too restricted
<Regenaxer>
yeah
<beneroth>
DB permissions is of course the main part, but functionality has also to be guarded by permissions
<Regenaxer>
so idx is the most direct way
<beneroth>
yeah
<Regenaxer>
as ever just take care of non-sequential inserts
<beneroth>
so when the user session is constructed (loading user data from the database, blabla), then this idx gets constructed to
<beneroth>
aye
<beneroth>
permissions, well "capability" will be an object. one object represents one or multiple (!) permissions
<Regenaxer>
I see
<beneroth>
I guess the idx should be on the finest granularity to make checking stupid/easy, so a tree of all single permissions of the current session
<Regenaxer>
yes, just space
<Regenaxer>
so a bit table with 'native' would be smaller
<beneroth>
aye, maybe some optimizations could be made later
<beneroth>
right
<Regenaxer>
if the indexes are numeric
<Regenaxer>
and not too sparse
<beneroth>
aye
<Regenaxer>
yes, no prelim optim :)
<beneroth>
the problem with bittable is changes, requiring a complete recalc
<beneroth>
well maybe not a complete recalc, but an involved one
<beneroth>
on the other side, most actions will be reads, not changes
<beneroth>
hm
<Regenaxer>
The ultimate simple is 'memq'
<Regenaxer>
push1
<Regenaxer>
push1q
<Regenaxer>
if not too many
<beneroth>
so idx for the start, simple & stupid, maybe optimize it later into an pil64 library (like ht), maybe add some intelligence to group multiple single permissions together instead of having to outline them in detail
<Regenaxer>
yes
<beneroth>
yeah I expect the permissions to explode into many
<Regenaxer>
ok
<beneroth>
meta-permissions like crud on a single entity
<Regenaxer>
It can't be stored in the class defs?
<beneroth>
down to "you only have write permission on this single property of this entity, and read permissions on this 5 other properties"
<beneroth>
hmm
<Regenaxer>
ok, not in class then
<beneroth>
well the storage/configuration of the permissions will be an entity
<beneroth>
but separated from what they are about
<beneroth>
the main point of a "capability" system (in opposition to group/role based ones) is that an user can forward his own permissions, or also only parts of it, to others
<Regenaxer>
In the end you have '&' on bit vectors?
<beneroth>
ideally the implementation of a capability system is that you actually only get the resources to do actions you are allowed to
<Regenaxer>
understand
<Regenaxer>
hmm
<Regenaxer>
then just a bignum
<beneroth>
but that doesn't fit picolisp app style, I think. I don't want to produce proxy-objects
<beneroth>
yes, basically
<Regenaxer>
as bit vector ;)
<beneroth>
aye
<beneroth>
bittable, that I meant with that :)
<Regenaxer>
yeah
<beneroth>
so you think a bignum is much better than an idx? should be..
<Regenaxer>
So it seems just using plain (big)nums will do
<Regenaxer>
Depends how the indexes are calculated
<beneroth>
how much do bignums get slower when they are made of many blocks?
<Regenaxer>
What kind of blocks?
<Regenaxer>
DB?
<beneroth>
cells
<beneroth>
no memory
<beneroth>
yeah I sound pretty premature here
<beneroth>
ok
<Regenaxer>
I think speed is good
<beneroth>
sounds to me like 1) storing configuration in its own entities/objects (as normal). these are edited by administrators etc. to change permissions 2) generate a bignum from it, can be stored in DB (as a cache)
<beneroth>
or replace 2) with an idx, which is not stored/cached in the db
<Regenaxer>
T
<beneroth>
the idx might be shorter for many users
<Regenaxer>
T, uses only the *set* cases
<beneroth>
as I understand bittables, the bignum would need to be the same size for all users, so the size/bits = maximal number of permissions currently possible in the system
<beneroth>
while an idx for one users could be much smaller, only containing the few permissions this user has
<Regenaxer>
if common flags are low bits, the sizes may be smaller
<beneroth>
T
<beneroth>
but a bit hard to determine this, globally, when permissions are added/removed, grouped into more common ones or sliced into finer granularity
<beneroth>
therefore I thought I would go with idx first
<Regenaxer>
yes, it is most general
<beneroth>
simple and general, KISS
<Regenaxer>
:)
<beneroth>
it's a bit bad that with a forking architecture, this idx would be re-constructed on every request. but once I would keep them in memory over multiple requests, they probably would not be such a big difference in practice
<beneroth>
or lets store the idx
<beneroth>
how to store an idx best? as a +List ?
<beneroth>
maybe (balance) after re-creating the idx from the +List ?
<Regenaxer>
Just +Any
<Regenaxer>
How about keeping the idx in the parent?
<beneroth>
how to update then?
<beneroth>
without restart
<Regenaxer>
by sending messages with 'boss'
<beneroth>
hm right
<beneroth>
pre-calculated stored idx would be nicer
<beneroth>
more flexible even with higher numbers of users
<Regenaxer>
T
<beneroth>
of course, that would be HIGH numbers
<beneroth>
current use case is your sizes, a few hundred users at max
<beneroth>
but I would like to have it flexible enough to grow into thousands
<beneroth>
not as premature optimization, but for re-usability
<Regenaxer>
yes, better
<beneroth>
so I use (idx 'Var) to export the tree into a list, which I store as +Any. and when loaded from DB, I loop over the list, insert into idx, and (balance) it before querying ?
<beneroth>
ah now
<beneroth>
I can put the list into (balance) to build idx without having to iterate
<Regenaxer>
You can store the idx directly
<Regenaxer>
ah
<Regenaxer>
ok, yes, balance
<Regenaxer>
If the keys are not absolutely sequential, it is not needed I think
<beneroth>
how can I store it directly, without fetching the list using (idx). just (put> 'Obj 'prop Var) ?
<beneroth>
the list returned from (idx) is sorted
<Regenaxer>
not put>
<Regenaxer>
(idx (prop ...) ... (touch Obj)
<beneroth>
ah
<beneroth>
I see
<beneroth>
nice
<beneroth>
will try out
<beneroth>
brilliant, so I can store for every user a kind of "session template" to construct the session from
<beneroth>
thanks Regenaxer <3
<Regenaxer>
Always fun :)
<beneroth>
creativity & fun leads to the best designs :)