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:11 lucasb left 00:29 pamplemousse left 02:07 vrurg left 02:08 vrurg joined 02:37 pamplemousse joined 03:18 klapperl left 03:21 klapperl joined 03:35 AlexDaniel joined 03:44 pamplemousse left 03:49 pamplemousse joined 04:56 pamplemousse left
AlexDaniel .tell patrickb so are these needed in the point release? github.com/perl6/nqp/pull/566 github.com/rakudo/rakudo/pull/3078 05:18
yoleaux AlexDaniel: I'll pass your message to patrickb.
06:58 patrickb joined
patrickb .tell AlexDaniel: Those changes are fixes for the big spaces-in-path PRs. Those were not part of 2019.07. So as long as we don't want to get the spaces-in-path PRs into the point release as well we have to leave out those fixup PRs. 07:17
yoleaux patrickb: What kind of a name is "AlexDaniel:"?!
05:18Z <AlexDaniel> patrickb: so are these needed in the point release? github.com/perl6/nqp/pull/566 github.com/rakudo/rakudo/pull/3078
patrickb .tell AlexDaniel Those changes are fixes for the big spaces-in-path PRs. Those were not part of 2019.07. So as long as we don't want to get the spaces-in-path PRs into the point release as well we have to leave out those fixup PRs. 07:18
yoleaux patrickb: I'll pass your message to AlexDaniel.
patrickb nine: I suspect reproducibility is flapping: travis-ci.org/rakudo/rakudo/jobs/5...1620#L2725 08:02
nine: That build was on a WIP branch I was doing build system work on. I think the failure was not caused by the not-yet working build system in that branch at the time. 08:03
nine: Congratulations to you getting married! I hope you'll have a great day tomorrow (despite the heat) and a good start! 08:05
nine patrickb: thank you very much :) 08:17
The reproducible-builds.t failure is...worrying :/ 08:18
patrickb: at least I can repro it here 08:27
08:29 AlexDaniel left
nine Looks like comp units get added to the bytecode in random order 08:32
patrickb That means that the test you added has already shown to be valuable. 08:35
nine Yes :) Though I probably should have made it more aggressive 08:42
09:46 robertle joined 10:04 Guest1109 left 10:08 rba[m] left 10:09 AlexDaniel` left
|Tux| Rakudo version 2019.07-90-gee584d299 - MoarVM version 2019.07-32-g85ce8ecc1
csv-ip5xs0.691 - 0.700
csv-ip5xs-205.083 - 5.222
csv-parser22.077 - 22.567
csv-test-xs-200.425 - 0.448
test6.393 - 6.879
test-t1.731 - 1.735
test-t --race0.789 - 0.799
test-t-2028.262 - 29.527
test-t-20 --race8.954 - 9.234
 10:22
10:49 AlexDaniel` joined 11:02 TreyHarris left
timotimo gist.github.com/timo/a98f91b754ed6...11fa04f326 - who has a lot of RAM free and wants to see the shape of a big, big precomp job? 11:11
anybody want to see if things are precomped multiple times? i think it's precompiling the same thing mulitple times actually 11:12
anyway, my browser is having trouble with it
11:14 TreyHarris joined
lizmat timotimo: I've had the feeling that things get precompiled multiple times for a long time, but haven't been able to put my finger on it 11:22
11:23 Guest92358 joined, rba[m] joined
nine lizmat: non-reproducible builds may have contributed to that 11:23
timotimo i'm not entirely sure why the output looks like that exactly 11:26
11:26 Guest37021 joined
timotimo like, so many unindented stagestats outputs 11:26
i'll post the patch so people can poke around while i'm afk
gist.github.com/timo/33435e201cefa...820c30f25c 11:27
oh
if $RMD isn't set, it always prints $err afterwards 11:28
probably want to throw that out for this patch
nine patrickb: oddly enough, I've so far failed to reproduce the reproducibility issue on my laptop despite running the test for an hour 11:36
Ah, finally! 11:41
12:58 Voldenet left 13:03 Voldenet joined, Voldenet left, Voldenet joined 13:16 x[LGWs4x4i]uG2N0 joined 13:25 pamplemousse joined 14:06 lucasb joined 15:43 robertle left 15:45 patrickb left 15:54 patrickb joined 15:55 discord6 left, discord6 joined, discord6 left, discord6 joined 15:59 discord6 left 16:00 discord6 joined
timotimo oh, hm, i wonder if it only looked like it was precompiling multiple times because the process was outputting the $err afterwards always 16:38
that could very well be the case
so no easy wins there? :(
Geth rakudo: dcf8c16d43 | (Patrick Bƶker)++ | 3rdparty/nqp-configure
Bump nqp-configure

More reliably detects nmake.		 16:43
nqp: 8f71baff8b | (Patrick Bƶker)++ | 3rdparty/nqp-configure
Bump nqp-configure

Make nmake detection more robust.		 16:46
vrurg jnthn: ping? 17:03
jnthn vrurg: pong
vrurg With regard to github.com/perl6/problem-solving/issues/74 ā€“ any objection for a new operator ():: which would construct a Stash object from it's argument? 17:04
jnthn Uh...yes, I really don't like that.
vrurg jnthn: why? The point is to fix HUGE issue about exports. 17:05
And ():: is a shortcut similar to %()
jnthn ===SORRY!=== 17:06
P6opaque: no such attribute '@!dispatchees' on type Routine in a Scalar when trying to get a value
This is surely a bug anyway?
(Missing decont of the invocant.)
vrurg Yes
But why a Routine must be exported as a scalar? 17:07
And Stash is a good candidate to store values as-is, no conterization/deconterization
jnthn Why must it? It's the use of %(...) or {...} hash constructors that are itemizing there. Just use `Map.new('&foo' => &bar)`? 17:08
vrurg Right the way a symbol table must behave.
Map deconts everything. If you export a $foo ā€“ you'll get it deconted in the target.
jnthn m: my $a = 42; my %m := Map.new(:$a, :2b); %m<a>++; say %m;
camelia Cannot resolve caller postfix:<++>(Nil:U); the following candidates
match the type but require mutable arguments:
(Mu:U $a is rw)

The following do not match for other reasons:
(Bool:D $a is rw)
(Bool:U $a is rw --> Bool::Falseā€¦
jnthn Huh 17:09
m: my $a = 42; my @l := List.new($a, 2); @l[0]++; say @l;
camelia (43 2)
jnthn *sigh* No, Map is meant to be to Hash as List is to Array.
It's meant to preserve containerness, not remove it. So *that's* what needs fixing.
jnthn wonders how that hasn't been noticed until now 17:10
At least now I know why I was so confused by the issue. 17:11
vrurg Let's assume Map work as expected. Anyway, re-exporting with Map.new( MyModule:: ) is ugly
People won't use it because %{ MyModule:: } looks prettier. 17:12
timotimo šŸ—ŗļø{ MyModule:: } 17:13
jnthn I think one of the synopses proposed a re-export mechanism that is applied at the point of a `use`, fwiw, that probably avoids the custom EXPORT logic for that purpose 17:14
vrurg metacpan.org/pod/release/HINRIK/Pe...odules.pod 17:15
:EXPORT tag?
jnthn Yes, that's the one. I'd thought it was called REEXPORT, but not, EXPORT, which is nicer 17:16
vrurg But in either case, I would consider preventing Stash from conteinerization. Why would it need it in first place? Just because it inherits from Hash? 17:17
jnthn m: module Foo { }; $foo::a = 42; # so this works?
camelia ( no output )
jnthn (Or more to the point, that needing to work is why it inherits form Hash, not Map) 17:18
vrurg m: module Foo { }; $Foo::a = 42; say $Foo::a; 17:19
camelia 42
vrurg m: module Foo { }; $Foo::a = 42; say $Foo::a.VAR.^name;
camelia Scalar
vrurg m: module Foo { }; Foo::a = 42; say Foo::a.VAR.^name; 17:20
camelia 5===SORRY!5=== Error while compiling <tmp>
Preceding context expects a term, but found infix = instead.
Did you make a mistake in Pod syntax?
at <tmp>:1
------> 3module Foo { }; Foo::a =7ā5 42; say Foo::a.VAR.^name;
vrurg m: module Foo { }; Foo::<a> = 42; say Foo::a.VAR.^name;
camelia Could not find symbol '&a'
in block <unit> at <tmp> line 1
jnthn Foo::a is a listop call
vrurg m: module Foo { }; Foo::<a> = 42; say Foo::<a>.VAR.^name; 17:21
camelia Scalar
vrurg And this is definitely not the right thing. Moreover, I would say that $Foo::a.VAR must not be a Scalar because it is vivified with a constant. But if its: $Foo::a = $foo ā€“ then it must be a scalar, as expected. 17:22
jnthn I don't think Stash should be in the business of looking at the keys and deciding whether to bind or assign based on that. 17:23
Whether the value is bound or assigned is a property of whatever puts stuff into the stash 17:24
So the `constant` declarator binds. In fact:
vrurg And this this paradigm I think sub EXPORT ( --> Stash ) { ... } makes total sense. And ():: would serve not only for creating a stash from a list, but, say, for ("MyModule"):: dynamic resolution.
m: module Foo { }; Foo::<a> := 42; say Foo::<a>.VAR.^name;
camelia Int
jnthn m: module Foo { constant $a = 42 }; say $Foo::a.VAR.^name;
camelia Int
jnthn It's bound even though it has the `$` sigil, 'cus that's what `constant` does
vrurg Ok, that's better
I'll fix Map then. 17:25
17:26 AlexDaniel joined
jnthn Part of the problem with ():: is that ::() (already given to indirect lookups) would be the most natural thing for a stash constructor, since like %() and friends the "sigil" is out the front. 17:26
vrurg But then it still would be great to have an op for Map.
jnthn Yeah, don't disagree there. List gets `,`
vrurg jnthn: Consider ():: from the point of view of MyModule::, MY::, etc. They all return Stash. So, as ::() resolves to a module, ("Module"):: resolves to a symbol table of it. A shortcut for ::("Module").WHO 17:28
I don't really insist, but it seems logical to me.
And extremly easy to implement, breaks no spectests.
jnthn Yeah, but it also violates the principle of avoiding endweight 17:29
Same reason s/foo/bar/g became s:g/foo/bar/ in Perl 6
vrurg But it's not :: attached to (), it's an op on its own. 17:31
Somehow I like the idea of it. ;)
jnthn Well, Map(...) is only one char more than (...):: 17:33
Geth Ā¦ problem-solving: AlexDaniel assigned to jnthn Issue Mechanism for Reusing Function Definitions in NativeCall github.com/perl6/problem-solving/issues/75 17:34
vrurg But ::("Module").WHO longer and looks worse.
jnthn Does ::("Module"):: not already work? 17:35
vrurg Anyway, what I can't come up with is a good operator for Map. Something as simple as comma list. 17:36
m: module Foo { our $foo }; say Foo::.keys;
camelia ($foo)
vrurg m: module Foo { our $foo }; say ::("Foo")::.keys;
camelia ()
vrurg Because:
m: module Foo { our $foo }; say ::("Foo")::.^name
camelia Foo
vrurg Where it was expected to be Stash. Perhaps it's a bug. If so, then ():: wouldn't really make sense. 17:37
jnthn I think that is a bug, yes 17:44
I expected Stash there too
vrurg Any good idea for map operator? I'm stuck. Any variant coming into my mind is bad for one reason or another. 17:45
jnthn No; TimToady++ is good at these things :) 17:48
Ah, I'm late for dinner. D'oh. bbl o/
vrurg jnthn: o/ 17:50
vrurg is summoning lizmat ;) 17:51
lizmat you rang ?
vrurg Not for daemon to know it! ;) 17:52
Commit 8b106374d ā€“ do you remember what was the reason for deconting all values in Map?
lizmat well, some people have demonized me on different platforms :-)
because a Map is supposed to be immutable ? 17:53
vrurg lizmat: But a value is a Scalar ā€“ it would remain immutable. 17:54
lizmat ?
no, a value is not a Scalar 17:55
a Scalar contains a value
the value of a Scalar can change
vrurg m: my $f = 42; my $a := 1,2,$f; say $a[2].VAR.^name; $a[2] = 11; say $a[2] 17:56
camelia Scalar
11
vrurg m: my $f = 42; my $m := Map.new( [a=>1, foo => $f] ); say $m; say $m<foo>.VAR.^name
camelia Map.new((a => 1, foo => 42))
Int
vrurg And of course: 17:57
m: my $f = 42; my $m := Map.new( [a=>1, foo => $f] ); say $m; say $m<foo>.VAR.^name; $m<foo> = 11; # BOOM!
camelia Map.new((a => 1, foo => 42))
Cannot change key 'foo' in an immutable Map
in block <unit> at <tmp> line 1

