BenGoldberg When the user types 'perl6', we read the serialized setting from disk, then deserialize that data into objects. Then we compile/run the user's code. 00:00
Zoffix That's my understanding of the process too, with the addition that we lazily deserialize the setting. We don't load it all at the start 00:01
BenGoldberg What if, when the setting is loaded to be serialized, we change how memory is allocated; specifically, use mmap, but NOT anonymous -- all allocations are file backed -- and skip serialization completely. When the user types 'perl6', we use mmap to load that same file (using MAP_PRIVATE and MAP_FIXED flags), and skip *deseralization* 00:03
You can call me mad, if you like, I won't be offended ;) 00:05
Zoffix That flew right over my head, so it won't be me calling you mad :) 00:07
BenGoldberg mmap is one of the (main?) ways for a program to get memory from the operating system. 00:08
geekosaur made sense to me, but beware of things like portability and things not being mappable to the same addresses (so all addresses in the mapped file end up wrong)
also be aware that major distributions plan to move to ASLR in the future and then this won't work at all 00:09
timo many things in the serialized blob are also "mutable", though things like "augment" 00:12
there's a mechanism called "repossession" where an object derived by a different comp unit will essentially "own" the object and include its changes
not sure what reasons would speak against just mmapping stuff directly into memory for the core setting apart from what was mentioned
timo goes tob ed
BenGoldberg When the MAP_FIXED flag is present, ASLR is not going to mess with that chunk of memory. The only issue to worry about here is that if some mysterious chunk of code mapping stuff into the byte range where we want to go, before we get a chance to do so ourselves. 00:13
geekosaur timo, in that case I think you can map it copy-on-write and then you get a baseline and can modify it which will make it a local image
BenGoldberg By mysterious, I mean a debugger or antivirus ;)
MAP_PRIVATE would make it copy-on-right, afaik. 00:14
geekosaur BenGoldberg, if it references e.g. libc, libc may be in a different location
BenGoldberg Oh, that could be a problem.
Hmm...
geekosaur or libuv
BenGoldberg Or any library which is dynamically loaded before the setting is loaded. 00:15
s/copy-on-right/copy-on-write/ ;)
I suppose that fixing up pointers is inevitable with this approach :( But it still might be faster than deserialization. 00:17
What if, after the setting is loaded (when we're creating the data), and before exiting, we scan through the entire chunk of memory, looking for pointers into our *currently loaded* libc, libuv, etc; For each such pointer we find, we mutate the pointer so it's an integer relative to the base of libc, libuv, etc., and record it into a separate file. 00:22
japhb BenGoldberg: It's sounding suspiciously like time to review the state of the art for linkers and loaders 00:23
geekosaur ^
BenGoldberg When the user types 'perl6', we mmap the main file, then read through the second file, and transform all of those relative integers into proper pointers to functions in our new process's libc, libuv, etc ;)
geekosaur this is more or less dlopen(). you'd need to arrange a relocations table so it can update all such when it attaches it, then save it as a shared object 00:24
but! I do not know how portable this will be. remember you have more than just Linux to deal with
Windows and OS X have their own shared objects and relocations (and rules associated with both) 00:25
BenGoldberg Hmm... I guess it *is* a mad idea... I don't know enough to suggest any sort of three-OS solution. 00:32
geekosaur libbfd, in theory 00:33
in practice, the edge cases will likely drive you nuts
BenGoldberg How much stuff in the setting contains pointers to library functions, anyway? 00:35
BenGoldberg had previously thought all of those were in moarvm, actually. 00:36
Geth roast: skids++ created pull request #317:
RT#126540 RT#130773 RT#130502 RT#131846 RT#131409 RT#126984 tests		 02:11
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126540
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130773
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130502
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131846
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131409
Link: rt.perl.org/rt3/Public/Bug/Display...?id=126984
Geth roast: 693bff1c37 | skids++ | S02-types/whatever.t
RT#126540 RT#130773 RT#130502 RT#131846 RT#131409 RT#126984 tests

  ...fudged, but for RT#126540
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126540
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130773
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130502
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131846
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131409
Geth roast: 4b2fef409c | skids++ (committed using GitHub Web editor) | S02-types/whatever.t
Merge pull request #317 from skids/rt126540

RT#126540 RT#130773 RT#130502 RT#131846 RT#131409 RT#126984 tests
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126984
Link: rt.perl.org/rt3/Public/Bug/Display...?id=126540
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126540
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130773
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130502
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131846
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131409
Link: rt.perl.org/rt3/Public/Bug/Display...?id=126984
[Coke] GAH 02:27
Geth roast: skids++ created pull request #318:
Fix RT number... RT#131502 not 130502		 02:28
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131502
roast: 9ed6c9cec6 | skids++ | S02-types/whatever.t
Fix RT number... RT#131502 not 130502
roast: 25d8538c1a | skids++ (committed using GitHub Web editor) | S02-types/whatever.t
Merge pull request #318 from skids/rt126540

Fix RT number... RT#131502 not 130502
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131502
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131502
skids yeah synopsebot6 could use a "just did that one" cache. Also maybe some "don't interrupt pastes/bots" logic. 02:34
[Tux] This is Rakudo version 2017.08-134-g627de7833 built on MoarVM version 2017.08.1-165-gf042d9eb 06:17
csv-ip5xs 1.352 - 1.397
test 9.766 - 10.129
test-t 3.564 - 3.598
csv-parser 11.248 - 11.292
nine lizmat: yes, it does 06:51
yoleaux 05:32Z <AlexDaniel> nine: FWIW RT #132088
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132088
lizmat Files=1223, Tests=67791, 289 wallclock secs (11.08 usr 4.53 sys + 1951.17 cusr 206.48 csys = 2173.26 CPU) 08:44
jnthn morning o/ 09:09
Geth rakudo/nom: 4e3f0fcad7 | (Jonathan Worthington)++ | tools/build/Makefile-Moar.in
Fix non-installed gdb/valgrind runners

The paths were in the wrong order, meaning a ./perl6-gdb-m or
  ./perl6-valgrind-m before `make install` would not work		 09:45
rakudo/nom: b30ac08a13 | (Jonathan Worthington)++ | src/core/Channel.pm
Fix race in Channel awaiter

Fixes an occasional crash with "cannot call close on a null object" in S17-promise/nonblocking-await.t		 09:49
Skarsnik releasable6, status 09:59
releasable6 Skarsnik, Next release in 1 day and ā‰ˆ9 hours. 2 blockers. 122 out of 136 commits logged
Skarsnik, Details: gist.github.com/9e928ad437f5aa12f7...dba124bfcb
Geth nqp: c20511799d | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump MOAR_REVISION for threadlockcount op
 10:54
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...1-gcf95892
507a94d678 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...1-gcf95892
b12ea726f3 | (Jonathan Worthington)++ | 3 files
nqp: f3b0f0c04a | (Jonathan Worthington)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
Corret a thinko in JVM threadlockcount
 11:20
rakudo/nom: 1818de980f | (Timo Paulssen)++ | lib/NativeCall.pm6
nativecall: don't try to compile sigs with optional parameters

it's currently NYI, and default values would just be ignored.		 11:50
rakudo/nom: 69dae1f3be | (Elizabeth Mattijsen)++ | src/core/Enumeration.pm
Give Enumeration its own .WHICH

So that we can distinguish between enums that happen to have the same value.		 12:29
Zoffix m: More.^roles.say 12:30
camelia No such method 'roles' for invocant of type 'Perl6::Metamodel::EnumHOW'. Did you mean any of these?
does
roll

in block <unit> at <tmp> line 1
Zoffix No, I didn't
bah, lizmat++ is way faster than me :)
Zoffix mops up by writing the tests 12:32
lizmat Zoffix++ 12:33
nine timo: oooh, thanks for the nativecall fix!
timo no prob :) 12:34
may also want to check if things like named parameter aliases and such are problematic, too
nine But native subs cannot have named parameters anyway? 12:35
timo oh
yeah, that's true
m: use NativeCall; sub test($a, :$b) is native(Str) { * } 12:36
camelia Potential difficulties:
In 'test' routine declaration - Not an accepted NativeCall type for parameter [1] $a : Any
--> For Numerical type, use the appropriate int32/int64/num64...
at <tmp>:1
------> 3; sub test($a, :$b) is nativā€¦
timo m: use NativeCall; sub test(int8 $a, int8 :$b) is native(Str) { * }
camelia ( no output )
timo look, they can! :P
nine And they work exactly as much as with the optimization ;) 12:39
With that taken care of, I can return to turning nativecallinvokejit into a real invoke op. 12:40
Though I may need some time to fully recover from Cassini's mission end :)
Geth rakudo/nom: cc64a75842 | (Elizabeth Mattijsen)++ | src/core/Enumeration.pm
Give enums an iterator

  - e.g. "for Order" will show Less/Same/More
  - e.g. "for Less" will still just show Less		 12:43
