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:24 tbrowder left 00:27 SmokeMachine left, leont left 01:04 reportable6 joined 01:11 tbrowder joined 01:14 SmokeMachine_ joined, leont joined, SmokeMachine_ is now known as SmokeMachine 02:01 CaCode- joined 02:04 CaCode_ left 03:43 benchable6 left, linkable6 left, releasable6 left, greppable6 left, tellable6 left, statisfiable6 left, bloatable6 left, sourceable6 left, shareable6 left, unicodable6 left, evalable6 left, bisectable6 left, notable6 left, coverable6 left, committable6 left, nativecallable6 left, reportable6 left, squashable6 left, quotable6 left 03:44 bloatable6 joined, unicodable6 joined, tellable6 joined 03:45 bisectable6 joined, statisfiable6 joined, greppable6 joined, nativecallable6 joined, releasable6 joined 03:46 sourceable6 joined 04:44 coverable6 joined, evalable6 joined 04:45 linkable6 joined, committable6 joined 04:46 reportable6 joined, notable6 joined 05:16 frost joined 05:44 quotable6 joined 05:46 benchable6 joined 06:03 reportable6 left 06:45 squashable6 joined 06:56 CaCode_ joined 06:59 CaCode- left 07:03 reportable6 joined 07:44 shareable6 joined 08:20 CaCode joined 08:21 CaCode_ left 08:29 japhb left 09:00 CaCode_ joined 09:03 CaCode left 09:25 ugexe left 09:39 ugexe joined 10:10 ugexe left, ugexe joined
lizmat had a flu shot yesterday and is feeling a little bit under the weather now 10:29
10:31 CaCode- joined 10:34 CaCode_ left 10:41 CaCode_ joined 10:44 CaCode- left
nine got his on Tuesday :) 10:49
11:00 CaCode_ left
lizmat hmmm... can't seem to think of syntactic sugar for creating a Seq of lazily created Seqs 11:39
m: my $s := (1,2,3,4).map: { .say; (^$_).Slip }; say $s.head(3) # the closest I can come up with 11:43
camelia 1
2
(0 0 1)
timo you want not to have Seq objects inside the resulting Seq, but one Seq that gives results from consecutive lazily created seqs? 11:48
11:55 japhb joined
jnthnwrthngtn lizmat: Calling .flat on what you get back from .map won't do it? 11:55
(Without the slip...)
Urgh, this is not going to be a very productive day... 11:57
(No, I didn't do a flu shot too...)
lizmat timo: indeed 12:00
I know how to do it using iterators and such, am just wondering how one would do it without resorting to such low level approaches 12:01
lizmat is also distracted by the history of Booking.com book that just arrived 12:02
12:02 reportable6 left
lizmat www.bol.com/nl/nl/p/de-machine/930...051708336/ 12:03
dogbert11 jnthnwrthngtn: is the coffee machine broken? 12:05
jnthnwrthngtn dogbert11: No, my stomach kinda is, though, which means I should avoid coffee. 12:06
Or at least, it doesn't feel like a great idea.
lizmat camomile tea ? 12:07
jnthnwrthngtn Yes, that's probably what's next.
lizmat chicken soup?
jnthnwrthngtn Hm, didn't know that was something for rough stomachs. :) 12:08
Given there's no particular objects to github.com/rakudo/rakudo/pull/4633, will clean up the thing nine++ noticed and the failing spectest and undraft it 12:09
releasable6: status
releasable6 jnthnwrthngtn, Next release in ā‰ˆ8 days and ā‰ˆ6 hours. 3 blockers. Changelog for this release was not started yet
jnthnwrthngtn, Details: gist.github.com/ee601cf4e0e4fa217f...a31b6d9a91
jnthnwrthngtn Hm, wonder if it's wise to wait until after that. 12:10
dogbert11 tea is good if the stomach is 'overly active'
timo jnthnwrthngtn: so that we only have new-disp in the release, but not get-rid-of-attrinited immediately as well? 12:12
jnthnwrthngtn new-disp was in the previous release anyway :) 12:13
But new-disp-nativecall is maybe in this one?
lizmat feels like we should either for the release indeed, not both 12:15
and there's still the matter of finding a release manager :-(
jnthnwrthngtn Yes, and getting blin runs 12:18
I hoped there'd be a release manager volunteer or two by now 12:19
timo my desktop is definitely not beefy enough for blin at a reasonable pace :D 12:20
jnthnwrthngtn m: class C { has int $.x = 1 }; C.new.x.say
camelia 1
jnthnwrthngtn m: class C { has int $.x = 1 }; C.new(x => 2).x.say
camelia 2
jnthnwrthngtn m: class C { has int $.x = 1 }; C.new(x => 0).x.say 12:21
camelia 1
jnthnwrthngtn m: class C { has int $.x is required }; C.new
camelia The attribute '$!x' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
jnthnwrthngtn m: class C { has int $.x is required }; C.new(x => 2)
camelia ( no output )
jnthnwrthngtn m: class C { has int $.x is required }; C.new(x => 0)
camelia The attribute '$!x' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
timo oh no 12:22
jnthnwrthngtn Um. Well, there's nothing much good we can do about this, tbh.
Thing is, attrinited never checked what kind of attriubte it was, it just read a pointer and checked for nullness 12:23
timo checking for presence in the named arguments when calling bless isn't an option, right? the definition could be like "has int $.x = $.y - 5" and then it'd be fine to not have x
jnthnwrthngtn Not really because you can also write it in a BUILD
timo right, or TWEAK 12:24
jnthnwrthngtn TWEAK is after defaults are applied, but I guess before required, iirc
timo so, give a deprecation warning for "is required" on int attributes?
jnthnwrthngtn But yeah, there's a semi-predicate problem here and...I dunno what to do about it.
timo for num we can potentially abuse tagged nans
jnthnwrthngtn But I suspect it is widely used 12:25
timo just gotta make sure the user doesn't use the exact same nan that we use
jnthnwrthngtn greppable6: has int
greppable6 jnthnwrthngtn, 951 lines, 146 modules: gist.github.com/50949d7766b8b0e868...9ad3bbf0d2
timo i see only one instance of "is required", though not sure if any declarations are split across lines 12:26
jnthnwrthngtn Yeah, quite a few more of default 12:27
timo oh, i totally missed that 12:28
jnthnwrthngtn So it turns out that for defaults we didn't rely on the attrinited semantics at all 12:31
nqp::if( # 5
nqp::iseq_i(my int $int = nqp::getattr_i(self,
nqp::atpos($task,1),
nqp::atpos($task,2)
), 0),
We really do compare it to 0
timo yeah that's kind of a footgun
jnthnwrthngtn So it's only `is required` that cheats
timo not sure if we should try declaring that a DIHWIDT
jnthnwrthngtn It is, but I think deciding what to do about it is probably quite the yak shave...
I'm inclined for now to just introduce buid plan codes for `is required` on the natives 12:32
In order to preserve current semantics
And then we can later discuss what to do with them
timo what does your branch currently do for is required and default values?
jnthnwrthngtn For natives? 12:33
timo yes
jnthnwrthngtn I believe ends up with a boxed value and then always considers it as an initialized thing 12:34
dies-ok { CompUnit::DependencySpecification.new }; 12:35
That's the test that fails, and it doesn't throw an exception that the attribute was required but not provided 12:36
(It's a str attribute)
timo ok, so goes from "passing 0 explicitly triggers default and required throws" to "whether you pass something or not it always succeeds and never uses the default initializer" and by adding the build plan code we'll get the earlier behaviour back
jnthnwrthngtn Right
timo +1 from me on doing it like you proposed: get earlier semantics back, work on an actual decision later 12:37
jnthnwrthngtn Yeah, I can open a problem-solving about it maybe
I can't see any especially good options 12:38
"sorry, you can't have the compactness of natives *and* these niceities" maybe
(e.g. deprecation) 12:39
I did momentarily consider madness like having an extra, secret, attribute that is used as a boolean flag
But...if people are doing natives it's probably because they care about object size. And in CStruct it's outright dangerous 12:40
lizmat fwiw, I'm ok with "is required" not working on native int / num
jnthnwrthngtn Not to mention an absolute implementation nightmare anyway
lizmat native str has a non-initialized state that can be troublesome
jnthnwrthngtn OK. So, I'll 0) have lunch, a) restore current semantics, b) make a PS issue for further discussion
bbiab
lizmat m: my str @a; @a[1] = "foo"; dd @a[0]
camelia chars requires a concrete string, but got null
in block <unit> at <tmp> line 1
lizmat so I'd argue you *can* see if a native str has been set or not 12:41
jnthnwrthngtn lizmat: Oh, at least for attributes I'll be able to fix that one in a bit
You can but...I don't know we should expose that :)
lizmat well, there's that
again, if we can always have a "" in a native str by default
then I could live with no "is required" on natives 12:42
because you basically always have a default , and defaults and "is required" don't mix
m: class A { has $.a is required = 42 } # guess that should also be a compile time error 12:43
camelia ( no output )
lizmat m: class A { has $.a is required = 42 }; A.new
camelia The attribute '$!a' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
13:03 reportable6 joined 13:42 leont left, tbrowder_ joined, SmokeMachine_ joined, tbrowder left, tbrowder_ is now known as tbrowder, SmokeMachine left, SmokeMachine_ is now known as SmokeMachine 13:43 leont joined 13:44 dogbert11 left 13:46 CaCode joined 13:51 CaCode left, CaCode joined 13:53 dogbert17 joined 13:56 CaCode_ joined
jnthnwrthngtn lizmat: Defaulting str attributes to '' can happen as part of the work that will follow getting rid of attrinited (which will be the step removing lazy auto-viv of attributes) 13:56
13:59 CaCode left
lizmat yeah... that'd be nice :-) 14:00
14:01 frost left
dogbert17 hmm, I'm getting a test failure in t/spec/MISC/bug-coverage.t (test #2) when running with MVM_SPESH_NODELAY=1 14:05
No such method 'Str' for invocant of type 'VMNull'. Did you mean
'Str'?
in sub count at /home/dogbert/repos/rakudo/t/spec/packages/Test-Helpers/lib/Test/Util.rakumod (Test::Util) line 61
in block at /home/dogbert/repos/rakudo/t/spec/packages/Test-Helpers/lib/Test/Util.rakumod (Test::Util) line 71
14:17 SmokeMachine left 14:19 leont left, tbrowder left 14:23 tbrowder joined 14:32 CaCode_ left 14:34 SmokeMachine joined, leont joined 15:01 ggoebel joined
jnthnwrthngtn greppable6: attrinited 15:03
greppable6 jnthnwrthngtn, Found nothing!
jnthnwrthngtn Wow, something no module author managed to depend on. I'm rarely so lucky... :) 15:04
lizmat yeah, it was pretty obscure :-) 15:05
I guess this can go now: github.com/Raku/nqp/blob/master/do...attrinited
jnthnwrthngtn Turns out removing it from NQP was easy too, though can't do that until it's gone from Rakudo
Oh, good catch
Added to the NQP branch 15:06
ggoebel regarding new release manager... are there any responsibilities or tasks which are not covered in: github.com/rakudo/rakudo/blob/mast..._guide.pod 15:10
lizmat sena_kun ^^ ?? 15:12
sena_kun I suspect so. I'll take my time today to review the document and update/clarify. 15:19
lizmat ++sena_kun 15:21
16:40 patrickb joined
nine jnthnwrthngtn: do you want to have a look at new-disp-nativecall or should I just merge? 16:49
jnthnwrthngtn nine: I can take a look over it. 16:54
This evening if I've the energy, tomorrow if not, if that's fine.
Gotta go for language class in a moment. That'll be interesting with a mushy brain. :)
17:56 rypervenche left 18:02 reportable6 left 18:04 rypervenche joined 18:05 reportable6 joined
timo i can possibly do a release, but probably not anything related to windows or mac 18:18
and also probably not blin 18:19
18:52 ggoebel_ joined, ggoebel left
timo .o( "Oops! MoarVM has been put in a situation in which it is not confident it can continue." ) 19:07
vrurg timo: don't embarrass the compiler, or it will embarrass you? 19:37
timo the compiler asks for your forgiveness 19:38
vrurg But it doesn't revoke your embarrassement. :) 19:39
timo trapped between a revoke and a reset --hard place 19:51
20:56 CaCode joined
jnthnwrthngtn Phew, that was quite a bit to review :) 21:26
nine++
Geth MoarVM/update-release-guide: d1b4ed5fdb | Altai-man++ | docs/release_guide.md
Update MoarVM release guide according to the actual release process
 21:35
MoarVM: Altai-man++ created pull request #1599:
Update MoarVM release guide according to the actual release process		 21:38
MoarVM/update-release-guide: e62bdcb940 | Altai-man++ | docs/release_guide.md
Update MoarVM release guide according to the actual release process
22:37 ggoebel_ left 23:51 harrow left 23:58 harrow joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!