<andrewrk>
noam, `@import("foo.zig")` will cause a shallow "scan decls" of the struct corresponding to foo.zig. if one of those decls is an export it is noticed
<noam>
andrewrk: but only if the import is referenced, right?
<andrewrk>
right
<noam>
That's what I was asking, yeah
<noam>
thanks :)
<noam>
Good news, finally just about done with this stupid rewrite of the analysis pipeline, so I should be working on getting behavior tests working tomorrow :D
<andrewrk>
cool
<antaoiseach>
Hello, folks - Zig newbie back again, experimenting with a small project - just a couple of functions in a couple of "directories". So I managed to make it work, but it feels a bit overly done. Could someone have a quick look?
<antaoiseach>
I have added all the file contents in the paste, around 100 SLOC total (https://zigbin.io/bf5aed)
<andrewrk>
not sure what kind of feedback you want. for such a small project, no need to have more than 1 file
<antaoiseach>
So how import works has me quite a bit confused. Initially, I had addPackage for the main.zig file, and `zig build run` worked just fine, but when I wanted to refer to another "module" (well, a directory with a file inside it) from a sibling one, I ran into all sorts of issues - "file outside package path" etc.
<andrewrk>
but it seems like your goal is to learn how importing stuff works, so I don't see a problem
<antaoiseach>
andrewrk: Oh, yes, I know. This is just a small experiment I was doing to test, and then use it for a bigger project I'm trying out
<antaoiseach>
Just wondering if this is even idiomatic
cr1901_modern has joined #zig
<antaoiseach>
(I mean, what I have done in the build.zig file)
<andrewrk>
seems fine
<antaoiseach>
andrewrk: yes, I'm slowly getting the picture, but I'm still not fully confident I understand it all.
<antaoiseach>
andrewrk: Oh, okay. Cool!
<andrewrk>
it feels like overkill for such a small amount of code but you can imagine how on a larger project, such fine grained control over tests and binaries would come in handy
recalloc has joined #zig
<antaoiseach>
andrewrk: That makes sense.
<cr1901_modern>
Okay I'm stumped... what does Zig want me to do here to convert a usize to u3? http://ix.io/3mmC
<cr1901_modern>
While it's on my mind, that function elementAt can do out-of-bounds access. Is there a way using comptime to create a polymorphic elementAt where one version runs if the values are comptime-known and another version if the vals are runtime-known?
<noam>
Ahahahaha, I did a dumb :P Time for my stupid 100K line test went from ~40ms to ~2.7s because the scoping rework / liveness analysis ended up checking an index against every item in a list of average size *200K*
<noam>
:P
<noam>
*98% of runtime* is in scope_contains XD
ur5us has quit [Ping timeout: 245 seconds]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
manicennui has joined #zig
[wtf] has joined #zig
<andrewrk>
cr1901_modern, if the type of `data` is a slice you're already getting bounds checking that turns off in release builds
tefter has joined #zig
<cr1901_modern>
Sure, that's fine. I was just wondering anyway
sord937 has joined #zig
manicennui has left #zig [#zig]
[wtf] has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 252 seconds]
tefter_ has joined #zig
tefter has quit [Ping timeout: 252 seconds]
tefter_ has quit [Remote host closed the connection]
<mikdusan>
that is weird. I am reluctant to install multilib on a somewhat clean archlinux to try to better reproduce. but it occurs to me now - clone the vm. dirty it up and nuke it afterwards :)
Anzh has quit [Ping timeout: 240 seconds]
<noam>
Stupid question: `const foo = bar();` in a declarative context is illegal, isn't it
<noam>
(where bar is a runtime function)
<noam>
Ah wait, no :)
<noam>
> The initialization values of global variables are evaluated at compile-time. | bar then becomes *implicitly* comptime
<noam>
That makes more sense :)
<TheLemonMan>
I do have a multilib around because of wine (I guess?)
<noam>
andrewrk: Behavior tests are just normal tests, right? :)
<mikdusan>
TheLemonMan: I have a clone of archlinux setup. has various llvm pre-builts in /opt and no multilibs installed yet. you want access?
<TheLemonMan>
mikdusan, I'm currently looking into the SPARC problem, will come back to that later
<mikdusan>
ok. what I can offer is for limited periods of time (ie: 12 hours) access. just need an account name you'd like, and authorized_keys ssh pubkey
waleee-cl has quit [Quit: Connection closed for inactivity]
<dutchie>
plz2send utf-8 headers
<mq32>
fix that server
<dutchie>
but cool to see zyg progressing
<ifreund>
noam: by the way, are you aware of this other project called C3? https://www.c3-lang.org/
<noam>
Yes :P
<noam>
Someone else linked it to me a while back
<noam>
dutchie: ... They aren't already? *shrugs*
<noam>
I plan on switching it to gemini at some point, so it'll be moot soonish anyways
<noam>
and yeah, zyg is *finally* able to actually make progress again, since there's nothing left I want to just delete :P
<dutchie>
noam: i see `lexer.c: In function ‘lexer_append’:` and other such mojibake
<noam>
I know.
<noam>
The first one is staying literally forever
<dutchie>
Content-Type
<noam>
The aliasing one I just haven't gotten around to fixing :P
<dutchie>
: text/plain
<noam>
... yeah, it is text/plain ?
<noam>
I mean, that's 100% correct
<mq32>
Content-Encoding is missing
<noam>
... ah
<mq32>
or the encoding on the mime type
<dutchie>
shouldn't it be text/plain; charset=utf-8
<dutchie>
yeah
<noam>
gotcha, fixing now
<noam>
ah, hm. I think that might be ASCII escape codes, actually? :P
<mq32>
default is ISO-8859-1
<mq32>
so your utf-8 is parsed as latin-1
<noam>
nope, yeah, it's an encoding issue
<noam>
it's using stupid uniquotes instead of just ""
<noam>
*rolls eyes in GNU's general direction*
<noam>
... okay, that's not fair. UTF-8 should absolutely be the default everywhere :P
<mq32>
doesn't hurt anybode with a reasonable and correct system setup ;)
<mq32>
it's too late for that now
<dutchie>
isn't there some actual historical reason browsers assume latin-1 or am i imagining it
<mq32>
yep
<mq32>
Netscape probably :D
<noam>
Yes but the fact that *that*'s the behavior they respect is moronic
<mq32>
i mean, you break stuff when you don't
<noam>
They break stuff all the time anyways!
<noam>
fixed
<noam>
dutchie: thanks
<dutchie>
np, lgtm now
<noam>
The dealloc one is because, well, nothing actually frees registers yet XD. The lexer one is because compilers are idiots. The last one is because *I'm* an idiot and didn't bother fixing an aliasing issue yet :P
<noam>
less tl;dr on the lexer: for performance reasons, an identifier is only appended when it's needed. Just zero-initializing the unused value has a significant performance cost, and the value doesn't actually matter, so I don't.
<noam>
(it occurs once for *every lexed token.* A few cycles multiplied by *every lexographic token* is a big deal)
Bernstein has quit [Remote host closed the connection]
tefter has joined #zig
<TheLemonMan>
koakuma, found the problem and fixing it
<noam>
Always fun optimizing new code...
<noam>
Regained 5% on the new pipeline by fixing redundancies and improving APIs, so far :)
wiesi69 has joined #zig
Bernstein has joined #zig
wiesi69 has quit [Remote host closed the connection]
Anzh has joined #zig
Anzh has quit [Ping timeout: 246 seconds]
<m314>
I recently upgraded my distro to one based on a new glibc (2.33). This caused my old zig version to fail to link system libraries and I'm trying to figure out why.
<m314>
I thought zig was pretty dumb about linking plain old system libraries (cross compiling for a glibc-based system is another matter of course). Am I missing something here?
<ifreund>
I got an idea to test it too: that logic hasn't changed since zig 0.7.1 so the patch applies cleanly
<ifreund>
thanks :)
sord937 has quit [Quit: sord937]
<andrewrk>
ifreund, hmm do we perhaps need the concept of the native libc?
<andrewrk>
we already have independent concepts for native cpu, and native os
<andrewrk>
and you could easily do something like native-native-musl or native-native-gnu
<ifreund>
hmm, that might indeed be a better way to expose this
<ifreund>
I like it, it's a lot more explict and less magic than having native os imply native libc
<andrewrk>
I think my approach in this case would be: * enumerate some of the use cases that would be affected by this new concept * go over each one and see what modifications need to be made to -target / builtin.zig / other stuff, to make the use case match up to the new model of how things work
<andrewrk>
this would hopefully identify all the code that needs updated to implement this
<ifreund>
/// `null` means the native C ABI, if `os_tag` is native, otherwise it means the default C ABI.
<ifreund>
andrewrk: our current doc comment is actually in line with my current patch
<andrewrk>
good point
<andrewrk>
mm but what happens if you do `-target native-native-musl` for example?
<andrewrk>
I think this patch would do unexpected behavior
<ifreund>
true
<andrewrk>
that is not an edge case either - it's a pretty useful target
<ifreund>
indeed, can't statically link glibc :D
<ifreund>
what does "default C ABI" actually mean in that comment?