xkapastel has quit [Quit: Connection closed for inactivity]
razzy has quit [Remote host closed the connection]
razzy has joined #picolisp
razzy has quit [Remote host closed the connection]
razzy has joined #picolisp
razzy has quit [Remote host closed the connection]
razzy has joined #picolisp
orivej has joined #picolisp
_whitelogger has joined #picolisp
rob_w has joined #picolisp
aw- has joined #picolisp
<aw->
Regenaxer: are you set on making PicoLisp releases every 6 months: June and December? It seems like the pattern since 2016. Just wondering if it's your plan or just a coincidence
<Regenaxer>
Yes, a plan
<Regenaxer>
before it was every 3 months
<aw->
great, i like it
<Regenaxer>
But the releases are mainly for Debian etc, and they are slow anyway
<Regenaxer>
For normal users I simply recommend the rolling release, it is always up-to-date
<aw->
yes i've been slow keeping TinyCore up-to-date as well
<Regenaxer>
thats all right for OS distros
<Regenaxer>
once an old distro version is running, a fresh local version can be built easily
<aw->
true
<Regenaxer>
The rolling release changes several times per week on average
<aw->
i'm having some philosophical questions recently, regarding software package versioning, OS's, etc
<aw->
mostly just curious if there's a solution for "staying up-to-date" with everything, without the high risk of "breaking something"
<beneroth>
I think there is no general solution apart from giving some care to backward compatibility.
<aw->
beneroth: so you think it's a human solution?
<aw->
no software/automation can handle that?
<beneroth>
I mean in theory it always should be possible to do clean migrations automatically, as the software vendor / upstream dev should know the older and the new state.
<beneroth>
aye
<beneroth>
I think you might be able to handle it partially. like closely monitoring what the update is changing
<beneroth>
but you can't always deduce from that how the existing data or config files need to be changed to fit the new system.
<beneroth>
especially when meaning of data structures change without a structural change.
<aw->
right
<beneroth>
I was for a while fan von semver, but I think now that the version scheme in use doesn't really mean anything.
<aw->
i'm still a fan of semver for certain things
<beneroth>
agreed.
<aw->
but not everything.. i think some things it's good to use Year.Month versioning
<beneroth>
T
<beneroth>
or just ever-increasing integer :)
<beneroth>
with Year.Month you can see the time since last change/update, which might tell you something.
<aw->
yeah
<aw->
like PicoLisp does
<beneroth>
T
<beneroth>
I think ubuntu started with it originally
<beneroth>
then picolisp and later windows followed.
<beneroth>
*g*
<beneroth>
You can also be funny and use a version scheme from Knuth, e.g. every version adds another digit of Pi to the version number :P
<beneroth>
as meaningful as esoteric programming languages
<Regenaxer>
:)
<beneroth>
aw-, did you look into Nix package manager (from NixOS) ?
<beneroth>
see also guix (based on nix)
<aw->
yes i've seen it
<aw->
it has some interesting ideas
<aw->
but i don't like the implementation
<aw->
and the package config language makes me vomit
<beneroth>
on OS theory: I think we should go back to lisp machines. Legend holds that you could undo/redo all configuration changes, and whatever you changed (and you could change like everything), the system always managed to boot into a stable (maybe reduced) environment where you could undo your breaking changes.
<beneroth>
aw-, haha, same!
<aw->
oh that would be a wonderful env
<aw->
ability to roll back _anything_
<beneroth>
aw-, my current approach to package management is: package of content, metadata (like package id/version/description/etc), so quite debian style. and in the metadata there is a list of pre-defined "hooks" which you can set with the filepath (a path present in the content), the file that should be executed. hooks would be things like "install" "remove" "upgrade" "downgrade" etc...
<aw->
similar to debian control files
<beneroth>
aye, that is the inspiration.
<beneroth>
if there is no file/hook not set, have a general default behaviour (like install: just copy all the extracted content files to its new locations)
<aw->
i'm trying to think of a system where developers make their releases directly to the end-user, instead of the end-user relying on the OS to push the update
<beneroth>
nice idea. problem is, user does not care :)
<aw->
right, but it's a pull, not push system
<beneroth>
I mean the linux package managers allow this usally. Like having your own source.list entry in debian.
<aw->
yes, and you can add the GPG keys of that developer and pull "safely" from their repo
<beneroth>
why do you consider debian push?
<aw->
no no, i mean.. if user doesn't care, then they won't get updates because they would need to "pull" first
<beneroth>
I envision packages to be signed multiple times: once from the original author, and then from "repo" (publisher/distributor) who might or might not give some guarantees on his repo (like we reviewed the stuff this and this way blabla).
<aw->
ex: Regenaxer makes a new release, i run a command that updates the picolisp on my system, independent of whether i'm using debian, alpine, tinycore, or whatever Linux
<beneroth>
signature is to prevent manipulation in transport and blame mechanism
<aw->
yes
<beneroth>
aw-, well this requires that Regenaxer is making the package in away that it can detect and handle its environment
<beneroth>
or that the package is never optimally using its environment
<aw->
no
<aw->
yes exactly
<aw->
the package shouldn't care about the environment - ideally
<beneroth>
like ORM-oriented database usage (no special features, because we might want to switch - never happens)
<beneroth>
I think this is not possible, you get at best an illusion of "not caring about environment"
<beneroth>
"not caring about environment" = "not using advantages where they're available"
<beneroth>
in the end its still platform-dependent (because too many details to take care of to guarantee otherwise), but now you only use the the smallest common features, so you probably end up with all the disadvantages of the different platforms you support without any of the advantages.
<beneroth>
I mean look at C and C++. the standardized language is completely platform-independent. but all the meaningful libraries aren't :)
<aw->
good points
<beneroth>
I myself find for myself the other strategy better at the moment: focus on a single (or a few) platforms and optimize the systems on them.
<beneroth>
like picolisp does with its focus on linux, supporting other unix'es when it's feasible.
<aw->
haha yeah so many C programs can't simply be compiled with gcc and no args
<aw->
do you think it's feasible for Regenaxer to build the packages for debian, ubuntu, and other OS's which typically distribute picolisp?
<beneroth>
restrictions like that are kinda limiting and frustrating (I would love to make native apps instead of web with online-requirement, but that would mean supporting many different OS)
<aw->
or do you think it's still a good idea to rely on "one maintainer" for each OS
<beneroth>
I think it is good with "one maintainer per OS" not because of any technical reasons but because those maintainers are active in the respective communities. they have a network of people and now how to solve issues.
<aw->
what about issues where the maintainer is sick? or on vacation, or lazy?
<beneroth>
less risk than focusing it on Regenaxer :) same problem, just another level.
<aw->
well Regenaxer being the main dev of his software.. if he's on vacation, why would there be a release?
<beneroth>
you can add redundancy, but you cannot completely solve the underlying problem.
<beneroth>
well either the OS-specific package release gets delayed then, or you have multiple maintainers (redundancy) if you really need it.
<aw->
sorry i have to step out, i can continue this discussion later
<beneroth>
sure
<beneroth>
thanks
<beneroth>
:)
<aw->
i'm trying to think of the possibility of doing this "maintenance" stuff without a "maintainer" (human) - is it possible? if so, how?
<aw->
bbl
<Regenaxer>
see you aw-
<beneroth>
In theory in best cases yes. In many cases and an practice - no chance I think.
<beneroth>
see you aw- :)
<beneroth>
I think the best strategy would not be to automate the human away, but get him/her enough tooling so the task can be handled easily and simple :)
<beneroth>
Regenaxer, what is the best way to achieve (tell *Pid) ?
<Regenaxer>
you mean how to know the pid?
<beneroth>
no, how to shovel messages into the current process.
<Regenaxer>
ok, mom
<beneroth>
like, in my scenario yesterday, I did (tell prog step1 step2) in another process. in current process I just finished execution of step2 function, and now I determine that I need to repeat the whole thing...
<Regenaxer>
something like (tell 'foo Pid1 *Pid ...) ?
<Regenaxer>
ah, mom
<beneroth>
How to conditionally issue another (top-level) function call in my current process. without doing db polling or such.
<Regenaxer>
I have examples
<beneroth>
install a (task) which de-installs itself?
<Regenaxer>
this is also possible, but independent from tell
<beneroth>
yes I could also directly call it, but then it might end up recursive, or at least deeply stacked.
<beneroth>
I would like to prevent the stacking.
<Regenaxer>
hmm, cant find
<Regenaxer>
must be something like (tell Pid 'tell *Pid ... ?
<beneroth>
ah
<beneroth>
tell another process to tell you xD
<beneroth>
lol
<Regenaxer>
yeah
<Regenaxer>
I have it here, but indirectly
<Regenaxer>
the second tell is some function which calls 'tell' in turn
<beneroth>
nice idea, but I don't have another process :) This is my long-running background worker process, the other processes being http request handlers (one-shots, not long-running)
<Regenaxer>
hmm, no process? Why tell then?
<beneroth>
Background-Process A. Short-lived process B which (tell A) to do something. After B finished with something, it might has to do the same thing again (conditionally!). how can it tell itself?
<beneroth>
argh
<beneroth>
wrong
<beneroth>
Background-Process A. Short-lived process B which (tell A) to do something. After A finished with something, it might has to do the same thing again (conditionally!). how can it tell itself?
<beneroth>
B is not around anymore at this point.
<Regenaxer>
Is it necessary to tell to itself?
<beneroth>
(tell) is not necessary. but how do it :)
<Regenaxer>
I think the parent always filters the sending process
<beneroth>
can clash, if multiple such messages happen at the same time...
<Regenaxer>
right
<Regenaxer>
also, -2 is reserver for 'tasks'
<Regenaxer>
so use -3, -4 ...
<beneroth>
so maybe instead of one fixed background process, fork a new one for every time something has do be done, which then loops until it is surely finished?
<beneroth>
but fork must happen on parent level, not in child (like background process is one)
<Regenaxer>
Isnt this a task for 'tasks' ?
<Regenaxer>
I use it is PilBox apps for such management
<beneroth>
it should be. let me check if anything speaks against it.
<Regenaxer>
It is very powerful
<Regenaxer>
on each firing it reconfigures the task for another kind of event
<Regenaxer>
all in a single *Run entry
xkapastel has joined #picolisp
<beneroth>
ok, I think: (task) which does db poll, and handles it. if there is nothing to do, task is not longer installed. main processes might install the task when the know there is something to do, but if the background process already knows of the task (it is installed), then (task) fails and that is ok.
<Regenaxer>
My typical case is waiting on a socket, then sleep a while
<beneroth>
sounds this good to you?
<Regenaxer>
yes, should be fine I think
<Regenaxer>
needed only once?
<Regenaxer>
Easier might be to have the task running infinitely, and checks a global if it should do something
<Regenaxer>
the global check is fast enough
<beneroth>
ah right
<beneroth>
global check to prevent unnecessary db polling
<beneroth>
right!
<beneroth>
yes of course
<Regenaxer>
Not so clean, but simpler ;)
<beneroth>
call me blind.
<beneroth>
pretty clean, actually
<Regenaxer>
ok :)
<beneroth>
now I feel stupid
<beneroth>
no task
<Regenaxer>
no task needed?
<beneroth>
tell is not executing anything but setting a global
<Regenaxer>
:)
<beneroth>
main loop in background process is doing db polling according to the global
<beneroth>
(tell on ...) :)
<Regenaxer>
yep
<beneroth>
hm
<beneroth>
and the tell is only handled during wait, so no conflict with (off ...) :)
<beneroth>
good
<beneroth>
all good
<Regenaxer>
no race
<beneroth>
aye. nice.
<beneroth>
thanks Regenaxer.
<beneroth>
that took me quite a while to get it simple -.-'
<Regenaxer>
So no task? Just (loop (wait *Global) ...) ?
<beneroth>
aye
<Regenaxer>
good
<beneroth>
I don't see why task would be necessary
<Regenaxer>
yeah
<beneroth>
the background process is anyway (loop (wait)) in essence, to be available as background processor via (tell) :)
<Regenaxer>
:)
<beneroth>
if one knows the db file, then task listening to change of db file to issue db poll would be an idea ;-)
<beneroth>
but not needed :)
<Regenaxer>
with (info)?
<beneroth>
hm right, stupid me
<Regenaxer>
I use inotifywait sometimes
<Nistur>
mornin'
<beneroth>
yeah, inotifywait
<Regenaxer>
no poll needed
<Regenaxer>
Hi Nistur
<beneroth>
morning Nistur !
<beneroth>
Regenaxer, I still need more zen-slaps to think simpler :)
<Regenaxer>
haha :)
<beneroth>
Thank you Regenaxer sensei :)
<Regenaxer>
its my pleasure ;)
<Nistur>
o7
<beneroth>
Regenaxer, instead of a boolean global, I make it a list of db objects which require handling. so (tell push1 ..) instead of (tell on ...)
<Regenaxer>
even better, yes
<beneroth>
the step-functions can just push their object back into the queue whenever next step or repetitions are necessary
<beneroth>
so, a real message queue :)
<Regenaxer>
T
<beneroth>
without misusing tell.
<Regenaxer>
Or (tell 'fifo ..
<beneroth>
hahaha, how perverse
<Regenaxer>
(while (fifo ) (handle @))
<beneroth>
ah ok
<Regenaxer>
keeps the sequence
<beneroth>
I thought you meant (tell fifo tell) :D
<Regenaxer>
as push reverses
<beneroth>
sequence does not matter actually :)
<Regenaxer>
ok
<beneroth>
hm
<beneroth>
yes
<beneroth>
fifo is nicer
<beneroth>
I use fifo
<beneroth>
thanks!
<beneroth>
but no
<beneroth>
does not check for double entries, does it?
<beneroth>
not like push1
<beneroth>
no harm done, but needless checking :)
<Regenaxer>
ok, then push1 is better
<beneroth>
How is life, Nistur ?
<beneroth>
Regenaxer, ersatz: did you implement your (gc), or do just trigger the java gc ?
<Regenaxer>
The latter. No need for a gc in Java
<Regenaxer>
Makes it a lot easier
<beneroth>
kk
<beneroth>
probably a .NET implementation could be based of ersatz.
<Regenaxer>
yes, similar
<Regenaxer>
I also have a fix for Ersatz on my todo list
<Regenaxer>
It still uses the older version of namespaces
<beneroth>
what features of pil64 does Ersatz not support? limited apply? what else?
<beneroth>
ah I see
<Regenaxer>
ie a big merged ns, not a search order
<beneroth>
yeah I know
<Regenaxer>
Had no prio
<Regenaxer>
Apply is fully supported
<Regenaxer>
only system stuff is missing
<beneroth>
yeah because you mainly see ersatz as an alternative boostrap, not as an real VM implementation ;-)
<Regenaxer>
networks, processes
<Regenaxer>
yes
<beneroth>
ok. so (fork) ?
<Regenaxer>
and it is fun
<Regenaxer>
right, no fork
<Regenaxer>
also no coroutines
<Regenaxer>
(no stack access in Java)
<beneroth>
(fork) is essential for most picolisp uses :)
<Regenaxer>
T
<beneroth>
hm
<beneroth>
maybe .NET VM is not even needed, if ersatz is pumped up to support all the pil64 features...
<Regenaxer>
I thought about emulating fork with threads
<Regenaxer>
but it is heavy
<beneroth>
though with the licensing changes of oracle, a .NET version might be more feasible
<beneroth>
yeah I see.
<beneroth>
threads are better supported than IPC
<Regenaxer>
yes
<Regenaxer>
but they are not isolated from each other
<Regenaxer>
So the behavior is different
<Regenaxer>
And copying heap and stack is no option
<beneroth>
why not, beside being ugly and horrible?
<Regenaxer>
copy heap would work, but is expensive
<Regenaxer>
Stack is not accessible
<beneroth>
thread behaviour: yeah therefore clojure with its immutable thingy makes sense. because its built upon threads. as picolispers we kick out the thread axiom, and then immutability is not so meaningful anymore.
<Regenaxer>
The database could be implemented (single process only, so no locking is needed)
<beneroth>
well it can only be a true picolisp vm if it can run standard picolisp applications unchanged. e.g. @app :)
<Regenaxer>
yes, but immutability is an issue. In pil we have non-destructive funs for that
<beneroth>
T, but that is not general universal immutability, that is control to the programmer :)
<Regenaxer>
it is not only for threads (though there it is more important)
<Regenaxer>
yes
<beneroth>
T
razzy has quit [Ping timeout: 245 seconds]
<aw->
re
<beneroth>
wb
orivej has quit [Ping timeout: 258 seconds]
<aw->
is pil @test/lib.l + ; # sufficient for running all the picolisp tests?
ubLIX has joined #picolisp
<Regenaxer>
yes, perfect
alexshendi has joined #picolisp
<aw->
ok, so if it exits cleanly then no problem
<aw->
pil @test/lib.l -bye +
alexshendi has quit [Read error: Connection reset by peer]
<aw->
hmmm… Ubuntu 'trusty' doesn't have picolisp
<aw->
i think
<aw->
oh.. it does
ubLIX has quit [Quit: ubLIX]
<Regenaxer>
I also start with -bye, directly from .bash_history
<Regenaxer>
There were one or two Ubuntu versions without pil
<aw->
Preparing to unpack .../picolisp_3.1.5.2-2_amd64.deb ...
<aw->
oh man…
<Regenaxer>
oh
<aw->
that version of PicoLisp can't compile pil64 because it's missing 'flood'