ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
rain1 has quit [Ping timeout: 255 seconds]
JinShil has joined #zig
relatingdata has joined #zig
lorde_kumamon[m] has quit [Ping timeout: 240 seconds]
raytracer[m] has quit [Ping timeout: 255 seconds]
dtz has quit [Ping timeout: 255 seconds]
kammd[m] has quit [Ping timeout: 255 seconds]
clebermatheus[m] has quit [Ping timeout: 276 seconds]
relatingdata has quit [Ping timeout: 260 seconds]
relatingdata has joined #zig
relatingdata has quit [Quit: Page closed]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kammd[m] has joined #zig
lorde_kumamon[m] has joined #zig
dtz has joined #zig
raytracer[m] has joined #zig
clebermatheus[m] has joined #zig
JinShil has quit [Read error: Connection reset by peer]
Dodo has joined #zig
<Dodo> do slices have a reverse method / is there a function that reverses slices?
davr0s has joined #zig
noonien has joined #zig
kammd[m] has quit [Ping timeout: 256 seconds]
lorde_kumamon[m] has quit [Ping timeout: 256 seconds]
dtz has quit [Ping timeout: 240 seconds]
commander has quit [Read error: Connection reset by peer]
raytracer[m] has quit [Ping timeout: 256 seconds]
clebermatheus[m] has quit [Ping timeout: 256 seconds]
commander has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tiehuis has joined #zig
<tiehuis> Dodo: std.mem.reverse
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask> Time for some code
<alexnask> Finally :P
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
<alexnask> Does @import work with a comptime string?
davr0s has joined #zig
davr0s has quit [Client Quit]
<alexnask> Does anyone know if static initialization of local variables is guaranteed to happen on the first call in C++?
<alexnask> Or rather initialization of static local variables
<tiehuis> alexnask: should be fine to use a comptime string
<alexnask> @tiehuis Right, I was looking at the discussion on the package manager and I'm wondering why it isn't just possible to write it as a package in std
<alexnask> You basically need network access at comptime and that's it
<tiehuis> yeah, although not sure if we'd want to do that
<alexnask> Or in the builtins
<alexnask> That would be better imho
<tiehuis> also i think static variables are all initializaed before main regardless of scope
<alexnask> Not that I'm opposed to the compiler doing the fetching itselfd
<alexnask> @tiehuis I'm pretty sure most compilers evaluate the initialization expression on the first call but I'm not sure if I can rely on that behavior
<tiehuis> don't quote me on that
<tiehuis> here is a relevant snippet of the standard: https://stackoverflow.com/a/58804
<alexnask> It seems that scoped statics are initialized when the scope is evaluated for the first time
<alexnask> Thanks for the link, I'll take a look
kammd[m] has joined #zig
<alexnask> Right, so I can't rely on this, a valid implementation could initialize the variable before the function is run
<alexnask> Damn
Dodo has quit [Quit: Page closed]
tiehuis has quit [Quit: WeeChat 2.1]
dtz has joined #zig
lorde_kumamon[m] has joined #zig
raytracer[m] has joined #zig
clebermatheus[m] has joined #zig
commande1 has joined #zig
commander has quit [Ping timeout: 240 seconds]
commande1 has quit [Client Quit]
commander has joined #zig
<alexnask> could not convert template argument ‘type_ptr_hash’ from ‘uint32_t(const TypeTableEntry*) {aka unsigned int(const TypeTableEntry*)}’ to ‘uint32_t (*)(TypeTableEntry*) {aka unsigned int (*)(TypeTableEntry*)}’
<alexnask> you wot mate
<achambe> I think function can't be implicitly casted to a function pointed because of the const ?
<achambe> pointer
walac has quit [Ping timeout: 256 seconds]
walac has joined #zig
<alexnask> Right, I got that much but it makes no sense to me, I would have thought it is implicitly castable from a const pointer param to a non-const pointer param
<alexnask> But then again, C++, so who knows :P
<MajorLag> Interesting note: it is possible for HeapAlloc to fail and crash your program without ever returning.
<MajorLag> Which means: it is possible for malloc to fail and crash your program regardless of checking for null.
<MajorLag> good work MS
<MajorLag> I can probably catch it with SEH, but seriously...
davr0s has joined #zig
<alexnask> @andrewrk Am I allowed to use a local no capture lambda in compiler code?
<alexnask> I saw some 'auto' in places so I guess we are targetting C++11 + ?
steveno_ has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
cenomla has joined #zig
cenomla has quit [Quit: cenomla]
<andrewrk> MajorLag, how can this happen?
<MajorLag> andrewrk: I don't think it can anymore. I think I was fooled by release-fast behavior in regards to buffer flushing with warn(). It made it appear HeapAlloc was causing the crash but I'm pretty sure it was actually a use-after-free happening somewhere else. It was just oddly consistent and I hadn't been awake long enough I think.
<alexnask> 8/15 TypeInfo cases are done
<alexnask> Nice
<andrewrk> alexnask, I don't really have a good reason to say no to no-capture lambdas other than personal preference
<andrewrk> we're targeting gcc >= 5.0.0 and clang >= 3.6.0
<alexnask> @andrewerk Ok, thanks!
<andrewrk> although an argument could be made that we shouldn't use features that don't exist in zig, to make porting code more straightforward
<alexnask> Sure, I just want to use a lambda in this case to avoid code repetition, and I don't think making a new function makes much sense.
<alexnask> I could split it off in a regular function regardless
<andrewrk> eh go for it, I'm sure it's fine
<alexnask> @andrewrk I added a type info cache in CodeGen, I assume it's ok? :P
<andrewrk> as long as it's perfect
<andrewrk> and by that I don't mean that it has no bugs, I mean that the cache by design has no false positives
<alexnask> Some kind of caching is actually required the way I am building the values, since we could ask for a typeinfo of a parent type while we are still generating it
<andrewrk> I think a typeinfo cache should be ok since types in zig are immutable
<alexnask> If you see what I mean :p
<alexnask> Like, const Foo = struct { const Self = this; fn init() Self { ... } };
<alexnask> I think the way I did it is ok, I'll see what pops out in testing (no worries, there will be LOTS of tests)
<andrewrk> I see now- for example StructField has a &TypeInfo
<andrewrk> maybe it should only have []type
<andrewrk> and you'd have to call @typeInfo again to explore fields
<andrewrk> I think that's probably better
<alexnask> Hmm
<andrewrk> but it might need Pointer Reform in order to work
<andrewrk> oops, not []type. it would just be type
<alexnask> I'm more partial to fully expanding the TypeInfo and @reify-ing what we need as types but I can see the arguments against that
<andrewrk> reify would stil work with a shallow typeinfo
<alexnask> I know
<alexnask> I'm just talking design, not functionality ;)
<alexnask> But I can switch it up if you think storing the types is better
<alexnask> No biggie
<andrewrk> sorry I didn't suggest this earlier, I know it would cause you to back out of a bunch of work you already did
<alexnask> Btw, do methods live in a type entry's decls_scope?
<andrewrk> yes
<alexnask> Nice and conveniant :P
<alexnask> I'm guessing 'type' is not a valid identifier?
<andrewrk> if you want you can use @"type"
<andrewrk> but for convenience it may be better to come up with a non-conflicting name
<alexnask> Yup
<andrewrk> @"foo" is mostly for API compatibility with external functions or .h files that have conflicting names as zig keywords
<alexnask> ?type causes a compiler assert to fail btw
<andrewrk> that's the Pointer Reform thing
<alexnask> How should I deal with optional types for now?
<alexnask> E.g. a union's tag type or a promise's child type
<alexnask> assigning void will have to do I guess, although I'm not sure if promise->void == promise
<andrewrk> I think I've realized that unfortunately @typeInfo depends on having distinct operators for address-of and "pointer-to" operator (on types)
<andrewrk> I have some time this evening; I can start on this and get enough done that it can unblock you from finishing @typeInfo
<alexnask> I don't actually think I need them
<alexnask> To just generate the typeinfop
<alexnask> I'll give it a go
<andrewrk> promise->void is distinct from promise in an important way
<andrewrk> you can await a promise->void but you cannot await a promise
<andrewrk> `the_type->data.promise->result_type == nullptr` means it's promise and not promise->void
<alexnask> I gathered that from the comments
<alexnask> I'll use some tag type
<alexnask> TypeInfo.Promise.NoType
<alexnask> Or perhaps noreturn
<andrewrk> why not ?type
<alexnask> Well, for now it causes the compiler to assert false sooo :P
<andrewrk> yeah, so this is why this depends on #588
<andrewrk> I'll work on unblocking you
<alexnask> Sure, I'll just go ahead and implement it with 'type' for now and when I have #588 I'll switch it up
<andrewrk> sounds good
mal`` has quit [Quit: Leaving]
mal`` has joined #zig
<alexnask> Ok, switched to shallow typeinfo generation, back to implementing the rest of the types!
<alexnask> I think it makes a lot more sense retrospectively
<alexnask> Should have thought more about it :p
<andrewrk> I always have to start coding something the wrong way before a the right way reveals itself to me
<alexnask> I used @typeOf(undefined) as a 'null' type for now
<andrewrk> I'm pretty sure you're still going to hit #588
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask> Idk, I don't see how I would, at least in the compiler side code
<alexnask> I only need ?type with the current layout
<andrewrk> oh, we actually have the PtrTypeOf instruction to distinguish from address-of
qazo has joined #zig
steveno_ has quit [Ping timeout: 276 seconds]
steveno_ has joined #zig
qazo has quit [Quit: leaving]
davr0s has joined #zig
Ichorio has joined #zig
<alexnask> It appears that unions never have a nullptr tag_type
<alexnask> Or rather I tested with a union { ... } and an extern union { ... } and TypeTableEntryUnion::tag_type != nullptr
<alexnask> Btw, is TypeUnionField::enum_field supposed to be nullptr when tag_type is nullptr?
<alexnask> (tag_type is a type with name @TagType(WhateverUnion) while @TagType(WhateverUnion) errors)
Fred_ has joined #zig
Fred_ is now known as Guest50075
<Guest50075> How do you access command line arguments in zig ?
isd has joined #zig
jjido has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest50075 has quit [Quit: Page closed]
davr0s has joined #zig
<MajorLag> Guest50075: std.os.args() returns an iterator for commandline arguments.
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
steveno_ has quit [Quit: Leaving]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
noonien has quit [Quit: Connection closed for inactivity]
jjido has joined #zig
<andrewrk> alexnask, yes I believe so
davr0s has joined #zig
isd has quit [Quit: Leaving.]
Hejsil has joined #zig
<Hejsil> andrewrk, are there any workaround for this: https://github.com/zig-lang/zig/issues/958 ?
<Hejsil> Forget it. Figured it out!
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk> Hejsil, I'm going to work on pointer reform this evening because it's blocking alexnask
<Hejsil> Exciting
<Hejsil> But then again. I'll have to go through all my pointers
<Hejsil> Ooh well
<andrewrk> Hejsil, I was thinking - if I finish zig fmt (make it preserve comments) we could make it be a tool to do source level translations from before pointer reform to after
<Hejsil> Btw. @field makes the functional "with" pattern really nice. imut.with("field", value).with("field2", value2)
<Hejsil> Uuuh, that's neat
<andrewrk> wait, what does @field bring to the table in your example?
<andrewrk> oh, it is setting the value?
<Hejsil> Returning a copy of imut with "field" set to value
<andrewrk> ah
<andrewrk> I think it would be more idiomatic to do IMut { .field = value, .field2 = value2, }
<Hejsil> True, but for https://github.com/Hejsil/zig-clap/issues/8#issuecomment-384782785 , this has some benifits
<Hejsil> But maybe I should just drop that and require lib users to fill out the entire struct
<Hejsil> Idk
<andrewrk> I guess I can see the "argument" for this feature ;)
<Hejsil> :)
<Hejsil> It's better that Builders
<andrewrk> the []Argument if you will
<Hejsil> Ooh god
<andrewrk> mwa ha ha
<Hejsil> What is the best word for this even (context: clap)? Argument, Flag, Option?
<Hejsil> Idk
<andrewrk> well if the 'a' in "clap" stands for Argument then I suppose it is an argument
<Hejsil> Maybe, it's actuall a parameter
<Hejsil> And you send in arguments
<Hejsil> Idk
<andrewrk> I see
<Hejsil> I'll open an issue on clap for this, so I don't forget!
Ichorio has quit [Ping timeout: 268 seconds]
isd has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
jjido has joined #zig
davr0s has joined #zig
davr0s has quit [Client Quit]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<achambe> Thanks for making tab an error
<achambe> lol - I often swap between two lots of code that use either
<achambe> and usually mess it up
<achambe> not a problem here :P
<achambe> andrewrk: in the compiler, is there any compilation time cost for unused imports?
<Hejsil> achambe, As far as I know, Zig will lazily load imports. If they are unused, Zig wont even try to open the fields imported
<Hejsil> files*
<achambe> Ah cool.
<Hejsil> Uuuurg. Inline loops and comptime stuff really needs better error messages: "error: control flow attempts to use compile-time variable at runtime", is not that helpful if the compiler is not gonna tell me the dependencies leading to this error :(
Hejsil has quit [Ping timeout: 260 seconds]
isd has quit [Ping timeout: 240 seconds]
alexnask_ has joined #zig
isd has joined #zig
alexnask has quit [Ping timeout: 260 seconds]
JinShil has joined #zig
alexnask_ is now known as alexnask