Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_logs/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by AlexDaniel on 12 June 2018.
00:53 gfldex joined 02:57 BenGoldberg joined
samcv hmm in nqp: my $foo = 'hi'; die() if !$foo is 8.5x slower than `unless $foo` 05:02
05:20 BenGoldberg left 05:42 skids left
nine jnthn, lizmat, Zoffix: exporting phasers is quite necessary in some situations: github.com/niner/Inline-Perl5/blob...5.pm6#L966 05:48
It's also how I hope to be able to make Inline::Perl5 users precompilable at some point
lizmat perhaps if the EXPORT sub exports a key such as 'LEAVE' and its value is a Callable, the exporter should take that as a cue to do an $*W.add_phaser ? 06:22
with the name returned ? 06:23
so you could also do a ENTER phaser :-)
Files=1239, Tests=76361, 319 wallclock secs (15.65 usr 5.39 sys + 2212.66 cusr 223.27 csys = 2456.97 CPU)
breakfast&
nine lizmat: we could also support EXPORTPHASER in addition to EXPORT and EXPORTHOW 06:24
06:54 robertle joined 07:12 AlexDaniel left 07:13 brrt joined 07:26 [TuxCM] joined
[TuxCM] Rakudo version 2018.05-86-g874ead515 - MoarVM version 2018.05-123-ge485ab338
csv-ip5xs0.896 - 0.902
csv-ip5xs-207.272 - 7.330
csv-parser23.370 - 23.499
csv-test-xs-200.446 - 0.448
test7.741 - 8.642
test-t2.251 - 2.304
test-t --race0.954 - 0.956
test-t-2040.174 - 41.167
test-t-20 --race14.138 - 14.609
 08:00
08:01 ufobat joined
[TuxCM] plus this: gist.github.com/Tux/8fd4d7866d4553...0cd2311450 08:01
lizmat when did that happen ? 08:02
[TuxCM] csv-ip5pp now fails 08:03
no Idea. I'm in Spain. this ran during breakfast
lizmat nine: ^^^
08:10 [TuxCM] left
lizmat jnthn: any comments on modules.perl6.org/dist/FINALIZER:cp...ALIZER.pm6 ? 08:41
I plan to use that a lot in the future, and push its use in the ecosystem (e.g. DBIish) 08:42
jnthn lizmat: Well, it ain't threadsafe for one 09:30
Also, doesn't it mean that if a module uses it, but the calling program doesn't, then objects registered become impossible to GC until program exit? 09:31
That'd be *worse* than the current situation
lizmat jnthn: which part do you not consider to be threadsafe? the .add_phaser bit ? 09:33
but yes, any objects registered will not be collectable until program exit 09:34
unless the user adds some "use FINALIZER" in some inner scope
of course, if the user does an explicit $dbh.close, the module should maybe unregister hmmm 09:35
09:42 brrt left
jnthn Yeah, the action-at-a-distance bothers me a bit. What I'd been more expecting us to do is have some kind of construct like `closing some-operation() -> $handle { ...code here... }` 09:42
With a better name :)
And it would automatically call some method on scope exit 09:43
lizmat well, that could be an ecosystem module (like FINALIZER) if it were able to export a LEAVE phaser, no ? 09:44
FWIW, the action-at-a-distance is what is intended here
jnthn I really don't like that if you don't care to use it, but a module you use is using it, then you're in trouble. 09:50
That's just too intrusive.
I'd probably be very reluctant to depend on any module using this as a result
lizmat if a module would only register *if* there is $*FINALIZER available? 09:52
because that would imply the user wants finalizations? 09:53
jnthn That'd probably be better
Maybe I should also draft up some language-level proposals for this kind of thing. 09:57
10:21 brrt joined 10:23 AlexDaniel joined
lizmat jnthn: that would be cool :) 10:35
10:37 brrt left 10:41 AlexDaniel left, AlexDaniel joined 10:47 robertle left
AlexDaniel lizmat: hm, what changed exactly regarding `pack`? 10:49
lizmat: I see some modules failing because of that, but I don't understand…
c: 2018.05 say pack('n', 25) 10:50
committable6 AlexDaniel, ¦2018.05: «Use of the 'pack' function is experimental; please 'use experimental :pack'␤ in block <unit> at /tmp/LttlZzQ96t line 1␤␤ «exit code = 1»»
AlexDaniel c: HEAD say pack('n', 25)
committable6 AlexDaniel, gist.github.com/622ec2b7bcabcf1345...2998b83190
lizmat I moved pack out the setting into the 'experimental' module
AlexDaniel so now it's a compile-time error? 10:51
so, for example, FastCGI module is using pack, but it's tests were fine on 2018.05 10:52
is it simply because tests simply never reached lines with `pack`?
lizmat AlexDaniel: are the tests doing 'use experimental :pack' ? 11:00
AlexDaniel no 11:01
lizmat hmm... are they just doing Blob.unpack ?
AlexDaniel example: github.com/supernovus/perl6-fastcg...l.pm6#L244 11:02
lizmat AlexDaniel: I think I have a golf: 11:04
m: Buf.new(1,2,3).unpack("C3")
camelia Cannot call method 'defined' on a null object
in block <unit> at <tmp> line 1
AlexDaniel well, that's something to be fixed, but still a different issue as far as I can see 11:05
but I guess these modules simply need `use experimental :pack`
lizmat yes, they do 11:06
BTW, testing a fix for above issue
AlexDaniel “No such method 'generate-samples' for invocant of type 'IntStr'. Did you mean 'generate-samples'?” 11:09
AlexDaniel squints 11:10
Geth rakudo: 2fa08d5e6f | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
Fix problem with Buf.unpack without 'use experimental'