lizmat this is spectest clean, although maybe a bit too much magic
afk for a few hours&
Zoffix m: for Bool { .say } 12:44
camelia (Bool)
Zoffix I guess now that'll give True, False 12:45
timo hopefully False, True :) 12:46
Zoffix Well, yeah 12:47
But the question is whether that's desired :) 12:48
m: my Bool $x; say $x.map: *.^name
camelia (Bool)
timo oh, you mean the enum type object now being iterable or so?
hm, it's not marked iterable, though? 12:49
masak lizmat: re "maybe a bit too much magic" -- `for Order` strikes me as maybe one word over-Huffmanized 12:51
timo at least our post-GLR semantics will prevent a change like this from causing e.g. a list [Bool, Int, Order] to suddenly become more elements 12:52
Zoffix timo: it still iterates
masak (in that as an uninitiated reader, even when I'm aware it's an Enum, I wouldn't be 100% sure what `for Order` did -- but something like `for Order.enums` makes it clearer)
Zoffix m: for Order { .say }
camelia Less
Same
More
Zoffix m: for Bool { .say }
camelia (Bool)
Zoffix Looks like Bool has its own iter too
timo is Bool now fully doing the Enumeration role? 12:53
Zoffix m: my Order $x; say $x.map: *.pair.key
camelia (Less Same More)
Zoffix timo: ah, I guess that's why it don't got that problem
Zoffix votes too-magical on that last eval
timo "problem"? i thought that was the feature ā€¦ 12:54
Zoffix Non-Iterable type objects producing numerous values when iterated over are a problem in my book :/ 12:56
timo yeah, i find that quite a bit surprising
m: for (Bool, Order, Int) -> $x { .perl.say }
camelia Any
Any
Any
Zoffix m: my PromiseStatus $status; for $status { .say }
camelia (PromiseStatus)
timo m: for (Bool, Order, Int) -> $x { $x.perl.say }
camelia Bool
Order
Int
Zoffix m: my PromiseStatus $status; for @$status { .say }
camelia (PromiseStatus)
Zoffix m: my PromiseStatus $status; for PromiseStatus { .say }
camelia Planned
Kept
Broken
Zoffix So it only works that way when typed literally? 12:57
masak ah, yes. "it's the type object" is a good description of what feels un-easy about it being iterable... :)
Geth rakudo/nom: 2ad51a0f5b | (Zoffix Znet)++ | src/core/Enumeration.pm
Constrain Enumeration.succ/.pred to instances

