brokenchicken m: (^0x30000)».chr.grep(*.match(/<:Digit>/).not)».uniprops.flat.unique.say 00:21
camelia rakudo-moar 3e28b1: OUTPUT«(Nd No Nl Lo)␤»
samcv jnthn, lizmat on the <:Digit> matches anything. 00:27
Digit resolves to Numeric_Type fyi
m: say "something" ~~ /<:Numeric_Type>/
camelia rakudo-moar 3e28b1: OUTPUT«｢s｣␤»
samcv m: 'a'.uniprop('Numeric_Type').say 00:28
camelia rakudo-moar 3e28b1: OUTPUT«None␤»
samcv m: 'a'.uniprop-int('Numeric_Type').say
camelia rakudo-moar 3e28b1: OUTPUT«0␤»
samcv i wish i could understand that QAST file, i mean i'm not totally sure of the flow of the statements there. somebody will have to help me so i can fix some of these problems 00:32
brokenchicken Which QAST file? 00:41
samcv brokenchicken, src/vm/moar/QAST/QASTRegexCompilerMAST.nqp 00:45
the odd thing is that you can do scripts without qualifying the property like <:Latin>, all the property value's are comingled in moarvm 00:47
even though they are not unique between properties, so it causes some weirdness
it needs to check property name's before it checks property values. so likek for <:space>, the only reason it works is because 'space' is resolving to the Line_Feed property, and spaces have Line_Feed=space 00:48
brokenchicken knows nothing in that area
(yet)
samcv it _should_ check the property names, find there's a space property, and check uniprop-int
if it's not a property name, then we should check the property value list, and so it will find Latin refers to the script property, then check that Script == Latin 00:49
but it does it the reverse order atm
so values take precedence over property names
there need to be some big changes to mvm, and we won't be able to look up property names for anything except script and script extensions and idk maybe a few more, but 00:51
i think we only want Script and General category to be unqualified when doing <:Latin> or <:Ll>
timotimo we can introduce new ops for you at any time 00:52
samcv yeah ofc
timotimo (though not in the next few hours, because i'm hoping to be sleeping then)
samcv the main problem is the current ucd2c.pl assumed property values would be unique (aside from Yes/No) etc
timotimo ah, yes indeed
so we're blocked by the ucd2c rewrite?
samcv yeah
well partially. we can still change the order of lookups
check if the requested <:Foo> is a property name first 00:53
we can fix that part
and we'll prolly have an op that is like hasuniprop, but it doesn't take unicode property codes, it takes the actual string names/values 00:54
and i'll probably retain a big jumbled hash table that holds all the property values, at least until all the changes are made. but one issue is RE: unimatch 00:55
i'm guessing unimatch fails if you try and check a property value that is non-unique 00:56
also i was never sure what the point of unimatch even was
i.e. usecase
my $prop := Rakudo::Internals.PROPCODE($propname); 00:59
so nqp::matchuniprop($code,$prop,Rakudo::Internals.PVALCODE($prop,$pvalname));
atm this is the code for sub unimatch
err wait that's the one for the property specific one, not the one that matcches any property 01:00
err nvm it is
multi sub unimatch(Int:D $code, Stringy:D $pvalname, Stringy:D $propname = $pvalname) {
haha, it uses the property value as the property name? and yeah uh... that's really kinda hard for me to look at 01:01
since property names can be the same as property values
timotimo gotta go sleep, my brain isn't doing very much 01:03
samcv night 01:05
timotimo o/
samcv brokenchicken, fyi it seems +'10' can be cached while .Int cannot
timotimo perhaps you mean compile-time evaluated?
samcv ah 01:06
that is probably true
that makes sense then 01:07
brokenchicken samcv: why .Int cannot? Int => (digits-only ?? nqp::radix() !! .Numeric -> val()) whereas + => (Numeric -> val()) 01:16
samcv well Int i guess as timotimo said isn't compile time evaluated 01:17
brokenchicken And .Numeric is? 01:18
samcv it would seem 01:22
m: for ^10000 { +'10' / +'20' }; say now - INIT now; 01:23
camelia rakudo-moar 3e28b1: OUTPUT«WARNINGS for <tmp>:␤Useless use of "/" in expression "+'10' / +" in sink context (line 1)␤0.0037290␤»
samcv m: for ^10000 { '10'.Int / +'20'.Int }; say now - INIT now;
camelia rakudo-moar 3e28b1: OUTPUT«WARNINGS for <tmp>:␤Useless use of "/" in expression ".Int / +" in sink context (line 1)␤0.1282265␤»
samcv .Int is 34x slower there 01:24
brokenchicken m: for ^10000 { $ = +'10' }; say now - INIT now; 01:25
camelia rakudo-moar 3e28b1: OUTPUT«0.0039301␤»
brokenchicken m: for ^10000 { $ = '10'.Int }; say now - INIT now; 01:26
camelia rakudo-moar 3e28b1: OUTPUT«0.03161738␤»
brokenchicken m: say 0.0316/.0039
camelia rakudo-moar 3e28b1: OUTPUT«8.102564␤»
brokenchicken m: for ^10000 { $ = '10'.Numeric }; say now - INIT now; 01:27
camelia rakudo-moar 3e28b1: OUTPUT«0.1368020␤»
brokenchicken Weird, considering + -> a.Numeric
Turning off optimizer turns the scales 01:28
Ahhh 01:30
brokenchicken just had an 'aha' moment
Hm. Actually no :) 01:31
Oh, I misread this QAST
Yeah, the optimizer evaluates +'10' at compile time, cause prefix:<+> is marked pure. 01:33
m: class Foo is Str { method numify { self.Int } }; my $f = Foo.new: :value('10'); for ^10000 { $ = $f.numify }; say now - INIT now 01:35
camelia rakudo-moar 3e28b1: OUTPUT«0.03264332␤»
brokenchicken m: class Foo is Str { method numify is pure { self.Int } }; my $f = Foo.new: :value('10'); for ^10000 { $ = $f.numify }; say now - INIT now
camelia rakudo-moar 3e28b1: OUTPUT«0.03204627␤»
brokenchicken Is doesn't work on methods?
Apparently not. Just compiled a version making Str.Num, Str.Numeric, Str.Int, and all val() multies `is pure` and no effect 01:43
samcv hm 01:53
TimToady m: for ^10000 { $ = Int('10') }; say now - INIT now; 07:34
camelia rakudo-moar 3e28b1: OUTPUT«0.04653305␤»
TimToady has most of a patch getting rid of $*ACTIONS lookups, but still failing 14 spectests, so something's probably leaking $!actions outward from some cursor or other that doesn't reset to the outer self's $!actions 07:40
(eventually might do this with a method mixin rather than an attribute, which would be simpler in some ways, not so simple in others...) 07:45
nine wonders if there is a way to just speed up lookup of dynamics
TimToady well, that would help too, and we've talked about it some 07:46
nine How are dynamics managed right now? 07:47
TimToady instead of keeping a direct cache entry in each frame, you'd keep a pointer to the next frame with a 'my $*foo' anywhere, and from that frame keep a more extensible cache, since most frames don't set dynvars
we just scan down frames for a frame that has cached the name currently 07:48
and if it was too far away, we cache it in a closer frame
but it's still a linear scan
on average we're still looking at 5 or so frames before we get a match 07:49
actually, might be worse will all the new dynvars competing for the single entry per frame
nine Me knowing nothing of how to implement dynamics, I'd keep a hash of arrays around. Hash key is obviously the name of the dynamic variable. The array is the stack of values with assignment pushing the value on the stack. Lookup would be just a single hash access + the access to the last element of the array.
TimToady with a pointer instead of an entry, we could jump straight to the frame that is likely to contain the cached element in a hash or some such 07:50
and it could be more authoritative too, for anything immutable
nine I think we're thinking along similar lines: push the work into assignment of a dynvar instead of the reading. 07:51
TimToady well, the reading can still hoist from a further cache to a closer one, but you know it's always the closest one you're populating, so better than "half way down the framelist" 07:52
I think your approach sounds a bit thread-unsafe
more like how P5 does things
we'd still root things in the frames, just not look at every frame anymore
we could also be helped with some kind of key interning, since we do a lot of string cmps 07:53
but the $*ACTIONS, %*LANG, %*PRAGMAS need to be fixed anyway regardless, since the current language is supposed to be 07:54
carried by the cursor, not by dynvars
on the dynvar frame hashes, we might be able to just poke extra temp entries into the lexpad for the frame that already has a 'my $*something', if we're willing to cheat a bit on the immutability of lexpads 07:58
anyway, our dynvar overhead is currently around 5% compiling the setting, and we could certainly get most of that back by doing smarter caching 07:59
jnthn morning, #perl6-dev 10:04
moritz \o jnthn 10:05
jnthn TimToady++ # working to eliminate $*ACTIONS 10:08
moritz what's the new paradigma? 10:13
storing the actions class in an attribute somewhere? 10:14
jnthn Believe so, since $!attribute was mentioned 10:18
uh, $!actions
timotimo wow, most of that? neat. 10:19
jnthn From backlog: methods are late-bound, which is why we can't know if they're pure and compile-time resolve them. 10:21
timotimo jnthn: well, we could for constants because we already know their type then and could see if find_method is what we'd expect from "harmless" classes 10:30
jnthn True 10:32
samcv proto sub prefix:<+>($?) is pure { * } 10:34
multi sub prefix:<+>(\a) { a.Numeric }
i mean the prefix does a method call 10:35
DrForr role Mostly-Harmless {};
jnthn The problem isn't the mechanics of doing a method call, it's that things in our lexical scope are part of our langauge, and method calls are interpreted as part of the object's language.
That's one of the key Perl 6 design principles, so I'm just a tad wary when we consider cheating. :-) 10:36
timotimo well, the prefix is a sub 10:41
so we can just look it up
when we want to figure things out about an object's methods, we have to ask the object, and it's allowed to give us whatever answer it finds pleasing 10:42
that's why you can create objects that "have" methods based on a SOAP definition, or XMLRPC, or just every combination of car and cdr cddr cdddr cddddr cdddddddddddr cdddddddddddddddddddr
Geth kudo/nom: ee7c1bba49 | (Jonathan Worthington)++ | src/core.d/await.pm
Improve error reporting of `await` in 6.d.

