Geth roast: 4105520fa1 | (Aleks-Daniel Jakimenko-Aleksejev)++ | S15-nfg/emoji-test.t
Unfudge all Emoji todo tests. samcv++
 02:59
samcv question. our `sub exit` has untyped argument. is this what we want or should it be typed to cool? 05:42
m: exit Any
camelia No such method 'Int' for invocant of type 'Any'
in block <unit> at <tmp> line 1
[Tux] This is Rakudo version 2017.06-197-g83e157012 built on MoarVM version 2017.06-56-g161ec639 07:29
csv-ip5xs 2.761
test 12.548
test-t 4.298 - 4.333
csv-parser 12.538
samcv o/ [Tux] 07:34
[Tux] o/ 07:35
lizmat samcv: added a paragrapgh 07:40
samcv yay :) 07:41
lizmat Files=1209, Tests=64192, 215 wallclock secs (13.22 usr 4.85 sys + 1307.87 cusr 136.26 csys = 1462.20 CPU)
[Tux] samcv, can you - just for completeness - also confirm the "High end Unicode in Perl6" talk? 08:16
samcv [Tux], i can't find any way to do that 08:33
i see submit
[Tux] weird
samcv oh i think i found it. i have to go to edit
done! 08:34
[Tux] thanks.
lizmat not sure this is a bug or I am doing something wrong: 08:36
m: role MyWay { multi method say(MyWay:D: |) { note "whee"; nextsame } }; my $*OUT = $*OUT but MyWay; $*OUT.say("foo")
camelia Cannot resolve caller say(Any+{MyWay}: Str); none of these signatures match:
(Mu $: *%_)
(MyWay:D $: | is raw)
in block <unit> at <tmp> line 1
lizmat hmmm... seems I mixed in the MyWay role into an Any 08:39
edited answer to: stackoverflow.com/questions/450245...s-iohandle 08:46
afk for a few hours&
m: role MyWay { method say(|) { note "whee"; nextsame } }; my $*OUT = PROCESS::<$OUT> but MyWay; say("foo") # shouldn't this work ? 08:55
camelia foo
lizmat really afk&
samcv m: exit Mu 09:17
camelia Type check failed in binding to parameter '$status'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
samcv exit Mu orelse say "oh no"
w: exit Mu orelse say "oh no" 09:18
m: exit Mu orelse say "oh no"
camelia Type check failed in binding to parameter '$status'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
llfourn m: role MyWay { method say($a) { note "whee"; nextsame } }; my $*OUT = PROCESS::<$OUT> but MyWay; $*OUT.say("foo") 09:23
camelia whee
foo
llfourn lizmat: does &say actually call .say?
(it doesn't) 09:25
lizmat llfourn: multi sub say(Str:D \x) { my $out := $*OUT; $out.print(nqp::concat(nqp::unbox_s(x),$out.nl-out)) } 10:45
ah, yes, see what you mean :-)
m: role MyWay { method print(|) { note "whee"; nextsame } }; my $*OUT = PROCESS::<$OUT> but MyWay; say("foo") # shouldn't this work ? 10:46
camelia whee
foo
lizmat whee!
lizmat wonders if it would make sense to have an IO::Handle.print candidate that would take a native str array 11:23
so we wouldn't need to join before printing
nine Is "$handle.print: $_ for @lines;" not enough? 11:24
lizmat eh, no :-) 11:27
trying to squeeze out some more % on say / print 11:28
specifically the **@args candidates
lizmat wonders why a new issue of the Perl 6 Weekly is not worthy of a @perl6org tweet anymore 12:00
stmuk_ can anyone remember the url to the output of the processes which create examples.perl6.org? I think it's on p6c.org but don't seem to have it bookmarked 12:05
timotimo it's in a subfolder named "build-log", but i can't reach it via http 12:08
oh
my mistake, it's examples.perl6.org not examples.p6c.org 12:09
moritz examples.perl6.org/build-log/
stmuk_ moritz++
Zoffix lizmat: ask moritz for keys to the account? :) 12:15
moritz which account? 12:16
Zoffix I see past weeklies were retweets from me but this week I did not use #Perl6 tag, so it probably wasnt in the @perl6org's feed
moritz: "* ā”‚ lizmat wonders why a new issue of the Perl 6 Weekly is not worthy of a @perl6org tweet anymore"
moritz oh sorry, just being busy
Zoffix :)
AlexDaniel, from what I recall while experimenting with ufobat's example, ealier rakudos .kill just fine. Also, the tree dies if you send kill yourself outside of Rakudo. So it's some kind of regression. Keep in mind there was one more bug that may have contributed to your code's comments: accessing list of signals (as kill does) wasn't thread safe and created a race where signal table was busted 12:19
moritz that said, I'd gladly give somebody else access to the perl6org twitter account 12:21
lizmat feels to me I shouldn't be at all Perl 6 knobs :-) 12:24
Zoffix thinks lizmat should get the Twitter knob :) 12:25
lizmat so if I have a sub a(|) {} , is there a way to pass on all parameters to another sub/method ?
moritz not really
lizmat other than doing (|c) ?
I mean, proto's can :-) 12:26
moritz and {next,call}same too
lizmat indeed :-)
Zoffix some p6 op?
nqp::p6* I mean
lizmat yeah, that's the question 12:27
moritz I think there is, yes
Zoffix m: use nqp; sub a(|) { dd nqp::p6argvmarray }; a <a b c>, 42, :70meow
camelia (("a", "b", "c"), 42)
lizmat hmmm.. pass nqp::p6argvmarray ? 12:28
not interested in names
nameds atm
ah, duh, can't work 12:32
because self is part of the parameter list, and that changes with the call to a method
timotimo are takecapture and usecapture usable from perl6 code, or will they be messed up by existing signature binding code we generate? 12:46
lizmat ok, so I can make say() and put() about 10% faster 13:20
*but* it will break a lot of spectest that expect say() internally calles $*OUT.print
Geth rakudo/nom: 58900e7ba8 | (Elizabeth Mattijsen)++ | src/core/IO/Handle.pm
IO::Handle.say(Str:D) instead of Str

