|
00:11
guifa2 joined
00:25
guifa2 left
00:46
lucasb left
02:16
finsternis left
03:16
sourceable6 left,
statisfiable6 left,
bloatable6 left,
linkable6 left,
benchable6 left,
shareable6 left,
quotable6 left,
squashable6 left,
unicodable6 left,
greppable6 left,
tellable6 left,
releasable6 left,
coverable6 left,
nativecallable6 left,
notable6 left,
reportable6 left,
bisectable6 left,
committable6 left,
evalable6 left
03:17
squashable6 joined,
coverable6 joined,
sourceable6 joined,
evalable6 joined
03:18
notable6 joined,
benchable6 joined,
committable6 joined,
linkable6 joined,
statisfiable6 joined,
bloatable6 joined,
reportable6 joined,
releasable6 joined,
greppable6 joined,
quotable6 joined,
shareable6 joined
03:19
bisectable6 joined,
nativecallable6 joined,
unicodable6 joined,
tellable6 joined
|
|||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | Playing around with prepending codepoints in graphemes, I came across this strange issue: | 04:08 | |||||||||||||||||||||||||||||||||||||
| nqp: say("\x[600]a"); say("\x[600]ä"); say("\x[600]ä") | 04:09 | ||||||||||||||||||||||||||||||||||||||
| camelia | a ä ä |
||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | Seems like a problem with me running this on the commandline, but that last one (which use a diaeresis codepoint over a instead of a precombined character) comes out visually as "a xCC x88" | 04:10 | |||||||||||||||||||||||||||||||||||||
| Huh, yeah, seems like a problem with using -e specifically. REPL prints it fine. | 04:11 | ||||||||||||||||||||||||||||||||||||||
| The problem doesn't need the prepending character, nqp -e 'say("ä")' is sufficient (and the problem shows up in rakudo too) | 04:14 | ||||||||||||||||||||||||||||||||||||||
| And it works fine if you try s̈ for instance; seems just character combos that NFC would end up joining into a single codepoint so far. | 04:15 | ||||||||||||||||||||||||||||||||||||||
| One more note: --target=ast shows the string argument is already corrupted, so the problem is showing up either before or during parsing. | 04:31 | ||||||||||||||||||||||||||||||||||||||
| (well, uh, that's assuming the printer outputting the QAST tree isn't the same as the one say() uses, were it to be an issue with say().) | 04:33 | ||||||||||||||||||||||||||||||||||||||
| nqp::chars("ä") returns 9, so it's definitely an issue with how the source code is being handled | 04:37 | ||||||||||||||||||||||||||||||||||||||
|
06:50
domidumont joined
07:48
Altai-man_ joined
08:12
tbrowder__ joined
08:20
tbrowder left,
tbrowder__ is now known as tbrowder
08:23
camelia left
08:25
camelia joined
08:27
sena_kun joined
08:29
Altai-man_ left
10:00
guifa2 joined
10:08
jmerelo joined
|
|||||||||||||||||||||||||||||||||||||||
| jmerelo | releasable6: status | 10:08 | |||||||||||||||||||||||||||||||||||||
| releasable6 | jmerelo, Next release in ≈24 days and ≈8 hours. There are no known blockers. Changelog for this release was not started yet | ||||||||||||||||||||||||||||||||||||||
| jmerelo, Details: gist.github.com/a895bb9c85f87e653c...6eb8c18518 | |||||||||||||||||||||||||||||||||||||||
| nine | Adding a mainline_frame to MoarVM's MVMCompUnit wasn't that hard after all. Thanks to a bump in the bytecode version to 7 and retaining backwards compatibility, I dind't need a bootstrap for NQP | 10:13 | |||||||||||||||||||||||||||||||||||||
| Now I get through NQP's compilation and nqp-m works, too. It fails in the setting compilation where it suddenly doesn't find a Blob's body block anymore and tries to execute a VMNull instead | 10:14 | ||||||||||||||||||||||||||||||||||||||
|
10:24
guifa2 left
10:25
guifa2 joined
10:27
Altai-man_ joined,
guifa2 left
10:29
sena_kun left
10:30
guifa2 joined
|
|||||||||||||||||||||||||||||||||||||||
| jmerelo | .seen cosimo | 10:36 | |||||||||||||||||||||||||||||||||||||
| tellable6 | jmerelo, I saw cosimo 2018-10-08T15:04:21Z in #perl6: <cosimo> thanks El_Che | ||||||||||||||||||||||||||||||||||||||
| jmerelo | That's some time | ||||||||||||||||||||||||||||||||||||||
|
11:00
squashable6 left
11:03
squashable6 joined
|
|||||||||||||||||||||||||||||||||||||||
| tbrowder | question, please: how can i set a variable in src/Perl6/Compiler.nqp that i can access in src/core.c/Pod.pm6? i see use of reading an hllsym in Array.pm6 but i'm not sure how to set it. | 11:08 | |||||||||||||||||||||||||||||||||||||
| nine | just use a dynamic variable? | 11:09 | |||||||||||||||||||||||||||||||||||||
| tbrowder | all this for lack or presence of a simple newline | ||||||||||||||||||||||||||||||||||||||
| so i can read the existing $*keep-decl from Grammar.nqp? | 11:10 | ||||||||||||||||||||||||||||||||||||||
| hm, as simple as that, doh. i'll try that. thnx! | 11:12 | ||||||||||||||||||||||||||||||||||||||
| nine | Actually it does run Blob's body but that throws an exception when trying to run (T.^nativesize / 8).Int | 11:18 | |||||||||||||||||||||||||||||||||||||
| It may actually be the method_not_found_error handler that runs into the VMNull | |||||||||||||||||||||||||||||||||||||||
| Geth | ¦ problem-solving: JJ self-assigned Ecosystem: versioning issues github.com/Raku/problem-solving/issues/72 | 11:23 | |||||||||||||||||||||||||||||||||||||
| ¦ problem-solving: JJ unassigned from jnthn Issue Ecosystem: versioning issues github.com/Raku/problem-solving/issues/72 | |||||||||||||||||||||||||||||||||||||||
| nine | Looks like it's failing to call closures from compile time executed code (like role bodies and trait_mods) like $parent.^methods.grep({$_.yada}) | 11:48 | |||||||||||||||||||||||||||||||||||||
| timotimo | ShimmerFairy: that looks like it's using utf8-c8 somewhere | 12:17 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | What gets me is that it's, at least so far, only precomposeable stuff, which is why I didn't for example blame my terminal emu. | 12:20 | |||||||||||||||||||||||||||||||||||||
| timotimo | i think "precomposable" is because "turning it into NFG will lose info, so utf-c8 will preserve that info for you" | 12:23 | |||||||||||||||||||||||||||||||||||||
| i bet you can use two non-precomposable composing characters on one base and flipping the order around will give you either the c8 synthetic character or the regular form | 12:24 | ||||||||||||||||||||||||||||||||||||||
| based on what order the normalization would give them | |||||||||||||||||||||||||||||||||||||||
|
12:28
sena_kun joined
12:29
Altai-man_ left
|
|||||||||||||||||||||||||||||||||||||||
| Geth | nqp/master: 4 commits pushed by andreoss++, (Jonathan Worthington)++ | 12:34 | |||||||||||||||||||||||||||||||||||||
| nine | The odd thing about this VMNull error I get is that if anything there should now be less of a chance of missing a callable object as we share almost everything between inner and outer compilations (most notably frames array and fixup lists) | 12:35 | |||||||||||||||||||||||||||||||||||||
|
12:44
ccamel left
12:45
camelCaser joined
12:54
pamplemousse joined
12:56
guifa2 left
12:58
jmerelo left
|
|||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | All I knew about UTF-C8 is a vague sense that it lets you put nulls in null-terminated strings. | 13:00 | |||||||||||||||||||||||||||||||||||||
|
13:00
pamplemousse left
|
|||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | But I was thinking that there was something deciding "this could be precomposed, but it isn't, so I'm explicitly refusing", I just didn't know what would do that or why. | 13:01 | |||||||||||||||||||||||||||||||||||||
| nine | any invalid UTF-8 | ||||||||||||||||||||||||||||||||||||||
|
13:02
guifa2 joined
|
|||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | I don't know if UTF-C8 is appropriate here (I was surprised by it, so I'd lean towards no right now), but at the very least I think commandline args and REPL input should be consistent, since they both involve someone typing at a terminal. | 13:03 | |||||||||||||||||||||||||||||||||||||
|
13:04
guifa2 left
|
|||||||||||||||||||||||||||||||||||||||
| nine | Holy cow! I think...I've got it. By just not sharing anything with the outer compiler in compile_in_context I get through the build and finally routines created by BEGIN time EVAL make it through precompilation! | 13:13 | |||||||||||||||||||||||||||||||||||||
| Which means one can now precompile a module that uses a module :from<Perl5> that is extended with a raku block which may contain attributes with accessors and methods. | 13:14 | ||||||||||||||||||||||||||||||||||||||
| And brings hope for quite a few issues about BEGIN time EVAL and constants | 13:26 | ||||||||||||||||||||||||||||||||||||||
| timotimo | ShimmerFairy: i'm not sure how c8 would allow a null inside a null-terminated string, but it's generally built so that you can roundtrip any data while decoding as much of it as possible as valid UTF8 | 13:39 | |||||||||||||||||||||||||||||||||||||
| so when you have uncomposed stuff for which a precomposed form exists it builds a synthetic that encodes to the original when encoding to utf8-c8, but encodes to a special character sequence when encoding to regular utf8 | 13:41 | ||||||||||||||||||||||||||||||||||||||
| same for completely invalid utf8 | |||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | It may not be UTF-C8, but I remember some system that let you encode a null in a usually-illegal overlong form, freeing up the literal byte value 0x00 to be a string terminator. | 13:43 | |||||||||||||||||||||||||||||||||||||
| timotimo | utf16 :D | 13:54 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | btw, does the CPPStruct REPR only work on certain C++ classes? (Like, say, only standard layout types?) The name being "struct" makes me think so, but I don't know for sure. | 13:58 | |||||||||||||||||||||||||||||||||||||
| timotimo | i don't know what other kinds of cpp classes are | 14:00 | |||||||||||||||||||||||||||||||||||||
| there are* | |||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | The "kinds" are really just how gnarly things get under the hood, depending on how fancy you get. | 14:01 | |||||||||||||||||||||||||||||||||||||
| I suppose I'd be surprised if you couldn't somehow strongarm CPPStruct into supporting any C++ class, so I suppose the question is more "how much does CPPStruct know about C++ classes? How much would I have to be like a very stubborn C programmer trying to use a C++ class directly?" | 14:03 | ||||||||||||||||||||||||||||||||||||||
| timotimo | mhm, i think we don't have support for explicitly setting the alignment of any given attribute, so that could be annoying i guess? | 14:04 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | Also, it's fun thinking about how the hell you'd support templates. You'd either need a module user to have a compiler installed, or provide a supplemental library with a gazillion instantiations. | 14:06 | |||||||||||||||||||||||||||||||||||||
| jnthn | Just write a C++ compiler in Raku... :) | 14:08 | |||||||||||||||||||||||||||||||||||||
|
14:10
Ven_de_Thiel joined
|
|||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | I've thought about a C or C++ compiler in Rakudo or NQP before, but one problem (among likely many) is that those languages don't expose enough info/control over floating points. :) | 14:10 | |||||||||||||||||||||||||||||||||||||
|
14:11
guifa2 joined
|
|||||||||||||||||||||||||||||||||||||||
| Ven_de_Thiel | ShimmerFairy: I know Dlang has pretty amazing support for C++ templates (dlang.org/spec/cpp_interface.html#...templates) | 14:13 | |||||||||||||||||||||||||||||||||||||
| And Nim also has good support (github.com/3dicc/Urhonimo/blob/mas...ashmap.nim is an example, though I admittedly don't know that much Nim) | 14:15 | ||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | The issue is that templates do not exist in compiled code. The instantiations do, but in order to provide arbitrary instantiations in Raku (via, say, parameterized roles), you'd have to do something with the source code itself. | 14:16 | |||||||||||||||||||||||||||||||||||||
| Ven_de_Thiel | I know | ||||||||||||||||||||||||||||||||||||||
| I'm just saying they probably had to face similar issues. | |||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | I notice in the D example they write code that only exists to instantiate the code, so D doesn't have to think about that issue. | 14:17 | |||||||||||||||||||||||||||||||||||||
| Well, they do it for template functions at least. | 14:18 | ||||||||||||||||||||||||||||||||||||||
| Ven_de_Thiel | yeah... they could also just write `template class Foo<int>;` I think. | 14:19 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | oh no, they do it for all templates. "Note that all instantiations used in D code must be provided by linking to C++ object code or shared libraries containing the instantiations." | ||||||||||||||||||||||||||||||||||||||
| Ven_de_Thiel | welp :-( | 14:20 | |||||||||||||||||||||||||||||||||||||
| doesn't help that every single C++ project uses a different build system or version thereof | 14:21 | ||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | There's nothing wrong with that solution, just would be nice if a Raku user could type my CppVector[int8] $foo; and have it just work. | ||||||||||||||||||||||||||||||||||||||
| That ideal solution would require a C++ compiler on the machine (which will be different kinds of painful for different people), or even worse, have Raku parse header files. | 14:23 | ||||||||||||||||||||||||||||||||||||||
| Ven_de_Thiel | that requires implementing a C++ VM, which is pretty difficult :-) | 14:24 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | At the very least, an ability to figure out the raw layout of a C++ class from its definition. | ||||||||||||||||||||||||||||||||||||||
| The good news may be that C++20 will come with honest-to-goodness modules, which will of course be able to contain templated stuff (or else nobody would bother with them), so maybe module-using code at least will work nicely. | 14:26 | ||||||||||||||||||||||||||||||||||||||
|
14:27
Altai-man_ joined
14:29
sena_kun left
|
|||||||||||||||||||||||||||||||||||||||
| Ven_de_Thiel | I don't think modules will really help | 14:29 | |||||||||||||||||||||||||||||||||||||
|
14:59
guifa2 left,
guifa2 joined
15:41
guifa2 left
15:45
jmerelo joined
16:22
jmerelo left
16:27
sena_kun joined
16:29
Altai-man_ left
|
|||||||||||||||||||||||||||||||||||||||
| [Tux] |
|
16:37 | |||||||||||||||||||||||||||||||||||||
|
16:56
guifa2 joined
17:21
patrickb joined
17:42
Ven_de_Thiel left
17:50
domidumont left
18:18
guifa2 left
|
|||||||||||||||||||||||||||||||||||||||
| nine | vrurg: you have fixed issues with subs and operators from the setting not working in nested scopes at BEGIN time, haven't you? What was the fix? | 18:24 | |||||||||||||||||||||||||||||||||||||
| vrurg | nine: I'd need to look into my PRs to recall. | 18:25 | |||||||||||||||||||||||||||||||||||||
| nine | Looks like I've got the very same now with those precompiled raku block in Perl 5 modules. Everything works unless I access subs or operators | 18:26 | |||||||||||||||||||||||||||||||||||||
|
18:27
Altai-man_ joined
|
|||||||||||||||||||||||||||||||||||||||
| vrurg | I think you're talking about another issue. A closure was not getting its outer set. It was a fix for MoarVM. | 18:28 | |||||||||||||||||||||||||||||||||||||
| M#1209 | |||||||||||||||||||||||||||||||||||||||
| linkable6 | M#1209 [closed]: github.com/MoarVM/MoarVM/pull/1209 Fix run-away CORE context on closures | ||||||||||||||||||||||||||||||||||||||
|
18:29
sena_kun left
|
|||||||||||||||||||||||||||||||||||||||
| nine | Darn....the symptoms are exactly the same though | 18:29 | |||||||||||||||||||||||||||||||||||||
| Well maybe I give it the wrong outer context | 18:31 | ||||||||||||||||||||||||||||||||||||||
| vrurg | Most likely. | 18:32 | |||||||||||||||||||||||||||||||||||||
| Do you see core symbols from the failure location? | |||||||||||||||||||||||||||||||||||||||
| nine | How do I check? | 18:35 | |||||||||||||||||||||||||||||||||||||
| vrurg | CORE::.keys | 18:36 | |||||||||||||||||||||||||||||||||||||
| Though I usually just iterate over outerctx and dump symbols. Let me see the whole picture. | 18:37 | ||||||||||||||||||||||||||||||||||||||
| *lets me | |||||||||||||||||||||||||||||||||||||||
| nine | "greet_me".note; prints as expected but CORE::.keys.note; just throws a "Cannot invoke this object (REPR: Null; VMNull)" | 18:38 | |||||||||||||||||||||||||||||||||||||
| vrurg | note "greet me" is a better check because in this case it looks up note in lexical outers. I'm not so sure about the method call. | 18:42 | |||||||||||||||||||||||||||||||||||||
| nine | That gives me "Cannot invoke this object (REPR: Null; VMNull)" | 18:48 | |||||||||||||||||||||||||||||||||||||
| it's why I switched it to the method call so I know that my code at least gets executed :) | |||||||||||||||||||||||||||||||||||||||
|
18:50
patrickb left
18:51
rypervenche left
18:53
rypervenche joined
|
|||||||||||||||||||||||||||||||||||||||
| nine | Ok, I just have 2 outer contexts. One containing $_, ::?PACKAGE, ::?CLASS, $?CLASS the other doing %?LANG, $_, ::?PACKAGE, !UNIT_MARKER, $=pod, $?PACKAGE, RakuBlock, EXPORT | 18:54 | |||||||||||||||||||||||||||||||||||||
| Clearly CORE is missing | 18:55 | ||||||||||||||||||||||||||||||||||||||
|
19:02
guifa2 joined
19:10
guifa2 left
|
|||||||||||||||||||||||||||||||||||||||
| nine | jnthn: sometimes a hammer just is the right tool. Back when we first discussed the language version issue I also had the idea of doing the kind of multi dispatch on language version you describe. Just without the means to actually implement it :) | 19:28 | |||||||||||||||||||||||||||||||||||||
|
19:36
cognominal joined
19:38
cognominal left
19:43
lucasb joined
|
|||||||||||||||||||||||||||||||||||||||
| vrurg | I'd say the new dispatching is rather a swiss army knife. But better. Yet, I have strong doubts about methods of the same instance behaving differently depending on the caller version. Thinking about it. | 19:46 | |||||||||||||||||||||||||||||||||||||
|
19:54
cognominal joined
19:56
Kaeipi joined
19:57
Kaiepi left
|
|||||||||||||||||||||||||||||||||||||||
| Geth | rakudo: coke++ created pull request #3724: Change INSTALL to markdown |
20:02 | |||||||||||||||||||||||||||||||||||||
|
20:15
patrickb joined
20:18
patrickb left
20:27
sena_kun joined
20:29
Altai-man_ left
|
|||||||||||||||||||||||||||||||||||||||
| jnthn | nine, vrurg I'm very, very tentatively wondering about claiming upper-case adverbs on names for language-provided things (:D/:U already fit that) and making the syntax `multi method foo:LANG<6.e+>(...)`, along with allowing `foo:D` and `foo:U` to be shortcuts to the `::?CLASS:D:` eyefull often seen in signatures... | 21:33 | |||||||||||||||||||||||||||||||||||||
| And that way it generalizes onto any name too, so if we deem we actually want different classes entirely between language versions (knowing they are type incompatible) then `class Foo:LANG<6.e+> { }` also naturally follows. | 21:34 | ||||||||||||||||||||||||||||||||||||||
| timotimo | it took me a moment, but now i get it, lol | ||||||||||||||||||||||||||||||||||||||
| but `method blorb:D($hello) { }` wouldn't that parse $hello as just the argument to :D? | 21:35 | ||||||||||||||||||||||||||||||||||||||
| jnthn | timotimo: eww, yes | ||||||||||||||||||||||||||||||||||||||
| timotimo | enforce a space? | ||||||||||||||||||||||||||||||||||||||
| jnthn | Hmm, OK, that's probably why we didn't do this :) | ||||||||||||||||||||||||||||||||||||||
| timotimo | require it to be :D:(...) | 21:36 | |||||||||||||||||||||||||||||||||||||
| even worse? :D | |||||||||||||||||||||||||||||||||||||||
| jnthn | Dunno, it's a tad unfortunate | ||||||||||||||||||||||||||||||||||||||
| As I said, only very tentative :) | |||||||||||||||||||||||||||||||||||||||
| timotimo | i'd really like a shortcut for this, yeah | ||||||||||||||||||||||||||||||||||||||
| jnthn | Thing is that we really need to leave foo:sym<bar> alone as being a normal name component | ||||||||||||||||||||||||||||||||||||||
| timotimo | what if we allow `_:D:` at the start of the signature | ||||||||||||||||||||||||||||||||||||||
| kind of to mirror :_ being "any definedness" | |||||||||||||||||||||||||||||||||||||||
| _:D being "the thing, but defined" | 21:37 | ||||||||||||||||||||||||||||||||||||||
| jnthn | I'm not sure I could live with being to blame for (_:_:) being valid syntax :P | ||||||||||||||||||||||||||||||||||||||
| timotimo | hm. it doesn't really say "the current class", just "anything" which isn't what it means | ||||||||||||||||||||||||||||||||||||||
| jnthn | That too | 21:38 | |||||||||||||||||||||||||||||||||||||
| vrurg: Anyways, there are problems that would be aided by method-level versioning by language; for example, we'd like to clear up the IO::Handle.new situation, but don't really want a whole IO::Handle definition just for that. | 21:39 | ||||||||||||||||||||||||||||||||||||||
| MasterDuke | do any other languages have names/syntax we could borrow? i'm thinking of this/it, but i believe those all refer to the instance, not the class | 21:40 | |||||||||||||||||||||||||||||||||||||
| jnthn | Yeah, I can only think of instance-y ones | 21:41 | |||||||||||||||||||||||||||||||||||||
| timotimo | i seem to recall we have something in the "multi: no match" exception message printer for when you got an undefined, but only defineds would work? | 21:45 | |||||||||||||||||||||||||||||||||||||
| perhaps only for arguments, not for the invocant? | |||||||||||||||||||||||||||||||||||||||
| m: print(Str) | |||||||||||||||||||||||||||||||||||||||
| camelia | Use of uninitialized value of type Str in string context. Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful. in block <unit> at <tmp> line 1 |
||||||||||||||||||||||||||||||||||||||
| timotimo | m: sin(Int) | ||||||||||||||||||||||||||||||||||||||
| camelia | WARNINGS for <tmp>: Useless use of "sin(Int)" in expression "sin(Int)" in sink context (line 1) Invocant of method 'Bridge' must be an object instance of type 'Int', not a type object of type 'Int'. Did you forget a '.new'? in block <unit> at… |
||||||||||||||||||||||||||||||||||||||
| timotimo | pffft :) :) | ||||||||||||||||||||||||||||||||||||||
| m: sin(Real) | |||||||||||||||||||||||||||||||||||||||
| camelia | WARNINGS for <tmp>: Useless use of "sin(Real)" in expression "sin(Real)" in sink context (line 1) Invocant of method 'Bridge' must be an object instance of type 'Real', not a type object of type 'Real'. Did you forget a '.new'? in block <unit… |
||||||||||||||||||||||||||||||||||||||
| timotimo | m: sin(Numeric) | 21:46 | |||||||||||||||||||||||||||||||||||||
| camelia | WARNINGS for <tmp>: Useless use of "sin(Numeric)" in expression "sin(Numeric)" in sink context (line 1) No such method 'sin' for invocant of type 'Numeric' in block <unit> at <tmp> line 1 |
||||||||||||||||||||||||||||||||||||||
| MasterDuke | does it have to be attached to the name? what about something like `returns`? e.g., `method foo ($b) belongs v6.e+ { ... }` | ||||||||||||||||||||||||||||||||||||||
| timotimo | ah, it forwards to a method call | ||||||||||||||||||||||||||||||||||||||
| jnthn | MasterDuke: I don't really want to introduce new special-case syntax, if we can avoid it | 21:47 | |||||||||||||||||||||||||||||||||||||
| timotimo | ah! we have that for "requires mutable arguments" | ||||||||||||||||||||||||||||||||||||||
| jnthn | So stackoverflow.com/questions/620517...and-a-rule is quite fascinating | 21:56 | |||||||||||||||||||||||||||||||||||||
| Somehow, when it's a rule, it ends up being happy to backtrack the *, apparently | |||||||||||||||||||||||||||||||||||||||
| And it's the sigspace directly aftr the * that causes it | 21:59 | ||||||||||||||||||||||||||||||||||||||
| I wonder if this is an issue in NQP too, and how much performance it costs us. | |||||||||||||||||||||||||||||||||||||||
| It's a bit unfortunate --target=ast doesn't dump out the backtrack on a quant | 22:00 | ||||||||||||||||||||||||||||||||||||||
| MasterDuke | would NQP_NFA_DEB be useful? | 22:04 | |||||||||||||||||||||||||||||||||||||
| jnthn | No, I suspect it's mis-construction of the AST | 22:05 | |||||||||||||||||||||||||||||||||||||
|
22:10
MasterDuke left
|
|||||||||||||||||||||||||||||||||||||||
| jnthn | Ah, and also: the NFA isn't used at the entry to the TOP rule, so it really can't be that | 22:11 | |||||||||||||||||||||||||||||||||||||
| timotimo | dump the spesh log and try figuring out from the bytecode how it was constructed, lol | 22:15 | |||||||||||||||||||||||||||||||||||||
| jnthn | It's probably faster to improve the dumper :P | ||||||||||||||||||||||||||||||||||||||
| timotimo | :D | 22:16 | |||||||||||||||||||||||||||||||||||||
| when do we introduce a dumper in a more formal format and a separate viewer that gives you lots more fine-grained control? | |||||||||||||||||||||||||||||||||||||||
| could come with rakuast i guess :) | 22:17 | ||||||||||||||||||||||||||||||||||||||
| there's one of zof's tools that turns qast dump output into an html file that lets you collapse stuff and it's colored and disemphasizes the "other" branch of a WANT | 22:20 | ||||||||||||||||||||||||||||||||||||||
| Want* | |||||||||||||||||||||||||||||||||||||||
|
22:27
Altai-man_ joined
22:29
sena_kun left
22:54
Kaiepi joined
22:55
Kaeipi left
23:00
Xliff joined
|
|||||||||||||||||||||||||||||||||||||||
| vrurg | What an interesting discussion I missed here! | 23:16 | |||||||||||||||||||||||||||||||||||||
|
23:59
Altai-man_ left
|
|||||||||||||||||||||||||||||||||||||||