|
🦋 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: 5f5fe4fe13 | (Stefan Seifert)++ | 2 files RakuAST Support adverbs on infixes Makes 3 zin 4 :x(5) equivalent to infix:<zin>(3, 4, :x(5)) |
05:33 | |
| roast: a07d730526 | (Stefan Seifert)++ | S03-operators/adverbial-modifiers.t Fix expected value in todo'ed test The stringified capture would contain the leading backslash if the test ran successfully. |
05:42 | ||
| roast: 87d20252ec | (Stefan Seifert)++ | S03-operators/adverbial-modifiers.t Skip todo'ed test that fails to compile on RakuAST While the old frontend would at least parse the construct, it has never been supported. No harm in making it fail straight out. |
|||
|
09:44
finanalyst joined
|
|||
| lizmat | 1085 | 09:58 | |
| so +16 so far this week :-) | 09:59 | ||
| m: my $a = ""; say Int.+"$a"() # feels to me the suggestions are a little too LLM like in this case | 10:43 | ||
| camelia | No such method '' for invocant of type 'Int'. Did you mean any of these: 'IO', 'fc', 'kv', 'lc', 'so', 'tc', 'uc'? in block <unit> at <tmp> line 1 |
||
| lizmat | m: say Int.""() # feels to me this should be a compile-time warning | 10:50 | |
| camelia | No such method '' for invocant of type 'Int'. Did you mean any of these: 'IO', 'fc', 'kv', 'lc', 'so', 'tc', 'uc'? in block <unit> at <tmp> line 1 |
||
|
11:08
finanalyst left
11:10
finanalyst joined
|
|||
| Geth | rakudo/main: bcb39d0b4c | (Elizabeth Mattijsen)++ | 5 files RakuAST: fix .? .+ .* dispatches This commit replaces the approach of specifying a special class indicating what type of dispatch to perform, with specifying the type of dispatch by indicating the Raku equivalent of it. So dispatch => '.?' # return Nil if method does not exist ... (19 more lines) |
11:35 | |
| rakudo/main: 06d11b591d | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod RakuAST: return "" on compilation errors inn ASTing when trying to syntax highlight a piece of Raku code |
11:49 | ||
|
12:13
finanalyst left
13:04
finanalyst joined
|
|||
| [Coke] | Started looking at my rakuast rakudoc ticket on a fresh rakudo. it's showing the classes of C< C<stuff> > as nested formatting codes - should the *parse* be saving the inner C<> as a formatting code or just a string? (since C<> is supposed to contain verbatim things) | 13:09 | |
| or is it saving all the potential formatting and intending to render the inner C<> as text instead? (guessing it should be the former) | 13:10 | ||
| lizmat | hmmmm are there other situations like that? | 13:11 | |
| I guess V< V< > > ? | 13:12 | ||
| [Coke] | m: qq|=begin pod\nC< C<a> >\n=end pod|.AST.say | ||
| camelia | RakuAST::StatementList.new( RakuAST::Doc::Block.new( type => "pod", paragraphs => ( RakuAST::Doc::Paragraph.new( RakuAST::Doc::Markup.new( letter => "C", opener => "<", closer… |
||
| [Coke] | (is there an better way to gen that class list? THough that is pretty easy) | 13:22 | |
| ... I can't believe after all those raku/doc commits that I just used "an" wrong. :) | 13:27 | ||
| lizmat | there better be an better way :-) | 13:38 | |
| Geth | rakudo/main: e007c70816 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Fixups.rakumod RakuAST: fix stringification of E< > Fixes #5618 |
13:52 | |
| [Coke] | lizmat++ | 13:53 | |
| Geth | rakudo/main: 6f687f10f7 | (Elizabeth Mattijsen)++ | 2 files RakuAST: fix rendering of C< > in pod and rakudoc Fixes #5617 |
14:33 | |
| rakudo/main: e16400b187 | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod RakuAST: in highlighting, wrap any errors in a Failure As to allow any renderer to inform users of the error in the source |
15:32 | ||
|
15:52
finanalyst left
16:02
finanalyst joined
16:20
finanalyst left
|
|||