<andrewrk>
oh look at this, one of these PRs to merge is my own
utzig has joined #zig
<tgschultz>
hmm... use working in structs might offer some improvement on #2533, but it would largely function the same so I'll only bother with it if we go that way.
<shritesh>
I was stressing out about out of bounds on my state machine but then I realized I can force @setRuntimeSafety for the scope. This is awesome.
<andrewrk>
lots of great PRs recently. I love it when I can just press the big green button
benaiah has quit [Remote host closed the connection]
benaiah has joined #zig
fengb has joined #zig
<shritesh>
I wish there was a different word that’s like a middle ground between “fast” and “unsafe”. It currently sounds like “safe” is “very very slow” and “fast” is “very very unsafe” to outsiders and newcomers.
<fengb>
thar-be-dragons
<shritesh>
release-fast should be fast-as-c and release-safe should be fast-as-rust 😉
<andrewrk>
release-safe can't be as fast as rust, that's sort of the main advantage of rust over zig
<shritesh>
Yeah. That’s why the wink.
<andrewrk>
however debug and safe are planned to get faster, as the compiler gets better and can prove that certain safety checks are not necessary
<andrewrk>
haha
<andrewrk>
that sounds fine as long as the fast-as-rust CLI switch has an actual wink face emoji in it
<shritesh>
Related to 2289/995, can’t we accept members of tagged unions with void parameter like `Type{ .Member }` instead of needing `Type{ .Member = {} }`?
marijnfs__ has joined #zig
<donpdonp>
i copied a zig-built binary of my app from my intel laptop to my intel desktop, and when I try to run it I got:
<donpdonp>
hread 1 "zootdeck" received signal SIGILL, Illegal instruction.
<donpdonp>
0x0000000000241fe3 in std.json.State.fromInt (x=0) at /opt/zig/2019-05-20/lib/zig/std/json.zig:182
marijnfs_ has quit [Ping timeout: 258 seconds]
<gamester>
webassembly compiled code editor inside a video game, editing the source code of the video game, hot reload
<gamester>
edit the video game while inside of it and see the results, never leave the game. Hehe. Or just use two monitors, but where's the fun in that? :)
<gamester>
"Eh I don't like these constants, need to tune them" -> mark them with slider tags -> UI auto built in-game. Interact with UI in-game -> code hot reloaded
<donpdonp>
thats hot.
<gamester>
donpdonp: Yep! -- I don't know what's going on with your code but I'm guessing it's 'unreachable' being converted into the illegal instruction to detect undefined behavior.
<gamester>
that's something that clang and llvm do
<gamester>
donpdonp: looking at json.zig, x is probably not being converted into a valid enum
<donpdonp>
gamester: any idea why that might be happening?
<gamester>
donpdonp: Did you compile with release-fast? Are you doing json parsing and passing in different data on your desktop?
<donpdonp>
hmm im using build-exe and not specifying a release type
<donpdonp>
should be the same json file on disk as the laptop but i'll doublecheck
<gamester>
donpdonp: this sounds like something that shouldn't happen, I think andrewrk is gone for the day but he should take a look tomorrow
<gamester>
you should get a stacktrace, not a SIGILL
lygaret has joined #zig
<andrewrk>
shritesh, try using Type.Member or even just .Member
<andrewrk>
donpdonp, if you want to cross compile you need the -target flag
<andrewrk>
even if the target is the same architecture as your native platform
<andrewrk>
zig turns on native CPU features if you don't use -target
<andrewrk>
I should put SIGILL somewhere searchable in the docs
<donpdonp>
hmm both recent intel cpus, still might have instruction incompatibilities?
<donpdonp>
there sure are a lot of cpu flags these days in /proc/cpuinfo :O
<donpdonp>
gamester: hmm.
<andrewrk>
copying binaries that were created without -target parameter to another target is not supported
<gamester>
Well it's still fun to figure out what instruction this might be :)
<andrewrk>
sure :)
<shritesh>
andrewrk: Type.Member causes 2289 to trigger later. .Member errors with “variable of type '(enum literal)' must be const or comptime”
<donpdonp>
okay im just unclear as to what constitutes another target
<donpdonp>
i can believe an i5 and an i7 are different targets, its just not something ive seen before. what is the -target name to use?
<shritesh>
Type{.Member} would have looked more uniform
<gamester>
andrewrk: I don't see a way to choose architectural features (AVX, AVX2, ...), just x86_64. How does this work?
<andrewrk>
gamester, looks like I didn't type up an issue yet, for adding the ability to choose cpu features as part of the target
<gamester>
andrewrk: But there's some default set of instructions that llvm is permitted to use?
<gamester>
donpdonp: It wouldn't be i5 vs i7. It's newer intel architectures with new instruction sets vs older architectures
<donpdonp>
i need to do a diff on each set of flags and see what comes up
<gamester>
andrewrk: oh maybe it's -target uses no instruction set extensions at the moment. That's the concept I was looking forward (extensions).
<gamester>
for*
<gamester>
donpdonp: For cross compile you choose x86_64 as the target and it will run on all x86_64 CPUs. Later you'll be able to restrict that by choosing additional CPU features like AVX
<hoppetosse>
emekankurumeh[m] regarding the live reloading in tick - it has worked, but I started that like... 2 years ago... I think some of the osurce still has old syntax
<hoppetosse>
I've been splitting it up into its useful parts
<hoppetosse>
There's an example of reloading in the examples/live directory
<hoppetosse>
and in src/core/window.zig and app.zig is it being used
<hoppetosse>
(reimplemented)
<hoppetosse>
I've been meaning to clean it up, but work and uni have kept me busy. I'll get back to it someday...
<hoppetosse>
meanwhile, feel free to carve it for parts
<hoppetosse>
I think there's still some c code in there, stuff from old tutorials, and some of the files haven't been updated to the new synta
<hoppetosse>
Also, the live reload stuff is just wrapping c - not pure zig
_whitelogger has joined #zig
fengb has quit [Ping timeout: 256 seconds]
marmotini_ has joined #zig
lygaret has quit [Remote host closed the connection]
scientes has quit [Remote host closed the connection]
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
If I have an extern enum with an explicit type (let's say u64 for example) as a parameter in an extern fn will the enum argument be passed in the same way as a u64?
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
marmotini_ has joined #zig
IntoxicatedHippo has quit [Quit: Leaving]
kristoff_it has quit [Ping timeout: 244 seconds]
marmotini_ has quit [Ping timeout: 272 seconds]
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
allan0 has quit [Ping timeout: 248 seconds]
Ichorio has joined #zig
mixi has quit [Remote host closed the connection]
allan0 has joined #zig
mixi has joined #zig
scientes has joined #zig
Xe has quit [Ping timeout: 248 seconds]
Xe has joined #zig
gamester has quit [Quit: Leaving]
porky12 has joined #zig
fengb has joined #zig
hg has joined #zig
<fengb>
How important is large alignments (> double word) in general programming?
<scientes>
fengb, not as important to x86
<scientes>
but very important to other architectures
<scientes>
16-byte alignment generally
<scientes>
for SIMD stuff
ijneb has quit [Ping timeout: 258 seconds]
<fengb>
Blah, I had hoped that stumbling upon 8 byte alignment was good enough :(
<tgschultz>
it depends on what you're doing with it. there's no need for every allocator to be general purpose, because zig doesn't have any requirement for one allocator to rule them all.
<nrdmn>
I'm getting "inline assembly allows up to one output value". Why can't I have multiple output values?
<scientes>
limitation of the compiler
<scientes>
but you can fix it by just using more asm instructions
<scientes>
i don't think that any instruction actually more than one output value
<scientes>
even multiplication
<nrdmn>
interrupts may have multiple
<scientes>
you only have interrupts in kernel mode
<andrewrk>
fengb, you can define your allocator to only support up to 8 byte alignment and then return error.OutOfMemory if it's greater. that's allowed
<nrdmn>
that's what I'm doing
<scientes>
nrdmn, I think Linux generally uses the assembler (and not even inline assembly) for this type of stuff
<scientes>
and there should be public functions (and not marked GPL) for all this type of stuff too
<scientes>
but that is if you are programming Linux, and not bare metal
<fengb>
andrewrk: sounds good thanks!
<nrdmn>
I'm programming bare metal
<andrewrk>
fengb, don't forget to document that behavior!
<scientes>
it would be kinda cool if the interrupt entrace could be a calling convention, and you could just those registers as arguments
<tgschultz>
is anyone aware of the reasoning for functions like @popCount to take the type as a parameter? From what the documentation says, it returns the smallest int type that can store the result, and the type of whatever it is popCounting could just be inferred. So I have to specify the type for no apparent reason and then still have to cast it.
<scientes>
tgschultz, they shouldn't, they should return the smallest type. If not, the bug is mine
<scientes>
however the type will be one bit bigger than you might perhaps expect, because the way those work
<tgschultz>
I may not have made myself clear: they do indeed return the smallest type, but then I have to upcast that to do math with it. My question is, what is the purpose of specifying the type in the first parameter?
<scientes>
to make it not a foot-gun
<tgschultz>
what's the footgun case?
<scientes>
like @clz(u64) will return 32 more than @clz(u32)
<tgschultz>
but popCount doesn't have that problem
<scientes>
it does on negative numbers
<tgschultz>
ok, that's fair.
<scientes>
I also proposed to not allow implicit upcasting, but that was rejected
<tgschultz>
it just seems weird to me that if I pass a i32 to I would expect anything else
<scientes>
yeah that is a good point
<scientes>
the llvm intrinsic returns that
<nrdmn>
is there a direct way to return flags from inline assembler?
<scientes>
but we downcast it
<scientes>
nrdmn, you mean cpu flags? Your best bet is to look at entry.S in linux, or the BSDs
<scientes>
or just read your architecture manual
<scientes>
assembler can of course write to the stack, or put stuff in the C ABI registers
<scientes>
zig supports the C ABI
<scientes>
tgschultz, it will implicitly upcast to that however, if you just declare the type of the variable first
<nrdmn>
scientes: yes, I mean cpu flags and I'd like to write this in zig, not in C or any other language. There are probably plenty of lenghty solutions, but I'd prefer a neat little one-liner with the tools that I already use.
<tgschultz>
here's the problem it caused me: originally I had `@intCast(i15, @popCount(x));` which I later do some math with. I thought this could become `@popCount(i15, x)`, but because of the return type being the smallest unsigned that can hold the result I end up having to `@intCast` it anyway. This isn't a big deal or anything, it just seems weird to me.
<scientes>
nrdmn, the thing is that this is only supported in assembly, that is how everyone does it---if you write a zig library that abstracts this and is cross platform you are free to submit it, but zig and llvm just don't know about this stuff (and shouldn't)
<andrewrk>
nrdmn, you can bind any number of variables to the inline assembly, and store the cpu flags in them
<scientes>
assemblers don't even know about very rare instructions, like MMU instructions
mouldysammich has joined #zig
<scientes>
tgschultz, yeah I think making it clear that you are doing a 15-bit *signed* popcount is useful, and while I admit the second bitcast is a little funny, it is similar to what you have to do for bit shifts
<scientes>
and it is useful that you don't have to unsafely downcast it if you want a narrower type
<scientes>
(even if you know it is safe you have to use @intCast() to down-cast)
<scientes>
tgschultz, you don't need to use @intCast there, you can just i15(@popCount(i15, x))
<tgschultz>
actually it would be `i15(@popCount(u9, x));` the input is u9, the output needs to be i15. From the signature I got the wrong idea about how it worked is all.
<scientes>
other languages prohibit the bit manipulation on signed numbers, but I don't see the reason to do that
<scientes>
as twos-complement is here to stay
<tgschultz>
yeah. since zig enforces a po2 alignment it wouldn't be suitable for esoteric architectures anyway.
<scientes>
maybe 8-bit
<andrewrk>
if we wanted to support such an esoteric architecture we would have to give up LLVM as well, since they have the same requirement
<scientes>
but i hear llvm-avr isn't as good as gcc-avr (which still isn't great)
<tgschultz>
someday I hope zig can have other backends. but targeting such things in 1.0 is unreasonable.
<scientes>
at least gcc
<scientes>
native just seems like too much work
<andrewrk>
tgschultz, I agree
<scientes>
and some of go's internals for doing syscalls are pretty ugly
<andrewrk>
on both counts
<fengb>
Just curious... would that mean embedding multiple backends and possibly frontends into the same binary?
<scientes>
I think one of the points of having multiple implementations is to have them be pseudo-independent
<tgschultz>
any idea yet wtf is up with CI breaking frequently now?
<tgschultz>
in ways that aren't our fault, I mean?
jfo has joined #zig
<andrewrk>
tgschultz, I thought it was fine now? yesterday one of the apt repositories on the linux ci was down
<tgschultz>
oh it might be, I'm was looking at stuff merged yesterday.
Xe has quit [Ping timeout: 258 seconds]
Xe has joined #zig
Sahnvour has joined #zig
ijneb has joined #zig
<shritesh>
Can I use the c_allocator to free() memory that was given to me by a C function that malloc’d? (readline)
<tgschultz>
c_allocator is just a wrapper for malloc, so that should work.
jfo has quit [Ping timeout: 248 seconds]
<andrewrk>
shritesh, yes that's defined to be correct
<Sahnvour>
isn't there a catch if the function lives in another module that has its own libc ?
<scientes>
i don't think musl and glibc can co-exist in the same process
<scientes>
but I would love to see someone proove me wrong
<scientes>
but yes, that would apply if someone was using tcmalloc or jmalloc Sahnvour
<scientes>
or samba's tmalloc(), which has different semantics
<Sahnvour>
I don't know about linux world, but remember that on windows you have to pay attention to this kind of stuff, even if you are using the system's malloc/free on both ends
<scientes>
and with's zig concept of an allocator interface ;)
<Sahnvour>
of course but at least that's explicit :)
<andrewrk>
malloc is global
<scientes>
except when it isn't, as we were discussing
<andrewrk>
I don't think it's possible to have 2 malloc symbols
<Sahnvour>
andrewrk, the problem happens with dynamic libraries
<scientes>
Sahnvour, you still have to use dlopen, because the dynamic linker can only see one of a symbol name
<andrewrk>
you can't have a static libc and then have your api return libc-allocated buffers and then expect the API user to free them. that's just broken
<scientes>
or partial static linking
<scientes>
indeed it is broken
<andrewrk>
that's the same as saying "this allocates memory and you can never free it, it's always a leak"
<scientes>
unless they provided a special deallocation function
<scientes>
which is actually quite common
<andrewrk>
yeah that's fine. then the function is documented that you have to free it with in that way
<andrewrk>
that's what std.process.argsAlloc does
<Sahnvour>
I'm not sure which messages are adressed to me ; but shritesh did not specify how their executable is built. The example I linked is not about defined malloc in multiple object files, but the fact that malloc/free sometimes are _not_ global to the system
<scientes>
generally that should be expected to be broken
<Sahnvour>
that's how c/c++ projects are built on windows, call it broken if you want, but it's not rare
<nrdmn>
scientes: in C, I can read a flag with asm("" : "=@cco" (overflow)). How would I do that in Zig? (note that I am not specifically interested in the overflow flag but in flags in general)
<andrewrk>
dynamic libraries either need to dynamically link c or not have an API that expects the API user to use their own libc free() function
<scientes>
nrdmn, what arch is this?
<nrdmn>
x86
<tgschultz>
speaking of argsAlloc, I'm not sure it is necessary on windows. We could include an [8192]u8 buffer and on first call to args interator process the commandline into it. Unless I'm mistaken, 8192 is the limit of the command line on Windows and the parsing should always make it <=. If the user never calls args interator in their code, the buffer shouldn't be included anyway.
<andrewrk>
Sahnvour, I see your point but if the API expects you to call free(), from a zig programmer's perspective, std.heap.c_allocator is correct (even if the API is flawed)
<shritesh>
Sahnvour: I’m just running zig run source.zig --library c
<Sahnvour>
nrdmn, I think that's currently broken, some issue mentions this already, let me find it
<Sahnvour>
andrewrk, yes, I agree, just wanted to mention this gotcha in case it's needed
<andrewrk>
Sahnvour, I'm glad you mentioned it
<andrewrk>
tgschultz, I like where this is going
<scientes>
tgschultz, I also want to allowing looking at the environment in a separate startup function on Linux, and then have main() start at the very beginning of the stack, after
<tgschultz>
something similar should be doable for args, but the buffer is much bigger.
<scientes>
and your multiple return issue is also discussed there
<SamTebbs33>
Hi all, is it possible to get zig to warn/error when something (variable, function etc.) is unused?
<scientes>
no
<andrewrk>
SamTebbs33, that's something I want and I have an idea of how to do it, but due to the nature of zig's design it's going to be a feat to pull off
<scientes>
thats the short answer, it might be possible in a scope, but because zig analysis is lazy, I don't think it is possible in general
<scientes>
andrewrk, oh interesting
<andrewrk>
I should type up this idea, because it has to do with doc generation too
<scientes>
andrewrk, you are going to put it in the tokenizer/parser?
<SamTebbs33>
Yeah that's an issue. The lazy analysis is the reason why warning on unused is useful :p
<andrewrk>
I call it "multibuilds", the idea is that you specify a "set" of targets to build, and the compiler builds them all at once. this would enable things such as unused function, unused variable, and is kind of just necessary for actually useful documentation generation
<SamTebbs33>
By targets do you mean x86, aarch64 etc.?
<scientes>
wouldn't that be expensive, and more and more targets are added?
<scientes>
especially as you have a matrix of os's * arches
<andrewrk>
SamTebbs33, yes but that also includes build options - build mode, link options, etc
<scientes>
oses * arches * build-flags
SimonNa has joined #zig
<scientes>
its too expensive
<andrewrk>
generally a project has a fixed number of configurations they support. it's not all of the ones supported by the compiler
<andrewrk>
also, it only matters when branching. if your function doesn't do any if / switch on build configuration, it applies to all configurations
<andrewrk>
what has to happen is during comptime evaluation, it might have to take multiple branches if they correspond to multiple build configurations
<scientes>
yeah but this will greatly change the compiler, because LLVM-IR generally ends up arch-specific (especially with data-layout
<scientes>
if you want to speed it up like that
<andrewrk>
for doc generation it wouldn't even make it to LLVM IR
<andrewrk>
you could have a doc generator that didn't link against LLVM
<nrdmn>
aha, seems like llvm 8.0.0 doesn't support flags as output parameters yet. This has been added somewhat recently
<scientes>
doesn't appear like zig has a llvm-9 branch yet
<nrdmn>
s/llvm/clang/
<scientes>
too soon
<andrewrk>
"multibuilds" could support generating multiple artifacts, or maybe artifacts for only 1 configuration, or maybe none, and it's just doing compile error detection
SamTebbs33 has quit [Quit: leaving]
<andrewrk>
I'm pretty sure we just have to implement this in order to have doc gen
<andrewrk>
I spent a few hours discussing it last night with thejoshwolfe
<tgschultz>
mem.readInt variant appear to use (bit_count / 8), when reading, but streams use @sizeOf. Is this intended or should these match? My gut feeling is that the mem variant is correct.
<andrewrk>
I can answer that question
<andrewrk>
@sizeOf is the number of bytes that the type takes up in memory. loads and stores may access this many bytes
<andrewrk>
bit_count / 8 will give you the number of bytes that the integer uses, logically. u24 is a good example
<andrewrk>
for u24 bit_count / 8 is 3, but @sizeOf is 4
<andrewrk>
so for readInt, the function is looking at a slice of bytes, and a given endianness, and wants to interpret the bytes logically
<andrewrk>
however if it were to use @ptrCast and then a memory load, it would have to respect @sizeOf
<tgschultz>
that doesn't really answer my question though, which is ultimately this: should in_stream.readInt(u24) consume 3 bytes or 4? Right now it consumes 4.
<tralamazza>
I'm new to zig, sorry if this is a stupid question. I am trying to crosscompile (from linux to osx), does zig link to libSystem (or whatever the osx libc is)?
<andrewrk>
tralamazza, yes - that is the only supported syscall ABI by macos
fengb has quit [Ping timeout: 256 seconds]
<tralamazza>
and a mild rant, it's insane how annoying it is to crosscompile things to osx
<andrewrk>
yes there are quite a few obstacles for that particular target
<tralamazza>
I have SDL cross compiled, but giving me errors about ___error undefined, there is no end to the yak queue
<andrewrk>
when running on macos? or when linking on your linux system?
<tralamazza>
running on osx
<tralamazza>
when*
<andrewrk>
hmmm
<tralamazza>
now I am thinking of implementing a simple sdl/glfw in pure zig
<andrewrk>
that's an exciting project that several members of the zig community (including myself) are interested in, and there are a lot of problems to solve for every platform besides Windows
<tralamazza>
I've zero experience w/ windows API
<andrewrk>
I started looking into doing an X11 zig library. I concluded that I wanted better async/await/coroutines semantics first
<tralamazza>
I will not go into opengl/vulkan straight away in any case
<andrewrk>
the x11 C library that everyone uses is blocking, but that actually doesn't match the nature of x11 which is a server
<tralamazza>
yah I was looking into xlib now
<tgschultz>
oh, I see. readVarInt is meant to cover the usecase I'm looking at.
<andrewrk>
tgschultz, oops missed your question. I think it should consume 3
<tralamazza>
I'm just an annoyed embedded developer that cannot stand this electron app craze, i just want a stupid UI to work
<andrewrk>
tgschultz, which means that @ptrCast + memory load is incorrect for u24
<tgschultz>
so it would seem. I'll see about fixing it. It isn't blocking me right now, but it is relevant to what I'm doing.
<andrewrk>
tralamazza, UI is an inherently difficult problem. there are 2 things in particular that conflict with each other: (1) accessibility / standardization within an OS, and (2) simplicity / cross compilation / standardization across OS's
<tralamazza>
I will try my hand at writing a zig library
<donpdonp>
the number of existing UI libraries is dizzying.
<tralamazza>
is there a way to visualize what is parsed/returned from a @cInclude?
<tralamazza>
a debug output of some sort
<andrewrk>
tralamazza, --verbose-cimport
<tralamazza>
oh
<tralamazza>
<3
<andrewrk>
it will print the path to a generated .zig file you can then look at
<donpdonp>
grep -r gtk_c_func zig-cache/ is a quick and dirty way to look up constants
<tralamazza>
maybe this command (--verbose-cimport) should display the file path even if a zig build only hits cache
<andrewrk>
I thought it did
<tralamazza>
hm nope
<tralamazza>
I need to change a file or clear the cache folder
<tralamazza>
it's minor ofc
<andrewrk>
ah I see
lygaret has joined #zig
<tralamazza>
great language btw andrewrk, please don't let it become rust =P
<andrewrk>
I think I have a pretty solid understanding of exactly the niche that zig fills
<andrewrk>
so don't worry, it's not going to do that
mikdusan1 has joined #zig
marmotini_ has joined #zig
<andrewrk>
tgschultz, it just occurred to me that you could use usingnamespace + @This() in functions to potentially implement comptime interfaces
<andrewrk>
I haven't looked at either of your PRs yet, for all I know you already did this
<tgschultz>
andrewrk: I didn't yet because usingnamespace on structs wasn't a thing when I started. The end result would be similar to #2533 in usage but the implementation would be similar. #2533 could be improved to work at comptime too. I'm holding off making those improvements unless there's interest in going that direction.
<tgschultz>
However, it is worth noting that usingnamespace doesn't allow you to use self
<tgschultz>
at least it didn't in my test, but now that I think about it... hold on
<andrewrk>
oh right. @This() would refer to where it was declared. that makes sense. it wouldn't get hijacked
<andrewrk>
when you look at @This() you don't have to wonder, where is this function getting included or whatever. you can just look up the scope to struct/union/enum, and that's what it's talking about
<tgschultz>
even if you define it `pub fn foo(self: var)` and usingnamespace on it, you still can't call self.
<andrewrk>
ahh right. usingnamespace does not affect method call syntax
<tgschultz>
not today anyway
<andrewrk>
I wasn't trying to have an opinion on this at this time. just had a false realization
tyler569_ is now known as tyler569
<tgschultz>
there's a lot to consider re: interfaces. are we ok with a "comptime"/"runtime" separation? if so, what's the balance between clarity and ergonomics? If not, how do we handle ErrorSets? etc. It is not a decision I'd want to rush.
<andrewrk>
agreed. that's why I've been doing the other language stuff first, where it seems reasonable to reach a stable conclusion which could inform this one
Ichorio has quit [Ping timeout: 264 seconds]
<tgschultz>
but speaking of interfaces, I had the thought that In/OutStream should unify with SeekableStream. Most existing stream targets (slices, files) are seekable, and when it isn't we can throw error.Unimplemented. this would mean we could eliminate PeekStream.
<tralamazza>
can zig import C macros with parameters? or rather, what is the macro import rule?
Ichorio has joined #zig
kristoff_it has joined #zig
<andrewrk>
tgschultz, that seems reasonable
<andrewrk>
maybe the implementation could check if Unimplemented was one of the errors in the provided set, and put `unreachable` instead of `return error.Unimplemented`?
programisto has joined #zig
<andrewrk>
so you could have an error set that does not include Unimplemented, and promise to never call the seek functions
<andrewrk>
tralamazza, C macros are resolved when they produce actual exports - functions, types, variables, etc. but when the macro itself is the API, it's all heuristics based
<andrewrk>
e.g. we're pretty sure `#define PI 3.14` should be `pub const PI = 3.14;` but if it's `#define x {` wtf is zig supposed to do?
<tralamazza>
in the case of xlib is a bunch of macros to access an opaque pointer
<andrewrk>
the actual ABI of the server is pretty simple
<tralamazza>
i will try things, i don't have a plan for any of this
<tralamazza>
thanks for the help
SimonNa has quit [Remote host closed the connection]
<donpdonp>
lol @ c macro logic. there was a fair amount of GDK "type casting" in macros that I had to wade through
<mikdusan1>
andrewrk: i think zig fmt on tests for dep_tokenizer is going to remove carriage-returns which are needed
<mikdusan1>
oh wait i see it did a good job
<mikdusan1>
my bad
<donpdonp>
another example is linux's errno.h, its a lot of macro confusion but zig cuts to the real function involved: const errnoPtr: [*c]c_int = c.__errno_location();
<andrewrk>
mikdusan1, that was my manual edit
<andrewrk>
the 0x0d right?
<mikdusan1>
yes
<andrewrk>
zig fmt emitted an error which was correct, so then I just fixed it manually
<andrewrk>
it's ok that stage2 parser is more strict than stage1
<mikdusan1>
that's one of the reasons i had to implement a "hexdump" compare output for the tests... cr-lf vs lf, whitespace characters, tabs. so that added to size of pr
<mikdusan1>
heh "\x0d" == "\r"
<donpdonp>
this build.zig works fine with exe.linkSystemLibrary("c"); but when I try to specify a target with exe.setTarget(builtin.Arch.x86_64, builtin.Os.linux, builtin.Abi.gnu); then zig build throws const c = @cImport({ => error: C import failed
<donpdonp>
am I missing something?
<tralamazza>
hm @cDefine does not accept a {} as value for void (like the docs suggest)
<andrewrk>
donpdonp, can I see more information?
<andrewrk>
tralamazza, what error do you get?
<tralamazza>
c.zig:2:29: error: expected type '[]const u8', found 'void'
<tralamazza>
@cDefine("_GNU_SOURCE", {});
<andrewrk>
tralamazza, that's probably a mistake, but you can work around it with ""
<andrewrk>
donpdonp, I'll give you a hint, it's one of the hints
<donpdonp>
i see two 'error:'s and two 'note:'s but no hints
<donpdonp>
the obviuos error of those .h files not existing doesnt happen with target is unspecified.
<andrewrk>
donpdonp, yeah the .h files not existing is what I was talking about. so the question is: "why doesn't Zig find the .h files when target is specified?"
<andrewrk>
the answer is that when you compile natively, zig can look at your native system for .h files. when you cross compile, you have to specify explicitly where the .h files are, because your system ones are not necessarily correct
<scientes>
yeah both the debian thing and the FHS thing that Debian explicitely rejected (to come up with multi-arch)
<scientes>
-fPIC is correct, but as he is not using bionic he isn't forced into that
<tralamazza>
2041 is interesting because in a way is a discussion on how fancy you make your build system or how much you push to packages
<andrewrk>
tralamazza, the cross-compilation / cross-platform focus of zig pushes us in the direction of preferring zig packages to system packages
<andrewrk>
eliminating system dependencies improves reliability and consistency
<andrewrk>
of course, system package maintainers can always patch zig projects to use system dependencies - and I fully expect e.g. Debian to do this - but as far as the project is concerned, collaborating on it will be streamlined
<andrewrk>
and Debian users are encouraged by Debian itself to file bugs with Debian first and not upstream
<andrewrk>
this is already the case
<scientes>
as long as llvm and zig are version synced it should lead to too many problems
<scientes>
*shouldn't
<andrewrk>
that's the plan. although I already have an open bug with debian regarding that
<tralamazza>
my gut feeling (because I don't really know much) is that pushing to packages is the best option, since you make the build system simpler and more robust, while not creating a bottleneck for new/upgraded systems
<andrewrk>
scientes, the linux builds on ziglang.org/download are built against musl
marmotini_ has quit [Ping timeout: 272 seconds]
<andrewrk>
alright I know I broke a lot of stuff recently so I gave a gift for everybody as a consolation prize
<andrewrk>
*s/gave/have/
<scientes>
Turkish delight?
<andrewrk>
even better. default struct field initialization values
<scientes>
awww sweet
<andrewrk>
as soon as the tests finish
fengb has joined #zig
<emekankurumeh[m]>
christmas came early this year?
<andrewrk>
pushed
<scientes>
wow it was such a small change
<scientes>
beautiful
<lygaret>
I'm not even paying attention and I'm stoked
WilhelmVonWeiner has left #zig [#zig]
apoddubn has joined #zig
<andrewrk>
I'm omw to the airport for my marathon trip (race is on Sunday). Planning on using the 5 hour plane ride to get some copy elision progress
<apoddubn>
Hi! I'm playing around with wasm stuff but I'm having problems getting the functions exported. This shouldn't be a problem with llvm 8, so I'm not sure if that's the issue here. I'm on a mac and used homebrew to get the latest llvm, but maybe zig still uses the xcode version?
<shritesh>
apoddubn: did you compile zig yourself?
<apoddubn>
Or does zig bring its own clang version? not sure I can trust zig cc --version
<apoddubn>
No, I downloaded the executable
<shritesh>
It does.
<shritesh>
The downloaded binary is self contained.
<apoddubn>
ah okay, thanks.
<shritesh>
Have you marked the functions as export?
<apoddubn>
I did.
<shritesh>
What’s the problem you’re seeing?
<apoddubn>
Just redid a minimal example and it works fine now. Originally I tried building raulgrell's tetris repo.