ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
return0e has quit [Remote host closed the connection]
stratact has quit [Remote host closed the connection]
stratact has joined #zig
squeek502 has joined #zig
reductum has quit [Quit: WeeChat 2.6]
wootehfoot has quit [Read error: Connection reset by peer]
<halbeno> wouldn't "" and c"" work better for multi-line strings? (or literally anything other than // )
<halbeno> "There are no multiline comments in Zig (e.g. like /* */ comments in C). This helps allow Zig to have the property that each line of code can be tokenized out of context."
<halbeno> it seems inconsistent, like the string syntax was made to spite the comment syntax
<halbeno> I'm only 10% of the way through reading the documentation, that's just a first impression
<scientes> halbeno, you can't put newlines in a string
<scientes> without doing \n
return0e has joined #zig
<scientes> yes, this is better than in C
<scientes> if you really want, you can just use insanely long lines
<scientes> or use @includeFile
<scientes> or whatever itscalled
<halbeno> it seems ambiguous with comments
return0e has quit [Ping timeout: 265 seconds]
<halbeno> I was just suggesting that this would make more sense:
<halbeno> ""int main(int argc, char **argv) {
<halbeno> I haven't read the entire documentation yet though, so I don't know if "" is would be ambiguous with something else
<halbeno> just my first impression
THFKA4 has quit [Ping timeout: 252 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
<telemach> I think it's not ambiguous as multiline comments are about multiple logical lines, while \\ is about forcing few physical lines into a single logical line
mahmudov has quit [Ping timeout: 250 seconds]
reductum has joined #zig
<halbeno> says "This helps allow Zig to have the property that each line of code can be tokenized out of context."
<halbeno> and then the comment syntax is reused to break that property
<halbeno> it's funny at the very least
chemist69 has quit [Ping timeout: 246 seconds]
chemist69 has joined #zig
<pixelherodev> I've been going over the docs, and I can't find where "anyerror!type" is explained - can someone point me in the right direction?
<pixelherodev> Oh wait never mind found it :P
knebulae has joined #zig
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
_whitelogger has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
rjtobin has quit [Quit: Leaving]
return0e has quit [Remote host closed the connection]
return0e has joined #zig
reductum has quit [Quit: WeeChat 2.6]
<pixelherodev> Wait, can integers have any size? e.g. u3, i293, etc?
<emekankurumeh[m]> yes, but llvm craps out at 2^16 bit sized integers
<pixelherodev> I was just confused because there's specific sizes listed under primitives but in other places in the docs it uses e.g. u2
<pixelherodev> Thanks!
<emekankurumeh[m]> happy to help!
<daurnimator> halbeno: // is different to \\
<halbeno> daurnimator, apparently I can't read, thanks
<pixelherodev> The self parameter is passed implicitly with dot syntax, but must be specified explicitly, right?
<daurnimator> pixelherodev: correct. though there is an issue that might change that.
<pixelherodev> Alright, thanks
<pixelherodev> Is there a printf equivalent?
<pixelherodev> Never mind, quick search found it in the docs
<pixelherodev> Really need to learn to ask *after* looking thoroughly :P
<emekankurumeh[m]> "found it in the docs" now that's what i like to hear...
<pixelherodev> Is there a compiler option to only build an object file instead of build-exe? Can't find anything useful in the output of `zig --help`
<emekankurumeh[m]> build-obj
<pixelherodev> ... because I was glancing right over it. Sorry!
<pixelherodev> Thanks
<pixelherodev> I was looking under compiler options instead of commands :P
<pixelherodev> What's the correct way to build multiple object files into one binary?
<pixelherodev> The --help output says "source or output *files*", not file, but with multiple files it errors out
ky1ko has quit [Remote host closed the connection]
ky1ko has joined #zig
<pixelherodev> ... eh, think I found a hacky way to do it
mahmudov has joined #zig
<daurnimator> pixelherodev: build-exe and build-lib should take in object files
<pixelherodev> One file yes; if two are passed it says "extra option received blah blah"
<pixelherodev> So in the Makefile, I set `zig build-exe $(OBJ:%=--object %) --linker-script src/linker.ld -target i386-freestanding --output-dir bin --name $(@:bin/%=%)` as the full command line
<pixelherodev> Relevant portion: `$(OBJ:%=--object %)`. For each object file, passed `--object FILE`
<daurnimator> pixelherodev: o.o makefile :P
<daurnimator> pixelherodev: here in zig land we use build.zig ;)
<pixelherodev> Well yeah, it's currently easier than trying to figure out build.zig for a freestanding target from the relatively poor docs
<pixelherodev> A lot of things are well-documented in zig, the build system isn't one of them at the moment AFAICT
<pixelherodev> It's also noticeably faster ATM
<daurnimator> pixelherodev: I think you just call setTarget with freestanding
<pixelherodev> Except setTarget is deprecated ;)
<daurnimator> pixelherodev: heh. docs for the whole standard library only came into existence last week
<pixelherodev> Does the standard library have anything like sprintf?
<pixelherodev> Wait, better question: where are the new standard library docs?
<pixelherodev> They're still not linked from the rest of the documentation
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<daurnimator> pixelherodev: std.fmt.bufPrint I think
<daurnimator> pixelherodev: there's also std.fmt.allocPrint if you want it to allocate memory for you
<pixelherodev> Yeah, allocPrint isn't an option yet - I haven't implemented the heap yet :P
<pixelherodev> Thanks for the links!
<pixelherodev> What's the context and Errors args for std.fmt.format?
<pixelherodev> s/'s/ are/
<daurnimator> pixelherodev: your `output` callback is called with `context`. your callback is only allowed to throw the errors you pass as allowed.
<pixelherodev> Ahh thanks!
<daurnimator> pixelherodev: you don't need to implement a heap btw.... you can pass a stack allocator...
<daurnimator> pixelherodev: e.g. see std.heap.FixedBufferAllocator
<daurnimator> though at that point you might as well use bufPrint
<pixelherodev> Which is why I didn't want to do it :)
<pixelherodev> I think it'd be better to just implement a print function over std.fmt.format using an output function that dumps to the terminal
<pixelherodev> If I want to leave context and errors blank, what's the best option? 0 for context and anyerror as error set?
<daurnimator> pixelherodev: that's essentially what std.debug.warn does
<daurnimator> pixelherodev: note that outStream objects have a print() method that uses std.fmt
<daurnimator> pixelherodev: void for context and the empty error set `error{}` for the error.
<nrdmn> pixelherodev: i386-freestanding? what are you working on?
<pixelherodev> An emulator-as-a-kernel :)
<nrdmn> what are you emulating?
<pixelherodev> It's a completely custom system - custom ISA, custom bus, etc
<nrdmn> sounds interesting
<pixelherodev> daurnimator, with "void" as context I get the error "parameter of type 'type' requires comptime"
<daurnimator> pixelherodev: void is the type. you need a value of type void. I think you get one with: `void{}`
<pixelherodev> Ahhh, thanks :P
<pixelherodev> Yeah that works
<nrdmn> daurnimator: is `void{}` special void syntax? or does this work with all 0-sized types?
<daurnimator> nrdmn: imagine that void is `struct{}`. `struct {}{}` is valid.
<nrdmn> hmm, so void{} and struct{}{} seem to work, but not i0{}, type{}, or @OpaqueType(){}
<nrdmn> also no c_void{}
<daurnimator> nrdmn: well you can't instantiate an opaque type, so that one makes sense
<daurnimator> nrdmn: then for some reason the syntax for integers is parenthesis instead: `i0(0)` should work I think?
<pixelherodev> Thanks for the help, I've got a working printf now!
<daurnimator> nrdmn: likewise you can't instantiate a type, so that one makes sense
<daurnimator> c_void{} makes less sense...
<pixelherodev> If I have an arbitrary `[*]const u8`, how can I force it to be treated as a string for the purposes of printing it? Format is automatically converting it to `u8@ADDRESS` instead of printing the string at that address...
<pixelherodev> Does it need to be a slice?
<pixelherodev> Yeah, got it
<pixelherodev> Just had to implement a simple strlen(), and do str[0..strlen(str)]
<nrdmn> daurnimator: yes you can instantiate a type
<nrdmn> "type" is an instance of the type type
<mq32> pixelherodev, the function should already exist in std.mem
<nrdmn> pixelherodev: use {s} instead of {} to print c strings
<nrdmn> then you won't need to iterate over the string once to determine the length and once to print it
<pixelherodev> huh. Thanks!
<nrdmn> daurnimator: and all other types are also instances of type
<daurnimator> pixelherodev: also strlen is pronounced `std.mem.len(u8, ptr)` in zig
<nrdmn> you can even have pointers of type :D
<pixelherodev> Good to know
<daurnimator> pixelherodev: also see std.mem.toSliceConst
<pixelherodev> What's the difference between toSliceConst and toSlice with a const type?
<daurnimator> pixelherodev: arguments are *always* const
<daurnimator> pixelherodev: `const sometype` is not a type.
<daurnimator> pixelherodev: `[]const sometype` is
<pixelherodev> That's what I meant
<pixelherodev> Ahhh, I get it now I think
<daurnimator> pixelherodev: you can't do: `toSlice(const sometype, myptr)`
<pixelherodev> Okay then, why is toSliceConst needed if you can just do `varname : []const u8 = toSlice`?
<daurnimator> pixelherodev: because you can't pass a slice of consts to toSlice: it'll error
<daurnimator> though.... now you've got me thinking. why *isn't* `const sometype` a valid type?
<pixelherodev> Ohh right, that's obvious in retrospect
<daurnimator> Did we just stumble upon a solution to ?
* pixelherodev shrugs
cheesy has quit [Ping timeout: 268 seconds]
slice has joined #zig
<bgiannan> So say i'd like to know exactly which error can occur here, how can i get the compiler to list them ? <- it will just tell me that i need to handle `@typeOf(std.array_list.AlignedArrayList(u32,null).append).ReturnType.ErrorSet` which is not really helpful
<Snektron> yeah ive noticed error messages about error sets are less than ideal
<Snektron> ideally they should be listed out until the first error alias
<Snektron> daurnimator: Wouldn't that get confusing with const variables?
<Snektron> i thing `const i: const u32 = 10` is kind weird
<Snektron> what would it even mean to write `var i: const u32 = 10;`
<Snektron> and what about internal mutability or other moments when you want to have one field const but not another
Foxfir3 has quit [Remote host closed the connection]
Ichorio has joined #zig
porky11 has joined #zig
meheleventyone has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev> ... well this is odd. `const begin1 = mmap.addr;` is causing a boot loop :(
<pixelherodev> mmap is a *definitely valid* pointer; addr is a u64
mahmudov has quit [Ping timeout: 265 seconds]
<pixelherodev> If I cast it to u32, everything's fine.
<nrdmn> you mean the assignment causes a boot loop?
<pixelherodev> Apparently.
<pixelherodev> Commenting it out, everything's fine; uncommenting it puts it right back to boot looping
<pixelherodev> Not just that one line - basically anything involving u64s seems to cause problems for some reason
<pixelherodev> I sincerely hope this is something stupid I did and not e.g. a compiler bug, but I'm blanking on what I could possibly have done to cause *this*
<pixelherodev> `const begin1 = @intCast(u32, mmap.addr);` is fine, `const begin1 = @intCast(u64, mmap.addr);` boot loops.
<nrdmn> did you try explicitly specifying the alignment?
<pixelherodev> Nope
<nrdmn> this should not be necessary but I think I've had a similar issue
<nrdmn> `const begin1 align(8) = mmap.addr;`
<mq32> pixelherodev you're writing bare metal code for x86_64?
<pixelherodev> x86, not x64
<pixelherodev> nrdmn, doesn't help
<mq32> so target i386?
<pixelherodev> i386-freestanding, yes
<mq32> probably it's a codegen bug that tries to use an x86_64 instruction without having long-mode activated?
<pixelherodev> If I'd already set up the IDT and set up fault handlers, it'd be easy to test that :P
<pixelherodev> Fortunately, I can just inspect the assembly
<pixelherodev> Or not
<pixelherodev> On a whim, I tried casting to u128, and that worked fine
<nrdmn> why don't you try x86_64-uefi-msvc? ;) Your firmware'll drop you off right into long mode
<pixelherodev> Because that's not my target.
<mq32> what do you want to achieve?
<pixelherodev> Literally it's just meant to be an alias
<pixelherodev> I noticed some broken firmwares report the same region of memory multiple times, so I'm basically doing an AABB box check to see if the two regions overlap
<pixelherodev> Even more interestingly, if cast to u63 or u65, it's fine
<pixelherodev> It's only when it's *exactly* u64 that it fails
<pixelherodev> Given I don't plan on using PAE, I can probably just force everything to 32-bit and ignore the problem
<nrdmn> have you tried debugging it with gdb?
<pixelherodev> I didn't exactly hook up a GDB stub yet
<nrdmn> qemu has gdb support
<pixelherodev> ... yes, but that doesn't help if the kernel doesn't support it...
<mq32> pixelherodev: it does
<mq32> you can hook GDB to your VM CPU, not to the program running in the VM
<mq32> so you get every crash, you can do breakpoints on any point in the kernel
<nrdmn> start qemu with `-s -S` and attach gdb with `target remote localhost:1234`
<pixelherodev> Whelp, not important right now anyways - the block it was checking was reserved anyways; if only available blocks are tested, the issue never comes up :P
<pixelherodev> This is definitely the best way to deal with issues. Definitely.
<mq32> is someone firm with socket programming in linux?
<mq32> i want multiple "listeners" on the same computer that can receive broadcasts
<mq32> ah, just ignore me, i should send to the broadcast address if i want to receive broadcasts :D
Demos[m] has quit [*.net *.split]
dom96 has quit [Ping timeout: 240 seconds]
Demos[m] has joined #zig
dom96 has joined #zig
mahmudov has joined #zig
<daurnimator> mq32: SO_BROADCAST
<mq32> daurnimator, yeah i got that already
<mq32> but interestingly if i don't send to broadcast, a single socket will receive the message, not all
<daurnimator> mq32: how did you set up the listening sockets?
<daurnimator> mq32: did you use REUSEADDR/REUSEPORT?
<mq32> bind to
<daurnimator> mq32: have you come across yet? that might help
<mq32> daurnimator: nc -ub portnum and go for it :D
mouseghost has joined #zig
<mouseghost> hi, so 1. are there usable sockets already? ive seen something in; 2. if not, then can i use C interop through mingw on windows?
<mq32> mouseghost, you can use posix sockets via std.os.socket
<mq32> and yes, you should be able to use winsock2 via mingw
<mq32> and libc linking
<mouseghost> mq32, i mean, i'd rather use socket.h than winsock2
<mq32> you will use winsock on windows anyways
<daurnimator> mq32: huh?
<mouseghost> mq32, idk how to read that docs
<daurnimator> mq32: my intention (one day... expect a year from now...) is to avoid winsock on windows and use raw AFD instead
<mq32> daurnimator, afaik there's no way around winsock as it's the official socket API
<mq32> oh yeah, there was AFD
<daurnimator> mq32: winsock is essentially microsoft's userland wrapper around AFD. but they made some bad API decisions 20 years ago that we'd love to avoid having to deal with
<mq32> is there documentation on AFD?
<mq32> hm
<mq32> this is gonna be crazy :D
<mouseghost> i dont know why but theres pub fn socket but it doesnt exist in the docs?
<mq32> i'm writing a udp protocol that has no "receiver" :D
<mq32> mouseghost, don't rely on docs yet
<mouseghost> :(
<mq32> any function that is not tested (or referenced) isn't in the docs
<daurnimator> mq32: no. AFD is knowledge is mostly passed around in whispiers
<mq32> oh, sad
<mouseghost> mq32, i would take winsock but i dont know how to use it
<mq32> there's plenty of documentation
<mq32> also it resembles posix sockets a bit
<mouseghost> im scared of it
<mq32> of what? documentation?
<mq32> MSDN is quite good :)
<mouseghost> especially of msdn
<mq32> why?
<mouseghost> i mean, i dont know how to read it really and it just seems a little bit weird to me
<mq32> start here
<mq32> there's even a full socket example
<mouseghost> but theres WSA added on the front of everything
<daurnimator> mouseghost: std.os should have most of the socket functions you need
<daurnimator> mouseghost: however there is not much documentation.
<mouseghost> i think i can manage
<mouseghost> somehow
<mouseghost> tho idk where do i find the things like AF_INET and all
<mq32> should be in std.os
<mouseghost> well, regardless, can i somehow interop with headers from mingw on windows to compile on windows?
<mq32> i don't think you need mingw at all, if you use musl
<mq32> but: i'm not a windows expert when it comes to zig
<mouseghost> im not sure if musl compiles to windows
<daurnimator> mq32: musl shouldn't work on windows...
<mq32> huh okay?
<mq32> ah, zig provides only glibc x86_64-windows-gnu
<mouseghost> then i mean, i dont know how to i get to this sys/socket.h really, cause i suppose i would have to add -isystem <dir where i keep my headers from mingw> buuut then types break
TheLemonMan has joined #zig
Akuli has joined #zig
<TheLemonMan> daurnimator, how's #3080 going?
marmotini_ has joined #zig
donaldallen has joined #zig
<donaldallen> I would like to build an application with multiple source files, with some calling among them. Vanilla stuff. I can @import callees into callers, but that involves compiling every callee each time I compile a caller. So I tried doing this C-style, where each of the files is compiled independently.
<donaldallen> I'm running into an issue that makes me wonder whether zig objects can be passed among such functions. Specifically, I got this error: /home/dca/Software/newcash_zig/composite_register/composite_register.zig:13:64: error: return type '[]u8' not allowed in function with calling convention 'ccc'extern fn guid_to_path(db: *c_void, account_guid:
<donaldallen> [*]const u8) []u8; ^/home/dca/Software/newcash_zig/composite_register/composite_register.zig:94:45: note: referenced here const split_account_full_path = guid_to_path(db, split_guid);
<donaldallen> Sorry about the formatting.
<donaldallen> Can anyone enlighten me about this? Does calling out to an extern-ed function presume that the callee is written in C?
<pixelherodev> C functions can't use slices IIUC
<pixelherodev> So a C function can't return a value of type `[]u8`
<pixelherodev> What you want is probably `[*]u8`
<pixelherodev> A pointer to an unknown number of u8s
<donaldallen> But the called function is not written in C. It's written in zig. The two modules are compiled independently to produce .o files and I want to call from one to the other.
<fengb> extern adheres to C ABI
<fengb> Zig standard is just import everything by source, and the build system caches individual object files
<donaldallen> @fengb So my supposition that calling an extern-ed function is assumed to be C-like is correct.
<fengb> Yep
<donaldallen> Using the build system is a bit dicey at the moment, given the state of the documentation last time I looked. But knowing that it eliminates unnecessary recompilation is very helpful. I'll revert to using @import for this. Thanks for the help.
<fengb> zig build is in flux but the cli commands have been pretty stable (zig build-exe or zig build-lib)
<pixelherodev> Which is why I went with Makefile using those :)
<Snektron> donalddallen: @import is different from build.zig, and i don't think theres really anything wrong with it
marmotini has joined #zig
<Snektron> build.zig can be a bit slow, but i usually just copy one from another project
<mq32> Snektron, donaldallen: @import and build.zig don't compete for the same job.
<Snektron> The system is not that complicated
<mq32> you don't need a build.zig for simple projects (most projects could probably live with a zig build-exe all the way)
<mq32> but build.zig allows to specify more complicated cased of the build (like packaging, installation, pre- and post-pocessing and such stuff)
<Snektron> There was talk of a custom compilation backend a while back which doesn't depend on llvm, i suppose that could be useful for build.zig
marmotini_ has quit [Ping timeout: 240 seconds]
<donaldallen> Snektron -- you are missing my point. I am trying to eliminate unnecessary recompilation. I tried to do it C-style with a makefile and separate compilations to produce a bunch of .o-s to be linked. That doesn't work because cross-module calls are restricted to C objects. But fengb mentioned that the build system does what I want -- caches object
<donaldallen> files to avoid recompiling unchanged files (I presume). This allows me to revert to using @import, because I can assume the build system will take care of this problem.
<pixelherodev> "cross-module calls are restricted to C objects." - actually, I have multiple .o files calling into each other
<pixelherodev> If you have a function declared `pub fn` and it's imported from the other module, you can use it normally
<donaldallen> pixelherodev -- that's certainly possible. What appears not to be possible is passing zig objects, e.g., slices, among them.
<pixelherodev> It is - i'm doing it
<pixelherodev> I have a `pub fn printf(comptime fmt: []const u8, args: ...) void` function in one module
<pixelherodev> Then in the other, it's just `@import("terminal.zig").printf("Example number: {d}", u8(3));`
<pixelherodev> (though I don't actually do one-liners; those are to not clog the IRC chat)
<donaldallen> Ah, so maybe my error was externing the target function, rather than just making it pub in target module.
<donaldallen> Thanks -- I'll give that a try.
<pixelherodev> No problem
<pixelherodev> On a different note, I ported the stack trace dumping from ClashOS to mine, but apparently `std.debug.openDwarfDebugInfo(&S.self_debug_info, kernel_panic_allocator);` causes a boot loop
<pixelherodev> Anyone here have more experience with freestanding zig able to lend a hand?
<TheLemonMan> maybe, can you trace exactly where it hangs?
<pixelherodev> Maybe. My next idea was to insert `while(true){}` in the std.debug function and track it down more precisely, but I figured I'd ask first and see if anyone else had run into this
<pixelherodev> Given that it's running from an ELF file, it'd be neat if I could just use *that*, but the ELF file itself isn't actually in memory
<TheLemonMan> my crystal ball is out of order at the moment heh
mps has left #zig [#zig]
<TheLemonMan> yeah you just need the few debug_* sections, not the whole image
<pixelherodev> True, but it would still be easier - I could just pass in the address of the file and let the library handle the rest
<pixelherodev> Okay, so the problem is somewhere in scanAllFunctions...
<pixelherodev> I'm going to guess right now that something's wrong and the sections aren't being included properly or something like that :(
<TheLemonMan> another possibility is that I introduced some bug when I wrote than function :)
<pixelherodev> Any suggestions how to at least confirm the integrity of the data sections?
<TheLemonMan> eyeball them with readelf + objdump --dwarf
<pixelherodev> hmm, `objdump -dwarf` sure makes it look like there's valid stuff there
marmotini_ has joined #zig
<TheLemonMan> is it stuck in the outer loop or the inner one?
<pixelherodev> `readelf: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_loc section.` Hmm.
<pixelherodev> But in the linker script there's definitely `KEEP(*(.debug_info))`
<TheLemonMan> does it appear in readelf -S ?
<pixelherodev> No!
marmotini has quit [Ping timeout: 240 seconds]
<donaldallen> pixelherodev Works great. Thanks again.
<pixelherodev> donaldallen, no problem!
<TheLemonMan> oh well, no debug_info no party
<pixelherodev> Yeah - hey wait, *none* of those are there
<pixelherodev> Oh wait
<pixelherodev> I don't know that they should be
marmotini has joined #zig
<pixelherodev> I think they're all merged into .rodata
<TheLemonMan> that's fine (a bit weird but fine) as long as you export the start/end markers
<pixelherodev> Yep
<pixelherodev> ".debug_info = dwarfSectionFromSymbol(&__debug_info_start, &__debug_info_end),"
marmotini_ has quit [Ping timeout: 240 seconds]
<pixelherodev> Then in the linker script there's e.g. ` __debug_info_start = .;`
<pixelherodev> I don't know the DWARF format, is there a convenient string I can read to test that it's there?
<TheLemonMan> cool, then forget about dwarfdump
<pixelherodev> ?
<TheLemonMan> you should see a few strings from the debug_str section
<pixelherodev> Yeah, I think I see them in `readelf -p .rodata`
<TheLemonMan> also, make sure your __debug_info_start,__debug_info_end are correctly pointing to the beginning/end of the data
<TheLemonMan> if you have a small reproducer I can have a look for you
<pixelherodev> might be relevant also, but the rest almost certainly isn't
<donaldallen> pixelherodev I can see you are in the middle of something else, but thought I'd mention this: you said you @import your target .zig file (terminal.zig). How do you know that file is not being recompiled when the calling file is compiled? I just tried renaming the target src file, leaving only the previously compiled .o and now the calling module
<donaldallen> won't compile, because it can't find the src file. @import-ing the .o also doesn't work. So while using your approach produces an executable without error, I am now realizing that I don't know that the imported file wasn't recompiled.
<pixelherodev> Not 100% certain? I'm largely recompiling everything anyways because it's fast enough and I've had files not get updated properly with changes
<pixelherodev> TheLemonMan, I think this is actually related to the bug I reported earlier (with u64s causing crashes)
<pixelherodev> The exact line causing the problem is ` var this_unit_offset = di.debug_info.offset;`
<pixelherodev> Line 2074 of std/debug.zig if my copy of the standard library is up to date
<pixelherodev> Now that I think about it, why do these functions use u64 instead of usize for pointers?
<TheLemonMan> because then you couldn't parse an ELF64 on a 32 bit system
<pixelherodev> Ah
<pixelherodev> The real question is why does using u64s cause a boot loop?
<pixelherodev> It's not calling panic, it's *crashing*
<TheLemonMan> hm? I get an OutOfMemory error
<pixelherodev> Running the repo I linked?
<TheLemonMan> yep
<pixelherodev> That's...
<pixelherodev> What Zig version (commit)?
<pixelherodev> Maybe mine is out of date?
<TheLemonMan> head
<pixelherodev> Alrighty, I'll try that
<pixelherodev> If you up the memory on the panic_allocator, does it work?
<TheLemonMan> maybe, it didn't crash yet
<pixelherodev> Oh wait - there might be a while(true){} still in there ;P
<pixelherodev> Yep
marmotini has quit [Remote host closed the connection]
<pixelherodev> That means it's probably working
marmotini has joined #zig
<TheLemonMan> where's the while?
<pixelherodev> Give me one sec to push a change; I never finished implementing panic() because I was trying to diagnose the issue
marmotini has quit [Remote host closed the connection]
<TheLemonMan> oh cool, I was trying to figure out where the rest of the code went
marmotini has joined #zig
<nrdmn> TheLemonMan: in #3445 you said zig is now buildable with llvm 10. What do you mean by that, what's the current status? Because I'm still getting complaints from my compiler
<TheLemonMan> nrdmn, everything's working as intended, I'm using it as daily driver
<TheLemonMan> I'm syncing my changes with the LLVM's APT repo updates to the toolchain snapshots tho
<scientes> but why?
<scientes> what does llvm 10 offer
<pixelherodev> Hmm... even with zig at HEAD, it still doesn't work
<scientes> just use llvm 9 for another few months
<TheLemonMan> pixelherodev, yeah it's LLVM10 that fixed the bug you're experiencing :)
<pixelherodev> ....dammit
<pixelherodev> It already took like eight hours to build LLVM 9 :(
<pixelherodev> Oh well
<TheLemonMan> scientes, see ;)
<pixelherodev> Thanks for the tip
<scientes> oh yeah, and we have that unified build think in cmake now
<scientes> so it builds just like clang does
<scientes> pixelherodev, but why build llvm 9, just download a binary
<TheLemonMan> if you manage to find the commit that fixed that problem you can ask the devs to backport it into 9.0.1
<pixelherodev> scientes, I'm running Gentoo ;)
<scientes> yes, please do a git bisect
<TheLemonMan> but good luck bisecting LLVM
* pixelherodev shudders in fear
<scientes> its not hard
donaldallen has left #zig [#zig]
<TheLemonMan> the only hard thing is watching the RAM usage raise way above the 12GB mark
<scientes> gentoo is a circle, you use gentoo to try to make your computer faster (doesn't work), then you need a faster computer to build gentoo
<nrdmn> >you use gentoo to try to make your computer faster
<nrdmn> wrong
<scientes> nah, you only need 4GB if you use the right configuration
<pixelherodev> I don't use it to make my computer faster
<pixelherodev> I use it because I like it
<TheLemonMan> even with tblgen + shared libs + as linker it takes too much RAM
<scientes> TheLemonMan, you have to turn off parallel links
<scientes> then you only need 4GB
<pixelherodev> TheLemonMan, shared libs often take MORE RAM, not less
<TheLemonMan> pixelherodev, you don't have to link the whole llvm amalgamation
<TheLemonMan> even with a single link job it uses more than 4GB
<pixelherodev> Fortunately, I have 8GB :)
<scientes> TheLemonMan, oh your are using gold
<scientes> lld is better
<scientes> gold is also largely abandoned
<scientes> pixelherodev, ^
<pixelherodev> Well, I'm going to just fire up something to do while this compiles
<pixelherodev> XKCD 303, always relevant
<scientes> pixelherodev, but it isn't your code
<pixelherodev> Still counts :)
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 264 seconds]
<TheLemonMan> pixelherodev, sorry about that, the real problem is a change I've recently committed
<TheLemonMan> using LLVM10 somehow didn't trigger it, nice
<nrdmn> building zig with llvm 10 still breaks in various places for me
<nrdmn> there are still many references to llvm::make_unique in deps/
<TheLemonMan> pixelherodev, the workaround is sticking "-sse" here
<nrdmn> deps/lld/COFF/PDB.cpp includes llvm/Support/JamCRC.h, which doesn't exist in my build of llvm 10
<TheLemonMan> nrdmn, yeah I'm using -DZIG_FORCE_EXTERNAL_LLD=ON, don't care about the local lld copy
<TheLemonMan> afair all the patches have been upstreamed and a vanilla copy should be fine
<nrdmn> ah, okay
<nrdmn> so we won't need deps/lld in the future?
<TheLemonMan> gotta ask andrewrk when he's back for an offical answer
<pixelherodev> Wait, it was geenerating SSE instructions? Huh
<TheLemonMan> yep
<TheLemonMan> ideally i386 -> no SSE but good luck running the test suite, i686 -> use SSE and avoid all the x87 madness
<TheLemonMan> it's not even just x87 doing x87 things, sometimes LLVM also legalizes some ops on f16 by extending them to f32 and then forgetting to turn them back to f16
<scientes> heh
<pixelherodev> So... mostly fine then? :P
<pixelherodev> Yeah, OOM now
<pixelherodev> If I up the available RAM to 4MB, it instead panics *within the panic* :(
<pixelherodev> "reached unreachable code"
<TheLemonMan> I don't even get the OOM with the latest code you've uploaded
<pixelherodev> At least now it's able to open the Dwarf w/o issue
<pixelherodev> It panicks *after* that at some point, not 100% sure where
<pixelherodev> Can't get a backtrace if the backtracer is panicking :P
<nrdmn> hmm, so gentoo's lld ebuild doesn't install header files :/
<pixelherodev> Now it's making it all the way to std.debug.printSourceAtAddressDwarf! Yay!
<pixelherodev> Assert failing, yay. 'assert(line_info_offset < di.debug_line.size);' which means data is probably wrong.
<pixelherodev> Probably.
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 265 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 268 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 265 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 264 seconds]
doublex has quit [Ping timeout: 250 seconds]
<gruebite> where can i find the .h file from exporting functions?
<mq32> gruebite, there is none. you have to write it yourself
<mq32> but afaik there were plans on auto-creating headers
<gruebite> ahh, but this example has "include "mathtest.h""
<gruebite> so i assume it's just on the fly .h? no real file
lunamn has joined #zig
<nrdmn> I think I've seen autogenerated .h files?
<nrdmn> gruebite: have you searched the zig-cache directory?
<gruebite> i have, the h/ dir has a bunch of .txt files
lunamn_ has quit [Ping timeout: 268 seconds]
<pixelherodev> Autocreated headers already exist I think
<gruebite> i do not think they appear in zig-cache though
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 240 seconds]
knebulae has quit [Quit: Leaving]
knebulae has joined #zig
Akuli has quit [Quit: Leaving]
<pixelherodev> In spite of all the trouble I've been having today, Zig has managed to do what I thought was impossible and knock C down from its position as my #1 favorite language
<mouseghost> tell more :e
doublex has joined #zig
diltsman has joined #zig
<diltsman> Probably a stupid question. Why doesn't the standard library @cImport Windows.h? I assume it has something to do with vendor specific extensions.
<pixelherodev> Well, for starters, 99% of use cases aren't going to be Windows.
<pixelherodev> That's like asking Why not @cImport pulse/pulseaudio.h
<diltsman> That is fair. Does conditional compilation cover the @cImport statements?
<pixelherodev> Or openGL, or any other library
<pixelherodev> I think so
<diltsman> The particular case in the standard library is the allocator. They explicitly declare the Win32 functions instead of using a @cImport. Of course, Windows.h includes everything but the kitchen sink.
<pixelherodev> Yeah, even with WIN32_LEAN_AND_MEAN or whatever it's still bloated as hell
<pixelherodev> What I started to mention earlier: in less than a day, I feel like I've gotten a thorough understanding of at least 60% of the language, possibly a bit more. I've been using C for years and I only learned yesterday that there are intfast_t types
<pixelherodev> Zig is just plain awesome
<diltsman> intfast_t is nice. I generally use uint_t, as memory usage is much more important in my field than the possible speed.
<pixelherodev> ... anyone know if LLVM supports the XTensa ISA? I'm suddenly tempted to use Zig for work on a project that's currently C with a dash of evil (aka C++)
<mq32> pixelherodev, not officially, but there is an xtensa llvm port by espressif
porky11 has quit [Ping timeout: 245 seconds]
<pixelherodev> Does it actually work?
<mq32> i never tried it
<mq32> but afaik they are in the process of including it into mainline LLVM
<pixelherodev> Is it possible to build Zig against that? If I do, would I have to manually extend Zig to support that target?
<mq32> i don't know, that's a question a zig dev should answer
<nrdmn> you'd probably be the first one to use zig on xtensa
<gruebite> yep, i thoroughly enjoy zig
<scientes> <TheLemonMan> nrdmn, yeah I'm using -DZIG_FORCE_EXTERNAL_LLD=ON, don't care
<scientes> that would also speed up my builds
<nrdmn> unfortunately gentoo's lld doesn't come with header files. Not sure what to do about that.
<scientes> ahh, same problem with debian
<scientes> you can check out llvm-project git
<mq32> can someone help mit with this error:
<mq32> usingnamespace @cImport({
<mq32> /tmp/hacks/src/c.zig:1:16: error: C import failed
<mq32> (welp, i should prefix paths with /say)
<scientes> mq32, why are you working in /tmp ?
<scientes> that isn't really kosher
<mq32> "i just wanted to try something"
<mq32> if it works, it will be moved to ~/projects
<scientes> oh ok
<scientes> fair enough
<mq32> if not, it will be gone after the next reboot and will not clobber my disk
<scientes> my projects folder is full of random stuff
<scientes> so much that i hvae to use two letters for tests now
<mq32> [felix@denkplatte ~]$ ls projects/ | wc -l
<mq32> 297
<mq32> should i feel ashamed? :D
<nrdmn> impressive :D
<mq32> nrdmn, yeah. i can now say: i started 300 projects and finished 3!
<torque> I've been interested in using zig on xtensa as well (doing a lot of work with esp32) but last I looked, the xtensa llvm port seemed to be very immature
ltriant has joined #zig
<torque> I ended up writing a pile of nasty c macros that sort of emulate zig's error mechanism which has actually been quite helpful
<mq32> can i somehow prevent zig from providing a windows.h?
<mq32> the one coming with glibc seems to create a broken cimport.zig
dingenskirchen has quit [Excess Flood]
dingenskirchen has joined #zig
<diltsman> On a @cImport, how do you find the set of symbols that it found?
<mq32> there's a cimport.zig in zig-cache
<diltsman> I don't see that. Do I need anything other than this: const c = @cImport({@cInclude("Windows.h");});
<mq32> yeah, you need to link libc
<mq32> otherwise @cImport will not work
<mq32> which is a kinda weird requirement
<diltsman> Is that in build.zig?
<mq32> if you use build.zig, then yes
<mq32> exe.linkSystemLibrary("c");
<mq32> does anyone know how to add custom def files?
<mq32> ah damn. i should go to sleep
<diltsman> mg32, still not seeing it.
marmotini has quit [Quit: Leaving]
<diltsman> mq32 still not seeing it.
<Snektron> <pixelherodev> ... I've been using C for years and I only learned yesterday that there are intfast_t types
<Snektron> i learned today that `int python(int a[*]);` is valid syntax
<Snektron> and `int python(int n, int a[n]) {}`
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<nrdmn> what, C has dependent types?
<Snektron> No in the last example a is a VLA
<Snektron> but since its a parameter its basically just an unknown length array
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<Snektron> the first one presumably is for people who like to write their function declarations without parameter names
<Snektron> I know someone who does that, but i dont know why
<Snektron> `int python(int a[static 10]);` is also valid, it means a needs to have at least 10 elements
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
SimonNa has joined #zig
noonien has joined #zig
mahmudov has quit [Remote host closed the connection]
<gruebite> can i resize an array dynamically? i see a lot of code passing static arrays with some arbitrary buffer size. what's the standard library's strategy for avoiding buffer overflow?
Ichorio has quit [Ping timeout: 245 seconds]
mouseghost has quit [Quit: mew wew]
protty has joined #zig
<protty> Hey, does anyone know how to run system commands for a build step? Trying to generate docs in zig-cache and move them to the root directory and using "mv" via `b.addSystemCommand` doesnt seem to work.
<Snektron> did you add the step after?
<protty> yea, added it to default_step to make sure it was being executed. Getting a "InvalidName" error
<Snektron> I like Zig but man
<Snektron> "broken LLVM module found" when trying to return a !u32 from a function returning !?32 is less than ideal
<gruebite> Snektron: code?
<diltsman> Windows SDK header files are in one of the subdirectories in C:\Program Files (x86)\Windows Kits\10\Include. Is there a way to determine how many there are and start parsing the directory names?