We cannot unbox type objects as strings, these should be done by the
  \x candidate.		 13:21
lizmat the gain is mostly caused by not needing to find out the nl-out using a method call, but inside IO::Handle directly accessing the private attribute 13:24
gist.github.com/lizmat/a8c06dd75f0...71e4fabf11 # the diff in question 13:25
Zoffix Are those spectests part of 6.c or just something that was added later? IMO the tests should not make any assumptions on what methods say() and put() use. Just that they use $*OUT handle for output. 13:26
lizmat FWIW, for interface consistency, I believe that say() *should* call $*OUT.say
lizmat checks
S16-io/note.t predates 6.c (August 2015) 13:27
Zoffix would argue that test assumes too much about internal implementation 13:30
lizmat well, t/spec/S16-io/say.t has the same issue 13:32
Zoffix If it were at least using print(), you could argue there's an expectation that &print call maps to .print call, but &note -> .print ĀÆ\_(惄)_/ĀÆ even .say is a closer match
lizmat and several advent post tests 13:33
e.g. integration/advent2009-day07.t
this all got triggered by stackoverflow.com/questions/450245...s-iohandle
Zoffix Same deal with S16-io/say.t. The writer of the test let their knowledge of internal implementation of IO::Handle seep into the test
lizmat: oh, the correct Bleed Rakudo answer is override .write-internal and .read-internal methods 13:34
Though I'm unsure if jnthn++ decided they are good to be the final names for the methods
lizmat well, that's it: if you provide your own .say / .put / .print / .note methods, the interface is clear 13:35
Zoffix And I don't think they're tested/implemented yet
lizmat write-internal feels to me as something that's internal :-)
Zoffix We had a lot of ecosystem breakage because people were assuming exactly what these tests assume that method X is implemented in terms of method Y
lizmat: yeah, the names were still up to bikeshedding, but the plan was that subclasses just need to override those and not worry what is implemented in terms of what 13:36
There's also .eof-iternal. The IO::Pipe interface shows the usage: github.com/rakudo/rakudo/blob/nom/...pm#L25-L51
lizmat still, if you just want to capture whatever is being "say"d, you don't need any of the internals 13:37
nine But....if tests assume something and people assume the same thing because the tests assume that then that's how our specification works. Then in Perl 6 method X _is_ defined as an augmented call of method Y. 13:38
lizmat you just need to know that your object needs to provide a "say" method if say() is done with $*OUT being set to your object
maybe this is 6.d stuff 13:39
Zoffix nine: you were the person who argued that doing so robs of crutial optimization opportunities 13:40
lizmat anyways, I think 10% gain on say() would be worthwhile to have
lizmat goes back to fixing (<) on Mixes
nine Zoffix: it does and that sucks :/ We do get away sometimes with correcting the tests (and thereby changing the spec) but if as you say the ecosystem actively relies on the tested behavior, that's a line that we may not want to cross. 13:41
Zoffix No, the ecosystem issue did not rely on tested behaviour. 13:42
nine This is a very hard topic. We did promise backwards compatibility with the published spec. And we're breaking that promise at every opportunity. Of course as a still young adult, we get away with a lot of that, but at some point we have to grow up and take things seriously. 13:43
Zoffix: oh, I reacted to your "We had a lot of ecosystem breakage because people were assuming exactly what these tests assume"
Zoffix s/exactly/similar/; 13:44
The assumption was .say was implemented in terms of .print IIRC
(and tests assum say() and note() are)
nine If that assumption is made a lot, then that could show that assumption's usefulness. 13:46
Maybe .say _should_ be specced as calling .print.
lizmat then why does IO::Handle.say exist ? 13:47
nine Note that I do know very little about all this IO stuff. I'm using those cases as arguments in a more general discussion about spec tests.
lizmat well, I guess for those who actually do $*OUT.say
nine The question would then be: what about optimization? That won't be as simple as it is now (write some optimized nqp code or whatever). But it would still be possible, e.g. via spesh. 13:48
Geth 6.d-prep: 33bbdf8c83 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/README.md
Add TODO: `Define More Concrete Spec Errata Rules`
 13:49
