ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<daurnimator> Tetralux: `show(struct{})` or also `show(usize(1234))`: essentially being able to call it on anything.
<diltsman> Does Zig support Spir-V as a target?
<fengb> LLVM doesn't support it natively so Zig currently doesn't either
<emekankurumeh[m]> there is an open issue for spir-v as a target
<emekankurumeh[m]> there is also llvm-ir to spir-v transpiler
<diltsman> Ok. I couldn't remember if that was resolved or not.
<emekankurumeh[m]> with the coroutine rewrite should we really rely on llvm specific features? would that make transitioning to other backends harder?
noonien has quit [Quit: Connection closed for inactivity]
<fengb> Coroutine is no longer LLVM specific
Ichorio has quit [Ping timeout: 264 seconds]
hio has quit [Quit: Connection closed for inactivity]
<Tetralux> daurnimator: If 'type' is able to be a runtime value, isn't that just typeid/typeinfo?
<emekankurumeh[m]> I know, I mean the "prefix data" stuff
<Tetralux> daurnimator: i.e: `show(usize)` == `show(@typeInfo(usize))` or `show(@typeOf(usize))` ?
<daurnimator> Tetralux: wut?
<Tetralux> Unless I'm missing something obvious, doesn't what your suggesting amount to converting a `type` to a `typeid` or `TypeInfo` implicitly if you pass it at runtime?
<daurnimator> Tetralux: `show(usize(5))` ==> shows the number 5. `show(usize)` shows info about the type usize
<daurnimator> `@typeOf(usize) == type`
<Tetralux> I don't know how/if you can get/a typeid from a value.
<Tetralux> But I know you can get the info from one.
<Tetralux> But that's not the point
<Tetralux> Point is, `show(T: type)` -- What does it _mean_ for the type to be at runtime?
<Tetralux> Surely typeid or typeinfo.
<daurnimator> Tetralux: it's `show(x: var)`
<Tetralux> Yeah - but `var` just means "specialize to whatever you pass` , right.
<Tetralux> So it'd get specialized to `show(anything: type)` if you passed a type.
<daurnimator> okay
<Tetralux> But we have typeid/typeinfo already.
<daurnimator> and then in such a function, it would be valid to do `@typeId(anything)`
<Tetralux> So
<Tetralux> To be clear
<Tetralux> I generally like the idea.
<Tetralux> But my inclination is that if you pass a 'type' to a fn at runtime, it would not be of type `type`.
<Tetralux> Because that's the type of a comptime version of a type.
<Tetralux> Like
<Tetralux> Okay
<Tetralux> I'm maybe not being clear.
<Tetralux> If 'type' can be runtime, what's the reason for having typeid/typeinfo.
<Tetralux> Does it make sense for there to be three such things?
<Tetralux> I'm not really seeing the advantage of having three over two.
<Tetralux> But perhaps it's just not clear to me.
<daurnimator> Tetralux: I don't understand the question
<daurnimator> Tetralux: the reason for @typeInfo is to get information about a type...
<Tetralux> Indeed.
<Tetralux> i.e: the runtime version of a 'type'.
<daurnimator> ?
<daurnimator> a typeinfo is not runtime
<Tetralux> Or rather, the metadata about a type.
<Tetralux> (.. which is available at runtime.)
<daurnimator> @typeInfo is rarely valid in a runtime variable
<Tetralux> But typeid is also available at runtime.
<daurnimator> pieces of it are. but @typeInfo for most types contains comptime_ints, and child `type`s.
laaron- has quit [Remote host closed the connection]
<Tetralux> .. Whereas typeid is basically just an integer that's unique to a particular type.
<daurnimator> no it's not... @typeId is the enum of type.... types.
<Tetralux> I'm not sure that makes sense to me xD
<nrdmn> is there any good way to completely disable stack probing in PE binaries?
<daurnimator> Tetralux: @typeId returns the type of a type => i.e. Bool vs Int vs Struct vs etc.
<daurnimator> `subtype` might be a better word
<Tetralux> Sounds like `typeOf` might be a better word xD
<daurnimator> ??
<Tetralux> That sounds like it should be an enum field on TypeInfo.
<daurnimator> it is
<daurnimator> TypeInfo is a union over TypeId
<Tetralux> OH
<Tetralux> So TypeId is the tag type for TypeInfo?
<daurnimator> yes
<Tetralux> OKAY
<Tetralux> That makes a touch more sense.
<daurnimator> WHY ARE WE YELLING
laaron has joined #zig
<Tetralux> XDDD
<Tetralux> I'm not sure why you'd want to have `typeid` be a type, when you have builtin.TypeId.
<Tetralux> Since it's just the tag type.
<Tetralux> But still.
<daurnimator> what?>
<Tetralux> show(t: typeid)
<Tetralux> instead of just `show(t: builtin.TypeId)`
<daurnimator> did anyone propose that?
<Tetralux> I'm pretty sure I've seen code with that.
<Tetralux> Though, you're surprise makes me question myself a tad xD
<daurnimator> I don't see that used anywhere in the standard library
<Tetralux> Hmmm.
<Tetralux> Odd.
<Tetralux> /shrug
<Tetralux> XD
<Tetralux> But yes - if it's fair to say that both type and TypeInfo are compile time, then the difference between them is just that one is for typechecking, and the other is metadata?
<Tetralux> Is that a fair summation
<scientes> Tetralux, generally you are only going to pass around types
<scientes> or var
<scientes> everything is is just to manipulate the types
<scientes> *everything else
<Tetralux> Makes sense.
<scientes> I just ran into that today
<scientes> I will have to create a function that examines a var, and checks if the type is the type passed, or a vector with that as the scalar type
<scientes> and throws a @compileError() otherwise
<Tetralux> I might be a little spoiled from how Jai has you pass around typeinfos at runtime and only handles variables of type `type` at comptime. :D
<scientes> that sounds like dynamic typing
<scientes> we have had proposal for that, mainly stemming from wanting to return values attached to errors
<Tetralux> Nah - doing `show(usize)` in Jai would essentially the same as `show(@typeInfo(usize))` in Zig.
<Tetralux> IIUC.
<Tetralux> It's been a while since I saw him show that off.
<Tetralux> Except that TypeInfo in Jai, is not comptime.
<scientes> i really dislike dynamic typing
<scientes> because a bunch of errors get pushed to run-time
<scientes> that could be caught at compile-time
<scientes> maybe we should have sets of types
<scientes> instead of just "var"
<scientes> type theory is really complicated...
<Tetralux> Meh.
<Tetralux> I like var, because it means something specific: specialize to whatever type you pass.
<Tetralux> Though maybe that could be more explicit?
<scientes> well you end up writing your own type checking code
<scientes> I haven't worked with haskell much or really understoood it, but people that do say the type system is great
<Tetralux> I haven't needed to try yet
<Tetralux> But I'd start off trying to just assume I can do certain things with the type.
<fengb> The people who can understand the type system say it's great :P
<torque> is a union not a set of types
<Tetralux> (the var of the type passed)
<torque> I guess the issue is runtime specialization with unions
<Tetralux> In my limited experience, it's kinda wordy - like Java. But "worse.2
<Tetralux> "worse."
<scientes> torque, yes
<scientes> you need a way to tag the union with an enum
<scientes> and then the grainy issue of trying to provide type safety to that, and even compile out the enum at times
<scientes> cause dynamic types actually kinda suck
<fengb> You could use it as a pseudo functional type union but it's still statically defined
<scientes> yeah but you are checking the type id
<torque> dynamic types suck a lot which is why people have spent ridiculous amounts of effort shoehorning static typing into languages that are inherently dynamically typed (see typescript and python)
<fengb> So it's not as flexible as an ML-like union
<scientes> like full-blown dynamic typing really sucks, but having sets of types is quite reasonable at times
<torque> julia has the most understandable and expressive typing system I've run into (though there are probably other languages that are as good or better)
<fengb> Haskell is expressive :P
<fengb> Elm is understandable >_>
<scientes> zig's type system is already quite expressive
<scientes> **quite rich
<scientes> but not very expressive
<fengb> On principle, I kinda wish Zig has traits or interfaces or something of the sort... but I haven't encountered a strong need
<scientes> it has interfaces
<scientes> compile-time
<fengb> I mean runtime
<scientes> but why?
<fengb> Zig's generics is surprisingly good
<scientes> what does that give you
<scientes> fengb, beautiful
<scientes> i'm kinda a zero-cost abstraction person
<fengb> The allocator "interface" is pretty kludgy
<fengb> It works but it's via magic pointer offset voodoo that's easy to break
<scientes> its not voodoo
<scientes> @fieldParentPtr is better than Linux's container_of() macro
<scientes> and it is also zero-cost
<fengb> There's a ticket that explains the cost. It's hostile to LLVM optimizations
<scientes> but yes there is a good proposal to add type safety to @fieldParentPtr()
<fengb> I think it's pretty cool we have userland interfaces, but it also feels rather hacky
diltsman has quit [Read error: Connection reset by peer]
<scientes> @fieldParentPtr is something that go fundamentally can't do
<fengb> But again... I haven't encountered a strong reason in awhile. Just a principle thing that I want some sort of dynamic dispatch :P
<scientes> and they are tons of cludges in go to do half of what it does
<scientes> but yes that proposal is great
<Tetralux> I don't want dyn dispatch.
<Tetralux> I want that to be very obvious.
<Tetralux> And be discouraged.
<scientes> dynamic anything is risky
<Tetralux> Otherwise Rust traits happen everywhere xD
<Tetralux> Or well - not quite cuz those are more static.
<Tetralux> But dyn traits -- nope.
<fengb> I just want a little polymophism. I've gotten by with function pointers just fine, but that's because I have statically defined fields
<fengb> But again... it's a "want", not a need so far
<scientes> fengb, yeah it would be nice to have "safe" dynamic casts
<scientes> not only @fieldParentPtr, but also specialization
<scientes> like IrInstruction in stage1
<scientes> but I guess that is union(enum)
<fengb> Union only works if you know all the types ahead of time. Although... most of the complex usecases I can remember about using polymorphism were all predefined
<scientes> wut?
<scientes> types are always comptime
<fengb> nvm
<scientes> uggh, its late i should go to sleep
<scientes> what about a ways to limit the amount of language features a program uses?
<scientes> nah
<scientes> that is only relevent if you want your langauge to be "safe"
Sobeston has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
ntgg has joined #zig
darithorn has quit [Quit: Leaving]
ntgg has quit [Quit: Lost terminal]
<emekankurumeh[m]> Sobeston did you make any progress on that issue you were having earlier?
_whitelogger has joined #zig
<emekankurumeh[m]> grr, i just figured out the error i was having
<emekankurumeh[m]> linking libc for mingw-w64 moves the section with the pdb info
<emekankurumeh[m]> i just realized lld can generate dwarf debug info for windows executables, so that raises the question when building zig executables on windows for mingw do we use pdb or dwarf?
<gonz_> I would assume tools will have pdb support
<gonz_> There are debuggers that will read pdb but not the way llvm creates them, as well, for example
<gonz_> so the most valuable option on Windows is to do it exactly the way `cl` would do it
<gonz_> The `RemedyBG` debugger doesn't work properly with zig, for example.
<gonz_> Happily windbg does
<emekankurumeh[m]> is the issue with lld's pdb's
<gonz_> As far as I can see on their issue tracker it's something like that, yes
<gonz_> They don't read the way lld/LLVM does it
<gonz_> Presumably this should be an easy add for them, but they're not prioritizing it
<gonz_> I think one ought to try everything and see what works best, obviously
_whitelogger has joined #zig
ArtlessMaladroit has joined #zig
<ArtlessMaladroit> Hello community, attempted convertee here. I'm trying to port some projects to Zig to get myself familiar with it and I've run into a road block with function pointers. I'm trying to do something like: "pub const FnAlias = ?extern fn([*]const u8, ...); pub var FnPtr: FnAlias = null;" which I then later assign to at runtime with "FnPtr = @ptrCast(Fn
<ArtlessMaladroit> Alias, addrOrigFn);" this is all fine but then when I later try to call it like: "FnPtr(args);" it reults in a compile error that the type isn't a function. What's the proper way to do this, or if not this, achieve the same effect of converting an address to a potentially null function pointer?
<gonz_> ArtlessMaladroit: Can you put a minimal example of what you want up on godbolt for people to see what you mean and play around with?
<gonz_> (, it has zig support)
<gonz_> This seems like a minimal example of something like what you're talking about, correct?
<gonz_> Here's a modified version that unpacks the `?`:
<gonz_> Using `if (possibly_null) |unpacked_value| { doStuff(); }`
<gonz_> ArtlessMaladroit: Given the possible nullity of that variable, unpacking it explicitly is a very good way of handling it
<ArtlessMaladroit> Here's what I was originally trying to do: will test out yours here shortly. Thanks for the feedback
<gonz_> Considering the type of `FnPtr`, it's certainly not actually a function. It's *maybe* a function.
<gonz_> I think the current situation at least points to it being just a type error because maybe null has to be checked
<ArtlessMaladroit> gonz_ Tried it out and it also gives me the TODO error. I guess it's just not implemented yet?
<gonz_> Can you paste the error if it's not too wordy?
<gonz_> Ah, the TODO with the issue
<ArtlessMaladroit> error: TODO: support C ABI for more targets.
<gonz_> Just to double check as well, is this on master?
<ArtlessMaladroit> I think I'm a bit behind: version 0.4.0+1547692d I'll go download master now and check though
<gonz_> I have no idea how much recent activity has been done on this, but you never know without talking to andrewrk
<ArtlessMaladroit> Yeah, the error persists on master as well. I'll follow the progress of the issue, just wanted to make sure I wasn't just doing something very wrong. Appreciate the feedback.
<gonz_> Is the use case trying to load one of the many different versions of DLLs depending on which is available, etc.?
<ArtlessMaladroit> Yep, getting the module of a loaded dll then calling GetProcAddress and attempting to assign that to a global variable to be called from elsewhere.
kristoff_it has joined #zig
_whitelogger has joined #zig
Ichorio has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
ArtlessMaladroit has quit [Ping timeout: 260 seconds]
<Sahnvour> gonz_: interesting remedyBG doesn't work with zig executables, because LLVM tries to follow PDB format as closely as possible
<Sahnvour> and in fact does, because it can build complex C++ project and have native debugging working perfectly with windbg/visual studio
<gonz_> Reality is often disappointing.
<gonz_> The highest hit rate with regards to debugger friendliness will undoubtedly be "do it exactly how `cl` does it" regardless of whichever values one has.
NI33_ has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
<scientes> what about a bit pointer type
<scientes> (that can't be volatile)
<scientes> cause large bit manipulation is so painful
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
<scientes> Yeah a bit pointer type would make it much less painful
<gonz_> scientes: Did you just agree with yourself? :D
<scientes> well i'm doing it and its painful
<scientes> to bit pack
<scientes> what we could have would be "packed" pointers
<scientes> like var a: *packed u7 = undefined;
<scientes> which would underneath be a bit pointer
<scientes> and if you did pointer arithmatic it would move 7 bits at a time
<scientes> once you think about it this whole byte thing is the weird thing
<scientes> and 64-bit machines don't really need bytes
<scientes> because they have so much address space
Akuli has joined #zig
<gonz_> scientes: I don't think I quite understand what it is you're doing. Is there some way you can illustrate what it is and what the purpose is?
<scientes> well I'm writing @bitCast to work with vectors
<scientes> and it means i have to serialize
<scientes> and it is just annoying that I manually have to deal with the fact that pointers only address bytes, and not bits
<scientes> the code would be WAY simpler if I could just have bit-granularity type sizes and pointer addressing
<scientes> it would also mean zig was more portable, if everything was just in bits
<scientes> a 8-bit byte pointer would just refuse to be taken out of alignment
<scientes> the language would be quite a bit simpler if the concept of bytes was completely eliminated, except in @alignOf()
<scientes> and @sizeOf()
<scientes> but @sizeOf() would require bits
<gonz_> Do you know of any examples of this being done previously on a big scale?
<scientes> no
<scientes> it could be done with proper types however
<scientes> all at compile-time
<scientes> generally you would still be using bytes under the hood, as that is how current hardware works
<scientes> but there really is no need to have that be part of the language
<scientes> i.e. most pointers would have align(3), i.e. byte aligned
<scientes> and that would be the default
<scientes> **that would be default due to the way @sizeOf works
<scientes> you would have to use "packed" to override that
donpdonp has quit [Ping timeout: 245 seconds]
<mikdusan> can you provide an example of a vector bitcast?
<scientes> var a: @Vector(4, u32); return @bitCast(u128, a);
<mikdusan> and anything under u8 is not applicable, correct?
<scientes> no i want to make those work too
<scientes> there is no reason to not support everything, even if it won't be as performant
<mikdusan> iirc you mentioned ppc did not pack vectors
<scientes> that is just the result of comparisons
<scientes> is a sext bool of the size of what was compared
<scientes> which means you can use bit-wise | and & on it
<scientes> that's kinda nice so I wanted to add a implicit cast from vectors of bools to that
<scientes> if the number of elements is the same
<companion_cube> weird question, but is there a way to index using isize and not usize? it's for a C pointer from weird code
<scientes> yeah Linux has that: ssize_t
<scientes> so does C++ with ptrdiff_t
<scientes> (ptrdiff_t BTW is an abomination)
<companion_cube> so should I cast my int to isize?
<scientes> companion_cube, use @intCast()
<scientes> which will panic (in debug mode) if the integer is negative
<companion_cube> but if I cast -1 into an usize?
<scientes> it will panic
<companion_cube> ah but that's the thing: this code uses actual negative indexing
<scientes> undefined
<scientes> oh, then use isize type
<companion_cube> (the pointer is in the middle of the array…)
<scientes> ahhh
<scientes> yeah that is a feature request
<companion_cube> :D ok
<scientes> to allow that for [*] arrays
<scientes> but you could do it with pointer arithmatic
<companion_cube> it's for [*c] here, as it's a lot of magic
<Tetralux> For clarity, `(ptr-1).* = ...` would modify the memory one memory address unit lower than the ptr value?
<Tetralux> Or "behind" the value, if you prefer.
<Tetralux> (Closer to NULL.)
<Tetralux> Well no - that's not it. You can do that already.
<Tetralux> Or am I wrong?
<Tetralux> I probably am lol
<scientes> Tetralux, you can by doing (ptr+offset).*
<scientes> but I don't think you can do ptr[offset] where offset is a signed number
<Tetralux> You can do ptr[offset] for [*]T ptrs in Zig
<Tetralux> ?
<Tetralux> I don't think I've ever actually tried that.
<scientes> > where offset is a signed number
<Tetralux> To be clear, you _can_ do it right now, just not with a signed value?
<scientes> yes
<Tetralux> Okay.
<Tetralux> Then yeah, that does sound somewhat reasonable to me.
<Tetralux> companion_cube: You probably did this already, but the workaround would be to @ptrToInt, subtract the amount, and then @intToPtr again.
<Tetralux> I believe that would work.
<scientes> also check if pointer arithmatic work
<scientes> i think it does
<scientes> (ptr+offset).*
<Tetralux> For -1, it'd be (ptr-1).* -- but yes. I believe that works on [*]Ts.
<companion_cube> no I didn't try, sounds like a good workaround
<scientes> Tetralux, you can add a negative number
<companion_cube> although it'd subtract in bytes, rigt
<companion_cube> right?
<scientes> no, add
<scientes> well yes
<scientes> i didn't read the whole sentence
<Tetralux> XD
<scientes> companion_cube, no bytes at all
<scientes> that concept doesn't apply
<scientes> it subtracts/adds in the ABI size of the type
<scientes> that's why I opened this
<scientes> the concept of bytes is confusing and unnecessary
<Tetralux> I believe companion_cube is asking if for [*]T, (ptr+offset).* would be (ptr+(offset*@sizeOf(T))).*
<companion_cube> oh so the integer is really a multiple of the sizeof T, not a number of bytes
<companion_cube> yes tat's the question!
<Tetralux> I don't think I've needed to test that yet, but I'd be surprised if the offset was not in "number of Ts"
<scientes> thats why sizeof should just return bits
<Tetralux> (I would expect it to move my sizeOf(T) and not bytes.)
<Tetralux> my => by *
laaron has quit [Remote host closed the connection]
<Tetralux> I'm not entirely clear about why returning bits is more useful.
<scientes> Tetralux, because it eliminates "bytes" from the language
daurnimator has quit [Read error: Connection reset by peer]
<scientes> it removed an entire concept
<scientes> *removes
<scientes> a concept which doesn't really help portability either
<Tetralux> I use bytes all the time, so I'm not sure what you're suggesting xD
<Akuli> the c standard defines byte as a thing that has n characters for some integer n >= 8
<Akuli> so you could have a system where c's char, a type whose size is one byte, is 32 bits
<scientes> Akuli, yeah its way too complicated and completely unnecessary
<Akuli> like someone on so said
<scientes> and the only place where it really matters, @ptrToInt, and @intToPtr, the C standard is silent
<Akuli> for any machine connected to internet, char is 8 bits
<scientes> yeah and Zig will continue to support that
<scientes> but with size "8", and not "1"
<Akuli> :)
<Akuli> so in zig we just call it u8 and that's it?
<scientes> no, there is also c_char
<Akuli> mmh lol
<companion_cube> well u8 is a char, right?
<scientes> guess there is not c_char
<scientes> companion_cube, no, on x86 it is i8
<scientes> but on arm it is u8
<companion_cube> well unsigned char
<Akuli> there are systems where c's char is u16 or u32
<scientes> yeah we should probably have c_char there too because of that
<companion_cube> anyway, the unit for utf8
<Tetralux> Personally, I'd find 'oct' (for octet) easier to type than u8 - not that I'm seriously suggesting that change.
<Akuli> put your index finger on u, middle finger goes to 8 automagically
<Akuli> u8
<companion_cube> u8 is very explicit ♥
<Akuli> (sorry i assumed that you are using a querty keyboard)
<Tetralux> Akuli: I just haven't needed to type u8 _that_ often in comparsion to normal typing and so my muscle memory for it is not quite as fast as it might otherwise be.
<Tetralux> I also do like both the consistency and simplictly of u8.
<Tetralux> I like u8.
<Tetralux> I just don't like typing u8 xD
<scientes> Tetralux, it isn't an octet, that would be u3
<Akuli> to type oct, i type o with my right hand middle finger, then i type both c and t with left hand index finger, moving it from c to t
<companion_cube> const myByte = u8; ?
<Akuli> hmm
<Akuli> const hex = u8;
<Tetralux> Akuli: I type 'o' with my right hand and the other two with my left. All index fingers.
<Tetralux> scientes: No, it is octet.
<Tetralux> That's a well established name for a byte AFAIK.
<Tetralux> (A byte that is 8 bits.)
<companion_cube> ugh, this C code does so many ugly things
<Tetralux> Perhaps I'm wrong but... :)
<Tetralux> Akuli: Well yeah, I could define const oct = u8, but then it doesn't light up in my highlighting and I feel sad xD
<Akuli> write a better highlighter :D
<Tetralux> No point - it's Sublime.
<Akuli> i think there should be a way to put common typedef names or similar in editorconfig
<Tetralux> I just don't wanna have to fiddle with it.
<Tetralux> I want to have an editor that just works (TM).
<Akuli> i wrote my own editor so :D
<Tetralux> Can I have it? xD
<Tetralux> I've considered 4Coder. It has some things I like, but...
<Tetralux> Not there y et.
<Akuli> tbh it just uses a library for highlighting
<Akuli> but that library is customizable
<Tetralux> Does it just have Py highlighting?
<Akuli> no it highlights pretty much anything
<Tetralux> Nope - just read that part in the readme xD
<Tetralux> Pygments is what Github uses no?
<Akuli> github used pygments before i think, they don't use it anymore
<Tetralux> Only, I program in Odin too and GH doesn't have highlighting for that.
<companion_cube> you like to live on the edge
<Tetralux> I like to use nice tools x)
<fengb> How about V then? :P
<Tetralux> I'm the guy that wants to buy a £15 mechanical pencil.
<Tetralux> But doesn't do that very often.
<Tetralux> I have... questions about... V. xD
<Tetralux> If I had the complete source code of it, then... /shrug.
<Tetralux> Depends how nice it is to use and debug stuff with.
<fengb> It’s been released
<companion_cube> there's 0.1% chance that V will yield anything useful ever
<Tetralux> One of my biggest complaints is that there isn't really a good debugger on Windows.
<Tetralux> VS is basically all you've got.
<Tetralux> GDB is damn near a hazard to install on windows.
<scientes> just debugg in wine
<Tetralux> And debug info is off in VS.
<Tetralux> (off meaning not entirely accurate)
<Tetralux> I could, but that's god-awful slow.
<Tetralux> Though it does help you debug bad winapi calls which is a godsend.
<Tetralux> I didn't know it did that.
<Tetralux> wine-dbg takes over five seconds to even begin running the program.
<Tetralux> I like having a simple lightweight interface where I can easily _discover_ how to use it/
<Tetralux> Like data breakpoints. I'd have to wade through text menus to figure out how to do that in gdb.
<Tetralux> VS isn't really much better. If at all.
<Tetralux> I don't wanna spend hours figuring out how to do the thing I want.
<Tetralux> I want to ask it and have it tell me.
<Akuli> look it up on google :)
<Tetralux> That's why I like the windows start search so much.
<Akuli> i know about 4 gdb commands and it's enough for my debugging needs
<scientes> eventually you will need reversable debugging
<scientes> and conditional breakpoints
<scientes> but yeah i was like you for a long time Akuli
<Akuli> don't tell me what i need, i survived for years with print
<Akuli> not in c though
<scientes> oh wow
<Akuli> but i still debug everything with print in other programming languages
<scientes> well of course
<Akuli> it's easy and it works
<scientes> but debuggers are nice
<Akuli> i think i have actually used the python debugger like once
<Tetralux> Personally, I want to see someone write a debugger where you can just search for keywords about what you want to do, and it just tells you and lays out how to do it.
<companion_cube> print is nice for logic bugs, debugguers for index/memory errors, in my experience
<Akuli> i just valgrind to find memory issues :D
<Tetralux> print is terrible if you want to monitor multiple things at once and see if one changes as you step though.
<Akuli> so are my 4 debugger commands, why would i want to do that? lol
<Sahnvour> Tetralux: what do you mean debug info is off in VS ?
<Tetralux> In C/C++ it only shows you the line, not the stmt that's running, and in Odin/Zig it doesn't even correctly do that.
<Sahnvour> well that depends more on the debug info itself
<Tetralux> Sometimes you have to press step-forwards twice to go to the next line.
<Tetralux> This is rediculous man xD
<Akuli> if line only is a problem, you have too much stuff on your lines
<Tetralux> I tend to like to do things like `if (!x) return 0, false` etc.
<Tetralux> But still
<Tetralux> For instance
<Sahnvour> in zig it actually does highlight the expression being run, and there can be multiple ones on the same line
<Tetralux> Maybe you want `f(g(x))` to show you what g(x) gives back
<companion_cube> so when you write in a higher level language, most errors are logic errors so debugguers are less useful
<scientes> if your language is turing complete you will have to debug it at some point
<Tetralux> Like
<Tetralux> Don't get me wrong
<Tetralux> I think that Zig's stack traces for errors are very useful.
<Tetralux> The less time I spend in a debugger the better.
<Tetralux> But I still want to have a debugger.
<Tetralux> If I have a complex program, I probably need a debugger.
<Tetralux> Though, if any language has a chance of overcoming that
<Tetralux> I'd probably be Zig.
<Tetralux> JUST because of those traces, and segfault traces, and memory traces in general because of the debug allocator.
<scientes> yeah i kinda agree
<Sahnvour> all these things are nice to have, but nothing new and don't remove the need for a debugger ever, I think. In any sufficiently complex program you will end up having to inspect its state when the behaviour seems wrong.
<companion_cube> hmm, in vim I used to have error report on save, but not anymore — is it because the build requires --library c inthis case?
<Sahnvour> bugs are not just about crashes and memory leaks
<scientes> Sahnvour, it still saves you when you can't reproduce the problem
<scientes> so i think its a good idea
<Sahnvour> it's great indeed, just not solving every problem where a debugger is handy :)
<scientes> UML just introduced time travel
<scientes> so time jumps forward if there is nothing to do
<scientes> and you can even set it to make all cpu take zero time
<Tetralux> Akuli: Awwh dangit - the editor doesn't have DPI awareness?
<scientes> yeah, maybe i wont buy a 4K laptop
<Tetralux> Oh?
<Tetralux> I did. I'm spoilt for life now.
<Tetralux> Text is nice to read now xD
<gonz_> I think there are certain circumstances that make debuggers more or less useful. In Erlang I've literally never wanted a debugger because all the interesting bugs happen in code that does message passing.
<gonz_> Using stop-the-world debugging in a system like that will change the entire dynamic of the system and effectively make it behave abnormally.
<scientes> how do i test if the bits in one number are differn't from the bits in another number, i.e. 1010 | 0101 (differn't), vs 1010 | 1101 (some the same) ?
<scientes> oh, you have to do assert(a | b == a & b)
<fengb> Xor
<scientes> ** assert(a | b == a ^ b)
<fengb> If there's *any same*, that'd be `a ^ b != 0`
<scientes> fengb, not true
<scientes> for intersection you need both or and xor
<fengb> Oops, that's any different. I got it mixed up
_whitelogger has joined #zig
<scientes> which is actuall nor
<scientes> *nor
<scientes> and you can do everything in a computer with only nor and if
avoidr has joined #zig
<Akuli> Tetralux, what is dpi awareness :D
<Tetralux> I'm not entirely sure if you're serious or not xD
<Akuli> i am
<Akuli> i know about pixels and not much else
<Tetralux> To my knowledge, high DPI will not work on programs that do not declare themselves as "DPI aware"
<Tetralux> This means that on high-res screens (like 4k screens) the program with render things blurry.
<Akuli> pixely or blurry?
<Tetralux> Blurry.
<Tetralux> Because it's basically a bitmap scale.
<Akuli> how else would a display work than with a bitmap scale?
<Tetralux> But if they are DPI aware, then they automatically (I'm not sure if Windows does it or the program does it) render things at the larger size.
<Tetralux> So fonts that are drawn will be drawn at a larger point size.
<Tetralux> For example.
<fengb> On a Mac, they treat high DPI at a lower resolution: 2880x1800 is treated as 1440x900 in the math
<Akuli> does a font with size 12px render with more than 12px of precision?
<fengb> So if you're not high DPI aware, it'll render as upscaled 1440x900
<Tetralux> fengb: You mean they render at a large size and scale down if not DPI aware?
<fengb> No I mean they're rendered at "native" 1440x900 and then scaled up to 2880x1800 physical pixels
<Tetralux> Does "native" mean "the size of your primary screen" ?
<fengb> Dunno how it works on other OSs, but the Mac basically has "half pixels" on HDPI
<Tetralux> Akuli: If DPI aware, it'll essentially just increase the font size to be the appropriate amount, rather than bitmap upscaling it.
<Tetralux> I don't know how you actually make that work though. I *think* it does it automatically if you do the winapi call to declare that you are dpi aware.
<Akuli> which operating system do you have?
<Tetralux> But I've never actually written a program that uses it so I don't actually know.
<Tetralux> Win 10 x64.
<Akuli> i only have windows 10 in a vm, and it eats up 4gb of ram every time i start it, lol
<Akuli> not exactly a thing i want to touch when not needed
<Akuli> if you can get it to work, please send a pull request :)
<fengb> Fonts are mostly vector based so I'd expect most fonts to behave correctly at HDPI, e.g. 12px might not be physical pixels
<Akuli> you can call winapi functions from python with ctypes, something like ctypes.winapi.SetProcessDpiAwareness(1)
<fengb> Tetralux: my terminology is confusing. Mac treats 2880x1800 physical pixels as 1440x900 software pixels. And each software pixels can be referenced via float half-pixel
<fengb> So if the software is not HDPI aware, it works just fine but everything is blurry because they're 2x upscaled
<Akuli> hmm or maybe it's something like ctypes.CDLL(ctypes.util.find_msvcrt()).SetProcessDpiAwareness
<Akuli> it's been a while since i used ctypes
<Akuli> i found some code for you :D
<Tetralux> So I took a brief glance at the code
<Tetralux> But cannot figure out where the entry point is.
<Tetralux> xD
<Tetralux> If I could, I'd try putting a call to the winapi at the top of main
<Tetralux> ctypes.windll.LoadLibrary("shcore")
<Tetralux> ; ctypes.windll.shcore.SetProcessDpiAwareness(2)
<Tetralux> Something like that.
GoorMoon has joined #zig
<Akuli> for a quick and dirty hack, just put it to any of the porcupine/ files :D
<Akuli> the more correct place for it is the main() function in porcupine/
<Akuli> porcupine.init(blah blah) creates the window, so you need to put it before that
<Tetralux> Already tried putting it at the top of main. Even assert(False) didn't assert there.
GoorMoon has quit [Remote host closed the connection]
GoorMoon has joined #zig
GoorMoon has left #zig [#zig]
<Akuli> how are you running porcupine?
<Akuli> you likely have two porcupines now, an installed porcupine and a porcupine from 'git clone'
<Akuli> i have multiple porcupines too, i use one for all real work, including developing the other one :D
rjtobin has joined #zig
<Tetralux> Where does it install it to?
<Tetralux> When you don't clone it.
<Akuli> i don't remember :D run py on cmd, then type 'import porcupine', then just 'porcupine'
<Akuli> if you have a cloned porcupine, cd to the directory where readme is and run 'py -m porcupine'
<Tetralux> Ta
<Tetralux> That worked
<Tetralux> So calling SetProcessDpiAwareness(2) before init makes it not blurred
<Tetralux> But it then it's small, because it's at native resolution.
<Akuli> mmh
<Akuli> awesome
<Tetralux> So now everything that's rendered has to have it's size scaled to the DPI of the screen you are on in order to be a good experience.
<Akuli> i think i know how to make the font sizes bigger
<Tetralux> The default is 96DPI. You get a message on the windows message loop when the DPI changes.
<Tetralux> You also have a winapi call that tells you the DPI you're actually dealing with.
<Akuli> there is this thing i found and i have no idea what it does
<Tetralux> I found this if it helps
<Akuli> oh you found a tkinter question too
<Tetralux> ;)
<Tetralux> Giving 1 to SetProcessDpiAwareness means that it only detects the DPI at startup (bad) - and 2 means it updates when the DPI changes (like if you drag it onto a different monitor) (good.)
<Tetralux> If it's 1, it takes the DPI of the monitor it first appears on, at first glance.
wootehfoot has joined #zig
dimenus has joined #zig
reductum has joined #zig
noonien has joined #zig
<scientes> wow, once you get use to zig's safety C is painful
<companion_cube> once you tried anything else…
<scientes> heh, I like C!
jjido has joined #zig
<scientes> …
<scientes> hmm compose plus TWO . is …
<scientes> should be three
<companion_cube> …
<companion_cube> ‽¿¡
<companion_cube> damn I'm spoiled by languages with stdlib docs and LSP :s
<scientes> LSP?
<companion_cube> language server protocol
<companion_cube> I mean a semantic plugin
<scientes> well i don't have enough memory for that
<scientes> even for c/c++
<Akuli> some day i'll implement lsp support in my editor :D
<Akuli> for now, grep ftw
<companion_cube> well works for OCaml and rust :s (even though the rust plugin could be improved)
<companion_cube> jeez I dislike this block expression syntax so much
<hryx> companion_cube: what do you dislike about it?
<scientes> the blocks are so powerful
<scientes> and awesome, because you can comptime initialize things
<scientes> they are def. differn't, but once you start getting use to them
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<companion_cube> hryx: it's verbose and there's a useless name
<companion_cube> I just want {foo; bar; x} -_-
<companion_cube> (so it's easy to turn `x` into `{ warn(whatev); x }` and conversely, for example)
<scientes> but that would break the arguments are const thing
<scientes> well i guess it wouldn't have to
<scientes> what is wrong with "return x"
<hryx> the label isn't useless when you have nested blocks, but a lot of people do wish for the ability to break without one
<hryx> there was discussion recently on GitHub if I recall
<scientes> explicit returns are ugly and a thing of dynamically typed languages
<scientes> not really a fan
<scientes> *implicit returns
<companion_cube> hryx: it should be optional ten
<companion_cube> then*
<Tetralux> "Only one way to do things."
<companion_cube> like, sure, if you have a weird case where you want to return from several nested blocks, name the outside one
<companion_cube> same as for loops
<companion_cube> would you want to name every single loop?
<scientes> Tetralux, optional names I don't think beaks that
<scientes> its still the same way
<Tetralux> I meant optional return to break with a value
<companion_cube> also `return` I find a bit ugly too, but well
<scientes> yeah I can see making the name optional
<scientes> but I like the "return"
<companion_cube> (again it's useful for early return, but shouldn't be required for one liners)
<scientes> it means that everthing is a statement
<Tetralux> While I've become a little more okay with naming every block I'm returning a value from than I was when I started, I still have the same idea of not wanting to _have_ to name it.
<companion_cube> everything should be an expression :/
<scientes> although I guess return is a little weird, because it comes from C where sizeof alignof offsetof and return are special things
<scientes> that are not functions
<Tetralux> Arguing that return is from C seems a little weird to me.
<companion_cube> just pick rust's syntax and remove the traits, borrow checker, and use simpler error handling :p
<Tetralux> And impl syntax.
<companion_cube> yeah sure
<Tetralux> And generic syntax.
<companion_cube> but the expression syntax is awesome, imho
<companion_cube> it's nonambiguous and clean
<Tetralux> That's in the form of:
<companion_cube> (again with the `while … { … }` and `if … { … }` without parenthesis but with mandatory braces)
<scientes> what's wrong with zig error handling companion_cube ?
<Tetralux> `let x = { code; return x; }
<hryx> sorry, I can't find the discussion about breaking to parent block without a label. I think the proposed word was `result`
<scientes> I have a few issues, but I think the idea is sound
<hryx> there may have also been a proposal for implicitly returning last expression but not sure
<scientes> hryx, yuck, just use "break"
<companion_cube> scientes: it's good!
<companion_cube> I mean, it's one of the differences with rust
<hryx> scientes: wasn't my proposal
<scientes> yes
<fengb> hryx: it ended up being rejected as being too foreign and named blocks are “good enough”
<companion_cube> but what I mean is that syntax is my least favorite part of zig
<companion_cube> well, it's good, but it could be closer to rust and gain from it imho
<Tetralux> Oh yeah - and that semicolon after the block name when you break?
<scientes> fengb, but we already have implicit scope with while and for
<hryx> fengb: thanks, I forgot it was closed. here's the issue for anyone interested in the previous discussion:
<fengb> Yeah, the break emulates C / Java style where it’s loop based
<scientes> and if() is not a block
<scientes> for the implicit scope
<fengb> Block based return languages don’t have a good return keyword afaik
<scientes> we already have these rules for while and for
<scientes> so just expand it to include result blocks
<fengb> I think it’s not ideal... but it fits existing paradigms. I kinda wish there’s a breakloop keyword and break is just nearest block
<scientes> with break returning a value (and continue and next compile errors)
<companion_cube> I just wish it'd be as simple as rust -_-
<scientes> otherwise, you could have two differn't sets of implicit blocks, and return could be the keyword
<fengb> Or make loop breaking the weird case that needs a label
<scientes> because it does not make sense to return from a function in a initialization block
<scientes> but then what if you wanted to return an error?
<scientes> uggh
<scientes> so probably break
<scientes> yeah closures would make sense here as is mentioned
<scientes> and you could return an error by using try to run the closure
<fengb> I don't want a closure just to break. Reminds me of IIFE hacks in JS
<scientes> closures don't have to be ugly
<scientes> look at how go does them
<companion_cube> |x| { x+1 }
<companion_cube> or `fn(x) { x+1 }` maybe
<fengb> I also don't like the Go version. Specifically, immediate execution closure is basically a block
<hryx> yeah, in Go you commonly find IIFE too
<hryx> namely in defer
<fengb> Like... go func() {} is a programmer error but the compiler won't warn you
<fengb> Whereas a Zig-like block would be `go {}` and really hard to screw up
<scientes> but why can't blocks be closures
<scientes> you would just have to add a (); at the end
<scientes> ahh yeah that is a problem, you don't always want to have to add ();
<companion_cube> 😱
<fengb> Because they aren't the same? I suppose you could make them the same but you need syntax to distinguish definition versus execution
<scientes> but they are if you immediately run them and they don't take arguments
<companion_cube> what's wrong with `fn (x) { … }` ?
<scientes> oh, binding variables
<scientes> i see
<fengb> Still different from defining and executing. Go style forces you to run it, which is easy to forget
Akuli has quit [Quit: Leaving]
<scientes> companion_cube, so fn (x) { … }(foo); ?
<companion_cube> uh, no, I meant for writing actual closures
<fengb> Oof, I forgot Go doesn't actually capture the variable in a sane way
<companion_cube> why would you do that?
<scientes> companion_cube, you wouldn't but you could
<companion_cube> yeah but there's no point
<hryx> Does anyone here have experience reading the output of --verbose-ir? I could use some tips on getting started
<fengb> Anyway, I think closures are out of scope here. We can use them to emulate blocks, but we don't have them and they open a can of worms on where to store the context
<scientes> companion_cube, more like fn (x: u32) { |x| … }
<Tetralux> fengb: Maybe.
<Tetralux> Whatcha got?
<scientes> ohhhh i see
<scientes> not annonymous functions, but closures
<scientes> differn't things
<scientes> I'm too use to C
<scientes> yeah, I would be happy with annonymous functions
<scientes> for now
<scientes> as fengb says, closures are a can of worms
<scientes> C's lack of annonymous functions is annoying
<hryx> "can of worms" was my experience when daydreaming about closures in zig
<fengb> There's a proposal and I think they're a good idea, but I'm not sure how cleanup would happen
<companion_cube> yeah memory management is messy
<scientes> fengb, but how about implementing annonymous functions now, and thinking about closures later
<companion_cube> and it's probably superseeded by coroutines anyway
<companion_cube> tbh I can't imagine anything simpler and cleaner than
<fengb> scientes: Yeah I'm a fan of that. We have quite a few `struct { fn foo() }.foo` hacks in std already
<scientes> fengb, and all over tests
<companion_cube> I think closures would be fine if they were always used comptime (and therefore specialized on)
<scientes> companion_cube, that would allow us to get the syntax down
<companion_cube> at least no need to worry about memory representation
<scientes> cause closures are a superset of annonymous functions (right?)
<fengb> the proposal is limited closures
<companion_cube> `foo.sort(|x,y| { x.a > y.a }`
<companion_cube> `foo.sort(|x,y| { x.a > y.a })` sorry
<fengb> That'd just be anonymous functions
<companion_cube> they could capture the scope though
<companion_cube> it'd be compiled as a function with additional arguments
<scientes> I like the variables in the {}
<scientes> `foo.sort({ |x, y| x.a > y.a })`
<scientes> but I think having it match function syntax is better
<fengb> Let's drop the parents too! `foo.sort { |x, y| x.a > yxa }` :P
<scientes> so like `foo.sort(fn(x: u32, y: u32) bool { return x.a > y.a; })`
<companion_cube> `var i = …; foo.sort(|x, y| { x.a + i < y.a + i });
<scientes> strongly typed too, as it should be
<scientes> so identical syntax, you just leave out the symbol name
avoidr has quit [Quit: leaving]
<fengb> I think the biggest challenge with closures is how to deal with mutations, e.g. what happens when reassigning `i` in your example
<scientes> also that example is horrible, you have to have a way to specify that i is bound to the function
<fengb> Java resolved it by only allowing `final` variables to be closable
<scientes> fengb, well that is why you pass it like a function
<fengb> scientes: closures imply automatic binding, usually via lexical scoping
<scientes> but when you define it
<companion_cube> it really is a can of worms…
<scientes> fengb, ewww, I guess I haven't really used closures, but just using lexical scoping seems gross
<fengb> (Doesn't have to be lexical... but languages that do dynamic scoping are terrible)
<scientes> it should be passed, just before execution
<scientes> then you don't have the variable-ish problem
<fengb> It's the basis for most MLs and Lisps
<scientes> but anyways, I don't use closures, but I want annonymous functions
<scientes> I will eventually use them if they exist
<scientes> maybe...
<scientes> but it sure sounds horrible
<scientes> perhaps co-routines are better
<scientes> as those also keep state
<hryx> mikdusan: if you're around, any tips on getting started with zig IR / --verbose-ir? I have your "minimal boilerplate" gist, but don't know how to read the output
<companion_cube> closures are just one shot coroutines
<scientes> yeah, then why no leap-frog them and have coroutines
<scientes> (and also annonymous functions)
<fengb> companion_cube: not if you talk to a functional programmer :P
<companion_cube> you could have a short syntax for closures that just give you a coroutine 🤷
<companion_cube> fengb: why not? :)
<fengb> Because if you can't return a closure, it's not a "real" closure
<companion_cube> well you could, just malloc and copy the closure there, right?
<companion_cube> ah that's assuming capture by value though
<mq32> oh the closure topic. i'm in!
<fengb> You can't if your context references are mutable
<scientes> well I guess I just haven't used them
<scientes> so I don't know what they are useful for
<fengb> But... you can't mutate in functional programming so it works
<scientes> and haven't seen how to optimize them either
<mq32> scientes, most simple example is targetet callbacks
<companion_cube> I feel like a fanboy, but look at what rust does? :D
<mq32> imagine having a list of callback functions that all require some logic with context to execute
<companion_cube> (it's not simple though)
<fengb> Nothing in Rust is simple :P
<mq32> you can do the c-style-thing (functionptr + void*) or use a closure, where you capture the void* context in the closure itself
<companion_cube> fengb: the syntax is pretty simple
<mq32> companion_cube, i think syntax is not a problem at all ^^
<companion_cube> I think it's a big deal
<companion_cube> syntax makes some things easy and some things cumbersome
<fengb> Syntax is the least of my worries here. Storing variables sounds like a nightmare when dealing with manual memory
<mq32> what fengb says
<mq32> syntax is something to talk about when all other stuff is safely designed
<scientes> WTF< why is buf_write_value_bytes big-endian?
* companion_cube thinks syntax has an influence on things like goto fail;
<scientes> ho wait it isn't
<scientes> its little, it just has weird padding
<companion_cube> but yeah, when talking about closures it's not the first priority, semantics is
<fengb> Some things have colliding syntax. I think whatever we agree on with closures will look pretty close to current functions and proposed anon functions
<fengb> I'm more scared of the ramifications of when variables go out of scope, how they get copied, how we can pass around closures, etc.
<mq32> i'll take a look at how Rust implements closures
<companion_cube> with traits
<companion_cube> but you have several flavors of closures, which is pretty neat
<mq32> so they actually go the same way as c++?
<companion_cube> (either by ref, or by move)
<companion_cube> I'm not sure about the details for C++, but in rust each closure is a nameless type which implements one of Fn, FnMut, FnOnce
<companion_cube> (depending on whether it captures by move (value), or by const/mutable ref)
<mq32> yeah
<Tetralux> I'm curious where the storage for captures vars goes.
<mq32> in C++ every closure is a class that implements a function call operator
<companion_cube> for moved closures, you have this nameless type which is basically a struct
<companion_cube> by-move closures*
<fengb> My brain hurts already. I'm gonna go back to coding :P
<companion_cube> so you can put that in a box (malloc) or just return it on the stack, or whatever
<companion_cube> for the by-ref closures, you have to respect scopes otherwise the borrow checker yells
<mq32> hm
<mq32> so they go full c++ with more hurdles :D
<Tetralux> I'm honestly not sure you need to have closures.
<mq32> it's useful some times
<fengb> Having the borrow checker yelling at you is a good thing. I hope we can't get to a point where we get an invalid stack reference because we used the closure wrong... eventually
<mq32> but: most closure tasks could be done with fnptr+context*
<companion_cube> less hurdles, more safety, mq32 :p
<Tetralux> mq32: Indeed. But where do you put the context?
<fengb> Hmm, I wonder if we can solve it with a coroutine. Stick the @Frame wherever you want and you get full control of the lifecycle
<Tetralux> You would statically allocate it as part of the function pointer.
<mq32> Tetralux: in most cases: on the stack
<companion_cube> in which case you have to respect the same constraints as rust's borrow checker imposes
<fengb> I really want to see the new coroutines in action. It feels like it can do so much :P
<Tetralux> Like a closure could be: struct { context: FnContext, proc: fn(FnContext, ...) }
marijnfs has joined #zig
<mq32> i just got an idea…
<mq32> where's my compiler explorer?
<scientes> uggh this padding in bigint.cpp is so weird
<scientes> its using big endian padding on little endian
<mq32> oh, found a compiler bug i think…
<scientes> welcome to the club :)
<mq32> yeah :D
<mq32> playing around and it seems like you can't capture @typeOf() through function layers
<mq32> although it should be possible
<mq32> oh
<mq32> even better
<mq32> unreachable: /deps/zig/src/codegen.cpp:gen_const_val_ptr:5956
<scientes> uggh, this padding is so fucked up
<scientes> mq32, look at the code, there are tons of FIXME all over stage1
<hryx> oh wow, github's "related issues" feature actually just prevented me from opening a dupe. nice work github
<scientes> its hard to "not" find acompiler bug
<scientes> hryx, yeah that is a great feature
<mq32> scientes, yeah i'm not surprised :D
<fengb> I'm surprised you haven't found one yet :P
<mq32> fun thing is i found it while working around another one :D
<mq32> but i have to admit, i'm more the theoretical zig programmer right now
<mq32> but, my example/thought is done:
<mq32> this is how closured *could* be done with near-usespace-experience
<scientes> its cool to see people in here using my SIMD work
<mq32> the function types would have to be somehow comptime generated
<companion_cube> like coroutines, right?
<mq32> i think my example could actually work without compiler support if @reify would be implemented and we could "enforce" an argument list like c++ variadic templates
<mq32> but my main idea is to have a "closure type" which is a struct that 1) provides a pointer to a function and a context, 2) stores all captured variables (by-ptr or by-val) and 3) implicitly casts to it's corresponding closure type
<mq32> 3 could work by the "go style inheritance" proposal
<mq32> companion_cube, yes, i think so. maybe a whole lot of the coroutine stuff could be reused for closures
<mq32> hm
<mq32> yeah, a closure would be a endless-loop-coroutine then
<mq32> except for that a "resume" passes in new arguments to the coroutine
<companion_cube> ah, if you can call it several times, interesting
<mq32> closures are meant to be called several times, usually
<mq32> scientes, i got another nice example for you :)
<mq32> var i : i32 = 0; list.forEach(fn(x : i32) { i += x; });
<mq32> generic forEach that can accumulate or calculate arbitrary stuff
<Tetralux> Is that cleaner or clearer than just a for loop though?
<companion_cube> it can be
<Tetralux> I can't say I've seen a good example of that.
<Tetralux> Though as someone who's played around with linq in their time
<companion_cube> if it's something a lot more complicated to iterate on, than a list
<companion_cube> (eg a tree)
<Tetralux> If you foreach a tree, surely the for isn't THAT much worse.
<mq32> Tetralux, yeah for an array a simple loop would surely be better
<companion_cube> heh, what about code reuse?
<companion_cube> what if it's a HAMT/radix tree? the iteration logic becomes non trivila
<companion_cube> trivial
<mq32> but if the enumeration type is more complex (imagine a sparse array structure), it's better to reuse the iteration code than rewrite it every time
<companion_cube> ofc you could also have iterators.
<mq32> we would'nt neet one if we have closures :D
<mq32> var iterator = list.makeForwardIterator(); while(iterator()) | loopvar | { … }
<hryx> currently seen as `... while( ...`
<mq32> yeah, that' true :D
<hryx> don't get me wrong mq32, I think closures are cool :>
<fengb> I mean, technically you wouldn't need anything else if you had closures :P
reductum has quit [Quit: WeeChat 2.5]
<mq32> hryx, wanted to say: for me closures aren't much more than neat syntax sugar that allows some code to be better to read because of less clutter
<companion_cube> but is it still C like then?
<mq32> closures *can* be done in C and are often done
<mq32> but with manual work
<mq32> which is cumbersome and and error-prone
<hryx> mq32, agreed but there's actually one odd thing that closures would actually bring (albeit horribly roundabout way). In the `` approach, you can't make anything inside `iterator` private. see #2059
<mq32> my browser tells me i should stop reading so much issues on the zig language repo :D
<mq32> if i type "zi" my browser autocompletes to the issues tab
<hryx> your browser is encouraging you to read more of them!
<mq32> :)
<mq32> on the private/public stuff:
<mq32> i've stopped using "private" in my code unless you can *actually* break memory safety
<mq32> in most of my structs all fields are public
<mq32> and i noticed that most of the code gets better in quality
<mq32> less code → less errors, better readability, less code to maintain, …
<hryx> interesting observation, very cool
<mq32> but there are reasons to hide state
<mq32> like safe memory handling (in C++ with alloc-on-ctor, free-on-dtor) and similar
ntgg has joined #zig
<mq32> this stuff is mostly private
<hryx> I see. luckily not an issue in zigland
<hryx> my main concern is, does lack of `pub` mean a leakier or weaker API for the user?
<hryx> I honestly don't know but my guess would be seeing all the "private" fields adds noise for the consumer
<mq32> yeah, that's some stuff that annoys me in c++ from day 1
<Tetralux> Yeah - I like POD.
<Tetralux> So private isn't really in my vocab.
<Tetralux> Though private to file scope is.
<Tetralux> That seems useful.
<fengb> I believe that we need a "this is API stuff" and "thar be dragons". Accessibility isn't what I care about
<hryx> mq32 I'll keep in mind what you said about not having private leading to better quality code
<fengb> Although I do prefer nothing to be inaccessible cause then I can't work around poor assumptions/designs/bugs
<mq32> hryx: i have to code with c++builder @ work and it's sometimes horrible how bad your code *has* to be in order to actually compile
ntgg has quit [Ping timeout: 246 seconds]
<scientes> uggh, the padding of bigint.cpp is big-endian on little-endian architectures
<scientes> and my code is going forward and backwards
<scientes> and had to pack bits
<scientes> this could be so much simpler with bit-granularity types
<scientes> and pointers
<scientes> and i cant used unsigned, because i have to support types large than 64-bits
<scientes> its madness
<scientes> i had something working, but then i ran into backwards padding
<scientes> and now its all to hell trying to support that
<scientes> maybe i should just us an array of bools
<scientes> that would make the logic much simpler
_whitelogger has joined #zig
laaron has joined #zig
dimenus has quit [Remote host closed the connection]
laaron has quit [Client Quit]
laaron has joined #zig