ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<jfo>
andrewrk: want to help me with a function signature?
<andrewrk>
there are a bunch of automatic cleanups we can add
<ltr_>
that was by hand?
<andrewrk>
but, here's a start, if you're trying to port zlib, zig can get you partway there
<andrewrk>
this is `zig parsec deflate.c`
<ltr_>
andrewrk: quick question , how can i add a path in build.zig so zig can find libs?
<ltr_>
to add a path to the linker to find libs
<andrewrk>
ltr_, I believe we have builder.addLibPath(path: []const u8)
<andrewrk>
but I think we should add that function to each build artifact, instead of globally
<ltr_>
can you pass --library-path when doing zig build?
<andrewrk>
no
<andrewrk>
but you can make that an option using the build API
<ltr_>
ok
<ltr_>
another question who can i see where zig is looking for libs?
<ltr_>
for the linker?
<andrewrk>
--verbose-link
<ltr_>
it is not finding anything in /usr/local/lib
<andrewrk>
we don't look in /usr/local/lib by default I think
<ltr_>
nor usr/lib
<ltr_>
lld: error: unable to find library -luv
<andrewrk>
ltr_, are you using zig build or calling zig directly? if the former, use --verbose
<ltr_>
both
<ltr_>
ill use verbose
<andrewrk>
that tells you the zig command it's running. then you might find it easier to modify that command line and try different things
<ltr_>
ok now i was able to compile ziguv
<andrewrk>
ltr_, what did you have to change?
<ltr_>
zig+libuv, but yeah core dump
<andrewrk>
I left you a github comment
<ltr_>
--library-path /usr/lib
<ltr_>
i dont know where is looking for libs
<ltr_>
verbose just tellme the command line it uses to invoke lld
<andrewrk>
I need to revisit the build system. right now it's a proof of concept but as you can see all the use cases aren't handled well
<andrewrk>
but it's important to the zig project, we want to improve it
<ltr_>
yes but its really flexible as it is, you can add more use cases as diferent build.zig templates
<ltr_>
imo
<andrewrk>
yes I think the potential is good
<ltr_>
you want to remove the & and then add it on the next line
<ltr_>
that comment you leave in my code
<ltr_>
you mean not to define loop as a pointer and add & to the uses?
<andrewrk>
you're using the uv API wrong
<andrewrk>
giving them an undefined pointer, but you want to give a valid pointer to (probably stack) memory
<andrewrk>
but you can't since zig translates uv_loop_t as an opaque type
<ltr_>
i get it
<ltr_>
i cant alloc a uv_loop_t with zig
<andrewrk>
right
<andrewrk>
that's a problem with our parse-c code
<andrewrk>
which I think is due to not having unions
<ltr_>
what if i use jemalloc, should i be able to use it?
<ltr_>
i thought that uv_loop_init was going to do the allocation, but right the user is responsable to clean their pointers
<andrewrk>
the problem is not where the memory is, the problem is that zig was unable to translate uv_loop_t type
<dimenus>
what part of the type is zig unable to translate?
<andrewrk>
you can see warnings with `zig parsec --verbose-cimport foo.h`
<andrewrk>
the warnings tell you what C code we couldn't translate
<andrewrk>
unions would be the next biggest win
<dimenus>
you've got that on your list right?
<andrewrk>
yes
<andrewrk>
we already have all the logic done, because enums contain a union in the implementation
<andrewrk>
just need to do the work
arBmind has quit [Quit: Leaving.]
<andrewrk>
dimenus, what was the other thing besides unions that I could look at to unblock you?
<dimenus>
andrewrk, #462
<andrewrk>
ah right. OK yeah that's a high prio issue too
<dimenus>
the dll works internally without ever calling LLVMSetDLLStorageClass
<dimenus>
but on truely 'exported' functions, we need to call that to make it visible in windows
<dimenus>
there needs to be a way to differntiate between just an externally linked function and an exported function
<andrewrk>
ah right
<dimenus>
on linux i don't think that distinction matters
<dimenus>
a symbol is a symbol
<dimenus>
andrewrk, so this is interesting
<dimenus>
i have a sample build.zig file that if i run zig build on cmd it just crashes
<dimenus>
but if i run it in powershell within vs code
<dimenus>
it gives me a proper error message
jfo has joined #zig
<andrewrk>
hmm
<andrewrk>
what kind of crash?
<dimenus>
its the build system crashing
<dimenus>
or doing something windows doesn't like at least
jfo has quit [Ping timeout: 255 seconds]
PV has joined #zig
<dimenus>
andrewrk, trying to use 'addIncludePath()' within build.zig but it doesn't look like the list gets relayed to the compiler
<andrewrk>
dimenus, probably a bug in std/build.zig
<dimenus>
yeah i'm looking through it
<dimenus>
but it's dense
<dimenus>
lol
<andrewrk>
LibExeObjStep represents a zig build target - an object, a library, or an executable. it has a reference to the builder struct
<andrewrk>
TestStep represents running `zig test`. it has a reference to the Builder struct also
<dimenus>
yep, the dir is populated on the LibExeObjStep
<dimenus>
but not in makeZig
<dimenus>
list is empty there so it gets dropped somewhere along the way
<andrewrk>
we should add include_paths local to LibExeObjStep
<andrewrk>
maybe you want 2 different objects to have 2 different include paths
<andrewrk>
gdb lets you set a memory watch point. if you think the include_paths list is changing, you can but a memory watchpoint on e.g. the length field, then run the code, then the debugger will break when that memory address is changed
<andrewrk>
I don't know if msvc supports this
<dimenus>
all build.zig files end up calling build_runner.zig correct?
<andrewrk>
it's the other way around - zig build compiles build_runner, which imports the user's build.zig
<dimenus>
ah
<andrewrk>
line 1 of std/special/build_runner.zig
<dimenus>
so we codegen build_runner every time the compiler is called?
<GitHub59>
zig/master 7a74dba Andrew Kelley: add docs for std.base64
<andrewrk>
jfo, ^ I added docs to answer your question
<andrewrk>
for the second thing: var buf:[s]u8 = undefined; riddle me this: where is the memory of buf stored?
<jfo>
is this a comptime thing?
<jfo>
also does that mean I need to sanitize my base64 input by stripping out invalid characters?
<andrewrk>
did you figure out where the memory is stored?
<jfo>
no
<jfo>
:\
<dimenus>
Microsoft has always considered VLAs in C to be a hack :P
<dimenus>
although they should know a thing or two about hacks.....
<andrewrk>
jfo, if you put something at global scope, it's in global static memory - allocated at *compile-time*. your .exe on disk has space for the memory
<andrewrk>
if you put something in a function, it's on the stack
<andrewrk>
if you call a function such as allocate() then it's on the heap, at least conceptually
<jfo>
I was going to say stack but I thought that was too simple! bah
<andrewrk>
stack frame sizes for each function are computed at compile-time. it would be a security vulnerability to increase the stack pointer by a runtime-known quantity
<andrewrk>
so, knowing all this
<jfo>
and file size is a runtime quantity
<andrewrk>
how many bytes can zig use for the stack frame of your function, which has var buf: [s]u8 in it?
<jfo>
limited only by the filesize which would be limited by the os if at all
<jfo>
... is a `test` block global scope?
<jfo>
(mem wise, I know functionally it is not)
<andrewrk>
test block is function scope
<andrewrk>
each test is a function
<jfo>
that is what I thought
<andrewrk>
I don't know what you're talking about re: limits
<andrewrk>
but zig can't compute a stack frame if the array length isn't known at compile time
<jfo>
I just mean that if `s` is the filesize, then `s` could be as big as a file could be
<andrewrk>
typically the entire stack is ~10MB
<dimenus>
stack size on most platforms isn't very large, so you wouldn't say want to open a 10MB file on the stack
<dimenus>
stack is for smaller buffers
<jfo>
well, that's not what I'm trying to do, I just didn't understand the error message
<andrewrk>
yes, and more importantly, it's for buffers for which the size is known to be bounded