01:48 ilbot3 left 01:57 ilbot3 joined, ChanServ sets mode: +v ilbot3 02:05 dct left
Geth nqp: jstuder-gh++ created pull request #455:
Rakudo Issue 1886: Remove erroneous decont op in chain compilation		 02:07
04:55 lizmat left 05:01 lizmat joined
AlexDaniel squashable6: next 05:11
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 1 day and ≈4 hours (2018-06-02 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
05:49 skids left 06:50 Ven`` joined 06:54 Ven`` left, Ven`` joined
lizmat Files=1239, Tests=76373, 323 wallclock secs (15.49 usr 5.56 sys + 2218.57 cusr 226.81 csys = 2466.43 CPU) 07:57
yoleaux 30 May 2018 22:15Z <tbrowder_> lizmat: you, and others, have done lots of nqp optimizations and shown how certain ops (or op combos) versus another for the same result are faster. do you have a list of those that we could put in a doc in nqp/docs? has anyone searched the code base to see if there are places where the faster op might be used? i can’t think of a specific example, but something like “@arr.push($item)” is slower or faster
than
AlexDaniel huh, is signal handling broken or am I being dumb 08:04
pretty sure that code worked in the past
AlexDaniel squints
alright? I updated my rakudo and it works again 08:07
lizmat yeah, signal handling should now be less fragile on different systems 08:09
Jeremy Studer++
AlexDaniel so we shipped 2018.05 with an issue, right? 08:10
… and even 2018.04? 08:11
AlexDaniel tests
I mean, the fact that numeric values of signals were incorrect was a very old bug, that I know 08:15
but signal(SIGUSR1) worked nonetheless
even though +SIGUSR1 was wrong
I think?
08:25 pmurias joined
lizmat AlexDaniel: so you're saying it's not working correctly now? 08:30
AlexDaniel lizmat: no, it's working correctly, but we shipped 2018.04 and 2018.05 with a bug that wasn't there previously 08:31
I think
testing it right now
lizmat I think the bug went back years
AlexDaniel I wrote some code earlier that year that definitely worked
unless I'm really dumb :)
testi 2018.03 right now… 08:32
ng*
lizmat AlexDaniel: could be that your code depended on the bug :-)
there's a lot of that going around in the Perl world :-(
AlexDaniel it works on HEAD :)
Geth rakudo: 4109ce36a5 | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Rename 'use p5isms' to more general 'use isms <perl5>

  - as proposed in GH #1887
  - should allow for other isms to be added later
  - internally still called 'p5isms' to allow for easier checking
   - this may need some attention if other alternatives are added in
   the future. But at least that will be work to do if we need
   rather than work now when we don't.		 08:46
