<tgschultz>
if anyone can see how I'm the cause of the problem, I'll gladly wear the dunce cap to get past this.
<tgschultz>
...of course immediately after I log the issue I find a workaround
<tgschultz>
Ugh, nope. Workaround only helped once. Called from a different test that same thing fails in the same damn way.
<tgschultz>
andrewrk, #2501 is blocking me in ways that seem to defy workarounds. If you get a few minutes I'd appreciate if you could see how involved a fix might be.
<andrewrk>
tgschultz, noted, thanks
hio has joined #zig
<andrewrk>
tgschultz, I'll see if I can get this bug fixed for you, but one random thought for a work around - try calling without method syntax
<tgschultz>
andrewrk: I did that, but where the problem shows up just changes. If I change it in int() it'll work for one test but then fail in a different one. In order for that fix to be used I'd have to do every function that uses any interface that way.
<tgschultz>
depth of the call stack seems related to the problem showing up
<tgschultz>
or something
karrick has joined #zig
karrick has quit [Remote host closed the connection]
jevinskie has joined #zig
shritesh has quit [Quit: Leaving]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #zig
hio has quit [Quit: Connection closed for inactivity]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thalheim has quit [Ping timeout: 252 seconds]
avoidr has quit [Quit: leaving]
jjido has joined #zig
kristoff_it has quit [Ping timeout: 252 seconds]
rivten has joined #zig
mikdusan1 has quit [Quit: WeeChat 2.3]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
neceve has joined #zig
mikdusan has joined #zig
<BitPuffin>
err is there like a handy compiler switch for linking to libc? Or should I pick the libc from the system manually
<daurnimator>
BitPuffin: --library c
<BitPuffin>
ah, makes sense
<BitPuffin>
thanks!
<voldial>
Am I using -L wrong? "zig translate-c --library-path /usr/include access.c" -> "access.c:2:10: error: 'stdio.h' file not found" https://bpaste.net/show/fc34cc61c0dc
<rivten>
indeed, this gets parsed as : CXCursor_CXXAccessSpecifier = 39, CXCursor_FirstDecl = 1, CXCursor_LastDecl = 39,
<rivten>
and zig says that the enum taf value 39 is already taken :(
very-mediocre has joined #zig
<tgschultz>
that's a known issue
<tgschultz>
a common way to deal with cImport issues right now is to dump the translated C out to a file and manually fix the problems, then import that file.
<tgschultz>
type id of array is Array, but pointer to an array is a Pointer.Size.One with the Child type set to the array type
<tgschultz>
of course, you could just use `std.meta.trait.isIndexable(T);`
<tgschultz>
or `std.meta.trait.isSlice(T);`
<tgschultz>
depending on what you're looking for, donpdonp
<donpdonp>
ok thx for the detail.
<donpdonp>
im trying to put together a structToJson(struct: var) []const u8
<tgschultz>
you can look at how std.fmt and std.io.Serializer inspect types
dm1try has joined #zig
<donpdonp>
ah thx.
<donpdonp>
im slowly realizing just how much zig can do at compiletime. :O
<donpdonp>
why is it I can warn @typeId(T) => "TypeId.Array" but warn @typeInfo(T) => requires comptime.
Zaab1t has quit [Quit: bye bye friends]
<tgschultz>
try warning `comptime @typeInfo(T)`
<kristoff_it>
donpdonp: same for me, it's like when neo gets out of the matrix in the beginning, it's that macros never really let us use our eyes
<andrewrk>
@typeInfo always runs at comptime
<donpdonp>
warn("{} {}\n", @typeId(T), comptime @typeInfo(T)); => error: parameter of type 'builtin.TypeInfo' requires comptime
<andrewrk>
this is a var args issue
<donpdonp>
kristoff_it: haha. true.
<tgschultz>
sometimes I think "this should always be comptime, right?" but then I leave off `comptime` and the compiler takes an invalid branch, so I usually sprinkle it in as the very first step in trying to work out what's wrong.
<tgschultz>
case in point: pretty much everything in std.meta
<donpdonp>
ok so I cant warn, but i can still use it. \o/ if(info.Array.child == u8) { ...
<shritesh>
andrewrk: the wasm generated from build-lib still needs to pass through the wasm linker before being usable in the browser. Where would be the best way to introduce this? I have been struggling to figure this out.
<shritesh>
build-exe blocks indefinitely with that somehow.
<andrewrk>
ok I'll figure out why
<shritesh>
Thanks
jevinski_ has quit [Ping timeout: 246 seconds]
jevinskie has joined #zig
<dm1try>
Hi there! A noob problem, I've just built zig from the source using master branch on osx 10.14.4 and it looks like I have some problem with encoding
<shritesh>
dm1try, the pointer alignment safety fail is a known issue with building Zig in debug mode on OSX
<shritesh>
Try building it in release mode
<andrewrk>
this is the first I've heard of this issue
<andrewrk>
I've been building debug mode on my OSX laptop
<shritesh>
I thought it was known. I could never build in Debug
<donpdonp>
if (@typeId(@typeOf(value)) == builtin.TypeId.Pointer) { warn("ptr {}\n", @typeId(@typeOf(value.*))); } => attempt to dereference non-pointer type '[]const u8'
<donpdonp>
does that make sense? ohh the value.* has to hold for all cases, ie the if() guard isnt being run at comptime??
<shritesh>
Or more clearly: The tests would never pass in debug
<andrewrk>
donpdonp, this is a bit of a terminology inconsistency. according to @typeInfo, slices are Pointers
<andrewrk>
but you cannot use pointer deref syntax with slices
<dm1try>
sorry, looks like it was bad example, i have a problem with encoding even for simple assertion `assert(1 == 2)`, see https://pastebin.com/raw/ME9tbux6
<andrewrk>
dm1try, that looks like stack traces not working
<donpdonp>
andrewrk: ok. is there another test to see if a ptr is a slice instead of say, a pointer to a struct?
<andrewrk>
donpdonp, look at the output of `zig builtin`. look at the TypeInfo struct and you can see the info that you get for Pointer
<donpdonp>
oh Size.Slice, tgschultz pointe me to that earlier. thx.
<andrewrk>
dm1try, stack traces are working for me on my macos laptop with master branch
<andrewrk>
is your source repo up to date?
<dm1try>
andrewrk, thanks for the information, the source repo is fresh
<dm1try>
i've tried precompiled binaries and have the same problem
<andrewrk>
dm1try, thanks for the report. I don't have any ideas yet but I'll keep my eyes open
<andrewrk>
shritesh, the infinite loop: it thinks it has to build std/special/c.zig for std/special/c.zig
<tgschultz>
possibly related to #2500?
<shritesh>
Hmm. It also tries to invoke the linking step for c, compiler_rt and the actual source file with the previous change. I don't know if that's the expected behavior or not.
<tgschultz>
using relative paths in @import has issues under certain circumstances
<andrewrk>
tgschultz, I suspect that is a separate issue
<tgschultz>
yeah, #2500 doesn't so much loop as run out of memory and crash
<tgschultz>
granted that is caused by an infinite loop
<andrewrk>
shritesh, so both wasm object files and wasm library files are ".wasm"?
meheleventyone has joined #zig
<andrewrk>
this is problematic, if you do build-exe, the input and output file are the same sometimes
<shritesh>
Yeah. I think that was an error on my part.
return0e has quit [Ping timeout: 244 seconds]
<andrewrk>
well it might not even be wrong, but it unfortunately invalidates a previously held premise
<andrewrk>
is it going to break anything if we go back to .o for wasm? maybe we can use ".o.wasm"?
<shritesh>
No. The .wasm isn't really usable anyway
<andrewrk>
ok cool. I have a commit coming shortly which should solve all the use cases
<shritesh>
nice
return0e has joined #zig
<shritesh>
I'll work on the docs after that.
Sahnvour has joined #zig
<andrewrk>
build-lib -target wasm32-freestanding should produce a *.wasm file though, not *.a, yeah?
<shritesh>
Yes
<andrewrk>
I'll disable the "lib" prefix as well
<andrewrk>
build-lib foo.zig -target wasm32-freestanding => "foo.wasm", not "libfoo.a"
<shritesh>
does it gets passed through the linker?
<andrewrk>
build-lib? yes build-lib will run lld
<shritesh>
that should fix the problem
<andrewrk>
shritesh, did you see that zig also provides --library c for the wasm32-freestanding target? and supports building .c code as well
<tgschultz>
is there a reference for the assembler LLVM uses? Is it just GAS?
<andrewrk>
I wonder if triplefox got any further on their "build lua for the browser" example
<andrewrk>
tgschultz, it's an implementation in LLVM meant to match GAS but it's not the same code
<tgschultz>
but GAS docs should be close? That'll do.
<shritesh>
I saw that. Maybe wasmer can execute those.
<andrewrk>
wit that change, zig entered into emscripten territory
<donpdonp>
value has typeId TypeId.Pointer typeName []*config.ColumnInfo, but value.len == 8 when I "know" value has 1 entry in it. is that something Im doing wrong or a zig bug perhaps?
<shritesh>
AFAIK the ecosystems are moving towards WASI and libc as-is doesn't makes sense
kristoff_it has quit [Ping timeout: 255 seconds]
<andrewrk>
shritesh, in the browser though
<andrewrk>
wasi isn't meant to be in the browser, right?
<shritesh>
There's a polyfill that is compiled through emscripten
<andrewrk>
donpdonp, I'm not sure I understand your question, but note that @typeInfo is only looking at compile time known type information; it's not related to runtime values such as a slice length
Sahnvour_ has joined #zig
<donpdonp>
andrewrk: the typeinfo details are correct, but for(value) |item| {} loops 8 times when value has one entry in it. (it crashes after the first loop).
Sahnvour has quit [Ping timeout: 252 seconds]
<donpdonp>
i'll try to make a simpler test case.
neceve has quit [Remote host closed the connection]
<andrewrk>
shritesh, what do you think for wasm objects? .o or .o.wasm?
<Xe>
intermediate objects?
<shritesh>
It doesn't really matter. .o should be fine as it technically isn't a usable wasm file.
<andrewrk>
ok
<andrewrk>
Xe, yes
<Xe>
probably .o then yeah
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
shritesh, I'm especially curious on your thoughts on what to do with the return value from calling main - you can see in this PR it ignores the result and then does an infinite loop
<andrewrk>
note this is for non-WASI
<andrewrk>
and not relevant for the build-lib use case, which I think has been all of your use cases
<shritesh>
That is dependent on the execution environment. I think the reference sysroot ignores it too
<andrewrk>
wasi is handled correctly already - if (builtin.os == builtin.Os.wasi) { std.os.wasi.proc_exit(callMain()); }
<andrewrk>
I think you wrote that :)
<donpdonp>
andrewrk: okay pretty sure the problem is on my end, it was accessing an ArrayList items slice while ignoring the arrylist size and i think arraylist is preallocating the slice to 8
<shritesh>
Ah yes. I also think there is a concept of a start function with wasm. Lemme dig it up
<andrewrk>
I think the build-exe use case for in-browser wasm is weird; people should probably be using build-lib for in-browser stuff
<andrewrk>
donpdonp, ah yes. I've been meaning to make that more difficult to do on accident. when you want a slice from an ArrayList use toSlice() not .items
<shritesh>
According to the spec, the start function is void -> void
<andrewrk>
ok well that answers the question then, I'll update the PR
<donpdonp>
oh i would but im comptime land and if I try toJson(value: var) { if(var is an ArrayList) { value.toSlice } else { other types} }; toJson(otherType) => no member named 'toSlice' for otherType
<donpdonp>
if that makes sense.
<donpdonp>
or maybe 'meta land' is more accurate than comptime land
<shritesh>
build-lib definitely makes more sense for the browser. I started with build-exe because I needed the linker to get exec'd
<andrewrk>
shritesh, commit pushed
<shritesh>
I'm still not convinced that build-exe should assume libc-like environment in wasm32-freestanding but I probably have not have encountered that specific usecase yet
<andrewrk>
me either, what makes you think zig is doing that?
<shritesh>
Not after this change.
hio has joined #zig
hg is now known as alot
<tgschultz>
donpdonp: how are you determining if @typeOf(var) is an ArrayList?
<donpdonp>
im embarrased to say i string compare against @typeName(var). I figured I would improve that later.
<andrewrk>
shritesh, can you clarify?
<shritesh>
last night, build-exe was generating a main function implicity for wasm32-freestanding
<andrewrk>
ah, yes, that was a mistake - it's supposed to do that only if you do --library c
<andrewrk>
which is triplefox's use case
<andrewrk>
it's planned that --library c will even work on any freestanding target. obviously the OS stuff won't work but we could provide math functions, memset, memcpy, etc
<tgschultz>
donpdonp actually I'm pretty sure that's the only way to do that short of including a UUID or something as part of the ArrayList.
<andrewrk>
shritesh, ok I'm gonna merge it then
<shritesh>
Cool. The PR looks good to me. build-lib works for the browser.
<tgschultz>
donpdonp I suppose you could just use std.meta.trait to see if it has a .toSlice()
<shritesh>
build-lib's still kinda iffy for wasi but I don't have my machine setup to test that right now. I will be in a better position after Saturday.
<andrewrk>
noted
<shritesh>
The docs are broken on master right now with the change. PR coming up
dm1try has quit [Ping timeout: 256 seconds]
<tgschultz>
andrewrk: am I recalling correctly that it is a known issue that std.event.lockRunner intermittently breaks in testing?
<andrewrk>
tgschultz, yeah if any of the evented I/O stuff breaks in testing the tests should just be disabled until coroutine rewrite is complete
<tgschultz>
alright, that's what I thought, thanks.
<andrewrk>
shritesh, thanks
<andrewrk>
I didn't realize we had doc coverage for that, that's nice
<andrewrk>
ah I see
<tgschultz>
the different operand order of att syntax asm is screwing with my head.
<tgschultz>
many years of habit are offended.
<andrewrk>
yeah. pretty much everyone agrees the intel syntex is better
<andrewrk>
unfortunately llvm's and therefore zig's support of intel syntax is buggy
<nrdmn>
can I put padding into a struct without giving it a name?
<donpdonp>
tgschultz: hasFn seems sane, but I get the same error: fn toJson(value: var) { if(std.meta.trait.hasFn("toSlice")(@typeOf(value))) { process(value.toslice(); }}; toJson(not_slice) => no member named 'toSlice' in struct NotSlice
<donpdonp>
(toslice is actually toSlice, typo in irc only :)
<tgschultz>
add comptime to the if statement: if(comptime std.meta.trait.hasFn("toSlice")(@typeOf(value)))
<andrewrk>
triplefox, this is progress! the next step here is going to be improving the zig-libc .h files for the wasm32-freestanding target
<nrdmn>
andrewrk: my goal is to specify a fixed number of unused bytes between two struct fields
<very-mediocre>
tgschultz: this seems to confirm what you said, which throws a small wrench in some shenanigans I'm coding https://godbolt.org/z/74X-k7
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
triplefox, maybe I can make this today's live coding stream topic: trying to get lua to compile for web assembly
<tgschultz>
very-mediocre yeah, once a parameter is var, everything after it is also var because it could have its type determined by the first generic parameter.
<triplefox>
andrewrk, sounds like fun
<andrewrk>
that'll be in 1hr20min
<nrdmn>
bits, actually. I'm playing around with bit fields and thought it might be a good idea to declare individual flags as u1 and somehow be able to ignore unused bits in between
<andrewrk>
nrdmn, I think this will work pretty well after those 2 issues I linked are implemented. until then you might hit some rough edges
<triplefox>
i haven't explained why i'm doing this, but you might find it interesting: i am making a fantasy console like pico-8, but i am using wasm as the coding VM. then i got the idea that it would be nice to focus the toolchain around a literal "interpreted rom basic" which you could extend with wasm, instead of supporting a compiler so then i thought i would build lua for it too
<nrdmn>
alright. thanks!
<andrewrk>
triplefox, that does sound interesting
<andrewrk>
well your use case will get a decent amount of attention in about 1 hour
<andrewrk>
I'll give your project a shout out if you're in the twitch chat
<triplefox>
although i want to release a thing soon, actual tooling that makes it fun to work with will probably come in over the summer
companion_cube has left #zig ["WeeChat 2.3"]
<Sahnvour_>
you might want to make your idea map image clickable. cool project :)
shritesh has joined #zig
very-mediocre has quit [Quit: Page closed]
<shritesh>
that's so cool triplefox. Are you targeting just the web browser or do you have any plans for it being standalone / on other platforms?
<triplefox>
i'm actually going native first, web browser later...because if i went browser first i would spend more time resolving weird i/o issues that are specific to the browser. the current build is using go and glfw and i've tested it on windows and linux desktop
<triplefox>
for the wasm vm i'm using wagon
<triplefox>
wasm is convenient as a vm target since a lot of people are working on implementations for their cryptocoin server code or whatever and i can just steal that
<shritesh>
nice. I've recently started working on a wasm vm for zig.
<andrewrk>
shritesh, a wasi interpreter?
<shritesh>
a wasm interpreter first.
<triplefox>
ah, awesome.
mindfv has joined #zig
<andrewrk>
ahh I see so you can embed a wasm interpreter, and have wasm plugins
<andrewrk>
that's a good use case
<shritesh>
I am still on the parse-the-binary stage, I hope to have something to show soon
<triplefox>
zig comes into this picture as the possible "single dependency that does all the stuff you need to build a custom wasm binary" - but i also expect 90% of users to stay in my preconfigured lua
<andrewrk>
that is indeed what zig intends to be
<shritesh>
andrewrk, wasi support will just be a special execution context for the interpreter.
<andrewrk>
makes sense
<andrewrk>
sounds like we're going to be able to add tests for wasm32-freestanding as well as wasm32-wasi
<shritesh>
that's the plan
<nrdmn>
is it possible to have an allowzero pointer to an array?
<donpdonp>
can someone point me to another language that has a comptime mechanism?
<donpdonp>
ie does it exist in other langs, or is it unique to zig to have such an expressive comptime concept (with func params, variables, and blocks)
<tgschultz>
nrdmn, is there a reason to suspect it isn't? `var ptr: *allowzero @typeOf(my_array) = &my_array;`?
<andrewrk>
nrdmn, are you on the freestanding target? are you sure you want allowzero?
triplefox has quit [Ping timeout: 252 seconds]
kristoff_it has joined #zig
<nrdmn>
andrewrk: yes, I tried to access the first few bytes of my memory as a slice
<andrewrk>
makes sense, just checking
kristoff_it has quit [Ping timeout: 244 seconds]
<andrewrk>
nrdmn, there might be some places internal to the compiler where it needs to better propagate the allowzero attribute. let me know if you see something that should work but doesn't
<andrewrk>
we don't have any test coverage for freestanding targets yet
triplefox has joined #zig
<nrdmn>
donpdonp: I think template haskell is similar.
<nrdmn>
andrewrk: I tried to do @intToPtr([*allowzero] u8, 0)[0..16] but the compiler complains about the 'a' after the '*' being invalid. I'm not sure if that'd be the correct syntax.
triplefox has quit [Remote host closed the connection]
triplefox has joined #zig
<hryx>
very exciting stream today. zig/lua/wasm combo is gonna make a big splash I think :D
<shritesh>
andrewrk: I really like the improvements that we got to build.zig. After I'm done with the move, I'll look into the libc i/o aspect and how other wasm exec envs handle / expect it. I know wasmer provides a libc compatible engine
<andrewrk>
shritesh, sounds good. providing a libc shim for file system / OS stuff is something a third party project could do. it could be something you plug into the env: {} object
<shritesh>
Yeah. That's what (I think) wasmer does.