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.
01:06 cognominal joined 01:09 cognomin_ left 02:17 dogbert11 left 04:07 committable6 left, statisfiable6 left, bloatable6 left, nativecallable6 left, evalable6 left, coverable6 left, squashable6 left, notable6 left, reportable6 left, tellable6 left, shareable6 left, greppable6 left, releasable6 left, unicodable6 left, benchable6 left, bisectable6 left, quotable6 left, benchable6 joined 04:08 evalable6 joined, ChanServ sets mode: +v evalable6, squashable6 joined, nativecallable6 joined, ChanServ sets mode: +v nativecallable6, releasable6 joined, epony left 04:09 tellable6 joined, committable6 joined, ChanServ sets mode: +v committable6 04:10 shareable6 joined, ChanServ sets mode: +v shareable6, unicodable6 joined, ChanServ sets mode: +v unicodable6, coverable6 joined, epony joined, greppable6 joined, bloatable6 joined, notable6 joined, bisectable6 joined, ChanServ sets mode: +v bisectable6 04:11 reportable6 joined, quotable6 joined, ChanServ sets mode: +v quotable6 04:12 statisfiable6 joined
[Tux] www.perlmonks.org/?node_id=11106712 ← vague Inline::Perl5 question 06:32
nine It's possible that the destructor tests won't pass on all machines. It's really hard to reliably get an object garbage collected. 06:38
AlexDaniel: jnthn finding you more and more unreasonable was more a message about him than about you. Narrowing of view and lessened empathy are unfortunate results of stress and it reads to me like jnthn recognized those in him and prescribed himself some time off. 06:45
AlexDaniel I see, I misread then 06:46
thanks 06:48
07:12 [Coke] left
discord6 <Vendethiel> AlexDaniel: as a single data point, CoffeeScript’s file extension is .coffee and we’ve never really had people complaining 07:45
<Vendethiel> It’s still 1 or 2 chars shorter though.
AlexDaniel Vendethiel: I see. From extension-stats: ".coffee": 165, ".coffeescript": 2 07:48
there are actually many long extensions that are a bit shorter
like .haddock => 3042 07:49
there's also .egg-info => 4525 with a dash
ok I meant not shorter but with less results :) 07:50
discord6 <Vendethiel> I don’t know many people who used .coffeescript (some used .js.coffee though)
<Vendethiel> (I’m not saying .t.rk/.rk.t is a similar case) 07:55
AlexDaniel I don't mind slightly longer extensions, but they'll be one of the longest out there, and as I said, I just want to know why we're going that route 07:56
the dealbreaker with short extensions was .rkt, but it no longer is for me 07:57
that is, we surely can't use .rkt, but we can use .t or even .rk.t
we were so focused on avoiding bikeshedding that the actual productive discussion was cut off short, and we didn't even get to see all the options. For example, I don't remember seeing .rk.t 08:00
though I'm still not sure how I feel about the similarity of .rk itself to .rkt 08:06
08:12 robertle joined
lizmat [Tux]: with already PerlMonks(TM) "useful" Anonymous Monk answer 08:37
if people wonder why Perl has such a bad name, it's interactions like that :-( 08:38
[Tux] true that
lizmat hmmm... just spotted something weird: 08:52
[Tux] Rakudo version 2019.07.1-357-gd00674b31 - MoarVM version 2019.07.1-241-gacb04a448
csv-ip5xs0.802 - 0.803
csv-ip5xs-206.429 - 6.902
csv-parser22.904 - 24.783
csv-test-xs-200.433 - 0.437
test7.554 - 8.166
test-t1.821 - 1.946
test-t --race0.944 - 1.000
test-t-2030.349 - 32.321
test-t-20 --race9.505 - 10.059
lizmat when I run "make spectest", processes appear as "moarvm" in the process list
when I run a single spectest with "perl6 t/spec/foo, it appears as "perl6" 08:53
what is "make spectest" doing differently ?
s/moarvm/moar/
08:56 SyrupThinker joined
lizmat So I was looking at the setting up of Proxy, and realized why you can *not* use the first parameter to access the proxy: it's put inside of a Scalar for *every* access 09:05
so I thought I'd remove that: gist.github.com/lizmat/71c32456b5d...33f3a8ea6a
alas, this makes t/spec/S03-operators/buf.t eat all of available memory *very* quickly 09:06
specifically subbuf-rw, which indeed returns a Proxy object
jnthn: what is the rationale of putting stuff inside of a Scalar for every access ?? 09:07
jnthn lizmat: Same as any .VAR, I think 09:10
(To prevent the thing becoming unwrapped) 09:11
lizmat unwrapped ?
I mean, the first parameter is usually *ignored* in most of the Proxy uses I've seen
jnthn Remember that self is decont'd, and if we passed in the Proxy itself, then it'd decont into the underlying value represented by the proxy, which would mean an infinite recursion 09:13
Well, it would on FETCH anyway
lizmat but if we're just passing a block, there is no self ? 09:14
ah, so you're saying, that *if* we use an actual method in the Proxy setup, it *would* decont self, and thus cause the infinite loop 09:15
or anything with a $ I guess, only a \foo would not do that decont 09:17
jnthn Right 09:18
lizmat pity
hmmm... is there a reason why Proxy needs to be setup in the Bootstrap? 09:20
couldn't we do this in the setting ?
afk for 2 hours or so&
jnthn Maybe, if you can use a BEGIN block to sneak the invocation protocol in 09:32
10:29 [Coke] joined
lizmat jnthn: "Cannot invoke object with invocation handler in this context" does that ring a bell 11:46
(after having made Proxy a "normal" class and excising it from the bootstrap 11:47
gist.github.com/lizmat/90974d3d89f...62ff39c6cc
jnthn Maybe you discovered why it's in the bootstrap :) 12:12
I'm not convinced those are right? 12:13
Probably instead of the my $ = ... you need nqp::p6var
lizmat nqp::p6var ? 12:20
jnthn Hm, isn't that what is used in the NQP version? 12:24
How did it do the wrapping? You need to replicate that precisely. 12:25
lizmat my $var := nqp::create(Scalar); 12:26
- nqp::bindattr($var, Scalar, '$!value', $cont);
- nqp::decont(nqp::getattr($cont, Proxy, '&!FETCH')($var))
jnthn There you are 12:30
You can't use = to set up $!value, for one because you wrongly get a rw wrapper (though that may not matter), but mostly because = will decont its RHS
May not matter as in "probably doesn't prevent the example from working" 12:31
It's wrong for it to be rw
lizmat but, that's the code from the bootstrap
anyway, updated the gist: gist.github.com/lizmat/90974d3d89f...62ff39c6cc 12:32
jnthn Yes, I'm explaing why the code you have in your non-bootstrap version has different behavior to the bootstrap one
lizmat ok, so now I think I mimicked it completely
it builds ok, but that's because the settings themselves don't use any Proxy 12:33
the first time one is created, immediate hang and eating of memory at 1+ GB / sec
could it be because I use a "method" here? 12:34
in any case, the reason I wanted it to be lifted to the setting, is to add more smartness
like not having to create a scalar if the block's parameter for FETCH would not decont anyway 12:35
saving a scalar creation for *every* FETCH call
timotimo you're probably aware, but "hang and eat memory extremely fast" is almost always an infinite recursion
lizmat yeah, I got that ? 12:36
timotimo OK
i didn't read closely enough
lizmat it's probably trying to decont itself deconting itself
timotimo yeah that seems likely
lizmat it's just that I don't see how
timotimo don't forget you can attach a debugger to get a stacktrace
12:41 lucasb joined
lizmat hmmm... it's not recursing on a call to FETCH (unless it recursing in parameter binding of the FETCH 12:41
)
jnthn Could be, if it has to type-check it 12:50
Maybe needs a Mu throwing in the signautre somewhere
lizmat hmmm... 12:52
adding a Mu doesn't make a difference 12:53
jnthn I'd just leave it in BOOTSTRAP then
That or disassemble the bytecode of each one and read them to spot the difference
lizmat is close to giving up but will try just a bit longer :-) 12:54
how about adding a containerless Proxy in the E bootstrap 12:56
hmmm... looks like that adds another can of worms :-) 12:59
ok, end of exercise
jnthn This stuff is...delicate. 13:01
It wasn't easy to get it to work in the first place.
lizmat yeah, that's clear to me.... 13:15
14:29 robertle left 14:30 robertle joined
nine lizmat: make (spec)test uses ./perl6-m which is still a shell script, while the installed perl6-m is a compiled program 15:10
lizmat isn't that, eh, weird ? Or WIP ?
15:20 robertle left 15:24 robertle joined 15:29 robertle left 15:44 robertle joined
vrurg nine: is it a shell script? 15:44
⇒ file ./perl6-m 26-09-19 11:44:47 [problem-solving-103] 15:45
./perl6-m: Mach-O 64-bit executable x86_64
nine Oh, apparently not anymore 15:46
vrurg Ok, I was afraid something is missing. 15:47
nine It's not a shell script but it still launches moar 15:48
15:48 robertle left 16:16 dogbert11 joined
vrurg .ask patrickb can we have perl6-m in rakudo source not run moar but be linked against moar's dynlib, same as inst-perl6-m? 16:23
tellable6 vrurg, I'll pass your message to patrickb
16:28 MasterDuke joined 17:02 chloekek joined 17:08 robertle joined
AlexDaniel vrurg: fwiw, if you're thinking “we'll fix that later”, it's not good enough for me. I want to know exactly what will happen because I have no idea what you all have in mind, and most of the arguments I'm seeing are very assfetched 17:48
vrurg AlexDaniel: sorry, but I've nothing to add. To me the most compelling argument is that voting was in favor of this option. I would equally well accept any other voting results. All other my arguments are only to explain why my choice was in favor of long extensions. Though I also understand why you don't like them and share your view too. It's just so that I weigh and my scales are in favor of the long ones. 17:51
AlexDaniel vrurg: ok, hold on 17:52
vrurg: you agree with this? github.com/perl6/problem-solving/p...fR152-R154
vrurg AlexDaniel: yes. Might as well remove the part about deprecation and removal. Then people can choose what works better for them. 17:55
AlexDaniel what do you mean “yes” and “remove the part” at the same time
but that's right, you edit the PR and remove that part, yes 17:56
that's a good start!
then you define what'd be with `.t` 17:57
for example, if I open a ticket for some editor that doesn't have raku support, do I ask them to associate .t files too or not?
vrurg I'm not editing it because I'm not on the list. If you strongly opposed to the deprecation – propose it. But rejecting long extensions altogether? Nah, not now.
AlexDaniel that's literaly what I'm saying 17:58
did you even read my review?
because it doesn't sound like it
I think you do have the rights to change it, and if you don't feel comfortable then you can PR a change to the branch 17:59
we won't be voting on a PR that changes a non-master branch, obviously 18:00
vrurg I have the rights technically, but not "oficially". Anyway, I have a couple of urgent things to be done. And yes, I read your review. Perhaps need to re-read it because some details are lost now. 18:01
AlexDaniel because I'm not rejecting long extensions. I basically said you either: 1) expand more on long extensions 2) change them to short ones 3) remove extensions from the PR completely 18:02
so basically whatever you do right, I'll probably approve it… 18:03
and then there's a test thing, which is different
OK the only option I won't approve is denial 18:04
Geth_ problem-solving: 999684ba5d | (Moritz Lenz)++ | README.md
No more moritz reviewer

