Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
vrurg . 01:24
05:20 llfourn left 05:25 [TuxCM] left 05:28 robertle left 05:40 llfourn joined 06:46 [TuxCM] joined 07:05 llfourn left 07:06 llfourn joined 07:10 patrickb joined
timotimo got a little optimization that activates a whole bunch in the core setting, but i didn't yet put in something that gives me the line number where it happens 07:15
07:16 llfourn left, llfourn joined
timotimo gist.github.com/timo/418ee35fcd968...3b86b4904c 07:16
probably also possible to change this for attributeref and localref on the assignee side
haha, whoops, it already activates for those, but it just changes it to "lexical" 07:19
that's surely explosive
ha, no, i wronged that 07:21
accidentally output the scope of the RHS twice
07:21 llfourn left 07:22 llfourn joined 07:31 llfourn left 07:32 llfourn joined 07:37 llfourn left 07:47 llfourn joined 07:52 llfourn left 08:02 llfourn joined 08:06 llfourn left 08:39 llfourn joined 08:44 llfourn left
Tux__ Rakudo version 2019.03.1-677-ga46c414f7 - MoarVM version 2019.05-99-g729303de7 09:08
csv-test-xs-20 0.427 - 0.432
csv-ip5xs 0.685 - 0.699
test-t --race 0.793 - 0.802
test-t 1.678 - 1.757
csv-ip5xs-20 5.275 - 5.330
test 7.305 - 7.447
09:08 Tux__ is now known as Tux
Tux test-t-20 --race 8.836 - 8.900 09:08
test-t-20 27.418 - 28.585
csv-parser 34.017 - 34.448
09:08 Tux is now known as |Tux| 09:22 japhb left
Geth rakudo: f44c14c356 | (Timo Paulssen)++ | lib/NativeCall/Types.pm6
NativeCall: no need to create lots of Int/Num to "CArray.allocate"
 10:00
