<FireFox317>
even better :) however naming a file llvm.zig is pretty dangerous, because putting functions 'globally' in that file will cause stage1 to emit function names like `llvm.foo` which llvm considers intrinsics ;p
<andrewrk>
ohh hmm is that why you originally moved it?
<FireFox317>
exactly
<andrewrk>
if it's in codegen dir I think stage1 will emit `codegen.llvm.foo`
<FireFox317>
oh maybe it does yeah, let me check that
<FireFox317>
andrewrk, just so you know, on the ci we do not pass the -Denable-llvm flag yet
<andrewrk>
ah right
mschwaig has quit [Quit: WeeChat 2.7.1]
mschwaig has joined #zig
mschwaig has quit [Client Quit]
mschwaig has joined #zig
<andrewrk>
meanwhile, I got -femit-h integrated with incremental compilation :)
<FireFox317>
Nice!
<pixelherodev>
Very nice! :D
<pixelherodev>
Ah right, I need to get more CBE work done tommorow :)
<andrewrk>
I reworked all of it
<pixelherodev>
CBE? Or emit-h in particular?
<andrewrk>
all of it
<pixelherodev>
Well okay then :)
<pixelherodev>
Did you see my PR for it?
<andrewrk>
yeah I merged it then reworked all of it
<pixelherodev>
Ah, so I should close it?
<andrewrk>
no just sit tight, I'm about to push
<pixelherodev>
Gotcha :)
mschwaig has quit [Quit: WeeChat 3.0]
<andrewrk>
we're going to need the test harness to support testing updates and making sure the emit-h output is correct
mschwaig has joined #zig
<FireFox317>
andrewrk, renaming and moving of llvm backend files has been added the PR and the testing of all the targets will go in a different PR. goodnight!
<andrewrk>
FireFox317, goodnight! nice work!
<pixelherodev>
My PR solved the first half, at least
<andrewrk>
pushed
* pixelherodev
nods
Biolunar has quit [Ping timeout: 272 seconds]
<andrewrk>
and now I think it's finally time for that coding stream I said I was gonna do yesterday
<g-w1>
nice, from my profiling it seems analyzeInst and analyzeBody are the most slow functions
mschwaig has quit [Quit: WeeChat 3.0]
mschwaig has joined #zig
mschwaig has quit [Quit: WeeChat 3.0]
Biolunar has joined #zig
mschwaig has joined #zig
<mikdusan>
andrew what if we introduced a new target `abi` of `apple` -> x86_64-macos-apple <- which means "use the SDK. use the apple linker.". I'm not saying to make this the *default* detection, but we need a way to fix this apple stuff and just make it work.
<mikdusan>
*andrewrk
<pixelherodev>
Or we could choose *not* to send the message of being willing to work around bad choices?
<mikdusan>
here's an example... the bundled headers for macos do NOT work with Big Sur SDK. all stop.
<mikdusan>
if you take that stance, I guarantee you frameworks will never work except for an EXACT version of framework that is compatible with zig's bundled macos headers.
<mikdusan>
and it's an API surface area thing. while our tricks logic may appear to work for a trivial program, the more frameworks that are used, the more likely we get versions butting heads
cole-h has quit [Ping timeout: 260 seconds]
SebastianKeller has quit [Remote host closed the connection]
remby has quit [Quit: Konversation terminated!]
FireFox317 has quit [Ping timeout: 246 seconds]
travv0 has joined #zig
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
<andrewrk>
mikdusan, I think you have a good point, let me think about it. I do think there is plenty of room for applications which do not depend on any frameworks
<andrewrk>
and we don't bundle any framework headers, just libc
<mikdusan>
to target non-framework binaries is simpler indeed. we would just need to shore up > 10.15 OS detection for < 11.0 applications and because /usr/include and libc++ includes/libs are bundled that would defacto mean "x86_64-macos-gnu" means never use Xcode, SDK or external ld.
<mikdusan>
ie. in addition to no frameworks, it also means "never use SDKs"
<andrewrk>
I think it's a worthy proposal. we have a similar situation happening right now with windows-msvc vs windows-gnu
<mikdusan>
yeah the analog i guess would be macos-xcode and macos-gnu (macos-bsd? lol)
<mikdusan>
how lame am I <-- just discovered (enabled) github dark
<fengb>
Is there a github after dark? 🤔
<pixelherodev>
I think I'm going with the "split one big compilation into many small ones" option - figured out a good solution which basically just involves replacing @imports with the equivalent of a header :)
<pixelherodev>
Allows doing big compilations with a single root source file, but still breaking it down into one partial compilation unit per input file, then rejoining them later
jsb has quit [Quit: .]
jsb has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<daurnimator>
mikdusan: zig treats cross compilation as a first class citizen. apple doesn't. what you're suggesting demotes one of zig's goals.
<mikdusan>
I'm seeking to improve macos-hosted builds. cross-compiling to macos need not be effected
leon-p has quit [Quit: leaving]
<mikdusan>
from a birds eye view, it could just be that zig gears to only require enough headers to build against libSystem (libc) with the understanding that it's limited.
<mikdusan>
limited in ways like don't use macos bundled stuff like libc++, libedit, libexpat, etc etc. and of course don't use frameworks.
<mikdusan>
and then the recommended way is to use a contributed library for build.zig which has xcode toolchain support.
<mikdusan>
that would mean for example the issue that got me back on this,
<mikdusan>
that a project depending on 3rd-party { src/deps/imgui, src/deps/sokol },
<mikdusan>
would need to build those 3rd parties with build.zig using xcode toolchain support
<mikdusan>
that's probably not such a bad thing
* mikdusan
shakes magic 8 ball
<mikdusan>
apple will continue doing things like this; one day they'll realize /usr/lib is aniquated and drop it completely to make everything frameworks. That can't happen for Big Sur, but could for macos 12.x or 13.x
<mikdusan>
s/realize/classify/
craigo has joined #zig
sord937 has joined #zig
notzmv has quit [Ping timeout: 264 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
<mikdusan>
have an old school function that will either succeed or fail. don't care about reason. return type `bool` or `!void` and `return error.Failure;` ?
<mikdusan>
s/old school/simple
<fengb>
If the function name indicates the returned status, a bool is fine
<fengb>
If it's more mutation based, I'd prefer !void
<ifreund>
!void lets you use try
<mikdusan>
it's a detection function. param is pointer to struct that gets modified on success. yeah sounds like !void gets thumbs up. thanks
Patrice_ has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
riba has joined #zig
midgard has quit [Ping timeout: 260 seconds]
<pixelherodev>
ifreund: try is sugar, code shouldn't be deliberately written for the sake of using sugar, it's there to make other pieces easier to use when you're already using them...
midgard has joined #zig
<justin_smith>
pixelherodev: I think the idea here is that you can communicate a "failure" with a true versus false, or by returning an error state, and depending on what you are attempting one or the other might communicate design intent better
olabaz has joined #zig
<pixelherodev>
justin_smith: I agree with that completely.
<pixelherodev>
I don't think "!void lets you use try" should be factored in at all, though.
<olabaz>
Hi, I am brand new to zig and I'm trying to compile the hello.zig example in the documentation but it fails.
<ifreund>
s/lets you use try/lets you return the error up the call stack if you want/
<pixelherodev>
That is, I don't think language features should be considered relevant
<olabaz>
the error is: ./test.zig:4:38: error: no member named 'writer' in struct 'std.fs.file.File'
<pixelherodev>
olabaz: what version of the compiler?
<ifreund>
the sugar is irrelevant here
<olabaz>
pixelherodev: how do I check?
<pixelherodev>
ifreund: sure, but that's not how you phrased it - I agree with it as rephrased
<ifreund>
zig version
<pixelherodev>
olabaz: `zig v` ^
<olabaz>
0.6.0
<ifreund>
pixelherodev: fair :D
<pixelherodev>
Yeah, too old :P
<olabaz>
wtf I got it from apt
<pixelherodev>
Yeah, that's your problem.
<ifreund>
debian is always out of date
<pixelherodev>
Debian version is too old :P
mikdusan has joined #zig
<pixelherodev>
To be fair to Debian, that's normally a good thing
<fengb>
Try upgrading to 0.7.0 or 0.7.1
<olabaz>
can I upgrade from zig or do I need to reinstall the newer version
<fengb>
Yeah Debian is always at least 6 months behind
<pixelherodev>
I do wish that rapid changes weren't the norm :(
<fengb>
ziglang.org has master builds that you can unzip
<pixelherodev>
Ideally, Debian would always be up to date because software wouldn't keep chucking in new features
<ifreund>
olabaz: zig can't upgrade it itself, you can download a statically linked recent build here: https://ziglang.org/download/
<fengb>
Not packaged but you can run it from anywhere
<fengb>
Yeah Debian is designed for stability, not edge :P
<ifreund>
pixelherodev: how does software progress then? I for one am not satisfied with the current state of the "linux desktop"
<pixelherodev>
ifreund: neither am I, which is why I'm likely going to nuke my last Linux box today.
<fengb>
Hell its unstable repo is more stable than most other distro’s lts
<olabaz>
should I just grab 0.8.0 or is 0.7.1 stable the better choice
<pixelherodev>
There is no 0.8.0...
<pixelherodev>
Ahh, master build is labeled as 0.8?
<olabaz>
yeah
<ifreund>
I guess you're saying "ideally software was already perfect" which would be nice, but sadly not the case
<pixelherodev>
ifreund: not what I'm saying at all
<fengb>
Most of us run against master
<pixelherodev>
ifreund: I'm saying bug fixes and actual improvements only, no feature expansion
<fengb>
But 0.7.1 should be pretty stable for a few months
wootehfoot has quit [Ping timeout: 240 seconds]
<pixelherodev>
fengb: unless upstream decides to do 1717 at the same time I did ;)
<olabaz>
is master the same as master on github?
<ifreund>
yes
<fengb>
Yes
<ifreund>
though the automated builds will lag behind slightly
<olabaz>
ok I'll just do that and rebuild every once in a while
<fengb>
The “official” versioned release is just a snapshot, not a contract if stability
<olabaz>
(clone github)
<pixelherodev>
note that building requires LLVM installed
<pixelherodev>
Though, if you're on Debian, that's less ofa n issue :P
<fengb>
Not yet anyway. 1.0 will be the first actual stable release but that’s in a few years
<pixelherodev>
ifreund: to use a better example: a C compiler. My ideal linux distro would reject all patches to a C compiler other than bug fixes for Debian-lengths of time. No optimizations would be added until there's been at least a year without a single bug report about it, for instance.
<olabaz>
oh I don't have llvm
<pixelherodev>
ifreund: A better way to put it is that I don't want *my OS* to be giving me code others wrote to experiment.
<pixelherodev>
Linux distros don't curate finely enough in my opinion
<pixelherodev>
Alternate distinction: I like Arch's split of the AUR.
<fengb>
I wish Arch offered easier ways of distributing binaries
<pixelherodev>
I want the core official repo to be fully usable with actual software (not minimal, but *curated*)
<pixelherodev>
I want a repo for which every package is *actually inspected* fully by the distro - anything for which that's unreasonable gets rejected out of hand
<pixelherodev>
I want, in short, Oasis Linux :P
<fengb>
Nobody in Arch really distributes prepackaged stuff like .deb
<fengb>
Even though it’s possible
<pixelherodev>
Maybe I should switch to Oasis+Nix instead of nuking it entirely...
<pixelherodev>
Or Oasis+bespoke-package-manager :P
<pixelherodev>
... or, you know, oasis and that's it? That actually sounds perfectly reasonable for me
<ifreund>
though it is admittedly quite obscure currently
<companion_cube>
Let me guess, it's written in Janet?
<ifreund>
C and Janet
<ifreund>
Janet is used for the package definitions
<justin_smith>
in a test I'm using an array literal to provide input to a function that takes a slice, I see the message "error: array literal requires address-of operator to coerce to slice type '[][]Placement" - what does that look like syntactically?
<fengb>
&[_]Placement{}
<justin_smith>
fengb: great, thanks
<justin_smith>
fengb: I'm still having trouble - it's a 2d array and I can't seem to combine the declarations and nested declarations that make the compiler happy
<ifreund>
&[_][]Foo{&[_]Foo{}}
<ifreund>
whoops, need a const there
<justin_smith>
I got expected type '[]Placement', found '*const [2]Placement'
<ifreund>
&[_][]const Foo{&[_]Foo{}}
<justin_smith>
ahh
<justin_smith>
ifreund: I think this is getting closer but the error looks a lot like what I started with: http://ix.io/2L5u
<ifreund>
justin_smith: your place_tile function requires mutable slices
samtebbs has quit [Remote host closed the connection]
<justin_smith>
ifreund: oh right, of course it does, and I can't do that with literals
<ifreund>
you need to declare each inner array as it's own mutable stack variable
<justin_smith>
ifreund: I think it's a good sign that that looks like what I ended up with, still getting: "error: expected type '*[][]Placement', found '*[2][]Placement'"
fputs has quit [Quit: WeeChat 3.0]
fputs has joined #zig
<ikskuh>
marler8997: i assume you didn't see/follow the PR that created the original problem in the first place?
<ifreund>
why does place_tile expect a pointer to a slice?
<justin_smith>
ifreund: probably because of my relative ignorance of the language, it's probably fixable
<marler8997>
ikskuh, I believe I followed it but I didn't realize SocketNotConnected was a compile-time error (not a runtime error)
<ifreund>
but I'd be surprised if this is really what you want
<marler8997>
but then why is it a SendToError? would it also be a codebug when returned by sendto as well?
<justin_smith>
ifreund: what likely happened was I was shotgun debugging an unexpected result and ended up changing the slice into a pointer to slice and never changed it back
<ikskuh>
Because you can call sendto on both UDP and TCP sockets
<marler8997>
not following
<marler8997>
why would it be a runtime bug for sendto, but not send?
<marler8997>
a *runtime error (not bug)
<g-w1>
is this correct? it works (top level) `const x: u32 = {return 5;}; pub fn main() void {@compileLog(x);}` (stage1)
wootehfoot has joined #zig
<pixelherodev>
ifreund: uhh
<pixelherodev>
the github link worked fine lol
<g-w1>
that seems like a stage1 bug to me
<pixelherodev>
Github is trash on *any* browser, but it's *viewable* trash even w/o JS :P
<pixelherodev>
sr.ht is still muchhhh nicer on mothra though
<ifreund>
g-w1: indeed :D
<g-w1>
it was found by a beginner on discord who just stumbled across it because they didn't know the blk: syntax yet. probably should be fixed
<olabaz>
is there a difference in either compile time/exe size if I @import("std") vs just @import("std").debug.print
Wolf480pl has joined #zig
cole-h has joined #zig
<ifreund>
olabaz: no
<ifreund>
the zig compiler analyzes all code lazily
<pixelherodev>
Not remotely, no
<pixelherodev>
I'd even say that any system in which it made a difference was poorly designed :P
<lf94>
> using mothra to browse the web
<lf94>
you just just be mounting remote fs :)
<pixelherodev>
not when the remote is a HTTP server I don't ;)
<lf94>
that sucks :D
<lf94>
does sr.ht have an api?
<lf94>
for example, to list projects
<ikskuh>
marler8997: not sure why that decision was made
<ikskuh>
imho it should be a mistake in both cases
<olabaz>
when I run zig test tests.zig I only get "All 1 tests passed" but it doesn't say the name like in the docs 1/1 test "string literals"... OK
<g-w1>
thats because it is piped in the docs so the terminal escape codes dont work. you can pipe to less: `zig test test.zig 2>&1 | less` to get everything
<olabaz>
I see, thanks
lf94 has left #zig ["WeeChat 3.0"]
jokoon has joined #zig
<marler8997>
ikskuh, ok thanks for clearing that up
<marler8997>
although, I'm not sure on all platforms and in all cases, it's not possible for send to return ENOTCONN or WSAENOTCONN because of a disconection (i.e. it would be a runtime error in this case)
<marler8997>
documentation seems a little hazy on it
<olabaz>
why is S.x in the namespaced_global.zig example in the doc a global variable. Shouldn't S not exist after exiting the function foo()?
<olabaz>
I would expect you need a keyword like "static" in C?
<fengb>
All container variables are global
<ifreund>
S is just a name for the type of the struct declared there
<ifreund>
the struct type itself is "static" if you will, and variables declared within it are also static in the C sense/globabl
<ifreund>
note that files are also structs
<olabaz>
oh so S is a definition of the struct it's not an instance of one
<ifreund>
right, @TypeOf(S) is type
<olabaz>
can I redefine S?
<olabaz>
oh I guess not cuz it's const
<ifreund>
indeed, and types are required to be const by the language
<olabaz>
so I can't change the number/types of the fields but I can change their default values
<olabaz>
?
<g-w1>
no, you cant change anything
<g-w1>
think of it as defining a struct
<olabaz>
but it seems like S.x += 1 is changing the value of x
<olabaz>
field
<olabaz>
so if I were to declare something of type S before and after calling foo() one would have its .x = 1234 and the other .x = 1235?
<g-w1>
no, S is the type of the struct. do`var t = S { .x = 5}; t.x= 6;`
<fengb>
S.x is a declaration, not a field. It’s like a static variable in Java
<g-w1>
a field looks like this `const S = struct { x: u32 };`
<olabaz>
ah I see
dernatsch has joined #zig
<olabaz>
ok I think I get it. And this value S.x can only be accessed from within foo() and only by calling S.x?
<marler8997>
ikskuh, I'm looking into removing SocketNotConnected, however, I think there are use cases for it
<marler8997>
for example, when you have multiple threads that have a socket handle, the way to signal the socket to be closed is to call shutdown on it
<marler8997>
that can cause the program to call "send" or "recv", and that may produce an ENOTCONN