The work so far actually made things a little worse, in so far as we no longer called Promise.result, and thus did not get an exception with both the original exception location and the location it was awaited. This improves things for the new `await` implementation. Furthermore, it means that all `await`s will get the treatment, not just those that `await` a `Promise`. So, unlike in 6.c, `await` of a
  `Supply` and a `Channel` will play ball and show both locations.		 11:01
ast: f26c4ed873 | (Jonathan Worthington)++ | S17-promise/nonblocking-await.t
Tests for exceptions produced by `await` in 6.d.
 11:06
brokenchicken hm... prefix:<+> does a.Numeric and we can constant fold it, but if we do a.Numeric ourselves then we can't? 11:09
brokenchicken doesn't really follow that one
timotimo yeah
the decision whether or not we constant-fold is based on the "is pure" trait
we can only sanely look that up in lexically scoped things, i.e. subs 11:10
when we get a method call on an object instead, the object is free to decide what it gives us
if for example it needs to do a network request, you'll quite possibly get a different answer during precompilation vs run time
or the method may not exist during compilation, but it will during run time
brokenchicken But all those arguments apply to the a.Numeric call inside the prefix:<+> 11:12
timotimo no
brokenchicken huh
timotimo we make the decision to constant fold +, then we Just Do It
though to be fair, if the Numeric method on that object is shitty, we're fucked 11:13
jnthn Well, if Numeric does something terrible then the folding will still do said terrible thing :)
timotimo the thing is that we can easily look up if a sub is marked pure 11:14
it's hard to look up if a method is marked pure
brokenchicken m: class Foo is Str { method numify { self.Int } }; sub numify (\a) is pure { a.numify }; my $f = Foo.new: :value('10'); for ^1000000 { $ = numify $f }; say now - INIT now 11:16
camelia rakudo-moar ee7c1b: OUTPUT«2.671370607␤»
brokenchicken m: class Foo is Str { method numify { self.Int } }; sub numify (\a) is pure { a.numify }; my $f = Foo.new: :value('10'); for ^1000000 { $ = $f.numify }; say now - INIT now
camelia rakudo-moar ee7c1b: OUTPUT«2.3328330␤»
brokenchicken Seems the `is pure` thing doesn't even work in userland? 11:17
timotimo that's not a constant
your $f there
brokenchicken m: class Foo is Str { method numify { self.Int } }; sub numify (\a) is pure { a.numify }; constant $f = Foo.new: :value('10'); for ^1000000 { $ = $f.numify }; say now - INIT now
camelia rakudo-moar ee7c1b: OUTPUT«2.2604848␤»
brokenchicken m: class Foo is Str { method numify { self.Int } }; sub numify (\a) is pure { a.numify }; constant $f = Foo.new: :value('10'); for ^1000000 { $ = numify $f }; say now - INIT now 11:18
camelia rakudo-moar ee7c1b: OUTPUT«2.31849855␤»
nine brokenchicken: the difference is that the author of prefix:<+> made a promise to the compiler that it will behave. So it's the author who trusts .Numeric
brokenchicken m: sub numify (\a) is pure { a.Numeric }; for ^1000000 { $ = numify '10' }; say now - INIT now 11:19
camelia rakudo-moar ee7c1b: OUTPUT«0.2556820␤»
brokenchicken nine: same can be done with methods.
timotimo brokenchicken: we'd already have to trust the object before we even try to look at the object whether a given method is pure or not 11:20
nine brokenchicken: foo.bar(); foo.bar(); foo.bar(); can call 3 different methods
brokenchicken The trust can be given by the type object with the `is pure` methods published with the meta object during composition. 11:21
m: sub numify (\a) is pure { a.Numeric }; for ^1000000 { $ = '10'.Numeric }; say now - INIT now
camelia rakudo-moar ee7c1b: OUTPUT«11.3806293␤»
brokenchicken m: say 11.38/.255 11:22
camelia rakudo-moar ee7c1b: OUTPUT«44.627451␤»
brokenchicken To get 44x speed increment
brokenchicken &
Geth kudo/nom: a2d69a0638 | (Jonathan Worthington)++ | src/core.d/await.pm
Avoid saying "at: in", which reads oddly.
kudo/nom: f22170f772 | (Jonathan Worthington)++ | src/core.d/await.pm
Improve `react` error reporting in 6.d.