Int
lizmat if you ask me, the bug is really in the handling of List
vrurg lizmat: If you look at the above discussion with jnthn, Map is a good thing to be used for sub EXPORT, but it can't be because it deconts and breaks export of scalar.
lizmat then use a Hash ? 17:58
vrurg lizmat: on the contrary, Hash conteinerzies its values. It breaks export of Subs. ;) 17:59
lizmat yuck
vrurg The only solution for a re-exporting is manual iteration over re-exported symbols and binding them to a hash values. Nah!.. 18:00
I also think that if you throw a Scalar into a map ā€“ it's Scalar which has to be immutable, not its value.
lizmat bisectable6: dd Map.new( (a => my $ = 42) ) 18:01
bisectable6 lizmat, On both starting points (old=2015.12 new=dcf8c16) the exit code is 0 and the output is identical as well
lizmat, Output on both points: Ā«Map.new((:a(42)))ā¤Ā»
vrurg Say, if I throw an object of own class into a map ā€“ I can chnge object's content, not the map and not the object in it.
lizmat m: dd Map.new( (a => my $ = 42) )<a> = 666
camelia Cannot change key 'a' in an immutable Map
in block <unit> at <tmp> line 1
lizmat bisectable6: dd Map.new( (a => my $ = 42) )<a> = 666
bisectable6 lizmat, Bisecting by exit code (old=2015.12 new=dcf8c16). Old exit code: 0
vrurg lizmat: this is the change: github.com/rakudo/rakudo/commit/8b106374d 18:02
bisectable6 lizmat, bisect log: gist.github.com/fbd368248c821836be...7e9e75f4cd
lizmat, (2017-07-09) github.com/rakudo/rakudo/commit/48...7a64427b4e
vrurg github.com/rakudo/rakudo/commit/8b...998b90R312 to be more precise.
lizmat feels to me that one is ?
vrurg Ah, sorry, overlooked. 18:03
lizmat that diff had a decont before and after ??
this is in 6.d
vrurg The bisected one is the right commit. 18:04
lizmat so changing this now, may cause issues
vrurg And the comment states it was a temporary fix.
lizmat well, if you want to change it back, please make sure you spectest it and have blin to a run 18:05
*do
FWIW, this problem *only* exists if you want to export scalars, atm, right? 18:06
vrurg Let's see what happens. As a workaround it could be 6.e thing, though I wouldn't like overloading the code with version checks.
lizmat otherwise you could use a Map
vrurg Sorry, don't get you on this. Use for what?
lizmat for export
vrurg As I wrote above, Map.new( ('$foo' => $Module::foo) ) will decont the value and you'd get the value of $Module::foo exported, not the container. 18:07
This is my current primary point of trying change this Map behavior. 18:08
18:09 travis-ci joined
travis-ci Rakudo build errored. Patrick Bƶker 'Bump nqp-configure 18:09
travis-ci.org/rakudo/rakudo/builds/563171041 github.com/rakudo/rakudo/compare/e...f8c16d43ad
18:09 travis-ci left
lizmat well, I think you're going to change the behaviour of a very general data structure to solve a very specific problem 18:09
the whole export mechanism is still very underdeveloped 18:10
I think energy would be better spent in finding a better way to do exports, presumably syntactic sugar wise
do you have a gist of the code that doesn't do what you want ? 18:11
vrurg github.com/perl6/problem-solving/issues/74 18:12
18:13 pamplemousse left
vrurg lizmat: the point is that whatever syntax sugar is there, sub EXPORT provides the best possible flexibility. A syntax would reduce the need in using EXPORT but won't avoid it altogether. 18:13
I'll see if spectests would be significantly affected. 18:14
I was proposing above to make Stash be like Map used to be before that commit. But jnthn stands against it backing it with good reasons as always. :) 18:15
lizmat note that the deconting was done for a reason then 18:16
18:16 chloekek joined
vrurg I looked into the ticket. Strangely, it's not covered by a test. At least, greping for 131722 finds nothing in the specs. 18:22
I'll see what can be done. The problem in ticket was definitely a bug. 18:23
18:31 pamplemousse joined
vrurg .tell TimToady could you come up with an idea for a Map operator like those we have for List,Array, and Hash? 18:40
yoleaux vrurg: I'll pass your message to TimToady.
vrurg lizmat: irrelevantly to key content, $map<foo> = 1; complains even if key foo contains a Scalar. I think this is what you would consider the right thing. ;) 18:49
[Coke] waves. 18:51
18:52 llfourn left
dogbert17 [Coke]: have you had time to tinker with your RPi 4 yet? 18:55
lizmat vrurg: changing ASSIGN-KEY would work 18:57
vrurg That's what was probably been done previously. I didn't have time to investigate details, just have thrown away all deconts. 18:58
spectest is passed but for single test. Not bad, I think.
lizmat vrurg: but not being able to assign to it because of ASSIGN-KEY blocking that, shouldn't be an issue for your use case > 19:01
?
vrurg lizmat: absolutely not. It's the value to be kept intact which matters. 19:02
So, it looks like an ideal solution, so far.
lizmat what does?
lizmat has lost you, I think
vrurg The one where Map doesn't decont it's values. 19:03
We still have the immutability as you see it. And we have something to keep object as-is without any mangling with containers. 19:04
But now it looks like you may be right about List still allowing asignment into a Scalar element. The consistency demands it to fail same way Map does. 19:05
lizmat or the other way around 19:06
changing the List behaviour will break a *lot*
vrurg lizmat: I would leave it up to you to decide. I'm happy to finally implement a local project with all the fixes I made so far. ;) 19:09
vrurg is unlucky to bump into every single bug possible...
lizmat of course, if that project is an ecosystem module, you won't be able to publish it :-(
as most systems out there won't have those semantics
vrurg lizmat: actually, I'm talking about the fixes I've merged into the core. 19:11
lizmat ah, ok 19:12
vrurg And the export bug is gonne be one of them. That's pretty annoying to get the language fail on > operator because it's dispatcher is wrapped into a Scalar. And there was no workaround for it.
Sorry for being unclear. I'm always like this, unfortunately, But today I'm heavily multitasking on top of it. :) 19:15
lizmat no worries 19:16
19:19 patrickb left, klapperl left
Geth rakudo/Map-keeping-containers: 2ee82afe6e | (Elizabeth Mattijsen)++ | src/core/Map.pm6
Keep containers in Maps
 19:23
