🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
Geth rakudo/main: 563addbb92 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Make unknown method calls on strings mention the string

This makes it easier to trace errors, specifically with RakuAST's
  "visit-children" being called on a Str, when it should have been
a RakuAST::StrLiteral		 10:18
Geth rakudo/main: c3df563b1f | (Elizabeth Mattijsen)++ | src/core.e/Formatter.pm6
Another round of Formatter tweaks

  - makes S32-str/sprintf.t run all its tests without throwing
  - fixes issues with using type objects as values
  - fixes issues with Inf / -Inf as values		 11:13
ugexe I managed to get naive support for long paths on windows sort of working. Rakudo builds and installs modules, and I can create and stat directories with long names. However, my work is all a mess of hacks void of any cohesiveness so I’m not sure it’s useful for anything other than confirming it can work but will be kind of a slog to implement cleanly 11:43
Now I think it might be easier to implement the path normalizing logic in nqp or moarvm since that doesn’t invoke e.g. CUR path specs and whatnot 11:44
s/invoke/involve/ 11:45
basically just: is it a windows system, is it an absolute path? If yes to both then prefix the path with \\?\ and change all / to \ 11:46
Geth rakudo/main: d3372c8d11 | (Stefan Seifert)++ | 4 files
RakuAST: support traits on signature declarations
 12:49
nine Much harder to get right than expected but oh boy was it worth it! 872 passing spectest files :) 12:50
lizmat whee!
ugexe: that sounds eminently doable at the MoarVM level 12:51
ugexe: any idea of JVM would be coping with this? an nqp solution would help there as well, no?
nine m: my constant name = 'TestName'; class ::(name) { } # You gotta be kidding me 13:01
camelia ( no output )
lizmat m: my constant name = 'TestName'; dd class ::(name)
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse class definition
at <tmp>:1
------> ant name = 'TestName'; dd class ::(name)⏏<EOL>
expecting any of:
generic role
nine m: BEGIN my $foo = "Foo"; class ::($foo) { } # At least it's not you know...really smart 13:03
camelia ===SORRY!===
Name ::($foo) is not compile-time known, and can not serve as a package name
lizmat seems like something RakuAST will fix :-)
Geth rakudo/main: 40aa1605b7 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Streamline X::Str::Sprintf::Directives::BadType

  - make it handle Mu as a value correctly
  - simplify value reporting in case of a type object		 13:04
rakudo/main: 10cc908d9c | (Elizabeth Mattijsen)++ | src/core.e/Formatter.pm6
Make sure format is reported with Formatter errors
nine lizmat: IIRC you have introduced something that lets me check whether we have a compile time value? 13:14
lizmat .literalize
returns Nil if there is no compile-time value
nine Why does it swallow all exceptions? That makes it harder to find the This element has not been resolved. Type: RakuAST::Term::Name 13:25
lizmat I wanted to make it an easy to use method
nine But this makes it less easy instead :) 13:26
lizmat well, for core developers perhaps?
nine I only get Nil instead of an esay to understand exception message
lizmat if it's about a RakuAST node that is not supported yet, you *will* get the class name 13:27
on STDERR
nine That does not require catching exceptions much less all of them. 13:28
lizmat if you have an expression with something variable in it, would you want the exception to be thrown? 13:29
that means that anytime you call .literalize, you will have to mind that it could throw
that felt LTA to me 13:30
nine Absolutely yes! I expected it to give me a literal. It didn't. With the exception swallowed I have to actually find and patch scary CORE setting code just to find out what went wrong. This is a problem especially for non-core developers. 13:31
lizmat why?
you ask an AST whether it could become a constant, Nil means it couldn't, and you go on with your business ? 13:32
nine And the error I got is a basic RakuAST mistake: I just tried to literalize a node without giving it a chance to resolve names first.
But it can become a constant. In fact it is my constant name. It doesn't get more constanty than that.
lizmat the other reason for catching the exceptions, is to be able to abort a multi-level deep expression without needing to backtrack 13:33
as we don't have gather/take there
nine backtrack? 13:35
lizmat { a => 42, b => { c => 137, d => $a } } 13:37
it would fail at the $a
or any level deeper
BTW, couldn't it be that just in Term::Name, it decided to throw Nil ? 13:39
because it couldn't resolve?
nine It can resolve. It just hasn't yet. Which is exactly what the exception would tell me. 13:43
lizmat wouldn't jnthn's work not prevent that issue?
brb
nine no
ugexe Lizmat: jvm and js backends should already just work. I haven’t tested that but that is my understanding after looking at a jvm source and the nodejs source 13:55
lizmat nine: well, if you want to work on the .literalize logic, be my guest 14:07
afk&
nine The whole thing turns into quite a mess quickly anyway. The correct canonicalization of names containing expressions requires us to evaluate to constant's values. This requires us to resolve the names contained in expressions contained in names. Since names are quite common in programming we need to do this pretty much right away. 14:15
Geth rakudo/main: b593dc9a89 | (Stefan Seifert)++ | 3 files
RakuAST: Support constant expressions as part of names
 14:26
rakudo/main: 0df71cfc31 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: actually apply traits to all variables in signature declarations

Trait nodes keep track of whether they have been applied to a target or not, so we must not share the same nodes across multiple targets.		 14:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!