ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<ifreund> CI is green for #8737 :)
ur5us has quit [Ping timeout: 258 seconds]
zenkuro has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 265 seconds]
earnestly has quit [Ping timeout: 260 seconds]
lyhokia has joined #zig
hiljusti has quit [Ping timeout: 250 seconds]
ur5us has joined #zig
Poorchop has quit [Quit: Leaving]
Poorchop has joined #zig
lyhokia has quit [Ping timeout: 240 seconds]
lyhokia has joined #zig
hiljusti has joined #zig
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
koakuma has quit [Quit: Leaving.]
v0idify has quit [Remote host closed the connection]
lyhokia has quit [Ping timeout: 240 seconds]
hiljusti has quit [Ping timeout: 260 seconds]
xackus__ has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 250 seconds]
ur5us has joined #zig
<noam> ifreund: what about discrete integration?
<noam> :P
recalloc has quit [Remote host closed the connection]
squeek502 has quit [Remote host closed the connection]
<andrewrk> oh man I just learned how to utilize vim's undo tree. this is wild
<andrewrk> you can go back in time and then choose a different alternate universe where you typed something else and redo that branch
waleee-cl has quit [Quit: Connection closed for inactivity]
sord937 has joined #zig
leon-p has joined #zig
aerona_ has quit [Quit: Leaving]
hiljusti has joined #zig
ur5us has quit [Ping timeout: 276 seconds]
mikdusan has quit [Read error: Connection reset by peer]
mikdusan has joined #zig
cole-h has joined #zig
squeek502 has joined #zig
[wtf] has joined #zig
johannes_ has joined #zig
[wtf] has quit [Ping timeout: 260 seconds]
novakane has joined #zig
[wtf] has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
[wtf] has quit [Read error: Connection reset by peer]
waffle_ethics has quit [Read error: Connection reset by peer]
waffle_ethics has joined #zig
Anzh has quit [Ping timeout: 240 seconds]
novakane has quit [Ping timeout: 268 seconds]
novakane has joined #zig
[wtf] has joined #zig
novakane has quit [Ping timeout: 265 seconds]
novakane has joined #zig
earnestly has joined #zig
novakane has quit [Ping timeout: 260 seconds]
novakane has joined #zig
amk has quit [Read error: Connection reset by peer]
amk has joined #zig
wilsonk__ has quit [Ping timeout: 246 seconds]
Bernstein has joined #zig
wilsonk has joined #zig
ShockTohp has quit [Ping timeout: 240 seconds]
tefter has quit [Ping timeout: 240 seconds]
tefter has joined #zig
<ifreund> noam: this isn't math class you nerd, I just want to happily forget all that stuff and am doing pretty well so far :P
hiljusti has quit [Ping timeout: 260 seconds]
tefter has quit [Ping timeout: 252 seconds]
tefter has joined #zig
TheLemonMan has joined #zig
kevinsjoberg has quit [Quit: ZNC 1.8.2 -]
<noam> lol
<noam> ifreund: I should've tossed in a reference to red/green trees or something, too XD
tefter has quit [Quit: WeeChat 3.1]
tefter has joined #zig
ShockTohp has joined #zig
koakuma has joined #zig
<TheLemonMan> mikdusan, if you're interested in some more challenges there's also Haiku
<ifreund> TheLemonMan: looks like OpenBSD doesn't have dl or rt :/
<TheLemonMan> aw shit, we need one list for glibc and one for BSDs then
<ifreund> not one per target?
<ifreund> or something like is_libc_lib_name() but in reverse?
<TheLemonMan> ah right, I cygwin/darwin may use some different sets of libs
<ifreund> TheLemonMan: one other thing I'm confused about that you might have insight on, I now need to explictly add -lffi when linking libc and wayland wayland libraries while I didn't before my changes
<ifreund> any idea what's up with that? I'm not really sure which behavior is correct
<TheLemonMan> uh that's strange, libffi is not part of glibc by any means. what symbols are missing?
<ifreund> none, linking succeeds but I get error while loading shared libraries: cannot open shared object file: No such file or directory
<ifreund> (at runtime)
<ifreund> which doesn't make sense caes ldd reports " => /usr/lib/ (0x00007f4a2bf72000)"
<ifreund> hmm, ldd reports all the other shared objects as being in /usr/lib64
<ifreund> libffi is the only one listed in /usr/lib
<ifreund> /usr/lib64 is a symlink to /usr/lib on my system though
<TheLemonMan> none of the libraries you've added should depend on libffi
<ifreund> maybe it wasn't my change specifically that changed this behavior, I'll test some other commits. Right now I'm comparing 0.7.1 with master
<TheLemonMan> yeah, bisecting the offending commit is a good starting point
<TheLemonMan> did you update any of the other wayland libs in the meanwhile?
<ifreund> no, the same system libraries still work fine on 0.7.1
<ifreund> I was right though, it wasn't my latest PR that changed this behavior, it's different on 55d235dc vs 0.7.1 as well
<ifreund> time to do a long slow bisect I guess
<TheLemonMan> git bisect with an automated script makes the bisection process quite painless
<TheLemonMan> anyway, brb
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<ifreund> too many breaking changes between 0.7.1 and master to make a bisect practical :/
<ifreund> well, an automated one at least
Bernstein_ has joined #zig
Bernstein has quit [Ping timeout: 240 seconds]
dputtick has quit [Quit: Connection closed for inactivity]
r4pr0n has joined #zig
leon-p has quit [Ping timeout: 265 seconds]
leon-p has joined #zig
motiejus has joined #zig
<mikdusan> wth is wrong with your prompt? :P
<motiejus> hi folks. How can I compile a bpf program with `zig cc`? Scrolling through the sources, it seems to be supported, but I can't find the right value for `-target` to generate the object file.
<motiejus> I tried `zig cc -target bpf -Wall -Wextra -Werror -o ebpf_classid_marker.clang.o -g -O2 -c ebpf_classid_marker.c`, and got `error: UnknownArchitecture`; if I replace `zig cc` with `clang`, it works as expected
<ifreund> motiejus: I think you need bpfel or bpfeb as the arch in the -target triple, see `zig targets`
[wtf]1 has joined #zig
<motiejus> thanks! `bpfel` it is :)
<mikdusan> the best thing about endian-acronyms is you have to remember their character-ordering for each archictecture. This is some huge conspiracy I tell ya.
[wtf] has quit [Ping timeout: 240 seconds]
[wtf]1 is now known as [wtf]
<motiejus> git grep bpfel | tail -1
<motiejus> src/zig_llvm.h: ZigLLVM_bpfel, // eBPF or extended BPF or 64-bit BPF (little endian)
<motiejus> easy enough ;)
<ifreund> git bisect says 6 more steps left :)
<mikdusan> motiejus: `zig targets`
<motiejus> thanks mikdusan and ifreund, that worked.
<motiejus> another question: I started dabbing with (add `zig ar` sub-command, which just starts clang's ar); Andrew added a label "contributor friendly"; does it mean it is a reasonable request and has a chance to be merged if proposed?
[wtf] has quit [Ping timeout: 260 seconds]
<ifreund> motiejus: yeah, that feature is considered desireable and easy for someone new to the zig codebase to work on
<ifreund> I say go for it!
<noam> mikdusan: nothing? :P
<mikdusan> hmmm it would be nice if `git commit` added as comments or something HEAD's commit message for easy reference
<mikdusan> during editing
<ifreund> noam: your powerline glyphs are a little funky/misaligned
* noam shrugs
<ifreund> mikdusan: you can totally make your editor do that :P
<mikdusan> yeah the '>' thingee sticks out above and then highlighting makes it look like the font is also shifted a pixel up
<mikdusan> ifreund: but I am lazy
zenkuro has joined #zig
<ifreund> guess you just gotta keep opening up another terminal to run git show then :P
<mikdusan> hhahah
<ifreund> actually, my editor lets me run git show in the editor and have the output show up in a new buffer
<noam> ... I'm not committing that, that's awful :P
Anzh has joined #zig
guccimayne has joined #zig
<mikdusan> oof oom - std.zig tests now blow out a 14 GiB VM
<dok> ouch
<mikdusan> it can't be that high. grr. maybe I had 2 tests running at the same time. I hope that's the case.
<koakuma> Question: does __floatunsitf really takes an u64? All the other implementation that I can find seem to take an u32 instead.
TheLemonMan has joined #zig
<ifreund> TheLemonMan: my bisect points to the merging of the llvm12 branch causing -lffi to be required
<ifreund> there a whole slew of commits from that branch that don't compile or produce a broken zig so I was unable to narrow it down further
<TheLemonMan> what's the output of --verbose-link for river? finding all the libs and ldd-ing them should give you a pretty complete dependency graph
<ifreund> I know that wayland-client and wayland-server depend on libffi
<TheLemonMan> ok, try running the link step using your system ld instead of using lld
<TheLemonMan> that's to rule out some newly-introduced change in the linker
<ifreund> gimme a minute, rebuilding master zig now
r4pr0n has quit [Remote host closed the connection]
r4pr0n has joined #zig
<ifreund> hmm, my system ld says "ld: warning: cannot find entry symbol rror-limit=0; not setting start address"
<TheLemonMan> yeah, drop the -error-limit switch
<ifreund> this is the command I tried:
<TheLemonMan> that's not supported by GNU ld
<ifreund> sysetem ld works, no runtime error about not being able to find libffi
<ifreund> guess that's a lld regression then?
<ifreund> or just a change in behavior? I'm not sure if the new behavior is wrong or not
<TheLemonMan> do you have lld-11 installed?
<ifreund> yeah I think so
<ifreund> TheLemonMan: yep, lld-11 works
<TheLemonMan> great, is your system beefy enough to run a LLVM bisection run?
<ifreund> i've got a beefy cpu but only 16 gigs of ram
<TheLemonMan> "only"
<ifreund> don't have time to try that today though, gotta get some other work done
<ifreund> TheLemonMan: heh, so you're saying I should be fine I guess :D
mq32 is now known as ikskuh
zenkuro has quit [Ping timeout: 252 seconds]
r4pr0n has quit [Quit: r4pr0n]
zenkuro has joined #zig
Anzh has quit [Ping timeout: 240 seconds]
Anzh has joined #zig
Anzh has quit [Client Quit]
marler8997 has quit [Ping timeout: 252 seconds]
Anzh has joined #zig
Anzh has quit [Ping timeout: 268 seconds]
waleee-cl has joined #zig
johannes_ has quit [Ping timeout: 265 seconds]
Anzh has joined #zig
Anzh has quit [Client Quit]
tefter has quit [Ping timeout: 252 seconds]
dmgk has joined #zig
zenkuro has quit [Ping timeout: 246 seconds]
Akuli has joined #zig
novakane has quit [Quit: WeeChat 3.1]
tefter has joined #zig
novakane has joined #zig
xackus__ has joined #zig
B767B has joined #zig
Bernstein_ has quit [Remote host closed the connection]
cole-h has joined #zig
gpanders has quit [Ping timeout: 252 seconds]
gpanders has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
gpanders has quit [Ping timeout: 246 seconds]
hiljusti has joined #zig
fritchie has joined #zig
gpanders has joined #zig
nvmd has quit [Quit: Later nerds.]
novakane has quit [Quit: WeeChat 3.1]
novakane has joined #zig
novakane has quit [Client Quit]
novakane has joined #zig
novakane has quit [Client Quit]
novakane has joined #zig
<TheLemonMan> koakuma, give this patch a try
notzmv has quit [Ping timeout: 240 seconds]
<TheLemonMan> I'm more and more convinced that we should write down the syscall stubs (and the clone impl) in some stand-alone .S file
<TheLemonMan> andrewrk, what do you think? would that be hard to integrate into the build system?
<andrewrk> still catching up on the conversation
<TheLemonMan> well, the problem is that we're hitting a few LLVM bugs in the inline asm handling when targeting SPARC, but in general we'd have some leaner and faster syscall entry points where we can precisely control how the parameters are forwarded to the kernel
<TheLemonMan> and clone() has a huge problem, it's defined as a naked function... in c.zig
<TheLemonMan> the problem is that, when optimizations are turned on, you can't really call a naked function defined in the same CU
<TheLemonMan> because LLVM sees trough all your shenanigans (eg. casting the fn to a non-naked CC) and eventually does something bad with it
<TheLemonMan> such as corrupting the input registers/frame
<TheLemonMan> you also wrote a comment about that in c.zig heh
notzmv has joined #zig
<andrewrk> ifreund, are you trying to upgrade river from 0.7.1 to master branch?
<ifreund> andrewrk: no, I was just making a 0.8.0 branch for zig-wayland so someone who was interested could play around with upgrading the code generation to use the new std.fmt fanciness
<ifreund> to be clear, everything works fine if I explicitly link libffi, it just seems weird that the behavior of lld changed
<andrewrk> agreed
tefter has quit [Ping timeout: 240 seconds]
tefter has joined #zig
<mikdusan> ifreund: do you have anything in progress re: *bsd hosted-lib linking ? it's pretty much broken now and I need to get some fixes in
<andrewrk> TheLemonMan, ok I'm thinking about the inline asm thing. damn, I really like the tight integration with inline asm. are you sure we can't fix the problems with a some combination of language modifications + lowering to LLVM IR in a more careful way?
hiljusti has quit [Ping timeout: 260 seconds]
notzmv has quit [Ping timeout: 240 seconds]
<TheLemonMan> I'll try to dig a bit more to see if LLVM can be convinced to leave the naked fns alone
<ifreund> mikdusan: No I haven't started anything yet, sorry for breaking things
<ifreund> I'll probably get to it later this evening unless someone else does it first
<ifreund> It should be as simple as adding a function to std.Target that returns the list of libc components that need to be linked and then using that over the current hardcoded list
<andrewrk> you could also put them in src/target.zig depending on whether it seems like a compiler implementation detail, or an interesting property of a particular target
<ifreund> ah, yeah src/target.zig is probably better
<andrewrk> TheLemonMan, I'm reluctant to give up the property that a compilation can start with .zig code as a root source file, and load only other .zig files, and be able to do syscalls. I don't want to shut down your efforts here but I do want to make sure we're exploring all the options. we'd definitely be giving up a certain cross-section of simplicity by trying to bring in assembly files into the mix
<andrewrk> but yeah I just re-read my own comment on top of fn clone and that TODO has just been sitting there for years now
<andrewrk> I think the first question that needs answering is, which of the three problems is this? (1) a soundness problem in the language? (2) a problem with lowering to sound LLVM IR? (3) bug(s) in LLVM?
<andrewrk> I might want to recruit Martin to help with this question
<mikdusan> ifreund: re: some libs are omitted if specified like -lcrypt; I saw ref in irclogs recently but didn't pay attention, but do you know why we eat libc library names and prevent them from going into system_libs ?
guccimayne has left #zig ["Leaving"]
<andrewrk> mikdusan, it's because until now we wanted to be in charge of providing libc
<andrewrk> so we treated "link libc" as a single bit, yes/no
<andrewrk> I still think that might be the right approach
<mikdusan> I'm thinking we let all -lfoo go into system_libs, and then at link-time, we dupe system_libs, and pull out the ones that are ordered, add to argv, then in ordered fashion add the special ones to argv
<mikdusan> i worded that goofy. but this lets us not assume which libs need to be on command line
<andrewrk> if zig is providing libc, we need to know if -lfoo is a non-libc system dependency, or if it is one that we will be providing with libc
<mikdusan> sure but we need to _track_ if crypt or pthread or m is needed
<andrewrk> why?
<mikdusan> and isn't that the spec'd by build.zig author ?
<mikdusan> well right now,
<mikdusan> `-lm -lpthread -lc -dl -lrt -lutil` is added
<TheLemonMan> andrewrk, I hear you, having everything into a single .zig file is a nice property
<mikdusan> and we don't need to link .so if not needed, right?
<TheLemonMan> in my notes I've found that you can avoid many problems by 1) marking the function noinline 2) not putting an unreachable as last instruction
<TheLemonMan> the former avoids inlining and the latter... well, that's sort-of correct as you're messing with the reachability analisys
<TheLemonMan> I think clone() would be ok with just a noinline
<TheLemonMan> __clzsi_arm32 is another example of this problem, as I wrote in clzsi2_test.zig
<andrewrk> back in a bit, food
<TheLemonMan> alright, stage1 is also buggy af and prevents you from calling a naked function even after casting it
<motiejus> andrewrk: thanks for your comment in ; but I missing on what happens once the command-line arguments are parsed and interpreted? My intial idea was to detect `zig ar`, and then call llvm-project/llvm/tools/llvm-ar/llvm-ar.cpp's `int main`.
<TheLemonMan> motiejus, you may want to talk with kubkon about that, he re-implemented part of the archive reading for his linker work
<motiejus> ok, what's the protocol? is he on IRC? Shall I ping him on github?
<TheLemonMan> I think he's on the Discord server
<g-w1> he is on github and discord. he does not use irc that much
<motiejus> I will ping on github then
<motiejus> thanks
Exonorid has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<g-w1> motiejus: i think what is going to happen, is that zig will just use it's own ar
<g-w1> i think kubkon already did a decoder with Zld
<motiejus> that means, if I want an `ar`-compatible `zig` subcommand, I'd need to reimplement the front-end in zig?
<g-w1> i think `zig ar` will be all zig
<motiejus> i.e. `ar d`, `ar m`, etc
<motiejus> if that's true, then it's quite a bit more involved (and does not fit/belong to src/main.zig ?)
<g-w1> well zig already can do libraries with `build-lib` so all it would have do to is parse the args in a different way
<mikdusan> zig puts everything into 1 executable
hiljusti has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
lemur has joined #zig
<ifreund> mikdusan: We don't need to no, but I'm not sure if there's any real cost associated with doing so. This is essentially the status quo as until now we have defaulted to using the libcs shipped with zig and linking all components thereof
<ifreund> if there is a demonstrable cost to linking 3-4 shared object that aren't used, we should reconsider this
<ifreund> I think that's probably better done down the line, I need to wash some dishes then I will fix the build for OpenBSD
koakuma has quit [Read error: Connection reset by peer]
B767B has quit [Ping timeout: 265 seconds]
<mikdusan> ifreund:
<mikdusan> that is a cost
<mikdusan> we also have `zig cc` drop in replacement. Start linking libs that `cc` doesn't and it won't go down well a lot of devs, imo
<mikdusan> and sure we can diverge behavior from `zig cc` and `zig build-*`
<mikdusan> but what's involved in knocking that list down, really? it's not much
<mikdusan> invariant 1: link what we know or detect to be minimum libc requirement
<mikdusan> then for each lib known to have ordering requirements, pull it out of libs-list,
<ifreund> mikdusan: it's probably not that hard to implement, but we end up breaking all code that relies on -lc to pull in the rest of the components
<mikdusan> add that set remaining to argv, then as needed, add each ordered lib, if it was specified.
<mikdusan> i'm not following, which code?
<ifreund> mikdusan: all code that links libc and uses e.g. pthreads right now
<mikdusan> pthreads is a special case btw. can't we just say `if builtin.single_threaded == true` add pthread?
<ifreund> what you are proposing is changing linking libc from a binary switch for *all* libc components to a more finely grained thing
<ifreund> no?
<mikdusan> that binary switch is precisely inadquate today
<ifreund> yeah I agree that we should change this, I'm just explaining that this is a pretty widely breaking thing
<ifreund> I'll just do a quick fix for OpenBSD and then look at how best to implement this
<mikdusan> netbsd is broken too
lemur has quit [Ping timeout: 240 seconds]
<mikdusan> status is: freebsd/dragonfly can tolerate the current list of .so always given
<mikdusan> and openbsd/netbsd cannot because they don't have... dl and rt (iirc)
<ifreund> mikdusan: ok, so the current list minus dl and rt is should be fine for openbsd/netbsd for now?
<mikdusan> just fyi, I'm not looking to make you do the work for that fix. it's easy enough to do. I'm more interested in how we solve this
<ifreund> mikdusan: hmm, one problem with making this switch non-binary, this would require changing std.builtin.link_libc from a bool to something else
<ifreund> or adding other bools for libm, libpthread, etc
<g-w1> does river work on openbsd?
<ifreund> very doubtful, it does work on freebsd though (and is packaged ;D)
<mikdusan> ifreund: hmm not grok'ing that. I assumed the quick fix would be a switch on os.tag around the currrent code
<mikdusan> and what about the other funky libs xnet, resolv
<mikdusan> crypt
<ifreund> mikdusan: oh that "one problem" wasn't regarding the quick fix
<ifreund> yeah, just a switch on os.tag but in src/target.zig cause that's a little cleaner
<ifreund> I don't really know what's up with xnet/resolv/crypt
<ifreund> is libc required to provide those?
notzmv has joined #zig
<mikdusan> well I'll answer that more generally. if zig std references symbols, on some platforms (like macos) they're all fronted by one libSystem. on others they're mostly offered by libc, then some platforms deviate which lib which sym is found in,
<mikdusan> so the answer is always going to be host-specific
sord937 has quit [Quit: sord937]
<mikdusan> I view this as a problem that `./configure` or `cmake` has generally solved
<ifreund> which is why our current binary switch is very convienient for cross compiling and cross platform code
recalloc has joined #zig
<mikdusan> cross-compiling is a little different, zig is in full control there
<mikdusan> but host-libc not so much
leon-p has quit [Quit: leaving]
<ifreund> when cross compiling we always link all the libc components no?
<recalloc> I'm looking into the STL and found that some structs use const `Self = @This()`, and others use `This` instead. Is intentional, something historic, or something else?
<g-w1> stl? ;)
<recalloc> sorry, std :)
<g-w1> well anyways, i don't think its intentional.
<recalloc> oh wait, I don't see `This` used at all actually. Where did I see it, then?
<ifreund> grep doesn't find any `const This = @This()` in the std
<mikdusan> ifreund: there's many kinds of cross. glibc .so or musl static?
<g-w1> maybe just self: @This()
<recalloc> I was going to ask which is current practice, but I guess I've answered my own question
<ifreund> mikdusan: glibc is the only one one where we provide multiple so files
<mikdusan> ifreund: for glibc cross the result:,,,,, <-- so the same set
<ifreund> recalloc: I think best practice is to not use `const Self = @This()` unless writing generic code
<ifreund> mikdusan: yep, I copied the full list I'm using from there
<ifreund> because that was the status quo for almost all zig code linking libc
<recalloc> Looks like generic code use `Self = @This()` too, at least specifically struct-returning-functions.
<oats> Why is `const = @This();` discouraged?
<g-w1> because its wrong syntax
<oats> Oh uhhh const whatever
<g-w1> and its verbose
<oats> Shaddup I'm on my phone :P
<ifreund> recalloc: yes, generic code is the only place I'd recomment the `const Self = @This()` convention
<oats> Should one just use @This() directly at point-of-use?
<oats> Such as in a top-level struct
<ifreund> no, just use the name of your struct and avoid @This() unless it is needed
<g-w1> or const FileName = @This(); for struct files
<oats> OK so struct files are a valid use for that
<mikdusan> ifreund: so looking at glibc source code, seems that { crypt, resolv } are part of it
<mikdusan> but not part of zig's bundled glibc
<ifreund> hrm, does musl provide those?
* mikdusan downloads it....
<ifreund> iirc it doesn't and for some good reason or another
* mikdusan boots alpinelinux to poke around a musl-based os
<ifreund> mikdusan: anyhow, I did the short term fix
<ifreund> a quick test on net/open bsd would be appreciated if you wouldn't mind
<mikdusan> looks like crypt/ subfolder in musl official sources. no resolv/ though
<mikdusan> heh alpine has a bunch of .a that have this content:
<mikdusan> !<arch>
<mikdusan> and that's it. for crypt.a, dl.a, m.a, ptherad.a, resolv.a, rt.a, util.a xnet.a
* mikdusan shrugs
<mikdusan> checking that PR now
<ifreund> mikdusan: musl puts everything in
* mikdusan watches as zig boils oceans and evaporates 28 GB of my RAM
<mikdusan> yup that PR looks good
<mikdusan> #8754
<mikdusan> pronouns. what could go wrong?
<mikdusan> ifreund: btw, thanks for the fix
<mikdusan> now we just need some ci for openbsd, netbsd and dragonfly
<ifreund> mikdusan: no problem, thanks for testing
<ifreund> yeah, CI for those would have prevented this in the first place
novakane has quit [Quit: WeeChat 3.1]
waleee-cl has joined #zig
ur5us has joined #zig
Spex_guy has joined #zig
<Spex_guy> Hey, anybody know how write-after-read memory hazards affect performance?  Specifically looking at a loop like this:
<Spex_guy> I haven't been able to find any resources on it, but it seems like in theory, since the address is computed, the processor wouldn't realize these are the same memory address until late in the pipeline.  Once that happens it would have to flush and restart at the read, similar to a branch mispredict.  Unless the issue unit is smart enough to avoid
<Spex_guy> this somehow?
<mikdusan> I have no idea about any of that subject but maybe my googlefu is of help:
<Spex_guy> Yeah, I couldn't find much that was relevant.  That lecture and most of the other things I found are about register write-after-read, which is usually resolved in the rename unit before issue, so in that case the processor already knows about the dependency and can delay one of the instructions.
nvmd has joined #zig
tefter_ has joined #zig
zenkuro has joined #zig
tefter has quit [Ping timeout: 252 seconds]
Akuli has quit [Quit: Leaving]
<ifreund> ooo, #8756 looks juicy
bitmapper has joined #zig
txdv has quit [Ping timeout: 252 seconds]
v0idify has joined #zig
<ifreund> hmm, now that we have std.mem.sliceTo() I feel like std.mem.span() should be std.mem.slice()
Nypsie has quit [Ping timeout: 258 seconds]
v0idify has left #zig [#zig]
Nypsie has joined #zig
<andrewrk> ifreund, I think I was considering renaming slices to spans
<andrewrk> std.mem.span was "let's try this name on"
<andrewrk> but I agree with you
<ifreund> andrewrk: cool, I'll get that PR'd tomorrow
<ifreund> and I should probably update the std for these changes as well
<ifreund> pretty happy with how the API of sliceTo() turned out :)
<mikdusan> 👍👍 for shorter stack traces. oh yes.
<mikdusan> pgup/dn keys are finally gonna get a break :)
<g-w1> which pr is that?
<g-w1> or is it committed?
<mikdusan> i think this one did it: c3d4733a00880e2c757b61b66ba18d9b6753aa11
<g-w1> thanks
ur5us has quit [Ping timeout: 250 seconds]
v0idify has joined #zig
<v0idify> i'm getting "segfault at address 0x10" when trying to get something from a std.event.Channel, i initialized just like in the tests
gpanders has quit [Ping timeout: 240 seconds]
koakuma has joined #zig
ur5us has joined #zig
xackus__ has quit [Remote host closed the connection]
<mikdusan> is the indent representing an inner scope of some kind? if so, how is self escaping to outer scope?
xackus__ has joined #zig
<mikdusan> and what is up with `var self =` ?
v0idify has quit [Ping timeout: 240 seconds]
gpanders has joined #zig
<andrewrk> mikdusan, don't get too excited, I didn't solve the problem generally
<andrewrk> (yet)
<g-w1> I am trying to write a shell (, and is blocking some parts of it. what are the next steps for me to try to resolve it? it seems to me like the best thing is to create a new stdio mode
v0idify has joined #zig
<andrewrk> if you're writing a shell, std.ChildProcess might be too high level of an API. you might want to reach into std.os for that
<g-w1> Thats what i thought at first, but then thought it could also be fun to improve ChildProcess. Ill take a look at std.os
<andrewrk> it's possible that we could add that feature to std.ChildProcess. the first step would be doing an inventory of what features are possible on various targets
<andrewrk> some targets in particular to consider are: Windows, WASI
<andrewrk> can still add a feature that is not supported everywhere, but requires special consideration
<g-w1> seems like windows has pipes (at least powershell has them, so it must be able to be done), not sure about wasi
Exonorid has quit [Remote host closed the connection]
<g-w1> what is the point of if pipes between processes don't work?
<mikdusan> don't work?
<g-w1> see the issue above
<g-w1> after reading the source code, it seems they are used for collecting the output, hmmmm. maybe i have a flawed understanding of stuff
<mikdusan> you can pipe to 1 child. that's still a pipe
<g-w1> how do you define child?
<mikdusan> fork()
<g-w1> (I am talking about ChildProcess right now)
<g-w1> ah you mean you can pipe stuff to it through write on stdin?
<g-w1> or read on stdout?
<mikdusan> yes, a good example is `pub fn exec()` . it does the setup for that to read stdout/stderr from the fork'd child
<mikdusan> fork being the posix path.
sm2n has quit [Ping timeout: 252 seconds]
<mikdusan> #7738 is re: creating 2 child procs, and setting up pipe from one to the other
<mikdusan> if you're looking for a generic spawn() api that does it all, the api design can be a little complex.
<g-w1> ok i think ill try the suggestion by vesim then with passthrough
<g-w1> does that seem correct?
<mikdusan> is this for your shell?
<g-w1> firstly to solve that issue, then for the shell