Re: Idea: infer types of constants

[TSa]

HaloO,

John M. Dlugosz wrote:

Then the declaration

  my ::T $x = whatever;

should use the exact same generic mechanism!  At worst, it needs


I would expect that this works by binding ::T to the type of whatever.



  my Any ::T $x = whatever;


Any here is optional.


and it will introduce the T symbol at that point based on the actual 
type of what gets initialized.


Yes. But the problem is that this does *not* fix the constraint
of $x to be T from there on! Or does it?

   my ::T $x = 'blahh';  #  ::T ::= Str

   my T $y = 'blubb';

   $x = 23; # legal
   $y = 42; # illegal

So perhaps one needs

   my ::T T $x = 'blahh';

to constrain $x to the type of the rhs.


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

shape trait and Hash

[John M. Dlugosz]

In S02 it is writ, "The key type of a hash may be specified as a shape 
trait--see S09."

However, S09 is rather brief on hashes, and although it shows using a type 
inside the curlies, it never talks about shape traits or anything else.

Am I do understand that it pretty much does all the same stuff that Array does?

More globally, nothing is said much about parameters to types.  It shows an 
example like  Array[of=>T] but never discusses the syntax of defining 
parameterized types or anything.  Is there a paper or discussion on that I 
could read?

Thanks,
--John

Re: shape trait and Hash

[TSa]

HaloO,

John M. Dlugosz wrote:

More globally, nothing is said much about parameters to types.

> It shows an example like  Array[of=>T] but never discusses the
> syntax of defining parameterized types or anything.  Is there

a paper or discussion on that I could read?


Essentially the direct indexing of a name with [] and {} is
reserved for type theoretical things. And one paper that makes
use of this is Theory.pod from Luke. Apart from that the
current design doesn't say much about the type system ;(


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

Re: Idea: infer types of constants

[Jonathan Worthington]

Miller, Hugh wrote:

What about the type support (system) one sees in ML ? (e.g., the way it
assigns automatically types can be assigned, does not require specific
types when they are not needed, flags incompatibilities, etc.) Do those
things not fit well with Perl's approaches and aims ? 
  
They don't really fit with Perl 6 too well. For example, suppose we 
tried to type inference this:


my $a = 42;
foo();
my $b = $a;

What is the type of $b? Well, we can't actually infer that because foo 
might be:


sub foo() {
   $OUTER::a = "oh hi, i iz not int!"
}

And because subs can be wrapped at runtime, or symbol tables can be 
diddled, or other such fun, we probably can't safely look at foo at 
compile time in the general case to make sure our inference is correct 
too, because foo might not be the foo we thought it was at compile time 
by the time we reach runtime.


