ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
n0tekky has quit [Quit: Leaving]
earnestly has quit [Ping timeout: 246 seconds]
mikdusan has joined #zig
daex_ has quit [Ping timeout: 240 seconds]
daex has joined #zig
gazler has joined #zig
gazler__ has quit [Ping timeout: 240 seconds]
LewisGaul has quit [Ping timeout: 240 seconds]
powerofzero has quit [Ping timeout: 240 seconds]
cole-h has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Biolunar has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
eddyb[legacy] has quit [*.net *.split]
andrewrk has quit [*.net *.split]
gracefu has quit [*.net *.split]
g8U4Z1xGzjlm has quit [*.net *.split]
Biolunar has joined #zig
eddyb[legacy] has joined #zig
andrewrk has joined #zig
gracefu has joined #zig
thaumavorio has joined #zig
osa1 has quit [Ping timeout: 265 seconds]
kurufu has joined #zig
<kurufu> Does zig have memory fences or an easy way for me to prevent reordering? Valgrind seems to attribute some memory corruption to use after free, but the free is after the use in source and both stacks in valgrind are on the same thread.
<g-w1> not familiar with atomics, but just found this:
<kurufu> ah yea that looks good, thanks I shoulda just searched the docs hah.
<shachaf> I don't know if there's something strange going on with Zig allocators, but I'd be pretty surprised if it reordered a read after the free like that. I kind of doubt a fence is the right answer for this sort of situation.
<kurufu> the allocators are in C calls, which is why i think it may just be too agressively optimizing.
<kurufu> since it has no insight.
<shachaf> I'd look at the generated code to see what it's doing, I guess. The behavior you're describing sounds like a bug to me.
<shachaf> The allocator being in C only makes it less likely (because it can't reorder a use to be after a call to an opaque function, right?).
<andrewrk> kurufu, zig won't move loads/stores across external function call boundaries
<kurufu> there are no loads or stores in zig
<kurufu> both occur on the C side
<kurufu> if i knew how to view assembly that would probably also help, but fences were the easiest way I knew to make a compiler not reorder things.
<andrewrk> I'm confused, @fence prevents zig from moving loads and stores across the fence, but you just said there are no loads or stores on the zig side
<kurufu> err sorry only loads on the zig side.
<kurufu> the three calls in question and the valgrind attributions. I may have misread something as well im not particularly skilled at this.
<kurufu> and the joys of being on archlinux I think i broke my build environment right before asking for help.
<g-w1> andrewrk: for 6542 I saw you just commented, how easy is this issue?
<andrewrk> g-w1, if you're thinking of taking it on I think it's perfect for you
<g-w1> i might want to take it on, as my project may depend on it as the workaround is not working
<g-w1> > zig needs to look at the CPU feature flags for arm and append, for example, "v6" to the architecture part of the LLVM triple <- where do I find these cpu flags?
<g-w1> the link just showed all the options, not what flags belolnged to which arch?
<g-w1> wait, does this affect stage1, or only stage2? now I am very confused :P
<andrewrk> all you gotta do is add a few lines of code in that linked spot with the TODO
<andrewrk> for arm, append an arm sub-architecture to the triple
<andrewrk> for kalimba, append a kalimba sub-architecture to the triple
<andrewrk> etc
<andrewrk> this function is used by both stage1 and stage2 to produce an llvm triple
<g-w1> hm, aren't the things listed in the linked code already sub archs?
<andrewrk> zig doesn't have sub-architectures
<andrewrk> the linked items in target/arm.zig are CPU feature flags
<andrewrk> the task is to translate target arm CPU features into an LLVM sub-arch when producing an LLVM triple
<g-w1> oh hmm, where is the code for that?
<andrewrk> for what?
<g-w1> translating it?
<andrewrk> it's the first link in the issue
<g-w1> ah, so I use the features in Cpu.features to add to the llvm triple?
<andrewrk> yes
<g-w1> oops my fancy irc client also pastebined the message: i see! would this help with the issue that I had earlier, as the suggested fix did not work and you linked the issue:
<g-w1> or was the issue just how this would get impled in stage2?
<andrewrk> it might help
<g-w1> if so, how can I make this work in stage1?
<kurufu> well fences didnt help, so its probably something im doing incorrect I guess. If i could ask another question though, I think i updated glibc and `zig build` fails on linking to system libs with missing glibc symbols. but the equivalent `zig build-exe` appears to compile fine?
<andrewrk> g-w1, this function is used by both stage1 and stage2 to produce an llvm triple
<g-w1> ah, its in the zig part of stage1 i see
<g-w1> kurufu: try clearing zig-cache and the global cache maybe?
<g-w1> .cache/zig for global one
<kurufu> Ah will do, i think i found one in local share so i was going to ask if there was another.
<andrewrk> this is not a cache issue
<kurufu> Ah this one correctly warns me that it cannot build again 2.33
<kurufu> build-exe agains `--target native-native-gnu.2.33` works can I set that in the build.zig?
<g-w1> interesting, I thought that build-exe working made it a cache issue
<kurufu> i can see the warning after clearing the cache, which is good.
<kurufu> thanks for the help, though ill probably just wait for a new package to roll down.
<g-w1> ooh, this is a pretty nice example of what the docs could look like:
bitmapper has quit [Quit: Connection closed for inactivity]
<g-w1> compiling that assembly doesn't work at all using clang, so it seems gcc and zig are at least a bit better :(
<andrewrk> I think doxygen is not a great example to look to
leon-p has quit [Quit: leaving]
<g-w1> do you know the port of the irc server at for #llvm and if it requires a password/identification?
<g-w1> i want to get this working with clang before zig
<g-w1> eh, ill just use discord
<jcmdln> kurufu: I recently ran into this, and it has me pining after Nix. For the simple idea I'm exploring, I decided to get my build.zig to build and include my dependencies as static libraries
vrdhn has joined #zig
vrdhn has quit [Client Quit]
vrdhn_ has joined #zig
vrdhn_ has quit [Remote host closed the connection]
vrdhn has joined #zig
terinjokes has quit [Quit: ZNC 1.8.1 -]
terinjokes has joined #zig
vrdhn has quit [Quit: Leaving]
factormystic has quit [Read error: Connection reset by peer]
factormystic has joined #zig
powerofzero has joined #zig
cole-h has quit [Ping timeout: 252 seconds]
powerofzero has quit [Remote host closed the connection]
sord937 has joined #zig
earnestly has joined #zig
gracefu has quit [Quit: WeeChat 2.9]
<ifreund> kurufu, jcmdln: workaround here if you want, I intend to fix this in zig before 0.8.0 though
<ifreund> I wonder how much time we have left before the final llvm 12 release
haliucinas has quit [Read error: Connection reset by peer]
haliucin1s has joined #zig
rtpg has joined #zig
gracefu has joined #zig
yyp has joined #zig
LewisGaul has joined #zig
gracefu has quit [Quit: WeeChat 3.0]
gracefu has joined #zig
leon-p has joined #zig
osa1 has joined #zig
LewisGaul has quit [Quit: Connection closed]
<daurnimator> ifreund: having to patch your build.zig to add the libcPaths thing is annoying. IMO should be part of normal release options etc.
<daurnimator> I guess that goes back to my build.zig options PR that is awaiting discussion
<daurnimator> mmmmmm. packed structs seem to be even more broken than I remember: I thought as long as you used multiples-of-8-bits you were fine
<kevinsjoberg> I'm trying to learn myself C and then eventually Zig. I have a lot of programming experience but not so much with low-level programming. I'm currently working my way through K&R but I'm constantly having questions and or want to someone more experienced to review my implementation on exercises. Does anyone know where to look for mentors?
<kevinsjoberg> I'm sorry if the above was considered off-topic.
yyp has quit [Quit: now it's safe to turn off your computer]
Anzh has quit [Read error: Connection reset by peer]
waleee-cl has joined #zig
jmiven has quit [Quit: reboot]
jmiven has joined #zig
<ugla> kevinsjoberg: I don't know if I would have time for code review, but I'd be happy to answer questions in DM
<kevinsjoberg> ugla: Thanks a lot for reaching out. Zig only questions, or C as well?
<ugla> kevinsjoberg: Both :)
<kevinsjoberg> Alright, appreciate it!
notzmv has quit [Ping timeout: 265 seconds]
notzmv has joined #zig
klltkr has joined #zig
Akuli has joined #zig
a_chou has joined #zig
yyp has joined #zig
bndbsh has joined #zig
vrdhn has joined #zig
jcmdln has quit [Remote host closed the connection]
a_chou has quit [Quit: a_chou]
yeti is now known as drawkula
a_chou has joined #zig
jcmdln has joined #zig
LewisGaul has joined #zig
<LewisGaul> When running `./zig test ../lib/std/json/test.zig --main-pkg-path ../lib/std` I get reems of compile errors, e.g. "error: expected type '*mem.Allocator', found '*std.mem.Allocator'". Something obvious I'm doing wrong?
<LewisGaul> tried replacing main pkg path with '../lib' but the errors are then just "expected type '*std.mem.Allocator', found '*std.mem.Allocator'"
a_chou has quit [Quit: a_chou]
LewisGaul98 has joined #zig
factormystic has quit [Read error: Connection reset by peer]
LewisGaul98 has quit [Client Quit]
LewisGaul12 has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
factormystic has joined #zig
LewisGaul12 has quit [Quit: Connection closed]
LewisGaul has joined #zig
sundbp has joined #zig
vrdhn has quit [Ping timeout: 246 seconds]
<andrewrk> LewisGaul, you accidentally have 2 different copies of the std lib active
<andrewrk> you can use --override-lib-dir or you can delete the unwanted lib/ dir from the cwd
<LewisGaul> I think the copy of lib/ in the cwd was just generated by the make install?
<andrewrk> yes. for zig development you can omit the install
<andrewrk> this will let you use the lib/ files directly from the zig source repo
<LewisGaul> did I need to do the install to generate the zig binary in the first place though, or could I have just used my 0.7.1 binary?
<LewisGaul> maybe this explains the issue that we were putting down to the zig caching mechanism not working on WSL1 actually...
<LewisGaul> removing the lib/ dir from build/ fixes the issue anyway, glad to have cleared that up! thanks
aerona has joined #zig
cole-h has joined #zig
bndbsh has quit [Quit: Connection closed for inactivity]
LewisGaul has quit [Quit: Connection closed]
aerona has quit [Quit: Leaving]
spyjetfayed has joined #zig
<g-w1> LOL
<g-w1> all along it was a nixos bug i think. i have a friend who is on archlinux and it works fine for him
<g-w1> and it works fine on an older version of nixos
<spyjetfayed> I was doing ratfactor's zigling exercises are on problem 33 on error-handling with if else, the swtich case used didn't need the else condition.
<spyjetfayed> on line 38 shouldn't it be giving some error due to the missing else?
<spyjetfayed> anyway first time here. cheers ^_^
<g-w1> i *think* zig does better than clang in this place
<g-w1> spyjetfayed: it shouldn't give an error due to missing else since the type of `err` is MyNumberError which only has 2 options
<g-w1> if you switch on `anyerror` then you would need an else
<spyjetfayed> ahh thanks
Anzh has joined #zig
sord937 has quit [Quit: sord937]
yyp has quit [Quit: now it's safe to turn off your computer]
jcmdln has quit [Remote host closed the connection]
Akuli has quit [Quit: Leaving]
sundbp has quit [Ping timeout: 260 seconds]
halbeno has quit [Quit: Leaving.]
halbeno has joined #zig
jcmdln has joined #zig
l1x has quit [Quit: Connection closed for inactivity]
spacelove has joined #zig
<spacelove> Is there a way to initialize an empty slice of strings? I think I've tried every conceivable permutation of {}, [][], and [0..]
<spacelove> Or, is there a way to make an empty array of strings, which I can then turn into a slice?
<spacelove> I was thinking maybe it was not possible. I've found workarounds, but nothing simple.
<cepheus> &[_][]u8{} should work
<spacelove> Whoah
<cepheus> bit of a magic incantation to do that one
<cepheus> the general deconstruction is that, const can be coereced if it's used in the type signature of the field or delaratation, the outermost array always needs to be sized but can be inferred using _, and you can coerce the resulting array into a slice using &
<spacelove> Sorry, I didn't reply because I fainted from too much oxygen going to my brain
<g-w1> andrewrk: ah i saw you closed the issue, for the arm. ill try playing around with it more, and ill file a bug report if i can't get it to work
spacelove has quit [Ping timeout: 240 seconds]
spyjetfayed has quit [Ping timeout: 258 seconds]