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`?
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 [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, builds.sr.ht 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
<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
<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>
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>
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>
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 ziglang.org/download will abort() rather than silently miscompile
<bgiannan>
ah
<bgiannan>
so what does that error actually means then? how do i fix it?
<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:
<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>
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.