lizmat jnthn: re the usefulness of .cow: if we just bind each element of an array to another, then changes propagate back 00:00
m: class Foo { has $.a is rw }; my @a = Foo.new(a => $++) xx 2; my @b; @b[$_] := @a[$_] for ^2; dd @a, @b; @a[0] = 42; dd @a,@b
camelia rakudo-moar d4a0e0: OUTPUT«Array @a = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @b = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @a = [42, Foo.new(a => 1)]␤Array @b = [42, Foo.new(a => 1)]␤»
lizmat if you however .cow the array, then the change does *not* propagate back:
m: class Foo { has $.a is rw }; my @a = Foo.new(a => $++) xx 2; my @b = @a.cow; dd @a, @b; @a[0] = 42; dd @a,@b 00:01
camelia rakudo-moar d4a0e0: OUTPUT«Array @a = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @b = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @a = [42, Foo.new(a => 1)]␤Array @b = [Foo.new(a => 0), Foo.new(a => 1)]␤»
lizmat m: class Foo { has $.a is rw }; my @a = Foo.new(a => $++) xx 2; my @b = @a.cow; dd @a, @b; @b[0] = 42; dd @a,@b
camelia rakudo-moar d4a0e0: OUTPUT«Array @a = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @b = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @a = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @b = [42, Foo.new(a => 1)]␤»
lizmat however, the values *are* bound, because:
m: class Foo { has $.a is rw }; my @a = Foo.new(a => $++) xx 2; my @b = @a.cow; dd @a, @b; @b[0].a = 42; dd @a,@b
camelia rakudo-moar d4a0e0: OUTPUT«Array @a = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @b = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @a = [Foo.new(a => 42), Foo.new(a => 1)]␤Array @b = [Foo.new(a => 42), Foo.new(a => 1)]␤»
lizmat note that in this last case, @a[0] and @b[0] are still referring to the same object 00:02
m: class Foo { has $.a is rw }; my @a = Foo.new(a => $++) xx 2; my @b = @a.cow; dd @a, @b; @b[0].a = 42; say @a[0] === @b[0] 00:03
camelia rakudo-moar d4a0e0: OUTPUT«Array @a = [Foo.new(a => 0), Foo.new(a => 1)]␤Array @b = [Foo.new(a => 0), Foo.new(a => 1)]␤True␤»
lizmat m: my %h = a => 42; my $m = %h.Map; dd $m; %h<a>++; dd $m # sigh, mutable .Map 00:42
camelia rakudo-moar d4a0e0: OUTPUT«Map $m = Map.new((:a(42)))␤Map $m = Map.new((:a(43)))␤»
pyrimidine moritz: I think irclog.perlgeek.de is down, not seeing archived logs anymore 01:31
dalek kudo/nom: 9b6d0cc | lizmat++ | src/core/Hash.pm:
Fix Hash.Map

  - handle case of completely empty Hash
  - add support for :view parameter
  - create actual cow copy otherwise
pyrimidine yup: www.downforeveryoneorjustme.com/htt...erlgeek.de 01:32
lizmat pyrimidine: it will be some hours before moritz wakes up 01:35
pyrimidine lizmat: not a problem 01:52
awwaiid lizmat: so .cow is sort of shallow-cow? 02:38
lizmat not sure what you mean by shallow exactly in this context 02:40
instead of aliasing the container, the value in the container is aliased
so that the new container will retain the value if the original container is changed
awwaiid m: my @a = [[[1]]] ; my @b = @a.cow; dd @a, @b; @a[0][0][0] = 42; dd @a, @b 02:43
camelia rakudo-moar 9b6d0c: OUTPUT«Array @a = [1]␤Array @b = [1]␤Cannot modify an immutable Int␤ in block <unit> at <tmp> line 1␤␤»
awwaiid hm 02:44
m: my @a = [1, [2, [3]]] ; my @b = @a.cow; dd @a, @b; @a[1][1][0] = 42; dd @a, @b 02:45
camelia rakudo-moar 9b6d0c: OUTPUT«Array @a = [1, [2, [3]]]␤Array @b = [1, [2, [3]]]␤Array @a = [1, [2, [42]]]␤Array @b = [1, [2, [42]]]␤»
awwaiid it would be neat if .cow magically did deep deep cow
lizmat how would it know to go deeper ? 02:46
because the value is Iterable ?
awwaiid magic I guess
sure, iterable sounds good :)
lizmat hmmm....
in any case, before I go on, I'd like to see what TimToady thinks of the idea
awwaiid maybe this could be a flag or property of any object
ya
lizmat and whether we should have any syntactic suger 02:47
*sugar
awwaiid seems like a very interesting idea to explore in any case
lizmat this is basically also a result of TheDamian's functional programming course and a conversation I had with TimToady afterwards
awwaiid ah cool. I did a lot of OCaml with purely-functional datastructures, and behind the scenes COW is what made it realistic 02:48
ocaml, iirc, has it baked in all the time. I guess like clojure does it -- extra layers of pointers all the time 02:49
clojure uses COW functional data structures as a key part of its concurrency story 02:53
dalek ast: 0d86018 | LLFourn++ | S32-str/split.t:
Test for RT #128481
 03:33
