Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-12-29

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

All times shown according to UTC.

Time Nick Message
02:58 ilbot3 joined #moarvm
02:58 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:17 unicodable6 joined #moarvm
03:17 benchable6 joined #moarvm
03:50 Geth joined #moarvm
03:51 Geth joined #moarvm
03:53 p6lert joined #moarvm
04:04 [Coke] mst: is there anything you can do to prevent that kind of spam?
05:39 Zoffix joined #moarvm
07:30 geekosaur joined #moarvm
07:32 piojo joined #moarvm
07:38 piojo so MVMObject is a type object, and there should be one MVMObject instance per type, right?
07:40 piojo for example, Array[Int] corresponds to one MVMObject? Or is it just Array that has a MVMObject?
07:41 piojo FYI, I'm looking into this: https://rt.perl.org/Public/Bug/Display.html?id=128287
07:41 piojo And I found type_check_store() does the bad check, but the logic itself is probably okay. The runtime data is probably the problem--duplicate types in memory.
07:43 geekosaur pretty sure every object has an MVMObject somewhere under it, and types are objects (of type Class iirc)
07:46 piojo geekosaur: oh, that sounds like turtles all the way down. very self-supporting, conceptually
07:47 geekosaur most pure object systems (e.g. smalltalk) also work that way
08:12 piojo Could you help me understand the meaning of this type check? https://github.com/rakudo/rakudo/blob/master/src/vm/moar/ops/container.c#L97
08:13 piojo I think "cont" is one type, and "tc" somehow contains a reference to the other type
08:14 piojo no, that can't be right. it must be rcd and obj, with tc holding extra info
08:17 geekosaur proibably not; I don't know much about the internal details, sorry
08:17 piojo thanks anyway, I understand it now. The problem must be at a higher level
08:17 geekosaur and atsome point probably only jnthn can help you
08:18 piojo my thought is that either:
08:18 piojo 1) the decision to use type caches is incorrect,
08:18 piojo 2) the type caches are incorrect, or
08:18 piojo 3) there are duplicate type objects so of course they don't exist in each other's type caches
09:21 piojo .ask jnthn Could you please take a look at this bug? I've debugged it some but it's really out of my league: https://rt.perl.org/Ticket/Display.html?id=128287&results=3c39a5462e0b203df4fa2850f25eb6ab
09:21 yoleaux piojo: I'll pass your message to jnthn.
09:21 domidumont joined #moarvm
09:27 domidumont joined #moarvm
09:28 piojo .tell jnthn I added comments that I hope will be useful, but the next step requires understanding how how MVMObjects are created (or looked up) as modules are parsed after (not during) compilation.
09:28 yoleaux piojo: I'll pass your message to jnthn.
09:29 FROGGS joined #moarvm
11:15 piojo_ joined #moarvm
11:24 Zoffix Announcing P6lert: Perl 6 Alerts Directly From Core Developers: https://rakudo.party/post/Announcing-P6lert-Perl-6-Alerts-Directly-From-Core-Developers
11:58 Zoffix left #moarvm
15:53 statisfiable6 joined #moarvm
16:05 nativecallable6 joined #moarvm
16:05 quotable6 joined #moarvm
16:05 releasable6 joined #moarvm
16:05 committable6 joined #moarvm
16:56 FROGGS joined #moarvm
17:26 piojo_ joined #moarvm
19:38 bisectable6 joined #moarvm
19:38 bloatable6 joined #moarvm
19:38 squashable6 joined #moarvm
19:38 coverable6 joined #moarvm
19:38 greppable6 joined #moarvm
20:58 evalable6 joined #moarvm
20:58 reportable6 joined #moarvm
21:22 geospeck joined #moarvm
21:30 AlexDaniel joined #moarvm
21:42 Ven`` joined #moarvm

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