nine spesh could still discover, that the code is running the standard case that will just call .print and use an even more optimized version instead.
lizmat spesh is smart enough to notice $*OUT hasn't changed ?
nine I'm fairly in hand waving territory right now :) But I guess it could be made smart enough to notice that, yes. 13:50
Or some more general mechanism will lead to equally optimized code.
The general mechanism could deal with dynamic variables (a pain point where we need to figure out optimization anyway) and how to detect that they do not change from one iteration of a loop to another. 13:51
Maybe that's something spesh even already does, I have no idea.
Spesh does recognize that some times are always the same. So it must have tracking infrastructure. And that may be repurposeable. 13:52
MoarVM does already inline small methods, doesn't it? From there it's not far from inlining a call to a method on $*OUT. 13:53
I guess my message is: not all hope is lost, even if we let people have their assumptions in some cases. We don't have to sacrifice all awesomeness to the performance god, like we don't compromise on having a real meta model either. 13:54
lizmat well, even a small (and important) sub like &DYNAMIC doesn't get inlined because of it using nqp::getlexreldyn or so
if &DYNAMIC could get inlined, all $*FOO accesses would benefit greatly
nine lizmat: yes, that's a current restriction. But I wouldn't know a reason for this restriction to remain indefinitely.
lizmat which includes say() 13:55
I was under the impression that this was not fixable
nine I'd be interested in the reason for that
Zoffix lizmat: " if your fiddling too low." in stackoverflow.com/a/45029361/2410502
lizmat fixed, Zoffix++ 13:59
Geth 6.d-prep: dc55ab42d5 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Add another 6.d feature to spec

Spec IO::Handle's `.write-internal`, `.read-internal`, `.eof-internal`		 14:04
Zoffix throws .WRITE-SOURCE, .READ-SOURCE, and .EOF-SOURCE as alternative names to ^ those into the bikeshedding pot
[Coke] blahs. 14:05
lizmat blahs ?
donaldh leans against bikeshed 14:09
[Coke] dayjob frustrations, everything is mostly fine.
donaldh Zoffix: source seems too overloaded a term.
Zoffix: would .READ, .WRITE and ,EOF suffice?
Geth_ nqp/master: 8 commits pushed by pmurias++ 14:10
Zoffix donaldh: not really. Then saying "call the read/write/eof method" has ambigutity with .read/.write/.eof
Not a fan of having three methods with different functions differentiated by letter case only 14:12
Zoffix &
Geth_ nqp: 045a4f4c50 | ven++ (committed using GitHub Web editor) | src/vm/js/bin/gen_sourcemap.js
js/gen_sourcemaps: Throw proper error

