Re: [perl #57402] [BUG] GC-related segfault in t/spec/S12-class/attributes.t

[Moritz Lenz]

chromatic wrote:
> On Wednesday 30 July 2008 01:45:10 Moritz Lenz wrote:
> 
>> r29870 on i386 Debian GNU/Linux 32 bit, after a fresh checkout:
>>
>> ../../parrot perl6.pbc t/spec/S12-class/attributes.t
>> Segmentation fault
>>
>> Calling the same either with the -G option to parrot or with perl6.pir
>> instead of perl6.pbc works (aka test passes).
>>
>> So far I've not been able to reproduce it with pir.
> 
> I can't reproduce this; now it looks more like RT #57584:
> 
> 1..19
> get_bool() not implemented in class 'Exception'
> current instr.: 'proclaim' pc 9045 (./Test.pir:3062)
> called from Sub 'ok' pc 1012 (./Test.pir:356)
> called from Sub '_block11' pc 99 (EVAL_17:35)
> called from Sub 'parrot;PCT;HLLCompiler;eval' pc 851 
> (src/PCT/HLLCompiler.pir:494)
> called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1125 
> (src/PCT/HLLCompiler.pir:623)
> called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1304 
> (src/PCT/HLLCompiler.pir:712)
> called from Sub 'parrot;Perl6;Compiler;main' pc 17094 (perl6.pir:179)
> 
> Can you confirm?

Yes. Can be closed.

-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

[svn:parrot-pdd] r32010 - trunk/docs/pdds

[Whiteknight]

Author: Whiteknight
Date: Sat Oct 18 07:21:18 2008
New Revision: 32010

Modified:
   trunk/docs/pdds/pdd20_lexical_vars.pod

Log:
[PDDs] Codingstd fix on PDD20, fixing very long lines.

Modified: trunk/docs/pdds/pdd20_lexical_vars.pod
==
--- trunk/docs/pdds/pdd20_lexical_vars.pod  (original)
+++ trunk/docs/pdds/pdd20_lexical_vars.pod  Sat Oct 18 07:21:18 2008
@@ -350,8 +350,8 @@
 Here, C<$P1> contains information on the current subroutine. C<$P2> will
 contain C<$P1>'s outer subroutine.
 
-To get C<$P2>'s outer subroutine (if any), the same method can be used on 
C<$P2>
-itself:
+To get C<$P2>'s outer subroutine (if any), the same method can be used on
+C<$P2> itself:
 
 $P3 = $P2."get_outer"()
 
@@ -360,7 +360,8 @@
 
 $P0 = getinterp
 $P1 = $P0["outer"; "sub"]
-$P2 = $P0["outer"; "sub"; 2] # get the outer sub of the current's outer 
subroutine
+$P2 = $P0["outer"; "sub"; 2] # get the outer sub of the current's outer
+ # subroutine
 
 It is also possible to get the C<:outer> sub's LexPad, as above:
 

[perl #58974] [TODO][IMCC] replace .return in tailcall context by .tailcall

[Andrew Whitworth via RT]

On Sat Oct 18 07:38:32 2008, Whiteknight wrote:
> > On Wed Sep 17 09:50:10 2008, kjs wrote:
> > > as suggested by Allison,
> > > .return in a tailcall context, like this:
> > > 
> > >  .return foo()
> > > 
> > > will changed into:
> > > 
> > >  .tailcall foo()
> 
> I've added ".tailcall" syntax to IMCC. It is supposed to be used instead
> of ".return" in tailcall context. Using ".return" for this is deprecated. 
> 
> I haven't tested yet, but i assume there are going to be a lot of uses
> of the old syntax throughout the repo that will need to be updated. Do
> any of our code generators like PCT use the old syntax? If so, how hard
> would it be to update them?
> 
> 

Forgot to post this reply to perl6-internals

-- 
Andrew Whitworth
a.k.a Whiteknight

[perl #57430] [TODO] [PDD19] implement .HLL_map 'Foo' = 'Bar'

[Andrew Whitworth via RT]

On Thu Jul 31 03:04:09 2008, kjs wrote:
> Implemented in r29908.
> 
> kjs
> 
> On Wed, Jul 30, 2008 at 7:51 PM, via RT Will Coleda <
> [EMAIL PROTECTED]> wrote:
> 
> > # New Ticket Created by  Will Coleda
> > # Please include the string:  [perl #57430]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt3/Ticket/Display.html?id=57430 >
> >
> >
> > =item .HLL_map  = 
> >
> > This is identical to the current implementation that uses a , for its
> > syntax.
> >
> > This syntax needs to be added, and then the comma version can go
> > through a deprecation cycle before removal.
> >
> > --
> > Will "Coke" Coleda
> >

This syntax was added by kjs++ and it appears to work properly. The
deprecation of the comma form of .HLL_map is being handled by RT#57432,
so we can close this ticket now.

-- 
Andrew Whitworth
a.k.a Whiteknight

Re: [perl #59784] [PATCH] Enhancement : support for multiple optables in PGE

[Florian Hatat]

Patrick R. Michaud a écrit :
> As that's being done, I suspect we may discover a far superior
> mechanism for handling optables in general, including allowing
> multiple optables.
>   

The only piece of information I could find about protoregexes was
actually STD.pm. I'm sure that I don't understand all details (in
particular, STD.pm defines precedence levels, this looks like black
magic to me for the moment), but it seems indeed that protoregexes could
do the trick.

> An intermediate answer might be to have an "is optable" trait 
> for proto subs that can specify an optable to use other than 
> the default.

That would be possible: if you like, I can write something for that...
(But read the following.)

> In particular, I don't want to provide too many new structures/
> features that we may want to turn around and quickly deprecate
> when protoregexes come into play

I agree with that, so it may be better to forget about this patch for
the moment.

May I just suggest that the documentation be changed to state explicitly
that only one optable is allowed? (Something like the tiny attached patch?)

-- 
Florian,
http://openweb.eu.org/
http://www.linux-france.org/

--- docs/pct/pct_optable_guide.pod	2008-09-17 00:14:34.0 +0200
+++ docs/pct/pct_optable_guide.new	2008-10-18 18:29:08.0 +0200
@@ -426,7 +426,7 @@
 
 =item * How many operator tables can I use in my language?
 
-{{ XXX I think one only? Anybody? }}
+You can only use one optable in your grammar.
 
 =item * How does an optable parser work?
 

Re: [perl #57584] [BUG] Can't test for truthness of $!

[Vasily Chekalkin]

Hello.

WFM on r32022

--
Bacek

Re: [perl #57584] [BUG] Can't test for truthness of $!

[Moritz Lenz]

Vasily Chekalkin wrote:
> Hello.
> 
> WFM on r32022

Not for me on r32033. Did you actually run the second test?

Moritz


-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

[perl #59982] [BUG] MMD fail for undef/complex interaction.

[via RT]

# New Ticket Created by  Vasily Chekalkin 
# Please include the string:  [perl #59982]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=59982 >


Hello.

00:05   bacek
rakudo: my $a; $a = $a + 1i; say $a

00:05   polyglotbot
OUTPUT[Multiple Dispatch: No suitable candidate found for 'add', with 
signature 'PPP->P'␤current instr.: 'infix:+' pc 1941 
(src/gen_builtins.pir:1368)␤called from Sub '_block11' pc 60 
(EVAL_12:25)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 
(src/PCT/HLLCompiler.pir:498)␤called from Sub


00:08   bacek
rakudo: my $a; $a = 1i + $a; say $a


00:08   polyglotbot
OUTPUT[0+1i␤]

-- 
Bacek

[perl #39796] [TODO] Implement .loadlib pragma in IMCC

[Andrew Whitworth via RT]

On Fri Jul 14 06:23:20 2006, coke wrote:
> So, does .loadlib wipe the current .HLL pragma that's in effect? (if  
> it's intereacting with the other dot-pragmas, we need to document.)
> 
> Regards.
> 
> On Jul 14, 2006, at 7:17 AM, Audrey Tang wrote:
> 
> >
> > 在 2006/7/14 上午 6:45 時，Audrey Tang 寫到：
> >> Changing it back to :immediate makes tests pass again.
> >>
> >> Alternately, skipping the Parrot_register_HLL part in IMCC makes  
> >> tests pass again.
> >
> > After several rounds of trial-and-error, I've committed r13294 that  
> > works around the problem:
> >
> > * Tcl: Change back to .loadlib.
> >
> >   Simply adding this line to tcllib.pir:
> > .loadlib 'dynlexpad'
> >   appears to fix the problem.
> >
> >   According to leo, .loadlib acts like a dummy HLL, so there is
> >   an order dependency to be observed by .loadlib calls.
> >
> >   This may not be a problem if Parrot_register_HLL_type takes the
> >   HLL name instead of the current max HLL_idx, but the current state
> >   renders this workaround neccessary.
> >
> > So this ticket is probably good to be closed again, though it still  
> > leaves me somewhat puzzled. :)
> >
> > Audrey
> 
> --
> Will "Coke" Coleda
> [EMAIL PROTECTED]
> 
> 

This ticket is over two years old. Does the ".loadlib" pragma work
without problems now? Does it still appear to interact negatively with
the .HLL pragma?

If the .loadlib pragma is implemented and doesn't cause any problems, we
should close this ticket.

-- 
Andrew Whitworth
a.k.a Whiteknight

Re: [perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[ajr]

>
> I don't know who is submitting the Darwin x86 tests.
>

Probably Seneca.


--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com

Re: [perl #57576] Twigils on reported in "Scop not found" error messages

[Vasily Chekalkin]

References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: multipart/mixed;
 boundary="01010104050702010809"
X-Posted-By: 122.110.127.219

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

Hello.

Trivial patch attached.

-- 
Bacek

--01010104050702010809
Content-Type: text/x-patch;
 name="57576.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="57576.patch"

diff --git a/languages/perl6/src/parser/actions.pm 
b/languages/perl6/src/parser/actions.pm
index 394b419..5ad4325 100644
--- a/languages/perl6/src/parser/actions.pm
+++ b/languages/perl6/src/parser/actions.pm
@@ -2287,8 +2287,8 @@ method variable($/, $key) {
 );
 }
 else {
-# Variable. [!:^] twigil should be kept in the name.
-if $twigil eq '!' || $twigil eq ':' || $twigil eq '^' { $name := 
$twigil ~ ~$name; }
+# Variable. [!:^?] twigil should be kept in the name.
+if $twigil eq '!' || $twigil eq ':' || $twigil eq '^' || $twigil 
eq '?' { $name := $twigil ~ ~$name; }
 
 # All but subs should keep their sigils.
 my $sigil := '';

--01010104050702010809--

Re: [perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[Allison Randal]

James Keenan via RT wrote:

On Sat Oct 18 16:28:22 2008, coke wrote:


I'm submitting some every night at midnight on my osx/x86 box; if it's
obviously a temp directory and the right time frame, it's probably me.


Coke, can you confirm that the test is failing for you now? And, what 
version of Mac OS?



So it seems to be failing consistently on Darwin regardless of platform.


It's passing on Mac OS 10.5.5 on my Intel laptop. Which makes it 
difficult to debug the failure.



Also, tonight I confirmed that the failure began at the recent merge in
r31668.  For the record, the svn diff of the test file at that point was:

$ svn diff -r 31667:31668 t/op/bitwise.t
Index: t/op/bitwise.t
===
--- t/op/bitwise.t  (revision 31667)
+++ t/op/bitwise.t  (revision 31668)
@@ -552,11 +552,11 @@
 loop:
 if $P1 > 100 goto done
 ## shift number and i_number into $P2 and $I2.
-n_shl $P2, number, $P1
+shl $P2, number, $P1
 $I1 = $P1
 shl $I2, i_number, $I1
 ## compare in I registers.
-$P3 = n_mod $P2, integer_modulus
+$P3 = mod $P2, integer_modulus
 $I3 = $P3
 if $I2 >= 0 goto pos_check
 ## The register op gave a negative result, but the modulus will
always be


However, as this test is passing on many other platforms, it's quite
possible that the failure is due to something that happened elsewhere in
r31668.


I would suggest reverting that one change to see if it solves the 
problem, but the n_mod and n_shl opcodes don't exist anymore.


Could you run the attached modified version of the test file and send me 
the output?


Allison
## The PMC shl op will promote Integer to Bigint when needed.  We can't stuff a
## BigInt in an I register, but we can produce the same result modulo wordsize.
## [Only we cheat by using the word size minus one, so that we don't have to
## deal with negative numbers.  -- rgr, 2-Jun-07.]
.sub main :main
## Figure out the wordsize.  We need integer_modulus because assigning a
## too-big BigInt throws an error otherwise.
.include 'sysinfo.pasm'
.local int i_bytes_per_word, i_bits_per_word_minus_one
.local pmc bits_per_word_minus_one, integer_modulus
i_bytes_per_word = sysinfo .SYSINFO_PARROT_INTSIZE
i_bits_per_word_minus_one = 8 * i_bytes_per_word
dec i_bits_per_word_minus_one
bits_per_word_minus_one = new 'Integer'
bits_per_word_minus_one = i_bits_per_word_minus_one
integer_modulus = new 'BigInt'
integer_modulus = 1
integer_modulus <<= bits_per_word_minus_one

## Test shifting a positive number.
new $P0, 'Integer'
set $P0, 101
test_shift($P0, integer_modulus)

## Test shifting a negative number.
set $P0, -101
test_shift($P0, integer_modulus)
.end

.sub test_shift
.param pmc number
.param pmc integer_modulus
new $P1, 'Integer'
set $P1, 1
.local int i_number
i_number = number

## Start the loop.
loop:
if $P1 > 100 goto done
## shift number and i_number into $P2 and $I2.
say "\nno error before shl"
$S0 = typeof number
print "typeof first argument 'number' is "
say $S0
$S0 = typeof $P1
print "typeof second argument '$P1' is "
say $S0
shl $P2, number, $P1
say "no error after shl"
$S0 = typeof $P2
print "typeof result '$P2' is "
say $S0
$I1 = $P1
shl $I2, i_number, $I1
## compare in I registers.
say "\nno error before mod"
$S0 = typeof $P2
print "typeof first argument '$P2' is "
say $S0
$S0 = typeof integer_modulus
print "typeof second argument 'integer_modulus' is "
say $S0
$P3 = mod $P2, integer_modulus
say "no error after mod"
$S0 = typeof $P3
print "typeof result '$P3' is "
say $S0
$I3 = $P3
if $I2 >= 0 goto pos_check
## The register op gave a negative result, but the modulus will always be
## positive.  If the truncated result is correct, then the difference will
## be the most negative INTVAL, which is the only number for which -x==x.
$I4 = $I3 - $I2
$I5 = - $I4
if $I4 == $I5 goto ok
goto bad
pos_check:
if $I2 == $I3 goto ok
bad:
print "oops; not ok: "
print i_number
print ' << '
print $I1
print ' gives I '
print $I2
print ' vs. P '
print $P3
print ".\n"
print $I5
print "\n"
ok:
## set up for the next one
inc $P1
goto loop
done:
print "done.\n"
.end

Re: [perl #45965] [RFC] Should slot names still have __ in front?

[Allison Randal]

chromatic wrote:

On Wednesday 15 October 2008 17:33:58 Will Coleda via RT wrote:


With the attached patch, parrot builds and tests with no errors[0]. A
re-configure is necessary to regenerate a file.

[0] well, no additional or unexpected errors.


Works for me.  +1 to apply.


+1

Allison

Re: [perl #36249] [TODO] Document policy on breakage, er, backward compatibility.

[Allison Randal]

jerry gay wrote:

On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT
<[EMAIL PROTECTED]> wrote:

On Sat Jun 11 13:08:49 2005, chip wrote:

Short version: Up through version 0.8 or so, we promise to break
everything constantly (but not until we have a good reason).  After
that, we will establish version number thresholds below which
individual APIs will not change.

For example, only on a major version change are we allowed to even
consider breaking the embedding API.  On the other hand, we may break
pasm somewhat more frequently: humans should only write pir, not pasm,
and it's not against the law to abuse silicon-based life forms.

Has anybody put any thought into this? Do we have any documents or
drafts which address this issue? We are getting close enough to the 0.8
release that's mentioned here as a specific milestone for getting this done.


replace 0.8 with 0.50 or so. we're not close enough to release at 0.8
to worry about this yet.


Change that to 1.0, which is when we'll start guaranteeing API stability.

And, we have discussed it considerably. The most likely scenario so far is:

- Yearly major release (1.0, 2.0, 3.0...), which may contain substantial 
API changes.


- Half-yearly minor release (1.5, 2.5, 3.5...), which may contain minor 
API changes, and deprecation notices for the next major release.


- Regular (two/three month?) point releases (1.x.x, 2.x.x...) primarily 
bug and security fixes, which will contain no API deletions, but may 
contain minor API additions, and deprecation notices for the next major 
or minor release.



This continues our time-based release policy, which has worked well for 
the development release process. Features that don't make it into one 
major or minor release get rolled into the branch for the next major or 
minor release, so we don't have an insane rush to cram features in just 
before a release.


Allison

Re: [perl #58988] [RFC] Parrot_get_runtime_prefix function

[Allison Randal]

NotFound (via RT) wrote:


The Parrot_get_runtime_prefix in src/library.c return a char *,
forcing the places that currently uses it to be more complicated than
desired for no real gain. I added and used a STRING * variant named
Parrot_get_runtime_path (that name makes more sense to me) in r31216

The question is: must we retain the old variant, kill it, deprecate
it, use his name for the new version, or revert the change and stay
with the char * way?


'STRING *' is vastly preferable to 'char *' anywhere it can be used. 
Mark the old one as deprecated, replace all calls to 
'Parrot_get_runtime_prefix' with calls to 'Parrot_get_runtime_path', and 
after a standard one release deprecation cycle remove the old function.


Allison

[perl #59986] Method syntax .:X doesn't work

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #59986]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=59986 >


In Rakudo r32009,

$ ./perl6 -e '"somefile" ~~ :e'

works, whereas

$ ./perl6 -e '"somefile".:e'
Multiple Dispatch: No suitable candidate found for 'concatenate_str',
with signature 'PSP->P'
[...]

doesn't. There are plenty of indications in the synopses that the
latter should work.

 
 

Re: [perl #59240] Automate publishing of docs/*

[Allison Randal]

Chris Davaz wrote:

Ahh, cool I didn't even know we had parrot.org. Publishing docs/book/*
would be nice.

On Tue, Sep 23, 2008 at 10:27 PM, Will Coleda:

On Tue, Sep 23, 2008 at 9:04 AM, via RT Chris Davaz:


I suggest we automate the publishing of everything under docs/* and
putting it under parrotcode.org/docs in HTML format for easy access.
This would probably help productivity and maybe even attract new
developers.

Just my two cents...


we're moving to http://www.parrot.org/ ; I think Allison has said
we're going to automate this publishing process.


Yes, we're moving to docs.parrot.org, a site generated using a fork of 
the perldoc.perl.org generation code. (Ideally, this will end up being 
the 'make html' target, so anyone can generate a mirror of the same site.)


Allison

[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin

[James Keenan via RT]

I probably spoke too soon.  We have a Smolder failure report for this
test on AIX.  So I'm going to reopen the ticket and rename it "failing
intermittently on various OSes."

[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin

[James Keenan via RT]

I should have included the failure report:

http://smolder.plusthree.com/app/public_projects/tap_stream/6324/202

This was at r32032.