ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
redj has quit [Remote host closed the connection]
<GitHub152>
[zig] isaachier closed pull request #1147: Fix segmentation fault on invalid enum field (master...enum-invalid-field-fix) https://git.io/flFs0
redj has joined #zig
lainon has quit [Remote host closed the connection]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
kristate has quit [Remote host closed the connection]
<GitHub123>
zig/master be2a4c4 Andrew Kelley: Merge pull request #1149 from ziglang/issue346...
lainon has joined #zig
darithorn has quit [Quit: Leaving]
vegecode has joined #zig
klltkr has quit [Ping timeout: 255 seconds]
<vegecode>
Actually my question still stands. Is there an equivalent to the -g flag for clang that will map instructions to lines of source code?
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
lainon has left #zig ["Leaving"]
redj has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
JinShil has joined #zig
<andrewrk>
vegecode: it's on by default. Unfortunately llvm does not support outputting elf files which would embed the debug info
<andrewrk>
I mean llvm does not yet support outputting .o files for msp430
<vegecode>
gotcha. I wasn't sure how that worked. Thanks!
<vegecode>
If I find something in a header that @cImport can't handle, should I report it?
<andrewrk>
Yes, go ahead
<andrewrk>
There may be some existing issues
kristate has quit [Remote host closed the connection]
<vegecode>
The thing it is having trouble with is imported from another header in the same folder. Is that normally something it can do?
kristate has joined #zig
kristate has quit [Remote host closed the connection]
<vegecode>
Well I moved the dependency all into the same file and it's still having trouble. I'll figure it out.
kristate has joined #zig
<vegecode>
PBOUT_H &= ~(0x80);
<vegecode>
This line fails with error: unable to perform binary not operation on type 'comptime_int'
<vegecode>
If I cast it first to a u8 all is well
<vegecode>
Is that expected?
kristate has quit [Remote host closed the connection]
<dbandstra>
that seems reasonable to me, comptime ints have no size, right?
xtreak has joined #zig
<dbandstra>
~ would yield an infinity number of 1 bits
<vegecode>
Yeah, even though I've been bitten in C with type inferences before, i still resent the boilerplate.
<vegecode>
I saw the video of the presentation andrewrk did on zig and about how he left out feature requests made by people in order to keep the language simple.
kristate has joined #zig
<vegecode>
I personally really like uniform function call syntax as an idea. It would be much quicker to annotate types like 1024.u16 instead of u16(1024)
<vegecode>
Endlessly nested parentheses are very difficult to read.
<dbandstra>
yeah i agree with that
kristate has quit [Remote host closed the connection]
<andrewrk>
vegecode, I think translate-c is missing a cast to c_int there
<vegecode>
that line of code was actually in my zig file
<vegecode>
I finally got a blinking led run by an interrupt. Huzzah! Unfortunately for embedded, volatile is only through pointers in zig so that is going to require some effort to port the header file for the device. Not terribly so, though.
<vegecode>
It's kind of a fool's errand to do this. Most of the msp430s have silicon errata that needs work arounds. I highly doubt llvm's half-baked msp430 backend can do that
<vegecode>
But it's still fun I guess
<vegecode>
Goodnight
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
very-mediocre has joined #zig
relatingdata has joined #zig
relatingdata has quit [Quit: Page closed]
JinShil has quit [Remote host closed the connection]
JinShil has joined #zig
alexnask has joined #zig
davr0s has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
xtreak has quit [Remote host closed the connection]
zolk3ri has joined #zig
xtreak has joined #zig
JinShil has quit [Quit: Leaving]
very-mediocre has joined #zig
xtreak has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
noonien has joined #zig
xtreak has joined #zig
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
xtreak has quit [Ping timeout: 256 seconds]
vegecode has joined #zig
vegecode has quit [Client Quit]
lainon has joined #zig
bheads__ has joined #zig
davr0s has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
Ichorio has joined #zig
lainon has quit [Remote host closed the connection]
<alexnask>
The fact that all graphics APIs apparently depend on libc blows my mind
bheads_ has joined #zig
bheads__ has quit [Ping timeout: 240 seconds]
bheads__ has joined #zig
isolier has joined #zig
bheads_ has quit [Ping timeout: 256 seconds]
vegecode has joined #zig
bheads_ has joined #zig
bheads__ has quit [Ping timeout: 268 seconds]
bheads_ has quit [Quit: Leaving]
jjido has joined #zig
<andrewrk>
At least on Linux
<alexnask>
@andrewrk Was looking into the current lambda/closure proposals, one I didn't see which is pretty interesting is having using the stack frame pointer of the parent function
<alexnask>
Ofc then the function cannot escape the parent function body
<alexnask>
And I'm not too sure on the LLVM IR for that, I think that's how D nested functions work though
vegecode has quit [Ping timeout: 260 seconds]
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 245 seconds]
<MajorLag1>
I'm having a tough time with comptime today. `error: cannot store runtime value in compile time variable` when all the variables involved are known at comptime and marked `const`, and the function is called in a comptime block.
<MajorLag1>
I don't know how to make it any more clear to the compiler that this should all be done at comptime
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag1>
I think it may be syntactically impossible to access the bytes of a type at comptime right now.
<alexnask>
The bytes of a type?
<alexnask>
Do you mean @sizeOf or..?
<MajorLag1>
I mean, take an isize, for instance, and get an [8]u8
<MajorLag1>
or rather, a slice of u8
<alexnask>
Aah right gotcha
<MajorLag1>
No matter what you do the compiler complains that your const value is in fact a runtime value and can't be placed in a comptime variable. you can't use pointer casting to do it because comptime.
<MajorLag1>
The closest I've come is crashing the compiler on a TODO because you can't bitcast to an array type.
<alexnask>
Well, you can pointer cast but not take a slice of it
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alexnask>
Hmm I'm trying to think if the compiler can even do that
<MajorLag1>
ok, you can't use @intToPtr
<MajorLag1>
or rather @ptrToInt
<MajorLag1>
which is where I go when something otherwise can't be done
<alexnask>
only for 1 byte though, a slice of len 2 yields "error: out of bounds slice"
<MajorLag1>
yeah, I know, I filed that bug this morning
<alexnask>
that's probably because all integer types are bigints under the hood at comptime
<MajorLag1>
even if I explicitly cast it to a regular type?
<alexnask>
Not too sure tbh, I don't think the compiler can handle what you are trying to do at comptime
<alexnask>
Yes
<alexnask>
Casting it only changes the type at comptime, all integer values are bigints
<MajorLag1>
Ok, here's the use case: given a value at comptime, byte-swap it to the endianess oposite of the comile target endianess.
<MajorLag1>
Given what you've told me, maybe i can do it by constructing the byte array from the value at comtime instead of trying to cast.
<alexnask>
Yes, that would be possible
<alexnask>
I think
<alexnask>
The way I would think of it is that the memory layout/representation is not defined at comptime
<alexnask>
So there is no way to take some chunk of bytes and cast it to another type as if you're just talking about bytes
<alexnask>
if that makes sense :p
<MajorLag1>
yeah, that makes sense, it just wasn't obvious that's how it worked.
<alexnask>
Right, the docs should probably be clearer on exactly what is compatible at comptime
jjido has joined #zig
<MajorLag1>
yeah, copying the bytes works as expected.
<MajorLag1>
thanks for the info.
<alexnask>
No problem, would you mind sharing your solution?
<alexnask>
I'm wondering if we can do some compiler side magic when casting specific types (like integers) to [*]u8
<alexnask>
Or to [*]const u8 prov
<alexnask>
prob*
<MajorLag1>
the solution is that I took the value and did the appropriate bitshifting to dump it into a comptime created array. https://paste.ubuntu.com/p/YNvgwKyJmN/
jjido has quit [Ping timeout: 256 seconds]
isd has joined #zig
_whitelogger has joined #zig
davr0s has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
lainon has joined #zig
andi3 has joined #zig
alexnask has quit [Ping timeout: 240 seconds]
Ichorio_ has quit [Ping timeout: 240 seconds]
lainon has quit [Ping timeout: 265 seconds]
andi3 has quit [Ping timeout: 260 seconds]
quc has quit [Ping timeout: 268 seconds]
fubd has joined #zig
<fubd>
zig looks like my jam! what's the wasm story so far?
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]