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/
<Snektron> Should stf.heap.ArenaAllocator.denit not take `self: Self` instead of `self: *Self`?
<fengb> svmhdvn: pfg_: the compiler actually isn’t smart enough to introspect the first type. You can call any struct level function as a method and the compiler will happily try (and report a mismatched type error)
<metaleap> Snektron: it's still a struct with state (fields). without ptr self, would risk getting a copy and wouldn't be allowed to modify itself. which deinit does . might not look like it
<metaleap> wait now im not so sure lol
<metaleap> well it tried it : https://pasteboard.co/IQLdQEW.png compiles and also runs without crashes or anything :D
<metaleap> maybe they wanted to just avoid a copy by-all-means, like psychologically.
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
<pixelherodev> What's the command to run basic tests locally?
<pixelherodev> Want to avoid relying on CI at this point
<pixelherodev> No need to abuse the infrastructure when I have a perfectly good PC to test locally
<mikdusan> pixelherodev: `zig build test -Dskip-release -Dskip-non-native`
<mikdusan> if messing with stage1 compiler, maybe just build zig0 instead. it's faster. `make zig0` and then fav first tests after that are `zig0 test test/stage1/behavior.zig` and `zig0 test lib/std/std.zig`
<mikdusan> then if either of behavior or std test fails, it can usually be narrowed down to individual test, like `zig0 test lib/std/array_list.zig`
<daurnimator> Oh, I'm reminded: can everyone please add some ideas to the GSoC page?
<daurnimator> mikdusan: any projects you might want to mentor?
<treeshateorcs> how do i properly concatenate command line arguments? http://ix.io/27RP
<mikdusan> daurnimator: I don't have any ideas for projects to add, but of the existing ones FreeBSD is probably something I can mentor
pfg_ has quit [Remote host closed the connection]
pfg_ has joined #zig
<metaleap> treeshateorcs: you need to `try`
<metaleap> the err msg of pattern "expected type foo, found <errs>!foo" indicates not handling an error-union
<treeshateorcs> http://ix.io/27RS
<metaleap> so `args.append(try arg)` or `if (arg) |a| args.append(a) else |e| myErrHandler(e)`
<metaleap> "expression value is ignored" means a call that returns non-void and you dont use the return value
<metaleap> now append returns an error because all things that allocate can OOM
<metaleap> so `try args.append(` .. annoying at first until it becomes motoric
pfg_ has quit [Ping timeout: 268 seconds]
<mikdusan> metaleap: just scraped most of this from lib/std/process.zig: https://bpaste.net/47KA
<mikdusan> that iterator is a bit tricky
<metaleap> you could also ignore it via `_ = append(` i think
<mikdusan> er sorry I mean treeshateorcs: https://bpaste.net/47KA
<treeshateorcs> OOM doesn't happen when it's done through a variable
<treeshateorcs> var args = std.process.args();
<metaleap> why do you wanna call .args() every iteration anyway
<mikdusan> std.process.args() is NOT an iterator. it CREATES an iterator for you. call it once.
<metaleap> it creates the iterator everytime
<metaleap> ah yes indeed =)
<treeshateorcs> yeah, i'm so stupid :(
<metaleap> i know the feelnig =)
<metaleap> actually jumping into a new lang i tend to be extra dumb with common silly things for the first few days, guess from the distractions by the new semantics+syntax being bombarded with
<metaleap> like learning to crawl before walking, all over again
<daurnimator> mikdusan: I just threw those ideas together
<mikdusan> ah ok.
<daurnimator> mikdusan: but if you can think of anything you feel like mentoring
<daurnimator> Particular OS? particular arch?
<metaleap> mikdusan: this week i can finally start on my LSP endeavour in zig and that means JSON-struct-mappings! so i will be pestering ya finally. sadly i only get a few evening hours per workday so will be slow going. which branch of your zig fork repo was it again?
<Snektron> <metaleap "Snektron: it's still a struct wi"> I dont think Zig holds any guarantee whether fn a(b: T) will cause b to be passed by-value or by-reference, or so i was told
<Snektron> Furthermore, self is not modified, so i think it might just be a typo
<metaleap> aah daurnimator: i misremembered who did the json stuff, sorry. mind was all over the place the first few days with zig
<metaleap> so the "dump" stuff is comptime-codegen of serializers?
<metaleap> ooh there are tests, noice
return0e_ has quit []
zfoo has quit [Remote host closed the connection]
<metaleap> treeshateorcs: as soon as you're iterating _all_ prog args _in order_, you can instead of iterator also loop through std.os.argv and std.mem.toSlice every item in there
<treeshateorcs> >std.os.argv
<metaleap> suspecting the iterator does the same thing, although .. it allocs, std.mem.toSlice doesnt
<treeshateorcs> that's what i was looking for, but std.process.args was the first hit
<metaleap> i havent fully analyzed the underlying differences between the 2 tbh. but argv is an array pre-filled before your main() enters
<metaleap> the other similar such arr is std.os.environ. well i'm off for the night
<daurnimator> metaleap: os.argv is POSIX only
<daurnimator> IIRC
<metaleap> aaah there we go, that was the catch indeed now i remember. went for it because local throwaway
metaleap has quit [Quit: Leaving]
cow-orker has joined #zig
keegans has quit [Ping timeout: 258 seconds]
<pmwhite> hmmm, so I finally fixed the bug that was only showing up on ARM. I have a `union(enum)` that has three cases, but only one of them is ever switched on. The one that was in use was the last one. When I reordered the cases so that the one in use was the first one, it started working again. Before, it would have an issue unwrapping the value with the case it was created as. Haven't yet been able to get a small repro yet.
<mikdusan> pmwhite: reminder: unwrapped values are the _same_ memory as their source. so `switch (x) { .big => |big| x.small = {....}; print(big); }` is bad because `x.small` clobbered the union where `x.big` existed
zippoh has left #zig ["User left"]
<pmwhite> I don't think that is my issue. I do know that unions have their members occupy the same space.
<pmwhite> const e = Event{ .KeyRepetition = 32 }; std.debug.warn("e = {}\n", .{e}); //works
<pmwhite> `key_event_handler(e);` where `key_event_handler` is a function pointer, and the assigned value's first statement is `std.debug.warn("e.value = {}\n", .{e.KeyRepetition})`.
<pmwhite> That yields an error that I'm accessing an inactive union case.
<pmwhite> Amend the first print statement to be the same as the second. I'm basically doing the same thing before the function call and inside the function call, but the second statement triggers the error.
<pmwhite> So perhaps the copying into the parameter ruins the data.
<pixelherodev> mikdusan, thanks!
<pixelherodev> And for the record, regarding GSoC, I'll be entering college this coming year so I think I'm elegible to participate as a student; if someone comes up with a good Ziggy project, I'd be very interested in participating
<adamkowalski> pixelherodev: are you interested in machine learning? I've been working on a library for doing that to compete with tensorflow/pytorch, but written purely in zig. There's a ton of work there for many many months to come
<daurnimator> pixelherodev: students are also allowed to propose projects :)
<mikdusan> pmwhite: curious which arm hardware?
<pmwhite> Pinebook Pro
<pmwhite> These are the two functions that are relevant. They're a little different they don't have the print statements, so the program fails by ignore the key press rather than flat-out erroring.
MaiDouH has quit [Ping timeout: 260 seconds]
<pmwhite> Note that KeyRepetition is the last element of this union - https://git.sr.ht/~philipwhite/wayland-stuff/tree/master/window.zig#L25. If I move that to the first position, it handles the key presses as expected.
<pmwhite> Also, apparently it works in the second position as well. I feel like it has to do with which items of the union are used a certain way in the rest of the program. Like perhaps Zig tries to remove them as dead code.
<mikdusan> if KeyRepetition is in last position (and not working), is PointerPressed working in first position?
dddddd has quit [Remote host closed the connection]
<pmwhite> Yeah, it is.
<pmwhite> wait, actually, that wasn't a valid check...
<mikdusan> also this is just a hail mary: for the failing switch on .KeyRepetition (when it's in last union position), add this to top of `handle_key_event`:
<mikdusan> `std.debug.assert(@frameAddress() % 16 == 0);`
<mikdusan> I'm assuming you are not doing release builds
<pmwhite> No, I'm not doing release builds. I added the assertion, but it didn't get tripped.
<pixelherodev> adamkowalski, not particularly. TBH I look upon "machine learning" with distaste
<pixelherodev> As someone put it, when you say "machine learning," I hear "we'll have the computer make a bunch of guesses using training data devised by humans"
<pixelherodev> daurnimator, interesting, good to know
<pmwhite> Also, I tried more rearranging. I added a print statement on `PointerPressed` to the switch statement in `handle_key_event`. If `PointerPressed` is the firsts or second element of the union, then it works, but if it is the third or fourth, then it gets ignored. Same for KeyRepetition. I was able to ignore both, neither, or one of them through rearranging of the union.
<pixelherodev> After watching the compile time stream: so comptime expressions are literally just run by an IR interpreter in stage1?
<mikdusan> pmwhite: (with .KeyRepetition in the 4th union slot), can you put in a trivial switch(event) BEFORE `_ = async current_slider.....` case for .KeyRepetition and just put in a @panic("whups") for the branch
<mikdusan> at top of fn handle_key_event would be fine
<pmwhite> Wait, everything started working like normal when I changed `union(enum)` to `union(enum(u3))`. I wonder if it chose too small of a tag type for the num.
<mikdusan> pmwhite: I wonder if looking at IR would shed light
adamkowalski has quit [Remote host closed the connection]
<pmwhite> Well, I can do a comptime log of the tag type, right?
<pmwhite> `@compileLog(@TagType(@TagType(Event)));` prints `u2`
<pmwhite> Presumably that would be okay for four values, right?
<pixelherodev> Yeah
<pixelherodev> 2^2 = 4 possible values
<pixelherodev> I would *definitely* compare the IR
<pmwhite> How do I do that?
<pixelherodev> `zig --verbose-ir` / `zig --emit ir` depending on version IIRC
<mikdusan> bare with me a sec. I'm checking something in IR locally
<mikdusan> bare. bear? i dunno
<pixelherodev> the latter, I think
<pmwhite> I'll try that after I install a pure wayland terminal. suckless terminal is making my pinebook chug, and I suspect it's mostly xwayland being the problem.
<pixelherodev> I don't think XWayland is all that heavy
<pixelherodev> I use it constantly and it uses *maybe* 1% CPU IIRC
<pixelherodev> Most I've ever seen it at was ~1.5%
<pmwhite> Well, st has been way less snappy than weston-terminal for some reason, but weston-terminal is rather buggy because it makes everything get underlined after exiting vim.
<pmwhite> Maybe it's time I make a terminal emulator in pure Zig and Wayland.
<mikdusan> +1
<daurnimator> use arcan :)
<pmwhite> Is there a library that handles actual emulation of a character grid? I feel like that should already exist
* daurnimator looks at letoram
<mikdusan> pmwhite: so here is the LLVM-IR difference between a switch on an 4-member enum (default to u2 I suppose), and explicit u3 as you did:
<pmwhite> Arcan is an alternative to both X and Wayland?
<daurnimator> pmwhite: yes
<pmwhite> This is probably what I'm thinking of - https://github.com/deadpixi/libtmt
<mikdusan> so weird it is signed. but it doesn't look incorrect
<mikdusan> unless something went wrong with final machine code on ARM
<pmwhite> Was that building my code, or building your own mini version of it?
<mikdusan> just a mini enum I mocked up
<pmwhite> Were you able to trigger the bug?
<pmwhite> Or whatever it is.
<mikdusan> no I'm on x86_64 just wanted to see it differentiating on u2 vs u3
<mikdusan> then again.... what's your arm target?
<pmwhite> arm target? wouldn't that just be ARM? Sorry, not trying to be difficult.
<daurnimator> pmwhite: would be very cool to try and use arcan from zig.
<pixelherodev> Anyone have a Zig Vim syntax highlighting file?
<daurnimator> pixelherodev: https://github.com/ziglang/zig.vim
<pixelherodev> Huh
<pixelherodev> Thanks
<pmwhite> daurnimator: can you give a sentence or two pitch for the value of arcan. I was trying to read about it, but I'm having trouble understanding what it's value proposition is.
<pmwhite> Wayland was not too hard to get working with Zig. The repo I'm working on has a dmenu-like color picker that prints the final hexcode to stdout.
<pmwhite> Just adding mouse support has forced me to rethink part of the structure of my UI library.
<daurnimator> pmwhite: its an alternative to X/wayland. It makes a lot more sense (to me) architecturally than any other GUI system
<pmwhite> Is that what you use on desktop?
<mikdusan> pmwhite: this will panic if switch fails: https://gist.github.com/mikdusan/fbfd5039dffce7119b396bdd575f79ef
<daurnimator> pmwhite: I'd like to; not *yet* though
<daurnimator> letoram: is there an arcan "hello world" we should try and port to zig?
<pmwhite> mikdusan: just tried that example on my PBP. No panic.
<mikdusan> ok last idea for me before I just shrug. can you comment-out the `_ = async ...` line?
<pmwhite> Just tried. No success. Thanks for the help anyway. I'm feeling better since I can just work around by using a larger tag type.
<pmwhite> Any way to print the exact bytes of a value?
<mikdusan> what does `current_slider.element.handleEvent(event)` do?
<pmwhite> At passes the event to the current slider bar. If that slider bar handles the event, it returns true, otherwise it returns false. Based on that result, the containing element can decide whether to handle the event itself.
<mikdusan> std.mem.asBytes() should get you a slice of bytes
marmotini_ has joined #zig
<pmwhite> Honestly, libtmt is only 500 lines, so I could just port it to zig.
<andrewrk> I wonder how far translate-c would get, given the recent improvements
marmotini_ has quit [Remote host closed the connection]
<daurnimator> andrewrk: please add a few ideas to the GSoC page when you get a chance
<andrewrk> thanks
SimonNa has quit [Remote host closed the connection]
<daurnimator> After the application itself, the ideas page is the most important thing they look at when judging a project
<andrewrk> good to know
<pixelherodev> Gonna be honest, watching that comptime stream is what swayed me to using Vim
<andrewrk> GeneralPurposeDebugAllocator and a GeneralPurposeReleaseFast allocator would be good projects
<pixelherodev> Especially since I don't really use all that much from Geany in the first place
<andrewrk> pixelherodev, the layneson-cpus_and_features branch is building, if you wanted to do the porting of detecting host cpu/features
<pixelherodev> It's almost 2 AM; I'll get started on it tomorrow
<andrewrk> if you run `zig targets` in that branch it segfaults, because `zig targets` is self-hosted now (in that branch) and I didn't figure out what is wrong
<andrewrk> but basically the task is to make `zig targets` print the current CPU name and feature set
<pixelherodev> Now that we have translate_c self hosted, what's remaining for stage2?
<andrewrk> 1. pay off some technical debt (https://github.com/ziglang/zig/pull/4152)
<pixelherodev> I mean, with the AST builder, generating crappy LLVM IR should already be possible, albeit annoying, no?
<andrewrk> 2. improve std lib async I/O (related: https://github.com/ziglang/zig/pull/4059)
<andrewrk> 3. serious work on self-hosted can begin
<andrewrk> prerequisite of non-llvm backends is working on https://github.com/andrewrk/zasm
<andrewrk> yeah we could just make another crappy zig compiler written in zig, but I want stage2 to be good :)
<pixelherodev> Well sure, but I like to think of it as... stage 1.5 :P
<andrewrk> stage1 already is stage1.5
<pixelherodev> More curious in a POC than anything else honestly
<pixelherodev> Or me finally redesigning my LLVM parser and making an actually good interface and implementation that can compete with zasm :)
<andrewrk> that's why we build zig0.exe which builds src-self-hosted/stage1.zig, which then makes zig.exe
<pixelherodev> I was wondering about that!
<andrewrk> zig0.exe is stage1, without the self-hosted stuff
<pixelherodev> Then it builds e.g. translate-c and links that in instead of parts of stage1, that explains a lot
<andrewrk> yep
<andrewrk> now you are in a position to understand this file: https://github.com/ziglang/zig/blob/master/src/userland.cpp
<andrewrk> arguably should be renamed to stage0.cpp
<pixelherodev> That a C++ binding? Yeah that explains it
<pixelherodev> There's something delightful about cool-retro-term + futuristic profile - flickering - jittering + Vim + colorscheme darkblue + Zig :)
return0e has joined #zig
_Vi has joined #zig
<betawaffle> feature request: allow me to use "static" methods on a struct, which return that struct, in places that accept the .{ fields } syntax? ie. some_call_which_accepts_foo(.init("bar", "baz"))
bheads has joined #zig
<mq32> betawaffle, how exactly is that supposed to work?
<mq32> I think it's confusing because i don't know which function is called
<betawaffle> right, from a readability perspective it might be too much
<betawaffle> but it would be like calling ArgType.init(...)
<betawaffle> (as opposed to what we have now, which is like ArgType{ ... }
dddddd has joined #zig
commander has joined #zig
kristoff_it has joined #zig
squeek_ has quit [Read error: Connection reset by peer]
squeek_ has joined #zig
return0e_ has joined #zig
wjlroe has quit [Ping timeout: 258 seconds]
kristoff_it has quit [Ping timeout: 272 seconds]
jzelinskie has quit [Read error: Connection reset by peer]
wjlroe has joined #zig
jzelinskie has joined #zig
return0e has quit [Ping timeout: 258 seconds]
dddddd has quit [Ping timeout: 240 seconds]
dddddd has joined #zig
zfoo_ has joined #zig
<frmdstryr> Is there a builtin special error type for a "null" error? I can't make a function that returns "?anyerror"
<fengb> anyerror!?void
<frmdstryr> then it has to be caught? I guess that works
<Snektron> error.Null
<frmdstryr> Is error.Null an actual type?
<mq32> frmdstryr: where's the problem with "catching" the error?
<fengb> Oh hmm that works? I wouldn’t expect ?void to be a thing >_>
<mq32> error.Null is freshly defined error :D
<mq32> ?void should be equivalent to bool D:
<frmdstryr> There's not it's just confusing
<fengb> anyerror!void might be the least confusing
<fengb> Catchable error or nothing
<frmdstryr> I want to convert a error flag (set by a hardware register) to the error message
<frmdstryr> *error type
<frmdstryr> in this case i don't want to actually "throw" the error but save it into a struct
<mq32> then just store the error union
<mq32> or return a typed error instead of anyerror
<frmdstryr> and it makes me wonder why zig decided to not make throw and return different keywords
<Snektron> Why coulnd't you can't return `?anyerror`
<frmdstryr> error: unable to make error union out of null literal
<fengb> anyerror is a keyword, not a type
<frmdstryr> Well if that's the case the keyword can be stored in a struct
<fengb> The type is errorset but I’m not sure if you can reference it
<frmdstryr> been doing it for a while now
<Snektron> afaik anyerror is just an int wide enough to hold all error variants
<fengb> Curious... can you use @TypeOf(error.Blah) ?
<frmdstryr> error: unable to evaluate constant expression
<fengb> Darn
<frmdstryr> It doesnt like pub fn toError(self: Errors) ReadError!?void {
<frmdstryr> either
<frmdstryr> task.data.cancel(errors.toError() catch |err| err);
<frmdstryr> error: expected type '?anyerror', found '?void'
<Snektron> `anyerror!anyerror` seems like an impossible to construct type to me
<frmdstryr> yeah, i think that's why many languages use separate throw and return keywords
<frmdstryr> or it'd be a reason to do this
waleee-cl has joined #zig
<frmdstryr> or have some builtin @toError(null)
<Snektron> you could always return an error explicitly by using `try error.Oof;`
<fengb> "error: expected error union type, found 'error{Oof}'"
<fengb> Silly throw function: https://godbolt.org/z/L7NA4Y
marmotini_ has joined #zig
<frmdstryr> That's a compiler error?
<mq32> huh
<mq32> is it forbidden to change a value of a struct literal?
<frmdstryr> Also error.Null breaks the compiler.. broken LLVM module found: Operand is null
<fengb> Oops, was playing with the other function: https://godbolt.org/z/cFeFbg
<mq32> if we had @Type() for structs, i could do user space closures :)
<frmdstryr> fengb: Doesn't seem to work right? https://godbolt.org/z/-GXR-A
<fengb> I think you need to catch it to compare?
<fengb> Might be easier to manually wrap it with a struct
<frmdstryr> Well this works https://godbolt.org/z/kHxUtn
<frmdstryr> Still seems extremely error prone
<mq32> frmdstryr, why not just use the throw mechanism in doit?
<fengb> I feel like we’re adding a bunch of layers for funsies 🙃
<mq32> fengb, yeah me too
<fengb> Seems so detached from solving the actual problem
<mq32> uart_err.toError() catch |e| assert(e == ReadError.FrameError);
<mq32> fn toError(…) ReadError!void
<frmdstryr> because it can't be saved to an "?anyerror" variable
<mq32> why do you want to use anyerror anyways?
<frmdstryr> the actual use case is to cancel a future and have the code "throw" the error later
<frmdstryr> an IRQ sets the error, the user code is is awaiting for the future to complete
<mq32> does anything speak against storing the error union directly?
<mq32> const IrqResult = struct {
<mq32> result: u8!ReadError,
<mq32> };
<frmdstryr> Actually it makes sense to just store the original "Errors" then use a generic error on the future
<fengb> mq32: lol I thought you were making a smiley
<mq32> with }; ?
<mq32> :D
_Vi has quit [Ping timeout: 246 seconds]
_Vi has joined #zig
grayhatter has joined #zig
marmotini_ has quit [Remote host closed the connection]
Akuli has joined #zig
adamkowalski has joined #zig
metaleap has joined #zig
bheads has quit [Ping timeout: 265 seconds]
marmotini_ has joined #zig
return0e_ has quit [Ping timeout: 268 seconds]
mahmudov has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
TheLemonMan has joined #zig
<TheLemonMan> pmwhite, you may be hitting https://bugs.llvm.org/show_bug.cgi?id=43383 if you're not using LLVM 9.0.1
bheads has joined #zig
<andrewrk> this is parsing syntax like "sse,avx2,fxsr" or "+sse,-avx2,+fxsr", with slightly different behavior depending on whether there are + and - found
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<andrewrk> the function does a single pass through the input, using SIMD to compute both answers, and then returns whichever one is correct, based on whether it saw + or - along the way
<TheLemonMan> speaking of that branch, I also thought we may want "pseudo" architectures like clang has
<TheLemonMan> eg. i686 -> x86 + SSE, i386 -> bare-bones x86, i586 -> x86 + ...
<TheLemonMan> admittedly it's only useful for the x86 family, unless y'all come up with other use cases
<andrewrk> those are in there, represented as cpus that you can choose
<andrewrk> so it would be: -target-cpu i686
<andrewrk> the branch disables using the flags together but maybe that should be allowed: -target-cpu i868 -target-feature +sse
<TheLemonMan> oh that's neat
<fengb> i868 🤔
<andrewrk> haha
<mikdusan> is there a `-target-cpu native` ?
<andrewrk> that's missing but I think it's a good idea
<TheLemonMan> everybody's hyped af by this patch heh
<fengb> Silly tangent: why did Intel decide to increment the middle number?
<TheLemonMan> x86 -> <revision>86
<TheLemonMan> so you have 286, 386 and so on
<pmwhite> fg
<pmwhite> oops, wrong window focused.
<mq32> ^Z
<pmwhite> :wq
<TheLemonMan> ZZ
<pmwhite> I'm having trouble using this libtmt code properly. While trying to loop over the terminal contents, I'm apparently trying to dereference 0, but it seems wrong.
<pmwhite> In C, I have a `struct TMTLINE{ bool dirty; TMTCHAR chars[]; };`
<pmwhite> In Zig, I have a valid-looking pointer to a value of this type called, say, `x`. To get `chars`, I have to do `x.*.chars`, right?
<TheLemonMan> eh, trailing VLAs are not really supported
<pmwhite> VLA?
FireFox317 has joined #zig
<TheLemonMan> Variable Length Arrays
<FireFox317> pmwhite, you did not forgot the link libc? `-lc`
<TheLemonMan> TMTLINE has only a single field, 'dirty', the other one has zero size (or 1 for some compilers...)
<pmwhite> correct, I did not.
BaroqueLarouche has joined #zig
<pmwhite> oh, so I should just change it to a pointer.
<TheLemonMan> you can access `chars` with something like @ptrCast([*]u8, &x.*.chars)
<TheLemonMan> the idea is that x points to a block of memory large enough to store 'dirty' and some TMTCHAR
<TheLemonMan> if the array is zero-terminated you can use [*:0]u8 as type (I'm assuming TMTCHAR is an u8 here) to avoid some headaches
<pmwhite> ahh, looks to be working properly.
ky0ko has joined #zig
<metaleap> treeshateorcs: made a PR (babbies first zig PR! woot) for your yesterday's suggestion https://github.com/ziglang/zig/pull/4249 btw
<mq32> MMIO leads to weird lines of code: UDR0 = UDR0;
return0e has joined #zig
<andrewrk> congrats metaleap :)
<metaleap> moar to come i'm sure =)
<TheLemonMan> BaroqueLarouche, I got some Zig code running on the nds o/
<andrewrk> pixelherodev, check out the latest layneson-cpus_and_features branch, and try running `zig targets`. the goal here is to replace the reflection in src-self-hosted/print_targets.zig, the part using reflection on Target.current to print "native"
<andrewrk> idea being to port llvm's sys::getHostCPUName and sys::getHostCpuFeatures to self-hosted and use that instead
<andrewrk> because the reflection-based approach does not work when, for example, using the downloads from ziglang.org because they have been cross compiled for a generic cpu; whereas the point of this code is to detect more specifically what CPU and features are native, not what zig compiler was compiled with
<TheLemonMan> can't we just ask LLVM?
<andrewrk> until we have a self-hosted implementation of this, I will directly call the llvm functions and then parse that output
<pmwhite> TheLemonMan: For some reason, `&x.*.chars` is 4 bytes past the correct value.
<andrewrk> yeah we can ask llvm. pixelherodev wanted to help work invest in a non-llvm future, and this is one related task
<TheLemonMan> pmwhite, how have you defined TMTLINE?
<pmwhite> You mean TMTCHAR? I already gave you TMTLINE.
<pmwhite> https://github.com/deadpixi/libtmt - it's just this library
<TheLemonMan> I mean the Zig definition, are you using translate-c ?
<pmwhite> Oh, well, I guess I could go look at the output of translate-c, but I've just been importing the header.
<TheLemonMan> yeah, translate-c should refuse to translate that structure definition
<pmwhite> using @cInclude
marmotini_ has quit [Remote host closed the connection]
<pmwhite> `pub const struct_TMT = extern struct { dirty: bool, chars: [*c]TMTCHAR };
<pmwhite> Ahh, that makes sense why it would be 4 bytes too large.
return0e has quit [Remote host closed the connection]
<TheLemonMan> if you are on a 32-bit platform yes
<pmwhite> I think I'm on 64-bit arm.
return0e has joined #zig
<pmwhite> `uname -m` gives `aarch64`
<TheLemonMan> anyway, the addressof operator should give you the address right after 'dirty'
_Vi has quit [Ping timeout: 258 seconds]
<TheLemonMan> do you have a small example to play with?
<pmwhite> I'll see if I can make one.
<mikdusan> metaleap: re #4249 take a look at `lib/std/special/build_runner.zig` . it already captures args after '--' and is available to RunStep
<metaleap> mikdusan: its a fiery coincidence that i was just idly browsing through that file, having caught eye of a 'lib/zig/std/special/' dir in my install
<metaleap> but i dont see it being used by run.zig so far so it's not "readily loaded" or anything in a `zig build` context i'd think?
<metaleap> only mention of build_runner is in build.zig 2x "/// This function is intended to be called by std/special/build_runner.zig, not a build.zig file."
<metaleap> guess the build_runner is for `zig run`
<mikdusan> build_runner creates the Builder object from zig command line driver
<metaleap> i see, so its that way around
<mikdusan> and b.run() creates RunStep which has self.builder . thus, `if (self.builder.args) |argv| {...}`
<TheLemonMan> pmwhite, what's @sizeOf(struct_TMT) and @sizeOf(bool) ?
<metaleap> ok it sets `builder.args = argsRest(args, arg_idx)` in *theory* but in *practice* when my local projects build.zigs run then Builder.args is always `null`
<mikdusan> metaleap: really? I do `zig build run -- one two three` and they show up
<metaleap> could be a bug but when i checked that i figured maybe its something for the user to fill in or such
<metaleap> zig version? nowadays not happening *at least* for me and treeshateorcs and others confirmed "you need to do that explicitly in your build.zig if you want that"
<metaleap> i mean i can see the whole logic now in build_runner and it's true it "should" be occurring. something to investigate
<mikdusan> metaleap: just added comment to gist. hope it helps
<metaleap> ahh so then the whole thing would be as simple as `runstep.addArgs(runstep.builder.args)` :D
<TheLemonMan> andrewrk, I hope that `zig targets` output won't be only in json
<pmwhite> TheLemonMan: ^
<pmwhite> error: no size available for type '.cimport:2:16.struct_TMT'
<andrewrk> TheLemonMan, I was about to make that change so that it could have all the CPUs and feature sets data
<TheLemonMan> pmwhite, thanks, I'm having a look
<andrewrk> You prefer the text format for easy reference?
<TheLemonMan> andrewrk, but I'm not a machine :( I'd love to have a terse overview of what's available
<mikdusan> metaleap: yeah I'm just wondering if `runstep.addBuilderLeftoverArgs()` is worth it
<TheLemonMan> because I can never remember the correct ARM revision to use
<metaleap> mikdusan: thx for bringing this bld.args to my attention, you were right. why that was null when i checked it earlier i have no idea but whatever fluke or other kinda oversight it was, bld.args is really properly populated. will close the PR
<andrewrk> I was hoping it would work to grep, use jq, or view in Firefox
<andrewrk> Because text format with all the CPUs and feature sets will be an overwhelming amount of information
<andrewrk> And we could have various flags to display different stuff, but then it's basically implementing an ad hoc jq API anyway
<TheLemonMan> maybe it could just display a general overview, `zig targets` -> show all targets, `zig targets <cpu>` -> show subtargets -> `zig targets <cpu> <subtarget>` -> show flags
<TheLemonMan> some kind of hierarchical display
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<andrewrk> that's what piping to jq would do: zig targets | jq arch
<andrewrk> I'm afk, not sure of exact syntax
<TheLemonMan> this reeks of the early-2000 let's-use-xml-everywhere heh
<TheLemonMan> sure thing, I can query a json document, but it's not as easy as typing `zig ...`
jjido has joined #zig
<TheLemonMan> pmwhite, you found a(nother) bug in the code computing the struct layout
<TheLemonMan> the good(?) news is that it also happens on x86_64
<andrewrk> True. Im fine with adding fancy CLI stuff to targets. doesn't hurt anything or complicate the lang spec
FireFox317 has quit [Remote host closed the connection]
<pmwhite> TheLemonMan: Of fun. Can you file it? You probably know better what the actual bug is.
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TheLemonMan> pmwhite, sure thing
FireFox317 has joined #zig
<pmwhite> I guess I'll just rewrite libtmt first.
<TheLemonMan> if anybody wants some easy compiler work to get their feet wet I've just filed 4251
<mikdusan> metaleap: if you're interested... https://github.com/ziglang/zig/issues/4252
zfoo_ has quit [Read error: Connection reset by peer]
<mikdusan> (need to wait for approval first tho)
<metaleap> ok will watch that
<BaroqueLarouche> TheLemonMan: wow! Any source code somewhere yet ?
<TheLemonMan> pmwhite, oh there's no bug (beside translate-c producing an incorrect struct), the four extra bytes are padding inserted because we don't consider the `chars` field to be zero-sized
<BaroqueLarouche> yesterday I started looking at https://github.com/ziglang/zig/issues/2826, turns out the binary mode in lld was only done for Linux and not reliable at all, even GCC binutils recommends to use objcopy. So my idea is to duplicate what objcopy does in stage1 zig code for binary and ihex
<TheLemonMan> until VLAs are somehow supported you're stuck with some nasty pointer manipulation
<TheLemonMan> BaroqueLarouche, not yet, it's mostly devkitPro crt0 & linker scripts tied together with a build.zig at the moment
<adamkowalski> if you allocate an array on the heap of size zero, does any allocation occur or is it a noop?
<adamkowalski> never mind fn alloc(allocator: *Allocator, n: usize, alignment: u29) error{OutOfMemory}![]u8 {
<adamkowalski> if (n == 0) return &[0]u8{};
<TheLemonMan> it depends on how the allocator is implemented
<adamkowalski> I was using an arena allocator on top of the page_allocator. I'm using it to encode the shape and stride of a tensor. However, if it's a scalar then the shape and stride are both the empty array. The only thing I'm worried about is that the branch predictor will probably not expect n to be 0. So maybe it's better to have a union and do something differnt for scalars entirely? Or I can at least use compile time traits to check if it's a
<adamkowalski> scalar and then do &[0]usize{} directly rather then putting an if around it
<adamkowalski> i'll profile it and make sure it's an issue first though I guess
metaleap has quit [Ping timeout: 265 seconds]
metaleap has joined #zig
_Vi has joined #zig
<TheLemonMan> mikdusan, can you isolate what declaration causes #4250 ?
<TheLemonMan> I hate bugs I cannot reproduce :(
jjido has joined #zig
FireFox317 has quit [Quit: Leaving]
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
<mikdusan> TheLemonMan: ah got you a decent reproduction I think.
Snetry has quit [Ping timeout: 258 seconds]
Snetry has joined #zig
Akuli has quit [Quit: Leaving]
adamkowalski has quit [Remote host closed the connection]
<TheLemonMan> mikdusan, thank you so much, I'm already on it
<mikdusan> unicode aficionados, I assume that font kerning for monospaced fonts is not required, but is it required for unicode combining codepoints?
<hryx> TheLemonMan + mikdusan I left a comment on 4155, hope it makes sense. I'm realizing it's been difficult to ask the right questions because I still lack some fundamental understanding of IR
mahmudov has quit [Read error: Connection reset by peer]
ur5us has joined #zig
pixelherodev has left #zig ["Leaving"]
ltriant has joined #zig
ur5us_ has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ur5us has quit [Ping timeout: 258 seconds]
metaleap has quit [Quit: Leaving]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<Snektron> Huh
<Snektron> Is zig fmt now running automatically?
<mikdusan> with vi?
<Snektron> sublime
<Snektron> oh wait, maybe because i tried to official syntax highlighting again
<Snektron> I was using someone else's because the official one highlights all types as built-in which im not quite fond of
<Snektron> also it highlights the variable name in `const a = 10;` and `const a: i32 = 10;` differently
ur5us_ has quit [Ping timeout: 258 seconds]
frmdstryr has quit [Remote host closed the connection]
lunamn has quit [Ping timeout: 272 seconds]
lunamn has joined #zig
<Snektron> Every time i think the Vulkan api registry can't get worse but then it gets worse