Kaiepi freebsd stresstest results hastebin.com/axogorabal.bash 00:01
forgot to pipe it to a file
Zoffix t/spec/S17-promise/basic.t is a regular flopper 00:03
Kaiepi btw did i remember to bring up the deadlock in promises i found?
i don't know if i did or not 00:04
Zoffix The await Promise.new?
Kaiepi oh
yeah i did
Zoffix Well, I saw that mentioned in #perl6. I don't have any opinion on it. Dunno if anyone else saw it. Maybe file a ticket? 00:06
AlexDaniel Zoffix: hey
Kaiepi i'll fill one 00:07
AlexDaniel it looks like module Crane is broken
and that seems to be a regression of today
well, between the last time I toasted
Zoffix What are the failures?
AlexDaniel gist.github.com/AlexDaniel/870b960...1c2ac5c46a 00:08
my brain was about to shut down actually
Zoffix Well, I'll direct you to this conversation... 00:09
AlexDaniel: irclog.perlgeek.de/perl6-dev/2018-...i_16072296 It starts with "Feels like adding constrained protos to resolve R#1739 is not the best of ideas"
synopsebot R#1739 [closed]: github.com/rakudo/rakudo/issues/1739 [āš  blocker āš ] Unintended consequences of converting routines from `only` to `multi` 00:10
Zoffix :)
AlexDaniel hehe
Zoffix AlexDaniel: but basically if we're sticking with out fix for R#1739 then that failure is by design and the user needs to add their own proto, or rename the sub
m: &copy.signature.say
camelia (| is raw)
Zoffix huh
s: &copy 00:11
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/a138...s.pm6#L231
Zoffix How does it get (| is raw) from it? :S
m: &copy.candidatesĀ».signature.say 00:12
camelia ((| is raw))
Zoffix oh, restricted stupid bot 00:13
e: &copy.candidatesĀ».signature.say
evalable6 (($from, $to, :$createonly))
Zoffix e: &copy.signature.say 00:14
evalable6 ($, $, *%)
Zoffix There we go
AlexDaniel: so basically, now all user multies would need to match ^ that proto.
AlexDaniel: and once we add it, there'll also be an error popping up when the user is trying to add a multi that doesn't match the proto.
And that's what the *% is for, so users could stick their arguments, like Crane does, but it wasn't considered that they may wish to omit some positionals. 00:16
m: sub copy {}
camelia ( no output )
Zoffix 6c: sub copy {}
committable6 Zoffix, Ā¦6c (28 commits): Ā«Ā»
Zoffix IMO that Crane code is iffy and it should've been an `only` sub instead of a multi
Ah, nm, they have many of them 00:17
AlexDaniel fwiw there are 4 other modules that depend on Crane
Zoffix Well, the fix is simple, just add a proto
AlexDaniel šŸ’¤
Zoffix And the author seems active. Last commit 4 days ago 00:18
Zoffix tries to fix and PR the breake
AlexDaniel: is that the only failure other than 4 modules that depend on it? 00:19
timotimo tony-o: pong 00:24
Zoffix .tell AlexDaniel` sent a PR for Crane github.com/atweiden/crane/pull/4 00:29
yoleaux Zoffix: I'll pass your message to AlexDaniel`.
AlexDaniel` Yes 00:43
yoleaux 00:29Z <Zoffix> AlexDaniel`: sent a PR for Crane github.com/atweiden/crane/pull/4
AlexDaniel` There was also something... 00:44
ah that's just a flop 00:45
Zoffix like what?
ok
AlexDaniel` Zoffix++ # thanks 00:46
Zoffix .tell jnthn FWIW, on the more restrictive protos in core thingā€”you said you'll think more about it. We had a regression in Crane because user's own multies took 1 positional arg but all core ones took 2: github.com/atweiden/crane/pull/4 00:57
yoleaux Zoffix: I'll pass your message to jnthn.
timotimo tony-o: i'll actually go to bed now, but i'll read whatever you send me when i get back to the keyboard 01:22
[TuxCM] Any link to a README with a "What do I need to do to run p6-blead without rakudowbrew from scratch"? 08:31
I got core-dumps in *compiling* Moar
stmuk_ [TuxCM]: gist.github.com/stmuk/147c17b8ed41...455d7b0bf2 08:59
nine [TuxCM]: did I get that correctly? The segfaults are gone now? 09:17
[TuxCM] All tests successful. 09:29
Files=30, Tests=22441, 21 wallclock secs ( 2.50 usr 0.18 sys + 75.15 cusr 2.07 csys = 79.90 CPU)
Result: PASS
nine [TuxCM] oh, how did you resolve the libper6_ops_moar.so issue?
[TuxCM] Rakudo version 2018.03-262-ga138dcf50 - MoarVM version 2018.03-126-g876aa90ee
csv-ip5xs0.892 - 0.895
csv-ip5xs-208.829 - 8.979
csv-parser36.186 - 36.750
csv-test-xs-200.449 - 0.455
test9.021 - 9.328
test-t2.510 - 2.552
test-t --race1.013 - 1.061
test-t-2045.363 - 46.204
test-t-20 --race15.233 - 15.393
 09:39
