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>
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
<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]
<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
<bgiannan>
So say i'd like to know exactly which error can occur here, how can i get the compiler to list them ? https://0x0.st/zxBk.zig <- 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*
<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>
daurnimator: nc -ub 255.255.255.255 portnum and go for it :D
mouseghost has joined #zig
<mouseghost>
hi, so 1. are there usable sockets already? ive seen something in std.net; 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
<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>
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
<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 + ld.gold 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/
<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
<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?