@ngn how is the second object from `p created with aCz(string) as input? or differently, how does prs() generates the second element of its returned list?

@JeromeIbanes the second element is the ast. i don't understand what you're asking about it - "how" in what sense?

the ast consists entirely of k objects. the parser uses recursive descent. there is no separate tokenization pass.

prs() generates the ast from the k-char list?

@JeromeIbanes yes

which call in prs() does that?

eso()?

@JeromeIbanes there are multiple functions responsible for parsing: pb() = parse body, pe() = parse expression, pt() = parse term, pw() = parse (skip) whitespace ..

ah thank you I'll check

@JeromeIbanes eso() sets the error source code and offset

pu() = parse unsigned int, pd() = double, pdu() = helper for parse double, pIL() = int/long list, pD() = double list, pC() = chars list (string literal), p0x() = same but in hex form, ps() = symbol, pS() = symbol list, lam() = create a partially filled in lambda object, po() = parse lambda

pT() = parse term followed by adverbs and/or square brackets, mon() = make a function monadic

i hope i got them right

I am passing a serialized object from an instance of libk to another: so I prs() it on the client, retrieve the ast, serialized it, pass it to the second instance of libk, deserialize it there, then have to do another prs(); then val() is there an easier way?

I could always just serialize the string from the first one, and pass the string though.

@JeromeIbanes serialization/deserialization is supposed to be just bytes:`@obj and obj:`?bytes

you shouldn't need to write c code for that or deal with ast-s

right, I've overcomplicated it slightly

the bugs in my serializer are a separate question :)

haha, yes sorry I opened a few lately, as a result of experimenting with networking

but more concerning are you able to repro the issue with ./t giving me, at times, but not always, failures?

@JeromeIbanes yes! that happens to me occasionally and i have no idea why

interesting

usually right after i run make

and then when i run the tests again, they are fine

yes, random

25% failure rate roughly

is this recent?

@JeromeIbanes no, it's always been like that

alignment issue?

but i get it much less than 25% of the times

how much ram do you have on your desktop?

@JeromeIbanes could be. but why would it fail only right after a build? i thought it might have something to do with flushing disk caches

@JeromeIbanes 8G

no, it fails if I call ./t multiple times, not necessarily after a make.

16G here

just did, failed after the 4th, I didn't compile it today

but you don't get the same issues from the k binary?

@JeromeIbanes hm, then it must be a refcounting bug of my own

meaning, is it confined to t?

I guess it must be, in that case it's not a huge deal.

@JeromeIbanes i mean, i must have messed up something in the core interpreter

@JeromeIbanes i've just observed it after 9 attempts

I guess we'll also need a t for libk.so

@JeromeIbanes i was going to suggest removing it :)

haha

@JeromeIbanes but as you're the only user, maybe i should remove the repl instead :)

keep only libk? :)

well, i'm half-joking

I think it's not a bad idea really

it would reduce the code quite a bit

@JeromeIbanes but nobody else would use it

yeah true

@JeromeIbanes regarding invalid hex literals - the original k doesn't validate them either

shouldn't oom though

but I'm not sure there's an easy way to avoid that

@JeromeIbanes serialization ooms - you're right about that one, validation would be good there

yes but how?

but it's a must if network is there though.

otherwise it's going to be quite trivial to crash the server

@JeromeIbanes by bloating x.c with all sorts of validity checks :)

@JeromeIbanes yeah :|

do you have plans for a server/client? I'm just dlopening libk.so in python's aiohttp honestly.

so I can use it at work

@JeromeIbanes i have no plans about anything, i just do whatever seems the most fun for the moment :)

haha that works

i had never heard of aiohttp

well if I can pass serialized strings to a "libk server" then maybe I shouldn't bother with ser() des() and aCz() on the client, and just cook my own ser() and des() without having to load libk on the client. I guess I can figure out most of the format, but could you identify the 'header" part?

that one is fairly obvious

that one less so

@JeromeIbanes i'd like to be able to change the format, though

ah good point

I can keep using likb's ser() and des() it's not really a problem for now

@JeromeIbanes the first byte there is the type, the rest is base-256 little-endian

perfect

maybe insert the length in there to prevent `? oom ?

@JeromeIbanes the length is inserted for lists

does it handle utf-8/16?

@JeromeIbanes k has no concept of utf, it treats it as a sequence of 8-bit chars (i.e. bytes)

works fine though

hehe

oh, you mean utf8 in identifiers? yes, i have that

very cool

anything beyond 0x7f is parsed as a single-character multibyte utf8 sequence and treated as an identifier

unfortunately this means non-latin alphabets can't form multichar identifiers

but who needs multichar identifiers anyway :)

heh

is the parser comparable to the apl implementation?

@JeromeIbanes apl is more complicated because the parser must do some analysis to figure out the grammatical categories (noun, verb, adverb, conjunction) of identifiers

right

or in dyalog terminology: to figure out the nameclasses (array, function, monadic operator, dyadic operator) of names

@ngn `k[x] is the not terminal-formatted version of a k expression?

let me guess ,that's probably what t is calling, thanks for exposing that