Apparently, 'with' cannot handle nqp::null values, so this caused a
  "Cannot call method 'defined' on a null object" error rather than
complain about 'use experimental :pack' not being loaded.		 11:21
lizmat AlexDaniel: ^^^ should now properly complain if FastCGI didn't to 'use experimental' 11:22
AlexDaniel thanks
I'll submit some pull requests to modules
ahh I see now 11:34
AlexDaniel is blind
FastCGI doesn't even have tests, it was failing on installation 11:35
so that's why
lizmat afk for a few hours& 11:40
Geth rakudo/rescalar: a92ce28b62 | (Jonathan Worthington)++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java
Remove dead code in JVM ops file

This supported p6scalarfromdesc, which is now done as a desugar.		 12:32
AlexDaniel github.com/supernovus/perl6-fastcgi/pull/10 github.com/samgwise/Net-OSC/pull/4 github.com/retupmoca/P6-Net-SOCKS/pull/4 12:33
that's it
Web, Web::App::Ballet, Web::App::MVC depend on FastCGI unfortunately
I mean, of course it's fine to depend on FastCGI, it's just that the PR needs to be merged to unburn them :) 12:34
Geth rakudo/rescalar: 384463ad19 | (Jonathan Worthington)++ | tools/build/Makefile-JVM.in
Bump JVM memory limit to survive setting build
 12:35
jnthn bartolin_++ for suggesting the second of those :)
Geth rakudo/rescalar: 1b584e1f3b | (Jonathan Worthington)++ | 2 files
Update JVM backend with the descriptor rw removal

The presence of a descriptor now implies rw without any additional flag checks.		 12:37
nqp: e1ff93d5aa | (Jonathan Worthington)++ | src/vm/jvm/QAST/Compiler.nqp
Stub new atomic ops on the JVM backend

These are not yet implemented, but stubbing them is enough to get the compilation of Rakudo on JVM in the Scalar refactoring branch to build, so the simpler parts to update can be handled first.		 12:41
rakudo/rescalar: e3adaf83d8 | (Jonathan Worthington)++ | 2 files
Switch Scalar container spec to run the NQP code

This seems to basically work, although the atomics won't until some new ops are properly implemented for NQP JVM, and there's also some kind of regression to hunt down involving `is copy` (which relates to the descriptor change).		 13:12
13:22 AlexDaniel left 13:29 robertle joined 13:52 skids joined 14:36 MasterDuke left 15:27 robertle left
Geth nqp/nqp-in-the-browser: 11 commits pushed by (Paweł Murias)++
review: github.com/perl6/nqp/compare/d43fd...1f8e2d9533		 15:33
15:36 perlpilot_ joined, perlpilot_ is now known as perlpilot
japhb Well that's an intriguing branch name .... 15:39
15:47 ExtraCrispy left 15:52 robertle joined
Geth rakudo: jstuder-gh++ created pull request #1921:
Issue 1918: Fix for .assuming sub with **@ and +@ params		 15:55
16:00 AlexDaniel joined
Geth rakudo/post-release-2018.06: 93a8ec6655 | (Jeremy Studer)++ | src/core/Parameter.pm6
Modify Parameter's positional to rm slurpies

Add slurpy_lol (**@) and slurpy_onearg (+@) to param types that are not considered positional.
This caused an issue when using '.assuming'. The fact that they were considered both positional and slurpy caused them ... (6 more lines)		 16:10
rakudo/post-release-2018.06: 0ef7109e7e | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Parameter.pm6
Merge pull request #1921 from jstuder-gh/param_all_slurpies_not_positional

