gamester has quit [Remote host closed the connection]
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<andrewrk>
I broke some zig build stuff in master branch - will fix tomorrow
noonien has quit [Quit: Connection closed for inactivity]
darithorn has quit [Remote host closed the connection]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
allan0 has joined #zig
SergeiMinaev has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
dewf has quit [Quit: Leaving]
very-mediocre has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 255 seconds]
noonien has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 245 seconds]
MajorLag has quit [Ping timeout: 240 seconds]
MajorLag has joined #zig
MajorLag is now known as tgschultz
halosghost has joined #zig
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
suirad has quit [Ping timeout: 256 seconds]
Hejsil_ has joined #zig
<Hejsil_>
andrewrk, The only place I can find where it would seem that we init a type with one possible value is in ir_analyze_container_field_ptr
<Hejsil_>
If OnePossibleValueYes, then ir_const(ira, source_instr, field->type_entry)
darithorn has joined #zig
<Hejsil_>
As far as I can see, ir_const just 0 allocates and then sets value.type = type and value.special = ConstValSpecialStatic
<andrewrk>
Hejsil_, oh you know what - this works because memset BigInt to 0 is correct
<andrewrk>
so in fact if OnePossibleValueYes, then no further initialization is required
<Hejsil_>
I'll add the type_has_one_possible_value check and then do the thing then
<andrewrk>
and then I'm guessing you'll get a compile error? but that should be one step closer to correct behavior
<andrewrk>
I'm working on the master branch CI failures - sorry for jumping the gun
<andrewrk>
the good news is that zig build system is about to have full and correct caching support :)
<Hejsil_>
Nice :)
<andrewrk>
the zig package manager pieces are starting to come together... the next piece of the puzzle is event-driven networking support in userland (which depends on non-allocating coroutines, which depends on no-copy-semantics part 1a)
<Hejsil_>
Looking forward to the blog post about all this. You seem to have a good idea about how all of this will come together, and git submodules are starting to annoy me
<andrewrk>
yes, and dependencies of dependencies are very awkward right now
<emekankurumeh[m]>
andrewrk: have you seen mio for rust? would the event based io in
<emekankurumeh[m]>
zig be similar to that?
SergeiMinaev has joined #zig
very-mediocre has joined #zig
schme245 has joined #zig
<andrewrk>
emekankurumeh[m], it will be what we already have in std/event/* except with better coroutine semantics
<emekankurumeh[m]>
does std.event use iocp on Windows or does it use overlapped io
<andrewrk>
iocp
<andrewrk>
I'm pretty sure those concepts are not mutually exclusive
<wrl>
you can do overlapped without iocp
<wrl>
not sure you can do iocp without overlapped
<emekankurumeh[m]>
I meant just overlapped to without iocp.
m6w6 has joined #zig
Akuli has joined #zig
klltkr has joined #zig
Hejsil_ has quit [Quit: Page closed]
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Ping timeout: 240 seconds]
kristate has joined #zig
<Akuli>
currently, to run all tests i do: zig test tester.zig --library c --library foo --library bar
<Akuli>
where tester.zig is a zig file that imports all the files
<schme245>
there is one common situation in Zig where the "Only one obvious way to do things" is not clear to me: declaring variables integer types
<Akuli>
can i have 'zig build test' or something?
<schme245>
`const x: u8 = 0` works, and so does `const x = u8(0)`
<schme245>
I'm always unsure of which one is preferred
<andrewrk>
schme245, they are semantically identical
<Akuli>
i use the first one because it also works with other types than integers
<andrewrk>
I would say prefer the former for now, but this is a known "more than one way to do things" violation as you mentioned, so maybe this will change in the future
<very-mediocre>
Is it really a violation? The former is more "obvious" imho
<schme245>
sounds good, just wanted to throw it out there to see if it had been discussed
<Akuli>
the latter is more obvious if you have never seen the former syntax, but you have seen the () conversions
<very-mediocre>
Not to split hairs, but you could argue both forms are obvious ways of doing different somethings
<very-mediocre>
the former being an obvious way to do it implicitly, the latter explicitly.
<very-mediocre>
This feels like a Seinfeld conversation.
<very-mediocre>
At the risk of entering into "Was it a shimmy? I think it was more of a tumble" conversation territory, what's a "something" in the context of there being an obvious way to do something
<andrewrk>
the idea is that two people who solve the same problem, end up writing roughly the same code
<andrewrk>
encouraging code reuse and code sharing
<very-mediocre>
ok, so I have just descended us into pedantry then
<very-mediocre>
btw andrewrk, is there a non-patreon way to give you a donation?
<very-mediocre>
I really like this project and wanna pitch in
<andrewrk>
soon, I'll have a charitable non profit foundation
<andrewrk>
dedicated to advancing zig and its associated tools, teaching best practices system programming, and in general encouraging more widespread adoption of higher quality software
<very-mediocre>
sounds good.
very-mediocre has quit [Ping timeout: 256 seconds]
<kristate>
andrewrk: that's good news -- we already have 5 paid programmers working on zig related technologies at connectFree. If anyone wants a job hacking on zig, we pay about 1,000,000 JPY a month, which is around 10k USD
<kristate>
andrewrk: connectFree also has interest in becoming a ground member of your foundation, so please keep us in the loop
<andrewrk>
kristate, glad to hear that. will do!
kristate_ has joined #zig
kristate has quit [Ping timeout: 252 seconds]
<Akuli>
i wonder what happens if zig now gets lots of non-backwards-compat changes D:
<halosghost>
Akuli: I mean, it's version 0.3
<halosghost>
it's not exactly meant to be long-term-stable, yet :)
<andrewrk>
Akuli, there are lots of breaking changes planned
<Akuli>
but if it's actually being used somewhere
<Akuli>
even though it's 0.3 and it has been changing a lot in the past
<halosghost>
it shouldn't be used in-production by anyone who isn't willing and able to update their code frequently
<andrewrk>
^
<Akuli>
ok that's what i thought
<halosghost>
honestly, it may be better to just say “it shouldn't be used in-production yet”
<halosghost>
it depends on the cost-benefit calculation at your place of work
<halosghost>
but, despite how interesting and exciting Zig is; it's not quite ready for prime-time yet imho
<andrewrk>
1.0.0 will be the first production ready release
<halosghost>
makes sense
<halosghost>
andrewrk: so, now that arbitrarily-sized, fixed-width integers are a thing; what do you think about arbitrarily-sized, fixed-width floats? :P
<halosghost>
(noting that llvm doesn't actually support those)
<halosghost>
(though, I suppose arbitrarily-sized, fixed-width posits are actually accomplishable)
<andrewrk>
is there actually a use case for that?
<halosghost>
well, for posits, yes
<Akuli>
how do i write this so that this works and is not horribly unidiomatic http://dpaste.com/3ATB9ZH
<halosghost>
it's the same as for arbitrarily-sized, fixed-width integers (asfw from here forward because I'm lazy): steadily-increasing precision / representable range
<halosghost>
for floats? probably not
<Akuli>
mpz_get_str(buf, ...) doesn't work because buf is not a c string
<halosghost>
and floats would be really hard to do actualy (particularly if you wanted to match the standard's sizes for the predefined sizes since they don't actually match any sane algorithm afaik)
* halosghost
really needs to get around to implementing posits in zig
<halosghost>
though, to be fair, they'll be implemented on top of integers anyway, so asfw posits would be for-free
<andrewrk>
Akuli, we have std.mem.len for that strlen at the bottom
<Akuli>
but how about the c string thing? now it says: error: expected type '[*c]u8', found '[]u8'
<andrewrk>
std.mem.len(u8, buf.ptr)
<andrewrk>
you can get from a []T to a [*]T by using `.ptr`
<Akuli>
is [*]u8 close enough to [*c]u8?
<andrewrk>
yes, [*c]u8 is the cowboy pointer, it casts to and from all other pointers
<Akuli>
is it c as in cowboy?
<Akuli>
not c as in the programming language
<halosghost>
andrewrk: tangentially related: I don't believe I've properly freaked out enough about how awesome it is to have a separation between pointer-to-item, pointer-to-bounded-aggregate and pointer-to-unbounded-aggregate
<halosghost>
andrewrk: I love that
<Akuli>
anyway thanks :) now that part of my code seems to be compiling without errors
<andrewrk>
Akuli, happy coincidence :)
<andrewrk>
this can't be repeated enough... there is never ever a reason to type [*c] into your keyboard. The only use case, no exceptions, is auto generated zig code
<halosghost>
lol
<halosghost>
andrewrk: out of interest, is there not a way to make that construct only valid in internal code?
<andrewrk>
i've been considering making "none" a special C ABI that outlaws all the c types, @cImports, C pointers, and C strings
<andrewrk>
it still makes sense for [*c] to be in user code because they might have used translate-c and have not fully ported the result yet
<halosghost>
ahh, I see
<andrewrk>
halosghost, one of my goals is to propose an extension to .h files to encode pointer-to-item, pointer-to-bounded-aggregate and pointer-to-unbounded-aggregate information
<andrewrk>
and get clang/gcc to adopt a new warning for them, so that C programmers start using the annotation
<andrewrk>
which will benefit zig users doing @cImport
<andrewrk>
plus zig generated .h files could have these annotations
<halosghost>
andrewrk: having that added to C would be amazing
<halosghost>
who knows; maybe with the proposal for C2x to remove the unfortunate requirements of {u,}intmax_t so that we can have types greater than 64-bits on supported platforms, we can get asfw integers in C
<halosghost>
that would be astounding
<halosghost>
though, I still really want a structured way to achieve overflow handling
<halosghost>
^ that's the main proposal I want to put in front of the C committee
Akuli has quit [Quit: Leaving]
<andrewrk>
I've always thought it was silly that unsigned and signed ints have different overflow behavior
<halosghost>
I understand why it is the way it is
<halosghost>
and I don't begrudge the history
<halosghost>
but I'm definitely not happy that there isn't a structural way to control it
<halosghost>
namely, I want to be able to say, “for this block of code, I want overflow to result in saturation”
<halosghost>
and control both signed and unsigned independently
<halosghost>
okay
<halosghost>
o/
halosghost has quit [Quit: WeeChat 2.4]
ganderzz has joined #zig
tiehuis has joined #zig
ganderzz has quit [Ping timeout: 256 seconds]
mikdusan has quit [Ping timeout: 252 seconds]
tiehuis has quit [Ping timeout: 245 seconds]
jjido has joined #zig
mikdusan has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ganderzz has joined #zig
tiehuis has joined #zig
<ganderzz>
Having some cross-platform issues. When running tests on Windows the following code passes, but on OSX it fails on the first test. Is this a compiler issue, or just my own weird code? :) (https://github.com/ganderzz/zig-exercism/tree/master/phone-number)
dewf has joined #zig
tiehuis has quit [Ping timeout: 245 seconds]
<andrewrk>
ganderzz, I can take a look in a bit
<ganderzz>
Thanks!
<andrewrk>
you could try running your code in valgrind
<schme245>
is it supposed to be possible to get "access of inactive union field" when you're doing a switch over a tagged union?
SergeiMinaev has quit [Quit: leaving]
<andrewrk>
schme245, I believe that's what currently happens if your union memory is corrupt. I'd have to double check
<andrewrk>
it's not supposed to be possible if your value is defined
<schme245>
it wouldn't surprise me in the slightest if I have corrupted the whole thing somehow :D
<schme245>
first time doing recursive structs/unions
<schme245>
I'm pretty sure it's my code, but if not I'll try to make a minimal repro and open an issue