kudo/nom: 9ee9693 | lizmat++ | src/core/BagHash.pm:
Simplify BagHash.Bag
 03:40
kudo/nom: ff63582 | lizmat++ | src/core/Capture.pm:
Simplify Capture.hash
kudo/nom: 8d5a9e4 | lizmat++ | src/core/CompUnit/Handle.pm:
Simplify CompUnit::Handle.new|from-unit
kudo/nom: d78d8cd | lizmat++ | src/core/Enumeration.pm:
Simplify ENUM_VALUES
kudo/nom: 2b12326 | lizmat++ | src/core/HyperSeq.pm:
Simplify HyperSeq.new

Simplify HyperWorkBuffer.new
kudo/nom: 6018ccd | lizmat++ | src/core/IO/Special.pm:
Simplift IO::Special.new
kudo/nom: 4f3b650 | lizmat++ | src/core/Iterable.pm:
Simplify Iterable.flat|lazy iterator.new
kudo/nom: e2b90ab | lizmat++ | src/core/MixHash.pm:
Simplify MixHash.Mix
kudo/nom: cc6d2a3 | lizmat++ | src/core/Seq.pm:
Simplify Seq.new
kudo/nom: 6d824ec | lizmat++ | src/core/Str.pm:
a556a86 | lizmat++ | src/core/Attribute.pm:

Not sure what the effect is, if any. They *do* get called during module installation after setting compilation.
lizmat all of these commits basically changed the same thing 03:49
It's spectest clean, but sometimes runs deep in the internals 03:50
in order for bisectable to be able to bisect any problems found, I did these all in separate commits
lizmat good night, #perl6-dev! 04:52
psch alright, so, the patch method doesn't show up in qbidToCodeRef because it doesn't get a CodeRefAnnotation during jast2bc.JASTCompiler.compileMethod 07:08
and it doesn't get a CRA because it neither has a crCuid nor an outer
i *think* i probably have to add an outer, but i have no clue how i can find out which CR *is* the appropriate outer
because during COMP_MODE we never add a cuid
Woodi m: my @a = [1, 2, 3]; my @b = @a.cow; @b[0] = 4; dd @b; dd @a 07:51
camelia rakudo-moar a556a8: OUTPUT«Array @b = [4, 2, 3]␤Array @a = [1, 2, 3]␤»
[Tux] This is Rakudo version 2016.06-46-ga556a86 built on MoarVM version 2016.06 09:03
test 16.492
test-t 9.864
csv-parser 21.979
dalek kudo/nom: e071e40 | lizmat++ | src/core/Attribute.pm:
More correct translation of given/when structure
 13:06
