ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk> alright great, that was a roundabout way to do it but array literals with inferred size are now working in the copy elision branch
<andrewrk> just a few more expression types and then I'm on to fixing regressions / getting the test suite passing
<andrewrk> it's only been 1 week... last attempt took 2 months until I was at the point of trying to get tests passing
<scientes> that's when you know you are doing it right :)
<scientes> the irony of good software it that is seems easy
<andrewrk> yeah. also people who are intelligent, charismatic, and talented communicators, seem like they aren't doing anything
<andrewrk> they explain something to you and it feels like you knew it the whole time
<scientes> that's why I pay for a subscription to LWN
curtisf has joined #zig
<curtisf> What's the best way to return extra information with an error? e.g., a parse function returning the position that parsing failed at
<scientes> i just use a return pointer, as is common in C
<scientes> but there are problems with that, and I think Zig should have multiple return values
<scientes> you can also return a struct, which is the "correct" way to do it
<scientes> but is kinda cumbersome
<curtisf> Right now I am returning a tagged-union, but that means I can't use "errdefer" for the parse error case
<scientes> then you have to pass a pointer and write to that
<curtisf> OK, that's the next best thing I could think of, but I didn't really like it
<scientes> yeah its not correct, because they can't mark the function "pure" or "const"
<scientes> (even if there is no support for that yet)
<scientes> curtisf, you could also return a struct, and then do manual error handling
<scientes> I'm wondering if zig might allow return values with error
<curtisf> That would be nice
<scientes> if you can think of a good syntax open a bug
<scientes> I can't think of a good syntax
<scientes> except maybe giving return values a name, like in go
<scientes> and if its a pointer, you can't do that
<curtisf> maybe it could be associated with the error itself instead of the function -- that would also possibly simplify inference / passing errors up
<scientes> so its complicated
<scientes> perhaps the first return value gets bound to the error
<scientes> but that is ugly
<curtisf> error { CouldNotAlloc, LexExeption: struct {offset: usize}, ParseException: struct {offset: usize, expected: []const u8} }
<scientes> that is kinda dangerous
<scientes> but it would work
<curtisf> what do you mean by dangerous?
<scientes> well errors are suppose to be rare
<scientes> they are marked as unlikely to the branch predictor
marijnfs has quit [Ping timeout: 258 seconds]
marijnfs has joined #zig
<emekankurumeh[m]> or allowing tagged unions to use errors as the tag value
<scientes> ^^
THFKA4 has joined #zig
<tgschultz> yeah, and !? where the type is not a pointer should be a single tagged union too.
<tgschultz> so.. I guess also allowing null to be part of any tagged union
<curtisf> well, I wrote up what I was thinking into an issue. I'm not really a Zig/C programmer so maybe everyone will think I'm crazy but it's done :)
<tgschultz> it is useful to have feedback from people who are not used to thinking inside zig's conventions.
curtisf has quit [Ping timeout: 256 seconds]
<hryx> There is an unfortunate... union?.... in the clang::APValue class making it difficult to redefine in plain C: https://clang.llvm.org/doxygen/APValue_8h_source.html#l00229
<hryx> If anyone has tips on how to define a struct which is the same size as this APValue class (preferably without including a bunch of clang/LLVM headers), lemme know
<hryx> I suppose each of the constituent types could be redefined as plain structs, then make a regular union out of them. Lots of overhead but might be less horrible than what I was just doing
<scientes> hryx, yeah llvm doesn't have unions, so i haven't figured outhow they work either
* daurnimator waves
<scientes> hryx, yeah i think the overlapping structs with bitcast between is the correct solution
<scientes> but def. check what clang outputs
* scientes waves back
<andrewrk> hryx, you can check the sizeof() and then just use something aligned enough followed by an array of chars that makes the size correct
<andrewrk> the only important thing for the pseudostruct is getting the size & alignment correct
<scientes> yeah but not all arches use natural alignment
<andrewrk> I really don't think that's going to be an issue
<andrewrk> 99% chance it's just aligned to a long
<scientes> well it won't be a general solution, but sure
<andrewrk> it doesn't have to be a general solution. just trying to get a C API on top of a C++ API
<scientes> oh yeah for that it is fine
<scientes> I thought he was doing translate-c
<hryx> andrewrk: I think I see -- so include APValue.h in zig_clang.h, then define this thing to be sizeof (clang::APValue) ?
<hryx> note that so far no llvm/clang headers have needed to be included
<andrewrk> hryx, no I mean determine the size experimentally then just hard code it with that static_assert for safety
<hryx> ah. The size won't be different per-platform?
<hryx> that's a cleaner solution fo sho
<andrewrk> if that's the case then the per-platform logic has to go into the .h file and clang.zig. the static_assert will generate a compile error if it turns out to be different per-platform
<scientes> there isn'y really a super-clean solution, because no-one wants to support c++....
<hryx> ok great. luckly we have CI to test different platforms
<andrewrk> yeah as long as ABI issues are easy to debug, I think we're good
<andrewrk> just don't want a mystery bug
<scientes> I think the cleanest solution would be to add what we need to c-llvm and c-clang
<andrewrk> I think a lot of zig_llvm.h/cpp has been added to llvm C API now and can probably be removed. as far as I'm aware clang C API is still worthless
<scientes> but get it working first
<daurnimator> Interesting to see the [_] syntax got merged
<scientes> zig_llvm.h is very good
<andrewrk> daurnimator, yep, needed it for copy elision branch
<daurnimator> andrewrk: I'm happy to see the TODO list for copy ellision part 1 is getting very small :)
<scientes> I don't think I funny understand how comptime arrays are stored.
<scientes> fully
<scientes> like is this a vector of pointers? TypeStructField *fields;
<andrewrk> scientes, that's for the type of a struct
<andrewrk> it sounds like you're talking about ConstExprValue x_array
<scientes> well i'm doing both
<scientes> ahh yes ConstArrayValue x_array;
<scientes> how do i get the spacing in that array?
<scientes> oh of course I just use DataLayout
<andrewrk> I'm not sure what you're asking
<scientes> well how do i dereference the array items
<scientes> i have to know their size
<scientes> in LLVM you do DataLayout::getABISize() or something like that
<andrewrk> in zig ir.cpp? const_ptr_pointee
<andrewrk> you should look at an example that does this because there are some gotchas
<andrewrk> e.g. the pointer type can disagree with the element type, and you have to call a function to resolve it ( this is how comptime pointer casting works)
<daurnimator> andrewrk: #2525 should be good to merge now
<andrewrk> thanks
<daurnimator> indentation in just merged 6c160b8856921e5e1d0a437794b3b7ee7e1a4d0b is weird
<andrewrk> fixed
<daurnimator> thanks :)
<daurnimator> andrewrk: thoughts on #2424 ?
<daurnimator> uh.... so I think that merged fix for empty while loop bodies is wrong?
<daurnimator> oh wait no. I just had a stray semicolon
<andrewrk> the data structure looks good but I still don't like the std lib reorg. I don't think anything is gained with the linked_list namespace, and I don't like LinkedList renamed to TailQueue
<daurnimator> andrewrk: how else should we have multiple different types of linked lists?
<andrewrk> I'd be fine with std.LinkedList, std.SinglyLinkedList, std.ArrayList
<daurnimator> andrewrk: ==> std.LinkedList is a tailqueue though: there are many differnet ways to implement a doubly linked list; with different tradeoffs.
<andrewrk> pardon my ignorance but what are some of those ways other than struct { head: ?*Node, tail: ?*Node} and Node = struct {prev: ?*Node, next: ?*Node }
<andrewrk> I just searched duck duck go for "tailqueue" and the first page of results has nothing
<daurnimator> andrewrk: 1. whether you keep the tail in the head at all. 2. whether you make it circular so that the tail's 'next' points back to the head. 3. XOR linked list.
<daurnimator> andrewrk: huh? I search on DDG and it's the first result... and 3rd, 4th, 5th
<andrewrk> oh I see this: https://linux.die.net/man/3/queue
<daurnimator> the first result being https://linux.die.net/man/3/queue
<andrewrk> TAILQ, CIRCLEQ
<daurnimator> andrewrk: TAILQ is the traditional C macro to make a tail queue.
<andrewrk> got it
<andrewrk> let me ask you this, are you on board with having these abstractions all with nice names and directly under the std namespace?
<andrewrk> I'm fine with TailQueue given that there is this clear prior work and established name
<daurnimator> I'd be okay with that. Though it would make more sense to me to have all the different linkedlist implementations under a 'linked_list' namespace
<daurnimator> std.linked_list.{TailQueue,SinglyLinkedList,CircularQueue,XORLinkedList}
<andrewrk> std.linked_list.SinglyLinkedList and std.linked_list.XORLinkedList are redundant
<daurnimator> ?
<daurnimator> oh you mean "linked list" in the name
<andrewrk> "linked list" is both in the namespace of those and the type name of those. that's redundant which means the namespacing is not quite right
<daurnimator> would `std.linked_list.XOR` make sense though? to me that suggests that it's some XOR operation over linked list types...
<andrewrk> this would be an improvement over that, for example: std.linked_list.Singly std.linked_list.XOR std.queue.Tail std.queue.Circular
<andrewrk> but I'd rather just follow the pattern of having core data types be directly under std. I don't see why not, it's not like that namespace is going to have ambiguities
<daurnimator> okay. will change the PR to have that.
<andrewrk> what is this xor data structure btw? I'm going to look that up
<daurnimator> should I leave in the old std.LinkedList alias? or just rename all users?
<andrewrk> go ahead and make the breaking change
<daurnimator> andrewrk: yep that's as good a link as any
<andrewrk> wow
<daurnimator> there's lots of other linked list varieties worth having as well; particularly lock-free varieties
<andrewrk> I went down that rabbit hole. I came to the conclusion it's not worth it
<daurnimator> hlist as in the linux kernel is probably the most useful
<andrewrk> there is no simple lock free linked list, and when you make it complex enough to be lock free you end up giving up enough perf with atomic ops that a mutex would have been better
<daurnimator> that's not true at all; the kernel's linked list being plain evidence of that
<andrewrk> I'll have a look at the hlist implementation
<daurnimator> (the rcu hlist that is)
<andrewrk> good night
<daurnimator> night
<marler8997> might not want to look at that kernel code too much...GPL issues
<scientes> daurnimator, in order to make it lockless you have to add epochs
<scientes> *actually* lockless
<scientes> but yeah I should submit the linked-list I made, which is still stupid simple
<scientes> something like xarray to do better cache line optimizations is good idea however
<daurnimator> scientes: huh/what?
<scientes> daurnimator, truly lockless code has a problem that you can never free anything
<daurnimator> ??
<daurnimator> scientes: if we had a userspace RCU-like implementation then we can pretty quickly implement all the known structures on top
<daurnimator> scientes: and I'm not sure how xarray is related here.
<daurnimator> other than being an RCU-safe structure...
<scientes> this is a subject like O() notation, or regular expressions, where the CS is very clear, but when people talk about it they are often talking about something entirely different
<scientes> RCU is not lockless
<scientes> its better, but it is not lockless
<scientes> xarray is just a cache-aware way of allocating memory
<daurnimator> an xarray is an entirely different data structure to a linked list. I'm not sure why you're bringing it up
<scientes> a random read can cost up to 25 cache lines
<scientes> if you are KVM
<scientes> *are in KVM
<scientes> *25 cache lines and 25 memory accesses
<daurnimator> I still have no idea what point you're trying to make
<daurnimator> an xarray is a sparse array implementation that is a good replacement/foundation for most users of growable arrays, hashtables, red-black trees, and prefix trees.
hio has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
SamTebbs33 has joined #zig
husho has quit [Ping timeout: 256 seconds]
porky11 has joined #zig
marmotini_ has joined #zig
Zaab1t has joined #zig
porky11 has quit [Ping timeout: 248 seconds]
porky11 has joined #zig
Zaab1t has quit [Remote host closed the connection]
porky11 has quit [Ping timeout: 248 seconds]
porky11 has joined #zig
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
<SamTebbs33> Commit b735764 changed array literal syntax from []T to [_]T and so I changed my uage to [_]T but [_]const T isn't accepted
<SamTebbs33> Is that intended?
<daurnimator> SamTebbs33: yes. [_]const should always have been a compile error
<daurnimator> SamTebbs33: that 'const' didn't apply to anything.
<tgschultz> interesting side effect of b735764: you used to be able to do this: `const List = []const u8; const my_list = List{0,1,2,3,4};`
<SamTebbs33> daurnimator: Cheers
<andrewrk> tgschultz, I noticed that
Zaabtop has joined #zig
Zaabtop has quit [Client Quit]
Akuli has joined #zig
<SamTebbs33> tgschultz: Forgive me for my ignorance but what is strange about that example? :p
<tgschultz> List is a slice of const u8, and I'm declaring an array literal with it.
halosghost has joined #zig
avoidr has joined #zig
<marijnfs> what optimizations does -Drelease-fast=true do? I have a case that segfaults under release-fast but is fine in normal mode
<SamTebbs33> tgschultz: So an array literal of const u8's is illegal?
<SamTebbs33> marijnfs: There is some documentation at https://ziglang.org/documentation/master/#ReleaseFast but it may not be detailed enough for you
<tgschultz> `[_]const u8` is meaningless in zig. `[]const u8` means the const applies to the slice, you can't write through it, but that makes no sense for an array. const x = [_]u8 makes sense, it's a constant array. But that's not the weird thing about what I wrote. What's weird is that I really shouldn't have been able to write that.
<SamTebbs33> tgschultz: Ah that makes sense, the constant-ness should be decided by var/const as in your snippet there.
<tgschultz> in the new syntax it is obvious why: `[]const u8{1,2,3,4}` would be saying `a slice literal of 1,2,3,4`, which is invalid. I'd need to say `([_]u8{1,2,3,4})[0..]`. However the ambiguity in the old syntax meant thateven though ` List` is a slice of const u8, I could declare an inferred size array literal with it => `[]const u8{1,2,3,4}` works in the old syntax. This godbolt, which still uses the old, should make it clear:
<tgschultz> List is a slice type, but I've declared an array with it.
<scientes> indeed
<marijnfs> when I do a quickSort on a large array of values it is quite a lot faster than sort.sort, should we add something like that to the sort.zig?
<marijnfs> seems the comments mention quickSort was tried, but slower in certain tested cases
<scientes> marijnfs, its probably because it is already sorted, python has a sort optimized for that
<scientes> that can also handle partially sorted data
<scientes> I had a simple patch for this that I never bothed submiting, but it wasn't complete
<marijnfs> scientes: no i'm sorting an array with random values, also tried it with more structures values
<scientes> well produce some benchmarks and then open a bug
<scientes> and post your benchmark source code
<scientes> quickSort is not stable, so it isn't suitable for all cases
<SamTebbs33> tgschultz: This actually explains a lot of confusion I've had with arrays since I've been using []const T a lot ever since I saw it in the docs/build.zig
<marijnfs> scientes: yes if the pivot is badly chosen it can be n*n worst case, but i believe with the median pivot it's ok? have to read up on it
<scientes> quickSort is nlogn AFAIR
kristoff_it has quit [Ping timeout: 246 seconds]
<scientes> but so is what we have
<scientes> are you sure you are using --release-fast?
<marijnfs> scientes: yes, https://godbolt.org/z/h3E7fs
<marijnfs> i tried random, and ordered (both increasing and decreasing)
fengb has joined #zig
<fengb> Worst case qsort is always O(n^2) unless you do advanced heuristics
<fengb> There's always a possibility of data injection to kill the algorithm
<companion_cube> or 3-way quicksort
<fengb> marijnfs: If I toss your array, [0, ... ... 1, ... ... 2], it'll start degenerating
<fengb> I think it's worthwhile to include but not necessarily as the default because it's reliant on the data not being an attack
<tgschultz> SamTebbs33 glad I could help clarify
<marijnfs> fengb: you mean putting the smallest values in the exact indices?
<scientes> we should also implement stupid sort haha
<marijnfs> fengb: i guess random quick sort is safe but costly
<fengb> Yeah if I can control where the pivots are, I can give you a really bad case that can kill the algorithm
<fengb> It's faster on average, but worst case is a potential mess
<fengb> I don't think any language uses it as the default sort for that reason
<fengb> I think Python and Java use a hybrid quick/heap
<scientes> python has a sort optimized for already sorted data
<scientes> *partially sorted
<fengb> Nope... Python uses Timsort and Java just switched
<scientes> timsort is optimzied for partially sorted data
<scientes> which would make sense to add
<scientes> yeah I should submit my patch, with a bug to add timsort
<scientes> its good to have contributor friendly bugs
<scientes> timsort: The algorithm finds subsequences of the data that are already ordered, and uses that knowledge to sort the remainder more efficiently.
husho has joined #zig
<marijnfs> is sorting parially sorted data really the most common?
<scientes> marijnfs, are you interested in working on this?
<marijnfs> scientes: meh i guess there is no general answer, i could implement timsort if its not too involved
<fengb> I'd imagine Java and Python did their homework pretty well >_>
<marijnfs> but in general I guess it's nice if zig has a nice swiss knife of sorting algos
<scientes> well its more that it doesn't require knowledge of zig internals
<scientes> so its a good way to learn the language
<scientes> it IS involved, and it needs to be tested
<scientes> hmm, how do i cast to comptime_int in stage1?
<scientes> I just want the value.....
<scientes> oh nvm
<marijnfs> scientes: true its a good excersise
<marijnfs> but i might want to make somehting else in zig, trying to make a little deep learning library
fengb has quit [Ping timeout: 256 seconds]
marmotini_ has quit [Ping timeout: 245 seconds]
<scientes> LLVMTypeRef union_llvm_type;
<scientes> what is this? llvm doesn't have unions
marmotini_ has joined #zig
husho has quit [Ping timeout: 256 seconds]
SamTebbs33 has quit [Quit: leaving]
<marijnfs> scientes: i'm getting a sense of timsort, till try to implement it soon
<scientes> trying to hack on Zig I'm starting to appreciate LLVM's OO approach
<scientes> its much easier to just have a list of methods
<scientes> cause i keep getting side-tracking trying to figure out how to do basic things
<scientes> (the self-hosted compiler will be better)
porky11 has quit [Ping timeout: 248 seconds]
porky11 has joined #zig
Ichorio has joined #zig
<andrewrk> marijnfs, std.sort.sort is ported from https://github.com/BonzaiThePenguin/WikiSort
<andrewrk> comparing the perf against quicksort is kind of invalid since quicksort uses O(log n) stack space. to avoid overflowing the stack you would need to introduce dynamic memory allocation to that. the sort that I linked supports that - using a dynamically allocated half-size cache
<andrewrk> also scientes this algo is supposed to be faster if the list is partially sorted
<scientes> oh ok
<scientes> > , and is even faster when the input is partially ordered or as the arrays get larger.
<andrewrk> I'm in favor of a swiss army knife of sorting algorithms. but quicksort is right out
<andrewrk> no quicksort
<andrewrk> respect the stack
<scientes> what we have is nice
<scientes> you can also use the red-black tree to sort
<scientes> which sorts as you insert elements
<andrewrk> we can look at a quicksort implementation using zig's solution to recursion (which is not available yet)
<scientes> well yeah i always though quicksort was in-place
Ichorio_ has joined #zig
<scientes> so i was confused when you said O(logn) stack space
<scientes> oh, those are two differnt things
Ichorio has quit [Ping timeout: 248 seconds]
<andrewrk> that looks good - I don't think that was mentioned when I did the sort port
<andrewrk> PR welcome if it comes with benchmarks
<scientes> I'll open a bug, that is a good bug for new contributors
<andrewrk> agreed
wootehfoot has joined #zig
<andrewrk> thanks for the writeup scientes
<andrewrk> it's nice when they provide a C reference impl. super easy to port
<scientes> yeah, its annoying when academic papers don't have a reference impl.
gamester has joined #zig
Akuli has quit [Quit: Leaving]
<scientes> Is there a way to get a IrAnalyze from an instruction?
<scientes> uggh
<scientes> i need to examine types to split an instruction
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 246 seconds]
mbarkhau has joined #zig
rain2 has joined #zig
rain1 has quit [Ping timeout: 272 seconds]
daurnimator has quit [Ping timeout: 252 seconds]
jjido has joined #zig
marmotini has quit [Ping timeout: 248 seconds]
I_Right_I has joined #zig
<scientes> how to i walk the Ast tree to get the AssignExpr ?
<scientes> there is no up pointer from AstNode
<scientes> like LLVM's uses()
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scientes> OK, so the specific thing I need is to be able to get the AssignExpr from the SuffixExpr (and know if there is an AssignExpr)
<scientes> vectors cannot be supported without this (among other things)
<scientes> ok sorry, I can figure this out myself :)
I_Right_I has quit [Remote host closed the connection]
I_Right_I has joined #zig
<tgschultz> andrewrk: is there something wrong with #2597 or is it just way on the back burner?
<tgschultz> the CI failure was just MacOS CI being broken.
Ichorio_ has quit [Ping timeout: 248 seconds]
<andrewrk> tgschultz, I hesitated because I wasn't sure if it was correct. I double checked just now and your changes are good, I'm going to merge them right now. but some of the std.mem functions are incorrect for non-power-of-2 integer sizes and I wanted to audit that at the same time
<andrewrk> for example readIntNative, right now, pointer casts and then does a memory load. this is valid for power of 2 bit sizes but for e.g. u24 it actually will have to do something else
<andrewrk> I looked at the assembly that llvm generates and it's actually fine, but according to the devs it's relying on implementation defined behavior
<andrewrk> and so it would be allowed for llvm to change behavior and load past the end of that array
<scientes> andrewrk, yeah i was just changing that...
<scientes> to use insertvalue/extractvalue insertelement/extractelement
<I_Right_I> andrewrk: I had a question about the live chat on Friday I didn't want to hold you up while I typed it out. But I pasted an example snippet that sums up my question.
<I_Right_I> whenever you get a chance
<marijnfs> andrewrk: yeah i was worrying about the stack as well, using an allocator is not gonna be fast enough?
zie has joined #zig
halosghost has quit [Quit: WeeChat 2.4]
moo has joined #zig
<andrewrk> marijnfs, using an allocator will be fine - but I bet it will eliminate the perf difference between the existing std lib sort function when using the dynamically allocated cache and quicksort
<andrewrk> in fact the dynamically allocated cache of wikisort would likely be better because it's a single allocation one time whereas the quicksort recursion allocation will probably have to do multiple checks, multiple allocations and frees
<andrewrk> this is all pretty hand wavey though, let's just find out once that feature is available
wootehfoot has quit [Ping timeout: 246 seconds]
<andrewrk> I_Right_I, https://clbin.com/0RzNm both x and y end up being type u32
<andrewrk> your first example is not correct
<andrewrk> I mean the comment is wrong. but if you change `var c` to `const c` then x will have type u8
<andrewrk> I_Right_I, https://clbin.com/4khJm
cameris has quit [Quit: leaving]
moo has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
<I_Right_I> andrewrk: Yeah I did comment incorrect sorry, In the video you used var c = false (runtime know), if 'var c = true' would x have evaluated to type u8?
ltriant has joined #zig
kristoff_it has quit [Remote host closed the connection]
daurnimator has joined #zig
hio has quit [Quit: Connection closed for inactivity]
ltriant has quit [Ping timeout: 245 seconds]
ltriant has joined #zig
I_Right_I has quit [Remote host closed the connection]