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/
<pmwhite> Units of measure are not complicated to understand from a user's perspective, in contrast to more fancy type theory stuff.
<pmwhite> By algebraicness, I mean that m/s^2*(s/m) = 1/s.
<fengb> Except you have to code all of that context into somewhere
<pmwhite> Right, but I assume that units which have the same name are indeed the same.
<pmwhite> I think F# does it rather well.
<fengb> How would it handle angular measurements?
<pmwhite> It wouldn't. Units are arbitrary tags that get treated like variables and combined into equations automatically by the compiler in the same manner as expressions.
<pmwhite> Probly not a good answer though.
<pmwhite> I doubt I understood what you were asking.
<Snektron> This sounds like a job for `template <typename T> Distance<T> operator "" _km(const T& x)`
<fengb> Oh I think I get it. Add / subtract only supports identical units. Multiply / divide will merge the units
<pmwhite> Yeah
WendigoJaeger has quit [Ping timeout: 265 seconds]
<pmwhite> It's been a while since I looked at other userland attempts, so maybe it is possible to be ergonomic. https://www.boost.org/doc/libs/1_37_0/doc/html/boost_units.html
qazo has quit [Remote host closed the connection]
qazo has joined #zig
qazo has quit [Ping timeout: 268 seconds]
treeshateorcs has joined #zig
SimonN has joined #zig
qazo has joined #zig
SimonNa has quit [Quit: Leaving]
<daurnimator> andrewrk: FYI I locked https://github.com/ziglang/zig/issues/4227
<andrewrk> thanks. that user appears to be a troll, blocked now
<daurnimator> jcharbon: happy to help you out; what are you not sure about?
<daurnimator> andrewrk: re: zig software foundation... I guess you're starting it as an american org?
<andrewrk> yes
MatrixBridge has joined #zig
MatrixBridge has left #zig ["User left"]
mahmudov has joined #zig
<daurnimator> andrewrk: how goes the yak shaving?
<fengb> I think the Wuhan virus is written in Zig 🙃
<pixelherodev> ... I don't get it
<fengb> Debug mode sets undefined data to 0xaaaaaa
<fengb> nvm it’s a stupid joke
<pixelherodev> ...ohhhhhhh
<pixelherodev> Right
* pixelherodev switches from scratching his head to smashing it into the wall
<andrewrk> I thought it was funny
<andrewrk> daurnimator, just finished dealing with compile errors. now debugging regressions.
* daurnimator looking forward to the target-feature merge
<andrewrk> me too
<pixelherodev> Not that it wasn't funny; I should've gotten that a lot sooner
<andrewrk> woo only a couple simple things needed to be fixed. about to find out how much memory this saved 🤞
BaroqueLarouche has joined #zig
<BaroqueLarouche> I'm almost ready to submit a PR for https://github.com/ziglang/zig/issues/2826 (raw only, not ihex)
<andrewrk> nice BaroqueLarouche
<andrewrk> here's the yak PR: https://github.com/ziglang/zig/pull/4290
<daurnimator> `->base.base.`
<daurnimator> all your base, your base, base, base
<andrewrk> hahah I was thinking the same thing
<andrewrk> this branch makes std lib tests on windows go from using 5.6 GiB peak memory (in the memory profiling build) to 4.5 GiB peak memory
<daurnimator> huzzah
<andrewrk> that should be enough to merge cpu features, I hope :)
<andrewrk> this yak stack is about to collapse
<daurnimator> I've had a draft blog post around for ~8 years titled "shave your yaks"
<andrewrk> nice! are you testing your branch integrated with the gba project to avoid calling llvm-objcopy?
<BaroqueLarouche> yup
<andrewrk> beautiful
<andrewrk> love that gba hello world will work with nothing but zig installed
<andrewrk> well and an emulator of course :)
<BaroqueLarouche> better than devkitPro for sure
<daurnimator> andrewrk: don't you mean flashcart? :)
<BaroqueLarouche> well you do need devkitPro if you want to use GDB remote debugging
<daurnimator> BaroqueLarouche: I'll also make use of that for the FOMU :)
epmills has joined #zig
<BaroqueLarouche> and done! https://github.com/ziglang/zig/pull/4291
<andrewrk> brilliant will take a look over the next couple days
<daurnimator> BaroqueLarouche: I don't think `--custom-ext` is what we'd want?
<BaroqueLarouche> use a different name for the command line switch ?
<BaroqueLarouche> or the concept of specifying custom extension ?
<daurnimator> the concept of specifying extension
<daurnimator> the build process might emit multiple files: it's not clear which it applies to
<daurnimator> but also, it would be better to be able to specify the entire file name
<BaroqueLarouche> yeah
<BaroqueLarouche> because now the file extension is appended by both the stage1 compiler and std/build.zig
<daurnimator> BaroqueLarouche: have to seen https://github.com/ziglang/zig/issues/2279 ?
<daurnimator> *you
<BaroqueLarouche> nope!
<fengb> Are you and Wendigo the same person?
<BaroqueLarouche> yes
<BaroqueLarouche> I use this pseudonym because homebrew is a grey area
<fengb> Well your secret is out now!
<BaroqueLarouche> if I change job one day, I may move it back to my real Github
<andrewrk> wow, after just a couple easy to fix issues at runtime, no regressions in this +10,996 −8,978 branch
<BaroqueLarouche> nice!
<andrewrk> zig: now with 200% more "base"
<BaroqueLarouche> if someone code a Genesis/Megadrive emulator in Zig, the first game it must emulate is Zero Wing
<andrewrk> makes sense to me
<tdeo> hmm... i've written a pure zig implementation of the wayland protocol, but some extensions fail with this and i'm not sure how to work around it https://hahay.es/XTRMm
<tdeo> in C, you can have dependency loops for constant structs fine
<fengb> Interesting how Odin is similar yet different
a_chou has joined #zig
<andrewrk> tdeo, are you able to reduce it to a small test case?
<andrewrk> zig supports this kind of thing unless it is a true dependency loop, e.g. a struct embedded inside itself
<andrewrk> but there may be a couple cases that aren't migrated to the new lazyvalue system
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
<pmwhite> Not sure if it'll get rejected really quickly, but I felt like writing a proposal for units of measure just for fun - https://github.com/ziglang/zig/issues/4292 - probably spent more time than I should have on it. It got rather long.
a_chou has quit [Remote host closed the connection]
<tdeo> (that should work, right?)
<andrewrk> tdeo, I believe you are hitting https://github.com/ziglang/zig/issues/131
<andrewrk> planned to work, but requires an improvement to the compiler
<tdeo> ah, good that it's planned
<tdeo> i've also just realized it's not essential to my project working, it just provides nicer debug logs
qazo has quit [Ping timeout: 268 seconds]
qazo has joined #zig
<andrewrk> #4290 merged into master. cpu/features PR is running CI tests again, with master merged in.
epmills has quit [Remote host closed the connection]
qazo has quit [Ping timeout: 268 seconds]
qazo has joined #zig
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
qazo has quit [Read error: Connection reset by peer]
<mikdusan> 👍👍 macOS Maximum resident set size before #4290 --> 5.59 GiB, after --> 4.27 GiB
<mikdusan> Command being timed: "zig test lib/std/std.zig"
ur5us has joined #zig
HesamR has joined #zig
euandreh has left #zig ["ERC (IRC client for Emacs 26.3)"]
euandreh has joined #zig
ur5us has quit [Ping timeout: 272 seconds]
<daurnimator> not sure why, but I only just got an email notification about #4284 now
ur5us has joined #zig
<daurnimator> andrewrk: so for the fomu stuff, I ended up with a sort of annoying pattern for the MMIO: see e.g. https://github.com/im-tomu/fomu-workshop/pull/140/files#diff-c16cea8845677b8386152c59c8b6dbff
<daurnimator> I had tried to make it just one extern struct and use `align(4)`; but that didn't seem to work
<daurnimator> as volatile was on the struct pointer itself; and not the field....
<daurnimator> andrewrk: what is the way I'm meant to get a cpu in the new build.zig api?
dddddd has quit [Remote host closed the connection]
_whitelogger has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
metaleap has joined #zig
MrMobius has quit [Ping timeout: 268 seconds]
HesamR has quit [Remote host closed the connection]
_whitelogger has joined #zig
mahmudov has quit [Ping timeout: 268 seconds]
mahmudov has joined #zig
ur5us has joined #zig
<daurnimator> Why does `isWasm` end up in all debug builds for all platforms?
FireFox317 has joined #zig
<FireFox317> hooray! #4264 (cpu-features) passed the CI tests <3
ur5us has quit [Ping timeout: 265 seconds]
___ has joined #zig
metaleap has quit [Ping timeout: 248 seconds]
forgot-password has joined #zig
<forgot-password> Hey :)
<forgot-password> Which compiler does `zig translate-c` use? Because I get some syntax errors for a c-file, but executing `clang -x c $file` works fine
<daurnimator> forgot-password: it uses libclang under the hood...
___ has quit [Quit: Leaving]
metaleap has joined #zig
daurnimator has quit [Quit: WeeChat 2.7]
daurnimator has joined #zig
<forgot-password> So does that basically amount to being the same when I'm compiling with clang?
<forgot-password> Or could there be differences? I'm attempting to convert apples CoreAudio headers to Zig, but it fails at a line that seems to be related to swift compatibility
MrMobius has joined #zig
MrMobius has quit [Ping timeout: 268 seconds]
jsmp-me has joined #zig
jsmp-me has quit [Ping timeout: 265 seconds]
dddddd has joined #zig
<mq32> andrewrk: i both like and dislike @volatileLoad at the same time
dddddd_ has joined #zig
dddddd has quit [Ping timeout: 265 seconds]
dddddd_ is now known as dddddd
mahmudov has quit [Ping timeout: 272 seconds]
FireFox317 has quit [Quit: Leaving]
metaleap has quit [Read error: Connection reset by peer]
___ has joined #zig
return0e has quit [Remote host closed the connection]
___ has quit [Read error: Connection reset by peer]
metaleap has joined #zig
epmills has joined #zig
MrMobius has joined #zig
epmills has quit [Remote host closed the connection]
<andrewrk> forgot-password, yes it amounts to being the same as clang
<andrewrk> what error exactly do you get?
epmills has joined #zig
<mikdusan> 1,000 issues
mahmudov has joined #zig
<pixelherodev> "5.6->4.5" wow, nice work!
<mq32> andrewrk, how do i have to interpret your "eyes"-reaction?
wilsonk has quit [Ping timeout: 258 seconds]
<andrewrk> I looked at your comment
<andrewrk> cpu features is merged
<pixelherodev> Whelp, that means I can't procrastinate implementing getHostFeatures anymore, right? :)
<mq32> nice @ cpu features
<mq32> <andrewrk> I looked at your comment
<mq32> so this is just a "ack, i've seen your comment"
<betawaffle> andrewrk: when are the std docs going to be updated?
metaleap has quit [Ping timeout: 260 seconds]
epmills has quit [Remote host closed the connection]
BaroqueLarouche has joined #zig
epmills has joined #zig
<andrewrk> betawaffle, they're updated now
<betawaffle> awesome, thanks
<andrewrk> std docs are still experimental
epmills has quit [Ping timeout: 260 seconds]
wilsonk has joined #zig
decentpenguin has joined #zig
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
epmills has joined #zig
wilsonk has quit [Ping timeout: 265 seconds]
<betawaffle> is there something I should be subtracting from `@sizeOf(@Frame(foo))` to get the actual needed _stack_ size of `foo`?
epmills has quit [Ping timeout: 240 seconds]
<betawaffle> when i use that on an empty function, it gives me something non-zero, presumably to account for space needed for dealing with async
<mq32> andrewrk: kyle asked an important question on the volatile topic: "is volatile a property of a variable or a store-action"
epmills has joined #zig
Akuli has joined #zig
lunamn has quit [Ping timeout: 260 seconds]
lunamn has joined #zig
<andrewrk> betawaffle, we don't have ability to measure stack size yet. the issue for that is https://github.com/ziglang/zig/issues/157
<betawaffle> well then how are you measuring frame size?
<andrewrk> frame size has to do with async
<betawaffle> but isn't some stack size info necessary to figure out frame size?
<andrewrk> mq32, it's a property of a store/load action
<mq32> i'd say it's the property of a memory location, as non-volatile access to an MMIO address is usually wrong
<andrewrk> in theory it's possible for a memory mapper to change which address is mapped to mmio
<mq32> yes, that's true
<mq32> but then all pointers/variables that were previously mapped are now also invalid
<andrewrk> yes but having volatile be a property of a store action guarantees that it is possible for software to correctly model the problem
<andrewrk> betawaffle, in async functions, local variables are pulled from the stack into the async frame
<andrewrk> there is still a stack frame when calling an async function. it's just devoid of the local variables
<betawaffle> what about functions called by an async function?
<andrewrk> well, to be clear: calling an async function like foo() is a tail call. so there is not still a stack frame. but calling it with `async foo()` there is a stack frame
wilsonk has joined #zig
jessermeyer has joined #zig
<jessermeyer> Hey everyone, how do I convert a LPVOID (?*c_void) to HWND ([*c]c_int)? I don't understand all the safety / robustness layers of Zig's compiler promises that seem to make this not straightforward.
<jessermeyer> I'm starting a thread via CreateThread which passes the parameters as a LPVOID, and I have to cast that to the types I expect inside the function.
<andrewrk> jessermeyer, it should coerce
<andrewrk> easy fix if it doesn't
<jessermeyer> .\win32_tbd.zig:26:36: error: expected type '[*c]c_int', found '*c_void' const handle: HWND = @as(HWND, thread_parameters);
<jessermeyer> or are you saying I don't need as?
<jessermeyer> <tries>
<andrewrk> @as does nothing in this context. @as is the same thing as found foo, expected bar
<jessermeyer> Yeah I've been referring to the documentation quite a bit to sort this out (thanks for making those!)
<jessermeyer> .\win32_tbd.zig:25:46: error: expected type '[*c]c_int', found '*c_void' const handle: HWND = in_thread_parameters.?; ^.\win32_tbd.zig:25:46: note: pointer type child 'c_void' cannot cast into pointer type child 'c_int' const handle: HWND = in_thread_parameters.?;
<andrewrk> I had it backwards though, the coercion works going to c_void, not from
<andrewrk> you need @ptrCast to get from *c_void to something else
<jessermeyer> I get alignment complaints when I do that.
<andrewrk> you'll need an additional @alignCast then
<jessermeyer> Ok, just being sure I wasn't walking into a trap doing that.
<andrewrk> `?*c_void` is extremely unsafe, so it looks nasty casting away from it
<jessermeyer> I assumed there was a sane reason. ;)
<andrewrk> jessermeyer, usually when you are casting from *c_void, it's because you are the one who casted *to* *c_void in the first place. so you should be able to find that code, and convince yourself the address is properly aligned
<andrewrk> you're using some windows API giving you a ?*c_void - I'm guessing it is regurgitating the same value you passed in another API call
<jessermeyer> Right, there are a number of layers between my code at the function call and when I actually see the data passed in again.
<andrewrk> BaroqueLarouche, sorry for making you toss out a bunch of perfectly good code
<andrewrk> but it's for great justice
<andrewrk> keeping the stage1 compiler simpler
<BaroqueLarouche> andrewrk: well, not that much, all the Zig code will be reused
<jessermeyer> BTW, andrew, Zig is such a high value product. Thank you for all the effort (and your contributors) have invested in thus far
<andrewrk> <3
<jessermeyer> And it's value prospects are even more promising. It's a joy to feel to play a tiny part in the beginnings.
<andrewrk> I'm so relieved to have finally merged the cpu features branch
<BaroqueLarouche> yeah, I feel I discover the language at the right time, it's usable enough but still so much to do and influence
<andrewrk> it was stressing me out having that sitting there
<andrewrk> BaroqueLarouche, I wonder, does the cpu features branch affect GBA? maybe if you pass the specific CPU it will generate better code?
<BaroqueLarouche> I have not tried it yet
* s-ol *scratches head*
<s-ol> am i overlooking something or is this silly?
<andrewrk> s-ol, is your gl.zig auto generated?
<s-ol> no
<s-ol> its what im writing
<andrewrk> it looks like glGetnUniformfv wants to mutate value
<andrewrk> so your value must be declared var not const
<s-ol> its not... this is switch (self.*)
<s-ol> and self is 'self: *UniformValue'
<s-ol> (UniformValue is a tagged union)
<andrewrk> oh I see, put |*value| instead of |value|
<andrewrk> and no &
<s-ol> ah!
<s-ol> perfect ;)
<s-ol> oh and a small thing: apparently &&var doesnt work because it warns about boolean AND
<s-ol> but it can be useful sometimes to take pointer-pointers
<andrewrk> BaroqueLarouche, looks like `-target-cpu arm7tdmi` is appropriate for GBA
<BaroqueLarouche> andrewrk: that's the one, and seems to be properly supported by LLVM when I looked in the .td file
<s-ol> hm, still getting that cast error, andrewrk: blob:https://imgur.com/58ead036-a748-46f6-aebe-9e995be1b914
<s-ol> 'signed 32-bit int cannot represent all possible signed 32-bit value'
<s-ol> im running some random zig-git version though, so maybe its an intermittent bug
<andrewrk> BaroqueLarouche, in gbaThumbTarget() you can add .cpu_features = std.Target.CpuFeatures.initFromCpu(&std.Target.arm.cpu.arm7tdmi),
<andrewrk> a bit verbose, but easy to solve with a helper function if we want to
<BaroqueLarouche> andrewrk: was just looking in the code for that haha
<andrewrk> I don't think it will matter. the feature set is identical to the armv4t sub-architecture
<andrewrk> still, it's correct to specify that CPU for this use case
<BaroqueLarouche> the arch argument seems superficial in initFromCpu, if you specifiy the CPU, it should know its own Arch
<betawaffle> how can i compute the Log2T from a T (https://ziglang.org/documentation/master/#shlExact)
<BaroqueLarouche> I have to do " .cpu_features = std.Target.CpuFeatures.initFromCpu(std.Target.Arch{ .thumb = std.Target.Arch.Arm32.v4t }, &std.Target.arm.cpu.arm7tdmi)
<BaroqueLarouche> which is a bit ugly
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<BaroqueLarouche> but at the same time, you do need to specify if you want ARM or thumb
<andrewrk> BaroqueLarouche, yes I agree, I plan to do another breaking change here
<andrewrk> as part of this issue: https://github.com/ziglang/zig/issues/4261
<andrewrk> I would like to change the "arch" part of the triple to "cpu"
<BaroqueLarouche> neat!
<andrewrk> but clearly as you pointed out, the cpu_features field and arch field of Target currently have redundant data
<s-ol> whoops, that was not a working link... here it is: https://i.imgur.com/mtEZfoW.png
<andrewrk> betawaffle, std.math.Log2Int
<andrewrk> s-ol, that looks like a bug
<andrewrk> "signed 32-bit int cannot represent all possible signed 32-bit values" 🤔
<andrewrk> a reasonable workaround would probably be making your data c_int instead of i32
<jessermeyer> Suppose I have in some 'main' source file: usingnamespace @import("Windows.zig"); usingnamespace @import("dx12.zig");. But many declarations inside dx12.zig requires declarations from Windows.zig, so it _also_ usingnamespaces that source file. I know @import will not redundantly add previously added files to the build list, but does this pattern
<jessermeyer> ultimately cause more work for the compiler that isn't necessary?
<andrewrk> the pattern is fine. it's equivalent in terms of what the compiler must do to having one big file with everything in it
<betawaffle> is there somewhere i should be looking for existing names in the error set? (ie. using something existing rather than error.UnexpectedEndOfInput)
<andrewrk> no; use what makes sense in the context that the error is created. later, up the call stack, where you deem appropriate you will want an error set or to handle all possible errors. here you will discover if some errors should be grouped or not and it will be clear how to refactor your code
<andrewrk> or, if you never feel the need for that error set or handling all errors (e.g. returning an error from main()) then everything is fine. user will get an appropriate error.Foo message
<jessermeyer> Thanks Andrew
<BaroqueLarouche> at quick glance, the generated code looks the same with target-cpu
<andrewrk> BaroqueLarouche, yes I looked and it's exactly the same cpu feature set as if only the sub-arch is specified
<betawaffle> i just mean, i've got an error that is semantically common, but I don't know what name might have already been standardized for that error
epmills has quit [Remote host closed the connection]
epmills has joined #zig
<pixelherodev> I've gotten bugs like that before ("x cannot represent x") and it was usually a bug in my code IIRC
<pixelherodev> i.e. the error message is wrong, but there was an underlying bug in my code anyways
<jessermeyer> Do I have to specially declare which file is the 'root' source file? Wanting to override the default panic handler to @breakpoint.
<pixelherodev> No
<pixelherodev> jessermeyer, the root source file is whatever file is being compiled
<pixelherodev> e.g. if you do `zig build-exe test.zig`, test.zig is the RSF
<jessermeyer> Thanks.
<jessermeyer> (I was hoping it was that simple / straight forward)
<pixelherodev> :)
<forgot-password> andrewrk: Hey, I'm replying to your message from 15:15, I just read it just now, sorry :P
<forgot-password> Here's a pastebin-link: https://pastebin.com/raw/zw8wAdZm
<forgot-password> `zig translate-c` doesn't seem to have the include path set by default, so I used `clang -x c -E core_audio.h` to run the pre-processor first
<forgot-password> `core_audio.h` just containing the necessary includes
epmills has quit [Remote host closed the connection]
<student069> can someone help give tips on ways I can improve this little program i made? I was trying to make a basic copy of "head". Anything would be appreciated as this is my first zig program besides hello world. https://yld.me/Jsq
<pixelherodev> student069, first, arg processing
<pixelherodev> Something like `if (args.len < 2) usage();`
<pixelherodev> Also, I'd replace the `try head` with `head(n, args[1]) catch |err| {` and print error info
<pixelherodev> and make main return void instead of `anyerror!void`
<pixelherodev> Also, std.debug.warn is for when you don't care if the output succeeds
<pixelherodev> I'd use stdout.print and catch the possible error
<pixelherodev> I'd also use a different loop to read the file
<pixelherodev> That shouldn't be a `try`; if there's a 257-byte line it'll return an error when it could continue without issue
<student069> oh shoot that makes sense
<pixelherodev> I'd also replace `try parseInt` with a catch that prints an error message like `length must be a number!`
<pixelherodev> (if that's the error ofc)
<student069> sure that makes sense. I didn't realize there was a just "catch".. probably should have looked a bit more for that
<pixelherodev> Maybe replace try argsAlloc with an "out of memory!" panic
<pixelherodev> Yeah, try is syntax sugar over `catch |err| return err`
<pixelherodev> (catch the error and return it)
<student069> ahh i c
<pixelherodev> Well, hopefully you Zig, but yes :)
<student069> lol
<student069> i am starting to like a lot of the stuff im seeing in Zig
<pixelherodev> Writing a full POSIX userland toolset?
<AndroidKitKat> yep
<pixelherodev> Nice :)
<AndroidKitKat> https://pbui.codes/
<AndroidKitKat> our barely functional website
<student069> its for a neat class we are taking this semester
<AndroidKitKat> feel free to star on github
<pixelherodev> Better a barely functional website than a modern design
<pixelherodev> ... no offense to any web devs in here
<pixelherodev> ... okay some offense
<AndroidKitKat> just wait im going to pump 10 megs of JS into the website shortly /s
<pixelherodev> Noooooo!
<AndroidKitKat> muh smooth scrolling
<pixelherodev> Anyways, I'd be curious to see a comparison between your tools and e.g. coreutils
<AndroidKitKat> at no point will we recommend replacing coreutils with our versions
<student069> but if you like random errors and less flags and functionality... i'd recommend our project
<pixelherodev> Eh, I don't particularly like coreutils as is
<pixelherodev> There's already better alternatives
<pixelherodev> Not complete yet though
<student069> ahhh i see
<jessermeyer> Is there a way to tell zig.exe not to stop on the first compiler error?
MrMobius has left #zig [#zig]
<pixelherodev> AFAIK no
<pixelherodev> It only does that for syntax errors though IIRC
<jessermeyer> Ah shame.
mahmudov has quit [Ping timeout: 265 seconds]
<student069> hey pixelherodev, when you said to "use a different loop to read the file", i was wondering if you could elaborate? do you mean like using a for loop instead or just changing the way i call the while
<pixelherodev> The latter
<pixelherodev> `That shouldn't be a `try`; if there's a 257-byte line it'll return an error when it could continue without issue`
<pixelherodev> I'd *probably* read the full buffer instead of individual lines
<pixelherodev> Then, use an index to find the end of line
<pixelherodev> If none, print full buffer; otherwise, print slice up to it, increment line count, repeat
<pixelherodev> Read buffer as needed
<pixelherodev> That reduces the number of syscalls made and increases time spent processing the file, which should theoretically be a tad faster
<pixelherodev> An interesting option would be to write a utility to estimate average line length of every non-distro file on the system, and derive the buffer length from that
<pixelherodev> but that would be getting into premature optimization territory I think
<ScentedFern> Bruh
<student069> ahh ok ok so you would say to stray away from the readUntilDelimiterOrEof and move to a different call also then to read the whole thing?
<pixelherodev> Not necessarily the whole file, but maybe memory pages?
<pixelherodev> e.g. 4KB?
<pixelherodev> However
<pixelherodev> That's a tradeoff
<pixelherodev> It'd be giving up simplicity
<pixelherodev> So, for a simple project, probably best to just handle the error
<pixelherodev> e.g. catch if the buffer is too small, and if so dump the buffer and continue the loop
<pixelherodev> That keeps the code simple, but adds support for extremely long lines
<student069> hmm ok that makes sense, I will try that out then. if you want, we ARE open to contributions on github 😏
<pixelherodev> Heh :P
<pixelherodev> Wish I had the time for that
<student069> o rip. Yea the semester hasn't ramped up for us yet
<pixelherodev> Should have a bit more free time in a week or two, but for now I'm rushing through deadlines for projects, and making sure all needed documents are in for college applications (FAFSA, SAT, transcript, etc), plus finishing off a couple of other projects (Zig refactoring tool is getting close to usable for instance), plus studying three foreign languages, the beginnings of Calculus II, Microeconomics...
<pixelherodev> Admittedly a lot of my workload right now is entirely my fault
<student069> where you looking at for school?
<AndroidKitKat> dang son
<ScentedFern> Wow sounds like quite the workload
<pixelherodev> MIT, WPI, and Princeton are my top three choices atm
<pixelherodev> Grades aren't the best, but SAT score almost literally is, so I'm optimistic
<student069> ok beast
<ScentedFern> Grades aren't everything anyways
<ScentedFern> A lot of those top schools look at a lot more
<AndroidKitKat> you sound like you're well prepared for anything lmao
<ScentedFern> Just flex your zig knowledge on 'em
<pixelherodev> I think my employment as a compsci teacher for my school's middle school is more likely to influence their decision, but this is getting a *tad* off topic :)
<ScentedFern> Oohhh
<ScentedFern> OK BEAST
<student069> dang your school has a middle school thats sick
<student069> i bet ur gonna be fine bor
FireFox317 has joined #zig
<FireFox317> I've got my first Zig code running on an ESP32 :^)
<student069> wow
<student069> nice
marmotini_ has joined #zig
<jessermeyer> Nice!
marmotini_ has quit [Remote host closed the connection]
metaleap has joined #zig
<pixelherodev> Nice work!
<pixelherodev> That use XTensa?
mahmudov has joined #zig
<FireFox317> Yes, it uses a fork of LLVM (https://github.com/espressif/llvm-project), it's a pity though that for now it can only output assembly, so I still have to use gcc to build and link
Akuli has quit [Quit: Leaving]
<metaleap> so what happens when some_arbitrary_allocator gets a free/destroy twice for the same pointer. no-op or bad bad stuff? or depends whether there are new alloc/create calls in between the 2?
<metaleap> eg. os/syscall-based allocator works page-based, right? so the page when "fully freed" (supposing the kernel tracks such) can be reused? in that case a delayed 2nd free/destroy against that addr would screw things majorly. ok I reckon it's sth to rather avoid
<pixelherodev> Depends on the allocator.
<pixelherodev> The only consistent answer is "bad"
<pixelherodev> AFAIK the only allocator at present that explicitly detects that is the libc allocator
<metaleap> yeah i quickly dropped even entertaining the notion =)
<fengb> The debug allocator will detect most double free and use after free bugs
<fengb> By detect, I mean assert and crash >_>
epmills has joined #zig
_Vi has joined #zig
<jessermeyer> What more do I have to do to override the default panic handler other than redefining it in the root source file?
<jessermeyer> Do I have to write that address somewhere?
<mq32> jessermeyer: afaik that's enough to override it
<jessermeyer> It's not getting called when unreachable is hit.
<jessermeyer> To be exact, all I have is a function called panic (with its specifications) in my root source file.
<pixelherodev> That's all that's needed
<jessermeyer> Smells like a bug.
<pixelherodev> Double check that it's your RSF
<jessermeyer> It is.
<pixelherodev> Is it public?
<jessermeyer> At least it's the file I tell zig to compile.
<pixelherodev> `pub fn panic`?
<jessermeyer> Nope ...
<pixelherodev> That would do it
<mq32> are you compiling safe mode?
<jessermeyer> Adding pub to see if that does the trick...promising.
<jessermeyer> Yes, mq32
<jessermeyer> Hmm, is msg parameter really not null terminated?
<pixelherodev> For panic?
<pixelherodev> Potentially
<pixelherodev> ... wait, no
<pixelherodev> 99% sure it's always null-terminated practically speaking
<jessermeyer> It just that I'm passing that message to OutputDebugStringA and it expects null-termination.
<jessermeyer> But the type explicitly states that it is not..
<metaleap> i had a union with dozens fields all typed `fn (SomeVaryingArgType) void` and it compiled. then i change their return types to my actually-intended ones and out of the blue https://paste.pics/7UN0L how in HECK does one deduct the actual prob from this sort of "error detail". i havent ever involved "std.auto_hash" anywhere from my code.
<mikdusan> hash the _value_ of a slice is probably not what you want. I think that error is guarding tha footgun. ie: { ptr, len } -- don't hash on that. hash on the bytes of slice.
<metaleap> i'm not "hashing the value of a slice" intentionally anywhere . BUT i found the culprit
<pixelherodev> jessermeyer, it's almost certainly null terminated
<pixelherodev> Panic strings have to be comptime string literals
<pixelherodev> Which are internally null terminated as of zig trunk
<mq32> pixelherodev: i would not rely on that
<jessermeyer> Not entirely following -- msg: []const u8 is null-terminated?
<mq32> it may be that a panic handler is a slice or something when you comptime calculate the message
<jessermeyer> I thought msg: [:0]const u8 was.
<mq32> you are right. pixelherodev is assuming compiler internals :D
<metaleap> mikdusan: thx, was being overly impatient just now here. =) it even hints at the "solution" at the end on second glance :D
<mq32> bad practise!
<jessermeyer> Here's another weird one. Randomly I get an incorrect alignment from const handle = @ptrCast(HWND, @alignCast(4, thread_parameters));, where thread_parameters is of type LPVOID. How can that fail only sometimes?
<mq32> this may fail when thread_parameters has one of the last two bits set
<fengb> That may be an intrinsic C problem. Zig complains about misalignment a lot but it would work in x86 hardware (albeit much slower)
<jessermeyer> So what do I do if I want to write correct Zig code and write threaded win32 apps that throw LPVOID parameters around?
<fengb> Or... the *c_void didn’t actually match what you expected
<mikdusan> +1
<fengb> I don’t know anything about Windows API >_>
<jessermeyer> I very much hoping this is my fault and not something more systemic ...
<mq32> the parameter to CreateThread is just "something"
<mq32> what do you want to pass to the thread?
<mq32> a pointer-to-struct?
<jessermeyer> Specifically a window handle.
<mq32> hm
<mq32> those aren't 4-aligned
<jessermeyer> Right, that's why I have to force align it. Zig won't otherwise.
<mq32> why is HWND enforcing 4-aligment anyways?!
<mq32> that looks like a bug to me
<jessermeyer> It's actually a pointer underneath, I think.
<mikdusan> then you need align 8?
<jessermeyer> Is there a way to tell zig to just figure it out?
<jessermeyer> Oops, I'm wrong.
<jessermeyer> HWND is an c_int.
<jessermeyer> Thus the 4 byte alignment.
<mq32> huh?
* mq32 looks confused
<jessermeyer> Sorry it's a spider web.
<jessermeyer> I'm looking at both what translate-c is saying it thinks it is, and then comparing that to MSDN.
<mq32> MSDN is ground truth
<jessermeyer> HWND is really just an alias for HANDLE, which is an alias for void pointer.
<mq32> HWND is "*align(1) c_void"
<mq32> if zig translates this wrong, it's a bug
<mikdusan> @alignCast(@alignOf(HWND), ... )
<jessermeyer> I'll try that...
<jessermeyer> This is what translate-c thinks HWND is...
<jessermeyer> pub const struct_HWND__ = extern struct { unused: c_int,};pub const HWND = [*c]struct_HWND__;
<mq32> okay, this looks wrong
<mq32> because that struct has align 4
<jessermeyer> Right.
<fengb> Hmm why is that inside a struct?
<jessermeyer> No idea but that's a very popular pattern translate-c uses for Windows.h.
<mq32> huh
<mq32> can you look up the source windows.h zig uses?
<fengb> I wonder if Windows.h was being clever and making “opaque pointers”
<mq32> libc/include/any-windows-any/wtypes.h:338:typedef void *HWND;
<mq32> hm
<jessermeyer> Fixing that type issue did solve the spurious alignment error. But now I have a function that later depends upon '
<jessermeyer> 'handle', but it states that it's invalid via GetLastError().
<jessermeyer> Hmm, I feel I now need to be much more cautious about translate-c here.
<jessermeyer> My code is probably littered with tiny time bombs.
<jessermeyer> that said, once it's up and running it'll probably be a valuable contribution to zig's test suite for win32 support.
<mq32> what are you working on?
<jessermeyer> Multithreaded DX12 renderer.
<mq32> neat!
<jessermeyer> The renderer portion can be cut if it's beyond the CI capabilities, but I'm touching quite a few win32 APIs in the process which can be ran via wine.
rjtobin has joined #zig
decentpenguin has quit [Quit: decentpenguin]
rjtobin has quit [Remote host closed the connection]
<student069> is there any way to keep the delimiter when splitting w/ tokenize?
<mq32> student069, afaik not, but i don't see the point. you can always add the delimiter later on when you need it
<mq32> with defined semantics (left side, right side, both sides)
<student069> hmm yea i might just be thinking wrong lol
<metaleap> "`setCold` Tells the optimizer that a function is rarely called" --- doesnt matter for one's rarely-called-but-always-running main / entry-point / main-loop eh?
<fengb> It usually prevents inlining. But if there’s only 1 call then not inlining is slower so it probably gets ignored
FireFox317 has quit [Ping timeout: 268 seconds]
<metaleap> fengb good to know, thx
jessermeyer has quit [Remote host closed the connection]
epmills has quit [Remote host closed the connection]
return0e has joined #zig
_Vi has quit [Ping timeout: 248 seconds]
<daurnimator> andrewrk: with the cpu features branch now merged; how do I "invent" my own CPU?
<daurnimator> oooooo, looks like FireFox317 got the extensa working. that's awesome! glad I gave them the push :D
<andrewrk> daurnimator, in build.zig? cli? can you explain the use case a bit more?
<daurnimator> andrewrk: yeah in build.zig: I have an FPGA that you invent your own CPU for: it obviously doesn't belong in the standard library; but I'd like a way to create one in build.zig
<daurnimator> or is http://sprunge.us/w2vf4M already the correct thing?
<andrewrk> build.zig is ultimately going to use the cli to communicate to zig, so it will end up using -target-features by not -target-cpu
<andrewrk> I would recommend to initialize with baseline features, and then add/remove from the set
<daurnimator> andrewrk: given that baseline features might evolve, I prefer to start from nothing and add features I have (which for now... is nothing)
<andrewrk> for most architectures, "empty" doesn't make sense. "baseline" is closer to empty than you might think
<andrewrk> for generic_rv32, it would look like this:
<andrewrk> .cpu_features = std.Target.CpuFeatures.initFromCpu(&std.Target.riscv.cpu.generic_rv32),
<andrewrk> you may note this is redundant information with arch. I would like to get to a place where specifying the full CPU would not require also specifying the arch
<andrewrk> for riscv, "generic" is truly empty
<daurnimator> andrewrk: yep... which is why I picked it
<daurnimator> is there some other more generic way to get a featureless cpu?
<andrewrk> are you sure you need a way to get a featureless cpu?
<andrewrk> s/a way/a generic way/
<andrewrk> oh, also note that generic_rv64 is not an empty feature set. it has the "64bit" feature
metaleap has quit [Quit: Leaving]
<Snektron> eh
<Snektron> printing with 0x{X:0>8} shouldnt output 0x+0000001 right?
return0e has quit [Remote host closed the connection]
<Snektron> maybe because i was using a signed type