| nine | I think I made some progress. With a shared JCLASS, I now arrive at "Wrong number of arguments passed; expected 2..-1, but got 0" when loading the precomp file | 09:59 | |
| Am I missing something here or should this error not even be possible? | 10:05 | ||
| if (positionals < required || positionals > accepted && accepted != -1) | |||
| throw ExceptionHandling.dieInternal(cf.tc, "Wrong number of arguments passed; expected " + required + ".." + accepted + ", but got " + positionals); | |||
| Oh, it's the positionals < required part that fails the check | 10:06 | ||
| Occurs when trying to run the deserialization code ref | 10:14 | ||
| Sometimes it's a StackOverflowError instead | 11:24 | ||
| dalek | kudo/nom: 85682a5 | lizmat++ | src/core/Mu.pm: Streamline Mu.Capture a bit - use nqp ops - make sure we don't keep an empty hash around |
11:27 | |
| nine | Current NQP diff looks like this: gist.github.com/niner/89b442aef9d4...3a79c68dc1 | ||
| lizmat | afk& | 11:47 | |
| [Tux] | This is Rakudo version 2016.05-56-g85682a5 built on MoarVM version 2016.05-18-g1339332 | 12:08 | |
| test 19.448 | |||
| test-t 12.120 | |||
| csv-parser 33.888 | |||
| brrt | good * | 13:05 | |
| jnthn | o/ brrt | 13:06 | |
| brrt | \o jnthn | ||
| any further on the issue of mixins / object structure extensions? | |||
| timotimo | good. | ||
| nine | Also a fun one: java.lang.LinkageError: loader (instance of org/perl6/nqp/runtime/ByteClassLoader): attempted duplicate class definition for name: "836BAC46652AF5708386DC6C31D0DC479214FAE6" | 13:07 | |
| timotimo | buh | ||
| jnthn | brrt: I'm not sure that part will happen very soon. But note that that step is the one needed to make every object smaller; getting rid of the cases where we need to look at "is this the real body" thing is a separate step that we can do sooner. | 13:09 | |
| psch | nine: curiously, i only get an NPE with your nqp gist applied | ||
| and reliably only that | |||
| brrt | hmm... and the container guards? | 13:10 | |
| nine | psch: my current rakudo diff: gist.github.com/niner/c49899d7912b...8efbc8c0b3 | ||
| The change in src/core/control.pm probably fixes the NPE | 13:11 | ||
| jnthn | brrt: The container guards probably sooner than either of those | ||
| nine | Though until everything is working, it's hard to say if any change is for good or bad | ||
| jnthn | brrt: After the return changes :) | ||
| psch | nine: yeah, the EVAL change is probably behind the NPE | 13:12 | |
| brrt | oh right, that :-) | ||
| exciting :-) | |||
| nine | psch: with this change, add_additional_frames may even have become obsolete | 13:13 | |
| timotimo | i'm wondering ... we have a lot of code with "existskey? if yes, bindkey,atkey,or-deletekey" | ||
| should we perhaps have a little cache somewhere that'll make *key-after-existskey a bit faster? | 13:14 | ||
| hm. my perf profile for this has existskey at only 0.37%, but at_key at 5% and bind_key at 3.25% | 13:15 | ||
| psch learned about ${ENV_VAR:=DEFAULT_IF_UNSET} just now | 13:18 | ||
| 'cause i want a way to spawn multiple -jdb-servers with different ports | |||
| timotimo | ah, nice | ||
| psch | although that's probably still iffy if there's no consistent failure mode... | 13:19 | |
| well, or a StackOverflowError - catching that doesn't really help | |||
| not sure if that needs to be in nom though | 13:20 | ||
| hm, isn't the linkage error just because %?OPTIONS<mast_frames> survives too long? | 13:49 | ||
| nine | Err...I have no idea? | 13:54 | |
| I feel like I understand about 3/4ths of what's going on. That leaves a lot of unknown. | |||
| psch | well, the error says we're loading a class we already loaded before | 13:55 | |
| and we're sharing JAST::Class instances across compilations | 13:56 | ||
| nine | Aaand we need to stop doing that after the first non-nested comp unit | 14:02 | |
| psch | yeah, the error seems to happen because NativeCall compiles NativeCall::Types and the latter gets the same class name | 14:04 | |
| nine | What I wanted to achieve was that we share a JAST::Class between the outer comp unit and all nested comp units (as when we're loading multiple modules). | 14:06 | |
| psch | yeah, i think that's reasonable | ||
| uh, unless i misunderstand | 14:07 | ||
| is NC::Types nested in NC? | |||
| nine | On MoarVM, add_additional_frames just merges those moar_frames hashes. | ||
| What's nested is the EVAL in src/core/CompUnit/PrecompilationUnit.pm:37 | 14:08 | ||
| psch | right, that's what i thought. and yes, i still agree | ||
| nine | Ok, I think, I'll just store the mast_frames hash in $*W. That should keep it safely within the current comp unit. | 14:35 | |
| Though I think, I'm too spent to do this refactor today | 14:38 | ||
| moritz | hi all | 20:20 | |
| how hard would it be to introduce a weak reference type in Perl 6? | 20:21 | ||
| jdv79 | out of curiousity what would be the benefit(s)/need(s)? | 20:24 | |
| lizmat | moritz: doesn't a weak reference imply refcounting, which we don't have ? | 20:30 | |
| nine | lizmat: works the same with any other GC. The reference just does not keep the object alive. | 20:32 | |
| moritz | lizmat: no, it means that weak references don't keep an object alive, and become undefined once the referenced object is collected | ||
| jdv79: for example keeping a list of sublcasses whose method caches need to be invalidated on augmentation, without preventing the subclasses from getting collected | 20:33 | ||
| or in general, keeping a list of things that might need some kind of cleanup, without keeping stuff alive | 20:35 | ||
| seems the JVM has weak references | 20:37 | ||
| jnthn | Moar doesn't. iirc, the typical algorithm for doing them is rather like the one used to make DESTROY work | 20:38 | |
| moritz | and ES6 has WeakMap | ||
| jnthn | (Since you don't want "being on the finalization queue" to keep the object alive, so the finalization queue in itself is a kind of special-case weak ref) | ||
| We've also talked a bit recently about using a weakmap style data structure for storing extra attributes of mixins to P6opaques, so that we don't have to have every object that might be mixed into pay the price when the majority of the time that doesn't happen. | 20:39 | ||
| And weak refs would also remove a special case in Moar for SC handling. | 20:40 | ||
| So quite aside from it perhaps being interesting to provide weak reference types at a Perl 6 level, we might end up introducing them in Moar for infrastructural reasons. | |||
| They might also help us to solve the "methods in parent classes don't propagate to child classes" problem | 20:41 | ||
| moritz | yeah, that was the use case I mentioned to jdv79 | 20:48 | |
| though I probably didn't make a good job explailning it | |||
| jnthn | Oh, I skimmed over that bit of the discussion somehow :) | 20:50 | |
| Time for rest...see y'all tomorrow o/ | 21:08 | ||
| jdv79 | nite | ||
| lizmat | gnight jnthn | 21:19 |