[perl #39776] [BUG] PGE core dump

[via RT]

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


---
osname= darwin
osvers= 8.0
arch=   darwin-thread-multi-2level
cc= cc
---
Flags:
category=core
severity=critical
ack=no
---
Original stack trace

../../parrot ../../compilers/pge/pgc.pir 
--output=lib/pruby_grammar_gen.pir lib/pruby.pg
Method 'reduce' not found
current instr.: 'parrot;PGE::Exp::Quant;reduce' pc 4358 
(compilers/pge/PGE/Exp.pir:402)
called from Sub 'parrot;PGE::Exp::Alt;reduce' pc 5056 
(compilers/pge/PGE/Exp.pir:818)
called from Sub 'parrot;PGE::Exp::Group;reduce' pc 4624 
(compilers/pge/PGE/Exp.pir:571)
called from Sub 'parrot;PGE::Exp::Quant;reduce' pc 4358 
(compilers/pge/PGE/Exp.pir:402)
called from Sub 'parrot;PGE::Exp::Concat;reduce' pc 4098 
(compilers/pge/PGE/Exp.pir:316)
called from Sub 'parrot;PGE::Exp;root_pir' pc 3609 
(compilers/pge/PGE/Exp.pir:69)
called from Sub 'parrot;PGE::P6Regex;compile_p6regex' pc 6254 
(compilers/pge/PGE/P6Regex.pir:128)
called from Sub 'parrot;PGE::P6Grammar;regex_stmt' pc 622 
(../../compilers/pge/pgc.pir:336)
called from Sub 'parrot;PGE::P6Grammar;compile_p6grammar' pc 345 
(../../compilers/pge/pgc.pir:225)
called from Sub 'parrot;PGE::P6Grammar;main' pc 135 
(../../compilers/pge/pgc.pir:111)



Stack trace after adding debug statements
The first VAR1 dump is self
the second VAR1 dump is exp0
pruby.pg is available at http://tewk.com/pruby.pg

henrys:~/srcs/parrot/languages/pruby tewk$ vi 
../../compilers/pge/PGE/Exp.pir
henrys:~/srcs/parrot/languages/pruby tewk$ ../../parrot 
../../compilers/pge/pgc.pir --output=lib/pruby_grammar_gen.pir lib/pruby.pg
"VAR1" => PMC 'PGE::Exp::Quant' => "+" @ 19537 {
 => 1
 => 2147483647
 => "postfix:+"
 => 3
[0] => undef
}
"VAR1" => undef
71 - Undef
Method 'reduce' not found
current instr.: 'parrot;PGE::Exp::Quant;reduce' pc 4397 
(compilers/pge/PGE/Exp.pir:414)
called from Sub 'parrot;PGE::Exp::Alt;reduce' pc 5095 
(compilers/pge/PGE/Exp.pir:830)
called from Sub 'parrot;PGE::Exp::Group;reduce' pc 4663 
(compilers/pge/PGE/Exp.pir:583)
called from Sub 'parrot;PGE::Exp::Quant;reduce' pc 4397 
(compilers/pge/PGE/Exp.pir:414)
called from Sub 'parrot;PGE::Exp::Concat;reduce' pc 4098 
(compilers/pge/PGE/Exp.pir:316)
called from Sub 'parrot;PGE::Exp;root_pir' pc 3609 
(compilers/pge/PGE/Exp.pir:69)
called from Sub 'parrot;PGE::P6Regex;compile_p6regex' pc 6293 
(compilers/pge/PGE/P6Regex.pir:128)
called from Sub 'parrot;PGE::P6Grammar;regex_stmt' pc 622 
(../../compilers/pge/pgc.pir:336)
called from Sub 'parrot;PGE::P6Grammar;compile_p6grammar' pc 345 
(../../compilers/pge/pgc.pir:225)
called from Sub 'parrot;PGE::P6Grammar;main' pc 135 
(../../compilers/pge/pgc.pir:111)


---
Summary of my parrot 0.4.5 (r13225) configuration:
  configdate='Sun Jul  9 19:13:58 2006'
  Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=ppc-darwin,
jitosname=DARWIN, jitcpuarch=ppc
execcapable=1
perl=perl
  Compiler:
cc='cc', ccflags='-g -pipe -fno-common -no-cpp-precomp  
-I/usr/local/include -pipe -fno-common -Wno-long-double  -I/sw/include 
-I/sw/include',
  Linker and Libraries:
ld='c++', ldflags='-L/usr/local/lib -flat_namespace  -L/sw/lib 
-L/sw/lib',
cc_ldflags='',
libs='-lm -lgmp -lreadline'
  Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress',
load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=4321,
nv=double, numvalsize=8, doublesize=8

---
Environment:
DYLD_LIBRARY_PATHHOMELANGLANGUAGELD_LIBRARY_PATH
LOGDIRPATHPERL5LIBSHELL

Re: TAP Namespace Nonproliferation Treaty

[Nik Clayton]

Ovid wrote:

- Original Message 

From: Nik Clayton <[EMAIL PROTECTED]>



Ovid wrote:

I'm perfectly comfortable with this idea, but what I'm trying to figure

 > > out then, is the namespace for my parser.  It's a TAP parser, after all.
 > > Any suggestions?  I see that Adam has suggested a TAPx:: namespace,
 > > but there could still be competing TAPx::Parser modules. Don't know if
 > > that would bug folks, though.


TAPxParser


Thought about that, but immediately discarded it.  TAPx::OVID::Parser 

> doesn't say anything about the parser other than authorship and the
> latter is verified by glancing at the docs.  My jumping on the
> TAPx::Parser namespace is almost as bad as my taking TAP::Parser, so
> I'm just trying to figure out how to truly distinguish my (currently
> parser from others.  I suspect it will be as arbitrary as your idea, 
though :)


The problem with that is that we risk ending up with a proliferation of 
modules with odd names just to avoid namespace clashes.  See all the 
modules on CPAN with ::Simple or ::Lite suffixes, or the Email::/Mail:: 
split.  And then there's Schwern's original example, CGI.pm.


At least CPAN IDs are globally distinct.  Two authors that want to write 
a simpler parser can't clash over who gets to own TAP::Parser::Simple 
this way.


It may be unwieldy, but this is something that Java managed to solve 
with 'reverse domain' syntax for class hierarchies.


N

Parrot Bug Summary

[Parrot Bug Summary]

Parrot Bug Summary

http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Jul 10 13:15:01 2006 GMT
---

  * Numbers
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Numbers

Ticket Counts: 60 new + 242 open = 302
Created this week: 38
Closed this week: 19

---

New Issues

New issues that have not been responded to yet

1 - 2 weeks old
39685  [CAGE] warning: no previous prototype
39648  PGE - bad variable name
2 - 3 weeks old
3 - 4 weeks old
39430  Method cache not always invalidated
4 - 5 weeks old
39329  Check to make sure PMC_str_val, etc. are used appropriately
5 - 6 weeks old
6 - 7 weeks old
39197  lib/Parrot/Test.pm ignores core dumps failures!
7 - 8 weeks old
8 - 9 weeks old
9 - 10 weeks old
39051  Test failure in t/pmc/objects_62.pasm (attributes)
10 - 11 weeks old
39018  t/pmc/complex failures on Solaris 8/SPARC
38969  [CAGE] parrot source does not conform to standards
11 - 12 weeks old
12 - 13 weeks old
13 - 14 weeks old
38887  Result of INFINITY or NAN stringification is platform dependent
14 - 15 weeks old
38823  [BUG] solaris 10 w gcc
15 - 16 weeks old
16 - 17 weeks old
38764  Test results of parrot on Freebsd
17 - 18 weeks old
18 - 19 weeks old
19 - 20 weeks old
20 - 21 weeks old
---

Overview of Open Issues

Platform   Severity   Tag  Lang
aix   0abandoned 05005threads   0  Amber0
All   2fatal 7bounce0  BASIC0
bsdos 0High  1Bug  19  bc   0
cygwin0low   1compiler  0  befunge  0
cygwin_nt 0medium0configure 0  bf   0
darwin0none  0core  0  cola 0
dec_osf   0Normal1dailybuild0  forth0
dgux  0unknown   0docs  0  jako 0
dos   0Wishlist  3duplicate 0  Lisp 0
dynixptx  0  install   1  m4   0
freebsd   0   library   0  ook  0
generic   0   notabug   0  perl60
gnu   0   notok 0  plot 0
HPUX  0   ok0  punie1
irix  0   Patch10  python   0
irix640   regex 0  ruby 0
Linux 0   sendToCPAN0  scheme   0
lynxos0   Todo184  tcl 30
mac   0   unknown   0  urm  0
machten   0   utilities 0  Zcode0
macos 0   wontfix   0
MacOS X   0
mswin32   0
netbsd0
next  0
openbsd   1
os2   0
os390 0
other 0
powerux   0
qnx   0
riscos0
sco   0
Solaris   0
sunos 0
svr4  0
svr5  0
sysv  0
unicos0
unicosmk  0
unix  0
unknown   0
uts   0
vms   0
VOS   0
Win32 3
---

Ticket Status By Version

New or OpenResolved

---

Requestors with most open tickets

[EMAIL PROTECTED]  49
Will Coleda 49
jerry gay   38
Joshua Hoblitt  30
Leopold Toetsch 28
Matt Diephouse  19
Andy Dougherty   8
Chip Salzenberg  8
Jarkko Hietaniemi7
Simon Glover 6

---

  * Total Issues
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---
This page is CPU intensive to create, it will be updated only once every 5
minutes

Re: Building a Fedora package

[Steven Pritchard]

On Sun, Jul 09, 2006 at 01:16:47AM -1000, Joshua Hoblitt wrote:
> When you say, "On x86_64" I think what your really mean is a "x86_64
> system with multilib support".

Right.

> You are correct that the current build system does not support
> multilib builds or installs (or at least it didn't the last time I
> looked at it several months ago).

Which is fine, if I could just override "lib".  It sort of works
now...  The libraries get installed in /usr/lib64, but /usr/lib/parrot
is also created, which wouldn't be a big deal if it was
arch-independent stuff (although then technically it should be
/usr/share/parrot), but /usr/lib/parrot/dynext has arch-dependent
files...

