PGE error?
Hi,
I don't know what happens and where in the code, but... Anyway, it's
strange... I have this code and input.tpl:
--- 8 ---
rule sp {
[ ]
}
rule id {
[a..z][a..z0..9]+
}
sub do($match) {
say $match[0];
return +;
}
my $template=slurp('input.tpl');
$template ~~
s:g!
[ \ server \: (id) [sp+ $?id:=(id) sp*=sp*(-[]*)]*
sp* \ (.*?) \\/ server \: $0 \ ]
|
[ \ server \: (id) [sp+(id)sp*=sp*(-[]*)]* sp* \/\ ]
!{ do($/) }!;
say $template;
--- 8 ---
text
server:foo /
server:huh /
text
server:boo inside server:huh / inside /server:boo
text
--- 8 ---
Running it several times, one time works: matches and replaces /
things to +-es, one time it not works... Randomly. Where should I send
these kind of bugs?
Bye,
Andras
q:e/.../ as a short cut for eval q/.../
-- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: PGE error?
BÁRTHÁZI András skribis 2005-06-10 10:29 (+0200): Running it several times, one time works: matches and replaces / things to +-es, one time it not works... Randomly. Where should I send these kind of bugs? If you have any means of testing this with PGE directly (without Pugs), do so. Otherwise, just report the bug (commit a test script) with Pugs and it'll find the right party eventually (of course with some help of the people coding Pugs). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: q:e/.../ as a short cut for eval q/.../
David Formosa (aka ? the Platypus) skribis 2005-06-10 9:32 (-): Interesting. Could you provide some more information, like perhaps a message body? I personally don't think string eval should be made too easy|simple. We don't want to end up with people thinking we upgraded Tcl. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: State of Design Documents
On Fri, Jun 10, 2005 at 12:51:15PM -0400, Joshua Gatcomb wrote: I know that decisions are subject to change but having the current state of decisions in a single location (Synopses) would be a great benefit to all. I am a firm believer in not complaining unless you have an idea about how to solve the problem, so here goes: Put the design documents into public change control. Read access to be granted globally with write access to be limited to @larry initially. The community posts patches where the bulk of the work is done and @larry makes any necessary modifications and commits. If even that work load proves to be too much, perhaps common mortals get granted commit access on a case-by-case basis. This already exists -- the design documents are all available from http://svn.perl.org/perl6/doc/trunk . And I've already volunteered to review/apply patches to the design documents or forward them to the appropriate people for review -- there just haven't been a lot of patches submitted. (p6l and/or p6c are probably appropriate forums for this.) Pm
Re: State of Design Documents
On 6/10/05, Patrick R. Michaud [EMAIL PROTECTED] wrote: This already exists -- the design documents are all available from http://svn.perl.org/perl6/doc/trunk . And I've already volunteered to review/apply patches to the design documents or forward them to the appropriate people for review -- there just haven't been a lot of patches submitted. (p6l and/or p6c are probably appropriate forums for this.) Ok, admittedly I was playing a bit dumb. I knew about the repository I just didn't think it was general knowledge. I was also unaware that patches had been requested with a volunteer to act as the approving authority. Hmmm. Thanks. I guess I will have to go back over the questions I have asked and see if any decisions were rendered not relfected in docs and be a pioneer. Pm Cheers, Joshua Gatcomb a.k.a. L~R
Re: State of Design Documents
On 6/10/05, Joshua Gatcomb [EMAIL PROTECTED] wrote: Hmmm. Thanks. I guess I will have to go back over the questions I have asked and see if any decisions were rendered not relfected in docs and be a pioneer. Ok, are there any guidelines for what should and should not be put forward as a patch. I can see 3 key areas of concern: 1. Framework for unwritten Synopses (so we know what goes where) 2. Heading placeholders for written Synopses with missing information 3. Decisions rendered by @larry (or should it only be $larry) on the list that are not yet in the corresponding Synopsis I have included a sample framework for chapter 17. Theoretically, someone could then go search the archives for decision points in any of those headings and fill in the blanks. Is this what you envisioned or were you thinking only minor tweaks to existing documents? Cheers, Joshua Gatcomb a.k.a. L~R S17.pod Description: Binary data
