AlexDaniel wait what… where are the bots? :) 01:24
geekosaur wromg end of a netsplit 01:25
*wrong
AlexDaniel ah, didn't notice
m: say 42
camelia 42
AlexDaniel hm, or are they just stuck trying to reconnect? 01:27
well, we'll see later
or… I can maybe fix it while I'm here… 01:28
geekosaur not sure I'd bother unless they;re needed, since the netsplits are still occuring periodically
my guess is someone's ddos-ing freenode again
AlexDaniel never really understood the idea behind ddos-ing freenode 01:31
geekosaur there isn't one except "looky me I'm important I can take a network down" 01:33
AlexDaniel yes, I'll never understand how to pipe one proc to another without getting a couple of holes in my feet 02:27
if you don't do $proc.out.close, then you leave something behind and at some point you'll just go over the open file limit or something 02:30
if you do, then… it simply doesn't work sometimes?
ah no, nevermind 02:31
you should .out.close, the issue I had right now was different
[Tux] under 4, but only by the minimal possible amount :) 06:42
This is Rakudo version 2017.06-13-g6b634a369 built on MoarVM version 2017.06-7-gee49c831
csv-ip5xs 2.496
test 12.629
test-t 3.999 - 4.042
csv-parser 12.489
Error encoding UTF-8 string: could not encode Unicode Surrogate codepoint 56388 (0xDC44) 06:43
lizmat Files=1204, Tests=62525, 216 wallclock secs (13.15 usr 5.05 sys + 1315.04 cusr 132.23 csys = 1465.47 CPU) 07:42
whee, test-t below 4! 3.999 :-) 07:52
Q: if a module has a BUILD method, can the BUILDPLAN ever have more than one element ? 08:00
also: are there still modules out there that depend on the "old" BUILDALL interface ? 08:02
if not, we could make BUILDALL an only method 08:03
samcv lizmat, would you support a variation of %( ) where the keys can be objects? like :{ } but with nicer syntax and none of the block problems 08:29
lizmat what are the block problems ?
samcv { } can create a block 08:30
or create a hash
m: my $var = { $_ => 'word' }; say $var.gist
camelia -> ;; $_? is raw { #`(Block|43311368) ... }
samcv also { } is slightly slower than %( ) for the parser
well like 15% i think. something. not sure if 15% is more than slightly 08:31
lizmat "for the parser" you mean for compiling the code?
samcv yeah 08:32
it's 15% faster to use %( ) than { }
and it doesn't have to decide whether or not it's a block or a hash
lizmat samcv: I wouldn't mind seeing %() and/or :%(), but that's really up to TimToady & jnthn 08:40
samcv kk
also see this stackoverflow.com/questions/441014...h-or-block 08:41
is background on what prompted this
oddly enough i had recently started making myself use %( ) after reading the synopsis and also being bitten by random blocks where i wanted a hash
lizmat afk for a few hours& 08:43
jnthn m: dd :{ 1, 2 } 08:51
camelia -> ;; $_? is raw { #`(Block|31328624) ... }
Geth roast: c8f9fa490a | (Jonathan Worthington)++ | S32-encoding/registry.t
Test we can find built-in encodings by registry.
 10:06
roast: ebfbe65f47 | (Jonathan Worthington)++ | S32-encoding/encoder.t
Basic tests for Encoding::Encoder.
rakudo/encoding-objects: 274e7c0413 | (Jonathan Worthington)++ | 5 files
Add encoding support to new encoder API.

This will be used by I/O handles for doing output, and may be used by Perl 6 language users directly also. It is designed to allow various decisions to be made up front (on newline translation, replacement chars, and output blob type), while `.encode` today has to make them for every single call.
rakudo/encoding-objects: 8974dd2574 | (Jonathan Worthington)++ | t/spectest.data
Run S32-encoding/encoder.t.
 10:07
rakudo/encoding-objects: f267928f1f | (Jonathan Worthington)++ | 3 files
Use Encoding::Encoder in synchronous handles.

Rather than calling `.encode` every single time. Removes a good bit of overhead, and also means that userspace encoders are now possible with synchronous I/O handles. A "write a million lines to a file" benchmark now runs in 55% of the time it used to.		 10:40
timotimo that sounds great! 10:41
Geth rakudo/encoding-objects: 4f9aafaf29 | (Jonathan Worthington)++ | 2 files
Use Encoding::Encoder in async I/O handles.

Means that they now also support user-defined encodings, and should have an output performance boost too.		 10:55
rakudo/encoding-objects: 58769585a1 | (Jonathan Worthington)++ | src/core/Encoding/Builtin.pm
Allow empty replacement char in default encoder.
 11:16
rakudo/encoding-objects: 642d24f173 | (Jonathan Worthington)++ | src/core/Encoding/Builtin.pm
Encode into blob8 by default, not just Blob.
rakudo/encoding-objects: 03765c3635 | (Jonathan Worthington)++ | src/core/Str.pm
Switch `Str.encode` to use the Encoding objects.

Meaning that "foo".encode('user-defined-encoding') will now also work. At this point, everywhere that an encoding can be mentioned by name in CORE.setting does lookups in `Encoding::Registry`, meaning that user defined encodings should be usable everywhere.
jnthn Think that branch is in pretty decent shape by now 11:18
I want to write some more tests
But now, lunch and language lesson :) bbl
Geth roast: d275acbfd8 | (Jonathan Worthington)++ | S32-encoding/encoder.t
Correct expected encoding output type.
 11:20
[Coke] jnthn: is the encoding registry lexical? 12:15
timotimo [Coke]: looks global 12:22
[Coke]: i.e. the Register::Encoding class has a my-scoped hash in it
a lexical registry wouldn't be very useful, unless functions that take encoding names also look into the CALLER's lexical scope 12:24
[Coke] just wondering if that means that I can override an existing entry in the registry, breaking someone else's code. 12:28
ilmari [Coke]: it won't let you clobber an already-registered name, and the lookup hash is private to the registry class 12:32
github.com/rakudo/rakudo/blob/enco...egistry.pm
[Coke] whee. 12:34
ilmari++ looking stuff up so I don't have to. :)
lizmat write_fhb requires a native array to read from # huh ? 12:50
trying to get some debug info out of BUILDALL
nqp::writefh(nqp::getstderr,"$count\n"); # what's wrong with that?
timotimo you have to use "note" now 12:51
char writing ops have been deprecated
you'd have to manually use an encoder
but note() does that for you
lizmat timotimo: note() at that location gets setting compilation into an infiniloop
tried that first :-) 12:52
so how do I write something on STDERR from nqp ? 12:53
timotimo i feared as much
lizmat also: github.com/perl6/nqp/blob/master/d...wn#writefh
timotimo i tried to have a note inside MethodContainer so that i could see how many times it gets called during, for example, stage compile
setting compilation*
lizmat can't write to stdout, as that interferes with precomp :-( 12:54
timotimo right, that shouldn't say "Str" there
nine_ lizmat: precomp should ignore everything on stdout that doesn't look like a dependency id 12:55
lizmat I guess I was outputting numbers
ok, maybe that will work :-)
nine_ It's probably kinda hard to hit this by accident :) $dependency-str ~~ /^<[A..Z0..9]> ** 40 \0 .+/ 12:56
lizmat it was a sequence of numbers separated by spaces 12:57
nine_: it caused ===SORRY!=== 13:00
Missing or wrong version of dependency
nine_ very odd 13:04
lizmat timotimo: I guess the BUILDPLAN is shared between BUILDALL and BUILDLEASTDERIVED, right ? 13:17
I see a lot of cases where 13 is executed by the BUILDALL, but that is a noop there 13:19
dogbert11 m: say Match.^methods # what's happening here? 13:20
camelia X::Method::NotFound exception produced no message
in block <unit> at <tmp> line 1
yoleaux 2 Jun 2017 14:39Z <Zoffix> dogbert11: do remember the story about $?BITS not being 32 on 32 bit boxes? I recall pmurias was fixing something in that area.
2 Jun 2017 14:45Z <Zoffix> dogbert11: never mind, turns out $?BITS isbits in an int, not OS bits
lizmat m: .say for Match.^methods>>.^name 13:21
camelia List
lizmat m: .say for Match.^methods
camelia STR
MATCH
CURSOR_NEXT
CURSOR_OVERLAP
CURSOR_MORE
INTERPOLATE
CALL_SUBRULE
DYNQUANT_LIMITS
OTHERGRAMMAR
INDMETHOD
INDRULE
RECURSE
BUILD
clone
Bool
prematch
postmatch
caps
chunks
X::Method::NotFound exception produced …
dogbert11 is it something with nqp?
lizmat m: .say for Match.^methods.map: *.^name 13:22
camelia Method
Method
Method
Method
Method
Method
Method
Method
Method
Method
Method
Method
Submethod
Method
Method
Method
Method
Method
Method
NQPRoutine
NQPRoutine
NQPRoutine
NQPRoutine
NQPRoutine
NQPRoutine
NQ…
lizmat yeah, an NQPRoutine, and they don't now how to .gist
dogbert11 thx, a bit annoying though 13:23
lizmat dogbert11: fwiw, I'm not sure why those classes do not have a .gist or .Str method
dogbert11 an oversight perhaps 13:26
Geth rakudo/nom: f03a176c81 | (Elizabeth Mattijsen)++ | src/core/Lock.pm
Give Lock its own .new