> While I don't have a recent Fedora build to look at I'd bet that
> /usr/lib64 on your system is actually a link to /usr/lib while
> /usr/lib32 is a separate directory.  So there shouldn't be any issue
> with installing under /usr/lib.  Is this the case?

No.  i386 packages have exclusive use of lib.  All x86_64 packages
install in lib64.

In an ideal world, the layout that would be best for a multilib Linux
system would probably be something like this:

  /usr/lib64/libparrot.*
  /usr/lib64/pkgconfig/
  /usr/lib64/parrot/dynext/
  /usr/share/parrot/include/
  /usr/share/parrot/library/
  /usr/include/parrot/
  /usr/bin/*

What I have now is this:

  /usr/lib64/libparrot.*
  /usr/lib64/pkgconfig/
  /usr/lib/parrot/dynext/
  /usr/lib/parrot/include/
  /usr/lib/parrot/library/
  /usr/include/parrot/
  /usr/bin/*

That's after overriding lib_dir...

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: [EMAIL PROTECTED] http://www.kspei.com/
Phone: (618)398-3000   Mobile: (618)567-7320

Re: making v6 test suite its own distro

[Gaal Yahas]

On Sat, Jul 08, 2006 at 12:47:17AM -0700, Darren Duncan wrote:
> As briefly discussed on #perl6 ...

As briefly replied there before being jethandled...

> I propose that we make like Sun and its Java VM validation suite,
> and start distributing the Perl 6 test suite as its own distribution
> on CPAN

Here are a number of issues.

1. Naming

> Audrey suggested that it could be named v6::tests ... I previously to 
> that suggested Perl6::Certification ... and other suggestions are 
> welcome.

Please let's not call it certification. That gives foreground to a
question of authority which I think is (certainly at this stage,
possibly later too) a needless distraction.

2. Modularity

> From that point onward, neither the Perl6::Pugs nor v6 distros would 
> include their own test suites, or such would be extremely basic. 
> Their 'make test' and 'make smoke' would instead call out to 
> v6::tests.
> 
> (A substantial part of the testing and/or smoking harness should 
> probably also be included, so people that use it get more consistent 
> formatted results that can be compared, though some details will need 
> to be in the individual implementation distros, as only they know how 
> they are invoked.  Whether that is written in Perl 6 or Perl 5 or 
> something else is less of an issue short term.)

The Pugs test system has grown organically and has functionality at the
following levels, most of which currently reside in the Pugs repo:

A) A Perl 6 Test.pm that borrows heavily from Perl 5 TAP goodies: ok, is,
   like, cmp_ok, isa_ok, is_deeply, dies_ok, skip, and related functions;
   as well as conventions for extra TAP info supplying message coordinates
   and skip/todo reasons, used in reports [ext/Test/ in the Pugs repo].

B) A Perl 5 Straps harness that keeps more metadata around for machine
   processing than Test::Harness' default "make smoke", and which
   has the extra bonus of working faster on SMP machines [originally
   util/yaml_harness.pl in the Pugs repo, which has since been refactored
   to mostly be a pugs-specific front-end to Test::TAP::Model on CPAN].

C) Local report generators: a colorful TAP results generator
   [Tetst::TAP::HTMLMatrix on CPAN and a frontend in util/testgraph.pl]
   and a FIT-and-Project-Xanadu inspired cross-referencer into arbitrary
   locations in the spec and the tests [util/catalog-tests.pl].

D) A smoke server system for transmitting and viewing other smoker's
   reports [code in util/smokeserv/ ; service maintained by Ingo
   Blechschmidt].

E) Scripts and cron jobs on feather to autosmoke pugs every revision and
   submit results [currently maintained by Juerd, I believe].

(The slides at http://perlcabal.org/~gaal/pugstest/start.html demonstrate
most of these features.)


The first obvious question that this enumeration presents is: where to
cut? Does every implementation use its own Test.pm? Pugs was able to
start using one after 23 days, but that was a simpler module then than
it is today, and a fresh implementation may find it hard to get started
if its first objective is to implement so much Perl 6 simultaneously.

Perhaps we need a baby-Perl Test::Simple for new implementations, and
by convention have 01-sanity use only those functions present there. The
drawback being somewhat duplicated effort and another distribution worry.


The other question that comes to mind is how to manage SKIP and TODO
tests for release mangement. Currently Pugs, assuming globality, simply
plunges into every t/ file before a release and marks forsaken (for this
release) tests TODO, and commits. But surely different implementations
have their different bugs. In the case of TODO we can fix that easily:
we already have a mechanism for force_todoing tests "at a distance",
though currently that distance is at the head of the test file (but it's
a simple matter to make that a distro-level file). The deeper technical
challenge is how to maintain SKIPs, which after all, are often used
before hanging tests. skip_all we can manage; skip we cannot, until at
least when we have a powerful debugger.


3. Generality

> On a separate but related matter, I suggest also separating anything 
> else that isn't Pugs specific, that is common to both it and v6, from 
> the Pugs distro and distributing those separately.  This includes the 
> contents of: examples/ , ext/, some of docs/, some of util/, and so 
> on.
> 
> These various distros can be distributed on their own schedule, as 
> frequent or infrequent as makes sense, just as v6 and Moose et al are.
> 
> As to whether any of the above are still maintained within Pugs SVN 
> or moved to separate SVN, that is a possibly orthogonal matter.

As a Pugs hacker I can say that the immediacy of access to t/ is a
great benefit, and I would hate to lose that. But what's the best way
of granting that benefit to other implementations without crippling it
for anyone?


And a different tack on all of this: at YAPC I heard from Jesse Vincent
that work has bee

Re: [ANNOUNCE] Pugs 6.2.12 and v6.pm released! (reformatted)

[Michael Goldshteyn]

"Audrey Tang" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Unfortunatelly, those of us who use Perl under Windows / MSVC Compiler 
cannot use v6.pm, due to the fact that it has an indirect dependency on 
Devel::Caller which fails to work using that compiler combination (i.e., 
fails all tests after a build using its makefile and Visual Studio 2003 as 
the C compiler).

Mike

TAP diagnostic syntax proposal

[Michael G Schwern]

The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time
talking about TAP) sketched out a syntax for parsable TAP diagnostics.

  not ok 2 - omg t3h sooper test!!1!
  file:foo.t
  line:45
  description: omg t3h sooper test!!1!
  got: this
  expected:that
  raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
  x-THAC0: 16

Details on the wiki.

http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax

Re: TAP diagnostic syntax proposal

[Ovid]

- Original Message 
From: Michael G Schwern <[EMAIL PROTECTED]>

> The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time
> talking about TAP) sketched out a syntax for parsable TAP diagnostics.
>
>   not ok 2 - omg t3h sooper test!!1!
>   file:foo.t
>   line:45
>   description: omg t3h sooper test!!1!
>   got: this
>   expected:that
>   raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
>x-THAC0: 16

That syntax seems fine and easy to parse.  I have some questions, though.  

1.  I assume that "expected" and "got" must always appear together?
2.  If the diagnostic is present, what's required and what's optional?
3.  I'll wait on asking questions about the subset of YAML until more ideas are 
tossed about.

(by the way, is "not ok" and a skip directive illegal?  I assume so and it 
should be marked as a parse failure)

Cheers,
Ovid

-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: TAP diagnostic syntax proposal

[Michael G Schwern]

On 7/10/06, Ian Langworth <[EMAIL PROTECTED]> wrote:

These diagnostic keywords seem to blend too much into the rest of TAP.


Look at it in a fixed-with font, if you're not already, and it might
stand out better.

Also consider that with the next gen TAP parsers, "enhanced" TAP
displays should be easier.  ie. Reading the raw TAP but with color,
emphesis, etc...



Consider:

  not ok 2 - omg t3h sooper test!!1!
  ! file:foo.t
  ! line:45
  ! description: omg t3h sooper test!!1!
  ! got: this
  ! expected:that
  ! raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
  ! x-THAC0: 16

...or some other delimiter.


I do like this idea because it makes it clearer what is and what is
not a diagnostic line, for parsing purposes, rather than "whatever
happens to parse as YAML".



Or maybe we say that any inline YAML is interpreted as a comment data
structure


*head scratch*  But if it has parsable structure its not a comment...



 instead of a giant comment string, which can be used for
diagnostics:

  not ok 2 - omg t3h sooper test!!1!
  --- TAP diagnostics
  file:foo.t
  line:45
  description: omg t3h sooper test!!1!
  got: this
  expected:that
  raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
  x-THAC0: 16


The "-- TAP" doesn't do much for me visually.  I guess I see where
you're going, making the YAML bits explicit for the parser, but where
do we stop parsing?

Re: TAP diagnostic syntax proposal

[Pete Krawczyk]

Subject: TAP diagnostic syntax proposal
From: Michael G Schwern <[EMAIL PROTECTED]>
Date: Mon, 10 Jul 2006 10:19:03 -0700

}The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time
}talking about TAP) sketched out a syntax for parsable TAP diagnostics.
}
}   not ok 2 - omg t3h sooper test!!1!
}   file:foo.t
}   line:45
}   description: omg t3h sooper test!!1!
}   got: this
}   expected:that
}   raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
}   x-THAC0: 16

I would be concerned about "got" or "expected" including embedded 
newlines, such as:

  is($mech->content,$expected_page,"Web page content matches what's expected");

even with a delimiter such as Ian suggested.  How would this handle that?

Also, would the raw test be pre-expanded?  That is, what would raw-test 
show for this?

  is($user,"testuser$id","Test user name correctly generated");

-Pete K
-- 
Pete Krawczyk
  perl at bsod dot net

Re: TAP diagnostic syntax proposal

[Ian Langworth]

These diagnostic keywords seem to blend too much into the rest of TAP. Consider:

 not ok 2 - omg t3h sooper test!!1!
 ! file:foo.t
 ! line:45
 ! description: omg t3h sooper test!!1!
 ! got: this
 ! expected:that
 ! raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
 ! x-THAC0: 16

...or some other delimiter.

Or maybe we say that any inline YAML is interpreted as a comment data
structure instead of a giant comment string, which can be used for
diagnostics:

 not ok 2 - omg t3h sooper test!!1!
 --- TAP diagnostics
 file:foo.t
 line:45
 description: omg t3h sooper test!!1!
 got: this
 expected:that
 raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
 x-THAC0: 16
 ...

On 7/10/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:

The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time
talking about TAP) sketched out a syntax for parsable TAP diagnostics.

   not ok 2 - omg t3h sooper test!!1!
   file:foo.t
   line:45
   description: omg t3h sooper test!!1!
   got: this
   expected:that
   raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
   x-THAC0: 16

Details on the wiki.

http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax




--
Ian Langworth

Re: TAP diagnostic syntax proposal

[Michael G Schwern]

On 7/10/06, Pete Krawczyk <[EMAIL PROTECTED]> wrote:

I would be concerned about "got" or "expected" including embedded
newlines, such as:

  is($mech->content,$expected_page,"Web page content matches what's expected");

even with a delimiter such as Ian suggested.  How would this handle that?


YAML has ways to deal with newlines in values, but it does press for
some sort of "this line is part of the failure diagnostics" indicator
as Ian suggests.



Also, would the raw test be pre-expanded?  That is, what would raw-test
show for this?

  is($user,"testuser$id","Test user name correctly generated");


Ideally it would show exactly that.  The idea is to show the literal
source line (or lines) which generated the test, if possible, so the
reader can have a better idea what happened beyond what the normal
got/expected diagnostics show.  To show them with interpolated strings
would require somehow reconstructing the syntax of the function call
from inside the function.  This loses information.

Besides, they already have the expanded thing which went in.
got/expected shows that.

Re: I'm pre-hackathoning at OSCON, not post-hackathoning

[Patrick R. Michaud]

On Fri, Jul 07, 2006 at 01:36:06PM -0700, Chip Salzenberg wrote:
> I'm unable to hang around Portland after Friday afternoon, I'm sorry to
> report, so Saturday hackathoning will miss me.  However, I will be arriving
> a day _early_ so I'll be in Portland all day Sunday.  I understood Patrick
> to be in a similar situation, so he might be there Sunday too.

Yes, I'm now targeting any hackathoning in Portland to occur on 
the Sunday before OSCON instead of the Saturday after.

Pm

Re: I'm pre-hackathoning at OSCON, not post-hackathoning

[jerry gay]

On 7/10/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:

On Fri, Jul 07, 2006 at 01:36:06PM -0700, Chip Salzenberg wrote:
> I'm unable to hang around Portland after Friday afternoon, I'm sorry to
> report, so Saturday hackathoning will miss me.  However, I will be arriving
> a day _early_ so I'll be in Portland all day Sunday.  I understood Patrick
> to be in a similar situation, so he might be there Sunday too.

Yes, I'm now targeting any hackathoning in Portland to occur on
the Sunday before OSCON instead of the Saturday after.


to be clear, the new parrot-porters portland hackathon date is sunday 23 july.
i've adjusted my schedule to ensure i'll be there for the fun, too.
~jerry

Re: TAP diagnostic syntax proposal

[chromatic]

On Monday 10 July 2006 10:19, Michael G Schwern wrote:

>got: this
>expected:that

"got" still sucks.  Is there any chance to change it to "received"?

-- c

Re: TAP diagnostic syntax proposal

[Ovid]

- Original Message 
From: chromatic <[EMAIL PROTECTED]>


> On Monday 10 July 2006 10:19, Michael G Schwern wrote:
>
> >got: this
> >expected:that
>
> "got" still sucks.  Is there any chance to change it to "received"?

I like "pitched" and "caught".

  ... silence ...

*cough*

Cheers,
Ovid (for Larry's sake, no I'm not serious!)

-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Ruby on Parrot

[Patrick R. Michaud]

On Fri, Jul 07, 2006 at 10:07:57AM -0600, Kevin Tew wrote:
> I based the initial PGE grammar for PRuby off of  
> svn://rubyforge.org/var/svn/rubygrammar/grammars/antlr-v3/trunk/ruby.g 
> which is in complete.
> I'm looking for a BNF style description of the Ruby grammar.  Otherwise 
> I will have to dig into :pserver:[EMAIL PROTECTED]:/src/parse.y.

I'll be glad to provide any help that I can in building a PGE
version of the grammar -- just let me know where I can help.

Pm

Re: TAP diagnostic syntax proposal

[David Wheeler]

On Jul 10, 2006, at 11:34, chromatic wrote:


"got" still sucks.  Is there any chance to change it to "received"?


It's not a gift package delivered by FedEx. What sucks about "got"?

Best,

David

Re: TAP diagnostic syntax proposal

[Jonathan T. Rockway]

 not ok 2 - omg t3h sooper test!!1!
 --- TAP diagnostics
 file:foo.t



Why aren't we commenting the YAML block so that it's compatible with 
current TAP parsers?  I'm thinking something like this:


not ok 2 - ensure that foo is equal to bar
# --- !!tap/diagnostics
# file: foo.t
# line: 42
# got:
#  - !!perl/foobar
#  key: value
# expected:
#  - !!perl/foobar
# key: ~
# etc: (and so on)

The commented section is raw YAML goodness, AND this format is 
compatible with current TAP parsers.  I'm liking this a lot, especially 
since I can use it Right Now (tm) by doing diag(Dump($data)).


Any reason this shouldn't be the standard? It's easy to parse, it's easy 
to read.


Would it be acecptable if I patched Test::More to start outputing it's 
expected/got messages in YAML instead of a plain text format?


Regards,
Jonathan Rockway

Re: TAP diagnostic syntax proposal

[chromatic]

On Monday 10 July 2006 11:41, David Wheeler wrote:

> It's not a gift package delivered by FedEx. What sucks about "got"?

It's the grammatical equivalent of tucking your shirt tail into your underwear 
before trying to get a date at your family reunion.

-- c

Re: TAP diagnostic syntax proposal

[David Wheeler]

On Jul 10, 2006, at 11:59, chromatic wrote:

It's the grammatical equivalent of tucking your shirt tail into  
your underwear

before trying to get a date at your family reunion.


That's the best place to *get* a date!

D

Re: [perl #39776] [BUG] PGE core dump

[Patrick R. Michaud]

On Sun, Jul 09, 2006 at 07:15:07PM -0700, Kevin Tew wrote:
> ../../parrot ../../compilers/pge/pgc.pir 
> --output=lib/pruby_grammar_gen.pir lib/pruby.pg
> Method 'reduce' not found
> current instr.: 'parrot;PGE::Exp::Quant;reduce' pc 4358 
> (compilers/pge/PGE/Exp.pir:402)
> ...
> pruby.pg is available at http://tewk.com/pruby.pg

This is probably due to a syntax error in the pruby.pg grammar 
itself.  In particular, the line

token EXPONENT { ( e | E ) ( + | - )?  }

should probably read

token EXPONENT { ( e | E ) ( \+ | - )?  }

After making this change on my system the grammar appears to
compile correctly.

I totally agree that PGE probably needs to provide better syntax
error checking in situations such as this, thus I'm leaving this
ticket open, or will add a new more descriptive one soon.

Also, FWIW, I think that the grammar will read much more cleanly
if the "PRubyGrammar::" qualifiers are taken out of the rules --
they aren't needed if the initial match call is coded correctly.
(Punie uses these in its grammar, and isn't a good model in this
respect.)

For example, I would write the above EXPONENT token as:

token EXPONENT { ( e | E ) ( \+ | - )?  }

or perhaps better is:

token EXPONENT { <[eE]> <[+\-]>?  }

Thanks,

Pm

Re: TAP diagnostic syntax proposal

[Jonathan T. Rockway]

I agree that "got" is generally a good word to avoid in formal writing, 
but in a testing protocol I think that it's an acceptable abbreviation 
for "the actual result".  Especially since "received" doesn't quite 
convey the right meaning here.  Maybe "expected data" and "actual data" 
(or "expected" and "actually") are better?  Or maybe "got" is fine; HTTP 
still works even though "Referer" is misspelled.


Has got/expected ever caused any confusion to anyone (including 
non-speakers of English)?  If so, why?



It's not a gift package delivered by FedEx. What sucks about "got"?
   



It's the grammatical equivalent of tucking your shirt tail into your underwear 
before trying to get a date at your family reunion.


-- c
 

Re: [ANNOUNCE] Pugs 6.2.12 and v6.pm released! (reformatted)

[Jonathan Scott Duff]

On Mon, Jul 10, 2006 at 09:37:24AM -0500, Michael Goldshteyn wrote:
> "Audrey Tang" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> 
> Unfortunatelly, those of us who use Perl under Windows / MSVC Compiler 
> cannot use v6.pm, due to the fact that it has an indirect dependency on 
> Devel::Caller which fails to work using that compiler combination (i.e., 
> fails all tests after a build using its makefile and Visual Studio 2003 as 
> the C compiler).

Bummer. You could check out the Vanilla/Strawberry Perl effort at
http://win32.perl.org/

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: TAP diagnostic syntax proposal

[Andy Lester]

On Jul 10, 2006, at 2:04 PM, David Wheeler wrote:

It's the grammatical equivalent of tucking your shirt tail into  
your underwear

before trying to get a date at your family reunion.


That's the best place to *get* a date!


Actually, weddings are.  There's always someone(s) also w/o a date  
who is looking to hook up with someone, even if only for the afternoon.


--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: TAP diagnostic syntax proposal

[Ian Langworth]

prove --secret-ovid-mode ...

On 7/10/06, Ovid <[EMAIL PROTECTED]> wrote:

- Original Message 
From: chromatic <[EMAIL PROTECTED]>


> On Monday 10 July 2006 10:19, Michael G Schwern wrote:
>
> >got: this
> >expected:that
>
> "got" still sucks.  Is there any chance to change it to "received"?

I like "pitched" and "caught".

  ... silence ...

*cough*

Cheers,
Ovid (for Larry's sake, no I'm not serious!)

-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/








--
Ian Langworth

Re: I'm pre-hackathoning at OSCON, not post-hackathoning

[Andy Lester]

On Jul 10, 2006, at 12:39 PM, Patrick R. Michaud wrote:


Yes, I'm now targeting any hackathoning in Portland to occur on
the Sunday before OSCON instead of the Saturday after.


I'll be in Monday afternoon and leaving Friday afternoon so nyeah!

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: TAP diagnostic syntax proposal

[Andy Lester]

On Jul 10, 2006, at 1:38 PM, Ovid wrote:


   got: this
   expected:that


"got" still sucks.  Is there any chance to change it to "received"?


"Expected" and "actual"

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Java Script in Parrot

[Patrick R. Michaud]

On Sun, Jul 09, 2006 at 04:11:55PM -0700, chromatic wrote:
> On Sunday 09 July 2006 02:15, Vishal Soni wrote:
> 
> > I am not an expert on which approach is the way to go:
> > 1. Hack Mozilla's JavaScript excution engine to generate PIR.
> 
> If there's a fairly direct correspondence between JS bytecode (if there is 
> such a thing; I have no idea -- whatever internal ops it uses to represent a 
> program to execute), this may be easiest to start.
> 
> > 2. Use the Compiler Tool Chain developed by Parrot Wizards to implement
> > JavaScript engine.
> 
> This is probably the best long-term approach, at least if you find someone 
> good to write the grammar.  (I hate parsing.)

FWIW, I'm more than happy to help with the grammar, especially if
there's an existing definition to work from.

Pm

Re: TAP diagnostic syntax proposal

[Ian Langworth]

YAML documents [can] end with a "...".

I like Jonathan's suggestion of making the YAML comments, but my gut
feels funny about that. If the lines are preceeded with hashes, then
it's not "true" YAML; it has to be stripped of the leading characters.
Also, I'd rather have a TAP directive to state, "This is YAML,"
instead of a parser wondering if the data _is_ valid YAML.

On 7/10/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:

On 7/10/06, Pete Krawczyk <[EMAIL PROTECTED]> wrote:
> I would be concerned about "got" or "expected" including embedded
> newlines, such as:
>
>   is($mech->content,$expected_page,"Web page content matches what's 
expected");
>
> even with a delimiter such as Ian suggested.  How would this handle that?

YAML has ways to deal with newlines in values, but it does press for
some sort of "this line is part of the failure diagnostics" indicator
as Ian suggests.


> Also, would the raw test be pre-expanded?  That is, what would raw-test
> show for this?
>
>   is($user,"testuser$id","Test user name correctly generated");

Ideally it would show exactly that.  The idea is to show the literal
source line (or lines) which generated the test, if possible, so the
reader can have a better idea what happened beyond what the normal
got/expected diagnostics show.  To show them with interpolated strings
would require somehow reconstructing the syntax of the function call
from inside the function.  This loses information.

Besides, they already have the expanded thing which went in.
got/expected shows that.




--
Ian Langworth

Re: HLL, perl6

[Patrick R. Michaud]

On Mon, Jul 10, 2006 at 12:10:37AM -0400, Will Coleda wrote:
> I am currently trying to add some PGE to tcl (for the [expr] command,  
> where the optok parsing will be very helpful).
> 
> While debugging, I noticed that perl6 isn't using the .HLL directive:  
> I suspect the namespace lookup issues I'm having (and perl6 isn't)  
> might be de to this difference.
> 
> Some intrepid coder want to try to switch to using .HLL instead of a  
> simple .namespace directive?

I tried this back in March, but namespace handling at the time
wasn't really up to the task.  But overall namespaces have been
vastly improved since then, so I'll probably make another attempt
at it soon (unless someone else wants to take a crack at it, in
which case I'll be glad to provide any help needed).

Pm

Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Patrick R. Michaud]

On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work.  I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediately clear:
> 
>  .HLL 'perl5', perl5_group
>  .namespace ['Foo']
> 
>  $P0 = get_global 'x'# ['perl5';'Foo';'x']
>  $P0 = get_global ['Bar'], 'x'   # ['perl5';'Foo';'Bar';'x']
> 
>  $P0 = get_hll_global 'x'  # ['perl5';'x']
>  $P0 = get_hll_global ['Corge'], 'x'   # ['perl5';'Corge';'x']
> 
>  $P0 = get_abs_global 'x'  # ['x']
>  $P0 = get_abs_global ['parrot'], 'x'  # ['parrot';'x']

Pardon me for coming in late to the thread -- this past week I
was on a trip with limited network access and I'm just now catching
up.

What's the status on the above...has it been blessed/implemented yet?
This looks to me like exactly what is needed/desired for the various 
HLL's I'm working with.

Thanks,

Pm

[svn:perl6-synopsis] r10077 - doc/trunk/design/syn

[larry]

Author: larry
Date: Mon Jul 10 13:48:24 2006
New Revision: 10077

Modified:
   doc/trunk/design/syn/S02.pod
   doc/trunk/design/syn/S03.pod

Log:
Disallow postfix after listops without intervening (), .() or \.().


Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Jul 10 13:48:24 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 1 July 2006
+  Last Modified: 10 July 2006
   Number: 2
-  Version: 48
+  Version: 49
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -1713,8 +1713,8 @@
 If it is not, it is compiled as a provisional function call of
 the list operator form, which may or may not have an argument list.
 When in doubt, the attempt is made to parse an argument list.  As with
-any list operator, an immediate postfix operator means there are no
-arguments, whereas anything following whitespace will be interpreted
+any list operator, an immediate postfix operator is illegal unless it is a
+form of parentheses, whereas anything following whitespace will be interpreted
 as an argument list if possible.
 
 Based on the signature of the subroutine declaration, there are only
@@ -1747,16 +1747,16 @@
 or a method call in dot form.  (It is also allowed on a label when a
 statement is expected.) So for any undeclared identifier "C":
 
-foo.bar# foo().bar -- postfix prevents args
+foo.bar# foo().bar -- illegal postfix, must use foo().bar
 foo .bar   # foo($_.bar)   -- no postfix starts with whitespace
-foo\ .bar  # foo().bar -- long dot, so postfix
-foo++  # foo()++   -- postfix
+foo\ .bar  # foo().bar -- illegal long dot, use foo()\ .bar
+foo++  # foo()++   -- illegal postfix, must use foo()++
 foo 1,2,3  # foo(1,2,3)-- args always expected after listop
 foo + 1# foo(+1)   -- term always expected after listop
 foo;   # foo();-- no postfix, but no args either
 foo:   #   label   -- must be label at statement boundary.
-- illegal otherwise
-foo: bar:  #   two labels in a row
+foo: bar:  #   two labels in a row, okay
 .foo:  # $_.foo: 1 -- must be "dot" method with : args
 .foo(1)# $_.foo(1) -- must be "dot" method with () args
 .foo   # $_.foo()  -- must be "dot" method with no args

Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podMon Jul 10 13:48:24 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 8 Mar 2004
-  Last Modified: 1 Jul 2006
+  Last Modified: 10 Jul 2006
   Number: 3
-  Version: 44
+  Version: 45
 
 =head1 Changes to existing operators
 
@@ -224,18 +224,23 @@
 syntax.
 
 =item * List operators are all parsed consistently.  As in Perl 5,
-to the left they look like terms, while to the right they look like
-operators that are looser than comma.  Unlike in Perl 5, the difference
+to the left a list operator look like term, while to the right it looks like
+an operator that is looser than comma.  Unlike in Perl 5, the difference
 between the list operator form and the function form is consistently
 indicated via whitespace between the list operator and the first
 argument.  If there is whitespace, it is always a list operator,
-and the next token will be taken as the first term of the list.
-If there is no whitespace, the parser is biased towards taking the
-next token as an operator if at all possible.  If the next token
-can be taken as either an infix or a postfix operator, it indicates
-that the list operator has no arguments.  (Or more precisely, no
-extra arguments that aren't supplied the operator, since C<.()>
-is a postfix that supplies arguments to the preceding function.)
+and the next token will be taken as the first term of the list (or
+if there are no terms, as the expression terminator).
+
+If there is no whitespace, the operator is never taken as a list
+operator, but always as a functional operator.  Postfixes are
+specifically disallowed right after the operator except for the
+parenthetical forms delimiting the argument list.  The parentheses
+are optional if and only if there are no arguments.  If there are
+parentheses, they may be followed by any postfix operator.  Unlike
+postfix operators, infix operators and expression terminators are
+allowed without intervening whitespace, and will be taken to indicate
+that the operator is a function with no arguments.
 
 Ex

new! parrot tap parser

[jerry gay]

at the chicago hackathon, i decided to create a simple tap grammar
using perl 6 regexes. you can find the example grammar at:
   http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg

that spawned interest from chris dolan on creating a parser using
parrot's parser grammar engine (pge.) today, i've committed a working
implementation of a tap parser to the parrot repository. feel free to
check it out from http://svn.perl.org/parrot/trunk/, look in
languages/tap/. there you should find a readme with a small example of
how to get it working. it's still very much a work in progress, but
i'll be happy to answer any questions you may have.

andy lester pointed me here, saying there's tapalicious discussion
going on. so, i've just signed up, to join the fun.

we're hoping to extend this tap parser to be available for use by
high-level languages implemented on parrot. of course, before this
occurs, we need to know what hlls may want to do with a tap parser
(perhaps emit xml/html/text/etc?) any uses you can think of would be
greatly appreciated.

~jerry

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* Ovid <[EMAIL PROTECTED]> [2006-07-10 20:40]:
> From: chromatic <[EMAIL PROTECTED]>
> > On Monday 10 July 2006 10:19, Michael G Schwern wrote:
> >
> > >got: this
> > >expected:that
> >
> > "got" still sucks.  Is there any chance to change it to "received"?
> 
> I like "pitched" and "caught".

I’m voting for “flesh” and “spirit”.

Regards,
-- 
Aristotle
“Like punning, programming is a play on words.”
   – Alan J. Perlis, “Epigrams in Programming”

Re: TAP diagnostic syntax proposal

[demerphq]

On 7/10/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

* Ovid <[EMAIL PROTECTED]> [2006-07-10 20:40]:
> From: chromatic <[EMAIL PROTECTED]>
> > On Monday 10 July 2006 10:19, Michael G Schwern wrote:
> >
> > >got: this
> > >expected:that
> >
> > "got" still sucks.  Is there any chance to change it to "received"?
>
> I like "pitched" and "caught".

I'm voting for "flesh" and "spirit".


Ill put forward:

Have: this
Want: that

If only because they are same length.

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: TAP diagnostic syntax proposal

[Paul Johnson]

On Mon, Jul 10, 2006 at 11:59:27AM -0700, chromatic wrote:

> On Monday 10 July 2006 11:41, David Wheeler wrote:
> 
> > It's not a gift package delivered by FedEx. What sucks about "got"?
> 
> It's the grammatical equivalent of tucking your shirt tail into your
> underwear before trying to get a date at your family reunion.

Wonderful imagery!

Whilst I would also like to see something nicer that "got", I'm actually
more concerned about the ordering.  I always expect to see "expected"
first, followed by "got" or "received" or whatever, and I end up having
to look at the output a lot closer than I think I should in order to get
things the right way around.

But perhaps it's just my brain that's wired backwards.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: Java Script in Parrot

[Patrick R. Michaud]

On Mon, Jul 10, 2006 at 09:19:14PM +0100, Norman Nunley, Jr wrote:
> There's a rules grammar in http://svn.openfoundry.org/pugs/misc/ 
> JavaScript-FrontEnd/Grammar.pm
> 
> When I last attempted to compile it with PGE, it gave up the ghost in  
> the character class definitions.

Wow, thanks for the update.  PGE seems to be having trouble with
the <-xyz> rules, which are currently unimplemented.  But the
grammar is also using incorrect regex syntax -- the statements
like:

rule no_LineTerminator_here {
  [  & <->*? ]
}

rule USP  { <-> }

need to eliminate the inner angles, as in:

rule no_LineTerminator_here {
  [  & <-LineTerminator>*? ]
}

rule USP  { <+Zs-TAB-VT-FF-SP-NBSP> }

But I think the no_LineTerminator_here rule probably needs
to be rewritten altogether to avoid the & conjunction.

At any rate, this is a very useful start; I think it could
be updated quite quickly.  Thanks!

Pm


> On 10 Jul 2006, at 20:47, Patrick R. Michaud wrote:
> 
> >On Sun, Jul 09, 2006 at 04:11:55PM -0700, chromatic wrote:
> >>On Sunday 09 July 2006 02:15, Vishal Soni wrote:
> >>
> >>>I am not an expert on which approach is the way to go:
> >>>1. Hack Mozilla's JavaScript excution engine to generate PIR.
> >>
> >>If there's a fairly direct correspondence between JS bytecode (if  
> >>there is
> >>such a thing; I have no idea -- whatever internal ops it uses to  
> >>represent a
> >>program to execute), this may be easiest to start.
> >>
> >>>2. Use the Compiler Tool Chain developed by Parrot Wizards to  
> >>>implement
> >>>JavaScript engine.
> >>
> >>This is probably the best long-term approach, at least if you find  
> >>someone
> >>good to write the grammar.  (I hate parsing.)
> >
> >FWIW, I'm more than happy to help with the grammar, especially if
> >there's an existing definition to work from.
> >
> >Pm
> 
> 

Re: Java Script in Parrot

[Vishal Soni]

Hi Patrick,

This is is a good starting point. I have been writing the JavaScript grammar
in PGE fromECMA-262 spec. They lay out the operator precedence using Grammar
rules. Instead of using rules for operator precedence I would like to use
your optok approach. Is there some help I can get? I did look at your YAPC
2006 presentation. Are there any code examples?

The other that would be great to have is if we could suport Unicode
Character classes in PGE for e.g. <[\u2028-\u2050]>. JavaScript
specification assumes that the Source could be in Unicode format.

-Vishal


On 7/10/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:


On Mon, Jul 10, 2006 at 09:19:14PM +0100, Norman Nunley, Jr wrote:
> There's a rules grammar in http://svn.openfoundry.org/pugs/misc/
> JavaScript-FrontEnd/Grammar.pm
>
> When I last attempted to compile it with PGE, it gave up the ghost in
> the character class definitions.

Wow, thanks for the update.  PGE seems to be having trouble with
the <-xyz> rules, which are currently unimplemented.  But the
grammar is also using incorrect regex syntax -- the statements
like:

   rule no_LineTerminator_here {
 [  & <->*? ]
   }

   rule USP  { <-> }

need to eliminate the inner angles, as in:

   rule no_LineTerminator_here {
 [  & <-LineTerminator>*? ]
   }

   rule USP  { <+Zs-TAB-VT-FF-SP-NBSP> }

But I think the no_LineTerminator_here rule probably needs
to be rewritten altogether to avoid the & conjunction.

At any rate, this is a very useful start; I think it could
be updated quite quickly.  Thanks!

Pm


> On 10 Jul 2006, at 20:47, Patrick R. Michaud wrote:
>
> >On Sun, Jul 09, 2006 at 04:11:55PM -0700, chromatic wrote:
> >>On Sunday 09 July 2006 02:15, Vishal Soni wrote:
> >>
> >>>I am not an expert on which approach is the way to go:
> >>>1. Hack Mozilla's JavaScript excution engine to generate PIR.
> >>
> >>If there's a fairly direct correspondence between JS bytecode (if
> >>there is
> >>such a thing; I have no idea -- whatever internal ops it uses to
> >>represent a
> >>program to execute), this may be easiest to start.
> >>
> >>>2. Use the Compiler Tool Chain developed by Parrot Wizards to
> >>>implement
> >>>JavaScript engine.
> >>
> >>This is probably the best long-term approach, at least if you find
> >>someone
> >>good to write the grammar.  (I hate parsing.)
> >
> >FWIW, I'm more than happy to help with the grammar, especially if
> >there's an existing definition to work from.
> >
> >Pm
>
>





--
Thanks,
Vishal

Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > Relative is the usual apposite to absolute, but we have a three-way
> > logic here, so appositives don't really work.  I think that "hll" is the
> > best I can think of, and given the existing ".HLL" directive, its meaning
> > is immediately clear:
> > 
> >  .HLL 'perl5', perl5_group
> >  .namespace ['Foo']
> > 
> >  $P0 = get_global 'x'  # ['perl5';'Foo';'x']
> >  $P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
> > 
> >  $P0 = get_hll_global 'x'  # ['perl5';'x']
> >  $P0 = get_hll_global ['Corge'], 'x'   # ['perl5';'Corge';'x']
> > 
> >  $P0 = get_abs_global 'x'  # ['x']
> >  $P0 = get_abs_global ['parrot'], 'x'  # ['parrot';'x']
> 
> What's the status on the above...has it been blessed/implemented yet?
> This looks to me like exactly what is needed/desired for the various 
> HLL's I'm working with.

Allison has blessed it except for the detail of the "_hll_" in the HLL
selection.  I haven't started implementing it yet, though nothing stands
in my way technically.

I've suggested that get_namespace follow exactly the same pattern, but
so far she hasn't commented on that suggestion at all.

BTW I expect find_global to keep working for a good while.  The only thing
that may change incompatibly in _any_ of this is the meaning of:

PMC = get_namespace KEY,STR

which currently starts from the HLL root but which I'm proposing should
start at the current namespace.  *If* that additional proposal goes forward,
any place you currently have the above, you would just change it to:

PMC = get_hll_namespace KEY,STR

PS: None of this is in any PDD yet -- not a complaint, just an observation. :-)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Patrick R. Michaud]

On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
> On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > > Relative is the usual apposite to absolute, but we have a three-way
> > > logic here, so appositives don't really work.  I think that "hll" is the
> > > best I can think of, and given the existing ".HLL" directive, its meaning
> > > is immediately clear:
> > >  .HLL 'perl5', perl5_group
> > >  .namespace ['Foo']
> > >  $P0 = get_global ['Bar'], 'x'   # ['perl5';'Foo';'Bar';'x']
> > >  $P0 = get_hll_global ['Corge'], 'x'   # ['perl5';'Corge';'x']
> > >  $P0 = get_abs_global ['parrot'], 'x'  # ['parrot';'x']
> > 
> > What's the status on the above...has it been blessed/implemented yet?
> > This looks to me like exactly what is needed/desired for the various 
> > HLL's I'm working with.
> 
> Allison has blessed it except for the detail of the "_hll_" in the HLL
> selection.  I haven't started implementing it yet, though nothing stands
> in my way technically.
> 
> I've suggested that get_namespace follow exactly the same pattern, but
> so far she hasn't commented on that suggestion at all.

I really like both of these suggestions.  We also noted on #parrot that
get_hll_global would really simplify things for the Tcl folks, which
currently go through a macro to achieve the same effect.

> BTW I expect find_global to keep working for a good while.  The only thing
> that may change incompatibly in _any_ of this is the meaning of:
> 
> PMC = get_namespace KEY,STR
> 
> which currently starts from the HLL root but which I'm proposing should
> start at the current namespace.  *If* that additional proposal goes forward,
> any place you currently have the above, you would just change it to:
> 
> PMC = get_hll_namespace KEY,STR

I'm not currently using get_namespace in any form, so I have no problem
with this switch.  

FWIW, a quick grep of the parrot tree seems to indicate that the only
places using get_namespace outside of the Parrot sources and tests
are in languages/dotnet (12 occurrences) and languages/tcl (2 occurrences).

Pm

Re: TAP diagnostic syntax proposal

[demerphq]

On 7/10/06, Paul Johnson <[EMAIL PROTECTED]> wrote:

On Mon, Jul 10, 2006 at 11:59:27AM -0700, chromatic wrote:

> On Monday 10 July 2006 11:41, David Wheeler wrote:
>
> > It's not a gift package delivered by FedEx. What sucks about "got"?
>
> It's the grammatical equivalent of tucking your shirt tail into your
> underwear before trying to get a date at your family reunion.

Wonderful imagery!

Whilst I would also like to see something nicer that "got", I'm actually
more concerned about the ordering.  I always expect to see "expected"
first, followed by "got" or "received" or whatever, and I end up having
to look at the output a lot closer than I think I should in order to get
things the right way around.

But perhaps it's just my brain that's wired backwards.


If so then you aren't the only one.

I'll repeat my earlier suggestion:

Want: This
Have: That

Cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [ANNOUNCE] Pugs 6.2.12 and v6.pm released! (reformatted)

[Audery Tang]

在 2006/7/10 上午 10:37 時，Michael Goldshteyn 寫到：


Unfortunatelly, those of us who use Perl under Windows / MSVC Compiler
cannot use v6.pm, due to the fact that it has an indirect  
dependency on
Devel::Caller which fails to work using that compiler combination  
(i.e.,
fails all tests after a build using its makefile and Visual Studio  
2003 as

the C compiler).



Indeed it is known that Devel::Caller currently fails some tests  
under Perl 5.8 with ithreads enabled;

its author, Richard Clamp, is looking into a solution.

For the time being, as v6.pm does not use the parts of Devel::Caller  
that fails the tests, a simple

"force install" should still get you a working v6-alpha.

Thanks!
Audrey



PGP.sig
Description: This is a digitally signed message part

Re: TAP diagnostic syntax proposal

[chromatic]

On Monday 10 July 2006 15:28, demerphq wrote:

> On 7/10/06, Paul Johnson <[EMAIL PROTECTED]> wrote:

> > Whilst I would also like to see something nicer that "got", I'm actually
> > more concerned about the ordering.  I always expect to see "expected"
> > first, followed by "got" or "received" or whatever, and I end up having
> > to look at the output a lot closer than I think I should in order to get
> > things the right way around.

> > But perhaps it's just my brain that's wired backwards.

> If so then you aren't the only one.

> I'll repeat my earlier suggestion:
>
> Want: This
> Have: That

I prefer that too.  Paul's suggestion about ordering also makes sense.

Of course, is() uses positional arguments in the opposite order.

However, if TAP is more successful than just Perl, that argument isn't very 
useful.  Besides, named arguments are nicer than positional ones.

Look, my bald yak has almost finished repainting that shed!

-- c

Re: making v6 test suite its own distro

[Darren Duncan]

At 6:53 PM +0300 7/10/06, Gaal Yahas wrote:

On Sat, Jul 08, 2006 at 12:47:17AM -0700, Darren Duncan wrote:

 As briefly discussed on #perl6 ...


As briefly replied there before being jethandled...


As further discussed there ...


Perhaps we need a baby-Perl Test::Simple for new implementations, and
by convention have 01-sanity use only those functions present there. The
drawback being somewhat duplicated effort and another distribution worry.


I believe that the current Test.pm already qualifies as a baby-Perl 
implementation, as overall its functionality is quite simple, and it 
uses very little of the language (especially since its use of 
junctions was removed a few weeks ago).


Have a look at 01-sanity again.  Since I moved 08-test out of that 
folder (and into 02-test-pm) none of those 01-sanity tests use 
Test.pm at all.


My impression of 01-sanity is that it checks that the Perl 6 
implementation has the basic language functions that Test.pm has as a 
prerequisite, such as being able to print, knowing basic 
conditionals, supporting basic subroutines and modules.


If 01-sanity runs, then the normal Test.pm should be useable, and 
02-test-pm checks that Test.pm itself actually works.  When that 
runs, then the other tests can be performed as usual.



The first obvious question that this enumeration presents is: where to
cut? Does every implementation use its own Test.pm? Pugs was able to
start using one after 23 days, but that was a simpler module then than
it is today, and a fresh implementation may find it hard to get started
if its first objective is to implement so much Perl 6 simultaneously.


I would say for starters that anything which is written in Perl 6 
will be shared by all implementations, and that includes Test.pm.


Considering its few needs, any Perl that can't run the current 
Test.pm is hardly useful, so they would be getting up to the level of 
supporting Test.pm very quickly.  And in the process of getting to 
that level, the 01-sanity tests can be tried without Test.pm.



The other question that comes to mind is how to manage SKIP and TODO
tests for release mangement. Currently Pugs, assuming globality, simply
plunges into every t/ file before a release and marks forsaken (for this
release) tests TODO, and commits. But surely different implementations
have their different bugs. In the case of TODO we can fix that easily:
we already have a mechanism for force_todoing tests "at a distance",
though currently that distance is at the head of the test file (but it's
a simple matter to make that a distro-level file). The deeper technical
challenge is how to maintain SKIPs, which after all, are often used
before hanging tests. skip_all we can manage; skip we cannot, until at
least when we have a powerful debugger.


All unconditional skips/todos in the test suite should be eliminated 
entirely, and be allowed to fail.  If hangs are a concern, then the 
test harness (presumably not written in Perl 6) can just have a 
timeout function and kill any tests that run for too long (the time 
threshold can be changed per user in config.yml).


The proper way to have skips/todos is for them to be conditional.

Ideally, one of the first things that any Perl 6 implementation would 
provide is something akin to a %FEATURES (or some other named) global 
or environmental or config variable, which a Perl 6 script can query 
at runtime to see whether that implementation CLAIMS to support 
certain features.  Only features that are claimed to be supported are 
tested, to yield a ok/not ok, and only those features claimed to be 
unsupported, either explicitly, or implicity by not being mentioned 
at all, will be skipped.


A brand new Perl 6 implementation will declare an empty %FEATURES, 
meaning that everything is unsupported, and so everything conditional 
skips (which would be most tests, ideally).  As the implementation 
matures, it starts adding items to %FEATURES, and so skips are 
replaced by passes or fails.


Of course, certain sanity items will have to work before %FEATURES 
does, such as the ability to print, basic conditionals and boolean 
expressions, the ability to read from a variable, etc.  But no 
support for subroutines or external modules will be needed in order 
to do this, so the threshold is lower than for any type of Test.pm.


The %FEATURES variable would be populated in the logical fashion, 
derived partly or entirely from explicit declarations in the 
implementation code itself, and partly or not at all from user 
configuration or environment as is applicable.  Entirely from code 
may be better so that this doesn't make the CONFIG or ENV or whatever 
vars redundant, or they could possibly overlap as makes sense, but my 
emphasis is on the code.


If we are going to go with this idea, and I give it my highest level 
of recommendation, it would stand to reason that the possible 
features to be tested for will be standardized and documented such as 
in a Synopsis.


I coul

Re: I'm pre-hackathoning at OSCON, not post-hackathoning

[Darren Duncan]

At 2:24 PM -0500 7/10/06, Andy Lester wrote:

On Jul 10, 2006, at 12:39 PM, Patrick R. Michaud wrote:


Yes, I'm now targeting any hackathoning in Portland to occur on
the Sunday before OSCON instead of the Saturday after.


I'll be in Monday afternoon and leaving Friday afternoon so nyeah!


If a virgin car-pool arrangement works out, I will be travelling to 
OSCON (for just the no-cost hallway track) on Sunday the 23rd (so 
maybe catch the end of a sunday event) and back on Friday the 28th. 
I mainly expect to do my hackathoning Monday to Thursday, with 
whoever's there. -- Darren Duncan

OSCON hackathon

[Patrick R. Michaud]

For those who are interested in doing hackathoning at OSCON,
we're currently planning to do things on Sunday the 23rd.
I'll see if I can find a designated place for us to meet
and work.

However, for those who cannot make it on Sunday, I notice that
Monday and Tuesday at OSCON are primarily dedicated for
tutorial sessions, so people arriving after Sunday and/or
not attending or presenting tutorials can perhaps continue
hacking activities on those days...?

Pm


On Mon, Jul 10, 2006 at 03:59:23PM -0700, Darren Duncan wrote:
> At 2:24 PM -0500 7/10/06, Andy Lester wrote:
> >On Jul 10, 2006, at 12:39 PM, Patrick R. Michaud wrote:
> >
> >>Yes, I'm now targeting any hackathoning in Portland to occur on
> >>the Sunday before OSCON instead of the Saturday after.
> >
> >I'll be in Monday afternoon and leaving Friday afternoon so nyeah!
> 
> If a virgin car-pool arrangement works out, I will be travelling to 
> OSCON (for just the no-cost hallway track) on Sunday the 23rd (so 
> maybe catch the end of a sunday event) and back on Friday the 28th. 
> I mainly expect to do my hackathoning Monday to Thursday, with 
> whoever's there. -- Darren Duncan

Re: OSCON hackathon

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 06:09:32PM -0500, Patrick R. Michaud wrote:
> However, for those who cannot make it on Sunday, I notice that Monday and
> Tuesday at OSCON are primarily dedicated for tutorial sessions, so people
> arriving after Sunday and/or not attending or presenting tutorials can
> perhaps continue hacking activities on those days...?

I think it'd be great to maintain a hackathon designated location for those
who are between tutorials, or who like me just show up during tutorial days
for the hell of it.  :-)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: TAP diagnostic syntax proposal

[demerphq]

On 7/11/06, chromatic <[EMAIL PROTECTED]> wrote:

On Monday 10 July 2006 15:28, demerphq wrote:

> On 7/10/06, Paul Johnson <[EMAIL PROTECTED]> wrote:

> > Whilst I would also like to see something nicer that "got", I'm actually
> > more concerned about the ordering.  I always expect to see "expected"
> > first, followed by "got" or "received" or whatever, and I end up having
> > to look at the output a lot closer than I think I should in order to get
> > things the right way around.

> > But perhaps it's just my brain that's wired backwards.

> If so then you aren't the only one.

> I'll repeat my earlier suggestion:
>
> Want: This
> Have: That

I prefer that too.  Paul's suggestion about ordering also makes sense.

Of course, is() uses positional arguments in the opposite order.


I think also that people tend to spend a lot more time staring at the
results of a failed test than they do writing the test in the first
place, so while it sucks the order is different it doesnt seem that
bad.


However, if TAP is more successful than just Perl, that argument isn't very
useful.  Besides, named arguments are nicer than positional ones.


Yeah, other implementations need not follow Test's precedent in terms
of interface.

cheers,
Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: TAP diagnostic syntax proposal

[Joe McMahon]

Want: This
Have: That


Put me down for this one too. Simpler for non-English speakers as well.

Re: TAP diagnostic syntax proposal

[Randy W. Sims]

chromatic wrote:

On Monday 10 July 2006 10:19, Michael G Schwern wrote:


   got: this
   expected:that


"got" still sucks.  Is there any chance to change it to "received"?


returned?

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* Randy W. Sims <[EMAIL PROTECTED]> [2006-07-11 01:40]:
> chromatic wrote:
> >On Monday 10 July 2006 10:19, Michael G Schwern wrote:
> >
> >>   got: this
> >>   expected:that
> >
> >"got" still sucks.  Is there any chance to change it to "received"?
> 
> returned?

Err, it’s what was passed, not what was returned.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP diagnostic syntax proposal

[Randy W. Sims]

Michael G Schwern wrote:

The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time
talking about TAP) sketched out a syntax for parsable TAP diagnostics.

  not ok 2 - omg t3h sooper test!!1!
  file:foo.t
  line:45
  description: omg t3h sooper test!!1!
  got: this
  expected:that
  raw-test:is( "this", "that", "omg t3h sooper test!!1!" );
  x-THAC0: 16

Details on the wiki.

http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax


Is 'got' and 'expected' going to return compound YAML when given 
objects? or stringified results? That would affect the complexity of the 
YAML subset you're going to support, right?


What output does C return?

Randy.

Re: [perl #39778] Segfault when using a Namespace with an Iterator

[Chip Salzenberg]

On Sun, Jul 09, 2006 at 11:52:23PM -0700, Matt Diephouse wrote:
> Trying to use an Iterator with a NameSpace makes Parrot segfault

Ouch.

The current namespace class is typed but in a silly way -- not with name
mangling but with actually storing two things with exactly the same name.
(One being a sub-namespace, and the other being anything else.)

So iterating through it requires custom code.

Frankly I'd prefer to make the default namespace actually be a hash with
extra behaviors (methods mostly), but that requires something else first,
namely, the rearrangement of the Parrot namespace so that Parrot no longer
requires a class object and its namespace object to have the same name.

I'm going to create a bug for this plan and then connect that bug to this.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

[perl #39784] Make Parrot's default namespace be untyped

[via RT]

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


Parrot's default namespace implementation should be 100% untyped --
basically just a hash with some additional methods.

Making this happen requires solving the problem of Parrot's currently
requiring classes and class method namespaces to have the same name.

e.g. the current situation is:

find_global 'MyClass'# 'MyClass' is class object
find_global ['MyClass'], 'mymethod'  # 'MyClass' is namespace object

Depending on a typed namespace in the core of Parrot is Not OK.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: OSCON hackathon

[Darren Duncan]

At 4:15 PM -0700 7/10/06, Chip Salzenberg wrote:

On Mon, Jul 10, 2006 at 06:09:32PM -0500, Patrick R. Michaud wrote:

 However, for those who cannot make it on Sunday, I notice that Monday and
 Tuesday at OSCON are primarily dedicated for tutorial sessions, so people
 arriving after Sunday and/or not attending or presenting tutorials can
 perhaps continue hacking activities on those days...?


I think it'd be great to maintain a hackathon designated location for those
who are between tutorials, or who like me just show up during tutorial days
for the hell of it.  :-)


Barring a better idea, I suggest paying attention to the parallel 
"OSCAMP" un-conference, which does or will have space designated for 
it in the convention center, Monday to Thursday.


See http://oscamp.org/ .

That web page indicates some specific locations like E141 + E142 as 1 
room for monday-tuesday, and D146 for wednesday-thursday.  Using a 
pipe+curtained section of the exhibit hall was also mentioned.


We could make use of OSCAMP as a venue for hackathoning, as I 
wouldn't be surprised if that venue attracts other similar-minded 
invididuals, some whom might join with us.


Or if that place becomes too busy, maybe somewhere else.

Watch out for their schedule page though, which while mentioning some 
general free events like the Damian's tuesday night event, it doesn't 
mention Larry's earlier one, and who wants to miss the Onion?


On a related matter, I highly recommend that those of us at the 
conference sign into #perl6 on our portables and leave it open all 
the time, so in case we need to locate each other physically 
(something I found difficult last year), we could easily ping each 
other in the forum for that purpose.  Or we could have another IRC 
channel for that, but most of us are in #perl6 anyway so I would 
think that is easier.


-- Darren Duncan

Re: OSCON hackathon

[Allison Randal]

Chip Salzenberg wrote:
> 
> I think it'd be great to maintain a hackathon designated location for those
> who are between tutorials, or who like me just show up during tutorial days
> for the hell of it.  :-)

There's a designated room for hackathon/Camp-style sessions inside the
convention center all week long. It's a conference within a conference,
see oscamp.org. The room on Monday and Tuesday is over 2000 sq.ft., so
plenty of room for a Parrot hacking corner.

Allison

Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Matt Diephouse]

Patrick R. Michaud <[EMAIL PROTECTED]> wrote:

On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
> On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > > Relative is the usual apposite to absolute, but we have a three-way
> > > logic here, so appositives don't really work.  I think that "hll" is the
> > > best I can think of, and given the existing ".HLL" directive, its meaning
> > > is immediately clear:
> > >  .HLL 'perl5', perl5_group
> > >  .namespace ['Foo']
> > >  $P0 = get_global ['Bar'], 'x'   # ['perl5';'Foo';'Bar';'x']
> > >  $P0 = get_hll_global ['Corge'], 'x'   # ['perl5';'Corge';'x']
> > >  $P0 = get_abs_global ['parrot'], 'x'  # ['parrot';'x']
> >
> > What's the status on the above...has it been blessed/implemented yet?
> > This looks to me like exactly what is needed/desired for the various
> > HLL's I'm working with.
>
> Allison has blessed it except for the detail of the "_hll_" in the HLL
> selection.  I haven't started implementing it yet, though nothing stands
> in my way technically.
>
> I've suggested that get_namespace follow exactly the same pattern, but
> so far she hasn't commented on that suggestion at all.

I really like both of these suggestions.  We also noted on #parrot that
get_hll_global would really simplify things for the Tcl folks, which
currently go through a macro to achieve the same effect.


You mean get_abs_global, actually. The proposed get_hll_global opcode
mirrors the existing find_global exactly. :-)

--
matt diephouse
http://matt.diephouse.com

Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Allison Randal]

Chip Salzenberg wrote:
> 
> Hrm.  Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work.  I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediately clear:

I like that.

> Seems to me that we should have get_namespace patterned just alike:

Agreed.

> I'm still not entirely happy with "abs", but I can live with it, especially
> since its use should be quite rare.

Yeah, if we're going for meaning-based naming in the 'hll' version, it'd
be nice to have a meaning-based name for the absolute-root version.
Perhaps get_root_global or get_base_global (I like 'base' better).

I'll work on updating the namespaces PDD tomorrow.

Allison

Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 06:57:06PM -0700, Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >I really like both of these suggestions.  We also noted on #parrot that
> >get_hll_global would really simplify things for the Tcl folks, which
> >currently go through a macro to achieve the same effect.
> 
> You mean get_abs_global, actually. The proposed get_hll_global opcode
> mirrors the existing find_global exactly. :-)

Erm, only if it's the explicit-namespace version of find_global.
Summarizing the conversion chart:

   $P0 = find_global 'x' ->  $P0 = get_global 'x'

   $P1 = find_global ['ns'],'x'  ->  $P0 = get_hll_global ['ns'],'x'

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 07:22:21PM -0700, Allison Randal wrote:
> Chip Salzenberg wrote:
> > I think that "hll" is the best I can think of, and given the existing
> > ".HLL" directive, its meaning is immediately clear:
> 
> I like that.

Great!

> > Seems to me that we should have get_namespace patterned just alike:
> 
> Agreed.

Great^2!

> > I'm still not entirely happy with "abs", but I can live with it, especially
> > since its use should be quite rare.
> 
> Yeah, if we're going for meaning-based naming in the 'hll' version, it'd
> be nice to have a meaning-based name for the absolute-root version.
> Perhaps get_root_global or get_base_global (I like 'base' better).

I could live with either get_root_global or get_base_global.  I may commit a
patch that contains one or the other but only as a development step, not as
a stealth vote.

(You'll probably want to know that "get_base_global" has a slight object-
orientation connotation from my C++ experience; in C++, a superclass is
called a "base class".  Whether this matters depends entirely on whether
slight C++ semantic bleed is likely to interfere with the Parrot user base;
and even I must admit that the answer is probably "no".)

> I'll work on updating the namespaces PDD tomorrow.

Great^3 that this happens automagically (from my POV) while I'm coding.  :-D
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Stealing base

[Bob Rogers]

   From: Chip Salzenberg <[EMAIL PROTECTED]>
   Date: Mon, 10 Jul 2006 19:41:38 -0700

   (You'll probably want to know that "get_base_global" has a slight object-
   orientation connotation from my C++ experience; in C++, a superclass is
   called a "base class".  Whether this matters depends entirely on whether
   slight C++ semantic bleed is likely to interfere with the Parrot user base;
   and even I must admit that the answer is probably "no".)

IIRC, "base class" predates C++.  So you may have stolen this from C++,
but C++ stole it from somebody else, so no need to feel guilty.  ;-}

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: Anyone experiencing problems with rt.cpan.org?

[Ask Bjoern Hansen]

Ovid wrote:


In the last day or so, every time I go to rt.cpan.org, it seems to
 nearly finish loading a page and then just stalls.





My problem was that I couldn't even log in yesterday.  I eventually
filed a bug report with perlbug-admin at perl and Robert had to
diddle the  database to get me sorted.


Wasn't that rt._perl_.org?

To the original poster: Posting about problems with a cpan.org or 
perl.org on a random-ish list or (worse) on use.perl or perlmonks is 
never the best way to get it resolved.



 - ask

Re: "Dynamic" (was discussion for #39711 -- [TODO] Make PIR->PBC reentrant)

[Audrey Tang]

在 2006/7/5 上午 12:15 時，chromatic 寫到：


On Tuesday 04 July 2006 21:01, Audrey Tang wrote:


Hence I'm puzzled why you raise the "dynamic language" categorization
as a justification, for that term usually refers to dynamic typing,
not to :immediate.  If it is referring to :immediate, then Python/
Ruby/PHP would become static languages. :-)


That doesn't quite seem fair; dynamic is a lot broader than just  
typing.
Certainly any statically typed language with decent support for  
generic
operations (or at least type-safe polymorphism) and a non-static  
loading

scheme would be sufficiently dynamic.

I can't point to an example of such a language, but there you go.


Haskell with Language.Haskell.Eval and Language.C.Eval is one such  
language
that I know of.  However, allowing unbounded evaluation within the  
assembler
cycle does not facilitate dynamic programming, so I'd still say it's  
entirely

besides the point for the :immediate discussion.

I agree there should be a static subset of functionality, that  
guarantees
(or at least declares) that their result will not change across  
different

runs, and those operations may be allowed in :immediate.  In that sense
it's not unlike the manifest sections in CLR, or constant table  
constructor

instructions in many other runtimes -- TrueType fonts included.

Assembler-level unbounded evaluation via :immediate (aka BEGIN) does not
facilitate dynamic languages at all, up and including Perl 5.

Thanks,
Audrey


PGP.sig
Description: This is a digitally signed message part

Re: Stealing base

[Allison Randal]

Bob Rogers wrote:
>From: Chip Salzenberg <[EMAIL PROTECTED]>
>Date: Mon, 10 Jul 2006 19:41:38 -0700
> 
>(You'll probably want to know that "get_base_global" has a slight object-
>orientation connotation from my C++ experience; in C++, a superclass is
>called a "base class".  Whether this matters depends entirely on whether
>slight C++ semantic bleed is likely to interfere with the Parrot user base;
>and even I must admit that the answer is probably "no".)
> 
> IIRC, "base class" predates C++.  So you may have stolen this from C++,
> but C++ stole it from somebody else, so no need to feel guilty.  ;-}

Aye, "base" is not ideal ("base class" is a generic term, used even in
Perl), it also conflicts with numeric "bases": "counting in base 2",
etc. But "root" also conflicts with "root" user, and mathematic roots
(square root, etc), not to mention the root of a tree in a
transformation (a term that will become more common since the compiler
tools are based on tree transformations). There just aren't many options
to choose from in English.

Maybe get_top_global, since it carries the idea that you need to specify
the namespace path from the top. It's also 3 letters, to match 'hll',
for whatever small value that adds. We can claim it stands for "the 'ole
(bl***y) path". ;)

Allison

Re: Java Script in Parrot

[Chris Dolan]

On Jul 10, 2006, at 4:31 PM, Vishal Soni wrote:

This is is a good starting point. I have been writing the  
JavaScript grammar
in PGE fromECMA-262 spec. They lay out the operator precedence  
using Grammar
rules. Instead of using rules for operator precedence I would like  
to use
your optok approach. Is there some help I can get? I did look at  
your YAPC

2006 presentation. Are there any code examples?


Take a look at parrot/languages/punie/lib/{punie.pg,PunieGrammar.pir}  
which has both bottom up and top down parsing.  I found it very  
educational.


Chris

--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Re: Java Script in Parrot

[Vishal Soni]

Thanks Chris 

I looked at it but it does not implement Unicode in PGE and Optok too..


On Mon, 2006-07-10 at 23:30 -0500, Chris Dolan wrote:
> On Jul 10, 2006, at 4:31 PM, Vishal Soni wrote:
> 
> > This is is a good starting point. I have been writing the  
> > JavaScript grammar
> > in PGE fromECMA-262 spec. They lay out the operator precedence  
> > using Grammar
> > rules. Instead of using rules for operator precedence I would like  
> > to use
> > your optok approach. Is there some help I can get? I did look at  
> > your YAPC
> > 2006 presentation. Are there any code examples?
> 
> Take a look at parrot/languages/punie/lib/{punie.pg,PunieGrammar.pir}  
> which has both bottom up and top down parsing.  I found it very  
> educational.
> 
> Chris
> 
> --
> Chris Dolan, Software Developer, http://www.chrisdolan.net/
> Public key: http://www.chrisdolan.net/public.key
> vCard: http://www.chrisdolan.net/ChrisDolan.vcf
> 
> 
> 

Re: Stealing base

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 09:25:53PM -0700, Allison Randal wrote:
> Maybe get_top_global   We can claim it stands for "the 'ole (bl***y)
> path". ;)

Now that's the Perl design metric I've come to know and love.  :-)

Seriously, it works for me.

I suggest that you delay the final choice utnil you write the PDD, then
to with whatever opcode name looks best in the =item that precedes its
description.  :-)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

[CAGE] Output of CPD on src/

[Juan Jose Natera]

Hi,

As per the cage/todo.pod I ran CPD (http://pmd.sourceforge.net) on src/, 
the attached file contains the output.


With some pointers, I can figure out how to eliminate the code 
duplication, please advice.


Regards,

Juan Jose
Skipping /home/juanjose/projects/parrot-bleed/src/exec_save.c due to parse error
=
Found a 126 line (421 tokens) duplication in the following files: 
Starting at line 954 of 
/home/juanjose/projects/parrot-bleed/src/jit/sun4/jit_emit.h
Starting at line 2618 of 
/home/juanjose/projects/parrot-bleed/src/jit/i386/jit_emit.h
break;
}
}

/* emit a call to a vtable func
 * $1->vtable(interp, $1)
 */
