xkapastel has quit [Quit: Connection closed for inactivity]
v88m has quit [Ping timeout: 272 seconds]
v88m has joined #picolisp
xkapastel has joined #picolisp
orivej has quit [Ping timeout: 268 seconds]
rob_w has joined #picolisp
mtsd has joined #picolisp
<tankf33der>
hi all
<Regenaxer>
Hi tankf33der
<tankf33der>
checked mul in pil21 on huge numbers, works.
<Regenaxer>
Thanks!
<Regenaxer>
I did only some random checks. Probably still buggy
<Regenaxer>
First finish a skeleton of all
<Regenaxer>
I hope I can implement all if big.l this month
<Regenaxer>
s/if/of
<Regenaxer>
Division is really tough
aw- has left #picolisp [#picolisp]
aw- has joined #picolisp
v88m has quit [Ping timeout: 260 seconds]
v88m has joined #picolisp
v88m has joined #picolisp
beneroth has joined #picolisp
<Regenaxer>
But I slowly begin to enjoy programming in PilVM. I still must learn to think in it
<beneroth>
hi all
<beneroth>
hi Regenaxer !
<Regenaxer>
Hi beneroth!
<beneroth>
theorizing question: when to use coroutines instead of a process? just to encapsulate state within a single process?
<beneroth>
nice to hear you start to enjoy pilvm :)
<beneroth>
pil vm implemented in pilvm using llvm. nearly microsoft level of naming (just nearly, not really as bad)
<Regenaxer>
Yes, to have it in a single process
<Regenaxer>
tightly coupled, less overhead
<Regenaxer>
I use it with 'task' sometimes
<Regenaxer>
In simple cases 'job' can be used
<Regenaxer>
So when you need a generator, coroutines are useful. With processes you need to use pipes for that
<Regenaxer>
Yeah, PilVM is not easy. I must keep LLVM-IR in mind all the time.
<beneroth>
what about doing IO (disk, network) - better in separate processes then, to gain parallelism ?
<beneroth>
or task, first one to wake up gets processed first?
<Regenaxer>
This can be a good idea
<Regenaxer>
as you say, for parallelism
<beneroth>
okay, thanks :)
<Regenaxer>
I often fork in tasks when a request arrives
<beneroth>
ah, nice!
<beneroth>
haven't thought of that
<Regenaxer>
Typical example is 'server'
<Regenaxer>
but also 'go' in app/main.l
<Regenaxer>
for RPC requests
<beneroth>
I don't have a specific use case, just general theorizing. though one use case would be an interface to a network resource, this interface having state and a (pip)ed subprocess to talk to the remote resource. so multiple processes would here probably be the best strategy