Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:31 patrickz left, patrickb joined 01:53 evalable6 left, releasable6 left, unicodable6 left, tellable6 left, bloatable6 left, sourceable6 left, quotable6 left, shareable6 left, coverable6 left, nativecallable6 left, bisectable6 left, linkable6 left, committable6 left, benchable6 left, squashable6 left, notable6 left, greppable6 left, statisfiable6 left 01:54 greppable6 joined, releasable6 joined, bisectable6 joined, unicodable6 joined 01:55 coverable6 joined, notable6 joined 01:56 bloatable6 joined, sourceable6 joined 01:57 committable6 joined 02:54 evalable6 joined, quotable6 joined 02:55 benchable6 joined 03:03 patrickb left 03:05 reportable6 joined 03:41 frost left 03:55 linkable6 joined, squashable6 joined 03:56 nativecallable6 joined, statisfiable6 joined 04:55 tellable6 joined 04:56 shareable6 joined 06:02 reportable6 left 06:03 reportable6 joined 07:20 Merfont joined 07:22 Kaipi left 07:29 frost joined
Nicholas good *, * 09:33
10:07 evalable6 left, linkable6 left 10:10 evalable6 joined
jnthnwrthngtn o/ 10:18
Nicholas \o
10:55 TempIRCLogger left 10:56 TempIRCLogger joined 10:58 TempIRCLogger left 11:10 linkable6 joined 11:11 TempIRCLogger joined
nine I get the impression that my unsigned fixing is going to be the most invasive change I've ever done to rakudo. I've now tought the dispatcher and binder that uint and int are different things. Next up: assign_u 11:16
lizmat nine++ 11:17
lizmat looks forward to putting UInts in the core in places where they should have been, but weren't 11:20
like AT-POS() :-) 11:21
and thereby getting rid of a lot of code checking for <0
jnthnwrthngtn Is UInt becoming a nominal type rather than a subset type? 11:24
lizmat that was my impression ?
nine No, I hope not
lizmat ah :-(
why would that be a bad idea ?
jnthnwrthngtn I'd kinda thought it might
nine I don't think you'd want that, as it'd make mixing UInt and Int in calculations painful
lizmat Uint could be a subclass of Int ? 11:25
*UInt
nine But mostly because I'd hoped that there'd be some of rakudo left unchanged :D
jnthnwrthngtn I don't think subclass makes sense; subclasses are meant to add capabilities, not take them away.
lizmat we don't have to do that right away... but it would make all array accesses much closer to the metal
jnthnwrthngtn Plus likely a bunch of other issues 11:26
lizmat m: dd Hash.^mro # jnthnwrthngtn
camelia (Hash, Map, Cool, Any, Mu)
jnthnwrthngtn Yes? Hash an do more than Map (adds mutability)?
lizmat that's one way to think about it... 11:27
nine I wonder if I'll have to add a new prim spec for uint at some point 11:28
lizmat nine: I don't think you will be able not to :-)
jnthnwrthngtn This stuff raises so many questions, though. 11:30
nine Ok, my simple my uint @a = 1, 2; $_++ for @a golf now works. Of course, probably everything else is broken though
jnthnwrthngtn Like how do you write a UInt literal.
Nicholas do you need to be able to? 11:31
lizmat 0u42
0i42
Nicholas in that, can you write a bigint literal, that's distinct from a regular int literal?
nine Cannot resolve caller infix:<+>(Int:D, Int:D); none of these signatures match: 11:33
... (Int:D $a, Int:D $b --> Int:D)
jnthnwrthngtn oops
11:42 Altai-man joined
nine I bet the error is misleading and the problem is really that the int candidate no longer matches and there's no uint candidate 11:42
But adding those gives me an ambiguous call. So there's still work to do in dispatch/binder
12:02 reportable6 left
nine I could live quite well with just half as many ways to specify primitive types... 12:24
Looks like I really am gonna need a new prim spec kind 12:31
And the escalation continues... 12:34
12:44 TempIRCLogger left 12:45 TempIRCLogger joined
nine There is a MVM_STORAGE_SPEC_BP_UINT64 already (as well as smaller sized ones and sized signed integer variants). But it appears to be pretty much unused. 13:04
13:04 reportable6 joined
nine They are only actually returned by nqp::lexprimspec which has a single user in HLL::Actions 13:08
lizmat m: my uint $a = -42; say $a # possibly allowing for this? 13:12
camelia -42
13:24 squashable6 left 13:30 TempIRCLogger left, TempIRCLogger joined 13:39 TempIRCLogger left, TempIRCLogger joined
timo every Int literal is UInt, and prefix:<-> returns an Int from that :P 14:04
14:07 frost left 14:26 squashable6 joined
nine Ah, maybe I can get by without the new primspec kind after all. A captureposprimunsigned op could do the trick (at least for the current problem) 15:05
Though I have to admit that the new primspec kind would alleviate the need for quite a bit of special casing throughout the code base. I still have this irrational hope of ever getting done however. 15:07
Oh....no, that would not work. You can't ask a primitive type in a register about it's REPR_data... 15:32
We'd need a new MVM_CALLSITE_ARG_TYPE for that (yet another one of those ways to specify types) 15:33
17:21 TempIRCLogger left 17:22 TempIRCLogger joined 17:46 discord-raku-bot left 17:56 TempIRCLogger left, TempIRCLogger joined 18:02 reportable6 left 18:05 reportable6 joined 18:21 Altai-man left 18:28 SmokeMachine left 18:29 SmokeMachine joined 18:39 TempIRCLogger left, TempIRCLogger joined 19:54 TempIRCLogger left 19:55 TempIRCLogger joined 20:01 linkable6 left 20:03 TempIRCLogger left, TempIRCLogger joined 20:14 JRaspass left 20:20 TempIRCLogger left, TempIRCLogger joined 20:21 JRaspass joined 20:22 TempIRCLogger left, TempIRCLogger joined 20:24 TempIRCLogger left, TempIRCLogger joined 20:30 TempIRCLogger left, TempIRCLogger joined 20:34 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined, TempIRCLogger__ joined 20:35 TempIRCLogger left, TempIRCLogger__ left, TempIRCLogger joined 20:36 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left 20:37 TempIRCLogger joined 20:42 lizmat_ joined 20:45 lizmat left 20:46 lizmat_ left, lizmat joined, TempIRCLogger left, TempIRCLogger joined 20:50 TempIRCLogger left 20:51 TempIRCLogger joined 20:54 TempIRCLogger left, TempIRCLogger joined 20:55 TempIRCLogger left 20:56 TempIRCLogger joined 21:00 TempIRCLogger left, TempIRCLogger joined 21:01 TempIRCLogger left, TempIRCLogger joined 21:04 linkable6 joined
MasterDuke arxiv.org/abs/2109.01950 "Type Stability in Julia: Avoiding Performance Pathologies in JIT Compilation", i didn't read the whole things, but looks like something jnthnwrthngtn might be interested in 21:13
i was experimenting with a fix for the problem of interpolated variables not getting flipped in `<?after $foo>`. if i'm reading things correctly, github.com/Raku/nqp/blob/master/sr...1011-L1045 is the implementation of how the overall regex gets flipped 21:25
i tried adding an `elsif $qast.rxtype eq 'subrule' && $qast.subtype eq 'method' {`, but i haven't figured out a correct implementation yet 21:26
jnthnwrthngtn I suspect only declarative things can really be flipped 21:27
MasterDuke in the --target=ast the "body" of the QAST::Regex in question is a QAST::NodeList
that calls INTERPOLATE
but i haven't been able to add a call to nqp::flip 21:28
another option would be to create an INTERPOLATE_FLIPPED in rakudo (or add a new flag to INTERPOLATE) 21:29
jnthnwrthngtn: so you think putting a non-literal in an <?after> should be disallowed? or just warned?
or should this entire problem just be punted until rakuast and/or an eventual regex implementation re-write? 21:32
jnthnwrthngtn Potentially an INTERPOLATE_FLIPPED would be possible is it's a string interpolation. 21:36
*if it's
MasterDuke *really* doesn't want to have to mess around with INTERPOLATE* (there be dragons), but if that's the best option... 21:39
jnthnwrthngtn We could just decide it's not supported and, in RakuAST, stick a "can-be-in-after" method on all RakuAST::Regex nodes, defaulting to False and overriding it to True for the cases we can handle 21:40
At least that way it's a clear "we don't support this" error
MasterDuke that does seem like a bit of a cop out though, since this is only a problem given the way we've implemented <?after> 21:42
that whole torture-implementor-thing coming to bite us
but you don't think we should try to support something like `<?after <{ "foo" x 3 }> >`? or would that be a string interpolation? (fyi, the ast for that shows a call to INTERPOLATE_ASSERTION 21:46
jnthnwrthngtn Sigh, of all the supid things that could happen, my monitor just failed, with a nice electrical smell :/ 21:58
jnthnwrthngtn ponders going to the office to fetch a spare from there
At least I've the laptop 21:59
MasterDuke has been trying to years to find a new monitor, but hasn't been able to find one with the right set of specs for the right price
jnthnwrthngtn MasterDuke: If somebody wants to implement it, I don't mind. It's a very long way down my own priority list for regex things.
nine With which you still can ssh into that machine with its awesome power 22:00
jnthnwrthngtn I mean, it's nice if it works, but I've so rarely reached for `after`...
nine MasterDuke: ha! Same here
jnthnwrthngtn nine: I can, but laptop is still not so ergonomic for me :/
MasterDuke heh. "wants" may be an overstatement, but it might be something i can do... 22:01
nine jnthnwrthngtn: in truth it's not ergonomic for anyone. At least a monitor is relatively pain free to replace. Once you have a new one that is
jnthnwrthngtn Yeah, I really wanted to work form home tomorrow, and there's trams for another hour, so I'll go collect the spare. bbl 22:02
MasterDuke nine: what are you looking for? i want high ppi, so something like a 5k 27" monitor. however the prices for the good quality ones are still crazy high, and the cheaper ones seem of questionable quality, and both aren't always very linux-compatible (or at least with my mb)
i can't seem to find something in the middle price point at all, regardless of compatibility 22:03
nine Something like a 34" 16:10 or maybe 16:9 high ppi display
MasterDuke it is kind of annoying that almost all the new monitors are 16:9. i much prefer my 16:10, but i want a lot more pixels in roughly the same physical space 22:05
nine I want at least as much vertical space as the 13 (or so) year old 30" monitor I currently use 22:07
ugexe i was recently looking at displays and ended up with P3222QE since i didn't want to pay the price for 5k
nine does look nice 22:08
ugexe it carries power and video over a single usb-c so its also like a laptop dock 22:09
MasterDuke i'm still using my 15.5 year old 24" Dell UltraSharp 2405FPW 22:11
the other problem is i still haven't been able to buy a new video card (because i won't buy one at crazy inflated prices) 22:12
ugexe i joined a discord channel when i wanted to get a ps5 and it only took about a week of watching before i was able to get one through retail 22:23
i remember there was a room for video cards too 22:24
japhb I've got an LG 27" 4K 16:9 that was relatively inexpensive and I've been pretty happy with, and it works fine as a second monitor for my Linux Mint laptop. 22:42
MasterDuke i've gotten into the queue on amd.com a couple times, but the rx 6800 has always been sold out when i get out of the queue 22:43
japhb It sounds like people are looking for 5K and 16:10, but I'll tell ya, the upgrade from my 2K panel was HUGE. TOTALLY worth the mid-range step.
MasterDuke if my monitor died that's probably what i would replace it with (while still looking for a 5k), but i'm still happy enough with this i'll just wait until a really big step 22:49
i'm also tempted by an e-ink monitor as a second screen just for coding 22:50
23:02 TempIRCLogger left 23:03 TempIRCLogger joined
jnthnwrthngtn yay for trams until midnight :) 23:03
Goodness, it's only now I hae it on my desk at home that I realize this monitor is rather bigger than the one it's replacing
*have
lizmat :-)
jnthnwrthngtn So, the Tika failure I can't repro but it may be a port conflict in testing or something 23:08
The November one is...weird
Among this module's problems are that it has a leftover - from a merge conflict! github.com/viklund/november/blob/m...gs.pm#L116 23:11
23:15 TempIRCLogger left, TempIRCLogger joined
jnthnwrthngtn OK, too tired for this already. Will have to wait for another day. 23:21
The failure mode is so odd I wonder if I've really broken this or if it's a mis-bissect

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!