pre- github.com/rakudo/rakudo/pull/1156 type objects would just die with X::Parameter::InvalidConcreteness but now they return weird results.
Constrain to instances, to restore the ::InvalidConcreteness throwage we had before.		 13:07
Zoffix ZOFVM: Files=1273, Tests=144768, 138 wallclock secs (15.74 usr 2.24 sys + 2827.19 cusr 223.59 csys = 3068.76 CPU)
m: enum Foo (a => 1, b => 1); say a.WHICH; say b.WHICH; say a === b 13:28
camelia Foo|a|Int|1
Foo|b|Int|1
True
Zoffix (writing tests)++
s: &infix:<===>, \(Kept, Broken) 13:29
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2ad5...nt.pm#L329
Zoffix fixes 13:33
with multi infix:<===> (Enumeration:D \a, Enumeration:D \b) { a.WHICH === b.WHICH } 13:34
Skarsnik What this supposed to do? x) 13:35
Zoffix make === on enums work 13:36
timo without trying, i landed at about the same amount of time tinita suggested for the yaml project (in my grant application)
Skarsnik m: enum Foo (A, B, C); enum Bar (C, D, E); say Foo === Bar; 13:37
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared names:
A used at line 1
B used at line 1
C used at line 1
Skarsnik m: enum Foo (A => 1, B => 2, C => 3); enum Bar (C => 1, D => 2, E => 3); say Foo === Bar;
camelia Potential difficulties:
Redeclaration of symbol 'C'
at <tmp>:1
------> 3=> 3); enum Bar (C => 1, D => 2, E => 3)7ā5; say Foo === Bar;
False
timo i'm already estimating ~171h but i haven't put any estimates in for writing the user-facing documentation about using and interpreting the profilers :|
Skarsnik m: enum Foo (A => 1, B => 2, C => 3); enum Bar (F => 1, D => 2, E => 3); say Foo === Bar; 13:38
camelia False
Skarsnik I don't even get what === supposed to mean between 2 enumeration x)
Zoffix Skarsnik: it's object identity test
perlpilot timo: What is this yaml project? 13:39
Zoffix m: enum Foo (a => 1, b => 1, c => 2); say a === b
camelia True
Zoffix Skarsnik: ^ that's supposed to say False
timo news.perlfoundation.org/2017/08/gra...amlpp.html perlpilot
perlpilot ah. cool
Skarsnik dunno a is an element of en enumeration in this, not an enumeration 13:40
timo docs.google.com/document/d/102h_Nl...sp=sharing - i need some guidance
Zoffix Skarsnik: call it whatever you want. It's still just an object :)
jnthn back 13:41
Geth rakudo: book++ created pull request #1157:
Avoid mistaking two enumeration elements with the same value
rakudo/nom: 8d442a5232 | (Philippe Bruhat (BooK))++ | src/core/Enumeration.pm
Avoid mistaking two enumeration elements with the same value

This is a fix for this issue:
   enum Animal (Cat => 0, Dog => 0, Human => 42);
   say Dog.succ; # OUTPUT: Ā«Dogā¤Ā»
With this change, the behaviour becomes:
   say Dog.succ; # OUTPUT: Ā«Humanā¤Ā»		 13:42
Skarsnik m: enum Foo (A => 1, B => 2, C => 3); enum Bar (F => 1, D => 2, E => 3); say A.WHAT;
camelia (Foo)
rakudo/nom: 6601561469 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Enumeration.pm
Merge pull request #1157 from book/book/enum-pred-succ

Avoid mistaking two enumeration elements with the same value
Zoffix ZOFFLOP: t/spec/S17-procasync/kill.t t/spec/S11-modules/nested.t t/spec/S17-supply/supplier-preserving.t 13:43
jnthn I think a type object should always iterate as if it's a list containing one element, which is the type object itself 13:44
If we need a method in the Enumerator role that gets a list of the values without having to do .^something then we I guess could 13:45
Geth rakudo/nom: 8d938461a9 | (Zoffix Znet)++ | src/core/Enumeration.pm
Fix Enumeration:D === Enumeration:D

An earlier fix[^1] to .WHICH fixed the method, but the issue with the operator remained, because there exists an Int:D === Int:D candidate that simply unboxes the Ints.
Fix by adding Enumeration:D === Enumeration:D candidate for infix:<===>
  [1] github.com/rakudo/rakudo/commit/69...b3223e2f62
