<g-w1>
although it seems those items just include the first paragraph of the articles
paulgrmn has joined #zig
<motiejus>
g-w1: thanks! That gives full content on my reader though
<g-w1>
interesting, cool
<motiejus>
(the past post at leastnis full)
<motiejus>
At least is*
<g-w1>
your reader must fill in the articles as the rss feed does not contain the full articles
LewisGaul has joined #zig
<motiejus>
Indeed, interesting. And I couldn't find anything in the rss spec where it would implicitly download the articles from
<motiejus>
Looks like it's just fetching html from canonical source. Didn't know!
notzmv has quit [Ping timeout: 268 seconds]
notzmv has joined #zig
jokoon has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
earnestly has joined #zig
Anzh has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bitmapper has joined #zig
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
ifreund2 has joined #zig
ifreund has quit [Read error: Connection reset by peer]
jokoon has quit [Read error: Connection reset by peer]
ifreund2 is now known as ifreund
tnorth has quit [Ping timeout: 250 seconds]
notzmv has quit [Ping timeout: 265 seconds]
motiejus has left #zig ["User left"]
FireFox317 has joined #zig
leon-p has quit [Quit: leaving]
LewisGaul has quit [Quit: Connection closed]
leon-p has joined #zig
meinside has quit [Quit: Connection closed for inactivity]
aerona has joined #zig
cole-h has joined #zig
notzmv has joined #zig
<Nypsie>
andrewrk: Any chance you have some spare minutes today to have that chat you suggested around the wasm pr?
yyp has joined #zig
Akuli has joined #zig
<oats>
rbino, I just came across your fresh work on svdtozig, very nice stuff :D
* oats
can't wait to toy with zig on stm32
sundbp has quit [Remote host closed the connection]
notzmv has quit [Read error: Connection reset by peer]
sord937 has quit [Quit: sord937]
fcambus has joined #zig
<andrewrk>
Nypsie, sure thing
<txdv>
Whats next after redis? Compiling SerenityOS with Zig?
<Nypsie>
andrewrk, great! I'll start off with my thought process.
<Nypsie>
So, when I was implementing this, I found out that the string literal's codegen was being done after the function body (duh). I then realized to figure out the pointer to it (what's really just the offset into the wasm memory), I could utilize allocateDeclIndex to save/declare it somewhere so that during codegen of the pointer I could find the correct offset.
<Nypsie>
Calculating the length was needed so I'd know where the decl (the offset) of the array started inside the memory
<Nypsie>
Yesterday, and today I thought of maybe using the 'TextBlock' strategy that the other backends have to save the offset and perhaps the length? on the Decl itself, tho I'm not sure how memory efficient that is considering every decl will contain those values than. But this way we would avoid the need to do a linear lookup to find the offset as I did in `offset()`
<andrewrk>
I think it would be best to use the TextBlock strategy, the same as the other backends, because if that turns out to be problematic from a memory efficiency perspective, that would apply to all the backends, not just wasm
<andrewrk>
by taking the same strategy (if possible) it makes it easier to apply similar code changes to all the backends
<Nypsie>
Ok yeah that makes sense
<andrewrk>
I think it's ok, it turns out to be ~16 bytes per decl or something like that
<Nypsie>
Sounds good. I'll take that approach then. In regards to the 'length issue' how do other backends solve knowing the offsets? Or is it that each TextBlock has a set size?
<Nypsie>
I tried to read Link/elf.zig but I'm not completely understanding it yet
notzmv has joined #zig
<andrewrk>
Nypsie, it depends on whether the wasm format allows this, but what the other backends do is take an approach similar to ArrayList, but with file data. so it allocates some basic amount, with extra capacity to grow. when that capacity is exceeded, it changes the metadata to put the file data somewhere else, and allocates a bigger region
<ifreund>
inside the data section that approach should work fine
<andrewrk>
here we use copyRangeAll to efficiently copy file data from one place to another (with the copy_file_range syscall if possible)
<ifreund>
oh we can't do this on disk with the current wasm backend design direction, we hold everything in-memory and write the whole binary on flush()
<andrewrk>
that's fine too, the same technique will work, it will just be a memcpy then right?
<ifreund>
yep exactly
<andrewrk>
or rather it won't even require moving stuff around since it's not written yet
<ifreund>
indeed, you can just store a different pointer
<ifreund>
(and free the old memory)
<Nypsie>
Hmmm I see
<Nypsie>
I'll need some time to implement all those changes tho :)
<Nypsie>
Thanks both, both ifreund and andrewrk
<Nypsie>
Will get back to you once I'm finished or get stuck
<andrewrk>
Nypsie, thanks for the patch, looking forward to round 2!
<ifreund>
andrewrk: is c-backend codegen for struct stuff up for grabs? It seems like it might not be too bad
<ifreund>
well packed will be, but extern and normal can just use C structs
<andrewrk>
ifreund, yep go for it. did you see we already have a passing test tho?
<ifreund>
no I must have missed that among the other changes
<ifreund>
ah, separate commit. nice :)
<andrewrk>
I was thinking the same thing as you: when the target is the C backend, I think we should just make auto and extern struct layout the same
<andrewrk>
here is my wip diff if you want to see what might conflict https://clbin.com/o75BD
<andrewrk>
it's mainly about enums but I did make some fixes to structs, Type, Value
<ifreund>
andrewrk: don't worry about conflicts from me yet, I've got an exam tomorrow so starting work on this now would be irresponsible :D
<andrewrk>
impressive self discipline
<ifreund>
well, you can see that I'm currently totally distracted from studying...
mikdusan has quit [Quit: WeeChat 3.0.1]
<Nypsie>
Good luck on your exam :)
isolier6 has joined #zig
<ifreund>
thanks :)
isolier has quit [Ping timeout: 246 seconds]
isolier6 is now known as isolier
klltkr has joined #zig
<ifreund>
andrewrk: by the way, we would still be free to sort the fields by alignment for auto layout structs in the CBE which would give us a lot of the benefit without much pain
<ifreund>
that's an optimization for down the line though, no need for that feature yet
<andrewrk>
excellent point
notzmv has quit [Ping timeout: 252 seconds]
gazler_ has quit [Remote host closed the connection]
mikdusan has joined #zig
notzmv has joined #zig
notzmv has quit [Ping timeout: 246 seconds]
jeregrine has joined #zig
spyjetfayed has joined #zig
teratorn_ has joined #zig
teratorn has quit [Ping timeout: 240 seconds]
notzmv has joined #zig
teratorn_ is now known as teratorn
sm2n has quit [Read error: Connection reset by peer]
sm2n_ has joined #zig
sm2n_ is now known as sm2n
yyp has quit [Quit: now it's safe to turn off your computer]
<g-w1>
i have to load the file first before accessing it :)
<g-w1>
ohh, since i wasn't calling getSource, the source is never gotten :)
<g-w1>
🤦
<g-w1>
hmm, we need some way to re-load the src and re-parse the file i think
FireFox317 has quit [Ping timeout: 265 seconds]
notzmv has joined #zig
<ifreund>
that seems weird, we must have already done that work to get the error no?
<ifreund>
g-w1: also unload shouldn't deinit() the tree if there was an error afaik
<g-w1>
just took a small break. i think i kinda understand it (not sure if completely because i dont know must about the ast). we get a parse error -> ast is not complete -> report parse error -> try to access ast -> bad stuff because ast is incomplete
<ifreund>
why do we try and access the ast to report a parse error?
<ifreund>
this logic is in Module.getAstTree() by theway
<g-w1>
not sure, the stack trace can probably tell the most: https://paste.rs/icI
<ifreund>
g-w1: the fix is to not deinit() the tree on parse failure in getAstTree()
<ifreund>
and change the relevant logic to make sure it gets cleaned up after reporting the errors
<g-w1>
ahh tysm. i have something to do for ~1hr rn but when i get back ill try that.
<ifreund>
also, it looks like we only attempt to report the first parse error
<ifreund>
we should iterate on tree.errors and report all of them
<ifreund>
anyhow, I'm off to bed. Good luck with the fix
maximum_yellow has joined #zig
<maximum_yellow>
Hey all, i'm in the process of learning zig and a quick poke about the docs didn't reveal anything: are there any std functions like fold/reduce or specific versions any/all for [_]bool?
<maximum_yellow>
(i'm used the Haskell terminology, sorry if these names are confusing)
<maximum_yellow>
andrewrk: wow, thanks for the response! Naah, nothing that fancy, just the usual array processing stuff. It's not serious, easy enough to write, but i thought i'd check first
<andrewrk>
recommended to use regular ol' control flow for that
<andrewrk>
in general the language discourages you from inverting control flow
<maximum_yellow>
interesting. To be sure, i'm in a situation where i'd like to know whether say all entries in foo : []bool are true. If i understand correctly, by control flow you mean ``for (foo) |b| { if (!b) {result = false; break; } }'' stuff, right?
notzmv has quit [Ping timeout: 265 seconds]
<andrewrk>
yeah. you can do it pretty succiently though: const result = for (foo) |b| { if (!b) break false; } else true;
<andrewrk>
*succinctly
<maximum_yellow>
(perhaps there's some better way to implement this, i'm currently unsure whether for loops are expressions)
<maximum_yellow>
nice!
<maximum_yellow>
so they are expressions, that's really great. Thanks again andrewrk!
<andrewrk>
np, happy hacking
<maximum_yellow>
btw, as i'm sure you hear all the time, it's brilliant that you're hear hanging around to chat about zig. I saw a show & tell on Zig Showtime and you introduced yourself as ``not the boss, just some guy'' -- it's so cool to hear that and see this firsthand.