05:14 <pixelherodev> Anyone currently on have a good knowledge of LLVM IR?

05:15 <pixelherodev> I'm also asking in #llvm on both freenode and the official OFTC server but from what I've seen those channels are both Very Quiet™ so I figured I'd ask here too in case anyone was familiar with it

07:03 <pixelherodev> Ah, the sweet smell of functioning optimizations at two in the morning :D

07:03 <pixelherodev> `Microoptimization zero is replacing load of %FirmwareCTX with an alias to %0`

07:35 <pixelherodev> Ah, using memberCount / memberName / field with an iterator from std.process.args to metaprogrammatically check runtime arguments...

08:05 <iocat> hey folks, is there any promise on backward compatibility, maybe on some part of the language today?

08:06 <iocat> (Very interested in learning this lang :) )

08:13 <pixelherodev> Not *yet* is I believe the best answer at the moment

08:13 <pixelherodev> Right now, the language is being improved a lot - but improving the language means existing code needs to be updated

08:13 <pixelherodev> Most of the changes are very minor, but they do add up

08:14 <pixelherodev> There *will* be such a promise eventually, though when that is I personally don't know

08:18 <iocat> oh ok thanks for the answer. I felt the language design is very simple, and extensible. Hope it'll be always simple. Will keep looking forward for its development!

08:22 <pixelherodev> iocat, a lot of these changes are actually meant to make the language *more* simple :)

08:23 <iocat> cool!

10:25 <pixelherodev> Just got the first working `Hello, world!` compiled using my LLVM backend :D

10:26 <pixelherodev> https://i.imgur.com/8t55Kt6.png

10:30 <pixelherodev> I mean, I cheated a *little* to get it working despite the fact that I haven't implemented e.g. strings :P

10:30 <pixelherodev> But still.

18:41 <pixelherodev> I'm starting to think my focus on this parser has gotten a bit... out of hand :P

18:42 <pixelherodev> This week alone, I plan on: implementing strings, implementing undefined values (though they already work for pointers), using a proper stream for output instead of stderr, removing the register allocator and allocating all variables to the stack and then accessing them from there (and then relying on optimizations to put them back into registers and increase performance), and beginning work on modularizing the parser so that it can actually be used as a

18:42 <pixelherodev> library and I can begin to add in an x86 backend

20:06 <andrewrk> pixelherodev, wow this is really cool!

20:06 <andrewrk> love seeing these screenshots

20:08 <pixelherodev> andrewrk, thanks!

20:11 <pixelherodev> `I actually cleaned it up so that the manual usage of the DragonFruit stack isn't necessary

20:11 <pixelherodev> A simple `a3x.Puts("str");` call works now :)

20:11 <pixelherodev> (a3x = the firmware)

20:11 <pixelherodev> The pointers and stuff are tracked by the a3x structure instead of being passed to main, making its usage a lot more convenient

21:30 <fengb> andrewrk: I started experimenting with generators again https://github.com/fengb/zig-tmpl

21:31 <fengb> I know you don’t like abusing async like this but it really simplifies callbacks / iterators

21:31 <fengb> (I’m also probably putting this on hold since a real templating engine requires an AST and comptime allocators...)

21:34 <pixelherodev> You could write a comptime allocator.

21:34 <pixelherodev> fengb, just decide on its size at comptime

21:35 <pixelherodev> And make a comptime array

21:35 <fengb> There’s an outstanding issue: https://github.com/ziglang/zig/issues/1291

21:41 <pixelherodev> Ah

21:43 <fengb> I guess I could slap together a node object pool for now. That wouldn’t be too bad

21:43 <pixelherodev> "One does not simply call a function pointer." ... Boromir, why?!

22:39 <Snektron> fengb, interestingly i also had a similar idea

22:39 <Snektron> I dont think you need either for comptime parser generator

22:40 <Snektron> My idea was to bind parsed structure to a struct somehow

22:41 <Snektron> For example struct { a: i32, b: i32 } could be parsed with "{a} {b}"

22:41 <Snektron> "10 -20" would be parsed by that

22:42 <Snektron> Was just an idea though, didnt work anything out

22:42 <fengb> I need arbitrary depth to handle for / if instructions

22:43 <Snektron> Yeah i was still thinking about how to handle nested structs

22:43 <Snektron> And arrays

22:44 <Snektron> You could also do a full on parser generator

22:45 <Snektron> You dont need recursion for those too i think

22:45 <Snektron> Though i forgot how LR(1) parsing worked, but thats probably what you'd want to implement

22:46 <fengb> I don’t see how it can be not recursive if I can have infinite embedded for loops

22:48 <Snektron> An LR(1) parser is just a kind statemachine i think

22:48 <Snektron> Maybe it needs a stack though

22:49 <Snektron> LR(1) parser generators are a lot of work though, i didnt even manage to complete my LR(0) one

22:51 <fengb> Oh the parser isn’t my concern. Running the formatter needs arbitrary nodes, which requires some form of allocation

22:51 <fengb> But I can possibly get by with a fixed object pool

22:52 <Snektron> Do you need allocation for formatting though?

22:52 <fengb> Nope, it’s generator based

22:53 <fengb> I think it’s a more scalable approach than the current formatter

22:54 <fengb> But andrewrk has mentioned he doesn’t like abusing async functions for generators

23:16 <bgiannan> is it possible to cast a []const u8 to a []u8 ?

23:18 <fengb> Something like `@intToPtr([*]u8, @ptrToInt(c.ptr))[0..c.len]`

23:49 <Snektron> Now thats what i call undefined behavior 2

23:52 <mq32> bgiannan: doing that sounds a lot like "bad design" and is probably undefined behaviour

23:54 <fengb> Yes but a lot of old C APIs are poorly typed