Zoffix (I realize the PR I merged was unnessesary since === now got fixed, but I plan to optimize the methods a bit anyway and didn't want to create more confusion to the PR author, since this morning I suggested the nqp::eqaddr instead of fixing the ====) 13:47
Geth roast: dfbbd70d46 | (Zoffix Znet)++ | S12-enums/basic.t
Add tests for Enumeration.pred/.succ and ===

  - methods fixed in [^1] and [^2]
  - operator fixed in [^3] and [^4]
  [1] github.com/rakudo/rakudo/pull/1156
  [2] github.com/rakudo/rakudo/pull/1157
  [3] github.com/rakudo/rakudo/commit/69dae1f3be
  [4] github.com/rakudo/rakudo/commit/8d938461a9		 13:50
Zoffix timo: briefly skimming it, looks good to me. What sort of guidance you need? 13:52
stmuk is there any documentation about the difference between roast master and 6.c-errata? 13:58
Zoffix Oh god. I merged a boo-boo :P
oh *phew* no, I didn't :) Just a flaw in my code here :P 13:59
stmuk: what sort of differences? 14:00
stmuk I mean high level docs explaining why the two branches exist 14:02
Zoffix README/CONTRIBUTING don't mention errata. But well, the differences can be summed up in one sentence: 6.c-errata is a released language version we don't change other than to fix errors in tests (the "errata"); master is the unreleased work-in-progress that will become the next language version; though its current state is not prescriptive of the next language version's behaviour: all the new additions will
be reviewed for inclusion into the release
ā€¦ a long, run-on, but still one, sentence :P
stmuk ok I may stick that (or something similar) in the FAQ together with "why does the test run complain about missing files" 14:04
Zoffix stmuk: oh. I was meant to take care of that actuallyā€¦ back in like February
And will actually take care of it during prep for 6.d stuff, so perhaps FAQ entry isn't needed. 14:05
Actually, *will* take care of it before next R* release
huggable: star
huggable Zoffix, Estimated Rakudo Star releases for 2017: .01, .04, .07 & .10
Zoffix .in 15d make separate t/spectest.data for each language version, bruh 14:06
yoleaux Zoffix: I'll remind you on 30 Sep 2017 14:06Z
Zoffix .in 28d make separate t/spectest.data for each language version, bruh
yoleaux Zoffix: I'll remind you on 13 Oct 2017 14:06Z
stmuk ++Zoffix 14:07
so 2017.10 should pass against 6.c-errata and a new 6.d-errata? 14:08
timo Zoffix: i'm not happy with the hour numbers in the schedule
Zoffix timo: so remove them and ask for the amount of money you think the entire work is worth, instead of per-hour 14:09
timo how the hell am i supposed to come up with a sensible number then? :D 14:10
Zoffix timo: well, use the numbers you got, but don't publish them.
Zoffix also lives by the "multiply the number of hours you think it'll take you by $n" rule
stmuk Fibonacci sequence story points! 14:11
Zoffix 'cause it always seems to take longer for me than what I estimate it to be :)
timo i think most people experience that
the yaml grant has a bit less than my hour amount and requested 2.5k usd 14:12
Geth rakudo/nom: f26d1e24f9 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Don't attempt non-blocking await if holding locks

Locks are tied to a particular OS thread. Non-blocking await may move code between OS threads. Therefore, if a lock is being held, then we fall back on a real blocking await, so things work.
At present, various bits of the Supply internals rely on locks; this thus fixes a lot of things that are broken, but also means that we can't yet get all the benefit we'd like from non-blocking await. Upcoming changes to various affected aspects of supplies will fix this issue.
timo i think i'd request more than that, but my impostor syndrome is asking me to STFU :)
roast: bd141e2f9d | (Jonathan Worthington)++ | S17-promise/nonblocking-await.t
Add test for RT #130692

Plus a test that more precisely covers the underlying issue		 14:14
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=130692
stmuk is 6.d-errata going to be a modified full copy of roast master or a smaller number of files like a delta? 14:16
timo because why would anybody give me 3k usd?
Zoffix timo: I'd still be +1 if the proposal listed 3k 14:17
stmuk: I'd say full copy. I imagine at some point will end-of-life 6.c and 6.d will be the oldest supported release
s/will/we'll/;l 14:18
jnthn timo: So that you'll build nice things :)
timo anyway, i can *totally* make use of more monies after the bits outlined in my schedule 14:19
not just because documentation can eat any amount of time you're willing to give it
dogbert17_ Stage mast : No registered operation handler for 'threadlockcount' wazzup with that 14:27
timo dogbert17_: needs a newer nqp 14:28
Geth rakudo/nom: a4ce97cacb | (Jonathan Worthington)++ | tools/build/NQP_REVISION
Bump NQP_REVISION for threadlockcount op
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....1-gf3b0f0c
a137c0de12 | (Jonathan Worthington)++ | 2 files
stmuk how is 6.d.2 (for example) handled in roast? 14:29
dogbert17_ timo: looks like a new version just showed up, jnthn++
timo well, the version was already there, but now configure will force you to get it :) 14:30
jnthn Yeah, forgot that
timo well, i'm one of those "i grab master from moar and nqp all the time" folks
dogbert17_ configuring ...
stmuk grrr I suppose I should convert Zoffix's "behaviour" into "behavior" even although I don't really want to :/ 14:31
jnthn Why change it to the wrong spelling? ;-) 14:32
timo wroung 14:33
Zoffix :D 14:34
perlpilot stmuk: I wouldn't change it.
roast: e5c50ae935 | (Jonathan Worthington)++ | S17-promise/nonblocking-await.t
Test to cover RT #132091
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132091
jnthn How convenient for that to be discovered on the day I'm working on non-blocking await anyway :) 14:51
timo <3
i'm not sure why there's two of them 14:52
jnthn Blocking awaiter, thread pool awaiter
Pondering if we can factor out some of the commonalities though
timo ah
Zoffix notices a drawback of learning C 14:59
nqp code looks a lot less messy now
Geth roast: 82a1e10ad8 | (Jonathan Worthington)++ | S17-supply/syntax.t
Test to cover RT #126842
 15:03
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126842
Geth rakudo/nom: 55aa7f28d3 | (Zoffix Znet)++ | src/core/Enumeration.pm
Make Enumeration.pred 8.4x faster / .succ 6x faster