So it won't have to go through BUILDALL, where it wasn't doing anything anyway.		 13:28
timotimo we're building a few locks during startup, aren't we? 13:30
lizmat yeah, 6 13:32
a bare startup now created 3 IO::Handle, 1 ThreadPoolScheduler and 1 Collation object using standard BUILDALL semantics 13:33
The ThreadPools Scheduler one is particularly wasteful: one call to BUILD and then 6x noop 13:34
(aka 13)
timotimo if we guarantee that 13 is only ever followed by other 13s until the end 13:35
we can skip all the rest when we see the first 13
lizmat there could be a TWEAK after it :0(
timotimo: but what is the reason for 13 in BUILDALL in the first place? 13:36
is that really because the same buildplan is also used for BUILDLEASTDERIVED ?
timotimo i believe so
lizmat and when is BUILD-LEAST-DERIVED called ? 13:37
timotimo when we have roles involved 13:38
i forgot the exact details
lizmat ok, something like $handle but Foo
timotimo all the variants of does have that in them 13:39
and but, too
not all, there is exceptions
but yeah, that's what it's for 13:40
lizmat ok, this is weird
all calls to BUILD_LEAST_DERIVED I can see, pass an empty hash as the parameter
ah, not all 13:41
timotimo not all, yeah
lizmat grrr
timotimo: have you thought about creating a separate buildplan for ALL / DERIVED ? 13:46
timotimo i'd expect it'd be a waste of memory. i'd rather do the thing with skipping when you find the first 13 13:48
jnthn back
lizmat but then we'd have to know whether there's no TWEAK at the end :-(
timotimo then we make sure to put the tweak in there before the 13s 13:49
either by sorting or through whatever other mean
lizmat buildplan of IO::Handle is: 1 1 1 1 1 4 4 4 13 13 13 13 0
but shouldn't the TWEAK be at the very end always ?
jnthn [Coke]: No, decided there didn't seem much use for that, especially given we'll let you pass an Encoding into IO handles rather than a name 13:50
lizmat: Eventually we'll compile, not interpret, the build plan 13:51
So I'd not worry abou tit
*about it
lizmat well, I've heard that for a long time already :-) 13:52
if I can get in some cheap opts in there still, it would be worth it now, no ?
anyways, this digging is good for my understanding of things :-)
jnthn Sure, so long as you don't break subclassability of stuff 13:53
lizmat break anything? :-)
jnthn So, what was I going to do next today.. 13:54
oh, right
[Coke] jnthn: there's apparently a segfault in Proc stuff? eveo mentioned it was known, but I don't see an RT.
jnthn [Coke]: There's two RTs on proc stuff that I'll work on later in the week :) 13:55
lizmat nine_: do you still need the "old" (@positional,%attr) interface to BUILDALL for Inline::Perl5 ?
[Coke] jnthn++
jnthn Though they both want the same fix
eveo Sorry, I misspoke, it wasn't a segv but a race
jnthn Or rather, one will be cleared up by the fix 13:56
(Because it's about code that goes away when doing the fix)
eveo: If it's not already (and you ain't already on it), could you RT the race? :)
eveo jnthn: it's this one rt.perl.org/Ticket/Display.html?id=131592
jnthn oh, right 13:57
[Coke] ... I am getting a segfault here on OS X. (checkout docs. run 'perl6 xt/space-after-comma.t'
jnthn But that goes away when we just start doing it wiht the hanndles :)
*with, *handles :)
eveo Yeah, probably
[Coke] If your fix is likely to avoid the segv, I'll just wait and try again later. Danke. 13:58
jnthn [Coke]: Are you chaining one process into another?
If so, then wait. If not, then it's probably something else.
jnthn builds his encoding branch on JVM to make sure he hasn't busticated it 13:59
dogbert11 [Coke]: I believe the handle thing is RT #131576 14:00
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131576
dogbert11 jnthn: how does the output code stand up against Perl 5 atm? 14:02
nine_ lizmat: looks like I do. What's wrong with it? 14:04
lizmat well, if we could make it a separate method, we could make BUILDALL an only 14:05
method
which presumably would dispatch faster
jnthn Not automatically
Depends on how it's speshed 14:06
Note that we only don't need it 'cus we haven't implemented part of S12 also :) 14:07
lizmat ah, ok, so forget about that then :-)
jnthn phew, JVM happy 14:08
Or at least, JVM not sad :P 14:09
[Coke] jnthn: yes, output from a -> b, in a loop for several hundred files. 14:10
(ach chain is only about 2 procs long.)
jnthn [Coke]: Ah, OK, then should be covered
[Coke] tries to figure out how to get an lldb backtrace... 14:11
jnthn OK, JVM looking alright. Merge time 14:12
dogbert11: Not too well; I need to look at why 14:14
[Coke] gives up before he loses an hour here.
jnthn dogbert11: Though a lot better than it was before :)
I'll run some profiles once I've got this merge landed 14:16
Geth rakudo/nom: 17 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/f...d0995f6890		 14:17
jnthn dogbert11: OK, so for: 14:18
perl -e 'open my $fh, ">:encoding(UTF-8)", "longfile"; for (1..1_000_000) { print $fh ("xyz" x 20) . "\n" }; close $fh'
./perl6-m -e 'my $fh = open "longfile", :w; for ^1_000_000 { $fh.say("xyz" x 20) }; $fh.close' 14:19
m: say 5.068 / 0.929
camelia 5.455328
jnthn Used to be nearly 5.5x slower
m: say 2.455 / 0.929
camelia 2.642626
jnthn Now about 2.5x slower
nine_ progress! 14:20
jnthn I suspect when writing to a file, though, Perl 5 does some buffering
'cus the Perl 6 time output is
real 0m2.455s
user 0m1.620s
sys 0m0.828s
vs. with Perl 5 14:21
real 0m0.929s
user 0m0.828s
sys 0m0.092s
Note the epic difference in sys
dogbert11 doesn't look too bad 14:29
hopefully there are some LHF's hiding in the code 14:31
Geth rakudo/nom: fff433379f | (Elizabeth Mattijsen)++ | src/core/Mu.pm
Micro-optimize building of some objects