When using a string, we throw away a lot of informations like the stack trace.		 14:18
Ven`` Whoops. Didn't mean to just commit directly. pmurias: ^ can you review, and revert in case it's incorrect? thanks
AlexDaniel Zoffix: that's interesting 14:22
because from my perspective .kill(9) is not going to DWIM anyway 14:23
if I'm not mistaken, in perlĀ 5 you'd use kill(-9) for that
and we have no alternative for that in rakudo (yet?) 14:24
Zoffix DWIM how? 14:27
m: say Signal.enums.antipairs.hash{9} 14:28
camelia SIGKILL
Zoffix ok 14:29
Well, whatever it's killing, I remember not having ufobat's issue in earlier rakudos
pmurias Ven``: seems fine, thank you for contributing :)
Geth rakudo/nom: 2eeb000c94 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Shorten R:Q.MIX-IS-SUBSET a bit

nqp::iterator also returns false on an empty nqp::hash		 14:30
AlexDaniel well, SIGKILL cannot be trapped, so the process has no chance to clean up its children
pmurias Ven``: the way the source maps are built will very likely change, as building them up from an array of offsets seem more efficient than creating a gigantic JSON string 14:31
AlexDaniel so if you're doing .kill(9) on something, you are deliberately leaving its children alive
which is never what you mean, I think
Zoffix Ah
And what's the correct signal to send?
AlexDaniel well, the correct thing would be to kill the process group, which in perlĀ 5 is done by negating the signal numberā€¦ like -9 14:32
or you can do SIGTERM and *hope* that it will finish and terminate its children also
Zoffix I'm using $proc.kill: SIGTERM; followed by $proc.kill: SIGSEGV; in toaster and there's a bunch of unkilled stuff remains
m: say +SIGSEGV 14:33
camelia 11
AlexDaniel in whateverable, for some reason sighup works better, but I don't think it should be this wayā€¦
Zoffix &
AlexDaniel greppable6: kill 14:35
greppable6 AlexDaniel, gist.github.com/a0cfc7ef7494187ba7...1bfaa6eda7
Ven`` pmurias: are they disablable entirely?
AlexDaniel greppable6: kill[^-']
Ven`` I know they were perf concerning in some apps
AlexDaniel OH COME ON
Ven`` AlexDaniel: well done :P 14:36
AlexDaniel ah, this was a malformed utf-8 on one of the threadsā€¦ so not a segv at least
pmurias Ven``: currently they are off by default
AlexDaniel greppable6: kill[^-'] 14:37
pmurias Ven``: they will be enabled by a flag when compiling
Ven`` pmurias: sounds perfect. thank you :)
sorry for pressing the "commit" button a bit too fast.
AlexDaniel Ven``: it's my bot! I torture it the way I want!! ;)
pmurias bbl& 14:38
AlexDaniel by the way, if anybody knows better about things I'm talking about, what would be the right way to kill a process group in rakudo? And should we support negative signal thingy in some way? 14:39
lizmat isn't negative signal values a p5ism ? 14:41
AlexDaniel yes-yes we don't have to do it the same way 14:42
lizmat ok, *phew* :-)
afk for some cycling before it starts raining&
AlexDaniel let it be a named param or whatever, and it could give a helpful error message if you try to give it a negative signal number
[Coke] (malformed utf8) see github.com/perl6/doc/issues/1414 15:35
nine FWIW both kill(2) and the kill shell command use negative signal numbers for denoting the process group: If pid is less than -1, then sig is sent to every process in the process group whose ID is -pid. 15:42
Err...negative PID numbers, not signal numbers 15:43
AlexDaniel signal numbers also 15:44
nine Perl 5's kill supports negative PID numbers, too for process groups. If the OS does it that way that is. So the negative signal number is its OS independent way of killing a process group (though those do not exist on all systems anyway)
AlexDaniel: POSIX man page for kill(1): "If the first argument is a negative integer, it shall be interpreted as a āˆ’signal_number option, not as a negative pid operand specifying a process group." 15:47
AlexDaniel interestingly, right now rakudo accepts negative signal values 16:19
but it seems to do nothing with them
at least on moarā€¦
Zoffix oops 16:34
Might be my fault
m: dd $*KERNEL.signal: -50
camelia -50
Zoffix mc: dd $*KERNEL.signal: -50
committable6 Zoffix, Ā¦2015.12: Ā«-50Ā»
Zoffix oh, nmm 16:35
Told my trainee about Perl 6. He was suitably impressed :) 16:39
Though it was really stupid lead up: "This is written in Perl, though I don't like that lang anymore. If I could, I rewrite this in another lang." "What is it called?" "Umm... PERL 6!" 16:40
heh
timotimo REPL 7
Zoffix for rakudo.perl6.org, I'm gonna use a Perl 5 web app (after first trying to see if it can work as a Perl 5 CGI script). Don't want the manual process as that's a whole new step that needs to be done on each release and can be forgotten and cron isn't good either because during the release you push the tarballs and send announcement, but with cron you have to sit and wait for it to refresh the page before 17:00
you can send anything
ugexe gist.github.com/ugexe/58c2d193b103...80739621c8 (windows precomp rename error with --ll-exception gives different error) 17:05
(note this is *after* zef has been precompiled+working, and then I edited a file and rerun)
the error goes away in 2017.04, and is present in 2017.05 17:16
Zoffix But not in 2017.06? That looks very familiar to the issue we had on 2017.06 release and I thought we fixed it 17:20
Though I saw that error crop up on more recent Rakudo when precompiling files in lib/
"t/04-nativecall/06-struct.t .............. Failed 14/28 subtests" 17:22
flopper
ugexe its in 2017.06 too 17:23
but yeah, i thought this looked similar to what you fixed 17:24
where it was precompiling multiple times or something 17:25
Zoffix IIRC it was a "wtf" fix. Like removing the same nqp ops used by Str.subst and using Str.subst instead. Like no sense behind it but it appeared to fix stuff. I guess it didn't really
I'd say this is a release blocker,s ince R* will be based on this release 17:26
Oh
ugexe im slowly bisecting the commit, but any hunches are welcome since building is slow
Zoffix Maybe not that.
Ohhhh... now I remember. The fix for the thing was that newline translation was done in like IO::Handle.slurp but not in IO::Path.slurp so we ended up with different shas in different parts of the codebase and it thought the source changed 17:27
ugexe ah, which then produced the current bug
i think I got lucky... seems like it might be github.com/rakudo/rakudo/commit/ca...6ed9cc28a4 17:29
Zoffix That sure fits into the picture that checksums don't match someplace 17:31
s: IO::Path, 'slurp'
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2eeb...th.pm#L602
Zoffix s: IO::Handle, 'slurp'
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2eeb...le.pm#L644
ugexe well in this case the checksums *do* change (i edit a source file) 17:32
so before, while the checksums didnt really change, rakudo thought they did and took the path we are debugging currently
Zoffix Ah, I had the error without it. On first compilation it works, on second fails and I have to remove lib\.precomp
ugexe likely that windows is holding a handle now somewhere we don't expect 17:33
Geth nqp: da267b0320 | (Zoffix Znet)++ | src/QRegex/Cursor.nqp
Fix handling of actions in .refine_slang