synopsebot RAKUDO#1887 [open]: github.com/rakudo/rakudo/issues/1887 Should 'use p5isms' be renamed / removed / documented & tested
AlexDaniel lizmat: so what are your thoughts on turning perl5 isms on by default? 08:49
lizmat I would not be in favour for that
AlexDaniel lizmat: ok, but why? As I see it, we can recommend “no isms<perl5>” in all 5to6 docs, so that anyone who is actually interested in these warnings will know about this feature, at the same time anyone who never touched perl5 will never see unrelated warnings. 08:52
otherwise it's only useful if non-perl5 devs explicitly declare that they're not writing in perl5, which is rather weird, no? 08:53
lizmat the default is "no isms <perl5>", which means you *will* get warnings for Perl 5 constructs 08:54
AlexDaniel yes, and I'm saying it shouldn't be the default
lizmat my primary goal for this pragma is to allow CPAN Butterfly Plan P5xxx modules to work without generating these warnings 08:55
and in some case, to work at all
which, I guess, is different from your goal :-) 08:56
AlexDaniel re signals – yes, it works on 2018.03 and on HEAD, it's definitely broken on 2018.05 and I assume it's also broken on 2018.04 08:57
c: 2018.03,2018.04,2018.05,HEAD use NativeCall; sub kill(int32, int32) is native {*}; my $x = signal(SIGUSR1).Channel; kill $*PID, 10; sleep 0.5 09:01
committable6 AlexDaniel, ¦2018.03,HEAD(4109ce3): «» ¦2018.04,2018.05: « «exit signal = SIGBUS (10)»»
AlexDaniel well, that's not SIGBUS, but that's because committable itself is running slightly older rakudo, I think 09:03
I'm not quite sure what to do about that
is there a workarond?
you can't do signal(10)
c: 2018.03,2018.04,2018.05,HEAD use NativeCall; sub kill(int32, int32) is native {*}; my $x = signal(Signal(10)).Channel; kill $*PID, 10; sleep 0.5 09:04
committable6 AlexDaniel, ¦2018.03: « «exit signal = SIGBUS (10)»» ¦2018.04,2018.05,HEAD(4109ce3): «»
AlexDaniel not really
the reason I noticed it now is that whateverable is using this 09:05
so while I was trying to prepare for the squashathon I noticed that things don't quite work
there was no test for this particular case, so I haven't noticed any issues in the past two months 09:06
github.com/rakudo/rakudo/issues/1888 09:16
R#1888 09:17
synopsebot R#1888 [open]: github.com/rakudo/rakudo/issues/1888 [regression][testneeded] Issues with signal(SIGUSR1)
AlexDaniel please let me know what you think
09:19 ExtraCrispy joined
El_Che AlexDaniel: it would be weir to enable p5isms by default. They are marked as such because they are unnatural in perl6 09:20
lizmat AlexDaniel: if you do 'kill $*PID, +SIGUSR1, doesn't that work for you then? 09:21
AlexDaniel lizmat: the kill is not a problem
lizmat: the problem is that signal(SIGUSR1) doesn't catch the signal
lizmat but it does, at least for me 09:22
AlexDaniel lizmat: on HEAD, yes, but on 2018.04 and 2018.05 it's broken
lizmat ah, ok
AlexDaniel so both latest rakudo release and latest Star release are broken
but on 2018.03 it was working just fine
lizmat well, all I can say is that you should use the +SIGUSR1 instead of just 10 09:23
as SIGUSR1 on my system is 30, so your code didn't work on HEAD now for me
AlexDaniel lizmat: that's correct, but the signal typically comes from elsewhere
lizmat :q 09:24
AlexDaniel so it's likely that SIGUSR1 comes from another program
lizmat oops
yeah, and if that other program also uses +SIGUSR1 , all should be fine
AlexDaniel I left a comment in an attempt to clarify it: github.com/rakudo/rakudo/issues/18...-393472456 :) 09:30
El_Che: aren't they unnatural only if you're coming from perl5? 09:37
El_Che: e.g. what is unnatural about `say`, why do I have to write `say()`?
note that currently isms pragma does not affect that enough to avoid the compile-time error completely, but still 09:38
09:41 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Rename 'use p5isms' to more general 'use isms <perl5> 09:41
travis-ci.org/rakudo/rakudo/builds/386080942 github.com/rakudo/rakudo/compare/e...09ce36a52e
09:41 travis-ci left
buggable [travis build above] ☠ All failures are due to: failed make test (1 failure). Across all jobs, only t/06-telemetry/01-basic.t test file failed. 09:41
lizmat looks like a flapper, /me restarts job 09:44
actually, no, will wait for result of next commit
El_Che AlexDaniel: if the use case is natural in perl6 sure, but I fear some perl5isms may not make sense any more besides tradition 09:50
$hash{foo}
AlexDaniel El_Che: not sure I understand your point 09:52
El_Che that's a perl5ism to read a hash value
would you adopt this -convoluted- example to make the transition easier?
lizmat m: my $m = Hash.new; $m<foo> = 42; dd $m 09:53
camelia Hash $m = ${:foo(42)}
lizmat El_Che: or are you referring to the bareword inside {} ?
El_Che mostly, but not completely
the canonical way is that the hash sigil stays (I know there are other ways, but using the perl5 construction would make the code les readable) 09:54
and the bareword inside { }
perl6 code will be read by non perl5 programmers 09:55
requiring knowledge of Perl5 and 6 for working on a perl6 project is fine for me personally, but it sound like a bad idea
lizmat ok, I think the scope of discussion if going much too far 09:56
my point was that a module developer wanting to provide Perl 5 like constructs in Perl 6 couldn't because of these warnings / errors 09:57
El_Che take my remarks from someone far away, maybe I am missing the point
my point is that if you use isms, it's ok
it's explicit
lizmat all I wanted to do is to create a pragma that would allow a *user* to say: yes I know I'm using P5isms, and I'm fine with it 09:58
El_Che (so you can stay away from that code because you don't want to deal with that or at at least prepared)
but I argue against enabling it by default
lizmat: yes, that's a good idea
I was commenting on AlexDaniel's idea to enable it by default 09:59
AlexDaniel well, at least now I understand why it was called p5isms :) 10:12
Geth rakudo: c80ea2f289 | (Elizabeth Mattijsen)++ | src/Perl6/Grammar.nqp
Oops, missed another case for use isms <perl5>

