ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<itsMontoya> :)
<itsMontoya> Just wait
<itsMontoya> I think I have a pretty interesting idea
<itsMontoya> Can do both eager and lazy coroutines
Ichorio has quit [Ping timeout: 250 seconds]
<itsMontoya> I gotta head home, but I'm going to beg the wife to let me work on this more tonight :D
itsMontoya has quit [Remote host closed the connection]
earnestly has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
lunamn_ has quit [Ping timeout: 268 seconds]
kllr_sbstn has quit [Remote host closed the connection]
<andrewrk> itsMontoya: I think you may be interested to read the std.event.Loop code. Specifically if you initMultiThreaded()
<andrewrk> It creates a thread pool
StateOffGames has joined #zig
<presiden> itsMontoya has quit 30min ago
<mikdusan> logged channel
rjtobin has joined #zig
itsMontoya has joined #zig
<itsMontoya> Can someone link me to the use-case where you call async before fn
<itsMontoya> Like async fn add(a: i32, b: i32) i32
_whitelogger has joined #zig
ntgg has joined #zig
<itsMontoya> Hmmm
<itsMontoya> I was hoping to pass a pub method as a func
<itsMontoya> Let me copy my code
<itsMontoya> I was hoping this would fulfill that
mahmudov has quit [Remote host closed the connection]
doublex has quit [Ping timeout: 245 seconds]
<itsMontoya> Updated it :)
<itsMontoya> andrewrk: I'm having trouble finding any reference to that error
wilsonk has quit [Ping timeout: 240 seconds]
<fengb> Function expressions aren’t a thing yet
wilsonk has joined #zig
doublex has joined #zig
wilsonk has quit [Read error: Connection reset by peer]
<itsMontoya> OH
<itsMontoya> So I can't do what I'm trying here?
<itsMontoya> I just updated the gist again
<itsMontoya> I thought I was getting close lol
<itsMontoya> My HOPE was to do this.. var co = NewCoroutine(sa1.add);
<itsMontoya> But I was getting another error
<itsMontoya> ^^^^ Error here
<fengb> This isn’t legal syntax yet: “const foo = fn() void { body }”. It needs to be “fn foo() void { body }”
<fengb> And functions can only be declared at the top level of a file/struct/union
<fengb> Bound methods can’t be passed around either. They have to be functions
<itsMontoya> That's a super bummer
<itsMontoya> My hope was the bound method would be treated as a func pointer
<itsMontoya> So then that could pave the way for interfaces
<itsMontoya> (or impl)
<fengb> Function pointers don’t have defined memory other than the pointer address
<itsMontoya> True
<itsMontoya> Is there any way I'd be able to accomplish what I'm trying to do here with the supported syntax?
<fengb> I think there’s discussion for closures or fat pointers
<itsMontoya> I saw some git issues about closures
<itsMontoya> I figured they were already implemented
<fengb> No closures yet
<itsMontoya> I think you can do a lot if there is a way to make struct methods more usable
<itsMontoya> Can get around the concept of interfaces/traits imho
<itsMontoya> I have to run, daughter has a cold. Going to help out the Mrs. I apologize with leaving more questions than answers :(
itsMontoya has quit [Remote host closed the connection]
wilsonk has joined #zig
chemist69 has quit [Ping timeout: 245 seconds]
chemist69 has joined #zig
hasanyasin has joined #zig
hasanyasin has quit [Remote host closed the connection]
ntgg has quit [Ping timeout: 265 seconds]
rjtobin has quit [Quit: Leaving]
StateOffGames has quit [Remote host closed the connection]
<sarahzrf> hmm, am actually getting slightly slower time from the zig version than the C version
<sarahzrf> im guessing its probably the overhead from error checking
<sarahzrf> i didnt do any checking of calloc return values in the c version >.>
LargeEpsilon has joined #zig
<sarahzrf> and of course in the zig version there's error checking all over the place in order to propagate
<sarahzrf> only marginally slower tho
LargeEpsilon has quit [Ping timeout: 240 seconds]
LargeEpsilon has joined #zig
LargeEpsilon_ has joined #zig
LargeEpsilon has quit [Ping timeout: 245 seconds]
gustav_o has joined #zig
_Vi has joined #zig
ltriant has quit [Quit: leaving]
tdeo has quit [Ping timeout: 268 seconds]
tdeo has joined #zig
mahmudov has joined #zig
avoidr has quit [Quit: leaving]
BigEpsilon has joined #zig
LargeEpsilon_ has quit [Ping timeout: 264 seconds]
earnestly has joined #zig
BigEpsilon has quit [Quit: Leaving]
LargeEpsilon has joined #zig
LargeEpsilon_ has joined #zig
LargeEpsilon has quit [Ping timeout: 245 seconds]
BigEpsilon has joined #zig
LargeEpsilon_ has quit [Ping timeout: 245 seconds]
<ceymard> will the `fn <name>(...)` disappear in favor of `const <name> = fn (...` ?
<ceymard> shouldn't extern go with pub / const / var in that case ? aren't we referencing an external symbol ?
<ceymard> `extern const my_fn_from_c = fn(...`
<ceymard> oh wait there's a part about it
<ceymard> don't know if it made it into the spec
<mq32> ceymard, nothing of #1717 is "spec" yet
<ceymard> oh ok
<ceymard> ah there is no "spec" label
<mq32> nah, it's an accepted proposal, but as long as it's not implemented, it is neither spec nor real :D
LargeEpsilon_ has joined #zig
<daurnimator> _Vi: you might have been looking for the 'non-exhaustive enum' proposal
<daurnimator> _Vi: you were probably also looking for `usingnamespace`
LargeEpsilon has joined #zig
<daurnimator> andrewrk: whats the shortcut plan for docs?
BigEpsilon has quit [Ping timeout: 276 seconds]
<daurnimator> is it the 'make doc comments acceissble from @typeInfo' solution?
gustav_o has quit [Remote host closed the connection]
LargeEpsilon_ has quit [Ping timeout: 268 seconds]
<mq32> daurnimator: the plan for docs is stage1 outputting json code that will be formatted by self-hosted
<telemach> hello, I continue to explore topic of interfaces; this time I took approach from this PR
<telemach> I like this approach because it's clear and straightforward, and also allows to have the type conforming multiple interfaces, and cast it back from interface when needed.
<telemach> Is anyone keen to help me to understand if this approach optimization-friendly? Is generated assembly any optimal for the task in my example?
<telemach> I renamed things a bit (because Interface there is more about Implementation inside actual interface type) and came up with this silly example:
<daurnimator> telemach: why the extra indirection via _compare instead of having the user provide the actual `compare`?
<telemach> just for the calling magic, otherwise need to, s2)
<_Vi> Is there "safe navigation operator" in for optional field access in Zig?
<telemach> (with `&` before args ofc)
<telemach> does this indirection have cost expect boilerplate? i assume that it should be easily optimized out, but i don't know for sure and can't read assembly
<telemach> s/expect/except/
<daurnimator> _Vi: what would you want to happen if its null?
<_Vi> daurnimator, Return null, obviously.
<_Vi> If type of the field is itself nullable, then the result may be doubly nullable (preserves info) or just nullable (flattens).
<daurnimator> _Vi: in zig there is no non-safe navigation...
<daurnimator> _Vi: i.e. `` isn't allowed if `foo` is nullable
<_Vi> Unsafe navitaion: `mything.?.myfield`
<_Vi> It is way shorter and nicer to type than safe analogue `if(mything)|x|x.myfield else null`
<daurnimator> _Vi: have you considered `orelse` and a slight change in your control flow elsewhere?
<daurnimator> `( orelse return null).bar`
<daurnimator> telemach: oh interesting that the self-passing doesn't work if its a function field
LargeEpsilon has quit [Ping timeout: 276 seconds]
samtebbs has joined #zig
LargeEpsilon has joined #zig
<_Vi> How do I make comparable structs? Or how to I otherwise "wrap" a primitive type in some smart object with domain-specific functions and checks?
<mq32> _Vi, write a compare function for the struct
<mq32>, b)
<_Vi> Maybe better `eq`? Are there standard names for such functions that correspond to primitive operators?
<_Vi> `a.eq(b)`.
samtebbs has quit [Ping timeout: 268 seconds]
<via> mem uses eql, could be some precedent there
<tgschultz> _Vi there is also std.meta.eql, which compares structs on a field-by-field basis if that helps at all
<_Vi> OK. So struct-specific functions that compares them while keeping field private should be called `eql`.
Barabas has joined #zig
LargeEpsilon has quit [Ping timeout: 268 seconds]
Ichorio has joined #zig
porky11 has joined #zig
_Vi has quit [Ping timeout: 276 seconds]
ntgg has joined #zig
sarahzrf has left #zig ["WeeChat 2.6"]
ntgg has quit [Ping timeout: 245 seconds]
<mq32> it's really time for "use" to deprecate
LargeEpsilon has joined #zig
_Vi has joined #zig
<mq32> hm, i need some advice
<mq32> i want to wrap glBufferData(GLenum target, GLsizeiptr size, const void *data, GLenum usage) to zig
<mq32> so my idea was to do "setData(self:Buffer, data: var, usage: BufferUsage)
<mq32> is that a sane idea?
halosghost has joined #zig
<andrewrk> mq32, why not `data: []const u8`
dimenus has joined #zig
ntgg has joined #zig
ntgg has quit [Ping timeout: 245 seconds]
<mq32> because i always forget we have something beautiful like @sliceToBytes
doublex_ has joined #zig
kenaryn has joined #zig
doublex has quit [Ping timeout: 245 seconds]
<kenaryn> Hello, please is there a discrepancy in performances between calling a builtin or using a keyword, e.g. @export builtin|export keyword?
<andrewrk> kenaryn, no difference
<kenaryn> Thank you sir.
<andrewrk> @export can be useful if you want to do comptime logic like this:
doublex_ has quit [Ping timeout: 240 seconds]
<andrewrk> mikdusan, I also ran into recently
<daurnimator> andrewrk: did we ever get a way to export something without a name?
<mq32> daurnimator, that doesn't really make sense, does it?
<mq32> huh
<daurnimator> mq32: the `_1` in there... shouldn't need to be
waleee-cl has joined #zig
doublex has joined #zig
<mikdusan> if i read code correctly, the "payload" of decls brought in by usingnamespace are _NOT_ added to ScopeDecls.decl_table and instead added to use_decls,
doublex has quit [Ping timeout: 264 seconds]
<mikdusan> and later something triggers a load of payload decls from use_decls -> decl_table
<mikdusan> there are a few places (namely where I recently patched ir_analyze_container_member_access_inner to support VarDecl struct-method calls),
<mikdusan> ok i think i see the gap now. just thinking outload :)
<companion_cube> thinking out loud?
<mikdusan> yes
<Cadey> that method works great
<Cadey> even better when you let the rubber duck talk back
<daurnimator> quack.
<presiden> \_o< (meow)
<mikdusan> heh nice
LargeEpsilon has quit [Ping timeout: 264 seconds]
mahmudov has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
<daurnimator> mikdusan: I just came to a realisation far far too slowly. your nick is based on your name.
<mikdusan> nobody ever said I was original :)
<fengb> It's missing a letter
<companion_cube> wait until you realize that andrewrk's nick is also based on his name
<mikdusan> i can't even remember why i did that. maybe mikedusan was taken. or i wanted to limit to 8 chars.
<fengb> ... I now read his name as Andrew R Kelley
<fengb> Unfortunate implications >_>
<jaredmm> andrewrk, just as confirmation: the epoxy linking issue happens with a normal C program, so it is something about how it is built on Windows that causes the problem. Only difference I noticed between a working and not working Windows .lib was that the code section included the exported symbol a second time.
doublex has joined #zig
<daurnimator> companion_cube: yeah. but somehow in my head I read it as "andrew work"
<companion_cube> "andrew worker"
<companion_cube> it's just one of his worker threads
LargeEpsilon has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
doublex has quit [Ping timeout: 245 seconds]
ntgg has joined #zig
<andrewrk> jaredmm, thanks for the follow-up
<andrewrk> scientes, I'm going to play around with the way you implemented vector element access. I might need to make some adjustments
<scientes> 121/803 behavior.bool.test "behavior-mipsel-linux-none-Debug-bare-multi bool vectors"...test failure
<scientes> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<scientes> see, this is buggy qemu, not zig or llvm
<andrewrk> scientes, as an example, this crashes the simd branch, where `v` is a vector: const ptr = &v[1];
<scientes> SIMD support in qemu is buggy, arm-32 too (arm64 seems to work)
<scientes> andrewrk, oh yeah, that needs a special exception, which I forgot to put in
<andrewrk> I'll be happy to rework the Array accesses on vectors commit, but it'll take me some time
<scientes> yeah I can work on the address not being possible
<andrewrk> I think this is the same problem as taking the address of a non-byte-aligned packed struct field, which requires additional metadata into the pointer type
<scientes> except here you just can't take the address
<andrewrk> and we should just embrace that. a zig pointer type can have metadata that tells you how to access the vector
<scientes> gcc ang clang will both error
<andrewrk> that's the same thing with packed structs
<andrewrk> hmm, you got it working with runtime indexes though, nice. that's a difference
<andrewrk> scientes, here's a question that I think you are the best poised to answer. would making the vector index required to be comptime be problematic?
<scientes> andrewrk, not currently, but for RISC-V (which isn't supported by LLVM yet, but they are working on it)
<scientes> which has variable-length SIMD
<andrewrk> in what way would that be problematic?
<scientes> the length is run-time on RISC-V
<andrewrk> hmm is this what the vscale thing is designed to address?
<scientes> not sure what that is
lunamn has quit [Ping timeout: 245 seconds]
<andrewrk> search for "vscale" on
<scientes> yes
<scientes> stage1 will require a overhaul once llvm figures it out, but I have tried to not create problems in the zig code
<andrewrk> OK, I want to think through this carefully
<scientes> like maskedLoad and maskedStore are very x86-specific and deprecated
<andrewrk> it's an important design consideration whether or not the appropriate vector length is comptime-available or not
<scientes> It is on current architectures
<andrewrk> I want to learn more about this runtime vector length risc v thing
<scientes> Mill CPU does the same thing, but that is still vaporware
<daurnimator> the hardware is vapor...
<scientes> <andrewrk> and we should just embrace that. a zig pointer type can have metadata that tells you how to access the vector
<scientes> but you really can't take a pointer
<scientes> just copy the value
<scientes> but I guess "pointer" could be reference
<scientes> and could even support pointer arithmetic
<andrewrk> scientes, if the index is comptime known, then the index can be part of the pointer metadata. this is how packed structs work
<scientes> anyways, for now I think it should just be disallowed
<scientes> ahhhh, I see
<andrewrk> so that's why it's pivotal whether or not we decide if indexes are allowed to be runtime
<scientes> oh yes, that's really useful
<scientes> even if on some architecture it has to be done with bit shifting
<scientes> no, i think it works on every architecture i've used
<scientes> I think pointer should be pointers, and they are with packed structs (its just that its a sub-byte pointer)
<scientes> and in that case it can be runtime too if you just use the high bits
<scientes> or whatever
lunamn has joined #zig
<andrewrk> another option is that index syntax has to have comptime indexes but additionally provide @vectorLoad(v, runtime_index) and @vectorStore(v, runtime_index, new_elem_value)
<andrewrk> so you can have a "pointer" to a vector but the index has to be comptime known
<scientes> I don't see that pointers of vector elements is useful at all
<scientes> and its not even a pointer
<scientes> If archs supported run-time choosing of vector register it would be differnt
<scientes> but they don't
<scientes> andrewrk, cause you wouldn't be able to assign the "pointer" to one vector to the "pointer" to another vector
<andrewrk> why not?
<scientes> because the vector register an instruction references is fixed
<scientes> it would have to refer to the *same* register
<andrewrk> it's the same as integers
<andrewrk> vectors have a well defined in-memory layout
<scientes> but we don't have pointers to registers
<andrewrk> we have pointers to integers
<andrewrk> zig doesn't have the concept of registers; it only has the concept of memory
<scientes> ahh yes I see, and then it can be run-time
<andrewrk> but certainly we are relying on the optimizer to convert memory loads and stores to registers where appropriate
<scientes> I don't think LLVM knows how to optimize this
<scientes> you would have to write to memory and then write back to the register
<scientes> yeah I get your point
<scientes> the compilers have just been lazy with vectors
<andrewrk> in zig a vector is very much like an integer
<scientes> we could just stack allocate all vectors
<scientes> like we do with integers
<andrewrk> and we already support sub-byte pointers to integers
<scientes> and then we could do this
<andrewrk> I think we already do that...
<scientes> oh yes we do
<andrewrk> yeah even in your branch
<andrewrk> what I'm suggesting is that in the same way zig already supports sub-byte pointers to integers, that might be the best way to do per-element pointers to vectors
<scientes> yeah, I think you've convinced me
<andrewrk> and we can still provide runtime element index access builtins for that use case
<scientes> no, we can do both
<andrewrk> this will make all zig pointer semantics work correctly
<scientes> run-time and comptime index
<scientes> the problem with that is that the pointer is bigger
<scientes> at least on 32-bit arches
<andrewrk> the point of comptime index is that the pointer can be not bigger
<andrewrk> because the index will be part of the type
<scientes> oh no, it isn't bigger!
<scientes> its just pointing to the stack, and its aligned!
<scientes> so you can use the low bits
<andrewrk> right
<scientes> except that only works for byte-sized array elements
<scientes> and llvm bit-packs sub-byte-sized vector elements
<scientes> sorry, not array there, then the packing is differn't
<andrewrk> the runtime address will point to the base of the vector. the comptime pointer metadata will inform how to access the element
<scientes> we still have 4 bits free
<andrewrk> yes I'm not even suggesting to use these bits
<scientes> rather support run-time indexes, have it point to to the element, and just have addrof not work on weird-sized integers
<scientes> in vectors
<scientes> although then its quite a hack with getelementpointer
<scientes> yeah, i guess comptime index support is better than no index support, ok agreed
<andrewrk> &v[2] would have type of something like this, assuming v is @Vector(4, i32) type: *align(16:0:4:2) i32
<andrewrk> here I appended another : field to packed struct syntax, this way we can even refer to sub-bytes of elements of a vector
<scientes> I don't see this a reason to change the syntax
<andrewrk> `*align(4:0:4) i32` is status quo syntax; and in fact `*align(4:0:4) i32 == *i32`
<scientes> hmm, I haven't used that type of syntax. RISV-V also has pretty cool bit-shuffle instructions
<andrewrk> if pointers gain additional metadata for vectors, then it makes sense to add this other field
<andrewrk> for: `*align(16:0:4:2) i32` it would mean: "this is a 16-byte aligned address, pointing to index 2 of a vector of i32 elements. Offset starting from bit 0, and the size of the containing integer is 4.
<andrewrk> this is that bit_offset_in_host, host_int_bytes, thing you were asking about
<scientes> ahh thanks for the explination of the syntax, i was looking for that
<andrewrk> let me rephrase the explanation
<scientes> I think I get it
<scientes> but vectors don't need the bit_offset and host_int fields
<andrewrk> for: `*align(16:0:4:2) i32` it would mean: "this is a 16-byte aligned address, pointing to the base of a vector of i32 elements. We refer to a 4-byte integer at index 2 of the vector, offset starting from bit 0
<scientes> and they should never be packed like that
<andrewrk> you could put a vector into a packed struct
<scientes> oh I guess that is OK
<andrewrk> hmm that's not quite what this situation would cause
<scientes> all this stuff is comptime
<andrewrk> yes, usually nobody would even see these types; it would just look like normal indexing worked
<scientes> and in this case pointer arithmetic can also be supported
<andrewrk> but if you tried to do foo(&v[1]) then you'd get something like, expected *i32, found *align(x:y:z) i32
<andrewrk> (unless you used the correct parameter type, in which case it would work fine!)
<scientes> yes it would!
<scientes> as we are not bound to C functions
doublex has joined #zig
<andrewrk> I think I would make the argument that this comptime index restriction is a good place to start
wootehfoot has joined #zig
<scientes> I want to support runtime indexes too
<scientes> that can't be remove
<scientes> yeah I'll have a stab at this
Barabas has quit [Ping timeout: 260 seconds]
<andrewrk> one way to do that would be to provide @vectorLoad(v, runtime_index) and @vectorStore(v, runtime_index, new_elem_value)
<andrewrk> this way they avoid going through a pointer type
<andrewrk> so you cannot have the &v[x] problem
<scientes> I'm still not convinced these pointers are useful at all
<andrewrk> this would probably be the most straightforward way to implement, to avoid having to introduce any additional complexity to the compiler
<scientes> i see a little use though
<andrewrk> well you already had to add a hack to avoid pointers
<scientes> i realized that f16->f128 should be implemented with @shuffle
<scientes> if you use vectors of u1s
<scientes> considering that RISC-V now has a bit-shuffle operation the optimizations might actually arrive
<scientes> yeah i turned it into a pointer as you say
LargeEpsilon has quit [Ping timeout: 265 seconds]
<scientes> we still don't need the special intrinsics
<scientes> you just do v.*[4]
<scientes> or v.*[i]
samtebbs has joined #zig
<scientes> It isn't that unsound
<scientes> that's the whole point of SSA is that you can do things like that
LargeEpsilon has joined #zig
<scientes> and LLVM's neededbits can even prune it
<scientes> the vector and the index belong together
<scientes> And I can't even emit that error until codegen.cpp because analyze doesn't have a use list like LLVM does
_Vi has quit [Ping timeout: 276 seconds]
ntgg has quit [Remote host closed the connection]
meheleventyone has joined #zig
mahmudov has joined #zig
<scientes> and types are not resolved when the AddrOf is handled
<scientes> but that is due to not having an instruction for AddrOf
<scientes> and just assuming that things are addresses
LargeEpsilon has quit [Ping timeout: 240 seconds]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
<scientes> Hah! gcc 9 now works with constant indexes into vectors!
<scientes> and variable indexes
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Akuli has joined #zig
_Vi has joined #zig
itsMontoya has joined #zig
doublex has quit [Ping timeout: 240 seconds]
meheleventyone has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
meheleventyone has joined #zig
meheleventyone has quit [Client Quit]
Akuli has quit [Quit: Leaving]
<andrewrk> who is the person who was working on some kind of LSP support?
<andrewrk> or something like that
<andrewrk> they were in here a few days ago mentioning it
<andrewrk> ah yes I think that was it
<andrewrk> ceymard, I think you are going to be happy with the changes I'll be pushing today
<Cadey> how do i target wasi in zig?
<Cadey> -target wasm32-wasi-musl isn't working
<andrewrk> in what way is it not working?
<Cadey> Zig is unable to provide a libc for the chosen target 'wasm32-wasi-musl'.
<andrewrk> that message is accurate
<andrewrk> what do you need libc for?
<andrewrk> the wasi spec is incompatible with libc in a lot of ways
<Cadey> i was curious if i could use zig as a c cross-compiler
<andrewrk> you can do that for all the targets listed under "Available libcs:" in `zig targets`
<andrewrk> we've got a W.I.P. wasm32-freestanding-musl libc
<andrewrk> no wasi one yet
<andrewrk> it's likely whatever c code you wanted to cross compile would be fundamentally incompatible with a wasi libc
<andrewrk> things like memcpy, strlen, etc can work, but wasi doesn't support e.g. the concept of a current working directory
<andrewrk> or any networking
<andrewrk> or lots of stuff. it's not very mature
<andrewrk> I mean even as a specification
<daurnimator> libc doesn't have to provide that stuff...
<Cadey> so how would i get a pure zig program building against wasi?
<daurnimator> Cadey: use freestanding rather than trying to link libc?
<Cadey> should i -target wasm32-wasi?
<andrewrk> Cadey, your -target param is fine (you can drop the musl if you want, it doesn't matter), but you need to omit -lc
<Cadey> okay
<andrewrk> it's just bare bones support in std and some stuff may have regressed because we don't have test coverage for it
<andrewrk> shritesh did a bunch of nice contributions for wasi but lost interest months ago, and nobody else is driving the use case (until you, right now)
<fengb> You can also try plugging in the defacto wasi-libc:
<Cadey> fair enough lol
<Cadey> what is the default abi for wasm32?
<fengb> Not defined
<fengb> Only pointers and u32s are allowed externally atm
<fengb> It's actually a bit of a problem since the spec doesn't bother defining an ABi
<Cadey> what value should i put in build.zig?
<andrewrk> Cadey, .none
<fengb> Oh... I put musl there
<andrewrk> musl is fine too
<fengb> lib.setTarget(.wasm32, .freestanding, .musl);
<fengb> Oh does .none work? I should do that :P
<Cadey> this is weird, the default hello world app from `zig init-exe` works when i build it with `zig build-exe -target wasm32-wasi src/main.zig` but not with this build.zig:
<andrewrk> in what way does it not work?
<andrewrk> I can reproduce this
<andrewrk> I'm guessing std/build.zig is incorrectly choosing the artifact extension name or something like that
<andrewrk> Cadey, is incorrect, it doesn't know about the .wasm extension
<andrewrk> you can see it doesn't match target_exe_file_ext from target.cpp. I'll update it
<andrewrk> it's also wrong for UEFI
<andrewrk> Cadey, fix pushed to master
<Cadey> i'll patch my local copy of std/build.zig
<Cadey> yep that did it
<Cadey> thanks!
<fengb> Curious, what will you be making in WASI?
<Cadey> i'm trying to see if it's possible to make an echo server
<Cadey> oh
<Cadey> apparently you just can't in WASI
<Cadey> they don't have an ability for programs to create sockets
<Cadey> they can only inherit them from parents
<Cadey> :(
<Cadey> how the heck does nginx work then?
<Cadey> oh
<Cadey> emscripten
<Cadey> boo
_Vi has quit [Ping timeout: 276 seconds]
<andrewrk> emscripten can't self host yet:
<Cadey> andrewrk: yeah, i more mean they compiled nginx to wasm using emscripten, which makes a javascript wrapper around a subset of linux system calls
<andrewrk> yeah, sorry I was selfishly changing the subject
<Cadey> :+1:
<andrewrk> I want them to finish self hosting so I can make a zig "sandbox" that is just client side javascript
<Cadey> i half wonder if wasi is good enough for compiling zig to it
<Cadey> er
<Cadey> like the compiler itself
itsMontoya has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 245 seconds]
samtebbs has quit [Remote host closed the connection]
samtebbs has joined #zig
<samtebbs> I'm getting an error whose @errorName is "Overflow". Is that only caused by addition overflow?
<andrewrk> samtebbs, if you grep the std lib for `error.Overflow` there are only a few places that comes from
<andrewrk> mostly std.math functions
<samtebbs> andrewrk: Thanks, I'm getting it when using std.debug.openElfDebugInfo
<samtebbs> I'll look into what could be causing it
<samtebbs> Working on freestanding code does make tracking down things like this difficult
<andrewrk> yeah
<andrewrk> you might be able to set up a non-freestanding unit test
doublex has joined #zig
<samtebbs> Perhaps I could. My setup is quite involved though, I'm loading my kernel's elf file as a grub module then creating a SeekableStream using the start and end of the module, then passing that to openElfDebugInfo
<samtebbs> There's quite a few places where things could be going wrong xD
halosghost has quit [Read error: Connection reset by peer]
halosghost has joined #zig
halosghost has quit [Read error: Connection reset by peer]
halosghost has joined #zig
<samtebbs> I see that the error is returned in leb128.zig as I've seen that leb128 is used to decompress some parts of elf files
<samtebbs> and I've seen*
FireFox317 has joined #zig
<FireFox317> Is zig target armv7 to be used for an armv7-A core? I can't find a target arm-v7a
doublex has quit [Ping timeout: 240 seconds]
<andrewrk> FireFox317, I believe the "a" is a target feature, which would be handled by I consider this issue to be high priority
<FireFox317> Uhm well, Clang has the triple armv7a-none-eabi. Are you sure it is a target feature?
<andrewrk> I think they parse that as: arch: arm, sub-arch: v7, features: +a
halosghost has quit [Quit: WeeChat 2.6]
doublex has joined #zig
<FireFox317> Ah yeah that makes sense
<andrewrk> (I didn't understand this until a few months ago)
dimenus has quit [Quit: Leaving]
return0e has joined #zig
return0e_ has quit [Ping timeout: 276 seconds]
doublex_ has joined #zig
doublex has quit [Ping timeout: 276 seconds]
FireFox317 has quit [Ping timeout: 240 seconds]
kllr_sbstn has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
kenaryn has quit [Quit: WeeChat 2.3]
<andrewrk> I think this will make people happy:
doublex_ has quit [Ping timeout: 276 seconds]
kllr_sbstn has quit [Remote host closed the connection]
Ichorio has quit [Ping timeout: 246 seconds]
LargeEpsilon has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
LargeEpsilon has quit [Ping timeout: 268 seconds]
<samtebbs> andrewrk: That's pretty cool. I've been wanting zig to be able to do IDE-like analysis and code completion which this would help with
<samtebbs> Are you planning on doing the html generation?
<andrewrk> I'll at least start it, to entice contributors
<andrewrk> there's nothing more motivating than something that kinda works but is easy to improve
<keegans> andrewrk: does #3372 work w/ building the zig std
<keegans> as in, how could i dump type analysis on the zig std
<andrewrk> same as testing the std lib, except add -fdump-analysis to the cmd line
<keegans> ok so it does, cool , ill give that a try now thx
<andrewrk> ./zig test ../lib/std/std.zig -fdump-analysis
<andrewrk> I already ran the tests locally, I'll merge into master
<andrewrk> firefox has a built in json viewer which can be handy
<keegans> assert(@import("std") == std); is failing with the command you sent?
<keegans> hmm yeah i am yet to have run tests on Zig before, perhaps i have mucked something up
<scientes> is ???????????????bool really a type?
<keegans> :D
porky11 has quit [Quit: Leaving]
doublex has joined #zig
ltriant has joined #zig
<samtebbs> keegans: Try adding `--override-lib-dir lib`
<samtebbs> Or ``--override-lib-dir ../lib` if that is where the lib folder is
doublex has quit [Ping timeout: 245 seconds]
traviss has quit [Ping timeout: 245 seconds]
<keegans> thx
doublex has joined #zig
<samtebbs> No problem
samtebbs has quit [Remote host closed the connection]
traviss has joined #zig