<pixelherodev>
What text editors have the best support for Zig? e.g. I use Geany, but it has zero support at the moment and I'm not starting yet another side project to change that
<andrewrk>
vscode, vim, sublime, emacs
<andrewrk>
you're not going to find type-aware auto completion in any editor yet
<tgschultz>
gruebite see 1268 and 1669 for current state of discussion on traits
<pixelherodev>
I was honestly just thinking of *highlighting* :P
<pixelherodev>
It's so awkward having colorless text all of a sudden
<tgschultz>
I use Notepad++ and distribute a UDL for highlighting, but that's Windows only
<tgschultz>
speaking of which, doccomments are in a different color now so it looks even more like unicorn vomit than ever
<andrewrk>
just as advertised
<pixelherodev>
I might use Notepad++ for it - could you link me the UDL file?
<pixelherodev>
(I have Notepad++ along with other useful utilities on a USB, and I run them through WINE when the occasion calls for it)
<pixelherodev>
Terrible solution, but in the short term it's probably easier to set up
<andrewrk>
what library for syntax highlighting does geany use?
<andrewrk>
if it were e.g. pygments then you could update to the latest version to gain zig support
drazan has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
mahmudov has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Ping timeout: 240 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
<pixelherodev>
Scintilla, apparently
doublex_ has joined #zig
doublex has quit [Ping timeout: 245 seconds]
<companion_cube>
like, wow, light background?!
<pixelherodev>
:P
<torque>
doesn't notepad++ also use scintilla
<pixelherodev>
...huh. So it does.
<pixelherodev>
Not that it matters
<pixelherodev>
UDL is np++-specific IIUC
<torque>
unfortunate
doublex_ has quit [Ping timeout: 240 seconds]
doublex has joined #zig
<kurufu>
Is it possible to know the type of ... args? I would like to have a function that takes variable args and a callback of the same arguments as what was passed in.
<kurufu>
and be able to call that callback with the given args. Both of which im not sure are possible.
<andrewrk>
this still doesn't have any of the more sophisticated type merging that I have planned
<andrewrk>
the links don't work yet either on those generic types
return0e has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<ntgg>
oh jeez those are some fast docs!
mahmudov has joined #zig
<daurnimator>
andrewrk: one example there `array_list.AlignedArrayList(...` array_list isn't mentioned anywhere
<andrewrk>
daurnimator, they're all AlignedArrayList. #3406 and #3404 are still open
gustav_o has joined #zig
<daurnimator>
andrewrk: but the examples section is really cool!
ntgg has quit [Quit: Lost terminal]
ltriant_ has quit [Ping timeout: 276 seconds]
muffindrake has joined #zig
<muffindrake>
Yello!
<bgiannan>
So the rewrite of my game is Zig is going well: https://0x0.st/zxxB.png And it's fast (which is the whole point of the rewrite).
<daurnimator>
andrewrk: idea: add a "see also" section that includes links to other structs/methods that link to the current one.
<muffindrake>
bgiannan: Presumably you're using SDL to get around the platform window stuff? What do you use to draw?
<bgiannan>
muffindrake, everything is done with SDL, the graphics are really simple
<muffindrake>
bgiannan: Oh, so it's just SDL's graphics drawing. That's fine.
<bgiannan>
yeah don't need much else right now
<muffindrake>
I've heard about Zig about 3/4 of a year earlier, but it didn't seem too interesting to me at the time. Is there a comprehensive resource I can use to get started with, being mostly a C programmer?
<pixelherodev>
Yeah, Zig is really really neat. I've been working on a C project for a few hours and there were so many times I wished I could switch to Zig
<telemach>
bgiannan: just curious, rewrite to Zig from which language?
<bgiannan>
telemach, from lua (löve 2d)
<muffindrake>
Ah, that's quite a slow library, yeah
<pixelherodev>
Does that use LuaJIT?
<bgiannan>
yes it does
<pixelherodev>
Could be worse then :P
<gustav_o>
hi everyone
ltriant has joined #zig
<gustav_o>
how do I use b.standardTargetOptions(null)? I can't seem to supply -target to my `zig build -target x`
<gustav_o>
found it, sorry spoke to soon (`-Dtarget=x`)
ltriant has quit [Ping timeout: 240 seconds]
<gustav_o>
andrewrk: Do you know of the top of your head which libc folder `zig cc ... -target wasm32-unknown-emscripten-musl` will result in? This is what gets supplied when I specify When I supply `-Dtarget=wasm32-emscripten`
<gustav_o>
I wanted to see if I could compile the sokol libs to wasm32 as you said yesterday. Please bear in mind that I'm new to this kind of low level stuff :)
<mq32>
<andrewrk> you're not going to find type-aware auto completion in any editor yet
<mq32>
that's not completly true. ceymard has written a vscode module that provides at least *some* type-aware autocompletion and more importantly: a quite well working "go to definition"
return0e has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<muffindrake>
I see that you can make arbitrarily-sized integer types, up to a bit length of 2^16 - 1. Is there some reason for this choice, or is it merely an implementation limit right now?
<mq32>
muffindrake, afaik it's an LLVM limit
return0e_ has quit []
return0e has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
<daurnimator>
muffindrake: do you have a use-case for something bigger?
<muffindrake>
No, I was simply curious
<muffindrake>
Besides that, is there an existing implementation of arbitrarily-sized integers in zig that we can use?
<daurnimator>
do I recall tgschultz having one?
<mikdusan>
math.big.Int
chemist69 has joined #zig
<tgschultz>
daurnimator you might be recalling my work on PackedIntArray/Slice.
<gustav_o>
Hmm.. seems like referencing c code in a comptime expression falls into an infinite loop?
<gustav_o>
or it seems to happen when I include the same headers from different files
<gustav_o>
putting all cImports into a c.zig and exposing declarations with `usingnamespace` does not infinite loop
<gustav_o>
Even if c.zig is imported and used in multiple places. Does anyone know why?
<bgiannan>
did someone built a zig program with sdl on windows?
<tgschultz>
a few of us have, yes. long time ago for me.
<bgiannan>
do you have gist of it?
<tgschultz>
Not on hadn, it would be outdated anyway. Anything specific you're trying to do? I think the consensus is that the easiest way to use it is to translate-c the header and import the result, modifying as necessary.
<tgschultz>
I can paste what I have quick, but it'll be about 2 zig versions behind so no guarantees.
<bgiannan>
i was hoping too still be able to link with libc and use cImport (am i right in thinking cImport == needing libc?)
<tgschultz>
cImport just means you're using C code, it doesn't necessarily link to libc (which is unnecessary for SDL2, IIRC)
<bgiannan>
huh i had `exe.linkSystemLibrary("c");` for no reason...
<bgiannan>
so if i don't need that i can try and use the msvc version of SDL2
<tgschultz>
yeah, that's what I used. Though I did try the mingw version first and had all sorts of trouble with it. But, zig's support for mingw was worse back then.
<tgschultz>
I just copy-pasted really old code there. No guarantees. Someone else probably has newer examples
<bgiannan>
i use @cImport, not sure what's your SDL2.zig
<tgschultz>
the build line just had to add --library "SDL2.lib"
<bgiannan>
ah
<bgiannan>
SDL2.lib, that's the file it needs
<tgschultz>
So cImport translates C to zig internally. You can dump the output of that process, which is handy if the translation doesn't quite work right because you can hand edit it. That's what SDL2.zig is
<bgiannan>
worked fine for me, i had to rewrite some missing macros but that's about it
<tgschultz>
I don't know if it is still true, but there used to be a few parts of SDL that didn't translate properly.
<bgiannan>
actually
<bgiannan>
removing the libc bits works on macOS because it always links against libc on macOS
<bgiannan>
but when targetting windows it does complains about libc missing when using cImport
<tgschultz>
strange. I definitely didn't have to link C
<bgiannan>
/Users/giann/git/zsettlers/src/sdl.zig:17:17: note: libc headers not available; compilation does not link against libc
<bgiannan>
pub const sdl = @cImport({
<bgiannan>
is mingw the `gnu` abi?
<tgschultz>
I think so
<bgiannan>
ok i maybe have something that will work, it seems to only fails now because it's trying to find windows symbols and i'm doing this on macOS.... maybe i need a msvc dll or something
<bgiannan>
scratch that last bit i'm not usign the msvc abi
<daurnimator>
you would still need the windows SDL2.lib file though?
<bgiannan>
looking at my old windows/SDL game i had things like: `-lmingw32 -lws2_32 -mwindows`
<bgiannan>
andrewrk, when you're around i'd love your help with this
ntgg has quit [Ping timeout: 250 seconds]
ntgg has joined #zig
ntgg has quit [Ping timeout: 268 seconds]
<gustav_o>
hmm.. I wonder how to go about handing errors in zig functions that are called from c-code..
<fengb>
Same way as C functions: error codes or some other convention. You can’t export error unions
<daurnimator>
would be cool to have a convention though
<fengb>
Well it’s C. So error codes or errno :P
<daurnimator>
not always
<daurnimator>
e.g. openssl usually has an error code per function
<daurnimator>
I think something that iterates `@typeInfo(myerrorset).ErrorSet` assigning numbers/offsets. then you could provide a reverse mapping. and also a offset->string via @errorName
<daurnimator>
oh Error actually has a `value: comptime_int` field
<mq32>
daurnimator, i don't think it's reasonable to use that value as it may change when new error values are introduced
<daurnimator>
mq32: that's fine: the value would only be suitable for passing back to a library-exported "error-number-to-errorstring" function
<companion_cube>
file:///home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/std/primitive.never.html oh btw, about the empty type
<companion_cube>
gaaah
<daurnimator>
companion_cube: traitor ;)
<companion_cube>
file:///home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/std/primitive.never.html actual URL
<companion_cube>
nah, I just think it's a neat pattern :p
<daurnimator>
companion_cube: looks like zig's noreturn
<daurnimator>
or just the empty error union `error{}`
<companion_cube>
yes, exactly
<companion_cube>
but the point I emphasize is how it behaves in sum types^W^W tagged unions ;)
<gustav_o>
Regarding the c errors... I use a library that calls into my zig code to draw each frame of a game. Ideally I want this zig function to be able to throw errors but then I need to figure out how to do custom error passing through the C side?
<mq32>
companion_cube: seems pretty similar to zigs noreturn
<mq32>
for Result<!,E> you should be able to create error{}!noreturn
<companion_cube>
sure
<mq32>
oh damn.
<mq32>
i will do a bug report :D
<mq32>
my code will out-of-memory the zig compiler
<mikdusan>
get more memory :)
<mq32>
aren't 32GB enough?
<fengb>
gustav_o: you can export a wrapper function that manually maps the errors to static values
<gustav_o>
fengb: I'm thinking of something like `myZigCode() catch |err| { global_var = err; doLogicToThrowErrorAndQuit(); }`. Is this what you meant?
<gustav_o>
I forgot to say that the c-code that calls zig-code is in turn called by zig-code, so I can return the error at the outer-most point, probably
<fengb>
Ick that doesn’t sound very pleasant >_>
<gustav_o>
you're right :) but the impact is fairly limited. All of the game is written in zig and this is for the native window management.
<daurnimator>
^ I'd probably play with that sort of construction
<gustav_o>
daurnimator: Thanks!
<gustav_o>
do you know of a way to save the error trace as it's printed?
<daurnimator>
gustav_o: maybe @errorReturnTrace() will work in that wrapper function there? however you'll probably end up using std.debug.dumpStackTrace or its friends
<daurnimator>
gustav_o: you can also just stash away that stack trace in your "error struct" and export another function that allows the user to print it when they want
<mikdusan>
is `!noreturn` even supposed to be a real thing?
<daurnimator>
mikdusan: I don't see why it shouldn't: you might have a function that can throw an error or otherwise e.g. calls exit()
<fengb>
Not noreturn 🙃
waleee-cl has joined #zig
<companion_cube>
mq32: :DD
konv has joined #zig
gustav_o has quit [Ping timeout: 260 seconds]
<mq32>
mikdusan: the rust article posted by companion_cube explains it quite good
<mq32>
"!noreturn" is "i have something that either runs endless or errors
<tgschultz>
I keep getting bitten by capture+result location
ntgg has joined #zig
<tgschultz>
#2915 that is
mahmudov has quit [Ping timeout: 268 seconds]
ntgg has quit [Ping timeout: 268 seconds]
<bgiannan>
do i need to build zig myself to run it on mingw? the windows binaries complains about a missing unkowned shared object file
konv has quit [Quit: Leaving]
<tgschultz>
hmmm: link: `could not find .def file to build opengl32`
<tgschultz>
said `.def` is in the same directory as main.zig and is also the cwd
<andrewrk>
mq32, nice, that's good to know about ceymard's vscode module
<bgiannan>
nevermind i was missing visual c++ redistribuables
<andrewrk>
bgiannan, need help with something?
<bgiannan>
andrewrk, yes i'm trying to build my game (SDL2) on windows
<bgiannan>
i have this so far https://0x0.st/zx3W.zig And trying right now to do it on an actual windows machine
<andrewrk>
are you using vcpkg?
<bgiannan>
i don't know what that is
<tgschultz>
did something change recently regarding building lib stubs for dlls or something?
<andrewrk>
never mind that. are you interested in setting up your project for cross compiling to windows?
<bgiannan>
andrewrk, i'm interested in being able to build it for windows, doing it from another system is not the goal
<andrewrk>
bgiannan, you shouldn't need the windows option then; the default target is native
<andrewrk>
you can detect whether the native target is windows
<bgiannan>
right my first test were on macOS
<andrewrk>
const target = b.standardTargetOptions(null); if (target.isWindows())
<andrewrk>
oh and don't forget exe.setTheTarget(target);
<andrewrk>
start with that, and none of the include dir/lib path stuff, and let me know what error you hit
<andrewrk>
tgschultz, did something regress?
<bgiannan>
alright
ntgg has joined #zig
<bgiannan>
andrewrk, right so it complains about missing libc. So related question -> do I need to link against libc for @cImport to work?
<andrewrk>
can I see the output?
<tgschultz>
andrewrk: possibly. If I'm reading 3434 correctly this is actuall intended? On Windows (64bit), using `extern "opengl32"`I never had to provide anything in the past and zig would just create and link a stub on its own. Now it appears that isn't the case.
<tgschultz>
but I can get you a list of what is in win32.zig
<bgiannan>
andrewrk, so `__imp_PropVariantClear` seems to be in comctl32.dll which i have on my system, but zig can't seem to find it. SHould i manually add it? if so how?
<andrewrk>
tgschultz, master branch has cross compiling support for opengl32.dll now. let me know if you hit anything else, it's easy to add. maybe it's a good idea to add all the dlls from mingw-w64, but I'm not ready to make that decision right this minute
<andrewrk>
bgiannan, ok that's another one I'll add right now ^
<tgschultz>
andrewrk: here is what I have defined in win32.zig, which should be anything the win32 api touches. https://pastebin.com/7LW3fLmC
<andrewrk>
if I add everything from mingw-w64, it's 7 MiB (1.2 MiB gzipped)
<andrewrk>
that's probably a reasonable trade off
<andrewrk>
I'll start with this list provided by tgschultz for now
<bgiannan>
that's not in mingw though
<bgiannan>
it's in windows itself
<andrewrk>
yes these are system dlls which zig can provide the ability to dynamically link against when targeting x86_64-windows
<andrewrk>
or i386, or arm 32 bit or arm 64 bit
<andrewrk>
tgschultz, i'm not sure what mincore is. that one is not provided by mingw-w64
<bgiannan>
andrewrk, ah yes sorry misread you there
<tgschultz>
I'll see what mincore is attached to
sossy has joined #zig
<bgiannan>
andrewrk, do i need a .def file for each missing dll?
<andrewrk>
bgiannan, no. which dll is missing?
<bgiannan>
comctl32
<tgschultz>
mincore is a Windows 8 api, I have 4 functions listed for it: GetOsSafeBootMode,WaitOnAddress,WakeByAddressAll,WakeByAddressSingle
<tgschultz>
What is our minimum supported Windows ver?
<muffindrake>
Are bare metal targets supported? How about 8-bit Sharp LR35902?
<nrdmn>
muffindrake: bare metal targets are supported.
<bgiannan>
andrewrk, ah thanks i'll wait for the binary to be on ziglang.org, never tried building zig on windows yet
<andrewrk>
should be about 1-2 hours
<muffindrake>
Welp, no z80 here. Too bad!
<tgschultz>
llvm doesn't support any 8-bit archs as far as I'm aware
<bgiannan>
andrewrk, perfect thanks for the help!
<muffindrake>
Ah, yes, I was reading about that.
<andrewrk>
tgschultz, all the libs in your list except mincore are now available in master branch
<tgschultz>
cool, thanks
<andrewrk>
anyone else blocked and need some help?
<andrewrk>
gustav_o, I wonder how many bytes it would cost to provide emscripten's libc for -target wasm32-emscripten
<nrdmn>
andrewrk: I'm documenting UEFI structs and functions. Can I copy & paste function descriptions if they're no longer than one or two sentences?
<nrdmn>
copy & paste from the spec*
<andrewrk>
that should be ok
<muffindrake>
Is it currently possible to switch on anything but integers? How about strings?
<andrewrk>
muffindrake, not possible
wootehfoot has joined #zig
<sossy>
Apologies for beginner question, but the designated assignment syntax p = { .a = 1, .b = 2}; only works for one level deep, right? I can dig down mutiple structs one statement at a time, but was attempting to find a less redundant way to assign a struct within struct.
<andrewrk>
it works for any number of levels
<sossy>
So p = { .a.c = 1, .a.d = 2}; should work?
<mq32>
no, but p = { .a = A { .c = 1, d = 2 } }
<andrewrk>
if you want to leave some fields uninitialized, use `undefined`
<sossy>
I'm sure I'm missing something obvious
<sossy>
const Td = struct { a: i32 = 0 };const T = struct { const D = Td; };export fn main() void { const t = T; t = { .D = Td { .a = 1 }; };}
<sossy>
That minimal thing gives error: type '(enum literal)' does not support struct initialization syntax
<tgschultz>
`const t = T` makes `t` a value of type `type` identical to `T`
<tgschultz>
`var t: T = undefined; t = {....}`
<tgschultz>
but you don't even need to declare T undefined. just do `const t = T{ .D = Td { .a = 1}, };`
SimonNa has quit [Remote host closed the connection]
SimonNa has joined #zig
<tgschultz>
oh, your struct def is wrong too
<tgschultz>
at least for how you're initializing it
<sossy>
I was suspecting, cause what you told now gave error: no member named 'D' in struct 'T'
<tgschultz>
`const T = struct { const D = Td; }` means "create an empty struct and place within its namespace a constant 'D' that is a type identical to Td"
<tgschultz>
`const T = struct { D: Td, }` creates a field named 'D' in the struct.
<sossy>
Thank you, I had wondered all over trying to change different parts to get it to work
<tgschultz>
structs contain both fields and decls. fields are struct members that can vary for each instance of the sturct (just normal every day struct fields really), but decls are variables and constants within the namespace of the struct type itself.
<sossy>
So at some point the declaration switched to const
<tgschultz>
andrewrk, is there a known issue with result location and doing things like `x = x.func();` where `func()` does not modify x?
<andrewrk>
tgschultz, in this case func() will be modifying x with the `return` statement
<tgschultz>
so `x = x.func()` is now also a footgun
<andrewrk>
yes
<tgschultz>
wonderful
<andrewrk>
in this case the result location aliases the first parameter
<andrewrk>
which is planned (pending research) to be illegal
<tgschultz>
so I should really get into the habit of explicitly copying everything I guess
knebulae has quit [Remote host closed the connection]
<andrewrk>
that's the idea, nothing is copied unless you make a copy
knebulae has joined #zig
<nrdmn>
should I add `test` statements just so docs are generated from my comments? Or will this not be necessary in a later version?
<andrewrk>
tgschultz, however, your characterization of this as a footgun is accurate, and my goal is for there to be no footguns in the language before it becomes stable
<andrewrk>
I don't consider status quo with regards to result locations to be anywhere close to acceptable for 1.0 status
<andrewrk>
however the progress on result locations is important, and closer to where we need to be than before
<andrewrk>
nrdmn, that's something I'm still figuring out. you'll definitely need to reference all the imports so that the files get looked at
<tgschultz>
sure, and I don't even mind the explicit copying really, it's just that we're in a state where the compiler isn't catching it and that makes it non-obvious what went wrong
<andrewrk>
I agree. one of the big goals for this release is safety
<andrewrk>
safety and making it obvious when something goes wrong are the same thing to me
<andrewrk>
it's a footgun either way btw, although I'll agree that the newer one is worse. the previous one is that a copy might move a "pinned" field
<andrewrk>
we don't have pinned fields yet, but now the language semantics are even capable of dealing with them correctly
<Sahnvour>
do you consider double optionals (??T) a code smell ?
ntgg has quit [Ping timeout: 265 seconds]
<pixelherodev>
... double optionals?
<tgschultz>
I am really curious about the usecase for that one
<tgschultz>
seems like you might want a custom union{enum{}, T}
<tgschultz>
er.. you know what I mean. A union with two void fields and one typed one
<Sahnvour>
let's say I have an operation that can return a result or null (in case of failure) ; and this operation's result will not change during the program, however I'd like to know if I already attempted it
<Sahnvour>
tgschultz: interesting
<tgschultz>
Personally I'd do the custom union thing. union{ .Failed: void, .Unattempted: void, Value: T, }
<Sahnvour>
yeah that looks nice
<Sahnvour>
thanks
ntgg has joined #zig
<andrewrk>
!noreturn would be the return type of std.os.execve
ltriant has joined #zig
<pixelherodev>
Inline assembly is a pain. "Error: invalid operand for instruction" "outb %dx, %al". This'll take a few hours...
<andrewrk>
bgiannan, the new build is up
<bgiannan>
andrewrk, yes on it :)
<bgiannan>
andrewrk, do you have a better that googling symbols to find out in which dll they are?
<Sahnvour>
bgiannan: if you're talking about windows functions, you can look at the associated msdn page, it will list the header and dll where it's located
<pixelherodev>
The correct way to refer to an input in an asm block is %[INPUTNAME], where INPUTNAME is the name given in the input constraints section, correct?
<tgschultz>
bgiannan, andrewrk: when creating the win32 package I wrote a script using dumpbin and every dll in system32.
<pixelherodev>
okay i'm losing my mind here. Anyone know why "outb %dx, %al" would be rejected?
<Sahnvour>
tgschultz: void types in a union have to be initialized with `TheUnion{ .Field = {} }` correct ?
<tgschultz>
yeah. you could also use u0 instead of void and set it to 0
<andrewrk>
pixelherodev, duplicate the %%
<pixelherodev>
Nah, I figured it out. I had the operands backwards :P
<pixelherodev>
It's %al, %dx; not %dx, %al
<andrewrk>
if the zig project takes on the task of an assembler we can have better syntax and error messages for inline assembly
<andrewrk>
it's a big project though
<pixelherodev>
Yeah, especially given the sheer number of targets
<pixelherodev>
Though a simple table format isn't impossible
<pixelherodev>
When you @import a file, are its functions compiled as part of the current compilation unit?
<andrewrk>
pixelherodev, the top level declarations are noticed; functions and variables are ignored unless referenced. comptime blocks are executed
<andrewrk>
the `export` keyword or `@export` builtin forces a function to be exposed in the object
<pixelherodev>
If a function is used though, it's merged into the current unit?
<andrewrk>
yes
<pixelherodev>
Ah
<pixelherodev>
That explains the "duplicate symbol" error :P
<andrewrk>
does it? are you exporting a library or an executable?
<pixelherodev>
This is for the kernel. Each file is built on its own, but some of them @import others, so `export`ed functions and symbols get duplicated
<andrewrk>
I see
<andrewrk>
why have more than one compilation unit?
<pixelherodev>
Habit?
<pixelherodev>
Didn't realize there were any reasons *not* to
<andrewrk>
I think you will have a smoother ride if you do a single build-exe from a root source file that imports the other ones
<pixelherodev>
So I've noticed
<pixelherodev>
How big does a file have to grow before that becomes a performance issue?
<andrewrk>
in zig land there are plenty of reasons: * better optimization (equivalent or better than LTO) * compiler is aware of all source files when linking; can help with diagnostics and codegen * theoretically faster builds
<pixelherodev>
*Faster*?
<pixelherodev>
Anyways, good to know; time to untangle the kernel :)
<andrewrk>
yes, if you don't force separate objects, the compiler is free to do its own separation, integrated with incremental building & linking
<Sahnvour>
andrewrk: just a thought, the test suite knows how to use wine and qemu, it could also learn to use WSL (if present on windows) to have linux, linux+qemu and even linux+wine from a windows box :)
<pixelherodev>
...
* pixelherodev
is stunned
<andrewrk>
pixelherodev, that is vaporware though; there's a proof-of-concept in the self-hosted compiler but stage1 does not have this capability
<andrewrk>
hence "theoretical". but if your project grows slowly enough, zig will gain this ability before your project build becomes slow :)
<pixelherodev>
Alright thanks for the info
<andrewrk>
Sahnvour, I was thinking the same thing :)
<andrewrk>
-Denable-wsl
<pixelherodev>
regarding the self-hosted compiler, does that still depend on LLVM?
<mikdusan>
also afaik, Zig is really good at doing work only once - ie: the cost of the same templates spread across multiple units in C++ is completely avoided
<Sahnvour>
that'd be cool
<andrewrk>
yeah. for an OS project that is beginning right now, single compilation unit will be just fine. larger projects (e.g. the size of linux) would not be possible with stage1 but that is a use case I have in mind for self-hosted
wootehfoot has quit [Read error: Connection reset by peer]
<Sahnvour>
andrewrk: yes, technically we're not bound to a particular compiler, just making it easier by providing prebuilt llvm for this one
<andrewrk>
I see, ok
<andrewrk>
I'll include LLD in this one since we no longer have any outstanding patches
<andrewrk>
that might shorten Windows CI time a bit
<Sahnvour>
okay
<andrewrk>
nrdmn, give me a few more days for this multibuilds docs stuff, and you'll be able to see your fresh docs in the generated html
doublex has quit [Ping timeout: 276 seconds]
sossy has quit [Remote host closed the connection]
<andrewrk>
holy cowabunga, qemu-devel is a high volume mailing list
FireFox317 has joined #zig
<FireFox317>
I got some basic completion support working for functions in vscode using the new dump-analysis functionality: https://i.imgur.com/bxqdfuY.png :^)
<andrewrk>
oh! statx is the thing that can make the std lib event loop smarter with regards to parallel file system access!
<andrewrk>
it can at least tell the device major/minor id of a file descriptor
<emekankurumeh[m]>
you've piqued my interest.
<andrewrk>
FireFox317, nice!
<emekankurumeh[m]>
is that something specific to VSCode FireFox317?
<emekankurumeh[m]>
also why do i keep getting projects involving schedulers in my feeds?
<FireFox317>
emekankurumeh[m], not vscode specific. It is a LSP server and in theory every IDE that has a LSP client should be able to use that
waleee-cl has quit [Quit: Connection closed for inactivity]
<ceymard>
FireFox317: sweet
<ceymard>
I'm sad though
<ceymard>
I've been working on a JS based solution but you beat me to it
wootehfoot has joined #zig
<FireFox317>
ceymard: well, it is really basic now and not ready to publish yet :) I implemented the server in Zig
<ceymard>
especially src/grammar.ts (which doesn't need much typescript understanding)
<FireFox317>
Damn, that's cool! I'm really not that deep into it yet, but I'm also enhancing my Zig skills by writing it in Zig
<ceymard>
yeah I ought to do that too
<ceymard>
andrewrk: anyway, I don't go the "self-correcting" route, rather the "lax" route
porky11 has quit [Quit: Leaving]
<ceymard>
and just bail on stuff that really doesn't make sense until I find something that does
ltriant has joined #zig
<ceymard>
I find it interesting that I was able to express a grammar of Zig (with AST creation !) in 600 or so lines
<ceymard>
(granted, the parser doesn't intend to be correct, but still... that's not many lines - the grammar is really simple)
<Sahnvour>
docs + lsp will be such a qol improvement :)
<ceymard>
yes, it will for sure drive more people to the language
<Snektron>
hi
<andrewrk>
hi Snektron
ntgg has quit [Ping timeout: 240 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<Snektron>
andrewrk: It caught my eye that offset in structs is calculated in both bytes and bits
<Snektron>
Wouldn't it make more sense to just calculate it in bits?
<pixelherodev>
Got the GDT working in pure Zig :) Well, "pure" in the sense that I'm not using C for it anymore; I of course have to use inline asm for the lgdt instruction :P
<andrewrk>
Snektron, there's an important difference, which is demonstrated by integer types which are not divisible by 8.
<andrewrk>
u7, for example, is 1 byte, but 7 bits
<Snektron>
ah you make a good point
<andrewrk>
the size in bits tells how much padding there is after the actual data of the type, which is important for packed structs
<Snektron>
yet for packed structs, shouldn't the offsets be defined in bits anyway?
<andrewrk>
because you can put u7 and u1 in a packed struct and it will be 1 byte
<pixelherodev>
Right, which means the bytes are being ignored, aren't they?
<andrewrk>
the byte offset for packed struct is also important; it tells the offset of the "host integer" which contains the packed values. this matters because of endianness
ntgg has joined #zig
<andrewrk>
I think there are some bugs and issues with this; the initial implementation was done before it became clear in my mind
<Snektron>
""because you can put u7 and u1 in a packed struct and it will be 1 byte" that was my problem with it, it didn't work in some cases
<Snektron>
after which my friend told me off for using a compiler which can't do that
<andrewrk>
this does work: @sizeOf(packed struct { a: u7, b: u1}) == 1
<pixelherodev>
If it wasn't, I'd be boot looping ~~still~~
<andrewrk>
packed structs which don't end with a clean byte boundary are currently buggy, but this will be fixed. it will be equivalent to e.g. u7 which also doesn't end in a clean byte boundary
<Snektron>
I think the problem i had with it has disappeared :) granted i didnt look at it for some time
<Snektron>
My problem was @offsetOf(packed struct{a: [3]u8, b: u32}, "b") returning the wrong value
<Snektron>
Sadly the code i was working on was a small test which i didnt upload to git and then i accidently deleted it
<nrdmn>
andrewrk: I'm not sure if multibuilds would make the uefi doc comments be rendered into html. I think the issue is that most structs in std/os/uefi are not referenced anywhere, even when building as *-uefi-msvc. I made a workaround in src/codegen.cpp so that for the zig_print_analysis_dump() step that generates the documentation, g->zig_target is set to x86_64-uefi-msvc. But apparently that didn't make any
<nrdmn>
difference.
<nrdmn>
so to test my doc comments, I wrote `test "" {}` blocks that reference everything once but don't do anything with it
FireFox317 has quit [Remote host closed the connection]
<andrewrk>
nrdmn, that can also be done with reflection. comptime {refAllDecls(@This());}
<nrdmn>
andrewrk: why isn't it done that way in lib/std/std.zig?
<andrewrk>
I'm still working on it
<nrdmn>
ah, ok :)
<andrewrk>
I'm thinking the merging tool will also print out a list of unreferenced symbols, which should essentially be treated as errors. all symbols should be referenced by at least one build configuration, or, in the case of a library, explicit references or tests should be added for every symbol
<andrewrk>
it's planned for all this functionality to exist directly in the self-hosted compiler
<THFKA4>
nooooo
<pixelherodev>
How much work is needed for the self-hosted compiler to be even mildly functional?
<andrewrk>
6 months ish
<nrdmn>
what's supposed to happen if I put a doc comment over a `pub const Foo = @import("foo.zig").Foo;` and another over the definition of Foo in foo.zig?
<pixelherodev>
Better question: what can I do to help?
<andrewrk>
that's a good question
<andrewrk>
you could help work on the std lib event based abstractions, making them robust and fixing bugs
<andrewrk>
what's your home OS, pixelherodev?
<pixelherodev>
Linux usually
<pixelherodev>
Though I have windows in a VM
<pixelherodev>
And running on another partition on my PC until I get around to cleaning it up and moving everything into a VM-accessible drive :P
<andrewrk>
nrdmn, FireFox317, ceymard, THFKA4: I'm considering adding this rule to zig's semantic analysis: if zig looks at a struct/union/enum, then it looks at all the declarations therein. However if no declarations are referenced from a given type, then they are all omitted. I think this would be a good compromise for the downsides of lazy analysis
<andrewrk>
so if you wanted, for example, a freebsd-only function, you would have to put it in a separate struct (note: files are structs) so avoid it from being analysed
<andrewrk>
this would prevent this refAllDecls silliness
<andrewrk>
it means semantic analysis dumps would include pretty much everything, unless something is explicitly omitted by putting it in a separate struct/file
Ichorio has quit [Ping timeout: 250 seconds]
<nrdmn>
I'm not sure what the implications of this change are
<THFKA4>
i'm not sure that would help the case i was nooo'ing about. i'm concerned about the mild annoyance of commenting out a line while experimenting and getting an unused declaration compiler error
<THFKA4>
if i move all variables into a struct, chances are that it'll still be referenced through another member
<nrdmn>
to answer my own question about doc comments over imports: we're importing structs, not their documentation. So there may be different text depending on whether you view the parent namespace or the namespace/struct itself
<Snektron>
Im still not sure what to imagine on using async
<Snektron>
i know the basic of how it works, but i have yet to see a concrete example
<andrewrk>
the general idea here you can see is quite powerful
<nrdmn>
... so we'd document the struct and the symbol that we're binding the struct to separately
<andrewrk>
nrdmn, when a decl doesn't have any doc comments, probably it would be good to use the doc comments on the thing it refers to
<andrewrk>
the reality is that things are what they are and the doc renderer's job is to display it in a useful way
<andrewrk>
a decl might reference different things on different targets
<pixelherodev>
What would be the correct way to write an interrupt handler in Zig?
<pixelherodev>
I don't see e.g an "interrupt" keyword / attribute, should I just leave them in assembly?
<Snektron>
andrewrk: looks interesting. I think you've done a really original job on async
<Snektron>
pixelherodev: i was thinking about that the other day
<Snektron>
You could wite a function that wraps another as interrupt handler
<Snektron>
Depending on the system that is
<Snektron>
I'd just leave them in asdembly though
<ky1ko>
i'm trying to rewrite a small emulator framework of mine in zig and i have a couple questions. in my existing C framework, i write an abstraction around the base idea of a "busDevice" that can be read from or written to. i do this abstraction with a struct containing function pointers and a void pointer that the device-specific functions dereference into whatever they store there.
<ky1ko>
is there some recommended way i could write a similar abstraction in zig right now?