rifkik has quit [Read error: Connection reset by peer]
lunamn has joined #zig
lunamn_ has quit [Ping timeout: 240 seconds]
<JinShil>
Is there a way to get this to compile: `const ti = @typeInfo(u8); warn("Test: {}\n", comptime ti);` It's emitting error: "arameter of type 'builtin.TypeInfo' requires comptime
<JinShil>
" I want to be able to print out some of the `TypeInfo` information from the compiler.
<Tetralux>
You can use @compileLog(@typeInfo(T)) for that.
<Tetralux>
Though I agree it would be cool if you could have TI at runtime.
<Tetralux>
Or @compileLog(ti) for that matter.
<JinShil>
Thanks. It appears I can pull what I need out of TI into a `const` and then use that: `const bits = @typeInfo(u8).Int.bits; warn("Test: {}\n", @intCast(u8, bits));`.
wootehfoot has quit [Read error: Connection reset by peer]
utzig has left #zig [#zig]
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
LargeEpsilon has joined #zig
rifkik has joined #zig
LargeEpsilon has quit [Ping timeout: 245 seconds]
andrewrk has quit [Ping timeout: 268 seconds]
andrewrk has joined #zig
_whitelogger has joined #zig
JinShil has quit [Read error: Connection reset by peer]
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #zig
letoram has quit [Remote host closed the connection]
hasanyasin has quit [Remote host closed the connection]
dimenus has joined #zig
porky11 has joined #zig
rsdimenus has joined #zig
<rsdimenus>
is anyone around who is familiar with cross compiling LLVM/clang for armv8a (aarch64)?
Ichorio has quit [Ping timeout: 245 seconds]
<via>
is there a long term vision on a way to improve the whole interfaces(function pointers)/async thing? specifically looking at implementing my own instreams and outstreams for a freestanding embedded targets with async read/write
<via>
it looks like support is only implemented for in streams right now (no async writefn's for out stream), and requires the toplevel setting of the stack size and io mode
<via>
but i could see that balooning into a lot of ugly root-level overrides for things to work
<via>
it would be cool to have the interfaces be agnostic as to if the underlying functions are async, but i do get why that is not necessarily doable
<via>
maybe they could take allocators instead of the hardcoded stack sizes? or take them in initialization somehow -- since isn't the stack size going to depend on where a stream (and what underlying read/write fn) is used, globally isn't ideal
<via>
i could be misunderstanding things, i didn't realize the interfaces like for the streams needed to handle async specifically until i saw the most recent stream
<Tetralux>
via: I think I asked a similar question a month ago or so; I believe andrewrk is waiting until the plan for interfaces is good for comptime and runtime and is easily switchable between them. I forget exactly the extent of what was said though, so maybe Andrew can repeat it - maybe there's an issue for it?
tghume has quit [Ping timeout: 252 seconds]
<via>
cool
<via>
maybe when thats more figured out, interfaces can be more common -- i'm hoping that the event loop becomes more of an interface, allowing site-specific implementations of a Loop
<via>
so that you can reuse all the cool things like Channels and such, but on freestanding
<Tetralux>
But yes - I too have found myself wanting to just say "so long as this done does this and this, I can use it for this"
<Tetralux>
Writer, being the obvious example.
<Tetralux>
.. meaning .write([]u8)
<via>
i want to implement my own write that wraps over my stm32f4's usb cdc interrupt based code, which means i'll need to make my own loop-like thing that busy waits for things like that to be ready and resumes waiting write()s
<via>
and use them with a out stream directly
tghume has joined #zig
<via>
but i feel like i'll be duplicating a lot of work that is already in event
<via>
but thats another issue
mahmudov has quit [Ping timeout: 240 seconds]
<fengb>
Most of event is the old async and still needs to be rewritten
<Tetralux>
I'm not sufficiently familiar with how interrupt are interacted with to give pointers on it, but yes, as fengb said, the event code, last I checked, has not been updated yet.
<Tetralux>
Or did it get stealth-updated?
<Tetralux>
Only 0.5 releases tomorrow.
<fengb>
Interrupts will have to be manually wired in, but stuff like channels should be platform agnostic
<Tetralux>
fengb: Array are also plat-agnostic and are faster xD
<via>
fengb: but they all rely on the specific event loop implementation in event.Loop, which is pretty platform-specific and doesn't look to me to be extendable without zig std lib changes
<via>
or are you saying thats what will be changing
<fengb>
They shouldn’t once they’re done. Only loop stuff should be platform dependent
<fengb>
Oh I see...
<andrewrk>
a lot of the standard library is left over from the first iteration of async/await and needs to be rewritten with the new design in mind
<andrewrk>
the only thing std.event.Channel needs to depend on is a way to ask for an anyframe to get resumed
<via>
do you have a vision for how all that is going to work? things like the root-level configurables and/or maybe loops being an interface?
<via>
i could see the latter being really painful
<via>
it would cool to not even have to implement a write fn for streams, but be able to implement loop functions for taking fd's and writes/reads for a specific project -- and then use the rest of the stdlib around it
<andrewrk>
yeah, that's the vision
<andrewrk>
there is still some work to get there
<via>
i could write up my thought process in an issue this evening, i know you're busy with the release stuff
<andrewrk>
if you do that I will read it
<via>
okay, thanks -- i also wouldn't mind taking a stab at implementing some things if i know where they're going. i'll write it up tonight
tghume has quit [Quit: WeeChat 1.6]
mahmudov has joined #zig
<akhetopnu>
andrewrk when more or less do you plan on releasing the first stable (1.0?) version of zig with all the main features implemented?
<andrewrk>
1.0 is still 2+ years out
<andrewrk>
zig will get a lot more usable and stable leading up to that, but the official compatibility commitments, language spec, different release cycle, etc, is what I'm referring to
<andrewrk>
it'll be pretty obvious when 1.0 is coming soon, because releases will be much less drastic
hasanyasin has joined #zig
jaredmm has joined #zig
hasanyasin has quit [Ping timeout: 240 seconds]
hasanyasin has joined #zig
LargeEpsilon has quit [Ping timeout: 265 seconds]
Traviss__ has quit [Quit: Leaving]
<jaredmm>
On Windows: when trying to use libraries (like SDL), lld appears to be double-mangling the exported names it is looking for (two underscores instead of one). Everything works on Linux without issue. Reading through the issues, it looks like link.exe would find them correctly, but I don't see a way to force that.
<jaredmm>
I also have issues with msvc headers not being found, so I'm wondering if this is all a result of a more general issue my Windows install has or if it is expected in Zig's current state.
traviss has joined #zig
<andrewrk>
jaredmm, why would link.exe find them and lld not find them?
<andrewrk>
ugh this is bad timing for sr.ht builds to stop working
konv has joined #zig
<andrewrk>
0.4.0: issues closed: 260
<andrewrk>
0.5.0: issues closed: 350
<andrewrk>
mostly due to increased contributions from the community
Akuli has joined #zig
<jaredmm>
andrewrk, it looks I may have mixed two unrelated issues. The upstream lld issue was related to builds halting (#1763), not linker errors. I even described this issue wrong, because I resolved the previous linking error with #3319. The current error is the opposite-> lld: error: undefined symbol: glfwSetErrorCallback where the exported name is _glfwSetErrorCallback.
<jaredmm>
Apologies for that. Two days trying to get Windows working after 2 minutes on Linux has been frustrating.
<andrewrk>
yeah this is one thing that the package manager will solve. everything will work the same on all systems
<andrewrk>
jaredmm, can I see your build.zig file? how did you obtain glfw?
<andrewrk>
are you trying to dynamic link or static link glfw?
<jaredmm>
My intent was to static link glfw. I tried using glfw binaries from their site first, then building with vcpkg. I've been using the Tetris example (and the sdl-demo project) as my base.
<andrewrk>
jaredmm, just so you know, my plan to get tetris working on windows was to get the package manager working. I never really had it building from source on windows
<andrewrk>
I do think static linking is the thing to do
<andrewrk>
what's with the native_libc.txt? is zig not picking up your msvc installation correctly?
<jaredmm>
Yeah. "Zig is unable to provide a libc for the chosen target 'x86_64-windows-msvc'." zig targets shows x86-windows-msvc as native.
<andrewrk>
jaredmm, when you do exe.setTarget(builtin.Arch.x86_64, builtin.Os.windows, builtin.Abi.msvc); you're selecting to cross compile for windows, rather than compiling for your native system. I'd suggest not specifying setTarget unless you're trying to cross compile
<andrewrk>
that should then pick up your msvc installation and you can delete all those workarounds adding directories
<andrewrk>
for static glfw, I apologize for the poor naming of this function but you're going to want exe.addObjectFile and then give the full path to glfw.lib
<jaredmm>
Removing the explicit setTargets does prevent the target error, but it still doesn't find all the directories. I originally added the directories because without C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um it doesn't find GL/gl.h
<andrewrk>
which msvc version is this?
<jaredmm>
Right now it should be whatever version comes with Visual Studio 2019. I previously was using 2017 build tools and think they're still installed.
<jaredmm>
(not sure how msvc versions)
<andrewrk>
on my computer `zig.exe libc` prints `kernel32_lib_dir=C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\x64`
<andrewrk>
looks like the extra directory you want is 1 up from that
hasanyasin has quit [Remote host closed the connection]
<andrewrk>
on my computer, however that directory only has these subdirs: arm, arm64, x64, x86
<andrewrk>
and it does not have any other files
<andrewrk>
oops I'm looking in Lib not Include
<andrewrk>
I just made a bunch of transcription errors, forget what I said and let me check something else
hasanyasin has joined #zig
<nrdmn>
proposal: make consts that are set to undefined be assignable once, with runtime checks in debug mode.
<mq32>
nrdmn, this check can also be done fully compiletime
<nrdmn>
mq32: are you sure about that? That would be even better
<andrewrk>
jaredmm, are you able to test a branch of zig?
<mq32>
nrdmn, yeah, codepath analysis allows stuff like that
<mq32>
but i don't think zig needs this as you can just use a if-expression
<mq32>
const foo = if(condition) 10 else 20;
<andrewrk>
nrdmn, you might be able to solve this use case by having a const pointer to the mutable state be the thing that is public
<jaredmm>
andrewrk, I haven't compiled from source on Windows yet, but I should be able to.
<andrewrk>
jaredmm, I have a patch to add auto detection of the um directory. one thing at a time, after this we can tackle the next problem
<andrewrk>
jaredmm, now I'm getting file not found: winapifamily.h. let me see where that is
<jaredmm>
Sorry, I should've mentioned. Including one leads to the next include I added. probably the ucrt directory.
<jaredmm>
I think after that, the shared directory will be necessary (or reverse ucrt and shared).
<andrewrk>
I see what happened here
<andrewrk>
microsoft added new include dirs since the time when I coded this detection
<andrewrk>
the latest version was 10.0.10150.0 when I first implemented this :)
<andrewrk>
jaredmm, ok, with the latest commit pushed to that branch, I can #include <gl/GL.h> if I first #include <windows.h>
<jaredmm>
Microsoft's never-ending quest to make finding headers impossible.
<jaredmm>
It'll be awhile before I can build it. Apparently the binary distribution of llvm doesn't include llvm-config and I only have LLVM8 from source, not 9. Not familiar enough for llvm to know if there's a way to build only one of the tools.
rifkik has quit [Read error: Connection reset by peer]
<jaredmm>
Ah, nice. Started the build with that. CPU's a decade old, so it might take a bit.
<jaredmm>
Removed the extra includes and ran a zig build -Dwindows -Dmsvc. No header include errors.
<andrewrk>
jaredmm, ok, sounds like progress. now on to solving these linker errors
<andrewrk>
I'll merge the branch after CI tests pass
<andrewrk>
I wonder how much progress Sahnvour made on integrating linkSystemLibrary with vcpkg
<andrewrk>
anyway I think the first thing to try is exe.addObjectFile() with the path to glfw.lib
<jaredmm>
I've tried linking it to a few different glfw3.lib files. The ones I compiled and the pre-built binaries. In both cases, it still comes back with the same errors.
<Sahnvour>
andrewrk: not much at the moment, I have a plan for what needs to be done but I still need to look more deeply into build.zig and actually do the work
<andrewrk>
jaredmm, so LLD is looking for no underscore, but glfw3.lib has underscores?
<jaredmm>
epoxy.lib gives the same type of errors, as confirmation that it isn't just glfw3.lib. `lld: error: undefined symbol: epoxy_glUniform1i`
<jaredmm>
dumpbin of glfw3.lib gives _glfwInit as one of the exports. The error during zig build has `error: undefined symbol: glfwInit`.
<jaredmm>
So the export has the _, the symbol it looks for is without.
<andrewrk>
I've run into a similar problem several times before on windows, and every time I tried to solve it, it broke something else
<andrewrk>
I wish I could find some authoritative reference on how symbol mangling is supposed to work on windows
<jaredmm>
It is confusing. I hadn't tried looking at epoxy yet, but if I do a dumpbin on epoxy.lib, it doesn't show any underscore and lld doesn't have an underscore.
<andrewrk>
hmm. can you eliminate the possibility that the link order matters?
<andrewrk>
with some linkers, you have to put the thing that fulfulls the dependency after the thing that depends on it
hasanyasin has quit []
<jaredmm>
If addObjectFile is done in order, then yeah. I switched them a couple times because I thought that might be it.
<andrewrk>
I think the underscore thing might be a red herring
<jaredmm>
Seems that way, since one has and one doesn't.
<andrewrk>
I don't have any ideas yet to solve this thing where the names match but it's still a linker error
<andrewrk>
the next step I would take would be reading LLD source to find out what its logic is
<andrewrk>
or maybe asking a question in #llvm
<jaredmm>
I looked through the LLD COFF code a bit the other day. It looked like it was demangling names if they were prefixed. I wasn't looking for anything related to matching symbols not being found, so I'll take another look.
<jaredmm>
Thanks for taking some time to look. I'll see if #llvm has any ideas after I try to get a handle on what it is doing.
<andrewrk>
godspeed. I also want to reiterate that the package manager will solve this because it eliminates system dependencies, which is the main problem here
<scientes>
what is lemonboy's irc nick?
<andrewrk>
trying to integrate with somebody else's binaries that was produced by god-knows-what process
<andrewrk>
scientes, TheLemonMan
<scientes>
oh he isn't on now
<scientes>
qemu is segfualting, and i'm wondering where to get a mipsel VPS
<andrewrk>
this lets you edit lib/* without `make`
<scientes>
ahh cool, yeah i was still using the symlink hack to do that
<andrewrk>
jaredmm, someone in #llvm is suggesting: <smeenai> andrewrk: perhaps linking with `--trace` to make sure the file is actually getting read by the linker?
<andrewrk>
for the epoxy symbol thing
<andrewrk>
jaredmm, you can use --verbose-link to `zig build` to print the linker line. then you can manually run LLD with a different linker line as a test
<andrewrk>
I didn't give you LLD with that tarball though, sorry
<andrewrk>
you can also swap out lld with link.exe as another test
konv_ has joined #zig
konv_ has quit [Remote host closed the connection]
konv_ has joined #zig
konv has quit [Ping timeout: 240 seconds]
konv_ has quit [Remote host closed the connection]
<rsdimenus>
andrewrk: my long term goal is to use zig with any RPI projects, i just want to get a hello world working in C first :)
<rsdimenus>
it's making me realize the value of zig even more, cross compiling is so easy
<andrewrk>
you can even use zig to cross compile your c hello world code
<rsdimenus>
i mean clang/llvm does arm-eabi out of the box, but it took me way too long to figure out that I can only do aarch64-elf with gcc
<rsdimenus>
is there a aarch64-eabi equivalent?
<andrewrk>
in zig? zig build-exe --c-source hello.c -lc -target aarch64v8-linux-musleabihf
<andrewrk>
(or gnueabihf, both work)
<rsdimenus>
not gnueabihf, but regular eabi
<andrewrk>
depending on whether you want to static link libc or dynamically link the target glibc
<rsdimenus>
(soft float)
<rsdimenus>
not sure why someone would want soft float, i'm just curious
<andrewrk>
yeah, just remove the hf
<andrewrk>
well are you trying to target libc or not?
<rsdimenus>
no, baremetal
<andrewrk>
you can do just aarch64-linux-eabi
<rsdimenus>
there are too many targets to keep track of!
<andrewrk>
have a look at `zig targets`
<rsdimenus>
lol
<andrewrk>
and zig supports them all >:-]
<andrewrk>
(not true, we have a support table that describes in detail to what extent various things are supported)
<andrewrk>
but you do get a lot more out-of-the-box with zig
<rsdimenus>
yeah
<andrewrk>
zig cross compiling c code for bare metal is nice as well because it provides some basic libc functions such as memcpy, memcmp, etc
<rsdimenus>
i have an rpi4, i'm going to follow your clashos example
<andrewrk>
oh, I haven't gotten clashos working with rpi4 yet
<andrewrk>
I don't have that hardware
<rsdimenus>
i'm going to use your example and the zig baremetal repo (which I've seen) to build idk something on rpi4
<rsdimenus>
we'll see
<andrewrk>
cool
<rsdimenus>
i just wanted to familiarize myself with the process of cross compiling and loading on baremetal
<rsdimenus>
(which is why I ended up in the llvm channel)
<rsdimenus>
i'd rather understand what's going on before jumping up to the zig level where things are easier :)
<andrewrk>
fair enough :)
Akuli has quit [Quit: Leaving]
<rsdimenus>
the error from lld was not helpful at all :(
doublex has joined #zig
<Tetralux>
That doesn't surprise me.
<Tetralux>
In fact, it would surprise me more if you got a good error message.
<jaredmm>
Alright. glfw3 is linking properly now. That looks like it was caused by trying to link the x86 library when the build was for x64. glfw3's pre-built binaries didn't specify which they were, but using vcpkg -triplet x64-windows got rid of those errors. Didn't fix the epoxy errors, though. Then I thought "wait, maybe x64-windows-static will work". `-- Note: libepoxy only supports dynamic library linkage. Building dynamic library.`
<jaredmm>
Both lld-link and link give the same errors, though, so that's good.
<andrewrk>
glfw3's pre-built binaries didn't specify which they were => <andrewrk> system dependencies, which is the main problem here <andrewrk> trying to integrate with somebody else's binaries that was produced by god-knows-what process
<andrewrk>
I called it :)
<jaredmm>
Yeah. Doesn't help that I build them with x86-windows the first time, either, but don't tell anyone.
<andrewrk>
anyway the header thing is in master branch now
<andrewrk>
unfortunately sr.ht picked the worst possible time to have outage, so binary downloads are delayed
sepisoad has quit [Quit: Connection closed for inactivity]
rjtobin has joined #zig
<rjtobin>
I'm calling a C function that returns a pointer. I'm casting the return value of a call to this function to a variable of type "?[*]". This was working fine (using a zig build from late July) but with more recent zig releases it crashes when the C function returns null. Am I using the wrong pointer type?
<rjtobin>
I thought from the docs that ?[*] should be sufficient (if the C function returns null, it would become Zig's null, which ?[*] is allowed to be)
<Tetralux>
I don't think I've ever seen anyone use that type; I've seen [*]T and ?*T, but never the combination -- or used it for that matter; it should work though.
<Tetralux>
Does this C function actually return a pointer to first of many things?
<rjtobin>
Yeah, it's a null-terminated string (the C function is just libreadline's readline())
<rjtobin>
Should I just be using [*]u8 instead of ?[*]u8? I assumed I had to use the latter since the return can be null
<nrdmn>
Tetralux: I think calloc would be an example where you'd use ?[*]
porky11 has quit [Quit: Leaving]
<nrdmn>
I've been working with plenty of ?[*] types recently
<nrdmn>
rjtobin: ?[*]u8 should be fine for a function that returns a pointer to an array of u8 or a null pointer.
<nrdmn>
is there any error message?
wootehfoot has quit [Read error: Connection reset by peer]
<rjtobin>
Yep, it is: "cast causes pointer to be null"
<rjtobin>
Let me make a minimal example. I just wanted to make sure I wasn't trying to do something stupid first
<nrdmn>
rjtobin: maybe you can use `git blame` to find the commit that caused this behavior
<rjtobin>
nrdmn: Do you mean git bisect, or is there a mode of git blame that I don't know about? I wouldn't know what line to examine for git blame (I don't know the compiler code at all)
<mikdusan>
nrdmn: `doesn't work` reduction you added in gist... crash or compiler error?
<nrdmn>
eh.. yes, git bisect, sorry
<rjtobin>
nrdm: Ah ok. Good idea in any case, will give it a try after dinner.
<nrdmn>
mikdusan: compiler error
<daurnimator>
andrewrk: looking into packaging again now.... the ZIG_SKIP_INSTALL_LIB_FILES dance is really weird