10:28 <GitHub159> [zig] kristate opened pull request #1297: [WIP] builtin function @handle() (master...handle-builtin-issue1296) https://git.io/fNupN

13:30 <bheads__> andrewrk, for a solution to the @handle issue 1297. What if functions could have implicit params. For async function you would have an implicit allocator and handle

13:30 <bheads__> fn <alloc, handle> foo(x: i32) { ... alloc and handle are in scope } ?

13:48 <bheads__> This idea could also be used to control the context a function executes in

13:48 <bheads__> fn<ctx: context> foo() void { } ... foo<new_ctx>();

14:06 <bodie__> howdy. I noticed the zig2 compiler has a similar issue to zig 0.2.0 on OSX where it can't find its libraries

14:06 <bodie__> er, "zig2" as in self-hosted

14:06 <bodie__> should I open an issue on this?

15:36 <andrewrk> bodie_, yes please. stage2 should at least be building on macos

15:37 <andrewrk> bheads__, handle isn't really passed in to an async function, it's created in the body

15:37 <andrewrk> in the function prelude

16:20 <andrewrk> ziegfried is a pretty great name for a general purpose allocator in zig

16:20 <andrewrk> https://github.com/mdsteele/ziegfried

19:54 <unique_id> looking at my c++ coroutine stuff from a while back...I have already forgotten how c++ coroutines work :( I have an async_http_write that returns an awaitable type of my own creation, which has an await_suspend method which gets passed a coroutine_handle, and it finally calls an asynchronous write function which takes a lambda, and from it I resume the coroutine

19:54 <unique_id> Maybe learning Zig's coroutines will help me understand C++'s coroutines :)

19:55 <unique_id> and after that I can port my c++ code

19:56 <andrewrk> unique_id, you might want to wait 1 day - I'm in the middle of a really important commit right now, dealing with cancel semantics

19:56 <unique_id> alright :)

19:56 <andrewrk> I'll have a really nice example of file system watching, where std.event.fs.watchFile() returns a Channel

20:05 <unique_id> how useful are stackless coroutines? Have I asked this question before? I mean you're only transforming a single function at the base of a call graph while everything else stays the same, no?

20:06 <andrewrk> they're useful in that you can use event-based programming with async/await syntax, which is huge

20:07 <andrewrk> here's the example I hinted at: https://gist.github.com/andrewrk/53edc9c545f0277772e463a50bc3db86#file-0test-zig-L30-L73

20:07 <andrewrk> to me, this is really high level code

20:07 <andrewrk> and it never goes beyond 1 level of indentation

20:08 <andrewrk> most of those try's on async can go away. there's an issue open for that. because when you await something in the same frame as you async it, and the function is comptime known, we can put the coro memory in the calling frame

20:09 <andrewrk> having used them at least in a proof of concept in self-hosted compiler, the stacklessness isn't an issue at all

20:10 <unique_id> okay, awesome

20:18 <andrewrk> one note is that the performance gap between debug mode and release-fast mode is bigger

20:19 <andrewrk> the cost for error return traces for normal functions is O(1) and the cost for error return traces for coroutines is O(N) where N is the max number of stack frames we collect (right now hard coded to 30)

20:19 <andrewrk> but iirc that only matters when an error is returned

20:20 <andrewrk> (in release-fast mode error return traces are disabled)

20:29 <unique_id> agh I missed your stream yesterday, gonna watch it now

20:30 <andrewrk> I think it got pretty dry. also everything I came up with relating to coroutines in that stream I've already tossed out

20:31 <andrewrk> but now I have a notebook with what I believe to be a sound plan

20:32 <unique_id> last time I learned about bash history searching :)

20:34 <andrewrk> ahhh. yes, it's life changing

20:34 <andrewrk> easily saves hours every day

23:17 <winksaville> I've created a Message http://bit.ly/2LE0kED that I can add any `BodyType` but I ran into a problem that the Queue class can only handle one type of Node but I'd like it to handle any type.

23:17 <winksaville> I then thought maybe I could use `data: var`, I tried `const Node = struct { data: var };`

23:18 <winksaville> But I get an "error: invalid token: 'var'

23:20 <winksaville> Any suggestions?