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.
jnthn Sleep time o/ 00:02
vrurg jnthn: o/ 00:04
02:24 squashable6 left
Geth rakudo: jstuder-gh++ created pull request #3042:
Issue 3041: Propagate laziness in KeyValue/Pair Iterators		 02:26
02:29 squashable6 joined 07:08 patrickb joined 07:12 robertle joined
Geth rakudo: abbd1285db | (Jeremy Studer)++ | src/core/Rakudo/Iterator.pm6
Propagate laziness in KeyValue/Pair Iterators

Propagate the laziness value from the base iterator used.
Otherwise using .kv, .pairs, or .antipairs on a lazy list would cause it to be eagerly evaluated.		 07:13
rakudo: 20e74837a9 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core/Rakudo/Iterator.pm6
Merge pull request #3042 from jstuder-gh/lazy_kv_pair_iters

Issue 3041: Propagate laziness in KeyValue/Pair Iterators
07:15 giaccard joined 07:44 giaccard left
Geth nqp: Kaiepi++ created pull request #564:
Implement NativeCall wide string support		 08:55
rakudo: Kaiepi++ created pull request #3044:
Implement NativeCall wide string support		 09:01
10:38 HarmtH left
[Tux] Higer values because I'm actually working on this box now 11:38
Rakudo version 2019.03.1-683-g20e74837a - MoarVM version 2019.07
csv-ip5xs0.708 - 0.711
csv-ip5xs-205.506 - 5.599
csv-parser36.395 - 37.125
csv-test-xs-200.429 - 0.452
test7.391 - 7.554
test-t1.796 - 1.934
test-t --race0.901 - 0.939
test-t-2030.117 - 30.719
test-t-20 --race9.697 - 9.817
12:54 squashable6 left 12:56 squashable6 joined 12:57 lucasb joined 13:10 HarmtH joined 13:27 dogbert17 joined 13:50 Necro^Byte joined 13:57 pamplemousse joined
AlexDaniel vrurg: so how come changes to the VERSION location and stuff is not in MoarVM? 15:00
vrurg: is it planned?
15:05 robertle left
AlexDaniel vrurg: ohā€¦ now that I look at it, the VERSION file is at the same place in NQP 15:07
but not in rakudo. So what's the plan?
15:10 pamplemousse left, pamplemousse joined 15:17 pamplemousse left 15:34 patrickb left, pamplemousse joined 15:46 MasterDuke joined 16:05 Necro^Byte left 16:06 pamplemousse left 16:10 pamplemousse joined
vrurg AlexDaniel: I don't have plans for MoarVM because it has almost nothing in common with nqp and rakudo. 16:11
And I don't know moar well enough to mangle with anything in it.
With regard to nqp, you're right, I missed it. 16:13
16:13 pamplemousse2 joined
AlexDaniel so I'm here suffering from the change to the location of the VERSION file and you're saying that there are no plans to make it consistent across all repos??? 16:13
vrurg rakudo/nqp share a lot in common ā€“ hence, the common nqp-configure for both and similar structure. 16:14
moar is much apart from them that I don't see how could it benefit from using nqp-cofnigure for build.
AlexDaniel ok but file locations should be consistified, no? 16:15
jnthn What was the motivation for moving it in Rakudo? 16:16
vrurg AlexDaniel: if we consider all three as parts of a single project ā€“ yes. 16:17
AlexDaniel ā€¦ here we go again
ugexe tbh it was weird having VERSION in the root of the repo
16:18 pamplemousse left
AlexDaniel they're not a single project, but put the goddamn file in the same place, please 16:18
vrurg jnthn: to unify loading of files used as sources for other files. I.e. it was considered to be a template.
AlexDaniel: that's not a problem to move it in MoarVM, but having a single file in tools/templates/ would be weird. 16:19
jnthn Well, yes.
vrurg Will do it for NQP though. 16:20
jnthn Does it being there help something practically
?
AlexDaniel OR, alternatively, put it back in rakudo
though then there are also *_REVISION files 16:21
AlexDaniel shrugs
vrurg jnthn: Nothing else but having a single place for all sources.
ugexe so the help is lowered barrier of entry for build system development 16:22
vrurg AlexDaniel: there is nothing preventing it to be in the root of the build tree. Considering moar, that would then make more sense from your point of view. 16:23
My point is that: one place where to look for data files. If I search for anything ā€“ I do it in tools/templates. Less clogging of the root too.
jnthn: BTW, is it mandatory for EVAL to have own CORE loaded? Can't it use it's context CORE? 16:26
AlexDaniel vrurg: that's a good point, I also want to search for anything in the same directory, regardless of which repo I'm in :) 16:27
same location I mean
vrurg: also, how do I run a 6.c stresstest? 16:29
vrurg AlexDaniel: I would ask for some of your patience for MoarVM then. It would be better to use templating for it too. The downside is that NQP::Macros is tied to NQP::Config. Breaking this link require time which I don't have much for now.
AlexDaniel vrurg: sure I can wait, that's why I'm asking if there's a plan for it to be changed 16:30
vrurg make stresstest doesn't work? 16:31
AlexDaniel vrurg: so I `git checkout 6.c-errata` in t/spec, then I run `make stresstest` and it says `make: *** No rule to make target 't/spec/spectest.data', needed by 'm-stresstest5'. Stop.`
vrurg Argh... -errata branch needs the file. 16:32
AlexDaniel vrurg: I added you to the list of people who can push to *-errata branches 16:33
though you're probably already in the team core 16:34
ah, actually you're not
vrurg I can commit to roast. That's enough, I guess?
AlexDaniel vrurg: no, *-errata branches are protected so that people don't push there accidentally 16:35
like, ideally we shouldn't be pushing new commits there at all, except for some minor stuff
ok the permission thingy is fixed now for sure :) 16:36
oh, and roast also has a VERSION file, interesting 16:37
vrurg Then 6.d-errata would need the spectest.data too. Must not forget it. 16:39
Anyway, anyone with advise on EVAL and CORE?
16:43 robertle joined
TreyHarris Is there a rakudo equivalent to 'perldoc -l' for locating the source file of a library that is use-able? 16:53
(Or a Perl 6 equivalent in general?)
16:58 pamplemousse2 left
ugexe what if its not in a file? 17:00
you query for things through the appropriate CUR
TreyHarris ugexe: I get that. But a best-effort should be possible, no? "When I do `use Foo`, what are you loading up and can you tell me so I can (try to) look at it to be sure it's what I think it is?" 17:02
ugexe $*REPO.resolve(CompUnit::DependencySpecification.new(:short-name<Foo>))
TreyHarris Yep, that's what I had. I'd hoped it was in CLI form already. 17:03
Since #| and #= aren't implemented fully so we get docs.perl6.org-style signatures, unless the maintainers have thought to put signatures in their POD, going to the source is often the only way to figure out what's going on with something you're using because the SYNOPSIS just isn't thorough enough 17:04
ugexe zef locate Foo
TreyHarris (I guess #| and #= implementation is separate from introspective doc extraction, but they're related?) 17:05
ugexe zef locate lib/Test.pm6
etc
TreyHarris thanks
Geth roast/6.c-errata: 2d096a6c27 | (Vadim Belman)++ | spectest.data
Add spectest.data to conform with the latest changes in Rakudo build.
 17:10
vrurg AlexDaniel: now working with my master. 17:12
AlexDaniel Missing test file: t/spec/S11-repository/cur-candidates.t 17:13
Missing test file: t/spec/S11-repository/cur-current-distribution.t
should it be this way?
I guess these two should not be listed then? 17:14
ugexe probably not. they came immediately after 6.d. they could be considered 6.c except they expose some new API via new .candidates method 17:16
kawaii AlexDaniel: I noticed an unused `perl6::codename=` parameter from `perl6 -V`, is this for release 'codenames' 17:17
vrurg ugexe: they're not in -errata. My fault, I overlooked these two.
ugexe s/probably not/probably/
vrurg Took spectest.data.6.c from 2019.03
AlexDaniel kawaii: there were codenames at some point, and luckily they were dropped :) 17:18
kawaii: so that's what that field is for, I guess 17:19
c: Bicycle say 42
committable6 AlexDaniel, Ā¦Bicycle: Ā«No build for this commitĀ»
AlexDaniel oh well to bad 17:20
c: ZĆ¼rich say 42
committable6 AlexDaniel, Ā¦ZĆ¼rich: Ā«42ā¤Ā»
AlexDaniel too* # what's up with my typing :) 17:21
vrurg: btw github.com/rakudo/rakudo/blob/mast...t-messages 17:22
vrurg AlexDaniel: I know... Look at most of my commits. :) 17:23
Sorry for this one. 17:24
AlexDaniel vrurg: a lot of them have a dot in the title 17:25
not a big deal, but still :) 17:26
vrurg Dot? I don't see it mentioned in the paper. 17:27
I usually more worried about the explanatory part.
AlexDaniel ā€œDon't end commit subjects with periods for ease of viewing a commit log by title. If there are multiple sentences in the subject, you can have a period, but do not have one at the end of the commitā€
vrurg Right... Thanks. 17:28
BTW, RT #12345 needs to be changed for conforming github standards. 17:30
Geth roast/6.c-errata: ddcbd2b6ab | (Vadim Belman)++ | spectest.data
Removed two missing tests from spectest.data

