<shachaf>
OK, I submitted it via the thing, and I'll just delete the fork later.
tomku has joined #zig
<andrewrk>
thanks
marijnfs has quit [Quit: WeeChat 2.8]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
earnestly has quit [Ping timeout: 252 seconds]
epmills has joined #zig
epmills has quit [Quit: Connection closed]
ur5us__ has joined #zig
zenkuro has quit [Ping timeout: 252 seconds]
selby has quit [Quit: My MacBook has gone to sleep.]
selby has joined #zig
selby has quit [Client Quit]
xackus__ has quit [Ping timeout: 252 seconds]
<mikdusan>
andrewrk: feeling pretty good about #8601. it runs what tests it can `-Dskip-debug`, builds build.exe as release; some tests like compile-errors and generating docs are still disabled because they have debug path,
<mikdusan>
other "main change" is tests are broken into 3 groups and parallelized in the pipeline. it's a roll of the dice with cavium speed.. very slow, so we need a way to cut wall time
<shachaf>
andrewrk: Hmm, it's pretty hard to benchmark these things because of all the variance, but it does look like the program is a bit slower with my change.
<shachaf>
Is it possible to make a table indexed by token types, rather than use a big switch like I wrote it?
ur5us__ has quit [Ping timeout: 245 seconds]
siraben has joined #zig
<andrewrk>
mikdusan, nice work
<andrewrk>
shachaf, yes
<shachaf>
What would be a standard way to set that up?
<andrewrk>
are you switching on any token, or a subset?
selby has joined #zig
<shachaf>
Potentially any token.
<shachaf>
The goal is just to get from a token to information about it, like its precedence.
SLWW_ has quit [Read error: Connection reset by peer]
<andrewrk>
std.enums.directEnumArray
SLWW has joined #zig
<shachaf>
Aha.
<g-w1>
andrewrk: im not sure the compact layout of data.js makes sense in my case since I don't de duplicate stuff like stage1 does (multiple things can refer to a single index). im designing a similar format right now that fits my use cases right now
<shachaf>
I think I'm confused about how to use directEnumArray. It looks like it doesn't support default values, because init_values: EnumFieldStruct(E, Data, null)?
<shachaf>
Oh, I see, there's a second one that supports a default.
<shachaf>
And you can't explicitly be calling EnumFieldStruct because each instantiation is a separate type, or something like that?
<andrewrk>
if you need default values you probably want a subset
<shachaf>
Maybe I misunderstood, what do you have in mind for a subset?
waleee-cl has quit [Quit: Connection closed for inactivity]
<g-w1>
hopefully i can figure out how do interface it with the js. does this look sane? https://clbin.com/yhAXi
<g-w1>
where [start, end] is essentially a slice into decls
<shachaf>
OK, the real conclusion is that this is way too variable to give any good benchmarks of.
<shachaf>
I have a version that uses directEnumArrayDefault. I can push that, it seems plausibly better, I guess. I'm not sure what the switch is being compiled into, actually.
outerpassage has joined #zig
selby has quit [Quit: My MacBook has gone to sleep.]
selby has joined #zig
selby has quit [Ping timeout: 240 seconds]
<andrewrk>
try using `-r` with `perf stat`
cole-h has quit [Ping timeout: 268 seconds]
TheLemonMan has joined #zig
<TheLemonMan>
koakuma, removing "generic" is not the right solution
<TheLemonMan>
I think that overriding detectNativeCpuAndFeatures will solve your problem
<mikdusan>
also target/sparc.zig: //! This file is auto-generated by tools/update_cpu_features.zig
<koakuma>
Oh sorry, will revert
<koakuma>
So I need to special-case it in detectNativeCpuAndFeatures instead?
halbeno has quit [Remote host closed the connection]
halbeno has joined #zig
<TheLemonMan>
yep, the .sparcv9 -> v9 association is all the autodetection you need heh
<TheLemonMan>
side note, that will only work for zig and not for zig0
<koakuma>
zig0 seems to work more-or-less correctly here so it shouldn't be an issue there (?)
pretty_dumm_guy has joined #zig
ovf has joined #zig
<mikdusan>
zig0 is used with `-mcpu=baseline` which replaces the problematic `-mcpu=generic`
<wilsonk>
WTF are the odds that I start doing taxes today and the VM I am using ends up on an array that craps the bed!??!? Dual enterprise drives with 1 million hours uptime guaranteed and one fails after a year with very little use? WTF!!!!!
<TheLemonMan>
the universe it suggesting not to file taxes this year
<earnestly>
It is wise
<wilsonk>
Lol, yeah I suppose the Universe is saying that...but I am one of those silly Canadians that inexorably files and pays...no matter what stupid crap our government does with that money (self employed so I don't get a rebate, I always have to pay this time of year).
<earnestly>
You don't exactly have a choice
<wilsonk>
Thankfully, I have the VM backed up and continual backups of the important directories inside the VM to a separate file server. Worst case I can rebuild...just didn't want to be doing this tonight!!
<wilsonk>
A choice of filing my taxes?
<Raito_Bezarius>
is there a way to get my stack address in Zig?
<koakuma>
Is there a way to make zig0 be built in release/optimized mode but zig1.o and zig be built in debug mode? Waiting for zig1.o rebuilds gets boring after a while, haha
<xackus__>
koakuma: I think you need to edit CMakeLists.txt for that
SLWW has joined #zig
SLWW_ has quit [Ping timeout: 252 seconds]
leon-p has joined #zig
<mikdusan>
interesting. you basically are asking to build zig0 in release (but do not build zig1.o or zig). then launch another build, skip zig0, use zig0-release to build zig1.o (debug) and link zig
xackus has joined #zig
<koakuma>
Yeah
xackus__ has quit [Ping timeout: 240 seconds]
<koakuma>
I don't have fast CPU so optimized zig0 would really help when doing work on the codenbase
xackus_ has joined #zig
xackus has quit [Ping timeout: 246 seconds]
<TheLemonMan>
koakuma, do the behavior test pass for you? I tried running them under qemu and got a segfault in "recursive async function"
TheLemonMan has quit [Read error: Connection reset by peer]
TheLemonMan has joined #zig
<mikdusan>
koakuma: with this patch; to build debug zig, I noticed a drop from 75 to 52 seconds to build zig1.o with a release-version of zig0:
<companion_cube>
It matches how the wasm3 thing works, I think?
<companion_cube>
Funny how tailcalls are maybe not an ivory tower thing after all
TheLemonMan has joined #zig
dimenus has joined #zig
<TheLemonMan>
mikdusan, the new drone script is not running any of the test-translate-c or test-run-translated-c tests
<mikdusan>
right, because they hang on cavium
<TheLemonMan>
do they? is that a different problem than #8537 ?
notzmv has quit [Ping timeout: 252 seconds]
<g-w1>
asked this yesterday, but don't know if you saw it, could the drone test suite be made to only skip debug if the detected host is cavium?
<mikdusan>
I started from the full set and disabled stuff that hang at granularity of test-<whatever> . We managed to run a lot of the big test-std, test-behavior with a new -Dskip-debug option,
<mikdusan>
but can't generate docs, can run compiler-tests, unless someone wants to make sure we have an equiv -Dskip-debug option that pervasive to all the kinds of test harnesses
<mikdusan>
and there is another question too: -OReleaseFast _seems_ to be a workaround. But it's not guaranteed. We might yet see hangs if test-std for example has a bonafide panic as a result of PR changes
<TheLemonMan>
it is guaranteed, the problem is showing up with the register allocator used at -O0
<mikdusan>
that's good. so yeah to get the rest of the test coverage would require adapting for pervasive skip-debug wherever it is missing
<TheLemonMan>
I've re-enabled them in 8616, hopefully the PR won't be tested on the cavium host
<mikdusan>
here's an example: test/tests.zig: CompileErrorContext.addCase() hardcodes .Debug
<TheLemonMan>
a better solution would be to patch the LLVM copy used by the CI
<mikdusan>
indeed
<mikdusan>
I view this change to drone testing as temporary until we get LLVM fixed. then it can be restored (but keep the parallel pipeline changes)
wootehfoot has quit [Quit: Leaving]
<mikdusan>
I haven't looked deep but test/src/translate_c.zig doesn't have any mode/debug stuff so it's all defaulting to debug explaining why it hangs
waleee-cl has joined #zig
<mikdusan>
TheLemonMan: you rolled cavium
<TheLemonMan>
well, shit
cole-h has joined #zig
<mikdusan>
the tell is speed: line 241,242 - if it takes ~800s then cavium otherwise usually about 350s Falkor
<mikdusan>
build log, zig1.o
<koakuma>
mikdusan: That patch reduced zig1 build time from over 25 mins to 17 mins here, pretty significant improvement I'd say
<koakuma>
TheLemonMan, I'm getting a lot of error: container '.cimport:4:11' has no member called 'LIGHTGRAY' errors when doing behavior tests but I don't see any segfaults
<mikdusan>
re drone: sucky part is (I think) drone lets us have 2 pipelines and when they finish in 30 mins (falkor) or 80 mins (cavium) it's not too bad. but hang = 120 minutes.
<TheLemonMan>
koakuma, you need to -I the tests dir
<mikdusan>
koakuma: oh that is significant. What kind of host are you building on?
<TheLemonMan>
a sparc box!
<mikdusan>
oh is this the v9 that is 1995 ? :)
<koakuma>
Yeah, a 2008 SPARC T2 to be exact. It's not very good at single-threaded compute
<koakuma>
TheLemonMan, how do I do that? AFAIK the command is just `zig build test-behavior`, right?
<TheLemonMan>
koakuma, I do `zig test ../test/stage1/behavior.zig -I ../test`, don't really like zig build
<koakuma>
Okay, lemme try with that command
<koakuma>
Ah, I'm still getting the same cimport error
<TheLemonMan>
wait, are you getting 'has no member called' errors but no error about a missing .h file?
<TheLemonMan>
mikdusan, it'd be great to split the linux/azure pipeline and paralellize the pieces
<TheLemonMan>
running all the qemu tests takes a looong time
klltkr has joined #zig
<koakuma>
Mhm, I don't see anything about missing .h files. All I see are "container cimport has no member called XXXXXXXX" errors.
<mikdusan>
TheLemonMan: big timesaver. if the steps in a pipeline have access to shared folder then it should be doable just like drone
<TheLemonMan>
koakuma, uh, can you try running `zig translate-c` over the `translate_c_macros.h` file? I'm afraid clang it's erroring out somehow
<TheLemonMan>
mikdusan, no idea about how Azure works :\
<mikdusan>
if andrewrk is keen on parallel pipelining azure and srht I'll pursue it :)
<mikdusan>
add `--verbose-cimport --verbose-cc` to your `zig test` command-line
SLWW_ has joined #zig
SLWW has quit [Ping timeout: 246 seconds]
<koakuma>
I get this extra line but nothing really changed from the error output.
<koakuma>
info(compilation): C import output: ../test/stage1/zig-cache/o/3766966979cc483637f007172db43123/cimport.zig
<koakuma>
The insides of the file is the same with the one I posted in the gist.
<TheLemonMan>
nuke all the zig-cache folders and retry
<TheLemonMan>
you're missing all the default defines _and_ the macro definitions
<mikdusan>
try this: zig cc -E -Wp,-dM -xc /dev/null
<mikdusan>
slightly simpler: zig cc -E -dM -xc /dev/null
<andrewrk>
ifreund, oh yeah I do tail calls all over the place (but without musttail). that's why for example everything calls rvalue at the end instead of having expr() do it
<mikdusan>
TheLemonMan: wow how did your PR drone pass? cool.
<mikdusan>
TheLemonMan: oh... heh... all the _tests_ passed so no panic. that's why!
<TheLemonMan>
hah, that's the trick
<koakuma>
Noted. I'll try a run with clean cache folders and look at the output of the commands tomorrow.
<koakuma>
It's getting late here and I need some sleep, ahah
<mikdusan>
koakuma: related: zig-cache will get created in test/stage1/ too
<andrewrk>
mikdusan, the only thing I'm worried about is CI complexity/maintainability, but if you're willing to take it on I support your efforts :)
<mikdusan>
I have a few ideas of sharing #!/bin/sh scripts. make a few fundamental functions for the test breakup. I think we might be able to get there without too much extra complexity
<andrewrk>
we also have the option of pursuing parallelism in zig build rather than bash
<andrewrk>
e.g. doing all the compile error checks at the same time as other stuff
<mikdusan>
true. I'll first have to get a handle on the diff CI providers, wrt. virtual cpu per step, per job and need to consider log progress, parallel pipelines is a plus there
<mikdusan>
like the idea of zig build being able to do it of course. pipeline or not, that would be useful on local systems
<andrewrk>
see that's what I don't like, you're introducing a lot of vendor-specific logic, locking us in
<andrewrk>
I want to be able to jump ship
<andrewrk>
if we start relying on vendor-specific logic making the CI tests run fast enough to pass, we're really stuck
<andrewrk>
the zig build approach does not have this problem
<andrewrk>
s/you're/you would be/
<mikdusan>
sure, enhance zig build to do it all and only if good reason, spread zig build into smaller executions in pipeline parallel tasks
<andrewrk>
ifreund, oh heh I actually considered this approach when looking into #8220. main reason I decided not to is that tail calls are not supported on all architectures
<andrewrk>
"Unfortunately, the latest Dino implementation uses more than 256 byte code instructions." we're right at 256 with ZIR 😎
notzmv has joined #zig
notzmv has quit [Ping timeout: 252 seconds]
jokoon has joined #zig
<mikdusan>
koakuma: fyi the cmake patch can be simplified down to just 1 new cmake variable `ZIG0_EXECUTABLE` as _build0 can already be stopped at the right target by doing `ninja zig0`
jokoon has quit [Quit: Leaving]
SLWW has joined #zig
dyeplexer has quit [Remote host closed the connection]
SLWW_ has quit [Ping timeout: 246 seconds]
Bernstein has quit [Remote host closed the connection]
Bernstein has joined #zig
marler8997 has joined #zig
<marler8997>
andrewrk, wanted to gauge what direction you see the std lib going with windows bindings
<marler8997>
the std lib will always have some of the windows bindings I'm guessing yes?
<marler8997>
so what I'm thinking, is the extended/full set of windows bindings, would actually reference whatever is defined in the standard library
<marler8997>
for example, instead of defining it's own type for SOCKET's, it would just reference std.os.windows.SOCKET
Akuli has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]