Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:59 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Add support for the "N$" index feature 00:59
travis-ci.org/rakudo/rakudo/builds/518009216 github.com/rakudo/rakudo/compare/4...5053891b8b
00:59 travis-ci left 01:10 Kaiepi left 01:13 Kaiepi joined 01:16 lucasb left 01:23 MasterDuke joined 01:24 MasterDuke left, MasterDuke joined 01:57 epony left 02:09 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix issue with "u" 02:09
travis-ci.org/rakudo/rakudo/builds/518014416 github.com/rakudo/rakudo/compare/7...00a12557ae
02:09 travis-ci left 03:14 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make sure the EVAL doesn't show in any backtraces' 03:14
travis-ci.org/rakudo/rakudo/builds/518017982 github.com/rakudo/rakudo/compare/d...02335dd972
03:14 travis-ci left 03:18 epony joined 03:39 Xliff joined
Xliff \o -- Please look at gist.github.com/Xliff/ce03bf24897d...14c35fd3d5 03:39
If you've seen it before, please look again. It's been updated. 03:40
05:24 robertle left 05:54 vrurg left
ugexe you change just one file, but that changes the checksum/sha1 of the entire distribution auth/ver/api 06:08
that used to not be the case, and I suppose it would have made things much faster in this case. but at the cost of being wrong
the old way treated (when using -Ilib) every single file as its own distribution 06:10
so changing one file would not change the sha1 used to seed the other distributions
stale precomps being loaded was a problem, but not obvious because most people's stale precomps probably still did what they wanted 06:13
Xliff OK. 06:15
But from an end-user standpoint, all I am seeing is MUCH slower execution of code. 06:16
I can understand being right.
But at that cost point... that's enough to force a change of language.
ugexe at least the problem is obvious now, unlike before
Xliff True.
But still. That's a bad setback, regardless.
ugexe require everything as files then
Xliff Which brings me to another problem.
I am using a lot of -I directives. I expect if I compile everything in one dir, then if I -I that lib dir, I should not expect those files to be recompiled again. 06:17
This is not the case. I switch CWD to another directory and still include that same dir via -I stuff is still recompiled 06:18
I think this is contributing to the larger recompile times.
ugexe are you using aboslute paths so the path fed to -I is always the same, and not differing based on being a relative path?
Xliff No. Relative paths.
Why should that matter? 06:19
I would expect -I to convert relative to absolute, in that case.
ugexe because of the path is used to seed the sha1 then ./ and ././ are not the same
Xliff Why is the path using a relative path? 06:20
I can understand -I being used to see the SHA, but in that case, convert relative to absolute to avoid this problem.
It should be as simple as man7.org/linux/man-pages/man3/realpath.3.html 06:21
ugexe it probably does, so i wouldnt focus too much on that. im just spit balling on a complex topic 06:22
Xliff OK. Apologies on this end. My frustration is leaking through. 06:23
I am trying to second guess design decisions that I have no clue about.
I just came up with a use-case (maybe) -- CURI staging?
ugexe the recompiling related to -I is likely because the next repo in the chain's id is taken into account when seeding its own id 06:24
so if the repo chain is not the same for two runs then the same -I $PATH will have two different ids
Xliff OK. So if I start recompiling using absolute paths, I shouldn't see this issue?
But now you are telling about repo chain, so even doing abs paths may not help??!? *headdesk* 06:25
ugexe if you run all the commands with absolute paths and using the same -I flags in the same order I think it shoudl go away
e.g. do -I dep1 -I dep2 -I dep3 for everything, even if it doesnt depend on e.g. dep2
Xliff Well. The -I flags are dependencies.
Ew. 06:26
ugexe they are CompUnit::RepositoryFileSystem (each one)
-I dep1 -Idep2 -Idep3 vs -I dep1 -Idep2 <-- dep1 will have a different id between these two 06:27
Xliff OK. So in my case I have to do -I /home/cbwood/Projects/p6-Pango/lib -I /home/cbwood/Projects/p6-GtkPlus/lib -I /home/cbwood/Projects/p6-SourceViewGTK for *all* of the project dirs listed?
Eesh!
So compiling Pango: -I /home/cbwood/Projects/p6-Pango/lib -I /home/cbwood/Projects/p6-GtkPlus/lib -I /home/cbwood/Projects/p6-SourceViewGTK/lib
Even though the last 2 are unnecessary. 06:28
Same with GTK and same with SourceView?
ugexe i suspect it will work
Xliff Hahaha!
You suspect? OK. I'll be yo huckleberreh.
If you see me tomorrow, remind me to recompile *everyzing!* 06:29
ugexe++ # For dealing with my insanity.
ugexe good luck
Xliff Yeah. Thanks. I think I'll need it.
ugexe there is a CURI staging btw 06:30
rakudo/lib/CompUnit/Repository/Staging.pm6
Xliff Yeah. 06:40
I think you told me about that one.
Because there is no way I can unleash p6-GtkPlus on the masses without severe warnings, and a faster install path. 06:41
Takes over 2100 seconds to do a full compile on all modules.
lizmat Files=1254, Tests=87994, 386 wallclock secs (20.74 usr 6.61 sys + 2765.40 cusr 230.44 csys = 3023.19 CPU) 07:14
07:30 robertle joined
lizmat afk for most of the day& 07:40
Xliff m: say 1 xx 2, 3 07:56
evalable6 (1 1)3
Xliff m: say |(1 xx 2), 3 07:57
evalable6 113
Xliff m: say |(1 xx 2), 3, 4
evalable6 1134
Xliff m: say (|(1 xx 2), 3, 4)
evalable6 (1 1 3 4)
Xliff m: my ($a, $b, $c, $d) = (|(1 xx 2), 3, 4); say ($a, $b, $c, $d) 08:16
evalable6 (1 1 3 4)
Xliff m: my ($a, $b, $c, $d) = (|(1 xx 2), 3, 4); say $a; say $b; say $c; say $d
evalable6 1
1
3
4
11:08 AlexDaniel left 12:25 robertle left 12:27 robertle joined 12:46 Kaiepi left, Kaiepi joined 12:49 MasterDuke left 13:12 Kaiepi left
|Tux| Rakudo version 2019.03.1-184-gdc02335dd - MoarVM version 2019.03-75-g9b1b60f66
csv-ip5xs0.700 - 0.704
csv-ip5xs-205.976 - 6.126
csv-parser22.301 - 23.483
csv-test-xs-200.435 - 0.437
test7.546 - 7.643
test-t1.773 - 1.863
test-t --race0.886 - 0.890
test-t-2030.394 - 30.618
test-t-20 --race11.565 - 11.775
 13:14