rakudo: lizmat++ created pull request #3081:
Keep containers in Maps		 19:25
19:25 klapperl joined 19:26 MasterDuke joined
vrurg lizmat: That was fast... ;) 19:29
19:30 MasterDuke left
lizmat yeah, but I also found just found out why we can't do it 19:30
vrurg I'll test it later today.
lizmat Map is currently an value type, so Map.new( <a b c d>) will only occur once in a QuantHash / ObjectHash 19:31
vrurg If it works I would be glad to get an op for Map creation similar to %() to provide a nice-looking and recommended solution for sub EXPORT.
lizmat now it is no longer avalue type
so every Map.new( <a b c d> ) will become a separate key in QuantHashes / ObjectHashes
this is what the test was testing
vrurg How do I coerce a map into a QuantHash then? By flattening? 19:32
lizmat what good would that do ? 19:33
you would lose the values ?
vrurg Baggy -> Map -> Baggy?
lizmat Baggy only has Int's as values ? 19:34
vrurg As far as I remember. Could be Mixy for that matter.
lizmat that only has Reals for values. You wanted a Scalar container as a value, no ? 19:35
Geth rakudo/Map-keeping-containers: 42d6e0bc1f | (Elizabeth Mattijsen)++ | src/core/Map.pm6
Map is no longer a value object now
 19:36
