<pixelherodev>
andrewrk: I think incremental compilation of ZIR is worth keeping
<pixelherodev>
A lot of the code paths *are* the same
<pixelherodev>
The burden of keeping it working is pretty light, relatively speaking
<pixelherodev>
also, food for thought: since we have C support (currently planned as an extension requiring LLVM in stage2), and we have a C parser good enough for translate-c, why not add a C Module type to self-hosted?
<pixelherodev>
I'd be more than willing to do all the work of adding it myself if that was welcomed :)
<mq32>
wait…
<mq32>
you mean translate C to ZIR?
slurpie has joined #zig
<andrewrk>
I think an experimental C frontend on top of the self-hosted backend is worth proposing
<mq32>
neat
<leeward>
That would be cool.
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
alexnask has quit [Quit: Leaving]
aerona has joined #zig
shcv has quit [Ping timeout: 260 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
shcv has joined #zig
layneson has quit [Ping timeout: 260 seconds]
doublex_ has quit [Ping timeout: 260 seconds]
leeward has quit [Remote host closed the connection]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
leeward has joined #zig
wootehfoot has quit [Ping timeout: 264 seconds]
ur5us has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
<marler8997>
andrewrk, looks like valgrind shims malloc_usable_size to return the original size requested to malloc, interesting
<andrewrk>
good to know, hopefully that's a precedent other tools follow, in which case our use of malloc_usable_size will be justified
<andrewrk>
does anyone remember what the gcc backend IR is called?
<andrewrk>
ahh GIMPLE
<leeward>
Right, that's it.
<leeward>
Hard to get at, because RMS.
<leeward>
I really want a backwards version of DragonEgg. LLVM IR -> any backend supported by GCC would be amazing.
rappet has quit [Ping timeout: 246 seconds]
rappet has joined #zig
leeward has quit [Ping timeout: 260 seconds]
doublex_ has joined #zig
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
slurpie has quit [Ping timeout: 240 seconds]
doublex_ has quit [Ping timeout: 246 seconds]
<pixelherodev>
Fixed it for ZIR!
leeward has joined #zig
aerona has quit [Read error: Connection reset by peer]
aerona has joined #zig
penguinicus has quit [Ping timeout: 245 seconds]
doublex_ has joined #zig
penguinicus has joined #zig
stripedpajamas has joined #zig
reductum has joined #zig
dingenskirchen has quit [Remote host closed the connection]
<marler8997>
makes me think it would be cool to organize a Zig-only game jam
stripedpajamas has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
reductum has quit [Quit: WeeChat 2.8]
aerona has quit [Ping timeout: 258 seconds]
slurpie has joined #zig
<andrewrk>
that sounds really cool
<andrewrk>
I think it would be unreasonable to do it without c libraries at this point
<marler8997>
yeah
ur5us has quit [Ping timeout: 260 seconds]
emekoi has joined #zig
_whitelogger has joined #zig
emekoi has quit [Ping timeout: 260 seconds]
emekoi has joined #zig
dddddd has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
wootehfoot has joined #zig
dermetfan has joined #zig
antaoiseach has joined #zig
stripedpajamas has quit [Quit: sleeping...]
ur5us has quit [Ping timeout: 260 seconds]
emekoi has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
<antaoiseach>
Can anyone please explain bitcasting vs bytecasting in some detail? Or point me to some relevant sources? When would I need to use either?
<antaoiseach>
and how that relates to alignment?
<antaoiseach>
I understand the basics, but I can't seem to understand the specific use-cases
<antaoiseach>
Also, why not always use packed structs?
<antaoiseach>
(I mean vis-a-vis normal structs, I understand the use-case for extern structs)
antaoiseach has quit [Quit: leaving]
nikita` has joined #zig
moo has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
<ifreund>
well, having an undefined memory layout allows for optimizations that aren't possible otherwise
<ifreund>
oh they left
alexnask has joined #zig
<pixelherodev>
andrewrk: when you get a chance, can we discuss stage2 a bit more? :)
<pixelherodev>
Figured out why I"m having issues fixing this for Zig code, but while I thought of a few fixes, this is definitely a case where your input is required
josias has joined #zig
<josias>
Hello. I was wondering if there was something like itoa in the Zig standard library. Just something to convert an integer to a u8 array.
<pixelherodev>
Sure is :)
<pixelherodev>
std.fmt.bufPrint is probably what you want
<alexnask>
There are various functions in std.fmt, like std.fmt.bufPrint or std.fmt.allocPrint etc
<pixelherodev>
There's other functions in std.fmt that might be of use too
<pixelherodev>
Yeah :)
<alexnask>
^_^
<josias>
Okay. Thanks!
<pixelherodev>
This is quite possibly the only channel I've been in in which someone asked a question, people responded in tandem with the same answer, and everything was just genuinely constructive :D
<pixelherodev>
I freaking love it
<pixelherodev>
Okay, not the *only* one, but you know what I mean; it's depressingly rare
opDispatch has left #zig ["Konversation terminated!"]
josias has quit [Remote host closed the connection]
josias has joined #zig
<josias>
Whenever I try to read from stdin, it gives an EndOfStream error. Any ideas? I am using readByte().
<ifreund>
is there anything in your std when you try to read? could try something like echo "test" | ./zig-cache/bin/my_program
wootehfoot has quit [Ping timeout: 265 seconds]
josias has quit [Remote host closed the connection]
<ifreund>
s/std/stdin/
<nrdmn>
I'm trying to compile `pub fn main() void {}` for target avr-freestanding and I'm getting "LLVM ERROR: Not supported instr: <MCInst 242 <MCOperand Reg:51> <MCOperand Imm:1> <MCOperand Reg:48>>"
<ifreund>
hmm, I'm not very familiar with bare metal but maybe you need to declare _start() directly?
<ifreund>
something like export nakedcc fn _start() noreturn {}
<ifreund>
oops nakedcc is gone, would be callconv(.Naked) now
<alexnask>
^
<nrdmn>
nope, same message in the end, although IR output stops at a different location
<nrdmn>
hmm.. no error with --release-small.
<ifreund>
interesting
<pixelherodev>
Weiiiiiird
<pixelherodev>
Oh heh, my Zig kernel is definitely dead of bit rot
<pixelherodev>
Whelp
<pixelherodev>
Time to do a new one! :P
<alexnask>
Hm so it may be some instruction in a safety check?
<ifreund>
I think it'd be worth opening an issue for that then
<ifreund>
yeah that's what I was thinking
<pixelherodev>
Oh, maybe it's a trap?
<pixelherodev>
/ breakpoint / whatchamacallit
<pixelherodev>
The panic handler
<pixelherodev>
Try replacing it?
<alexnask>
Good call
<ifreund>
oh yeah good call
<pixelherodev>
I only have... uh, way too much experience with bare metal in Zig :)
<pixelherodev>
Ugh, this stage2 issue is realy bugging me
<pixelherodev>
really*
<pixelherodev>
It's a design problem, I think.
<pixelherodev>
I've thought of a number of solutions but all of them have serious downsides
<pixelherodev>
Basically, we track analyzed Decls in a Map(NameHash, *Decl) - if you do a redefinition (`const a = foo; const a = bar;`), the name is the same for both
<pixelherodev>
It *needs* to be able to track *both* decls *separately*
<pixelherodev>
And irrespective of the contents (e.g. `const a = foo; const a = foo;` is equally invalid), so a trick like `name_hash XOR contents_hash` as the key wouldn't work
<pixelherodev>
(not to mention that we use name_hash alone *on purpose*)
<ifreund>
and you can't use e.g. line number either cause it's incremental
<pixelherodev>
Exactly.
<pixelherodev>
Incremental compilation is the root of the issue here
<pixelherodev>
I can get it erroring easily
<pixelherodev>
It's really not that hard, at all
<pixelherodev>
But we can't clear the errors on each update (which was my first solution until Andrew pointed out why it's bad)
<pixelherodev>
If neither broken decl is updated, they won't be reanalyzed, but we need the errors to remain
<pixelherodev>
Which means we need to be able to reanalyze both decls *independently* on the next update
<pixelherodev>
The reason it's failing currently is that it's trying to analyze them both with the same name_hash - which means the same *key*
<pixelherodev>
Rather
<pixelherodev>
The test does a failure (redefines a symbol), then updates the source to remove the second definition
<pixelherodev>
Since it's unable to properly track the second definition, it doesn't realize that it's been deleted
<pixelherodev>
The current symption is that the error message remains, but the source code no longer contains the referenced line, so it errors trying to figure out the line and column from the byte offset, which is no longer in a valid spot in the source
<pixelherodev>
s/tion/tom
<pixelherodev>
The same issue *probably* occurs in ZIR, but we don't really care
<pixelherodev>
The actual test I was working on - exported symbol collision - was straightforward in ZIR, because both `export`s have unique IDs
<pixelherodev>
Which led to one idea for a solution: lower Zig to ZIR for each incremental update
<pixelherodev>
But that's terrible for performance and would basically mean a major design change to workaround a single minor edge case
<pixelherodev>
A smaller change which would also have worse performance characteristics would be to turn the map value from a *Decl into a []*Decl, and have it track both
Prf_Jakob has quit [Remote host closed the connection]
<pixelherodev>
But that means overhead for *everything* just to check for redefinitions, which I don't think I've *ever* seen
<pixelherodev>
So, not great.
<ifreund>
yeah, neither of those are great
<pixelherodev>
Hmm
<pixelherodev>
Here's an idea
<ifreund>
what about an ancillary hashed_name -> []*Decl hash map?
<pixelherodev>
When a redefinition is detected, the original decl could just be invalidated
<ifreund>
that only gets used for redefinitions
<pixelherodev>
ifreund: same problem there, *and* it wastes memory
<pixelherodev>
It'd mean checking an additional map *constantly*
<pixelherodev>
Which means a map lookup
<pixelherodev>
I think invalidating the original decl is the way to go here
<pixelherodev>
If the original one is invalidated and removed from the map... wait hmm, failed_decls tracks it though
slowtyper has quit [Quit: WeeChat 2.8]
<pixelherodev>
It could mark the original one as invalidated, and leave it in the map though
<ifreund>
well, since this case is so rare it could actually be an ancillary arraylist or something
<pixelherodev>
Yes, but it doesn't even matter
<pixelherodev>
If we have an extra list/map/whatever, that is in and of itself problematic
<pixelherodev>
Best case, it means a single unnecessary list check on *every single analysis*
<pixelherodev>
My goal here is a solution that has literally zero cost for any input in which there are no redefinitions
<pixelherodev>
I'm going to try invalidation and see if there's any issues with it...
<pixelherodev>
ifreund: thanks for the feedback :)
<ifreund>
heh, I didn't actually say anything particularly useful :P
<ifreund>
heh, yeah I definitely relate to that style of programming
waleee-cl has joined #zig
<pixelherodev>
Ohh, found the real issue! Woo
<pixelherodev>
When the second definition was removed, the first is left alone - and thus, not analyzed again
<scientes>
> if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits
<scientes>
oh god
<scientes>
that is horrible
<scientes>
super clever, but horrible
<ifreund>
aye
<scientes>
don't remember Knuth covering that trick
marnix has joined #zig
<marnix>
Quick question, using zig 0.6.0. In a while loop with error union with optional type, why is the 'while' type still optional?
<marnix>
So with `fn f() anyerror!?u8` in `while (f()) |item| {...} else |err| {...}`, I would expect item to be u8, but it is ?u8. Why is that?
<ifreund>
it will only unwrap one layer of optional/error union afaik
<ifreund>
consider what would happen if there was no error, but the optional was null
<ifreund>
then the else branch doesn't really work
<ifreund>
(if the while unwrapped both layers)
<alexnask>
zls now has renaming, here is an example of renaming std.ArrayList http://prntscr.com/t7gd7u
<ifreund>
woah
<alexnask>
(Note: currently renaming doesnt flow through aliases and always checks all open documents)
<alexnask>
So in this example in `std.zig` the decl will become `pub const Vector = @import("array_list.zig").ArrayList;`, eventually it will probably support renaming the inner decl if it does not cross package boundaries
<ifreund>
makes sense, still pretty cool though
<marnix>
ifreund Thanks-- continuing to look for best/simplest pattern for finite iterator that can have errors.
<ifreund>
while (try f()) |item| would work, though then you handle the errors ouside of the current function
<ifreund>
you can also use a block for the while statement: while (f() catch |e| handle(e)) |item|
<ifreund>
er, that's not a block but whatever
<marnix>
ifreund I like that last option, thanks!
<ifreund>
no problem!
<marnix>
ifreund (Well, `handle(e)` could be a block :-) )
<ifreund>
a block would be more like while (blk: { foobar(); break :blk f(); }) |item|
<ifreund>
but yes what you said would make a lot more sense
decentpenguin has joined #zig
dddddd has joined #zig
<marnix>
Is there a pattern for 'does expression ... return error ...?', in tests?
decentpenguin has quit [Read error: Connection reset by peer]
<marnix>
Simply doing assert(... == ...) doesn't work, it seems.
<traviss>
std.testing.expectError i believe
<traviss>
yes its defined as: std.testing.expectError(expected_error: anyerror, actual_error_union: var)
<marnix>
Just discovered `if (...) |_| unreachable else |err| assert(err == ...);` which kinf of makes sense. Not using std.testing yet, will look in to that later. (Noob here.)
cren has joined #zig
dermetfan has joined #zig
marnix has quit [Ping timeout: 264 seconds]
tane has joined #zig
marnix has joined #zig
<ifreund>
marnix: fyi you should be using std.testing.expect not std.debug.assert in tests
<ifreund>
the latter will be UB in release-fast/release-small build modes if the assert fails
<marnix>
ifreund Thanks for that tip, will check it out. So what form of assert is compiled away in a release mode?
<marnix>
Because I want to use asserts in non-test code as well, without UB.
<ifreund>
marnix: std.debug.assert is just if (!ok) unreachable;
<ifreund>
hitting unreachable code is safety-checked UB
<marnix>
ifreund: Clear, thanks.
<marnix>
Ah, OK, so release-safe checks asserts. And release-fast/release-small completely ignore the asserts?
<fengb>
Yes but not just ignore. It assumes unreachable as correct and uses that for optimization
<ifreund>
release-safe keeps all of the safety checks enabled, included for unreachable code
<fengb>
So for something like “catch unreachable”, release-fast convinces the compiler that errors cannot happen and optimize accordingly
<marnix>
OK, release-fast/release-small assumes the asserted expression is true, can incorrectly optimize if it's not, hence UB. Clear, thanks!
<fengb>
Yep 👍
<shcv>
how does zig determine the type of a struct; I presume some sort of tag? Is there any way to have it hide the tag in a tagged pointer contained in the struct?
<fengb>
Types don’t have runtime representations atm
<fengb>
So you’ll have to invent your own identifier
<fengb>
Typically done with an enum of sorts
marnix has quit [Quit: WeeChat 1.9.1]
<shcv>
ok
<shcv>
has anyone done any tagged pointers?
<shcv>
I had an early draft with a packed struct of u2,u30...
<ifreund>
what's the use case?
<ifreund>
I've yet to find one where a tagged union didn't do what I want
<shcv>
well, building a hamt data structure; each entry is either {map,subtable_ptr}, {key,value_ptr}, or empty
<ifreund>
that sounds like a tagged union to me
<shcv>
so how is a tagged union represented?
<alexnask>
its an enum value + enough storage for the biggest of the possible types
<ifreund>
like the binary representation? It's undefined unless you used packed just like structs
<shcv>
since the structs are simple pointer pairs, it seems like it would be nice to have them aligned, which sounds hard to do with the extra enum tag
<marler8997>
Zig is free to reorder structs that aren't tagged with packed/extern. So if one field requires more alignment than another, it can reorder them to keep @sizeOf and @alignOf to a minimum
<ifreund>
^
<shcv>
ok; in that case I guess for flexibility I'll try the tagged union, and make it so that users can pick their desired map/key sizes, which may not be usize
<ifreund>
i'd say that a non-packed tagged union is what you want here
<ifreund>
if profiling/whatever finds a better solution than by all means change it :D
slurpie has quit [Ping timeout: 240 seconds]
<shcv>
start simple, optimize later
<shcv>
especially since I don't really know what I'm doing
<shcv>
how do I cast a []u8 to []u5?
<shcv>
or does that even make sense?
<ifreund>
@ptrCast(), but i'm not sure why you would want to?
<shcv>
well, I want to take 5 bits at a time of the key for indexing into the subtable array
<shcv>
it seemed like a good way to do it...
<shcv>
how do I print the type of something? I tried printing @TypeOf, but I think it just printed "type"... unless that is the type
layneson has joined #zig
<alexnask>
yeah fmt prints "type" for every type which is annoying
<alexnask>
Looks like `while (it) |node| : (it = node.next) if (true) count` is parsed as the lhs
<alexnask>
Ive encountered this in similar situations before as well with if
<shcv>
hmm; I don't think my cast to u5 did what I wanted it to; though I can't say I'm surprised. It ended up giving me the low 5 bits of each byte, instead of a packed u5 array
<shcv>
guess I'll have to extract 5 bits at a time manually
<tgschultz>
shcv: there is PackedIntArray in std that may be what you're looking for
<ifreund>
neat, I hadn't seen that before
<ifreund>
looks like that would do the trick
<shcv>
ooh
<oats>
is PackedIntArray only useful for non-powers-of-two ints?
<ifreund>
afaik yeah
layneson has quit [Ping timeout: 260 seconds]
dongcarl has quit [Read error: Connection reset by peer]
cren has quit [Ping timeout: 245 seconds]
<shcv>
what happens if it's a power of 2?
<shcv>
though it seems to work perfectly for my 5 or 6 bit usecase
<ifreund>
well, it would still work for things that are a power of two
<ifreund>
but it wouldn't really be worth using since those already align properly
<shcv>
even sub-byte ints?
<ifreund>
not 100% sure but I think so?
<shcv>
I guess that makes sense
<shcv>
it was probably alignment that I was dealing with
<ifreund>
I haven't really done that much bit-twidiling with zig yet, mostly higher level stuff
<ifreund>
alexnask: yo, i noticed that i'm not getting fancy semantic highlighting for the second init() call here https://paste.rs/8zn.png
<ifreund>
is this because the build option is default disabled?
<alexnask>
If you dont get highlighting for a function its because it wasnt resolved for some reason
<alexnask>
There are a couple of reasons why it couldnt have been resolved I would have to see the specific type so idk :P
<alexnask>
I could probably default to returning a "function" token in this case
<ifreund>
ah, probably cause the type also depends on this build option: https://paste.rs/tr1.png
<ifreund>
I kinda wish I had found a better way to do this
marmotini has quit [Remote host closed the connection]
marmotini has joined #zig
stripedpajamas has joined #zig
marmotini has quit [Max SendQ exceeded]
marmotini has joined #zig
layneson has joined #zig
_Vi has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 240 seconds]
radgeRayden has joined #zig
marmotini has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
marmotini_ has quit [Remote host closed the connection]
marmotini has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
<tgschultz>
shcv, ifreund: a normal array of po2 ints is still byte aligned, so if you're not a multiple of 8 you are wasting bits. PackedIntArray doesn't waste any bits.
<andrewrk>
(no worries, can always do follow up changes if necessary)
<marler8997>
yes it's ready
cota has quit [Remote host closed the connection]
dimenus has joined #zig
nikita` has quit [Quit: leaving]
Aransentin has joined #zig
<pixelherodev>
andrewrk: did you see the issue breakdown from earlier?
<andrewrk>
no, what are you referring to?
aerona has quit [Ping timeout: 246 seconds]
kristoff_it has quit [Ping timeout: 260 seconds]
dermetfan has quit [Ping timeout: 272 seconds]
<pixelherodev>
I removed clearErrors, as you mentioned, and was able to easily get the test working for ZIR
<pixelherodev>
For ZIR, the two exports are distinct, so it was just a matter of having analyzeExport clear failed_exports
<pixelherodev>
s/clear/wipe the current export from
<pixelherodev>
For Zig though? If you have `fn a() void {} fn a() void {}` there's no way of distinguishing the two
<pixelherodev>
The contents don't even matter
<pixelherodev>
The name_hashes are identical, so it's impossible to track them both separately in the decl_table
<pixelherodev>
And, thus, deleted_decls
<pixelherodev>
Which means that even if you remove the second one, there's no way to detect that it's been deleted
<pixelherodev>
I was thinking the best option was to wipe the first one from decl_table too
<pixelherodev>
So on the next update, *both* would show up as new again
<pixelherodev>
(or, if you deleted the second one, just the first one, thus resolving the error)
<pixelherodev>
Problem is, if you delete the decl, you can't map it in failed_decls :P
<pixelherodev>
And you obviously can't use an invalid pointer because then it won't be deleted
<andrewrk>
pixelherodev, ok I see. what we need to do is to have a pass that goes over a file and builds the Decl maps and checks for names
<andrewrk>
see also @panic("TODO handle missing function name in the parser");
<andrewrk>
rather than what this text says, what we'll do is build the Decl maps as part of post-process of parsing, and report missing decl names there, as well as duplicate ones. if any such errors occur, then we will fail the entire *file*
<andrewrk>
the error will go into `failed_files` and no further processing of that file will occur
<pixelherodev>
hmm, okay
<pixelherodev>
andrewrk: I actually implemented missing function names already :P
<pixelherodev>
But I'll move it to post-parsing instead :P
layneson has joined #zig
layneson has quit [Ping timeout: 265 seconds]
<pixelherodev>
andrewrk: wait, is that really worth it? I mean, if we're using failed_files anyways, why not just have it be part of the analysis pass?
<andrewrk>
sure if that works
<pixelherodev>
Worth a shot at least
<pixelherodev>
Missing decl names can definitely be part of this pass, so if the redefinitions can, it should be good
<pixelherodev>
Since decls w/o name can't be added to the table anyways, they're *always* analyzed
dimenus has quit [Ping timeout: 260 seconds]
<andrewrk>
it should be fine to mark the file as failed when encountering a duplicate name or missing name, and then skip that decl
<andrewrk>
TIL about the "red zone": "The 128-byte area beyond the location pointed to by%rspis considered tobe reserved and shall not be modified by signal or interrupt handlers.10Therefore,functions may use this area for temporary data that is not needed across functioncalls. In particular, leaf functions may use this area for their entire stack frame,rather than adjusting the stack pointer in the prologue and epilogue. This area isknown as the red zone."
<ifreund>
huh, neat
<fengb>
Oops, I took a nap. WasmPageAllocator looks good enough, and I'll probably submit in-place expand with the new interface
<fengb>
It didn't exist before, but it's now much more obvious how to do it correctly
<andrewrk>
it's so much easier to do the C ABI correctly when you're just actually doing x86_64 machine code rather than having to guess what LLVM is going to do
<andrewrk>
you know what's funny is that the per-architecture code we have to do for self-hosted isn't even wasted, even with llvm we need per-architecture code for the C ABI anyway
wootehfoot has quit [Read error: Connection reset by peer]
tane has quit [Quit: Leaving]
<pixelherodev>
and if we can actually get a C frontend working, and add some basic optimization passes for release mode?
<pixelherodev>
We can probably remove the need for LLVM even as an extension
<pixelherodev>
andrewrk: what's the behavior whena file is marked as failed?
<andrewrk>
const fn_type = module_fn.owner_decl.typed_value.most_recent.typed_value.ty; // ty ZLS <3
<andrewrk>
pixelherodev, I'm not sure what you're asking
<andrewrk>
marler8997, ooh it looks like ArenaAllocator could be improved to take advantage of extra capacity. this will make a difference when backing it with PageAllocator
<pixelherodev>
andrewrk: never mind, found the issue :P
<pixelherodev>
failed_files is never cleared
<pixelherodev>
failed_exports wasn't either, but I fixed that one
<Aransentin>
Wrote a little "competitor" to zig-window. It can create an X11 window and listen to keyboard events, no C libraries involved: https://github.com/Aransentin/ZWL
<andrewrk>
nice!
<pixelherodev>
Neato!
<pixelherodev>
I'm going to want to work on a Wayland version at some point
<pixelherodev>
... no I'm not :P
<pixelherodev>
too much to do already
<andrewrk>
Aransentin, I really want to solve the problem of providing static linux binaries that can open a window and do graphics
<andrewrk>
I think there are some problems to solve but I think it's doable
<Aransentin>
Yes, I've researched just that
<Aransentin>
With Vulkan
<andrewrk>
yeah
<companion_cube>
wait, on X, or wayland?
<Aransentin>
Both
<andrewrk>
everyone says "just use glvnd" but I want portable binaries that work on all linux distros
<Aransentin>
It's possible, yeah, but you need to use a few Vulkan exensions that aren't ubiquitous
<Aransentin>
E.g. "VK_KHR_external_memory_fd"
<andrewrk>
alexnask, ^ you and Nypsie have company
<andrewrk>
in theory it should be possible to do this without the extension too. it would involve doing some tricky dynamic linking at runtime but IMO it would be worth it
<Aransentin>
Dynamic linking to XCB or something, yes
<Aransentin>
But that's kinda lame... :P
<andrewrk>
agreed, it's lame. you would have to recognize different kinds of libcs too. like if you detect it's a glibc system then you have to do some tricks to pretend your exe is a glibc binary
<alexnask>
that sounds convoluted :P I will have to research this as well
<andrewrk>
the reward is huge though, a binary that works everywhere
<leeward>
wow, zls just pointed out that my function's name was not the right case.
<alexnask>
B)
blinghound has joined #zig
<pixelherodev>
It can do that now?!
<alexnask>
You can disable this
<leeward>
I don't want to disable it! It was right!
<alexnask>
Uhh this is the style warning that was there pretty much from the start
<pixelherodev>
Ohh whoops
<pixelherodev>
Wait
<andrewrk>
I want ZLS sound effects
<pixelherodev>
Why is that a style warning?
<andrewrk>
an "ahhhhhh" sound when I fix a zig fmt error and it goes away
<pixelherodev>
... ohh way I see what you mean
<pixelherodev>
wait*
<leeward>
FunctionName is supposed to be functionName (I had changed it from returning type)