Closes RT#132093: rt.perl.org/Ticket/Display.html?id=132093		 15:04
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132093
jnthn Zoffix: Yeah, that's a lot of why we try to write what we can in Perl 6 / NQP rather than C :)
timo NQP does all our MVMROOT for us, too :)
Zoffix I meant it's harder to tell for me now if that ^ commit looks a bit over the top with all the nqp stuff. 15:06
:)
Dunno, didn't think the perf was a real concern with these methods, but the ticket was created, so I guess it was.
jnthn m: react whenever Supply.interval: 1 { .say }; sleep 5
timo i wonder if someone would be down to write a slang for just in the setting that lets us write nqp-equivalent code more prettily
Zoffix & for the weekend
\o 15:07
timo have a good one, Zoffix
camelia (timeout)0
jnthn oh duh, it was react, so no need for sleep ;)
m: react whenever Supply.interval: 1 { .say; done if $++ = 5 };
camelia 0
Tried to get the result of a broken Promise
in block <unit> at <tmp> line 1

Original exception:
Cannot modify an immutable Int (0)
in block <unit> at <tmp> line 1
jnthn m: react whenever Supply.interval: 1 { .say; done if $++ == 5 };
camelia 0
1
2
3
4
5
nine Why does NativeCall box the return value in the VM instead of letting the high level code handle that? 15:13
timo probably because the nativecall op is defined to return into an object register
you could probably build multiple, one per return primitive type 15:14
jnthn Because an op can only have one register result type
nine Like the invoke_* ops?
timo yup
jnthn But we could do something like invoke_[osin] yes
nine Would save me from figuring out a way to pass the return value type to the op. At the cost of even more refactoring... 15:15
jnthn Yeah, but think of the potential extra performance! ;) 15:16
nine I know. It really feels like the right way to do this
It's just hard, because this is a "change everything at the same time" kinda refactor. I dread the debugging... 15:17
Geth roast: 7c39b04256 | (Zoffix Znet)++ (committed using GitHub Web editor) | S12-enums/basic.t
Fix typo in test description
 15:18
jnthn m: use Test; my $i = 0; react whenever Supply.from-list(1..5) { $i += $_ }; is $i, 15
camelia ok 1 -
jnthn c: 2015.12 use Test; my $i = 0; react whenever Supply.from-list(1..5) { $i += $_ }; is $i, 15 15:19
committable6 jnthn, Ā¦2015.12: Ā«Method 'phasers' not found for invocant of class 'Code'ā¤ in block <unit> at /tmp/QysrlZ9VPn line 1ā¤ Ā«exit code = 1Ā»Ā»
jnthn yay
Geth roast: 4d64c02e58 | (Jonathan Worthington)++ | S17-supply/syntax.t
Test to cover RT #128717
 15:21
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=128717
lizmat .tell Zoffix re 8d938461 , I think the nqp::eqaddr is enough. Or am I missing something? 17:08
yoleaux lizmat: I'll pass your message to Zoffix.
Zoffix . 17:10
yoleaux 17:08Z <lizmat> Zoffix: re 8d938461 , I think the nqp::eqaddr is enough. Or am I missing something?
Zoffix lizmat: I think so too, but I wasn't 100% sure :)
OK, I'll change it now :)
lizmat Zoffix: also, I would bind $values to $!reified directly, so you can use the much cheaper nqp::elems on $values, than the relatively expensive .elems 17:16
a gettatr is really cheap
Zoffix lizmat: thanks. I'll change that too. I was just unsure whether .^enum_list_values would always be guaranteed to be fully reified (and .elems reifies) 17:17
lizmat yes, it's guaranteed to be reified
Zoffix Sweet
lizmat it's an nqp::list underneath
timo could also be an IterationBuffer without much more cost 17:18
lizmat the whole gettatr stuff is only needed because rakudo auto-HLLizes the nqp::list on the return from ^enum_value_list
timo: IterationBuffer is a HLL concept
that doesn't exist insude EnumHOW afaik 17:19
Zoffix m: use nqp; class Foo {}; my $x = Foo; sub x (\a, \b) { dd nqp::eqaddr(a,b) }(Foo, $x)
camelia 0
Zoffix m: use nqp; class Foo {}; my $x = Foo; sub x (\a, \b) { dd nqp::eqaddr(nqp::decont(a),nqp::decont(b)) }(Foo, $x)
camelia 1
timo oh, right, not early enough
Zoffix Should we stick deconts over here? github.com/rakudo/rakudo/blob/2ad5...ny.pm#L485
lizmat looks like it's needed for the eqaddr 17:20
so yes
Zoffix++ # good catch 17:21
Zoffix cool, I'll add 'em
lizmat I wonder if we should be able to store the index of an Enum in the Enum itself 17:35
so we could bypass the whole O(n) discussion
it would only need to be a native int 17:36
assuming we won't see more than 2**32 elements in an enum 17:37
Zoffix ZOFVM: Files=1273, Tests=144780, 140 wallclock secs (15.82 usr 2.55 sys + 2845.90 cusr 237.88 csys = 3102.15 CPU) 17:38
Geth rakudo/nom: 43e41ec683 | (Zoffix Znet)++ | src/core/Enumeration.pm
Apply lizmat++'s improvements

From irclog.perlgeek.de/perl6-dev/2017-...i_15169665
Makes .pred 2.8x faster still and .succ 80% faster		 17:40
rakudo/nom: 880b33e2e6 | (Zoffix Znet)++ | 2 files
Add deconts to nqp::eqaddr() tests