The buildplan may contain several "13" entries which only have meaning when mixing in stuff into a class. In the standard BUILDALL execution, they have no meaning. However, they're always checked last. Since we know that all 13's are grouped together, we can shortcut the loop so that multiple consecutive 13's don't need to go through the whole machinery. This e.g. saves 36 nqp::iseq_i's for each IO::Handle object that gets created (of which we always create 3 at startup, so saves 108 nqp::iseq_i's for each startup).		 14:37
lizmat jnthn: all of a sudden I see setting parse drop 5 seconds ??? 14:38
jnthn o.O 14:41
lizmat but bare startup seems to have risen :-( 14:45
ah, 7 Encoding::Builtin objects being created at startup 14:50
jnthn: shouldn't that be precompiled ??
jnthn We could stick BEGINs in there, but is it really so costly?
|Tux| lizmat, that causes some tests to break 14:51
jnthn The add to registry call needs to happen at startup
But the encoding objects themselves we can precomp
lizmat [Tux]: looking at CSV now
|Tux| perl6 csv Cannot invoke null object 14:52
lizmat I have all tests successful
?
All tests successful.
Files=29, Tests=22298, 23 wallclock secs (14.94 usr 1.60 sys + 60.97 cusr 3.59 csys = 81.10 CPU)
|Tux| it is one of the older test scripts
lizmat which one ? 14:53
|Tux| test and test-t still pass, as does the test suite
$ p6 csv.pl </tmp/hello.csv
Cannot invoke null object 14:54
in sub non_nil at csv.pl line 37
and don't ask me why that script is (still) there
lizmat [Tux]: works ok here
|Tux| This is Rakudo version 2017.06-32-gfff433379 built on MoarVM version 2017.06-7-gee49c831 14:55
csv-ip5xs 2.602
test 12.253
test-t 4.016 - 4.030
csv-parser 12.004
is fff433379 new enough?
lizmat that's the latest afaik 14:56
jnthn Wow, nice, the inliner does pretty good already on the line output loop 14:57
All of write-internal, encode-chars, and gist get inlined into say 14:58
However, since it thus inlines ops that can't JIT...the whole lot ends up unjitted 14:59
So I guess that's my LHF :)
timotimo any jit ops i could implement? 15:00
jnthn timotimo: afaik it just needs write_fbh and encode; I'm already on them 15:02
timotimo: Though you could do some other I/O or decoder ops 15:03
Since most are missing
ugexe github.com/sergot/perl6-encode/tre...lib/Encode # here are 3 mappings in the ecosystem 15:17
timotimo sure, for now my next steps are grocery shopping though 15:46
lizmat just pushed github.com/rakudo/rakudo/commit/79...4e381ba4d1 15:50
fwiw, this seems to scrape off a few milliseconds from bare startup for me 15:51
timotimo now we can build all these iso-12345 encodings in perl6-space 15:52
lizmat would that mean they would be ecosystem, or just an extra module in lib, or part of the setting ? 15:53
timotimo good question
i mean all three of these are possible 15:54
jnthn Ecosystem
If something is common enough to warrant inclusion with Rakudo, it'd be common enough to warrant an optimized impl in the VM.
Nice thing about speeding up writes is I'm seeing slightly faster spectest times :) 16:11
m: say 2.085 / 0.929 16:14
camelia 2.244349
jnthn m: say q:c"You can now $fh.say in {100 * 2.085 / 4.434}% of the time you could at the start of the day" 16:16
camelia You can now $fh.say in 47.023004% of the time you could at the start of the day
jnthn The big win still to be had is implementing output buffering 16:19
But I'd like to let some more of the other I/O change dust settle before I do that. 16:20
The other wins will come from better spesh :)
jnthn afk for rest, nom, etc. 17:01
Geth rakudo/nom: 640404fc10 | (Elizabeth Mattijsen)++ | src/core/Mu.pm
Same as fff433379f33e621a3 for BUILD_LEAST_DERIVED
 17:38