see github.com/perl6/problem-solving/p...-535629589 for context		 18:28
18:45 TreyHarris left
vrurg AlexDaniel: It's not really clear to me how to produce a PR for PR. I would just leave a comment. for that paragraph. 18:55
18:58 TreyHarris joined
AlexDaniel vrurg: the PR itself is this branch: github.com/perl6/problem-solving/t...th-to-raku 19:09
so you should be able to create a PR to change this branch
vrurg Ah, my habbit of forking repos plays bad to me. 19:10
[Coke]
AlexDaniel forking should be fine too 19:11
Geth_ problem-solving: vrurg++ created pull request #109:
Clarify the situation with .t extension		 19:28
vrurg AlexDaniel: ^ 19:29
AlexDaniel vrurg: unfortunately I'm falling asleep as I type this 19:34
buut
what does it mean for editors? 19:35
for example, if some editor is supporting .t6, when can it drop the support?
vrurg It means developer chooses what's appropriate for him. If intelliJ treats .t as perl – one can use .rakutest.
AlexDaniel not talking about that right now 19:36
vrurg For .t6 – yes, it can. Same as for .p6 and the rest.
AlexDaniel “`.t6` will continue to be supported for 6.e” yet tools will be dropping support for it?
previously I suggested writing something like
“Using `.t6` extension is discouraged, and tools should not include `.t6` when adding support for Raku. However, tools that already support `.t6` should continue doing so for the time being.” 19:38
vrurg AlexDaniel: depends on when dropping is ok. As stated later in the same section: "Around the time of 6.f, a `.p6` association
could be deselected by default, and perhaps dropped entirely by 6.g." That could be applied to .t6
19:38 MasterDuke left
vrurg AlexDaniel: good point about adding support for Raku, though. 19:39
As to dropping moment – I'll add it to .p6 part. 19:40
20:15 chloekek left
dogbert11 releasable: next 20:20
releasable6 dogbert11, Next release in ≈22 days and ≈22 hours. R6 is down. At least 4 blockers. Unknown changelog format
dogbert11, Details: gist.github.com/459037fa778f6daae6...99f8bfebf8
dogbert11 more than three weeks, I see
20:28 robertle left
Geth_ problem-solving/path-to-raku: 0de1d74e16 | (Vadim Belman)++ | solutions/language/PATH-TO-RAKU.md
Clarify the situation with .t extension

