pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/
Set by Tene on 29 July 2008.
ruoso can't get cmake to produce a debug build 01:05
pugs_svn r22187 | ruoso++ | [smop] array iterator almost working... the return of prefix:<=> needs to be better defined. re set SMOP_LOWLEVEL_MEM_TRACE in cmake and find out that the files .m0ld have many leaks... 01:46
ruoso @tell pmurias, I found out that SMOP_LOWLEVEL_MEM_TRACE was not set in the compiling process... and now I've found a lot of leaks in mold 01:47
lambdabot Consider it noted.
ruoso pmurias, hi 14:20
ron perl6: my $y = (12, 11, undef, 10).reduce({ $^a + $^b }); say "ok"; say $y; 14:21
p6eval rakudo 30888: OUTPUT[Use of uninitialized value␤ok␤33␤]
..pugs: OUTPUT[ok␤33␤]
..elf 22187: OUTPUT[Useless use of a constant in void context at (eval 121) line 3.␤Useless use of a constant in void context at (eval 121) line 3.␤Use of uninitialized value $Main::b in addition (+) at (eval 121) line 3.␤Use of uninitialized value $Main::a in addition (+) at (eval 121) line
..3.␤Can'...
ron is rakudo's final conclusion of * 33 * ok ?? 14:23
pmurias ruoso: hi 14:39
moritz_ ron: I think it is 14:40
ron: it's a good sign that it's the same as pugs' output (even thoug it contains a warning)) 14:41
ron you did notice the undef in the list which, I think, * should * at least have issued the warning ...
moritz_ ron: well, pugs doesn't do any warnings yet, I think 14:42
ron that's right, I am working on 58646 and Failure handling and am wondering if reduce should have returned Failure in some form here. There is some code for that though it doesn't cover the case just tested ... 14:43
moritz_ ron: I don't think it should. There'a resonable way to define undef+Int, so we shouldn't unnecessarily die 14:44
ron: just like in perl 5
ron s/is some/seems to be some/ 14:45
moritz_ pmichaud experimented with making those warnings fatal, which broke too much stuff to be pratical 14:47
ron Ok - thx much, I'll move on to other aspects of the problem then ...
moritz_ ron: if you're working on Failure stuff... it would be nice if $! could be tested for truthness 14:48
rakudo: my $x = try { die 1; } say "yes" if ?$x
p6eval rakudo 30888: OUTPUT[Statement not terminated properly at line 1, near "say \"yes\" "␤␤current instr.: 'parrot;PGE::Util;die' pc 119 (runtime/parrot/library/PGE/Util.pir:82)␤]
moritz_ rakudo: my $x = try { die 1; }; say "yes" if ?$x 14:49
p6eval rakudo 30888: OUTPUT[Null PMC access in can()␤current instr.: 'parrot;Perl6Object;infix:=' pc 37 (src/gen_builtins.pir:45)␤]
moritz_ rakudo: my $x = try { die 1; }; say "yes" if ?$!
p6eval rakudo 30888: OUTPUT[Null PMC access in can()␤current instr.: 'parrot;Perl6Object;infix:=' pc 37 (src/gen_builtins.pir:45)␤]
moritz_ rakudo: my $x = try { die 1; }; say $x
p6eval rakudo 30888: OUTPUT[Null PMC access in can()␤current instr.: 'parrot;Perl6Object;infix:=' pc 37 (src/gen_builtins.pir:45)␤]
moritz_ rakudo: my $x = try { die 1; }; say $!
p6eval rakudo 30888: OUTPUT[Null PMC access in can()␤current instr.: 'parrot;Perl6Object;infix:=' pc 37 (src/gen_builtins.pir:45)␤]
moritz_ uhm.
rakudo: say "still alive"
p6eval rakudo 30888: OUTPUT[still alive␤]
ron I think I have at least part of the solution to the original request on failure changes and will try to look into your concern too ... 14:50
pmurias cycling& 14:56
meppl good night 17:08
pmurias meppl: good night 17:10
meppl ;)
ruoso Hello! 17:10
pmurias Hi! 17:11
ruoso: it is possible to determine a memory leak under ref counting without destroying everything 17:19
ruoso pmurias, I don't think so...
pugs_svn r22188 | ruoso++ | [smop] avoids stopping to release objects if there is a null constant... 17:20
ruoso pmurias, that's the basic argument against refcounting 17:21
ruoso pmurias, btw... test/31 is leaking only two values... it's probably going to be easier to catch the bug there... 17:23
pmurias always thought it's disposing of circural references correctly 17:25
* incorrectly 17:26
* not dispososing of circural references at all
ruoso er... we can't have circular references...
that's the other basic argument against refcounting...
pmurias we leak memory when they happen 17:28
ruoso sure, we do...
but that's not the case in test/31 17:30
and I think when we catch that one, the others should become more evident...
pugs_svn r22189 | ruoso++ | [smop] fix leak in native_int... test/31 no longer leaks, but that means the other leaks are not related to this one. 17:34
ruoso pmurias, one thing I didn't get... did you said that there are circular references in SMOP? 17:39
pmurias no 17:40
ruoso ah... ok
pmurias i'm not aware of any
ruoso good... 17:41
TimToady n 18:10
bleh
pmurias TimToady: what the context of an argument to a multi? 18:15
pugs_svn r22190 | ruoso++ | [smop] some code review, trying to hunt down the memory leaks 18:17
pugs_svn r22191 | ruoso++ | [smop] still trying to find the leak 18:31
TimToady pmurias: depends on the proto, if any. when unknown, an argument assumes list context, (more like capture context, really) 18:45
ruoso TimToady, but "capture context" is really "no context", isn't it? 18:48
TimToady more or less 18:51
TimToady except that the capture boundaries are important insofar as a given capture will be bound to a single parameter (in the absence of prefix:<|>) 18:52
s/single parameter/single scalar parameter/ 18:53
slurpies can pull from multiple captures, of course
but given sub foo ($x, *@y) {...}, foo(bar(), baz()) will put all of bar's results into $x 18:54
even if bar returns a list
that's the sense in which capture context is more than "no context" 18:55
ruoso but... is there a way that the return of baz() will be treated as more than one argument? 18:56
I thought foo(bar(), |baz()) would be needed to provide that behaviour 18:57
TimToady the | there is useless because @y is slurpy 18:58
ruoso o.O
TimToady a | is useful only for spreading a single capture out over multiple scalar parameters 18:59
ruoso or to turn an object into a list of arguments... 19:00
foo(|@parameters)
TimToady once you're binding slurpies in list context it doesn't care about capture/list boundaries 19:00
extension of the p5 notion that () is invisible in list context
rakudo_svn r30908 | pmichaud++ | [rakudo]: spectest-progress.csv update: 158 files, 3288 passing tests 19:02
ruoso pugs: sub foo ($a) {say $a.WHAT}; my @a = (1,2,3); foo(@a) 19:02
p6eval pugs: OUTPUT[Array␤]
ruoso pugs: sub foo ($a) {say $a[0], $a[1], $a[2]}; my @a = (1,2,3); foo(@a)
p6eval pugs: OUTPUT[123␤]
ruoso pugs: sub foo ($a, $b, $c) {say $a, $b, $c}; my @a = (1,2,3); foo(@a)
p6eval pugs: OUTPUT[*** No compatible multi variant found: "&foo"␤ at /tmp/kEMeQdRpyT line 1, column 57 - line 2, column 1␤]
ruoso pugs: sub foo ($a, $b, $c) {say $a, $b, $c}; my @a = (1,2,3); foo(|@a) 19:03
p6eval pugs: OUTPUT[*** No compatible multi variant found: "&foo"␤ at /tmp/5Misj5I2ZZ line 1, column 57 - line 2, column 1␤]
TimToady pugs: sub foo ($a) {say $a[0], $a[1], $a[2]}; foo((1,2,3))
p6eval pugs: OUTPUT[123␤]
TimToady pugs: sub foo ($a) {say $a[0], $a[1], $a[2]}; foo(1,2,3)
p6eval pugs: OUTPUT[*** No compatible multi variant found: "&foo"␤ at /tmp/59vf2YOldf line 1, column 41 - line 2, column 1␤]
TimToady pugs: sub foo ($a, *@b) {say $a[0], $a[1], $a[2], @b}; foo((1,2,3), (1,2,3))
p6eval pugs: OUTPUT[123123␤]
ruoso pugs: sub foo ($a, @b) {say $a[0], $a[1], $a[2], @b}; foo((1,2,3), (1,2,3)) 19:04
p6eval pugs: OUTPUT[123123␤]
TimToady pugs: sub foo ($a, *@b) {say $a[0], $a[1], $a[2], @b}; foo((1,2,3), 1,2,3)
p6eval pugs: OUTPUT[123123␤]
TimToady pugs: sub foo ($a, @b) {say $a[0], $a[1], $a[2], @b}; foo((1,2,3), 1,2,3)
p6eval pugs: OUTPUT[*** No compatible multi variant found: "&foo"␤ at /tmp/Z5DoaKrKQI line 1, column 49 - line 2, column 1␤]
TimToady slurpy ignores the ()
ruoso slurpy takes the rest of the positional arguments 19:06
but there needs to be positional arguments
TimToady which are scalars, and pay attention to ()
once you switch to slurpy, () is ignored 19:07
ruoso but when that relates to foo(bar()) 19:08
bar() is a single positional argument
TimToady bar returns a capture, so how it gets bound depends on the definition of foo
all bar knows by default is that it's returning a capture
it doesn't necessarily know whether it will be bound to a scalar or a slurpy
ruoso sure... but it is a single positional argument anyway 19:09
prefix:<|> is the thing that does the capture expasion...
*expansion
TimToady it's a single positional argument only when bound to a scalar 19:10
list context also does capture expansion
(but not slice context)
anyway, the pugs behavior seems to be correct here 19:13
(except pugs doesn't implement slice context yet)
ruoso TimToady, capture seems too magical yet... 19:17
TimToady, if the user wants to implement a capture type on its own? which API it would need to follow?
TimToady, I really can't see how capture gets from this magical state to low-level implementation... 19:20
pugs: sub foo ($a, *@b) {say $a[0], $a[1], $a[2], @b[0]}; foo((1,2,3), (1,2,3)) 19:21
p6eval pugs: OUTPUT[1231␤]
ruoso pugs: sub foo ($a, *@b) {say $a[0], $a[1], $a[2], @b[0]}; sub bar { (1,2,3) }; foo((1,2,3),bar()) 19:24
p6eval pugs: OUTPUT[1231␤]
TimToady I have no idea what you mean by "magical" here, unless you think pugs is magical somehow... 19:25
but it's likely that captures are an irreducably fundamental type 19:26
ruoso TimToady, hmm... that's a new assumption... 19:28
and it can indeed make our life much easier 19:31
[particle]1 captures have made their way into parrot core, mainly because of this design 19:38
ruoso the problem is the opposite case... when someone wants to use a non-native capture... 19:40
TimToady that's like asking for a non-native version of Lisp's . operator, I suspect 19:54
or user-defined quarks :) 19:55
ron rakudo: my $x = 1 .. 1; $x.pop; my $y = $x.pop; try {die $!}; say $!; try {die "abc"}; say $!; say "ok"; say $y' 20:03
p6eval rakudo 30912: OUTPUT[Statement not terminated properly at line 1, near "'"␤␤current instr.: 'parrot;PGE::Util;die' pc 119 (runtime/parrot/library/PGE/Util.pir:82)␤]
ruoso TimToady, alright... so "Capture" needs to be renamed to "capture" and promoted to a native type... which is not what's listed on the specs atm 20:04
ron rakudo; my $x = 1 .. 1; $x.pop; my $y = $x.pop; try {die $!}; say $!; try {die "abc"}; say $!; say "ok"; say $y;
rakudo: my $x = 1 .. 1; $x.pop; my $y = $x.pop; try {die $!}; say $!; try {die "abc"}; say $!; say "ok"; say $y;
p6eval rakudo 30912: OUTPUT[Null PMC access in get_string()␤abc␤ok␤Undefined value popped from empty range␤␤]
ron working on Failure again ... Ranges have the new !FAIL technology and gives nice warning messages but am not sure about writing tests that capture and validate the messages ... 20:07
pugs_svn r22192 | ruoso++ | [smop] more plumbing... there was circularity in some code... mold frames now dont add a refcount when it stores itself on its registers.. 20:15
ruoso home &
ron hmm... well I at least have patches that make other builtins behave like range so unless someone will claim I don't understand the area I will post them against the TODO report 20:39
rakudo_svn r30914 | julianalbo++ | rename pmc attributes struct from Parrot_<type> to Parrot_<type>_attributes RT#48014 20:51
rakudo_svn r30915 | julianalbo++ | forgot to update perl6 mutable_pmc.template in previous commit 21:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!