We accidentally try to bind them to $name instead of $name ~ "-actions"		 17:34
rakudo/nom: c40a2122cf | (Zoffix Znet)++ | tools/build/NQP_REVISION
Bump NQP

Changes: github.com/perl6/nqp/compare/2017....8-gda267b0 da267b0 Fix handling of actions in .refine_slang 045a4f4 js/gen_sourcemaps: Throw proper error 87535d4 [js] Repair source map support and make it accesible from rakudo 51b5124 Attach the match (for file positions etc.) to the QAST properly ... (6 more lines)		 17:35
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....8-gda267b0
0e30ae13df | (Zoffix Znet)++ | .gitignore

  - ll-something-debuger is now generated during build
  - zef is something that exists during release process or when
   installing it to fetch modules to do extra Inline::Perl5 tests
ugexe the concat thing from --ll-exception is probably from $handle.print($!source-checksum ~ "\n"); 17:36
Zoffix ll-something => perl6-lldb-m
ugexe might be nice if we had a ENV var that the perl6 wrapper could use to point at perl6-whatever 17:38
well, i guess im more interested in setting --ll-exception 17:39
Zoffix would just doing it with a bash function stuffed into .bash_aliases 17:42
I have this one to run `./perl6` if it exists in directory or `perl6` if not. Avoiding having to remember which one to use depending on if I'm working on rakudo: p6() { if [[ -x ./perl6 && ! -d ./perl6 ]]; then ./perl6 "$@"; else command perl6 "$@"; fi; } 17:43
p6() { if [[ $LL_EX ]]; then perl6 --ll-exception "$@"; else command perl6 "$@"; fi; } 17:44
Or something or other. I don't know bash :)
Geth rakudo/nom: fe1a06cc97 | (Zoffix Znet)++ | t/02-rakudo/08-slangs.t
Test .refine_slang accepts an action class