From what I can see, making a language where the types are inferable, 
like ML, can almost involve doing the language design on a knife edge. 
You need the inference to not only be decidable, but also reasonably 
efficient, and a subtle feature interaction can hurt this (I think ML 
nearly had one of these when ref types and let statements interacted in 
a way that could compromise type safety - I'm rusty on the details). And 
if I'm remembering correct, there are contrived programs you can write 
that make the ML checker go exponential order in the size of the code too.


Jonathan

Re: Idea: infer types of constants

[TSa]

HaloO,

Jonathan Worthington wrote:

Miller, Hugh wrote:


Was that private communication or on another mailing list?


What is the type of $b? Well, we can't actually infer that because foo 
might be:


sub foo() {
   $OUTER::a = "oh hi, i iz not int!"
}


That should be $CALLER::a because $OUTER::a is the outer
lexical scope where foo is defined. And I think that this
reaching out to the caller should taint foo in some way.


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

Re: "$" vars in PASM don't work, but aren't disallowed either

[cognominal]

This patch should fix the problem.
Note that one needs to run flex so as to generate the dependant file
that is tracked by svn.

cd compilers/imcc
flex -d  -o imclexer.c imcc.l


Index: compilers/imcc/imcc.l
===
--- compilers/imcc/imcc.l   (revision 26966)
+++ compilers/imcc/imcc.l   (working copy)
@@ -629,25 +629,36 @@

 \$I[0-9]+ {
 if (valp) (valp)->s = yytext;
+   if (IMCC_INFO(interp)->state->pasm_file)
+   REJECT;
 return IREG;
 }

 \$N[0-9]+ {
 if (valp) (valp)->s = yytext;
+   if (IMCC_INFO(interp)->state->pasm_file)
+   REJECT;
 return NREG;
 }

 \$S[0-9]+ {
 if (valp) (valp)->s = yytext;
+   if (IMCC_INFO(interp)->state->pasm_file)
+   REJECT;
 return SREG;
 }

 \$P[0-9]+ {
 if (valp) (valp)->s = yytext;
+   if (IMCC_INFO(interp)->state->pasm_file)
+   REJECT;
 return PREG;
 }

 \$[a-zA-Z0-9]+ {
+   if (!IMCC_INFO(interp)->state->pasm_file)
+IMCC_fataly(interp, E_SyntaxError,
+"'%s' is not a valid identifier or register name
in pir mode", yytext);
 IMCC_fataly(interp, E_SyntaxError,
 "'%s' is not a valid register name", yytext);
 }


On Apr 14, 10:22 am, [EMAIL PROTECTED] (Klaas-Jan Stol) wrote:
> On Mon, Apr 14, 2008 at 12:26 AM, via RT Bob Rogers
>
>
> <[EMAIL PROTECTED]> wrote:
> > # New Ticket Created by  Bob Rogers
> >  # Please include the string:  [perl #52858]
> >  # in the subject line of all future correspondence about this issue.
> >  # http://rt.perl.org/rt3/Ticket/Display.html?id=52858>
>
> >    If you run the following PASM code:
>
> >         new P0, 'Integer'
> >         set P0, 77
> >         set $N1, 1
> >         set $N2, 2
> >         set $N3, 3
> >         print $N1
> >         print ' '
> >         print $N2
> >         print ' '
> >         print $N3
> >         print "\n"
> >         print P0
> >         print "\n"
> >         end
>
> >  you will see something like the following output:
>
> >         [EMAIL PROTECTED]> ./parrot dollar-vars.pasm
> >         3.00 3.00 3.00
> >         Segmentation fault
> >         [EMAIL PROTECTED]>
>
> >  The reason for this odd behavior is that all of the $N registers are
> >  getting mapped to "N-1" (that's the register *before* N0); disassembly
> >  shows the bogus register numbers clearly.  This happens to overwrite P0,
> >  hence the segfault.
>
> >    So either the "$" syntax for registers must be disabled in PASM, or
> >  it must be implemented properly.  (I don't particularly care, and
> >  haven't the IMCC-fu to do anything about it myself.)
>
> >                                         -- Bob Rogers
> >                                            http://rgrjr.dyndns.org/
>
> IMCC's lexer has a number of states, one of which is "emit". I'm not
> clear on how all these states are interacting,and to what cases these
> states correspond, but I think "emit" is "pasm" mode (I might be wrong
> here! I never really figured out what all states in IMCC are). The
> lexer recognizes virtual registers (with the $) in this "emit" state
> too.
>
> Ideally, the lexer could be tweaked that when reading $P0 in pasm
> mode, it emits an error message saying you can't use virtual registers
> in pasm mode. Rewriting the lexer rules (and states) might be tricky,
> but a simple solution would to check whether the lexer is in pasm mode
> in the action body of the rule for registers. (I think there's a flag
> in IMCC_INFO).
>
> I don't have time currently to work on this, unfortunately
>
> kjs

Re: Idea: infer types of constants

[Jonathan Worthington]

TSa wrote:

Jonathan Worthington wrote:

Miller, Hugh wrote:

Was that private communication or on another mailing list?
It was also sent to perl6-language, through I was on the To or Cc line 
too, so I guess that's how I got it but the list, somehow, didn't. Not 
sure why the original message I replied to didn't actually make it to 
the list, though.



That should be $CALLER::a because $OUTER::a is the outer
lexical scope where foo is defined. 

Yup, sorry, brain only half working at this time of day. :-)

And I think that this reaching out to the caller should taint foo in 
some way.
Sure, but from what I can see that still doesn't help us infer types at 
compile-time if what foo means can be modified at runtime.


Jonathan

Re: [perl #43305] [TODO] config/auto/perldoc.pm: Write unit tests

[Andy_Bach]

Sorry, I know this is closed but it seemed to be related to what I'm 
seeing.  Due to my (perhaps unorthodox) permission settings, I'm getting 
"No Perldoc found" due to:
config/auto/perldoc.pm

trying:
sub runstep {
 my ( $self, $conf ) = @_;

 my $cmd = $conf->data->get_p5('scriptdirexp') . q{/perldoc};
 my $tmpfile = q{c99da7c4.tmp};
 my $content = capture_output("$cmd -ud $tmpfile perldoc") || undef;

What is attempted is:
/usr/bin/perldoc -ud c99da7c4.tmp perldoc

w/ the result:
Can't write-open c99da7c4.tmp: Permission denied at 
/usr/lib/perl5/5.8.3/Pod/Perldoc.pm line 1422

Appears perldoc runs an suid and so it can't write that file name in the 
current dir.  Making it
 my $tmpfile = q{/tmp/c99da7c4.tmp};
 my $content = capture_output("$cmd -ud $tmpfile perldoc") || undef;

then makes it work. But isn't there a mktemp file that's a better route?

a

---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932

"When angry, count to four; when very angry, swear."
Mark Twain

[perl #52894] config detection perldoc failing due to write permissions

[via RT]

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


config/auto/perldoc.pm  uses a hardcoded, local path for a temp file to 
output perldoc -d to write to. perldoc also seems to use suid. So, if that 
file or the local fs is not writeable, the test fails even if perldoc is 
available.  By changing the path to use "/tmp", at least, the test will 
succeed.  On *nix.  Hmm  Okay, I guess I need to find the OS agnostic 
version of this.

Failure:
Testing 
snprintf..done.
Determining whether perldoc is 
installedno.
Determining whether python is installed.yes, 
2.5.1.
Determining whether GNU m4 is 
installedyes.
Determining whether (exuberant) ctags is 
installed.yes.
Determining Parrot's 
revision...r26971.
Determining whether ICU is 
installedno.
Generating C 
headers..done.
Generating core pmc 
list..done.
Generating 
runtime/parrot/include.done.
Configuring 
languages.done.
Generating makefiles and other build files...
No Perldoc, not generating a docs makefile.
.done.
Moving platform files into 
place..done.
Recording configuration data for later 
retrieval..done.
Okay, we're done!

Succeeding:
Testing 
snprintf..done.
Determining whether perldoc is 
installed...yes.
Determining whether python is installed.yes, 
2.5.1.
Determining whether GNU m4 is 
installedyes.
Determining whether (exuberant) ctags is 
installed.yes.
Determining Parrot's 
revision...r26971.
Determining whether ICU is 
installedno.
Generating C 
headers..done.
Generating core pmc 
list..done.
Generating 
runtime/parrot/include.done.
Configuring 
languages.done.
Generating makefiles and other build 
filesdone.
Moving platform files into 
place..done.
Recording configuration data for later 
retrieval..done.
Okay, we're done!


Index: config/auto/perldoc.pm
===
--- config/auto/perldoc.pm (revision 26971)
+++ config/auto/perldoc.pm (working copy)
@@ -37,7 +37,7 @@
 my ( $self, $conf ) = @_;

 my $cmd = $conf->data->get_p5('scriptdirexp') . q{/perldoc};
-my $tmpfile = q{c99da7c4.tmp};
+my $tmpfile = q{/tmp/c99da7c4.tmp};
 my $content = capture_output("$cmd -ud $tmpfile perldoc") || undef;

 return 1 unless defined( $self->_initial_content_check($conf, 
$content) );


---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932

"When angry, count to four; when very angry, swear."
Mark Twain

[perl #50068] [BUG] Configure doesn't detect backtrace* on ubuntu gutsy

[Mark Glines via RT]

On Mon Apr 14 12:20:52 2008, infinoid wrote:
> Issue resolved due to closure request from submitter.  Thanks!

Sorry, I should turn my brain on.  Ticket reopened pending confirmation.

tewk: does this issue still exist for you?  I've confirmed that Senaka's
Ubuntu Gutsy machine detects backtrace() just fine:

(12:25:12 PM) Senaka: Determining whether libc has the backtrace*
functions (glibc only).yes.

Re: [perl #52894] AutoReply: config detection perldoc failing due to write permissions

[Andy_Bach]

Okay a patch using File::Temp

Index: config/auto/perldoc.pm
===
--- config/auto/perldoc.pm (revision 26971)
+++ config/auto/perldoc.pm (working copy)
@@ -20,6 +20,7 @@
 use strict;
 use warnings;

+use File::Temp;
 use base qw(Parrot::Configure::Step);

 use Parrot::Configure::Utils ':auto';
@@ -37,7 +38,9 @@
 my ( $self, $conf ) = @_;

 my $cmd = $conf->data->get_p5('scriptdirexp') . q{/perldoc};
-my $tmpfile = q{c99da7c4.tmp};
+my $tmpfile = File::Temp->new( UNLINK => 1, SUFFIX => '.tmp' );
+my $mode = 0666;
+chmod $mode, $tmpfile;
 my $content = capture_output("$cmd -ud $tmpfile perldoc") || undef;

 return 1 unless defined( $self->_initial_content_check($conf, 
$content) );

a
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932

"When angry, count to four; when very angry, swear."
Mark Twain

C++ test failure caused due to dll linkage errors

[Senaka Fernando]

Hi all,

It seems that most C++ test failures are caused due to dll linkage errors.
Adding the extern "C" block to each header will circumvent these.

Regards,
Senaka

[perl #52874] Re: [bug] Build failure with G++

[Mark Glines via RT]

On Mon Apr 14 04:50:02 2008, [EMAIL PROTECTED] wrote:
> Attaching patch No. 2 for C++ Build Issue.

Using a normal C compiler (gcc), I get this warning before this patch:

src/key.c:448: warning: passing argument 2 of 'key->vtable->isa'
discards qualifiers from pointer target type

And these warnings after this patch:

src/key.c:448: warning: cast discards qualifiers from pointer target type
src/key.c:448: warning: cast discards qualifiers from pointer target type


At first glance, the only difference I can see is that your cast removes
the "const" attribute.  But instead of doing that, I'm wondering if
maybe the second argument of VTABLE_isa(interp, pmc, name) should be
made const, instead.  Would that help the g++ case too?

Mark

RE: Idea: infer types of constants

[Miller, Hugh]

 

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>Behalf Of Mark J. Reed
>Sent: Monday, April 14, 2008 2:05 PM
>To: Jonathan Worthington
>Cc: David Green; Perl6
>Subject: Re: Idea: infer types of constants
>
>On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington
>>  my Dog $fifi .= new(); # works in Rakudo too ;-)
>
>And even in Pugs! :)  Doesn't help with literals, though, e.g.
>
>my Float $approx_pi = 3.14;
>
>
>
>--
>Mark J. Reed <[EMAIL PROTECTED]>
>

What about the type support (system) one sees in ML ? (e.g., the way it
assigns automatically types can be assigned, does not require specific
types when they are not needed, flags incompatibilities, etc.) Do those
things not fit well with Perl's approaches and aims ? 

Re: [perl #50068] [BUG] Configure doesn't detect backtrace* on ubuntu gutsy

[Kevin Tew]

Issue fixed

Kevin

Mark Glines via RT wrote:

On Mon Apr 14 12:20:52 2008, infinoid wrote:
  

Issue resolved due to closure request from submitter.  Thanks!



Sorry, I should turn my brain on.  Ticket reopened pending confirmation.

tewk: does this issue still exist for you?  I've confirmed that Senaka's
Ubuntu Gutsy machine detects backtrace() just fine:

(12:25:12 PM) Senaka: Determining whether libc has the backtrace*
functions (glibc only).yes.

  

The evolution of TGE

[François Perrad]

In my opinion, TGE is a very good tool, especially for new languages 
when the grammar (and its tree structure) is not well established.

The need for language experimentation is not execution performance,
but rapid development and clean design.
The functional paradigm of TGE (like XSLT, transforming tree) allows to 
create clean design.

TGE could be used in 2 different stages : parse -> PAST, and PAST -> POST.

The current syntax allows to specified a target language :
transform name (pattern) :language('PIR') {
# action
}
Currently, only PIR is supported.
I think that the support of NQP (action written in NQP, and NQP 
generation) will be a great improvement.

By this way, TGE becomes a NQP preprocessor.

Comments most welcome.

François Perrad

Re: New specdoc available

[Moritz Lenz]

John M. Dlugosz wrote:
> Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:
>> John M. Dlugosz wrote:
>>   
>>> I posted my current work at 
>>> http://www.dlugosz.com/files/specdoc.pdf
>>> and .odt.
>>> 
>>
>> 3.1.1 Normalization uses a constant without a sigil - is that really
>> allowed?
>>   
> Yes, it's in the Synopses.
> 
> 
>> 3.1.2 BOM - can you detect UTF-32 U+FEFF painlessly? If so, you could
>> allow that
>> 3.1.3 The =encoding is used only for POD in perl 5. And if you force it
>> to be on the first line, you forbid #!/usr/bin/perl lines. What about
>> 'use encoding('ISO-8859-1');' instead? Any other thoughts?
>>   
> No problem if it can read that 'use' line in the first place.
> 
> Does a BOM also interfere with #!/usr/bin/perl ?

Sadly, yes.
I used vim with
:set nobinary fileencoding=utf-8 bomb
:w

./foo.pl
bash: ./foo.pl: cannot execute binary file

moritz

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



signature.asc
Description: OpenPGP digital signature

[perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'

[Mark Glines via RT]

On Fri Apr 04 10:50:53 2008, pmichaud wrote:
> On Fri, Apr 04, 2008 at 10:06:39AM -0700, chromatic wrote:
> > Using CONST_STRING to build the null STRING will hurt performance
> less, but
> > the right solution is to excise all traces of new_from_string()
> throughout
> > the system, and then completely forget it ever existed.
> 
> Correct.  Perhaps this ticket should be merged with RT#47011 ,
> which talks about new_from_string() being deprecated?  (Or at least
> link to that ticket.)

Ok, I've merged #52462 (regarding brokenness in the implementation of
new_from_string) into #47011 (regarding deprecation of new_from_string).
 Note the brokenness is still causing the testsuite to hang for me when
I configure Parrot with --gc=libc.

Mark

Re: static types, checking, conversions

[TSa]

HaloO,

John M. Dlugosz wrote:

This needs to be fleshed out.  Decisions need to be made.

> Anyone want to discuss it with me?

I want to. But give me time. Meanwhile you could read
e.g. .
This deals with F-bounded polymorphism in a tutorial
style. A generalisation of that is Constraint Bounded
Polymorphism as given in the papers of the WASP Group
at . Another inspiration
is the CDuce language  which is
built around semantic subtyping.

My point is that Perl 6 so far has defined a syntax
for type markup but hardly defined how typing works
---I remember the "pain but no gain" thread. It might
actually be the case that optional typing means that
you need a module that implements it.

I personally see types as the semantics of the code
with the added benefit of being machine readable and
thus can assist you in reasoning about the code.
A type system is a tool just like an IDE allows you
to browse the code, e.g. jumping to the definition of
a class or all invocations of a method etc.

There are two fundamental type errors in Perl 6:
  1) a) no or b) ambiguous targets for dispatch
  2) non-bindable args in non-dispatch position
1a and 2 can be easily avoided with slurpy Any
protos. So the only remaining offender is 1b. And
that might be pragmatized to just call them all.
So we sort of end up with the impossibility of
type errors :)

Your concerns so far have been with the typing of
assignment and binding. The former is easy because
it involves the creation of a new value. Thus one
can dispatch $x = $y on the container type of $x
and the value type of $y and store the result in
$x. So here you get an error of type 1 if any.
Binding is more complicated because there is no
new value involved but you want two containers
to share a value. This is where Larry's view concept
comes in to avoid the invariance problem of rw
containers. OTOH the synopsis say that binding
replaces the container, so

  my Int $x = 13;
  my Str $y = 'foo';

  $y := $x;
  $y = 42; # OK, type of $y now Int

but that contradicts the fact that binding happens
when functions are called

  sub foo (Dog $d) { say $d; }

  my Int $x = 23;
  foo $x;  # $d := $x makes type of $d Int and prints 23?

Note also that binding is specced only for scalars so far.
Not for elements of an array or hash!


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

Re: [perl #52894] config detection perldoc failing due to write permissions

[jerry gay]

On Mon, Apr 14, 2008 at 1:25 PM, via RT Andy_Bach @ wiwb. uscourts.
gov <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  [EMAIL PROTECTED]
>  # Please include the string:  [perl #52894]
>  # in the subject line of all future correspondence about this issue.
>  # http://rt.perl.org/rt3/Ticket/Display.html?id=52894 >
>
>
>  config/auto/perldoc.pm  uses a hardcoded, local path for a temp file to
>  output perldoc -d to write to. perldoc also seems to use suid. So, if that
>  file or the local fs is not writeable, the test fails even if perldoc is
>  available.  By changing the path to use "/tmp", at least, the test will
>  succeed.  On *nix.  Hmm  Okay, I guess I need to find the OS agnostic
>  version of this.
>
yes please. File::Temp is used throughout parrot, so there's plenty
examples to copy from.
~jerry

Re: static types, checking, conversions

[Mark J. Reed]

It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)



On 4/15/08, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> John M. Dlugosz wrote:
> > This needs to be fleshed out.  Decisions need to be made.
>  > Anyone want to discuss it with me?
>
> I want to. But give me time. Meanwhile you could read
> e.g. .
> This deals with F-bounded polymorphism in a tutorial
> style. A generalisation of that is Constraint Bounded
> Polymorphism as given in the papers of the WASP Group
> at . Another inspiration
> is the CDuce language  which is
> built around semantic subtyping.
>
> My point is that Perl 6 so far has defined a syntax
> for type markup but hardly defined how typing works
> ---I remember the "pain but no gain" thread. It might
> actually be the case that optional typing means that
> you need a module that implements it.
>
> I personally see types as the semantics of the code
> with the added benefit of being machine readable and
> thus can assist you in reasoning about the code.
> A type system is a tool just like an IDE allows you
> to browse the code, e.g. jumping to the definition of
> a class or all invocations of a method etc.
>
> There are two fundamental type errors in Perl 6:
>1) a) no or b) ambiguous targets for dispatch
>2) non-bindable args in non-dispatch position
> 1a and 2 can be easily avoided with slurpy Any
> protos. So the only remaining offender is 1b. And
> that might be pragmatized to just call them all.
> So we sort of end up with the impossibility of
> type errors :)
>
> Your concerns so far have been with the typing of
> assignment and binding. The former is easy because
> it involves the creation of a new value. Thus one
> can dispatch $x = $y on the container type of $x
> and the value type of $y and store the result in
> $x. So here you get an error of type 1 if any.
> Binding is more complicated because there is no
> new value involved but you want two containers
> to share a value. This is where Larry's view concept
> comes in to avoid the invariance problem of rw
> containers. OTOH the synopsis say that binding
> replaces the container, so
>
>my Int $x = 13;
>my Str $y = 'foo';
>
>$y := $x;
>$y = 42; # OK, type of $y now Int
>
> but that contradicts the fact that binding happens
> when functions are called
>
>sub foo (Dog $d) { say $d; }
>
>my Int $x = 23;
>foo $x;  # $d := $x makes type of $d Int and prints 23?
>
> Note also that binding is specced only for scalars so far.
> Not for elements of an array or hash!
>
>
> Regards, TSa.
> --
>
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mark J. Reed <[EMAIL PROTECTED]>

