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] Rakudo version 2020.05.1-206-g986f8ab6b - MoarVM version 2020.05-15-g644533ad1
csv-ip5xs0.817 - 0.845
csv-ip5xs-208.138 - 8.483
csv-parser24.325 - 24.916
csv-test-xs-200.383 - 0.385
test7.376 - 7.840
test-t1.886 - 2.199
test-t --race0.811 - 1.152
test-t-2030.831 - 31.435
test-t-20 --race8.812 - 9.554
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
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: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
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