They were added with version 6.d.		 17:31
vrurg Ok, 6.d will need some manual work. It's spectest.data wasn't frozen. 17:32
afk for a while. 17:34
TreyHarris AlexDaniel: That is confusing... it means the first-line subject shouldn't end with a dot, right? If you have a long explanation in a subsequent paragraph (separated by \n\n), that explanation can (and should) still end with a period, yes? 18:02
ugexe just put a bullet in front of it, then its ok 18:11
AlexDaniel TreyHarris: yeah 18:22
vrurg: I think the VERSION file should go back to its previous location, just for now 18:23
external things may very well depend on it (e.g. releasable sakefile does, even though it's not really external anymore), so we better not move it around on a whim 18:25
and having a VERSION file in the root seems like an unwritten convention in perl6 projects
at least in moar, nqp, roast and not anymore rakudo :)
greppable: VERSION 18:26
greppable6 AlexDaniel, 1183 lines, 167 modules: gist.github.com/52a49d78ae2e1dc725...7015b22f38
AlexDaniel fwiw I'm all for changing it, just in a more documented and consistent fashion 18:28
ugexe depending on implementation details? tsk tsk
i say this as the biggest depending on-er of implementation details :P
why not just create a symlink to the new location for now 18:29
vrurg AlexDaniel: I now tend to agree from another point of view too: when I get some sources I usually look for any version-related information in the root. So, maybe for VERSION it makes more sense to keep it there. 18:31
AlexDaniel ugexe: maybe. I don't see symlinks in git repos very often, so I don't know if there are any pitfalls
vrurg ugexe: a symlink solves nothing, but might have impact on Windows builds.
ugexe sake doesnt run on windows
or releasable or whatever 18:32
it means items depending on the implementation detail have more time to adapt
AlexDaniel sure, but anyone cloning the repo will see a symlink in the root, so hmmā€¦ 18:33
ugexe if any of those items are actually being run on windows, then i'm wrong
what difference does it make if they see a file or a symlink
AlexDaniel ā€œIn windows (msysgit), the symlink is converted to a text file with a path to the file it points toā€
not claiming it's a big problem, I'm just scared :D 18:34
ugexe so are we trying to solve an issue with windows apps consuming VERSION or what?
because i dont think thats a real issue
vrurg I'm avoiding symlinks in sources in general. Neither I see why VERSION location should be a problem at all. If moving it into tools/templates causes more techincal problems than it solves (and it solves nothing) ā€“ I see no reason not to keep it in the root. 18:36
ugexe goland nor node have VERSION files in their roots 18:37
vrurg AlexDaniel: do you have an idea which version of spectest.data would serve best for 6.d-errata? 18:38
AlexDaniel 6c: say $*PERL 18:39
committable6 AlexDaniel, gist.github.com/d475b782d8fcf095be...4bf2200661 18:40
AlexDaniel vrurg: the one in 2018.11 release maybe?
that's the first rakudo that defaults to v6.d
ugexe: where do they have it? And do they have it at all? 18:41
ugexe dunno, its not in their root which is all im concerned with tbh
AlexDaniel github.com/golang/go/commit/7f416b...1e6052b2d6 18:42
ugexe generating it only in the release is also acceptable 18:43
ideal even
AlexDaniel it's not exactly generated, as far as I can see: github.com/golang/go/commits/7f416...d6/VERSION 18:44
ugexe looks like its in the release branch? 18:45
AlexDaniel yeah they do it a bit differently, it seems like they have a release branch for every release
whereas we merge back to master after releasing 18:46
ugexe fwiw either way it seems wrong to have a VERSION file with some stale version between releases
AlexDaniel yeah it's kinda weird 18:48
I guess it should be generated for the released tar, yeah. But for now we should probably leave it be in the root 18:52
vrurg It's weird when it's referring to a released version. But it's ok if it gets bumped, I think. So, it would mention the version being developed now.
6.d-errata fails a lot on master... 18:53
Geth roast/6.d-errata: d90444a2ec | (Vadim Belman)++ | spectest.data
Add spectest.data

