<aw->
ok thanks for the info, i can work from this :)
<Regenaxer>
:)
<m_mans>
question about index search
<m_mans>
if I have (class +Class1 +Entity) and (class +Class2 +Class1)
<Regenaxer>
ok
<m_mans>
and index (rel nr (+Need +Key +Number)) - defined only in class +Class1
* beneroth
uses often such class hierarchies
<m_mans>
which search functions can filter by class if I want to search only +Class2 objects?
<beneroth>
collect and db
<Regenaxer>
T
<beneroth>
iter and pilog require you to specify +Class1 (on which the index is)
<beneroth>
collect and db can deduce the correct index from the class hierarchy and filter the output
<Regenaxer>
yes, but I think pilog should do too
<m_mans>
what if I want to filter the class in pilog?
<beneroth>
I think you need an (isa) filter, no?
<beneroth>
isa/2
<Regenaxer>
T
<beneroth>
and the generator has to be for +Class1 not +Class2
<beneroth>
(generator in select clause)
<m_mans>
thank you very much!
<Regenaxer>
It seems that db/3 should do too
<beneroth>
count also works for both.. (count (tree 'nr '+Class2)) vs (count (tree 'nr '+Class1))
<Regenaxer>
Perhaps not select
<beneroth>
select doesn't in my experience, but I might have done mistakes. I don't think so.
<Regenaxer>
correct
<beneroth>
db/3 I haven't used much yet, so you are probably right, not tested :)
<Regenaxer>
But 'count' is not looking up the hierarchy
<Regenaxer>
db should do, it uses 'meta'
<beneroth>
no, there is a entity count variable (ECnt) :D
<Regenaxer>
db is the equivalent of 'collect'
<Regenaxer>
yes
<Regenaxer>
ECnt is ok
<beneroth>
(since our fix :P)
<Regenaxer>
but not the 'count' function
<Regenaxer>
'count' is tree-level, does not know about classes
<Regenaxer>
ECnt was also handling this before our fix, just not for graph inheritances ;)
<beneroth>
T
<Regenaxer>
non-unique inheritance?
<beneroth>
multiple inheritance from +Entity was the issue
<Regenaxer>
that was ok too
<beneroth>
m_mans example would work as it is the usual structure
<Regenaxer>
just not if the *same* class was inherited multiple times
<Regenaxer>
yes
<beneroth>
T
<beneroth>
it did not check all branches of the inheritance tree under some special circumstances :)
<Regenaxer>
right
<Regenaxer>
now it is perfect :)
<beneroth>
it is!
<Regenaxer>
(I hope)
<Regenaxer>
:)
<beneroth>
I'm pretty sure it is
<Regenaxer>
cool
<beneroth>
at least I can't think of a more involved graph structure inheritance than what I had... would just be more of the same.
<beneroth>
^^
<Regenaxer>
OK :)
* beneroth
remembers aw- about "don't run email servers"...
<beneroth>
he is right, I tell you :)
<Regenaxer>
What happened?
<beneroth>
just fought off some major spam attacks
<Regenaxer>
uh
<beneroth>
hacked smtp accounts of clients used for spamming
<beneroth>
website contact forms with bad/non-existing checks used for spamming
<beneroth>
Joomla user self-registering which causes joomla to send out an "your new account is created blabla" email used for spamming
<beneroth>
it's fun :)
<Regenaxer>
hmm
<beneroth>
ah, hehe. T
<Regenaxer>
I'm not convinced
<beneroth>
you're not convinced about?
<Regenaxer>
That it is fun
<aw->
beneroth: indeed, why run your own email server? it's madness
<aw->
unless it's private/internal email server..
rudha has joined #picolisp
<beneroth>
aw-, I run it for webhosting clients (LAMP) ;-)
<beneroth>
took over an existing setup from another company to get some customers & get experience with this stuff as I want develop software in this space
<beneroth>
was more effort and mor experience learned than initially estimated, haha :)
<beneroth>
also, most email (80%) going over gmail is maybe not such an ideal situation for freedom and stability (decentralised infrastructure is overall more stable, or so the theory is)
<rudha>
hello all
<beneroth>
hello rudha !
<aw->
i agree, but you don't need to use gmail ether
<rudha>
:)
<aw->
either*
mtsd has joined #picolisp
<m_mans>
Regenaxer: you said: just not if the *same* class was inherited multiple times
<m_mans>
could you (or beneroth) explain?
<m_mans>
sorry, was busy
<beneroth>
m_mans, it is not relevant anymore. for every entity and for every index, there is a count variable, which holds a total of the objects.
<beneroth>
this is how (count) works - it just fetches that value (not iterating over records)
<beneroth>
when having more complicated class inheritances, especially multiple indirect inheritances from the same entity class, this count value got not correctly updated
<beneroth>
I stumpled upon this bug as I have such inheritance "graphs" (vs. simpler lines/trees) in use
<beneroth>
its fixed for quite a while
<beneroth>
so should be of no concern for you. and the example you gave would not be subject of this bug :)
<beneroth>
was fixed in 27jul17
<beneroth>
if you are interested in the inner workings, you can look at (incECnt), (decECnt), (badECnt) and (fixECnt) in @lib/db.l and @lib/too.l
<beneroth>
you can also look at the source of (count) in @lib/btree.l
<m_mans>
ok. Btw, seems my question was wrong. I need to find only +Class1 objects (parent class). It seems that 'collect returns +Class2 too
<beneroth>
ah
<beneroth>
yes, your question was understood as "find only class2"
<beneroth>
Class2 are also class1, so the match
<m_mans>
but the discussion was interesting
<beneroth>
so do you want A) all +Class1 which are not +Class2 ? or B) all objects which directly inherit from +Class1 (also excluding any future +Class3 and +Class4 etc who also inherit from +Class1) ?
<beneroth>
pilog or lisp or both?
<beneroth>
(filter '((E)) (not (isa '+Class2 E))) (collect 'nr '+Class1)) or (make (iter (tree 'nr '+Class1) '((E) (unless (isa '+Class2 E) (link E)))) would work for A)
<beneroth>
to achieve B), meaning only ever getting objects which directly inherit from +Class1, I would look at the parent list (in the value of the symbol).. so:
<beneroth>
the 'iter variants would be nicer/faster, as less allocation happens. the filter variant is easier and probably ok if the index is not big
<beneroth>
haven't tested this code :)
<beneroth>
does this answer your question, m_mans ?
<beneroth>
for pilog you would also use (not) and (isa), or implement a predicate to do the (car (type)) check on lisp level
<beneroth>
e.g. something like (be direct_child (@Object @Class) (^ @ (= (car (type (-> @Object))) (-> @Class)))) I guess (not tested)
<beneroth>
or a hardcoded variant could probably also be used: (be isa_class1 (@Object) (^ @ (= (car (type (-> @Object))) '+Class1)))
<beneroth>
I hope this is about right, I haven't really implemented any lisp code predicates
<Regenaxer>
ret
<beneroth>
welcome back. please check my answers :)
<Regenaxer>
Yes, looks good
<Regenaxer>
'collect' filter for the requested class and inherits the right tree
<Regenaxer>
But the above is different it seems
<Regenaxer>
(filter '((E)) (not (isa '+Class2 E))) (collect 'nr '+Class1)) I mean
<Regenaxer>
(collect 'nr '+Class2) would return only +Class2 objects
<beneroth>
yeah, but he wants only +Class1 objects which aren't +Class2
<Regenaxer>
Ah, perhaps instead of (car (type)) I would check for (last (type ...
<Regenaxer>
The last is usually the main class
<beneroth>
T
<beneroth>
ah maybe I would use my variant plus (not (cdr (type E))
<beneroth>
depends on what he wants to restrict
<Regenaxer>
T
<Regenaxer>
So 'isa' is best
<Regenaxer>
it checks all
<beneroth>
yeah, but does not exclude
alexshendi has quit [Read error: Connection reset by peer]
<Regenaxer>
Well, with (not (isa ...)) ?
<beneroth>
T
<beneroth>
maybe the modelling should be different, so no exclusion is necessary
<Regenaxer>
yep
<beneroth>
e.g. instead of using +Class1 for objects, use it only as abstract class and have separate child branches, e.g. +ClassA and +Class2 both inheriting from +class1
<beneroth>
that was my approach in the past
<Regenaxer>
yes, this is good
<beneroth>
the problem with exclusion is that you have to make implicit assumption about future changes to the ER model :)
<Regenaxer>
I've never excluded classes in this way
<beneroth>
assumptions about the future are limitations in flexibility for the future... and/or likely future bugs :)
<beneroth>
well.. as in security.. whitelisting is the simpler and better approach instead of blacklisting
<beneroth>
enumerating all bad/excluded things in a future-prove way isn't exactly possible
<beneroth>
better enumerate all positive/allowed things
<beneroth>
the difference is the default behaviour for uncatched cases
<beneroth>
s/uncatched/unhandled
mtsd has quit [Remote host closed the connection]
aw- has quit [Ping timeout: 246 seconds]
aw- has joined #picolisp
<m_mans>
sorry, was afk. Reading answers
<m_mans>
thanks again for the answers! I'll try it later
<Regenaxer>
No hurry! :)
rudha has quit [Read error: Connection reset by peer]
rudha has joined #picolisp
aw- has quit [Quit: Leaving.]
orivej has quit [Ping timeout: 240 seconds]
alexshendi has joined #picolisp
orivej has joined #picolisp
freeemint_ has joined #picolisp
<freeemint_>
Hi
<beneroth>
hi freeemint_
alexshendi_ has joined #picolisp
<freeemint_>
hi bene
<freeemint_>
how are you?
<beneroth>
tired
<beneroth>
generally I'm well
<beneroth>
how are you freeemint_ ?
<freeemint_>
very tired
<beneroth>
hard day?
<freeemint_>
no hard university life
<beneroth>
what is the hard part?
<freeemint_>
the home work
<freeemint_>
and the self imposed social pressure
<freeemint_>
the imposter syndrom
<freeemint_>
oh and sleep deprivation
<beneroth>
I see
<beneroth>
it usually helps me to do written ToDo-Lists, so I don't have to think the whole time what I need to do soonish and can focus on what I choose to do right in that moment
<freeemint_>
That is a very good idea
<freeemint_>
How would you go about ToDo-lists? Paper or software? if so which?
<beneroth>
paper is good enough as long as the list is not to big. start with paper.
<freeemint_>
ok
<beneroth>
I have a todo-tool written in picolisp.. little web application having +Todo with subject and optional text, and a list of +Tag, single keywords I use to tag the todos. and the list of todos I can filter by tag.
<beneroth>
so I have tags like "work" "private" "NOW"
<beneroth>
so I can switch contexts
<freeemint_>
Do you handle dependencies between places or tasks?
<freeemint_>
or are todo lists good enough
<beneroth>
just with tags
<freeemint_>
ok
<beneroth>
I mean I handle those things just with tags
<freeemint_>
is there some protocol like caldav which allows to sync TODO lists?
<beneroth>
afaik not
<beneroth>
but I haven't searched for it
<beneroth>
could probably also be implemented on top of webdav
<freeemint_>
i would like to have clients on all devices i use without having to write one
<beneroth>
that's why I like web-apps
<beneroth>
how many different devices do you use then?
rudha has quit [Remote host closed the connection]
rudha has joined #picolisp
<freeemint_>
1 android device 2 linux laptops
<freeemint_>
beneroth: I got a question. Did you recommend the ToDo list because of the symptoms i listed today or did you recommend them because of the bigger picture you build of me
<beneroth>
symptoms & my own experience
<beneroth>
what you do with this you have to figure out yourself ;)
<freeemint_>
Let me ask from another angle. Was the advice motivated only by my symptoms listed today or by a general picture of me you developed over time?
<beneroth>
symptoms
rudha has quit [Quit: Leaving]
orivej has quit [Ping timeout: 248 seconds]
<freeemint_>
beneroth: that i powerful word in that context
<beneroth>
how so?
<beneroth>
don't overthink
rudha has joined #picolisp
<freeemint_>
because it suggested that the tool (ToDo list) is a tool of which you think that it helps with the problems i listed.
<beneroth>
T
<freeemint_>
You suggest it will work not because of your image of me (which is flawed ;D ) but because of the abstracted list of symptoms i came up with
<freeemint_>
So if it does not work it only did not help because i were not sufficently aware of the symptoms myself
<freeemint_>
(or i did implement it badly)
<beneroth>
or my advice was nonsense or other unknown factors are at play
<beneroth>
don't look for blame and guilt unless there are insights to gain. move on when you got that insights.
<beneroth>
or move on when you can't find them. might be because there aren't any.
<freeemint_>
T
<beneroth>
happier -> more productive -> more able to leverage opportunities to fulfil your dreams -> happier -> recur
<freeemint_>
wrong use of recur but fine otherwise
<beneroth>
T :)
<freeemint_>
also it does not include handling of error cases
<freeemint_>
how far you should adujst your dreams in face of repeated failure
<beneroth>
well maybe don't adjust your dreams, but look out that you don't get stuck in a dead end (sackgasse), regularly check if your current strategy truly brings you forward, and consider attempting other approaches.
<beneroth>
if you are not in the position to execute a strategy, try to back-track a route (path-finding) to get around the obstacles and/or to generate the necessary environment/opportunities
<beneroth>
also, your goals may change over time independently of the presence or absence of failures and problems, just because you gained experiences and because you are alife, life is about change.
<freeemint_>
adjusting dreams is kinda a last resort and it has to happen sometimes, but T
<freeemint_>
I am kinda thinking that a CalDAV server with "magic lisp ai" would be a worthwhile project
<beneroth>
nice idea
<freeemint_>
but it has lot of logical balast, some standards involved
<freeemint_>
on the other hand. If the software is good enough and is able to push it features properly even on mediocre clients i may actually be something i would pay for.
<freeemint_>
For example if you delete a task client side wise and put a "pause" in it's place the slot is not re assigned with anew task. A later point for that task is found and all tasks with dependencies on that one are moved too.
<beneroth>
well in my next overhaul of my todo tool I want to add calendar features, and maybe the whole tool will eventually evolve into a product
<beneroth>
but not soon
<freeemint_>
Tasks can be scheduled based on location and time it takes to move between locations. People can be informed and meetings rescheduled on a button press when you did not catch a train
<freeemint_>
Some what informed decision can be made whether taking a taxi is worth the invested money in the end or not.
rob_w has quit [Quit: Leaving]
<freeemint_>
kinda utopic to be honest but people would definitly pay if it would work
<freeemint_>
I am just worried that picolisp ceases to be performant enough once you do scheduling for larger groups of people
<freeemint_>
well anything would since optimal scheduling (even without location aspect) is reducible to the knapsack problem which is NP-hard
<freeemint_>
(or just NP-complete ?) not sure
<freeemint_>
*It is NP-complete
rudha has quit [Quit: Leaving]
<beneroth>
google is already doing such things
<beneroth>
I don't think you will run into performance issues with picolisp, except in case of obvious mistakes by the programmer
<beneroth>
once you need additional performance, you can adapt it to scale up. pretty easy with picolisp as it is so very flexible.
<freeemint_>
google has gqueues wich does roughy that
<freeemint_>
beneroth: Do you think it is a worthwhile task. How would you handle privacy?
<beneroth>
ask money for the hosting instead of using the user data for ad-targeting.
<freeemint_>
i got hosting settled already for the development phase and the first few hundered users. But that is not what i meant. Calendars + position profiles are incredibly sensitive data.
<freeemint_>
How to protect it from a technical standpoint in Picolisp. The database is not exactly secure
<beneroth>
how is the database not secure?
<freeemint_>
(as in it has no built in security features like encryption)
<beneroth>
there are two aspects to this topic: 1) protect from illegitim access by other users/public/etc
<beneroth>
2) protect from employees of the hoster
miskatonic has joined #picolisp
<beneroth>
1) -> do good secure programming of the application
<beneroth>
2) -> only allow the employees access which need it to. log & monitor.
<freeemint_>
i always want to assume that the attackers can execute arbitrary code in the first process facing them.
<freeemint_>
(in this case arbitrary lisp they have access too)
<beneroth>
if they can do that, it is lost anyway. encryption will not protect you then, just add another little obstacle which can get overcome
<beneroth>
it is now a trend to also apply encryption so the hoster/operator/software devs don't see the data. but that is not really a security measure, not really for the user but for the company to claim legal innocence.
<beneroth>
you have to trust the software developers, you have trust that they haven't added a backdoor. and they can add one anytime.
<freeemint_>
True
<freeemint_>
are there technical solutions to this social problem?
<beneroth>
no
<beneroth>
whoever has physical access to the machine (e.g. data center operator) can get the data. yes you can encrypt it, but for the software to do anything with the data it needs to decrypt it, so they key must be somewhere on the server. maybe only temporary after a user gave it to the server, but still, that is enough to give the software developers or someone with physical access to the server all they need.
<beneroth>
there is a kind of technical solution: only decrypt the data on the client. but this means you also have to do all logic/functionality on the client, which renders this approach useless for most use cases.
<freeemint_>
or homomorophic encryption (yeah!!)
<beneroth>
a related approach is to do the encryption in such a way that the clear text data cannot be read on the server, but the logic/functionality can work with the encrypted data.
<beneroth>
yeah homomorophic encryption
<beneroth>
but also no solution in my eyes, because you can still extract the metadata (relations between data-points and patterns of logic/behaviour), which is probably enough for whatever you want to find out. or you can deduce the real data from that.
<beneroth>
so you can do this very complicated things which will add some obstacles but not really more security, or you can keep it simple and spend more time doing the simple stuff in the most secure ways.
<beneroth>
chances are, with the overly complex approach, that there are more bugs and problems, and more security weaknesses than without
<beneroth>
and also: datensparsamkeit. the less data you store, the less security problems you can have. when you don't need to sell the data (or ad-products based on that data), then you can also afford to only store what you truly need.
<beneroth>
this way you are also a less interesting target for criminals/secret services
<freeemint_>
Just an extreme case, per user raspberry pi, encrypted sd, power supply is cut when case opened, users connect directly to his raspy. Raspies anonmize scheduling problems and send them out over some kind of mixmaster? #overly complex solution?
<beneroth>
good solution.
<freeemint_>
huh?
<freeemint_>
ok
<beneroth>
physical separation is a security feature, virtual separation isn't :)
<beneroth>
but yeah, the user still has to trust that you do this much-effort setup (and pay for it)
<beneroth>
you can't prove that you actually to this :)
<freeemint_>
let me think about that
<beneroth>
then, from user security standpoint, better sell the software + raspi as a box to plugin at the users home, with no backdoor/automatic update access for you
<freeemint_>
and provide the high calculation rescheduling as a cloud service?
<beneroth>
no, then it is again on your servers
<miskatonic>
regenaxer sell raspberries with pilos?
<beneroth>
this approach, selling the whole thing as a box to be operated on premise by the user, is also a growing niche trend (e.g. datamate.org)
<freeemint_>
no lan driver, and there are better platforms by every metric
<miskatonic>
but without lan driver, one can't irc and bother beneroth
<beneroth>
miskatonic, no. pilOS is not advanced enough for this. but there is the mizar32 http://www.4star.it