psch alrighty then, lets see if carrying every single jclass compiled with one compiler instance gives me back the missing method 13:25
+along
well, apparently it kinda works 14:18
unfortunately the StaticCodeInfo of the CodeRef seems to get lost somewhere 14:19
which is kind of the same problem as before, only one goal post further... vOv
llfourn gist.github.com/LLFourn/135680d93e...86b49fa20e # backtrace on the segfaults I'm getting for anyone interested 14:23
timotimo llfourn: unfortunately that's utterly useless without the filename and line number 14:25
because every single REPR has a gc_mark function
though perhaps the right clue to behold is that frame_force_to_heap is in the backtrace; jnthn?
llfourn oh. Yeah I was never able to build with debug symbols on mac last time.
timotimo damn :( 14:26
llfourn will attempt again
timotimo thanks
llfourn how to do again? 14:27
timotimo give moarvm's Configure.pl the --debug=3 flag
psch now carries the CodeRefBuilder for each file around as well 14:29
hope that has the info for e.g. oLexStatic
...although, probably not
timotimo psch: it's kind of amusing how you can tell by the cpu usage graphs on collect when you're working on rakudo-jvm :D
psch *but* it might have the info for building the stuff for oLexStatic etc...
timotimo: i'm glad i'm not compiling locally 'cause it would be lots too hot here then :) 14:30
timotimo :D
yeah
psch ohh, what's ram usage say? 14:33
for rakudo specifically
'cause i have a feeling that'll increase a lot
i mean, during rakudo build
timotimo hardly noticable on the graph, as the machine has like 20 gigs 14:34
psch i mean, during CORE compilation i have to carry all JAST::Methods of all CompUnits around
timotimo llfourn: btw, gfldex isn't in this channel, so even though he's interested, he's not going to have seen that backtrace
psch but yeah, in the grand scheme of 20 gigs on a server that probably doesn't matter too much 14:35
ISTR we did have r-j compilation problems due to stack size in the past...
anyway, i'll take a break now 'cause everything's getting hairy again with the CodeRefBuilder stuff >_>
llfourn timotimo: thanks. 14:38
ek. after rebuilding with --debug=3 there seems to be less info -_- 14:39
timotimo that's fantastic!
llfourn looks like: #0 0x0000000100063cf4 in ?? () from /Users/llfourn/src/rakudo/install/lib/libmoar.dylib 14:40
timotimo that'd happen when going through the jit (or something) makes the stack unreadable to the debugger
you can try if it still happens with MVM_JIT_DISABLE=yes in your env
llfourn ah. thanks.
timotimo: updated gist - gist.github.com/LLFourn/135680d93e...86b49fa20e 14:43
but it's still empty :S
in terms of info with MVM_JIT_DISABLE 14:44
timotimo well, it's not necessarily the same crash
does file tell you something interesting about the dylib?
like "not stripped"?
llfourn how do I check?
timotimo "file" is a commandline program
llfourn /Users/llfourn/src/rakudo/install/lib/libmoar.dylib: Mach-O 64-bit dynamically linked shared library x86_64 14:45
timotimo hm
mine looks like this: perl6/install/lib/libmoar.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=092ad8a65bd5594c1e60c3e6ab1f34a216c519a6, not stripped 14:49
llfourn this is BSD file vs gnu I guess
timotimo *shrug* 14:50
also, i don't think BuildID is a thing on every linux distro
so probably also not on mac osx
llfourn I think "stripped" is a thing on BSD file though because it mentions it in the man page
stmuk I did wonder at one point if upstream file(1)s should recognise moar magic 14:54
maybe they do already
timotimo they probably don't yet 14:55
nine psch: CORE compilation won't be affected since it's a single CompUnit
Zoffix the `parse` stage went up from 54s to 83s when I switched my 4-core VM to 1 core 14:56
timotimo i wonder if the jvm switches GCs depending on whether or not multiple cores are available 14:57
Zoffix (I'm talking about moar FWIW) 14:58
timotimo oh
huh
Zoffix ¯\_(ツ)_/¯
stmuk gist.github.com/ilmari/2a23f96373163a1fa45b 15:00
ilmari: have you made any attempt to commit that upstream to GNU and any BSD projects? 15:01
timotimo i wonder if the format changed since then 15:02
stmuk not sure . I stuck in my /etc/magic and it seems to work
timotimo well, of course it seems to work 15:03
it just reads values from the first ~100 bytes
it can hardly crash :)
but the values could be wrong
stmuk thats what I meant 15:04
/opt/rakudo-star-2016.01/share/perl6/runtime/perl6.moarvm: MoarVM bytecode (version 5), 5 serialization contexts, 1 extension ops, 11 frames, 8 callsites, 199 strings, 1576 bytes serialized data (version 16), 3020 bytes bytecode, 492 bytes annotations
timotimo ah, ok :) 15:05
ilmari stmuk: nope 15:45
psch nine: it already is. i have to keep track of all CUs compiled by a given instance of a HLL::Compiler to still reach the already-defined-but-later-lost method that refers to the inner CU 15:53
because that's a thing i noticed; we compile that method that later goes missing before we compile the inner CU 15:54
s:2nd/before/after/ 15:55
err, there's no 1st vOv
ilmari stmuk: I tired to get the hll name, but I couldn't figure out a way to get the Nth string in the string heap 16:05
llfourn timotimo: \o/ I got debugging symbols to show up: gist.github.com/LLFourn/135680d93e...86b49fa20e 16:07
not with gdb but with lldb
b2gills Should IO::ArgFiles.eof() act per input file, or should it be for the entire list of input files ( fixing other problems with it currently ) 17:04
timotimo that looks very interesting, i'll have to look at it later today - i hope i'll make it 17:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!