Issue 1918: Fix for .assuming sub with **@ and +@ params
16:32 perlpilot left 17:08 sivoais left 17:10 sivoais_ joined 17:12 sivoais_ left 17:16 sivoais joined
AlexDaniel hm, if I see a comment again saying that toaster is an example of how we introduce many breaking changes, I'll revert back to reviewing the results locally without publishing them 17:19
or maybe I should do another redundant run on the actual monthly release to show that actually everything is green
( context: github.com/perl6/user-experience/i...-397371514 ) 17:20
japhb AlexDaniel: Yes, you should have separate displays of the most recent monthly (+point release), separate from the "blead" view. And the blead view should be well-labeled as such, and NOT the default thing new people see. 17:23
17:23 [TuxCM] joined
japhb .ask nine Did Inline::Perl5 intentionally start requiring Moose? (Noticed it no longer passes testing in my "rebuild the world and install all my favorite modules" script.) 17:24
yoleaux japhb: I'll pass your message to nine.
AlexDaniel I see. I guess toaster indeed sends a wrong message to anyone who stumbles upon it 17:25
“16 modules got burnt” – that's a message to the release manager, somewhat irrelevant to anybody else 17:26
OK I hope I'll have time to work on that after the release 17:27
there's also a way to make it faster, I think
japhb: thanks 17:30
japhb AlexDaniel: My advice is as usual worth what you paid for it. ;-) 17:48
18:10 perlpilot joined
timotimo "16 modules preventing a rakudo release" 18:19
AlexDaniel quickly changed it to that, yeah 18:24
18:42 perlpilot left
nine japhb: nope 18:46
yoleaux 17:24Z <japhb> nine: Did Inline::Perl5 intentionally start requiring Moose? (Noticed it no longer passes testing in my "rebuild the world and install all my favorite modules" script.)
AlexDaniel ugexe makes a good point that people probably upgrade their rakudo without upgrading installed modules 18:47
which makes me wonder what exactly should be done with modules that rely on buggy or experimental stuff 18:49
nine AlexDaniel: I know I do. Also while I'm usually not far behind in packaging rakudo for openSUSE, I haven't packaged new versions of modules yet.
AlexDaniel if we say that we should wait before actually introducing a change like that, then how much? 18:51
and should we wait at all
let's take FastCGI and the change to experimental pack as an example
lizmat AlexDaniel: so what was the problem there in the end ? 18:52
AlexDaniel lizmat: if I understand things correctly, then previously it was a run time error 18:53
c: 2018.05 if False { say pack('n', 25) }
committable6 AlexDaniel, ¦2018.05: «»
AlexDaniel now it's compile time
c: HEAD if False { say pack('n', 25) }
committable6 AlexDaniel, ¦HEAD(2fa08d5): «04===SORRY!04=== Error while compiling /tmp/knA1bF9zpg␤Use of pack is experimental; please 'use experimental :pack'␤at /tmp/knA1bF9zpg:1␤------> 03if False { say pack('n', 25) }08⏏04<EOL>␤ «exit code = 1»»
AlexDaniel FastCGI has no tests, so the run time issue was never noticed
lizmat ah, that, yeah. I considered that an improvement actually, mentioned it in the commit mesage
so I would consider that an issue with FastCGI 18:54
which apparently has not been working since Christmas 2015
(as around then we added the experimentality of pack)
installing ok, running no 18:55
or am I missing something ?
AlexDaniel that's correct, but now any user who was using FastCGI (or any of 3 modules that depend on it), once their rakudo is upgraded, will see issues (I think?)
I'm actually not sure… any users of FastCGI here? :) 18:56
lizmat so when was this pack / unpack run then? always, or just in some cases before?
in any case, I would suggest FastCGI add an "use experimental :pack" asap :-)
AlexDaniel actually, I guess you're right, these modules were broken since the moment pack was made experimental 18:58
then I guess I don't have a good example 🤷 18:59
:)
I think all changes related to hash randomization were with tests 19:00
so even if users upgraded their rakudo, they wouldn't run module tests without upgrading the modules first 19:01
so that was also a non-issue
same goes for Num precision changes
20:08 skids left
Geth nqp/nqp-in-the-browser: a4f1de15a8 | (Paweł Murias)++ | 5 files
[js] Disable stuff in the browser in an ugly manner

This allows parcel to bundle nqp::say('Hello World')		 20:31
20:58 MasterDuke joined 21:36 perlpilot joined 22:24 robertle left 22:59 [TuxCM] left
AlexDaniel hm, where can I find a repo for modules.perl6.org/dist/DBIx::NamedQueries ? 23:04
fwiw the module is failing this test: modules.perl6.org/dist/DBIx::Named...ails.t#L28
23:06 perlpilot left 23:08 brrt joined
timotimo is it because the message now gets made longer because of the longer type names? 23:25
AlexDaniel # Expected: Type check failed in binding to parameter '$obj_query'; expected DBIx::NamedQueries::Query but got Queries::Write::Failtest (Queries::Write::Failt...) 23:29
# Got: Type check failed in binding to parameter '$obj_query'; expected DBIx::NamedQueries::Query but got Queries::Write::Failtest (Queries::Write::Failtest.new)
:)
by the way, which commit changed that? 23:30
AlexDaniel 💤 23:32
timotimo bisectable6: class ThisName::Is::MuchToo::LongFor::Error::Messages { }; sub foo(Int $a) { }; foo(ThisName::Is::MuchToo::LongFor::Error::Messages.new) 23:35
bisectable6 timotimo, Bisecting by output (old=2015.12 new=2fa08d5) because on both starting points the exit code is 1
timotimo, bisect log: gist.github.com/de4dd26a3907bd664f...ce50616309
timotimo, (2016-02-18) github.com/rakudo/rakudo/commit/99...4283b48d0a
timotimo lizmat++ # making this error message smarter
23:45 brrt left

Powered by Cro and the Raku® Programming Language.

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

Thank you!