ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
pdmer has joined #zig
pdmer has quit [Client Quit]
pdmer has joined #zig
pdmer has quit [Client Quit]
kristate has quit [Ping timeout: 250 seconds]
_whitelogger has joined #zig
unique_id has quit [Ping timeout: 245 seconds]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Ping timeout: 272 seconds]
kristate has joined #zig
pdmer has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
pdmer has quit [Quit: pdmer]
qazo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
qazo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
darithorn has quit [Quit: WeeChat 2.2]
qazo has joined #zig
porky11 has joined #zig
<kristate> I have been doing a little bit of swift programing on iOS lately and its nuts
wilsonk has quit [Read error: Connection reset by peer]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
wilsonk has joined #zig
pdmer has joined #zig
porky11 has quit [Read error: Connection reset by peer]
porky11 has joined #zig
kristate has quit [Remote host closed the connection]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
pdmer has quit [Quit: pdmer]
kristate has joined #zig
Thalheim has quit [Remote host closed the connection]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
<kristate> hmm, got this lovely error
<kristate> Unable to check cache: invalid format
qazo has quit [Read error: Connection reset by peer]
hoppetosse has joined #zig
qazo has joined #zig
unique_id has joined #zig
kristate has quit [Ping timeout: 244 seconds]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
noonien has joined #zig
kristate has joined #zig
fdsimk has joined #zig
<andrewrk> kristate, I'm trying to reproduce
<kristate> andrewrk: I almost have a patch out
<andrewrk> is it a workaround or did you figure out why the cache is becoming corrupt?
<kristate> andrewrk: cache is not becoming corrupted
<kristate> it's a parse err
<andrewrk> great, looking forward to the patch
<kristate> good morning, btw
<andrewrk> morning :)
<andrewrk> I think caching compiler_rt.o and builtin.o is still a good idea, but it turned out to be less of a performance gain than I hoped
<andrewrk> I also augmented --enable-timing-info with LLVM details. And it's renamed to -ftime-report to match clang
<kristate> yeah, saw that and its cool
<andrewrk> I think `zig build` caching alone is worth it
<andrewrk> kristate, did you see that llvm's coroutine split pass is a significant time sink? :(
<andrewrk> this is required even in debug builds for coroutines to work
<andrewrk> plus it's buggy and we can't turn optimizations on
<andrewrk> I'm thinking about redoing coroutines on top of structs instead of with LLVM's coroutines
<kristate> andrewrk: you mean in userland?
<andrewrk> this would make it easier to solve #1194 too
<kristate> andrewrk: yeah, stage2 would be easier to implement
<andrewrk> I still mean in the compiler, but without
<kristate> problem is that if its userland, we would have to support lots of archs, no?
<andrewrk> I mean that instead of using the above linked features of llvm, it would only use more basic llvm IR such as structs and normal functions
<andrewrk> e.g. zig would do the coroutine splitting / switch statement insertion / however we choose to lower it
<andrewrk> thanks!
<andrewrk> argh, I meant to do this and forgot, sorry about that
<andrewrk> in the zig code for split iterator we have the rest() function
<kristate> andrewrk: yeah, it's hacky, but I didn't see rest
<kristate> andrewrk: if you want to talk about coroutines, maybe we could jump on a webRTC call for 15 minutes or so
<andrewrk> sure I'd be up for that
<andrewrk> then I need to use my extra sharp morning brain to work on a hard bug
qazo has quit [Ping timeout: 252 seconds]
<kristate> I'm excited again
<andrewrk> :)
pdmer has joined #zig
qazo has joined #zig
<andrewrk> finaly CI passing on all platforms again
<andrewrk> had to disable release builds on windows
qazo has quit [Ping timeout: 240 seconds]
noonien has quit [Quit: Connection closed for inactivity]
very-mediocre has joined #zig
<very-mediocre> Maybe a crazy idea: why don't programming languages have a lean way to do interfaces + default implementations?
porky11 has quit [Ping timeout: 250 seconds]
<very-mediocre> interfaces -> sometimes you have to duplicate functions, or provide an external function (messy) to multiple implementers of the interface - no default implementation can be provided
<very-mediocre> abstract classes -> you can provide a default implementation for a given function, but you can't provide a signature for other functions and force implementers to provide their own implementation there
<very-mediocre> I find myself wishing I could write an interface that has some members with default implementations, and some not
<pdmer> very-mediocre: Does C++ not provide this?
<very-mediocre> afaik you'd have to have an abstract class which implements an interface
<very-mediocre> it doesn't scale well at all
<very-mediocre> I am writing something in TypeScript now and I found it was getting too Java-ish
<very-mediocre> actually what I described for C++ doesn't work, the abstract class is forced to satisfy the interface requirements...
<very-mediocre> so then each child of the abstract class would have to implement the interface. Talk about spaghetti!
<very-mediocre> The gears are spinning for attempting something like this with comptime in zig
<very-mediocre> (no idea whether reify is close to being a thing now, i've been away from zig for a while)
porky11 has joined #zig
<andrewrk> very-mediocre, there's a good chance we won't have reify because it's too powerful in the wrong way
<very-mediocre> oh, I see
<very-mediocre> are you open for proposals then?
<very-mediocre> I feel like a mix of interface+abstract class is a good idea, I may just make a case for it on github if you're accepting such things
<very-mediocre> huh, i skimmed the docs, this might be doable with TypeInfo. Gonna experiment with this soon. :]
<andrewrk> yes open for proposals. there are quite a lot of them out there
<andrewrk> for this particular topic
<very-mediocre> I've read a few. I'm sure this is a controversial topic and you probably have it rough trying to design this without being too influenced
<andrewrk> the null hypothesis is to have no such feature
<very-mediocre> honestly, if it can be done in comptime with a builtin of some kind, that feels pretty ideal
<andrewrk> I've promised that I will create a GUI in zig before making a decision about this topic
<very-mediocre> Makes sense.
<very-mediocre> @reify is actually way more than is needed for userland takes on this kind of thing
<andrewrk> I think you can go a long way with @fieldParentPtr
<andrewrk> some people really dislike this practice
<andrewrk> 6 more bug fixes to hit quota for today...
<very-mediocre> my very rudimentary view is it's fine if it's abstracted somehow into a lib
<very-mediocre> wish i had more time to play with zig, you're doing great work here
<very-mediocre> i keep coming back because i'm pretty sure this language will be a big deal
<very-mediocre> very rudimentary idea for userland oop: ironically, it'd be a functional approach
<very-mediocre> something like, a function that accepts an "interface" and checks whether another struct conforms to it
<very-mediocre> I really need to make time to play with this, too bogged down with work
<very-mediocre> I tried something with unions a couple of months ago, basically creating a union of all the "implementing" classes, at comptime, but it was unwieldly and didn't work well.
<very-mediocre> and there's "unboxing" at the receiving end if such a union is passed as a function param
<andrewrk> very-mediocre, I believe that MajorLag has a proof of concept of this idea
<very-mediocre> i'd like to see that, maybe he can show me when he's back :]
<very-mediocre> this is almost academic for me at this point, i find it super interesting
<very-mediocre> I've just never felt comfortable with OOP or functional paradigms, I always end up doing something in between that feels like fighting whatever language I'm using
<very-mediocre> what this has to do with zig is... in all other areas, zig has the best ratio of leanness to power and safety that I've seen
<andrewrk> that's an interesting way to put it
Thalheim has joined #zig
<very-mediocre> i'm just jaded and very tired of ObserverFactoryVisitorFactoryProxy class design :)
<very-mediocre> and C is just not modern, I've had toolchain issues
<very-mediocre> so there aren't many options.
<very-mediocre> Golang had the right idea in being minimalistic
<very-mediocre> but it has issues zig does not have even in its current state of development.
<very-mediocre> tl;dr: i really think zig has great merits.
<andrewrk> I'm really surprised at this paragraph about assertions:
<andrewrk> I might write a blog post about this
<andrewrk> every language has assertions
<andrewrk> for example when you write through a pointer you're asserting that it's not null
<andrewrk> that's not an "error" that's an unanticipated, unrecoverable situation
<very-mediocre> Yeah, that's pretty shocking now
<andrewrk> and to prevent the user from annotating their source code, telling the compiler about additional unanticipated, unrecoverable situations is to fundamentally fail to grasp what programming is
<very-mediocre> I have to say though, hindsight is 20/20
<andrewrk> true :)
<very-mediocre> I think it's easy to forget, back when golang launched, language design wasn't so accessible
<very-mediocre> at most there were some toy languages on github
<very-mediocre> education on this subject is exponentially higher now
<very-mediocre> My code from 2012 is shockingly bad D:
<very-mediocre> old code / projects are always horrible, the same applies for language decisions imho
<andrewrk> even as young as zig is, it's a lot different than it used to be
<very-mediocre> I actually saw your early posts about it, back when it was all sigils
<very-mediocre> with % and whatnot
<very-mediocre> been following from a distance for a while now, i'm pretty sure many HN readers are too
<unique_id> I have to go 10mins but.. What do you guys think about C++ Contracts? I think it's a fascinating move from abusing exceptions towards the extreme other end..heavily fortified code in a systematic fashion. I love it.
<andrewrk> I haven't learned about them yet
<very-mediocre> i only skimmed them a while ago, i'm unsure how they differ from regular checks
<andrewrk> yeah I'll have to read more to find out how this is different than (in zig) calling assert or defer assert
<very-mediocre> personal preference: I don't like language constructs, with special syntax
<very-mediocre> looks like a declarative way of writing checks
pdmer has quit [Quit: pdmer]
pdmer has joined #zig
<very-mediocre> ^ this, on the other hand, I like
<andrewrk> cgag, I made zig test put the test artifact in zig-cache, like it worked before
<andrewrk> sorry about that
jjido has joined #zig
very-mediocre has quit [Ping timeout: 252 seconds]
<unique_id> very-mediocre: I don't know about concepts, those seem very complex. I'm scared of them. Contracts are a similar idea to how --release-fast, --release-save alters how much checking is done. Unlike asserts, contracts also allow you to state post conditions right at the top. Having special syntax maybe isn't ideal, I agree with that
very-mediocre has joined #zig
<very-mediocre> I guess it's a matter of personal comfort
<MajorLag> andrewrk, very-mediocre, I have experimented with a "trait" and a "typeclass" library. "traits" are simple checks like "does this type have a field named x?" or "is this type a const pointer?". These can be used today but would be better with the small addition detailed in #1268. "typeclass" is more like you've described in that you can set up a relatively complex descritpion of a type, then apply that description as a simple boolean check
<MajorLag> or "inspect" the type, which provides more descriptive compile errors. I have gist previews of both:
<very-mediocre> cool, this will take some time to grok
<MajorLag> My own conclusion is that "typeclass" is more effort than it is worth, but "trait" is useful for changing behavior based on the passed in type(s). The `var<trait()>` construct I think would be usefull mostly as a form of documentation.
<very-mediocre> using <> is genius
<MajorLag> that's andrewrk's doing.
<unique_id> very-mediocre: Also contracts have 'audit' asserts which are asserts that are almost never checked. You'd use them as compiler checked comments that can be turned into runtime checks when hunting for bugs. Also, these asserts can automatically be converted into good documentation for libraries.
<very-mediocre> unique_id: I like the functionality, but that syntax doesn't sit well with me
<very-mediocre> I feel constraints are more my style, since they are comptime checks too
<very-mediocre> except imperative, not declarative
<very-mediocre> but really I've gone full Danny Glover "I'm too old for this" wrt. C++ now :)
<very-mediocre> so maybe I'm not a great reference for this.
<unique_id> oh I've abandoned C++, I'm done with it, I've had enough
<unique_id> but I think the ideas from C++ could be used without the special syntax. A defer + function call at the top of a function could act as a post condition contract
<very-mediocre> see, I'm super picky, that kind of change flips me over to the "like" side again
<very-mediocre> I don't know if it's just me... Seeing [[ ]] in the middle of an imperative block just scares me away
<unique_id> yeah. There's no rush, we can see how well contracts work for C++ and then in a few years we'll know if they're a good idea or not
<very-mediocre> I think the thing that scares me about C++ is I've done full projects in it, without really knowing how close I was to danger
<very-mediocre> and now I can't unsee it anymore
<very-mediocre> There are too many things to be aware of. Not knowing them at the time allowed me to make things work, but now if I have to write C++, I'll be googling answers to 10+ different questions for every line.
<very-mediocre> if you've played the game Bloodborne, you will understand this metaphor: I have too much insight now to be able to code in C++ comfortably
<very-mediocre> Amygdalas everywhere. :]
<unique_id> haha unfortunately I have not played Bloodborne
<very-mediocre> Alternatively, consider how many insects you probably have in your house that you would prefer not to think about.
<unique_id> oh please
<unique_id> yeah lets not go there :)
<very-mediocre> :)
jjido has quit [Read error: Connection reset by peer]
pdmer has quit [Quit: pdmer]
pdmer has joined #zig
<very-mediocre> I got what I deserved for making that metaphor
<very-mediocre> There's a gecko on my curtains... :|
<very-mediocre> freaked me the hell out lol
<unique_id> haha
pdmer has quit [Quit: pdmer]
pdmer has joined #zig
very-mediocre has quit [Quit: Page closed]
<unique_id> andrewrk: sqlite has functions (sqlite3_bind_text) that take a pointer to data and a pointer to a destructor to clean up the data. However, you can also pass in -1 instead of a destructor and sqlite will make a copy of that data. When I do I crash the compiler.
<unique_id> when I do this* I crash the compiler
<unique_id> To be clear, I first cast -1 (actually I cast @maxValue(usize))
<unique_id> Since I didn't find a way to cast -1 to an unsigned int
<unique_id> or function ptr
<unique_id> const SQLITE_TRANSIENT = @intToPtr(extern fn(*c_void) void, @maxValue(usize));
<unique_id> andrewrk: Do you know about this or should I submit a bug report? Does one exist?
<andrewrk> unique_id, let me look at this after the stream, I'm about to start in 5 min
<unique_id> oh cool
<andrewrk> that's a bug, should be easy to fix
<unique_id> I'll give you a small file to run after your stream
<unique_id> andrew is live:
pdmer has quit [Quit: pdmer]
pdmer has joined #zig
porky11 has quit [Ping timeout: 252 seconds]
qazo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
<andrewrk> unique_id, thanks
<andrewrk> unique_id, fixed
<unique_id> awesome, thank you!