return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 260 seconds]
klltkr_ has joined #zig
klltkr has quit [Ping timeout: 256 seconds]
wootehfoot has quit [Ping timeout: 260 seconds]
_Vi has quit [Ping timeout: 272 seconds]
drasko has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig
xackus_ has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 265 seconds]
nephele_ is now known as nephele
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
knebulae has joined #zig
kydrops has joined #zig
<mikdusan>
andrewrk: hmm vim syntax for zir; maybe too much red. globals probably just keep no-color ?
<mikdusan>
s/too much red/too many constants/
xackus has joined #zig
xackus_ has quit [Ping timeout: 260 seconds]
klltkr_ has quit [Ping timeout: 260 seconds]
<foobles>
how does ir_analyze_bin_op_bool work? it doesn't seem to introduce any short-circuiting logic itself. and even at comptime, it somehow short circuits even though it unconditionally calls ir_resolve_const on op1 and op2
<foobles>
like this works `const x = false and @compileError()`
<andrewrk>
foobles, the short circuiting happens in pass 1
<foobles>
oh, even for comptime stuff
<foobles>
cool
<foobles>
and im guessing the runtime short-circuiting is generated as a kind of wrapper around the IrInstSrcBinOp?
<foobles>
well i can just look
<andrewrk>
pass 1 has no access to types or values
<foobles>
so how does it know to short-circuit the `false and @compileError()` at pass 1?
<foobles>
if it doesnt have the value
<andrewrk>
foobles, it creates basic blocks and ir_build_br
<andrewrk>
have a look at ir_gen_bool_and - I think it's pretty readable
waleee-cl has quit [Quit: Connection closed for inactivity]
<redj>
andrewrk: sorry if I missed it on the stream but I was wondering what arch/binary formats are planned for the self-hosted zig compiler with the new zir compiler or whatnot?
<redj>
how much you're insisting on "cross platform as a first class use case" for this new work and how soon you think you'll start testing on other platforms?
<andrewrk>
all architectures, all binary formats
<yrashk>
this is a massive effort indeed
<pmwhite>
I haven't kept track of the state of break. Can I break out of an outer loop fr within an inner loop?
xackus has quit [Ping timeout: 246 seconds]
<foobles>
yeah, just label your loops
<foobles>
`outer: for (slice) |x| { while (condition()) { break :outer; } }`
<foobles>
pmwhite
<pmwhite>
Sweet
xackus has joined #zig
<foobles>
so if i understand correctly: basic blocks can only cause branching at the end
<foobles>
and that is what ir_build_br() does: it goes from one basic block to another
<foobles>
and ir_build_br_cond() will jump to different blocks based on a condition
<foobles>
if this understanding is correct: then does that mean you should ONLY do ir_build_br() as the last thing in a block?
<foobles>
since a block is supposed to just have 1 exit point at the end
Invader_Bork has joined #zig
<andrewrk>
foobles, yes that's all correct
<foobles>
great, ok
<foobles>
br = break?
<andrewrk>
branch
<andrewrk>
however note that with the new SSAT form, it will work differently, with different primitives (confusingly, with break instead of branch)
<shakesoda>
what does zig expect me to do instead of 1 << i in a loop
<shakesoda>
it complains with "LHS of shift must be an integer type, or RHS must be compile-time known" but 1 is definitely an integer and RHS can't be comptime known so that doesn't make sense
<shakesoda>
and if I try casting things or telling it what kind of int, it gives me an ever-changing integer type (u5, then u3, etc...)
<andrewrk>
shakesoda, it should say "...must be a *fixed-width* integer type"
<shakesoda>
I see
<shakesoda>
do i just need to cast both sides so it knows it can't overflow the u32
<andrewrk>
ya
<foobles>
i think you just need to cast the 1
<foobles>
oh?
<foobles>
i thought you would need to cast the lhs to a fixed-width tye
<foobles>
s/tye/type
<shakesoda>
foobles: when i do that it then wants the right side to be a type that cannot possibly contain a value that would shift everything out, i guess
<foobles>
aaah, yeah
<shakesoda>
feels a bit overboard to me on the requirement but okay, I get it now
<shakesoda>
better safe than sorry when bit manipulation is already fickle, i suppose
<foobles>
yeah
<foobles>
and in other langs where there is UB for over-shifting something, i think its interesting the potential UB shifts to be in the int-cast
<andrewrk>
in C it's basically the same, except you get UB instead of compilation errors
<foobles>
heh, i just realized you can call `@truncate` to make the type bigger
joey152 has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
xackus_ has joined #zig
xackus has quit [Read error: Connection reset by peer]
Invader_Bork has quit [Read error: Connection reset by peer]
dddddd has quit [Remote host closed the connection]
Invader_Bork has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
ur5us has joined #zig
hspak has joined #zig
FireFox317 has joined #zig
FireFox317 has quit [Remote host closed the connection]
dermetfan has joined #zig
Patrice_ has joined #zig
Patrice_ has quit [Quit: Leaving]
<daurnimator>
foobles: you should use @as for that
<daurnimator>
or just keep it small and let it eventually cast...
<foobles>
yeah, that would make more sense
<foobles>
i just thought it was funny
<foobles>
that it isnt checked that it is actually truncating
ur5us has quit [Ping timeout: 244 seconds]
marler8997 has quit [Ping timeout: 240 seconds]
foobles has quit [Ping timeout: 240 seconds]
Invader_Bork has quit [Read error: Connection reset by peer]
waleee-cl has joined #zig
riba has joined #zig
<gonz_>
andrewrk: Nice to see some action in terms of self-hosted
<andrewrk>
it's going to be quiet for a couple weeks as I prepare (two!) talks for RedisConf 2020, but you can expect to see a lot of progress on this front in this release cycle :)
riba has quit [Ping timeout: 240 seconds]
<gonz_>
Are either or both talks Redis-specific or is kristoff_it doing the redis module specific stuff?
metaleap has joined #zig
<gonz_>
(or whatever they call the pseudo(?)-plugin stuff in redis)
<gonz_>
I seem to remember there being two tiers of plugins you can write for it
_whitelogger has joined #zig
riba has joined #zig
drasko has joined #zig
Invader_Bork has joined #zig
<Invader_Bork>
/join #meson
_Vi has joined #zig
riba has quit [Ping timeout: 246 seconds]
<Snektron>
wrong chat
<gonz_>
What tools do we have for analyzing a `fn` returning a generic type?
<gonz_>
I don't want to force some evaluation of `f` in order to see the type; I'd like to analyze the returned type in its generic form.
<gonz_>
Ideally, I mean.
<mikdusan>
isn't the return type of a generic type always going to be `type` or `!type` or some other error union with a type?
<gonz_>
Sure
<gonz_>
I don't want to qualify the types and analyze the result
<gonz_>
(if I can avoid it)
<gonz_>
I can give it garbage types and see what type comes out, but this isn't ideal
<daurnimator>
gonz_: you can use `@TypeOf(foo(1,2,3))` and it doesn't actually execute it
<mikdusan>
that's peer-type resolution
<daurnimator>
mikdusan: ?
<gonz_>
This is all comptime stuff regardless so executing it isn't super important
<mikdusan>
oh sorry, that's just going to return type
<gonz_>
The issue I have is that I'm basically going to have to (as far as I can see) give it u1,u2,u3, etc., and see where these fall in the result.
<gonz_>
To determine which generic parameter goes where in the result type
<daurnimator>
gonz_: it could be *anything* though
<daurnimator>
gonz_: maybe at this point a better question is: what are you trying to do?
<gonz_>
daurnimator: No, generic values can't be *anything*, they correspond to the passed in type in the function.
<gonz_>
And if there were two instances of `U`, they are guaranteed to match.
<gonz_>
Sure, zig types can depend on many things, some of which I'm planning to add
<gonz_>
The issue is not (right now) "Can we translate all of these things to all target languages?" but rather "What can we do with zig type analysis atm?"
<gonz_>
And right now we're at the very basic scenario of looking at a pretty basic generic struct type and outputting the corresponding TypeScript, PureScript & Haskell one.
<mikdusan>
this seems like you have `fn add(a,b) result` and you're asking to see result without running add
<gonz_>
Well, what I'm asking is mostly whether or not we've established any tooling for analyzing these types of generic functions yet?
<gonz_>
We have type fields for `is_generic`, etc., so it's not outside of the realm of possibility that someone has dealt with this.
<gonz_>
And let's not pretend this is some outerworldly scenario
<gonz_>
We can do plenty of analysis on types and this is just a natural extension of that.
<daurnimator>
so you need a scheduler for that; you can try out the immature one in the zig standard library by doing: `pub const io_mode = .evented;`
<drasko>
But I do not know how to launch two functions in parralel - one that reads from `in` proxy and sends it to `out`, and in parallel one that reads responses from `out` and writes them to the `in`
<daurnimator>
drasko: `const a = async start_read_loop(); const b = async start_write_loop(); await a; await b;` or something like that
<drasko>
Now I am getting: error.FileDescriptorAlreadyPresentInSet => unreachable, // evented writes to the same fd is not thread-safe
<pixelherodev>
Then some other types that just embed e.g. Register32 for type safety
<pixelherodev>
e.g. RegisterAddress / RegisterInt
<ikskuh>
pixelherodev: yes, you can usingnamespace functions with the correct first type
<ikskuh>
i think both daurnimator and me made an experiment with this
<ikskuh>
but you have to use generic structs fr that
<ikskuh>
like
<ikskuh>
usingnamespace Mixin(@This());
<pixelherodev>
Righty, that works fine
<pixelherodev>
Logic deduplication is worth it
st4ll1 has joined #zig
<ikskuh>
yeah
<daurnimator>
hmmm.... anyone had an issue where llvm-objcopy keeps making 256MB files?
waleee-cl has joined #zig
<pixelherodev>
There's no form of multi-initialization, is there?
<pixelherodev>
Something like `const a, b: c = .{}, .{};` would be awesome...
<ifreund>
imo that hurts readability and isn't really worth it
<pixelherodev>
I think it hurts readability less than *32 lines* of initialization
<pixelherodev>
:P
<pixelherodev>
`pub const AL = R8{.id = 0};`
<pixelherodev>
8 for R8, 8 for R16, 8 for R32, 16 for R64...
<ifreund>
if you have 32 lines of straight up initialization maybe there's some way to restructure things and break it up into smaller tasks
<pixelherodev>
There isn't.
<pixelherodev>
It's 32 lines of *definitions*
<pixelherodev>
All of which are absolutely required
<pixelherodev>
As they are exposed outside the library
pystub has joined #zig
<pmwhite>
I don't think that's necessarily unreadable. It's just long, which is fine, all other things being equal.
<pixelherodev>
It's not *more* readable than e.g. `AL, CL, DL, BL: R8 = .{.id = 0}, .{.id = 1}, .{.id = 2}, .{.id = 3};`
<pixelherodev>
Split into four per line would make it easier to read
<pystub>
hello everyone, are questions about bootstrap tarball on topic?
<pixelherodev>
yeah
<pmwhite>
pixelherodev: why would that be more readable?
<pmwhite>
I guess readability is subjective.
<pmwhite>
But I personally find a 32 item list simpler than an 8 item list of 4 item lists, since that would have a nested rather than flat structure.
<pixelherodev>
It wouldn't nested though
<pystub>
it compiles all the deps (clang, llvm, lld) but then gets to zig itself and then stops at "Linking CXX executable zig0" with error "lld: error: unable to find library -lclangARCMigrate"
<pixelherodev>
In this specific case, it makes sense; the groupings are all logical
<pmwhite>
Okay, it would be matrix rather than an array.
<pixelherodev>
It's neither
<pixelherodev>
it's 32 distinct constants
<pixelherodev>
either way, it's 32 distinct constants, logically grouped
<pmwhite>
I see more now. A blank line between groups is your current option, then, right?
<pixelherodev>
Yeah
<pixelherodev>
The only difference is whether the grouping is inter-line (8 lines grouped together) or intra-line (4 sets of 2 grouped lines)
<pixelherodev>
s/4 sets of 2 grouped lines/2 grouped lines each containing four definitions
<pixelherodev>
pystub, check if it's a known issue?
<pmwhite>
I personally still don't care for multi initialization. One per line would make variables and values line up parallel. I don't get bothered by large line counts either.
<pmwhite>
I'm also against using directories for grouping files.
<pixelherodev>
Why?
<pmwhite>
pixelherodev: they don't semantically improve the structure of a program, and they just add more things for the programmer to manage. They don't really make anything easier.
<pixelherodev>
Agree to disagree
<pmwhite>
Note, I'm talking mostly about source code, but I also do this with, for example, my Documents folder.
<pmwhite>
I'm fine with disagreeing, but I'm curious which points you disagree with.
Aransentin has quit [Remote host closed the connection]
<pixelherodev>
I think having a well thought out directory structure makes it much easier to find a specific component
<pixelherodev>
e.g. for my current project `src/emitters/x86/assembler.zig` - if I know what I'm looking for I can find it in seconds, and if I don't it only takes slightly longer
<pixelherodev>
Clean separation of components make everything simpler
decentpenguin has joined #zig
TheLemonMan has joined #zig
<nephele>
i like using directory structures because semantically grouping helps me find stuff too, and it makes tabcompleteion much easier in some cases
<pixelherodev>
Gah, there's going to be way more than 32
<pixelherodev>
Forgot that the new 64-bit registers can be used as e.g. r8d, r15w, etc
st4ll1 has quit [Ping timeout: 260 seconds]
st4ll1 has joined #zig
<drasko>
HI all, I am getting this error:
<drasko>
reached unreachable code
<drasko>
/home/drasko/bin/zig/lib/zig/std/event/loop.zig:473:60: 0x231946 in std.event.loop.Loop.linuxWaitFd (zproxy)
<drasko>
^
<drasko>
error.FileDescriptorAlreadyPresentInSet => unreachable, // evented writes to the same fd is not thread-safe
<yrashk>
any chance we can make this more straightforward in the next release?
<andrewrk>
yrashk, glad you followed up with the "cut the chase" because that won't accomplish your goal, and there is a good way to accomplish your goal
<andrewrk>
from the zig source build dir, `./zig build test -Denable-qemu`
<andrewrk>
you might want to combine that with -Dskip-release to save some hours
<yrashk>
this will run zig's own tests
<andrewrk>
I understand now, you want to run the tests for multiple targets with qemu. yes this is a good use case
<andrewrk>
b.standardTargetOptions already accepts a set of valid targets - so the next improvement to make here is adding to build_runner.zig a CLI option to use qemu to run tests for all the specified targets that it can
<yrashk>
yeah that'd be most interesting
<andrewrk>
contribution welcome, it's a great feature