<wilsonk>
is there a way to override a "std" imported definition by a newer defiinition in a locally imported file? ie. I have a definition that overrides the sleep funcition and just want my new definition to take precedence, but I keep getting an override error
<wilsonk>
I know I could just rename my function but I actually have dozens of these errors and don't want to rename everything!
mnoronha_ has joined #zig
<Xe>
how do I turn an int64 into a string kind of like the libc function itoa?
shritesh has joined #zig
<shritesh>
Xe: You can write to a buffer with fmt.bufPrint
<shritesh>
...and for the other way around, it's fmt.parseInt
<scientes>
what you want to happen with signed numbers
<Xe>
a negative number should never be able to get there
<scientes>
then use @intCast(usize
<Xe>
:+1:
mikdusan has quit [Ping timeout: 246 seconds]
mikdusan has joined #zig
hio has joined #zig
<wilsonk>
scientes: you around?
<scientes>
wilsonk, yeah, why?
<wilsonk>
just wondering if there is a way to use a specific definition in an @imported file over another @imported file?
<scientes>
yes!
<wilsonk>
ie. it is defined twice so I keep getting an error
<scientes>
just use two two @cImport()s
<scientes>
to keep the conflicting headers separate
<wilsonk>
so they will namespace uniquely?
<scientes>
that's something c cant do
<scientes>
see the const c
<scientes>
c is just a variable
<scientes>
but in zig variables are namespaces
<wilsonk>
hmm, but then I would have to access via a unique namespace, yes? so @import("std/os/time") as time and then time.sleep and @import("./time") as mytime and then mytime.sleep?
<scientes>
yep
<wilsonk>
ok. I get that but the problem I am having is that I am @importing a file from someone else's library that confilicts with dozens of definitions in std. So now I would have to go through dozens (maybe over a hundred) calls and namespace all of them? UGH
<scientes>
nono
<scientes>
you don't "import as"
<scientes>
you import to a variable
<scientes>
and they can be nested, like std.debug.assert()
<scientes>
you only have to namespace the new conflicting library
<very-mediocre>
and not in line with the no-shadowing principle of zig
marmotini_ has quit [Ping timeout: 246 seconds]
marmotini_ has joined #zig
<shritesh>
That looks like expected behavior as structs are namespaces too. OTOH, I wonder if there is no way to access the outer function from the inner namespace.
mnoronha_ has quit [Ping timeout: 255 seconds]
<tgschultz>
see ralted issue #1836
marmotini_ has quit [Ping timeout: 240 seconds]
<very-mediocre>
tgschultz: I think I disagree with the proposed remedy in #1836. shritesh is right that structs have like a namespace aspect
<very-mediocre>
the real problem imho is calling such functions from within the struct using the unqualified name
<very-mediocre>
even in high level languages you would write `this.func()`
<very-mediocre>
rather than the ambiguous `func()`
ManDeJan has quit [Ping timeout: 255 seconds]
<tgschultz>
the issue is a bit different in #1836, in that both names are in the same namespace.
<very-mediocre>
yeah you're right, my bad
<very-mediocre>
confused it with something i read in #678 which seems to be the relevant place
<daurnimator>
tgschultz: yes. though the info in there seems incorrect now.
<tgschultz>
andrewrk: I'm pretty sure this should error because we're evaluating compileError on the result of a runtime expression, but I think it could error with an error indicating that as the problem instead of erroring with the compileError statement... if that makes sense: https://gist.github.com/tgschultz/236290d87d6103fdd111e5c46ab645ce
very-mediocre has quit [Ping timeout: 256 seconds]
TheLemonMan has joined #zig
scientes has quit [Ping timeout: 252 seconds]
<TheLemonMan>
any idea on how to have a function use the C ABI without being marked with `export`?
scientes has joined #zig
<TheLemonMan>
and do you have any pointers about C-string <-> slice conversions?
<scientes>
TheLemonMan, its just an array
<scientes>
oh it isn't
<scientes>
TheLemonMan, probably use mem.cpy()
mnoronha_ has quit [Ping timeout: 268 seconds]
<daurnimator>
TheLemonMan: 'extern'?
<TheLemonMan>
yeah, I mixed up `extern` and `export`... but I just wanted to affect the ABI and not the visibility
<wilsonk>
TheLemonMan: can you just force that with the stdcallcc convention? Is that what you mean? "stdcallcc fn myfunc() void {}"
Akuli has joined #zig
<TheLemonMan>
I guess so, the documentation is a bit hand-wavy about what it does
<daurnimator>
oh we only support stdcallcc? what about all the other calling conventions out there?
meheleventyone has joined #zig
<wilsonk>
I am not sure if that is the only one supported, but it should be trivial to add the others (I think), as LLVM outputs the specified convention in bitcode.
<wilsonk>
I haven't looked at how Zig is handling things though
<wilsonk>
hmm...looks like there is some commented out code for 'coldcc' and 'nakedcc' conventions, so perhaps ask Andrew? Might be some pragmatic reason that was removed and other conventions aren't supported
<shritesh>
Now all three of the WASI environments (wasmtimer, wasmer and lucent?) can run wasi binaries created by Zig out of the box.
<shritesh>
wasmtime*
marmotini_ has quit [Remote host closed the connection]
dembones has joined #zig
<hobomaic>
cool!
hobomaic is now known as hobomatic
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
nice work shritesh
<shritesh>
Thank you. Next comes the WasmAllocator
<andrewrk>
I realized yesterday that zig can now be use to make node modules
<andrewrk>
node supports wasm, zig supports wasm, just run your zig build before npm publish
<shritesh>
Yes!!!
<hryx>
dang
<andrewrk>
it's going to be a low-volume week for me as far as commits to zig - I'm writing my talk for next tuesday at philly ETE conference - which will be recorded
<hryx>
awesome!
mnoronha_ has joined #zig
<mikdusan>
👍
<shritesh>
nice
mnoronha_ has quit [Quit: Ping timeout (120 seconds)]
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 250 seconds]
<shritesh>
Should I not be able to do `const foo = extern fn bar(i32) i32;` at the top level and call `foo(0)` in some other function later?
<andrewrk>
right now function declarations are not expressions, but you can do `extern fn bar(i32) i32; const foo = bar;`
<andrewrk>
actually I think that `extern fn bar(i32) i32` is an expression that evaluates to a `type` which is the function prototype
<shritesh>
hmm
<andrewrk>
I do think there may be some room for improvement here
<andrewrk>
the meaning of `extern` is overloaded right now
<Xe>
shritesh: thank you for making zig's webassembly support better, you are actively making it easier for me to do amazingly satanic things based on unix first principles
<shritesh>
Xe: My goal is to never have to write JS or C ever again and I'm contributing my part
<Xe>
it's appreciated
<andrewrk>
shritesh, we're going to have to talk about that - we can leave that in for now but it's an accident than you can reference any LLVM builtin with @"" syntax
<andrewrk>
there are ways that could be problematic
<shritesh>
Definitely.
<shritesh>
Xe: ^_^
<andrewrk>
I won't pull the rug out from you though, if I change it I'll make sure your use case is still solved
<shritesh>
we need to make sure nvptx (CUDA) works too.
<andrewrk>
good point
ltriant has joined #zig
<Xe>
are the LLVM intrinsics absolutely needed to emit a `grow_memory` instruction?
shritesh has quit [Read error: Connection reset by peer]
<andrewrk>
I believe so
shritesh has joined #zig
<shritesh>
Both clang and rustc have builtins to do that
<andrewrk>
Xe, btw the crash you found, is because support for disabling error return traces in debug mode is not implemented, but it's required for wasm
<andrewrk>
we just need to implement a couple of llvm ir things and then it will be fixed
<shritesh>
Ah. So release mode should fix it
<andrewrk>
yeah - though I would use the work "workaround" :)
<shritesh>
Yes. I think I saw rust do something with backtraces. Lemme check
<andrewrk>
shritesh, the problem is in get_safety_crash_err_fn, it assumest the first parameter is the error return trace. we simply have to check if that's disabled and omit that parameter
<andrewrk>
let me see if I can just fix it real quick
<shritesh>
Gotcha. I was looking at how or if rust does backtraces in wasm
<andrewrk>
I don't think we pass that. the reason error return traces don't work is lack of the return address builtin
<andrewrk>
that's also why the stack traces of GeneralPurposeDebugAllocator wouldn't work on WASI either
<shritesh>
ah
<andrewrk>
but yeah if rust gets stack traces working on web assembly targets, that would be a good clue to see if there could be a way
<shritesh>
So much in the was{m,i} world is in flux and undocumented. I have way too much W3C CG meeting minutes, commit history and github discussion in the last few days lol