ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<kristate>
having a struct/type for tai64 is handy and keeps mistakes out of the implementation
<hoppetosse>
kristate I know there's the enumToInt function - I was just wondering if there was a reason to not implicitly cast it in the case of packed enums
scientes has joined #zig
<scientes>
kristate, I just got your brother's email
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<kristate>
scientes:
<kristate>
scientes: yes, please meet with my brother
<andrewrk>
kristate, this is a good example - I'm becoming convinced
<kristate>
⭐︎
ryanmtate has joined #zig
<ryanmtate>
@kristate howdy
<kristate>
scientes: ryanmtate: cool, we're all synced up
<kristate>
andrewrk: you don't seem to be connected via a secure connection
<scientes>
ryanmtate, oh hi
<scientes>
I'm vulnerable because my znc certificate is self-signed, i should probably fix that....
<scientes>
i have a signed certificate on the same server too
<ryanmtate>
@scientes; hey, responding to your email!
<ryanmtate>
yes, I need to use TLS as well...
JinShil has joined #zig
Thalheim has joined #zig
kristate has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has joined #zig
Thorn has quit [Ping timeout: 240 seconds]
walac_ has joined #zig
odc has quit [*.net *.split]
walac has quit [*.net *.split]
jeromegn has quit [*.net *.split]
walac_ is now known as walac
kristate has quit [Remote host closed the connection]
mnoronha has quit [Ping timeout: 260 seconds]
mnoronha has joined #zig
scientes has left #zig ["Leaving"]
scientes has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 240 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
ryanmtate has quit [Remote host closed the connection]
mnoronha has quit [Read error: Connection reset by peer]
mnoronha has joined #zig
mnoronha has quit [Read error: Connection reset by peer]
mnoronha has joined #zig
kristate has quit [Ping timeout: 272 seconds]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
Thorn has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
mnoronha has quit [Ping timeout: 260 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 265 seconds]
qazo has joined #zig
JinShil has quit [Quit: Leaving]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
_whitelogger has joined #zig
hoppetosse has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 276 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
wow that is a really good worst case time
<Hejsil>
loopless gets faster with input size?
<Hejsil>
But who really parses strings to u127 :)
<Hejsil>
Maybe this could be used for a bigint lib
<andrewrk>
what is the code size cost? e.g. difference in binary size with parseUnsigned vs atoi
<Hejsil>
I'll compile them into sep objs
<andrewrk>
I'm perhaps a little too eager to have different implementations behind `if (builtin.mode == ReleaseSmall)` blocks
<andrewrk>
but the idea is nice
<andrewrk>
in other news, I have learned a lot about mach-o files, and I can at the very least make the following improvements to macos stack traces:
<andrewrk>
* instead of std.os.openSelfExe() I figured out that we can just access our own exe which is already mmapped by the OS, so that's pretty foolproof and fast
<andrewrk>
that improvement can be made on linux too
<andrewrk>
* add source file and line number of the function that an address is in
<andrewrk>
i'm still trying to figure out how to get the exact address-to-line info. lldb is able to do it based on the .o file somehow but I don't see where the info is and it's driving me mad
<andrewrk>
the bad code forgets to increment the pointer so it doesn't find all the sections
<DutchGh0st>
oh btw, Hejsil , I have to thank you for pointing out that if the slice passed into atoi() is larger than the maximum number of digits of the integer type you want to convert into, the whole thing crashes
<DutchGh0st>
I basically made a little library in Rust that uses the same technique, but in the documentation I never mentioned that case, which I now do! :)
<redj>
thanks andrewrk, looking forward to diving into zig when I get more time... btw I'm glad you changed 0.3.0's goals...
<andrewrk>
DutchGh0st, sounds like a good case study of rust's macros vs zig's comptime
<DutchGh0st>
I quite like the comptime honestly
<DutchGh0st>
and the inline while
mnoronha has joined #zig
<DutchGh0st>
because if you make a mistake in a macro, its super hard to debug, and you get verry unhelpfull error messages
<andrewrk>
there's room for improvement in zig there too
<andrewrk>
at least we have @compileLog
davr0s has joined #zig
<DutchGh0st>
but one thing Im a little scared of, is that Im going to mess up a few times with releasing resources, and 'who' should clean up
<andrewrk>
that's fair
<andrewrk>
in comptime code though all your resources are probably static
<andrewrk>
e.g. global constants
Hejsil has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<DutchGh0st>
yes, but runtime code
<DutchGh0st>
like vectors, and heap memory
<DutchGh0st>
Oh, that is one thing I wanted to ask about, and tell me if it's the docs somewhere,
<DutchGh0st>
but what happens if a vector goess out of scope? Does it auto-destruct? or do you need to 'defer free(vec)' right after creation?
davr0s has joined #zig
<andrewrk>
DutchGh0st, zig does not have destructors
<andrewrk>
there's no hidden control flow
<andrewrk>
so if you don't see the code doing something, it's not doing something
<DutchGh0st>
soo it's not always good to ' defer list.deinit();' right after creating one (using std's arraylist as an example)
<DutchGh0st>
because you might pass the whole list to another function
davr0s has quit [Client Quit]
<andrewrk>
you can also use errdefer
<DutchGh0st>
but that runs on errors,
<andrewrk>
right
ryanmtate has joined #zig
<DutchGh0st>
but whenever the list is 'moved', or passed into another function that *should* cleanup, but you also cleanup...
<andrewrk>
if it's not clear who owns the memory, consider reference counting
<andrewrk>
then you can defer deref()
<andrewrk>
but usually you know who owns the memory so it's ether defer or errdefer
<andrewrk>
it's the same problem with open file descriptors, opengl texture handles, pipes, sockets, etc
<andrewrk>
memory is just yet another resource
<DutchGh0st>
I wonder how hard it would be to write a tracker that scans over the source and tells if you maybe messed up
<andrewrk>
nothing can be perfect, but there are a lot of tools that can help in this regard
<andrewrk>
for example if you use std.heap.c_allocator then you can check for memory leaks with valgrind --leak-check=full
<andrewrk>
zig could also provide a debug allocator to do something similar
<DutchGh0st>
ohh yeah, valgrind, thats also a thing
<DutchGh0st>
I dont have any experience with it, how well does it catch mistakes?
<andrewrk>
100%
<andrewrk>
and it gives you a stack trace of where it was allocated, freed, reallocated
<DutchGh0st>
:D
mnoronha has quit [Ping timeout: 256 seconds]
mnoronha has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 252 seconds]
<DutchGh0st>
I wonder how well all this comptime stuff would work with idea's like decorators
DutchGh0st has quit [Ping timeout: 252 seconds]
tobbez has joined #zig
hoppetosse has joined #zig
hoppetosse has quit [Remote host closed the connection]
DutchGh0st has joined #zig
<DutchGh0st>
How do I match against what I get back from @typeInfo
<MajorLag>
if an arg is type 'type' or 'var', every arg after it and the return type will be `arg_type == null`
<andrewrk>
yes, when you use reflection, the illusion that generic functions and normal functions are the same is dispelled
<MajorLag>
also happens when you try to make interfaces out of them.
<andrewrk>
yeah. it's one of the unsolved problems
<MajorLag>
interesting note, if you use `@typeOf(@field(Type, "actual field"))` on an actual field, it won't work. You need an instance of Type to use @field against. I solved this by `const ptr = @intToPtr(*T, 0);` then `@typeOf(@field(ptr, "actual field"))`
<andrewrk>
yuck
<DutchGh0st>
what is this 'TargetType' ?
<andrewrk>
(that's not a criticism of your code, but of myself because of what you were forced to do)
<wink_>
MajorLag: it looks like paste.ubuntu.com have expiration dates (8/30/2018), it would be nice if they were permanent so they'd be useable "forever" from the logs (https://irclog.whitequark.org/zig/2018-08-23). I believe https://gist.github.com are permanent I'm sure there are others.
<MajorLag>
I know, but I couldn't think of a better way without actually instantiating something.
<MajorLag>
@wink, I'm manually setting them to expire in a week. Partly because the language is still in flux and I don't think it's a good idea to have a lot of invalid syntax and bad workarounds floating around, but also because I want to dispose of incriminating evidence.
<andrewrk>
lol
<MajorLag>
DutchGh0st: TargetType is whatever type the function is a member of. Oh, it occurs to me now you might want to examine a top level function...
<MajorLag>
andrewrk: based on discussion in the "comptime interfaces" thread, I've designed a simple trait mechanism and a much more elaborate typeclass mechanism. Typeclasses can act pretty well as a "comptime interface" in my experiments, provided a tiny bit of language sugar.
<wink_>
MajorLag: IMHO, I think it would be better to have it permanent, but your call.
<andrewrk>
MajorLag, I'll be sure to read that carefully when I go through all those discussions
<andrewrk>
I've been putting off that particular language design decision, although I know it's important
<MajorLag>
DutchGh0st: just replace `@field(TargetType, "fnName")` with the function identifier. `@typeOf(someFn);`
<andrewrk>
after 0.3.0 is released it'll be time to create a 0.5.0 milestone and then sort out what "sooner" (0.4.0) and "later" (0.5.0)
<andrewrk>
*sort out what issues will be done
<DutchGh0st>
"error: variable of type 'FnArg' must be const or comptime"
<DutchGh0st>
wait Im a noob
<MajorLag>
what I like about my idea, aside from it being mine, is that it is pretty simple. `var<x>` where `x` is of type `fn(type)bool`. the compiler will run the comptime function `x` against the type of that var and throw an error if it comes back false. In my implementation of this (without the var<> part, it's done with asserts), simple traits like `hasFn("next")` are pretty clear already, but for Typeclasses (which are
<MajorLag>
r instance specifying the arguments of the "next" fn and any fields that need to be exposed) I added a lot of @compileErrors to give better detail, like "argument #2 of fn 'doStuff' does not match TypeclassType definition.".
<DutchGh0st>
can you alter the argtypes?
<andrewrk>
MajorLag, I'm also going to evaluate if the feature should solve runtime dispatch or not, or whether that should be a different feature, or whether that should not exist
<MajorLag>
DutchGh0st: I pulled that code out of my Typeclass implementation, which is wrapped in a comptime{} block. Changing the for to inline might also work.
<MajorLag>
I don't know that it can help with runtime dispatch. That requires vtables and the like...
<MajorLag>
or our current interface implementation.
<DutchGh0st>
noo but I mean compiletime change
<MajorLag>
No, you can't reify a typeInfo currently. There's no way to go from typeInfo back to a type.
<andrewrk>
it's a contended issue whether to have that
<andrewrk>
it's extremely powerful - some might say too powerful
<DutchGh0st>
I suppose it would be usefull if you are into decorator like stuff
<andrewrk>
and while everybody has fun writing @reify-style code, nobody wants to read it
<MajorLag>
As much as I can dream up interesting uses for it, I do also see how it could make things overly complicated.
<DutchGh0st>
but you dont have to use if you dont want to
<andrewrk>
DutchGh0st, zig's philosophy is that actually you do end up having to use features that you don't want to, because in practice people collaborate
<andrewrk>
so it's important what is *not* available in zig
<andrewrk>
because you can know with 100% certainty that when you crack open your collaborator's code, they didn't do certain things
<andrewrk>
and that certainty lets you rapidly understand code
<wink_>
andrewrk: I wanted to get the return type of a fn in a struct. I created a function that loops over the names in a Definition and then returning def.data.Fn.return_type. Is there a easier way to lookup the fn's in a struct?
mnoronha has quit [Ping timeout: 268 seconds]
<MajorLag>
@field(Type, "fnName").ReturnType should work
<MajorLag>
Or even: Type.fnName.ReturnType
<wink_>
T.fnName.ReturnType is an error "'fn(*BmAdd) void' does not support field access"
<MajorLag>
TraitFn is defined as `fn(type)bool`. It isn't a built in type
<DutchGh0st>
ohh I see
<MajorLag>
I don't know if you realize, but you can say things like: `const StringList = [][]const u8`
<MajorLag>
and then use StringList as an alias for [][]const u8: `var data = StringList{"A","B","C",};`. That one in particular I've had to use to get around lack of varargs at comptime.
DutchGh0st has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<cgag>
is there a way to split a namespace across files, like the equivalent of multiple files with 'package "main"' in go?
<MajorLag>
hierarchically, yes. `use @import("whatever.zig");` will import the entirety of "whatever.zig" into the current namespace.
<MajorLag>
I'm not sure how a circular use reference would be handled.
<andrewrk>
it works correctly
<andrewrk>
top level declarations are order-independent, regardless of which files they are declared in
<cgag>
ah ok, didn't know about `use`, thanks
<andrewrk>
it's generally discouraged unless you're trying to make your public API better
<cgag>
yeah i just thought of a less hacky way to do this, but was curious regardless