ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
return0e has joined #zig
return0e_ has quit [Ping timeout: 246 seconds]
tgschultz has quit [Ping timeout: 255 seconds]
<scientes> something is broken regarding error sets in comptime
tridactyla has quit [Remote host closed the connection]
tridactyla has joined #zig
scientes has quit [Remote host closed the connection]
scientes has joined #zig
<scientes> my program crashes writing to 0x1 despite the mmap() succeeding, if I add a debug statement printing the address, the bug disappears :/
<scientes> there is some over-eager pruning going on somewhere--also doesn't show up in debug mode
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
return0e_ has quit [Ping timeout: 250 seconds]
scientes has quit [Ping timeout: 246 seconds]
tgschultz has joined #zig
return0e has joined #zig
_whitelogger has joined #zig
return0e has quit [Ping timeout: 246 seconds]
_whitelogger has joined #zig
jjido has joined #zig
_whitelogger has joined #zig
wootehfoot has joined #zig
_whitelogger has joined #zig
return0e has joined #zig
Zaab1t has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
scientes has joined #zig
Ichorio has joined #zig
jjido has joined #zig
scientes has quit [Ping timeout: 246 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgschultz has quit [Ping timeout: 245 seconds]
scientes has joined #zig
_whitelogger has joined #zig
return0e has quit [Ping timeout: 245 seconds]
scientes has quit [Read error: Connection reset by peer]
a_chou has joined #zig
jjido has joined #zig
a_chou has quit [Ping timeout: 250 seconds]
scientes has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has quit [Ping timeout: 250 seconds]
a_chou has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
a_chou has quit [Client Quit]
Zaab1t has joined #zig
<mikdusan> on zig command line; would like to pass args to main run by “zig run [source]” . i don’t see any command-line options for that
<andrewrk> mikdusan, I think I broke that, sorry. It's supposed to be any args after the positional [source] argument
<mikdusan> do you think there is value in creating a consistent sub-process args syntax a’la unix style? double-hyphen
<mikdusan> zig run main.zig — 1 2 3
<mikdusan> or
<mikdusan> zig test main.zig —test-filter … — 1 2 3
<andrewrk> tests don't have the capability of accepting user args
<andrewrk> as for the other one, I think if it were `zig run` it would make sense to do the double hyphen. but if we do https://github.com/ziglang/zig/issues/1505 then it would make sense to take args after the source as runtime args
<andrewrk> I'm reconsidering though about zig run. not sure what to do. anyway in the meantime mikdusan if you are thinking of submitting a pull request to enable passing runtime args to zig run, I would merge it however you decided to do it
jjido has joined #zig
<mikdusan> i need to install a linux vm to investigate this further. /usr/bin/env on macos is splitting on whitespace.
<hryx> andrewrk: I marked #2144 as ready -- do you want me to squash & rebase into 1 commit before it's merged?
<hryx> Not sure which way you prefer in general
<hryx> Sorry, I'll comment on the PR. Just realized I'm fragmenting the conversation by asking here
scientes has quit [Ping timeout: 245 seconds]
<andrewrk> hryx, nice work
<hryx> thankee, very happy to finally have made a contribution to the code
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgschultz has joined #zig
jjido has joined #zig
Zaab1t has quit [Quit: bye bye friends]
<mikdusan> i think a lot of #!/usr/bin/env use is unecessary. if you need to modify ENV vars then it makes sense. unfortunately /usr/bin/env itself is creating the dilemma because between linux’ /usr/bin/env, gnu’s newer version, and bsd older/newer… it’s a bit of a mess.
<mikdusan> funny thing is; this works predictably on both linux and macos. —> #!zig run -one -two -three
<andrewrk> mmm that does not match my experience
tankf33der has joined #zig
<tankf33der> andrewrk: ping
<andrewrk> the args passed would be "-one -two -three", rather than the expected "-one" "-two" "-three"
<tankf33der> o/
<andrewrk> hi tankf33der
<tankf33der> there is compile error
<mikdusan> `#!zig run -one -two -three` ends up as —> arg[0] = “run -one -two -three” and arg[1] = “zig” or if zig is found in path “/path/to/zig” . so 2 args.
<mikdusan> the docs i found on this is before freebsd 6.0, this 2-arg behavior didn’t exist. i don’t know how far back linux 2-arg behaviour goes.
<andrewrk> tankf33der, I suggest to upgrade to master branch rather than 0.3.0. because 0.4.0 is to be released in 8 days from now
<tankf33der> now i just compilation.
<tankf33der> now i just need compilation.
<andrewrk> tankf33der, I suggest you achieve compilation with master branch rather than 0.3.0
<tankf33der> ok, i see.
<tankf33der> will it help here ?
<andrewrk> yes
<tankf33der> recompiling.
<tankf33der> i see.
<andrewrk> because of C pointer types
<mikdusan> the interesting thing is this DIRECT shebang is stil workable even before 2-arg behavior. if it does split, it’s still consistent in that the LAST arg would always be the arg[0] to shebang line.
<mikdusan> so /usr/bin/env compats aside, from what it looks like #!zig would work. obviously there is no mechanism for ENV var modifications.
<andrewrk> tankf33der, this example can help you see how to update build.zig: https://github.com/mikdusan/benchmark.unicode/blob/master/build.zig
<hryx> Is there an example of another compiled language which supports shebang?
<andrewrk> now zig compiles C code with libclang rather than system C compiler
<andrewrk> hryx, D
<hryx> Ah
<hryx> I'm still curious if it's actually useful
<andrewrk> I'm starting to think it is not very useful
<tankf33der> sleep. thanks.
tankf33der has left #zig [#zig]
<mikdusan> all the details aside, yeah i don’t find it too useful. neat tho.
<mikdusan> i’ll move forward on a pr to enable passing runtime args to zig run
<hryx> 8 days. we got lots of time to remove stuff before the next release °u°
<andrewrk> yes, time to remove a lot of bugs
jjido has quit [Read error: Connection reset by peer]
* strmpnk cheers. llvm 8 is now in the main arch repos. Recompiling my outdated master build (avoiding the LLVM 8 build that I kept putting off).
<andrewrk> welcome to master branch
Ichorio has quit [Ping timeout: 250 seconds]
<mikdusan> what looks better in usage?
<mikdusan> —> run [source] [—] [args]
<mikdusan> —> run [source] [— [args]]
<hryx> don't they mean different things?
<andrewrk> mikdusan, it's a bit confusing because your IRC client is collapsing -- into —
<mikdusan> oh.
<mikdusan> so it’s not 100% required, but i’d like a way to show that double-hyphen needs to proceed executable arguments.
<mikdusan> in help usage.
<andrewrk> ahh in usage text
<andrewrk> the second one I think is clearer
<mikdusan> (i did a typo. proceed should be *precede). ok i’ll go with second one.
wootehfoot has quit [Read error: Connection reset by peer]
scientes has joined #zig
shawn_ has joined #zig
scientes has quit [Ping timeout: 246 seconds]
<andrewrk> thanks mikdusan
<shawn_> mikdusan, splitting in sh is effected by the IFS environment variable, just a heads up
shawn_ is now known as scientes
_whitelogger has joined #zig
<hryx> On master, when I make a test fail, it spews a stack trace forever, seemingly in a loop
<hryx> is this known?
<hryx> doesn't matter what test
<andrewrk> uhh I think that's a new bug
<hryx> daym
<hryx> I noticed last night while working on the column alignment ticket. I get it for both macOS and linux
<andrewrk> it's probably in std.debug.writeStackTrace
<andrewrk> 00d8f4a1bb634ec5b0569e6ff6c2679ade2bd6b0 is suspect
<emekankurumeh[m]> i don't think it's an infinite loop
<emekankurumeh[m]> it's just a really long stack trace
<hryx> want me to see how long it goes?
<andrewrk> I'm pretty sure there's a bug. the most frames it should ever print is 32
<emekankurumeh[m]> hmm, on second glance it just loops printing the stack trace
<andrewrk> this is also related to https://github.com/ziglang/zig/issues/1923
<hryx> I'll make a ticket real quick
<emekankurumeh[m]> hryx: you'll need to update that second example because that build got deleted
<hryx> oh, wack
<hryx> it was there a minute ago! I'll see if I can find another (or just remove it)
<andrewrk> build logs are ephemeral
<hryx> aren't we all
<emekankurumeh[m]> is this a problem with zig or the testing api
shawn_ has joined #zig
scientes has quit [Disconnected by services]
shawn_ is now known as scientes
<hryx> ok, I fixed the link
shawn_ has joined #zig
scientes has quit [Disconnected by services]
shawn_ is now known as scientes
shritesh has joined #zig
shritesh has quit []
<scientes> yes agree
<andrewrk> scientes, we already have robust futexes in std/mutex.zig
<andrewrk> have you looked at the code?
<scientes> I wrote that linux code
<hryx> more juicy fmt fixes https://github.com/ziglang/zig/pull/2153
<andrewrk> yes I thought so
<andrewrk> so what's this about robust futexes for linux then?
<scientes> its mutexes between processes
<scientes> because otherwise when a process dies it still holds the locks
<scientes> this allows the kernel to release its locks when it dies
<mikdusan> “robust” as in the OS guarantees some kind of unlock/cleanup
<scientes> exactly
<andrewrk> zig does not currently have a cross platform abstraction for a mutex shareable between processes
<andrewrk> nor does it currently have an abstraction for a linux-specific mutex shareable between processes
<andrewrk> ok, now I understand scientes, you are proposing such a thing
<scientes> yeah, it doesn't make sense to share between processes unless you make them robust
<mikdusan> scientes: can u point me to the issue/proposal
<andrewrk> agreed. note that current mutex implementation is robust, however, since it is not shared between processes, there is no problem with resource cleanup
<andrewrk> hryx, looking now
<hryx> tite
<scientes> mikdusan, https://github.com/ziglang/zig/issues/1455 and this blog post that complains about the limitations of glibc https://keithp.com/blogs/Shared_Memory_Fences/
<andrewrk> scientes, that's not a proposal for an abstraction for mutexes shared across processes