chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
<abu[7]>
bd
<abu[7]>
oops
corecheckno has joined #picolisp
corecheckno has quit [Remote host closed the connection]
<tankf33der>
Morning
<tankf33der>
abu: Some time ago, you mentioned that coroutines are currently single-core. What changes would need to be made for them to run on different cores?
<abu[7]>
It is a single process
<abu[7]>
What do you mean with different cores? At the same time?
<tankf33der>
Yeap. But when you said: it is a single process. I started understand this is impossible
<abu[7]>
Yeah
<tankf33der>
yeah
<abu[7]>
You mean threads
<abu[7]>
running in parallel
<abu[7]>
The only way in Pil to parallelize is processes (fork, pipe)
corecheckno has joined #picolisp
<beneroth>
and (later) :)
<beneroth>
tankf33der, the picolisp way would be to make multiple worker processes, which get tasks via pipe (or database)
<abu[7]>
beneroth, T
<abu[7]>
(later) is a wrapper of 'pipe' though
<beneroth>
T
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
geri has joined #picolisp
<geri>
hey, did you change anything in json.l recently abu[7]
<geri>
? (packJson '("hello" "world"))
<geri>
-> "\"\"hello\"\": {\"world\"}"
<geri>
this now happens, broke one of my scripts
<geri>
did you change schema completely or smth?
<abu[7]>
Yes, 25.1.9 and 25.2.1
<geri>
hm
<abu[7]>
We discussed it here iirc
<geri>
didnt know you actually went with it
<geri>
alright
<abu[7]>
I thought you use your own?
<geri>
my music script used json.l the whole time
<geri>
switched to use mine though
<abu[7]>
But lib/json.l always used ieternal symbols for keys
<abu[7]>
That's more useful I think
<geri>
im just saying stuff that worked before now doesn't
<geri>
good thing i found the error at least xd
<abu[7]>
Yeah
<abu[7]>
We discussed with tankf33der. I don't remember well ... ;)
<abu[7]>
)
<abu[7]>
;)
<geri>
))
<geri>
at least got a reason to use my parser
<abu[7]>
But something was wrong
<abu[7]>
good
<tankf33der>
hi all
<tankf33der>
i remember details.
<abu[7]>
lib/json.l works for all my use cases
<abu[7]>
ah, ok?
<tankf33der>
abu just add feature and all tests passed.
<abu[7]>
hmm
<abu[7]>
yeah
<tankf33der>
i bet geri use it in wrong way.
<abu[7]>
it was buggy after the array markers were removed
<geri>
tankf33der: it worked before
<geri>
abu[7]: it seems you added array markers now?
<abu[7]>
yes
<abu[7]>
added back again
<abu[7]>
they were in pil64
<geri>
actually readJson reads [{"hello": "world"}] as (((hello . "world")))
<beneroth>
I don't understand the sense of it. If its a reasonable finite recursion, normal recursion is good enough. If its a unreasonable large or possibly infinite/looping recursion, or a context with stack space limits, then it should be a loop in the first place.
<abu[7]>
Exactly!!
<abu[7]>
Stupid feature
<bjorkintosh>
tsk tsk. Academic exercise.
<abu[7]>
Indeed. It is for people who cannot write a loop
<beneroth>
xD
<beneroth>
T
<bjorkintosh>
wait that's a slippery slope there.
<bjorkintosh>
FORTRAN is for people who can't write Assembly!!
<abu[7]>
But at I'm translating SICP, it gets tedious without
<bjorkintosh>
ah of course.
<abu[7]>
bjorkintosh, ok
<beneroth>
abu[7], why not translate into loops? :P
<abu[7]>
I did in the first chapter
<abu[7]>
but the flow changes too much
<abu[7]>
I'll try both in the future
<bjorkintosh>
abu[7]: I read that was the sort of thing asm programmers used to say about the new fangled FORTRAN programmers in the '50s
<bjorkintosh>
I bet they too got chastised by the plug board operators before automatic assembly ruined their lives in the early '50s
<abu[7]>
Right, I know
<bjorkintosh>
Original plug and play!
<abu[7]>
Quiche eaters
<bjorkintosh>
All of them!
<abu[7]>
:)
* bjorkintosh
smiles in uncompleted fpga projects.
<tankf33der>
abu: tco-tc looks promising. Will try to bench asap.
<abu[7]>
OK, thanks
<beneroth>
thanks tankf33der :D
<abu[7]>
It is about 50% faster than the recursive version
<abu[7]>
I removed the 'printsp's and did (bench (do 9999 (f 9999)))
<beneroth>
bjorkintosh, well the argument for FORTRAN over ASM is speed of development. Same for tail-call-optimization over manual looping, I guess, but with loss of some fine control.
<bjorkintosh>
always.
<beneroth>
Then again, the ASM devs probably say the same about using a high level language (loss of fine control)
<bjorkintosh>
it's a trade-off.
<beneroth>
T
<bjorkintosh>
and fortran (as well as lisp), were serious game changers for computational sciences.
<bjorkintosh>
underlying technologies that created the modern world.
<bjorkintosh>
sure, I get COBOL gets to play too.
<bjorkintosh>
*guess
<beneroth>
though my point would be, in the tail call optimization discussion: if recursion is problematic, then you're probably already in territory where you should apply more fine control, not less
<beneroth>
bjorkintosh, nah, no points for COBOL, it's an abomination compared to FORTRAN
<bjorkintosh>
beneroth: careful there. just imagine your payroll being processed by some ASM program known and understood by exactly one person and he/she/they retire on monday.
<beneroth>
what's the difference to todays situation in COBOL land?
<abu[7]>
Same happens in other langs too
<beneroth>
(also, I do my own manual payroll procession, so...)
<bjorkintosh>
beneroth: at least COBOL is readable and arguably machine independent.
<beneroth>
current COBOL situation is famous for A) COBOL devs are retiring B) the still-in-use COBOL code is a horrible spaghetti mess
<beneroth>
bjorkintosh, so is FORTRAN
<bjorkintosh>
yes.
<abu[7]>
Actuall, real tail call *elimination* is not possible in PicoLisp. What 'tc' does is returning and restarting a loop established by 'tco'
<abu[7]>
The 'f' function needs 61% of the time of the recursive version
<abu[7]>
And it does not run out of stack space :)
<abu[7]>
But in any case, a loop it still a *little* faster
<abu[7]>
5 % perhaps
<abu[7]>
The "mutual" case in the reference example actually cannot be expressed by a normal loop. Perhaps here 'tco' even makes sense!
<abu[7]>
Hehe, I'm crostposing :)
<abu[7]>
IRC, Matrix and Mastodon
<abu[7]>
fun ☺
<abu[7]>
... and mailing list, but that's too tedious
<abu[7]>
taleon, you know ;)
<taleon>
Yes, that's the disadvantage of using multiple channels. :-)
<abu[7]>
T
<taleon>
I didn't know there was also a Mastodon instance. Where can I find it?
<abu[7]>
It is a Mastodon "group": @picolisp@gup.pe
<abu[7]>
*Very* few members though
<taleon>
Thanks. I only use Mastodon irregularly and read-only, but I'll subscribe to the channel (or whatever it's called on Mostdon). ;-)
<abu[7]>
It is a kind of pseudo-group I think
<abu[7]>
Everybody following it gets the messages
<abu[7]>
And to write to it mention @picolisp@gup.pe in the toot
<abu[7]>
My ID is @Regenaxer@social.tchncs.de btw
<taleon>
503 Remote data could not be fetched
<abu[7]>
uh
<abu[7]>
in Mastodon?
<taleon>
When I search for @picolisp@gup.pe, I get the 503 error.
<taleon>
@Regenaxer@social.tchncs.de works
<abu[7]>
Searching for @picolisp@gup.pe yields nothing, but just @picolisp finds the group
<abu[7]>
I'm using the Web client in PilBox and "tut" in Termux
<taleon>
@picolisp is also not found. Probably because I'm on a different instance? I'll look into it tomorrow. My wife still wants to watch TV. :-)
<abu[7]>
👍
<geri>
abu[7]: oh hell yeah, we got tco now 🥳
<abu[7]>
Here the same :)
<abu[7]>
(watch TV I mean)
<abu[7]>
geri, yes, let's see if it has any use
<abu[7]>
off for toda
<abu[7]>
y
<abu[7]>
cu ☺/
<geri>
same, byebye
<abu[7]>
👍
geri has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
<tankf33der>
abu: checked my bench idea for tco for fibo.