<Regenaxer>
mtsd, do you already use a contact tracing app in Sweden?
mtsd1 has joined #picolisp
mtsd1 has quit [Client Quit]
<mtsd>
No, not yet
<mtsd>
Still very mild restrictions here
<Regenaxer>
ok
<Regenaxer>
great
<mtsd>
Hard to say if it will be more restrictions or not. Depends on how the hospitals manage, I think
mtsd has quit [Quit: Leaving]
mtsd has joined #picolisp
mtsd has quit [Client Quit]
mtsd has joined #picolisp
mtsd has left #picolisp [#picolisp]
<Regenaxer>
Guido has no idea about how Lisp works
mtsd has joined #picolisp
<beneroth>
Regenaxer, just ignore him
<beneroth>
I agreee
<Regenaxer>
Sure
<Regenaxer>
I was just surprised that he doesn't even know the concept of 'cons'
<beneroth>
Edgaras Šeputis was on point
<beneroth>
"I'll just point that for some time now you are acting like some kind of weird troll, making some seemingly interesting pionts, even while displaying crappy attitude"
<mtsd>
T
<Regenaxer>
Yep
<beneroth>
Guido shows all the symptoms of a self-obsessed theorist, mixing up the theory & reality, not even understanding the theory
orivej has joined #picolisp
<beneroth>
unfortunately I still haven't implemented a picolisp IMAP client (it's on the list, for a long time already), else I would send you all a script to put into your cronjobs to clean your inboxes ;-)
<mtsd>
Didn't he write something about having to re-implement Picolisp? Go ahead, I say..
<Regenaxer>
indeed
<beneroth>
too dumb to just continue using pil64
<Regenaxer>
beneroth, well, I have not a real inbox
<beneroth>
your mail server is a picolisp script? :P
<Regenaxer>
I fetch mbox files with pop3 into mutt
<Regenaxer>
no, but I do not care about the boxes there
<beneroth>
yeah well then you just need a POP client instead of IMAP :P
<Regenaxer>
yes
<beneroth>
yeah I see
<Regenaxer>
I configured mutt to fetch directly, no fetchmail or exim any more
<Regenaxer>
on Termux
<beneroth>
how do you do backups of the important mails?
<Regenaxer>
Anyway, I wont filter anybody, just archive the mail for fun when reading them later perhaps
<Regenaxer>
yes
<beneroth>
I like IMAP, for multi device access
<Regenaxer>
I keep in muwt only a hand full
<Regenaxer>
I archive in a directory tree
<beneroth>
I see
<Regenaxer>
in mbox files
<Regenaxer>
by year, user
<Regenaxer>
goes all into my incremental backups
<beneroth>
yeah as a community policy I would refrain from censoring/banning people. client side filtering is the right thing.
<Regenaxer>
right
<beneroth>
the mailing list is archived anyway
<Regenaxer>
T
<beneroth>
though we should establish another mailing list archive, we hang on one as gmane shut down
<beneroth>
also an entry on my todo list :)
<Regenaxer>
good idea
<beneroth>
but I believe you also have all messages, right?
<Regenaxer>
yes, I hope so
<Regenaxer>
There seem some mails to get lost, so the archive is probably also not absolutely complete
<beneroth>
my plan would be to have another archive, fetching the messages from the incoming mails, or from your mailing list server directly somehow.
<beneroth>
mail-archive could be scrapped to fill missing gaps
<beneroth>
not urgent, but something we should take care of eventually :-)
<Regenaxer>
yes, technically it would be another member
<beneroth>
I have to write code to handle incoming mails for my internal stuff anyway eventually
<Regenaxer>
ok
<beneroth>
yeah that would be the cleanest way :)
<Regenaxer>
beneroth, question about a e/r model
<Regenaxer>
I need 6 classes
<Regenaxer>
(class +LkwE +exp +lkw +snd)
<Regenaxer>
(class +LkwI +imp +lkw +snd)
<Regenaxer>
(class +LfE +exp +lf +snd)
<Regenaxer>
(class +LfI +imp +lf +snd)
<Regenaxer>
(class +SfE +exp +sf +snd)
<Regenaxer>
(class +SfI +imp +sf +snd)
<Regenaxer>
+imp and +exp are normal prefixes
<Regenaxer>
but +lkw etc could be subclasses of +snd
<Regenaxer>
like that:
<Regenaxer>
(class +LkwE +exp +snd)
<Regenaxer>
(class +LkwI +imp +snd)
<Regenaxer>
(class +LfE +exp +snd)
<Regenaxer>
(class +LfI +imp +snd)
<Regenaxer>
(class +SfE +exp +snd)
<Regenaxer>
(class +SfI +imp +snd)
<Regenaxer>
<beneroth>
I see
<Regenaxer>
What would be better?
<Regenaxer>
eg (class +lkw +snd)
<Regenaxer>
so the diff is only super vs. extra in the last class
<Regenaxer>
I think no much difference, right?
<beneroth>
right
<beneroth>
both works with (isa) and code handling +lkw in general
<Regenaxer>
only if there were more combinations
<Regenaxer>
yes
<beneroth>
both works with generalized indices on +lkw
<Regenaxer>
T
<beneroth>
I would probably do (class +LkwE +exp +lkw) instead
<beneroth>
but maybe your approach might be cleaner
<Regenaxer>
The full spec looks more general
<beneroth>
aye. what else?
<Regenaxer>
No diff else I think
<beneroth>
you're right
<Regenaxer>
On the DB it stays the same
<Regenaxer>
just the code structure
<beneroth>
objects only store +LkwE in their class list value
<beneroth>
T
<Regenaxer>
yes
<Regenaxer>
ok, so I go with the longer version
<beneroth>
shorter class list might be more readable, less chance to mistake it. on the other hand, keeping the class list transparent has also many advantages
<Regenaxer>
yes
<beneroth>
I think I tended to go for shorter in the past
<Regenaxer>
seems more clear
<beneroth>
T
<Regenaxer>
ah, ok
<Regenaxer>
oh, wait
<beneroth>
longer version makes it more transparent, and more obvious that changes can be made
<Regenaxer>
the above is wrong
<Regenaxer>
moment
<beneroth>
shorter version might make changes to the class list easier, as ordering is more implicit spread over the inheritance tree instead of having to make sure the ordering in the specific class list is right
<Regenaxer>
What I meant is:
<Regenaxer>
(class +lf +snd)
<Regenaxer>
(class +lkw +snd)
<Regenaxer>
(class +sf +snd)
<Regenaxer>
<Regenaxer>
(class +LkwE +exp +lkw)
<Regenaxer>
(class +LkwI +imp +lkw)
<Regenaxer>
(class +LfE +exp +lf)
<Regenaxer>
(class +LfI +imp +lf)
<Regenaxer>
(class +SfE +exp +sf)
<Regenaxer>
(class +SfI +imp +sf)
<Regenaxer>
<Regenaxer>
This would be the short alternative
<beneroth>
yeah
<beneroth>
hmmm
<Regenaxer>
So the diff is whether +lkw is a prefix
<Regenaxer>
or a subclass of +snd
<beneroth>
I think we have two kinds of parent classes in such a setup: prefix classes (providing methods, but not altering DB layout), and schema/entity generalizing (providing properties and indices)
<Regenaxer>
In this case they alter the properties
peterhil has joined #picolisp
<beneroth>
a strategy would be to keep prefix classes as-is (explicitly list them), and schema generalizations should be in the inheritance tree, so only the last entry in the class list is a +Entity
<Regenaxer>
In fact I have different properties in +LfE vs +LfI
<beneroth>
+exp and +imp are also +Entity ?
<Regenaxer>
this was the reason why I need to refactor
<Regenaxer>
no
<Regenaxer>
they are pure prefixes
<Regenaxer>
in fact still empty
<beneroth>
but meant for customizing of methods / method dispatching ?
<Regenaxer>
yes, perhaps
<Regenaxer>
What I *need* atm would be just
<Regenaxer>
(class +LkwE +lkw)
<Regenaxer>
(class +LkwI +lkw)
<Regenaxer>
(class +LfE +lf)
<Regenaxer>
(class +LfI +lf)
<Regenaxer>
(class +SfE +sf)
<Regenaxer>
(class +SfI +sf)
<Regenaxer>
<Regenaxer>
+lkw etc. being subclass of +snd
<beneroth>
I'm still unsure. But I tend to think that a clear distinguish between purely behavior changing classes and DB schema generalizations would be good.
<beneroth>
so the shorter version
<Regenaxer>
yeah
<beneroth>
hm, no
<beneroth>
hm
<beneroth>
:D
<beneroth>
1) long version, everything in the entity class definition, inheritance tree is rather flat
<Regenaxer>
in any case the DB relations will be mostly in +snd and *some* diffs in +LkwE
<beneroth>
2) short version, as much as possible in the inheritance tree, class definition as short as possible
<Regenaxer>
Inheritance is not much an issue in this case
<beneroth>
3) prefix classes into entity class definition, schema affecting stuff into parents
<Regenaxer>
The main point are the data diffences
<beneroth>
yeah it is not a optimization or functional discussion, it is purely about maintainability for the programmer
<beneroth>
no?
<Regenaxer>
as oop in general, yes
<Regenaxer>
The classes are changed at runtime
<Regenaxer>
So the data are cleaned up at such times
<Regenaxer>
+ClassField
<Regenaxer>
ok, so I go with the short on
<Regenaxer>
the last one displayed above
<beneroth>
in the past I did the short one
<Regenaxer>
ok
<beneroth>
also with class changes during runtime / obj lifetime, using set>
<Regenaxer>
yes, is more clear
<Regenaxer>
yes
<Regenaxer>
ok, thanks!
<Regenaxer>
Thinking loud helps :)
<beneroth>
my illustrative use case was a an object going through multiple phases, each phase adding some more properties and having mostly different indices.
<Regenaxer>
So everything possible
<beneroth>
all phases were subclasses of a generalized abstract one which holds the basic properties the obj has over the whole lifetime
<beneroth>
yeah
<Regenaxer>
ok
<beneroth>
everything possible, but question is which strategy is less pain in the future :)
<Regenaxer>
I cannot keep in the base class
<Regenaxer>
there are +Bag's with different contents
<Regenaxer>
so they go into +LkwE
<beneroth>
I've to add more phases in the past already, and I should still add more (new features). so I just create a new subclasse and adapt the code where the phase change is happening
<beneroth>
yeah
<beneroth>
you can surely have multiple layers of base classes :)
<beneroth>
that I would do too
<Regenaxer>
yeah
<beneroth>
so in conclusion: we agree that the short version is probably better, more concise
<beneroth>
?
<Regenaxer>
yes
<Regenaxer>
I feel so too
<Regenaxer>
Just (class +LkwE +lkw)
<beneroth>
yeah one can drill down into +lkw if required
<Regenaxer>
T
<beneroth>
ah short version is better
<Regenaxer>
T
<Regenaxer>
super instead of extra
<Regenaxer>
for +lkw -> +snd
<beneroth>
e.g. when wanting to combine with a new prefix class, you can do it at the definition of +lkw, instead of every definition below it
<beneroth>
aye
<Regenaxer>
right
<Regenaxer>
Big change after 2 years
<beneroth>
I think I only used extra in some rare special cases, e.g. a root parent class which knows that it is always used as a prefix class, and so in some cases it chooses not to handle the method message itself but pass it to the extra branch
<Regenaxer>
Until now we had only (class +Lkw +snd)
<beneroth>
I see
<Regenaxer>
Good that we noticed now
<Regenaxer>
before production use
<beneroth>
discussions always help a lot with such involved architecture decisions :)
<beneroth>
and some passive brain time
<Regenaxer>
T :)
<Regenaxer>
The stuff is weird. It turned out that +Lf and +Sf are very much like +Lkw when in import :)
<Regenaxer>
So it is 6 instead of 3 classes
<Regenaxer>
a mess in praxis
<beneroth>
the less classes the better, though having more gives more points to hook into
<Regenaxer>
true
<beneroth>
never forget the YAGNI rule
<beneroth>
"You Ain't Gonna Need It" - make sure too not gold plate stuff you don't need. (but add the stuff you certainly require)
<Regenaxer>
absolutely
<Regenaxer>
So +exp and +imp are not needed, but "Sendung" is *the* central object here, that I want the chance to insert stuff here
<Regenaxer>
It is even so that often +sf and +lf behave the same, so a common superclass would make sense
<Regenaxer>
not sure ;)
<Regenaxer>
So we can summarize, when in doubt, prefer the deep inheritance tree over the shallow one
<beneroth>
T
<beneroth>
<Regenaxer> It is even so that often +sf and +lf behave the same, so a common superclass would make sense
<Regenaxer>
yeah, but it gets too much
<Regenaxer>
I don't even have a good name
<beneroth>
depends, if they really have some "identity" in common (e.g. an DB index common to both would make sense), then a superclass. if it is more by chance that they have the same behavior, than maybe better put the behaviour in a prefix class (to have it at one place), and use the prefix class
<beneroth>
+sf = sendung. +lf = lieferung?
<Regenaxer>
Seefract vs Luftfracht
<beneroth>
ah
<Regenaxer>
snd = Sendung
<Regenaxer>
So sf and lf are intercontinental
<Regenaxer>
overseas
<beneroth>
so.. just Fracht.. or overseas-fracht as parent class
<Regenaxer>
perhaps
<beneroth>
freight
<beneroth>
or cargo
<Regenaxer>
well freight is everything
<beneroth>
hehe
<beneroth>
I suspected so
<Regenaxer>
and LKW is involved always in the beginning and end of a route
<Regenaxer>
a mess
<beneroth>
so OverseasFreight..
<beneroth>
osf
<Regenaxer>
makes sense
<beneroth>
overseas can always be by air or water
<Regenaxer>
yep
<beneroth>
though rhine river water transport or air transport from DE to Russia is not strictly required to go over any oceans :P
<Regenaxer>
:)
<Regenaxer>
There is no perfect solution
<beneroth>
well there are good approximations
<beneroth>
"picolisp software it built too last. maybe it is still in use once the alps are an ocean again!!" :P
<Regenaxer>
hehe :)
<beneroth>
my golden software design rule this days is "do not add restrictions. only restrict what is really required by the nature of the task, take extra care to not build in any extra restrictions by accident / dev laziness"
<Regenaxer>
Once the 6 classes are there, the internal hierarchy can be changed any time
<beneroth>
this rule is for me the essence of your work and the secret of the high re-usability of picolisp components and picolisps (especially pilDB's) emergent properties (which are very useful)
<beneroth>
T
<Regenaxer>
no need the modify the DB
<beneroth>
e.g. the arbitrary sized strings base upon the arbitrary sized integer numbers.
<beneroth>
and that results in arbitrary sized strings in the DB.
<Regenaxer>
as general as possible, no preliminary assumptions
<beneroth>
and while it makes sometimes sense to restrict the length / check for plausibility, the pain of artificially limited string lengths is one of the persistent pains of working with a traditional DBMS
<beneroth>
exactly
<beneroth>
the upside of those string limits in mainstream DBMS: it makes it easy to spot websites who don't follow best practices. if the password field has a size limit, then they certainly don't hash the passwords as they should
patrixl has left #picolisp [#picolisp]
patrixl has joined #picolisp
<Regenaxer>
if you see the model from outside
<beneroth>
well you see it when you register/change password, and they say you are only allowed to use.. N characters (not 60 from the password manager created)
<beneroth>
if they would store the passwords only as hashes, than there would be no need for a size limit, as the resulting hashes always have the same length
<Regenaxer>
Right
mtsd_ has joined #picolisp
mtsd_ has quit [Remote host closed the connection]
mtsd has quit [Ping timeout: 246 seconds]
rob_w has quit [Remote host closed the connection]
aw- has quit [Ping timeout: 246 seconds]
mtsd has joined #picolisp
mtsd has quit [Client Quit]
mtsd has joined #picolisp
alexshendi has joined #picolisp
<alexshendi>
Hi, hello, Good evening!
<Regenaxer>
Servus alexshendi!
<alexshendi>
Hi Regenaxer! How are you?
<Regenaxer>
Very good, thanks :)
<Regenaxer>
You are OK?
<alexshendi>
Yes, I'm quite well.
<Regenaxer>
Today I got pil21 so far that it can run misc/bigtest
<Regenaxer>
fails of course
<Regenaxer>
Must debug during the next days
<Regenaxer>
Then next goal is to get pil21 to self-bootstrap
<Regenaxer>
I hope within May
<mtsd>
Good progress, Regenaxer
<Regenaxer>
:)
<Regenaxer>
yes, faster than I expected
<mtsd>
It really sounds promising
<Regenaxer>
At least no unsolvable problem in sight currently
<alexshendi>
Regenaxer: Very interesting! Must fetch latest version.
<mtsd>
And no fear of a competing implementation appearing. Despite threats ;)
<Regenaxer>
Still not really usable though
<Regenaxer>
haha, Guido's?
<mtsd>
yes, just joking
<Regenaxer>
yeah
<Regenaxer>
Will be interesting, a Lisp consing at the end
<mtsd>
Revolutionary
<Regenaxer>
and in 160 lines
mtsd_ has joined #picolisp
mtsd has quit [Ping timeout: 264 seconds]
mtsd_ has quit [Quit: mtsd_]
tankf33der has quit [Quit: Connection closed for inactivity]
<beneroth>
and provable!
<beneroth>
we cannot even compile Fexpr, but proofs are no problem!
* beneroth
just realized he is very late to the party...
* beneroth
shrugs and continues to stroll around sipping from his orange juice
<DKordic>
PilOS: If the main idea of PilOS was to make it easy to try picoLisp, PuppyLinux is an interesting alternative. I booted Puppy Linux LiveUSB into OpenBox WIndow Manager: 160MB/2GB RAM with networking. rsync-ed my local pil install.
<beneroth>
that was not really the main idea of pilos
<beneroth>
PilOS was never really a real project.. it was considered for George Orais' work (pil hardware, or at least FPGA), or an alternative to that work because it didn't get get that far yer besides Regenaxer delivering a verilog implementation of pil in pretty short time (George is still working on it, the project is not dead)
<beneroth>
currently PilOS is fully based on standard BIOS functionality.. which apparently most BIOSes don't implement, because the major OSes use anyway their own implementations
<beneroth>
what would make PilOS useful would be to also do this implementations, and then on top to implement all the necessities for practical use, e.g. implementing a TCP stack
<beneroth>
that is heavy lifting. the theoretical pieces are difficult enough, but in practice many implementations fly around not following the standards the same way, so to actually work with them a lot of tolerance and special cases have to be implemented (and first one would need to know about them somehow)
<beneroth>
so in summary: pilOS is already a nice piece of software, and maybe some people will work on it again eventually, but so far it is just a nice academic toy without much practical use
<beneroth>
DKordic, how does PuppyLinux compar to TinyCore Linux and those other distros used for application containers?
twelvemonkeys has quit [Ping timeout: 260 seconds]
twelvemonkeys has joined #picolisp
<DKordic>
Just my 2 cents... I don't know nor care about container. Well, it's a (so called) LiveUSB, and it will even write the changes back to USB (configurable). I just tryed rebooting. I haven't figured how to get TinyCore LiveUSB working.
<beneroth>
interesting
<beneroth>
did you try tails?
<beneroth>
Linux USB distro, focus on security
<DKordic>
Barely heard about it. Not sure why should I even care?
orivej has quit [Quit: orivej]
<DKordic>
""Security"" is the new ""speed""?
<DKordic>
I mean it seems like a buzzword.
orivej has joined #picolisp
<DKordic>
What I heard sounded like a stupid joke.
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #picolisp
<beneroth>
it's basically a distro with tor & gpg ready xxD
<beneroth>
so more in the "security tools" realm than in the "magically secure" territory
<beneroth>
just thought of it because you talked about Live Distros
<beneroth>
in term of protective "security" I fully agree, best approach is to lower the attack surface by reducing the amount of software and using simple transparent software - within the limits that are practical
<beneroth>
practical is of course subjective :)
f8l has quit [Remote host closed the connection]
f8l has joined #picolisp
<DKordic>
Both GNU on technical aspects and FSF on philosophical aspects make no more sense than Guido Stepke (recently).
<DKordic>
For me security is an advanced topic and I wouldn't like to talk about it if anuthing GNU can even be mentioned :) .
ephetic has joined #picolisp
ephetic has quit [Remote host closed the connection]