ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<Yardanico> So after a bit of work even raw libui C API looks not that bad:
mahmudov has quit [Remote host closed the connection]
<Tetralux> Should be using [*]c.uiControl, ?*c.uiControl, or *c.uiControl instead of [*c]c.uiControl, but yes. Looks a little busy, but could be much worse :)
<Tetralux> I'm curious, how many of you can recall getting a stack overflow when it WAS NOT a programming logic error.
<Tetralux> (Relates to the async await demo.)
stratact has quit [Quit: Konversation terminated!]
rjtobin has quit [Quit: Leaving]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
chemist69 has quit [Ping timeout: 276 seconds]
chemist69 has joined #zig
dewf has joined #zig
stratact has joined #zig
drazan has joined #zig
curtisf has joined #zig
<curtisf> Why is `@typeOf` lowercase and not uppercase `@TypeOf` like `@TagType` or `@This`?
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
qazo has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
<stratact> andrewrk: I got your patch in my PR while the FreeBSD CI was running, but the build log says the process got killed? I was kind of surprised it failed...
kristoff_it has quit [Ping timeout: 244 seconds]
laaron has quit [Quit: ZNC 1.7.1 -]
laaron- has joined #zig
curtisf has quit [Remote host closed the connection]
kristoff_it has joined #zig
ltriant has quit [Quit: leaving]
dbandstra has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 245 seconds]
dewf has quit [Quit: Leaving]
abbiya has joined #zig
m6w6 has quit [Quit:]
m6w6 has joined #zig
kristoff_it has joined #zig
earnestly has joined #zig
lunamn has quit [Ping timeout: 244 seconds]
lunamn has joined #zig
samtebbs has joined #zig
laaron- has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
avoidr has quit [Quit: leaving]
<mikdusan> stratact: moar RAM. moar RAM
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
mahmudov has joined #zig
<stratact> mikdusan: gotcha, thanks for finding that out. Is it possible for me to set the vm to 6GB?
<mikdusan> sorry i don't know much about sourcehut
<stratact> Then I'll assume andrewrk has control of that.
<stratact> Well that takes the worry out of my back, so thanks again
ofelas has quit [Quit: shutdown -h now]
<samtebbs> Snektron: Apologies for the noise on the packed struct issue, I removed my comment as it was innacurate
earnestly has quit [Ping timeout: 245 seconds]
earnestly has joined #zig
abbiya has quit [Quit: abbiya]
rappet has quit [Quit: -]
rappet has joined #zig
<Snektron> No worries
<Snektron> Im taking a quick look at it now
<euantor> As far as I know, doesn't give any control over VMs running builds - all you can do is run standard commands inside the build script
<samtebbs> Snektron: nice. andrewrk did say he wanted to revamp packed structs so any work you do for this issue may be undone later on
<Snektron> Just looking for a temporary solution
<Snektron> I suspect its just a programming error in struct offset calculatiob
<Snektron> It seems like a bit of a mess right now
<Snektron> It should be a lot simpler if every field's offset was represented in bits
fsateler has quit [Ping timeout: 244 seconds]
fsateler has joined #zig
mahmudov has quit [Ping timeout: 264 seconds]
mahmudov has joined #zig
<samtebbs> Snektron: It really would. Keep me updated as a fix to this would help me refactor some of my code :)
<fengb> How about compromise and return floats? :P
<daurnimator> anyone else getting LLVM broken module errors?
<kristoff_it> daurnimator: I've got a few of those when I made mistakes with return types in somewhat complex call chains. it happened whenever there was a mistake made by me and I would immediately return the result of a call `return bad_call(...);`
<daurnimator> kristoff_it: I get them when I compile zig myself; but not when I download a binary
<kristoff_it> daurnimator: ah ok, then it's something out of my paygrade :D
<andrewrk> it would be reasonable to turn this on unconditionally in stage1.
<daurnimator> andrewrk: so if that is not hit; the generated code just ..... does something else?
<andrewrk> the entire build artifact is undefined behavior
<andrewrk> if the llvm module is invalid and not verified
<daurnimator> okay. so would be good to turn on until we hit 1.0 or so...
<andrewrk> it can stay on unconditionally in stage1. self-hosted will have it off in release builds
mmx870 has quit [Ping timeout: 258 seconds]
kristoff_it has quit [Ping timeout: 246 seconds]
halosghost has joined #zig
mmx870 has joined #zig
<andrewrk> I'll do that now. I've been meaning to make a couple other improvements regarding "release" builds of stage1
laaron has quit [Quit: ZNC 1.7.1 -]
<Snektron> Oh man
<Snektron> What is going on with this offset calculation
<Snektron> Why is the abi size calculated on a packed struct?
<andrewrk> all types that exist at runtime have an abi size
<andrewrk> that's what @sizeOf is
<Snektron> Yeah but it returns invalid valurs
<Snektron> It returns 4 for a [3]u8
<Snektron> Which is fine when you have a normal struct
<Snektron> But not when the struct is packed
<andrewrk> you're asking why did this bug happen?
waleee-cl has joined #zig
<Snektron> Yeah, would be nice if there was a temporary fix until the new packed struct idea gets worked out
<Snektron> Kind of blocked on that generating invalid offsetd
mmx870 has quit [Ping timeout: 244 seconds]
mmx870 has joined #zig
<fengb> Just count manually :P
<Snektron> Neu
<andrewrk> bugs happen because the requirements and assumptions are constantly changing out from underneath the code as the language evolves
<andrewrk> this is already the 3rd or 4th major reworking of packed structs
laaron has joined #zig
<daurnimator> andrewrk: want me to send a PR?
<andrewrk> daurnimator, for what?
<daurnimator> andrewrk: removing the NDEBUG around the broken module-ness
<andrewrk> I pushed 2482bdf2 already
<daurnimator> ah. too quick you are :)
<andrewrk> this should also slightly reduce the tarball size, I think, since it won't pointlessly include the debug info handling code
<andrewrk> a while ago I made asserts on in release builds
<daurnimator> andrewrk: additional change I made in my commit:
<daurnimator> ==> I always find the LLVM abort more jaring than a zig panic
<andrewrk> I don't want to bother testing whether that messes up the output
Aransentin has quit [Remote host closed the connection]
<andrewrk> I actually prefer the former, but you can have this one if you feel strongly about it :)
<daurnimator> not that strongly :P
wilsonk__ has quit [Ping timeout: 245 seconds]
rappet has quit [Quit: -]
shritesh has joined #zig
wilsonk_ has joined #zig
<daurnimator> GCC gaining eBPF target:
Akuli has joined #zig
shritesh has quit [Quit: Leaving...]
mahmudov has quit [Ping timeout: 268 seconds]
<samtebbs> Builder.standardTargetOptions() adds an option for each target supported, but an IMO better way of doing it would be to add a "target" option that takes a string and is parsed to one of the supported targets
<samtebbs> What do you think?
<andrewrk> samtebbs, that's what happens if you pass `null` for supported target list. /// Exposes standard `zig build` options for choosing a target. Pass `null` to support all targets.
<samtebbs> E.g. by passing avr and i386 both with freestanding and gnu abi, you get
<samtebbs> -Di386-freestanding-gnu=[bool] i386-freestanding-gnu
<samtebbs> -Davr-freestanding-gnu=[bool] avr-freestanding-gnu
<samtebbs> andrewrk: that's actually when you pass a non-null array, see above
<andrewrk> yeah the CLI API is not good, I agree with you
<samtebbs> It doesn't make sense for them to be bools as they are mutually exclusive (multibuilds will change that however)
earnestly has quit [Ping timeout: 245 seconds]
<samtebbs> andrewrk: I'll draft up a PR :)
<andrewrk> :)
<Yardanico> is it possible to somehow tell cmake to use "-lclang" and other link flags when compiling? I'm trying to build zig in termux (android linux-like environment with a package manager), but it fails at the final linking stage because it can't find clang symbols
<andrewrk> I think it should be unified; whether you try to support all targets or a whitelist, it should have the same CLI to choose a target. this is currently not the case
<samtebbs> It's a welcome feature though. Makes accepting multiple targets nice and uniform
<andrewrk> samtebbs, maybe there should be standardTargetOptions() which returns a single target, and standardTargetOptionsMulti() which returns a set of targets
<andrewrk> I don't think anyone has a use case for the multi version yet
<samtebbs> yeah I'm not sure what multiple targets would be used for
<samtebbs> The question I have is what to list as the possible values when passing null. There's a lot of combinations and it would fill up the terminal when doing zig build --help
<andrewrk> no list when all targets are supported, it should just note that selecting a target is an available option
<samtebbs> andrewrk: +1
<samtebbs> Another request for debugging tips :p There have been some bugs I've tried to investigate lately that have segfaulted in LLVM code. Any tips on building a reasonable (i.e. not 10s of GBs) debug build of LLVM and getting Zig to use it?
<stratact> andrewrk: I threw a comment in my PR suggesting a heap profiler tool to see where the build is using more memory. Dunno if it will help
earnestly has joined #zig
<Yardanico> hmm, so with ZIG_LLVM_STATIC the linking step seems to work fine, but I get an error later
<Yardanico> "/data/data/com.termux/files/home/stuff/zig/test/tests.zig:190:78: error: operator not allowed for type 'builtin.Arch'"
<andrewrk> samtebbs, my tip is get a bigger hard drive and invest the time in an llvm debug build
<andrewrk> andy@ark ~> ls ~/local/
<andrewrk> llvm8-debug llvm8-release llvm9-debug llvm9-release
<Yardanico> so right after zig0 finished linking I get this:
<Yardanico> the architecture of the phone (and the compiler) is aarch64
<Yardanico> oh, ok
<andrewrk> Yardanico, oh, actually that's not right. you can't do that equality comparison because the union field has a type
<andrewrk> the arch has a sub-arch
<Yardanico> ok, I'll try that now
<samtebbs> andrewrk: macbooks weren't meant for this :p
<scientes> samtebbs, build a debug llvm with optimized table gen
<scientes> those are way faster than full-debug-builds
<scientes> samtebbs, and your machine is far faster than mine, i promise
<samtebbs> scientes: sounds intriguing. Is that an option to cmake?
<scientes> yes it is
<samtebbs> I've only ever tried RelWithDebInfo before
<scientes> oh, that is even faster
<scientes> but if you are getting a segfault
<scientes> then a debug build with probably have an assert that catches it
<samtebbs> scientes: Debug it is then
<scientes> also, build with shared libs, those are much smaller
<samtebbs> scientes: Will do, cheers
<samtebbs> Then the normal zig cmake and make steps will bring in the new llvm build?
<scientes> no
<scientes> i actually haven't had to do that yet
<scientes> but if you build the same llvm version (8-8 9-9) then you can just use LD_PRELOAD
<Yardanico> hmm, for some reason I believed that you can't have global variables in Zig (although I tested and it works) :D
<scientes> well, LD_LIBRARY_PATH=
<Yardanico> probably got confused with V
<samtebbs> scientes: :thumbs up:
<samtebbs> Yardanico: yeah it's always been supported :)
<scientes> I don't get why auto_hash even works on vector
<scientes> mem.asBytes should work
<scientes> as Vectors are not stored in memory
<scientes> *should not
<scientes> I think its because of the funky way we pass arguments around
<gonz_> "funky way"? :D
<samtebbs> scientes: You can store vectors in memory though right?
<scientes> yes
<scientes> llvm implements pointers to vectors
<scientes> there really should be a better way to zero-initialize an array
<scientes> *a vector
<samtebbs> patches welcome
samtebbs has quit [Quit: leaving]
<andrewrk> scientes, var is_special_case2 = @splat(vlen, false);
<scientes> ahh yes of course
rappet has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
ky1ko has quit [Remote host closed the connection]
<Tetralux> @splat is a thing?
<Tetralux> Only for @Vector?
<scientes> Tetralux, only in my patch set
lunamn has quit [Ping timeout: 258 seconds]
mahmudov has joined #zig
lunamn has joined #zig
<Sahnvour> Tetralux: I compared the asm generated on my machine for your example, and the difference is that in the fast version (without recently added comparison on std.mem), the parseFloat() call is totally inlined such that even the "4.777777777" string disappears from the generated code
<Sahnvour> in other words it has generated a parseFloat4.7777777777() function
<Sahnvour> which isn't very interesting to time in itself
<Tetralux> See my comment on the issue - I discovered some fun stuff after you went.
<Tetralux> But yeah that makes some sense.
<Tetralux> I did try inlining the call to parseFloat and that didn't seem to do anything.
<Tetralux> I'll try it again though.
<Sahnvour> I mean it's inlined in both cases, but the fast one seems to have more knowledge about the input propagated through the code
<Tetralux> Ah, I see.
shritesh has joined #zig
<Tetralux> Apparently you can read asm more easily than I can xD
<Tetralux> Ta for that :p
<Sahnvour> not 100% sure about what's going on, but I highly suspect this is some side effect on the benchmark not being robust enough
<Tetralux> Oh?
<Sahnvour> also on godbolt (both local and web) there's no diff in the asm, for some reason
shritesh has quit [Client Quit]
* Tetralux shrugs.
<Tetralux> Also - I just measured with string literals again - that does slow it down a lot.
<Tetralux> So it seems the extra knowledge it has makes it misread the sitation.
<Tetralux> I'm not even using the result of the parsing, and it slows down a bunch.
<Tetralux> Seems related to error unions.
<Tetralux> catch unreachable makes it faster again.
<andrewrk> catch unreachable makes it undefined behavior if an error is returned. it's not a valid performance test
<andrewrk> your real code will have to handle errors
<Tetralux> In the general case, sure.
<Tetralux> But it _is_ a perf test in this case
<Tetralux> Specifically because it was fast, despite using errors, before.
<Tetralux> And now it's an order of magnitude worse with string literals.
qazo has joined #zig
<Sahnvour> I suggest you build a better benchmark if you're really interested in this, such that the compiler cannot guess any unfair information on the input you're parsing
<Tetralux> You mean like read the string from a file? ;)
<Sahnvour> also in zig-benchmark I added a doNotOptimize function to prevent some unwanted optimizations on results
<Tetralux> Actually - scratch that. That's only valid for runtime values, not literals.
<Tetralux> For the non-literal case, I'm already using random numbers.
<Sahnvour> for example, and read lots of them, with varying sizes and values
<Tetralux> Hmmm.
ky1ko has joined #zig
donpdonp has joined #zig
<andrewrk> I ordered a pine book pro, expected to arrive in october
<andrewrk> that'll give me arm64 hardware to develop & test on
<Yardanico> andrewrk: it's pretty low-end though
<Yardanico> ah it's a pro version, hmm
<donpdonp> andrewrk: nice. i was just looking at the order page for the pinebookpro.
qazo_ has joined #zig
<bgiannan> andrewrk, should 2482bdf2 have fixed the llvm broken module error?
return0e_ has quit [Read error: Connection reset by peer]
<andrewrk> bgiannan, no, 2482bdf2 makes it so that if the llvm module is broken, the builds provided on will abort() rather than silently miscompile
<bgiannan> ah
<bgiannan> so what does that error actually means then? how do i fix it?
<bgiannan> i know nothing about llvm
qazo has quit [Ping timeout: 258 seconds]
<bgiannan> here's my full error:
return0e has joined #zig
<andrewrk> bgiannan, it's a bug in zig compiler, you will have to find a workaround, until it is fixed. Here is how you can find a workaround. add `--verbose-llvm-ir 2>stderr.txt` to that "following command" line. Next, look at stderr.txt for !14997
<andrewrk> you will see something like this: !14997 = !DILocation(line: 481, column: 13, scope: !6947). that's the line and column of the problem
<andrewrk> if you look for the scope: !6947 = distinct !DILexicalBlock(scope: !6948, file: !233, line: 478, column: 24), and then look for that file, you'll see something like !233 = !DIFile(filename: "elf.zig", directory: "/home/andy/downloads/zig/build/lib/zig/std")
<andrewrk> so now you have a clue: the file, line, and column of the zig source code that is triggering the compiler bug
<andrewrk> if you take the time to produce a small test case that triggers the bug, and then file an issue, that is a helpful contribution to the zig project
<andrewrk> either way, this will lead you to how to work around the bug until it is fixed
kristoff_it has joined #zig
<scientes> yeah the test suite has grown too be for me to runn
<andrewrk> I do want to address that. But the opportunity cost is high
<scientes> yes i understand
<andrewrk> I wonder if this is something mikdusan would find interesting
<scientes> I will be getting a new laptop in a few months
kristoff_it has quit [Ping timeout: 245 seconds]
<bgiannan> andrewrk, thanks for the pointer i'll give it a go right now
samtebbs has joined #zig
<mikdusan> andrewrk: tests.addPkgTests() iterates on a hard-coded target list of { linux,macosx,windows } without regard to say freebsd. make sense if i change to:
<mikdusan> symbolically speaking, { <whatever_host_target>, <all_tier_1_targets> } ?
<andrewrk> mikdusan, the complication here is that non-freebsd will fail to cross compile freebsd because they can't yet build the freebsd libc startup files (#2876)
<andrewrk> however I was thinking we could, for now, add a flag that at least will run that target if it is the native one
<andrewrk> mikdusan, reading your suggestion again - I like that, let's go with it
<mikdusan> ok. how about then I just add the host target to addPkgTest's loop if it's missing. i don't think freebsd even executes right now.
<mikdusan> it'll build the cross targs but never actually builds/runs freebsd (on freebsd)
<scientes> there is a bug in --release-safe where @frameAddress returns null
<andrewrk> I believe that is due to omitting the frame pointer in release builds
<andrewrk> maybe @frameAddress should be a compile error if it is known the frame pointer will not be available
<bgiannan> andrewrk, found the issue: i was calling a function which could fail without a try or a catch. So this probably should have been a `ignored result` error.
qazo_ has quit [Ping timeout: 244 seconds]
Akuli has quit [Quit: Leaving]
casaca has quit [Ping timeout: 258 seconds]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
marmotini_ has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 244 seconds]
avoidr has joined #zig
<andrewrk> I wonder if interning strings would be a way to reclaim some memory in stage1
<andrewrk> it's worth a try, I think
<andrewrk> I suspect Buf has a lot of overhead, but the first thing to do is measure it. I'm thinking a configure variable so we can do some #ifdefs to guard expensive data collection
<mikdusan> is there a std.Set or a way to use HashMap with keys only?
<andrewrk> mikdusan, you can use `void` as the value :)
<mikdusan> thanks
<andrewrk> this use case was one of the driving ideas behind how void & other zero bit types work
<samtebbs> Does anyone know a nice way to get the position of the first clear bit in a usize?
<andrewrk> @clz(~x)
<scientes> ^^^^that will do it
<scientes> but @clz(usize, ~x)
<samtebbs> I had to use ctz
<andrewrk> we should clarify what "leading" and "trailing" means in these docs with the words "most significant" and "least significant"
Ichorio has joined #zig
<samtebbs> Thanks andrewrk and scientes
<samtebbs> andrewrk: Agreed
waleee-cl has quit [Quit: Connection closed for inactivity]
<scientes> absolutely
<scientes> especially as that is big-endian terminology
<scientes> I made it really clear on the @Vector documentation that they are numbered little-Endian
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 264 seconds]
batok has joined #zig
marmotini has quit [Quit: Leaving]
<Tetralux> Snektron: I just made sublime-zig highlight enum literals and function calls, though I've tried to do it in such a way that it's not hard to find colorings that do not highlight them. It's an experiment. Let me know if it's a little too much or not.
<Tetralux> scientes: It's always fun when things like "leading" and "trailing" is not longer clear that it means "most" and "least significant" respectively.
<Tetralux> I didn't know anyone got those confused.
<fengb> On little endian, lsb technically leads
<Tetralux> Right, but you never inspect integers in little endian do you.
<Tetralux> Though I've never worked on BE machines so.
<Tetralux> The clz/ctz instructions presumably always work from the high/low end respectively.
<batok> and this blog post appeared at hacker news
<scientes> well i guess it isn't technicall little-endian
<scientes> but r->l
<scientes> because they are distinct numbers, and none is more significant than the others
<scientes> anyways, the docs are clear about this
<scientes> ugggh, r->l is also super confusing
<scientes> cause it assumes that you are reading left->right
<scientes> ugggh
<fengb> Apparently there's systems that are bitwise r->l and bytewise l->r just to be extra confusing
<Tetralux> "leading" was always just the same as "most significant" to me xD
<Tetralux> most significant first*
<scientes> fengb, armv4 floating point is mixed-endian
<scientes> one endianness for 32-32, and the other for 64-64
<scientes> of the same number
<scientes> or somethin glike that
<scientes> its insane
<scientes> or 8-8-8-8, 2-1-4-3 or something
<fengb> I feel spoiled by Intel dominance :P
<scientes> those chips are ancient
<fengb> I mean how intel endianness basically crowded out everything. ARM, Power, etc are all mostly little endian now
<scientes> and arm had to start supporting unaligned memory access
<scientes> same with power
<Snektron> Its surprising when something puts intels idiocity to shame
<scientes> little-endian is better however
<scientes> because you can zero-extent a number in place
<fengb> LE makes pointers easier
<scientes> fengb, ?
<fengb> Zero extent thing. That’s more accurate
<fengb> I'm not sure why I've always thought of it as pointers
<fengb> Maybe because in a union, *u8 == *u16 == *u32? I'm just confused >_>
<Snektron> I would't be surprised if it originated of a "they did it like this, so we have to do it differently" type of argument
Tetralux has quit [Read error: Connection reset by peer]
<fengb> Funnily enough, we naturally do math in little endian anyway so maybe little endian is more "natural"?
Ichorio has quit [Ping timeout: 264 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
samtebbs has quit [Ping timeout: 258 seconds]
Tetralux__ has joined #zig
<Tetralux__> I believe it's meant to be more efficent, though I'm not sure why.
Tetralux__ is now known as Tetralux