github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 09:33
MasterDuke just thinking out loud here, i've added a bunch of `MVM_gc_worklist_add(tc, worklist, <something related to spesh candidates>);`. are there any places i definitely should not have? 09:36
also. github.com/MoarVM/MoarVM/pull/1344 in it's current state is fine (just convert MVMSpeshCandidate to a REPR). i've been working locally on that branch to add the removing of an opt if there are too many deopts (this is what's causing segfaults/MVM_panics). should i keep working on this branch and then have the PR include both changes? 09:43
or does it make sense to merge the PR as is, and then have a new one for removing opts?
jnthn Probably makes sense to review/merge the PR separately 10:20
And then another one for the deopt bit
I can't think of a reason not to add a reference to a collectable. 10:21
MasterDuke good and good 10:22
has anybody looked at the PR? i'm inclined to rebase/squash all the commits down in to one and then take it out of draft status 10:23
jnthn I only looked when I was trying to help find problems 10:24
nine same here 10:25
jnthn +1 to tidying it up and taking it out of draft; I'll have a look over it
MasterDuke there's the initial largish commit, and then some followup smaller ones that don't have very descriptive messages
i'll give them more descriptive messages for now, but leave them in, and then reviewers can decide if they should be squashed (the reason i mildly argue for squashing is that while moarvm builds on each of them, nqp and/or rakudo has some problem) 10:27
jnthn OK, thanks. Good to get this change in well ahead of a release. 10:29
jnthn continues on with the dispatch resumption 10:30
MasterDuke hm. now the git fun begins. i have my branch with newly rebased commits, plus commits i don't want to push. i guess i can force push up to the ones i don't want yet, then move them onto a new branch for the eventual next PR 11:05
MasterDuke ok, github.com/MoarVM/MoarVM/pull/1344 is taken out of draft 11:18
MasterDuke is afk for a little while to go smear porridge on a baby's face, because said baby is not very skilled at eating said porridge 11:20
Geth MoarVM/new-disp: a15e237adf | (Jonathan Worthington)++ | 5 files
First steps towards resume initialization state

The resume initialization state is the state that a dispatcher indicates as being needed in order to start a resumption of a dispatch. From the perspective of the dispatch program, it's another place to obtain some values. This gets us to the point of handling the simplest case of the resume initialization state (that is, where it precisely matches the ... (5 more lines)		 11:42
jnthn aww, no geth 15:20
lizmat yeah... seems like all of a sudden there's an issue setting up an SSL connection to Freenode :-( 15:46
tyil has no time to look at it right now 15:47
jnthn ah, ok 15:55
Phew, finally, the first working case of a dispatch program that handles a dispatch resumption. 16:50
Now let's see how what's left of my brain handles language class... :) 16:54
MasterDuke better than depending on the right side... 16:56
jnthn :P 18:14
nine Ah, GILs are great. Half an our and I got use Inline::Perl5 <thread-safe>; do what it looks like 19:55
Oh GILs suck. Kinda destroying the point of having multiple threads in the first place ;) 19:57
jnthn :) 20:31
nwc10 nine: are you paying attention to tanks in Texas? 20:34
nine scrubbed for today, isn't it? 20:35
nwc10 nope.
it's approved. And they started fueling it *before* they got the approval 20:36
I think a more accurate answer than "nope" would have been "it got unscrubbed" 20:39
nine Unscrubbed? Now that would be a first :) 20:40
nwc10 OK, it's completley unclear what is actually going to happen, but the tank farm is venting 20:41
nine Meanwhile I actually got rid of the GIL and still have an (optionally) thread safe Inline::Perl5. Only now with scaling :) 20:43
nwc10 so this is sort of like the independent interpreters of ithreads, but with a proper system to orchestrate them? 20:44
nine The use case I'm aiming at is using Perl 5 in a Cro application, i.e. non-communicating worker threads. I do this by mixing a role into $*THREAD and use it to attach a Perl 5 interpreter. 20:47
Test script is: use Inline::Perl5 <thread-safe>; use TestFoo:from<Perl5>; my @p = do for ^15 { start { for ^100000 { TestFoo.new.test; } } } await(@p); 20:48
lizmat looks like it is detanking :-( 21:39
nwc10 Yes. And it is completely confused as to what is going on. Other than "wet dress rehersal again - fooled you" 21:40
[Coke] I also am confused by "wet dress rehearsal" 21:41
nwc10 you test the procedure for fuelling your rocket. With real fuel. 21:42
[Coke] ah 21:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!