date:20080911

On Wed, Sep 10, 2008 at 11:14 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
 On Mon Apr 07 21:31:15 2008, coke wrote:
 This has been removed in the type_ids branch.

 Coke,

 Can you provide any update on this deprecation and/or the type_ids branch?

 Thank you very much.

 kid51


Not really. The work to remove any user-visible type ids is still in
progress on the branch.

-- 
Will Coke Coleda

[perl #57530] Fwd: Parallelize the Perl 6 tests

Moritz,

I applied parallel-r.patch to trunk at r30978 on Darwin (10.4 PPC),
successfully built and tested Parrot, built Perl 6, then got the results
below out of 'make test'.

Since I build and test Perl 6 infrequently, I'm not sure whether these
results are different from what I would have gotten without the patch
applied.  But everything passed!

Thank you very much.
kid51


/usr/local/bin/perl t/harness t/00-parrot t/01-sanity
t/00-parrot/01-literalsok 
t/00-parrot/02-op-math.ok 
t/00-parrot/03-op-logicok 
t/00-parrot/04-op-cmp..ok 
t/00-parrot/05-var-array...ok 
t/00-parrot/05-var.ok 
t/00-parrot/06-op-inplace..ok 
t/00-parrot/07-op-string...ok 
t/00-parrot/08-regex...ok 
t/01-sanity/01-tap.ok 
t/01-sanity/02-counter.ok   
t/01-sanity/03-equal...ok   
t/01-sanity/04-if..ok   
t/01-sanity/05-sub.ok   
t/01-sanity/06-use.ok   
t/01-sanity/07-binding.ok   
t/01-sanity/07-defined.ok   
t/01-sanity/07-end-blocks..ok   
t/01-sanity/07-for.ok   
t/01-sanity/07-isa.ok   
t/01-sanity/07-range...ok   
t/01-sanity/07-ref.ok   
t/01-sanity/07-simple-multisubsok   
t/01-sanity/07-split...ok   
t/01-sanity/07-substr..ok   
t/01-sanity/07-try.ok   
t/01-sanity/08-say.ok 
t/01-sanity/09-types...ok   
All tests successful.
Files=28, Tests=232, 82 wallclock secs ( 0.36 usr  0.29 sys + 71.43 cusr
 6.98 csys = 79.06 CPU)
Result: PASS
prove t/pmc
t/pmc/mutable...ok   
t/pmc/mutablevarok   
t/pmc/perl6multisub-arity...ok 
t/pmc/perl6multisub-basic...ok   
t/pmc/perl6multisub-tiebreakok   
t/pmc/perl6multisub-typeok 
All tests successful.
Files=6, Tests=39,  8 wallclock secs ( 0.10 usr  0.08 sys +  6.45 cusr 
1.21 csys =  7.84 CPU)
Result: PASS
make -C /Users/jimk/work/parrot codetest
/usr/local/bin/perl t/harness --gc-debug --running-make-test --code-tests
t/distro/file_metadata.# Collecting svn:mime-type attributes...
t/distro/file_metadata.1/5 # Collecting svn:keywords attributes...
t/distro/file_metadata.3/5 # Collecting svn:eol-style attributes...
t/distro/file_metadata.4/5 # Collecting svn:eol-style attributes...
t/distro/file_metadata.ok   
t/codingstd/c_code_codaok   
t/codingstd/c_cppcomments..ok   
t/codingstd/c_header_guardsok   
t/codingstd/c_indent...ok   
t/codingstd/c_macro_args...ok   
t/codingstd/c_operator.ok   
t/codingstd/c_parens...ok   
t/codingstd/c_returns..ok   
t/codingstd/c_struct...ok   
t/codingstd/check_isxxxok   
t/codingstd/check_toxxxok   
t/codingstd/copyright..ok   
t/codingstd/cuddled_else...ok   
t/codingstd/filenames..ok   
t/codingstd/gmt_utcok   
t/codingstd/linelength.ok   
t/codingstd/pccmethod_deps.ok   
t/codingstd/pdd_format.ok   
t/codingstd/perlcritic.ok   
t/codingstd/pir_code_coda..ok   
t/codingstd/svn_id.ok   
t/codingstd/tabs...ok   
t/codingstd/trailing_space.ok   
All tests successful.
Files=24, Tests=374, 960 wallclock secs ( 0.64 usr  0.37 sys + 628.56
cusr 28.01 csys = 657.58 CPU)
Result: PASS

[perl #57178] [BUG] Broken links on smolder site.

2008-09-11 Thread Will Coleda via RT

No problems have surfaced since last post: closing ticket.

-- 
Will Coke Coleda

Re: Where did the toggle switch go?

On Thu, Sep 11, 2008 at 8:11 AM, James E Keenan [EMAIL PROTECTED] wrote:
 Is it just me  ...?

Yup.

 When I went to rt.perl.org just now to reply to a ticket, I could not find
 the toggle for automatically CC-ing [EMAIL PROTECTED]  I know it was
 there just last night.  I am clearly logged in to RT.  What gives?

I just did this about 30 seconds ago, the link was there.

 Note:  If the CC to the list is now automatic, that's probably a good thing.
  But I don't recall any notification that such a change was about to be
 implemented.

 Thank you very much.

 kid51



-- 
Will Coke Coleda

Re: [perl #54372] [BUG] test failures on win32/msvc

On Wed, Sep 10, 2008 at 10:51 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
 Coke, particle:  Where do we stand on this ticket?

 thank you very much.

 kid51


I haven't touched a win32 build of parrot in some months now, msvc or
otherwise. Smolder is probably a better place to look for information
at this point.

Do we have anyone in the audience building on these tools that can
give us a more up to date answer?

-- 
Will Coke Coleda

Re: [perl #53682] [CAGE] Visual Studio compiler for parrot

On Wed, Sep 10, 2008 at 10:56 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
 Coke, particle:  Can we get an update on the issues raised in this RT?

 Thank you very much.

 kid51


I haven't touched a win32 build of parrot in some months now, msvc or
otherwise. Smolder is probably a better place to look for information
at this point.

Do we have anyone in the audience building on these tools that can
give us a more up to date answer?


-- 
Will Coke Coleda

Re: [perl #57530] Fwd: Parallelize the Perl 6 tests

2008-09-11 Thread Reini Urban

2008/9/11 James Keenan via RT [EMAIL PROTECTED]:
 Moritz,

 I applied parallel-r.patch to trunk at r30978 on Darwin (10.4 PPC),
 successfully built and tested Parrot, built Perl 6, then got the results
 below out of 'make test'.

 Since I build and test Perl 6 infrequently, I'm not sure whether these
 results are different from what I would have gotten without the patch
 applied.  But everything passed!

Wrong make target.
You have to run

$ cd languages/perl6
$ make spectest_regression

to test this patch and the speed difference.


 Thank you very much.
 kid51


 /usr/local/bin/perl t/harness t/00-parrot t/01-sanity
 t/00-parrot/01-literalsok
 t/00-parrot/02-op-math.ok
 t/00-parrot/03-op-logicok
 t/00-parrot/04-op-cmp..ok
 t/00-parrot/05-var-array...ok
 t/00-parrot/05-var.ok
 t/00-parrot/06-op-inplace..ok
 t/00-parrot/07-op-string...ok
 t/00-parrot/08-regex...ok
 t/01-sanity/01-tap.ok
 t/01-sanity/02-counter.ok
 t/01-sanity/03-equal...ok
 t/01-sanity/04-if..ok
 t/01-sanity/05-sub.ok
 t/01-sanity/06-use.ok
 t/01-sanity/07-binding.ok
 t/01-sanity/07-defined.ok
 t/01-sanity/07-end-blocks..ok
 t/01-sanity/07-for.ok
 t/01-sanity/07-isa.ok
 t/01-sanity/07-range...ok
 t/01-sanity/07-ref.ok
 t/01-sanity/07-simple-multisubsok
 t/01-sanity/07-split...ok
 t/01-sanity/07-substr..ok
 t/01-sanity/07-try.ok
 t/01-sanity/08-say.ok
 t/01-sanity/09-types...ok
 All tests successful.
 Files=28, Tests=232, 82 wallclock secs ( 0.36 usr  0.29 sys + 71.43 cusr
  6.98 csys = 79.06 CPU)
 Result: PASS
 prove t/pmc
 t/pmc/mutable...ok
 t/pmc/mutablevarok
 t/pmc/perl6multisub-arity...ok
 t/pmc/perl6multisub-basic...ok
 t/pmc/perl6multisub-tiebreakok
 t/pmc/perl6multisub-typeok
 All tests successful.
 Files=6, Tests=39,  8 wallclock secs ( 0.10 usr  0.08 sys +  6.45 cusr
 1.21 csys =  7.84 CPU)
 Result: PASS
 make -C /Users/jimk/work/parrot codetest
 /usr/local/bin/perl t/harness --gc-debug --running-make-test --code-tests
 t/distro/file_metadata.# Collecting svn:mime-type attributes...
 t/distro/file_metadata.1/5 # Collecting svn:keywords attributes...
 t/distro/file_metadata.3/5 # Collecting svn:eol-style attributes...
 t/distro/file_metadata.4/5 # Collecting svn:eol-style attributes...
 t/distro/file_metadata.ok
 t/codingstd/c_code_codaok
 t/codingstd/c_cppcomments..ok
 t/codingstd/c_header_guardsok
 t/codingstd/c_indent...ok
 t/codingstd/c_macro_args...ok
 t/codingstd/c_operator.ok
 t/codingstd/c_parens...ok
 t/codingstd/c_returns..ok
 t/codingstd/c_struct...ok
 t/codingstd/check_isxxxok
 t/codingstd/check_toxxxok
 t/codingstd/copyright..ok
 t/codingstd/cuddled_else...ok
 t/codingstd/filenames..ok
 t/codingstd/gmt_utcok
 t/codingstd/linelength.ok
 t/codingstd/pccmethod_deps.ok
 t/codingstd/pdd_format.ok
 t/codingstd/perlcritic.ok
 t/codingstd/pir_code_coda..ok
 t/codingstd/svn_id.ok
 t/codingstd/tabs...ok
 t/codingstd/trailing_space.ok
 All tests successful.
 Files=24, Tests=374, 960 wallclock secs ( 0.64 usr  0.37 sys + 628.56
 cusr 28.01 csys = 657.58 CPU)
 Result: PASS





-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

[perl #58150] Doing split on the result of a slurped empty file results in a Null PMC Access in rakudo

On Fri Aug 29 13:14:19 2008, ronaldxs wrote:
  $   empty ./perl6 -e 'say split(\n, $*IN.slurp)' # but this fails
 
 Two proposed patches attached.  The patch to src/pmc/parrotiio.pmc seems
 to fix the problem as originally stated.  Then the patch to
 languages/perl6/src/classes/Str.pir seems to fix 'say
 $*IN.slurp.split(\n)'.  If you have any questions please ask.
 
Thanks for the patches! The first one to ParrotIO, I fully agree with so
I have applied it in r30981 (if you slurp an empty file, the empty
string would seem a much more sensible and predictable result than a
NULL string, which suggests something went wrong with the read). And
this fixes the test that was originally submitted for this ticket. :-)

The second patch was not quite correct - we need to have it :multi for
when we implement the regex variant. I changed it to:

.sub 'split' :method :multi('String')

So it's a bit more liberal about what sorts of strings it gets for now.

Thanks!

Jonathan

Re: Where did the toggle switch go?

2008-09-11 Thread Vasily Chekalkin


Will Coleda wrote:

On Thu, Sep 11, 2008 at 8:11 AM, James E Keenan [EMAIL PROTECTED] wrote:

Is it just me  ...?


Yup.


When I went to rt.perl.org just now to reply to a ticket, I could not find
the toggle for automatically CC-ing [EMAIL PROTECTED]  I know it was
there just last night.  I am clearly logged in to RT.  What gives?


I just did this about 30 seconds ago, the link was there.


I've got same problems... This link not always appears on reply page. 
(In my case it's appears very rare...)


--
Bacek

[perl #58602] subset types and multi dispatch don't mix

On Fri Sep 05 08:26:34 2008, [EMAIL PROTECTED] wrote:
 Rakudo r30787 dies on multi dispatch when subset types are involved:
 
Yes; this ticket depends on us switching over to the new
multi-dispatcher (perl6multisub.pmc), which does handle this case. I
hope to get that sorted out in the near future.

Thanks,

Jonathan

[perl #58012] Empty contextualizer @() should be same as @($/)

Hi,

This is implemented in r30983, as are $() and %() (which mean $($/) and
%($/) respectively). Also unfudge'd a spec test.

Jonathan

[perl #58012] Empty contextualizer @() should be same as @($/)

Hi,

This is implemented in r30983, as are $() and %() (which mean $($/) and
%($/) respectively). Also unfudge'd a spec test.

Jonathan

[perl #58012] Empty contextualizer @() should be same as @($/)

Hi,

This is implemented in r30983, as are $() and %() (which mean $($/) and
%($/) respectively). Also unfudge'd a spec test.

Jonathan

[perl #58012] Empty contextualizer @() should be same as @($/)

Hi,

This is implemented in r30983, as are $() and %() (which mean $($/) and
%($/) respectively). Also unfudge'd a spec test.

Jonathan

[perl #57338] parrot segfaults after nonexistent method is called from within sub invoked without parens in rakudo

On Sun Jul 27 08:06:04 2008, masak wrote:
 This also works, but segfaults:
 
 $ ./perl6 -e 'class A {}; sub c { say A.new.b() }; c'
 Method 'b' not found for invocant of class 'A'
 current instr.: 'c' pc 99 (EVAL_13:42)
 called from Sub '_block11' pc 17 (EVAL_13:11)
 called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
 (src/PCT/HLLCompiler.pir:481)
 called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305
 (src/PCT/HLLCompiler.pir:708)
 called from Sub 'parrot;Perl6::Compiler;main' pc 14567 (perl6.pir:172)
 perl6(27149) malloc: *** error for object 0xcc2e40: double free
 *** set a breakpoint in malloc_error_break to debug
 Segmentation fault

Is this still an issue - I think I saw something to the effect taht the
double free had been resolved recently-ish?

Thanks,

Jonathan

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

2008-09-11 Thread Vasily Chekalkin

References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
Content-Type: multipart/mixed;
 boundary=09080402060404020800
X-Posted-By: 122.110.103.226

--09080402060404020800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Will Coleda wrote:
 
 Now that we can subclass PMCs with Objects, we need to go through all
 the code in src/pmc/*.pmc that directly fiddles with PMC guts (e.g.
 PMC_int_val(...) and PMC_num_val(...) and replace them with VTABLE
 accessor methods, or constructs like SELF.get_integer().

Just for clarification, it attached patch is actually what this ticket 
about?

-- 
Bacek

--09080402060404020800
Content-Type: text/x-patch;
 name=bigint.patch
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename=bigint.patch

diff --git a/src/pmc/bigint.pmc b/src/pmc/bigint.pmc
index 9399eae..0c00f18 100644
--- a/src/pmc/bigint.pmc
+++ b/src/pmc/bigint.pmc
@@ -746,7 +746,7 @@ MMD_Integer: {
 else
 dest = pmc_new(INTERP, SELF-vtable-base_type);
 
-bigint_add_bigint_int(INTERP, SELF, PMC_int_val(value), dest);
+bigint_add_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), dest);
 return dest;
 }
 MMD_DEFAULT: {
@@ -804,7 +804,7 @@ MMD_Integer: {
 else
 dest = pmc_new(INTERP, SELF-vtable-base_type);
 
-bigint_sub_bigint_int(INTERP, SELF, PMC_int_val(value), dest);
+bigint_sub_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), dest);
 return dest;
 }
 MMD_DEFAULT: {
@@ -862,7 +862,7 @@ MMD_Integer: {
 else
 dest = pmc_new(INTERP, SELF-vtable-base_type);
 
-bigint_mul_bigint_int(INTERP, SELF, PMC_int_val(value), dest);
+bigint_mul_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), dest);
 return dest;
  }
 MMD_DEFAULT: {
@@ -886,7 +886,7 @@ MMD_BigInt: {
 bigint_mul_bigint(INTERP, SELF, value, SELF);
 }
 MMD_Integer: {
-bigint_mul_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_mul_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), SELF);
  }
 MMD_DEFAULT: {
 Parrot_ex_throw_from_c_args(INTERP, NULL,
@@ -943,7 +943,7 @@ MMD_Integer: {
 else
 dest = pmc_new(INTERP, SELF-vtable-base_type);
 
-bigint_div_bigint_int(INTERP, SELF, PMC_int_val(value), dest);
+bigint_div_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), dest);
 return dest;
 }
 MMD_DEFAULT: {
@@ -967,7 +967,7 @@ MMD_BigInt: {
 bigint_div_bigint(INTERP, SELF, value, SELF);
 }
 MMD_Integer: {
-bigint_div_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_div_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), SELF);
 }
 MMD_DEFAULT: {
  Parrot_ex_throw_from_c_args(INTERP, NULL,
@@ -994,7 +994,7 @@ MMD_Integer: {
 VTABLE_morph(interp, dest, SELF-vtable-base_type);
 else
 dest = pmc_new(INTERP, SELF-vtable-base_type);
-bigint_fdiv_bigint_int(INTERP, SELF, PMC_int_val(value), dest);
+bigint_fdiv_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), dest);
 return dest;
 }
 MMD_DEFAULT: {
@@ -1018,7 +1018,7 @@ MMD_BigInt: {
 bigint_fdiv_bigint(INTERP, SELF, value, SELF);
 }
 MMD_Integer: {
-bigint_fdiv_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_fdiv_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), SELF);
 }
 MMD_DEFAULT: {
 Parrot_ex_throw_from_c_args(INTERP, NULL,
@@ -1046,7 +1046,7 @@ MMD_Integer: {
 else
 dest = pmc_new(INTERP, SELF-vtable-base_type);
 
-bigint_mod_bigint_int(INTERP, SELF, PMC_int_val(value), dest);
+bigint_mod_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), dest);
 return dest;
  }
 MMD_DEFAULT: {
@@ -1072,7 +1072,7 @@ MMD_BigInt: {
 bigint_mod_bigint(INTERP, SELF, value, SELF);
 }
 MMD_Integer: {
-bigint_mod_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_mod_bigint_int(INTERP, SELF, VTABLE_get_integer(interp, 
value), SELF);
  }
 MMD_DEFAULT: {
 Parrot_ex_throw_from_c_args(INTERP, NULL,
@@ -1085,7 +1085,7 @@ MMD_BigInt: {
 bigint_mod_bigint(INTERP, SELF, value, SELF);
 }
 MMD_Integer: {
-bigint_mod_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_mod_bigint_int(INTERP, SELF, VTABLE_get_integer(interp,

[perl #58558] Implement stubby exception generators in Rakudo

On Wed Sep 03 11:10:21 2008, masak wrote:
 Implement the '...', '???' and '!!!' operators, as described in S03:1691.

I've just done in r30980 the argumentless case of '...':

sub foo { ... }
my $x = foo(); say $x;
Attempt to execute stub code (...).

The argument version needs a bit more work as it needs the args rule
from STD.pm, and we can't do !!! and ??? in Rakudo yet because it ends
up getting parsed as three prefix:! or prefix:? by the operator
precedence parser. That probably waits on a hack (same one needed for -
to work on RHS) or LTM, if I'm understanding what's going on correctly.

So, ticket should stay open while we do the rest, but this is the first
piece of the puzzle, and hopefully useful.

Thanks,

Jonathan

Re: Where did the toggle switch go?

On Thu, Sep 11, 2008 at 8:36 AM, Vasily Chekalkin [EMAIL PROTECTED] wrote:
 Will Coleda wrote:

 On Thu, Sep 11, 2008 at 8:11 AM, James E Keenan [EMAIL PROTECTED] wrote:

 Is it just me  ...?

 Yup.

 When I went to rt.perl.org just now to reply to a ticket, I could not
 find
 the toggle for automatically CC-ing [EMAIL PROTECTED]  I know it
 was
 there just last night.  I am clearly logged in to RT.  What gives?

 I just did this about 30 seconds ago, the link was there.

 I've got same problems... This link not always appears on reply page. (In my
 case it's appears very rare...)

 --
 Bacek


Might depend on whether you're using the public page or the page for
bugadmins. (The public page now has a link to the bugadmin version to
help avoid this confusion.)

-- 
Will Coke Coleda

Re: Where did the toggle switch go?

2008-09-11 Thread Patrick R. Michaud

On Thu, Sep 11, 2008 at 08:11:50AM -0400, James E Keenan wrote:
 Is it just me  ...?

 When I went to rt.perl.org just now to reply to a ticket, I could not  
 find the toggle for automatically CC-ing [EMAIL PROTECTED]  I  
 know it was there just last night.  I am clearly logged in to RT.  What  
 gives?

Perhaps you were looking at a ticket in the perl6 queue?  The
automatic Cc: for perl6-internals only applies to tickets in the
parrot queue.

Pm

Re: [perl #58150] Doing split on the result of a slurped empty file results in a Null PMC Access in rakudo

2008-09-11 Thread Patrick R. Michaud

On Thu, Sep 11, 2008 at 05:34:14AM -0700, [EMAIL PROTECTED] via RT wrote:
 The second patch was not quite correct - we need to have it :multi for
 when we implement the regex variant. I changed it to:
 
 .sub 'split' :method :multi('String')
 
 So it's a bit more liberal about what sorts of strings it gets for now.

Not only that, but split needs to go into Any so that we can
split on things that aren't strings yet (i.e., by stringifying
the invocant).

Pm

Re: [perl #54000] [DEPRECATED] get_array, get_list, get_scalar methods

2008-09-11 Thread Patrick R. Michaud

On Wed, Sep 10, 2008 at 07:53:13PM -0700, James Keenan via RT wrote:
 Patrick:
 
 Where do we stand in the deprecation cycle re these three methods?

I probably just need to remove the methods from the code,
see what breaks, and fix what breaks.  I'll try to do that this
weekend before the release.  If it doesn't happen then, we can
do it immediately following the release.

Pm

Re: [perl #57338] parrot segfaults after nonexistent method is called from within sub invoked without parens in rakudo

2008-09-11 Thread Carl Mäsak

Jonathan (), Carl ():
 This also works, but segfaults:

 $ ./perl6 -e 'class A {}; sub c { say A.new.b() }; c'
 Method 'b' not found for invocant of class 'A'
 current instr.: 'c' pc 99 (EVAL_13:42)
 called from Sub '_block11' pc 17 (EVAL_13:11)
 called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
 (src/PCT/HLLCompiler.pir:481)
 called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305
 (src/PCT/HLLCompiler.pir:708)
 called from Sub 'parrot;Perl6::Compiler;main' pc 14567 (perl6.pir:172)
 perl6(27149) malloc: *** error for object 0xcc2e40: double free
 *** set a breakpoint in malloc_error_break to debug
 Segmentation fault

 Is this still an issue - I think I saw something to the effect taht the
 double free had been resolved recently-ish?

Aye, this one still persists.

// Carl

[perl #57858] $/ is de-defined in if blocks in rakudo

Hi,

All broken examples in this ticket now work as or r22207.

Thanks,

Jonathan

Re: [perl #53682] [CAGE] Visual Studio compiler for parrot

2008-09-11 Thread Reini Urban

2008/9/11 Will Coleda [EMAIL PROTECTED]:
 On Wed, Sep 10, 2008 at 10:56 PM, James Keenan via RT
 [EMAIL PROTECTED] wrote:
 Coke, particle:  Can we get an update on the issues raised in this RT?

 Thank you very much.
 kid51

 I haven't touched a win32 build of parrot in some months now, msvc or
 otherwise. Smolder is probably a better place to look for information
 at this point.
 Do we have anyone in the audience building on these tools that can
 give us a more up to date answer?

Yesterday I did a MSVC attempt with a mingw perl, which I described in
cygwin070patches/README_win23.pod

=
  If you want to use MSVC with a mingw-gcc perl you can use
  C--cc=cl --link=link. Just Far in Fconfig_lib.pasm has to be changed
  to Flib and CLIBPARROT = $(LIBPARROT_STATIC) in FMakefile.

Today I tested mingw fully and found only minor issues in some languages
not finding @build_dir@/libparrot.dll (well, perl6 is also involved :)
and I hope to patch it away soon.

MSVC with ActivePerl will be the next attempt today or tomorrow.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

[perl #58352] The inside of a while loop loses $/ in Rakduo

On Wed Aug 27 02:10:10 2008, moritz wrote:
 On Mon Aug 25 01:37:17 2008, masak wrote:
  r30528:
  $ ./perl6 -e 'while (test ~~ /(es)/) { say $0; exit; }'
  Null PMC access in get_pmc_keyed_int()
  [...]
  Segmentation fault
  
  FWIW, the error shows up in r30503, whose slightly Orwellian message
  reads [rakudo] allow access to $/, $!, $_ in while loops, closes RT
  #58306.
 
 FYI I added tests for that to t/spec/S05-match/blocks.t

This was resolved in a commit earlier today (same one that fixed a very
similar bug in if blocks). Also now unskipped some tests in the
mentioned test file.

Thanks,

Jonathan

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

2008-09-11 Thread chromatic

On Thursday 11 September 2008 04:03:27 Vasily Chekalkin wrote:

 Will Coleda wrote:

  Now that we can subclass PMCs with Objects, we need to go through all
  the code in src/pmc/*.pmc that directly fiddles with PMC guts (e.g.
  PMC_int_val(...) and PMC_num_val(...) and replace them with VTABLE
  accessor methods, or constructs like SELF.get_integer().

 Just for clarification, it attached patch is actually what this ticket
 about?

Yes, that's correct.

-- c

Re: [perl #57338] parrot segfaults after nonexistent method is called from within sub invoked without parens in rakudo

2008-09-11 Thread chromatic

On Thursday 11 September 2008 07:17:56 Carl Mäsak wrote:

 Jonathan (), Carl ():
  This also works, but segfaults:
 
  $ ./perl6 -e 'class A {}; sub c { say A.new.b() }; c'
  Method 'b' not found for invocant of class 'A'
  current instr.: 'c' pc 99 (EVAL_13:42)
  called from Sub '_block11' pc 17 (EVAL_13:11)
  called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
  (src/PCT/HLLCompiler.pir:481)
  called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305
  (src/PCT/HLLCompiler.pir:708)
  called from Sub 'parrot;Perl6::Compiler;main' pc 14567 (perl6.pir:172)
  perl6(27149) malloc: *** error for object 0xcc2e40: double free
  *** set a breakpoint in malloc_error_break to debug
  Segmentation fault
 
  Is this still an issue - I think I saw something to the effect taht the
  double free had been resolved recently-ish?

 Aye, this one still persists.

This backtrace pattern bothers me a lot; I wish I could figure it out:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7b4f8d0 (LWP 29711)]
0xb7f17410 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7f17410 in __kernel_vsyscall ()
#1  0x4810b085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x4810ca01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x4814e835 in free_check () from /lib/tls/i686/cmov/libc.so.6
#4  0x4814f495 in free () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7cae3c1 in mem_sys_free (from=0x0) at src/gc/memory.c:304
#6  0xb7caeafa in destroy_context (interp=0x81e4008) at src/gc/register.c:163
#7  0xb7cb555b in Parrot_really_destroy (interp=0x81e4008, exit_code_unused=1, 
arg_unused=0x0) at src/inter_create.c:441
#8  0xb7ca8459 in Parrot_exit (interp=0x81e4008, status=1) at src/exit.c:89
#9  0xb7ca7e26 in find_exception_handler (interp=0x81e4008, 
exception=0x4822b864) at src/exceptions.c:149
#10 0xb7ca8095 in Parrot_ex_throw_from_op (interp=0x81e4008, 
exception=0xb772ee3c, dest=0x0) at src/exceptions.c:193
#11 0xb7ca8209 in Parrot_ex_rethrow_from_op (interp=0x81e4008, 
exception=0xb772ee3c) at src/exceptions.c:363
#12 0xb7c7af1f in Parrot_rethrow_p (cur_opcode=0x828d6f4, interp=0x81e4008)
at src/ops/core.ops:832
#13 0xb7ce6bd0 in runops_slow_core (interp=0x81e4008, pc=0x828d6f4)
at src/runops_cores.c:222
#14 0xb7cb6a7f in runops_int (interp=0x81e4008, offset=164)
at src/interpreter.c:937
#15 0xb7cb754d in runops (interp=0x81e4008, offs=164) at src/inter_run.c:101
---Type return to continue, or q return to quit---
#16 0xb7cb7753 in runops_args (interp=0x81e4008, sub=0xb772ef1c, 
obj=0x823cf28, meth_unused=0x0, sig=0xb7e80886 vPS, 
ap=0xbfb38f5c ��x�212���x�212�-) at src/inter_run.c:236
#17 0xb7cb7d77 in Parrot_runops_fromc_args (interp=0x81e4008, sub=0xb772ef1c, 
sig=0xb7e80886 vPS) at src/inter_run.c:300
#18 0xb7ca7fcc in Parrot_ex_throw_from_c (interp=0x81e4008, 
exception=0xb772ee3c) at src/exceptions.c:292
#19 0xb7ca8361 in Parrot_ex_throw_from_c_args (interp=0x81e4008, 
ret_addr=0x828d65c, exitcode=45, 
format=0xb7e76018 Method '%Ss' not found for invocant of class '%Ss')
at src/exceptions.c:339
#20 0xb7c63a6c in Parrot_callmethodcc_p_sc (cur_opcode=0x828d650, 
interp=0x81e4008) at src/ops/object.ops:71
#21 0xb7ce6bd0 in runops_slow_core (interp=0x81e4008, pc=0x828d650)
at src/runops_cores.c:222
#22 0xb7cb6a7f in runops_int (interp=0x81e4008, offset=3289)
at src/interpreter.c:937
#23 0xb7cb754d in runops (interp=0x81e4008, offs=3289) at src/inter_run.c:101
#24 0xb7cb7753 in runops_args (interp=0x81e4008, sub=0xb73c65e0, 
obj=0x823cf28, meth_unused=0x0, sig=0xb7e80886 vPS, 
ap=0xbfb3916c ���XX�\024) at src/inter_run.c:236
#25 0xb7cb7d77 in Parrot_runops_fromc_args (interp=0x81e4008, sub=0xb73c65e0, 
sig=0xb7e80886 vPS) at src/inter_run.c:300
---Type return to continue, or q return to quit---
#26 0xb7ca7fcc in Parrot_ex_throw_from_c (interp=0x81e4008, 
exception=0xb73c58c0) at src/exceptions.c:292
#27 0xb7ca8361 in Parrot_ex_throw_from_c_args (interp=0x81e4008, ret_addr=0x0, 
exitcode=20, format=0xb7e82edc Class %Ss already registered!\n)
at src/exceptions.c:339
#28 0xb7cdec19 in Parrot_oo_register_type (interp=0x81e4008, name=0xb73c620c)
at src/oo.c:624
#29 0xb7e02296 in init_class_from_hash (interp=0x81e4008, self=0xb73c6084, 
info=0xb73c594c) at ./src/pmc/class.pmc:222
#30 0xb7ce620f in pmc_new_init (interp=0x81e4008, base_type=49, 
init=0xb73c620c) at src/pmc.c:368
#31 0xb7c70607 in Parrot_newclass_p_p (cur_opcode=0xb7b67b24, 
interp=0x81e4008)
at src/ops/object.ops:249
#32 0xb7ce6bd0 in runops_slow_core (interp=0x81e4008, pc=0xb7b67b24)
at src/runops_cores.c:222
#33 0xb7cb6a7f in runops_int (interp=0x81e4008, offset=3289)
at src/interpreter.c:937
#34 0xb7cb754d in runops (interp=0x81e4008, offs=3289) at src/inter_run.c:101
#35 0xb7cb7753 in runops_args (interp=0x81e4008, sub=0xb73b40dc, 
obj=0x823cf28, meth_unused=0x0, sig=0xb7e80886 vPS, 
ap=0xbfb3942c t;��X�t;��X�\024) at

Re: Iterator semantics

2008-09-11 Thread Larry Wall

On Tue, Sep 09, 2008 at 08:50:02AM -0700, Larry Wall wrote:
: At the moment the design of Perl 6 (unlike certain FP languages) is
: that any dependence on the *degree* of laziness is erroneous, except
: insofar as infinite lists must have *some* degree of laziness in order
: not to use up all your memory immediately.  But any finite list can
: do any amount of batching it pleases, so there's no foolproof way to
: tell a lazy finite list from an eager list.  Modifying the inputs to
: a lazy list is basically asking for undefined behavior.
: 
: This seems to me like the most multicore-friendly default, though
: perhaps not the most programmer friendly.  It seems to me that any
: programming involving cyclic lazy feeds must somehow have an eager
: in it somewhere to prevent indeterminacy, but I don't know how to
: write a compiler that enforces that offhand.

Perhaps there is some middle ground.  I was thinking about the
relationship of iterators with reactive programming this morning, and
it occurred to me that we tend to think of iterators as having
two states when perhaps they have more.  In the imperative mindset,
when you ask an iterator if it has more elements, it either says yes or
no.  But in the reactive mindset, the two valid answers are yes and
I dunno yet; hang on

If we are to combine these paradigms, then iterators have at least three
valid answers:

No, there is nothing to return here, ever (see EOF).
Yes, there's something here that is easy to return, and if you ask
me nicely I will return it immediately without blocking.
I don't know if there's anything to return because I'd have to ask
someone else, and that is likely to block.

So when you put something into a list context, some of the values
will be considered easy, and some will be considered hard.
The basic question is whether we treat those the same or differently
from a referential point of view.  Obviously there's an argument for
consistency on the one hand, but on the other, it's rather like the
difference between value semantics and object semantics, which is
another paradigm crossing idea.

A given array may has some values that are easy and some that are
hard.  The easy ones are the values that have already been calculated,
presumably, plus maybe any values that the first iterator spec says are
easy (and if those are all easy, go on to the next iterator spec).

My basic point is that it's easy to arrange single assignment semantics
for the easy values, and hard for the hard values.  The thing that
makes it harder for the hard values is that you have to avoid having
two different iterators asking the same sub-iterator for values.

Suppose we have

my @a = 1..10;  # assume easy
my @b = =$socket;   # assume hard

for @a,@b {...}

If the for list sees @b as hard and just copies @b's iterator into its
own list for lazy evaluation, then it's going to end up iterating the
socket without loading @b.  Contrariwise if @b is eagerly evaluated it
might clobber the other iterator in the for list.  So those iterators
must be kept unified.  It's not enough to copy out the iterators
from the array; access to the hard elements of the array must still
be modulated by the array container.  A snapshot of the array container
will not do in this case.

So I think when you ask to interpolate an array into a list, the array
must return an iterator that refers to itself, not an iterator that
merely snapshots its values.

And I guess the fundamental underlying constraint is that a list cannot
be considered immutable unless its feeds can be considered immutable,
at least in some kind of idempotent sense.  This conflicts with the
whole point of reactive programming, which is that you have to react
because don't know what's coming.

This seems like it's close to the fundamental difficulty we're trying
to solve here.  And maybe the solution is much like the value/object
distinction, where lists get to *decide* for themselves where they
switch from easy eager immutable semantics to hard lazy reactive semantics.
And if we're pretty clear about the boundary between those, it
could work out much like the boundary between DFAable regexes and
side-effectful regexes as defined in S05.  And maybe it's even the
same boundary in some theoretical sense.

As a first shot at that definition, I'll submit:

1 .. $n # easy
1 .. *  # hard

On the other hand, I can argue that if the first expression is easy,
then the first $n elements of 1..* should also be considered easy, and
it's not hard till you try to get to the *.  :)

It could also be that I'm confusing things here, of course, and that
1..* is something easy and immutable that nevertheless cannot be
calculated eagerly.  More to think about...

Larry

[perl #58718] [BUG] Assigning result of WHAT to Perl6Scalar makes wrong result.

2008-09-11 Thread jn...@jnthn.net via RT

On Tue Sep 09 07:34:40 2008, bacek wrote:
 perl6 via RT wrote:
  
  During investigating bug from #58276 I found very nasty bug with 
  assigning to Perl6Scalar.
 
 Actually bug #58278.
 
Actually wasn't Perl6Scalar itself, but rather what a proto did in item
context. Fixed that in r31004, so this should work properly.

Thanks for reporting,

Jonathan

Re: [perl #54372] [BUG] test failures on win32/msvc

2008-09-11 Thread Ron Blaschke

Will Coleda wrote:
 On Wed, Sep 10, 2008 at 10:51 PM, James Keenan via RT
 [EMAIL PROTECTED] wrote:
 Coke, particle:  Where do we stand on this ticket?

 thank you very much.

 kid51

 
 I haven't touched a win32 build of parrot in some months now, msvc or
 otherwise. Smolder is probably a better place to look for information
 at this point.
 
 Do we have anyone in the audience building on these tools that can
 give us a more up to date answer?

I haven't seen this using Visual C++ 9.0.  I'll also run a test with
6.0, 7.1 and 8.0.  Is it okay if I close this ticket if nothing special
shows up?  (There are some test failure, but not a serious breakdown
like this.)

Re: building parrot with clang + llvm

2008-09-11 Thread Moritz Lenz

NotFound wrote:
 On Wed, Sep 10, 2008 at 8:12 PM, chromatic [EMAIL PROTECTED] wrote:
 
 The line numbers reported by clang seem sensible enough, but do they match
 values in src/pmc/default.str?  Mine contains:

 #define _CONST_STRING_45 80
 #define _CONST_STRING_103 534
 #define _CONST_STRING_144 _CONST_STRING_103
 #define _CONST_STRING_182 _CONST_STRING_144
 #define _CONST_STRING_626 535
 #define _CONST_STRING_1033 3
 #define _CONST_STRING_973 536
 #define _CONST_STRING_951 _CONST_STRING_973
 
 These are .pmc file line numbers, it isn't? Looks like llvmc does not
 honor #line directives.

That's indeed the case, and the llvm/clang developers told me it's being
worked on (it seems to be a rather friendly community, from my sparse
contact so far).

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [perl #53156] [BUG] Segmentation violation in parrot

2008-09-11 Thread Clark Cooper

I just downloaded and built parrot-0.7.0. The PIR program from the original
bug report no longer SEGFAULTS.

However:

1) make test had this result:
Failed Test Stat Wstat Total Fail List of Failed
---
t/perl/Parrot_Test.t 666 55 57 59 61 63 65
15 tests and 656 subtests skipped.
Failed 1/414 test scripts. 6/10754 subtests failed.

2) A different PIR program in which I was trying to get around the bug in
the original still SEGFAULTS. I have included this program as an attachment.
I've also attached a script session where I used gdb to see where the
SEGFAULT is occurring.

On Wed, Sep 10, 2008 at 10:58 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:

Clark,

Are you still getting these failures in the latest version/revision of
Parrot?

Thank you very much.

kid51

--
Clark Cooper

classinfo.pir
Description: Binary data
[EMAIL PROTECTED] work]$ gdb ../parrot-0.7.0/parrot
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-redhat-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1.

(gdb) r classinfo.pir Class
Starting program: /home/ccc/Parrot/parrot-0.7.0/parrot classinfo.pir Class
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xabb000
[Thread debugging using libthread_db enabled]
[New Thread -1208260944 (LWP 31084)]
name: String
namespace: NameSpace
name: NCI
get_namespace: NCI
resolve_method: NCI
new: NCI
attributes: NCI
add_attribute: NCI
methods: NCI
add_method: NCI
find_method: NCI
parents: NCI
add_parent: NCI
roles: NCI
add_role: NCI
inspect: NCI
isa: NCI
does: NCI
methods: Hash
add_parent: NCI
methods: NCI
inspect: NCI
add_role: NCI
add_attribute: NCI
isa: NCI
parents: NCI
resolve_method: NCI
name: NCI
find_method: NCI
roles: NCI
attributes: NCI
add_method: NCI
new: NCI
does: NCI
get_namespace: NCI
parents: ResizablePMCArray
all_parents: ResizablePMCArray

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208260944 (LWP 31084)]
0x00424612 in Parrot_Class_does (interp=0x8f77040, pmc=0x913bad8, role_name=0x911ac48)
at ./src/pmc/class.pmc:1242
1242 if (VTABLE_isa(interp, cur_class, classname))
(gdb)

[perl #58678] [BUG] defining a regex after a grammar places the regex in the grammar namespace

On Mon Sep 08 09:08:50 2008, [EMAIL PROTECTED] wrote:
 Rakudo, r30888.  When defining a grammar and regex, defining a regex  
 after a grammar places the regex in the grammar namespace, but vice  
 versa works fine.  Below is some demo code (switch the definition  
 placements and comment out the check against Foo::Bar to see it  
 magically work):
 
 grammar Foo {
  rule TOP {\d+}
 };
 
 regex Bar {\d+};
 
 # smart match against Foo may change based on RT 58676
 '123' ~~ Foo;
 say $/;
 
 '1234' ~~ Foo::Bar; # works?!?
 say $/;
 
 '12345' ~~ Bar; # fails
 say $/;
 
Ah yes, forgot to clear the thingy holding the current namespace. Fixed
it in r31006; if you have time to contribute a test for this somewhere,
that'd be wonderful.

Thanks for reporting,

Jonathan

Re: Where did the toggle switch go?

2008-09-11 Thread James E Keenan


Vasily Chekalkin wrote:

Will Coleda wrote:
On Thu, Sep 11, 2008 at 8:11 AM, James E Keenan [EMAIL PROTECTED] 
wrote:

Is it just me  ...?


Yup.



I've got same problems... This link not always appears on reply page. 
(In my case it's appears very rare...)




Ah, so it's not just me!

I had to completely exit the browser (SeaMonkey) and open and login 
anew.  The toggle link then reappeared.

[perl #54372] [BUG] test failures on win32/msvc

On Thu Sep 11 14:28:08 2008, rblasch wrote:
 
 I haven't seen this using Visual C++ 9.0.  I'll also run a test with
 6.0, 7.1 and 8.0.  Is it okay if I close this ticket if nothing special
 shows up?  

Absolutely!

[perl #44315] [TODO] Enable scripting of an entire configuration session

The patch was indeed applied in r30640 (with touch-ups in r30645) on
2008-08-29.  There have been no complaints, so I am resolving the ticket.

Thank you very much.

kid51

[perl #58392] Recursion and for loops interact badly in Rakudo

Hi,

Here is a pure PIR example that doesn't depend on Rakudo at all.

.sub main :main
$P0 = new 'Integer'
$P0 = 2
'f'($P0)
.end

.sub 'f'
.param pmc l
.lex $l, l
$P0 = find_lex $l
if $P0 = 0 goto ret

print entering 
$P1 = find_lex $l
say $P1

$I0 = 1
  for:
if $I0  3 goto for_end
'_block1'()
inc $I0
goto for
  for_end:
  ret:
.end

.sub '_block1' :outer('f')
$P2 = find_lex $l
$P3 = new 'Integer'
$P3 = $P2 - 1
'f'($P3)
print looping in 
$P4 = find_lex $l
say $P4
.end

Gives the same erroneous output as the Rakudo program.

Jonathan

[perl #43857] [TODO] Refactor config probes that are used only by language implementation

I'm trying to see if we can move this ticket toward resolution.  I think
that it has remained unresolved for so long because the original post
originally called for two steps:  (a) removal from Configure.pl of
configuration steps which probed for features only used in specific
language implementations; (b) development of a way to conduct such
language-specific probes in the language directory trees after 'perl
Configure.pl' and 'make' have been run.

There were two specific steps cited for removal per (a):  auto::python
and auto::m4.  By June of this year I had removed both of those from
Parrot configuration.

So that leaves us with (b).  particle wrote:  languages/dotnet/ has its
own configure.pl, and m4, plumhead, etc. should follow that model. 
Barney responded:  One thing that held me back from using something
like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently
needs to be explicitly called after the main 'Configure.pl' has run.
This is bad for universal languages testing.

And that's where discussion left off three months ago.  I am
recommending the following:

(1) Mark this ticket resolved.
(2) Conduct discussion on list or IRC as to the best architecture/model
for language-specific probes.
(3) Once we've come to such resolution on (2), open a new RT to
implement what we've decided.

particle, Barney:  Any objections?

Thank you very much.
kid51

Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation

2008-09-11 Thread jerry gay

On Thu, Sep 11, 2008 at 4:47 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
 I'm trying to see if we can move this ticket toward resolution.  I think
 that it has remained unresolved for so long because the original post
 originally called for two steps:  (a) removal from Configure.pl of
 configuration steps which probed for features only used in specific
 language implementations; (b) development of a way to conduct such
 language-specific probes in the language directory trees after 'perl
 Configure.pl' and 'make' have been run.

 There were two specific steps cited for removal per (a):  auto::python
 and auto::m4.  By June of this year I had removed both of those from
 Parrot configuration.

 So that leaves us with (b).  particle wrote:  languages/dotnet/ has its
 own configure.pl, and m4, plumhead, etc. should follow that model.
 Barney responded:  One thing that held me back from using something
 like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently
 needs to be explicitly called after the main 'Configure.pl' has run.
 This is bad for universal languages testing.

 And that's where discussion left off three months ago.  I am
 recommending the following:

 (1) Mark this ticket resolved.
 (2) Conduct discussion on list or IRC as to the best architecture/model
 for language-specific probes.
 (3) Once we've come to such resolution on (2), open a new RT to
 implement what we've decided.

 particle, Barney:  Any objections?

's fine with me.
~jerry

[perl #57530] Fwd: Parallelize the Perl 6 tests