<fengb>
It won’t go away. It’ll just be a pain to use :P
<pixelherodev>
Argh - been working on an ESP8266 project. and there are SO MANY ways it would be better if I could write it in Zig :(
<pixelherodev>
Error unions alone would save me so much pain
<daurnimator>
pixelherodev: have you given llvm-xtensa a spin?
<pixelherodev>
Not worth the risk.
<fengb>
I hope Zig succeeds just to push error unions into the mainstream
<pixelherodev>
Yeah
<daurnimator>
fengb: I still want error values
<hryx>
ooh what's it about pixelherodev ? I'm excited to see/make embedded shiz done with zig in the future
<pixelherodev>
Without going into details, it's a medical project
<adamkowalski>
daurnimator how would you solve that problem without recursion?
<pixelherodev>
Again, without going into too much detail, there's an investor interested in it, so I can't afford to risk using an (AFAIK) unstable toolchain
<adamkowalski>
daurnimator: what are error values? would that allow us to add data to the error rather than just being a tag? I'm really missing that
<fengb>
daurnimator: do you mean errors with extra data? Or more like Rust/Haskell/ML style errors
<pixelherodev>
If all goes well, I can explain everything in ~2 months
<pixelherodev>
If it goes poorly, I can do the same because nobody will care anymore :P
<fengb>
pixelherodev: good luck!
<pixelherodev>
Yeah, thanks
<hryx>
sounds cool, also a perfect amount of mystique in your answer
<adamkowalski>
also tail recursion won't blow up the stack, I feel like that could be allowed. It's a fixed size usage
<pixelherodev>
I mean, I could probably spill the details without anyone caring, but at the same time I don't feel comfortable doing that even for something that's of relatively minor secrecy
<hryx>
no, don't ruin your comfort or the mystique
<fengb>
adamkowalski: there’s a proposal to mark functions tail recursive
<hryx>
but you should totally announce it when you can
<adamkowalski>
the compiler should be able to see that? Is that just to make it explicit?
<fengb>
Yeah it’s helpful as a personal check, especially if the compiler will reject non tail calls
<daurnimator>
e.g. I think AF_* constants should become non-exhaustive enums
<daurnimator>
*members of a non-exhaustive enum
<andrewrk>
flags remain the same though
<pixelherodev>
Huh
<daurnimator>
andrewrk: yep
<pixelherodev>
#2647 looks cool
<daurnimator>
pixelherodev: indeed. I hope andrewrk accepts it :)
<daurnimator>
probably with emekoi's suggestion in the comments
<daurnimator>
(with `union(error) {`)
dddddd has quit [Ping timeout: 258 seconds]
<adamkowalski>
we should think about creating a unified interface for errors and optional
<adamkowalski>
they are both monads, maybe we can have do notation like haskell and unify error, optional, async, etc
<adamkowalski>
also with optional I feel like we need something that allows us to convert it to an error so we can use try syntax
<adamkowalski>
if your function "needs" a key to exist in a hashmap to continue for example. the current if (optional) |value| {} else {} is a bit much
<daurnimator>
adamkowalski: ? I don't know how those would get unified.
<daurnimator>
adamkowalski: for optionals you already have `orelse` syntax
<daurnimator>
fengb: no reason I see
<fengb>
Saves a byte now with sentinels ;)
<adamkowalski>
daurnimator: they are both monoids, functors, applicatives, monads
<adamkowalski>
so you can have "map" which takes an optional and a function
<fengb>
I understand half those words
<adamkowalski>
if the value exists, call the function on the value and put it back in an optional
frmdstryr has quit [Ping timeout: 258 seconds]
<adamkowalski>
fengb pretty much it's just having map, and_then, or_else
<adamkowalski>
but in abstract algebra we use map, bind, apply
<adamkowalski>
try is syntax sugar for that right now
<adamkowalski>
we don't have a try equivalent for optionals though
<daurnimator>
I understood at least 2 of those additional words
<adamkowalski>
ah, alright i'll back up
<adamkowalski>
pretty much in haskell we have common "interfaces" (they call them type classes)
<adamkowalski>
just like in c++ there are iterators, containers, etc
<adamkowalski>
the most common in haskell are functors, applicatives, monads
<daurnimator>
adamkowalski: I think you're saying is that these `foo() catch |e| return e` `foo() orelse return something` should share a keyword?
<adamkowalski>
they provide a unified interface for accessing many common types
<daurnimator>
adamkowalski: already lost me there
<adamkowalski>
i'm saying that right now Zig uses many special purpose API's for each type
<adamkowalski>
we don't have overloading
<daurnimator>
by api do you mean syntax?
<adamkowalski>
we don't really deal with iterators uniformly
<adamkowalski>
arrays and slices are the only thing that can be accessed with []
<adamkowalski>
it makes it really hard to write generic code
<adamkowalski>
i'm proposing that we start finding the commonailities between types and have common apis to access them
<adamkowalski>
then just like people have "concepts" in c++, "traits" in rust, "type classes" in haskell, "interface" in ...
<daurnimator>
you're using such weird words to describe things here. they're not APIs... they're syntax.
<adamkowalski>
they are functions
<daurnimator>
they are explicitly *not* functions
<adamkowalski>
[] is just getting an index into something
<adamkowalski>
i'm building a tensor type
<adamkowalski>
I can't use that
<adamkowalski>
which is shame
<adamkowalski>
now I need to have my own .index method
<fengb>
[] maps to memory. It's intentionally not a function or interface
<adamkowalski>
we don't have good mechanisms for treating different types in a similar fashion is what i'm saying
<adamkowalski>
like if you want to write a sort function
<adamkowalski>
wouldn't it be nice to take anything which is random accessible, read and writable?
<daurnimator>
adamkowalski: no
<adamkowalski>
why?
<daurnimator>
because it changes how the function should be implemented
<adamkowalski>
does it though?
<daurnimator>
yes. if I write a function like that, I'm probably going to want to assume that elements are linear in memory
<adamkowalski>
if something is contigous in memory, has random access, and is mutable do I care if it's an array, slice, arraylist, or some other custom type that matches the interface
<daurnimator>
[] let me do that. if I was going via method... I can't make that assumption
<adamkowalski>
it's a precondition of your function
<fengb>
If it's contiguous, they can devolve into a slice
<daurnimator>
^
<daurnimator>
adamkowalski: note that we also have .at() supported by e.g. std.ArrayList which might be what you're after here?
<adamkowalski>
daurnimator: write that's my problem with it
<adamkowalski>
sometimes it's .at, sometimes it's []
<adamkowalski>
now if I want to write a function with something random accessible
<adamkowalski>
it's a pain
<adamkowalski>
I guess you can just only take in a slice and force everyone else to devolve to a slice
<adamkowalski>
but things like +, -, /, etc
<adamkowalski>
I wish we didn't have those
<adamkowalski>
because I can add matrices, but they don't share a syntax with numbers
<adamkowalski>
but why?
<adamkowalski>
my point is, striving to create a set of interfaces that every type adhers to allows for writing more generic code that is reusable
<fengb>
`broken LLVM module found: Instruction does not dominate all uses!`
<fengb>
Oh boy this guy again
<andrewrk>
argh I hate that error
<daurnimator>
so if I wanted to use TLS (SSL) from zig... what is my best option? and going further: what is our plan for using TLS (and HTTPS) in the standard library?
<andrewrk>
same as go. port a high quality tls impl to std lib, or directly implement it based on the RFC
<hryx>
andrewrk: as an everyday Go user, I'm relieved to hear that's your position. I think it's the responsible thing to do if we are gonna have networking in the stdlib :>
<andrewrk>
here you can kind of see how zig's async I/O mode competes with go
<andrewrk>
I mean, the perf is not competitive yet, but the paradigm is the same
<hryx>
I haven't! Are those things you worked on during live stream?
<hryx>
(still catching up on the streams - finishing zasm pt. 2 tonight, now that I'm home)
<andrewrk>
they're related to some of the stuff I did streaming, but no I coded these offline
<andrewrk>
kprotty has done some improvements to the std lib event loop since these measurements were taken and has some more work in progress, I believe
<hryx>
these look exciting. honestly I should study these examples pretty well because my mind hasn't 100% wrapped around Zig's async patterns. (It looks simple, I'm just not that experienced in some types of async programming)
<hryx>
I'm used to Go invisibly providing a scheduler at runtime
<andrewrk>
hryx, in summary you can think of `async` as the equvialent of "go" in go. it really is the same. the difference is zig has "await" to collect the return value of the function and go does not
<hryx>
that is far simpler than I has assumed
swoogan has quit [Ping timeout: 260 seconds]
<hryx>
andrewrk: just re-read #181 (const/var vs. let/mut). Is the reason it was reopened that const/var as they pertain to functions may not properly convey the right meaning?
mahmudov has quit [Remote host closed the connection]
<fengb>
I think I found a weird limit on how many blocks can be suspended
<daurnimator>
andrewrk: I think #3972 #3989 should be straightforward merges?
<daurnimator>
andrewrk: would you want to receive a refactor of std/debug.zig that moves things into format-specific methods and adds deinitialisers?
<daurnimator>
fengb: I'm suprised options isn't comptime known? I guess it doesn't have to be
<fengb>
I can work around the bug in this case but I'm sure I'll encounter it again soon
<hryx>
Multidimensional arrays with inferred inner array size a la `const x = [_][_]u8{ .... }` give "error: inferred array size invalid here". Is this intentional or should this be supported?
<daurnimator>
hryx: intentional I think; in as far as it falls out of zig's general rules
<hryx>
Looks like https://github.com/ziglang/zig/issues/2894 was sort of about this, but whether inferred inner array size should be supported wasn't directly addressed
<hryx>
daurnimator: whatchoo mean by general rules?
<daurnimator>
hryx: [_]T{ things_of_type_T}
<daurnimator>
`[_]T` isn't a valid type. hence [_][_]T is invalid
<traviss>
2.783s zig vs 2.532s c on my system for the best c solution :)
<traviss>
.. vector changes i mean. anyway. nice job guys.
<traviss>
there are a couple of hairy ptr/align casts in there. i was able to get a rough idea of how to translate them thanks to the new translate-c capabilities.
<hryx>
traviss: nice! side note, I can't get enough of those slim .{ literals } conforming to all kinds of structs/arrays/Vectors
<traviss>
yeah, it was super easy to change over from using [3]f64 to @Vector(3, f64). just change the type and all those literals worked.
_Vi has joined #zig
schme245 has joined #zig
jjido has joined #zig
schme245 has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 246 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
doublex has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schme245 has joined #zig
hpyc9 has quit [Ping timeout: 258 seconds]
schme245 has quit [Read error: Connection timed out]
return0e_ has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 265 seconds]
darithorn has quit [Quit: Leaving]
<gonz_>
I'm having an existential crisis. At some point I wrote a program, painstakingly in Haskell to solve a problem. I spent a day and change to optimize it down to giving a result in a reasonable time. The same program written naively, once, not a care in the world for optimization, runs in 1/48th of the time.
<gonz_>
In Zig, that is.
<gonz_>
None of this is really news, of course, Haskell is slower than zig... But it's just such a stark difference.
<gonz_>
Many man-decades have been put into `ghc` to make it do veritable magic to make Haskell go fast and it's indeed one of the faster slow languages... But it just can't compete even remotely on this level.
<gonz_>
I/O also wouldn't be able to bottleneck this; the Haskell version spends a bit more than 2 seconds doing this work on 9.5 kB of data. The I/O required isn't even meaningful here, except to the zig version.
<gonz_>
Haskell has other upsides, of course, but you start to wonder if it's productive to even go down that avenue at all at some point.
<companion_cube>
what kind of work does the program do?
marmotini_ has joined #zig
dingenskirchen1 has joined #zig
<bgiannan>
gonz_, performance is not always a requirement
dingenskirchen has quit [Ping timeout: 248 seconds]
dingenskirchen1 is now known as dingenskirchen
<gonz_>
bgiannan: Sure. I like Haskell in many ways and I think disregarding the parameter of performance it still has a real value proposition.
<gonz_>
companion_cube: Parses some data (~9.5 kB) into commands, executes those commands on a vector of 1 million elements.
<gonz_>
The commands can touch any range of values in the vector.
<companion_cube>
did you use a vector of unboxed types in Haskell? :D
marmotini_ has quit [Ping timeout: 260 seconds]
<gonz_>
I made several Haskell versions, one about as dirty as you can imagine that I remember performing better but I saw more runtime errors that day than I've seen since.
<gonz_>
That was using a mutable vector with only `unsafeX` functions
<companion_cube>
I'd be curious to see a rust version as well
<gonz_>
The most interesting thing about this IMO is that I spent so much less energy on the zig version, yet it outperforms it so handily. I imagine idiomatic rust would be the same; you'd just write it and it would perform well.
<companion_cube>
I think so too, yeah
<gonz_>
I imagine outsourcing the Haskell version to nastyness would yield whatever that code takes + FFI costs which wouldn't be too bad. But at that point you've definitely just resigned yourself to hard debugging and hard to work with code.
<companion_cube>
what kind of commands are these, btw? Set/Get?
<gonz_>
It's day 4 of the 2015 advent of code set
<gonz_>
day 6*
<companion_cube>
ah, there's an integer machine or something, right? I didn't have the motivation for AoC this year :(
<gonz_>
One part is a toggle of a vector of booleans, essentially
<gonz_>
Turn on/off, toggle
<companion_cube>
basically, a bitvector :D
<gonz_>
So addressing into the vector + changing the values
<gonz_>
The other part is dim/raise & raise by 2
<gonz_>
So a vector of ints, +1, -1, +2
<gonz_>
Again addressed the same way
_Vi has joined #zig
<gonz_>
I'm sure there are better ways to solve the problem itself and it's possible that this is just a pathological case for Haskell that needs to be solved with entirely unsafe tools, but at the same time it's not an unrealistic thing and the fact that it's expressible in an efficient way so easily with other languages isn't a positive for slower languages.
<gonz_>
I'm also leaving the door open for myself having expressed it badly in Haskell, but the main issue there in that case is that I'd used Haskell far more than I'd used zig when I created the respective solutions.
<companion_cube>
probably in Haskell you need to use the ST monad? and be careful to have everything eager and unboxed
<gonz_>
Right, but a `STVector` is just a type alias over `MVector` and yes, the end solution uses unboxed vectors
<gonz_>
Like I said, I do remember `MVector` improving the situation but also essentially ruining the maintainability of the code.
<companion_cube>
:D long live system languages
<companion_cube>
zig, rust, crystal, nim…
<gonz_>
But yes, fundamentally there will always exist a solution in Haskell that somehow gets to a competitive result, either by outsourcing a lot or using unnatural tools in the language.
<gonz_>
The internal crisis I have/had is mostly about how that feels so unnecessary in the end.
<gonz_>
On one hand I have an easy to use tool that gives me great performance when I write my naive solution. On the other, I have a tool that I love expressing myself in but requires me to do tons of work to get to a well performing result.
<gonz_>
Anyway, not to dwell too much on this...
<gonz_>
I just needed to vent and not hear "well no code is ever blocked on computation, we have such great hardware nowadays, SQL queries are always what you need to optimize", etc.
<companion_cube>
well if your goal is to solve problems, seems like the answer is clear :)
<companion_cube>
ahah as if everything was a website…
<gonz_>
Indeed. On the 6th I come back from my holidays to Elixir which is probably a few times slower than fast slow languages. :D
<gonz_>
I'm properly fired up now for a workout; BBL.
<companion_cube>
otoh elixir is pretty clean, innit?
<gonz_>
It makes for unmaintainable code beyond even a moderate linecount, IMO
<gonz_>
I hate it
<gonz_>
I owe a really good career to it, but as a language I hate it
<lupine>
heh
<lupine>
people keep suggesting we should rewrite a pile of stuff in it at work
<lupine>
so far, successfully resisted
<gonz_>
Unless those things are likewise dynamic messes, don't
<companion_cube>
yeah, dynamic types :(
<lupine>
*cough*ruby*cough*
<lupine>
I owe a really good career to it, but as a language I hate it
<gonz_>
:D
<companion_cube>
lupine: have you looked at crystal at all?
<lupine>
yeah, I despise it
<companion_cube>
ah well, it looks pretty cool to me
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
<lupine>
my dislike is highly irrational, so who knows maybe it's actuallygood
dingenskirchen1 is now known as dingenskirchen
<gonz_>
Crystal looks really good. Very funky FFI specs but that's a surface thing. It seems impressively fast and their standard library is vast for such a young project.
<gonz_>
If I was a Ruby user I'd probably want to use it.
<gonz_>
Likewise with Nim and all the other alternatives to scripting languages.
<gonz_>
Overall it's very impressive how much the balance between programmer convenience and performance has shifted so much with all these languages on the scene.
<gonz_>
People yell "Why one more language!?" every time someone makes a new one, but several of these newer ones have improved a lot on the general eco system of programming.
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
<mq32>
hey, i got a question on zig on windows
<mq32>
i want to link against an extern function from a dll, but i get this error message:
<mq32>
Build Dependencies...link: could not find .def file to build acknex
<mq32>
i have a small, handwritten acknex.def in my project root and import a single function like this:
return0e_ has quit [Remote host closed the connection]
frmdstryr has joined #zig
marmotini_ has joined #zig
Akuli has joined #zig
return0e_ has joined #zig
marmotini_ has quit [Read error: Connection reset by peer]
bheads has joined #zig
<fengb>
andrewrk maintains one for Zig. Lemme see if I can find it
dddddd has joined #zig
<fengb>
How do I create a frame for a generic function?
azth has joined #zig
waleee-cl has joined #zig
<via>
with the new translate-c stuff merged, i can now use libopencm3 directly from zig, thanks guys
<fengb>
🥳
protty has joined #zig
<via>
tryin to use @intToFloat on armv7 freestanding, getting 'lld: error: undefined symbol: __aeabi_ui2f', i'm guessing thats https://github.com/ziglang/zig/issues/1290?
<via>
eh, looks like its not actually doing hardfloat
<frmdstryr>
via: What hardware are you using?
<via>
stm32f405rg
<via>
m4 with fpu
<via>
exe.setTarget(builtin.Arch{.thumb = builtin.Arch.Arm32.v7em}, builtin.Os.freestanding, builtin.Abi.eabihf); -- though with c i have to pass some fpu flags, trying to figure out how to do that with zig build system
FireFox317 has joined #zig
<frmdstryr>
I think you pass them while building zig build -Dsome-flag
<fengb>
I don't need @asyncCall for comptime known generic methods right?
<fengb>
Because this looks pretty brutal >_>
<via>
FireFox317: passing -mllvm with -mcpu nor float-abi=hard seems to make a difference. i think i really need to speceify -mfpu, which -mllvm does not support
<via>
nor --march=cortex-m4f
_Vi has quit [Ping timeout: 246 seconds]
protty has quit [Remote host closed the connection]
adamkowalski has quit [Quit: leaving]
<FireFox317>
@via you can do `zig build-exe example.zig -mllvm --help` and it will show all the options you can provide
<via>
yeah, i saw that, but no ability to pass the fpu type
<via>
float-abi and mcpu/march don't seem to cause it to emit fp math
<FireFox317>
Hmm yeah, i don't know either :)
<via>
bummer. thanks though, i'll keep messing with it
<fengb>
Oh no, I just realized none of this async stuff will work with wasm :(
WendigoJaeger has joined #zig
BaroqueLarouche has joined #zig
dimenus has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
return0e_ has quit [Remote host closed the connection]
FireFox317 has quit [Remote host closed the connection]
mahmudov has joined #zig
schme245 has joined #zig
wjlroe has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
return0e_ has quit [Ping timeout: 268 seconds]
schme245 has quit [Ping timeout: 268 seconds]
WendigoJaeger has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<fengb>
andrewrk: I'm trying to debug "Instruction does not dominate all uses!". It seems like the @frameSize is erroneously generating the same value no matter what I do?
<fengb>
Maybe I'm not printing the right thing: `@sizeOf(@TypeOf(async testFmt(...)))`
<fengb>
Always returning 352. Having the wrong size would explain things because if I comment random things out, it'll start compiling
<mikdusan>
me and c++ ain't getting on so well right now. I'm spending 80/20 time dealing with cruft like header-vs-impl and .h ordering rather than problem domain
<andrewrk>
that's always a bummer
<companion_cube>
isn't it supposed to get modules soon?
<BaroqueLarouche>
"soon"
<fengb>
When were modules invented?
<companion_cube>
C++20, right?
<fengb>
I mean as the modern thing in languages
<BaroqueLarouche>
C++20 standard is supposed to be final early this year
<companion_cube>
fengb: at least as early as modula
<BaroqueLarouche>
but time will tell when all major will support them and be fast
<Snektron>
aren't modules pretty much DOA because of macros?
<Snektron>
C macros ruin everything
<fengb>
frmdstryr: seems like it doesn't like attaching an optional to a zero size `advanced_config: ?void = null,`
<fengb>
Or ?u0, they all fail
<Snektron>
andrewrk, another one of those tricks is empty base class compression
<Snektron>
it's used all over the stl because structures in C++ aren't allowed to be 0 bytes
<Snektron>
Theres an attribute in c++20 to fix it though
<Snektron>
kind of
<fengb>
You know how they say C++ is an octopus made by bolting on 4 legs to a dog? I think it's a centipede at this point
<Snektron>
Nothing beats sfinae though
<fengb>
I wonder how Zig will develop forward though. Backward compatibility at all cost?
<Snektron>
I hope not
<Snektron>
I think Rust handles it quite well by making different incompatible editions
<fengb>
Oh yeah I think I read about something similar
<Snektron>
Though i suppose you risk a Python 2/3 problem if its not handled well
<fengb>
Ruby does a pretty remarkable job providing decent compatibility while phasing out stuff
<Snektron>
Andrew mentioned wanting to be "done" with the language's semantics at some point
<Snektron>
I wonder if that's even possible
<fengb>
Well that's the fabled 1.0 release right? Forever perfect :P
<Snektron>
I doubt development stops after 1.0 though
<Snektron>
theres always more targets to add and more optimizations to make
<Snektron>
One thought i had regarding 2765 btw... it seems illogical to me that `const result = a(); return a;` can't be handled by the result location system by eliminating that local variable
<Snektron>
err, that should be `const result = a(); return result;`
frett27 has joined #zig
<fengb>
I think that's one of the follow up tasks the the original version
<fengb>
But I'm also a little concerned that you can easily break result location by adding an extra return anywhere. Maybe there should be a compile hint?
<Snektron>
I think you can probably make an even stronger guarantee, but that would probably be complicated to implement
<Snektron>
than just `return foo;` i mean
kristoff_it has joined #zig
mahmudov has quit [Read error: No route to host]
<Snektron>
ideally `var result = a(); result.b = 10; return result;` would also edit the result location in place
<fengb>
Maybe @resultLocation() returns the pointer
mahmudov has joined #zig
<fengb>
Then it behaves like normal code
<companion_cube>
what if async turns out to be a bad idea, post 1.0? :/
<Snektron>
Why would it only after 1.0 turn out to be async?
plumm has joined #zig
<frmdstryr>
fenbg: How would @resultLocation work with the example from mikdusan?
<plumm>
andrewrk: is there any way the 'cannot evaluate constant expression' message could be more verbose? I'd really like to know why some things don't work rather than they just dont
<companion_cube>
idk, it just seems like the most experimental part of zig to me
<companion_cube>
it's hard to get design entirely right :/
<fengb>
Ah... error unions and options are a sibling parent of this issue so... I don't know :P
<andrewrk>
plumm, yes there is a bunch of helpful context zig has that isn't in the error message
<kristoff_it>
hi all, I noticed that since about 2-3 weeks ago something changed in the way zig generates the documentation. Before the change I was able to generate the docs for my lib, while now they come out empty. Is there anything that I'm missing?
jjido has joined #zig
<andrewrk>
kristoff_it, sounds like a regression. generated docs are still pretty experimental
<andrewrk>
I'll make a note to look into this
<kristoff_it>
do you want me to open an issue?
<andrewrk>
yes if you want to be notified when it is fixed
<kristoff_it>
btw I think that the docs in the current state are already tremendously useful. I have a lot of comptime magic in my lib and I can see how in some places it's hard for the docs to know what to display, but even just being able to navigate the namespaces is great.
<kristoff_it>
More than anything the one thing I feel is missing are docstrings for structs, which the documentation doesn't render. I tried fiddling around with the JS but I couldn't get to the bottom of it. I see that the Node is present in the json data structure but it's not referenced back from the struct definition.
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
pmwhite13, your `_ = async handleEvent(event);` inside the for loop is using the same memory for each invocation
<kristoff_it>
pmwhite13: not an expert, so take my comment with a grain of salt, but I think you're mostly correct in the comment that you have at the bottom of that page: without inlining the for loop is just reusing the memory
dozn_ has joined #zig
<kristoff_it>
so either you allocate enough memory for all the frames upfront, or you use an allocator and allocate as-you-go
<pmwhite13>
reusing the same *stack* memory? Should I then use "call" builtin function with a new stack?
<andrewrk>
you provide the frame by the left-hand side of the `= async foo()`
<andrewrk>
by using `_` you provide an anonymous stack variable as the frame
<pmwhite13>
oh, gotcha, that's simple enough. I'll go try that.
<andrewrk>
but the lifetime of the anonymous stack variable ends at the end of the block in the for loop
<andrewrk>
the inline for loop is still problematic; it's an accident that it works
jjido has joined #zig
dozn__ has quit [Ping timeout: 260 seconds]
<andrewrk>
consider, when you async call a function, its frame is supplied by the callsite. and that frame must outlive the call
<andrewrk>
so if you async call handleEvent(), you need to make sure that the frame memory for handleEvent is valid until handleEvent returns
<andrewrk>
the simplest way to do this would be to use `await`
<andrewrk>
well, let me rephrase - one tool to do this is to use `await` because it makes the fn that awaits suspend until the frame is no longer needed
<kristoff_it>
do I remember correctly that you can't just straight create an array of Frames, set them (using `async foo()`) and then await them one by one?
<kristoff_it>
I think last time I tried that the program crashed immediately
<pmwhite13>
if I understand correctly then, any async functions called by `handleEvent` will be apart of the final stacksize of `handleEvent`
<daurnimator>
traviss: you should just be able to assign an array to a vector
<pmwhite13>
ahh, just tried allocating the frame and then just leaking it after the iteration so that it lasts forever. worked!
<pmwhite13>
I had tried to do something similar by allocating and then copying the frame into the allocated memory, but then I saw that frames are not movable. However, saving directly into the dynamic memory is not moving.
<andrewrk>
pmwhite13, yes if you call an async function as a normal function, then the caller becomes an async function, and uses an anonymous variable in its frame, for the callee's frame
vexu has quit [Quit: WeeChat 2.7]
<andrewrk>
kristoff_it, array of frames should work fine
<plumm>
lukeholder: what zig version are you using?
<lukeholder>
➜ zig version
<lukeholder>
0.5.0
<plumm>
im on 0.5.0+f40b6b85f and that format + compiles + runs fine
<plumm>
oh, you can't use anonymous struct syntax with 0.5.0, thats a trunk/master thing
<fengb>
lukeholder: need to update to master zig build
<andrewrk>
lukeholder, there's a 0.5.0 version of the docs to match that compiler version
<fengb>
daurnimator: ah yes!
<andrewrk>
unfortunately zig is still so unstable, that it makes sense to use master branch
<lukeholder>
andrewrk: ah yeah was pasting the master docs
<lukeholder>
thanks
<fengb>
Unfortunately, your language has: [x] comprehensible syntax
<lukeholder>
ha
<lukeholder>
Actually just working for the docs from a UX point of view
<lukeholder>
working *through
schme245 has joined #zig
<schme245>
any way to get `zig build` to output everything on separate lines?
<daurnimator>
schme245: hmm? zig build doesn't really have much output normally
<schme245>
oh, I guess the actual output is coming from `zig test`
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<schme245>
daurnimator: ^
<kristoff_it>
andrewrk: I'm pretty sure it caused a crash in one of my programs, but I can't test it again because now I'm tripping a compiler assertion when cross-compiling for linux
<daurnimator>
schme245: silly hack: pipe zig test output through `cat`
<daurnimator>
schme245: it uses `isatty` to know if it should use newlines or not
<daurnimator>
schme245: in general that type of output occurs when a CI system lies about supporting a certain set of terminal escape codes...... cause most of them lie and say they're xterm
<daurnimator>
piping through `cat` will make `isatty` fail
<schme245>
soehh... do I want it to be tty or not? :D to get newlines
<schme245>
as you can tell, my knowledge of shells is limited
mahmudov has quit [Read error: Connection reset by peer]
<daurnimator>
schme245: you want it to not be a tty
<kristoff_it>
schme245: daurnimator: the command should look like this I think: `2>&1 zig build test | cat`
<schme245>
get the same result when piping to cat
<schme245>
is the output coming through stdout or stderr?
<kristoff_it>
you need the first part because you first need to redirect stderr to stdout
mahmudov has joined #zig
<schme245>
ahh, this one did the trick!
<schme245>
zig build 2>&1 >/dev/null | cat
<schme245>
oh snap missed your message kristoff_it, sorry!
<daurnimator>
use `zig build |& cat` instead
<kristoff_it>
np, glad you got it working :)
<kristoff_it>
daurnimator: wow that's a trick I didn't know about
<schme245>
that's slick
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
frett27 has quit [Ping timeout: 252 seconds]
mahmudov has quit [Remote host closed the connection]
kristoff_it has quit [Remote host closed the connection]