<Xatenev>
in the related issue someone commented "macro functions are now supported remaining cases are tracked in x"
<Xatenev>
but I can't really read from it whether this case is fixed or not
waleee-cl has joined #zig
Xatenev has left #zig ["Leaving"]
Xatenev has joined #zig
Xatenev has left #zig ["Leaving"]
<TheLemonMan>
try it and see, it should work pretty well
Snetry has quit [Ping timeout: 272 seconds]
_Vi has joined #zig
Snetry has joined #zig
TheLemonMan has quit [Ping timeout: 252 seconds]
dddddd has joined #zig
frmdstryr has joined #zig
<betawaffle>
lol... macos doesn't have accept4, and zig *only* has accept4
<betawaffle>
i suppose nobody has tried to use networking at all on macos yet
<mikdusan>
probably not
<fengb>
I feel so spoiled nowadays. In college, I had the choice of polling or blocking IO
dingenskirchen has joined #zig
dimenus has joined #zig
dingenskirchen has quit [Remote host closed the connection]
frmdstryr has quit [Read error: Connection reset by peer]
TheLemonMan has joined #zig
<fengb>
`pub fn len(comptime T: type, ptr: [*:0]const T) usize {` shouldn't these functions allow for any type of null termination?
<fengb>
sentinel termination*
<TheLemonMan>
check out #3972
<fengb>
Ah
waleee-cl has quit [Quit: Connection closed for inactivity]
frmdstryr has joined #zig
FireFox317 has joined #zig
<FireFox317>
andrewrk: there seems to be a regression regarding libc detection on windows, when doing `zig targets` in the libc list it is showing `x86_64-linux-gnu (native)`, which i think is incorrect. This is using the latest master zip file from ziglang.org
<FireFox317>
however the native cpu is correctly detected and the triple is `x86_64-windows-msvc`
<mikdusan>
the RSS was calculated from a msys2/cygwin command "/usr/bin/time -v" which I'm not sure how accurate it is. maybe there's a real native win32 tool I can use to monitor.
<mikdusan>
s/accurate/all-inclusive/
<fengb>
Oh
<fengb>
I'm not doubting you. I'm more curious why it's so different, like maybe somehow it's more optimized
<mikdusan>
very well could be exactly that. an allocator that has less overhead?
marmotini_ has quit [Remote host closed the connection]
<mikdusan>
fwiw, macos also reports same `zig targets` --> "x86_64-linux-gnu (native)"
<TheLemonMan>
andrewrk, million dollar question, is there a reason why ir_resolve_result_raw calls ir_resolve_result with allow_discard forced to true?
<mikdusan>
I see a couple of `false` callsites
<TheLemonMan>
not a single one of them is within ir_resolve_result_raw
<mikdusan>
whups i read that totally backwards. sorry
<TheLemonMan>
np, the names are very similar :)
<andrewrk>
TheLemonMan, I'm completely sure that `allow_discard` was never part of the original idea, and it was a hack added to make _ = foo; work, and then used in more hacky ways
<andrewrk>
with some of the recent technical debt payoff, it may be possible to remove this option entirely
<TheLemonMan>
uh maybe, but then you'd have to handle the assignments to _ at the ir_resolve_result callsite
<andrewrk>
in answer to your question though, I would treat this parameter skeptically
<TheLemonMan>
to give some context, in #3529 you have a slice operation with a peer-resolved result loc and everything is meant to be written to _
<TheLemonMan>
I've solved it locally by kindly asking for a non-void result loc to avoid tripping the bogus type-cast
<TheLemonMan>
if allow_discard is to be ignored then I'd have to add some more code to detect this situation
<TheLemonMan>
it's not much of a problem as a type_has_bits on the result_loc type is probably enough to reliably detect this
<andrewrk>
I can look at #3529 in a bit and see if that gives me any more insight to share with you. otherwise, I'm giving you blessing to change how things work if you see a better way
<TheLemonMan>
no worries, I'll have a look around and experiment a bit
<andrewrk>
the way I reason about my own code, I know the areas where the design is weak and where it is strong. and I know that when I change some things, it weakens some places and strengthens others. sometimes I will intentionally "forget" how a weak area of code works, so that when I read/edit that area of code I'm forced to sort of re-design it. that's currently happening with resolve_result_loc{,_raw}
<scientes>
can confirm that I did not understand result_loc stuff
FireFox317 has quit [Ping timeout: 260 seconds]
<TheLemonMan>
I understand, but keep in mind that other people cannot read your mind heh
<fengb>
... yet
<andrewrk>
right, I'm just trying to communicate that I have no defense of this area of code, and you should feel free to hack away at it as you see fit
LER0ever has joined #zig
return0e_ has quit [Ping timeout: 260 seconds]
LER0ever has quit [Remote host closed the connection]
LER0ever has joined #zig
frmdstryr has quit [Ping timeout: 255 seconds]
FireFox317 has joined #zig
marmotini_ has joined #zig
jjido has joined #zig
Akuli has joined #zig
frmdstryr has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
<betawaffle>
@byteSwap doesn't work on arrays of multi-byte integers, right?
LER0ever has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TheLemonMan>
wtf, the CI didn't start at all for #4556
<TheLemonMan>
oh it started, noice
<andrewrk>
betawaffle, ints only. I'm sure you could write something for that in userland though
_Vi has quit [Ping timeout: 252 seconds]
<frmdstryr>
TheLemonMan: Any thoughts on the @intToFloat(f64 ) thing from yesterday?
<TheLemonMan>
frmdstryr, do you have a minimal piece of code I can compile and run locally?
FireFox317 has quit [Quit: Leaving]
<frmdstryr>
Do you have a stm32 or just want to try it on any generic arm?
<andrewrk>
can you reproduce the problem with qemu?
<TheLemonMan>
don't have any stm32 board with me atm, I wanted to see if I can reproduce the problem with Qemu
<frmdstryr>
I guess I need the FPEXCN wherever that is
<TheLemonMan>
check out the last article I've linked
<frmdstryr>
That's an A7
<frmdstryr>
this is an M7
<TheLemonMan>
damn, the ARM website doesn't update the url when you change page
<frmdstryr>
Let me read the FPU feature registers and see what it says
<TheLemonMan>
are you sure the CPACR is correctly written to?
<pixelherodev>
Whoa, you hit the 4GB RAM target?! Nice work!
<pixelherodev>
(#4515)
<frmdstryr>
Pretty sure, before the cpu flag changes I had to comment out that line
<frmdstryr>
after the cpu flags let it pass cortex_m7 I had to renable it or it just froze when it got to the first float division
<TheLemonMan>
did you also add the dsb/isb to flush the caches?
<frmdstryr>
Whats your gitlab user name?
<andrewrk>
pixelherodev, thanks to mikdusan. note that the target is 3.5 GiB on FreeBSD
<TheLemonMan>
frmdstryr, LemonBoy
_Vi has joined #zig
<frmdstryr>
sent an invite, it's in lib/stm32/system.zig
<frmdstryr>
the init fn
<fengb>
Should there be a way to generate a switch at comptime? I spent a bit of effort fiddling in Godbolt until I convinced LLVM to do it
<TheLemonMan>
frmdstryr, is there a buildable example?
<frmdstryr>
targets/stm32h7/build.zig
<TheLemonMan>
gah, let me build an older version of the compiler, the new one broke once again the target thingie
<frmdstryr>
oh let me push
<frmdstryr>
ok
<frmdstryr>
The FPU media & feature registers match the "single-precision and double precsion FPU" values
<mikdusan>
heh #4515 savings of 5-6% were based on 58 revs behind master. RSS is up 10% since then. whups. but that's ok, probably means more tests, etc.
<frmdstryr>
Also don't build in release mode there's another strange issue I haven't figured out yet
<frmdstryr>
faults when entering main
<frmdstryr>
lol
<andrewrk>
TheLemonMan, what regressed?
<andrewrk>
a diff of --verbose-llvm-cpu-features would be telling
<frmdstryr>
I don't think the repo was updated to the changes to the cpu features
<frmdstryr>
"FPv4-SP and FPv5 both define a FPU that supports single precision 32-bit arithmetic", while FPv5 also provides additional instructions for double-precision
<frmdstryr>
From the armv7m reference manual
<frmdstryr>
So maybe llvm doesn't have the proper flag?
<frmdstryr>
There's seprate instructions for 64bit integer conversions
<frmdstryr>
VCVTA, VCVTN, VCVTP, and VCVTM
<andrewrk>
is it mve.fp?
<andrewrk>
enable with +mve_fp
<andrewrk>
if it's faulting, doesn't that mean that zig emitted instructions which were *not* supported by the CPU? so the solution would be removing features?
<TheLemonMan>
bleh, qemu refuses to be helpful here
FireFox317 has joined #zig
<FireFox317>
frmdstryr, do you have a link to your repo? or is it private
<frmdstryr>
It's private but I can share it if you want
<frmdstryr>
if you have a gitlab username
<TheLemonMan>
you said all the other fp ops are working just fine, right?
<frmdstryr>
Yeah only had a problem when trying to use the f64
<TheLemonMan>
try adding -vfp2d16sp to your flags
<andrewrk>
"Enable VFP2 instructions with no double precision"
<frmdstryr>
same thing
<andrewrk>
vfp4d16sp was already enabled because the cpu model is cortex_m7
FireFox317 has quit [Remote host closed the connection]
<andrewrk>
it's noted as enabled in the --verbose-llvm-cpu-features paste in the gist
FireFox317 has joined #zig
<andrewrk>
along with +vfp3d16sp, +vfp4d16sp
<FireFox317>
TheLemonMan, mentioned to disable it
<andrewrk>
ah
<TheLemonMan>
eh, llvm flags are a wonderful maze
<andrewrk>
oh! you should double check that it got disabled. because cpu features have dependencies, and it might have got re-enabled if something else depended on it
<TheLemonMan>
without knowing _why_ it is tripping the fault handler (and without some hw to test) finding the problem is going to be hard
<frmdstryr>
so it does look like it's from using d16
<andrewrk>
the binary downloads on ziglang.org are still using 9.0.0. if you build from source it's whatever your package manager has (or if you built from source, you're in control of it)
<frmdstryr>
clang --version says 9.0.0
<andrewrk>
if you want to sit through a clang/llvm/lld release/10.x source build, you could try zig's llvm10 branch
<andrewrk>
you should wait to use llvm10 branch until I merge master into it
kristoff_it has joined #zig
<TheLemonMan>
frmdstryr, can you reproduce the same problem with a teeny source file with just a @intToFloat in it?
FireFox317 has quit [Ping timeout: 260 seconds]
<kristoff_it>
I have a function that takes a type as input and depending on the type it might produce a specific error or not. Now, at a call site I want to catch that error, but since it's not always present in the errorset I get a compile error. Any recommendation on what I should do? I could use anyerror, but in reality I'd just like to "pin" that particular error to the inferred errorset.
<andrewrk>
kristoff_it, in this case it is recommended to use an explicit error set
<kristoff_it>
thanks!
<fengb>
I'm using this silly hack: `const result_value = if (@typeInfo(@TypeOf(result)) == .ErrorUnion) try result else result;`
<andrewrk>
kristoff_it, one thing you can do is use an empty error set and the compiler will tell you all the errors you are missing
<andrewrk>
you can also use the || operator to combine error sets
<fengb>
Oh mixing multiple error sets
<kristoff_it>
uhmm thinking a bit more about this I'm not sure it's the right choice for me because the type could be user-provided and they might want to introduce their own errors. I'll admit what I'm doing is pushing what is probably considered idiomatic / good zig code, but trying to get a feeling for that limit is partially the goal :)
<TheLemonMan>
andrewrk, could it be that the llvm flags are not correctly inherited by the child codegen units? That may explain why compiler-rt refuses to respect the register limits
<andrewrk>
kristoff_it, in this case I think you are forced to accept an error set from the user as a parameter
<andrewrk>
kristoff_it, one of the things I want to explore with the possible `interface` language feature is to make error sets of interfaces composible in this way. I believe this is the same problem you are running into
<andrewrk>
idk, something like an interface having an inferred error set
<frmdstryr>
TheLemonMan: yes
<frmdstryr>
idk why it chooes to use d16
ur5us has joined #zig
<kristoff_it>
fengb: I looked at your snippet, but I know the return value is always going to be an errorset, the problem is about what's in the set in a given codepath
<andrewrk>
I think your best bet with status quo zig is to accept an error set parameter, possibly merge another set of errors into it, and then use that
<fengb>
Yeah I misunderstood your problem >_>
<kristoff_it>
andrewrk: I think my case is a simpler subset, all functions are specified statically, so the errors flow naturally in the inferred error set. the only problem is one elusive error that sometimes is not part of the set. So I'd like to either "pin" it, or have a way of recognizing in which case I am using metaprogramming.
<TheLemonMan>
ok I managed to reproduce the problem using a Zig build from the website
<TheLemonMan>
time to find out _why_
<kristoff_it>
I think there is an interesting underlying question about wether the programmer should be allowed to do this stuff or not (and I would be more in favor of NO), but right now it's so annoying that I'm so close to expressing precisely what I want to happen :D
<andrewrk>
IMO, when in doubt, explicit error set
_Vi has quit [Read error: Connection reset by peer]
<shakesoda>
is it a known issue that c functions returning structs are buggy (windows)
<fengb>
Oh... most likely not working. I have some code that tries to use it but I don't think it's tested
<shakesoda>
i've been getting some crazy bad stuff with imgui functions that return stuff like struct { float x, y }
<shakesoda>
i had to write in helpers that just returned single floats instead (or, I suppose, I could have used out vars)
<TheLemonMan>
yep
<betawaffle>
are functions brought into a struct with usingnamespace eligible to be used with method syntax?
<betawaffle>
(assuming the type of the first arg is correct)
<fengb>
Yes, a quirk of the compiler is that any function can be invoked with the method syntax. It'll most often throw an error due to mismatched types
<betawaffle>
whoa, *any* function?
<betawaffle>
interesting
<fengb>
Yeah, a method is just a funny looking invocation. The type check is what the compiler cares about. It's not useful... and possibly not a real feature but still
<TheLemonMan>
okay, so this whole shit show happens because my LLVM version defaults to fpv5-d16 while the one used to compile the ziglang.org one defaults to fp-armv8
<andrewrk>
TheLemonMan, is there perhaps a branch on uninitialized value happening?
<andrewrk>
TheLemonMan, the cpu model is being explicitly specified as cortex_m7. this should set the cpu features accordingly, overriding any defaults llvm has
<betawaffle>
interesting
<TheLemonMan>
I suspect it's more a problem with LLVM, let me check if the apt.llvm.org copy has some patches applied to it
<frmdstryr>
TheLemonMan: The comments in the llvm PR to add say they're the same thing
<frmdstryr>
/ FPv5 and FP-ARMv8 have the same instructions, so are modeled as one
<andrewrk>
ziglang.org download is 9.0.0; apt.llvm.org is probably 9.0.1
<TheLemonMan>
"FPV5_D16 is identical to FP_ARMV8 except for the number of D registers"
<TheLemonMan>
it's identical but not the same :)
<frmdstryr>
hah.. just shoot me
jjido has quit [Read error: Connection reset by peer]
<andrewrk>
cortex_m7 has +fp_armv8d16. in frmdstryr's gist, it shows -fp-armv8 and +fp_armv8d16
<TheLemonMan>
according to ARMTargetParser.def cortex_m7 defaults to FK_FPV5_D16
<TheLemonMan>
don't focus too much on the flags andrewrk, there's a lot more going on
<andrewrk>
ok
<andrewrk>
that's too bad; seems like llvm is making it more complicated than it needs to be
<TheLemonMan>
meh, most of the times it's complex because it has to accomodate a huge number of use-cases
<andrewrk>
and not break backwards compatibility. yeah I get it
<TheLemonMan>
move fast and break things™
<companion_cube>
move things and breakfast
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
<metaleap>
"move fast" is *exactly* how you "break things"
<fengb>
You don’t need to move fast to break things >_>
<TheLemonMan>
not really, cats are able to break stuff with just a little tap
<andrewrk>
llvm10 branch is now up-to-date with latest master
<andrewrk>
I'll do another test suite run with asserts enabled overnight
* andrewrk
solves conflicts with master branch in one branch, while introducing conflicts in the same lines of code in another branch
dingenskirchen has joined #zig
<TheLemonMan>
I still have no idea of why the fpu setting is different ¯\_(ツ)_/¯
<frmdstryr>
You're the magic guy at work that just looks at problems and they go away while you're around
<frmdstryr>
Is zig standalone?
<frmdstryr>
If so could I try to build with your build of zig?
<TheLemonMan>
hm?
<TheLemonMan>
oh... I think so
<TheLemonMan>
want me to zip it up?
<andrewrk>
frmdstryr, are you willing to try with the llvm10 branch?
<andrewrk>
(you have to build llvm/clang/lld release/10.x branch from source yourself)
<frmdstryr>
Yes it'll take me hours on 2g, or I can run and grab a coffie
<frmdstryr>
Or I can try with llvm10
<TheLemonMan>
how comes you're stuck with 2g?
<TheLemonMan>
it'll probably take less time to send you a stack of floppy disks via snail mail
<frmdstryr>
Long story ha, start unlmited at the beginnign of the month
<TheLemonMan>
I really don't understand what the hell is causing this problem, the CI and I use the same apt repo
<andrewrk>
TheLemonMan, the CI uses an alpine linux docker image with a source build of llvm/clang 9.0.0
<andrewrk>
it runs the test suite with the same apt repo as you but then it uses the apline linux docker image to make the download tarball because that was the most straightforward way I found to make a static executable
<andrewrk>
heads up this branch is extremely volatile
<jaredmm>
Any hot tips for trying to improve translate-c? Having a hell of a time trying to extract a minimal test case from the mess that is the Windows headers.
<dimenus>
maybe i'll table it until it gets merged, I can still explicitly specify glibc version for now
<jaredmm>
Lots of console printing or debugging?
<andrewrk>
jaredmm, often times a minimal test case is the main challenge of problem solving
<andrewrk>
dimenus, I'd still take a look at your diff if you like, maybe you got further than me
metaleap has quit [Quit: Leaving]
<pixelherodev>
Not much more left until ZigIRRat is usable :D
<pixelherodev>
The lexer is actually completely valid, and as a result I've been forced to put `error.unimplemented`s all throughout the AST generator instead of leaving it blank as I did in v1, which means it'll be nearly trivial to come in and finish the implementation to bring it up to spec later on
<pixelherodev>
I hope to have a hello world compiling tomorrow