Re: use Tests; # ?

- Original Message From: Michael G Schwern On 7/15/06, Ovid wrote: > > Just a thought: > > > > use Tests qw/ > > Exception > > Differences > > /; > > > > Have it import those modules and check for sub conflicts. > > This doesn't really buy you anything over: >

Re: fetching module version from the command line

On 7/17/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * Graham Barr <[EMAIL PROTECTED]> [2006-07-17 02:00]: > perl -MDBI\ 999 > DBI version 999 required--this is only version 1.50. > BEGIN failed--compilation aborted. You can use an equals sign instead of a space, there, which makes it a little ea

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

Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers: >    BTW, it doesn't seem right that I can run Parrot for only a second or > two and get more than 300K stack frames deep.  Isn't there a way to > limit the stack to something sane, since more than a few MB of C stack > usage is a pretty sure sign

[perl #39849] [PATCH] pmc2c: Wrap MMD initializer code in block

# New Ticket Created by Ron Blaschke # Please include the string: [perl #39849] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=39849 > Problem: languages/lua doesn't compile on Win32, with the following error message. l

Re: use Tests; # ?

On 7/17/06, Ovid <[EMAIL PROTECTED]> wrote: Many people would prefer that $description always be the last thing you type and always be something you can provide. IMO if I were to write a replacement for Test::More id put the description argument first, and therby make it mandatory. And then yo

Re: use Tests; # ?

On Mon, 2006-07-17 at 11:39 +0200, demerphq wrote: > Test names shouldnt be optional. I disagree. I would find it cumbersome to have to come up with a description for each and every test. > Finding a particular test in a file by its number can be quite > difficult, especially in test files wher

The Perl 6 summary for the month of 2006-03

The Perl 6 summary for the month of 2006-03 Summary updates It was pointed out that I was unclear about URLs. I will be using long (original) URLs for web editions and short URLs for mail editions. Compiler (perl6-compiler) make error on 9188 Beau E. Cox r

Re: Lessons from the test function parameter placement quibbles?

On 7/17/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: Hi all, so by now we've had quibbles about the "irregularity" of `skip`, `can_ok` and `isa_ok`, and a suggestion that the test name always go first. Just to clarify, my main point is really that test names should be mandatory. The fact that m

Lessons from the test function parameter placement quibbles?

Hi all, so by now we’ve had quibbles about the “irregularity” of `skip`, `can_ok` and `isa_ok`, and a suggestion that the test name always go first. Conclusion? Had they been named parameters, we wouldn’t be having this discussion. And you know what? We don’t even need Test::More::NextGen to imp

Re: use Tests; # ?

On 7/17/06, Torsten Schoenfeld <[EMAIL PROTECTED]> wrote: On Mon, 2006-07-17 at 11:39 +0200, demerphq wrote: > Test names shouldnt be optional. I disagree. I would find it cumbersome to have to come up with a description for each and every test. I dont think its that cumbersome at all. Even

Re: use Tests; # ?

On 17/07/06, demerphq <[EMAIL PROTECTED]> wrote: On 7/17/06, Torsten Schoenfeld <[EMAIL PROTECTED]> wrote: > On Mon, 2006-07-17 at 11:39 +0200, demerphq wrote: > > > Test names shouldnt be optional. > > I disagree. I would find it cumbersome to have to come up with a > description for each and e

Re: Lessons from the test function parameter placement quibbles?

- Original Message From: A. Pagaltzis <[EMAIL PROTECTED]> > so by now we’ve had quibbles about the “irregularity” of `skip`, > `can_ok` and `isa_ok`, and a suggestion that the test name always > go first. Conclusion? > > Had they been named parameters, we wouldn’t be having this > discuss

Re: Lessons from the test function parameter placement quibbles?

On 17 Jul 2006, at 12:49, Ovid wrote: - Original Message From: A. Pagaltzis <[EMAIL PROTECTED]> [snip] And you know what? We don’t even need Test::More::NextGen to implement that. All functions as they stand could unambiguously accept a hashref as their single argument. That's goin

Re: use Tests; # ?

On 7/17/06, Fergal Daly <[EMAIL PROTECTED]> wrote: On 17/07/06, demerphq <[EMAIL PROTECTED]> wrote: > On 7/17/06, Torsten Schoenfeld <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-07-17 at 11:39 +0200, demerphq wrote: > > > > > Test names shouldnt be optional. > > > > I disagree. I would find it cu

Parrot Bug Summary

Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jul 17 13:10:47 2006 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with m

Re: use Tests; # ?

On 17/07/06, demerphq <[EMAIL PROTECTED]> wrote: On 7/17/06, Fergal Daly <[EMAIL PROTECTED]> wrote: > On 17/07/06, demerphq <[EMAIL PROTECTED]> wrote: > > On 7/17/06, Torsten Schoenfeld <[EMAIL PROTECTED]> wrote: > > > On Mon, 2006-07-17 at 11:39 +0200, demerphq wrote: > > > > > > > Test names sh

Re: [perl #39849] [PATCH] pmc2c: Wrap MMD initializer code in block

Am Sonntag, 16. Juli 2006 18:46 schrieb Ron Blaschke: > Possible Solution: Attached patch adds a block around the MMD > initializer code, which should bring the generated code back to valid C. Thanks, applied - r13329. leo

[svn:parrot-pdd] r13331 - in trunk: . docs/pdds

Author: allison Date: Mon Jul 17 09:49:44 2006 New Revision: 13331 Modified: trunk/docs/pdds/pdd21_namespaces.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: [pdd21]: Some wordsmithing from Patrick Michaud. Modified: trunk/docs/pdds/pdd21_namespa

[perl #39854] [PATCH] adds preamble section to tge grammar to allow for includes and global defines

# New Ticket Created by Kevin Tew # Please include the string: [perl #39854] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=39854 > adds preamble section to tge grammar to allow for includes and global defines at the top

Re: suggestions for new pdd21

Patrick R. Michaud wrote: Allison just updated pdd21, it looks great! Here's a first cut at some suggested changes and wordsmithing to the text. Feel free to adopt, ignore, or discuss any of the suggestions below as you see fit. Thanks, applied! : =item get_global : : $P1 = $P2.get_glob

Re: suggestions for new pdd21

Am Montag, 17. Juli 2006 18:52 schrieb Allison Randal: > > Since we have slurpy named parameters in Parrot, why not simply leave $P3 > > off and use (optional) named parameters here to specify options? > > Chip/Leo, do the various named parameter passing techniques work on > low-level PMC's defined

Namespace.get_namespace() vs. optional params

Looking over the recent editorial improvements in pdd21, I need to point out that, right now, if a method is written in C, it can't have optional arguments. (This is per Leo; I haven't checked into how/why this restriction arose.) Thus, to support both of these interfaces: =item get_namespace

[perl #39855] configuration: define MIN/MAX macros for all integral typedefs

# New Ticket Created by Chip Salzenberg # Please include the string: [perl #39855] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=39855 > It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of hard to wo

Re: IMCC Reentarancy

4th Option: fix flex. ;) -J -- On Sun, Jul 16, 2006 at 10:57:07PM -0500, Vishal Soni wrote: > Hi, > > Please disregard the previous mail. Hit the wrong shortcut key!! > > I have been working on trying to make reenterant and/or thread-safe. There > are couple of things that have come up which mi

Re: [perl #39854] [PATCH] adds preamble section to tge grammar to allow for includes and global defines

Kevin Tew (via RT) wrote: adds preamble section to tge grammar to allow for includes and global defines at the top of the PIR generated by TGE For example, I use preamble{ .include 'interpinfo.pasm' } You're on to an important idea, but it still needs refinement. A bit of background info

Re: use Tests; # ?

On Monday 17 July 2006 05:19, demerphq wrote: > The fact that it does the same thing every time for a given set of > input doesnt mean that it does the RIGHT thing. And i dont see how its > possible to automatically do the right thing every time. Therefore if > you need a custom wrapper you need t

Re: use Tests; # ?

- Original Message From: chromatic <[EMAIL PROTECTED]> > On Monday 17 July 2006 05:19, demerphq wrote: > > > The fact that it does the same thing every time for a given set of > > input doesnt mean that it does the RIGHT thing. And i dont see how its > > possible to automatically do the

Re: use Tests; # ?

On 17/07/06, chromatic <[EMAIL PROTECTED]> wrote: On Monday 17 July 2006 11:37, Ovid wrote: > For example, what could be done in TAP::Harness to improve the reporting on > line numbers? That alone would be a nice benefit for folks. I agree, but I disclaim the idea that there's a nice, general,

Re: use Tests; # ?

On Monday 17 July 2006 11:37, Ovid wrote: > For example, what could be done in TAP::Harness to improve the reporting on > line numbers?  That alone would be a nice benefit for folks. I agree, but I disclaim the idea that there's a nice, general, working heuristic. The best I've come up with che

TAPx::Parser 0.03

Hi all, OK, so I haven't gotten to my 0.10 roadmap yet, but the next version of my TAP parser is at http://users.easystreet.com/ovid/downloads/TAPx-Parser-0.03.tar.gz A variety of the changes listed below are precursors to allowing streams to be handled correctly. Feedback is highly sought

Re: [perl #39829] [PATCH] accept() always fails

Am Donnerstag, 13. Juli 2006 23:41 schrieb Kay-Uwe Huell: > Hi parrot, > > unfortunatly you fail when I call your accept() op. This should be fixed now with r13332 (there was some confusion about sockaddr* types and the len of these). leo

Re: suggestions for new pdd21

On Mon, Jul 17, 2006 at 09:52:35AM -0700, Allison Randal wrote: > >: =item get_global > >: > >: $P1 = $P2.get_global($S3) > >: > >: Retrieve a global variable $P1 from the namespace $P2, with the name > >: $S3. > > > >What's the meaning of "global" in this context? Some part of me > >wants t

[svn:parrot-pdd] r13335 - in trunk: . docs/pdds

Author: allison Date: Mon Jul 17 13:48:29 2006 New Revision: 13335 Modified: trunk/docs/pdds/pdd21_namespaces.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: [pdd21]: Backing out optional argument on a low-level PMC. Modified: trunk/docs/pdds/pdd

Re: Namespace.get_namespace() vs. optional params

Chip Salzenberg wrote: Looking over the recent editorial improvements in pdd21, I need to point out that, right now, if a method is written in C, it can't have optional arguments. (This is per Leo; I haven't checked into how/why this restriction arose.) Aye. This went through my mind as I made

Re: binding operators and related introspection

Darren Duncan wrote: > But I would also like to have an easy way to change all bindings to > the same variable at once to point to the same new variable. > [...] >my $x = 'foo'; >my $y = 'bar'; >my $z := $x;# $x and $z point to same 'foo', $y to a 'bar' >$z.rebind_all_aliases_

Re: IMCC Reentrancy

Vishal Soni wrote: The current implementation is implemented using Flex and YACC. Flex implementation has limitations in C mode. The C lexer generated by flex cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in C++ mode. This limition of flex will defeat the whole effort

Hyperoperators and the Each role

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Beware, here be newbie -- possible nonsense ahead.] I have a couple of questions about what S03 says about hyperoperators applying recursively to any object which matches the 'Each' role: [from S03] Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq(2,7

Re: IMCC Reentarancy

On 17 Jul 2006, at 05:22, Audrey Tang wrote: 在 2006/7/16 下午 11:57 時，Vishal Soni 寫到： I think that the lemon+re2c, being the more modern parsing tools, will make refactoring/hacking considerably easier. For future reference Ragel is definitely worth a look too: http://www.cs.queensu.ca/~th

Re: use Tests; # ?

* Fergal Daly <[EMAIL PROTECTED]> [2006-07-17 15:45]: > The standard way to do this is to put > > local $Test::Builder::Level = $Test::Builder::Level + 1; > > at the top of every function in your library that does not > actually call ->ok() use Attribute::Handlers; sub UNIVERSAL::TestHe

Re: IMCC Reentrancy

On Mon, 2006-07-17 at 14:49 -0700, Allison Randal wrote: > re2c and lemon aren't enough of an improvement over flex and bison to be > worth the pain of rewriting IMCC from scratch. If we do create a new way > of producing bytecode (and it's a safe bet that we will at some point), > I would lean

Re: IMCC Reentrancy

Vishal Soni wrote: Allison having said that we need an API for byte code generation that supports plug n play optimizers would it make sense to start implementing this layer. This API could be used for OST to byte code generation. Later when Patrick's PGE to C parser generator is ready we could

Parrot should limit its own stack usage?

From: Leopold Toetsch <[EMAIL PROTECTED]> Date: Mon, 17 Jul 2006 11:50:35 +0200 Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers: >    BTW, it doesn't seem right that I can run Parrot for only a second or > two and get more than 300K stack frames deep.  Isn't there a way to > li

Re: Hyperoperators and the Each role

At 6:06 PM -0400 7/17/06, Christopher Jeris wrote: I have a couple of questions about what S03 says about hyperoperators applying recursively to any object which matches the 'Each' role: [from S03] Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7) 1. What determines the concret

Re: IMCC Reentrancy

> Let's go for an agile, iterative approach to the spec. Write up some > initial thoughts on the shape of the API and post them to > parrot-porters. The group can do sanity-checking/brainstorming, and then > you can start a prototype based on the result. After we've played with > the prototype

RE: use Tests; # ?

I know we've moved on, but I'm in a completely different time zone, so please understand... I, like demerphq, also think that coming up with a name for each and every test is a good idea. It shouldn’t be hard to think of a description for each and every test. Just note down why you wrote that

Re: IMCC Reentrancy

Vishal Soni wrote: Allison this sounds great. To get started I will need some reference to the OST format. Can you please point me in the right direction (some documentation or sample code shall do.)? Start with languages/punie/lib/POST/ and languages/punie/lib/PIRGrammar.tg. This is the most

Source cleanup ideas (pending STM merge)

I've got a few source cleanups in mind, and I figured I'd share the ideas I have kicking around my head, and ask if anyone else has been thinking of cleanups as well. Note that I don't want to make the eventual STM merge more difficult than necessary, so I don't think we can make these cleanups ye

Re: Source cleanup ideas (pending STM merge)

On Jul 17, 2006, at 9:22 PM, Chip Salzenberg wrote: Ideas I've got: * standarizing on "interp" or maybe even "intr" as the interpreter variable, for brevity & consistency Yeah, that one's bugged me, too. I've dumped all your suggestions into cage/todo.pod. Thanks for taking the t

Re: Parrot should limit its own stack usage?

On Mon, Jul 17, 2006 at 09:26:12PM -0400, Bob Rogers wrote: >But what I really meant was: Shouldn't Parrot do a 'setrlimit' on > itself in order to detect these sorts of bugs sooner, and more usefully? > Or, maybe 'ulimit -s' would be appropriate before running test cases? Running the test su

Re: Source cleanup ideas (pending STM merge)

On Mon, Jul 17, 2006 at 09:38:22PM -0500, Andy Lester wrote: > I've dumped all your suggestions into cage/todo.pod. Thanks. That you're editing cage and herding the cage cleaners is a load off my mind. -- Chip Salzenberg <[EMAIL PROTECTED]>

Re: Source cleanup ideas (pending STM merge)

On Jul 17, 2006, at 10:03 PM, Chip Salzenberg wrote: I've dumped all your suggestions into cage/todo.pod. Thanks. That you're editing cage and herding the cage cleaners is a load off my mind. That's my job. I flap my lips a lot, stir the soup, organize it, and hand it off to other pe

Re: IMCC Reentarancy

在 2006/7/17 下午 3:41 時，Joshua Hoblitt 寫到： 4th Option: fix flex. ;) Turns out flex 2.5.30+ has a reentrant mode. However, it also has an incompatible API with earlier flex, even in non-reentrant mode. I've attached a patch under http:// rt.perl.org/rt3//Public/Bug/Display.html?id=34669 (ne

Re: IMCC Reentrancy

Audrey Tang wrote: As I'm writing this, I noticed that Allison has ruled that we go with PIR/PGE and eventually C-based libpge instead -- since a lexer refactoring that doesn't affect the IMCC API will somehow throw important projects on Parrot into a "dead stall", and thread safety for PIR c

Re: IMCC Reentrancy

在 2006/7/18 上午 1:21 時，Allison Randal 寫到： LOL :) Audrey, I love you dear, but you always have an interesting way of interpreting what I say. :) Yes, I'm not willing to start a 6+ month project to gut IMCC. The cost is too great and the benefit isn't great enough. Indeed, and I'd like to ap