The file is now considered roast property and the latest Rakudo builds depend on it.		 18:59
AlexDaniel vrurg: yeah I see that, will figure it out soon 19:47
19:56 Kaiepi left 20:26 squashable6 left 20:29 squashable6 joined, ChanServ sets mode: +v squashable6 21:15 MasterDuke left 21:18 Kaiepi joined 21:24 MasterDuke joined 21:55 Kaiepi left 22:16 Kaiepi joined
[Coke] waves from the Dulles airport, delayed flight for 3.5 hours. AMA. 22:32
AlexDaniel [Coke]: how's the chair? 22:36
lizmat: github.com/ajs/perl6-Math-Sequences/pull/151
jnthn Heh, I read it as ANA and thought that was the airline to blame for the delay :P 22:39
MasterDuke m: BEGIN my int $a = 4; # i don't undertand this 22:44
camelia 5===SORRY!5=== Error while compiling <tmp>
An exception occurred while evaluating a BEGIN
at <tmp>:1
Exception details:
5===SORRY!5=== Error while compiling
Lexical with name '$a' has wrong type. real type 8 wanted type -1
aā€¦
[Coke] alex; suprisingly comfy 22:49
I'm not near an outlet, though, taking my chances.
22:58 Kaiepi left
vrurg jnthn: ping 23:21
23:24 Kaiepi joined 23:26 lucasb left
jnthn vrurg: pong 23:39
vrurg I wonder if a setting loaded with --setting ought to have !CORE_MARKER set. I guess it's not. 23:40
The problem is that chained SETTING pseudo include symbols from outer lexical and I don't see how to filter them out correctly yet. 23:41
jnthn !CORE_MARKER should only really go into CORE.setting
The intention of it was to mark out "this is CORE.setting"
We could, in theory, figure that out in a totally different way
Though a symbol like that was cheap to look for, and easy to implement 23:42
Any --setting=Foo where Foo is not CORE should not get !CORE_MARKER; the whole point of it was so we could find CORE! 23:43
vrurg It's not a problem and easy to grasp. I just wonder how to get it working correctly for EVAL and have only EVAL-related setting symbols reliably.
jnthn EVAL's "setting" is the scope in which EVAL was called, really 23:44
vrurg It's perhaps the only problem left to solve before my PR is ready for merge. Just one damn spec test failing. ;)
jnthn But I've never really thought of it as a setting in the SETTING:: sense
AlexDaniel fwiw there's a new blocker-like thingy here: github.com/rakudo/rakudo/issues/3045
it'd be nice if somebody takes a look while I'm doing other stuff
jnthn AlexDaniel: Will see if I can take a look tomorrow 23:45
vrurg EVAL code is wrapped into own CORE loaded by load-lang-ver method.
jnthn That might be more accident than intentional...
vrurg This actually allows for: use v6.e; EVAL q|use v6.c;|
AlexDaniel yeah I'm going to need some sleep today anyway, and I still want the VERSION file movedā€¦ so tomorrow is about perfect :) 23:46
jnthn I'm a tiny bit surprised that works...
vrurg AlexDaniel: If I get time for it. I need to get it done with pseudo-pacages, eventually.
jnthn Is it covered in roast?
vrurg jnthn: I was thinking about preventing this ā€“ it's really simple and things work afterwards. But what for? 23:47
No, it's not covered.
jnthn Actually I'm very surprised it works, in that EVAL is also meant to see language tweaks
(Those in effect at the point it is called)
And I'm not sure how those can really both apply. 23:48
vrurg But it is used in rakudo t/02/rakudo/99-mist.t
jnthn What does `use v6.c` in an EVAL really imply?
What outer does it get?
vrurg It gets CORE.setting, as it should.
And then that is wrapped into EVAL's outer context. 23:49
jnthn Wait...what?
Wrapped as in forceouterctx?
Or does it copy the symbols out of CORE.setting into an intermediate frame? 23:50
vrurg Yep.
No, it doesn't copy.
jnthn Ufff...that's a great way to make EVAL really slow :)
vrurg Its forceouterctx
jnthn Oh, that's even scarier, isn't it?
vrurg ForeignCode.pm6
jnthn If I'm understanding you right, this must be a complete threading disaster 23:51
vrurg To my limited knowledge, it doesn't look so. But I'm underinformed yet. ;)
I guess it is. Just a moment, there was an issue on this.
R#1391
synopsebot R#1391 [open]: github.com/rakudo/rakudo/issues/1391 EVAL is not thread safe
jnthn 'cus there's only one CORE.setting UNIT frame, and if we're then doing `forceouterctx` on it and we do two concurrent EVAL's...
vrurg Ok, I could try evade loading CORE, it's as simple as return from load_setting if $*INSIDE-EVAL. If you think this should work I could try Zoffix samples from the ticket. 23:53
I would still have own UNIT though. Not sure if this affects anything. 23:54
*It would
BTW, it also shares the compiler. That could be even bigger problem, as I see it. 23:56
jnthn There's certainly some other thread-safety issues 23:57
I note loading_and_symbol_setup certainly looks if we have an outer_ctx 23:58
vrurg EVAL provides outer_ctx
But grammar is calling load-lang-ver implicitly and that loads CORE 23:59
jnthn Yeah, so I see...trying to figure out what happens *then*
m: my $x = 42; EVAL 'say $x'
camelia 42
jnthn m: my $x = 42; EVAL 'use v6.c; say $x'
camelia 42

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!