<hryx>
thanks for sharing that hoppetosse. I ran into a strikingly similar situation with branch quota for a static audio buffer and never went back to solve it
<hoppetosse>
hryx cheers =)
<hryx>
I'm back from travelling and excited to get back to work. First funny bug (of mine) of the night was another example where an ultra-safe Debug mode would be so amazing
<hryx>
An undefined struct field led to self-referential AST node, which for a while I thought was due to a logical bug: https://hastebin.com/raw/owemajikiw
<hryx>
I assume the undefined 0xAAAA took on a meaningful value?
<hryx>
I'd made some bogus assumptions about arena_allocator then tyler caught it
<hryx>
interesting
<daurnimator>
essentially: an arena allocator can't be copied, it can only be *moved*: if you make a copy of it, the old one shouldn't be used again
hio has joined #zig
jevinski_ has joined #zig
jevinskie has quit [Ping timeout: 248 seconds]
jevinskie has joined #zig
jevinski_ has quit [Ping timeout: 252 seconds]
scientes has quit [Ping timeout: 252 seconds]
xbat has quit [Remote host closed the connection]
<daurnimator>
Anyone made a circular buffer structure yet?
<daurnimator>
emekankurumeh[m]: ^ did you have any more thoughts about the command buffer pattern
<daurnimator>
I just noticed the 5.1 linux kernel was released; finally including io_uring. So now I have a running kernel implementation to code against
<daurnimator>
andrewrk: ^ expect syscalls added to zig soon :)
<shachaf>
whoa, Linux is getting a async I/O interface?
<emekankurumeh[m]>
daurnimator: by circular buffers, do you mean ring buffers?
<daurnimator>
shachaf: yep. and lots more syscalls are expected to be added soon
<shachaf>
I implemented one in C the other day, does that count?
<emekankurumeh[m]>
what i'm excited for is gcc9
<daurnimator>
emekankurumeh[m]: could you send that as a PR to the standard lib?
<daurnimator>
emekankurumeh[m]: ehhhh gcc9 breaks several libs I use
<emekankurumeh[m]>
it adds support for -fuse-ld=lld and lld is several times faster than the default linker that comes with mingw, which hopefully should speed up my 10+ minute link times
<emekankurumeh[m]>
i'll have to clean it up a bit before opening a pull request
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgschultz has quit [Ping timeout: 252 seconds]
<rivten>
Hello everybody ! I hope you are doing ok :) Quick question : I can't seem to be able to do : "const windows_utils = @import("std/os/windows/util.zig");" when I want to use some function in the util file. The compiler seems unable to find the file. What am I doing wrong ?
<very-mediocre>
that would work if you had a copy of the stdlib and the path you were importing was valid
<very-mediocre>
otherwise what you probably want is `const windows = @import("std").os.windows;`
<very-mediocre>
not sure if utils is exposed actually, let's see...
<very-mediocre>
apparently not
<rivten>
nope doesn't really seem like it :( my other solution would be to just copy pase the code I want to use in my file... maybe i'll do that just to go quickly about it
<very-mediocre>
you could keep a copy of the stdlib and import the file directly that way
<rivten>
yes maybe i'll do that. Thanks for the help :) :)
tgschultz has joined #zig
DutchGh0st has joined #zig
<DutchGh0st>
can I switch on a []const u8 ?
<DutchGh0st>
because, sure, I can write a quazillion `if (mem.eql(u8, ..., ...)) { // whatever}` , but just a simple switch would be nice
<tgschultz>
No, but if it's a comptime known string you might be able to switch on the .ptr value.
<DutchGh0st>
its comptime known, yes
<DutchGh0st>
basically I have checkedInt struct, which takes a hook. The checkInt has a few methods, like opUnary(*self, comptime op: []const u8, rhs: var). Inside there I check what operation is being done
<DutchGh0st>
soo with opUnary, it can only be "++" or "--"
<DutchGh0st>
but with opAssign, it can be "+=", "-=", "*=", "/=", "^=", "<<=", ">>=", what have you
<DutchGh0st>
kek, there's no divWithOverflow. Guess it cant overflow then
<DutchGh0st>
only devide by 0 :3
<DutchGh0st>
huh
<DutchGh0st>
there is @shlWithOverflow
<DutchGh0st>
but not @shrWithOverflow
scientes has joined #zig
rivten has quit [Quit: Page closed]
rivten has joined #zig
shritesh has joined #zig
hg has joined #zig
slugm has quit [Remote host closed the connection]
<rivten>
hello again ! I think I found something pretty weird. In here : https://github.com/ziglang/zig/blob/master/std/dynamic_library.zig#L197 lookup takes a Zig String, but the call to GetProcAddress expects a C String. Therefore, if we have several string in the zig exe that are not null terminated, the name.ptr will take the whole strings, not the only name.
<rivten>
I found this out while debugging while my loading DLL crashed in ReleaseFast ^^
<tgschultz>
before I dive in and do it myslef, has anyone implemented a way to interface with COM in zig already?
<scientes>
==30866== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
<scientes>
in zig0
<scientes>
oh nvm i see
<scientes>
I am not sure if the import() semantics are sound given the existance of "use"
<scientes>
because of the possibility of recursive includes
Zaab1t has joined #zig
<scientes>
ahh this is #2189 specific
Zaab1t has quit [Remote host closed the connection]
akavel has joined #zig
<akavel>
Hi! I tried the following command: `zig.exe build-lib -dynamic -fno-PIC --verbose-cc --verbose-link --c-source hello-jni.c --library c -target arm-linux-musleabi`
<akavel>
but I'm getting an error: `invalid target: unrecognized architecture`
<akavel>
But when I run `zig.exe targets`, there seems to be an `arm-linux-musleabi` entry
<akavel>
Am I doing something wrong?
<akavel>
....eh, ok, found myself:
<donpdonp>
akavel: zig targets lists a few categories of things.
<tgschultz>
akavel you may have to speficy the entire tartet string: -target [name] <arch><sub>-<os>-<abi> see the targets command
<akavel>
I had to scroll up the window
<donpdonp>
armeb-linux-musleabi is an "available libc"
<tgschultz>
nevermind me, I can't read before lunch
akavel_ has joined #zig
* akavel_
has some trouble with connectivity
<donpdonp>
hmm the way you have it does make sense. disregard my comment :)
<donpdonp>
all ive used target for is webasm
<akavel_>
I tried -target armv7m-... eventually and something started to be happening, so it's definitely better now
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
shritesh has joined #zig
meheleventyone has joined #zig
<TheLemonMan>
yay, the test suite runs fine on x86 too if I disable x87 and enable SSE
shritesh has quit [Quit: Segmentation Fault]
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<donpdonp>
im passing a struct into a *c_void param, and back again. When I warn("struct {}", thing.client) => Client@2b3be0 why is the memory address so short? I would have expected something 64bits long
return0e has quit [Ping timeout: 268 seconds]
return0e has joined #zig
<donpdonp>
for example when I warn("{}", thing) its Thing@7ffc538f7a10
<donpdonp>
both thing and client are of type struct
<TheLemonMan>
show some more code, 2b3be0 suggests it is something off your ELF .rodata/data/bss
<donpdonp>
oh i was mixing up client.* and &client.
jjido has joined #zig
<donpdonp>
hmm to reiterate, im casting a struct Client@19ced80 to a *c_void, but getting the same *c_void back gives 0xc_void@aaaaaaaa019ceca0
neceve has quit [Remote host closed the connection]
<donpdonp>
so still some kind of bitwidth error
<TheLemonMan>
see the aaaaaaaa ? that's some undefined memory
<donpdonp>
yeah i can recognize that now. it still makes me giggle
<donpdonp>
i just dont understand why the address of the struct is short to begin with
<donpdonp>
0x019ceca0 is only 32bits, when i figure on my intel laptop a memory ptr should be 64
<TheLemonMan>
yeah but even with a 64bit address space we still use the lowest 0xffffffff bytes
<TheLemonMan>
7ffc538f7a10 -> suggest it's from a mmap allocation, 2b3be0 -> suggests it's from your ELF image
<donpdonp>
well when I @ptrCast(*myStruct, c_void_ptr), it says the cvoid is alignment 1 and *myStrut is alignment 8, so I'm using @alignCast(@alignOf(myStruct), c_void_ptr)
<donpdonp>
and it all compiles and runs but yeah the first half is 0xaaaaaaaa
<tgschultz>
what are you passing this through?
<donpdonp>
c.epoll
<donpdonp>
i wonder if warn() is simply truncating the display of 0x00000000019ceca0 to 0x019ceca0
<shachaf>
No, it's printing it as "19ced80". Seven nybbles. Not printing leading zeros is not usually called truncating.
<tgschultz>
doesn't explain the undefined bytes though
shritesh has joined #zig
bheads______ has quit [Ping timeout: 258 seconds]
_whitelogger has quit [Ping timeout: 248 seconds]
scientes has quit [Remote host closed the connection]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]