github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
03:25 lucasb left 05:35 nativecallable6 left, shareable6 left, tellable6 left, sourceable6 left, greppable6 left, quotable6 left, benchable6 left, bisectable6 left, unicodable6 left, committable6 left, notable6 left, evalable6 left, squashable6 left, linkable6 left, bloatable6 left, coverable6 left, statisfiable6 left, releasable6 left 05:36 bisectable6 joined 05:37 shareable6 joined, releasable6 joined, benchable6 joined, statisfiable6 joined 06:34 domidumont joined 07:19 brrt joined 07:27 patrickb joined 07:45 zakharyas joined
MasterDuke any objections to merging github.com/MoarVM/MoarVM/pull/1475 and github.com/MoarVM/MoarVM/pull/1467 ? 08:01
sena_kun still awaits for the release blocker 08:22
patrickb sena_kun: That's the App::Uni failure and fix in github.com/MoarVM/MoarVM/pull/1473 correct? 08:46
sena_kun patrickb, exactly.
MasterDuke patrickb: thanks for the quick reviews 08:47
patrickb: do you know if there's a way to start the jobs in a particular order? the windows ones take the longest, so i think it would make sense to start them first. they're listed first in the file, but order in there doesn't seem to match with order jobs are actually started 08:58
patrickb AFAICT there is no way to control the order. 09:03
MasterDuke huh 09:04
[Coke]: how do you build rakudo on windows? 09:09
jnthn morning o/ 09:22
sena_kun o/
nwc10 \o 09:23
lizmat \o/
MasterDuke nine: did you have a suggestion for github.com/MoarVM/MoarVM/pull/1474 ? 09:31
patrickb: why is the PWSH_DEV script needed in the windows jobs? 09:35
09:35 lizmat is now known as lizmmat_, lizmmat_ is now known as lizmat
Geth MoarVM/master: 6 commits pushed by (Daniel Green)++, MasterDuke17++ 09:47
09:52 lizmat is now known as lizmat_, lizmat_ is now known as lizmat, lizmat is now known as lizmat_ 09:53 lizmat_ is now known as lizmat 09:54 lizmat is now known as lizmat_, lizmat_ is now known as lizmat
Geth MoarVM: 53312b9fd8 | (Daniel Green)++ | 8 files
Deprecate now unused graphs_s op

It was removed from NQP in
  github.com/Raku/nqp/commit/a161dbd...e88b69d945		 09:55
MoarVM: 462c41c321 | MasterDuke17++ (committed using GitHub Web editor) | 8 files
Merge pull request #1467 from MasterDuke17/deprecate_now_unused_graphs_s_op

Deprecate now unused graphs_s op
MoarVM: 79027bdd07 | (Stefan Seifert)++ | 6 files
Fix inlines missing synthetic deopt points

Since commit 3345ec36466dbae315b00960d3afedf121b08451 we have synthetic deopt points on inserted guards. These deopt points take their index from an existing deopt point they are linked with. This is important as otherwise we might miss registers we need to restore when deoptimizing.
... (8 more lines)		 10:11
MoarVM: 3013dcf3ba | (Jonathan Worthington)++ (committed using GitHub Web editor) | 6 files
Merge pull request #1473 from MoarVM/fix_inlines_missing_synthetic_deopt_points

