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/
<akavel> why is it trying to link?
<andrewrk> it's not linking libc
<andrewrk> your application probably does not link against your dll
<akavel> I'm still trying to only build the foo.dll
<andrewrk> your dll needs to link libc and lua
<akavel> ouch :(
<andrewrk> is that unexpected?
<akavel> I dunno, last time I did it very long ago
<andrewrk> can you post your full build.zig file in a paste
<andrewrk> in a paste site
<akavel> sure, sec
<akavel> I kinda hoped just .h files would be enough
<andrewrk> unfortunately that's not how C works. why are you adding . as an include dir? is lua copied into your project's tree?
<akavel> yep
<andrewrk> ok you probably want zig to build lua for you then, so you'll need to add that to the build script first, then you can do lib.linkLibrary(lua)
<andrewrk> that might be what daurnimator's script does, I didn't look
<akavel> I mean, I only copied lua.h and lauxlib.h into my project
<andrewrk> in this case, how were you expecting your project to find the actual lua library files?
<andrewrk> that's not a rhetorical question, it's something you must ask so that other people (or yourself later) know how to build your project
<akavel> as I said, I kinda thought .h files would be enough for building a dll, and then lua.exe would be able to use such a dll
<andrewrk> you either need to have your project depend on lua being installed on the system, or you need to vendor it as part of your project. when zig has a package manager, then it could be gracefully solved with a package
<akavel> I'm kinda having some flashes of memory that maybe there was some kind of .def files, that were used in place of .dlls as dependencies
<andrewrk> lua has to exist somewhere. it has to either be installed or you have to provide it with your project. this is a fundamental property of nature, independent from any programming language
<daurnimator> FWIW you shouldn't actually link against lua
<daurnimator> the symbols are provided by the interpreter/host application
<andrewrk> it's a header-only library?
<andrewrk> that wasn't the case when I looked at it
<daurnimator> andrewrk: no. the host application provides symbols to be used by a lua module
<daurnimator> --> the host application links against lua; lua libraries shouldn't.
<akavel> kinda "reverse linking"
<akavel> or "reverse dependency"
<andrewrk> you can't have a dll that depends on a library that isn't linked
<andrewrk> you can have a .lib though
<daurnimator> andrewrk: sure you can
<daurnimator> the dynamic loader resolves it for a dynamic library
<mq32> these ring-dependencies are pretty common for shared-object plugins
<mq32> both in linux and windows world
<andrewrk> I see
<andrewrk> I guess that's a missing build.zig api then, allowing undefined symbols in the linker
<akavel> oh, crap
<mq32> this stackoverflow topic explains the pattern quite well
<andrewrk> thanks
<fengb> Quite philosophical: "lua has to exist somewhere. [...] this is a fundamental property of nature"
<akavel> :D
<akavel> The Law of Lua
<akavel> Kelley's Law of Lua Conservation?
<mikdusan> andrew: context: https://github.com/ziglang/zig/pull/4119#issuecomment-572803709 "Instead, new codegen.cpp code needs to be added to support sub-byte addressing with arbitrary alignment of the host integer, and the layout code for packed structs needs to support non-power-of-two host integers."
akavel has quit [Ping timeout: 260 seconds]
<mikdusan> if we allow arbitrary alignment (non-power2) host integers, why do we even need host integers? deduce load size from alignment and field bits ?
zfoo has joined #zig
<mikdusan> I think I'll make a table to grok these rules
return0e has quit [Ping timeout: 268 seconds]
blueberrypie has quit [Quit: Ping timeout (120 seconds)]
return0e has joined #zig
blueberrypie has joined #zig
mokafolio has quit [Quit: Bye Bye!]
adamkowalski has joined #zig
mokafolio has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<AndroidKitKat> really dumb question, i'm getting an error when im trying to build-exe from latest head
<AndroidKitKat> "Unable to open /Users/meiseman/Library/Application Support/zig/stage1/native_libc.txt.tmp: No such file or directory"
<AndroidKitKat> this just a simple hello world am im not sure
<andrewrk> not a dumb question. mikdusan, looks like the new native_libc.txt cache code needs to ensure the directory exists
<andrewrk> I'll be happy to help with the packed struct thing in ab it
<AndroidKitKat> should i just mkdir the folder?
<mikdusan> AndroidKitKat: sounds related to a recent change I made; you are on macos?
<AndroidKitKat> I am on macOS
<mikdusan> AndroidKitKat: wait a moment. I'd like to reproduce
<AndroidKitKat> thanks
student069 has joined #zig
<mikdusan> AndroidKitKat: can you paste the zig command line?
<AndroidKitKat> wdym?
<AndroidKitKat> zig version?
ScentedFern has joined #zig
<AndroidKitKat> 0.5.0+357f42d
<mikdusan> `zig build-exe hello.zig` <-- anything other args?
<AndroidKitKat> no
<AndroidKitKat> `zig build-exe ../asdf.zig`
<mikdusan> `which zig`
<AndroidKitKat> //usr/local/bin/zig
<AndroidKitKat> i did --HEAD when installing with brew
<AndroidKitKat> but I also confirmed it doesn't work with the binary from the website
<mikdusan> ok let me try a few variations
<AndroidKitKat> thanks
<mikdusan> waat. it fails for me. I can't believe I didn't test this
<AndroidKitKat> f
<mikdusan> AndroidKitKat: ok I'll work on a fix. in the meantim just create the dir all the way up to and including stage1/
<andrewrk> mikdusan, another workaround would be zig build-exe hello.zig -target x86_64-linux-gnu
<andrewrk> cross compiling would init the cache :)
<AndroidKitKat> that'd do it chief
<student069> thanks o7 I was having the same issue
<pixelherodev> `<mq32> these ring-dependencies are pretty common for shared-object plugins` can confirm
<pixelherodev> Literally using one in Zig at the moment
<pixelherodev> Works w/o issue as is, even with unknown symbols though
<pixelherodev> But I'm not using build.zig
<pixelherodev> I'm using `zig build-lib`, so that might be why
<fengb> Would a Trie be useful in stdlib?
<pixelherodev> A what?
<shachaf> How much prefix tree code is there that you don't just write at the use site anyway? It's a very transparent data structure.
<shachaf> Maybe something like a radix tree is useful to have in some library.
mahmudov has quit [Remote host closed the connection]
<daurnimator> fengb: in practice tries are inefficient
<daurnimator> fengb: we do need a btree though; and a radix tree.
<daurnimator> and a radix tree can be a type of trie
<fengb> I actually realized bsearching an array would be smaller and faster for me >_>
<shachaf> Hmm, what sort of B-tree thing are you after?
<shachaf> I wrote a B+ tree implementation in C recently for u64->u64 maps, and it's faster than anything I've benchmarked it against.
<daurnimator> shachaf: hmm. I wanted one for some reason a couple of months ago. can't remember off the top of my head now
<shachaf> (absl::btree_map, Rust btree_map, etc.)
<daurnimator> FWIW I wanted the radix tree for a general purpose allocator.
<daurnimator> --> given a pointer (and possibly a length): look up the allocation metadata
<shachaf> Why not a hash table or something, if it's just point queries?
<fengb> Hmm is that just a compacting trie?
<shachaf> Anyway if there was some interest I could port my thing to Zig maybe.
<student069> could someone point me to example code for reading a file in zig?
<daurnimator> shachaf: one reason I had was that I wanted to be able to pass an address in the middle of an allocation; and find out about what it belonged to
<shachaf> Ah, so not just point queries. Makes sense.
<shachaf> I bet a B+ tree thing would be way better for that sort of thing, though.
<daurnimator> student069: read a file as a whole? line-by-line? how did you want to read it?
<daurnimator> shachaf: not really. radix trees are the perfect data structure for it
<student069> Line by line is what im looking for
<shachaf> Actually, hmm, you could write a special-case B+ tree for storing intervals which would be more regular than the usual kind.
<daurnimator> shachaf: I also want to write a maple tree implementation in zig :P but first things first
<shachaf> daurnimator: I stand by my bet.
<pixelherodev> What I've gotten out of the last few minutes of the chat: I really need to get some more experience with data structures :P
<fengb> The only thing I know about B trees is that they're everywhere in file systems and databases >_>
<shachaf> That's because they're the best.
<pixelherodev> What are B - never mind, imped
<daurnimator> student069: hmmm. there's io.readLineFrom.... but I don't like it already
<pixelherodev> readUntilDelimiterOrEof
<pixelherodev> That's what I'm using for the LLVM parser
<pixelherodev> Though I'm actually using a slightly modified version
<daurnimator> pixelherodev: ah yeah that would work for student069
<student069> oh neat
<pixelherodev> I didn't want to tweak ~~the stdlib~~ zag at the time so I just did it in the parser source
<pixelherodev> Yeah, just pass `\n' as the delimiter
<pixelherodev> I'd suggest finding the source for it and reimplementing a local version that can check for multiple delimiters, or manually stripping off any `\r`s found at the end of lines
<daurnimator> student069: so yeah; get dir -> open file -> get reference to file's stream field -> call `readUntilDelimiterOrEof` with '\n'
<daurnimator> student069: you will probably want to wrap it in a buffered reader too
<student069> tyvm pixelherodev & daurnimator
<pixelherodev> I'll probably submit a PR opening a version that requires a comptime delimiter
<pixelherodev> No problem!
<student069> This is pretty neat to see, having just taken a compilers class last semester
<pixelherodev> s/comptime delimiter/comptime array of delimiters
<fengb> I feel like such an old fart
<pixelherodev> Should allow for the same performance as manually checking each delimiter
<pixelherodev> fengb, why?
<shachaf> I should flesh that text out a little more and post it somewhere probably, I think the usual explanation is much more complicated.
<fengb> Cause apparently everyone in here is gen z >_>
<daurnimator> What's gen z? >.<
<student069> 1998->
<student069> ish
<daurnimator> I thought that was millenials
<student069> you would think that
<fengb> Millennial is ~1980-96
<Snektron> I got ninjad
<AndroidKitKat> Gen Z skrrt skrrt
<fengb> But we're still apparently teenagers who'll ruin the world
<daurnimator> fengb: I thought that was Gen Y?
<Snektron> Fengb, how old are you?
<fengb> 35
<fengb> Millennial is the new term for gen y lol
<Snektron> About the B trees
<Snektron> It seems to me like a memory efficient alternative to hash maps for associative types
<Snektron> On tries, i read julia tries are quite efficient
<shachaf> Hash tables are certainly going to do better when you don't need ordering.
<daurnimator> Snektron: b trees preserve order; so things next to each other stay next to each other
<Snektron> Oh i forgot to type:
<Snektron> B trees can be memory efficient when used together with an arena allocator
<Snektron> Which is not the case for hash maps
<daurnimator> Someone could probably port https://github.com/antirez/rax to zig...
<Snektron> You can even make each node the size of a page or cache line , that'll probably be quite nice
<Snektron> But i dont have too much experience with B trees
<Snektron> Octrees, thats where its at
<shachaf> If you have fixed-size data like u64 keys I'd be kind of surprised if radix trees can actually beat B+ trees for just about any workload.
<daurnimator> shachaf: so can you send a B+tree implemenation to the zig standard library? :)
<Snektron> Oh wait, they werent called julia tries but judy arrays
<Snektron> How did i make that mistake
<shachaf> I benchmarked Judy arrays (u64 keys) and they were really slow.
<shachaf> daurnimator: Maybe!
<BaroqueLarouche> Done with the Zig code part for the binary/raw objcopy-like code: https://gist.github.com/mlarouche/93f957b4bc5b5997cf73cf0a1f5bf3c8
<BaroqueLarouche> Now to integrate it in stage1 zig code and call it properly from C++ after the link phase
jcharbon has joined #zig
<student069> lol daurnimator i just saw your zig advent of code while searching around online
<daurnimator> student069: oh? I only did like the first 5 days
<daurnimator> ran out of time after that >.<
<student069> something must've clicked in the SEO when i searched a certain function haha
<fengb> https://github.com/vlang/v/blob/master/tools/gen1m.v#L4 Uhhhh is this off by a factor of 10?
_Vi has joined #zig
<daurnimator> fengb: yes... why are you even looking at that? >.<
<fengb> I troll the nets
<daurnimator> trawl?
<Snektron> I did all the AOC days in Zig
<Snektron> Also some other challenge by the same guy
<Snektron> Its full of hacks though
<fengb> I still remember the one where I blew out both the stack and the heap
<fengb> 10 GB is too much
adamkowalski has quit [Remote host closed the connection]
<Snektron> Half the days are already broken because formatting changed
<AndroidKitKat> hey fellas, my boys and are I trying to build some tools and after one of our guys finished ls, it doesn't work on my machine
<AndroidKitKat> here's the code
<AndroidKitKat> he was running Ubuntu 18.04 using the latest head and im on Fedora 31 same version
<mikdusan> AndroidKitKat: building a binary on one machine by zig defaults to use host cpu features
<AndroidKitKat> yeah but im trying to compile the code i linked
<AndroidKitKat> not transfer binaries
<mikdusan> oh
<AndroidKitKat> jcharbon: was the one who wrote it
<AndroidKitKat> we're a rag tag group of young men who like to use esoteric langs
<AndroidKitKat> i can build the executable just fine on my box, but it doesn't do anything
<mikdusan> maybe your pwd is empty
<mikdusan> works for me on archlinux
<AndroidKitKat> weird
<AndroidKitKat> it's working when i do ./ls /etc but not certain things
<student069> im facing the same issues on AndroidKitKat on rhel
<student069> hmmm maybe its debug time? we appreciate the help tonight btw
marmotini_ has quit [Remote host closed the connection]
<daurnimator> AndroidKitKat: "certain things"?
<AndroidKitKat> yeah, like the cwd
<AndroidKitKat> for example
<AndroidKitKat> /home/foo/bar works but /home/foo doesn't
<traviss> i noticed that you're using `var iter = dir.iterate();` which i thought should be `var iter = dir.iterator();`
<traviss> just a guess thought. not sure what the difference is.
<daurnimator> AndroidKitKat: misc comments: no need for your `stat_ptr` variable. use `mem.cmp` for comparing slices. sorting should be optional for a ls-alike, default is *not* sorted. declare you variables at the latest time possible: e.g. don't hoist your declaration of `tempString` out of the loop
<AndroidKitKat> jcharbon: ^^
<AndroidKitKat> thanks for the tips
<daurnimator> also use std.ArrayList for tracking entries... not a static sized array and a counter
<AndroidKitKat> that's a very helpful hint
<AndroidKitKat> all of us were scratching our heads at that
<daurnimator> in general you variables should be ~90% `const`, with only a couple of `var`.
<pixelherodev> Although generally, generalizations are false
<daurnimator> pixelherodev: In theory, theory matches practice; in practice, it doesn't.
<pixelherodev> Nice one :)
* andrewrk doing a refactor that touches nearly every line of ir.cpp @_@
<daurnimator> andrewrk: check for any open PRs first :P
<andrewrk> anything touching ir.cpp will likely have to be manually rebased
metaleap has joined #zig
<fengb> Is it something like `s/ / /`? >_>
<daurnimator> `git diff -w` "what changes?" ;)
<andrewrk> it divides IrInstruction into IrInstSrc and IrInstGen base types
<andrewrk> saving memory and preventing bugs
<andrewrk> hopefully enough to merge #4264
<andrewrk> I'm on line 2312 of 30,000 in the compile errors
marmotini_ has joined #zig
<AndroidKitKat> sounds... exciting?
<fengb> Gotta break eggs
marmotini_ has quit [Ping timeout: 265 seconds]
<jcharbon> daurnimator .. a few questions on the comments you made. I've been trying to adjust my code closer to what you said, but am running into personal issues due to lack of understanding.
<jcharbon> 1 - I don't fully understand your recommendation for mem.cmp. I am using stat_ptr with the syscall stat for a directory. does mem.cmp do the same? also I didnt even realize I was working with slices there?
<jcharbon> 2 - Why do you think sorting should be optional? just a preference? I thought ls-like functions usually were always default alphabetized.
<jcharbon> 3- what's the best way to understand how to use std.ArrayList? Can you possibly give me an example to see how it's used?
<jcharbon> 4 - why should most of my variables be const? I feel as though all of my var variables need to be like that because they change throughout the program running. Maybe its just my current limited grasp of how to code in zig.
<daurnimator> jcharbon: 1. I meant swap out the `alpha_compare` function for `mem.cmp`.
<jcharbon> oooh that makes more sense
<daurnimator> jcharbon: 2. `ls` has a variety of sorting flags (by name/mtime/ctime/owner).
<daurnimator> jcharbon: 3. looks at the tests in lib/std/array_list.zig
<daurnimator> jcharbon: 4. most variables *shouldn't* change :) what makes you think they should?
ltriant has quit [Quit: leaving]
dddddd has quit [Read error: Connection reset by peer]
<jcharbon> Well I guess a decent chunk of mine will go away if I use mem.cmp and ArrayList. I guess I didn't think too much in beyond using incremental counters for everything
<jcharbon> Also I guess throughout all my coding experience I never thought too-too much about constant but the more I think now i see your point
<andrewrk> zig will reward you for generally preferring const to var
<daurnimator> jcharbon: two related principles: prefer the smallest scope you can for variables. only make something non-const if you're going to modify it.
<jcharbon> Thanks for the tips. I will keep this all in mind going forward haha. Thanks a lot for all the help. I really appreciate it!
<fengb> Matt Godbolt has the best last name ever
<andrewrk> what about Usain Bolt, who holds the world record for the 100 metres and 200 metres sprint
<daurnimator> I had a friend that had an appointment with a "Dr Hurt"
<mikdusan> andrewrk: ok if I merge #4279 "stage1: make sure to create native_libc.txt dir" - Windows CI is out to lunch
<andrewrk> yep
<andrewrk> I'm working on a master branch commit to reduce memory usage
<mikdusan> nice!
<mikdusan> exploring ideas: if self-hosting implemented comptime via bytecode/vm (is that what Jai does?), what would the pros/cons be? I'm thinkin pro would be less memory usage but slower performance for the main use case - run once
<andrewrk> is that different than what stage1 does?