gazler__ has quit [Remote host closed the connection]
ur5us_ has quit [Quit: Leaving]
ur5us_ has joined #zig
ur5us_ has quit [Remote host closed the connection]
ur5us has joined #zig
alexnask has joined #zig
<Xavi92>
traviss: isn't a programming language with ~10k commits and >200 contributors not interesting enough for Wikipedia? That's also surprising
<Xavi92>
r/not interesting/interesting
<ifreund>
wikipedia has this weird thing where they only accept secondary sources not primary soruces
Mulugruntz has joined #zig
<opDispatch>
you can try to put it in the influence charts, in a first place, or other articlces, you see, to bring sneakily the fact that then the article is required
<opDispatch>
so you'll have red links pointing to the zig article here and there and at some point you will be able to say "you see it's required"
<opDispatch>
by red links I mean those link that works and then you see "this article doesnt exist yet" etc
<Xavi92>
That's a good idea. Red links could be added on both Rust and Go articles, since they influenced Zig in some ways
<alexnask>
Maybe in the metaprogramming article as well
<opDispatch>
yeah, you got it. But I cant guarantee it will work, it's just an idea. As we often say, bad ideas often look like good in first place ;) so your call on this.
forgot-password has joined #zig
antaoiseach has joined #zig
<forgot-password>
Hi guys, I have a quick question: I have a Zig project in my ~/Documents folder on macOS. The build script creates a custom directory, but due to macOS' weird permission system since 10.15 I now have to run `zig build` as sudo. Otherwise I get an error.AccessDenied. Is anyone aware of a solution for that?
<forgot-password>
I don't think I can permanently authorize the build executable, because that always gets recompiled to a different path
<antaoiseach>
chown?
<forgot-password>
Huh, no wait. It works now, I just used the wrong mode_t when creating the dir
<forgot-password>
Stupid me, sorry to bother
<antaoiseach>
Hahaha
<forgot-password>
antaoiseach: Thanks for the suggestion, though
<antaoiseach>
Well, all's well that ends well :-) ... I myself am still of 10.14.6 - maybe not migrate in the forseeable future!
<forgot-password>
When they first rolled out 10.15 this permission stuff was absolutely horrible. You had to separately authorize every single binary that you ran from the command line to access your Documents/Desktop/whatever folder
<antaoiseach>
That sounds like not very fun :( ... it was a mess just getting gdb working on Mojave ... I can't even imagine having to set permissions for everything now
<forgot-password>
It's gotten better, apparently
<antaoiseach>
I have a problem myself ... my project structure is like to : "project-root/src and project-root/tests" ... in my tests directory, I have, say, test1.zig which imports from the src directory like so: "const foo = @import("../src/path/to/foo.zig");"
_Vi has joined #zig
<antaoiseach>
However, this gives a "import outside package path" error ... I searched the codebase, but couldn't find anything that would explain this ... did anyone face this too?
<antaoiseach>
I don't want to keep the tests within the source files since they're fast ballooning in size
<alexnask>
Yes the best way to do this is probably to add a package to the test step
<antaoiseach>
alexnask: can you elaborate a bit?
<alexnask>
One second I will link you an example
<antaoiseach>
Cool, thanks!
<alexnask>
Relative import paths can only use '..' up to the root file's directory. In this case your test file is the root
<alexnask>
This is how I work around this issue in zls
dermetfan has quit [Ping timeout: 260 seconds]
<alexnask>
So in this case unit_tests.zig can use @import("analysis") and @import("types")
<antaoiseach>
alexnask: Thank you! I'll check it out
<antaoiseach>
That looks exactly like what I need! I'll try it and report back! :-)
<lemmi>
andrewrk: since you mentioned hashmap perforance. i was toying around with some project euler stuff that makes heavy use of a hashmap. the almost identical code runs twice as fast in go. if you are intereseted i could put these 2 somewhere.
ur5us has quit [Ping timeout: 260 seconds]
<lemmi>
(i didn't benchmark memory though)
<alexnask>
This can be a bit cumbersome if you have lots of test files but you can get around it by either importing them all in a root test file or making a function in the buildfile that sets up the packages and defining all tests in an array that gets looped over and calls that fn
<fengb>
Um... what would you expect it to do? ComptimeStringMap only works with comptime values
<forgot-password>
Well, now that I think about it. Still it probably shouldn't just crash at runtime then
<fengb>
Oh yeah, I thought it was crashing at compilation. Definitely a bug, but fixing still won't let you use it :P
<forgot-password>
Yeah I'm not sure what I was thinking, I just deseparately wanted to declare a map like that... The normal StringHashMap works perfectly fine :)
<oats>
did the InStream/Outstream -> Reader/Writer change bring any interface changes, or is it just a renaming?
layneson has quit [Ping timeout: 256 seconds]
forgot-password has quit [Ping timeout: 240 seconds]
forgot-password has joined #zig
<ikskuh>
oats: afaik it's just renaming
<pixelherodev>
ikskuh: WHICH IS IT?!
<pixelherodev>
:P
<pixelherodev>
WHAT DO I CALL YOU?!
B4s1l3 has joined #zig
<pixelherodev>
Just a rename
* ikskuh
is called xq
niftynei has quit [Ping timeout: 264 seconds]
factormystic has quit [Ping timeout: 264 seconds]
WilhelmVonWeiner has quit [Ping timeout: 264 seconds]
dongcarl has quit [Remote host closed the connection]
opDispatch has quit [Ping timeout: 246 seconds]
so has quit [Ping timeout: 246 seconds]
skrzyp has quit [Ping timeout: 246 seconds]
Techcable has quit [Ping timeout: 246 seconds]
Ekho has quit [Remote host closed the connection]
skrzyp1 has joined #zig
so has joined #zig
gpanders has joined #zig
Ekho has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
dongcarl has joined #zig
_whitelogger has joined #zig
stripedpajamas has joined #zig
WilhelmVonWeiner has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
<tgschultz>
ArrayList(T).shrink asserts `new_len <= items.len` and that doesn't make sense to me. I don't necessarily want to destory data, just ensure that excess capacity is freed. Is there a reason for this or is it an oversight after the allocator changes?
<ikskuh>
huh? <= asserts exactly that to my understanding
<tgschultz>
the way ArrayList is now, items.len tracks the used portion of the list memory.
<tgschultz>
and `capacity` tracks the available memory
<tgschultz>
so shrink will only let you free unused memory if you take some used memory with it.
<tgschultz>
unless I'm missing something
gazler has joined #zig
<ifreund>
tgschultz: what you say makes sense to me
<ifreund>
pixelherodev: you just need to say his name out loud, then it's always the same :D
<tgschultz>
shrink is probably behaving correctly: resize also affects items.len, so shrink should too. So I guess what I'm looking for is a new function to free unused capacity.
<fengb>
toOwnedSlice does it
<fengb>
Although semantically it looks weird to do that and keep the arraylist around
<alexnask>
toOwnedSlice sets capacity to zero
<alexnask>
(to be precise it reinitializes the ArrayList after shrinking and returning the items slice)
layneson has joined #zig
<ifreund>
list = ArrayList(u32).fromOwnedSlice(list.allocator, list.toOwnedSlice());
<ifreund>
guess that's it
<fengb>
Totally legit
daurnimator has quit [Ping timeout: 260 seconds]
layneson has quit [Ping timeout: 246 seconds]
stripedpajamas has quit [Quit: sleeping...]
<rooke>
Speaking of ArrayLists, does any one know why ensure capacity does 1.5(capacity) + 8?
<rooke>
I've seen 1.5(capacity) discussed inplace of 2(capacity) as it gives you the possibility to reshare memory, but I've never seen a + constant tacked on
<rooke>
reshare -> reuse*
cole-h has joined #zig
stripedpajamas has joined #zig
dermetfan has joined #zig
<Snektron>
Maybe to ensure a minimum size
nerthus has joined #zig
<rooke>
Ah yeah, it initializes to 0. So I guess you need the constant to get out of that
daurnimator has joined #zig
forgot-password has joined #zig
<rooke>
How much does that memory re-use thing matter in the real world™?
<rooke>
All my run ins with it have been purely academic
Akuli has joined #zig
<leeward>
Also weird that it's not `while(better_capacity < new_capacity) { better_capacity += better_capacity / 2 + 8; }`
waleee-cl has joined #zig
<leeward>
Oh, never mind. As written it ensures at least one increase.
<leeward>
No, never mind again. The line before that guarantees it will go through the loop at least once.
<leeward>
That's 2 extra branches. I wonder how the optimizer does with it.
<leeward>
Well, 1 extra branch. while(true) doesn't branch.
<leeward>
rooke: The +8 question is a good one, and should definitely get answered.
<rooke>
Which is interesting as 1.5 + 8 will also never re-use memory unless I'm missing something
<fengb>
We recently changed allocator patterns
<alexnask>
`#static_eval_enable(false)`
<alexnask>
Wow
<leeward>
Well, if andrewrk comes by he might illuminate us.
<rooke>
I'll keep an eye on the logs then :)
<shcv>
why would 1.5 permit reuse? or conversely why wouldn't 2x?
<shcv>
I guess it could relate to how the allocator works...
<rooke>
The idea is the new array is always bigger than the sum of the arrays which came before it
<leeward>
I read an article about this a while ago...
<shcv>
I guess 1.5x+c is the minimum that grows faster than the sum of the previous?
<rooke>
Golden ratio is the division line
<rooke>
Anything smaller permits reuse
<rooke>
Anything bigger grows too fast
<leeward>
1.6 is awkward math though, and 1.5 is super easy math (in binary).
<shcv>
sounds reasonable
<rooke>
I say "permits reuse" that memory can still be re-used its just never going to put the array there
<shcv>
doesn't lead to nice powers of two sizes though
<rooke>
.Net dictionaries double the size then go to the next prime number
<rooke>
If memory serves
<leeward>
It's about minimizing memory fragmentation. It's way more likely that an array that's been growing will grow than that you'll happen to want an N-byte chunk of memory. That's the idea, anyway.
Xavi92 has joined #zig
<rooke>
Ah the prime thing has to do with distributing hash values better, ignore that comment
<rooke>
Was just a weird thing I read some where :x
<rooke>
Heres FB explaining why they use 1.5 as a growth factor
<rooke>
and some more stuff with playing nice with pages and things if thats something y'all are into
<leeward>
rooke: That's the thing I read.
<leeward>
I had totally forgottin it was from facebook.
<shcv>
oh, I see - it permits reuse because it will eventually fit within the space of the old copies
<shcv>
that sounds like it assumes contiguous allocation though? otherwise there could still be fragmentation preventing reuse
<shcv>
or at least a defragmenting allocator
<leeward>
The only way it's worse than 2 is if allocation is both discontinuous and frequent.
<shcv>
the allocation-aware vector concept sounds neat; I wonder what it would take to do that here
<leeward>
You mean decide how it grows based on the particular allocator it's passed?
<rooke>
Yeah, they mention that allocators don't usually give you exactly what you asked for but do it in fixed-size chunks. So to be optimal you would want to request multiples of those chunks
<fengb>
We expose that now in the allocator
nikita` has joined #zig
<fengb>
The allocator interface can now return the "natural" size instead of the requested size
<fengb>
So it just works™ in Zig
<rooke>
oh nice
<shcv>
the comments on relocation are also interesting
<rooke>
On a related note is there an online copy of the standard library for zig 0.6?
<rooke>
er documentation for the standard library*
<rooke>
it is a little odd that "master" is behind "0.6.0"
<leeward>
Also, I've had trouble with -femit-docs lately.
<rooke>
I've just been grepping my local copy of the source for bout a month
<rooke>
Which has been informative... but not particularly smooth
<leeward>
If you want a somewhat smoother experience that's up to date, try using ZLS with your editor.
<rooke>
huh zig has a language server. TIL
<ifreund>
zls is awesome, it lets you see the docs in the autocompletion, and you can also "goto definition" into the std source to read further
<ifreund>
i mean, it's only been around for a little over a month or something
<rooke>
I'll have to set that up
<rooke>
The readme says to use CoC for neovim, any one know if theres an advantage to that over the built in neovim LSP client?
layneson has joined #zig
<ifreund>
coc is more mature but it's nodejs
<ifreund>
i'd go with the bultin lua one
<ifreund>
I use kakoune these days though
<rooke>
Oh neat
JoshAshby has joined #zig
<rooke>
I feel too invested in vim to switch, the muscle memory would kill me.
* leeward
looks at kakoune, trying to find something Emacs doesn't do.
<leeward>
First pass: no.
<ifreund>
kakoune has a very different philosohy than emacs
<leeward>
I don't see it.
<leeward>
Unless it's "be cool" which emacs is notably bad at.
<ifreund>
emacs tries to do everything, kakoune does one thing very well and has great interop with other programs
<rooke>
I just recently gave up on emacs + evil, I just never used 99% of what emacs provides
<ifreund>
I think that we could agree that it's a good bit simpler than emacs at least
<leeward>
Emacs itself doesn't really try to do everything. There's just someone who's written an emacs extension to do everything because it's extensible. I see "Users can extend the features of Kakoune or customize them to their liking with macros or hooks."
<leeward>
Which sounds very emacs-y to me.
<rooke>
Sounds very "unix-y" in general lol
<ifreund>
well for one kakoune doesn't have a fully fledged scripting language like elisp or vimscript
<leeward>
Ugh, modal editor is the first line in their pitch. Hard pass.
<ifreund>
it just has shell expansions which allow you to interact with the editor over stdin/out in any language you choose
<fengb>
It's a vi replacement right? Of course it'll be modal :P
<ifreund>
yes if modal isn't your thing than you probably wont like it
<leeward>
Yeah, incompatible with my religion.
<ifreund>
rooke: fwiw how I switched from vim was by forcing myself to use kak for a week to see if I liked it
<ifreund>
i never went back
<leeward>
I am amused by the ascii-art clippy.
<leeward>
Clippy has come full circle.
<ifreund>
clippy is awesome, it makes the discoverability of features way better than vim
traviss has quit [Remote host closed the connection]
<leeward>
"clippy is awesome" is not a phrase anyone would ever have expected to hear ca. 1998.
<ifreund>
reminds me of that quote from dwm's readme
<ifreund>
Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
<leeward>
That sounds unlikely to succeed at its ultimate goal.
* leeward
goes back to working on standard library's docs.
<leeward>
^actually a lie. I'm learning Prolog this week.
<ifreund>
not hipster enough to learn mercury instead?
<leeward>
verily
<fengb>
I should show up to dwm and ask stupid questions
<leeward>
Zig notwithstanding, I like having a binary package I can apt install for my languages.
<waleee-cl>
(and a new stable release from this year)
<waleee-cl>
but I guess people knowing prolog would rather use https://ciao-lang.org/ which is more of a prolog with optional typing
<leeward>
I had a friend who was playing with it a few years ago and it was constant pain. "Oh, this bit seems cool...oh, it was someone's senior project in 2009 and hasn't been touched since." and many-hour builds.
<leeward>
I think after prolog my next stop is coq. Make up for that CS education I never got.
<fengb>
If it makes you feel better, I've never learned this stuff either
<fengb>
Closest "exotic" language we had in college was Scheme... and I really didn't learn the fundamentals of functional programming in that class either
<leeward>
It's not like the time in college was wasted; just gotta keep learning and CS has a lot of interesting stuff that's easy to learn from home.
<fengb>
Eh, most of the knowledge of programming were pretty useless
<fengb>
I'm really glad I learned a bunch of things on my own
stripedpajamas has joined #zig
<leeward>
Yeah, that's what I'm doing. It's a lot cheaper than getting a master's.
<rooke>
ifreund: "I never went back" want caused you to stay?
<rooke>
want -> what
<rooke>
I guess I just have yet to hit a point with vim where I think "man if only it -"
<rooke>
Outside of "man I wish vimscript wasn't a thing" and neovim solves that particularly issue lol
<ifreund>
I never really hit that point with vim, because I didn't have the imagination to think of the ways modal editing could be better
<ifreund>
then I tried kakoune, and everything was more intuitive
<ifreund>
mutliple cursors and selection-first editing make doing many things at once way more ergonomic than vim, where you basically have to stick to macros and regexes
gldev has joined #zig
<gldev>
Hello!
<ifreund>
yo
<leeward>
o/
<rooke>
I guess I'll add it to the ever growing stack of things to try when I'm not busy
<gldev>
can i compile zig with gnu's tools? i have been getting the lld error, i am also trying compiling llvm and clang but it takes foooooorever (:
<gldev>
i mean, the one that says that the var is not set
<leeward>
I don't know anything about an unset LLD_INCLUDE_DIRS. If the fix for https://github.com/ziglang/zig/issues/4799 doesn't solve your problem, come back and we'll actually try to debug it.
<gldev>
thanks, i'll try it, really excited to get into zig
<ifreund>
what distro are you on?
<gldev>
pop os
<ifreund>
ah yeah, their llvm package won't be up to date enough then
<leeward>
system76...isn't that a kind of glass?
<leeward>
Oh, no, that's system96.
<leeward>
So different.
<gldev>
haha, yeah this is just like ubunbu 20 i guess
<ifreund>
(make sure you choose 0.6.0 not master if that's what you're using)
<ifreund>
there's also https://ziglearn.org/ now which is WIP but already quite useful
<gldev>
omg i just compiled upstream
<gldev>
>.<
Mulugruntz has quit [Quit: ZZZzzz…]
Akuli has quit [Quit: Leaving]
<pixelherodev>
ikskuh: working on SPU-II JIT again :D
<ikskuh>
\o/
traviss has joined #zig
stripedpajamas has quit [Ping timeout: 260 seconds]
B4s1l3 is now known as opDispatch
<andrewrk>
looks like my hash map work was not wasted. by adding back robin-hood-hashing and storing hashes in entries, I'm seeing an 8% overall compilation speed boost
<andrewrk>
with no impact on memory usage
<andrewrk>
in fact, still lower memory usage since before the rewrite of stage1 HashMap
<ifreund>
nice, bet that feels a bit better than no change :D
<ifreund>
Do we want a swiss tables implementation in zig eventually?
<andrewrk>
ifreund, is there any reason to choose it over what I've prototyped in stage1 just now?
<ifreund>
I don't know, I need to do more reading
<ifreund>
I think what you've prototype has lower memory usage
<andrewrk>
what I've done right now has some nice properties: * memory efficient * pointers to keys and values live forever * it retains insert order * you can iterate with `for`; entries is literally an array list
<andrewrk>
and it's faster than the current implementation that we use in zig (which used to be the same impl as stage1)
<ifreund>
yeah I watched that python talk and it seems quite nice
<andrewrk>
I wish they mentioned deletion
<andrewrk>
I did it with swap_remove, which I'm happy with, but I wonder what they did
<ifreund>
didnt they mention that at some point? iirc swap remove was brought up but I don't remember the conclusion
<ifreund>
the code is probably available somewhere too
<ifreund>
I think swiss tables might be faster for hashtable lookup/insert/delete stuff but you loose the nice stuff like ordering and pointer stability
<ifreund>
they're also a good bit more complex, the rust port is over 6k loc
<andrewrk>
and it's a great way to make sure that your project stays fast and even gets faster, because you give the zig project a piece of code that represents your use case, and we track the perf over time and make sure it stays good / gets better
layneson has quit [Ping timeout: 244 seconds]
<companion_cube>
imho a stdlib implementation should be robust and versatile (so it's good to have, say, pointer stability; also debug-only checks for iterator invalidation)
<companion_cube>
swiss tables rely on simd, don't they? or at least they're designed to be fast in that case?
<andrewrk>
I'm struggling to imagine how simd would help with a hash table impl
<andrewrk>
I can definitely see it for hash functions
<ifreund>
yeah they leverage simd for some stuff, idk the details yet
<companion_cube>
iirc you can check for slots that have the same hash using simd
<companion_cube>
there's like an array that is only `[i]=>hash(entry(i))`
<ifreund>
apparently simd lets you "scan multiple hash enteries in parallel"
<companion_cube>
and thus you can check 8 of them in one instruction
<companion_cube>
and the entries are in a separate table
<andrewrk>
interesting
<companion_cube>
so it's all about cache lines and simd
<andrewrk>
oh, derp, I was wrong earlier about pointers living forever. pointers can become invalid when you put(), but you can do the same trick as with ArrayList where you ensureCapacity first and then putAssumingCapacity will guarantee to not invalidate any entry pointers
<ifreund>
I was kinda wondering how that worked :D
dermetfan has quit [Ping timeout: 244 seconds]
<ifreund>
still though, I think ordering and iteration with for are super nice
<andrewrk>
yeah I think it's a good general purpose hash map
<ifreund>
and I think this implementation you prototyped would fit well in the std
<ifreund>
we can always have a swiss tables impl as a user library (who knows, maybe I'll feel like writing one after watching this video)
<andrewrk>
cool
<companion_cube>
swiss tables are probably good if you need super fast big-ish tables
<andrewrk>
add that benchmark first!!
<companion_cube>
but I suspect a lot of tables are actually pretty small
<ifreund>
will definitely port benchmarks from the existing impls if I write one
<ifreund>
I dont have any hash maps in hot paths for river
<andrewrk>
oh with this hash map you can iterate over it while putting items into it too
<ifreund>
oh, that is nice
<ifreund>
suppose you can't delete while iterating though
<ifreund>
looks to be fairly well commented as well
<andrewrk>
I took a peek at this earlier
<andrewrk>
there's a lot of noise; I found it easier to reason about it myself than look at this code
factormystic has joined #zig
<andrewrk>
oh interesting, they lose an entire bit for their indices index size
<andrewrk>
they have: u8 for size <= 128, u16 for size <= 2**15, etc. we have: u8 for size < 255, u16 for size < 2**16 - 1, etc
<ifreund>
hm, why do they do that?
<ifreund>
like, it seems to be because they're using signed integers
<ifreund>
but why are they using signed integers in the first place?
<ifreund>
seems to be just for 2 sentials
gldev has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 244 seconds]
oats is now known as t-b
<jaredmm>
It is slightly strange that we have case sensitive types like that, anyway. I generally use IDEs with auto-complete that ignore case, but it wouldn't make sense for uint16 to be different than Uint16 or UInt16. .
<shakesoda>
case sensitive identifiers entirely seem mostly unhelpful
<shakesoda>
although last i checked zig enforces shadowing rules in a case insensitive way, so at least that's not a concern
<andrewrk>
not correct
<andrewrk>
there is no case insensitivity in the language
<shakesoda>
hmmm, i thought the shadowing check was insensitive, but ok