<andrewrk>
daurnimator, sure. the first bullet point is describing master branch. the last bullet point is not relevant anymore, I've eradicated all of the `posix` namespace
<andrewrk>
"This may cause a OS's std/os/* to be quite small! " -> have a look at in that branch, std/os/freebsd.zig and the others that should be small - this matches your comment
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 248 seconds]
<andrewrk>
the only differences I see here are that you want a new non exhaustive enum feature for SYS_* and you want std/os.zig to be empty. where would that code go then? it's used all over the place
<andrewrk>
maybe you can do a proof of concept PR that doesn't have to pass any tests, to show what you mean
<daurnimator>
andrewrk: the non-exhaustive enum thing was just an example of how the syscall wrappers should be 'zigified' => another example there is that syscall wrappers should return actual zig errors.
<daurnimator>
e.g. mmap should return: linuxError![*]align(4096) u8
<andrewrk>
you want to remove the feature that functions have limited error sets?
<daurnimator>
andrewrk: syscalls *don't* have limited error sets though
<andrewrk>
I'm pretty confident the limited error sets are good
<andrewrk>
they certainly do; some errors would be undefined behavior
<daurnimator>
andrewrk: the limited error sets would be done in e.g. 'std/fs'; where e.g. for `open` you would switch on linuxError and say that ECONNREFUSED is unreachable
<daurnimator>
andrewrk: they aren't...
<andrewrk>
e.g. if you get ENOSYS from exit()
<daurnimator>
andrewrk: the kernel is free to use different errnos for any release. it's not considered stable api
<andrewrk>
I'm not going to change how error sets for linux work in this branch
<daurnimator>
andrewrk: I think you should; or very soon after: would be good to only have breakage happen once here
<andrewrk>
I'll keep an open mind about it, but I'm strongly of the opinion the limited error sets + Unexpected are significantly beneficial
<andrewrk>
there's a reason the man pages for syscalls list the possible errors
<daurnimator>
they are rarely correct...
<daurnimator>
not to mention that e.g. WSL introduces all sorts of different errnos for operations
<andrewrk>
zig's error sets are going to make zig one of the only platforms where it's reasonable to write software that behaves perfectly on WSL as well as real linux
<andrewrk>
daurnimator, zoom out a little - what are you trying to solve?
<daurnimator>
andrewrk: see the bottom of my comment: to "separate the 2 from the 3"
<andrewrk>
I don't see that as a goal in and of itself
<daurnimator>
andrewrk: but in general: std/os is only what the OS has made stable ABI. std/c is the bindings to libc; and implements any C conventions (such as errno) that aren't actually part of OS ABi
<shachaf>
Does Zig have a standard way to represent errors that contain more information than an integer?
<emekankurumeh[m]>
no
<andrewrk>
shachaf, that extra information has to be communicated via a separate channel
<emekankurumeh[m]>
hmm, if errors are like enums (as the docs say) why can
<emekankurumeh[m]>
't we have tagged unions, using errors as the tag type?
<andrewrk>
emekankurumeh[m], how would `try` work?
<shachaf>
I do like the error handling primitives Zig came up with. They're very similar to what I was thinking about not long before I found out how Zig does it.
<emekankurumeh[m]>
the same as with regular errors
<andrewrk>
emekankurumeh[m], can you elaborate? regular errors are integers not error unions
<emekankurumeh[m]>
a "tagged error union" would implicitly cast to it's tag type like with regular tagged unions
<emekankurumeh[m]>
and vice versa when possible
<shachaf>
OK, so you returns it with an out parameter or something.
<andrewrk>
yeah, something like that
<andrewrk>
I really don't think it's so bad
<andrewrk>
plz don't use threadlocal variables
<emekankurumeh[m]>
but it could be better
<shachaf>
That works and is generally better than something errno-style.
<shachaf>
But if you don't need that sort of thing for regular return values, it's funny to require it here.
<emekankurumeh[m]>
"that works" really shouldn't be the goal with zig imo
<andrewrk>
emekankurumeh[m], I still don't understand your suggestion. so `try` would toss the error payload - if any- in the trash?
<andrewrk>
do the same error names have to have the same payload type globally?
<shachaf>
What's the suggestion? That the error type be a tagged union, so it might be of different sizes depending on what errors are possible?
<andrewrk>
I'm not opposed to this idea if all the complexities and consequences of it can be worked out satisfactorily
<shachaf>
If that's the case then giving the same errors the same payloads seems like the only reasonable thing to do.
<shachaf>
It's already the case that you don't want two people ever using the same error name for different errors.
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
<andrewrk>
currently @sizeOf(anyerror) is 2, with an open issue to make that configurable. if errors could have payloads then this could potentially raise the size of `anyerror` to be large
<shachaf>
If I understand how errors work now, they seem kind of like Go interfaces, where they don't need to be explicitly declared but implicitly there's still a connection between different uses of them.
<andrewrk>
this is a proposal that needs a lot of consideration,examples, and explanation. feel free to open it and make the case
coolreader18 has quit [Ping timeout: 272 seconds]
<daurnimator>
an off the cuff idea: a module can "define"/"claim" a error's payload. e.g. error.MyNetworkLibFail = struct {client_code: u8, server_code: u8, category: u8};
<daurnimator>
@sizeOf(ErrorSet) would be the max of any errors in that error set
<merlyndmg>
how would that work cross-module?
<emekankurumeh[m]>
and @sizeOf(ErrorSet.MyNetworkLibFail) would be the size of that specific struct?
<emekankurumeh[m]>
just allowing errors as union tags could be a huge improvement imo
<merlyndmg>
so different topic, is there a set of win32 test programs out there already? like "hello world window that doesn't open a console, has a proper event loop and callbacks", etc? If not, I'm tempted to make some.
<merlyndmg>
the tetris one kinda works but it pulls in a lot of deps to make it work, and so far it's been a bit screwy building it *on* windows. just thinking of starting with something simpler to test stuff out, if it hasn't already been done
<andrewrk>
if you target windows-only that should be pretty straightforward
<emekankurumeh[m]>
andrewrk: the error still persists with #2532
<andrewrk>
unfortunately cross platform window/graphics is a complete mess
<merlyndmg>
oh, it's not hard to do. I know how to do a win32 app in C :) It's just some things seemed to be working out messily so I was thinking of making some "here's a win32 app" examples to test out if there's any linker behavior issues or no. i.e. --subsystem didn't seem to be working correctly for me last night.
<merlyndmg>
wanted to know if such a thing already existed and I'd be duping effort or not
<merlyndmg>
"it still opens a console though, but i'm working on a patch to fix that" - yeah, this is what I was talking about. didn't know anyone was actively working on it though
marijnfs_ has quit [Ping timeout: 268 seconds]
<emekankurumeh[m]>
the trick part will be getting zig to respect user defined entry points
<shachaf>
Man, I'm going to port my Linux+X11 C thing to Win32 at some point and I'm not looking forward to it.
<shachaf>
Not that X11 is a lot of fun.
<emekankurumeh[m]>
i think zig exporting its entry points as weak might do it
<merlyndmg>
oh I didn't notice the link you sent emek* due to the color and it being next to join/leave messages. checking that out now
<emekankurumeh[m]>
if it's the second link, its unrelated to the windows stuff we were talking about
<merlyndmg>
the first link is the one I meant. and yeah, looks basically like the win32 example test code I was thinking about writing
<merlyndmg>
plus dx/ogl support. so yeah, easy enough to delete half it
<emekankurumeh[m]>
did you have the prototype wrong before then?
<merlyndmg>
possibly
<merlyndmg>
the signature was entirely different, and it wouldn't compile
<merlyndmg>
hence why I wanted to try actually doing it right :)
<emekankurumeh[m]>
a different signature wouldn't be a compile error though
<emekankurumeh[m]>
did you export the function?
<emekankurumeh[m]>
because i get the same error you were describing when i leave off the export
<merlyndmg>
could have been it, yeah. I trashed my context since last night so will take a bit to get back into the thick of it
<merlyndmg>
I'm going to experiment with just a hello world program for a bit and see if I can repro with that
<emekankurumeh[m]>
for some reason zig thinks my function is void not noreturn even when the last thing my function does is call another noreturn function
<merlyndmg>
did you paste the wrong one? I did a diff and they're the same
coolreader18 has joined #zig
<emekankurumeh[m]>
whoops
<emekankurumeh[m]>
fixed
<merlyndmg>
yeah, so "pub" vs "export" might have been the issue I ran into last night. Haven't gotten far enough in the language to know the difference between those
<merlyndmg>
But a "WinMain() void" seems to work and get the right subsystem, as long as I do "export" and not "pub"
<merlyndmg>
a function named winmain seems to work (at least, it compiles, runs, and doesn't make a console window) even without the right signature
<emekankurumeh[m]>
zig's behavior regarding winmain and winmaincrtstartup is a little weird as changing the calling convention changes which symbols are exported
<tgschultz>
emekankurumeh[m] com unfortunately won't cut it in the long run, but I did at least get llvm to assemble absolute-addressed 16-bit code to use a DPMI host to enter protected mode and allocate memory, then extract that from the ELF as a COM executable. The issue is that LLVM doesn't understand a single output format that is actually loadable by a DOS natively or any DPMI host I've found (except one, which would
<tgschultz>
handle PEs and a good chunk of Windows API... of only we could actually target 32-bit Windows right now at all).
<tgschultz>
Ultimately I'm not sure what the solution will look like, but it will probably involve a DPMI stub written in assembly, and teaching the compiler to output an MZ exe. Possibly it would need even more complication by then embedding the actual program as an LE, but we might be able to avoid that.
neceve has joined #zig
<merlyndmg>
how do I ifdef in different functions depending on OS?
<merlyndmg>
I know that comptime exists but not entirely how to use it
<merlyndmg>
and the builtin module
<andrewrk>
merlyndmg, `if` and `switch` expressions
<andrewrk>
as long as the condition/expr is comptime known
<merlyndmg>
I can't do a if at file scope can I?
<merlyndmg>
for example, say add and export 10 more functions if const some_config_value = true;
<andrewrk>
you have to do it in a declarative way, so to accomplish that you would put 10 functions in a struct, and then `use if (some_config_value) your_struct_with_10_funcs else struct{};`
<andrewrk>
but probably you don't need `use` and you can simply have those 10 functions namespaced (or not) and they won't be referenced if some_config_value is false
<merlyndmg>
I mean, really what I'm trying to do is rename main if I'm on windows :) you said that, and I started wondering if it was going to be able to see it if "namespaced" via a struct
<andrewrk>
merlyndmg, when the root source file has pub fn main()
<andrewrk>
the build type is build-exe
<andrewrk>
*and the build type is build-exe
<andrewrk>
and the target is not freestanding
<emekankurumeh[m]>
or WinMain
<andrewrk>
that's either not correct or it's a bug
<fengb>
Oh I see
<emekankurumeh[m]>
scratch that, exporting WinMain does not cause bootstrap.zig to be linked in
<merlyndmg>
alright I found the codegen for including bootstrap, will dig in
<emekankurumeh[m]>
if you perform a weak export, then a strong export with the same name shouldn't the strong export work?
<emekankurumeh[m]>
ie. be exported without error?
<andrewrk>
emekankurumeh[m], yes in a separate compilation unit
neceve has quit [Read error: Connection reset by peer]
coolreader18 has quit [Ping timeout: 258 seconds]
<emekankurumeh[m]>
i'm noticing that fields in builtin.TypeInfo.Definition.Data aren't being set to true values
<emekankurumeh[m]>
the calling convention is always CallingConvention.Unspecified and is_exported is always false
_whitelogger has joined #zig
_whitelogger has joined #zig
scientes has joined #zig
_whitelogger has joined #zig
scientes has quit [Ping timeout: 268 seconds]
_whitelogger has joined #zig
fengb has quit [Ping timeout: 256 seconds]
sadanjon has quit [Quit: Page closed]
wootehfoot has joined #zig
WilhelmVonWeiner has joined #zig
WilhelmVonWeiner has left #zig [#zig]
neceve has joined #zig
Ichorio has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<nrdmn>
andrewrk: is building zig only for specific targets supported?
<nrdmn>
I'm writing a gentoo ebuild for zig and would like to avoid it depending on an llvm that is built for all supported platforms
scientes has joined #zig
<tgschultz>
nrdmn I'm not sure that aligns with Zig's philosophy of being able to cross compile for any target from any target.
<tgschultz>
then again, that doesn't really work for the freestanding platforms, so... I don't know.
scientes has quit [Ping timeout: 268 seconds]
scientes has joined #zig
marijnfs has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 245 seconds]
Pursche01 has joined #zig
<andrewrk>
nrdmn, no that's not supported
knebulae has quit [Read error: Connection reset by peer]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
knebulae has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
merlyndmg has quit [Ping timeout: 272 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
neceve has quit [Ping timeout: 272 seconds]
neceve has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 244 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 252 seconds]
<emekankurumeh[m]>
why wouldn't you want to able to cross compile?
<nrdmn>
emekankurumeh[m]: I'd want to, but usually gentoo users enable only those targets for their llvm builds which they actually need. Just to install zig, they'd have to recompile llvm, which takes well over an hour on a laptop
<andrewrk>
any builds of llvm/zig that do not support all the targets are not supported by the upstream zig project
<andrewrk>
it's not considered a valid use case
hio has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 248 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
marijnfs has quit [Ping timeout: 268 seconds]
scientes has quit [Ping timeout: 244 seconds]
<shritesh>
It would be nice if `zig init-exe` created a .gitignore with zig-cache in it
voldyman has joined #zig
neceve has quit [Read error: Connection reset by peer]
porky11 has joined #zig
<andrewrk>
shritesh, how about if it detecst a .git folder then it does that
<shritesh>
Maybe. My usual workflow is add some files -> git init.
<shritesh>
I know some web dev tools init git too (though they may not be the best model to follow)
<torque>
I think shoehorning version control interop into tools that aren't expressly for that purpose is bad practice
Ichorio has quit [Ping timeout: 250 seconds]
<emekankurumeh[m]>
what if svn or mecurial was being used?
<shritesh>
Yeah. I think it’s safe to just put zig-cache to global gitignore.
<shritesh>
Also, shouldn’t `zig build run -- args` pass arguments like `zig run src/main.zig -- args` does?
wootehfoot has joined #zig
<mikdusan>
shritesh: a complication with `zig build run -- args` is build can have more than 1 top step to perform. `zig build run1 run2 test3`
marijnfs has joined #zig
scientes has joined #zig
<shritesh>
Can the run step be a special exception like install is?
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 272 seconds]
shawn_ has joined #zig
scientes has quit [Disconnected by services]
shawn_ is now known as scientes
porky11 has quit [Quit: Leaving]
scientes has quit [Ping timeout: 248 seconds]
<mikdusan>
hmm now i'm second-guessing my previous opinion about what `zig build run` should do: run from zig-cache or install dir.
<mikdusan>
presumably running from zig-cache is inconvenient due to hash in the pathname. and install dir is more straight forward. you know where it's going.
<mikdusan>
so in case of manually running from install, you can of course supply command line args.
<mikdusan>
in case of `zig build run`, maybe a rule like `-- args` is used ONLY if there is exactly one top-level step specified.
marijnfs_ has quit [Ping timeout: 258 seconds]
Aransentin has joined #zig
scientes has joined #zig
<Aransentin>
It seems like I can't cast an array to [*]u1 as to then get the n-th bit of it... Is there a nice ziggy way of doing that, or should I just use shifts and stuff like I would in C?
shawn_ has joined #zig
scientes has quit [Remote host closed the connection]
<emekankurumeh[m]>
would having use bring a specific identifiers into scope be acceptable
<emekankurumeh[m]>
ie `use module.some_fn;` is syntax sugar for `const some_fn = module.some_fn`
scientes has joined #zig
marijnfs has joined #zig
shawn_ has quit [Ping timeout: 248 seconds]
<marijnfs>
man i can't get linking to cuda work, i just want to get a simple cudamalloc to run
<marijnfs>
it links but then crashes
marijnfs has quit [Ping timeout: 272 seconds]
<tgschultz>
Aransentin: zig doesn't support bit-arrays in the language. an array of u1 is an array of bytes in which only 1 bit is used. What you want is supported in userland with std.PackedIntArray and std.PackedIntSlice
<Aransentin>
Ah, thanks :)
Pursche01 has quit [Quit: Connection closed for inactivity]
<tgschultz>
alternatively you could cast it to an array of packed structs.
marijnfs has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 248 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
wilsonk has quit [Ping timeout: 246 seconds]
marijnfs has quit [Ping timeout: 245 seconds]
marijnfs has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
<marijnfs>
hmm it seems I can call cuda functions, just malloc segfaults, probably because i screw up the arguments
hio has quit [Quit: Connection closed for inactivity]
<marijnfs>
to give a void pointer i make a ?*c_void right? can give a ref to that?
<marijnfs>
damn it works, apprently my code above that corrupted the stack:O