| 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 |
