ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Picolisp latest found at http://www.software-lab.de/down.html | check also http://www.picolisp.com for more information
michelp has joined #picolisp
tankfeeder has quit [Ping timeout: 258 seconds]
tankfeeder has joined #picolisp
orivej_ has quit [Ping timeout: 255 seconds]
circ-user-LLSO9 has joined #picolisp
circ-user-LLSO9 has quit [Remote host closed the connection]
<m_mans> Hi all
<m_mans> Regenaxer: good morning! Maybe you have 5 minutes, I need help with pilog question :)
<Regenaxer> Hi m_mans, good morning
<Regenaxer> ok
<m_mans> (class +Person +Entity)
<m_mans> (rel roles2 (+List +Ref +Any))
<m_mans> (show '{13074})
<m_mans> {13074} (+Person)
<m_mans> roles2 (("modOther" . "exec") ("modOther" . "ini") ("mod3" . "exec"))
<m_mans> (? @R '(("mod3" . "exec")) (select (@Pers) ((roles2 +Person @R))))
<m_mans> @R=(("mod3" . "exec")) @Pers={13074}
<m_mans> @R=(("mod3" . "exec")) @Pers={13056}
<m_mans> -> NIL
<Regenaxer> Double entries are not good
<Regenaxer> "modOther"
<Regenaxer> (dbCheck) might complain about "dangling" after deleting one value
<m_mans> first item is module name, the second is role name
<Regenaxer> Sorry, my mistake
<Regenaxer> values are not duplicate
<m_mans> the idea was to hold that pairs indexed
<Regenaxer> Yes,good
<m_mans> yeah, cons pairs itself are unique
<Regenaxer> So no problem
<Regenaxer> ok
<m_mans> not yet
<Regenaxer> yes, the question ...
<m_mans> but I want to add 'same' predicate to select
<m_mans> then, I get nothing
<Regenaxer> Why not (? @R '("mod3" . "exec") ... ?
<m_mans> I suppose I need same because there will be other generators later
<Regenaxer> yes, but cons pairs in such queries mean (from . to)
<m_mans> : (? @R '(("mod3" . "exec")) (select (@Pers) ((roles2 +Person @R)) (same @R @Pers roles2)))
<m_mans> -> NIL
<Regenaxer> I think cons pairs are problematic here because of that
<m_mans> : (scan (tree 'roles2 '+Person))
<m_mans> (("mod3" . "exec") . {13056}) {13056}
<m_mans> (("modOther" . "exec") . {13074}) {13074}
<m_mans> (("mod3" . "exec") . {13074}) {13074}
<m_mans> (("modOther" . "ini") . {13074}) {13074}
<m_mans> -> NIL
<Regenaxer> is it (("mod3" . "exec") . NIL) ?
<Regenaxer> ie ("mod3" . "exec") is "from", then search backwards to NIL?
<m_mans> no, I want exact match
<m_mans> not "from - to"
<Regenaxer> yes, but I think the generator gets confused
<Regenaxer> a cons pair means (from . till)
<m_mans> @R '(("mod3" . "exec"))
<m_mans> its a nested list
<m_mans> not OK?
<Regenaxer> Yes, so it means (("mod3" . "exec") . NIL) ?
<Regenaxer> backwards
<m_mans> ah, maybe
<Regenaxer> still, your problem is the filter, right?
<Regenaxer> Same problem perhaps
<m_mans> can I get exact match for a such index then?
<m_mans> I mean with select
<Regenaxer> As I said, queries don't work well with pair values
<Regenaxer> 'same' sees a list, and tries to match the elements
<m_mans> ah
<Regenaxer> I would avoid such models
<Regenaxer> +List +Any
<Regenaxer> Pilog does not know the internal structure
<m_mans> I also tried (rel roles (+List +Bag) # Роль((+Ref +String))((+Ref +String)) )
<Regenaxer> so it cannot handle it
<m_mans> but I see that such way I can index only individual strings
<Regenaxer> yes
<Regenaxer> Pilog wants atomic data :)
<Regenaxer> you need to filter with a Lisp expression then
<m_mans> or should I store something as "mod1_role1" strings...
<Regenaxer> (^ @ ...)
<Regenaxer> "mod1_role1" not so nice, right?
<m_mans> you asked if my problem is with filter only. Maybe also generator part is wrong with (("mod3" . "exec") . NIL), it's not clear for me
<Regenaxer> exactly
<Regenaxer> it means some range
<Regenaxer> So not clear what is meant
<Regenaxer> Can't you operate in Lisp here
<m_mans> so, in general I can store indexed lists but should use "collect", "iter" etc, right?
<Regenaxer> yes, this is always possible, just more work
<Regenaxer> (init ..) (step ..)
<Regenaxer> or just (for This (collect ... if not too many data
<m_mans> I can't use +QueryChart then, can I?
<Regenaxer> You can, using db/3
<Regenaxer> hmm, not sure atm
<Regenaxer> db/3 also applies ranges perhaps
<Regenaxer> Can't you modify the model?
<Regenaxer> The +Any pair also does not work in the GUI
<m_mans> I would be happy to change the model. I just don't know, which model will be nice for that
<Regenaxer> I think I would go with +Bag, generate for one atom, and filter for the other atom
<m_mans> ok,thank you for the help!
<Regenaxer> Sorry, was not really satisfying ;)
<m_mans> I'll try
<Regenaxer> ok :)
<m_mans> +Bag work more or less with GUI?
<m_mans> works
<Regenaxer> yes, +List +Bag maps to +Chart 1:1
<m_mans> or GUI with +Bag, to be correct
<Regenaxer> T
<m_mans> : (? @R "mod3" @R2 '("mod3" "ini") (select (@Pers) ((roles +Person @R)) (same @R2 @Pers roles)))
<m_mans> @R="mod3" @R2=("mod3" "ini") @Pers={13056}
<m_mans> seems OK
<Regenaxer> good
<Regenaxer> I think (? @R "mod3" @R2 "ini" ... would also work
<Regenaxer> With (? @R "mod3" @R2 "ini" ... (same @R2 @Pers roles))
<m_mans> let me check
<Regenaxer> Or (? @R "mod3" @R2 "ini" ... (same (@R1 @R2) @Pers roles)) but not necessary
<Regenaxer> (? @R "mod3" @R2 "ini" ... (same (@R @R2) @Pers roles)) I mean
<Regenaxer> but 'same' checks for membership, so (same @R2 @Pers roles) should work
<m_mans> : (? @R "mod3" @R2 "ini" (select (@Pers) ((roles +Person @R)) (same @R2 @Pers roles)))
<m_mans> -> NIL
<m_mans> : (? @R "mod3" @R2 "ini" (select (@Pers) ((roles +Person @R)) (same (@R @R2) @Pers roles)))
<m_mans> @R="mod3" @R2="ini" @Pers={13056}
<m_mans> -> NIL
<Regenaxer> hmm
<Regenaxer> which filter?
<m_mans> last filter works
<m_mans> (@R R2)
<m_mans> (same (@R @R2) ...
<Regenaxer> Note my mistype in (same (@R1 @R2)
<Regenaxer> @R1
<m_mans> : (show '{13056})
<m_mans> {13056} (+Person)
<m_mans> roles (("mod3" "ini"))
<m_mans> roles is +List +Bag
<Regenaxer> did you copy/paste my line?
<m_mans> not
<m_mans> no
<Regenaxer> ok
<Regenaxer> So (? @R "mod3" @R2 "ini" ... (same @R2 @Pers roles)) does not work? Strange
<Regenaxer> anyway, (same (@R @R2) is better
<m_mans> I suppose we must check whole +Bag?
<Regenaxer> I think not, it checks for membership
<Regenaxer> as data are expected atomic
<Regenaxer> So in general a pair in a filter clause means (from . till), just 'same' is perhaps different, as a range makes no sense
<Regenaxer> This is a bordeline situation ;)
<m_mans> ah, I've forgotten that in general the same 'range lists' go to filters too
<m_mans> not only to generators
<Regenaxer> T
<Regenaxer> Still it works here, as 'same' first tries the whole pair, then recurses into the lists
<m_mans> ok, I'll check it later
<m_mans> thanks again, Regenaxer! :)
<Regenaxer> np :)
orivej has joined #picolisp
<beneroth> interesting read :)
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #picolisp
<m_mans> Hi beneroth
alexshendi has joined #picolisp
<beneroth> hi m_mans :)
<m_mans> beneroth: have you used lists in indexes?
<beneroth> not really. you aware of the differences between (+List +Ref +Link), that I use a lot, vs. (+Ref +List +Link) ?
<m_mans> yeah
<beneroth> good! so I understand you are asking about (+Ref +List ...) or (+Key +List ..), aye?
<m_mans> and it seems that (+List +Ref +Bag ...) doesn't work
<Regenaxer> Hmm, you want to index the whole bag?
<beneroth> I have (+List +Bag) ((+Ref +Link)) ((+Ref +Link))) in use?
<Regenaxer> Usually I index the elements of the individual bag
<m_mans> no, I just talk how I started
<beneroth> yeah, it is probably more meaningful to index the stuff within the bag, not the whole bag
<beneroth> ok
<Regenaxer> beneroth, same here
<beneroth> details matter a lot with this powerful class prefixing ^^
<Regenaxer> If the whole bag is indexed, we run in the pair-ambuigities again
<Regenaxer> Grr, wifi here in the train is awfully slow, can't type well
<beneroth> Deutsche Bahn? hehe
<Regenaxer> yeah, horror
<beneroth> well at least you have wifi. but its slow and makes you even more insecure (leaks your browsing history to websites you visit)
<m_mans> you *have* wifi in the train! We don't here in our trains :))
<Regenaxer> I'm logged into the server at my basement via ssh
<beneroth> we neither, but our GSM network is good enough to use it in train. in germany it is not usable really in train.. or maybe this is only true for the fast-moving long-travelling trains
<beneroth> at least that was my experience :)
<m_mans> well, I need to return to work
<Regenaxer> I don't have a GSM card in this tablet
<Regenaxer> Good luck m_mans!
<m_mans> same to you!
<m_mans> "away from that app ;)"
<beneroth> good luck m_mans :)
<Regenaxer> :)
<beneroth> Regenaxer, you could tether with the smartphone. I travelled a lot in Germany by train some 3-4 years ago, from Basel up to Köln and further... GSM was not usable. wifi on train was slow but usable.
<Regenaxer> Haha, I also have no smartphone :D
<Regenaxer> I used an USB stick a few years ago with a notebook
<Regenaxer> also not satisfying
<Regenaxer> Main problem here is typing into a remote console (irc)
<beneroth> I thought you had once, haha. You purist. Good habit.
<Regenaxer> this is annoying, as it hangs several seconds often
<beneroth> T
<Regenaxer> I used my wife's if necessary
<Regenaxer> nach Alkmaar
<beneroth> you're leaking ^^
<Regenaxer> yep, sorry
alexshendi has quit [Quit: Leaving]
orivej has quit [Ping timeout: 240 seconds]
<cess11> Lists of cons pairs are nice but it might be a better idea to invent a class if they need close indexing.
<cess11> Sometimes I use such cons pair lists to hold more or less temporary data, like search results or value-value pairs (e.g. '(word count . word)).
<cess11> If I understood it correctly the use case is configuration of user roles or something like that, which usually doesn't require high performance in retrieval or transactions so a little overhead might be acceptable.
orivej has joined #picolisp
<beneroth> my role mechanic looks like this:
<beneroth> (rel bag (+List +Bag)
<beneroth> ((+Ref +Link) NIL (+Role)) # a role
<beneroth> ((+Ref +Link) NIL (+control)) ) # a control per role
<beneroth> the indexes are rarely ever used. usual retrieval (which should be fast) fetches this object and than iterates over the list. so in this use case it is good that this list is directly within one object and not more distributed.
<beneroth> for more querying power, the more different indices the better, right (increases the cost of writes though).
<beneroth> optimal model heavily depends on the use case.
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
orivej has quit [Remote host closed the connection]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
anjaa has joined #picolisp
alexshendi has joined #picolisp
_whitelogger_ has joined #picolisp
_whitelogger has quit [Remote host closed the connection]
raydeejay has joined #picolisp
orivej has quit [Ping timeout: 268 seconds]
miskatonic has joined #picolisp
orivej has joined #picolisp
miskatonic has quit [Remote host closed the connection]