This re-instates getting both the location of the `react` block as well as the location of the original exception. However, the language of the message is far better. In 6.c we report that a `Promise` was broken, thus leaking an implementation detail of `react`. This new erorr clearly states it was a `react` block that was at fault.		 11:27
ast: 26f910e382 | (Jonathan Worthington)++ | S17-supply/syntax-nonblocking-await.t
Test react exception handling in 6.d.
 11:29
dogbert17 jnthn: any 6.c bugfixing on todays agenda? 11:30
jnthn dogbert17: Yeah, I think I've done what I wanted to with await/react for now :) 11:31
timotimo nice.
dogbert17 any bug in particular? 11:33
jnthn Would be good to figure out a way to spectest with 6.d.PREVIEW on any existing thest that doesn't demand 6.c
timotimo i'd like to bump up the priority of fixing inlining of subs with native arguments :(
jnthn timotimo: spesh inlining of them?
timotimo either that, or static-optimizer-inlining of them
on the static optimizer level we currently create loads and loads and loads of nativerefs
*and* don't inline - and i think we don't even spesh-inline those after the fact 11:34
jnthn Hmm 11:35
Seems we do inline things like $a + 1
Where $a is native
timotimo but do we create a nativeref?
jnthn Shouldn't, but lemme check the bytecode 11:36
timotimo we seem to
jnthn The QAST tree says lexicalref but the add_i compilation is meant to be smart enough not to do that :)
timotimo so where did i get the impression that we do a shitty job at this …
jnthn 00022 getlex loc_5_int, lex_Frame_1__int 11:37
00023 const_i64_16 loc_7_int, 1
00024 add_i loc_7_int, loc_5_int, loc_7_int
Obviously not from a simple example like 'my int $x = 41; say $x + 1' :)
dogbert17: Got any particular ones you'd like me to look at? 11:38
dogbert17 jnthn, timotimo: what happens if you run: perl6-valgrind-m -e 'for ^900 { IO::Socket::INET.new( :port($_), :host("127.0.0.1") ); CATCH {next}; say $_~" is open" }' 11:39
I get invalid reads and the code seems to leek memory 11:40
jnthn Let's see...
==28778== Address 0xffeffc484 is on thread 1's stack
==28778== 12964 bytes below stack pointer
dogbert17 .oO
jnthn During GC destruction 11:41
dogbert17 what about definitely lost mem?
jnthn There's that too
But it looks like we're taking a reference to something on the stack when we should be heap allocating
dogbert17 does it 'feel' simple or does it require cheese :-)
I have hidden more detailed info in the last comment here: github.com/MoarVM/MoarVM/issues/234 11:42
the nursery change was obviously not necessary 11:44
jnthn Ah, I think I may see it 11:48
dogbert17 that was quick :) 11:49
timotimo neat 11:50
jnthn Seems we freed too quick but also threw an exception and longjmp'd over some libuv internals 12:03
dogbert17 is it easy or difficult to fix? 12:07
jnthn Think I've got a fix 12:10
Looking at the leaks
Seems I've got 'em. :) 12:12
jnthn spectests 12:13
dogbert17 jnthn++, you made short work of that one :) 12:14
jnthn Except t/spec/S32-io/socket-accept-and-working-threads.t now seems to explode 12:18
dogbert17 flapping? 12:20
jnthn No, I actually introduced a double-free. Obvious in hindsight 12:21
Probably need lunch :)
dogbert17 lunch++
jnthn Valgrind seems happier now
And looking good still on the original code we set out to fix 12:25
Anther spectest while I have lunch :)
bbiab
dogbert17 follows jnthn's lunch example 12:32
travis-ci Rakudo build errored. Jonathan Worthington 'Avoid saying "at: in", which reads oddly.' 12:52
travis-ci.org/rakudo/rakudo/builds/196909943 github.com/rakudo/rakudo/compare/e...d69a06389b
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
timotimo Cannot add PPA: 'ppa:ubuntu-toolchain-r/test'. 12:54
Please check that the PPA name or format is correct.
jnthn back 13:09
o.O
Pretty sure that's not my fault :P 13:10
yay, clean spectest
dogbert17: Pushed 3 commits that sort it out. Might you be able to verify it's gone for you and/or add a test case? :) 13:13
brokenchicken That error happened in the past. I think it's something to do with travis's "trusty beta" thing 13:19
dogbert17 jnthn: cool, I'll try it out 13:20
will try to figure out a test case 13:21
cool, the 'socket(PF_NETLINK, SOCK_RAW, 0) = -1 EMFILE (Too many open files)' is also gone 13:29
brokenchicken, could jnthn's latest fixes be of interest to your bots by any chance? 13:30
jnthn Also, do the bots still leak after the stuff I merged just after the Jan relesae? :) 13:32
brokenchicken shrugs 13:35
not tested anything
m: say 'rakudo.moar' eq 'rakudo.moar' 13:42
camelia rakudo-moar f22170: OUTPUT«True␤»
dogbert17 fixes a recently discovered ENOCOFFEE error 13:45
jnthn: one question, if I change the loop to ^3900 valgrind spews out a bunch of '==29436== Warning: invalid file descriptor 1031 in syscall socket()'. Is it something to worry about? 13:53
jnthn Sounds a bit odd 13:59
Nice, I've got valgrind --leak-check=full on perl6-valgrind-m -e '' to show no leaks :)
That'll make things a bit less noisy when we're leak hunting in the future :)
And give us an every so slightly smaller memory footprint 14:00
dogbert17 perhaps the fact that I had set the Nursery to 16k had something to do with it
very nice 14:01
Geth kudo/nom: 43666039ae | (Zoffix Znet)++ | 2 files
Update t/harness* help texts to match accepted options