Fix inlines missing synthetic deopt points
patrickb MasterDuke: Those lines turn the Powershell into a so called "Developer Console". Technically that means setting a bunch of environment variables that the msvc build toolchain requires to work. 10:17
MasterDuke so might only be needed if the script calls nmake? 10:19
patrickb It's not only adapting the PATH, but I think also puts the path to the Visual Studio installation in some variable.
MasterDuke and not, e.g., when running nqp/rakudo tests?
patrickb correct. It's only needed for running nmake, cl, ... 10:20
lizmat ok, so it's time for a bump ? 10:21
MasterDuke ok. i think some of the jobs after building moarvm/nqp/rakudo can be simplified then. it's kind of unfortunate that testing this requires spamming everybody with github notifications though... 10:22
lizmat: believe so
lizmat ok, will do
nine MasterDuke: zctually, yes 10:38
MasterDuke: reading the docs can help tremendously from time to time :)
If a write() is interrupted by a signal handler before any bytes are written, then the call fails with the error EINTR; if it is interrupted after at least one byte has been written, the call succeeds, and returns the number of bytes written.
On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.)
This actually tells us exactly what we need to do: since write() can be interrupted and not write the whole number of bytes we requested, we need to call it in a loop and keep track of how much is already written. Luckily our code does that already. 10:40
So when we get a 64 bit number > 2^32 and can only pass on a 32 bit number, the sensible thing to do is to just pass UINT_MAX. 10:41
The (int)bytes was not terribly wrong in so far as we would eventually write the whole buffer. But it was inefficient as worst case with a buffer size of 2^32, we'd write in 1 byte increments. 10:42
or maybe it's 2^31, since we casted to int, not unsigned int. But you get the drift 10:43
nwc10 nine: likely would be better to pass an even number. Rounded down to a block size might work even better. 10:44
(And not worry about what the actual block size is - just assume 65536) 10:45
nine good point 10:49
nwc10 or maybe 2M.
MasterDuke so maybe just change the `(int)bytes` to `(uint)bytes`? the problem was that the cast was going negative when bytes was too big 10:58
nine No
That would still keep that 1 byte worst case
A simple "bytes > INT_MAX ? 65536 : bytes" should do 10:59
lizmat am I understanding that all writes in Moar are done in 1-byte increments ? 11:00
nwc10 I don't think so. That will change to chunks of 65536 until the size drops below INT_MAX
nine Maybe "bytes > (MVMuint64)INT_MAX ? 65536 : bytes"
nwc10 I think that ((INT_MAX >> 2) + 1) would likely be easiest
nine MasterDuke: if in doubt, listen to nwc10 :D 11:01
nwc10 or just bytes > INT_MAX ? 1073741824 : bytes
nine is just an amateur at this
nwc10 I mess things up sometimes
MasterDuke is less than an amateur
nwc10 and not jsut coffee
see. typing. Not great at that
lizmat never had any formal CS education 11:02
nwc10 me neither
lizmat but has been given CS classes and has been a promoter for CS students
nwc10 I haven't even done that!
nine You don't learn these things in CS anyway :)
lizmat I don't know :-)
MasterDuke final answer is `bytes > INT_MAX ? 1073741824 : bytes`? 11:04
nwc10 m: 2**30 11:05
camelia WARNINGS for <tmp>:
Useless use of "**" in expression "2**30" in sink context (line 1)
nwc10 m: say 2**30
camelia 1073741824
nwc10 yes, best suggestion for what to try
MasterDuke thanks, will do
what about for send(), same value? 11:09
nine MasterDuke: what does the man page say? 11:10
MasterDuke reading it now
this looks like it might be slightly more complicated to pick a size. pausing for lunch 11:14
11:31 zakharyas left 11:39 LizBot joined
lizmat PSA: LizBot is an experimental logger by yours truly 11:46
atm, it just logs
brrt welcome LizBot!
nwc10 LizBot: botsnack 11:47
nwc10 assumes that UGT implies it's always elevensies
(on reflection, this could be an unhealthy concept) 11:48
lizmat yeah, always elevensies is what me big :)
*made
brrt 'great', is the word :-) 11:49
lizmat no, I meant big :-)
I'm a lot smaller now, since I started losing weight about 1.5 years ago 11:50
about 30% smaller
brrt that's pretty substantial :-) 11:51
I imagine we'll see at the next perl community conference.
If indeed there will be a next one of those
lizmat I won't be visiting any Perl events anymore, I *will* be visiting Raku events
brrt Hmm.
Best we start organizing those, then. 11:52
(Why, though, what's wrong with Perl events these days? Drama?)
lizmat conf.raku.org is a good start
brrt what, august 7 we'll all be vaccinated for sure.... 11:53
lizmat 1. I don't want to attend any Perl presentations anymore
2. I'm done with certain members of the Perl community 11:54
3. I may well visit social events around Perl conferences
12:12 sena_kun left 12:14 sena_kun joined
brrt anyway, raku conf seems fun 12:18
12:18 Kaeipi left
[Coke] MasterDuke: Have not done so on a fresh box in ages, but building on windows requires a perl5 and one of the visual studios. I had made it work easily with msvc2017, but was having some difficulty getting it setup with 2019, which is probably on me. 12:20
(and then do the build from within the dev tools command prompt, which sets up all the env vars) 12:21
Am actually trying to get this to work on a windows 10 64-bit box with 2019 this week.
MasterDuke so similar to github.com/MoarVM/MoarVM/blob/mast...#L158-L161 ?
[Coke] MasterDuke: there's a moar option that says "use the msvc toolchain" 12:22
MasterDuke if you do, could you test whether that `set CL=/MP` does speed things up by doing the compilation in parallel or not?
12:22 Kaiepi joined
[Coke] I'll add taht to the list of things to try on the new box, sure 12:22
MasterDuke huh, no option like that is used in the azure jobs 12:23
patrickb it's not actually necessary to have a full Visual Studio installed. The BuildTools package suffices. 12:24
[Coke] fair. I just have it for work anyway.
patrickb See: github.com/rakudo/rakudo/tree/mast...de-modules 12:25
12:26 LizBot left, LizBot joined 12:31 Kaiepi left 12:32 Kaeipi joined 12:36 Kaeipi left 12:40 Kaiepi joined 12:41 LizBot left 12:42 LizBot joined 12:45 brrt left 12:56 zakharyas joined 13:04 zakharyas left, shareable6 left, lizmat left, nwc10 left 13:05 zakharyas joined, shareable6 joined, lizmat joined, nwc10 joined 13:08 zakharyas left
Geth MoarVM/new-disp: 80fc8fec09 | (Jonathan Worthington)++ | src/core/interp.c
Add assertions to inline cache resolution

So we can catch problems a little earlier when debugging.		 13:15
MoarVM/new-disp: 8f93408cca | (Jonathan Worthington)++ | 4 files
Fix race and simplify static frame setup

The function `prepare_and_verify_static_frame` is only called from the instrumentation barrier routine, so it need not obtain a lock that is always obtained by the instrumentation barrier routine. Furthermore, it need not check the instrumentation level is zero (that's also done in the caller). Those are the simplifications. ... (16 more lines)
MoarVM/new-disp: 09e8dc9be3 | (Jonathan Worthington)++ | src/core/frame.c
Add a couple of MVM_UNLIKELY
13:20 zakharyas joined
jnthn Hmm, this segv feels a little familiar... 13:20
Thread 1 "moar" received signal SIGSEGV, Segmentation fault.
0x00007ffff796af0d in MVM_spesh_arg_guard_gc_mark (tc=0x55555560a080, ag=0x5555556519a0, worklist=0x555555f3c160) at src/spesh/arg_guard.c:611
611 MVM_gc_worklist_add(tc, worklist, &(ag->nodes[i].st));
MasterDuke when was new-disp last rebased? 13:22
looks like relatively recently 13:23
jnthn Probably O(weeks) ago
Thing is I thought this was the segv we saw in a branch
But yeah, if it looks familiar to you too, maybe I should rebase 13:24
MasterDuke my remove opt branch probably
jnthn Today's discovery: if construction work is ruining my concentration, cranking up metal to cover it helps
Maybe I'll try a rebase before I got debugging 13:25
nwc10 rĢˆĆ«bĢˆĆ¤sĢˆĆ«! 13:26
rĢˆeōæ½xCCōæ½x88bĢˆaōæ½xCCōæ½x88sĢˆeōæ½xCCōæ½x88!
jnthn Rebase wasn't so bad this time, at least. 13:35
MasterDuke nwc10: wouldn't `bytes > 1073741824 ? 1073741824 : bytes` make sense instead of `bytes > INT_MAX:w ? 1073741824 : bytes` 13:36
minus the 13:37
':w'
on a roll with my typing right now
jnthn Darn, still segfaulty
Geth MoarVM/new-disp: 212 commits pushed by (Jonathan Worthington)++, (Timo Paulssen)++, (Daniel Green)++
review: github.com/MoarVM/MoarVM/compare/0...913bc9df50		 13:38
MasterDuke jnthn: colabti.org/irclogger/irclogger_lo...03-30#l111 13:39
Geth MoarVM/new-disp: 307cc798f6 | (Jonathan Worthington)++ | 4 files
Fix race and simplify static frame setup

The function `prepare_and_verify_static_frame` is only called from the instrumentation barrier routine, so it need not obtain a lock that is always obtained by the instrumentation barrier routine. Furthermore, it need not check the instrumentation level is zero (that's also done in the caller). Those are the simplifications. ... (16 more lines)
MoarVM/new-disp: 24e5152088 | (Jonathan Worthington)++ | src/core/frame.c
Add a couple of MVM_UNLIKELY
jnthn MasterDuke: ooh, thanks. So did that fix ever make it into master? 13:41
MasterDuke i don't think so...but i think nine is the person to ask 13:43
jnthn "The head commit of new-disp is the tweak for gen2 candidates" - oh, that implies I tried to fix it 13:44
Yes, 67ad85e1bd1 13:45
But then nine++ discovered that more is needed 13:46
Geth MoarVM/new-disp: 38380c9e2c | (Jonathan Worthington)++ | src/6model/reprs/MVMSpeshCandidate.c
Fix unmarked potential gen2 -> nursery references

The MVMStaticFrameSpesh holds the argument guard tree, which may in turn point to nursery objects. We don't currently do those writes through MVM_ASSIGN_REF. For now, conservatively always have the object checked for nursery objects on the next collection. nine++ for working this out.		 13:55
jnthn Yay, seems far more stable now :)
The only `make test` failures in new-disp for Raku now are because of my new-disp-callsame and similar additions, which are temporary workarounds. 13:56
MasterDuke nice
jnthn Only a handful of spectest failures too. Of course, we're not fully using new-disp yet 13:58
The segv is interesting 13:59
nwc10 MasterDuke: Yes, I think so. Seems clearer. It's "write 1G at most"
by the time you're attempting to write blobs of 1G or greater, it seems a bit nuts to presume that it matters whether it's 1 system call. It's certainly not going to be atomic at any lower level 14:00
nine: 14:04
oops
jnthn: well, ASAN got through the NQP build with all the env vars turned on 14:05
and didn't bat an eyelid
(or anything else)
unlike the neighbour's cat, which seemed to think that my finger was a mouse. Or at least, something worth blatting.
MasterDuke github.com/MoarVM/MoarVM/pull/1474 updated
nwc10 (this was actually a couple of weeks ago. Silly thing doesn't realise that fingers are useful - they can open catfood tins) 14:06
jnthn Ouch, if this was batting with claws enabled 14:07
nwc10 yes, but one front foot 14:08
jnthn Glad it builds for you now. I'm looking into a segv that reliably happens in make spectest at the moment
nwc10 it wasn't like I went to tickle its tummy.
(for anyone not familiar with cats, what can happen next is that the two front feet grab your hand and the two back legs attempt to "kill" it - you get very long and deep scratches) 14:16
dogs do not do this.
Geth MoarVM/new-disp: 413735ea4a | (Jonathan Worthington)++ | src/core/interp.c
Use correct bytecode address for IC lookup
 14:23
jnthn And that's the segv fixed 14:24
It seems the remaining spectests I fail are because new-disp doesn't yet implement the latest Raku coercion protocol
MasterDuke so just a rebase is required? or something more? 14:27
jnthn More
MasterDuke ah 14:28
jnthn Nothing MoarVM side, in theory.
MasterDuke so merge new-disp in moarvm today and it gets a full day of testing before the release, i assume that's the plan? 14:30
jnthn haha 14:31
MasterDuke nothing risky there
jnthn nqp and rakudo HEAD won't build on it, because I already removed spesh plugins
(To make sure I'd already ported over everything else)
14:32 lucasb joined
MasterDuke probably wise 14:32
14:34 lucasb left 14:35 lucasb joined 14:36 lucasb left
jnthn Ah, the spesh assignment plugin was updated in the simplest possible way (e.g. doesn't really optimize the coercion case at all), and I can easily steal that change 14:38
And with that, only t/spec/S32-io/io-path-subclasses.t fails 14:43
Guess I'll look at that before I go and do the next big round of breakage :) 14:44
MasterDuke wow, very cool 14:46
jnthn Ah, I think I know which todo this will be :) 14:49
14:50 brrt joined 14:54 LizBot left, LizBot joined 14:55 LizBot left, LizBot joined
nwc10 jnthn: current new-disp master/master/master fails t/04-nativecall/18-routine-sig-sanity.t 15:13
with all the env and debug stuff:
ok 33 - Method are silly
MoarVM panic: Invalid owner in item added to GC worklist
Aborted
So there's still one more of those to be found
jnthn grmbl 15:16
15:17 LizBot left, LizBot joined
Geth MoarVM/new-disp: bd7405be68 | (Jonathan Worthington)++ | src/core/args.c
De-dupe named args in new dispatch flattening
 15:18
jnthn With that todo todone, make spectest on new-disp (without the magic go-boom flags) passes. Of course, this is because we're not *really* using new-disp in full yet.
nwc10 woohoo! 15:19
how is the beer fridge?
15:19 brrt left
nwc10 I'm half doing well - 2 dry days. And half not - 0 days since last hot beverage mishap 15:19
jnthn Mon/Tue are my designated dry days, and yesterday I only had one, so it's not been raided for a while 15:22
15:23 LizBot left
jnthn That said, I've not ordered fresh interesting stuff for a while, so the stout/porter section is dwindling, and the interesting Belgian stuff section isn't looking too good either. 15:23
15:23 LizBot joined
jnthn I keep reading that bot's host mask as "free dominator". Working on compilers has ruined me. 15:24
MasterDuke i've been surprised at how hard it is to find belgians here. but walked past an actual beer store tuesday morning, though sadly it was closed at the time, so plan to go back and see if they have a better selection 15:25
jnthn It just keeps getting easier for me to do that. There's a Belgian beer pub 15 minutes walk away. It can't open at the moment, but it can sell bottles. That's been there as long as I've lived in this district. 15:26
MasterDuke every place had duvel and leffe, but that's it, i haven't seen a single other belgian 15:27
jnthn That's...limited.
The online grocery store I use can offer Kwak most of the time.
And the two you mentioned.
Two weekends ago they opened a new craft beer shop around 20 minutes away. It's a new branch of a shop I already know, but it's the other side of the city, so quite an effort to go to. 15:28
Uh, the original branch is an effort to go to
The new one isn't. I meant to write 20 minutes *walk*. Which is obviously convenient. :) 15:29
15:29 LizBot left 15:30 LizBot joined
nwc10 and I read "original branch is an effort" and thought about version control 15:30
jnthn When I visited the new place they had 2 rooms but only 1 room filled with fridges/shelves of beer. They promised soon their would be "spousta piv" :) 15:31
Which, if they fill the second room too, will certainly be the case.
Anyway, apparently I moved to a good part of the city :)
Aha, t/04-nativecall/18-routine-sig-sanity.t blows up 15:32
(for me too, with the flags)
nwc10 spousta? I figure the other word is pivo
jnthn "plenty" 15:33
nwc10 aha!
some day I hope to visit this place
15:34 brrt joined
MasterDuke belgium is significantly closer to me now than it used to be (6h drive instead of 8h flight), so i'm hoping we get to drive there when things get a bit better. i visited in high school, but didn't really have an appreciation for abby ales at the time... 15:36
15:36 Kaiepi left, Kaiepi joined
nwc10 When beer's involved, I generally prefer other-than-drive to get back (and there) 15:37
jnthn Hm, we're in MVM_disp_inline_cache_mark when we add the pointer to a past fromspace to the worklist
So I'm obviously guilty for that :) 15:38
MasterDuke true, but 6h is long enough there's going to be an overnight stay upon arrival
lizmat cycled about 40km in Belgium yesterday :-)
jnthn oh, MVM_disp_program_mark is on top of it
lizmat ( it's allowed again )
nwc10 woohoo!
but you're making us jealous 15:39
15:40 LizBot left, LizBot joined
MasterDuke that time i visited belgium was a day trip from our longer visit to the netherlands, we were staying in Maastricht 15:40
lizmat sadly, no establishments open yet in Belgium :-(
MasterDuke: I live about 35km from Maastricht
MasterDuke but we took a bus, had to save our energy for the soccer games we were playing
15:42 patrickb left
MasterDuke it was a great trip, i'd been looking forward to going back to the netherlands for yapc:2020 (i think that's the one that was supposed to be in amsterdam?) 15:42
15:43 brrt left
MasterDuke lizmat: sadly i had no perl connections then, didn't get first exposed to it until 2-3 years later 15:44
lizmat yeah, another on in Amsterdam
they've also been in 2001 and 2018
15:46 tellable6 joined, LizBot left, LizBot joined
MasterDuke i've never really been to a yapc. showed up at the end of the last day of the one in DC, and been to two london perl conferences, but that's it 15:46
lizmat well, that's something.. :-)
MasterDuke anyway, afk to grab a beer and head to the garden to push the kids on their swing & 15:47
nine jnthn: just to be sure. While removal of DECONT facts from add_facts in src/spesh/args.c is enough to fix the bug, there's then no longer a reason to handle DECONT facts in spesh arg guards, is there? So that should be removed as well.
(pushing kids)++ 15:48
.oO(well that may have come out wrong...)
nwc10 I push them away, but they keep coming back. Am I doing something wrong? :-) 15:49
aha yes, related - our code term for "swing" was "simple pendulum", as that way the children didn't figure out what the topic was 15:50
15:53 LizBot left
jnthn nine: In the arg guard tree it's not about facts so much as candidate selection 15:54
nine: And there it still matters
15:54 LizBot joined
jnthn But I don't think we can end up with memory safety violations there 15:54
This latest GC issue is a bit odd; everything looks about correct in the inline cache in so far as it enforces barriers 15:55
ah, language class time. Guess this is tomorrow's bug hunt 16:01
16:06 LizBot left, LizBot joined 16:22 LizBot left, LizBot joined 16:23 LizBot left, LizBot joined 16:25 greppable6 joined 16:26 brrt joined
Geth MoarVM/fix_spesh_missing_writes_to_containers: c8c1b4f2b4 | (Stefan Seifert)++ | src/spesh/args.c
Fix spesh missing writes to containers

When containers get passed as arguments (i.e. read/write arguments), we collect statistics on these containers' contents and create facts from them. These facts are guarded by the arg guard tree which is used for selecting spesh candidates, so a candidate relying on these facts will only be run, when the facts hold. ... (12 more lines)		 16:36
MoarVM: niner++ created pull request #1476:
Fix spesh missing writes to containers
16:54 domidumont left 17:06 lucasb joined 17:35 quotable6 joined, MasterDuke left 17:41 zakharyas left 17:43 sxmx1 joined 17:44 brrt left
Geth MoarVM: b553aba6f8 | (Stefan Seifert)++ | src/core/args.c
Remove double-MVMROOT of result in MVM_args_set_result_obj

Commit 90252a8fe8af3efdb307f29b6d91b3cfbd1f1d09 added missing MVMROOTing of result to MVM_args_set_result_str. When doing so I looked around for similar errors and thought I found one in MVM_args_set_result_obj. A second look would have revealed that result was already MVMROOTed just outside the if/else block though.		 17:52
17:59 committable6 joined
nwc10 is double routing just an inefficiency, or can it result in double updates to the same memory location, which cause (later) corruption? I'm wondering how serious it is 18:04
lizmat is rooting re-entrant ? 18:05
18:05 LizBot left
lizmat ā€˜There is a risk that a malfunction of the SpaceX vehicle during these activities will create an overpressure event that can break windows,ā€™ 18:35
.oO( big bada boom! )
jnthn nwc10: It may cause double updates, but with the same new address, so it's harmless 18:39
japhb "overpressure event" *snrk* 18:44
lizmat rapid unexpected disassembly might cause an overpressure event :-) 18:45
sena_kun bad news, it seems we introduced another regression. :| 19:28
tellable6 2021-04-22T18:51:48Z #raku-dev <vrurg> sena_kun gist.github.com/vrurg/a608e01a44e5...205359cf9c
sena_kun I am checking correctness of the bisect.
19:43 MasterDuke joined, linkable6 joined
MasterDuke sena_kun: the GTK::Simple one is it doing something wrong and the test now correctly failing. github.com/finanalyst/GTK-Simple/b...er.pm6#L33 nqp::hllize is only supposed to take one arg 19:46
sena_kun MasterDuke, so we just hid the bug then? 19:48
MasterDuke exactly 19:50
lizmat that's maybe the result of losing that extra parameter for all nqp ops
that was only intended for internal usage ?
sena_kun Now that's a very difficult situation.
MasterDuke github.com/finanalyst/GTK-Simple/pull/104
sena_kun I mean, yes, nqp is "we can break it internal thing", but GTK::Simple is not something I'd be ok with breaking. 19:51
lizmat it's a backward compatible PR 19:52
sena_kun phew
MasterDuke IO::Handle::Rollover bisects to a commit by vrurg 19:54
vrurg I think it's a false positive. Otherwise it'd be triggered much earlier. 19:55
sena_kun re-checks
vrurg The commit is from mid-March and we already had a couple of blin runs since. 19:56
sena_kun oh, yes, this makes sense
the module is not stable then somehow
MasterDuke 'Exception message: Failed to open file /tmp/rollover/rollover.txt: No such file or directory', something with how you're running bling?
*blin 19:57
sena_kun ===> Fetching [FAIL]: IO::Handle::Rollover:ver<1.3.1>:auth<github:atroxaper> from www.cpan.org/authors/id/A/AT/ATROXA...3.1.tar.gz
hmm
vrurg Nothing special about it. Just a disposable VM. 19:58
19:58 leont joined
sena_kun does some testing 19:59
nine MasterDuke: is that PR actually correct?
Wouldn't it with 2 arguments take the first one as the target register? 20:01
sena_kun So far I can confirm it fails on HEAD and works on 03.
MasterDuke hmm, guess it should be `$task := Any` instead 20:03
then i don't understand the point of the original code 20:04
nine Could be. If my reading of QASTCompilerMAST is correct. Could also be that making room for a target register was just the reason for accepting an additional arg, but then it wouldn't be used this way
Well neither interpretation of that code seems to make sense :)
MasterDuke committable6: 2021.03 use nqp; my class Queue is repr("ConcBlockingQueue") { }; my $queue := nqp::create(Queue); my Mu $task := nqp::queuepoll($queue); dd nqp::hllize($task, Any) 20:05
committable6 MasterDuke, Ā¦2021.03: Ā«Anyā¤Ā»
MasterDuke committable6: HEAD use nqp; my class Queue is repr("ConcBlockingQueue") { }; my $queue := nqp::create(Queue); my Mu $task := nqp::queuepoll($queue); dd nqp::hllize($task)
committable6 MasterDuke, Ā¦HEAD(c05b23f): Ā«Muā¤Ā»
MasterDuke committable6: HEAD use nqp; my class Queue is repr("ConcBlockingQueue") { }; my $queue := nqp::create(Queue); my Mu $task := nqp::queuepoll($queue); dd $task := Any 20:06
committable6 MasterDuke, Ā¦HEAD(c05b23f): Ā«Anyā¤Ā»
nine github.com/finanalyst/GTK-Simple/c...ef680c9615 20:07
MasterDuke those aren't exact replications of the code
ha, i've never seen `nqp::p6parcel` before 20:08
nine committable6: 2021.03 use nqp; my $task = 1; nqp::hllize($task, Any); dd $task;
committable6 nine, Ā¦2021.03: Ā«===SORRY!===ā¤Cannot find method 'op' on object of type QAST::Varā¤ Ā«exit code = 1Ā»Ā»
nine committable6: 2021.03 use nqp; my Mu $task = 1; nqp::hllize($task, Any); dd $task; 20:09
committable6 nine, Ā¦2021.03: Ā«===SORRY!===ā¤Cannot find method 'op' on object of type QAST::Varā¤ Ā«exit code = 1Ā»Ā»
nine committable6: 2021.03 use nqp; my Mu $task := 1; nqp::hllize($task, Any); dd $task;
committable6 nine, Ā¦2021.03: Ā«===SORRY!===ā¤Cannot find method 'op' on object of type QAST::Varā¤ Ā«exit code = 1Ā»Ā»
nine I give up...
lizmat p6parcel is pre-GLR is it not ?
nine - nqp::p6parcel($rpa, Any);
+ nqp::p6bindattrinvres(nqp::create(List), List, '$!reified', $rpa)
lizmat ah, *phew* 20:10
nine ChangeLog says for 2015.9 Parcel is no longer a type, use List instead 20:11
20:13 lizmat is now known as lismat, lismat is now known as lizmat 20:15 lizmat is now known as lismat, lismat is now known as lizmat
MasterDuke just removing that second argument does make the test pass, but i suspect that code isn't getting exercised 20:16
it isn't
nine Well with your PR the code makes most sense. Who knows, maybe it fixed another bug as well? 20:19
MasterDuke m: use nqp; my $a := nqp::list(1, 2, 3); dd $a.WHAT; my $b := nqp::hllize($a); dd $b.WHAT 20:23
camelia ()
List
MasterDuke so yeah, i think the PR is correct 20:24
so switching modules, i can repro the fails in IO::Handle::Rollober 20:25
sena_kun MasterDuke, it's odd, so far I can reliably have no issues on the previous release, but on HEAD it always fails for me. 20:29
But on the commit it was bisected to, it works.
vrurg sena_kun: was you bisecting IO::Handle::Rollover? 20:33
sena_kun vrurg, ? Blin bisected it to your commit, but I think it's bad. I would say the test can be race-y, but I don't understand how it always passes on release and fails on HEAD for me. 20:40
s/it's bad/the commit it bisected to is innocent/
vrurg sena_kun: my point is wether it makes sense to bisect manually. But I'm doing it anyway already. 20:41
sena_kun vrurg, yes, you won't be doing double work this way.
*"duplicated work" maybe
vrurg I have 95% of bisection automated, so it's not much work anyway. 20:45
21:04 Kaiepi left, Kaiepi joined 21:39 dogbert12 joined 21:41 dogbert17 left 21:44 LizBot joined 21:48 dogbert17 joined 21:52 dogbert12 left 22:29 sena_kun left 22:54 dogbert11 joined 22:58 dogbert17 left 23:40 nativecallable6 joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!