Fix: github.com/perl6/nqp/commit/da267b0320 Bump: github.com/rakudo/rakudo/commit/0e30ae13df Bug find: irclog.perlgeek.de/perl6/2017-07-11#i_14857056		 17:45
ugexe yeah thats probably the correct way. but its not something I can easily explain to a windows user vs `set HARNESS_OPTIONS="-v"` or some such
Zoffix Ohh.. Yeah 17:46
nine Zoffix: I think, ugexe and me have found the source of the Windows precomp issues. 18:51
We never close the CompUnit::PrecompilationUnit::File's $!handle. I have no idea why that hasn't been an issue before. It just plain should not have worked.
Well we close the .load'ed PrecompilationUnit, but not the dependencies in the case the is-up-to-date check fails
Zoffix Ah cool. 18:52
nine Here: github.com/rakudo/rakudo/blob/nom/...ry.pm#L137
This should have been an issue since github.com/rakudo/rakudo/commit/f55e113290 (2016-09-06). No idea why it's only popping up now. 18:55
ugexe it probably was, but went away somewhere along the line if the fact 2017.04 did not have this issue means anything 19:04
Geth rakudo/nom: a526d839f5 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Fix baggy semantics of Mix (<) Mix

This breaks 3 tests in S03-operators/mix.t , which on deeper inspection I presume to be faulty.		 19:14
lizmat m: say <a b c>.Mix āŠ„ <a b b c d>.Mix
camelia True
lizmat this will return False after the above commit
Geth rakudo/nom: 37250ed5eb | (Stefan Seifert)++ | src/core/CompUnit/PrecompilationRepository.pm
Fix precomp dependencies left open when up-to-date check failed

This may fix issues with precompilation on Windows failing with failing to rename the new precomp file. Was probably caused by the open file handle.		 19:30
ugexe nine: i can confirm that fixes it 19:48
nine Yeah!
lizmat: can you note for the next weekly that ugexe++ did all the hard work of digging where the issue may come from? 19:49
lizmat nine: will try to remember :-) 19:50
ugexe open handles for procs can cause segfaults / no-message halting, so this could possible fix some of those as well
although it'd have to be a pretty big dependency chain 19:51
nine But this fix will only affect cases where a precompiled dependency is out of date. 19:52
Modules used by the top level script were already handled correctly. 19:53
Geth roast: 5ffd8ad12f | (Elizabeth Mattijsen)++ | 2 files
Add de-activated debugging helpers
 20:03
roast: 36a15940b9 | (Elizabeth Mattijsen)++ | 2 files
Add another set of (inactive) debugging helpers
 20:13
roast: 5fa2132fdf | (Elizabeth Mattijsen)++ | 2 files
Fix copy-pasto in debugging helpers
 20:15
roast: f534df325d | (Elizabeth Mattijsen)++ | S03-operators/set_subset.t
De-activate two suspect tests

These assume that a Set on either side of (<=) will force Setty semantics. This is against the notion of baggies being more contagious then setties, as expressed by TimToady on:
   irclog.perlgeek.de/perl6-dev/2017-...i_14830389		 20:24
samcv i'm working on tweaking things so that concatting two strings will less likely result in having to renormalize them 21:26
Geth roast: 6b021fbc68 | (Elizabeth Mattijsen)++ | S03-operators/set_subset.t
De-activate 3 more suspicious (<=) tests
 21:35