vrurg lizmat: I'm just considering possible consequences. Trying to see it from different points of view. Like: ok, I've got what I wanted. How would this impact other cases?
lizmat well, I have a Tuple module in the ecosystem, that provides a fully immutable List 19:37
perhaps I should also make a TupleMap module, that provides the current Map semantics
so people could use that if the change in Map semantics turns out to be a problem for them 19:38
vrurg BTW, github.com/perl6/problem-solving/issues/71 blocks github.com/perl6/problem-solving/issues/47 and R#1203. 19:39
synopsebot R#1203 [open]: github.com/rakudo/rakudo/issues/1203 [data types] Would be nice to have an easy way to work with SetHashes and its kin
19:40 robertle joined 19:45 pamplemousse left 20:12 patrickb joined 20:25 lucasb left
Kaiepi i'll probably pullreq making IO::Handle usable with fds as a wip at some point since the refactoring needed to make it so fds can be represented as a class like IO::Path is turning out to be a much bigger job than i expected 20:30
[Coke] dogbert17: nope, it's in a box on my desk 20:32
right next to my non-functioning 3d printer.
Kaiepi everything is hardcoded to accept paths, when fds may also be acceptable.. something ridiculous like a dozen new ops needed to fix this
20:33 cygx joined
lizmat Kaiepi: how does that work out on Windows ? 20:34
20:36 robertle left
Kaiepi lizmat, what i have so far just uses uv_file for fds, which is HANDLE on windows 20:36
lizmat as long as there is an equivalent on Windows, Perl 6 was intended to be less Unix centric :-) 20:37
cygx lizmat: re Map, I think it could remain a value type - but if you put a container into it, the map's identity will depend an that container's identity, not the contained value's...
lizmat nope... can't do 20:38
that same logic would apply to Lists then as well
and we decided that can never be the case
cygx just note that the current situation has a weird asymmetry between List and Map 20:45
m: .say for List.new(1,2) === List.new(1,2), Map.new(<a b>) === Map.new(<a b>)
camelia False
True
20:46 pamplemousse joined
lizmat cygx: that's because Map is currently a value object 20:47
and List is *not*, because List can contain containers, of which the contents can change
m: say List.new(1,2).WHICH; say Map.new(<a b>).WHICH 20:48
camelia List|72589392
Map|1D1E394B79B012432E825E63107ECF18F5FBB5BD
lizmat m: say List.new(1,2).WHICH.^name; say Map.new(<a b>).WHICH.^name
camelia ObjAt
ValueObjAt
cygx and that's weird, because I'd expect List <-> Array as Map <-> Hash
lizmat well, I'd expect List to also be a value object
but because List is being used internally for all kinds of tricks, that is not an option 20:49
so github.com/rakudo/rakudo/pull/3081 would make Map get the same behaviour as List in that respect 20:50
fwiw, I do think we need completely immutable types for List and Map in core 20:54
hence: modules.perl6.org/dist/Tuple:cpan:ELIZABETH 20:55
cygx I'd have expected List/Array and Map/Hash semnatics to more or less mirror the my $a/my \a sematics 20:59
one allows re-binding, the other doesn't 21:00
both allow assignment is they happened to be bound to a container
but I'm also happy to let this be Someone Else's Problem ;)
*if they happened 21:01
21:03 chloekek left 21:32 cygx left
Geth nqp/release-2019.07.1: 0fece14494 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get point release fixes
 21:54
rakudo/release-2019.07.1: e18b4f3be0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION
Bump NQP to get point release fixes
22:04 patrickb left 22:32 pamplemousse left 23:56 pamplemousse joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!