rakudo/nom: e36d7eda37 | (Elizabeth Mattijsen)++ | src/core/Collation.pm
Initialize $*COLLATION only when needed
 18:25
rakudo/nom: 888a1b2ad8 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
Initialize $*SCHEDULER only when needed
 18:38
jnthn m: say PROCESS::<$SCHEDULER> 18:46
camelia ThreadPoolScheduler.new(initial_threads => 0, max_threads => 16, uncaught_handler => Callable)
lizmat jnthn: are you implying in cannot be initialized lazily ? 18:47
*it
jnthn Did you spectest the change?
lizmat yup 18:48
I always spectest changes before pushing (well 99.99% of the time :-)
jnthn Huh, I undid the laziness there because github.com/rakudo/rakudo/blob/nom/...oc.pm#L140 uses PROCESS::<$SCHEDULER>
lizmat is there a reason you didn't want to use $*SCHEDULER there ? 18:49
jnthn Because we always want to use the built-in one, not any override one
lizmat ok, I'll revert :-)
jnthn But I did the change because the lookup failed
And run/shell were totally busted by that
So I'm wondering how you got away with it :-)
lizmat is not sure
lizmat spectests again, just to be 100% sure 18:50
jnthn I un-lazy'd it like last week because I ran into problems :)
Does a simple -e 'run "ls"' or so work?
lizmat yes
maybe something else in Proc is triggering initialization before the spawn-internal ? 18:51
jnthn Yeah, that's my guess. It wasn't that way originally 18:54
And I'm curious what it is, and if it leaks anything
lizmat perhaps I should add a //= ThreadPoolScheduler.new ?
to line 140 in Proc ?
jnthn Well, // $*SCHEDULER would maybe do it but it's fragile
Becuase technically you can override it without ever having touched the original 18:55
lizmat hence my idea for //= ? 18:56
instead of // ?
make sure that that default TPScheduler will be the default one in the future ?
dinner calls& 18:57
jnthn Maybe that'd work, yeah 18:58
How costly is constructing it? Do we save a lot with the laziness?
lizmat 9 attributes without initialization, so quite a buildplan 19:48
they're all 13's so they've actually become a lot cheaper now
that saved 8x12 nqp::if/nqp::iseq_i 's 19:49
for a ThreadPoolScheduler object
ah, and a call to BUILD 19:50
metacpan.org/pod/release/DCONWAY/P...ontrols.pm # pointy blocks and phasers in Perl 5 20:00
www.reddit.com/r/perl/comments/6ie...ctures_as/ # Reddit comments 20:02
jnthn: hmmm... looks like I've introduced a race condition 20:09
Geth rakudo/nom: 608fd580c1 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
Revert "Initialize $*SCHEDULER only when needed"