samcv as i have it now it does slow down concatting lots of unicode text when it's single codepoints i'm concatting all together. but that is unusual 21:36
it's more common there's going to be potentially a much longer string 21:37
instead of concatting like thousands of characters one at a time
AlexDaniel What I don't like about all these name change/tweak ramblings is the approach. Whenever some name was suggested, ten other suggestions would pop up and (at least for me) it's unclear which one is better(and then we get more ramblings on how the proposed name is not good enough). Let's *assume* that at some point we manage to tweak or change the name, would we be getting ā€œah, name X would've been so much betterā€ comments afterwards
Please noā€¦ So, if we are feeling at least a tiny bit serious about the whole question, and if we are ready to spend so much time on this beaten bikeshed, why not do the bikeshedding properly? Set up a page on rakudo wiki for brainstorming. Let's put *all* possible names there. Stupid or smart, tweaky or radical, everything goes into the list. After the brainstorming we can see where we stand. Maybe there will be a community favorite
that is undeniably better than everything we have seen so far? Maybe not, but I don't know, and I guess nobody does. Sorry to underestimate the effort put into the blog posts, but right now I feel like we only have I-have-this-idea-and-here-is-my-tunnel-visioned-justification-for-it kind of proposals.
And personally, I don't even think that we have to decide if the name should be changed/tweaked at all at first. If we did change or tweak the name, what would the best one be? Let's see, and then we can think if we can actually do itā€¦ 21:39
lizmat FWIW, I think we can get close to the desired PR effect by just consistently using "Rakudo Perl 6" vs "Perl 6" the same way one would use "perl" and "Perl" 21:40
aka the former being the implementation, the latter being the name of the language 21:41
and in case of "Rakudo Perl 6", one could argue it is *an* implementation
now, if p5p would start using "Pumpking Perl 5" instead of "perl", we could reach a. some symmetry and b. some distance 21:42
AlexDaniel can't really see how ā€œRakudoĀ PerlĀ 6ā€ is more marketable than ā€œPerlĀ 6ā€, but I really have no ideaā€¦
samcv ok WOW 21:43
in my tests concatting various languages. with actual normal lengths of text
from 9.829 seconds to 2.761
and i haven't yet seprately timed the concatting from the other code here
lizmat cool, that would help say() a lot :-) 21:44
AlexDaniel: try googling for "Rakudo Perl 6" and "Perl 6" and compare the results
the first hit for "Perl 6" for me is www.activestate.com/activeperl 21:45
samcv so this is concatting text 4650 chars long
lizmat AlexDaniel: which doesn't even have the string "Perl 6" in it
AlexDaniel lizmat: perl6.org, perl6.org/downloads/, wikipedia, ā€œWhy in The World Would Anyone Use Perl 6? | Zoffix Znetā€ 21:46
damn personalized resultsā€¦
lizmat aka, welcome to my bubble :-) 21:47
"Perl 6" has 8.5M results for me, "Rakudo Perl 6" has 40K results for me 21:48
AlexDaniel ā€œrakudo perl 6ā€ stuff seems to be more technical and less bloggy 21:49
*shrug* but we can also start renaming it to pisix or whateverlang and in a month we'll have decent google results pointing to the official resourcesā€¦ I guess it'll take a bit more to convince me about the marketing benefits :S 21:54
samcv m: say 10.8090910379193/4.48341698
camelia 2.41090469303600
Zoffix FWIW, my view on the naming approach is no one has issues with letting technical decisions be made based on the people's expertise, but when name/branding is at question, then suddenly everyone's a Marketing Director and a Brand Manager (proper jobs you have to go to college for).
samcv so 2.4x faster with 4000 character unicode text
16% faster with 460 characters
only case it is slower is if you are renfging single codepoints. but that can be optimized if we want i suppose special case low numbers of codeponits 21:55
Zoffix So the "let's start a wiki" approach sounds to me like a sound way to burn everyone out on an issue everyone's already burnt out.
lizmat samcv: what about concatting something with about 80 chars and a newline ?
Zoffix So IMO instead of a wiki, TimToady should make the call, asking for community suggestions if he's short on ideas. 21:56
samcv lizmat, that may not get a speedup
though i can see if i can special case that
lizmat Zoffix: agree, that would be the RFC , Apocalypse, etc... all over again
samcv more than it is maybe
hm
Zoffix &'s again
AlexDaniel noā€¦ that would be brainstormingā€¦ a list of possible namesā€¦
but if we don't want that, sureā€¦
samcv lizmat, so i guess it calls concat as part of the operation 21:57
lizmat yup
io_operators, line 24 would be the hottest path 21:58
samcv line 24 of which file
lizmat src/core/io_operators.pm
alternately, if someone would implement nqp::say :-)
samcv do we already have that? 21:59
lizmat hmmm... that would not work atm, as the interface sorta defines we call IO::Handle.print, not IO::Handle.say
samcv: no we don't
samcv m: use nqp; nqp::say('test') 22:00
camelia test
lizmat hmmm... duh
samcv or not to a specific filehandle you mean?
lizmat ah, yes :-)
samcv ah ok
this would make things a lot faster i think... printing out output. i should do this
lizmat anyways, I think the comment in io_operators is bogus 22:01
at least at that place
samcv yeah idk it is weird
how about a say operation that accepts two strings as arguments. the string and the ending 22:02
and filehandle obv 22:03
Geth rakudo/nom: 8cdeb21974 | (Elizabeth Mattijsen)++ | src/core/io_operators.pm
Remove misleading comment

