Zoffix \o 00:00
ugexe github.com/MoarVM/MoarVM/blob/a9f4...text.c#L13 is this comment backwards, or does the logic just look that way? 00:30
having pasted that i now understand 00:31
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 00:33
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
but seems like a pain to do it versus the amount of time to commit to it
and luckily i already got join to be much faster for long strings so that's quite nice
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:39
though i kinda would like that… 01:41
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
Geth MoarVM/inline_ignore_instrumentation_bytesize: cc721c8515 | (Timo Paulssen)++ | 6 files
subtract size of profiling ops from bytecode size

so that turning profiling on can't push some functions over the inline size limit, which causes differences between profiled and non-profiled runs.
Not inlining some candidate only during profiling can have ripple effects if an inlined piece of code causes a bigger frame to bail in the JIT.		 01:59
MoarVM: timo++ created pull request #744:
subtract size of profiling ops from bytecode size		 02:04
02:07 colomon joined
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:10
"sunk" getting inlined into "wanted" and "visit_op" now that didn't use to be the case 02:11
actually, i put the log before the code that actually inspects the inlinee's graph in depth
wow, the difference is especially drastic with MARKER (being inlined into _ws) which is 566 with instrumentation but 176 without 02:13
02:56 ilbot3 joined 03:04 KDr2 joined
timotimo can't sleep and what is this? "cannot find appropriate pred to update" mvm oopses? holy crap 03:46
my changes shouldn't have any effect if profiling isn't active 03:47
remember, kids: always null your fields 03:52
Geth MoarVM/inline_ignore_instrumentation_bytesize: ecc6bf0692 | (Timo Paulssen)++ | src/spesh/codegen.c
ignore PHI and initialize ignored_bytes field
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:08
aha, it's also ignoring extops. that's certainly wrong 04:10
i'm not sure if lastexpayload should be noinline. 04:15
Geth MoarVM/inline_ignore_instrumentation_bytesize: d799fdb132 | (Timo Paulssen)++ | src/spesh/codegen.c
don't ignore extops for size calculation
 04:17
timotimo in any case, i'm spectesting a moar that allows lastexpayload to be inlined
hm. t/02-rakudo/repl.t fails with "Cannot receive a message on a closed channel" 04:21
04:22 mtj_ joined
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:27
t/spec/S10-packages/basic.rakudo.moar fails under the harness (crashes the last test) but not on its own 04:29
t/spec/S32-str/CollationTest_NON_IGNORABLE-3.t plans 1246 tests, but runs only 1056; its output ends in "Failed: none" 04:36
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 04:45
06:42 brrt joined
brrt good * #moarvm 06:45
samcv good * brrt 06:48
brrt what's up? 06:54
samcv not much. converting MVMROOT into MVMROOT2 MVMROOT3 MVMROOT4 MVMROOT5's 06:55
which should make code a lot cleaner when we need multiple MVMROOT's
the max number of MVMROOT's on sequential lines i've found has been 5! 06:56
brrt oh wow 06:58
unfortunately we can't do recursive macros 06:59
samcv makes things look sooooo much nicer doing this
well yeah. i just added multiple MVMROOT's
so it pushes X number of times and then it runs MVM_root_pop_n(X)
so slightly more efficient with the popping. but mostly just much less distraction and such having to look at so many MVMROOT's 07:00
wonder how many lines i'll save 07:01
brrt pretty cool 07:02
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
samcv will be a ton easier to add test adding or removing something from an MVMROOT as well 07:17
just the variable + ', ' instead of having to mess with adding extra braces and parens and stuff
07:35 domidumont joined 07:37 domidumont joined 07:40 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Add MVMROOT2..MVMROOT5 to make rooting multiple variables easier 07:40
travis-ci.org/samcv/MoarVM/builds/296135710 github.com/samcv/MoarVM/compare/3e...191078c38b
07:40 travis-ci left 08:00 brrt joined
brrt uhuh 08:00
samcv ah that makes sense. since i don't have tags 08:06
Geth MoarVM: 87191078c3 | (Samantha McVey)++ | 34 files
Add MVMROOT2..MVMROOT5 to make rooting multiple variables easier