This reverts commit 888a1b2ad8fa484eae77ed0fbe9b81523030fb8a.
Feels like this also introduced a race condition somehow, so reverting for now.		 20:11
lizmat hmmm.. I guess that goes for any standard dynamic that's lazily initialized 20:20
www.unicode.org/emoji/charts/emoji-released.html # fresh emojis :-) 21:17
AlexDaniel U+1F91F spiderman gesture! 21:22
jnthn I wonder if there'll be a font with "face with symbols on mouth" there the symbols are valid Perl syntax... :) 21:26
*where
Geth rakudo/nom: 0f77dd7cbc | (Elizabeth Mattijsen)++ | src/core/Mu.pm
Remove superfluous nqp::p6box_s

These would probably be speshed/jitted away already, but this also makes the code easier to read.		 21:31
rakudo/nom: b456122966 | (Elizabeth Mattijsen)++ | src/core/Mu.pm
Reorganize BUILDALL logic

So that we have fewer conditions to check on average when building an object using the default .new semantics.		 21:59
lizmat afk&
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Reorganize BUILDALL logic 23:40
travis-ci.org/rakudo/rakudo/builds/245134515 github.com/rakudo/rakudo/compare/0...561229663b
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.

Powered by Cro and the Raku® Programming Language.

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

Thank you!