<ifreund>
I've been planning on reformatting my hard drive so I can use zfsbootmenu at some point when I have a free day and don't feel like programming
<ifreund>
I'll definitely get a void-musl install going when I do
_whitelogger has joined #zig
cole-h has joined #zig
earnestly has quit [Ping timeout: 258 seconds]
Enrico204 has left #zig [#zig]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
hf69 has joined #zig
<hf69>
q
hf69 has quit [Quit: WeeChat 3.0]
hf69 has joined #zig
hf69 has quit [Quit: WeeChat 3.0]
hf69 has joined #zig
hlolli_ has joined #zig
jicksaw has quit [Quit: ZNC is kill]
hlolli__ has quit [Ping timeout: 260 seconds]
jicksaw has joined #zig
hf69 has quit [Quit: WeeChat 3.0]
xackus_ has joined #zig
hf69 has joined #zig
hf69 has quit [Client Quit]
hf69 has joined #zig
seadragon-droid has joined #zig
ur5us has joined #zig
xackus has joined #zig
xackus_ has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
spiderstew_ has joined #zig
spiderstew has quit [Ping timeout: 260 seconds]
radgeRayden has joined #zig
a92 has quit [Quit: My presence will now cease]
lucid_0x80 has joined #zig
sdixon has quit [Ping timeout: 258 seconds]
ur5us has quit [Ping timeout: 260 seconds]
notzmv has quit [Remote host closed the connection]
sord937 has joined #zig
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
a_chou has joined #zig
seadragon-droid has quit [Quit: -a- Connection Timed Out]
seadragon-droid has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
a_chou has quit [Remote host closed the connection]
marnix has joined #zig
copy has quit [Ping timeout: 264 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
cole-h has quit [Ping timeout: 265 seconds]
radgeRayden has quit [Remote host closed the connection]
Alloc has joined #zig
nyaayaya has quit [Remote host closed the connection]
koakuma has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
<Alloc>
Hello I'm attracted to Zig by wondrous idea of first-class type, and learning Zig.
<Alloc>
I want to write a function that takes Reader interface and will do something likes this: fn thing(r: /* a type that enforces Reader interface */, arg: u32) !u32 { ... }
<Alloc>
I don't know what the type of r should be. is anytype and duck typing sufficient?
marnix has quit [Read error: Connection reset by peer]
<daurnimator>
yes
leon-p has quit [Quit: leaving]
viashimo has quit [Ping timeout: 246 seconds]
Alloc has quit [Remote host closed the connection]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<koakuma>
Hi. I'm having what appears to be an endianness issue in comptime-executed code
<koakuma>
On sparc64, comptime(std.math.absFloat(-10-05)) returns -10.049 (or 0xC120CC4D in hex)
<koakuma>
(Correct one should be 0x4120CCCD)
<koakuma>
I've tracked it down to ir_eval_const_value but still can't wrap my head around the interpreter code
<koakuma>
Anyone can help me around these parts? Especially on how/where does function arguments get passed and where does the actual interpretation takes place
<koakuma>
Thanks
spiderstew_ has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
spiderstew has joined #zig
<daurnimator>
koakuma: I remember a similar bug report; are t you running latest?
<daurnimator>
oh that was you
squeek502 has joined #zig
earnestly has joined #zig
<koakuma>
Yeah
<koakuma>
That one was about float parsing, which has been fixed
<koakuma>
This one is about comptime-execution of float values
<koakuma>
(Or rather, bitops? I peeked at the code for absFloat and it seems to be implemented in terms of bitops)
<daurnimator>
koakuma: that does seem to be true.
<daurnimator>
koakuma: I assume you can replicate the failure by running `zig test lib/std/math/fabs.zig` ?
<koakuma>
Yes, that's how I found out about the
<koakuma>
*this
hlolli__ has joined #zig
hlolli_ has quit [Ping timeout: 272 seconds]
dumenci has joined #zig
lucid_0x80 has quit [Ping timeout: 265 seconds]
<koakuma>
Oh, I think I found it - seems like @bitCast returns swapped values on BE machines?
<koakuma>
Where does it get impemented? I didn't manage to find the definition of it when grepping
marnix has joined #zig
<semarie>
koakuma: your problem with comptime is with zig running on LE machine (crosscompile to BE) or BE machine (native compilation or cross BE to BE) ?
<semarie>
(with BE=big endian / LE=little endian)
<koakuma>
Native BE
<koakuma>
Or more precisely, building for sparc64 on sparc64
<semarie>
regarding @bitCast, if I didn't mess myself, it is implemented with BuiltinFnIdBitCast (in src/stage1/ir.cpp line 7141)
TheLemonMan has joined #zig
<TheLemonMan>
koakuma, ir_analyze_bit_cast
<TheLemonMan>
the main suspects are buf_read_value_bytes and buf_write_value_bytes
<TheLemonMan>
hey semarie, mind trying #7411 on openbsd when you have some time?
<semarie>
TheLemonMan: I am testing
<TheLemonMan>
thank you, that patch already uncovered a nasty error somewhere deep down qemu
<semarie>
hum. sa_flags in struct sigaction is expected to be c_int (and not c_uint) on openbsd
<TheLemonMan>
yeah, on linux too but I prefer an unsigned int there
<TheLemonMan>
some flags are like 1<<31 and that's awful
xackus has quit [Remote host closed the connection]
<semarie>
here, I am not understanding. it isn't a matter of preference, but correctness. it could introduce subtile errors
xackus has joined #zig
<TheLemonMan>
...like?
<daurnimator>
oh wow; that feeling when I name something the exact same as something that already exists; and with the same implementation
<TheLemonMan>
size and alignment are the same, that's all I care for
<TheLemonMan>
daurnimator, plot twist, you wrote that
<daurnimator>
I had to double check... it was tdeo
<TheLemonMan>
plot twist, you _are_ tdeo
koakuma has quit [Ping timeout: 258 seconds]
koakuma has joined #zig
<protheory8-new-m>
Do I actually have to await all launched async functions or is it optional to do that?
<ikskuh>
protheory8-new-m: you are not forced to do anything, but note that if you don't await, you don't have a guarantee that all defers are being run and the resources are cleaned up
<protheory8-new-m>
ikskuh: I was asking that because Zig documentation says this: "In the same way that every suspend has a matching resume, every async has a matching await. "
<ikskuh>
you are not forced to do that
<ikskuh>
if you can guarantee that all defers were run, you can also just abandon your frame
<daurnimator>
though I assume that would be rare: your frame would normally be allocated somewhere, and you'll need to free it...
<protheory8-new-m>
Wouldn't the fact that async function frames run out of the scope and deallocate cause problems?
<daurnimator>
at least, you should :P
<protheory8-new-m>
daurnimator: The frame is in stack
<koakuma>
semarie & TheLemonMan: thanks for the pointer
<koakuma>
Also is there a way to force the compiler to disable caching?
<koakuma>
The help message doesn't seem to say anything about it
<TheLemonMan>
koakuma, sadly there's no way :( it's a pita when you're working on the compiler
<TheLemonMan>
semarie, you can send a PR to my repo, if you set the correct base branch it'll appear in that PR
wootehfoot has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<koakuma>
So from my reading it's that buf_write_value_bytes reads a ZigValue's contents into a buffer, which is then written again to a differently-typed ZigValue by buf_read_value_bytes?
<koakuma>
And guessing from the amount of is_big_endian flags, that buffer is supposed to be ordered as LE?
<koakuma>
Is there a reason for that? I feel like I'm missing something here; if it really just copying values around all the byteflipping seems unnecessary
protheory8-new-m has quit [Ping timeout: 260 seconds]
protheory8-new-m has joined #zig
bfredl has quit [Ping timeout: 260 seconds]
<koakuma>
OMG this is nasty
<koakuma>
buf_write_value_bytes calls float_write_ieee597 which will write into the buffer in LE
<koakuma>
But buf_read_value_bytes calls bigint_read_twos_complement which requires the buffer to be in... system endianness
<koakuma>
Yeah I think that's the root cause
<ifreund>
that does sound ugly :D
Tharro has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in]
Tharro has joined #zig
bfredl has joined #zig
hlolli__ has quit [Ping timeout: 256 seconds]
cren has joined #zig
waleee-cl has joined #zig
kenran has joined #zig
hlolli__ has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
koakuma has quit [Quit: Leaving.]
TheLemonMan has joined #zig
<TheLemonMan>
ifreund, ping
<ifreund>
o7
seadragon-droid has quit [Read error: No route to host]
seadragon-droid has joined #zig
seadragon-droid has quit [Read error: Connection reset by peer]
hf69 has left #zig ["WeeChat 3.0"]
hf69 has joined #zig
hlolli_ has joined #zig
hlolli__ has quit [Remote host closed the connection]
<andrewrk>
I believe this will go a long way towards making comptime semantics understandable and the implementation robust
dsmcfarl has quit [Remote host closed the connection]
<hexaflex>
Hello folks. I am very new to the language, so forgive me if this is silly. But the following program is giving me a bit of a headache. The comment at ythe top should explain what is meant to happen. https://gist.github.com/hexaflex/161d3a3559f8ae30b47e283df6262230
<ifreund>
hexaflex: I think you might be interested in std.meta.trait
<ifreund>
it does what you are trying to implement as far as I can tell
<hexaflex>
I'll check that out. thanks
<ifreund>
no problem, the test cases in that file serve as pretty good examples of what the API does
a_chou has joined #zig
<andrewrk>
I think trying to constrain generic types is a trap that new zig programmers fall into
<andrewrk>
rust is great at constraining generic types, you might like it better
<andrewrk>
for zig we rely on duck typing for generic types
<andrewrk>
I personally never use std.meta.trait
dominikh has quit [Ping timeout: 258 seconds]
<ifreund>
I haven't used it personally either, I just avoid anytype wherever possible and let comptime duck typing do its think when anytype can't be avoided
a_chou has quit [Remote host closed the connection]
<TheLemonMan>
hexaflex, your code is triggering a compiler bug, yay
<hexaflex>
that would explain things
<hexaflex>
Is this something I should file a bug report for?
<TheLemonMan>
andrewrk, yeah, I guess that's not something we want in stage1
<TheLemonMan>
hexaflex, yes
<hexaflex>
alright
<andrewrk>
TheLemonMan, it could potentially simplify things and help with memory usage, but since it's an additional restriction it's not strictly necessary to implement
<marler8997>
I have an idea that might solve (or at least help) the problem of not using type constraints but still getting good error messages
<andrewrk>
what's that?
<marler8997>
a change to the compiler that can backtrace compilation errors to the signature of generic functions and reason about whether the error could be with the type passed in by the caller
<marler8997>
the only unsolved part about it is that I'm not sure how the compiler could tell if it's a problem with the generic type passed in, or with the code using it...the compiler could report both issues though
<andrewrk>
that sounds really sophisticated
<marler8997>
basically, if (compile_error) ... if (inside_generic_function) ... if (error_involves_anytype_parameter) report_compile_error_and_generic_type_error
<marler8997>
This is the exact same problem that C++ concepts solves, alot of complexity introduced just to create sane error messages
<marler8997>
maybe a good enough solution would just be to add a compile error "NOTE" about the generic type whenever one is involved
<TheLemonMan>
I really liked the anytype(predicate) idea
<marler8997>
that solution has the problem that the predicate needs to be kept in sync with the implementation
<marler8997>
which isn't a huge problem, but there may be a solution that works just as well that doesn't have that problem
<marler8997>
and the anytype(predicate) idea is possible today with a wrapper function
dominikh has joined #zig
<torque>
what do you mean by "kept in sync"?
<torque>
I was under the understanding that the type predicate stuff was basically just syntactic sugar for doing the ducktype conformance checking at the top of the function
<ifreund>
say your function takes any type with foo and bar methods. then say you modify the function to only require the bar method
<ifreund>
you now need to update your type verifier to sync with the implementation
<marler8997>
^
<torque>
so the difference is that refactoring isn't purely local in some cases
dumenci has quit [Ping timeout: 265 seconds]
<marler8997>
the problem is that you're adding code whose sole purpose is to provide better error messages, that code needs to be maintained just like all other code. So if we can solve this problem without requiring all this extra code then we've removed a whole class of possible bugs by removing the need for this special error message code
wootehfoot has quit [Ping timeout: 258 seconds]
<marler8997>
on the other hand, solving this issue makes "generic code" more tractable, which actually isn't a goal of Zig
seadragon-droid has joined #zig
<marler8997>
so I suppose verifying types inside function bodies like we have now aligns with Zig's goals
<marler8997>
but then again, solving this problems helps users of generic code, not the generic code itself, so I take my last point back
<TheLemonMan>
grr, I can't put labels on my gh issues
<torque>
I would argue that the main advantage is making generic type conformance declarative in the function signature
<torque>
and improved error messages, if they happen, is a side benefit
<marler8997>
torque, one question I recall andrewrk asking is why putting type constaints in the signature is better than putting them in the body
<TheLemonMan>
because it serves as documentation?
<torque>
documentation and readability
<TheLemonMan>
anytype tells you jack shit about what the interface is
<marler8997>
if we added support for that in the signature, now we have 2 ways of adding type constraints
<torque>
if a constraint is bound to a name, the user can memoize its definition in their head so that upon encountering that elsewhere, they immediately understand what it means
<marler8997>
torque, yes that's a good observation, but having it at the top of a function body has nearly the same effect
<torque>
I disagree, because the actual code is frequently some chained conditionals
<TheLemonMan>
except for all the times you don't see the function body
<fengb>
Except it’s harder to generate documentation and provide guarantees
<TheLemonMan>
eg. in some documentation
<marler8997>
if the type checking code is inside conditions, then you couldn't put it in the signature anyway
<marler8997>
that's not an equivlent comparison
<marler8997>
yes it makes it harder to generate documentation
<marler8997>
an ideal documentation generator in this case should analyze the function body and add type constraints to the documentation, which would be harder that having then in the signature in the first place
<marler8997>
so do we want to maintain one way to add type constraints, or do we want to make it easier to generate documentation?
<semarie>
TheLemonMan: I opened a PR against your repo regarding #7411
<torque>
I think dogmatically focusing on "one way to do things" is a great way to make bad decisions
<TheLemonMan>
semarie, hah, I've just finished updating the definition
<marler8997>
torque, that's a very interesting proposition, I've thought about it myself and haven't really decided one way or the other
<marler8997>
However, I think having multiple ways to do things at some point becomes problematic. My intuition tells me there's probably a balance to be had there
<marler8997>
Zig clearly errors on the side of minimalism here, which I think is a better side to error on
<torque>
like, why does the "for" loop exist
<marler8997>
you could make the argument that there is no other equivalent way to semantically write a for loop
<fengb>
andrewrk has talked about removing the for loop
<marler8997>
a while loop with a counter or incrementing pointer isn't really equivalent, since a for loop covers both cases simultaneously
<marler8997>
also keep in mind that "one way to do things" isn't an absolute rule, but more of a goal. Using it as an argument doesn't necessarily mean it justifies rejecting every proposal
<marler8997>
But it's a good question to ask of any proposal, "without this proposal, what's the current solution? If there is already a way to do this, why are we adding another way?"
<TheLemonMan>
because duck typing sucks?
<marler8997>
TheLemonMan, would like to hear your thoughts on the subject, share more?
sord937 has quit [Ping timeout: 240 seconds]
<leeward>
I think the word obvious is important and should not be ommitted.
<TheLemonMan>
error messages are terrible (on par with C++ ones?), no documentation in the signature, people often forget to put checks on anytype params
<leeward>
My bar is if I see two competing ways to do a thing and one is obviously superior, then that's the way to do it. If there isn't an obvious winner, it's probably time to think hard about finding a better way.
<marler8997>
yeah I agree on those points
<andrewrk>
same
<ifreund>
has there been a proposal of something close to go's interfaces but comptime only?
<marler8997>
yeah it's one "obvious" way to do things, which is alot weaker than "one way to do things", adding type constraints to the function signature could be seen as more "obvious" than putting then in the function body. And when the type constrains are more "dynamic", that could be when it's obvious to put them in the body
<llimllib>
If I get `LLVM ERROR: Unsupported library call operation!` when compiling, is that a compiler error, and should I file an issue?
<llimllib>
(in this case, if I change a u128 to u256, the program fails to compile)
<TheLemonMan>
does it work with align(@sizeOf(c_int)) ?
<semarie>
fail with assert(@sizeOf(siginfo_t) == 128) and fail with assert(@sizeOf(siginfo_t) == 136) too
<semarie>
(and C is saying the size is 136)
earnestly has joined #zig
<TheLemonMan>
alright, what if you remove the align directive completely?
<semarie>
it pass with assert(@sizeOf(siginfo_t) == 136)
<TheLemonMan>
the maximum alignment should be the one of pointer fields
<TheLemonMan>
alright, that's ok... the compiler is smart enough
<semarie>
I had to go. bbl
<TheLemonMan>
bbl and thanks for the help
<andrewrk>
god damn it, clang introduced a regression in 11.0.1 release candidate when building zig on arm-linux
<TheLemonMan>
huehuehue
<ifreund>
:/
<andrewrk>
or... did I just not pass the right floating point abi like a dummy
<andrewrk>
oh good, I'm a dummy
<ifreund>
yay?
hf69 has quit [Remote host closed the connection]
<TheLemonMan>
so, you cut the tag before running the tests? that's bold!
<ifreund>
I assume this came up while making tarballs for all the targets we can
<andrewrk>
TheLemonMan, nah but I did cut the tag before making the tarballs
<dch>
so should I wait a wee bit before rolling the freebsd 0.7.1 package then?
<dch>
damn computers
<ifreund>
I'm waiting for the release to appear on ziglang.org to bump the void package
<andrewrk>
dch, the release train is on the tracks, nothing can stop it
<dch>
i say ship it and damn the consequences! (pirate voice)
<ifreund>
the only real reason I'm waiting is cause void pulls the source tarball from ziglang.org instead of github :D
<ifreund>
though I suppose I could change that
<andrewrk>
dch, don't worry, there are no consequences, I just fucked up a command and then got surprised by the error
leon-p has joined #zig
ur5us has joined #zig
SebastianKeller has joined #zig
<TheLemonMan>
lol @ #7433
<andrewrk>
TheLemonMan, I get the distinct impression you are having yourself a drink, eating popcorn, kicking back, and watching me sweat through this release process :D
<TheLemonMan>
haha something like that, yeah
<TheLemonMan>
cutting releases is much harder than writing code :\
seadragon-droid has quit [Read error: No route to host]
<andrewrk>
it's pretty difficult to automate the tarball creation
<andrewrk>
I can make most of them on linux but not freebsd or macos
<andrewrk>
also, automating or not automation is just choosing between the different kinds of things that can go wrong
marijnfs_ has joined #zig
<andrewrk>
release notes are up if anyone wants to check it for mistakes while I get the rest of the assets in order
<g-w1>
I am still a little confused, why is it any different than just making the automated tarballs nightly?
<g-w1>
do you want to make it on your machine for maximum precision?
<TheLemonMan>
andrewrk, try with % or without any leading symbol
<andrewrk>
on it
<TheLemonMan>
the @ is used for comments in ARM asm
<TheLemonMan>
we never hit this check when building glibc's .s stubs for ARM ??
<andrewrk>
hm yeah we test static musl on arm
<andrewrk>
drone ci is running aarch64-linux-musl tho, seems like that one should be choosing dynamic musl
<andrewrk>
oh we pass -DZIG_STATIC=ON because we use it to create a static zig tarball
<andrewrk>
g-w1, it's just a bunch of little details that add up, combined with only testing it roughly once every 6 months
<TheLemonMan>
good news, I've grepped LLVM source code and % should be ok for every arch
<andrewrk>
nice
<andrewrk>
I think lowercase with % did it
<TheLemonMan>
yeah, it's parsed in MCAttrForString
<TheLemonMan>
and it uses a case-sensitive StringSwitch
<g-w1>
ah this makes sense, you want the release to be perfect, but you don't care as much if nightly is broken
<TheLemonMan>
the same fix should be applied to glibc's generated stubs, no?
<andrewrk>
yeah good point
hnOsmium0001 has joined #zig
mattnite has joined #zig
nyaayaya has joined #zig
gpanders has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Ping timeout: 265 seconds]
<ifreund>
why does asm have to be so weird and non-standardized
<ifreund>
I'll PR a fix, guess it's too late for this release though :/
<ikskuh>
ifreund: related to asm on one platform?
<ikskuh>
arm has pretty standardized asm, avr as well
<ikskuh>
x86 has two major dialects
<ifreund>
ikskuh: #7433
<ikskuh>
oh no :(
<andrewrk>
it's not a regression
<andrewrk>
I am curious why drone CI didn't catch it tho
<ifreund>
it is on musl-based arm systems which should hit that as they'll link musl dynamically by default no?
<ifreund>
but yeah idk why drone didn't hit that either
<andrewrk>
hmm I see, yes because the default changed
seadragon-droid has joined #zig
<andrewrk>
now the big question: leave 0.7.0 on the download page, or replace it with 0.7.1?
<andrewrk>
I'm thinking replace
<ifreund>
Definitely don't kill the links though
seadragon-droid has quit [Ping timeout: 260 seconds]
<andrewrk>
yep all the links on download/* are immutable
<andrewrk>
tarballs I mean
<ifreund>
isn't the drone aarch64?
<ifreund>
that would explain why it didn't hit it
<fengb>
0.1.0 was dereferenced so there’s precedence :P
seadragon-droid has joined #zig
<ifreund>
I also had someone confirm they can build and run river on a musl raspberry pi 4 so that's cool
hexaflex has quit [Quit: Going offline, see ya! (www.adiirc.com)]
cren has quit [Quit: cren]
seadragon-droid has quit [Ping timeout: 272 seconds]
<andrewrk>
linux & windows tarballs are up. download page will get updated at next CI run
<andrewrk>
oh I almost forgot to send the announcement email ;)
<ikskuh>
wonderfl!
nyaayaya has quit [Remote host closed the connection]
<ifreund>
heh Frank made it into the contributors list twice :D
sord937 has joined #zig
sord937 has quit [Client Quit]
viashimo has joined #zig
<ikskuh>
btw, andrewrk: some people proposed that we should announce the releases also in the News section on the website
<ikskuh>
it's "big news" after all
<andrewrk>
good point
<ikskuh>
and i think it would be enough to just link to the release notes/download page
<ikskuh>
> This release solves 69 bugs.
<ikskuh>
*click* *click* NOICE
<viashimo>
I'm trying to add a signal handler to my application, and even without a handler installed SIGUSR1 seems to terminate the application
<andrewrk>
utzig, you threw off my gimmick on lobste.rs
<viashimo>
I'm not sure what the question I'm trying to ask is, but maybe to start: how do I get the application to not terminate when receiving sigusr
<ifreund>
viashimo: block the signal
<viashimo>
ah, add it to sa_mask?
<ifreund>
yes, see the sigprocmask man page
<viashimo>
although, at least for linux, it seems like it should automatically blocked unless SA_NODEFER is specified in the flags
<viashimo>
I'll try it though, thanks ifreund
xentec has joined #zig
<ifreund>
and signal(7) says the default action for SIGUSR1 is to terminate the process by the way
<viashimo>
ifreund: ah okay, I hadn't checked the default behaviour. I assumed it would be ignored
<andrewrk>
macos and freebsd tarballs will arrive later today, they are still building
Bekwnn has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<cCCCCcccccCCc>
So I've not programmed on Windows since the late 90s and at the moment I'm trying to test that a libsoundio-using music synth I'm writing on Linux can compile and run on Windows. I genuinely did search around before asking, but what should I be passing to linkSystemLibrary so that the WASAPI symbols can be resolved? Everything else seems fine.
<ikskuh>
(and also answers your questions related to libs which is uuid and ole32)
<viashimo>
ifreund: got it working, thx
<ifreund>
no problem!
<ifreund>
a lot of systems programming is just finding and reading the right man pages :D
<utzig>
andrewrk :-P I can delete it if you want
<ikskuh>
cCCCCcccccCCc, did it solve your problem?
<cCCCCcccccCCc>
ikskuh: No, but I'll keep plugging away before I bother again. In my case I've pulled libsoundio into my tree and I'm compiling it with zig directly, so I may be doing something different.
<cCCCCcccccCCc>
Thank you, though.
<andrewrk>
anyone know the codesign CLI args for ad hoc code signing?
mattnite has quit [Quit: Lost terminal]
<andrewrk>
nvm, looks like `-s -`
<ikskuh>
cCCCCcccccCCc: for windows and linux, all build information should be in build.zig
<ikskuh>
(the one linked above)
<ikskuh>
it builds libsoundio with zig as well
xackus has quit [Quit: Leaving]
<andrewrk>
utzig, thanks ;)
xackus has joined #zig
xackus has quit [Read error: Connection reset by peer]
<andrewrk>
ok there will be no 0.7.2. Onwards to 0.8.0!
<leeward>
\o/
<leeward>
I thought I saw a roadmap somewhere once, but can't find it.
<ifreund>
you think it's realistic to have stage2 working for x86_64 debug builds by then?
<andrewrk>
I don't think we will be passing all behavior tests by then. But I do think it would be realistic to have it work for some projects for this target by then
<ifreund>
yeah that sounds reasonable :D
<andrewrk>
after a month of bug fixes / release work, I think I've earned some heads-down focused time on stage2 :)
<ifreund>
for sure!
<ikskuh>
<andrewrk> ok there will be no 0.7.2. Onwards to 0.8.0!
<ikskuh>
Full throttle!
<ikskuh>
what will be the next steps?
<ikskuh>
more frontend? more backend? more midend? :D
wilsonk has quit [Quit: Leaving]
<ifreund>
I think the backend stuff is probably the most contributor friendly currently
<ifreund>
my impression is that the higher level ast -> zir stuff is where the most design work is needed
<ifreund>
in particular comptime
<ikskuh>
to my understanding, the "frontend" translating the AST to ZIR is the "easy" part
<ikskuh>
and comptime is then implemented in ZIR
<ifreund>
maybe I mean zir -> ir then
<g-w1>
I disagree, there is a lot of stuff in zir_sema that is SUPER low hanging (comptime array concat/mult, in general comptime stuff)
<ifreund>
maybe it's cause I'm just a lot more familiar with the backend stuff then :D
<g-w1>
yep, i am completly lost in the weeds of the assembly opcodes, but im pretty comfortable with implimenting the comptime stuff :)
<ifreund>
that's good, cause we need both :D
<leeward>
Is there a function in the standard library that takes an integer type and a number, and left-shifts 1 by the number? I don't see a bitmath module in there.
<leeward>
fn (T: type, n: [however you spell uT]) T { return 1 << n }
<ifreund>
why would we need a function for that? it's one line...
<leeward>
I have a lot of constants that live in bit masks, and `@as(u8, 1) << NUMBER` is a lot less clear than `bit(u8, NUMBER)`
<leeward>
My other question, if it's not already in std somewhere, is about how to write that uT bit. I can get the bit width from @bitSizeOf, but how do I get from the number 8 to a u3?
<leeward>
Ah, looks like @Type is what I'm looking for.
SebastianKeller has quit [Quit: leaving]
<ifreund>
you can use std.meta.Int() too
<leeward>
Ooh, that's a lot prettier.
<ifreund>
(which is just a wrapper for @Type)
wilsonk has joined #zig
<leeward>
heh, @log2 is for floats...silly me
<ifreund>
leeward: oh, std.math.Log2Int()
<leeward>
ifreund: That is way better than @floatToInt(@log2(@intToFloat)))
<ifreund>
most of the things are there, they just aren't easy to find :D
<leeward>
yup
<leeward>
That one could use a doc comment. I think I'll write one.