ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
dimenus has quit [Quit: WeeChat 2.8]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
aruniiird has joined #zig
<leeward>
Should there be a GenericReader that anything that wants a reader can accept if it's willing to tolerate the overhead of runtime dispatch? It seems like writing functions that take `Reader(std.fs.File,std.os.ReadError,std.fs.File.read)` is a bit limiting.
<leeward>
It could be a part of Reader, to minimize code duplication.
<fengb>
Biggest problem with runtime dispatch is mixing errorsets
<leeward>
Does anyerror help?
nephele has quit [Ping timeout: 240 seconds]
nephele has joined #zig
<leeward>
I guess an alternative is to have every function that wants a Reader also want a type so it can specify what kind of Reader. That leads to madness: pub fn thingWithReader(ReaderType: type, reader: ReaderType)
<leeward>
No, it is. fn map(I: type, T: type, fn(I) T, iter: I) I
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
pangey has joined #zig
<marler8997>
the nice part about using generic readers in the standard lib is that you can always wrap them with a common type for runtime dispatch
<marler8997>
so it allows the application to control the trandoff between 'generic bloat' and runtime overhad
<marler8997>
man my typing is bad today
<daurnimator>
andrewrk: I saw you closed https://github.com/ziglang/zig/pull/4996 . what did you think of the idea in there of slice.len being of the relevant smaller-than-usize type?
<leeward>
marler8997: Right. I'm just suggesting that maybe that common type should be included in the standard library. Let people choose between the bloaty looking code and runtime overhead without writing as much code.
<marler8997>
leeward, gotcha, something to explore
<marler8997>
daurnimator, it took me a minute to get what your PR was doing...but now I see, that's pretty clever
<marler8997>
you're limiting the type by the "cardinality" of the element type set
<marler8997>
wait I don't think I get it anymore...what if you have an infinite number of duplicate values? Maybe I didn't get it
<daurnimator>
marler8997: max(usize) is the max number of bytes on a machine. if you have a 2 byte element, you can't have max(usize) of them.
<marler8997>
I don't understand why not?
<marler8997>
you could have max(usize) of zeros of 2-byte elements
<marler8997>
all set to zeros right?
<leeward>
Something something segmented memory?
<leeward>
Isn't usize defined as the size of a pointer?
<marler8997>
yes
<daurnimator>
marler8997: how?
<daurnimator>
marler8997: you can't have 2^64 * 2 byte elements on processor that only has 2^64 bytes of memory
<marler8997>
oh!
<marler8997>
I see now
<leeward>
I feel like I've used a processor that had different sized physical and virtual pointers, so the machine could have more than <virtual pointer size> bits of address space.
<marler8997>
I like it
<leeward>
Unfortunately, the ISA for the one I'm thinking of is proprietary and I don't have a copy. I'm probably wrong anyway.
<daurnimator>
leeward: isn't every processor like that? even x86_64 and arm64?
<marler8997>
leeward, yes that's the case for the old 16 bit 8086 processors
<marler8997>
actually modern processors boot in that mode
<marler8997>
also consider the 6502 8-bit processor, with 16K of address space
<marler8997>
I wonder how Zig's types would look on the 6502...
<marler8997>
as I think about it, I think usize would have to be 16 bits
<leeward>
marler8997: It definitely would.
<leeward>
Yeah, 8086 and successors have segmented memory, but I think physical pointers on amd64 are 64 bits...haven't checked though.
leeward has quit [Remote host closed the connection]
<leeward>
Ugh, I haven't looked at 8086 assembler since college and I don't miss it.
stripedpajamas has joined #zig
<stripedpajamas>
during zig test, is a segfault without stack trace something to report as an issue ?
<leeward>
Are you running master?
<stripedpajamas>
yes
<leeward>
seems likely
<stripedpajamas>
seems likely that it would happen or seems likely that i should report it
<leeward>
that you should report it
<leeward>
zig test runs under debug, so if you found a way to make it not dump a trace, it's almost definitely a bug
<leeward>
Unless you're doing something like -Drelease-fast
<stripedpajamas>
no release-fast
<stripedpajamas>
just normal zig test
<stripedpajamas>
will try to cut out my cruft and to demonstrate in an issue
waleee-cl has quit [Quit: Connection closed for inactivity]
emekoi has joined #zig
<andrewrk>
daurnimator, worth considering
<andrewrk>
ok, self-hosted Module.zig is getting big enough that I'm going to try out ZLS now :D
<leeward>
It works pretty well.
aruniiird has quit [Ping timeout: 264 seconds]
<wilsonk>
Woot, it took about 5 hours, but I managed to replace the keyboard on my daughters Macbook Pro 13" (A1708) and everything works!!! What a pain, had to rip out the old acetone splattered keyboard one key at a time with pliers, then pop all the rivet heads off one at a time and then super glue the keyboard back down via the rivet posts...then put it all back together. Whew.
<wilsonk>
also a hint for others...get high quality, hardened tip torx screwdrivers for that job because I managed to strip two T3 drivers and had to go buy a hardened one to finish
leeward has quit [Ping timeout: 256 seconds]
<andrewrk>
congrats wilsonk
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk>
gat damn this zls is snappy
leeward has joined #zig
traviss has quit [Quit: Leaving]
traviss has joined #zig
slowtyper has joined #zig
<marler8997>
ok I disabled all the extra assertion checks on the C and page allocator and now the drone CI is back to 30 minutes instead of 1h15m
<marler8997>
so drone must just have some fast and slow machines
_Vi has joined #zig
<andrewrk>
now that I'm willing to believe
stripedpajamas has quit [Quit: sleeping...]
<andrewrk>
oof just had to work around a nasty miscompilation :(
<pixelherodev>
Ouch
<pixelherodev>
That's always annoying
<andrewrk>
I think "no analysis/codegen bugs in stage2" is a reasonable goal to have
<pixelherodev>
For sure
<andrewrk>
where "bug" is a distinct concept from "unimplemented"
<pixelherodev>
Those should also definitely be in the test suite
<pixelherodev>
Though how to do that is unclear...
<pixelherodev>
Fuzz testing, maybe?
<pixelherodev>
Would be nice to fuzz test the parser, for instance
<andrewrk>
I just mean from an meta-organizational standpoint. if there are open stage2 analysis/codegen bugs, I think it's worth prioritizing those before working on new features
<pixelherodev>
Ahh, gotcha
<pixelherodev>
Yeah, agreed
<andrewrk>
whereas with stage1... maybe we can build a new ship before the old one sinks :)
<pixelherodev>
Going to finish up the test harness PR rn
<pixelherodev>
Hopefully tomorrow I'll get back to codegen
<andrewrk>
I'm 80% through with adding arg, block, and break ZIR instructions, function parameters, and runtime conditional branching
<pixelherodev>
Oh whoops
<pixelherodev>
Should have gotten the function parameters done more quickly :(
<pixelherodev>
I can push what I had locally to a branch if that helps?
<andrewrk>
actually if you want to take a crack at it, I left things in a good state for you
<andrewrk>
have a sec?
<pixelherodev>
What for?
<pixelherodev>
Oh yeah, just remembered that I need to rebase my function parameters stuff before I can extend it
<andrewrk>
I'm going to give you something to rebase on
<pixelherodev>
Ah, okay
<pixelherodev>
andrewrk: should I also `case.addCompareOutput` -> `case.compareOutput` ?
<pixelherodev>
The only problem there is addError...
<andrewrk>
I'm going to spend tomorrow morning preparing for showtime, so you have some time to work on the machine code stuff if you want to
<pixelherodev>
I had basic codegen
<pixelherodev>
So I can just copy a bit over and tweak it a bit
<pixelherodev>
Shouldn't be too hard to get integer parameters working at least
<pixelherodev>
andrewrk: what should be the name for error cases?
<pixelherodev>
exe/exeZir -> addExe
<pixelherodev>
_error / errorZIR -> addError ?
<andrewrk>
nearly all the compile error test cases we have use build-obj
<pixelherodev>
I mean in ctx
<pixelherodev>
not case
<pixelherodev>
The convenience wrapper that just does `addObj().addError`
<andrewrk>
compileError
<pixelherodev>
Gotcha
<andrewrk>
well, if we measure self-hosted progress by how many lines of code Module.zig is compared to ir.cpp then self-hosted is 11% done 🙃
<pixelherodev>
Hopefully we can get self-hosted to have more functionality than stage1 in a fraction of the total code (including LLVM + Clang)
<pixelherodev>
(albeit with lighter optimization passes)
<pixelherodev>
(not that that's a bad thing)
<pixelherodev>
andrewrk: to confirm, the symbol_name in a ZIR export is the name given in the binary, and the decl_name is the name of the internal symbol to reference?
<pixelherodev>
so e.g. `@0 = str("_start") \ @1 = export(@0, "start")`?
<andrewrk>
yes
<pixelherodev>
Gotcha, thanks
<pixelherodev>
Working on adding collision detection
<pixelherodev>
(so that e.g. `@1 = export(@0, "start") \ @2 = export(@0, "start")` fails)
<andrewrk>
don't forget to test it with incremental updates too
<pixelherodev>
True
<andrewrk>
for every error we gotta test getting *out* of the error state correctly with an incremental update
<pixelherodev>
Gotcha
<andrewrk>
ZLS is gonna be ridiculously fast with this design
<pixelherodev>
All exports are in export_owners, correct?
<pixelherodev>
Wait, what does this have to do with ZLS?
<andrewrk>
I mean IDE integration using this backend
<pixelherodev>
Ah, gotcha
<andrewrk>
I suggest to read the fields and doc comments in Module that match a search for "export"
<pixelherodev>
Ahh, I want to check decl_exports, not export_owners, correct?
wilsonk has quit [Ping timeout: 258 seconds]
<pixelherodev>
andrewrk: for duplicate exports, the new export should still be added, but marked as a failure, and the error added, correct?
<pixelherodev>
Got the ZIR one passing :)
cole-h has quit [Quit: Goodbye]
radgeRayden has quit [Ping timeout: 272 seconds]
wilsonk has joined #zig
<pixelherodev>
Ugh, broken on incremental compilation though :(
<pixelherodev>
Ahh, messages need to be removed from failed_* on each round of incremental compilation
marnix has joined #zig
<pixelherodev>
Got it working :D
_Vi has quit [Ping timeout: 246 seconds]
<pixelherodev>
Azure is consistently the only failing CI, and it won't let me see why ugh
<pixelherodev>
... isn't AutoHashMap(T, void) just an ArrayList(T)?
dermetfan has joined #zig
<marler8997>
I see ArrayList as an ordered collection of items, I would expect AutoHashMap(T, void) to function be an unordered set of unique items
<pixelherodev>
Ah, true
<pixelherodev>
Thanks
<pixelherodev>
Slowly getting more of the tests up and running :)
<pixelherodev>
Function redefinitions, missing function names, etc
<pixelherodev>
Ohh, Azure fails on old commits on a PR automatically when you push new ones
<pixelherodev>
Oops
nikita` has joined #zig
emekoi has quit [Ping timeout: 265 seconds]
<pixelherodev>
Ugh, can't push new changes because it'll break CI again :P
<pixelherodev>
Biggest remaining thing for that PR now is docs
doublex_ has joined #zig
nikita` has quit [Quit: leaving]
<pixelherodev>
Oh hey, I *did* push the function parameters thing to a branch
<pixelherodev>
I even opened a PR lol
<pixelherodev>
#5411 - the biggest blocker was the test harness :)
<pixelherodev>
Going to have to redo it largely, given that it's ancient in stage2 terms, and it did a refactor which it shouldn't
dddddd has quit [Ping timeout: 258 seconds]
aruniiird has joined #zig
ifreund has quit [Quit: WeeChat 2.8]
ifreund has joined #zig
aruniiird has quit [Ping timeout: 240 seconds]
<pixelherodev>
andrewrk: unless there's anything you want changed, I'm satisfied with #5708 now
<pixelherodev>
Not even going to try rebasing function-args onto master; going to just redo it instead
<pixelherodev>
#5505 is good to go, too
<pixelherodev>
CI passed :)
<pixelherodev>
`:9:12: error: TODO implement passing parameter type i32` Getting there :)
aruniiird has joined #zig
<pixelherodev>
Okay!
<pixelherodev>
Integer passing works! (i think)
<pixelherodev>
Just need to do a bit of refactoring, and add in some test cases
decentpenguin has joined #zig
dddddd has joined #zig
aruniiird has quit [Quit: Leaving]
dddddd_ has joined #zig
dddddd__ has joined #zig
dddddd has quit [Ping timeout: 260 seconds]
dddddd__ is now known as dddddd
dingenskirchen has quit [Ping timeout: 244 seconds]
dingenskirchen has joined #zig
dddddd_ has quit [Ping timeout: 246 seconds]
<pixelherodev>
Heh
<pixelherodev>
Working with Zig now with stage2 reminds me of my custom backend lol
<pixelherodev>
Using @ptrToInt for strings, for instance :P
dddddd has quit [Ping timeout: 256 seconds]
r4pr0n has joined #zig
dddddd has joined #zig
<pixelherodev>
Working with ZIR is already so pleasant :)
<marler8997>
why's that?
<pixelherodev>
Everything just works
<marler8997>
what backends is zir starting out with? x86_64? i386?
<pixelherodev>
x64, for now
<pixelherodev>
There's some x86 in place as well, since they share some code
antaoiseach has joined #zig
<pixelherodev>
But x86 isn't actually usable at all, since some basic codegen isn't in place for it
<pixelherodev>
It'd be really straightforward to add though
<marler8997>
gotcha
heitzmann has quit [Quit: WeeChat 2.8]
heitzmann has joined #zig
<antaoiseach>
Do you guys know if any third party people generate llvm+lld+clang, specifically for macOS? The one from homebrew does not work, and my machine cannot handle building from source.
<antaoiseach>
Right now I'm making do with the master binary, but I wish to resume building from source (if possible without waiting for LLVM 11!)
<antaoiseach>
(I've asked this question over on #llvm as well, awaiting response :-))
<pixelherodev>
There we go! `:49:19: error: expected usize, found *const [14:0]u8`
<antaoiseach>
Second question - for a general purpose library, which existing allocator would you recommend? I'm leaning towards arena allocator, but not sure if that's the best choice - memory requirements similar to something like a json library, say
<ifreund>
antaoiseach: usually zig libraries accept an allocator from the user
<marler8997>
if it's a library, usually you just take an allocator from the client/application so you don't need to choose one
<ifreund>
you can of course wrap that allocator in an arena if it makes sense though
<antaoiseach>
ifreund: marler8997: ah yes, that's right
<antaoiseach>
I was mixing up the client side of it as well
<antaoiseach>
So in case I also provide a parser of sorts that would read in a bunch of text and use the core lib ... in that case?
shcv has joined #zig
<mq32>
marler8997: it was a mistake to watch the allocator issue…
<shcv>
what's the best way to substitute characters in a string? E.g. "-" -> "_" for compatibility with stringToEnum
<ifreund>
arenas are a good choice when you build up a bunch of allocations and want to free them all at once
<antaoiseach>
ifreund: yes, that's my line of thinking as well ... might as well munge everything and then free in one go ... don't expect any OOMs too! :-)
<antaoiseach>
thanks!
<antaoiseach>
By the way ... looking forward to the next zig show touching upon allocators... that should be useful as well!
<marler8997>
m32...lol
<mq32>
i just want to know when it's merged! :D
<marler8997>
mq32, well I've pretty much finished, now just need andrewrk to review
<mq32>
yeah, i've been reading here :D
<mq32>
i wish github had an option to watch only creation/closig/merging of issues/PRs
<antaoiseach>
mq32: agreed ... the current watch settings on github are annoying at best
antaoiseach has quit [Quit: Changing server]
<mq32>
yep
<mq32>
but hey
<mq32>
we got a new layout…
<shcv>
is there anything like destructuring, to assign elements of a slice to multiple variables?
<ifreund>
not currently, no
<ifreund>
though I believe there are a few open proposals for something like that
antaoiseach has joined #zig
<antaoiseach>
Hey folks, another quick question. I downloaded the llvm-all-in-one from the official releases pages, set compilers to gcc-9 and g++-9, and then I run into errors such as this one:
<antaoiseach>
src/zig_llvm.cpp:1299:73: error: 'AVR_SIGNAL' is not a member of 'llvm::CallingConv' 1299 | static_assert((CallingConv::ID)ZigLLVM_AVR_SIGNAL == llvm::CallingConv::AVR_SIGNAL, "");
<antaoiseach>
Anybody have an idea what is wrong?
<antaoiseach>
I simply used the commands `cmake .. -DCMAKE_PREFIX_PATH=<path to local download>; make install`
<leeward>
I think the error you quoted is because you need -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="AVR"
<leeward>
in the cmake command for llvm
<antaoiseach>
leeward: I've already got a binary of llvm+lld+clang ... I'm trying to compile the zig part now. You're right about those flags, but they're needed if building llvm or clang from source, right?
<antaoiseach>
That may point to the issue though - maybe these releases are built without those flags turned on? Hmmm... well, that would suck
<leeward>
Yeah, that's what it sounds like.
<antaoiseach>
okay, that's too bad for me.... I dare not try building clang and llvm themselves from source. My poor old machine couldn't handle it. No worries, will make do with the zig binaries for now... thanks!
<leeward>
no problem
antaoiseach has quit [Quit: leaving]
<leeward>
I actually built llvm and clang from source on a raspberry pi last weekend. It did take the whole weekend :P
<shakesoda>
i envy such patience
<leeward>
Didn't take much of my time; I just kicked it off and left.
marnix has quit [Ping timeout: 240 seconds]
cren has joined #zig
<pixelherodev>
andrewrk: got a present for you ;)
<pixelherodev>
Function args work in ZIR now :D
<pixelherodev>
Just need to rebase the branch...
doublex_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
#5411 woo
aruniiird has joined #zig
<aruniiird>
compiling zig from source is failing for me... (did created build directory. from build directory did `cmake ..` and `make install`)
<aruniiird>
is it a known issue
<pixelherodev>
could be, can't know without more info
<leeward>
What OS are you building on?
<leeward>
Did the error message mention LLVMPolly.so?
<scientes>
except very few distros are interesting
<leeward>
SUSE uses RPMs.
<scientes>
and very few distros are maintained
<leeward>
fengb: That tree has BSDs on it.
<fengb>
I can't even read it
<antaoiseach>
hello again, folks ... have a few broad design questions: 1). We can use generic functions to simulate trait-like functionality to some extent - true/false, to what extent? 2). `zig init-exe` and `zig init-lib` can be used create bare project templates, and we can also combine lib+exe functionality by tweaking build.zig. Is this correct? 3). About project structure, the stdlib seems to have a general
<antaoiseach>
pattern of `foo/bar.zig` which may call `foo/bar/bar.zig` .. is this idiomatic? How would you resolve directory structure vis-a-vis modules, and finally 4). free functions or methods (well, functions nested within structs/unions/etc. oop style)?
<fengb>
So no idea what's going on in there
<leeward>
2: yes
<antaoiseach>
cool!
donaldallen has joined #zig
<leeward>
4) whatever's most appropriate for your interface
<antaoiseach>
leeward: that looks quite promising... thank you!
<leeward>
Short version of 1: yes-ish
<leeward>
3) The stdlib is as idiomatic as Zig code gets these days. Note that, e.g. mem.zig has public declarations of things in mem/
<antaoiseach>
leeward: yes indeed
<donaldallen>
I would like to create an array of string literals. My reading of the documentation tells me that "hello" and "goodbye" are different types, because they have different lengths. And arrays seem to be of a single type.
<antaoiseach>
I was thinking of following the same idiom ... not sure if the indirection is worth it
<antaoiseach>
maybe cleaner
<leeward>
donaldallen: use slices
<donaldallen>
But on a hunch, I tried const test_array = .{"hello", "goodbye"}; warn("test_array: {}\n", .{@typeName(@TypeOf(test_array))}); warn("test_array[0]: {}\n", .{test_array[0]});
<donaldallen>
This produces the output test_array: struct:94:25test_array[0]: hello
<antaoiseach>
leeward: that link is exactly what I was thinking about - but with a better concrete example... this should prove very useful for me! :-)
<leeward>
antaoiseach: The mechanism in the link definitely adds some runtime overhead.
<antaoiseach>
yes ... but looks much cleaner and understandable!
<donaldallen>
Much to my surprise. Is this documented anywhere? I may have missed it, certainly, so if you can point me to where this is discussed, I'd appreciate it.
<fengb>
There should be a segment on how `*[N]T` automatically coerces into `[]T`
<donaldallen>
Ah -- I will have a look. Thank you.
halbeno has quit [Remote host closed the connection]
halbeno has joined #zig
opDispatch has joined #zig
antaoiseach has quit [Quit: leaving]
emekoi has joined #zig
wootehfoot has joined #zig
antaoiseach has joined #zig
<antaoiseach>
I have a probably dumb question, but here goes - why is it that we can coerce a bigger alignment value into a smaller alignment, but not vice versa?
<pixelherodev>
If something is 16-bit aligned, it's also 8-bit aligned, definitionally
<pixelherodev>
Something that's 8-bit aligned might not be 16-bit aligned
doublex_ has quit [Ping timeout: 240 seconds]
<pixelherodev>
etc
<fengb>
Example: a byte is align(1). A pointer is align(8). We can always directly map the pointer into raw bytes, but going from bytes to a pointer requires alignment concerns
<antaoiseach>
Wow ... that was a dumb question indeed!:D ... hahaha, yeah, I should have thought that through
<antaoiseach>
Makes perfect sense... thanks, folks!
<antaoiseach>
Okay, maybe a better question this time ... do we have any standard serializer/deserializer in the stdlib?
doublex_ has joined #zig
<antaoiseach>
I found something in io/serialization.zig, not sure if that can be used ... will try it out in any case
<antaoiseach>
yes, looks promising
slowtyper has quit [Ping timeout: 246 seconds]
slowtyper has joined #zig
<tgschultz>
why would you think it couldn't be used?
<antaoiseach>
tgschultz: That was me jumping the gun there - I'd thought that that was an internal-use only module, but the test cases (which are excellent!) show otherwise :-)
<antaoiseach>
yes, this should suit me quite nicely indeed
<tgschultz>
glad to hear it
<antaoiseach>
cheers!
<pixelherodev>
The big blocker for function params in Zig source now is local variable lookups
<pixelherodev>
I haven't worked with the Zig-specific parts enough to do that quickly
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
cren has quit [Ping timeout: 245 seconds]
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
nrdmn has joined #zig
waleee-cl has joined #zig
<nrdmn>
mq32: you had trouble building zig on gentoo, right?
<nrdmn>
Zig 0.6.0 currently does not build on gentoo and I've written down why that is. In case someone else is affected.
<nrdmn>
Unfortunately gentoo's llvm/clang/lld maintainer doesn't like the idea of including arch linux' workaround to the issue discussed at https://reviews.llvm.org/D75579 and shipping lld's .a files
<pixelherodev>
So I've heard.
<pixelherodev>
It's why I don't use their ebuilds.
<nrdmn>
:/
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
antaoiseach has quit [Quit: leaving]
donaldallen has quit [Remote host closed the connection]
<shcv>
nrdmn: thanks for the notes, that addresses most of what I ran into when trying to build on gentoo the other day
<shcv>
I eventually gave up when someone reminded me that there were binaries available :P
<shcv>
zig's build system is so much nicer (so far anyway) than llvm+cmake; thanks for all the work guys
<leeward>
shcv: If you want to know more about it, pixelherodev did some streamy stuff about how it works a little while ago. He can probably tell you where to find it.
<ifreund>
one thing I have yet to figure out is if there is a good way for my custom steps to take advantage of the artifact caching system
<ifreund>
right now I write the custom step artifacts to directories ouside of zig-cache and then use installFile(), but I think this results in the steps being rerun every build regardless if something changed
cren has joined #zig
alexnask has joined #zig
<alexnask>
Now that we have @Type for error sets, I made an "error dispatcher" which lets you narrow down your error types and update the type of the error at comptime
<alexnask>
This relies on a couple of tricky comptime concepts, here is the link if anyone is interested: https://zig.godbolt.org/z/p6Y_vE
aruniiird has quit [Ping timeout: 265 seconds]
<alexnask>
I recall people discussing something like this for a language feature in this channel
cole-h has joined #zig
<leeward>
We have @Type for error sets?
<leeward>
I have to update!
cren has quit [Ping timeout: 245 seconds]
<ifreund>
wild
casaca has quit [Remote host closed the connection]
<shcv>
ifruend: maybe we could make a wrapper around the custom steps, like memoizing a function? hash the inputs, store the outputs in the resulting hash location?
<shcv>
that would give you a target directory to store the artifacts in too
<shcv>
I guess I should read more about how the current build system works
<shcv>
er, sorry for mispelling your name, ifreund
<ifreund>
the current system already does that for zig files afaik
<ifreund>
but I didn't find an easy way to tie into that last time I poked at it
<alexnask>
The cache hash api is in std btw so you could probably do it
<shcv>
one thing I noticed while reading cache_hash.zig was that the digest len is supposedly 24, but the cache files seem to have a much longer digest; any reason for that, and where is it set?
<ifreund>
I'm sure I could do it, but ideally it should be as easy as calling one extra Builder function or something
<ifreund>
it's not really worth my time to implement it just for my project, if I were to dig further I'd try to add it in a generic way
<alexnask>
Sure
<alexnask>
shcv, hm looks like the C++ implementation uses 48 byte digests (aka 64 bit base64 digests) while the stdlib one uses 24 bytes aka 32 bytes of base64
<alexnask>
I thought they were compatible
<alexnask>
Guess not
decentpenguin has quit [Quit: decentpenguin]
<shcv>
interesting
<shcv>
where's the cpp version?
emekoi has quit [Ping timeout: 240 seconds]
<alexnask>
src/cache_hash.cpp
<shcv>
just found it
<shcv>
thanks
<shcv>
when is each version used?
<shcv>
looks like the cpp version is blake2b, whereas I think the zig version claims to be blake3
<alexnask>
ah could be, didnt notice it >.>
<alexnask>
Only the c++ version is used atm I believe
<alexnask>
this was a port to start self hosting some of this stuff which is why I thought it was compatible
<alexnask>
But I guess it doesnt actually need to be (beyong the dir structure)
casaca has joined #zig
<shcv>
makes sense
<shcv>
with format we can print a buffer in hex, etc.; how does one parse a hex string? I only see individual parseInt, etc.
<alexnask>
{x} and {X} will print in hex I believe
<ifreund>
shcv: parsInt takes a radix
<ifreund>
so you can pass 16 to parse in hex
<shcv>
so, I guess I can approximate a short buffer with e.g. u256?
<ifreund>
i'm not sure why you would want to use that over a [8]u8 but sure
<ifreund>
er, [32]u8 i guess
<shcv>
the test cases don't show an array example
<shcv>
does math.add work with arrays? probably not the most efficient way to do it...
<ifreund>
this is for parsing an int?
<leeward>
Huh, a funny problem: when I use ZBS to generate things depended on by Make, the cache can cause stuff to not get rebuilt. I built my .a file with -Drelease-fast and -Drelease-safe, and when I switch between the two the .a file I see in my output_dir does change, but its timestamp is from when it was originally built.
<shcv>
well, parsing a hex-encoded digest
<leeward>
I guess the easiest way to deal is to touch it.
<shcv>
interesting...
<shcv>
maybe it would be useful to have ZBS touch the files automatically?
<ifreund>
well, it kinda depends on what output form is most convient for whatever you want to do with it
<marler8997>
I bet it is hashing the source and seeing it was already built, then it just copies it from the cache which has the old timestamp
<marler8997>
this is an issue for Make, because it assume that if an input file has an older timestamp than an output file, then the output file must be up-to-date
<leeward>
shcv: It might be. Worth thinking about, anyway.
<marler8997>
ZBS could update the timestamp of any file that it copies out of the cache
<shcv>
since it's a new copy of the files in the output dir, it doesn't seem unreasonable
<shcv>
ifreund: I was probably going to use it as a [32]u8, but if u256 has better / faster support for comparison operators, etc., that might actually be better
<ifreund>
only way to know is to try both and benchmark :D
<leeward>
shcv: It ought to at least be more natural to write code with a u256. I wouldn't depend on the implementation being awesome yet, but this feels like a "one obvious way to do it" kind of thing.
<shcv>
are there any benchmarking utilities?
<leeward>
shcv: std.time includes a microsecond timer.
<shcv>
I'll try the u256; I do really like that zig supports arbitrary bit sizes, so I might as well take advantage of it
<ifreund>
yeah it does work if I use a block for the while
dimenus has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
slowtyper has quit [Ping timeout: 260 seconds]
<shcv>
I guess I'll put using u256 on hold for now, until it can be handled directly by std.fmt; otherwise I have to keep juggling the endianness
<shcv>
and converting back and forth between [32]u8; might as well stick with [32]u8
<fengb>
Just assume little endian :P
<fengb>
There's mem.readInt that'll do endian processing for you
<shcv>
the problem is that english is mixed endian; printing a [32]u8 is effectively big endian, the opposite of a bitcast to u256
cole-h has quit [Quit: Goodbye]
andrewrk has quit [Ping timeout: 256 seconds]
andrewrk has joined #zig
waleee-cl has joined #zig
ifreund has quit [Quit: WeeChat 2.8]
<alexnask>
http://prntscr.com/t773mz <- just a screenshot of zls-only highlighting with lots of colors I use for testing :P
<leeward>
That is a lot of colors.
<alexnask>
:-) Should have shoved a label into there too I use a yellow for that :P
<andrewrk>
so beautiful 😍 😍
<andrewrk>
what editor is that?
<alexnask>
VSCode
<mq32>
alexnask: nice, so semantic highlighting is going well?
<alexnask>
Yeah its been done for a while ;) I only need to correctly add a couple of modifiers like async and generic and some extra details
<alexnask>
Im working on renaming rn
<mq32>
whoo
<andrewrk>
this is probably enough to make me switch to vscode
<shakesoda>
vscode + zls has made using zig a lot better
<alexnask>
lol, what, the rendering? :P The semantic tokens will work in all editors that support LSP once the next version of the protocol comes out
<alexnask>
(already supported in a couple but not coc which is the main vim lsp client)
<andrewrk>
btw I tried vim+coc+zls "go to definition" yesterday but it was unavailable
<alexnask>
hm Ill give it a shot I have an install
<leeward>
I've been using ZLS with Emacs and it works very nicely. Not that anyone else in the world would be caught dead using Emacs.
<alexnask>
I have so many editors installed now >.<
<shakesoda>
i run into things that won't complete a lot though :(
<shakesoda>
mostly cimport stuff
<alexnask>
cImport is not supported yet yeah
<mq32>
andrewrk: i'm not sure if it's worth switching to vscode for you, but it's wort a shot
<mq32>
i've seen you using vi like i never could :D
<andrewrk>
dvorak+vim does have some interesting one-handers
<shakesoda>
not usually troublesome for pure zig although i regularly have problems with getting the completion to come back once vscode has decided it doesn't want to show me the signature of something anymore
<shakesoda>
seems like a vscode issue but i don't know the implementation details
* leeward
dvoraks the Emacs
<leeward>
andrewrk: You use dvorak?
<andrewrk>
yep, at this point been using it longer than qwerty by several years
<shakesoda>
it's like it thinks i can remember the thing it was telling me :(
<leeward>
I think that makes...4 people I know, for certain values of know.
* mq32
quertzes all the way
<leeward>
I've been using dvorak since 2001. Not the best decision I've ever made.
THFKA4 has left #zig ["WeeChat 2.4"]
<shakesoda>
i used dvorak for a while but it didn't net me enough to deal with the mapping problems chronically
<alexnask>
I think I had trouble getting coc to jump to definitions over import boundaries too
<alexnask>
But I dont recall
<leeward>
Switching back and forth is the worst. I have a bash alias on computers I need other people to be able to use: aoeu -> setxkbmap us; asdf -> setxkbmap dvorak
<alexnask>
exaclty what the issue was
<shakesoda>
leeward: i like that
<shcv>
I use colemak and emacs
<leeward>
shcv: You fiend
<leeward>
Never tried colemak; switching keyboard layouts once was painful enough.
<shcv>
yeah; I made the poor decision to switch like a month before my GRE, which turns out to be on a provided computer, and involves an essay...
<andrewrk>
damn, I have to send my laptop into dell to repair a swollen battery
<andrewrk>
that's going to be annoying not having this machine
<leeward>
That's...not awesome.
dermetfan has quit [Ping timeout: 240 seconds]
<shcv>
:(
<leeward>
The battery isn't removable?
<andrewrk>
maybe I'll try to get more comfortable with windows ;)
* leeward
shudders.
<alexnask>
Time to install wsl2 :P
<andrewrk>
image search for "battery swelling trackpad"
<shcv>
lol
<leeward>
Fun times.
<shcv>
but no, I wouldn't want to develop on windows... I use exwm and emacs all the things
<mq32>
andrewrk: no getting comfortable with windows once you've mastered the ways of the shell
<leeward>
I have a windows machine for work, because Lotus Notes. WSL is...kinda ok.
<r4pr0n>
LSW though
<shcv>
lotus notes? I didn't know it was still a thing
<leeward>
You mean WINE?
<leeward>
shcv: Neither did I!
<r4pr0n>
WSL => wine
<leeward>
I like how it's called Windows Subsystem for Linux, but so many distros make such a big deal about how it's GNU/Linux. Linux is the only thing that's missing from a GNU/Linux install on WSL.
<marler8997>
leeward true, but it's "emulating" the linux kernel syscall interface
<leeward>
marler8997: That's exactly what Wine does in reverse. Don't call it an emulator though.
<marler8997>
meaning any OS coded for linux should work, not just gnu
<leeward>
What does WSL2 do?
<nycex>
I use musl/busybox/linux
<shcv>
would be funny to run WINE on WSL then
<marler8997>
wsl2 is basically a VM, so you can load your custom kernel instead of emulating a kernel syscal interface
<alexnask>
wsl2 is a vm
<leeward>
Well that's...why didn't they do that in the first place? VMs already existed and didn't need anyone to write a whole userland interface shim.
<mq32>
WSL2 is just a VM
<marler8997>
yeah you could totally run WINE on WSL, I've worked on project that did similar things, even went 3 levels deep in places
<mq32>
WSL1 isn't a userland shim though
<leeward>
Does that mean I can run OpenBSD on WSL2?
<mq32>
afaik the kernel is actually emulating the syscalls in WSL1
<mq32>
which is quite awesome
<leeward>
marler8997: You're making me sad.
<marler8997>
I'm not too familair with OpenBSD...isn't it a bsd kernel?
<leeward>
It is.
<mq32>
wine is just a PE loader + replacement libs with syscalls
<mq32>
so wine is not an emulator while WSL is
<marler8997>
I doubt it would have the same syscall interface as linux
<leeward>
If WSL2 is just a VM, can it run other kernels?
<marler8997>
WSL1 is just an implementation of the linux syscall interface
<leeward>
Oh, I didn't realize WSL1 was implemented in kernel space.
<marler8997>
leeward good question, I don't know that one
<alexnask>
running windows 10 in wsl2 is the true big brain move
<leeward>
alexnask: They do it for speed.
<mq32>
alexnask: while running linux instead of windows 10? :D
<shakesoda>
i don't think it's accurate to call virtualization emulation
<mq32>
first one uses the same processor as the host, no instruction translation used
<leeward>
Yeah, if the guest and host machines are the same type.
<mq32>
second one actually JITs the CPU
<mq32>
otherwise it's nt virtualization :D
<andrewrk>
oh neat somebody posted zig showtime to HN
<leeward>
nifty
<marler8997>
going to have to port my wsl-register code to Zig...
<nephele>
WSL2 is the linux kernel... on the vm windows already has and uses nartively :D
<nephele>
also, running wine on WSL2 makes perfect sense... with windows caring less about backwards compatibility (and dx9 -> opengl giving better performance than dx9 comparitively, so that could be used on win potentially)
blinghound has joined #zig
blinghound has quit [Remote host closed the connection]
<shcv>
should I try to implement a full ctrie, or just a hamt?
ifreund has joined #zig
<shcv>
a ctrie has the advantage of better concurrency support I guess; hamts are simpler though
<mq32>
what is both?
<shcv>
they're k/v stores like hash tables, but designed to work well in immutable, data-sharing contexts
<marler8997>
andrewrk, I've finished working on new allocator interface PR. It's ready to merge. The last 3 pushes were final touches and all 3 fully passed all CI tests. Please have a look when you find the time.
<shcv>
a HAMT (hash array mapped trie, https://en.wikipedia.org/wiki/Hash_array_mapped_trie) uses a trie of sparse arrays kinda a lookup table, with each node storing up to 32 items / ~6bits of key, and a bitfield to indicate which of those items are actually present
<mq32>
oh neat
<shcv>
the ctrie (https://en.wikipedia.org/wiki/Ctrie) is extended with better compatibility with atomic swap operation; I still don't fully understand it though
<mq32>
ctrie sounds sexy
* mq32
likes tries
<andrewrk>
marler8997, brilliant
<shcv>
apparently there hasn't been much work on non-GC ctries
<pixelherodev>
andrewrk: ... oops. That clearError thing is going to be annoying...
<fengb>
Great, do I need to update my slides already? :P
<andrewrk>
lol perfect timing
<andrewrk>
fengb, that's what you get for not procrastinating. I haven't even started my slides yet
<marler8997>
it records execution so you can play it back? wow sounds cool
<andrewrk>
you can even play it back in reverse
<andrewrk>
get to a failure state, then set a breakpoint, then rewind until you hit it
<andrewrk>
or get to a failure state, set a memory watchpoint, then rewind until you hit it
<andrewrk>
it answers the question, "how did this data get set to [unexpected value]?"
<marler8997>
that's a really good idea
<pixelherodev>
andrewrk: the "looking at just one line of code" thing was impressive TBH :)
<pixelherodev>
Hmm, instead, I should just clear *modified* decls?
<andrewrk>
that already happens
<andrewrk>
marler8997, oh nice, you integrated malloc_usable_size
<pixelherodev>
... then I'm suddenly very confused what the error was.
<pixelherodev>
This'll be fun
<andrewrk>
look at markOutdatedDecl, it removes the error for it
<pixelherodev>
I'm not doubting you lol
<pixelherodev>
ohh
<pixelherodev>
andrewrk: idea: did you not hook that up for Zig sources yet?
layneson has joined #zig
<pixelherodev>
... wait no, this is happening in a ZIR case
<marler8997>
yeah it was easy to implement malloc_usable_size with the new interface
<andrewrk>
pixelherodev, I don't think it's worth supporting incremental updates for ZIR modules
<andrewrk>
just .zig source
<andrewrk>
I'm pretty sure ZIR is just going to be an implementation detail + debug tool, not a stable API or ABI for third party applications
<andrewrk>
and release builds will ship with ZIR support comptime-disabled, to improve binary size and perf
<pixelherodev>
I think it's worth it for testing at least
<pixelherodev>
Even if we disable it in proper builds
<pixelherodev>
It makes it easier to make sure everything's hooked up properly
<andrewrk>
there's a non-trivial surface area that is required to make incremental compilation of .zir files work, which does not overlap with making it work for .zig source
<pixelherodev>
So I should disable the tests? (and, in a separate PR, nuke incremental ZIR support?)
<pixelherodev>
well actually, the exact same issue occurs with Zig code *and* ZIR
r4pr0n has quit [Quit: r4pr0n]
r4pr0n has joined #zig
<pixelherodev>
retraction of the retraction, the ZIR test passes
<pixelherodev>
It's only the Zig one that doesn't
<pixelherodev>
:P
<pixelherodev>
orrr not? Whatever, I'mma just fix it.
wootehfoot has joined #zig
* pixelherodev
faceplams
<pixelherodev>
facepalms*
<pixelherodev>
I'm an idiot
<pixelherodev>
Forgot to set the export's status to failed
<andrewrk>
you're not an idiot, we just need better debugging infrastructure that make the state of everything more obvious
<mq32>
zigdbg when?
<andrewrk>
in my experience nearly all debugging difficulties are lack of observability / intuition about state
<andrewrk>
and I don't think it's something that can be solved generically
<andrewrk>
that's why we have a text based ZIR format in the first place
<andrewrk>
it's an investment in debugging the compiler