static void
Parrot_jit_vtable1_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 1 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 1, a);
}

/* emit a call to a vtable func
 * $1 = $2->vtable(interp, $2)
 */
static void
Parrot_jit_vtable1r_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 2 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 1, a);
Parrot_jit_store_retval(jit_info, interpreter);
}


/* emit a call to a vtable func
 * $1 = $2->vtable(interp, $2, $3)
 */
static void
Parrot_jit_vtable_1r223_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 2 , 3};
Parrot_jit_vtable_n_op(jit_info, interpreter, 2, a);
Parrot_jit_store_retval(jit_info, interpreter);
}

/* emit a call to a vtable func
 * $1 = $3->vtable(interp, $3, $2)
 */
static void
Parrot_jit_vtable_1r332_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 3 , 2};
Parrot_jit_vtable_n_op(jit_info, interpreter, 2, a);
Parrot_jit_store_retval(jit_info, interpreter);
}
/* emit a call to a vtable func
 * $1->vtable(interp, $1, $2)
 */
static void
Parrot_jit_vtable_112_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 1, 2 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 2, a);
}

/* emit a call to a vtable func
 * $1->vtable(interp, $1, $1)
 */
static void
Parrot_jit_vtable_111_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 1, 1 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 2, a);
}
/* emit a call to a vtable func
 * $2->vtable(interp, $2, $1)
 */
