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