xkapastel has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #picolisp
orivej has joined #picolisp
kashyap_ has quit [Ping timeout: 256 seconds]
xkapastel has joined #picolisp
orivej has quit [Ping timeout: 245 seconds]
ubLIX has joined #picolisp
orivej has joined #picolisp
razzy has joined #picolisp
<razzy>
um, if i have (rel pa (+Joint) kids (+Man)) is "kids (+Man)" and "pa (+Joint)" interchangable without function change?
xkapastel has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #picolisp
f8l has quit [Ping timeout: 245 seconds]
<Regenaxer>
razzy, what do you mean with "interchangable"?
<Regenaxer>
The order of args to 'rel'?
<razzy>
yes
f8l has joined #picolisp
<Regenaxer>
I still dont understand
<Regenaxer>
args to a function always have a defined order
<razzy>
is (rel pa (+Joint) kids (+Man)) different from (rel kids (+Man) pa (+Joint) )
<Regenaxer>
sure
<Regenaxer>
pa is the relation
<razzy>
than i do not undestand it at all, and will go back to reading :D
<Regenaxer>
kids and (+Man) are arguments for +Joint
<Regenaxer>
ok
<Regenaxer>
It is always (rel <name> (+Class1 ...) ...
<Regenaxer>
the second ... is the args depending on the classes
<Regenaxer>
Basically 'rel' is 'new' with (+Class1 ...)
<Regenaxer>
and stores it under the <name> property in the current *Class
<razzy>
i feel like "Basically..." could help me
<Regenaxer>
ok :)
<Regenaxer>
well, not only basically, but really is 'rel' a frontend to 'new'
<Regenaxer>
: (pp 'rel)
<Regenaxer>
(de rel Lst
<Regenaxer>
(def
<Regenaxer>
*Class
<Regenaxer>
(car Lst)
<Regenaxer>
(new (cadr Lst) (car Lst) (cddr Lst)) ) )
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #picolisp
alexshendi has joined #picolisp
ubLIX has quit [Quit: ubLIX]
beneroth has joined #picolisp
<beneroth>
Ahoy
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
xkapastel has joined #picolisp
alexshendi has joined #picolisp
<beneroth>
Regenaxer, still around?
ubLIX has joined #picolisp
razzy has quit [Remote host closed the connection]
razzy has joined #picolisp
<Regenaxer>
beneroth, yes, now :N
<Regenaxer>
:)
<beneroth>
:)
<beneroth>
I don't wanna disturb your evening :)
<Regenaxer>
No problem
<beneroth>
Just liked to tell you that last week I figured out how (tell) mechanism works (probably) on the receiving end...
<Regenaxer>
Good! :)
<Regenaxer>
in waitFd ?
<beneroth>
I wanted to misuse (tell) for a kind of message queue, but that didn't work out as I originally expected, I can see why ^^
<Regenaxer>
Well, it *does* queue
<Regenaxer>
unly in one direction though
<beneroth>
yes, but not in order really. well it does, the thing is not the queue, but when the receiving process does process incoming stuff :)
<Regenaxer>
not in order?
<Regenaxer>
it arrives when the child gets the event, yes
<beneroth>
I sent 3 messages right after each other. 3 method calls working on the same object, brining it from one status to the next. so the second and the last method call make sure to wait until the object has their start status (or quit if the object got a failed status flag). so I sent the 3 messages, the first one doing processing and the second and the third doing looping until they may start processing. I got the concept wrong, you see! instead of being exec
<beneroth>
uted pseudo-parallel, they (of course!) blocked each other. I figure that happened: process (receiver) is in (wait), fetches first message, starts to execute, meets (dbSync) so enters (wait), fetches second message, enters (wait 'num), fetches third message, enters (wait 'num), endlessly loops :) because it does not work on message 2 or three wail being in (wait) in message 3. message 2 will only leave its (wait) once message 3 has been finished, and same
<beneroth>
with message 1 in respect to message 2. right?
<beneroth>
I should use *Task mechanism instead, I believe now :)
<Regenaxer>
yes, calling wait in a task handler ignores top level events iirc
<Regenaxer>
The events are always asynchronous
<beneroth>
yes, and the (wait) which fetches messages from the pil IPC only returns once those messages are finished executing. so (tell) messages should be short to execute. correct?
<beneroth>
the (waits) stack
<beneroth>
s/(waits)/(wait)s
<Regenaxer>
Not necessarily, if the nobody else is interested that the child gets done :)
<Regenaxer>
(short to execute)
<beneroth>
haha, T
<Regenaxer>
if waitFd is called in a task handler, it sets locally *Run to NIL
<Regenaxer>
so the top level events are handled later
<beneroth>
yeah I figure my scheme would work if I send my messages (which should be processed after each other sequentially) in reverse order. so first message 3, which gets blocked during handling of message 2, which gets blocked during handling of message 1. that would work.
<beneroth>
ah
<Regenaxer>
No, reverse is not needed
<Regenaxer>
But we need defined responsibilities
<Regenaxer>
I dont remember exactly, should check myself
<Regenaxer>
What did you want to achieve?
<Regenaxer>
I do a lot of IPC both with tell and sockets, and it is reliable
<beneroth>
It looks to me that when one is doing: (tell ... 'wait) (tell ... 'wait) (tell ... 'wait), then the first wait is blocking until the second one is done, the second is blocking until the third is done.
<beneroth>
yeah yeah
<beneroth>
it's all reliable
<beneroth>
no critic
<Regenaxer>
yes, wait *in* a task is dangerous
<beneroth>
!
<Regenaxer>
you don't know which handler gets which events
<beneroth>
yep
<Regenaxer>
so the inner wait ignores the outer ones
<Regenaxer>
pseudo: (let *Run NIL ...
<beneroth>
not ignores, blocks. they will be handled later.
<beneroth>
hm
<Regenaxer>
right
<beneroth>
aye
<Regenaxer>
the inner select() does not select it
<Regenaxer>
thats all
<Regenaxer>
thus ignored
<beneroth>
ah I see
<beneroth>
what you mean
<beneroth>
yeah
<beneroth>
no problem
<Regenaxer>
the pending data show up later
<Regenaxer>
So we know exactly which level handles which descriptors
<beneroth>
so what is your perfect solution for "background process do X when your (db ...) succeeds" ?
<beneroth>
(loop (when (db ...)) (wait 15000)) ?
<Regenaxer>
hmm, something like 'later'?
<beneroth>
na, nothing to do with later I think.
<Regenaxer>
The loop is in a child
<Regenaxer>
a sister process?
<beneroth>
it's not about parallel processing really. it's about "start processing that object when it's property 'state looks like X)
<Regenaxer>
and when finished something, does tell?
<beneroth>
no, changes are saved to database and via database communicated to main processes.
<Regenaxer>
ok, this is the best
<beneroth>
trigger could also be changes in database
<Regenaxer>
but then we must poll to see if it chhanged?
<beneroth>
or (tell) from main process to make the handler process aware that it should do something
<beneroth>
aye
<Regenaxer>
So tell is good here
<beneroth>
I think about a *Task which runs a db query from time to time, to see if there are objects to process
<Regenaxer>
I would not see from time to time
<Regenaxer>
a single task
<Regenaxer>
but wakes up only on tell
<Regenaxer>
or a socket
<Regenaxer>
recently I even use a task on UDP
<Regenaxer>
to refresh the GUI
<Regenaxer>
if objects in other DBs were modified
<Regenaxer>
ie wipe
<beneroth>
I did such setups before but then the tell'ed message/processing was always just one step.
<Regenaxer>
but not in family processes
<beneroth>
now it can be 1, 2 or 3 steps
<beneroth>
which I want to be able to run independently, or all in sequential order
<Regenaxer>
ok
<beneroth>
how to tell the "do multiple method calls after another" ?
<Regenaxer>
just send them with tell one after the other
<beneroth>
or doing another wrapping method for that, and tell the do-all> method instead of tell step-1> ... step-2> ?
<Regenaxer>
I would call 3 times
<Regenaxer>
seems more clear
<beneroth>
haha, yeah that was what I did. but that doesn't work.
<Regenaxer>
why not?
<Regenaxer>
cause you wait in the task?
<beneroth>
step-1) does (dbSync), so enters (wait), this start the handling of the second tell, but the second tell enters a loop where it waits until the object meets it start criteria
<beneroth>
aye
<Regenaxer>
ah
<Regenaxer>
But dbSync clears *Run
<Regenaxer>
should be OK
<Regenaxer>
: (pp 'dbSync)
<Regenaxer>
(de dbSync (Obj)
<Regenaxer>
(let *Run NIL
<Regenaxer>
(while (lock (or Obj *DB))
<Regenaxer>
(wait 40) )
<Regenaxer>
(sync) ) )
<Regenaxer>
so it runs isolated
<Regenaxer>
the tell events are ignored, no?
<Regenaxer>
hmm
<Regenaxer>
I see
<Regenaxer>
tell and hear are independent of *Run
<Regenaxer>
understand
<beneroth>
I did (tell step1> Obj) (tell step2> Obj) (tell step3> Obj). step>1 is doing dbSync... commit... processing...dbSync...commit... step2> and step3> are doing (loop (dbSync) check database, should I do something now? (commit) (wait 'num)) :)
<beneroth>
I end up in the step3 waiting loop. step1 and step2 are blocked from it (I deduce)
<beneroth>
s/from it/by it
<Regenaxer>
hmm, not sure. involved issue
<beneroth>
while step3 is sleeping in (wait num), step2 and step1 are not continueing
<Regenaxer>
DB writes are OK I think. the problem is the wait
<Regenaxer>
Why do you want to sleep?
<beneroth>
therefore I figure reverse order of (tell)s would solve it: step3 first, enters wait, which triggers handling of step2, enters wait, which triggers handling of step1, step1 finishes, step2 gets unblocked, finds its beginning criteria fullfilled and does its thing, finishes, block on wait in step3 gets uphold/continues, finds it start criteria fullfilled, does it thing, finish :)
<beneroth>
step2 requires step1 to be finished. step3 requires step2 to be finished.
<Regenaxer>
weird
<Regenaxer>
There must be a simpler way
<beneroth>
maybe, or at least a cleaner :)
<Regenaxer>
Yes, it feels so
<beneroth>
I think polling the DB would be ok.
<Regenaxer>
hmm, also not nice
<Regenaxer>
at least a single message to tell to check it
<beneroth>
or just normal (tell), but instead of sending multiple tells where I want multiple steps do be done, I send one prog which calls the methods in sequential order
<beneroth>
yeah
<Regenaxer>
yes, as you suggested above
<beneroth>
just not sending multiple tells which depend on each other directly, as they might end blocking each other
<beneroth>
practically resulting in a logical dead lock :)
<beneroth>
no wrapping method/functions. just using prog - thats the right solution.
<beneroth>
I think now
<Regenaxer>
hmm, perhaps, I dont understand the exact situation good enough
<beneroth>
I mean instead of (tell step1) (tell step2) it should be (tell prog step1 step2)
<beneroth>
ok
<Regenaxer>
yes
<beneroth>
no worries
<Regenaxer>
at least it guarantees sequential exec on the receiving side
<beneroth>
aye
<beneroth>
well my mental model was wrong about (wait)
<Regenaxer>
this is a tricky point
<Regenaxer>
it also happens in the gui
<Regenaxer>
if you call (wait) in a GUI event
<beneroth>
I expected multiple pseudo-parallel (waits) to not block each other, but the process just working on whatever (wait) can continue. but that is not how it works, kinda.
<Regenaxer>
as the GUI runs in tasks
<beneroth>
ah?
<Regenaxer>
I do that iirc, it is the reason why wantFd is implemented that way
<Regenaxer>
(ignoring higher tasks)
<Regenaxer>
ie http events are delayed
<beneroth>
ah yeah, makes sense
<Regenaxer>
while eg the db is updated
<beneroth>
it's all correct, nothing needs to be changed
<Regenaxer>
ok :)
<beneroth>
(only documented eventually in an article or tutorial) :)
<Regenaxer>
ah, right, this should be better explained
<beneroth>
well needs is own article
<Regenaxer>
true
<beneroth>
the reference is ok and right. its a more deeper thing.
<Regenaxer>
yes, involving several issues
<Regenaxer>
the ref addresses only individual issues
<Regenaxer>
I still like this model
<beneroth>
btw. I thought maybe we (well *someone*) should write an picolisp implementation on .NET, similar to how ersatz runs in java (.NET is conceptually comparable to java runtime)
<beneroth>
to get picolisp running on windoof
<Regenaxer>
for example, the threads in Java are a nightmare
<beneroth>
haha, I heard so before :)
<Regenaxer>
pil in .net would be good
<Regenaxer>
Yes, I struggle with Addroid
<beneroth>
I see why (wait) is how it is. it's just the most simple straight-forward way. and no real disadvantages with this, one just needs to be aware if one has to do some real involved stuff with it.
<Regenaxer>
I end up needing to do everything in 'runOnUiThread'
<beneroth>
what is that?
<Regenaxer>
Many code pieces are not allowed to be run directly
<beneroth>
I'm fortunate that I know less java then you :P
<Regenaxer>
The callback pops up a toast when the cookies are successfully removed
<Regenaxer>
So you see everything run asynchronous
<Regenaxer>
In Pil with task and tell everything is still pretty syncronous
<beneroth>
it's a feature! :D
<Regenaxer>
haha, indeed!
<beneroth>
more threads = faster! yes? no? what more bugs? more consulting time you mean!
<Regenaxer>
yes, more money!!!
<beneroth>
so if C++ was a conspiracy so programmers can look busy... (you know the story?).. then what is java? :D
<Regenaxer>
yep
<Regenaxer>
the same
<Regenaxer>
just more acceptable by programmers
<Regenaxer>
(garbage collection etc)
<Regenaxer>
What is this with the voting machines in Suisse?
<Regenaxer>
Can you trust them?
<beneroth>
lol
<Regenaxer>
ok :)
<beneroth>
there are multiple issues with them
<Regenaxer>
they asked the public
<Regenaxer>
to check the code
<beneroth>
first: conceptually eVoting machines are (afaik) flawed, either you get accountability, or you have secret voting. but not both. physical ballot voting gives you both, and for safety you want both.
<Regenaxer>
yes, they will never work
<beneroth>
yes, but you have to sign some terms. also the code is incomplete (to be compiled/executed). also they exclude much attack vectors (e.g. hardware, untrustable client OS, DDoS, ...)
<beneroth>
some guys leaked the source code then to a public repo :)
<beneroth>
and twitter is full of nice comments of international top guys.. looks like the codebase is one big java mess
<beneroth>
:)
<Regenaxer>
oh
<beneroth>
the best thing is that there are even git merge conflicts.. has no effect on the code, but it shows that the developers don't really know the tools they work with
<beneroth>
(when you have a conflict because multiple people edited the same files, and git cannot resolve the conflict automatically, it puts both parts in the file for you to edit, so you can edit it to the definitive version of the code. they didn't do this)
<Regenaxer>
haha, like me (as far as Git is concerned)
<beneroth>
well but you don't work with it :)
<beneroth>
it's a difference if you don't use a tool, or if you use it wrong.
<beneroth>
also you work alone, so that issue would not happen to you :)
xkapastel has quit [Quit: Connection closed for inactivity]
<Regenaxer>
I sent you a book (also about voting machines)
<Regenaxer>
if you have time ...
<Regenaxer>
funny and interesting
<Regenaxer>
OK, I go to sleep :)
<Regenaxer>
brain stops working
<Regenaxer>
Good night!
<beneroth>
thank you!
<beneroth>
good night!
<beneroth>
sleep well. thanks for your support :)
razzy has quit [Remote host closed the connection]