This should now allow bareworded functions such as "say" to not croak when "use isms <perl5>" is used.		 10:16
El_Che AlexDaniel: without trolling, my minds reads it as pessimisms 10:24
AlexDaniel
.oO( pfffisms )
 10:33
11:11 Ven`` left
El_Che perl6 domains look to be down 11:52
moritz: perl6 domains look to be down
it's back 11:53
12:31 Ven`` joined 12:46 Ven` joined, Ven` left 12:47 Ven` joined 12:49 Ven`` left 13:21 Ven` left, Ven`` joined 13:52 skids joined 13:56 Ven`` left 14:01 Ven`` joined 14:47 brrt joined 15:03 brrt left, brrt joined 15:05 Ven`` left 15:09 Ven`` joined 15:33 Ven`` left 15:56 brrt left 16:31 ExtraCrispy left 16:44 brrt joined 17:13 brrt left
AlexDaniel m: say Signal(0) 18:00
camelia SIGTHR
AlexDaniel e: say Signal(0)
evalable6 SIGINFO
AlexDaniel haha
these are from FreeBSD I think
lizmat m: say $*KERNEL.name 18:01
camelia linux
lizmat camelia is not running on a FreeBSD
AlexDaniel that's exactly the problem :D
github.com/rakudo/rakudo/issues/1891 18:04
R#1891
synopsebot R#1891 [open]: github.com/rakudo/rakudo/issues/1891 [regression][⚠ blocker ⚠] Signal(0) gives FreeBSD signals on Linux
El_Che fix: install freebsd? 18:05
AlexDaniel El_Che: what's the result of Signal(0) on freebsd? 18:06
El_Che AlexDaniel: I only had freebsd shortly on a laptop, not anymore
AlexDaniel c: HEAD^^^^,HEAD^^^,HEAD^^,HEAD^,HEAD say Signal(0) 18:07
committable6 AlexDaniel, ¦HEAD^^^^: «SIGBREAK␤» ¦HEAD^^^: «SIGTHR␤» ¦HEAD^^: «SIGEMT␤» ¦HEAD^,HEAD(c80ea2f): «SIGINFO␤»
samcv i have a vm if someone wants me to test soething?
just tell me what you want the output of
AlexDaniel samcv: IMO it's not critical, so don't bother
but if you want to have some fun, then sure, just `say Signal(0)` 18:08
El_Che AlexDaniel: it looks random 18:09
AlexDaniel c: HEAD^^^^,HEAD^^^,HEAD^^,HEAD^,HEAD say Signal(0)
committable6 AlexDaniel, ¦HEAD^^^^: «SIGBREAK␤» ¦HEAD^^^: «SIGTHR␤» ¦HEAD^^: «SIGEMT␤» ¦HEAD^,HEAD(c80ea2f): «SIGINFO␤»
AlexDaniel El_Che: random per build :)
and all these are non-linux signals, I think
geekosaur two of them are just aliases 18:10
El_Che AlexDaniel: the list is here: man7.org/linux/man-pages/man7/signal.7.html
ctrl+f "Standard signals"
AlexDaniel c: 2018.03,HEAD say Signal(28) 18:11
committable6 AlexDaniel, ¦2018.03,HEAD(c80ea2f): «SIGWINCH␤»
AlexDaniel c: 2018.03,HEAD say Signal(50)
committable6 AlexDaniel, ¦2018.03,HEAD(c80ea2f): «(Signal)␤»
AlexDaniel c: 2018.03,HEAD say Signal(30)
committable6 AlexDaniel, ¦2018.03: «SIGUSR1␤» ¦HEAD(c80ea2f): «SIGPWR␤»
AlexDaniel c: 2018.03,HEAD say Signal(32)
committable6 AlexDaniel, ¦2018.03: «SIGTHR␤» ¦HEAD(c80ea2f): «(Signal)␤»
lizmat m: sqrt(-4) # shouldn't that be 2i ?
camelia WARNINGS for <tmp>:
Useless use of "sqrt(-4)" in expression "sqrt(-4)" in sink context (line 1)
lizmat m: say sqrt(-4) # shouldn't that be 2i ? 18:12
camelia NaN
geekosaur lizmat, auto-promotion to Complex is rarely what you want because very little code will expect it
so IEEE default is NaN and you work explicitly in complex if that's what you want
lizmat m: say sqrt(-4+0i) # I see what you mean :-) 18:13
camelia 0+2i
geekosaur there might be times when a pragma setting the default expectation would be handy, but I suspect that requires a fair amount of work 18:14
(might be nice anyway, to tell it to e.g. stick to (Fat)Rats as much as possible instead of auto-promoting to Num)
use AncientGreeks; # :p 18:15
18:23 pmurias left 18:42 j3nnn1 joined 18:49 brrt joined
brrt can i ask the regular benchmarkers to benchmark the MoarVM branch 'jit-stack-walker' again 18:52
i expect compiled code size reduction and maybe a performance improvement
lizmat brrt: looks like Travis is a bit red for your PR: travis-ci.org/MoarVM/MoarVM 19:05
afk& 19:06
brrt heh, that's the no-jit variant 19:07
i'll fix that up
AlexDaniel squashable6: next 19:15
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in ≈14 hours (2018-06-02 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
19:17 brrt left 20:05 brrt joined 20:40 brrt left 21:17 lizmat left 21:19 lizmat joined 21:40 skids left
samcv oh btw Signal(0) on freebsd is SIGSTKFLT 22:22
whatever that is ¯\_(ツ)_/¯
AlexDaniel
22:57 entonian joined 23:01 entonian left, entonian joined 23:08 entonian left, entonian joined 23:11 entonian left
samcv if i turn off hash randomization i get the same thing for Signal(0) on two different rakudo builds 23:33
El_Che samcv: you didn't it break it :) 23:34
or you did :)
great post btw
liked it 23:35
samcv thanks :)
El_Che explanations for us mortals :)
samcv i mean did anything break? i mean
or just signals that didn't mean anything
El_Che I run at least 1 Perl 5 program that catches SIGUSR1 and 2 23:36
samcv get signals seems to return a hash 23:37
nqp::getsignals
El_Che I thought AlexDaniel started hist debugging with that signal
samcv so. idk why would it work previously?
El_Che <blank> 23:38
samcv i mean it shouldn't work at all
or maybe it was broken but not for commonly used signals?
m: use nqp; say nqp::signals 23:39
camelia ===SORRY!===
No registered operation handler for 'signals'
samcv m: use nqp; say nqp::getsignals
camelia {SIGABRT => 6, SIGALRM => 14, SIGBREAK => 0, SIGBUS => 7, SIGCHLD => 17, SIGCONT => 18, SIGEMT => 0, SIGFPE => 8, SIGHUP => 1, SIGILL => 4, SIGINFO => 0, SIGINT => 2, SIGIO => 29, SIGKILL => 9, SIGPIPE => 13, SIGPROF => 27, SIGPWR => 30, SIGQUIT => 3,…
samcv m: use nqp; my %hash = nqp::getsignals; say %hash.sort(*.value.Int) 23:41
camelia (SIGINFO => 0 SIGEMT => 0 SIGBREAK => 0 SIGTHR => 0 SIGHUP => 1 SIGINT => 2 SIGQUIT => 3 SIGILL => 4 SIGTRAP => 5 SIGABRT => 6 SIGBUS => 7 SIGFPE => 8 SIGKILL => 9 SIGUSR1 => 10 SIGSEGV => 11 SIGUSR2 => 12 SIGPIPE => 13 SIGALRM => 14 SIGTERM => 15 SIG…
samcv and it only adds things > 1 23:42
El_Che samcv: github.com/rakudo/rakudo/issues/1888 Did you see that where jstuder says it's to changes he introduced?
samcv at least from the section i'm looking at
El_Che due
samcv ah ok 23:43
also we should make sure we have some tests for the signals too :) 23:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!