There are more places where this is needed. Will try to remember to fix up those later, unless someone beats me.
Per: irclog.perlgeek.de/perl6-dev/2017-...i_15169706		 17:41
Zoffix grep -FRn 'nqp::eqaddr' src/ shows up several other places that likely need it, but my editor on this box sucks so I left those for now
lizmat: my view on that is: whom are we helping? If the changelog reads "- All enums now use $n extra bytesā¤ - Enums with more than a few elements are now a few microseconds faster" will people rejoyce? Currently you can do a million .succ's in 4 seconds on Order enum. Who's doing so many .succ's/.pred's on enums that the current performance would be problematic? 17:46
m: for ^1000_000 { $ = More.succ }; say now - INIT now
camelia 4.2706098
Zoffix Prolly be faster still after the last commit
To me this looks like a case of premature optimization (including the speed improvements commits I pushed). The methods aren't that slow to begin with and they're not commonly used. It's O(n), but so what? 17:47
timo most use cases for many succs in a row would more easily be served by just iterating over the elements of the map themselves 17:51
AlexDaniel FWIW I'm fine with documenting it as a trap and moving on, even though everything about it is distasteful 17:54
Zoffix What's the trap? 17:55
If any algo that's not O(1) needs to be put into traps, we're in serious trouble :) 17:56
AlexDaniel I would never expect .succ to be O(n)
Zoffix I see 17:57
AlexDaniel but in general the trap is using .succ on enums, it doesn't really DWIM
Files=3, Tests=14, 18 wallclock secs ( 0.05 usr 0.01 sys + 19.60 cusr 2.33 csys = 21.99 CPU) 17:58
Result: PA
SS
PAā€¦ SS? :-/
Zoffix .in 29d see if nqp::eqaddr deconting stuff needs to be done anywhere in core 18:00
yoleaux Zoffix: I'll remind you on 14 Oct 2017 18:00Z
lizmat FWIW, having an enum element know it's own index, would also make for a much cheaper .WHICH 18:03
that would be independent on the complexity of the value of the enum 18:04
Zoffix Sweet. 18:06
I'm gonna switch my position. I don't like this code and it'd be much nicer if the enum knew its index: github.com/rakudo/rakudo/blob/nom/...pm#L47-L78 18:09
lizmat working on that :-) 18:10
Zoffix \o/ 18:11
lizmat running spectest now 18:15
samcv releasable6, status 18:19
releasable6 samcv, Next release in 1 day and ā‰ˆ0 hours. 2 blockers. 122 out of 149 commits logged 18:20
samcv, Details: gist.github.com/49ffe0a2ec5e8ccc83...03edd8c105
Geth rakudo/nom: f925c64826 | (Elizabeth Mattijsen)++ | 3 files
Streamline Enum.succ|pred|WHICH

  - facilitated by an Enum knowing its index in the ^enum_value_list
  - make Enum.succ|pred about 7x faster, and O(1) (testing with Order)
  - use index to make Enum.WHICH completely agnostic about its contents		 18:22
AlexDaniel ^ native int thingy is probably not an issue, and the buffering fallout seems to be minor 18:23
so not exactly blockers but more eyeballs on these won't hurt 18:24
lizmat eyeballs welcome :-) 18:25
samcv good * everyone 18:28
lizmat samcv o/ 18:29
Zoffix lizmat++ looks great
AlexDaniel: I don't get where "the reasoning for keeping O(n) kinda contradicts itself." 18:32
Nor do I see where your "very fucking close" enums use .pred or .succ 18:34
AlexDaniel Zoffix: doesn't really matter anymore I guess, but my understanding was: 1) we're just trading more RAM for performance 2) n is very small ā†’ā†’ā†’ so why do we care if it's going to use more RAM or whatever, if n is small? 18:38
lizmat anyways, it's O(1) now
AlexDaniel you could of course argue that we may potentially have lots of small enums, so my logic is flawedā€¦ but oh well :) 18:39
and some examples from the ecosystem were just showing that big-ish enums definitely exist 18:41
although these are still small, I'd agree
Zoffix But none of them use .succ/.pred. They don't match the usecase you are trying to (prematurely) optimize for., 18:42
geekosaur seems to me .WHICH covers that one
AlexDaniel well we didn't have working .succ/.pred before, so yeah they are not using it
Zoffix Yeah, which is why I switched my position :) 18:43
AlexDaniel: We have working .combinations and .permutations. They're not O(1) 18:45
AlexDaniel not O(1) in what way? You mean besides what you're explicitly asking for when you use these? 18:47
lizmat afk& 18:48
Zoffix AlexDaniel: they're not O(1) in that they depend on N. 18:49
AlexDaniel well, if you want to get the elements out of it, then sure? 18:50
but at the same time this is fine:
m: say +combinations(30000, 5)
camelia 202432507874625006000
Zoffix Why are you OK with getting elements out of it being O(1)? You could pre-generate that list and return it faster. 18:51
And surely more people use these methods than .succ and .pred on Enumeration:D
*not being 18:52
Does it need to be "very fucking close" for it to be worthy of a ticket?
Zoffix &
AlexDaniel I dunno, I just think that .succ being O(n) is exceptional (and is unexpected), while I guess most people know that combinations/permutations can blow up with high n's 18:53
if we can optimize for some common combinations/permutations, then it can be worth a ticket, yeah. But so far I don't see this opportunity though 18:55
Geth rakudo: dwarring++ created pull request #1158:
add isa method to SubsetHOW		 19:47
rakudo/nom: 0704cd9722 | (David Warring)++ | src/Perl6/Metamodel/SubsetHOW.nqp
add isa method to SubsetHOW

