CommunistWolf has quit [Ping timeout: 256 seconds]
<mikdusan>
andrewrk: does your quick eyeball see anything wrong with what I'm seeing in foo2() ? I've got a WIP PR for #3963 and looking good so far but this case was unexpected. if this is expected behavior then I'll just follow the ConstPtrSpecialRef to ref.pointee
<shakesoda>
pixelherodev: reloads crap out from beneath you
<shakesoda>
twitter does that kind of crap constantly. auto-refreshing things from under your mouse, refreshing pages out of existence etc
<shakesoda>
it's a nightmare
<pixelherodev>
ah
<pixelherodev>
Don't use Twitter, so I wouldn't know :)
<fengb>
Do we have a naming convention of functions returning other functions?
<andrewrk>
no but maybe that's a good idea
<fengb>
`makeAtomicRmw`
<mikdusan>
I wonder if it would be better to organize our tests around topics, and self-contain them. behavior.zig would then explicitly @import the unit tests, and for example compile-errors would import those files and naming conv like `<topic>/` with `test.zig` for units, and `compile-error.zig` and the naming tells us what should do the import
<redj>
zig cc -- src/sys/DualPipe.ec:1:10: fatal error: 'stdarg.h' file not found -- shouldn't that work?
<mikdusan>
yes. whenever I see stdarg.h not found I think, hey are you on macOS? :)
<redj>
I tried -target native-native-gnu and x86_64-linux-gnu but same result
<redj>
mikdusan: I'm on windows 10 and linux
<redj>
though I have yet to run zig on windows
diltsman has joined #zig
<diltsman>
Does anyone know of an example of how to use an ArrayList with an OutStream? I have been trying to get it to work and it is driving me crazy.
<fengb>
Hmm, methods on enums can't accept a pointer? :(
daex has quit [Ping timeout: 258 seconds]
daex has joined #zig
daex has quit [Ping timeout: 250 seconds]
diltsman has quit [Remote host closed the connection]
daex has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
mahmudov has quit [Ping timeout: 256 seconds]
daex_ has joined #zig
daex has quit [Ping timeout: 250 seconds]
swills has quit [Ping timeout: 256 seconds]
swills has joined #zig
dddddd has quit [Ping timeout: 256 seconds]
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
<pixelherodev>
I get distracted by side projects way too easily
josch557 has quit [Remote host closed the connection]
josch557 has joined #zig
marijnfs_ has joined #zig
_Vi has joined #zig
marijnfs1 has quit [Ping timeout: 264 seconds]
marijnfs1 has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
mahmudov has quit [Remote host closed the connection]
waleee-cl has joined #zig
mahmudov has joined #zig
mahmudov has quit [Remote host closed the connection]
rzezeski has quit [Quit: Connection closed for inactivity]
yurip has joined #zig
mokafolio has quit [Quit: Bye Bye!]
<yurip>
Hi everyone, I'm experimenting with translating an existing C base to zig. I'm starting with the build system. An old blog post on the subject uses addCExecutable, but that seems to be gone. What's the recommended way now?
<ifreund>
yurip: should be addCSourceFile() I think
<fengb>
I'd probably just manually write the exports though. It's not too many more lines and copy paste is easier on my brain
<TheLemonMan>
I'm hitting so many comptime bugs
<andrewrk>
thanks for the tip TheLemonMan, was able to resolve the riscv thing
<fengb>
Sometimes I want to tell Zig to stop helping. It can get frustrating trying to map to C semantics >_>
<andrewrk>
self-hosted needs a much more deliberate design plan for how to do comptime. none of this experimentation based design that stage1 evolved from
<FireFox317>
andrewrk, nice! so that means we get a ricv binary for 0.6.0 ? <3
<andrewrk>
no so fast, still need to test it in the bootstrap repo :)
<TheLemonMan>
andrewrk, cool, the whole ABI thing gets unwieldy pretty quick
<TheLemonMan>
you have the ABI in the triple, the float ABI, the machine ABI...
<andrewrk>
yeah. std.Target.Abi might need to get slightly more complicated, similar to how the cpu and os have recently
* ikskuh
is confused about a trigger of ud2
<ikskuh>
what could provoke undefined behaviour in a function pointer call that ud2 is executed after the return of that function pointer?
<TheLemonMan>
noreturn function?
<ikskuh>
nope
<ikskuh>
void (*func)(void *);
<TheLemonMan>
if the function jumps to ud2 right after the `bx lr` you may have some other thing going on
<ikskuh>
x86_64, but yes, it does
<ikskuh>
kinda?
<ikskuh>
gdb tells me that the line of code is an assert
<ikskuh>
but code after that assert got executed
<ikskuh>
could it be a stack overflow?
<TheLemonMan>
does the control flow resume after the branch to the function pointer?
<TheLemonMan>
if it's returning to god-knows-where then you have a stack overflow
<TheLemonMan>
or calling convention mismatch
<FireFox317>
We closed almost twice as many issues as the previous release cycle :O 516 now comparing to 260 of the previous one
<FireFox317>
s/we/andrewrk/
<ikskuh>
nice!
<andrewrk>
nah it's we for sure
<andrewrk>
I am but one man, capable of a fixed amount of work. the contributions have skyrocketed this cycle
<andrewrk>
special thanks to TheLemonMan for solving so many non-x86 issues
<ikskuh>
TheLemonMan: i think it's a SO
<ikskuh>
or some stupid programming mistake of mine
<andrewrk>
also for yelling at me hard enough to learn how to use QEMU :)
<BaroqueLarouche>
TheLemonMan is a MVP
<TheLemonMan>
I'm just doing my part to accelerate the slow death of x86
<ikskuh>
TheLemonMan: Slap me. Slap me hard.
<BaroqueLarouche>
hahahaha
<andrewrk>
kinky
<ikskuh>
thou shalt not cast a function pointer
<ikskuh>
i really wonder how that resolved into having a ud2 instruction in a completly other function
<ikskuh>
but it looks like it worked correctly
<ikskuh>
and did what it should
<TheLemonMan>
haha nice
<ikskuh>
well, it definitly sanitized some undefined behaviour
<ikskuh>
because
<ikskuh>
void foo(void*) and void foo(CAMERA*) are definitly not castable :D
<TheLemonMan>
there's a lot of stuff that runs just fine due to sheer luck
<andrewrk>
or misfortune, from a different perspective
<TheLemonMan>
think of the aarch64 issue, we've been running with a faulty builtin for who knows how much time
<ikskuh>
yeah, having a UBSan active all the time is great :)
<TheLemonMan>
and everything worked just fine!
<andrewrk>
yeah that was pretty crazy
<andrewrk>
FireFox317, this riscv64 llvm build looks like it might succeed :D
<fengb>
No errors means working fine right?
<TheLemonMan>
andrewrk, `obj[start..end:T]` is meant to produce a slice with length (end-start+1) and an assertion that obj[end] == T, right?
<andrewrk>
length should be end-start, no +1. otherwise yes
<andrewrk>
note that obj[end..end] is allowed
<TheLemonMan>
oh sure, I meant that the slicing operation should also assert that there's space for one more item in the backing object
<andrewrk>
ahh I see
<TheLemonMan>
#4857 helped me to find some potential oob sentinels in the stdlib
<andrewrk>
regarding mips, at least the 64 bit and 32 bit ones are hitting the same problem
_Vi has quit [Ping timeout: 252 seconds]
<shakesoda>
ifreund: i hate it lol
<ifreund>
i should probably rewrite this, but that can wait for later
r4pr0n has joined #zig
wootehfoot has quit [Ping timeout: 256 seconds]
dimenus has quit [Remote host closed the connection]
FireFox317 has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
tributarian has joined #zig
<pixelherodev>
Oh my god
<pixelherodev>
What is that
<pixelherodev>
Those nested functions...
marijnfs_ has quit [Ping timeout: 265 seconds]
marijnfs_ has joined #zig
r4pr0n has quit [Quit: r4pr0n]
frmdstryr has quit [Remote host closed the connection]
<yurip>
what's the best way to add a bunch of C source files with the same args to a build? It looks like https://tiehu.is/blog/zig1.html this blog from the front website is pretty out of date
<ikskuh>
yurip: right from my current wip port to zig build:
<yurip>
i'm considering using zig for a fairly major embedded project over the next year or so (student stuff), and having data compression might be important
<BaroqueLarouche>
it will once I wrote a deflate (compression) implementation
<yurip>
looking forward to compression!
<yurip>
BaroqueLarouche: awesome, looking forward to it
<BaroqueLarouche>
I want to finish reading PNG support first
<BaroqueLarouche>
doing interlaced support this weekend
Akuli has quit [Quit: Leaving]
_Vi has joined #zig
FireFox317 has quit [Ping timeout: 265 seconds]
<ikskuh>
oh man
<ikskuh>
building ODE is hell
<ikskuh>
:D
<ikskuh>
there are build-files for autotools,cmake AND premake
<mikdusan>
how does one find the default linker script (internal?) used by lld
<fengb>
I'm not sure they need more control on Android
<pixelherodev>
Tighter integration is a bad thing in terms of maintainability, but could have unique performance / feature advantages
<pixelherodev>
and maintainability isn't a problem if Google owns it
<fengb>
But it's a chance to fix some of the design flaws
<shakesoda>
i wouldn't say tighter integration is automatically a bad thing for maintainability
<fengb>
I suppose baking more of the Google stack directly into the OS would help them a bit
<shakesoda>
since generic solutions to things are usually more complex
<shakesoda>
(often substantially so)
<mikdusan>
I predict zig's std will support serenity before fuchsia
<THFKA4>
hah i'm playing with Fuchsia on my desk right now
<pixelherodev>
`<shakesoda> i wouldn't say tighter integration is automatically a bad thing for maintainability` true
<mikdusan>
how fast does can it fork-bomb (launchpad) ?
<pixelherodev>
Serenity?
<pixelherodev>
On a different note
<THFKA4>
the technical choices they made for the kernel are actually pretty great
<fengb>
Oh it's actually working?
<pixelherodev>
Anyone interested in working on a joint project to write a kernel in Zig?
<THFKA4>
and they emulate a big part of POSIX, so porting Zig might not be that hard
<ikskuh>
pixelherodev: what kind of kernel do you want to make? :D
<pixelherodev>
I've done some bits and pieces for a project, and I know a few others have as well, but I want to actually make a usable system (even if not necessarily "the future!!!")
<fengb>
Oh Serenity
<fengb>
Oops I hit the enter key instead of delete >_>
<pixelherodev>
Insert joke about how so did they? :P
<fengb>
Sometimes I wish there's an undo button in IRC. And real life
<pixelherodev>
The initial idea is a x64 kernel with cooperative multithreading instead of the usual preemptive (though with a preemptible bit for each thread table entry for reasons I'll get to shortly)
<pixelherodev>
(sorry; had to take care of something)
<pmwhite>
fengb: I mean, if you use matrix to edit your message, it will work for me :)
<pixelherodev>
I don't have much concrete plans; the idea is to start by merging together various existing pieces (like APCICA, Linux kernel modules for graphics) with the goal of ASAP usability, then phasing them out and replacing with from-scratch ones
<pixelherodev>
What I do have in the plans is to not support ELF executables.
<mikdusan>
what I'd like to see are 2-sided (made up that name) page tables for virtual address space; one side is for stack, and other side is everything else. so thread can have it's own private stack, and thread-locals basically become globals. how much heavier does that make a thread? hopefully not much.
<pixelherodev>
Instead, I want to have IR frontends (QBE, LLVM, etc)
<pixelherodev>
Which is where my compiler project comes in
<pixelherodev>
Every executable will be JITed into the native architecture on demand
<pixelherodev>
This allows for `-march=native` by default, and security improvements
<fengb>
Just use wasm as the "native" code
<pixelherodev>
WASM frontend is okay too, but I also want to support LLVM + QBE + etc
<pixelherodev>
That would allow for using, say, `cproc` as the C compiler, not just those that already support WASM
<pixelherodev>
WASM + LLVM + QBE is a good set to start with
<ikskuh>
luajit *grin*
<THFKA4>
Fuchsia handles "runners" kind of like that. It's not tied to ELF.
<pixelherodev>
The thing to note is that it's intended to use an in-memory tree for the AST
WilhelmVonWeiner has quit [Ping timeout: 240 seconds]
<THFKA4>
it calls units of executable software "components" and you can implement your runtime in those
<THFKA4>
then use them to interpret scripts, or whatever else you want
<pixelherodev>
Still, I'm completely open to suggestions and improvements from others; I don't claim to have all the answers, and I'd rather work with others on a changed design than on my own with the current one
<ikskuh>
what i found crazy was what microsoft did with their "windows subsystem for linux"
<ikskuh>
which is like.... "ah, btw! our kernel now supports the linux syscall interface!"
<THFKA4>
for v1 they had a shim layer to translate syscalls, right?
<THFKA4>
now they embed the entire linux kernel or something
<ikskuh>
nah
<ikskuh>
the first thing: yes
<ikskuh>
v1 was actually a kernel extension that allows to switch out syscalls
<squeek502>
parameter dash 1, parameter dash 2, parameter slash 1 presumably, they correspond to `-`, `--`, `/` being allowed prefixes for that option
<squeek502>
that file is generated by update_clang_options.zig
<daurnimator>
pixelherodev: a slice from LinearFifo can be represented with maximum 2 iovs: if you're reading from a pipe, you can use e.g. readv to fill it up across the wrap-around.
<pixelherodev>
Ah
<pixelherodev>
That's useless to me right now, but I'll note it down for later :)
r4pr0n has quit [Quit: r4pr0n]
decentpenguin has quit [Quit: decentpenguin]
<daurnimator>
Its actually something that annoys me about the current stream interface