<daurnimator>
andrewrk: just thinking in case it turns up in stack traces or error messages at some point: having zig in the name is probably a good thing
<daurnimator>
vs sending someone off on a wild goose chase looking for `libstage2` somewhere on the internet
<andrewrk>
that's a good point
<daurnimator>
even worse: there *is* a libstage2 in ubuntu
<andrewrk>
that's such a good point that I'm going to do the chore
<daurnimator>
andrewrk: so what are the dummy libc paths for?
<andrewrk>
on macos, -lc is implied. so zig0 ends up calling detect_libc(), in case of @cImport, so that the include paths can be set correctly. since stage1 does not rely on @cImport, these dummy paths are ignored
<daurnimator>
should we not e.g. set them to `null` so that any access results in a segfault?
<andrewrk>
I have a bigger vision that I'm focusing on, which moves all of building libc and linking to become self-hosted
<andrewrk>
the code you're suggesting to improve will instead be deleted
<daurnimator>
k
dbandstra has quit [Ping timeout: 240 seconds]
LER0ever has joined #zig
<pixelherodev>
Does anything need to be done for #4418?
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
pixelherodev, I'll look soon. I want to finish up #4478
LER0ever has quit [Remote host closed the connection]
<daurnimator>
andrewrk: just saw your `copy_open_files` function: we should try and use the syscall `copy_file_range` which would take advantage of reflinks.
<pixelherodev>
What's the difference between std.event.{Group,Batch}?
<andrewrk>
daurnimator, step 1 is get it working at all. ugh, the zig std lib version already works perfectly but we need an impl in stage1
<andrewrk>
copy_file_range is another local maximum anyway - the zig std lib version does an atomic rename into place, which is more correct
<andrewrk>
pixelherodev, check the implementations and doc comments, I wrote a little bit about it there
<daurnimator>
oh I didn't look to see the surrounding code...
<daurnimator>
if we delete the source file then why would we not be doing a rename in stage1 too?
<daurnimator>
okay that needs to be converted to use `copy_file_range` too.
<daurnimator>
it currently does readFull/write
dbandstra has joined #zig
<daurnimator>
and for the fallback path (for when `copy_file_range` is not available: which would be the current code): we should use LinearFifo: it should be faster.
<andrewrk>
I see, yes that will be an excellent improvement
<andrewrk>
the copy_file_range thing
<andrewrk>
why is LinearFifo trying to be 3 different abstractions at the same time?
<daurnimator>
andrewrk: you mean the static vs slice vs dynamic?
<andrewrk>
yeah
<andrewrk>
the slice one looks like it is conflicting with ArrayList
<andrewrk>
err the dynamic one
<daurnimator>
indeed. its quite similar except it's a circular buffer
<andrewrk>
hmmm ok
<daurnimator>
it should be used instead of an arraylist whenever you have a code path that removes items from the start.
<daurnimator>
the key situation of that is when you have a .read() .write() loop: exactly like that copy loop in `updateFileMode`
<fengb>
I think it’s good that a circular buffer has a very similar API to ArrayList
<andrewrk>
except it's hard coded to be u8
<daurnimator>
?
<andrewrk>
hmm I'm wrong. I'm not sure what made me think that
<daurnimator>
are you confused with std.Buffer?
<daurnimator>
that one is hardcoded to u8 and should probably be removed. or at least renamed to something odd so that people don't use it
<andrewrk>
sorry, I'm looking at this while trying to debug 4 things gone wrong
<pixelherodev>
Always makes for a fun time :)
<daurnimator>
andrewrk: when you pop your stack a bit we should talk more about this :)
mattmurr has quit [Ping timeout: 268 seconds]
i_right_i has joined #zig
<andrewrk>
ugh, the error on windows was forgetting to `return ErrorNone` at the end of a function, and msvc didn't give me a compile error
<fengb>
Returns are optional in C++?
<andrewrk>
daurnimator, looks like copy_file_range is https://github.com/ziglang/zig/issues/2563, and it's waiting on introduce operating system version ranges as part of the target #1907
<andrewrk>
I do want to get 1907 done by the release
<andrewrk>
this has got to be a new record. 3/3 builds are working on my home computers. 0/3 are working on the ci
<andrewrk>
kudos for having such a fresh glibc on your system, I'm still on 2.27 myself
<andrewrk>
you can pass `-target-glibc 2.30` to work around
<pixelherodev>
I'm guessing there's no code quality checker thingies (like e.g. LGTM) that support Zig yet?
<andrewrk>
figured it out. clang's selfExePath() or whatever they call it is not as robust as zig's, and it's using argv[0] to find its own path. but it's not resolving argv[0] according to PATH
<andrewrk>
so basically we treat clang like a little child and give it the full absolute path to itself in argv[0]
<andrewrk>
(pun intended)
mahmudov has quit [Ping timeout: 268 seconds]
<daurnimator>
andrewrk: -target-glibc doesn't work for `zig build test`?
<andrewrk>
daurnimator, you can also modify target_can_build_libc logic to take into account glibc versions
<hryx>
sup friends. Given any std.mem.Allocator, what's the proper way to make an allocation for some opaque type, assuming the size and alignment are runtime-known? Use some_allocator.reallocFn directly?
<daurnimator>
hryx: `alignAlloc` passing u8 and the alignment you want
<hryx>
daurnimator: the alignment param of alignedAlloc is comptime, though
<daurnimator>
ah right.... I've hit that before
<andrewrk>
daurnimator, you can use glibc_load_metadata to get a list of all versions zig can build, and the target parameter tells the one we want to check for
<daurnimator>
hryx: yeah I guess use .reallocFn directly. or alignAlloc an re-align yourself I guess?
<andrewrk>
hryx, it's planned (if possible) to make the alignment parameter of the Allocator interface always comptime known, so this wouldn't work with your use case. can you elaborate on it?
<andrewrk>
also hi :)
<hryx>
hey again :)
<hryx>
sure, I'll try to summarize my use case here
Xatenev has joined #zig
<daurnimator>
anyone know why I'd be getting " error: unable to evaluate constant expression" with std.fmt after moving to latest master?
<daurnimator>
oh, `output` is comptime now!
<andrewrk>
daurnimator, yes it's going to become very common for function pointers to be comptime, because that's a lot more async friendly
<fengb>
Are they even pointers if they're comptime? >_>
* daurnimator
has now rebased the autojson branch on master. lets hope the mysterious CI failure has disappeared
<hryx>
andrewrk: use case: I'm porting an old (incomplete) C library of mine to Zig, but I want to maintain a C interface. the library has a plugin API where plugin authors can define custom types to register with a central system. I want the host app to define the allocator, so the existing design is that plugin just says its own size and alignment
<andrewrk>
it's past my bedtime but I would appreciate an issue for improving target_can_build_libc to take into account glibc versions. I'll do it in the morning if I remember
marmotini_ has quit [Remote host closed the connection]
_Vi has joined #zig
mattmurr has joined #zig
samtebbs has quit [Ping timeout: 240 seconds]
jrl has quit [Quit: WeeChat 2.6]
Xatenev has quit [Quit: Leaving]
Xatenev has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Read error: Connection reset by peer]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
zfoo_ has joined #zig
samtebbs has joined #zig
dddddd has joined #zig
<samtebbs>
Wow this channel really has grown since I was last active :)
<mq32>
hey samtebbs
<daurnimator>
samtebbs: welcome back (you haven't been that long have you?)
<Xatenev>
samtebbs, hello :)
Xatenev has quit [Remote host closed the connection]
slowtyper has joined #zig
<alexnask_>
Does anyone know if there is an issue (or even should be) about the function argument type erasure? (e.g. everything after a type argument becomes a var argument and ret type)
<alexnask_>
ret type becomes var too *
<daurnimator>
alexnask_: you mean in docs?
<alexnask_>
Anywhere really, is this 100% intended behavior is it up to change? Couldn't find anything relevant in github issues
<alexnask_>
Im taking a shot at writing an interface library again
<mq32>
alexnask_, ah i noticed that too
<mq32>
but i don't think there's an easy solution for that :(
<alexnask_>
I believe the compiler just finds the index of the first type argument and type erases everything subsequent
frmdstryr has joined #zig
decentpenguin has joined #zig
ave_ has joined #zig
zfoo_ has quit [Ping timeout: 268 seconds]
<samtebbs>
mq32: Hi :)
FireFox317 has quit [Remote host closed the connection]
<samtebbs>
daurnimator: I haven't been active since coming back to uni last September :/
<samtebbs>
I've been so focussed on my final year project
LER0ever has quit [Remote host closed the connection]
LER0ever has joined #zig
shakesoda has quit [Quit: Connection closed for inactivity]
frmdstryr has quit [Ping timeout: 265 seconds]
return0__ has joined #zig
return0e has quit [Ping timeout: 248 seconds]
LER0ever has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
I'm trying to remember what service I used last time I needed ssh access to an aarch64 server
FireFox317 has joined #zig
<FireFox317>
wasnt it pixelherodev who had an aarch64 server?
<FireFox317>
or access to some
<andrewrk>
I found one - daurnimator hooked us up a few months ago
<daurnimator>
andrewrk: `ssh 147.75.49.246`
<andrewrk>
yeah I had it in my ssh config still. thanks!
<companion_cube>
ssh aliases are ♥
<daurnimator>
andrewrk: I just wasted an hour trying to figure out nix.... and failing :P
<andrewrk>
if I recall correctly I requested something boring like ubuntu or debian on this box :)
<daurnimator>
there was like 3 options and nixos was the one you picked
<andrewrk>
oh ok
<andrewrk>
damn. it's not reproducing the drone ci failure
<daurnimator>
looks like more OS options are available now
<daurnimator>
I could redeploy if you want
<daurnimator>
originally it was just meant to be a CI worker
<Snektron>
<mq32 "but i don't think there's an eas"> Should be doable, in the worst case the prototype can be copied in verbatim
<mq32>
<companion_cube> ssh aliases are ♥
<mq32>
oh yeah, i have pretty much all devices with SSH in my config with preconfigured forwardings and stuff
<mq32>
Snektron: Yeah, i think some of the docs would really benefit that already
<FireFox317>
is the drone CI testing on real hardware or emulated stuff? Maybe its actually emulated
<companion_cube>
yeah same, it's quite nice
<mq32>
also, ssh -D, -L and -R are just awesome
<mq32>
oh, you want a TCP hole from here to there? Lemme just put that up
TheLemonMan has joined #zig
<andrewrk>
FireFox317, it's an alpine docker image
<andrewrk>
but I think it's real hardware
<TheLemonMan>
if it's a machine from WorksOnARM I'd say it _is_ running on real arm64 chips
<FireFox317>
yeah looking at their website, it looks like its real hardware indeed
zfoo has quit [Remote host closed the connection]
<daurnimator>
could be a cpu model thing? I think drone ci cloud uses the cavium; but the box I gave you andrewrk is an ampere
<andrewrk>
I think it is a dynamic linker thing
<andrewrk>
which has more to do with the linux distro than anything
<andrewrk>
...but also the arch because of the path
* daurnimator
bed
slowtyper has quit [Ping timeout: 268 seconds]
<andrewrk>
night
* andrewrk
sips his morning tea
slowtyper has joined #zig
* TheLemonMan
sips his afternoon tea
<TheLemonMan>
the beauty of timezones
<andrewrk>
I'm bummed that even lld 10 can't do risc-v linker relaxation
<andrewrk>
I thought we were going to have a great RISC-V story in the 0.6.0 release
<TheLemonMan>
eh you can't really blame the lld devs, it's not a trivial feature
<mq32>
TheLemonMan: you german? i've seen you have a branch "sauerkraut" *grin*
<TheLemonMan>
I'd just pass in `-mno-relax` for the time being and call it a day, at least until LLVM11 comes out
<TheLemonMan>
mq32, don't read too much into my branch names, sometimes I just press some random keys heh
<TheLemonMan>
I do like saukerkraut tho
<mq32>
hey, asking doesn't hurt (usually)
<mq32>
also, sauerkraut is great
<alexnask_>
can confirm
<TheLemonMan>
cabbage is great!
<TheLemonMan>
either as sauerkraut or kimchi or whatever
<andrewrk>
so it's only in the dwarf info not the executable
<jessermeyer>
Ah, so the debugger has to know that.
<jessermeyer>
Is there a way to force it to the stack on runtime?
<andrewrk>
use var instead of const
<jessermeyer>
Thx.
<jessermeyer>
Makes sense.
<fengb>
Declare it as a var?
Snektron has quit [Ping timeout: 252 seconds]
jonathon has quit [Remote host closed the connection]
aperezdc has quit [Ping timeout: 252 seconds]
Dominic[m] has quit [Ping timeout: 245 seconds]
AlexMax has quit [Ping timeout: 245 seconds]
jzck has quit [Ping timeout: 256 seconds]
dtz has quit [Ping timeout: 240 seconds]
D3zmodos has quit [Ping timeout: 260 seconds]
hryx has quit [Ping timeout: 245 seconds]
BitPuffin has quit [Ping timeout: 256 seconds]
jonathon has joined #zig
fengb has quit [Ping timeout: 245 seconds]
<FireFox317>
+c is the problem apparently andrewrk
pmwhite has quit [Ping timeout: 240 seconds]
<jessermeyer>
Does translate-c view post pre-processor output?
FireFox317 has quit [Ping timeout: 265 seconds]
<jessermeyer>
I'm having a situation where, to fix the calling convention issue, I pass -target i386-windows, but this causes all pointer sizes to be 32bits.
<jessermeyer>
Struct sizes are wrong for the platform I'm compiling for.
<jessermeyer>
So, damned if I do, damned if I don't.
<TheLemonMan>
fyi stdcall does nothing on x86_64
jmiven has quit [Quit: riboute]
mahmudov has joined #zig
<jessermeyer>
That's right.
jmiven has joined #zig
<jessermeyer>
It's more the principle of the matter.
<jessermeyer>
I think translate-c _should_ result in Zig code that is correct for the platform which is compiled to.
<jessermeyer>
But SIZE_T is 4 bytes atm, since, presumably, it didn't know any other option as the pre-processor already ran?
pmwhite has joined #zig
<TheLemonMan>
the C code is parsed and ananlyzed, it's not just a syntactical translation
<jessermeyer>
Parsed first ... by the pre-processor?
<jessermeyer>
Which would set the size of SIZET in this case.
<jessermeyer>
Meaning, translate-c doesn't have any flexibility since it's perspective is fixed.
<TheLemonMan>
the pre-processor is dumb as a brick, it just copies and pastes text
<jessermeyer>
It can radically transform the semantics of the code. That's the point.
jzck has joined #zig
<jessermeyer>
My expectation is resulting Zig code from translate-c will generate a correct executable for the target platform.
aperezdc has joined #zig
<jessermeyer>
Which, I think, implies that translate-c should see the pre-processed C code.
<andrewrk>
jessermeyer, don't pass the wrong target to translate-c
<jessermeyer>
I think I'm arguing that the target should not matter for translate-c. The 'correct' target may be a set of targets, with incompatible pointer sizes.
<TheLemonMan>
(atm) the output from translate-c is not meant to be a poor-man universal binding generator
<TheLemonMan>
the idea is to cImport a header file the same way you'd do in C
<metaleap>
my_slice got somewhere initialized to `[]Foo{}`, will `my_slice.ptr == []Foo{}` always be true?
<andrewrk>
jessermeyer, what you want is impossible due to the c preprocessor. it's a design limitation of the C programming language
<andrewrk>
`if (undefined) a else b` is illegal behavior, currently not detected but it is planned
BitPuffin has joined #zig
<jessermeyer>
I agree it's impossible if translate-c only sees post-processed C files. I think this is of no practical issue once Windows.h and friends can be correctly translated via cImport, since the target platform is correctly propogated.
AlexMax has joined #zig
Akuli has quit [Read error: Connection reset by peer]
Akuli has joined #zig
<jessermeyer>
Fortunately the fix in general here is to just define SIZE_T as usize. Done.
Dominic[m] has joined #zig
D3zmodos has joined #zig
hryx has joined #zig
_Vi has quit [Ping timeout: 246 seconds]
fengb has joined #zig
zfoo_ has quit [Ping timeout: 260 seconds]
slowtyper has quit [Quit: WeeChat 2.7]
<procnto>
I'm curious, how stable is Zig right now.. will I be in a world of pain if I go build a hobbyist OS in it? Aside from normal pains with developing an OS.
<procnto>
Been on the Rust kick for a bit... but it doesn't really maximize developer productivity/fun, which is critical for fun projects
waleee-cl has joined #zig
<andrewrk>
very unstable
<andrewrk>
breaking changes every week
<procnto>
👍 doing the lord's work :) I'll have to wait for v1.0
<andrewrk>
maybe you can try 0.6.0 when it comes out in April, and decide if it's good enough to last you 6 months until 0.7.0
<andrewrk>
I do work with active projects before a release to make sure everybody's projects are building
<procnto>
Sounds like a plan, six months is a good amount of time to build something cool. I've been thinking about contributing later on but don't have the cycles at the moment.
<procnto>
Very few new languages hit that C sweet spot
jjido has joined #zig
FireFox317 has quit [Ping timeout: 272 seconds]
FireFox317 has joined #zig
jwh has joined #zig
decentpenguin has quit [Quit: decentpenguin]
zfoo_ has joined #zig
slowtyper has joined #zig
ur5us has joined #zig
BitPuffin has quit [Quit: killed]
AlexMax has quit [Quit: killed]
hryx has quit [Quit: killed]
fengb has quit [Quit: killed]
pmwhite has quit [Quit: killed]
D3zmodos has quit [Quit: killed]
jzck has quit [Quit: killed]
aperezdc has quit [Quit: killed]
Dominic[m] has quit [Quit: killed]
Snektron has quit [Quit: killed]
slowtyper has quit [Ping timeout: 268 seconds]
slowtyper has joined #zig
<metaleap>
in case anyone wondered.. `const test_name = "lets try this"; test test_name { .... }` isnt supported :D (somehow i'm glad as one operating on zig asts =)
<jessermeyer>
And thanks for writing up the pull request!
<jaredmm>
Ok. I was looking at how #defines are currently handled and they don't go through the same flow as a normal multicharacter literal usage. I have a semi-fix to translate-c that would fix the basic usages, but I'm unsure if it would break for more involved defines.
zfoo_ has quit [Read error: Connection reset by peer]
<jaredmm>
I know you were working on getting the Windows imports to work, so I figured you might've taken a look as well.
<jessermeyer>
I haven't tried tackling the fundamental problems. At this point I'm still more a Zig user rather than a Zig developer.
<TheLemonMan>
no that's just C being a dick
<jessermeyer>
lol
<jessermeyer>
I didn't know if the code paths diverge given the L postfix.
<TheLemonMan>
the literal is promoted to an unsigned long, I've briefly looked in the C spec and couldn't find anything about that
<jessermeyer>
Seems likely to be a Microsoftism.
<TheLemonMan>
not quite, clang does the same
<jessermeyer>
Huh. I would've expected it from clang-cl, not clang itself.
jjido has joined #zig
<alexnask_>
I think 'L' is implementation defined to long int or unsigned long int
<TheLemonMan>
it seems to be more of a hint
<TheLemonMan>
"The type of the integer constant is the first type in which the value can fit, from the list of types which depends on which numeric base and which integer-suffix was used."
i_right_i has joined #zig
<jaredmm>
Speaking of https://github.com/ziglang/zig/pull/4430, TheLemonMan, can you take another look at that? I got rid of most of the code that was there. It looks better to me, but that doesn't say much.
rjtobin has joined #zig
<alexnask_>
Fixed a couple of things in my PR too
<TheLemonMan>
jaredmm, oh I've fixed the problem with the c_ushort/u16 conversion, now it should work just fine
<alexnask_>
Ill probably try a new interface implementation for std on a branch next (+ std.interface)
<jaredmm>
Yeah, saw that. Switched all the c_ stuff to u16s.
<TheLemonMan>
andrewrk wanted it to return a `*[N:0]const u16` to make it symmetrical with the "normal" string literals
blackbeard420 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<andrewrk>
I tried to fix the aarch64 CI test failure of #4478 by additionally self-hosting dynamic linker detection, and, while that is now done and working, it didn't fix the ci test failure
<jaredmm>
Wasn't sure how to make that work. The existing wide functions gave errors trying to pass that in (or maybe I was doing it wrong).
<TheLemonMan>
the pointer-to-array should gracefully decay into a slice
<jaredmm>
Alright, I'll take another look at it.
<TheLemonMan>
andrewrk, any reason why function-sections is not enabled by default?
<TheLemonMan>
it helps to remove some comptime-only functions that end up in the final binary (eg. isWasm, isMIPS, ...)
<andrewrk>
I thought it was
<andrewrk>
huh, ok I see that it is exposed as a command line option, defaulting to off
<andrewrk>
oh right - we enable it for compiler_rt and libc
<andrewrk>
I think it's not strictly better. especially in optimized builds
<andrewrk>
there's an issue open for this, there are some considerations. for example, should functions and values that are comptime-only be available to debuggers?
<companion_cube>
what about comptime debugging? :D
<andrewrk>
all you get is printf debugging with @compileLog
blackbeard420 has joined #zig
<jaredmm>
Would `*[N:0]const u16` look like `*[:0]const u16`?
<jaredmm>
or is N actually a valid grammar thing?
<andrewrk>
N means it should be a comptime value
<andrewrk>
calculate N in your function
<jessermeyer>
Are there plans to support AST manipulation (build time metaprogramming) at build time?
<andrewrk>
no
<jessermeyer>
Are there plans to support some kind of metaprogramming at build time?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32>
jessermeyer: you can just generate code in your build.zig with zig
<TheLemonMan>
you can already do that
<mq32>
add a custom "writeFile" build step or similar
<jessermeyer>
That's a good start.
wilsonk has quit [Ping timeout: 268 seconds]
alexnask_ is now known as alexnask
<andrewrk>
and it's finished! all the planned metaprogramming features are done, no more will be added
<andrewrk>
some redundant builtins will be removed in favor of @typeInfo
<jaredmm>
How do I define N in my comptime function?
<mq32>
andrewrk: have you concluded that @Type will not support struct generation?
<andrewrk>
mq32, oh good point, that's still an open area. but yeah leaning towards "no"
<mq32>
i can imagine
<mq32>
it both has potential to do great stuff and follows the "only one thing" zen
<mq32>
but it also is a complex devil of undebuggability
<andrewrk>
I wish this aarch64 ci server was a crash dummy so I could wring its neck
<andrewrk>
or even better... ssh access
<andrewrk>
as much of a ram miser as drew can be, the ability to ssh into sr.ht build servers is killer
<andrewrk>
just 1 ldd command, would tell me so much information
<jaredmm>
Tried N=, const N=, var N=, and .N=. I don't see anything in the existing std that matched *[N when I searched, other than the test cases and errors.
<TheLemonMan>
don't you have a pinebook andrewrk ?
<andrewrk>
yeah but I can't get llvm to build on it successfully
<andrewrk>
I have ssh access to a different aarch64 server but it's not reproducing the error
<andrewrk>
maybe I'll take daurnimator's offer to change to a different OS
<mq32>
jaredmm: what N do you want to have?
<mq32>
for array size?
<TheLemonMan>
building LLVM on a pinebook doesn't sound fun heh
<andrewrk>
oh wait a minute.. docker is installed. this might just do the trick
wilsonk has joined #zig
<mq32>
use fn(comptime N: comptime_int, array: [N]i32) void
<hryx>
does malloc just assume the largest possible alignment for the platform? if so, what's the downside, fragmentation?
<jaredmm>
It would be, but it doesn't exist locally right now.
<FireFox317>
okay good
<jaredmm>
How could I can add N as a comptime parameter, when it is calculated in the body of that function? The value of N should be utf16le_len.
<fengb>
Make the args comptime
<jessermeyer>
Metaprogramming: What Zig's response to something like code standards checking, like MISRA C? Is the idea to parse the source file using Zig's AST generator and do it there, at build time?
<fengb>
Or you can’t... runtime known arrays are basically impossible. That’s why slices are a thing
<jessermeyer>
If the answer is 'Yes' or something similar, then it would be nice to be able to send the build system an AST tree based on changes made.
<mq32>
later in self-hosted, you can probably just parse the ast with the parser from self hosted
<jessermeyer>
Yeah that would be sweet.
<mq32>
but i think something like misra-zig is hard to achieve with a formal verifier
<jessermeyer>
Yeah, I'm not thinking specifically as MISRA, but something like house rules.
<fengb>
Like linting rules and such?
<jessermeyer>
In games, there is often a point in the frame where you do not want new entities spawned, since it'll mess with indexes.
<jessermeyer>
So if you could do something like buildtime {house_rules.no_entities_after_this_point=true};, and the build system can see that, you can check the AST structure to confirm that constraint.
<jessermeyer>
JAI handles this with build time messages. Not suggesting that approach necessarily, but it does get the job done.
<andrewrk>
TheLemonMan, maybe -ffunction-sections would be a nice default for optimized build modes when building a static library
<andrewrk>
the only downside is I think it can potentially generate worse code when there would have been a machine code benefit to having functions generated next to each other. like maybe it messes with tail calls or something
discip has joined #zig
<TheLemonMan>
we should check if stage1 increases in size with that option turned on
<andrewrk>
hallelujah I reproduced the failure on this aarch64 box in docker
<TheLemonMan>
the improvements to dl_iterate_phdr are nice
<andrewrk>
thanks
<andrewrk>
lots of self hosting going on here
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
discip has quit [Remote host closed the connection]
<andrewrk>
no but there should be a CLI option for that and an automatically provided zig build CLI option as well
<andrewrk>
it's currently a hardcoded integer constant
<daurnimator>
located where? :)
<andrewrk>
ir.cpp:10301 and ir.cpp:10310
<daurnimator>
that number seems to be 10....
<andrewrk>
yes it is 10
<daurnimator>
In my experience tracebacks seem to be consistently 3
<andrewrk>
the "referenced from here" errors are kinda messed up right now - they make sense when debugging dependency loops but they should be omitted otherwise
<andrewrk>
if it's only 3 then the 3rd one is the beginning of your "comptime stack"
<andrewrk>
zig doesn't currently keep track of why decls are being analyzed when it puts them in the queue, but it probably should
<daurnimator>
I wonder if its just a side effect of @typeInfo not being lazy