Fixes RT#132073 the following was erroring, but now returns True:
subset S of Int; say S.isa(Int);		 20:09
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132073
rakudo/nom: ac8e099bad | niner++ (committed using GitHub Web editor) | src/Perl6/Metamodel/SubsetHOW.nqp
Merge pull request #1158 from dwarring/subset-isa

add isa method to SubsetHOW
nine AlexDaniel: what I have not seen in this discussion is an actual use case for .pred/.succ on enums. Let alone one that's performance sensitive. 20:15
AlexDaniel nine: what about Fooā€¦Bar ? 20:17
not that it works, butā€¦
ugexe The Nine Billion Names of God
geekosaur nine, actually we did find one: .WHICH and its use in serialization 20:19
BooK sorry about the Enumeration mess 20:33
are there types where .succ can return, er, nothin? because we've reached the end of the list? 20:39
perlpilot BooK: not sure why you're sorry ... it seems to me that it was slightly neglected area that could cause confusion. Better to find that stuff out sooner rather than later. :-)
BooK it's still causing confusion :-) 20:40
AlexDaniel some of the .pred/.succ stuff I don't understand at all 20:41
m: say (0.05).pred
camelia -0.95
geekosaur oh boy, we borrowed one from haskell >.> 20:42
basically numeric types treat succ/pred as +/-1 20:43
because there's some question as to what it means otherwise for non-integrals
BooK give me the Real immediately following Ļ€! 20:49
or 0, for that matter
AlexDaniel
.oO( 9e99.succ )
 21:01
doesn't work either way :D 21:02
BooK one possibly useful enum would be Errno 21:04
timo do it like javascript: turn the number into scientific notation and just increment the last number you find 21:08
BooK how do we get the 2 out of No such file or directory when doing IO::Path.new("not-there").slurp ? 21:09
it seems we just get a X::AdHoc with the message
timo the 2? 21:10
BooK errno = 2
timo oh, i don't see that
BooK the Perl 5 $! is a dual var that is the errno value in numerical context, and the error message in string context 21:11
also, with use locale, the message is localized
I know $! is much different in perl6, but I was wondering if we'd have access to the same kind of goodies 21:12
timo oh, you want to get the underlying errno 21:14
i'm not sure where the text comes from, actually 21:15
ah, yes, moarvm uses strerror for that 21:17
i thought that's supposed to respect LC_ALL and friends? 21:18
BooK yes 21:21
in Perl5, you only get localized messages if you explicted say "use locale"
timo yeah, but this is C 21:22
BooK and? 21:23
I mean, it could be useful to know when an error comes from down below 21:24
timo and i'm wondering why setting LC_ALL doesn't give me different messages
this is good, though. we can still stringmatch on error messages from "down below" if we want 21:25
since they won't be changed just because environment variables are set
BooK wouldn't it be nicer to match on the enum? 21:27
like, Errno::ENOENT
Skarsnik btw no stuff in place to localise errors?
timo we don't have anything yet to throw structured exceptions from inside the v 21:28
vm
might actually be simple, come to think of it. we'll just have to have a handler in place that knows how to translate what we throw into the proper HLL structured exceptions 21:29
like if we throw hashes that have a "type" key
BooK also, maybe failing syscalls should return specific exceptions 21:30
AlexDaniel lizmat: here? 21:32
lizmat am now 21:42
BooK AlexDaniel ^^ 21:45
AlexDaniel ah, well, I'm almost done submitting a ticket
but maybe you'll have some quick thoughts before I do
lizmat: bisected to github.com/rakudo/rakudo/commit/de...9734798a35
commit: 2017.08,dea0a08545a^,dea0a08545a,HEAD gist.githubusercontent.com/AlexDan...stfile1.p6 21:46
committable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, Ā¦2017.08,dea0a08545a^: Ā«30ā¤30Ā» Ā¦dea0a08,HEAD(ac8e099): Ā«(Int)ā¤30Ā»
AlexDaniel that's golfed from Automata::Cellular tests
lizmat so what is that supposed to say ? 21:48
AlexDaniel lizmat: honestly, I understand that question as much as I understand BUILDPLAN changesā€¦ 21:49
lizmat I get (Int) 30 for that piece of code, is it supposed to get something else ? 21:50
AlexDaniel 30 30
commit: 2017.08 gist.githubusercontent.com/AlexDan...stfile1.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, Ā¦2017.08: Ā«30ā¤30Ā»
lizmat aha 21:51
ok
ok, I see what the problem is 21:53
could you please add that golf as a test? 21:54
I will revert the necessary commits
AlexDaniel in 30 minutes, yeah
timo dang, i thought i was satisfied with my grant application, but now it seems pretty bad :S 21:56
Geth rakudo/nom: 3de6f33887 | (Elizabeth Mattijsen)++ | 2 files
Revert streamlining of BUILDPLAN

  - this reverts a8e0352b0358ad3ca99335d dea0a08545ab172836f9
  - defaults can refer to something being initialized later
   - so merging the actions into a single action does not cut it :-(
BooK timo: you need some proofreaders? 21:57
AlexDaniel lizmat: :( the amount of work being reverted
lizmat yeah, that's about 2 days of work 21:58
but I learned a lot :-)
AlexDaniel Skarsnik++ # running toaster
timo i'd appreciate a look; the current worry is that it's unintellegible to outsiders
which is ironic given that the task i'm giving myself is to make the whole thing simpler to understand for outsiders
BooK well, I think I qualify as an outsider :-)
timo docs.google.com/document/d/102h_Nl...3yfI/edit# - BooK, here's the text 21:59
AlexDaniel timo: I'm an outsider, where's the link? :) But I'm in the middle of evā€¦
ah ok
timo what ev is this?
AlexDaniel of everything actually. The multitasking is killing me 22:09
timo mhm
AlexDaniel lizmat: what would be the best place for this test? somewhere in S14-roles?
lizmat yeah, sounds right 22:10
AlexDaniel or maybe S12-construction
lizmat that also sounds like a good place 22:13
Geth rakudo/nom: ce95e1628c | (Elizabeth Mattijsen)++ | src/core/Enumeration.pm
Revert "Give enums an iterator"