This makes it much easier and visually cleaner to root multiple variables at once. Should not have much impact on speed since the only extra efficiency is one call to pop instead of multiple.		 08:07
08:30 zakharyas joined 08:36 zakharyas joined 09:25 robertle joined 10:02 zakharyas joined 11:06 zakharyas joined 11:29 bisectable6 joined
lizmat assets.bitbashing.io/papers/lockless.pdf # is this something good ? 12:19
apparently a better title would have been: What every C++ systems programmer should know about std::atomic 12:21
so probably not of use here, so sorry for the noise :-) 12:22
dogbert2 I'll add to the noise :) cr.openjdk.java.net/~rpressler/loom...posal.html # Fibers and Continuations for the Java Virtual Machine 12:25
brrt re: that java thing 12:40
i read that, and i don't think continuations are the proper abstraction for java
in fact, i think continuations are not a very good abstraction, in general 12:42
but java, is stack machine all the way 12:46
dogbert2 and those are not continuation friendly? 12:50
i.e. difficult to implement
brrt it depends on what you want your continuations to do 12:54
'true' continuations are hard because they effectively must copy the *entire* thread state
for a green thread i mplementation, a one-shot delimited continuation is much simpler 12:55
in which case, most people just shut up and call *that* a thread
or fiber, or whatever 12:56
jnthn I'd say one-shot continuations are OK plumbing, which is what we do rather than directly exposing them 13:19
lizmat jnthn: there is no way to reset attrinited state, right ? 13:39
setting default fails in this case because the attribute is already marked because of the additional attribute set up: 13:41
m: class A { has %.a is SetHash = 1,2,3 }; dd A.new
camelia A.new(a => SetHash.new())
lizmat m: class A { has @.a[3] = 1,2,3 }; dd A.new # fails for the same reason
camelia A.new(a => Array.new(:shape(3,), [Any, Any, Any]))
jnthn lizmat: There isn't actually any attrinited stage 13:42
*state
It's just the absence of the field having been vivified
lizmat ok, so then we need another way to mark: this needs initialization for the above cases (involving BUILDPLAN code 9) 13:43
13:44 zakharyas joined
lizmat jnthn: perhaps it would be an idea to push an additional TWEAK into the buildplan in that case? 13:55
jnthn Additional TWEAK? 13:58
lizmat well, a code block to be executed at the end 14:00
jnthn But how would we decide whether to run it?
lizmat basically like this:
class A { has @.a[4]; method TWEAK(:@a) { say "tweaking"; @!a = 1,2,3,4 unless @a } }; dd A.new
jnthn And what then about
lizmat m: class A { has @.a[4]; method TWEAK(:@a) { say "tweaking"; @!a = 1,2,3,4 unless @a } }; dd A.new
camelia tweaking
A.new(a => Array.new(:shape(4,), [1, 2, 3, 4]))
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 tweaking
A.new(a => Array.new(:shape(4,), [4, 5, 6, 7]))
jnthn Oh, you're seeing if @a was passed
lizmat yup
jnthn Thing is
There's no promise that we didn't assign more indirectly 14:02
lizmat yeah :-(
jnthn I don't know how to solve this. I've never much liked the attrinnited thing
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
lizmat but if we can't fix this (at leas not now)
jnthn Or more to the point, providing it costs us
By making it hard to get rid of the lazy attribute initialization thing
lizmat perhaps we shouldn't allow defaults on BUILDPLAN code 9 things
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
At some point we need to work out what we really mean by "the attribute was set"
lizmat yeah, ok, so I'm going to make it a NYI 14:05
class A { has @.a[4] = 1,2,3 } and class A { has %h is SetHash = 1,2,3 }
is that a plan for now ? 14:06
14:07 MasterDuke joined
jnthn Yeah, at least it'll prevent people some frustration 14:07
lizmat ok 14:08
MasterDuke hello all (from a train, so likely to drop off intermittently) 14:10
anybody have thoughts/comments about github.com/MoarVM/MoarVM/pull/737 (and the subsequent nqp+rakudo PRs)? 14:11
Zoffix MasterDuke: yeah, we need that op, but I don't got enough skill to successfully review that PR :) 14:12
dogbert2 closed two MoarVM tickets, #721 and #724, because jnhtn++ fixed them some time ago 14:18
jnthn MasterDuke: Reviewed it
MasterDuke jnthn: thanks, i just noticed that missing MVMROOT 14:19
there is at least one other missing one though, because i copied that line from MVM_bigint_from_num
jnthn If that's a num64, then that's not a GC-able value 14:20
14:21 stmuk_ joined
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:22
jnthn result_type is only used there so it need not be rooted 14:23
MasterDuke but it's also only used there in my new function? 14:24
jnthn Yes, it's `a` that needs rooting 14:25
MasterDuke ah
lizmat jnthn timotimo is there a way to get at the World object while in create_BUILDPLAN ? 14:26
jnthn $*W
lizmat ack 14:27
jnthn You know the compiler is in scope, so should be safe
MasterDuke PR updated 14:33
14:37 zakharyas joined 15:21 japhb joined
lizmat m: m: use Telemetry; say T.max-rss # object method interface 16:04
camelia 87168
lizmat m: m: use Telemetry :COLUMNS; say max-rss # subroutine interface
camelia 117148
lizmat 30MB difference ?? wow
timotimo lizmat: it could come down to what gets deserialized and what doesn't 16:05
i can give you a moarvm patch that gives you a tiny bit of info about that
16:05 brrt joined
lizmat timotimo: a moarvm patch is too dangerous in my hands 16:06
timotimo haha
patch responsibly
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
lizmat a bit like "use trace" as it were? 16:08
m: use trace: say "foo"; no trace; say "bar"
camelia ===SORRY!=== Error while compiling <tmp>
Confused
at <tmp>:1
------> use trace⏏: say "foo"; no trace; say "bar"
lizmat m: use trace; say "foo"; no trace; say "bar"
camelia 2 (<tmp> line 1)
say "foo"
foo
bar
brrt lizmat: we can give that guidance 16:11
we have the technology
lizmat :-) 16:13
timotimo samcv: src/strings/unicode.c:71935:20: warning: return makes integer from pointer without a cast [-Wint-conversion] 16:16
return "";
what this?
brrt that funcrtion doesn't have the proper type specified? 16:17
timotimo perhaps
ah because int is the default return type?
jnthn iirc, if you don't puta a return type, it defaults to int 16:19
*put a :P
16:23 unicodable6 joined
timotimo that much is true 16:24
Geth MoarVM: e4b39aa1dc | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c
show the actual type when "no such attribute" error occurs