13:16 Kaiepi joined 13:19 vrurg joined 13:38 Kaiepi left 13:40 Kaiepi joined 14:50 Kaiepi left 14:54 Kaiepi joined 15:15 Kaiepi left 15:16 Kaiepi joined 15:30 vrurg left 15:33 vrurg joined 15:35 vrurg left 15:36 vrurg joined 15:47 robertle left 16:22 dogbert17 left 16:27 Kaiepi left 16:30 Kaiepi joined 16:31 AlexDaniel joined 16:52 Kaiepi left 16:55 Kaiepi joined 17:16 vrurg left, vrurg joined 17:27 lucasb joined 17:42 Kaiepi left 17:46 Kaiepi joined 18:01 lgtaube left 18:19 lgtaube joined
ugexe on some systems (such as cygwin) libuv's uv_cpu_info can return 0 items, which means nqp::cpucores would be 0. However -- ThreadPoolScheduler does a division by nqp::cpucores which would result in Inf when using that 0 18:32
i believe ThreadPoolScheduler might be better using `my $... = nqp::cpucores() || 1` 18:33
Geth nqp: 3921b1e6c7 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
[JVM] Be more picky when trying to rmdir or unlink

Throw an exception when trying to rmdir something that isn't a directory or when trying to unlink a directory.
This mimics the behaviour of MoarVM. Also there is a spectest in S32-io/mkdir_rmdir.t that expects a complaint from an attempt to rmdir a non-existing directory.		 18:51
tony-o that seems sane 19:01
19:43 Kaypie joined
Kaiepi writing the script to bisect R#2824 for me ended up being too big a pain in the ass so i'm doing it manually 19:50
synopsebot R#2824 [open]: github.com/rakudo/rakudo/issues/2824 [BLOCKER] Cannot install zef (or run much of anything without MVM_JIT_DISABLE)
19:50 Kaypie left 20:31 sortiz joined 21:16 sortiz left 22:39 ggoebel 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!