Fixes RT#130659: rt.perl.org/Public/Bug/Display.html?id=130659
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130659
Geth kudo/nom: f94cb21ef5 | (Zoffix Znet)++ | t/harness5
Fix VM conditional

  - Remove useless ternary that was accidentally left over[^1]
   when parrot option was tossed.
  - Use $moar instead of $jvm to check against, to match another
   similar check earlier in the file.
  [1] github.com/rakudo/rakudo/commit/c8...0d59fb318e
  [2] github.com/rakudo/rakudo/blob/f221...rness5#L39
dogbert17 it seems to have been the small nursery which caused the warnings
jnthn They're still a bit odd, though... 14:05
dogbert17 it's always FD 1031 14:07
jnthn: if you're on the hunt for memory leaks t/spec/S17-procasync/no-runaway-file-limit.t is a good example 14:15
definitely lost: 147,513 bytes in 1,192 blocks 14:16
jnthn t/spec/S17-procasync/no-runaway-file-limit.t 14:17
oops
:)
jnthn takes a look
heh, this is none too fast under valgrind :) 14:19
dogbert17 no, takes a few minutes
did your latest commits mean the end of the --full-cleanup bug? 14:24
jnthn No 14:35
They mean that perl6-valgrind-m -e '' with --leak-check=full in valgrind will report no lost memory 14:36
(Well, a few things lost due to DLL handles, but you have to --show-leak-kinds=all to get those) 14:37
The --full-cleanup bug in multi-threaded programs is thanks to it trying to clean up mutexes which are still held
Which is a much thornier problem
dogbert17 thx for the explanation, I usually make a copy of perl6-valgrind-m because it has that option enabled, which has tripped me up a few times 14:39
there are no many spectests which leaks memory, one is t/spec/S17-procasync/no-runaway-file-limit.t the other is t/spec/S17-lowlevel/lock.t 14:42
brokenchicken m: say do for ^3 { $/ = $++; $/ } 14:43
camelia rakudo-moar f94cb2: OUTPUT«(2 2 2)␤»
brokenchicken This ain't a bug, is it? Or do blocks supposed to get fresh $/ or something ?
jnthn No, they aren't 14:45
So no bug
Hm, I'm suspecting $!void_context in the optimizer isn't entirely accurate... 14:46
brokenchicken Hm. This leads to very interesting interactions that by extension aren't buggy: 14:47
m: say <a1 a2 a3>.map({S/huh//})
camelia rakudo-moar f94cb2: OUTPUT«(a1 a2 a3)␤»
brokenchicken m: say eager <a1 a2 a3>.map({S/huh//})
camelia rakudo-moar f94cb2: OUTPUT«(a3 a3 a3)␤»
brokenchicken The first ones are different because they get printed each before the next iteration updates $/; while the version that returns stuff from $!reified has all the items updated to last value of $/ 14:48
Makes perfect sense once you understand what's going on, but that's quite a trap :P 14:52
m: my $stuff = <a1 a2 a3>.map({S/huh//}); say $stuff[^1]; say $stuff[^2]; say $stuff[^3] 14:53
camelia rakudo-moar f94cb2: OUTPUT«(a1)␤(a2 a2)␤(a3 a3 a3)␤»
brokenchicken ehehehe
jnthn o.O 14:55
brokenchicken :D 14:56
m: say eager <a1 a2 a3>.map({S/huh//});
camelia rakudo-moar f94cb2: OUTPUT«(a3 a3 a3)␤»
brokenchicken m: say eager <a1 a2 a3>.map({S/huh//.Str});
camelia rakudo-moar f94cb2: OUTPUT«(a1 a2 a3)␤»
brokenchicken :) 14:57
jnthn Darn, two attempts at fixing rt.perl.org/Ticket/Display.html?id=130615 that don't work :/ 15:01
hah, it makes 2 todo tests pass and fails one 15:04
brokenchicken :)
jnthn m: sub a($b) { $b = 1 }; a(2); 15:06
camelia rakudo-moar f94cb2: OUTPUT«Cannot assign to a readonly variable ($b) or a value␤ in sub a at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
jnthn huh, the error there changed to "Cannot assign to an immutable value"
bah 15:08
It's because we nail an inline that we didn't before
Which in turn does away with some info
This kinda reminds me that I was going to pull inlining of anything not natively typed out of the optimizer anyway... 15:09
The static one, that is
Because spesh can inline better and preserve semantics better 15:10
And then we'd also keep a bunch less info around in precomp files.
And do a bunch less analysis.
lizmat sounds like a plan :-) 15:12
Geth kudo/optimizer-tweaks: 489bcec7b2 | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
Generalize sink branch optimize logic.

Given:
  - QAST::Want
   <some node>
   v
   QAST::Op p6sink
... (5 more lines)		 15:16
dogbert17 tries to build the docs on his 32 bit vm, will it work or will it crash after having allocated 2+ gigs ...
jnthn That's the RT #130615 fix, modulo the regression that's finally going to make me sort out the inline situation :) 15:17
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130615
dogbert17 Writing type document for Num ... 15:23
MoarVM panic: Memory allocation failed; could not allocate 2013836 bytes
:(
jnthn wonders where it all goes... 15:26
dogbert17 could it still be rt.perl.org/Public/Bug/Display.html?id=130494 15:28
lizmat m: say $*PERL; { use v6.d.PREVIEW; say $*PERL } # is this a bug ?
camelia rakudo-moar f94cb2: OUTPUT«Perl 6 (6.d)␤Perl 6 (6.d)␤»
lizmat jnthn: ^^ would have expected to see "Perl 6 (6.c)␤Perl 6 (6.d)␤" 15:30
brokenchicken IIRC the use v6.* has to occur no later than how `unit...` can occur.
So I'd expect the above to throw with "too late to switch versions" 15:31
m: say $*PERL; { unit class Meows; say $*PERL }
camelia rakudo-moar f94cb2: OUTPUT«5===SORRY!5=== Error while compiling <tmp>␤A unit-scoped class definition is not allowed in a subscope;␤Please use the block form.␤at <tmp>:1␤------> 3say $*PERL; { unit class Meows;7⏏5 say $*PERL }␤»
brokenchicken m: say $*PERL; {say $*PERL }; unit class Meows; 15:32
camelia rakudo-moar f94cb2: OUTPUT«Perl 6 (6.c)␤Perl 6 (6.c)␤»
brokenchicken oh. OK. :)
lizmat brokenchicken: so from this I gather that a "use v6.x" should not be allowed in *any* subscope either ?
brokenchicken lizmat: as I understand it, yeah. Because setting it the outter scope (or something) it doesn't really make sense for there being two settings at the same time 15:34
lizmat: jnthn's explantion: irclog.perlgeek.de/perl6-dev/2017-...i_13999497 and irclog.perlgeek.de/perl6-dev/2017-...i_13999797 15:35
jnthn Yes, but is that we acept it :) 15:37
*the bug 15:39
lizmat hmmm.. I guess the use handling code is already special cased for v6.x anyways 15:42
jnthn aye
lizmat so that shouldn't interfere with lexically using a module and its exports
m: { use Test }; ok 1 15:43
camelia rakudo-moar f94cb2: OUTPUT«5===SORRY!5=== Error while compiling <tmp>␤Undeclared routine:␤ ok used at line 1␤␤»
jnthn Only end up saving us 48.5KB off CORE.setting size 15:45
(Only generating inline_info for natives, that is)
Bit of a time saving too, though
brokenchicken Wonder what's the point of S/// returning $/ instead of just the string 15:48
Especially since it whines when you use it without getting the result;
m: "foo" ~~ S:2nd/o/x/; say $/ 15:49
camelia rakudo-moar f94cb2: OUTPUT«Potential difficulties:␤ Smartmatch with S/// is not useful. You can use given instead: S/// given $foo␤ at <tmp>:1␤ ------> 3"foo" ~~ 7⏏5S:2nd/o/x/; say $/␤fox␤»
brokenchicken Feels like original design didn't mean for that warning and people were expected to use $/ to get the result?
lizmat m: class A { has Int $.a = 42 }; my $a = A.new; for ^100000 { $a.a }; say now - INIT now 15:50
camelia rakudo-moar f94cb2: OUTPUT«0.07085673␤»
lizmat m: class A { has int $.a = 42 }; my $a = A.new; for ^100000 { $a.a }; say now - INIT now 15:51
camelia rakudo-moar f94cb2: OUTPUT«0.0810552␤»
lizmat m: say 0.0810552 / 0.07085673 # native int attribute slower
camelia rakudo-moar f94cb2: OUTPUT«1.14393086␤»
lizmat was this already ticketed ^^^ ?
jnthn It's having to box it every time 15:54
It's nothing we can really solve in Rakudo.
Once spesh gets good enough, that benchmark will also measure nothing :) 15:55
Because it'll inline the method then see it's all pure and throw it all away :)
brokenchicken \o/ 15:56
jnthn At the moment we inline but we don't re-analyze the inline in its new context. 15:57
Geth kudo/optimizer-tweaks: 8cea57f187 | (Jonathan Worthington)++ | src/Perl6/Actions.nqp
Only generate static inline info when native args.

Some years back, when Rakudo's optimizer was implemented, we didn't run on a VM that could do inlining. This is no longer the case, and it's much easier to do the analysis for correct semantic preservation in a VM and get it consistently right than it is in Rakudo. A VM can also only expend the effort on hot code. So, from now on we will only ... (7 more lines)		 16:00
lizmat ok, just wondering :-)
dogbert17 jnthn: github.com/MoarVM/MoarVM/issues/234 looks fixed to me, what is not entirely obvious is how to test that 16:05
should I run the port scanner as a test? 16:06