rakudo: 80bf3d003c | (Timo Paulssen)++ | src/Perl6/Optimizer.nqp
Optimizer: Direct assignment between native vars don't need refs
10:10 llfourn joined 10:16 llfourn left 10:20 llfourn joined 10:28 llfourn left 10:29 llfourn joined
lizmat ooo that last one is interesting :-) 10:29
lizmat commented on github.com/rakudo/rakudo/commit/80bf3d003c 10:39
10:39 llfourn left
timotimo lizmat: not sure what that'd help, that'd mean you'd have to $node.scope(make-scope-not-ref($node.scope)) everywhere 10:43
lizmat hmmm... I guess: I didn't realize there were going to be more calls 10:44
timotimo could be used in other places
lizmat hmmm... shouldn't 10:45
$nodescope eq "localref" { $node.scope("local") }
be
$nodescope eq "localref" { $nodescope("local") }
?
argh..... been around Javascript too much in the past week
:-)
timotimo yep, too much js for sure :) 10:48
hrmpf, my upgraded patch to also handle stuff like $bloop = $bloop + 1 where it'd previously have a lexicalref for the first $bloop 10:56
explodes in stage mast
because somehow a bind with a lexicalref as first argument appears in the final qast 10:57
lizmat yuck
timotimo perhaps it's due to partial qast re-use 10:58
who knows ...
i've got kind of a headache at the moment, not sure how that'll develop throughout the day 11:02
11:03 llfourn joined 11:08 llfourn left 11:42 llfourn joined 11:47 llfourn left 11:49 llfourn joined 11:59 llfourn left 12:38 llfourn joined 12:44 nubie joined 12:45 llfourn left 12:46 llfourn joined 12:54 nubie left 12:56 nubie joined, llfourn left
nubie sorry, its me Bram who sent you email few weeks ago 12:57
sorry - wrong type.
12:57 nubie left 13:05 llfourn joined 13:19 llfourn left 13:20 llfourn joined 13:34 llfourn left 13:35 llfourn joined 13:37 pamplemousse joined 13:45 llfourn left 13:47 llfourn joined 13:53 llfourn left 13:58 llfourn joined
lizmat reportable6: 2019-07-01T00:00:00 2019-07-08T00:00:00Z 14:41
reportable6 lizmat, OK, working on it! This may take up to 40 seconds
lizmat notable6: weekly 14:42
notable6 lizmat, 14 notes: gist.github.com/ddbb1730117e3eaead...8ec4a3b4ee
reportable6 lizmat, gist.github.com/9376c87ffa8201b4f8...349ce7de7b
14:44 AlexDaniel left
lizmat notable6: weekly reset 14:44
notable6 lizmat, Moved existing notes to “weekly_2019-07-08T14:44:25Z”
14:44 AlexDaniel joined
[Coke] yawns. 15:05
lizmat and yet another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/07/08/...ythifying/ 15:30
16:05 robertle joined 16:06 patrickb left 16:41 vrurg left 16:51 vrurg joined 17:31 patrickb joined 18:12 [Coke] left
Kaiepi what encoding does windows use for strings? is it supported by moarvm? 18:14
atm i assume strings converted from wide strings to c strings are utf8 but that only works on linux since i specifically set the locale to utf8, which isn't possible on windows 18:15
timotimo probably UCS16 or something?
Kaiepi would that be windows1252? 18:17
timotimo that's not equivalent to latin1, is it?
Kaiepi idk, it's a separate encoding from latin1 on moarvm 18:18
there's also windows1251 18:21
18:22 [Coke] joined
Kaiepi looks like it uses UTF16LE according to stack overflow 18:23
[Coke] me;test
oops.
Kaiepi oh wait you can set the encoding to utf-16 18:27
that'll work
18:34 epony left
ugexe windows use utf-15.5 18:47
vrurg thought it's still utf-8.3. But that's perhaps correct for Win95... ;) 18:57
Kaiepi ok the encoding doesn't actually matter at all, i can use MultiByteToWideChar/WideCharToMultiByte and specify CP_UTF8 as the codepage it should use 19:04
wonder if it's thread-safe though... 19:05
stackoverflow says it is but there's no concrete proof in the documentation 19:06
pamplemousse weekly: yakshavingcream.blogspot.com/2019/...etely.html 19:21
notable6 pamplemousse, Noted!
19:38 pamplemousse left
ugexe lizmat: "all socket actions are asynchronous" this is not true. sync sockets do not use libuv under the hood 20:06
that is true for proc/proc::async, not sockets
20:12 robertle left
AlexDaniel lizmat++ 20:24
MasterDuke lizmat++ tons of blogs/posts/etc to keep track of 20:33
lizmat ugexe: then why am I seeing the ThreadPoolScheduler start up in that example ? 20:41
timotimo what are you currently talking about? 20:43
lizmat, ugexe, can i see the code? 20:44
lizmat it was one of the replies on the demyth storm, I forget where exactly... ugexe? 20:45
Kaiepi ugexe don't both sync and async sockets use libuv to resolve hostnames or am i misremembering the code?
timotimo that seems likely, yeah
Kaiepi it reaaallllyyyy sucks that i can't make P6str support wide strings atm because you're forced to explicitly-manage whatever wide strings you make members of CStruct/CPPStruct/CUnion 20:47
AlexDaniel maybe we *do* want to migrate rt tickets to github, just not into any existing repo
like maybe a new repo for old tickets
then we can transfer tickets that are still relevant, and let the rest rot… 20:48
Kaiepi timotimo, what is it about NFG that makes it so hard for P6str to support c/wide strings?
AlexDaniel “Old urls would redirect to the migrated github issue. The top of the migrated issue would provide a link to a read only archived version of the RT ticket.” 20:49
timotimo there are codepoints in P6str that don't exist in unicode and thus cannot be passed to C. strings therefor have to be turned into some encoding to be passed on to C and friends 20:50
AlexDaniel and if we don't do that, then RT tickets will be read-only 20:51
which is LTA
so, thoughts?
and maybe ideas for the new repo name?
Kaiepi why wouldn't you be able to use MVM_string_utf8_encode_C_string on the MVMString value P6str keeps timotimo?
or MVM_string_utf8_encode_wide_string, which i'm adding 20:53
does NFG not get dealt with in a way functions taking c or wide strings can understand or something? 20:54
AlexDaniel I'll go with “perl6/old-issue-tracker” if nobody stops me :P 20:55
jnthn I'd probably stick them under rakudo/rt-issues given GitHub's current organization limit on issue transfers. 20:57
I'd not particularly against importing them into rakudo/rakudo though, *if* they'd take on the dates of the old issues, but I fear they won't.
But it'd maybe be easier to triage them all together. 20:58
AlexDaniel they won't, yeah, and they'll be on the top
I dislike rt-issues because nobody will know what's RT in relatively short time
jnthn True.
old-issue-tracker is better in that sense, I guss 20:59
*guess
A load of issues were automatically opened with nothing more than a link to a roast test that was skip or todo
timotimo Kaiepi: that should easily work
jnthn Those don't have much value IMO 21:00
AlexDaniel jnthn: yeah, we'll perhaps close them or something
jnthn Might be scriptable - if anyone has the time/wish of course.
AlexDaniel jnthn: btw, just to make sure, you do know that a repo transfer will leave behind redirects? 21:01
jnthn I guess the one upside of them being in rakudo/rakudo is we're a bit less likely to just leave them to rot but...really not fond of them flooding the top of the issue list, which has things people recently care about.
AlexDaniel: Redirects from the URL the issue was moved from, you mean? 21:02
AlexDaniel jnthn: no, I mean if you transfer a whole repo
jnthn I'd kind of assumed it would...
Ah, for some amount of time, yes; I've no idea how long.
AlexDaniel until you create a new repo with the same name
and even then, if you did that by accident, you can probably transfer it back and forth to restore redirects 21:03
Kaiepi if that works timotimo then awesome, i don't have to make an exception on how you use wide strings just for structs and unions
MasterDuke maybe that would be a good squashathon. find good ones to move from rakudo/old-issues to rakudo/rakudo? 21:04
AlexDaniel jnthn: the thing is, I don't know if the old RT queue has enough relevant rakudo bugs to even justify being in rakudo/ org… maybe but I'm not yet convinced
jnthn: and more so for closed tickets, I guess a lot of parrot stuff will be there too? I don't know if it'll transfer closed stuff though
jnthn I would expect only open stuff, though worth checking
AlexDaniel ok asked that 21:05
even if not, a lot of the stuff there is about roast and language stuff 21:06
ugexe lizmat: r/programming i think
jnthn fwiw, I'm still quite uneasy about the suggested rakudo/rakudo => perl6/rakudo move, out of wanting to maintain distinctions I feel are valuable now and can be in the future; OTOH we already have perl6/nqp. If there's a large majority for moving it, I'm not going to veto it. 21:07
timotimo Kaiepi: not sure how exactly to manage when that gets freed, though
AlexDaniel jnthn: I mean, giving your strong opposition I'm starting to doubt myself, right :)
jnthn: but I don't feel like I understand your position, to be honest, still trying to digest it 21:08
jnthn Were you around at a point where there were multiple actively developed Perl 6 implementations?
AlexDaniel jnthn: briefly, I wasn't involved as much back then
Kaiepi timotimo, i wouldn't change how strings are stored in P6str, i'd just keep native type info in MVMP6strREPRData and have the code that actually needs to transcode the MVMString to whatever deal with the memory management itself 21:10
AlexDaniel jnthn: for example, there's a seemingly strong argument about moving stuff, but considering that there will be redirects for everything, I don't thing the argument is very strong?
lizmat ugexe timotimo this was the thread: www.reddit.com/r/programming/comme...t/et6kuvw/ 21:11
AlexDaniel jnthn: as for the “official compiler”, I think there's no hiding from that. We can call it “officially endorsed compiler”, or something, because that's how it is. But for most people the distinction is not very important 21:12
jnthn: but IMO that's not bad. I don't think that having a somewhat main compiler ever stopped other from implementing their own 21:13
jnthn AlexDaniel: It's not really a technical issue. The thing is, at first "the Perl 6 implementation effort" was pretty much the "build a Perl 6 compiler on Parrot", and that was kind of considered the "official" Perl 6 project. Then when Pugs came along - without which I suspect the Perl 6 project might not have survived - there was a realization that the language/impl distinction was really important, and competition was useful.
AlexDaniel and if we make it clear that we welcome other implementations, and that we're ready to take in their repos if that's what they'd prefer, maybe everything is fine and dandy 21:14
jnthn AlexDaniel: Similarly, Niecza did prompt an amount of re-thinking of Rakudo architecture, which also contributed a huge amount. Plus the SMOP work hugely influenced what became 6model (the Rakudo metamodel implementation).
So basically, the history has been that competing implementations (make me uncomfortable and :P) are good for Perl 6. 21:15
AlexDaniel I agree, but how having a repo in a slightly different place is going to impact that negatively? 21:16
maybe it will, but I'm just trying to understand a sequence of actions or something 21:17
jnthn And the parenthetical bit there is what makes me reluctant to endorse things that makes Rakudo "more official": of course, having poured a decade plus into Rakudo, I'd really like it to continue to be the leading Perl 6 impl; but I know for Perl 6 as a whole, competition has been good.
timotimo if you're a new project you may want to do very rapid development, and that can mean "i want a new repo now. damnit all rakudorks are asleep. ehhh, i didn't want to work on this so bad anyway"
jnthn I guess I don't worry about this specific action so much as "is it part of a slippery slope". 21:18
AlexDaniel timotimo: but you can create your own repo at any moment
if you want it to be under perl6/ then sure, wait for someone to wake up :) 21:19
jnthn Maybe I'm worrying about a problem that isn't really going to manifest, though it's curious pmichaud - who pretty much lived the same history as I did (but longer, since he founded the codebase that gradually became Rakudo years before I joined in) - had the same feeling.
(lived the same Perl 6 history, I should add :)) 21:20
AlexDaniel jnthn: “Create and close.” it's going to transfer closed tickets too! 21:21
jnthn OK, but close them? 21:22
That's OK, in that we don't have to triage them all. :)
AlexDaniel yeah, as in you can't open a closed ticket :)
jnthn: I think we need another ticket to discuss compiler/lang distinction, I don't think we're doing a good job at it right now 21:23
jnthn :)
AlexDaniel as in, it should be clear to people that other implementations are welcome regardless of where a repo is :)
ugexe at least no one in the reddit thread complained about which repo the various components were located at
AlexDaniel ha!
jnthn: what are your thoughts on CLA btw? Any chance of dropping that as a requirement? 21:24
does it do anything useful? If yes then sure we can let it be, but it's a bit PITA-ish 21:25
especially given how mails are somehow not reaching the right person and you have to CC Coke directly in the end :)
jnthn AlexDaniel: I think that's better asked to somebody who understands the legal stuff better, but my understanding is that it gives some kind of benefit. I've simply gone with it because I figure the folks who instituted it know better than I do about that. I've no attachment to it beyond that. 21:27
patrickb Related but different idea: Having the CLA cover all of rakudo, nqp and MoarVM might also be worth a thought. 21:28
jnthn Well, maybe, though that might be closing the door after the horse bolted :)
patrickb AFAIK CLAs allow for license changes without having to track every contributor down or rip the code base apart. VLC is a prominent project that went through that process, there are probably others. 21:29
jnthn But really, I think that'd need some discussion with somebody from TPF who understands it.
AlexDaniel yeah, I want to consistify a bunch of stuff, whether it is extending CLA to other repors or dropping it altogether 21:33
otherwise it's kinda weird
repos* 21:34
ugexe CLAable: My Name, 2019/07/08 [email@hidden.address]
AlexDaniel yeah, and if we keep it, might as well make the process easier. Indeed. 21:35
ugexe i also dont care if it stays or goes
jnthn away for a bit 21:37
21:41 patrickb left 21:43 patrickb joined 22:46 japhb joined 22:51 patrickb left 22:52 AlexDaniel left 22:53 AlexDaniel joined 23:03 [TuxCM] left 23:17 jnthn left 23:18 jnthn joined 23:43 epony joined
Geth rakudo: 82fc4e5700 | (Timo Paulssen)++ | lib/NativeCall/Types.pm6
NativeCall: turns out CArray nulls itself out when resizing

so binding a 0 to every slot was wasteful		 23:55
timotimo my program used to spend about 3.2s on CArray.allocate, now it's 2.5ms 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!