This reverts commit cc64a75842236de43b7874578b289f6fcd292c97.
This appears to at least be given more thought. So at least reverting before the release.		 22:23
AlexDaniel lizmat++ 22:24
Skarsnik releasable6, status 22:29
releasable6 Skarsnik, Next release in ā‰ˆ20 hours. 2 blockers. 122 out of 154 commits logged
Skarsnik, Details: gist.github.com/ff2c367a108398d3c2...350f0f68a4
Skarsnik will run toaster tomorrow again if you want 22:30
AlexDaniel thanks 22:31
Geth roast: 9741b1b3bc | (Aleks-Daniel Jakimenko-Aleksejev)++ | S14-roles/basic.t
Add a test for the BUILDPLAN regression
 22:36
AlexDaniel lizmat: there :)
not really ā€œbasicā€ but that will do I guess
lizmat AlexDaniel++
AlexDaniel d'oh, I didn't mean to use unicode quotes there /o\ 22:37
but now grepping through the roast it seems that I'm not the only one who did that. OK 22:38
MasterDuke timo: 25 euro / hour seems low, i'd suggest increasing that quite a bit 22:39
timo i'm supposed to ask for even more moneys? 22:43
MasterDuke sure 22:44
timo how is TPF supposed to greenlight such a big request?
MasterDuke do they have a limit?
timo and how much would you consider "quite a bit"?
their upper limit is 10k dollars 22:45
MasterDuke then 10k
timo i'm not sure i can provide work that's worth this much money?
AlexDaniel I believe in you 22:46
MasterDuke you're proposing to do a lot of work, you should get appropriately compensated
BooK timo: is it easily splittable?
MasterDuke that's a good idea too 22:47
timo BooK: tricky, i was thinking about that, too
BooK so you build confidence (and trust) in succeeding at a smaller first step
timo yeah
if i only offer to build the web interface for the heap snapshot explorer and a new regular-profiler-UI, that'd cut down on the time noticably 22:48
BooK what was that thing that the rakudo people used to do? ah, yes, under promise and over deliver 22:49
timo hrmpf. ctrl-z doesn't get me back the time estimates i had in the inchstone list
hah, i wasn't part of the rakudo crew when most of the underpromising and overdelivering happened
but when i remove significant chunks of this, the "useful for outsiders" angle is lost 22:53
okay, i'll pivot and make this about a new profiler UI that doesn't explode your browser if your program is more complicated than hello world :P 22:56
plus integration for the heap snapshot analyzer
MasterDuke eh, everybody likes profilers. you don't have to be a core dev to want to know where to speed up your program
timo++
.oO(is a timo++ == a timotimo)
 22:57
geekosaur doesn't that require banach-tarski? 22:59
timo www.youtube.com/watch?v=uFvokQUHh08 23:00
oh, potentially nsfw 23:03
i wonder if i should pull "make the instrumented profiler threadsafe" into the scope 23:11
thing is, i'm entirely unsure how much time that will take 23:14
it could be it's just tens of lines of code in moarvm to make it work and then a bunch of time spent in the profiler to make it understand multiple threads 23:15
really, just focusing on making a new profiler UI that's also good at all the multithreading stuff we have, that'd be pretty neat 23:16
MasterDuke that would be so nice...
timo with my new estimates i'm down to only 135 hours 23:47
wow, there's a big discrepancy of commit counts with git log --all vs only git log when grepping for my name 23:50
that means there's many commits i didn't end up merging
MasterDuke_: you think 40 euros makes more sense as per-hour rate? 23:52
Geth roast: 5568a0d63f | (Samantha McVey)++ | 5 files
Add tests for testing collation. Tests for the unicmp operator

Tests generated with CollationTestGen.p6		 23:54
samcv yay collation tests
timo o/ samcv
MasterDuke_ yeah. that's just under 50 usd per-hour, which works out to what i believe is a pretty standard yearly rate for software devs
samcv that was annoying to do. since there are so many damn tests. it takes minutes to run
timo samcv: time to parallelize %)
samcv well. i mean it needs to be in order 23:55
so that was annoying
and i did try, but it didn't really benefit that much, and made it less flexible in the code i could write
timo ah 23:56
docs.google.com/document/d/102h_Nl...sp=sharing - would you mind giving my mostly rewritten grant application another look?
MasterDuke_ timo: but there's a lot of subjectivity in what i just said, so it would probably be smart to get some other opinions as well
timo MasterDuke_: i think you stopped looking before i rewrote most of this 23:57
samcv timo, me? ok i will. i took a glance at it and it looked like great work
timo yeah, then the application took an arrow to the knee 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!