nine: cd install
AlexDaniel good * o/ 10:46
nine Inline::Python is now officially the first module to use our new build system :) 10:57
Kaiepi sweet 11:06
Zoffix [TuxCM]: github.com/zoffixznet/r Just throw out the "git checkout $(git describe --abbrev=0 --tags) &&" step to make it fetch the latest commit instead of latest release and you can run `update-perl6` any time you want to upgrade to latest 12:21
[TuxCM]: made a separate repo that just lists instructions for bleed: github.com/zoffixznet/rd 12:30
There's also Z-Script, if you want to re-build a lot after making some changes 12:31
huggable: zscript
huggable Zoffix, Helper script for Rakudo Perl 6 core development: github.com/zoffixznet/z
Zoffix m: say (Instant.from-posix: .posix + .second % 1, .second >= 60) - (.posix + .second % 1) with DateTime.new: '1964-01-22T01:42:56.925148Z' 14:54
camelia Instant:10
Zoffix wonde if that's to blame somewhere in .later :\ 14:55
Hm, if I use `self.new: catastrophe.later(seconds => $s).Instant, :timezone(catastrophe.timezone), :$formatter` I get the precision error, but if I use `self.new: catastrophe.Instant + $s, :timezone(catastrophe.timezone), :$formatter` then it disappears 15:00
Filed ungolfed version as R#1760 15:07
synopsebot R#1760 [open]: github.com/rakudo/rakudo/issues/1760 Potential precision bug in DateTime/Instant
Zoffix Oh, wrong chat. 15:12
nine Zoffix: is ecosystem/server/updatelist.pl the script that creates project.json for zef? And will commits to that automatically be picked up by whatever is running it? 15:24
Zoffix nine: yes and yes 15:25
nine: this is the URL for the generated file: ecosystem-api.p6c.org/projects.json
Cron job is run at: 8,28,48 * * * * bash update.sh > update.log 2>&1 15:27
And this is the update.sh it runs: gist.github.com/zoffixznet/ce0fbf0...40c5f3a7ad 15:28
(I see a run running right now, so whenever it finishes, I'd expect ecosystem-api.p6c.org/projects1.json to be a non-404 no more) 15:29
Can't use string ("1") as an ARRAY ref while "strict refs" in use at server/updatelist.pl line 127. 15:32
nine: but it created the file before dying with that: ecosystem-api.p6c.org/projects1.json 15:33
nine Zoffix: just pushed a fix 15:34
Testing this is non-trivial on a train's Wifi. Better than on the airplane where I wrote it though... 15:35
Zoffix nine: I did a manual run and now it completed successfully 15:40
And ecosystem-api.p6c.org/projects.json and ecosystem-api.p6c.org/projects1.json should now show what it produces
nine Awesome! I just confirmed that an old zef is now able to install Inline::Python even though it uses the S22 build system. Backwards compatibility FTW! 15:44
This means that I can now start sending pull requests for getting rid of Build.pm 15:45
Zoffix sweet 15:49
Geth Ā¦ rakudo: zoffixznet self-assigned DateTime.later .Int'ifies fractional seconds github.com/rakudo/rakudo/issues/1762 16:47
rakudo/post-release-2018.04: 29 commits pushed by (Ben Davies)++, (Tobias Leich)++, (Zoffix Znet)++, (Elizabeth Mattijsen)++, (Aleks-Daniel Jakimenko-Aleksejev)++, (Stefan Seifert)++, (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/6...0b95df3458		 16:48
roast/post-release-2018.04: 10 commits pushed by (Zoffix Znet)++
review: github.com/perl6/roast/compare/5bf...0e202c13da
Zoffix ZOFFLOP: t/spec/S11-modules/require.t 17:10
Geth rakudo/post-release-2018.04: 656ff77b96 | (Zoffix Znet)++ | src/core/DateTime.pm6
Do not .Int `second` units in DateTime.later/.earlier

Fixes R#1760 github.com/rakudo/rakudo/issues/1760 Fixes R#1762 github.com/rakudo/rakudo/issues/1762
Unlike other units, there's no ambiguity in fractional seconds, so don't .Int them to allow user to .later/.earlier a date by sub-seconds.		 17:15
synopsebot R#1760 [open]: github.com/rakudo/rakudo/issues/1760 Potential precision bug in DateTime/Instant
R#1762 [open]: github.com/rakudo/rakudo/issues/1762 DateTime.later .Int'ifies fractional seconds
roast/post-release-2018.04: 7c3bf500ed | (Zoffix Znet)++ | S32-temporal/DateTime.t
Test DateTime.later/.earlier can handle sub-second units

Closes github.com/rakudo/rakudo/issues/1760 R#1760 Closes github.com/rakudo/rakudo/issues/1762 R#1762 Rakudo fix: github.com/rakudo/rakudo/commit/656ff77b96		 17:16
rakudo: d4a6b92f39 | (Zoffix Znet)++ (committed using GitHub Web editor) | README.md
Direct users to rakudo.org bugs page for info on bug reporting

Fixes github.com/rakudo/rakudo/issues/1598		 18:31
Zoffix I find GitHub is in some ways suckier for ticket searching than fail.rakudo.party/ because all tickets aren't on the same page 18:32
AlexDaniel yes 18:38
I noticed that too
but I still think that github tickets should be listed on fail.rakudo.party 18:39
Zoffix Patches welcome :P
AlexDaniel ticket in question: github.com/zoffixznet/r6/issues/11
why do websites like to paginate so heavily? 18:43
25 per page, whyh
?
Zoffix can show more ads 18:44
GitHub.. dunno, less load on the system?
AlexDaniel through api you can't get more than a 100 it seems: api.github.com/repos/rakudo/rakudo...r_page=150 18:47
(if you're not logged in it's even less I think) 18:48
Zoffix # expected: DateTime.new(2014,12,11,12,32,23.137494802474976) 19:26
# got: DateTime.new(2014,12,11,12,32,23.137495)
AlexDaniel that's pretty close
Zoffix Still precision loss somewhere in DateTime/Instant routines :/ since they're Rats, I'd expect all operations to be exact 19:27
m: my \t = 1220735354.9501421; use Test; is-deeply DateTime.new($t), DateTime.new(DateTime.new($t).Instant) 19:30
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$t' is not declared
at <tmp>:1
------> 0301421; use Test; is-deeply DateTime.new(7ā5$t), DateTime.new(DateTime.new($t).Insta
Zoffix m: my \t = 1220735354.9501421; use Test; is-deeply DateTime.new(t), DateTime.new(DateTime.new(t).Instant)
camelia ok 1 -
Zoffix Oh, I forgot to stick a .Rat on t in my code :S (strangely, do have a memory of doing so) 19:31
I mean, I gen it with 1524424977.922727.rand; but it needs to be 1524424977.922727.rand.Rat;
.oO( or does it )
 19:32
m: my \t = 1220735354.9501421e0; use Test; is-deeply DateTime.new(t), DateTime.new(DateTime.new(t).Instant)
camelia not ok 1 -
# Failed test at <tmp> line 1
# expected: DateTime.new(2008,9,6,21,9,14.950142)
# got: DateTime.new(2008,9,6,21,9,14.95014214515686)
Zoffix This likely needs to convert it to .Rat first: github.com/rakudo/rakudo/blob/mast...e.pm6#L145 19:33
not really sure 19:35
m: say DateTime.new(0e0).second.^name 19:36
camelia Num
Zoffix m: say DateTime.new(0.0).second.^name
camelia Rat
Zoffix Now I'm more sure...
AlexDaniel speaking of jvm, does it even build for anyone? 19:37
AlexDaniel tries again
Zoffix Filed as R#1763 19:40
synopsebot R#1763 [open]: github.com/rakudo/rakudo/issues/1763 [consistency] DateTime.new(Numeric) does not normalize type 19:41
AlexDaniel I am getting this: gist.github.com/AlexDaniel/a3ff884...21e93cdcd3
bartolin: ā†‘ is this normal? 19:42
definitely does not look so
AlexDaniel bisects 20:05
bartolin AlexDaniel: no, that's not too good. I saw it earlier today, too. I'm pretty sure it happens since github.com/rakudo/rakudo/commit/4b5d36f3a8
yoleaux 3 Apr 2018 23:32Z <Zoffix> bartolin: FWIW, this commit used 309 as scale (citing perf loss concerns), but I imagine 17 is good enough, as doubles have at most 18 significant figures. Looking at openjdk's impl of BigInteger.divide, there's even a fast path when scale is < 18. Perhaps something to investigate, to improve perf? github.com/perl6/nqp/commit/b9f195...6650695165
3 Apr 2018 23:33Z <Zoffix> bartolin: err, I meant BigDecimal.divide's impl
bartolin didn't have much time recently 20:06
it looks like for some reasons the proto is called. 20:07
it's not only trait_mod:<does>: I changed that back to use (|) as its signature and then a similiar error surfaced for one of the other changed protos 20:09
AlexDaniel yea it's definitely that commit 20:23
lizmat FWIW, such a sweeping change feels meh just before a release :-( 20:25
I assume Zoffix had a good reason to do that now 20:26
AlexDaniel well, it resolved a blocker actually 20:27
but maybe we should rethink something
I'm not ok with breaking jvm build actuallyā€¦ 20:28
I know it's not in the best shape in general, but not building at all is a bit too much IMO 20:29
Zoffix Well, I wanted to resolve the blocker by teaching the things that care about .count to handle multies. 20:31
But that was turned down in favour of more restrictive protos.
bartolin I think there is still something fishy with nqp::multicacheadd on the jvm backend -- and this could very well be the reason for the explosion. I tried to fix something in that area not too long ago, but there is at least one problem left: rt.perl.org/Ticket/Display.html?id=126702
Zoffix I'm also -1 on restrictive protos. In general, not just this close to release.
We already had Crane regress due to the change. 20:32
AlexDaniel (that was resolved with a PR to Crane) 20:33
Zoffix e: say &trait_mod:<does> ~~ Callable; say &trait_mod:<does>.signature; .say for &trait_mod:<does>.candidatesĀ».signature
evalable6 True
(Mu, Mu, *%)
(Mu:U $doee, Mu:U $role)
(Variable:D $v, Mu:U $role)
Zoffix As for JVM breakage. Well, what's the long-term plan for JVM? There's a million fudges for it in roast, so I'm guessing it's not usable and it seems no one's actively working on it; just bartolin and psch doing occasional "resurrection" and fudging even more tests. 20:38
We could revert working more commits and stick even more #if conditionals, to make it "build" (but still not work right) so all that effort is just equivalent to sweeping problems under the rug IMO. 20:39
AlexDaniel I think it's somewhat usable, although I haven't heard of anyone actually using it for anything 20:40
Zoffix s/more/moar/;
AlexDaniel except for newcomers who just keep asking about it
Zoffix ( FWIW 4b5d36f3a8 is well-covered with tests github.com/rakudo/rakudo/blob/mast...ty-count.t ) 20:46
bartolin well, I like the general idea of supporting different backends. I'm not actively using the jvm backend myself, I'm just trying to help to keep it alive, hoping that some greater mind will jump in at some point. 20:48
I might be wrong, but I think the majority of fudged tests (for the jvm) are related to unicode stuff or are caused by one or more bugs leading to those infamous UnwindExceptions. Otherwise a lot of features are working ... 20:50
pmurias Zoffix: the biggest argument for keeping the jvm backend alive is that graal/truffle has a ton of promise and having something working to steal stuff from makes it more viable 20:52
I'm seriously doubtful that the current JVM bytecode emitting approach has a future 20:54
Zoffix But it's not kept fully alive. We just stick `#if jvm -> use old buggy codepath` into rakudo or just fudge failing spectests. 20:55
Not all all the time, but often enough.
bartolin true enough :/ 20:56
Zoffix I guess what I'm saying is this isn't the first time a commit I made broke something on JVM and someone suggested it should be fixed/fudged/reverted and if JVM doesn't have the future, then why waste time fixing/fudging/reverting
bartolin I'd be interested to hear jnthn's opinion on that. He invested a lot of time in the jvm backend, too. (not only back in 2013 or 2014) 20:57
AlexDaniel jnthn: ping ā†‘ 20:58
timotimo rakudo-jvm is potentially also the only way into some devs's hearts
well, into their manager's hearts i suppose
AlexDaniel that's correct, yes
but if it barely worksā€¦ šŸ¤· 20:59
Zoffix It's also slow AF. If people say MoarVM is slow... heh, let 'em try out JVM
pmurias Zoffix: graal/truffle has a large chance of being fast (possibly AF) 21:02
Zoffix pmurias: and who's working on that graal/truffle? 21:03
On the backend for it
pmurias Zoffix: nobody yet, I could volunteer some time jump start it if there are others interested but I don't want to start yet another thing when I'm the only dev 21:05
Zoffix I can reword my statement: "Why waste time on something that apparently doesn't have a future, only to be able to "steal stuff from"ā€”providing that stuff is working in the first placeā€”in the event that in some future time someone might want to work on some other backend"
I also don't fully understand what you mean. The existing code would still remain in the repo's history, so you could still "steal stuff" from it without having to fudge things all the time. 21:06
timotimo it'd be harder if it keeps bitrotting without people regularly looking after it
Zoffix I wouldn't call fudging spectests and rewriting rakudo's code to avoid JVM bugs "looking after it", but whatever. 21:07
timotimo i'ven't got a good idea for treating the jvm backend right 21:08
Zoffix Were TPF funds ever used to sponsor JVM backend development? 21:09
Or any other sponsor's? 21:10
lizmat Zoffix: not afaik 21:13
pmurias Zoffix: copying over stuff from something that doesn't work is harder 21:23
Zoffix: also reviving the JVM backend will be hard 21:29
AlexDaniel any volunteers for reviving it right now? 21:30
pmurias is it know what's broken? I can add some missing nqp:: op or fix some minor bugs 21:31
AlexDaniel some discussion here: irclog.perlgeek.de/perl6-dev/2018-...i_16078190 21:33
pmurias AlexDaniel: if that commit is causing this bug I could look into it (not today) 21:36
AlexDaniel when? :) 21:37
pmurias AlexDaniel: I don't want to make any promises that I won't keep but Tuesday seems likely (will be travelling on Monday) 21:40
Zoffix I don't think it's that commit that causes the bug, but rather it exposes it. 21:42
lizmat goes away to get some sleep 22:07
AlexDaniel lizmat++ :) 22:12
MasterDuke i don't know enough to start it myself, but if someone got graal/truffle integration started i would be interested in helping out 22:33
Zoffix ZofBot: help 22:40
ZofBot Zoffix, com/scriptkitties/perl6-dist-helper/pull/35 what about blockers? dogbert11: yeah, these are still up currently jnthn said he'll try to look at #1573 but #1566 needs some love R#1573 ##1566 R#1573 #1566 AlexDaniel: Yeah, there's that and another spesh bug I want to hunt tomorrow sounds great! Beastie
synopsebot R#1573 [closed]: github.com/rakudo/rakudo/issues/1573 [regression][āš  blocker āš ] Regression causing previously working script to fail
Zoffix hm
AlexDaniel ZofBot: that's old
ZofBot AlexDaniel, He told us to sit down on the far side of the table and he sat down on the other side
Zoffix For some reason earlier plugins in the list don't match :/
this is kinda weird 22:45
I have a file calls this: github.com/zoffixznet/perl6-Games-...teTime.pm6
But inside of it is `unit class GCT`.. And in my meta I have `"GCT": "the file"` in provides... And I can't -MGCT with -Ilib when developing, yet it works when module is installed, and I can't -MGames::TauStation::DateTime when module is installed, but I can when I'm developing, with -Ilib 22:46
s/calls/called/; 22:47
Zoffix wraps it up in module Games::TauStation::DateTime just in case 22:48
AlexDaniel jnthn: there was a discussion about jvm backend today: irclog.perlgeek.de/perl6-dev/2018-...i_16078492 23:20
(starting from here: irclog.perlgeek.de/perl6-dev/2018-...i_16078190 ) 23:21
in case you missed it
jnthn Yeah, I saw, I'm too tired to participate.
Though TPF has in a sense funded JVM work in that I've taken care of keeping JVM working when I've done major changes funding through that work.
s/funding/funded/ 23:22
MasterDuke is there any good way to profile the jvm compiling the setting? or, is it known what parts are the slowest? any LHF perf-wise? 23:23
jnthn Could use VisualVM 23:24
Which comes with the JVM as standard, I think.
MasterDuke huh, never heard of it
jnthn docs.oracle.com/javase/8/docs/tech...filer.html
I used it when I was working more intensively on the JVM stuff in the past 23:25
Sleep time for me; 'night
tony-o timotimo: i was looking at the possibility of using the moarvm coverage flags as a way to do test coverage 23:39
it seemed to me that it wasn't reporting lines hit, but whenever a function was called (and not necessarily returned from)
MasterDuke tony-o: it definitely does lines, but optimizations may throw it off 23:40
Zoffix Yeah, there's a slightly dated article on generating test coverage: rakudo.party/post/Perl-6-Core-Hack...Moar-Cover 23:41
You need to disable optimizations and even then it's not very perfect.
(well, the article is about coverage of core, but I think it can be tweaked to show coverage of any script) 23:42
timotimo it doesn't report what lines definitely exist, either 23:46
you need to moar --dump the bytecode files for that :(
gnite! 23:47
Zoffix \o
ZofBot: gct 198.17/0:0
ZofBot Zoffix, 2018-04-25T01:42:29.925148Z; which is 2 days, 1 hour, 54 minutes, and 42 seconds from now
Zoffix ZofBot: gct D/8:0 23:48
ZofBot Zoffix, 2018-04-23T01:43:14.773074Z; which is 1 hour, 55 minutes, and 11 seconds from now
Zoffix Nice :)
moritz: ^ takes those via /msg too, if you ever need 'em

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!