<halosghost>
daurnimator: I listed it in prior-art for #2634 :)
<daurnimator>
emekankurumeh[m]: the question was targetting mingw; not zig itself
<emekankurumeh[m]>
that works fine too
<daurnimator>
emekankurumeh[m]: in that case: how do you do it? do you have an example anywhere?
<emekankurumeh[m]>
the target is "<arch>-windows-gnu"
<daurnimator>
emekankurumeh[m]: can you mention that in the issue?
<daurnimator>
emekankurumeh[m]: I assume you need to set up a libc file as well?
<emekankurumeh[m]>
I did the work to get linking to libc to work on mingw-w64
<emekankurumeh[m]>
<daurnimator "emekankurumeh: in that case: how"> zig invokes the compiler defined by the env variable CC and uses that to find the necessary libraries
<emekankurumeh[m]>
export CC=`which gcc` is what I do and linking with libc works fine
<daurnimator>
emekankurumeh[m]: huh okay. I thought you'd have to use --libc
<daurnimator>
emekankurumeh[m]: in any case: can you comment on that issue with all this info? :)
marmotini_ has joined #zig
lunamn has quit [Ping timeout: 258 seconds]
lunamn has joined #zig
mrkishi has quit [Ping timeout: 252 seconds]
halosghost has quit [Quit: WeeChat 2.5-rc1]
marmotini_ has quit [Ping timeout: 272 seconds]
st4ll1 has quit [Ping timeout: 248 seconds]
marmotini_ has joined #zig
<scientes>
what about using clang to implement the C ABI, so that zig is more easily ported?
<scientes>
and having it link against libclang
<scientes>
that might be a really bad idea however
Wolf480pl has left #zig ["Leaving"]
avoidr has joined #zig
jmp_0 has quit [Ping timeout: 256 seconds]
jjido has joined #zig
avoidr has quit [Quit: leaving]
marmotini_ has quit [Ping timeout: 258 seconds]
<SamTebbs33>
Has a workaround for the mac azure issue been made or is it still unstable?
jjido has quit [Quit: Connection closed for inactivity]
marmotini_ has joined #zig
knebulae has quit [Read error: Connection reset by peer]
allan0 has quit [Ping timeout: 272 seconds]
mrkishi has joined #zig
allan0 has joined #zig
st4ll1 has joined #zig
jjido has joined #zig
st4ll1 has quit [Ping timeout: 252 seconds]
alexander92 has joined #zig
jmp_0 has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
marmotini_ has joined #zig
jmp_0 has left #zig [#zig]
marmotini_ has quit [Ping timeout: 272 seconds]
halosghost has joined #zig
knebulae has joined #zig
marijnfs_ has quit [Quit: WeeChat 2.4]
<BitPuffin>
can I pass a comptime known size array to a procedure that takes a slice?
<BitPuffin>
I guess I can do arr[0..arr.len]
<BitPuffin>
it can be a bit verbose though
<shritesh>
BitPuffin: arr[0..]
<BitPuffin>
oof
<BitPuffin>
amazing
alexander92 has quit [Ping timeout: 258 seconds]
I_Right_I has joined #zig
Pwipwi has joined #zig
marmotini_ has joined #zig
Pwipwi has quit [Quit: Page closed]
husho has joined #zig
jjido has quit [Quit: Connection closed for inactivity]
SamTebbs33 is now known as samtebbs33
<tgschultz>
BitPuffin also: &arr
<tgschultz>
the compiler knows to turn that into a slice
Akuli has joined #zig
wilsonk has joined #zig
wilsonk|2 has quit [Ping timeout: 248 seconds]
avoidr has joined #zig
wilsonk|2 has joined #zig
samtebbs33 has quit [Quit: leaving]
wilsonk has quit [Ping timeout: 245 seconds]
marmotini_ has quit [Ping timeout: 248 seconds]
Ichorio has joined #zig
<BitPuffin>
tgschultz: that's even more pleasant maybe
<BitPuffin>
But maybe the other one shows intent better
<halosghost>
tgschultz: did you have a chance to take a look at the new issue? if so, is there anything you think I should change in the description right away?
merlyndmg has quit [Read error: Connection reset by peer]
<tgschultz>
No, it looks fine. I have some concerns with the concept itself that I'll post, because if we're going to do this those things will need to be discussed.
<tgschultz>
Actually, i guess one thing you could do before I do that is more clearly state the use case for this. Specifically, why it needs to be so quick and easy to change from SoA to AoS.
<halosghost>
hm
<halosghost>
the way I would likely phrase that would be, “this is a common performance optimization path, so allowing for it to be a simpler transition rather than an extensive refactor can be a big win”
<halosghost>
is that a reasonable explanation, or are you expecting more? and if so, what?
<I_Right_I>
Hey is there any ide that support syntax highlighting for zig?
<shritesh>
VSCode, Sublime, Vim. They might not be IDE enough though.
Sahnvour has joined #zig
<I_Right_I>
I see alot of linux devs like Vim, I never broke down and spent the time to learn it.
<I_Right_I>
Maybe I will give it a try.
<tgschultz>
halosghost: well, from my perspective it hides a lot of behind-the-scenes behavior. Take for example how pointers to SoA elements would have to work. I just think we need pretty good justification for that. There are a lot of features zig doesn't have that could make certain usecases easier, but we don't plan to, so why this one?
<shritesh>
I_Right_I: give VSCode a try too if you haven’t already. It’s such a good experience out of the box.
<I_Right_I>
shritesh: I have used VSCode and I haven't given Microsoft kudos for much but I have to hand it to them there....
<halosghost>
tgschultz: that's fair; though, if something like index-stride were implemented as the solution, it might solve the problem more generally only hiding a bit of behavior
<halosghost>
(which is why I posed the issue as a discussion, RFP rather than a “here's what I think we should do” since I don't really have a solid answer for it yet) :)
Akuli has quit [Quit: Leaving]
<andrewrk>
oh good, my macos CI fix worked
<andrewrk>
copy elision is coming along brilliantly. everything is fitting into place
* shritesh
is excited
<andrewrk>
this is part 1 of 3 of The Copy Elision Plan
<andrewrk>
only part 1 is needed to proceed with the coroutine rewrite
<andrewrk>
which I plan to do before parts 2 and 3 of copy eliding stuff
<andrewrk>
I think also only part 1 is needed for the "fixed fields" thing
<halosghost>
:D
fengb has quit [Ping timeout: 256 seconds]
<andrewrk>
I'm thinking of calling them something other than "coroutines"
<andrewrk>
when people hear that word they think of "light threads" with stacks, but they're actually stackless, which confuses people
<mikdusan>
what's the best PR to look over for what "coroutines" is to become?
<scientes>
a big problem with stackless co-routines is that the C ABI often requires passing on the stack, and it differs by arch, so you kinda would want to be able to specify the arches you want to support and have the compiler check for you
st4ll1 has joined #zig
<andrewrk>
there's still *a* stack, it's just that there is only one (per thread)
<scientes>
oh, well in that case
<andrewrk>
calling a stackless coroutine is a `call` instruction; suspending from one is a `ret` instruction. the only difference is that all the local variables are in a struct passed in as a pointer in a secret first parameter
<scientes>
if you kept the stack pointer and the frame pointer seperate you could probably even just interleave the stacks
<scientes>
but that would require some more thought
<tgschultz>
so it's a state machine
<scientes>
tgschultz, but much easier to read/understand
<andrewrk>
yes, it's syntactic sugar (a lot of it) for a state machine
<andrewrk>
let me rephrase that, it's a state machine that the language is aware of the semantics of in a few key ways
<scientes>
you are also arranging the states, instead of having them in a flat namespace
<tgschultz>
I just finished writing a bunch of state machines for the redo of my BMP lib. It will be interesting to compare before/after rewriting with "coroutines"
<tgschultz>
maybe we should just call them stateroutines or something.
<andrewrk>
I'd be fine with making up a new word
<andrewrk>
saves me half the trouble of getting someone to forget what they already know to explain how it actually works
<andrewrk>
you can see how this is related to generators now
<tgschultz>
there is a lot of unlreaning to do when learning to write zig well, I think.
<andrewrk>
I wonder if that is a negative, neutral, or positive thing
<tgschultz>
*unlearning, obviously
<mikdusan>
call them `zigzags`
<tgschultz>
positive, in my opinon, because they're mostly the product of working with limitations that don't exist anymore
<I_Right_I>
I think it boast well of the simplicity of zig - In Rust nor C do I believe optimization and simplicity go hand in hand.
<I_Right_I>
Oh! I am very impressed zig and what you folks have done.
<I_Right_I>
* impressed with zig
<mikdusan>
in PR #2377 is `@Frame(...)` intended only for state-storage type of continuaions (i hope i worded that correctly), or potentially other things in the future?
<mikdusan>
oh i see about futures.
<andrewrk>
if you wanted to store something else there one would make it a local variable to the function
<andrewrk>
whether or not you could "reach into" the local vars is under consideration
<andrewrk>
that would be one way to have generators
<mikdusan>
does it make sense to model a continuation function as a merge of fn and struct, and use struct-field syntax for anything you might want to reach; that takes care of differentiating between locals and reachables
<scientes>
yeah i wanted to be able to use global in other files too
<scientes>
hadn't checked if I could do that yet
ijneb has joined #zig
halosghost has quit [Quit: WeeChat 2.4]
<squeek502>
andrewrk, still planning on streaming today?
<andrewrk>
squeek502, yeah, any stream topic suggestions? :)
<tgschultz>
it would be interesting to be able to access a function's local vars like it were a struct. take for instance the old comptime dsl parser idea: https://github.com/ziglang/zig/issues/871#issuecomment-377794182. only instead of passing in the variables and `[0]` `[1]` etc you could just use the actual variable names in the string and pass a reference to your stack frame, then the parser could access those variables using @field.
<tgschultz>
Interesting, but the kind of thing that probably shouldn't exist.
<andrewrk>
note that generators are merely a "blessed" way of doing this
<squeek502>
i did a bit more on the lua in the browser stuff, used placeholder fns for the io stuff in javascript, wasnt sure how to provide a malloc, and ran into an issue i havent debugged with lua functions not being exported (like luaopen_package), not sure if that would be a good starting point for another stream on that
<squeek502>
havent pushed my changes anywhere yet, can do that if you want to take a look
<andrewrk>
that might be neat - I think I would want to prepare a little more first for that one though
<andrewrk>
hmm, maybe I'll pick a neglected issue on the issue tracker
<andrewrk>
oh, I think it's time to make more progress on the debug allocator
<squeek502>
last thing on the debug allocator was almost completely rethinking how it works iirc
<squeek502>
for double free detection
<I_Right_I>
andrewrk: Have you ever used Raylib for game development?
<fengb>
squeek502: I've been working on a wasm "friendly" allocator. It's not actually been tested very thoroughly (or at all really...) but providing malloc/realloc/free is a main goal