Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-02

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 Zoffix \o
00:30 ugexe https://github.com/MoarVM/MoarVM/blob/a9f477011079e35667622089b73faf41835cdfe4/src/core/threadcontext.c#L13 is this comment backwards, or does the logic just look that way?
00:31 ugexe having pasted that i now understand
00:33 ugexe i think i was confused trying to perceive if it was used in a thread safe way in the context of event loop per thread
01:38 samcv i've been thinking of making concatenation work with more than 2 strings. though technically i guess i could do it for 3 strings since with my renormalized_section code it actually *does* concatenate 3 parts
01:38 samcv but seems like a pain to do it versus the amount of time to commit to it
01:38 samcv and luckily i already got join to be much faster for long strings so that's quite nice
01:39 samcv if i *do* do it. i'd probably need to break it down into new functions to make it easier to compose a strand based string
01:41 samcv though i kinda would like that…
01:41 samcv even if i don't make concatenate able to do more things. it would be nice to have an easy function to add strands onto a string. maybe adding a new struct to hold the relevant data needed during its composition
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: cc721c8515 | (Timo Paulssen)++ | 6 files
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: subtract size of profiling ops from bytecode size
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize:
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: so that turning profiling on can't push some functions
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: over the inline size limit, which causes differences
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: between profiled and non-profiled runs.
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize:
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: Not inlining some candidate only during profiling can
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: have ripple effects if an inlined piece of code causes
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: a bigger frame to bail in the JIT.
01:59 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: review: https://github.com/MoarVM/MoarVM/commit/cc721c8515
02:04 Geth ¦ MoarVM: timo++ created pull request #744: subtract size of profiling ops from bytecode size
02:04 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/744
02:07 colomon joined #moarvm
02:10 timotimo hm. logging this seems kind of nondeterministic; in one run i get no changes, in the next i get two inlines in the compilation phase, in another i only get one from the "run time" portion
02:11 timotimo "sunk" getting inlined into "wanted" and "visit_op" now that didn't use to be the case
02:11 timotimo actually, i put the log before the code that actually inspects the inlinee's graph in depth
02:13 timotimo wow, the difference is especially drastic with MARKER (being inlined into _ws) which is 566 with instrumentation but 176 without
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:04 KDr2 joined #moarvm
03:46 timotimo can't sleep and what is this? "cannot find appropriate pred to update" mvm oopses? holy crap
03:47 timotimo my changes shouldn't have any effect if profiling isn't active
03:52 timotimo remember, kids: always null your fields
03:52 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: ecc6bf0692 | (Timo Paulssen)++ | src/spesh/codegen.c
03:52 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: ignore PHI and initialize ignored_bytes field
03:52 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: review: https://github.com/MoarVM/MoarVM/commit/ecc6bf0692
04:08 timotimo all of the frames that end up below the inlining threshold because the instrumentation overhead is subtracted bail out because of either lastexpayload or (rarely) takeclosure
04:10 timotimo aha, it's also ignoring extops. that's certainly wrong
04:15 timotimo i'm not sure if lastexpayload should be noinline.
04:17 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: d799fdb132 | (Timo Paulssen)++ | src/spesh/codegen.c
04:17 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: don't ignore extops for size calculation
04:17 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: review: https://github.com/MoarVM/MoarVM/commit/d799fdb132
04:17 timotimo in any case, i'm spectesting a moar that allows lastexpayload to be inlined
04:21 timotimo hm. t/02-rakudo/repl.t fails with "Cannot receive a message on a closed channel"
04:22 mtj_ joined #moarvm
04:27 timotimo t/spec/S05-metasyntax/regex.t has a test for "no unhandled failures left around"; it outputs a few hundred screenfuls of warnings instead of "" :\
04:29 timotimo t/spec/S10-packages/basic.rakudo.moar fails under the harness (crashes the last test) but not on its own
04:36 timotimo t/spec/S32-str/CollationTest_NON_IGNORABLE-3.t plans 1246 tests, but runs only 1056; its output ends in "Failed: none"
04:45 samcv timotimo, i'm going to add MVMROOT2 MVMROOT3 and MVMROOT4 that should make using multiple MVMROOT's cleaner codewise and not have us have to do a ton of MVMROOT's one after another. in string_concatenate we have 4 after another
06:42 brrt joined #moarvm
06:45 brrt good * #moarvm
06:48 samcv good * brrt
06:54 brrt what's up?
06:55 samcv not much. converting MVMROOT into MVMROOT2 MVMROOT3 MVMROOT4 MVMROOT5's
06:55 samcv which should make code a lot cleaner when we need multiple MVMROOT's
06:56 samcv the max number of MVMROOT's on sequential lines i've found has been 5!
06:58 brrt oh wow
06:59 brrt unfortunately we can't do recursive macros
06:59 samcv makes things look sooooo much nicer doing this
06:59 samcv well yeah. i just added multiple MVMROOT's
06:59 samcv so it pushes X number of times and then it runs MVM_root_pop_n(X)
07:00 samcv so slightly more efficient with the popping. but mostly just much less distraction and such having to look at so many MVMROOT's
07:01 samcv wonder how many lines i'll save
07:02 brrt pretty cool
07:03 samcv i had thought of doing this a while ago, but never got around to it
07:03 brrt yeah, i know what that's like
07:16 domidumont joined #moarvm
07:17 samcv will be a ton easier to add test adding or removing something from an MVMROOT as well
07:17 samcv just the variable + ', ' instead of having to mess with adding extra braces and parens and stuff
07:35 domidumont joined #moarvm
07:37 domidumont joined #moarvm
07:40 travis-ci joined #moarvm
07:40 travis-ci MoarVM build failed. Samantha McVey 'Add MVMROOT2..MVMROOT5 to make rooting multiple variables easier
07:40 travis-ci https://travis-ci.org/samcv/MoarVM/builds/296135710 https://github.com/samcv/MoarVM/compare/3e4ed6bffed1...87191078c38b
07:40 travis-ci left #moarvm
08:00 brrt joined #moarvm
08:00 brrt uhuh
08:06 samcv ah that makes sense. since i don't have tags
08:07 Geth ¦ MoarVM: 87191078c3 | (Samantha McVey)++ | 34 files
08:07 Geth ¦ MoarVM: Add MVMROOT2..MVMROOT5 to make rooting multiple variables easier
08:07 Geth ¦ MoarVM:
08:07 Geth ¦ MoarVM: This makes it much easier and visually cleaner to root multiple
08:07 Geth ¦ MoarVM: variables at once. Should not have much impact on speed since the only
08:07 Geth ¦ MoarVM: extra efficiency is one call to pop instead of multiple.
08:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/87191078c3
08:30 zakharyas joined #moarvm
08:36 zakharyas joined #moarvm
09:25 robertle joined #moarvm
10:02 zakharyas joined #moarvm
11:06 zakharyas joined #moarvm
11:29 bisectable6 joined #moarvm
12:19 lizmat https://assets.bitbashing.io/papers/lockless.pdf  # is this something good ?
12:21 lizmat apparently a better title would have been: What every C++ systems programmer should know about std::atomic
12:22 lizmat so probably not of use here, so sorry for the noise  :-)
12:25 dogbert2 I'll add to the noise :) http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html  # Fibers and Continuations for the Java Virtual Machine
12:40 brrt re: that java thing
12:40 brrt i read that, and i don't think continuations are the proper abstraction for java
12:42 brrt in fact, i think continuations are not a very good abstraction, in general
12:46 brrt but java, is stack machine all the way
12:50 dogbert2 and those are not continuation friendly?
12:50 dogbert2 i.e. difficult to implement
12:54 brrt it depends on what you want your continuations to do
12:54 brrt 'true' continuations are hard because they effectively must copy the *entire* thread state
12:55 brrt for a green thread i mplementation, a one-shot delimited continuation is much simpler
12:55 brrt in which case, most people just shut up and call *that* a thread
12:56 brrt or fiber, or whatever
13:19 jnthn I'd say one-shot continuations are OK plumbing, which is what we do rather than directly exposing them
13:39 lizmat jnthn: there is no way to reset attrinited state, right ?
13:41 lizmat setting default fails in this case because the attribute is already marked because of the additional attribute set up:
13:41 lizmat m: class A { has %.a is SetHash = 1,2,3 }; dd A.new
13:41 camelia rakudo-moar c2baf95e1: OUTPUT: «A.new(a => SetHash.new())␤»
13:41 lizmat m: class A { has @.a[3] = 1,2,3 }; dd A.new   # fails for the same reason
13:41 camelia rakudo-moar c2baf95e1: OUTPUT: «A.new(a => Array.new(:shape(3,), [Any, Any, Any]))␤»
13:42 jnthn lizmat: There isn't actually any attrinited stage
13:42 jnthn *state
13:42 jnthn It's just the absence of the field having been vivified
13:43 lizmat ok, so then we need another way to mark: this needs initialization for the above cases (involving BUILDPLAN code 9)
13:44 zakharyas joined #moarvm
13:55 lizmat jnthn: perhaps it would be an idea to push an additional TWEAK into the buildplan in that case?
13:58 jnthn Additional TWEAK?
14:00 lizmat well, a code block to be executed at the end
14:00 jnthn But how would we decide whether to run it?
14:00 lizmat basically like this:
14:00 lizmat class A { has @.a[4]; method TWEAK(:@a) { say "tweaking";  @!a = 1,2,3,4 unless @a } }; dd A.new
14:00 jnthn And what then about
14:00 lizmat m: class A { has @.a[4]; method TWEAK(:@a) { say "tweaking";  @!a = 1,2,3,4 unless @a } }; dd A.new
14:00 camelia rakudo-moar c2baf95e1: OUTPUT: «tweaking␤A.new(a => Array.new(:shape(4,), [1, 2, 3, 4]))␤»
14:01 lizmat m: class A { has @.a[4]; method TWEAK(:@a) { say "tweaking";  @!a = 1,2,3,4 unless @a } }; dd A.new(a => (4,5,6,7))
14:01 camelia rakudo-moar c2baf95e1: OUTPUT: «tweaking␤A.new(a => Array.new(:shape(4,), [4, 5, 6, 7]))␤»
14:01 jnthn Oh, you're seeing if @a was passed
14:01 lizmat yup
14:01 jnthn Thing is
14:02 jnthn There's no promise that we didn't assign more indirectly
14:02 lizmat yeah :-(
14:02 jnthn I don't know how to solve this. I've never much liked the attrinnited thing
14:03 * lizmat neither...
14:03 jnthn I don't think it's possible to make that appraoch robust, and it isn't a very performant thing to provide
14:03 lizmat but if we can't fix this (at leas not now)
14:03 jnthn Or more to the point, providing it costs us
14:03 jnthn By making it hard to get rid of the lazy attribute initialization thing
14:03 lizmat perhaps we shouldn't allow defaults on BUILDPLAN code 9 things
14:04 lizmat so basically make it a NYI
14:04 jnthn And, as these cases bring up, we can't actually get every case to work on lazy attr init either
14:04 jnthn At some point we need to work out what we really mean by "the attribute was set"
14:05 lizmat yeah, ok, so I'm going to make it a NYI
14:05 lizmat class A { has @.a[4] = 1,2,3 }  and class A { has %h is SetHash = 1,2,3 }
14:06 lizmat is that a plan for now ?
14:07 MasterDuke joined #moarvm
14:07 jnthn Yeah, at least it'll prevent people some frustration
14:08 lizmat ok
14:10 MasterDuke hello all (from a train, so likely to drop off intermittently)
14:11 MasterDuke anybody have thoughts/comments about https://github.com/MoarVM/MoarVM/pull/737 (and the subsequent nqp+rakudo PRs)?
14:12 Zoffix MasterDuke: yeah, we need that op, but I don't got enough skill to successfully review that PR :)
14:18 * dogbert2 closed two MoarVM tickets, #721 and #724, because jnhtn++ fixed them some time ago
14:18 jnthn MasterDuke: Reviewed it
14:19 MasterDuke jnthn: thanks, i just noticed that missing MVMROOT
14:19 MasterDuke there is at least one other missing one though, because i copied that line from MVM_bigint_from_num
14:20 jnthn If that's a num64, then that's not a GC-able value
14:21 stmuk_ joined #moarvm
14:22 MasterDuke `MVMObject * const result = MVM_repr_alloc_init(tc, result_type);` but this line doesn't depend on what the other arg is, right?
14:23 jnthn result_type is only used there so it need not be rooted
14:24 MasterDuke but it's also only used there in my new function?
14:25 jnthn Yes, it's `a` that needs rooting
14:25 MasterDuke ah
14:26 lizmat jnthn timotimo is there a way to get at the World object while in create_BUILDPLAN ?
14:26 jnthn $*W
14:27 lizmat ack
14:27 jnthn You know the compiler is in scope, so should be safe
14:33 MasterDuke PR updated
14:37 zakharyas joined #moarvm
15:21 japhb joined #moarvm
16:04 lizmat m: m: use Telemetry; say T.max-rss  # object method interface
16:04 camelia rakudo-moar 0973b307a: OUTPUT: «87168␤»
16:04 lizmat m: m: use Telemetry :COLUMNS; say max-rss  # subroutine interface
16:04 camelia rakudo-moar 0973b307a: OUTPUT: «117148␤»
16:04 lizmat 30MB difference ??  wow
16:05 timotimo lizmat: it could come down to what gets deserialized and what doesn't
16:05 timotimo i can give you a moarvm patch that gives you a tiny bit of info about that
16:05 brrt joined #moarvm
16:06 lizmat timotimo: a moarvm patch is too dangerous in my hands
16:06 timotimo haha
16:06 timotimo patch responsibly
16:07 lizmat seriously though, I will need some serious guidance before I feel comfortable hacking on Moar
16:07 timotimo all that patch would do is spit out what gets deserialized
16:08 lizmat a bit like "use trace" as it were?
16:08 lizmat m: use trace: say "foo"; no trace; say "bar"
16:08 camelia rakudo-moar 0973b307a: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Confused␤at <tmp>:1␤------> use trace⏏: say "foo"; no trace; say "bar"␤»
16:08 lizmat m: use trace; say "foo"; no trace; say "bar"
16:08 camelia rakudo-moar 0973b307a: OUTPUT: «2 (<tmp> line 1)␤say "foo"␤foo␤bar␤»
16:11 brrt lizmat: we can give that guidance
16:11 brrt we have the technology
16:13 lizmat :-)
16:16 timotimo samcv: src/strings/unicode.c:71935:20: warning: return makes integer from pointer without a cast [-Wint-conversion]
16:16 timotimo return "";
16:16 timotimo what this?
16:17 brrt that funcrtion doesn't have the proper type specified?
16:17 timotimo perhaps
16:17 timotimo ah because int is the default return type?
16:19 jnthn iirc, if you don't puta a return type, it defaults to int
16:19 jnthn *put a :P
16:23 unicodable6 joined #moarvm
16:24 timotimo that much is true
16:26 Geth ¦ MoarVM: e4b39aa1dc | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c
16:26 Geth ¦ MoarVM: show the actual type when "no such attribute" error occurs
16:26 Geth ¦ MoarVM:
16:26 Geth ¦ MoarVM: until now it only showed the type that was specified as the
16:26 Geth ¦ MoarVM: one having the attribute; no indication of whether the type
16:26 Geth ¦ MoarVM: has anything to do with the object being operated upon.
16:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e4b39aa1dc
16:28 timotimo jnthn: do you think it makes sense to optimize $!todo.DEFINITE to first look if attrinited gives true?
16:30 jnthn No, I think attrinited is going away
16:30 jnthn Along with all lazy attribute vivification
16:32 timotimo thread safety issues?
16:33 jnthn That plus it makes the JIT for reading attributes giant/branchy
16:33 timotimo mhm
16:34 jnthn But yeah, that you can very easily trip over it when writing lock-free data structures is also bad
16:44 Geth ¦ MoarVM/deserialization_debugspam: 0acc10814c | (Timo Paulssen)++ | src/6model/serialization.c
16:44 Geth ¦ MoarVM/deserialization_debugspam: debugspam what objects get deserialized
16:44 Geth ¦ MoarVM/deserialization_debugspam: review: https://github.com/MoarVM/MoarVM/commit/0acc10814c
16:59 brrt wait, attribute autovivis going away?
16:59 brrt yay!
17:00 brrt next thing you'll tell me is we're going to get rid of containers :-P
17:46 zakharyas joined #moarvm
18:06 zakharyas joined #moarvm
18:09 Ven joined #moarvm
18:27 domidumont joined #moarvm
18:59 MasterDuke joined #moarvm
19:32 Geth ¦ MoarVM: 25bbba8c57 | (Samantha McVey)++ | 2 files
19:32 Geth ¦ MoarVM: unicode: make sure to return 0 not "" from get_property_int
19:32 Geth ¦ MoarVM:
19:32 Geth ¦ MoarVM: Accidently put the same return value as for get_property_str. The return
19:32 Geth ¦ MoarVM: value should be 0 which is what we had been doing prior.
19:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/25bbba8c57
19:32 samcv timotimo, fixed that error
19:33 Ven joined #moarvm
19:33 samcv actually that can probably be simplified and just return 0 if it can't find the bitfield row like before. sorta.. was mainly the str one that needed to be fixed so it would return the default enum value
19:34 samcv but i still am not sure how to fix getting <:C> to match Cn things
19:35 samcv oh looks like MVM_UNICODE_PROPERTY_C
19:38 samcv nice! i think i solved that bug
19:39 samcv if we can't find the codepoint in the bitfield rows, what we do for the int prop lookup is return 0. but that neglects the fact that the C property is boolean, and since unknowns are Cn general category that needs to be true
19:40 samcv though annoyingly how can we tell the difference between hard 0 and soft 0 (nothing found). uncertain
19:41 samcv though for the collation stuff i just had everything off by 1 so 0 would be nothing found and 1 would be "0" from the UCD database for collation
19:47 AlexDaniel joined #moarvm
19:56 wander joined #moarvm
20:00 samcv i feel accomplished now :)
20:16 zakharyas joined #moarvm
20:22 MasterDuke jnthn: think https://github.com/MoarVM/MoarVM/pull/737, https://github.com/MoarVM/MoarVM/pull/734, and https://github.com/MoarVM/MoarVM/pull/689 are good now?
20:22 Geth ¦ MoarVM: e767888195 | (Samantha McVey)++ | 2 files
20:22 Geth ¦ MoarVM: unicode: Make sure 'Cn' codepoints match with C enum
20:22 Geth ¦ MoarVM:
20:22 Geth ¦ MoarVM: Unassigned codepoints have General Category Cn. Since this returns 0
20:22 Geth ¦ MoarVM: for unknowns, unless we return 1 for property C then these unknows
20:22 Geth ¦ MoarVM: won't match with <:C>.
20:22 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e767888195
20:23 wander left #moarvm
20:40 jnthn MasterDuke: Close, but no cigar
20:42 MasterDuke of course. after the root, or inside?
21:01 jnthn after
21:02 jnthn Well, either will work
21:02 jnthn But after is probably more natural
21:02 MasterDuke k, will do
21:23 MasterDuke jnthnupdated again
21:23 MasterDuke jnthn++ updated again (ugh, this one-handed typing)
21:33 * Zoffix stifles a laugh
22:21 cognominal joined #moarvm
23:06 lizmat Sanity check: with this code:
23:06 lizmat await (^16).map({start { qqx{echo -n foo $_} } })
23:07 lizmat I can see there are 16 general worker threads.  I sorta woulda have expected to also see 16 affinity worker threads
23:07 lizmat am seeing only one
23:08 lizmat is that to be expected ?
23:08 lizmat this is about GH #1202, btw
23:16 lizmat sleep&
23:27 evalable6 joined #moarvm
23:37 Geth ¦ MoarVM/master: 4 commits pushed by MasterDuke17++, (Jonathan Worthington)++
23:37 Geth ¦ MoarVM/master: 9b9bd1bf45 | Create and JIT coerce_II op
23:37 Geth ¦ MoarVM/master: 3821a09d9d | Add a missing MVMROOT to MVM_bigint_from_bigint
23:37 Geth ¦ MoarVM/master: 723269978c | Move assignment after MVMROOT
23:37 Geth ¦ MoarVM/master: 5a66a38511 | Merge pull request #737 from MasterDuke17/create_coerce_II_op
23:37 Geth ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/e767888195...5a66a38511
23:38 Geth ¦ MoarVM: 9aa99f3e9f | (Nick Logan)++ | 2 files
23:38 Geth ¦ MoarVM: Add more missing MVMROOTs
23:38 Geth ¦ MoarVM:
23:38 Geth ¦ MoarVM: See: 9ad1f5f
23:38 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9aa99f3e9f
23:38 Geth ¦ MoarVM: b7b1f3e40f | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
23:38 Geth ¦ MoarVM: Merge pull request #742 from ugexe/more_mvmroot_redo
23:38 Geth ¦ MoarVM:
23:38 Geth ¦ MoarVM: Add more missing MVMROOTs
23:38 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b7b1f3e40f
23:39 MasterDuke thanks, jnthn++
23:40 * Zoffix bumps
23:41 Geth ¦ MoarVM/master: 4 commits pushed by (Nick Logan)++, (Jonathan Worthington)++
23:41 Geth ¦ MoarVM/master: e71739ec79 | Retry in certain cases of EINTR
23:41 Geth ¦ MoarVM/master: 1fba3a5e39 | Fix copy pasta
23:41 Geth ¦ MoarVM/master: a74163dde9 | Fix unneeded gc blocking in loop
23:41 Geth ¦ MoarVM/master: f88ab169d5 | Merge pull request #738 from ugexe/eintr_retry
23:41 Geth ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/b7b1f3e40f...f88ab169d5
23:44 jnthn .tell lizmat Yes, we only create a new affinity workers reluctantly, e.g. if the existing ones have stuff in their queues.
23:44 yoleaux jnthn: I'll pass your message to lizmat.
23:48 jnthn .tell lizmat That tends to work out pretty well: web servers scale their threads for message handling appropriately by load, for example.
23:48 yoleaux jnthn: I'll pass your message to lizmat.

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary