[00:06] *** reportable6 left [00:07] *** reportable6 joined [01:18] how much longer until it gets merged? [01:23] *** frost joined [01:38] *** Kaipi left [02:19] *** [Coke] left [02:22] *** [Coke] joined [04:53] *** Kaiepi joined [05:38] *** frost left [06:07] *** reportable6 left [06:08] *** reportable6 joined [06:28] good *, * [07:31] drakonis: there's quite a bit of work ahead still [07:36] something like: [07:36] 1162 red spectests with a status fail [07:36] 1162 red spectests with a status fail [07:36] and if one red spectest should unexpectedly pass [07:36] there'd by 1161 red spectests with a status fail [07:36] (repeat for another 1161 verses) [07:37] also, "unexpectedly pass" is not a good thing [07:37] "it's not easy being green" [07:40] My gut feeling says we're probably somewhere in the middle. That may sound disappointing considering the 2 years or so since the start. But then so far it was pretty much only jnthnwrthngtn working on it and he did new-disp in the same time frame. The latter is done and I have just joined the effort. And I think most of the difficult design questions are answered. [08:49] *** frost joined [09:24] nine: I think there's still quite a few tricky design questions to go :) [09:25] nine: btw, it was 320 passing not so long ago, so back to 277 is still quite the regression [10:24] *** linkable6 left [10:26] *** linkable6 joined [10:33] *** sena_kun left [10:34] *** sena_kun joined [10:44] `Cannot have attributes on an array representation`. i just attempted to add some methods to MAST::Bytecode that would do a write_at at an incrementing position (to clean up https://github.com/Raku/nqp/pull/768), but the idea may not work nicely [10:45] i.e., i tried to add `has $!pos` and then the new method would do `write_at(..., $!pos); $!pos := $!pos + x;` [10:48] guess i can just implement via MoarVM::BytecodeWriter in NQP instead [10:52] jnthnwrthngtn: I have never managed to get 320 passing, even on the commit before my very first one [10:52] So 277 was my base line [10:53] MasterDuke: if it becomes too troublesome, I'd just leave your PR as it is. I don't like it, but sometimes we just have to accept a little uglyness [10:55] i'll see if doing in on MoarVM::BytecodeWriter is any cleaner, it's not difficult to give it a try. if not, i'll revert to as is + a variable rename for clarity [11:49] *** linkable6 left [11:49] *** evalable6 left [11:50] *** linkable6 joined [11:52] *** evalable6 joined [12:06] *** reportable6 left [12:07] *** reportable6 joined [13:03] nine: Will check what I get. t/12-rakuast/var.t fails on latest `rakuast`, btw [13:03] But package seems OK [13:07] nine: Back up to 320 for me! \o/ Trying to guess the difference: do you do a `make spectest` without RAKUDO_RAKUAST=1 and then one with? [13:08] The first one pre-compiles all the various utility modules [13:08] And then the RakuAST-based compiler can load them [13:09] I guess just doing `make test` followed by the spectest with RAKUDO_RAKUAST=1 would pass rather less (for example, all that use is-run) [13:09] Ah, and I guess the var.t failure is the one we talked about :) [13:10] Yes, that's the one somewhat fishy test [13:10] And yes, I'm pretty sure that explains it :) I have noticed that I get only failures until I run one test without RAKUDO_RAKUAST=1. But of course that one test will not load all the modules [13:11] Aha, OK, then it makes sense. [13:34] *** evalable6 left [13:34] *** linkable6 left [13:37] *** linkable6 joined [13:37] *** evalable6 joined [13:40] *** linkable6 left [13:42] *** linkable6 joined [14:07] *** frost left [14:11] *** Geth left [14:46] *** linkable6 left [14:50] *** linkable6 joined [15:34] *** TempIRCLogger left [15:37] *** Geth joined [15:45] *** TempIRCLogger joined [15:49] *** TempIRCLogger left [15:50] *** TempIRCLogger joined [16:22] *** sena_kun left [16:22] *** sena_kun joined [16:50] *** jdv left [16:50] *** jdv joined [18:04] *** discord-raku-bot left [18:04] *** discord-raku-bot joined [18:05] *** reportable6 left [18:06] *** reportable6 joined [19:37] *** Kaipi joined [19:38] *** Kaiepi left [19:41] *** Kaipi left [20:12] hm, i don't think adding anything to MoarVM::BytecodeWriter is any cleaner. i could add an `$!mbc_pos` along its `$!mbc` and some methods which manipulate the two, but it/they would only be used in `write_frame` [20:18] dunno. all those `$!mbc.write_uint32_at($foo, $idx); $idx := $idx + 4;` could become `self.add_uint32($foo);`, with implementation `method add_uint32($data) { $!mbc.write_uint32_at($data, $!mbc_pos); $!mbc_pos := $!mbc_pos + 4; }` [20:18] maybe just two lexical subs in `write_frame` is better [20:19] then if the same kind of change is made elsewhere they could be pulled out into methods [20:28] 320 it is! [20:29] nice [20:49] High time for me to get to work and get 100 more passing... [20:53] ~1352 is the final target, correct? [20:57] Yup [21:20] Now it's 321 [21:26] <[Coke]> woot [21:35] Will try and get a few more tomorrow. My brain is still mushy today. [21:40] *** evalable6 left [21:40] *** linkable6 left [21:41] *** evalable6 joined [21:42] nice. after the excitement of putting an offer on a house, going to go save earth from (another) alien invasion [21:43] *** linkable6 joined [21:49] Cool, best of luck with the house. :) [21:54] ... and the alien invasion [21:57] .oO( Would they be worse than humans? ) [22:07] thanks (for both)