japhb <3 00:50
01:30 kjp left 01:34 kjp joined 02:51 djinni` left 02:59 djinni` joined 05:26 hurufu joined 05:33 hurufu left, hurufu1 joined 05:35 hurufu1 is now known as hurufu 06:55 hurufu1 joined 06:57 hurufu left, hurufu1 is now known as hurufu 09:36 kurahaupo left 09:50 kurahaupo joined
[Coke] Could probably rig up a blin run that did new as HEAD/rakuast, old as HEAD/original 10:09
... ah, not exactly, because none of the raku's are built from scratch with rakuast. 10:10
Geth rakudo/lizmat-1: 3dc0a1a58a | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Make 6.e sprintf %e format compatible with C

Basically took the logic from NQP and adapted for use in RakuAST. The NQP implementation was limited to native nums, this implementation shouldn't.
10:46
rakudo/lizmat-1: de4d93e794 | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Handle %F in 6.e sprintf support

Using %F apparently indicates that Inf and NaN should be rendered in full capitals. Otherwise identical to %f.
11:24
11:34 kurahaupo left 11:47 kurahaupo joined 11:55 [Coke] left 12:13 hurufu left
Geth rakudo/lizmat-1: 4eb4323ef0 | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Fix for sprintf %f/F format in 6.e

If the value did not produce sufficient digits, make sure 0's are added to make up for the precision requested.
12:26
rakudo/main: b10adfb378 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.e/Formatter.rakumod
Make 6.e sprintf %e format compatible with C

Basically took the logic from NQP and adapted for use in RakuAST. The NQP implementation was limited to native nums, this implementation shouldn't.
Also fix %F: using %F apparently indicates that Inf and NaN should be rendered in full capitals. Otherwise identical to %f. Also, if the value did not produce sufficient digits, make sure 0's are added to make up for the precision requested.
13:21
roast: 562ec6162a | (Elizabeth Mattijsen)++ | 2 files
Update 6.e tests of sprintf %e formatting
13:27
rakudo/lizmat-2: 2a5cc876c8 | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Fix sprintf %f in 6.e for very high precisions
13:37
13:37 [Coke] joined
Geth rakudo/main: eb91c164ff | (Nick Logan)++ | 3 files
RakuAST: silent-replace cross-compunit class reload in 'our' scope

Installed zef couldn't install anything under `RAKUDO_RAKUAST=1`, dying with `Redeclaration of symbol 'CompUnit::Repository::Staging'`: a `CompUnit::DependencySpecification.new(:short-name<...Staging>)` literal in `Zef::Client` gets harvested as a precomp runtime dep, so loading the precompiled module preloads Staging. Client's ... (35 more lines)
14:10
rakudo/main: 9e341da642 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Merge pull request #6185 from ugexe/ugexe/rakuast-cross-compunit-class-reload

RakuAST: silent-replace cross-compunit class reload in 'our' scope
14:15 hurufu joined
ugexe i need to find a way to get CURS into core 14:23
there is something weird going on with CURS, precomp, and type caching
i looked at zef precomp files and noticed CURS being pulled in. this doesn't happen if i change a `--> IO::Path` in CURS to `--> IO::Path:D` 14:24
14:24 librasteve_ joined
ugexe seems like IO::Path (without :D) may not be getting hit (and thus cached) during core compile. when zef installs itself it loads CURS which seems to also act as the source of IO::Path used later in zef 14:26
Use of uninitialized value of type RakuAST::Node::CannotLiteralize in string context. 14:32
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in any has-compile-time-name at src/Raku/ast/name.rakumod line 519
bunch of these warnigns during RAKUDO_RAKUAST=1 make install
new warnings 14:33
14:38 hurufu left
ugexe lizmat i assume it was related to your changes but i'm not really sure 14:43
the warnings that is
15:05 hurufu joined
lizmat ok, I hadn't realized these were new 15:29
15:30 hurufu left 15:31 hurufu joined 15:43 hurufu left
lizmat ugexe: ok, so that's weird 15:44
$!expr.literalize // nqp::die('Name ' ~ $!expr.DEPARSE ~ ' is not compile-time known')
so either $!expr.literalize returns something that is defined, or it dies
I don't see how it can return something that is *not* defined
perhaps // doesn't work like we think it does at that time? 15:45
15:47 hurufu joined
lizmat I've tried several things, but none of them worked... 16:08
adding RAKUDO_LITERALIZE_DEBUG shows a few trees being literalized, but they should be all ok 16:09
do we have a way to fatalize the warning at that stage of bootstrapping ?
Geth rakudo: lizmat++ created pull request #6186:
Fix sprintf %f in 6.e for very high precisions
16:16
16:49 hurufu left
Geth rakudo/lizmat-2: 13a70b6a1e | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Fix sprintf %f in 6.e for very high precisions (Part 2)
17:33
rakudo/lizmat-2: cf6ae67824 | (Elizabeth Mattijsen)++ | 2 files
Move 6.e sprintf format error handling to actions