Re: static types, checking, conversions

[Mark J. Reed]

I apologize for the vagueness; I was away from browser when I sent
that. Go to http://www.ecmascript.org for the nitty gritty on
ECMAScript 4th Edition, a.k.a. "JavaScript 2", which is what I was
talking about.  White papers, specs, reference interpreter.

The link from the Firefox developers page
(http://developer.mozilla.org/en/docs/Main_Page, which you get to by
clicking the "Developer" tab on http://www.firefox.com) is called "The
Truth about Javascript", and leads to slides from Brendan Eich's talk
at last year's Ajax Experience West conference
(http://developer.mozilla.org/presentations/eich-ajax-experience-2007/).
 Embedded within the slides is discussion about what went into the
design of "Javascript 2", and a link over to the
http://www.ecmascript.org site (as well as other interesting stuff).

Re: [perl #51690] parrot fails to build from source

[Nuno 'smash' Carvalho]

On Sat, Apr 12, 2008 at 6:45 PM, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> Bernhard Schmalhofer via RT wrote:
>
> > On Do. 13. Mär. 2008, 08:37:06, coke wrote:
>  >> Do you have an existing parrot installation already? If so, the
>  >> installed library could be conflicting with running this copy of out
>  >> the build directory... Remove the installed version and try again?
>  >
>  > Hi Moritz,
>  >
>  > did you check for a conflict with an existing Parrot installation?
>
>  There was no other parrot installed.
>
>  > Could you check whether a current checkout of Parrot now works on CentOS?
>
>  No, I don't have access to that machine any more. Sorry.

 Successfully builded Parrot (r26976) on updated CentOS 5.1, and 'make test':

All tests successful.

but notice (not x86_64):

$ uname -a
Linux servidor 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:50:22 EDT 2007
i686 athlon i386 GNU/Linux

>  Cheers,
>  Moritz

./smash

Re: [perl #52932] AutoReply: [PATCH] Eclectus: Use SRFI-9 records

[Andreas Rottmann]

Oops, hit "send" too fast. Here's the patch.

Use SRFI-9 (Records)

From: Andreas Rottmann <[EMAIL PROTECTED]>


---

 languages/eclectus/compiler.scm   |6 +-
 languages/eclectus/gauche/prelude.scm |   10 --
 languages/eclectus/guile/prelude.scm  |   10 --
 3 files changed, 5 insertions(+), 21 deletions(-)


diff --git a/languages/eclectus/compiler.scm b/languages/eclectus/compiler.scm
index 1d92761..a2a22f0 100644
--- a/languages/eclectus/compiler.scm
+++ b/languages/eclectus/compiler.scm
@@ -199,7 +199,11 @@
 
 ; Support for primitive functions
 
-(define-record primitive (arg-count emitter))
+(define-record-type primitive
+  (make-primitive arg-count emitter)
+  primitive?
+  (arg-count primitive-arg-count)
+  (emitter primitive-emitter))
 
 (define *primitives* (make-eq-hashtable))
 
diff --git a/languages/eclectus/gauche/prelude.scm b/languages/eclectus/gauche/prelude.scm
index 0919f03..c60e52d 100644
--- a/languages/eclectus/gauche/prelude.scm
+++ b/languages/eclectus/gauche/prelude.scm
@@ -8,16 +8,6 @@
  (if (not condition)
  (begin body1 body ...)
 
-(define-macro (define-record name fields)
-  (define (symbol-append . symbols)
-(string->symbol (apply string-append (map symbol->string symbols
-  `(define-record-type name
- (,(symbol-append 'make- name) ,@fields)
- ,(symbol-append name '?)
- ,@(map (lambda (field)
-  `(,field ,(symbol-append name '- field)))
-fields)))
-
 (define (make-eq-hashtable)
   (make-hash-table))
 
diff --git a/languages/eclectus/guile/prelude.scm b/languages/eclectus/guile/prelude.scm
index b7b750f..24383ef 100644
--- a/languages/eclectus/guile/prelude.scm
+++ b/languages/eclectus/guile/prelude.scm
@@ -11,16 +11,6 @@
  (if (not condition)
  (begin body1 body ...)
 
-(define-macro (define-record name fields)
-  (define (symbol-append . symbols)
-(string->symbol (apply string-append (map symbol->string symbols
-  `(define-record-type name
- (,(symbol-append 'make- name) ,@fields)
- ,(symbol-append name '?)
- ,@(map (lambda (field)
-  `(,field ,(symbol-append name '- field)))
-fields)))
-
 (define (make-eq-hashtable)
   (make-hash-table))
 

Regards, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://rotty.uttx.net| GnuPG Key: http://rotty.uttx.net/gpg.asc
Fingerprint  | C38A 39C5 16D7 B69F 33A3  6993 22C8 27F7 35A9 92E7
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth

Parrot 0.6.1 "Bird of Paradise" Released

[jerry gay]

Aloha!

On behalf of the Parrot team, I'm proud to announce Parrot 0.6.1
"Bird of Paradise." Parrot (http://parrotcode.org/) is a virtual machine aimed
at running all dynamic languages.

Parrot 0.6.1 can be obtained via CPAN (soon), or follow the
download instructions at http://parrotcode.org/source.html.
For those who would like to develop on Parrot, or help develop
Parrot itself, we recommend using Subversion or SVK on the
source code repository to get the latest and best Parrot code.

Parrot 0.6.1 News:
- Specification
  + drafted pdd29_compiler_tools.pod
  + updated pdd28_character_sets.pod draft
  + updated pdd19_pir.pod draft
- Languages
  + c99: added independent C pre-processor
  + HQ9+: reimplemented with PCT
  + Lua:
. reimplementation with PCT, using PAST and POST
. behavior aligned wih 5.1.3
  + Rakudo:
. implemented basic I/O, including '$*IN', '$*OUT', '$*ERR', 'prefix:='
. implemented simple typing and runtime type checking
. added basic multi-method dispatch
. expanded named argument handling, including Pair and colonpairs
. added 'Whatever' and 'Capture' classes
. implemented 'handles' trait verb
. added 'loop' statement
. implemented 'given', 'when', 'for', 'while', 'until' statement modifiers
. implemented Hash methods '.keys' and '.values'
. fixed bug to get '.WHAT' working correctly
. initial implementation of 'eval'
- Compilers
  + NQP:
. created a bootstrapped build, see 'make boot'
. added 'infix:<', 'infix:<=', 'infix:>', 'infix:>=' relational operators
. added 'postfix:++', 'postfix:--' operators
  + PCT:
. added methods specifying default behaviors in PAST, reducing repeated code
. improved symbol table lookup
  + PGE:
. removed deprecated code including: P6Regex, P6Grammar, PAST-pm
- Miscellaneous
  + notable speedups during compilation and execution of parrot and HLLs
  + pdb (the parrot debugger) can now catch parrot exceptions
  + better detection of glibc and gettext during configuration
  + various bugfixes, code cleanups, deprecations, and coding standard fixes


Mahalo to all our contributors for making this possible, and our
sponsors for supporting this project.

Enjoy!
~jerry

Re: The Big Three Rakudo (and Parrot OO) Bottlenecks

[Leopold Toetsch]

Am Samstag, 12. April 2008 02:27 schrieb chromatic:
> I've committed a couple of minor optimizations which speed up Rakudo and
> Perl OO in general by about 35%.  There may be a few more lurking, but I
> keep running into three spots which dominate most of the other optimization
> strategies I might pursue.
>
> 1) The Garbage Collector is algorithmically inefficient.  There are various
> potential optimization strategies here which don't require us walking every
> allocated header in the system multiple times (yes, it's that bad in at
> least two places), 

Last time I looked at it, a header isn't "walked" if the live bit is already 
set. pobject_lives() will be called, yes, but that was a macro in very former 
times and cheap for the common case, when the live bit is already set.

> but the real solution I suspect is to replace the 
> current GC with at least the one specified in the new GC PDD.

Which pdd are you refering to? I don't see any substantial text in 
pdd09_gc.pod.

> The two worst spots are turning off the live flag (and destroying
> everything with a custom destroy flag) and dividing newly-allocated memory
> pools into headers and manually adding each header to a linked-list of free
> objects.

A bitmap handling for live flags was in the code base ~1.5 yrs ago. You could 
look at svn diffs near:

r14799 | leo | 2006-09-30 12:38:35 +0200 (Sa, 30 Sep 2006) | 4 lines
r14798 | leo | 2006-09-30 11:24:49 +0200 (Sa, 30 Sep 2006) | 6 lines

[GC] remove ARENA_DOD_FLAGS code

I've removed it, because I couldn't measure any remarkable performance 
improvements.

> Flag marking would be much cheaper (and likely cache-friendlier, though I
> haven't done the math to make sure of this) 

See above.

> The free object list is the reason that compacting/copying collectors are
> popular,

[ ... ]

Copying collectors need another indirection in PMC allocation, as a PMC isn't 
allowed to move - external C code might have stored a pointer to a PMC. Did 
this philosophy change somewhen?

Anyway, due to better cache locality and in combination with diffently sized 
PMCs a copying collector could be faster I'd estimate.

> With that all said, one good optimization is to allocate fewer PObjs

Indeed.

> -- c

leo

Re: parrot benchmarking

[Leopold Toetsch]

Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> Greetings all,
>
>  I just posted a little Parrot benchmark in my use.perl's journal

Just a reminder:

Please don't use unoptimzed builds for benchmarking. There are a lot of code 
asserts and other slowdowns due to compiler goodwill in devel code.

  $ make realclean; perl Configure.pl --optimize && make

should do it,

leo

Re: parrot benchmarking

[Geoffrey Broadwell]

On Wed, 2008-04-16 at 00:10 +0200, Leopold Toetsch wrote:
> Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> > Greetings all,
> >
> >  I just posted a little Parrot benchmark in my use.perl's journal
> 
> Just a reminder:
> 
> Please don't use unoptimzed builds for benchmarking. There are a lot of code 
> asserts and other slowdowns due to compiler goodwill in devel code.
> 
>   $ make realclean; perl Configure.pl --optimize && make
> 
> should do it,


It might be worth building two parrots by default -- one debug for
normal work, and one optimized for benchmarking; perhaps call the second
one 'parrot-opt' or 'parrot-fast' or something similarly descriptive?
Heck, we could even reverse the huffmanization, and call the benchmark
parrot 'parrot', and call the one we do core development with
'parrot-debug'.  Or equalize them, calling them 'parrot-debug' and
'parrot-opt', and symlink 'parrot' to 'parrot-opt'.

I'd even say to not only compile the benchmarking parrot with C compiler
optimizations on, but also set it to turn on the parrot optimization
flags (-O2 -Ot -Oc -Op -Oj etc.) by default -- whichever ones we would
generally recommend to a benchmarker (per platform).

Of course, then it would be nice to have 'make test-opt' to make sure
that the recommended C and parrot optimization flags actually result in
a working parrot.

I recommend all this mostly because of the number of benchmarkers who
persist in always using the default build, with the default (C and
parrot) optimization flags.  I've heard a lot of reasons for this
behavior, but to me the two most persuasive are:

  1.  Average users will likely use the default config and no flags.
  2.  It's hard to determine the "recommended" benchmark config/flags.

Building a "fast parrot" in addition to the existing debug parrot
addresses both of these concerns.  "Average users" will likely use
anything labeled "fast", especially if it's clear that the other option
is "debug".  And the recommended benchmarking config and flags will be
baked into parrot-fast, so there's no question about the appropriate way
to build and use parrot when benchmarking.

The one remaining problem is if the build gets slowed down too much for
normal development.  Several things may mitigate this:

  1. As I recall a decent amount of the build time is spent in
 the Perl scripts that preprocess and generate source files;
 this time would probably not need to be duplicated, only
 the actual C compile and link phases.

  2. PASM and PIR code executed during the build (building
 compilers based on PCT, for instance), or during testing,
 can be run with the fast parrot by default, and only with
 the slow parrot when needed.

  3. It might be useful to add a config option to turn *off*
 building the fast parrot, and just tell core Parrot
 developers to use that if the build times are too long.
 This config should also change the 'parrot' symlink to point
 to 'parrot-debug' of course 

Anyway, just a thought.


-'f

Re: The Big Three Rakudo (and Parrot OO) Bottlenecks

[Jonathan Worthington]

Hi,

chromatic wrote:
3) PCC argument processing is slow.  I've looked over Parrot_pass_args and 
Parrot_process_args several times in the past few months, and I didn't see 
any obvious speedups or tricks.  However, we do spend a lot of time shuffling data back and forth, and something (instinct, blind desire, lower blood sugar than normal) suggests that we already *know* some of this information already.  That is, at the point of a call we know if there are slurpy or named arguments and if the invoked function wants to bind slurpy or named parameters.  It seems like we could have a fast path for that common operation... somehow.
  
I thought that detecting when the signature on the caller and callee 
side were identical and fast-tracking that might help. I stuck in 
something to count how many times this happened. It was the case in 23% 
of calls while compiling Rakudo. So I did the optimisation in the 
attached patch, which basically just copies arguments from one set of 
registers to the other about as efficiently as I can see how to do it.


The end result? I can't actually detect enough of a difference to make 
me think I've really improved anything. Not in the compilation time of 
Rakudo's actions.pm, nor when I took a Perl 6 Ackerman's function 
implementation and ran it under Rakudo.


Jonathan
Index: src/inter_call.c
===
--- src/inter_call.c(revision 26955)
+++ src/inter_call.c(working copy)
@@ -1520,12 +1520,45 @@
 Parrot_init_arg_indexes_and_sig_pmc(interp, dest_ctx, dest_indexes,
 dest_signature, &st.dest);
 
-Parrot_process_args(interp, &st, param_or_result);
+if (st.src.u.op.signature == st.dest.u.op.signature && 
!PMC_IS_NULL(st.src.u.op.signature)) {
+/* Identical signatures, so we can fast-track it. */
+PMC *sig = st.src.u.op.signature;
+int sig_length = st.src.n;
+opcode_t *src_idxs = st.src.u.op.pc;
+opcode_t *dest_idxs = st.dest.u.op.pc;
+int i;
+for (i = 0; i < sig_length; i++) {
+const int constant = PARROT_ARG_CONSTANT_ISSET(SIG_ITEM(sig, i));
+int src_idx = src_idxs[i];
+int dest_idx = dest_idxs[i];
+switch (PARROT_ARG_TYPE_MASK_MASK(SIG_ITEM(sig, i))) {
+case PARROT_ARG_INTVAL:
+CTX_REG_INT(st.dest.ctx, dest_idx) = constant ?
+src_idx : CTX_REG_INT(st.src.ctx, src_idx);
+break;
+case PARROT_ARG_STRING:
+CTX_REG_STR(st.dest.ctx, dest_idx) = constant ?
+st.src.ctx->constants[src_idx]->u.string : 
CTX_REG_STR(st.src.ctx, src_idx);
+break;
+case PARROT_ARG_FLOATVAL:
+CTX_REG_NUM(st.dest.ctx, dest_idx) = constant ?
+st.src.ctx->constants[src_idx]->u.number : 
CTX_REG_NUM(st.src.ctx, src_idx);
+break;
+case PARROT_ARG_PMC:
+CTX_REG_PMC(st.dest.ctx, dest_idx) = constant ?
+st.src.ctx->constants[src_idx]->u.key : 
CTX_REG_PMC(st.src.ctx, src_idx);
+break;
+}
+}
+}
+else {
+Parrot_process_args(interp, &st, param_or_result);
 
-/* If we created a slurpy, we had to DOD register it so it did not get
- * collected during arg processing; we'll now unregister it. */
-if (st.dest.slurp)
-dod_unregister_pmc(interp, st.dest.slurp);
+/* If we created a slurpy, we had to DOD register it so it did not get
+ * collected during arg processing; we'll now unregister it. */
+if (st.dest.slurp)
+dod_unregister_pmc(interp, st.dest.slurp);
+}
 }
 
 

[perl #52916] [PATCH] Making NCI test C++ compatible

[Senaka Fernando]

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


Index: src/nci_test.c
===
--- src/nci_test.c  (revision 26966)
+++ src/nci_test.c  (working copy)
@@ -37,6 +37,12 @@
 #include 
 #include 
 
+#ifdef __cplusplus
+extern "C"
+{
+#endif
+
+
 /* Declarations of structs */
 
 typedef struct Nested {
@@ -1070,6 +1076,10 @@
 
 #endif
 
+#ifdef __cplusplus
+}
+#endif
+
 /*
 
 =back
Hi all,

The provided patch makes the NCI test C++ compatible.

Regards,
Senaka

Re: static types, checking, conversions

[Thom Boyer]

Mark J. Reed wrote:

It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)
  
Could you be a little more specific on where to find information on 
JavaScript's proposed system of type constraints?


The firefox.com developers page 
(http://developer.mozilla.org/en/docs/Main_Page) has several links on 
JavaScript topics. The most promising one leads to 
http://developer.mozilla.org/en/docs/JavaScript, and, while that page 
has info on quite a few different versions of JavaScript, version 2 is 
not one of them. Of course, I'm only guessing that JavaScript 2 is what 
you might have meant by Javascript:TNG. (I can't find any mention of TNG 
or "Next Generation" on either of those pages, either.)

=thom

[perl #52934] [PATCH] Eclectus: Support Chicken Scheme

[via RT]

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



The attached patch adds Chicken support to Eclectus, and changes the
test harness on Win32 to use Chicken instead of Petite Chez.

Chicken support

From: Andreas Rottmann <[EMAIL PROTECTED]>


---

 MANIFEST   |1 +
 languages/eclectus/chicken/prelude.scm |   34 
 languages/eclectus/t/harness   |3 ++-
 3 files changed, 37 insertions(+), 1 deletions(-)
 create mode 100644 languages/eclectus/chicken/prelude.scm


diff --git a/MANIFEST b/MANIFEST
index 77cc912..40a8b1c 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -1309,6 +1309,7 @@ languages/dotnet/tools/benchmark.pl [dotnet]
 languages/dotnet/tools/fail_analysis.pl [dotnet]
 languages/eclectus/MAINTAINER   [eclectus]
 languages/eclectus/README   [eclectus]
+languages/eclectus/chicken/prelude.scm  [eclectus]
 languages/eclectus/compiler.scm [eclectus]
 languages/eclectus/config/makefiles/root.in [eclectus]
 languages/eclectus/docs/eclectus.pod[eclectus]
diff --git a/languages/eclectus/chicken/prelude.scm b/languages/eclectus/chicken/prelude.scm
new file mode 100644
index 000..e6a915f
--- /dev/null
+++ b/languages/eclectus/chicken/prelude.scm
@@ -0,0 +1,34 @@
+(use srfi-9)
+(use srfi-1)
+
+(define-syntax unless
+  (syntax-rules ()
+((unless condition body1 body ...)
+ (if (not condition)
+ (begin body1 body ...)
+
+(define (make-eq-hashtable)
+  (make-hash-table eq?))
+
+(define (hashtable-ref tbl key default)
+  (hash-table-ref/default tbl key default))
+
+(define (hashtable-set! tbl key value)
+  (hash-table-set! tbl key value))
+
+(define (printf fmt . args)
+  (apply format #t fmt args))
+
+(define (fprintf port fmt . args)
+  (apply format port fmt args))
+
+(define (flush-output-port . port-opt)
+  (apply flush-output port-opt))
+
+(define open-output-file
+  (let ((chicken:open-output-file open-output-file))
+(lambda (filename mode)
+  (chicken:open-output-file filename
+
+(define (atom? x)
+  (not (pair? x)))
diff --git a/languages/eclectus/t/harness b/languages/eclectus/t/harness
index bb811fa..5b7eb8f 100644
--- a/languages/eclectus/t/harness
+++ b/languages/eclectus/t/harness
@@ -31,7 +31,8 @@ use lib qw( ../lib ../../lib ../../lib );
 use Parrot::Test::Harness
 language => 'eclectus',
 exec => ($^O eq 'MSWin32')
-  ? [ 'petite', '--script' ]
+  ? [ 'csi', '-R', 'riaxpander', '-i', '-k', 'none',
+		  '-e', '(load "chicken/prelude.scm")', '-s' ]
   : [ 'gosh', '-fcase-fold', '-I', '.',  '-l', 'gauche/prelude.scm' ],
 #exec => [ 'guile', '--debug', '-l', 'guile/prelude.scm', '-s' ],
 files=> [ 't/*.pl' ];

Regards, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://rotty.uttx.net| GnuPG Key: http://rotty.uttx.net/gpg.asc
Fingerprint  | C38A 39C5 16D7 B69F 33A3  6993 22C8 27F7 35A9 92E7
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

It's *GNU*/Linux dammit!

Re: The Big Three Rakudo (and Parrot OO) Bottlenecks

[Patrick R. Michaud]

On Wed, Apr 16, 2008 at 02:19:42AM +0200, Jonathan Worthington wrote:
> I thought that detecting when the signature on the caller and callee 
> side were identical and fast-tracking that might help. I stuck in 
> something to count how many times this happened. It was the case in 23% 
> of calls while compiling Rakudo. So I did the optimisation in the 
> attached patch, which basically just copies arguments from one set of 
> registers to the other about as efficiently as I can see how to do it.
> 
> The end result? I can't actually detect enough of a difference to make 
> me think I've really improved anything. Not in the compilation time of 
> Rakudo's actions.pm, nor when I took a Perl 6 Ackerman's function 
> implementation and ran it under Rakudo.

FWIW, all of the regexes compiled by PGE end up with slurpy hashes
in their parameter list, so (IIUC from the earlier IRC discussion)
they aren't seeing any benefit from this optimization.

A similar situation applies for the methods in PCT -- most of them
also have slurpy hash parameters.  This is in order to be compatible
with Perl 6's default *%_ parameter in methods.

Pm

[perl #52932] [PATCH] Eclectus: Use SRFI-9 records

[via RT]

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



Use SRFI-9 records instead of DEFINE-RECORD.



-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://rotty.uttx.net| GnuPG Key: http://rotty.uttx.net/gpg.asc
Fingerprint  | C38A 39C5 16D7 B69F 33A3  6993 22C8 27F7 35A9 92E7
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

It's *GNU*/Linux dammit!

Re: The Big Three Rakudo (and Parrot OO) Bottlenecks

[chromatic]

On Tuesday 15 April 2008 17:19:42 Jonathan Worthington wrote:

> I thought that detecting when the signature on the caller and callee
> side were identical and fast-tracking that might help. I stuck in
> something to count how many times this happened. It was the case in 23%
> of calls while compiling Rakudo. So I did the optimisation in the
> attached patch, which basically just copies arguments from one set of
> registers to the other about as efficiently as I can see how to do it.
>
> The end result? I can't actually detect enough of a difference to make
> me think I've really improved anything. Not in the compilation time of
> Rakudo's actions.pm, nor when I took a Perl 6 Ackerman's function
> implementation and ran it under Rakudo.

It helps the PIR Ackerman benchmark by 4.67%.  parrot_pass_args gets more 
expensive, but next_arg_sig and everything else except for 
Parrot_init_arg_indexes_and_sig_pmc gets called much, much less.  I played 
with the patch a little bit, but didn't get it much faster.

It may be possible to avoid the Parrot_init_arg_indexes_and_sig_pmc calls, but 
I couldn't immediately see how.

-- c

Re: [svn:parrot] r26998 - in trunk: . config/auto t/steps

[chromatic]

On Tuesday 15 April 2008 19:40:48 [EMAIL PROTECTED] wrote:

> Added:
>trunk/t/steps/auto_macports-08.t
>   - copied, changed from r26997, /trunk/t/steps/auto_macports-07.t
> Modified:
>trunk/MANIFEST
>trunk/config/auto/macports.pm
>
> Log:
> Fix bug in auto::macports identified at Perl Seminar NY build fest by Jim
> Anderson:  case where there is no /opt/local/ directory yet.  Add 3
> additional test files to exercise this case.

We need *three* test files to exercise a *single* case?  There are 215 test 
files in t/steps/ and 72 test files in t/configure/.  How much duplication 
are we carrying around in all of these files?

Here's the functional diff between t/steps/auto_macports-06.t and 
t/steps/auto_macports-07.t:

--- t/steps/auto_macports-06.t  2008-04-15 19:46:25.0 -0700
+++ t/steps/auto_macports-07.t  2008-04-15 19:46:25.0 -0700
@@ -11,7 +11,6 @@
 use Carp;
 use lib qw( lib t/configure/testlib );
 use_ok('config::init::defaults');
-$ENV{TEST_MACPORTS} = 'foobar';
 use_ok('config::auto::macports');
 
 use Parrot::Configure;
@@ -40,7 +39,8 @@
 isa_ok($step, $step_name);
 ok($step->description(), "$step_name has description");
 
-# mock no Macports-default directories
+# mock no Macports root directory
+$step->{ports_root} = undef;
 ok($step->runstep($conf), "runstep() returned true value");
 is($step->result(), 'no', "Got expected result");

Here's the functional diff between t/steps/auto_macports-07.t and 
t/steps/auto_macports-08.t:

--- t/steps/auto_macports-07.t  2008-04-15 19:46:25.0 -0700
+++ t/steps/auto_macports-08.t  2008-04-15 19:46:25.0 -0700
@@ -1,13 +1,13 @@
 #! perl
 # Copyright (C) 2007, The Perl Foundation.
-# $Id: /mirror/trunk/t/steps/auto_macports-07.t 27004 
2008-04-16T02:32:04.905804Z jkeenan  $
-# auto_macports-07.t
+# $Id: /mirror/trunk/t/steps/auto_macports-08.t 27005 
2008-04-16T02:40:47.421967Z jkeenan  $
+# auto_macports-08.t
 
 use strict;
 use warnings;
 use Test::More;
 plan( skip_all => 'Macports is Darwin only' ) unless $^O =~ /darwin/;
-plan( tests => 12 );
+plan( tests => 13 );
 use Carp;
 use lib qw( lib t/configure/testlib );
 use_ok('config::init::defaults');
@@ -16,9 +16,10 @@
 use Parrot::Configure;
 use Parrot::Configure::Options qw( process_options );
 use Parrot::Configure::Test qw( test_step_thru_runstep);
+use IO::CaptureOutput qw( capture );
 
 my $args = process_options( {
-argv=> [],
+argv=> [ q{--verbose} ],
 mode=> q{configure},
 } );
 
@@ -41,8 +42,17 @@
 
 # mock no Macports root directory
 $step->{ports_root} = undef;
-ok($step->runstep($conf), "runstep() returned true value");
-is($step->result(), 'no', "Got expected result");
+{
+my ($stdout, $stderr);
+my $ret = capture sub { $step->runstep($conf) }, \$stdout, \$stderr;
+ok($ret, "runstep() returned true value");
+is($step->result(), 'no', "Got expected result");
+like(
+$stdout,
+qr/^Could not locate Macports root directory/,
+"Got expected verbose output"
+);
+}

Effectively speaking, 07 and 08 each contain only *one* interesting test.  The 
rest is repetition.

These three files should be a single test file.  I suspect the same is true of 
many of the other 287 test files in t/steps and t/config.

-- c

What does this mean in S03?

[John M. Dlugosz]

"Strings, arrays, lists, sequences, captures, and tree nodes can all be pattern 
matched by regexes or by signatures more or less interchangably."


How can captures me matched by regexes?  Does this mean that there is really an 
isomorphism between Signatures and Regexes?