until now it only showed the type that was specified as the one having the attribute; no indication of whether the type has anything to do with the object being operated upon.		 16:26
timotimo jnthn: do you think it makes sense to optimize $!todo.DEFINITE to first look if attrinited gives true? 16:28
jnthn No, I think attrinited is going away 16:30
Along with all lazy attribute vivification
timotimo thread safety issues? 16:32
jnthn That plus it makes the JIT for reading attributes giant/branchy 16:33
timotimo mhm
jnthn But yeah, that you can very easily trip over it when writing lock-free data structures is also bad 16:34
Geth MoarVM/deserialization_debugspam: 0acc10814c | (Timo Paulssen)++ | src/6model/serialization.c
debugspam what objects get deserialized
 16:44
brrt wait, attribute autovivis going away? 16:59
yay!
next thing you'll tell me is we're going to get rid of containers :-P 17:00
17:46 zakharyas joined 18:06 zakharyas joined 18:09 Ven joined 18:27 domidumont joined 18:59 MasterDuke joined
Geth MoarVM: 25bbba8c57 | (Samantha McVey)++ | 2 files
unicode: make sure to return 0 not "" from get_property_int

Accidently put the same return value as for get_property_str. The return value should be 0 which is what we had been doing prior.		 19:32
samcv timotimo, fixed that error
19:33 Ven joined
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:33
but i still am not sure how to fix getting <:C> to match Cn things 19:34
oh looks like MVM_UNICODE_PROPERTY_C 19:35
nice! i think i solved that bug 19:38
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:39
though annoyingly how can we tell the difference between hard 0 and soft 0 (nothing found). uncertain 19:40
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:41
19:47 AlexDaniel joined 19:56 wander joined
samcv i feel accomplished now :) 20:00
20:16 zakharyas joined
MasterDuke jnthn: think github.com/MoarVM/MoarVM/pull/737, github.com/MoarVM/MoarVM/pull/734, and github.com/MoarVM/MoarVM/pull/689 are good now? 20:22
Geth MoarVM: e767888195 | (Samantha McVey)++ | 2 files
unicode: Make sure 'Cn' codepoints match with C enum

Unassigned codepoints have General Category Cn. Since this returns 0 for unknowns, unless we return 1 for property C then these unknows won't match with <:C>.
20:23 wander left
jnthn MasterDuke: Close, but no cigar 20:40
MasterDuke of course. after the root, or inside? 20:42
jnthn after 21:01
Well, either will work 21:02
But after is probably more natural
MasterDuke k, will do
jnthnupdated again 21:23
jnthn++ updated again (ugh, this one-handed typing)
Zoffix stifles a laugh 21:33
22:21 cognominal joined
lizmat Sanity check: with this code: 23:06
await (^16).map({start { qqx{echo -n foo $_} } })
I can see there are 16 general worker threads. I sorta woulda have expected to also see 16 affinity worker threads 23:07
am seeing only one
is that to be expected ? 23:08
this is about GH #1202, btw
sleep& 23:16
23:27 evalable6 joined
Geth MoarVM/master: 4 commits pushed by MasterDuke17++, (Jonathan Worthington)++ 23:37
MoarVM: 9aa99f3e9f | (Nick Logan)++ | 2 files
Add more missing MVMROOTs

  See: 9ad1f5f		 23:38
MoarVM: b7b1f3e40f | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
Merge pull request #742 from ugexe/more_mvmroot_redo

Add more missing MVMROOTs
MasterDuke thanks, jnthn++ 23:39
Zoffix bumps 23:40
Geth MoarVM/master: 4 commits pushed by (Nick Logan)++, (Jonathan Worthington)++ 23:41
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.
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.

Powered by Cro and the Raku® Programming Language.

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

Thank you!