<gruebite>
can i save runtime type information? say in a pointer? :D
ur5us has joined #zig
<gruebite>
i have a layer of indirection: export fn -> C -> export fn, and need to determine the type i can store in a payload
<gruebite>
along with the types declarations, so i can call the correct function
<gruebite>
comptime type information*
<ky0ko>
so i've been having this issue for a while and i just started to dig into it a little more. i'm running alpine linux, built zig from latest git. i have an example c89 program that links with sdl2, that when built with gcc or clang, works perfectly. when built with zig cc, sdl2's video subsystem doesn't initialize correctly, and so the program does not work.
<ky0ko>
and this seems to extend to using SDL2 from zig, as well. I get the same error if I try to initialize SDL2 from zig code.
<andrewrk>
ky0ko, I'm guessing the video driver on that system depends on musl being dynamically linked
<andrewrk>
there's a lot going on with this topic, but suffice to say the workaround available to you today would be using zig build-obj and linking with system clang or gcc
<andrewrk>
or build-lib
waleee-cl has quit [Quit: Connection closed for inactivity]
euandreh has quit [Remote host closed the connection]
<pixelherodev>
gruebite: I don't think that's possible
craigo has quit [Ping timeout: 260 seconds]
<fengb>
Is there a way to kill a thread?
<pixelherodev>
Finally figured out why Valgrind never worked on zig binaries for me
<pixelherodev>
it doesn't support static executables
* pixelherodev
facepalms
<pixelherodev>
can't override the dynamic linker... *if there is none*
<pixelherodev>
I think Valgrind is a bit too conservative in deciding what qualifies as "still reachable"
<pixelherodev>
If I can trivially free the memory at the end of main, it should qualify
<pixelherodev>
Ah, I know!
<pixelherodev>
The pointers are on the *stack*, so it doesn't notice them probably
<pixelherodev>
... I know what I'm doing tomorrow.
<pixelherodev>
I had an idea on how to make the self-hosted parser faster / more memory-efficient, I'm going to probably spend at least an hour playing with it
<pixelherodev>
andrewrk: currently, all nodes are effectively subclasses of Node, right?
<pixelherodev>
The idea was to make it non-generic (and then update allllll the callers)
<andrewrk>
it's already non generic
<pixelherodev>
... I need to take another look :P
<andrewrk>
I don't understand the idea
<pixelherodev>
Probably not a very good idea :P
<pixelherodev>
so that's okay
<andrewrk>
you don't want to share the idea?
<pixelherodev>
1) it's not really feasible, after looking over the source more in-depth, and 2) I'm fairly certain it's a bad idea anyways
<pixelherodev>
If you hadn't made me think further on it now, I'd have probably ended up saying "whoops, bad idea" tomorrow morning lol
<pixelherodev>
Well, today morning (after midnight woot), but you know what I mean
<andrewrk>
fair
<andrewrk>
there is a bunch of tedious work to do to further memory-optimize the ast, if you want to take that on
<andrewrk>
look through my latest commit diffs that touch the ast.zig file and you'll see the kind of changes I'm talking about. it's all about reducing the size of AST nodes in memory
<pixelherodev>
Nah, I'll focus on the SPU stuff
<pixelherodev>
On that note, I think it's still your turn :)
<pixelherodev>
I'll work on the next few PRs today regardless
<gruebite>
i created a monster. a script to generate shim functons over C functions with <16 bytes for parameters OR return types
<gruebite>
now the question is do i add do it for ALL the apis? since i'm adding a prefix, it could suck to always have to check if it won't work
nvmd has quit [Quit: Later nerds.]
waleee-cl has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
<andrewrk>
I'm planning to do a live stream in about 1 hour 20 minutes. Agenda is to demo the incremental compilation + debug line number info and then LLVM11 upgrade part 2
<ifreund>
nice! i will make some pasta in preperation
<andrewrk>
ifreund, I would be happy to talk stage2 stuff too, anything I can explain or demo for people trying to contribute
ur5us has joined #zig
<fengb>
ifreund: everything makes sense to me 👍️
<fengb>
I'm a little afraid of call_indirect being less performant but that's a general gut reaction
<andrewrk>
oh I didn't see 5985 until just now, will take a look
<ifreund>
fengb: yeah, call indirect will certainly be less performant
<ifreund>
maybe I should hand-code some wasm and benchmark it
<ifreund>
it may not be significant, needs research
<ifreund>
andrewrk: would appreciate it. #5985 is mostly a brain dump of what I've been thinking about the past couple days
<ifreund>
it does give me somewhere to start with regards to an implementation though
<andrewrk>
call_indirect is how x86 does incremental compilation
Ichorio has joined #zig
<fengb>
I think the "start" should be fairly straightforward. Zig code doesn't use this section
Ichorio has quit [Client Quit]
<ifreund>
does wasi have a different entry point?
<ifreund>
I'll admit that I haven't really read up on wasi yet
<fengb>
Yeah it's different. I think it's an exported function name
<ifreund>
makes sense
<fengb>
start is reserved for setting the internal state at runtime. Mostly for constructors and such, which we don't have
<ifreund>
yeah the start section should be the easiest then :P
<ifreund>
do we have a way to do imports yet?
<fengb>
Yeah, it's just `extern "module" fn foo();`
<ifreund>
makes sense
<fengb>
Caveat is that you can't import variables in LLVM atm
<fengb>
So only functions
<ifreund>
guess self hosted will be more feature complete :P
<andrewrk>
pfg_, it might be nice to try to get your riscv branch to a mergeable state as soon as possible to help avoid merge conflicts. It's OK for it to be incomplete, as long as there aren't regressions of existing test cases
<andrewrk>
you can do that pattern you see everywhere of returning a compile error that says "TODO: implement xyz"
<andrewrk>
start.zig is kind of cool file, you can learn what code runs before main on every system at the same time, and it's only 272 lines
<ifreund>
good tip, I had read parts of it before but forgot to check in this case
<andrewrk>
pfg_, yeah, all tests passing, in my opinion we should just merge this!
<andrewrk>
unless you enjoy resolving merge conflicts :P
<pixelherodev>
Ugh
<pixelherodev>
andrewrk: while you're at it, mind looking at mine soon?
<pixelherodev>
Same reason :P
<andrewrk>
I'm so tickled that our inline assembly support so far is literally if (!mem.eql(u8, inst.asm_source, "syscall")) return self.fail(inst.base.src, "TODO implement support for more x86 assembly instructions", .{});
<andrewrk>
you can go a long way with that
<pixelherodev>
Yep!
<pixelherodev>
Huh, actually
<pixelherodev>
My grep-fu needs work, hold on :P
<pixelherodev>
At a quick glance, that's literally the only instruction we need for linux x64 support
<pixelherodev>
Potentially `nop` for a test
<pixelherodev>
`pause` for threading, maybe?
<pixelherodev>
But that's really it
<andrewrk>
wow riscv codegen is so much easier than x86
<pixelherodev>
You say that like it surprises you!
<Snektron>
So when are we getting brainfuck codegen
<pfg_>
asm volatile("<>>>>.<<.>>>,")
FireFox317 has quit [Ping timeout: 264 seconds]
<pixelherodev>
Snektron: oh god no please don't give people ideas
<pixelherodev>
Those are dangerous
<Snektron>
will codegen.zig be the new ir.cpp
<pfg_>
andrewrk, how should I do a compare_output test for a non native platform?
<pixelherodev>
pfg_: I can answer that :)
<pixelherodev>
See #5972
<andrewrk>
pfg_, you just specify the target and the build system figures out whether to run it or not
<pixelherodev>
I was going to say "hook it up to QEMU" :P
<andrewrk>
it should be clear I think if you look at compare_output.zig
<andrewrk>
I don't think pixelherodev's PR is relevant here
<pfg_>
compare_output returns immediately if the current target isn't linux x86_64
<andrewrk>
pfg_, you should be able to pass -Denable-qemu
<pfg_>
ah
<andrewrk>
./zig build test-stage2 -Denable-qemu
<pfg_>
neat
<pixelherodev>
andrewrk: test cases go through runOneCase though - currently, it'll try just running the binary directly
<pixelherodev>
enable-qemu won't be noticed, unless I'm missing something big
<andrewrk>
hm ok I'll take a look at it along with #5972
<andrewrk>
anyway that's how it's supposed to work though. the test cases are declarative
<pixelherodev>
The idea is, you give it a target, the test harness and build system collaborate to decide if it should be run, and if so, how to do so
<andrewrk>
pfg_, if you add that test case I'd be happy to merge that PR right now and then fiddle with it until it's running properly
<pixelherodev>
We need to integrate externalRunner from CrossTarget with the harness I think
<pfg_>
I added the test case, trying to run it errors InvalidExe
<pfg_>
should I push that?
<andrewrk>
yeah, if you don't mind doing a hand-off, I'll get you up and running here
<pixelherodev>
`std.debug.print("TODO implement non-native tests for target arch {}\n", .{e});`
<pixelherodev>
I think we need to detect a) if an extern runner is known, and b) if it's enabled
<pixelherodev>
Based on a combination of the two, we either run the test with the external runner, skip it, or mark it as failed
<pfg_>
oh there's a merge conflict with codegen.zig now
<pixelherodev>
`git fetch origin master && git rebase origin/master` is what I typically do
<pfg_>
github has a web merge conflict resolver that seems to have worked
<andrewrk>
pfg_, I'm merging your branch locally now, will fiddle with the test harness until it gets run by qemu
<pixelherodev>
andrewrk: Should I close my PR then, since you're probably superseding it anyways? :P
<andrewrk>
I would have merged the debug.warn commit
<pixelherodev>
You can cherry-pick it
<pixelherodev>
I'll let you decide what to do with that PR
<andrewrk>
ok
<pixelherodev>
and the one after it ;)
xackus_ has quit [Ping timeout: 240 seconds]
factormystic has quit [Ping timeout: 265 seconds]
KKRT has quit [Quit: KKRT]
<andrewrk>
ifreund, `./zig build test-stage2 -Denable-wasmtime` now works
<ifreund>
nice, that will be super useful
<ifreund>
I was wondering I was going to need to write a simple wasm vm
<fengb>
Speaking of which...
<ifreund>
oh nice, you have one
<fengb>
Um... it doesn’t parse everything correctly and only tested to run nop
<fengb>
In theory the math should work too >_>
<fengb>
I need to actually add more tests. It should work for a lot of things
hspak has quit [*.net *.split]
mattmurr has quit [*.net *.split]
neptunepink has quit [*.net *.split]
ronsor has quit [*.net *.split]
haliucinas has quit [*.net *.split]
signop has quit [*.net *.split]
andrewrk has quit [*.net *.split]
][_R_][ has quit [*.net *.split]
chivay has quit [*.net *.split]
factormystic has joined #zig
hspak has joined #zig
signop has joined #zig
mattmurr has joined #zig
chivay has joined #zig
][_R_][ has joined #zig
andrewrk has joined #zig
ronsor has joined #zig
neptunepink has joined #zig
haliucinas has joined #zig
hspak has quit [Max SendQ exceeded]
<ifreund>
didn't someone say they were working on a birth and death of javascript style wasm in the ring 0 thing?
<ifreund>
guess they'd need a vm or jit of some kind
hspak has joined #zig
jicksaw has quit [Ping timeout: 246 seconds]
* pixelherodev
sobs
<pixelherodev>
please no
<pixelherodev>
Please please no
jicksaw has joined #zig
<ifreund>
pixelherodev: are you sobbing on technical or ideological grounds
<ifreund>
I think it would be cool even if it doesn't prove useful
<fengb>
I’ll create a cpu chip that runs wasm natively
<fengb>
Right after I finish my vm
<pixelherodev>
ifreund: *both*
<ifreund>
pixelherodev: care to explain the technical grounds?
<andrewrk>
streaming in 10 min
<lemmi>
perfect timing :>
<pixelherodev>
ifreund: I don't consider in-kernel emulation sane grounds for an executable format
<pixelherodev>
Not in the slightest.
<ifreund>
and why not?
<pixelherodev>
... if I have to explain it, we clearly have fundamentally incompatible axioms about sane computing.
<ifreund>
I'm just asking for a little more than "doing that isn't sane." What about it is so fundamentally insane?
<pixelherodev>
It's unnecessary complexity which serves no real purpose other than "WHoa this is awesome!!!!!!!"
<pixelherodev>
I've *never* heard anyone make a serious argument in favor of it
<pixelherodev>
Every argument boils down to coolness factor
<pixelherodev>
And I say this as someone who's literally working on a kernel-mode emulator: not a good idea for a serious OS
<ifreund>
I guess you don't buy the argument that reduced context-switching could make syscall heavy workloads run faster?
<ifreund>
(I'm honestly not all that well informed on os dev, just a curious person)
<pixelherodev>
I do buy the argument
blinghound has joined #zig
<pixelherodev>
I just think that a) there's better ways to accomplish that goal and b) performance is only one aspect of a system
<pixelherodev>
Better a system that's easier to maintain and a bit slower.
<pixelherodev>
Radical redesign isn't even necessary for higher performance
<pixelherodev>
If you want better-performing syscalls, you could disable security features.
<pixelherodev>
Turn off security entirely, effectively.
<pixelherodev>
If you fully trust the system, it's honestly not that insane
<pixelherodev>
(so long as you disable networking, don't use untrusted peripherals, etc)
<pixelherodev>
ifreund: also, while it's true that reducing context switching can help performance, the cost of even the best JIT of all time will more than reverse any performane gains
<pixelherodev>
performance*
<ifreund>
heh
<ifreund>
thanks for the thoughts
<pixelherodev>
Np
<pixelherodev>
Always happy to persuade people that I'm the source of absolute truth /s
<pixelherodev>
If you have any opposing arguments, I'm eager to hear them
<ifreund>
I don't have enough experiance with jits or os dev to make any convincing statements :P