With the encoding refactor and the proposed use of an IO role that needs providing a write-buffer/read-buffer only, this comment does not make any sense whatsoever. This was from another era with a different future.
lizmat samcv: forget that, maybe focus on nqp::concat being faster if the right hand is a NewLine
samcv ok
can do
Geth rakudo/nom: 4101581d5d | (Elizabeth Mattijsen)++ | src/core/set_subset.pm
Properly implement Baggy semantics for (<)

Fix some cases where Baggies would not be contagious enough wrt to Setties.		 22:07
dogbert17 [Coke]: htmlify failure, 'Writing disambiguation files ... Writing html/js/search.js ... Invocant of method 'wordcase' must be an object instance of type 'Str', not a type object of type 'Str'. Did you forget a '.new'?' 22:09
in sub write-search-file at htmlify.p6 line 762 22:10
Geth rakudo/nom: fae4aca029 | (Elizabeth Mattijsen)++ | 2 files
De-abstract R:Q.SET-IS-SUBSET

With the proper implementation of baggy semantics for (<=), we only need this logic once. So no need to put in a library for multiple use cases.		 22:27
rakudo/nom: 2fb109f1de | (Elizabeth Mattijsen)++ | src/core/set_subset.pm
Any (<=) Setty doesn't need to coerce Setty to a Set

It would be almost a noop for a Set, but potentially expensive for a SetHash.		 22:31
roast: 6fdc8b5d22 | (Elizabeth Mattijsen)++ | S03-operators/set_proper_subset.t
De-activate 3 suspicious (<) tests
 22:37
roast: ac3f86d2ff | (Elizabeth Mattijsen)++ | S03-operators/set_proper_subset.t
Oops, forgot to remove debug helper
 22:38
samcv time to add a brand new roast test
i forget which RT or even if there's an rt i wrote it for and originally it wasn't complete enough to get merged in 22:40
but it had to do with crlf line endings causing problems in certain conditions
and me and MasterDuke having to change is concat stable in moarvm
Geth rakudo/nom: c6cc1a7a3a | (Elizabeth Mattijsen)++ | src/core/set_proper_subset.pm
Properly implement Baggy semantics for (<)

Please note that 4101581d5d was the one for (<=)		 22:45
lizmat I will overhaul S03-operators/set_subset/set_proper_subset tomorrow 22:46
good night, #perl6-dev!
timotimo nite lizmat! 22:47
Geth roast: 2e1f7d92aa | (Samantha McVey)++ | 5 files
Add new test S15-nfg/concat-stable.t

This test checks that Unicode text of different languages is able to be broken up into the individual graphemes and concat'ed together without any change or alteration.
The script was originally created when a bug was found in concatting things ... (8 more lines)		 22:55
samcv yay more tests

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!