After carefully considering @AlexDaniel review, #108, and
  [some IRC chatting](colabti.org/irclogger/irclogger_lo...-26#l179),
I would like to propose to remove the part about `.t` deprecation. I do it with a some regret as this proposal would postpone the voting if accepted, but:
1. Tools currently supporting TAP are used to this extension. We can't ask all of them to produce the deprecation message for Raku only. 2. This would allow a user to choose the extension more suitable to the tools he/she is using and even up to his personal preferences. 3. In a way, this conform to TIMTOWTDI.		 20:45
problem-solving/path-to-raku: dd8dcd5b4e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | solutions/language/PATH-TO-RAKU.md
Merge pull request #109 from vrurg/path-to-raku

Clarify the situation with .t extension
21:22 AlexDaniel left 22:07 epony left 22:26 patrickb joined 23:08 epony joined 23:10 lucasb left
patrickb .tell vrurg It's not easily possible to replace the build perl6 runners with native executables. Reason: The C runners rely on the directory layout of a perl6 installation. In the build directory the files are lying around differently. Unless one creates a copy of src/vm/moar/runner/main.c and adapt it heavily there is no way to have a native executable that works in the build directory. 23:19
tellable6 patrickb, I'll pass your message to vrurg
vrurg ok :) 23:21
patrickb: did you see my question from tellable6 ?
patrickb The above was meant to be an answer. 23:22
Or did you mean a different question?
vrurg Yes, different. I didn't see tellable6 reporting to you. Neither it reported to me now. 23:23
.
patrickb tellable6 told me over in #moarvm 23:25
vrurg Ah, ok. And I was probably ignored because of instant reply. 23:26
patrickb So is there another question? 23:30
23:33 patrickz joined 23:36 patrickz left 23:38 patrickb 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!