<ericonr>
so the dlopen() sequence is succeeding, it's afterwards that's the problem (apparently)
frmdstryr has joined #zig
<pixelherodev>
Void in qemu to avoid driver issues?
<ericonr>
then vulkan doesn't work
a92 has joined #zig
hnOsmium0001 has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
<KIMI>
anytype will disapear in the future? it is ok if i use that right now?
msingle has joined #zig
<KIMI>
also one thing i asked but i didnt get the reply i think, about type inference in struct like .name = "myname" so i don't have to type the array thing all the time
<KIMI>
is it possible?
<g-w1>
in struct definitions, type inference is not possible, but in making structs it is. it would help if you gave a more complete example
<KIMI>
like i have there glyphs: [MAX_GLYPHS]?*Glyph = [MAX_GLYPHS]?*Glyph{null} ** MAX_GLYPHS,
<KIMI>
xD
<g-w1>
it is not possible to remove the type there.
<KIMI>
is it possible in the future?
<g-w1>
no. it is for the same reason that function arguments can't be inferred (not counting anytype which shouldn't be used for that anyway): it is to make a stable api. when you go to a function or struct definition, you should be able to see the type signature.
<dominikh>
I mean, in that line, the type information _is_ duplicated
<dominikh>
the right hand side could, if such syntax existed, be written without the array type, and the lhs still explicitly and specifically describes the API
<dominikh>
just like you have .{} for structs
<KIMI>
that would be nice to have less to type
reductum has quit [Quit: WeeChat 2.9]
<g-w1>
could you do glyphs: [MAX_GLYPHS]?*Glyph = [_]?*Glyph{null} ** MAX_GLYPHS,?
<KIMI>
it works, but it is still too long in my opiunion
<KIMI>
because the array is typed twice as dominikh said
<KIMI>
in var it is good because i can have type inference, just in struct it is a big too long to type
Jeanne-Kamikaze has quit [Ping timeout: 260 seconds]
frmdstryr has quit [Ping timeout: 246 seconds]
a92 has quit [Quit: My presence will now cease]
<fengb>
This might work: `var glyphs = std.mem.zeroes([MAX_GLYPHS]?*Glyph);`
<KIMI>
not in struct
<KIMI>
struct need : TheType
<KIMI>
that is why i asked
<fengb>
Oh yeah, there’s a proposal for using the default to infer the type
msingle has quit [Ping timeout: 240 seconds]
msingle has joined #zig
earnestly has quit [Ping timeout: 264 seconds]
<pixelherodev>
Eh, I don't like that
<pixelherodev>
Explicit is almost always better than implicit
msingle has quit [Ping timeout: 240 seconds]
msingle has joined #zig
<pixelherodev>
Wait, why would I comment on that *here*? :P
<KIMI>
or maybe . {null ** MAX_GLYPH} just like for struct
KIMI has quit [Remote host closed the connection]
msingle has quit [Ping timeout: 256 seconds]
frmdstryr has joined #zig
msingle has joined #zig
frmdstryr has quit [Ping timeout: 246 seconds]
frmdstryr has joined #zig
KIMI has joined #zig
marler8997_ has joined #zig
marler8997 has quit [Read error: Connection reset by peer]
frmdstryr has quit [Ping timeout: 240 seconds]
segfaults has quit [Quit: WeeChat 2.9]
msingle has quit [Ping timeout: 256 seconds]
kristoff_it has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
msingle has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<KIMI>
how to make printing float? i get line_height: 1.8e+01
<KIMI>
i parsed like this height = std.fmt.parseFloat(f32, value)
<KIMI>
i mean, non scientific notation print float, is it possible?
ur5us_ has joined #zig
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
dumenci has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
supercoven has joined #zig
supercoven has quit [Max SendQ exceeded]
hlolli__ has joined #zig
sord937 has joined #zig
<KIMI>
zls make life so easier OMG
<wilsonk>
yep
waleee-cl has quit [Quit: Connection closed for inactivity]
KIMI59 has joined #zig
KIMI has quit [Ping timeout: 245 seconds]
cole-h has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
Ashpool_ has joined #zig
msingle has quit [Ping timeout: 272 seconds]
Ashpool has quit [Ping timeout: 272 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
Ashpool_ has quit [Ping timeout: 256 seconds]
dumenci is now known as suskun
a_chou has joined #zig
KIMI59 has quit [Remote host closed the connection]
<pixelherodev>
g-w1: are you sure there are no non-x64 tests?
<pixelherodev>
Yeah, there's ARM tests already :)
notpiika has joined #zig
<ifreund>
g-w1: that failure is just some connection failure when fetching deps
<pixelherodev>
The SPU-II tests don't need QEMU at least, since they use an interpreter that's part of the test harness :)
TheLemonMan has joined #zig
<pixelherodev>
Hey lemon!
<TheLemonMan>
turning all the {} into {s} has been a bloodbath (and is still ongoing!)
<TheLemonMan>
ohai
<filpAM>
zig looks good
<TheLemonMan>
it even tastes good
<pixelherodev>
TheLemonMan: would it have been faster to write a tool using the AST API?
<pixelherodev>
Find all function call arguments which are comptime-known strings, parse and replace, route the output through zig fmt? :P
<TheLemonMan>
if only! I had to audit each callsite to make sure the replacement would work
<pixelherodev>
nif2
<pixelherodev>
... oops
<pixelherodev>
ignore gibberish , sorry
<TheLemonMan>
nice password
<pixelherodev>
lol my passwords aren't four character alphanumerics
<pixelherodev>
*UEi$r1o0]rf0LICcb@=FF)U|BdSPY
<pixelherodev>
*that's* a password
<pixelherodev>
Like actually. To a deleted account though :P
marnix has quit [Read error: Connection reset by peer]
sord937 has quit [Ping timeout: 240 seconds]
<g-w1>
oh, it doesn't run only the x64 tests. ifreund: is there a way to re-run the ci so I can actually see if my code is good?
marnix has joined #zig
<pixelherodev>
g-w1: test-stage2 runs all tests it can
<g-w1>
why did it not run the tests for x64_linux if I am on that?
<pixelherodev>
without enable-qemu, that means arch-independent tests (e.g. CBE, ZIR), tests for which it has an in-built interpreter (SPU-II), and anything else depends on enabled tooling (QEMU for alternate architectures, WINE for Windows-on-Linux)
<pixelherodev>
g-w1: it should...
<pixelherodev>
error output?
<pixelherodev>
Are you 100% certain it's an error with x64_linux?
<pixelherodev>
Did you double check it's printing the correct architecture? :P
<filpAM>
TheLemonMan: I would use zig but I'll stay on the safe side and wait until it is "production ready"
sord937 has joined #zig
<pixelherodev>
filpAM: that's definitely a smart choice
<g-w1>
does it run the check output tests on your linux machine?
<pixelherodev>
I think so?
<pixelherodev>
The linux_x64 ones at least
<TheLemonMan>
filpAM, life is too short to play it safe!
<pixelherodev>
g-w1: check output tests have a specified *target*
<pixelherodev>
If the target isn't the current system, it marks it as a pass for now
<pixelherodev>
we should have a way to indicate it was skipped in the output
<g-w1>
I know, I put mine as this `var case = ctx.exe("comptime type equality", linux_x64);` but it only ran with qemu
<pixelherodev>
retraction:
<pixelherodev>
If the target isn't the current system
<pixelherodev>
^ that's wrong (but I didn't mean to correct it like this, hit enter by mistake :P), it's if it doesn't have a way to run it
<pixelherodev>
g-w1: that's really weird
<pixelherodev>
The way it works, basically, is that if the os matches, and the arch matches, the Executor should be native
<g-w1>
Ill try to get a screenshot composing all the stuff
<pixelherodev>
You're on x64 linux, I assume :P?
<g-w1>
yes
<pixelherodev>
native executor simply causes the file to be run
<pixelherodev>
Are you sure it's not working on your machine but failing in CI?
<pixelherodev>
You're absolutely certain it's actually not running?
<g-w1>
ill check again and post some logs
<pixelherodev>
g-w1: src/test.zig, you can have it print the executor for each case as a test
<pixelherodev>
~line 660 in HEAD
<g-w1>
ok
<pixelherodev>
Above the switch(...getExecutor()), basically just `std.debug.print("Case {}, executor {}\n", .{case.name, ...getExecutor()})`
<pixelherodev>
Alternately, you can set a breakpoint in GDB and watch it
<pixelherodev>
That'll let you trace the output through the code with a proper debugger :)
shynoob has left #zig ["Leaving"]
<pixelherodev>
...I've been spending more time helping people work on zig than actually contributing myself - which isn't a bad thing, but I really want to get more done. Today I'll finally send another CBE patch, even if it's just something small to get me back into it.
<g-w1>
from what I see, it makes some qemu that can be native
<g-w1>
I think this is a bug in in lib/std/zig/cross_target:630.
<g-w1>
also, it says all 25 tests passed, but it shows 32 tests? this also confused me too
haliucinas has quit [Ping timeout: 240 seconds]
msingle has joined #zig
haliucinas has joined #zig
<pixelherodev>
g-w1: test count is very wrong
<pixelherodev>
all stage2 tests count as one test
<pixelherodev>
test count is from the compiler; all the cases are managed by one "test{}" block so Zig thinks it is one test
<g-w1>
ah, do you have any insights as why some tests are wrongly marked as qemu?
<g-w1>
ah, do you have any insights as why some tests are wrongly marked as qemu?
<g-w1>
oops wrong window
<pixelherodev>
g-w1: if you GDB trace, it should be pretty easy to figure out
cole-h has joined #zig
notzmv has joined #zig
nvmd has quit [Ping timeout: 265 seconds]
xackus has joined #zig
<pixelherodev>
I'd just > break getExternalExecutor
nvmd has joined #zig
msingle has quit [Ping timeout: 240 seconds]
<andrewrk>
ikskuh, I haven't started yet on mingw-w64 by default for windows - I think that's planned to be part of 0.8.0
<andrewrk>
you can test it out now with -target native-native-gnu
<ericonr>
andrewrk: did you catch the backtrace I sent you?
<andrewrk>
ericonr, ah yes. thanks for sending. I'm working on trying to repro it so I can tinker
<ericonr>
okdo, good luck
<g-w1>
pixelherodev: i found the problem: target.DynamicLinker thinks im using musl so the path is wrong and is screwing stuff up (im not using musl) https://share.olind.xyz/f.php?h=1nZeUElo&p=1 . I think because zig statically links musl to create the binary it things I use musl in target.zig.standardDynamicLinkerPath (at target.zig:469 it always returns musl for linux which means that it gives wrong
<g-w1>
dynamic linker path -> not native -> no run)
<TheLemonMan>
there's no shame in using musl, you can tell us if you do
frmdstryr has quit [Ping timeout: 240 seconds]
<andrewrk>
xD
<TheLemonMan>
yo andrewrk, how's your thanksgiving going?
<ikskuh>
<andrewrk> you can test it out now with -target native-native-gnu
<ikskuh>
ah, yeah
<ikskuh>
that works :)
<andrewrk>
I have a couple hours and then gonna take the rest of the day off and hang with Alee
<ifreund>
TheLemonMan: just spent another 20 minutes trying to come up with a test case for that bug you fixed without luck :/
<andrewrk>
I'm gonna try to cook okonomiyaki
<ikskuh>
enjoy your day!
<ifreund>
that doesn't sound very traditional but does sound very tasty
<TheLemonMan>
that doesn't sound very thanksgiving-ey, where's the turkey and gravy and pumpkin pie?
<TheLemonMan>
I'm gonna steal that recipe tho
<TheLemonMan>
ifreund, yeah there's something tricky in how river interacts with zig-wayland...
<ifreund>
I didn't intend for there to be anything tricky about it, just took what seemed to be the path of least resistance
<ifreund>
but yeah it seems like something else in river is putting the compiler in a state that causes this bug to materialize
<TheLemonMan>
have you tried replicating the @import chain? that may help
<ifreund>
I haven't yet, no
<andrewrk>
TheLemonMan, you don't want me to block the merge on the test case do you?
<TheLemonMan>
well, I left a comment for posterity, it should be good to go
<ifreund>
We could add compiling river to the zig CI :P
frett27_ has joined #zig
<andrewrk>
TheLemonMan, is there a missing compile error before return ErrorSemanticAnalyzeFail ?
dumenci has quit [Ping timeout: 265 seconds]
<andrewrk>
or does that mean a compile error was already emitted if we see a null field type?
<andrewrk>
never mind me, still waking up. this patch is good to go
<pixelherodev>
g-w1: that's weird, but glad you figured it out :)
<ifreund>
andrewrk: any sense of a timeline for 0.7.1? I'm probably going to block merging my dev branch of river on this patch
<ifreund>
no stress of course, I'll start trying to fix things on the milestone if I get impatient
<andrewrk>
I'm not going to put a due date on it, this one will be based on the issues in the milestone
<andrewrk>
quite a few open PRs addressing the issues, I think we're close
<ifreund>
cool, and thanks for all the support getting issues I've dredged up through river fixed :)
<andrewrk>
of course :)
<TheLemonMan>
one thing it'd be nice to fix is the FreeBSD VM, it's now constantly failing :(
<andrewrk>
hmm let me test something
<andrewrk>
damn, I could spend 40 hours/week just keeping the CI passing and helping people get their PRs merged
<andrewrk>
i wanna code too!
<TheLemonMan>
well CI scripts _are_ code!
<andrewrk>
-_-
<andrewrk>
is there a freebsd equivalent of `time -v` that shows the peak rss?
<andrewrk>
oh I can just run bash
<andrewrk>
ok it's `/usr/bin/time -l` on freebsd. anyway, just checked, the std lib tests take peak rss of 6.06 GiB
<TheLemonMan>
is the OOM killer kicking in?
<TheLemonMan>
if that's the problem we may want to split the test suite into smaller chunks
frmdstryr has joined #zig
<andrewrk>
Ave is gonna bump up the ram for us
<andrewrk>
I'd rather work on stage2 than fuck around with mitigating this
<dch>
regular reminder that I have freebsd flavoured ram and cpu to help as needed
<andrewrk>
thanks :)
<dch>
an ARMy of cores
<TheLemonMan>
the problem is hooking the extra machines to the github CI
<ifreund>
I wonder if you can self host sourcehut's builds thing easily
<dch>
TheLemonMan: can you config a webhook? If so I can deal with the rest probably
<andrewrk>
dch, yeah if you had source hut running on there I'd be on it in a heart beat
<dch>
mmmmm what does sh need to make a jail look like a qemu instance
<dch>
iirc it just ssh into the vm
radgeRayden has quit [Ping timeout: 272 seconds]
<dch>
So is the build triggered from SH or from GH ?
<ifreund>
oh, sourcehut has the github integration in a separate service from the builds
<ifreund>
this is super modular :)
<TheLemonMan>
dch, I guess it's GH that sends a webhook to kickstart the CI runner
<dch>
I have 2/3 of a ci system here already, never finished. I can’t return results to github yet but if you send me a webhook it can kick off a build
<dch>
always other projects just ahead of that one
<dch>
I would need to figure out how to do that last bit
<TheLemonMan>
that's the 20% that takes the 80% of the time :P
<dch>
exactly! anyway if you get me a webhook I have an incentive to finish it
<andrewrk>
TheLemonMan, we have 16 GiB in the freebsd CI runs now
<andrewrk>
so if it is still crashing it is not OOM
<TheLemonMan>
dch, I guess andrewrk is the only one with enough admin power to do so
<TheLemonMan>
andrewrk, good! we'll probably need 16 more by the end of the month :P
<andrewrk>
ha
ur5us has joined #zig
<TheLemonMan>
dch, you know what would be good? some NetBSD/OpenBSD CI
<TheLemonMan>
right now the latter is tested by pinging an openbsd dev heh
<TheLemonMan>
one could argue that we wouldn't have any of this problems if only BSDs didn't decide to fork again and again heh
sord937 has quit [Quit: sord937]
<dch>
I could do OpenBSD that’s an option
<dch>
How much ram does a builder need?
<andrewrk>
12 GiB to be safe
<dch>
could only do amd64
<dch>
lol ok I can fit it in then just one less chromium tab
<andrewrk>
I'm personally choosing to work on stage2 rather than address this out of control ram usage of stage1. it won't always be like this
<dch>
our db and scalability testing regularly uses 200+Gb so this will barely be noticed
<TheLemonMan>
the fuck
tane has joined #zig
<ziguana[m]>
i got a couple of extra 16GB sticks just to run IntelliJ and bazel together once
<ziguana[m]>
dev time is the most expensive part of software, and everything's optimized for it
<ziguana[m]>
could be the reason that modern software is...the way it is
<pixelherodev>
Zig is quite possibly the only program in which I tolerate the insane RAM usage
<pixelherodev>
and only because I have full confidence that it's a temporary problem - in part because I'm actively helping to solve it :)
<Michcioperz>
oh that kinda reminds me, is the out-of-control memory usage a recent regression or has been there in 0.6.0 already?
<pixelherodev>
It's been around for a long time
<pixelherodev>
Stage1 was written while the language was evolving
<pixelherodev>
So a lot of the design decisions for the compiler were less than ideal
<Michcioperz>
i tried to build a hello world for cortex-m and spent half an hour begging oom killer to finally let me back into my laptop
<ziguana[m]>
the plan was to translate-zig the stage 1 from stage 2 in the future, right?
<pixelherodev>
That's not an attack - these are hard problems, and they're only made harder when they're being solved one-at-a-time
<pixelherodev>
ziguana[m]: basically, yes
<pixelherodev>
Michcioperz: hello world should not use that much
<Michcioperz>
yeah i'm surprised myself
<pixelherodev>
How much RAM do you have?
<TheLemonMan>
Michcioperz, an hello world shouldn't take that much RAM
<pixelherodev>
That sounds like a separate bug
<Michcioperz>
8 gigs
<pixelherodev>
Yeah no
<pixelherodev>
That's not normal, even for stage1.
<pixelherodev>
That's a separate actual bug
<Michcioperz>
sure, makes sense
<pixelherodev>
can you still reproduce?
<Michcioperz>
was gonna try to get a minimal repro but life's getting in my way
<pixelherodev>
Maybe limit the RAM usage before running it, so it crashes before OOMing? :P
<Michcioperz>
yeah but no matter how much i give it crashes
<pixelherodev>
See e.g. ulimit
<pixelherodev>
yeah
<pixelherodev>
that's bad
<TheLemonMan>
we can have a look even if it's not a minimal repro
<pixelherodev>
^
<TheLemonMan>
there's no outstanding issue that could eat all your ram... unless you tried to use `!noreturn` as a function return type
<Michcioperz>
iirc i just did `export fn _start() noreturn { main() catch unreachable; unreachable; } fn main() !noreturn { while (true) {} }`
<Michcioperz>
hahahaha
<Michcioperz>
so you guessed it
<Michcioperz>
let me check if that helps
<TheLemonMan>
what have I become? a living bug tracker
<Michcioperz>
i could use one at work, a living bug tracker
<TheLemonMan>
I also have a patch for that buuut... iirc I never submitted it because of a flaw in the type system
<Michcioperz>
had a meeting today where we were supposed to discuss something but boss forgot half the things
<andrewrk>
holy crap TheLemonMan that was honestly impressive
<Michcioperz>
+1
<andrewrk>
I'm taking the rest of the day off. take care everyone 👋 I appreciate you all
<ziguana[m]>
o7
<TheLemonMan>
cya!
<ikskuh>
andrewrk, have fun and enjoy your time off!
<Michcioperz>
we already discussed that, a living bug tracker
<ifreund>
a lemon :P
<ikskuh>
TheLemonMan is a patch machine
<TheLemonMan>
I don't really like bugs IRL :\
<Michcioperz>
understandable
<TheLemonMan>
a one line patch fixes the !noreturn problem, yay
<TheLemonMan>
I mean, it stops the compiler from eating all your ram
<fengb>
Should !noreturn be allowed?
<ikskuh>
yes, definitly
<fengb>
And what about ?noreturn 🙃
<TheLemonMan>
and what about ¿noreturn
<Michcioperz>
?noreturn sounds kinda cursed and i'm taking a compiler construction class this semester so i'll just sigh
<earnestly>
cursed instructions
<Michcioperz>
kinda glad the class is taught on llvm and x86 and not armv8.3
<ikskuh>
Michcioperz: why does it sound cursed?
<ikskuh>
i think the semantics are pretty clear
<TheLemonMan>
noreturn should be a special type that can be casted into every other type, ?noreturn (iirc) is disallowed
<Michcioperz>
hmm yeah i guess it is not much different from !noreturn
<Michcioperz>
just no clear error value right?
<TheLemonMan>
?noreturn would be like ?void or ?u0, it decays into a boolean flag
<Michcioperz>
hmm, i saw it more like "it returns null or doesn't return" i think?
<TheLemonMan>
but there's an ongoing ticket war about what zero-sized types should do
<Michcioperz>
anyway thanks to y'all i realized i don't need to return !noreturn anyway if i'm on a microcontroller
<Michcioperz>
right i think i remember that war
<fengb>
If bool is 1 bit storing 2 values, and void is 0 bit storing 1 value, noreturn must be -1 bits storing 0 values!
* Michcioperz
screams in mathemathical script
<TheLemonMan>
coincidence?
filpAM has quit [Ping timeout: 256 seconds]
radgeRayden has joined #zig
FireFox317 has joined #zig
<FireFox317>
andrewrk, when using an external library (.a file) with zig and then using `-L. and -lfoo` there is currently no caching implemented for this. Do we want this, or should we rather just add the .a file as an input to the zig compiler (i.e. `zig build-exe main.zig libfoo.a -lc`)?
<FireFox317>
Because currently with the `build.zig` APIs you can add an external library by using `linkSystemLibrary` and `addLibPath` however that doesn't cache the libfoo.a file.
wootehfoot has joined #zig
nullheroes has quit [Quit: WeeChat 2.9]
FireFox317 has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
<FireFox317>
whoops, computer rebooted -_-
xackus has quit [Remote host closed the connection]
xackus_ has joined #zig
gpanders has joined #zig
nullheroes has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
filpAM has joined #zig
ur5us has joined #zig
notzmv has quit [Remote host closed the connection]