static void
Parrot_jit_vtable_221_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 2, 1 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 2, a);
}

/* emit a call to a vtable func
 * $2->vtable(interp, $2, $3, $1)
 */
static void
Parrot_jit_vtable_2231_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 2, 3, 1 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 3, a);
}

/* emit a call to a vtable func
 * $1->vtable(interp, $1, $2, $3)
 */
static void
Parrot_jit_vtable_1123_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 1, 2, 3 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 3, a);
}

/* emit a call to a vtable func
 * $1->vtable(interp, $1, $2, $1)
 */
static void
Parrot_jit_vtable_1121_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter)
{
int a[] = { 1, 2, 1 };
Parrot_jit_vtable_n_op(jit_info, interpreter, 3, a);
}


/* if_p_ic, unless_p_ic */
static void
Parrot_jit_vtable_if_unless_op(Parrot_jit_info_t *jit_info,
 Interp * interpreter, int unless)
{
int ic = *(jit_info->cur_op + 2);   /* branch offset */

/* emit call  vtable function i.e. get_bool, result eax */
Parrot_jit_vtable1_op(jit_info, interpreter);
=
Found a 50 line (268 tokens) duplication in the following files: 
Starting at line 1409 of /home/juanjose/projects/parrot-bleed/src/string.c
Starting at line 1478 of /home/juanjose/projects/parrot-bleed/src/string.c
string_bitwise_xor(Interp *interpreter, STRING *s1, STRING *s2, STRING **dest)
{
STRING *res;
size_t maxlen = 0;

if (s1) {
if (s1->encoding != Parrot_fixed_8_encoding_ptr) {
real_exception(interpreter, NULL, INVALID_ENCODING,
"string bitwise_and (%s/%s) unsupported",
((ENCODING *)(s1->encoding))->name,
((ENCODING *)(s2->encoding))->name);
}
maxlen = s1->bufused;
}
if (s2) {
if (s2->encoding != Parrot_fixed_8_encoding_ptr) {
real_exception(interpreter, NULL, INVALID_ENCODING,
"string bitwise_and (%s/%s) unsupported",
((ENCODING *)(s2->encoding))->name,
((ENCODING *)(s2->encoding))->name);
}
if (s2->bufused > maxlen)
maxlen = s2->bufused;
}

if (dest && *dest) {
res = *dest;
res->enc

Re: Re: [perl #39777] Large Subroutine Segfaults IMCC

[Matt Diephouse]

Vishal Soni <[EMAIL PROTECTED]> wrote:

Hi Matt,

This patch is because the number of .constant decls in IMCC is limited
to 4096. This is a todo to make this dynamic. The evil code seems to
have about 4200 .constant decls being generated.

Here is the patch to fix it. For now I bumped up the limit to 8192 and
it works. But this is a TODO for sure.


Thanks for investigating this, Vishal. Coke mentioned on IRC that he
had bumped this number up once before. I'll change the ticket in RT to
document the real problem. In the meantime, would it be possible to
die with an error saying "too many .constants" instead of just
segfaulting?

Thanks again,

--
matt diephouse
http://matt.diephouse.com

Re: Re: [perl #39777] Large Subroutine Segfaults IMCC

[Vishal Soni]

Hi Matt,

I can patch up something that would spit out an error message and exit
rather than Segfaulting.

Right now there is no bounds check. 

Other thing I could do is re-allocate the Macro Array size when it gets
full. So it would not fail until system starts swapping :-)

I would prefer the second option. Because it might hinder your and other
language development. This might become a bigger issue as you start
writing bigger programs or libraries.

Let me know your thoughts.

-Vishal

On Mon, 2006-07-10 at 22:11 -0700, Matt Diephouse wrote:
> Vishal Soni <[EMAIL PROTECTED]> wrote:
> > Hi Matt,
> >
> > This patch is because the number of .constant decls in IMCC is limited
> > to 4096. This is a todo to make this dynamic. The evil code seems to
> > have about 4200 .constant decls being generated.
> >
> > Here is the patch to fix it. For now I bumped up the limit to 8192 and
> > it works. But this is a TODO for sure.
> 
> Thanks for investigating this, Vishal. Coke mentioned on IRC that he
> had bumped this number up once before. I'll change the ticket in RT to
> document the real problem. In the meantime, would it be possible to
> die with an error saying "too many .constants" instead of just
> segfaulting?
> 
> Thanks again,
>