ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
kristoff_it has quit [Ping timeout: 248 seconds]
<Tetralux> In loops where you did use it, it'd know that it could maybe remove something and so would insert the switch on @removeType(), for example.
<Tetralux> I'm hypothesising here.
<Tetralux> But the idea is that the author of the custom struct would only have to ever write one fn to enable iteration with for loops.
<Tetralux> Period.
<Tetralux> But yes, it could be:
<Tetralux> fn iterate(self: *Self, by_pointer: bool, f: fn(ElementType) void) void {}
<Tetralux> Or rather, `comptime by_pointer: bool`.
<Tetralux> The idea of using *e to mean "I can remove this elem", is an interesting idea.
<Tetralux> Though, it's a little strange because that's talking about "can I modify the elem in the iterable?" rather than "can I remove it from the iterable?"
<Tetralux> Mutability of the value, rather than mutability of existence.
<mikdusan> to be clear i'm bring this up in regards to mutating an item, **not** mutating the list size
<mikdusan> i'll try to make time to reply to your PR. thanks for answering
<Tetralux> Oh, you mean, for instance, "I'm iterating over this iterable thing; if I find an element of a certain value, I want to update it."
<Tetralux> And I'd appreciate responses, so feel free :)
<mikdusan> (yes to the Q).
<Tetralux> AH
<fengb> In current for loops, without the * implies “const”, like function args
<Tetralux> In that case yes.
<Tetralux> It would work like fors do currently.
<Tetralux> for (iterable) |*e| { e.value += 1 }
<Tetralux> for (iterable) |e| { e.value += 1 } // error
<Tetralux> I don't see why that would be a problem. :3
<Tetralux> It may be for all I know, but I can't think of a reason rn.
<mikdusan> take a simple primitive like u32. compiler can pass by value for const iteration. for non-const it must use an underlying pointer for reference semantics.
<mikdusan> that sounds to me like iterator() has 2 different code paths
<Tetralux> It's comptime known which you take.
<mikdusan> what i mean is if i have the same program... that iterates one place as const, another place as non-const... i need 2 versions of iterate()
<Tetralux> Yeah, that seems fair.
<mikdusan> i guess no big deal if it's generated by compiler. just wanted to suss this out and make sure the programmer doesn't need to define 2 functions.
<mikdusan> i think you're correct, programmer only needs 1. i was getting confused programmer vs. compiler
<Tetralux> Oh no - the programmer would _definitely_ not need to define two functions.
<Tetralux> If they did, I'd consider it a failure xD
<Tetralux> That would be quite silly.
<Tetralux> Unless there's a good reason I'm not thinking of.
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<Mr_Slurpy> just fyi, you might already know this but "zig translate-c" seg faults when you pass it a file that doesn't exist
<Mr_Slurpy> Confused me at first lol
<mikdusan> also 0-byte file
sammich has quit [*.net *.split]
_whitelogger has joined #zig
hoppetosse has joined #zig
<andrewrk> FireFox317, the logger is back
<Tetralux> It does pass, yeah :)
<andrewrk> but does it work with a new test case that has your new align syntax
<Tetralux> *coughs*
<Tetralux> ONE MOMENT
<andrewrk> that will test parsing and rendering both, if you add a testCanonical
<Tetralux> Add a 'test {}' to align.zig?
<Tetralux> Where does the testCanonical go?
<andrewrk> ../std/zig/parser_test.zig
<andrewrk> these test the stage2 parser and renderer
<Tetralux> Added such a test to parse_test.zig; it fails.
<Tetralux> It doesn't render the align(N).
<andrewrk> unless you edited std/zig/parse.zig I would expect parsing to fail as well
<Tetralux> I did edit it ;)
<andrewrk> rendering code is in std/zig/render.zig
<Tetralux> I'm having trouble figuring out how to get the align expression from the tree so I can render it.
<andrewrk> you might find inspiration from where the other align() syntax is rendered
<andrewrk> for pointer types
<Tetralux> I can't even find that xD
<Tetralux> Ah wait - I think I just found it.
<Tetralux> When I edited parse.zig, I put the align_expr on ContainerField.
<Tetralux> Ah yes - foudn it.
<Tetralux> Man this is awkward to get your head round.
<Tetralux> Slowly figuring it out though
<gonz_> Is "{d:<32.3}" in a format string not supposed to be 32 characters wide left-aligned float with 3 decimals precision?
<gonz_> Getting the fill/alignment to make any difference at all seems a challenge.
<andrewrk> I think tiehuis either just changed that or is in the middle of changing it
<Tetralux> FINALLY
<Tetralux> It works.
<gonz_> Hmm, ok
<gonz_> But is it actually supposed to work atm?
<gonz_> I mean, am I just using it wrongly or is it plain not working at all atm?
<gonz_> I think I have my answer
<gonz_> it seems `formatFloatDecimal` & `formatFloatScientific` ignore all options except `precision`
<andrewrk> gonz_, I believe Tetralux is referring to working on a patch to zig fmt, not std.fmt
<gonz_> I was saying "Hmm, ok" to you
<gonz_> and the following was also directed at you
<gonz_> because yeah, people might be rewriting it, but was it even supposed to work before that
<gonz_> was the question
<gonz_> and "no" was the answer
<Tetralux> fmt tests passing.
<gonz_> it's not strictly a bug that alignment doesn't work for floats because it doesn't seem to ever have been written with that in mind
<andrewrk> I've only ever updated std.fmt when I personally needed it. I wasn't planning on stabilizing the interface until much closer to 1.0
<gonz_> Anyway, doesn't matter
<gonz_> I only needed it for some marginally nicer text output
<gonz_> In that PR he did add the whole options struct to the float formats
kristoff_it has joined #zig
<gonz_> But it still doesn't seem to check for width in them :/
<gonz_> So, anyway.
<gonz_> Life got a whole lot easier when I realized I could actually just `@cInclude("windows.h")` and get everything for free
<gonz_> and now I've just copied over the generated `cimport.zig` file and removed the libdirs I had to add in the build file
<gonz_> And added some of the missing things that end up a bit wonky in the import
<gonz_> ~66.9k lines of win32 goodness
<gonz_> Including hits such as "ERROR_SUCCESS_RESTART_REQUIRED"
<Tetralux> WOW
<gonz_> s/libdirs/includedirs
<Tetralux> andrewrk: Should I PR this?
<Tetralux> gonz_: I still don't know what "s/xxx/yyy" means... x'D
<gonz_> replace xxx with yyy
<gonz_> on the current line
<gonz_> (the first occurrence only)
<Tetralux> Ah.
<Tetralux> Interesting.
<Tetralux> Vim I assume.
<mikdusan> it's sed syntax. well almost. missing trailing '/'
<gonz_> It predates `vi` AFAIK, but was added to it
<gonz_> People used to use line-oriented editors back in the day like madmen
<mikdusan> real programmers use cat > a.out
<gonz_> This is probably the best wikipedia article, mostly because of the example
<fengb> Real programmers using a magnetic needle against a spinning platter
<gonz_> I think there was also a parody of this showing the typical user trying to get out of `ed`
<fengb> ?
<mikdusan> hahah exiting ed. i seem to recall an os with a default alias of 'e' to ed. royal pain.
<gonz_> fengb: Haha, yes, indeed
<mikdusan> "I'm okay with this." <-- :)
<Tetralux> ;P
<Tetralux> He has worked on it already so he'll merge it with his work.
<Tetralux> So more "already done" xD
kristoff_it has quit [Ping timeout: 245 seconds]