<pixelherodev>
daurnimator, when is a feature a maybe?
<fengb>
I think zig test is eating the seg fault message :(
<fengb>
Curious, what's the usecase of a tagless union?
<andrewrk>
fengb, when the knowledge of which tag is active lives elsewhere
<fengb>
Oh yeah, my emulator uses one >_>
<andrewrk>
Im really happy with how tagless unions turned out
<fengb>
There's still a check in release-safe right?
waleee-cl has quit [Quit: Connection closed for inactivity]
<Snektron>
Finally starting to get somewhere on this vulkan thingy
<andrewrk>
Yeah release safe has union safety
<andrewrk>
It's planned to support disabling it per type
<andrewrk>
Havent needed that yet tho
<Snektron>
Curious, do extern unions also have type safety?
<daurnimator>
pixelherodev: at compile time the target *might* have it: but you actually need to check at runtime
<fengb>
`unsafe union` :P
<andrewrk>
No because extern unions have well defined memory layout and non zig code modifies the data
return0e has joined #zig
<Snektron>
Guessed so
<pixelherodev>
daurnimator, no I got that
<pixelherodev>
I'm saying, when might that happen?
<fengb>
After I'm more accustom to Zig, writing a sexpr parser is actually pretty nice and elegant
<mikdusan>
tagged-union + switch-unwrap is the first thing that grabbed me about using zig to write a parser
return0e has quit [Ping timeout: 272 seconds]
<pixelherodev>
Switch unw - oh right yeah
<pixelherodev>
Used that for the LLVM parser :P
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
SimonNa has joined #zig
_Vi has quit [Ping timeout: 248 seconds]
casaca has joined #zig
<mikdusan>
when adding breakpoints by lineno to the wrong source file it's time for a coffee refill
<pixelherodev>
s/coffee/tea
<pixelherodev>
FTFY
return0e has joined #zig
return0e has quit [Ping timeout: 268 seconds]
<fengb>
How did I live before errdefer?
<pixelherodev>
Probably the same way the rest of us did
<pixelherodev>
With lots and lots of regret
<fengb>
Should I put braces around guard clauses?
<fengb>
if (foo) { return null }
<daurnimator>
Only if it goes to multiple lines
dddddd has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Ping timeout: 260 seconds]
<pmwhite>
I wonder if one could implement an in-language parser generator using comptime features.
<daurnimator>
pmwhite: for sure
marmotini_ has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
<pmwhite>
It would be cool if the parser generator could require the grammar to be valid LL(1), or whatever the most efficient thing is.
<daurnimator>
not all formats *can* be parser with an LL parser
<mikdusan>
I'm going to take a stab at fixing incorrect packed struct @sizeOf, and @byteOffsetOf, if anyone else is on this let me know so we don't compete
<daurnimator>
mikdusan: many have tried. go for it :)
<pmwhite>
daurnimator: Yeah, but if the grammar is LL can be than it would be nice to statically check that the specification for the grammar is that way. That way you don't end up with a non-terminating parser.
<pmwhite>
No, wait. I guess anything produced by a generator should pretty much be terminating, right?
ltriant has quit [Quit: leaving]
<pmwhite>
I think what I mean is that allowing enforcement of LL would provide confidence that you haven't made some mistake that causes the parser to be really slow.
<mikdusan>
sound right? @sizeOf(packed struct{ field: u24 }) should be 3? and @sizeOf(packed struct{ field: u23 }) should also be 3?
<andrewrk>
mikdusan, I wrote a bit about this recently... let me find it
<daurnimator>
mikdusan: I'm not sure..... @bitSizeOf was in a recent proposal
<daurnimator>
andrewrk: shouldn't we be checking actual feature flags rather than looking at reported model?
<daurnimator>
or at least: if there *is* a feature flag for a given feature; we should use that. Only falling back to the model for features that aren't reflected by a flag?
<andrewrk>
not sure what you're asking
<andrewrk>
for native or cross compiling?
<daurnimator>
for discovering native
<daurnimator>
I haven't looked at the code; but it sounded like we trust the model name reported over the cpuid feature flags
<andrewrk>
nah we trust llvm for figuring out native features
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<mokafolio>
Since zig does not support any kind of polymorphism, would you use tagged unions instead? i.e. if you needed a tree structure to host different types
<mokafolio>
just found the language so bare with me if I am blurting out stupid things :)
<andrewrk>
tagged unions is a good solution if you are ok with having each object take up the space of the maximum sized one
<andrewrk>
otherwise you can use a different pattern of embedding the "base" as a field of the child
<andrewrk>
see std/zig/ast.zig for an example
<andrewrk>
also std.mem.Allocator for an "interface" and the implementations in std/heap.zig
<andrewrk>
there are problems with this approach, several important open issues related
<mokafolio>
thank you, will check it out
marmotini_ has quit [Ping timeout: 265 seconds]
<mokafolio>
the tagged union approach has the same issue as in C i guess in that you need to define all the types the tree can ever hold beforehand
<daurnimator>
mikdusan: while you're looking at the packed struct stuff... do you know where the layout of `extern` structs is done?
<daurnimator>
mokafolio: yes. also you want types all roughly the same size
<andrewrk>
daurnimator, llvm inserts padding into structs in accordance with the c abi
<daurnimator>
andrewrk: the reason I ask is for bitfields in extern structs. I wasn't sure where to look
<andrewrk>
but check out analyze.cpp, resolve_struct_zero_bits and resolve_struct_type
<andrewrk>
there are several "phases" of struct resolution, corresponding to the ResolveStatus enum
<andrewrk>
I'm kinda stuck on the cpu target features branch. the next step in troubleshooting this is for llvm to tell me WTF it's doing when empty strings are passed (such as in master branch)
<daurnimator>
andrewrk: empty strings as the target feature list? that worked for me....
<andrewrk>
I'll send an email to the mailing list, and meanwhile go digging through the sources
<andrewrk>
what's happening is empty string is choosing some "baseline" cpu/features that was passing CI tests. now we're explicitly passing a list that is supposedly identical to the empty string. but ci tests fail now
<andrewrk>
I haven't figured out how to get llvm to tell me what cpu/features it was actually choosing, based on passing the empty string
benjif has joined #zig
<mokafolio>
andrewrk: by adding the "base" field I assume you'd still have to access it like a regular member right>
<mokafolio>
is there any issue for proposals how to improve that? I
<andrewrk>
yes, and yes there are open proposals
<andrewrk>
personally I don't mind the access. it solves the "multiple inheritance" issue
<mokafolio>
yeah it is no easy problem to solve and maybe should not be, I am just curious what people are thinking
<andrewrk>
I'm a bit resistant to the idea, on grounds of it being not strictly necessary
<mokafolio>
This is my favorite solution to the problem, too. But I hear you, at least there is no urgency to it
<pixelherodev>
i'd definitely agree that if it's not *necessary*, and there's no compelling demand for it, and it increases the language's complexity, it's probably not worth it, but that's just my two cents
<mikdusan>
andrewrk: how do we define @byteOffsetOf for packed struct fields? I guess the answer could vary for today's align=1 for packed struct, and #3133 where field aligns must be considered
<andrewrk>
mikdusan, it's defined to be the "host integer" address minus the base address
<andrewrk>
so if you have 2 u1 fields, they both have @byteOffsetOf() == 0
benjif has quit [Quit: Leaving]
<tdeo>
is there a way to get the current source file line/name?
lunamn_ has quit [Remote host closed the connection]
return0e has joined #zig
lunamn has joined #zig
return0e has quit [Ping timeout: 268 seconds]
HesamR has joined #zig
return0e has joined #zig
metaleap has joined #zig
metaleap has quit [Client Quit]
metaleap has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
lqd has joined #zig
JX7P has joined #zig
tyler569 has joined #zig
tbodt has joined #zig
programi1 has joined #zig
bgiannan has joined #zig
Flaminator has joined #zig
lucus16 has joined #zig
crimson_penguin has joined #zig
Cadey has joined #zig
companion_cube has joined #zig
tobbez has joined #zig
ur5us_ has joined #zig
dom96 has quit [Ping timeout: 268 seconds]
dom96 has joined #zig
ur5us__ has joined #zig
ur5us_ has quit [Ping timeout: 248 seconds]
_whitelogger has joined #zig
_Vi has joined #zig
<s-ol>
hey, in latest zig, how do I get std.debug.warn to format in a C string ([*c]const u8)? its just printing it as a pointer for me at the moment
<s-ol>
(latest from git)
<HesamR>
s-ol: I would do something like this : "std.debug.warn("{s}\n", .{@ptrCast([*:0]const u8, c_string)});"
<s-ol>
ooh right, theres that new type of slice
<s-ol>
i'll give it a shot, thanks HesamR
<mq32>
one wish: zig needs a good, __integer based__ date/time library in std
<mq32>
i have problems with a double-based date/time lib right now in that term that "too many day increments on a date time may skip some days eventually"
ur5us__ has quit [Ping timeout: 268 seconds]
HesamR has quit [Remote host closed the connection]
bheads has joined #zig
dddddd has joined #zig
fengb has joined #zig
AlexMax has joined #zig
mattmurr has joined #zig
Dominic[m] has joined #zig
dtz has joined #zig
BitPuffin has joined #zig
Demos[m] has joined #zig
Snektron has joined #zig
hryx has joined #zig
pmwhite has joined #zig
vegai has joined #zig
D3zmodos has joined #zig
alva has joined #zig
zfoo_ has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<s-ol>
how about casting a nested array to a linear slice? e.g. [_][3]f32{ [3]f32{ ... }, [3]f32{ ... } } to []const f32?
marmotini_ has quit [Read error: Connection reset by peer]
<s-ol>
doing it as @bitCast([9]f32, array)[0..] now but that means repeating the size, which isnt clean
waleee-cl has joined #zig
marmotini_ has joined #zig
<fengb>
Might be easier to start with linear array and manually slice it up
<betawaffle>
i'm curious if there's a difference between the two (linktime vs post-comptime)
<betawaffle>
the usecase i've got in mind right now are basically assertions of things that can really only be checked at or after linking (i think)
<fengb>
Linktime would require a special linker just for Zig code. That might be a really hard buy-in unless it's hoistable into runtime
<betawaffle>
i feel like it could fit in with the idea of ditching linker scripts
<fengb>
Hmm that might be pretty cool
<betawaffle>
which obviously kinda requires a custom linker anyway
<fengb>
Yes but the object files still need to be backwards compatible
<fengb>
I don't think it'd be a good idea to force our linker onto every toolchain
<betawaffle>
right, i'm thinking you'd have really limited abilities
<betawaffle>
what i'm not sure about is whether that would even allow us to do what i think i want
<mq32>
hm
<BaroqueLarouche>
on some platforms, I think it would require that use their linker, like some console that encrypt their ELF
<mq32>
zig *could* provide a zig linker that works similar to "zig build"
<mq32>
so there's a link.zig which defines the stuff similar to linkerscripts
<mq32>
BaroqueLarouche: yeah that would be one use case actually
<betawaffle>
mq32: oh that's an interesting idea
<mq32>
the LPC1786 requires a checksum in the list of execption handlers
<betawaffle>
so here's a sort of related question... is it *possible* to know the frame size of a function in any pre-runtime environment? (eg. comptime, post-comptime, etc)
<betawaffle>
i know it *currently* isn't available at comptime (right?)
<betawaffle>
at least every time i've tried it tells me it's a runtime value
<betawaffle>
but presumably that's only because it needs information only the linker has access to
<betawaffle>
how does @frameSize currently work, and how would post-comptime change it?
<fengb>
wasm was clearly not designed for physical hardware :P
dddddd has quit [Ping timeout: 260 seconds]
<betawaffle>
yeah, pretty sure i was designed to be easy to interpret and/or translate to native code at runtime
<betawaffle>
it*
<fengb>
Right. It's exhibiting none of the bit patterns I've seen in other assembly
<fengb>
I'm curious how difficult it'd be to create a physical wasm machine. Maybe that could be a future project
<betawaffle>
all you need is something that does the translation in hardware
<betawaffle>
x86 is basically that at this point
<betawaffle>
everything gets translated to micro-ops
Snetry has quit [Ping timeout: 265 seconds]
forgot-password has joined #zig
<forgot-password>
Hey guys, how can I convert a null-terminated c-string to a slice?
<forgot-password>
When trying to print the c string directly I get the following error: "Expected tuple or struct argument, found [*c]const u8"
<mq32>
forgot-password, use std.mem.toSlice or toSliceConst
<forgot-password>
Here's the call: "std.debug.warn("{}", NSRunLoop.*.name);
<forgot-password>
Alright, I'll give it a try, thanks :)
<fengb>
You need to wrap the last argument: `.{NSRunLoop.*.name}`
<mq32>
std.debug.warn("{}", .{ NSRunLoop.name }); // would be the right way atm
mokafolio has quit [Quit: Bye Bye!]
<forgot-password>
Oh okay, when and why did that change?
<mq32>
some time after 0.5
<mq32>
:D
<forgot-password>
Oh, how enlightening :D
<mq32>
it's the new tuple syntax that removes the need for varargs completly
<mq32>
i think it's now at least one month in action already
<forgot-password>
Do I still need to convert it to a zig slice?
<forgot-password>
I've been abstinent from Zig for a while
mokafolio has joined #zig
<forgot-password>
Wait, even when I do `std.debug.warn("{}\n", .{1 == 1});` it doesn't print anything...
<adamkowalski>
try doing that in a new project to check if your compiler is up to date and no other issues are responsible. create a folder and do zig init-exe
<forgot-password>
That's basically what I did, but I'm gonna delete the cache folder really quick
eagle2com has joined #zig
<adamkowalski>
also not sure if this is documented anywhere, but something that's rather useful is if you want to debug a test case you can create a binary with: zig test src/main.zig --cache off --verbose-link
<adamkowalski>
then you can lldb test and you're off to the races
<forgot-password>
Does std.debug.warn output to stderr?
<adamkowalski>
yeah
<adamkowalski>
tries to*
<forgot-password>
So, it turns out that Vim doesn't show the stderr output, only stdout
<forgot-password>
At least it seems like it
<forgot-password>
When running it in a terminal *inside* vim, it works ^^
<adamkowalski>
yeah I would use tmux and launch it inside of a seperate pane.
<forgot-password>
Hm, I'm using a gui client for neovim
<forgot-password>
The terminal app doesn't render it correctly :(
<adamkowalski>
or better yet join me over at emacs
<companion_cube>
adamkowalski: I swear, the cult can't shut up about org-mode :D
<adamkowalski>
Yeah it's pretty good but that's not why I like emacs at all
Akuli has joined #zig
forgot-password has quit [Quit: leaving]
marmotini_ has joined #zig
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has joined #zig
marmotini_ has quit [Remote host closed the connection]
eagle2com has quit [Ping timeout: 268 seconds]
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
<mikdusan>
http://llvm.org/docs/LangRef.html#load-instruction "When loading a value of a type like i20 with a size that is not an integral number of bytes, the result is undefined if the value was not originally written using a store of the same type."
nullheroes has joined #zig
<mikdusan>
and for store "When writing a value of a type like i20 with a size that is not an integral number of bytes, it is unspecified what happens to the extra bits that do not belong to the type, but they will typically be overwritten."
<mikdusan>
I suppose this is one of the reasons why we have TypeStructField.gen_index and "host integer"
nullheroes has quit [Client Quit]
<andrewrk>
gen_index can disagree with src_index if there are 0 bit fields
nullheroes has joined #zig
<fengb>
TIL vim has an "easy" mode
return0e_ has quit []
<andrewrk>
alright I think I solved the aarch64 cpu features issue
<metaleap>
whats the size of an optional: 2 words (value being hidden ptr), or 1 + full sizeof underlying?
<Snektron>
Depends on the type
<mikdusan>
usually { payload: T, isNull: bool }
<Snektron>
for ?*T its @sizeOf(*T)
adamkowalski has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 248 seconds]
<metaleap>
thx =) makes sense too
<metaleap>
"hidden ptrs" would be weird in a ziglang
Snetry has joined #zig
<andrewrk>
mikdusan, the bit is the other way around: is_non_null
<andrewrk>
that way writing 0 to it makes it null
nullheroes has quit [Ping timeout: 260 seconds]
wilsonk has joined #zig
traviss has joined #zig
TheLemonMan has joined #zig
<traviss>
is there already an issue for this compiler bug? its struct initialization with a mismatched type. https://clbin.com/Cif5P
<TheLemonMan>
traviss, does it give you a 'broken LLVM module' thing ?
<traviss>
yes
<traviss>
`broken LLVM module found: Call parameter type does not match function signature!`
<TheLemonMan>
it's the most hated error at the moment
wootehfoot has joined #zig
<TheLemonMan>
together with "instruction doesn't dominate all the uses"
<TheLemonMan>
mikdusan, are you on osx?
<mikdusan>
aye
<traviss>
was looking for an issue to possibly post this repro. sounds like its not necessary.
<fengb>
dominate is more intimidating :P
<andrewrk>
TheLemonMan, I solved the aarch64 issue with cpu features. now it's just down to windows
<TheLemonMan>
what's up with windows? I see the CI failed with an OOM error
<andrewrk>
yeah that's weird. I checked how much more ram we are using in the branch for std.zig tests compared to master and it's 200MiB. maybe that was the last straw
<andrewrk>
I'll see about lowering it
<fengb>
Is there a leak?
<TheLemonMan>
yeah, std.zig sometimes triggers the OOM killer on my box
<TheLemonMan>
fengb, it's yuuuuuge
<Snektron>
Is there an ordered associative container in Zig?
<andrewrk>
we need a garbage collector that runs at comptime
<Snektron>
Something like a linked hash map or a tree
<andrewrk>
biggest memory leak is ZigValue
<Snektron>
(insertion ordered)
lunamn_ has joined #zig
<andrewrk>
fengb, it's less that there's a leak, and more that stage1 until recently never freed any memory ever
<TheLemonMan>
there's also a lot of temporary Buf made with constant strings
<fengb>
Ah
<andrewrk>
TheLemonMan, I measured that though, it accounts for something like 1% of the memory
<fengb>
I remember mikdusan mentioned porting over an arena
<andrewrk>
an arena wouldn't really help in the case of ZigValue, if you think about it the compiler is already one big arena
<TheLemonMan>
1% of 6GB is still a sizable amount of memory heh
<mikdusan>
fengb: I was and let "ideas" features creep in and take my eye off the ball
<andrewrk>
is it though? 6 GiB - 1% is 5.94 which doesn't really get us closer to our 3.5 GiB goal
<andrewrk>
one thing we could do is free all zig stuff before telling llvm to go for it
lunamn has quit [Ping timeout: 268 seconds]
<Snektron>
Is that memory consumption just the AST?
<andrewrk>
check out the link, it shows a breakdown. AST is a tiny fraction
<andrewrk>
AST also never wants to get freed, everything ultimately wants to know where it occurs in the source code
<andrewrk>
Unknown_1 is buf bytes
<Snektron>
Im not familiar enough with the compiler internals to know at first glance what part of the compiler a type belongs to at first glance, so they all seemed like AST nodes to me
<andrewrk>
AstNode: 401273 items, 160 bytes each, total 61.229 MiB
Snetry has quit [Ping timeout: 240 seconds]
nullheroes has joined #zig
Snetry has joined #zig
<Snektron>
andrewrk, did you add malloc overhead in your profiler?
<Snektron>
Im not sure how drastic it is though, or whether its correct to just add 8 for each allocation
<andrewrk>
that's not the point of the tool. `time -v` is a better tool to find out actual memory usage. this profiling is to figure out how to change zig source code to use less memory
nullheroes has quit [Ping timeout: 268 seconds]
nullheroes has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
<andrewrk>
argh, c++ does not allow strings in template args
<Snektron>
Nope, not untill c++20
<andrewrk>
sometimes I forget the main reason to avoid c++ is because the features don't just work
<Snektron>
if you really want to you could of course use a parameter pack
<andrewrk>
what I really want is @typeName()
<Snektron>
you can do that
<Snektron>
but you're probably not going to like it
<andrewrk>
I looked into this, and you are correct, I do not like it
nullheroes has quit [Client Quit]
<Snektron>
Which one did you look into, rtti or PRETTY_FUNCTION
<Snektron>
theyre both headache worthy though
<TheLemonMan>
I've never seen a project not using -fno-rtti
_Vi has joined #zig
metaleap has quit [Quit: Leaving]
Snetry has joined #zig
<Snektron>
Remind me of a project i had to work on for uni
<Snektron>
The students who worked on it the previous year left some nice things for us
<Snektron>
such as `delete this;`
<TheLemonMan>
hah
<Snektron>
Along with a segfault caused by a destructor
<TheLemonMan>
talk about pulling the rug from under your feet
<Snektron>
but was fixed by creating a cyclic reference to itself with a shared_ptr
<TheLemonMan>
two wrongs make a right!
<Snektron>
My uni's "main" language is c++, so that goes about as well as you'd expect
<Snektron>
Not that i really have a problem with it, i have a love/hate relationship with c++
<TheLemonMan>
it's not C++98, you can't complain (that much)
<Snektron>
Well its not like they teach c++11, you have to figure that out by yourself
<fengb>
You love to hate it? >_>
dddddd has joined #zig
<Snektron>
I don't really think its that horrible to program in
<Snektron>
At least, if you stay away from macros
<fengb>
So... if at comptime you try looking up the declarations of @This(), the compiler segfaults >_>
<fengb>
I feel like every day, I make the compiler cry in new ways
<andrewrk>
if I wrote a compiler I would simply make it never segfault
<fengb>
catch(segfault) return 0
<TheLemonMan>
replace all the macros with too much SFINAE and you're back to square one :P
<fengb>
I mean, I keep telling it nonsensical operations, so I get it >_>
<TheLemonMan>
fengb, the rules of the fight club are clear, who finds a bug has to fix it!
<Snektron>
I don't use SFINAE too much but i'm never shy of a bit of metaprogramming in templates
<fengb>
I guess I should log it
<andrewrk>
thx
Snetry has quit [Ping timeout: 260 seconds]
<andrewrk>
hmmm. on posix `zig test` does execve which replaces the compiler with the test binary in memory; so the memory taken up by the compiler is gone
<andrewrk>
windows doesn't really have this afaik so it executes as a child process, the any allocations while running std tests are on top of whatever the compiler used
<fengb>
I don't think it's a really useful case since it's nonsensical heh
<andrewrk>
it should either work or report a dependency loop
metaleap has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<mikdusan>
is there a std fn to convert string from `[16]u8` where it could be max size 16, or null terminated if shorter ?
marmotini_ has joined #zig
<andrewrk>
not that I'm aware of
marmotini_ has quit [Ping timeout: 268 seconds]
marmotini_ has joined #zig
<Snektron>
mikdusan, if you're adding stuff to std.mem anyway, could you do a quick countScalar?
<Snektron>
otherwise i'll add it
<TheLemonMan>
countScalar?
<Snektron>
Counting occurances of a value in a slice
<Snektron>
Surprised me that its missing
<TheLemonMan>
I think `count` is a better-suited name if you consider all the other fns in mem
<Snektron>
I thought that name would be reserved for something that counts occurances of a subsequence
<TheLemonMan>
you can probably come up with some nice simd-accelerated algorithms for that
<Snektron>
yeah but is that worth it
<Snektron>
I mean, considering Zig is uses LLVM it will probably autovectorize it anyway
<BaroqueLarouche>
is the autovectorizer that good ?
<Snektron>
LLVM's, at least on clang, is pretty crazy
<andrewrk>
I tested and using @Vector in zig speeds up even debug builds which have no autovectorization
<andrewrk>
even with safety checks, it's faster
<Snektron>
Did you actually test a count function or is that in general?
<andrewrk>
in general
<Snektron>
In the general case is not surprising because its not omnipotent of course
<Snektron>
I think if you use @Vector (at least, its the case with xmmintrin86 in c), LLVM will even try to autovectorize that
<Snektron>
Hm, by a quick look the generated assembly could be simpler
<Snektron>
Ill take a look at it in a moment, now i got interested
<mikdusan>
Snektron: re: adding stuff to std.mem; not planning on adding anything right now
<Snektron>
oh, alright
<andrewrk>
Snektron, if you use @Vector it's not auto vectorization, it's just lowering
<andrewrk>
@Vector is manual vectorization
marmotini_ has quit [Remote host closed the connection]
<Snektron>
i know
<Snektron>
What i mean is that LLVM tries to autovectorize manual vectorization too
Akuli has quit [Quit: Leaving]
wilsonk has quit [*.net *.split]
dom96 has quit [*.net *.split]
terinjokes has quit [*.net *.split]
Yardanico has quit [*.net *.split]
frmdstryr has quit [*.net *.split]
cow-orker has quit [*.net *.split]
livcd has quit [*.net *.split]
mahmudov has joined #zig
aequitas_ has joined #zig
<aequitas_>
hi, I'm new to Zig, thought I'd try it out for my next pet project to parse some binary data from a serial device to reverse engineer the protocol but I'm getting stuck on type conversions.
cow-orker has joined #zig
<Snektron>
Which kind of conversion?
<Snektron>
and whats the error
<aequitas_>
I have a []u8 where I want to step over in u16 values, but I don't want to convert the []u8 to a []u16
<aequitas_>
as I don't know if the starting byte is half of a u16 so to say
<aequitas_>
my approach now is to take a slice of the input data of 2 u8's, but I don't know how to convert it into a u16
<aequitas_>
var crc: u16 = data[start .. start + 2];
<aequitas_>
error: expected type 'u16', found '[]const u8'
<andrewrk>
why not convert the []u8 to []u16? slices are reference types so it's just a pointer cast
<Snektron>
For a single value, you can use either `@bytesToSlice(data[start .. start + 2])[0]`, or you can cast to an array and use a bitcast: `@bitCast(u16, []const u8{data[start], data[start + 1]})`
<TheLemonMan>
andrewrk, any plan for the switch to llvm 10?
<andrewrk>
yeah same plan as last time. now that llvm did the release/10.x branch it's time to update zig's llvm10 branch to be compatible. when llvm releases we merge into master
<andrewrk>
I did some work on llvm10 but there is more to do before it builds
<aequitas_>
andrewrk readIntSliceLittle does the trick, readIntSliceBig in this case for me, thx
<andrewrk>
np
<aequitas_>
out of curiousity, when I try to cast the []u8 to []u16 I get this: casting []u8 to []u16 gives me this: error: expected type '[]const u16', found '[]const u8'
<andrewrk>
it should be @bytesToSlice(u16, data)
<andrewrk>
I think there is std.mem.bytesAsValue
<andrewrk>
which is maybe an argument for removing the builtin entirely
<aequitas_>
I probably should dive into the stdlib a little bit more :)
<andrewrk>
TheLemonMan, note that zig 0.6.0 release date is scheduled for a couple weeks after llvm 10's scheduled release
<TheLemonMan>
that doesn't leave us with too much time to report any bug that may surface :\
<TheLemonMan>
when LLVM9 dropped we hit that nasty bug with switches on aarch64 a patch was only shipped with 9.0.1
<andrewrk>
well I was planning on getting the branch building today, and once per week running the full test suite in llvm debug mode with asserts on
<andrewrk>
the aarch64 thing didn't have test coverage until this release cycle - I don't think it was a regression
<andrewrk>
there were several regressions in llvm 9 release candidates found by zig's test suite, which I reported upstream and they got fixed before 9.0.0 was released
<TheLemonMan>
it was, see #3271 #3526 #3288
<andrewrk>
you filed those issues when trying to add test coverage for aarch64 right?
<andrewrk>
before you did that we didn't have coverage
<andrewrk>
are you saying this bug did not exist in llvm 8?
<TheLemonMan>
yeah, LLVM 9 introduced it
<andrewrk>
ah. well if zig had test coverage for it when llvm 9 release candidates were announced we would have caught it
<TheLemonMan>
I used to run the aarch64 tests by hand before the qemu-user thing went mainstream :)
<andrewrk>
yeah your point is still valid. how much time would you prefer between llvm10 merge and zig 0.6.0?
<TheLemonMan>
I'd say that as soon as they cut the first RC it's time to merge the branch
<TheLemonMan>
that'd give us ~1 month to find any eventual release-blocking problems
terinjokes has joined #zig
wilsonk has joined #zig
dom96 has joined #zig
Yardanico has joined #zig
<andrewrk>
that's problematic for people trying to build zig from source or with apt.llvm.org. we already get a bunch of complaints for merging on release day
marmotini_ has joined #zig
<andrewrk>
but I see your point. the goal is to get real actual testing of the release candidate, before it is released
<andrewrk>
my preference would be to have people build llvm10 branch from source and test using that
<andrewrk>
that will be possible within a day or two, and it gives people 3+ months
metaleap has quit [Quit: Leaving]
<andrewrk>
TheLemonMan, llvm10 branch builds now. haven't run the test suite yet
<andrewrk>
some good news is that zig_clang.cpp & friends were relatively easy to update
blackbeard420 has quit [Quit: ZNC 1.7.5 - https://znc.in]
blackbeard420 has joined #zig
return0e has joined #zig
akavel has joined #zig
<akavel>
Hi! How should my build.zig look like to build a .DLL on Windows?