And make it use the intended error message for it, rather than an AdHoc error.
17:39
lizmat m: use v6.*; dd sprintf("%d", 0 | 1) 17:42
evalable6 any("0", "1")
lizmat so, do we deem that to be a Bug or a feature?
m: use v6.d; dd sprintf("%d", 0 | 1) 17:43
evalable6 (exit code 1) Directive %d not applicable for value of type Junction ((any(0,
1),).Iterati...) in format '%d'
in block <unit> at /tmp/DzbhgKOGrE line 1
lizmat feels like a feature to me, fwiw 17:44
problem before was really that sprintf() was implemented in NQP, and NQP doesn't have Junctions
in 6.e, sprintf basically generates a Callable, and calls that 17:45
ShimmerFairy My first reaction is that it should be allowed, since that's generally what you expect Junction arguments to do, *and* I don't think a sprintf user would generally expect it to print un-C-like types. 17:50
lizmat well... I *was* thinking of adding a Rat type... but yeah :-) 18:10
18:12 MasterDuke joined
Geth rakudo/lizmat-2: 03748865b1 | (Elizabeth Mattijsen)++ | src/core.e/Format.rakumod
Make 6.e sprintf check arguments against format

And produce the expected error message if they don't match, instead of the binder throwing because the number of arguments doesn't match
18:31
19:08 MasterDuke left
Geth rakudo: ugexe++ created pull request #6187:
RakuAST: suspend precomp-dep recording across $*REPO chain setup
19:46
20:00 rakkable left 20:01 rakkable joined 21:06 hurufu joined
Geth rakudo/main: 081e4ba066 | (Nick Logan)++ | 3 files
RakuAST: suspend precomp-dep recording across $*REPO chain setup

resolve-unknown-repos's `need()` of a custom CUR class was being recorded as a precomp dep of the module currently being compiled. The legacy frontend has a suspend/resume mechanism for this on Perl6::World; RakuAST had no equivalent and Process.rakumod's call site was $*W-gated, so under RakuAST the protection silently ... (8 more lines)
21:14
rakudo/main: 05c18fa15f | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Merge pull request #6187 from ugexe/ugexe/rakuast-suspend-precomp-deps

RakuAST: suspend precomp-dep recording across $*REPO chain setup
ugexe how can github.com/rakudo/rakudo/commit/8b61f16776 not be revision gated? 21:34
i meant github.com/rakudo/rakudo/issues/2362 21:38
lizmat well, the commit just made sure we won't regress 21:43
it's just a test
or are you saying that we should retain the faulty behaviour in 6.e ? 21:44
ugexe is it expected that switching on rakuast for a working program will silently make it behave differently? 21:47
maybe it is i dunno, but i wouldnt expect it i dont think
Geth rakudo/lizmat-2: c42088579d | (Elizabeth Mattijsen)++ | src/core.e/Format.rakumod
Format.render is an implementation detail
ugexe you've actually fallen victim to this yourself 21:51
github.com/rakudo/rakudo/commit/b2...ff77cbba9d
which is part of the cause of github.com/rakudo/rakudo/issues/6183 21:52
21:59 hurufu left 22:08 ShimmerFairy left, ShimmerFairy joined
Geth rakudo/lizmat-2: 6 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 22:33
rakudo/lizmat-2: 58afc38046 | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Restore faulty sprintf format specification handler in 6.e

No idea how that got lost
22:42