<hryx>
I think this is actually correctly parsing a lot of stuff already, but the tests still fail with error.MemoryLeakDetected
<hryx>
progress: +2,176 lines, 107x TODO, 52x error.NotImplemented
fsateler_ has joined #zig
fsateler has quit [Ping timeout: 255 seconds]
fsateler_ has quit [Quit: ZNC 1.7.2+deb1 - https://znc.in]
fsateler has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
<very-mediocre>
hryx: nice job
<very-mediocre>
i thought recursion was currently buggy, pending #1006
ofelas has quit [Quit: shutdown -h now]
ofelas has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 244 seconds]
wink_ has quit [Ping timeout: 255 seconds]
very-mediocre has quit [Ping timeout: 256 seconds]
ofelas has quit [Ping timeout: 246 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 255 seconds]
ManDeJan has quit [Ping timeout: 246 seconds]
ManDeJan has joined #zig
<tgschultz>
recursion works just fine, it just isn't safe since it can blow out the stack. That is the status-quo in pretty much every language. #1006 is about solving that.
Ichorio has quit [Ping timeout: 246 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 255 seconds]
fengb_ has joined #zig
slugm has quit [Remote host closed the connection]
ManDeJan has quit [Ping timeout: 255 seconds]
fengb_ has quit [Quit: Page closed]
fsateler has quit [Ping timeout: 244 seconds]
redj has joined #zig
very-mediocre has joined #zig
<very-mediocre>
tgschultz: ok, saw some issues months ago and iirc some were said to be fixable after a revamp of some kind for recursion, but apparently the bugs were just fixed in isolation instead
<very-mediocre>
i'm asking lots of questions lately, trying to get up to speed after many months of absence from zig
<tgschultz>
I think there are some issues with comptime recursive evaluation.
<tgschultz>
but it has been a while since I've abused comptime heavily enough to notice.
Jenz has joined #zig
halosghost has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 250 seconds]
jjido has joined #zig
Ichorio has joined #zig
glassofethanol has joined #zig
meheleventyone has joined #zig
Jenz has quit [Ping timeout: 245 seconds]
Akuli has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
glassofethanol has quit [Quit: Probs out playing Golf]
ltriant has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ltriant has quit [Ping timeout: 246 seconds]
Sahnvour has joined #zig
<tyler569>
what's the best way to diagnose cInclude issues? there's a symbol in a header I'm using that's not visible in zig, but I'm not sure how to approach figuring out why
Sahnvour has quit [Read error: Connection timed out]
Sahnvour has joined #zig
<tyler569>
for the record, it's an ioctl identifier, which are generated by some pretty gnarly macro invocations
jjido has joined #zig
wink_ has joined #zig
glassofethanol has joined #zig
glassofethanol has quit [Quit: leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
I'm going to do a live coding stream in 25 minutes from now, demo the milestone zig got to this week, some work on GeneralPurposeDebugAllocator, and then general Q&A about zig language
<shritesh>
andrewrk: I'm trying to implement a wasm32-javascript target that has first-class support for writing Zig / WASM inside a JS environment. Any thoughts?
<andrewrk>
it sounds like there is a very interesting use case there, is the idea that the target is inside a browser?
<shritesh>
If you think about it, JS can be viewed an operating system target. std.debug.warn would be console.log, etc.
<andrewrk>
DirectAllocator is `new Buffer()` (or is that a nodejs API?)
<shritesh>
Memory is tricky
<shritesh>
WASM doesn't have access to outside memory and we'd have to do the song and dance like my leftpad example
<shritesh>
But this can be automated if we export a .js header file
<andrewrk>
hmmm. that sounds a lot like an ABI
<andrewrk>
I think it would help to have some detailed use cases - e.g. an example project that would take advantage of this
<shritesh>
Yes it is. But it will be a sane bare-bones ABI that stays true to Zig. We don't have strings, but []u8 will map to Uint8Array
<andrewrk>
that would guide the design
<andrewrk>
btw I wasn't planning on demoing any wasm in this stream today - I would want more time to prepare some good examples
<shritesh>
Definitely. I'll do a "survey" of popular WASM projects / use cases out there and keep notes
<tyler569>
thanks andrew, I'll take a look at that issue
<shritesh>
Sure, let me complete the WASI std and we should be able to demo better things
<andrewrk>
tyler569, also, translate-c is in the middle of a transition during this release cycle, from its current C++ implementation to being implemented in zig code
<andrewrk>
I am hoping that the completed transition will make contributing to translate-c more attractive
<hryx>
andrewrk: just in case you know off the top of your head, do you know why I would be getting "error: MemeoryLeakDetected" in the new recursive parser? https://hastebin.com/raw/sewoyebika
<hryx>
Don't worry about it if it would take time to debug
<andrewrk>
I want to rewrite this in zig - even the browser-side!
<andrewrk>
hryx, you're using the existing test system unmodified yeah?
<hryx>
correct
<hryx>
though I've replaced `parse()` with `parse2()` (for now)
<andrewrk>
are you doing the arena strategy to free everything at once if there's an error?
<hryx>
I thought I was, but I must be missing something
<hryx>
let me see
<hryx>
I do have errdefer tree_arena.deinit();
<hryx>
just like in the original. But I'll take a closer look tonight
<andrewrk>
what that test system does is 1. run the test with an allocator that won't fail, and count the number of allocations. 2. re-run the test N times, each time with an allocator that fails on the Nth index.
<andrewrk>
during step 2 it makes sure that the number of bytes freed equals the number of bytes allocated. so it's basically testing every possible failure case
<hryx>
Oh wow, that's cool
<hryx>
That explains why when I add `tree.dump()` it prints multiple times
<andrewrk>
maybe there's an edge case where the new implementation messes up if the first or last allocation fails?
<shritesh>
I didn't consider this so it might be something like wasm32-js-browser and wasm32-js-node
<shritesh>
*but it might
<shritesh>
and -browser somehow knows about WebIDL
<hryx>
andrewrk: by "allocation fail" you mean that e.g. `try arena.create(X)` returns an error?
<andrewrk>
hryx, yes
<hryx>
cool, I'll keep that in mind tonight. thanks!
<andrewrk>
that should all be covered by your errdefer arena.deinit()
<andrewrk>
but it says freed bytes: 0? maybe you can figure out why nothing seems to be getting freed?
<hryx>
yeah the setup/teardown is so similar to the original that I can't see the problem
<hryx>
ok
<andrewrk>
(I hope that doesn't sound condescending- the ? at the end of my question is indicating that I'm brainstorming and don't have the answer)
<daurnimator>
Is there any plans around our buffer type? I was thinking about optimizing it for network apis (and other usage too I guess)
<daurnimator>
idea: buffer should be an array of page-size buffers (from DirectAllocator), so that you can use e.g. `vmsplice` => though the length should be adjustable (not only on page size: 4K vs huge pages); but also for usage with e.g. UDP packets and sendmmsg.
Akuli has quit [Quit: Leaving]
halosghost has quit [Quit: WeeChat 2.4]
ManDeJan has joined #zig
Sahnvour has quit [Read error: Connection reset by peer]