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.
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/a4...9693cfa832 00:48
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2018....4-ge1929a4
AlexDaniel Geth: ver github.com/perl6/nqp/commit/e1929a...18d59903ac 00:49
Geth AlexDaniel, version bump brought in these changes: github.com/MoarVM/MoarVM/compare/2...5-g0c5f6e5
AlexDaniel mhm
c: a41c37c89f4^,a41c37c89f4 gist.github.com/AlexDaniel/8b745fd...85cadbd04c
committable6 AlexDaniel, gist.github.com/3015f5a6cbfedc8845...41b5ee6eda
AlexDaniel Unable to call postcircumfix $bt[ (Any) ] with a type object 00:50
Indexing requires a defined object
I'm going to bed soon, but there's something fishy going on there ↑
lizmat Files=1248, Tests=76067, 334 wallclock secs (15.33 usr 5.37 sys + 2337.89 cusr 219.52 csys = 2578.11 CPU) 08:16
|Tux| Rakudo version 2018.06-478-g37a30ab9b - MoarVM version 2018.06-431-g919e78ab1
csv-ip5xs0.955 - 0.969
csv-ip5xs-207.260 - 7.976
csv-parser23.512 - 24.398
csv-test-xs-200.442 - 0.452
test9.302 - 9.415
test-t2.065 - 2.084
test-t --race0.906 - 1.060
test-t-2036.238 - 36.727
test-t-20 --race11.719 - 12.260
 10:59
dogbert2 2.065 it's getting close ... 11:12
Ulti I still find it hard to know from the names what all of those are 11:14
AlexDaniel .tell lizmat can you fix S02-literals/quoting.t S03-operators/bag.t S03-operators/mix.t S03-operators/set.t ? 11:49
yoleaux AlexDaniel: I'll pass your message to lizmat.
Geth rakudo: 0979b77565 | (Jonathan Worthington)++ | src/core/Deprecations.pm6
Harden deprecation location handling code

It's possible to get an undefined back from `next-interesting-index`, which caused the slicing to blow up. The undef can happen because, as in various languages, inlining optimizations result in a backtrace with with some frames omitted. In the future, we plan to make MoarVM able to reconstruct a backtrace as if inlining had not taken place; in the meantime, this avoids the issue reported in #2235.		 17:12
synopsebot_ RAKUDO#2235 [open]: github.com/rakudo/rakudo/issues/2235 [regression][⚠ blocker ⚠] t/spec/S32-num/complex.t errata file is failing
jnthn .tell AlexDaniel I fixed #2235; verification welcome. 17:20
yoleaux jnthn: I'll pass your message to AlexDaniel.
tbrowder_ hi, #perl6-dev 17:45
i need some pod advice... 17:46
we currently don’t handle formatted code or paragraphs consistently 17:47
i know everyone wants a separate pod slang but i’m not sure if that helps very much other than cleaner separation of pod and “ambient” text. 17:49
i believe formatted text, being final markup that can’t be truly rendered in ascii, shouldn’t be parsed and identified as such in rakudo’s parser. any renderer, other than Pod::To::Text, should create the final results by parsing and implementing the formats 17:54
*formatted chars. 17:55
thoughts?
Rakudo would treat formatted code as ordinary text, and Pod::To::Text could just strip out all formatting. We could have something like Pod::To::Generic which would take raw formatted text and break a text chunk into two pieces: unformatted text and a separate formatted object similar to the current Pod::FormattedCode class. 18:01
* that should be Pod::FormattingCode 18:03
tbrowder_ [Coke]: hi, ^^^ 18:04
anyone watching at the moment? 18:08
.ask TimToady any thoughts on treating pod formatted text downstream from rakudo’s treatment? i.e. rakudo treats the format chars as ordinary text and leaves treatment to the renderers. 18:12
yoleaux tbrowder_: I'll pass your message to TimToady.
timotimo tbrowder_: can you properly tell when pod ends if you don't do proper formatting code parsing? what of multi-line formatting codes? 18:16
AlexDaniel` jnthn: cool, thanks! Will check soon 18:19
tbrowder_ from what i’ve seen in the trenches, i don’t think that’s a problem. but i could be wrong. the chunks could be diverted to paras instead of formatted code instances. 18:21
[Coke] tbrowder_: I'm having trouble following what the ask is here in IRC. is there a doc to read? 18:24
tbrowder_ right now just my ramblings above, plus a rakudo wiki article i’m working on. 18:25
tbrowder_ but all this is stemming from my current work on a pr to add some more specced pod handling. 18:26
tbrowder_ fc chunks don’t play well with othe pod. 18:29
other pod chunks on the p6 side.
tbrowder_ for one good case in point, tables currently can’t use formatted code blocks when parsing, but downstream rendering could do that, 19:06
jnthn Aren't the formatting codes that are allowed in a particular context configurable? 19:09
I'm a bit reluctant about the suggested change in that it moves away from one pass parsing though. At the same time, the Pod bits of the grammar last I looked seemed to have an amount of repetition and curious factoring. That may well be simple because they were written prior to various grammar features being available, and never updated. 19:10
otoh, I guess maybe tables are particularly horrible in terms of formatting codes in that I guess they can span multiple lines in a given column 19:11
Leading to needing per-column parse state 19:12
tbrowder_ i don’t have a good argument for this, but the current parse path tries to create some classes too early so some data, like the ‘#’ number alias for %config, is unavailable if formatted text is encountered. thus we end up with varying para combinations and inconsistent block handling in contents. handling PostScript seems kind of similar to me: text formatting is carried with the text until rendering. 19:26
i mean that we should handle formatted text roughly the same way: interpret it last. 19:29
gfldex m: BEGIN { say 'BEGIN' }; constant $s = Q:c⟨foo { say 'HERE' }⟩; say $s; 21:20
camelia BEGIN
HERE
foo True
gfldex does the block in the quote run at the right time?
[Coke] looks like. constants happen at BEGIN time, I think. 21:23
m: BEGIN { say 'BEGIN' }; constant $s = Q:c⟨foo { say 'HERE' }⟩; BEGIN say "there"; say $s; 21:24
camelia BEGIN
HERE
there
foo True
timotimo yes, constants run at BEGIN time, and the code inside the quotes is basically codegenned to be put in there with ~ ~ operator in between
gfldex the docs are wrong then 21:26
timotimo oh damn, got a link for us? 21:27
gfldex filing issue 21:28
filed as github.com/perl6/doc/issues/2279 21:32
also, Perl 6 is great. I just added a few lines to a script that would have filled halve a page in a lesser language. :) 21:34
timotimo oh, i personally refer to BEGIN time as compile time often, but clarifying can only help 21:36
gfldex when is BEGIN time for a module that is loaded with require? 21:37
timotimo precompilation bakes in the results of BEGIN time
if you run-time "require" a module, the compile-time of that module can be embedded in the run-time of the program that has the require in it 21:38
gfldex we got a "no precompilation" pragma. So you need to know if the module actually wants to be precompiled 21:40
it's all a bit blurry :)
timotimo right, but it comes with a lot of power :)
gfldex i filled a 2nd issue 21:44
gfldex sleep& 21:44
AlexDaniel basically set/bag/mix errata spectests is the only thing blocking right now 23:53
it's a relatively easy thing to fix but I'm out to bed now 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!