ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk>
MajorLag, I'll try to duplicate the problem tonight
<MajorLag>
I think I'm only really affected because I insist on not installing VS, or even running the BuildTools installer. I'm probably about the only person on earth affected by this.
<andrewrk>
I still want to make it work for this case
<MajorLag>
Of course. BTW, do I have to include my tests somewhere for CI to run them? I only included them in the zig file, didn't see them in the log output.
<andrewrk>
MajorLag, oh, we need os/index.zig to @import("time.zig") in a test {} block
<andrewrk>
or better yet: comptime { if (bultin.is_test) { _ =
<MajorLag>
ah, ok.
<andrewrk>
or better yet: comptime { if (bultin.is_test) { _ = @import("time.zig"); } }
<andrewrk>
workaround for lazy declarations
<MajorLag>
I was suspicious when my first CI succeeded. There's almost no way I got Darwin right on the first shot.
relatingdata has joined #zig
<MajorLag>
So should I alter the test block in std.os? because it currently doesn't use said workaround
isd has quit [Remote host closed the connection]
<andrewrk>
MajorLag, yeah that's perfect
<andrewrk>
I'll do my own suggestion to all the std lib later
<andrewrk>
MajorLag, your changes to the test/comptime thing make it so that --test-filter works if you do `zig test` on the root source file rather than the file with matching test names
<JinShil>
Hello again. Does Zig have anything in the language for dealing with volatile memory (think memory-mapped IO in microcontrollers)?
<GitHub60>
zig/master 06909ce Andrew Kelley: support break in suspend blocks...
isd has joined #zig
isd has quit [Ping timeout: 260 seconds]
relatingdata has quit [Quit: Page closed]
heakins has joined #zig
l1x has joined #zig
JinShil has quit [Quit: Leaving]
adagio1 has quit [Quit: Leaving.]
<achambe>
anyone know if there are there any coverage tools that work with zig debug symbols as it is?
<alexnask_>
@andrewrk What is the difference between void and c_void? Thought I'd ask since I see a todo for it in the docs, I assume it's important
adagio1 has joined #zig
adagio1 has quit [Ping timeout: 240 seconds]
Hejsil has joined #zig
<Hejsil>
As far as I know, void in zig is just a 0 byte type. You can have fields, variables, parameters, returns that are void and they are just treated like a 0 byte value. c_void works like in C (aka, you can have void pointers, but c_void is not something that can be a value)
<alexnask_>
Ah, ok, gotcha.
<alexnask_>
Thanks!
<Hejsil>
Np!
<alexnask_>
Anyone knows if there are opengl bindings available? Or should I just cInclude + link it and work that way?
<Hejsil>
I think that's how all projects that want opengl does it
<Hejsil>
for now
<Hejsil>
I haven'
<Hejsil>
t seen any bindings
<alexnask_>
Ok, I'll do it that way and if I end up building useful abstractions around it I may split them off into a small package
<Hejsil>
@alexnask_, void is a little special. You are allowed to ignore it when returned from functions, but other 0 size types cannot be ignored: https://pastebin.com/raw/tTCbpn9S
<Hejsil>
Just food for thought
<alexnask_>
I like the way void is handled, metaprogramming in C++ can sometimes be a pain because of the issues zig appears to be solving
<Hejsil>
It's, in general, a little weird that types can't be of size 0 in C/C++
<alexnask_>
Well it's a requirement for the memory model of C++ at least in the recent (C++11 forward) standards.
<alexnask_>
Each object must have a unique address I believe
<alexnask_>
So empty structs have to be of sizeof 1
<Hejsil>
Ooh! C handles 0 sized structs, lol
<Hejsil>
But ye, C++ gives it size 1
<alexnask_>
Huh, I assumed they worked the same as C++
<Hejsil>
Apparently not
<alexnask_>
C standard guy missed the memo I guess :P
<alexnask_>
guys*
<alexnask_>
Since they seem to be copying everything else from C++11
<Hejsil>
Hmmm. For variables, C still pads them out, so they have unique address'
<alexnask_>
sizeof(void) is 1 too
<alexnask_>
sizeof(<empty struct>) returns 1 in gcc too
<alexnask_>
woops im in C++ mode
<MajorLag>
alexnask_: I actually don't link to C for OpenGL (on windows). I just used translate-c on the headers and link to OpenGL.lib. Obviously also the relevant Win32 wgl code.
<alexnask_>
Right, so libc isn't needed
<alexnask_>
Any funcitonal difference between using translate-c on the headers and doing cImport or does cImport translate C behind the scenes?
<Hejsil>
cImport uses translate C, as far as I know
<MajorLag>
I personally use translate-c because it lets me clean up anything that wasn't converted correctly.
<alexnask_>
@MajorLag, are you @tgschultz on github?
<alexnask_>
Where does zig look for packages?
<alexnask_>
I can't find any command line option that overrides it
alexnask has joined #zig
alexnask_ has quit [Ping timeout: 256 seconds]
<alexnask>
Nvm I just import the index file I guess
<MajorLag>
alexnask: Yeah, that's me. Also, there's a commandline option to specify packages `--pkg-begin [name] [path] --pkg-end`, and some way to do that in build.zig but I'd have to check the docs.
<alexnask>
Tried using those but I don't really get how they work or what the path is relative to, I'll just stick to importing for now
adagio1 has joined #zig
<Hejsil>
alexnask, im pretty sure the path is relative to where you call zig build-exe. The path is relative to build.zig if you use the build system
<alexnask>
Didn't seem to work that way, I guess I'll give it another shot
<MajorLag>
oh good, seccomp can actually return arbitrary errno values.
<Hejsil>
And the fun begins
<Hejsil>
Grrr, I really need "reflection" of enums. I have to generate a lookup table, but right now it is not possible to iterate over all enum members and add each of them to the table.
<Hejsil>
Maybe I should look into adding @field
Hejsil has quit [Quit: Page closed]
adagio1 has joined #zig
<alexnask>
@MajorLag Is there any issue tracker/comment section I can notify you on about issues with the winapi package?
<alexnask>
The one I caught right now is that WNDPROC appeard to require a stdcallcc function
<alexnask>
With the current definition it gets called a couple of times correctly then it crashes (presumably when we try to get some argument since we're talking ABI issues)
<MajorLag>
Right now, because I don't really use git for my own work, there isn't anything like an issue tracker. Things on that site are just kind of as-is. Feel free to email me or get my attention here though.
adagio1 has quit [Quit: Leaving.]
<alexnask>
Sure, I will probably mail you a diff if end up touching quite a bit.
<MajorLag>
I'm confused. From what I can tell, WNDPROC is LRESULT CALLBACK, and CALLBACK is __stdcall.
<MajorLag>
My win32 test program works correctly with it declared as stdcall.
<MajorLag>
granted, my wndproc is pretty much just passthrough on that.
<andrewrk>
as far as I understand, all the windows API functions should have stdcallcc on them. it matters for x86, but for x86_64 stdcallcc and c abi are the same thing
<alexnask>
Sure, currently WNDPROC = '?fn(HWND, UINT, WPARAM, LPARAM) LRESULT;'
<alexnask>
I added the stdcallcc in my version
<andrewrk>
almost certainly it should at least be `extern fn` to get the c abi
<alexnask>
It crashes with extern too
<andrewrk>
is this 32 bit?
<alexnask>
As MajorLag said, WNDPROC should be a CALLBACK which is __stdcall
<alexnask>
Yes, this is in 32 bit
<andrewrk>
ah I see. yeah that makes sense. 32 bit is the one where stdcall matters
<alexnask>
Yup, on x64 there is a signle calling convention for windows iirc
<alexnask>
single*
<MajorLag>
ah, ok, I'm on 64bit so I'm not seeing the same issue
<alexnask>
Right, that makes sense
<MajorLag>
Oh, and apparently I didn't declare my fn using WNDPROC, I just went ahead and said `pub stdcallcc fn`
<alexnask>
Got crinkler to work like a charm btw, I'm now producing ~1kB executables to open a window
<alexnask>
I just need to build a .lib for every def file with lib.exe and then link to those libs + the microsoft sdk ones
<alexnask>
@MajorLag I defined it that way too but you can't fill the WINCLASS struct with it unless WNDPROC is changed on 32bit.
<alexnask>
On 64 bit I assume zig is smart enough to know that the calling convention is the same and lets you assign into it (perhaps?)
<alexnask>
WNDCLASS*
<andrewrk>
assign into what?
<MajorLag>
I did a pointer cast apparently. It has been a while since I've worked with this. I keep meaning to port toy game engine to it so I can unshackly myself from SDL, but I haven't gotten around to it.
<andrewrk>
you can definitely do what you're trying to do. stdcallcc is one of the supported calling conventions of zig
<alexnask>
Right, so you basically just got around the type system :P
<andrewrk>
oh I see the question now
<andrewrk>
allowing implicit cast on x86_64 from stdcallcc to extern
<alexnask>
Anyways, I'll send you a diff once I have some changes stacked up
<alexnask>
@andrewrk Right, something along those lines
<MajorLag>
yeah, I was too quick to work around it rather than actually figure out the issue.
<alexnask>
Btw, is there any way to init a struct to all zeroes?
<alexnask>
Without leaving it uninitialized then memseting it, that is
<andrewrk>
alexnask, no
<alexnask>
Ok
<andrewrk>
idea being, you want a compile error at all the initialization sites when you add a new field
<alexnask>
Right, makes sense
<MajorLag>
I wouldn't be surprised to find a whole lot of stuff broken in that package, because as I noted on the site it was built from translate-c (an older, more broken version at that), and then I applied a lot of manual and automated cleanup, doing at least compiler error checks where possible.
<alexnask>
With @field it could be written in userland anyways
<alexnask>
@MajorLag No worries, better than going through the same process all over again :P I'm not really expecting a stable package ;)
<MajorLag>
you can write it in userland without @field. `fn zeroStruct(comptime T: type) T { var s = undefined; mem.set(T, s, 0); return s; }`
<alexnask>
I just need a window with an OpenGL context and ESCAPE to work, really :P
<alexnask>
Good point
<MajorLag>
that's basically what my test program is, so you should be covered.
<andrewrk>
feel free to contribute to std/os/windows/index.zig btw
<andrewrk>
ideally all the windows api you'll ever need will be there eventually
<MajorLag>
std does things a little different from how I setup the win32 package. win32 sticks closely to the C definitions, where for instance std uses @OpaqueType for HANDLE.
<MajorLag>
which breaks MAKEINTRESOURCE
<andrewrk>
the way it works in std makes it so you can't accidentally pass an HINSTANCE where an HMODULE was expected or vice versa
<andrewrk>
but it sounds like that is sometimes desirable?
<andrewrk>
you can always @ptrCast betwen them
adagio1 has joined #zig
<MajorLag>
oh, i didn't realize that was allowed for @OpaqueType. I suppose @intToPtr(@ptrToInt), the swiss army knife of hackery, would have worked too.
<andrewrk>
c_void is just defined like this: const c_void = @OpaqueType();
hoppetosse has joined #zig
<andrewrk>
so the difference between &c_void and &@OpaqueType() is that the second one is not the global one that everyone shares
<MajorLag>
good to know. I may add enough code to std.os.windows in the near future to get a window up and running in that case. So much on my todo list though...
<MajorLag>
If I do that I may also convert those A calls to W... but that would require an allocation for runtime values which might affect other parts of the stdlib that don't necessarily take an allocator currently.
<andrewrk>
yeah. it's going to be a bit of an annoying undertaking
<andrewrk>
fortunately (or not) a lot of the places where it matters, we already need an allocator in order to insert a null byte
<MajorLag>
true, but that might be going away with pointer reform.
<MajorLag>
If only MS had been lazy and not implemented unicode until UTF8 came around.
<andrewrk>
it wouldn't fully go away. best case scenario we would have multiple ways to call the same API - e.g. File.open and File.openAndMyPathAlreadyHasANull
<andrewrk>
the former would call the latter
<MajorLag>
probably best to do that with var on the string and comptime branch?
<andrewrk>
hmm that's an idea
<MajorLag>
yeah, actually I'm not sure it's a good idea though.
<andrewrk>
yeah because the already has a null case doesn't need an allocator
<MajorLag>
maybe a `noAlloc` namespace for those calls?
<MajorLag>
though that's not strictly true either, since read would alloc anyway.
<andrewrk>
and then another question is do we also support if you called it with UTF-16LE with a null byte, because then for windows we wouldn't need an allocator
<andrewrk>
it starts to get messy
<andrewrk>
I think this is related to braedon's pull request
hio has joined #zig
<MajorLag>
Technically speaking it isn't even UTF-16LE in Windows. I think it is better to present a consistent interface everywhere outside of the os namespaces themselves. If that means everything is in null-terminated UTF8 then so be it, and if you're concerned about allocations on windows or a unix system that uses utf32 or something, you should bypass std.
<alexnask>
Imho there should be access to the "raw" C functions (in the os namespace), os specific bindings on top of that (e.g. wrapping up stuff in enums, returning error sets etc.) then the rest of the standard library uses what is most convenient and takes care of marshalling data to and from the os as needed.
abique|home has joined #zig
<abique|home>
Yo
<abique|home>
How far is the 0.3 development ?
Ichorio has joined #zig
hio has quit [Ping timeout: 260 seconds]
Hejsil has joined #zig
MajorLag2 has joined #zig
MajorLag has quit [Ping timeout: 260 seconds]
adagio1 has quit [Quit: Leaving.]
adagio1 has joined #zig
MajorLag2 is now known as MajorLag
<MajorLag>
I had completely forgotten that zig supports scientfic notation for literals. unfortunately it turns them into float literals.
<alexnask>
Can't you just comptime cast them to integers?
<MajorLag>
sure, but then I have to cast them any time I use them for a different type.
<MajorLag>
I don't believe I can cast to integer literal, but I've never tried...
<MajorLag>
doesn't look like it, compiler assert for trying.
<GitHub127>
[zig] Hejsil opened pull request #934: Added @field builtin function (master...adding-builtin-field) https://git.io/vpton
<Hejsil>
Here comes reflection boys!
<Hejsil>
Or, well
<Hejsil>
Idk if we can call @field refection
<Hejsil>
But it's powerfull
<MajorLag>
is it functionally identical to @ptrToInt(M, @intToPtr(t) + @memberOffset(T, m))?
<Hejsil>
What if you want Enum.A?
<Hejsil>
That's what @field solves
<MajorLag>
true
<MajorLag>
wait, does it also work on empty structs?
<MajorLag>
because I can use that
<Hejsil>
Yes, you can get fields from "namespaces"
<MajorLag>
Now all we need is a way to check for the existence of a name in a namespace and it'll be trivial to have fmt use custom formatters for types.
<Hejsil>
Wouldn't you just call a .format on the type?
<Hejsil>
And if it doesn't exists, the the compiler will throw the error for you
<MajorLag>
yeah, but maybe I don't care and just want the default behavior of '<Type>@<ptr>'
<Hejsil>
Aah
<Hejsil>
Could you use @memberCount, @memberName?
<Hejsil>
And look up the name?
<MajorLag>
only work on actual members
<Hejsil>
Ooooh
<Hejsil>
Hmmm
<alexnask>
Awesome
<MajorLag>
We could just take a format option for it, which I did as an example: `warn("{@}\n", myTypeInstance);`
<alexnask>
We just need @reflect and @reify now :p
<MajorLag>
Those will be game changers I think. A lot of builtins would be redundant and a lot of code could potentially be simplified... or you know, intentionally complicated.
<alexnask>
Yeah the ability to generate types with imperative code is crazy
<MajorLag>
I'm excited for them but also a bit worried by what kind of C++ templating nightmares and random DSLs might come out of it.
<alexnask>
I think you can only do something similar in D and possible Nim
<alexnask>
I think it will be a lot cleaner than C++ templates in a lot of cases
<alexnask>
And at the end of the day the proposal is just about types, so I don't think it's too much magic for users to handle
<Hejsil>
You can already write some weird code with comptime and inline loops
<Hejsil>
Soo, I don't think it's a problem
<alexnask>
Generating functions in global scope etc. would be a whole other issue
<Hejsil>
People will make hacks
<Hejsil>
That's how it is
isd has joined #zig
<andrewrk>
Hejsil, ooh, exciting PR
<Hejsil>
Idk if my solution is the best
<Hejsil>
I requires little code, but it changes the analyzation of field access
<andrewrk>
I think it's good. I'm still reading, but I think the only change I want to make is to have the "hot path" where it's a normal field access still use the Buf * instead of going through IrInstruction *
<andrewrk>
only for performance reasons
<andrewrk>
but overall this is a simpler change than one would have thought, right? :)
<Hejsil>
So, something like a union with id, where the field name can either be and instruction or buf
<Hejsil>
Ye, it was pretty simple
<Hejsil>
Though I was staring at a nullptr deref for a while
<alexnask>
Right, just looked at the PR, surprising how little code it takes
<andrewrk>
I think just having both fields. and then ir_analyze_instruction_field_ptr looks for the buf first followed by the instruction
<andrewrk>
we have this pattern in a couple other places
<Hejsil>
Right
<Hejsil>
I'll do that
<andrewrk>
I don't know how you couldn't have found the pattern, in a 19,000 line file, lol
<Hejsil>
I didn't read the whole thing mad
<Hejsil>
Read what was required to solve the problem
<Hejsil>
man*
<andrewrk>
to be clear, I'm making a self deprecating humor joke
<andrewrk>
this PR looks very good
<Hejsil>
I'll do the optimization, and the merge then
<alexnask>
Btw, does this work for structs? For example, to get a method from a struct
<Hejsil>
Yes. It does the same as 'a.b'
<alexnask>
Nice
<Hejsil>
For any type
<Hejsil>
I should also add doc!
<Hejsil>
I forgot!
<Hejsil>
Arg! There was a bug!
<Hejsil>
This doesn't work @field(f, "o" ++ "ne") = 4;
isd has quit [Read error: Connection reset by peer]
isd has joined #zig
<alexnask>
Do defer blocks run before or after the return statement?
<alexnask>
I'm trying to lift up an error from a call in a defer block to the parent function's return
<Hejsil>
I think it runs after the expression in the return statement is evaluated
<alexnask>
Right, makes sense, I tried declaring a variable in the function's scope and binding it in the defer then return it at the end of the function
<alexnask>
But that wouldn't work either
<Hejsil>
So: var x = 0; defer x = 7; return x; ?
<alexnask>
Right, something like that
<Hejsil>
Ye, I don't that probably wont work
<alexnask>
Ofc my goal is to propagate the error if it happens if the defer
<alexnask>
I don't necessarily need to use a variable
<alexnask>
It's probably impossible right?
<Hejsil>
Ye, you can't return from defer
<Hejsil>
And I think that's a good choice
<Hejsil>
I don't even know how returning from defer would work
<alexnask>
Sure, makes sense if it's evaluated after the return
<alexnask>
Right, I' probably only need a single return point in my function so I don't even need to defer
<andrewrk>
alexnask, in the future when we have more sophisticated control flow analysis, Hejsil's example code would be a compile error on the x = 7 expression: `value written but never read"
<alexnask>
A specific error message for writting to a stack variable in a defer statement could make sense too right? I don't think it is valid in any situation right?
<alexnask>
That is, writting to variables in the current function's stack frame
<andrewrk>
defers can be inside a block in a function though, and then it's fine
<andrewrk>
better to solve the general case
<alexnask>
Woops, forgot defer works on a scope level
<alexnask>
Go has poisoned my mind :p
<andrewrk>
defers in go can allocate memory
davr0s has joined #zig
abique|home has quit [Quit: Leaving]
mal`` has quit [Quit: Leaving]
<Hejsil>
Common tests, pass! I want to go play with my new toy!
<andrewrk>
pro-tip: the CI will create a static linux build for you even for branches