Re: [PATCH] multiple heredoc beginning in the same line

it's not so difficult, really. you just gotta know the trick: - cd into the repository you want, then run "git am". - Use your mail client's "view source" function (ctrl-u in thunderbird for example). - copy the complete mail source including headers - paste it into the terminal that's running git

Re: [PATCH] multiple heredoc beginning in the same line

On Thu, Dec 01, 2016 at 10:46:17AM -0600, andy_b...@wiwb.uscourts.gov wrote: > Hmm: > $ cat /tmp/here.pl6 > my ($first, $second) = qq:to/END1/, qq:to/END2/; > FIRST > MULTILINE > STRING > END1 >SECOND >MULTILINE >STRING >END2 > say "f: $first, s: $second"; > > $ perl6 /tmp/

Re: [PATCH] multiple heredoc beginning in the same line

On Thu, Dec 01, 2016 at 10:15:03AM -0500, Will Coleda wrote: > This will be much more likely to be applied if you provide a pull > request to the repo at https://github.com/perl6/doc I agree but it was a lot simpler for me to send it by e-mail at the moment. I will perhaps try to make a pull-reque

Re: [PATCH] multiple heredoc beginning in the same line

This will be much more likely to be applied if you provide a pull request to the repo at https://github.com/perl6/doc On Wed, Nov 30, 2016 at 10:31 AM, wrote: > This is to document the fact that, as in POSIX shell, you can use > multiple HEREDOC strings in the same line. > > --- > doc/Language/

Re: [PATCH] typo fix for spec S05

On 11/22/2010 04:01 PM, Moritz Lenz wrote: Although it looks like a typo, "to vary" is indeed the correct verb here I'm not a native English speaker, so sorry for the noise.

Re: [PATCH] typo fix for spec S05

Am 22.11.2010 08:39, schrieb Hongwen Qiu: > -argument vary faster than the left. In other words, C<&&> and C<||> establish > +argument very faster than the left. In other words, C<&&> and C<||> establish Although it looks like a typo, "to vary" is indeed the correct verb here (means as

Re: [patch]: typo of perl6 book

Thanks for the patch, I've applied it. If you have a github ID, please tell me what it is -- I can add you as a committer to the book, so that you can apply such fixes directly in future. Cheers, Moritz

Re: [PATCH]: Fixed a useless test for S06-multi/type-based.t

Hi, thanks for your patch, I've applied it as r30579. Hongwen Qiu wrote: > I wonder if the patches for test files should go here. No, you should commit them directly to the pugs repository. Please tell me your desired nickname, and I'll set up commit permissions for you. Cheers, Moritz

Re: patch for t/spec/s06-multi/type-based.t

On Fri, 2009-08-21 at 14:24 +1100, Илья wrote: > -multi foo (@bar) { "Array " ~ join(', ', @bar) } > -multi foo (%bar) { "Hash " ~ join(', ', %bar.keys.sort) } > +multi foo (@bar) { "Positioanl " ~ join(', ', @bar) } > +multi foo (%bar) { "Associative " ~ join(', ', %bar.keys.sort) } Typo in thi

Re: [PATCH] Add .trim method

On 2009 Jan 12, at 15:17, Ovid wrote: " בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ לְעוֹלָם וָעֶד." If you can't see that in your client, that's Hebrew from http://www.i18nguy.com/unicode/shma.html and means "Hear O Israel, the Lord is our God, the Lord is One". Actually that's the res

Re: [PATCH] Revised .trim patch

Ovid wrote: > Seems Larry's agreed to the .trim method. There are bits that are not agreed > upon, so this patch only implements what we've agreed upon. It relies on the > new S29-str/trim.t test in pugs. I committed that earlier and updated > t/spectest.data. > > > In other words, the pat

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 6:26 PM, Ovid wrote: > - Original Message > > > From: jason switzer > > > If we wanted language dependent version, use :leading, :trailing, and > :both. > > That will require each implementation properly handle the language > > variations. > > I think :start and :

Re: [PATCH] Add .trim method

- Original Message > From: jason switzer > If we wanted language dependent version, use :leading, :trailing, and :both. > That will require each implementation properly handle the language > variations. I think :start and :end are my favorites. Huffman++ (maybe :begin and :end for c

Trimming; left or start? (was: Re: [PATCH] Add .trim method)

Can I make a suggestion? From my point of view, it'd be nice if the trim method supported: - left/right (leftmost/rightmost part of the string; language-independent) - start/end (start and end of string; could be leading/trailing instead) - both How would that work?

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 9:07 AM, jesse wrote: > > 'left' and 'right' are probably not the right names for functions which > trim leading and/or trailing space, since their meanings get somewhat > ambiguous if a language renders right-to-left instead of left-to-right > or vice-versa > I'm in favo

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 4:19 PM, Aristotle Pagaltzis wrote: > Maybe :h and :t (head/tail). I like the echo of the csh pathname modifiers there. Unless that confuses people into thinking that .trim has something to do with pathname canonicalization... -- Mark J. Reed

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 06:36:55PM +0100, Moritz Lenz wrote: : Carl Mäsak wrote: : > Jonathan (>), Ovid (>>), Larry (>>>): : Can't say I really like the negated options though. They smell funny. : >>> : >>> Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. : >>> Sugge

Re: [PATCH] Add .trim method

Carl Mäsak wrote: > Jonathan (>), Ovid (>>), Larry (>>>): Can't say I really like the negated options though. They smell funny. >>> >>> Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. >>> Suggestions welcome as I can't think of anything better. >> >> The .Net framew

Re: [PATCH] Add .trim method

On Jan 12, 2009, at 11:27 AM, Carl Mäsak wrote: How about .trim(:start) and .trim(:end)? And .trim(:both) for orthogonality. -- Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance

Re: [PATCH] Add .trim method

Ovid wrote: $string.trim(:leading<0>); $string.trim(:trailing<0>); Setting leading or trailing to false (they default to true) would result in either leading or trailing whitespace not being trimmed Alternatively, those could be ltrim() and rtrim(). If you need to dynamically de

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 9:01 AM, Ovid wrote: > - Original Message > > > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). If you need to > dynamically d

Re: [PATCH] Add .trim method

- Original Message > From: Aristotle Pagaltzis > * Austin Hastings [2009-01-12 22:00]: > > How about .trim(:l, :r) with both as the default? > > Liveable. I've just committed the pugs tests for trim. However, it's just 'trim' with no left/right, leading/trailing, Catholic/Protestant

Re: [PATCH] Add .trim method

* Austin Hastings [2009-01-12 22:00]: > How about .trim(:l, :r) with both as the default? Liveable. > And if the rtl crowd makes a furor, we can add :a/:o or :ת/:א > or something. *grin* Maybe :h and :t (head/tail). > Useful for doing infrequent things. IMO, left and right > trimming are inf

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 22:05]: > I see your point And now I see yours. I was visualising the memory layout of a string, wherein a right-to-left string gets displayed from the right end of it’s in-memory representation so “left” and “right” are absolutes in that picture. But of course RTL reverses the

Re: [PATCH] Add .trim method

* Larry Wall [2009-01-12 21:55]: > * Aristotle Pagaltzis [2009-01-12 21:20]: > > Plus if there are separate `.ltrim` and `.rtrim` functions it > > would be better to implement `.trim` by calling them rather > > than vice versa, so it wouldn’t even be less efficient two > > make two calls rather t

Re: [PATCH] Add .trim method

- Original Message > From: Aristotle Pagaltzis > > I like Jonathan's trim_start and trim_end. > > Let me ask you first: does a string that runs Right-to-Left start > at the left and end at the right or start at the right and end at > the left? > > Now to answer your question, *I* know

Re: [PATCH] Add .trim method

Aristotle Pagaltzis wrote: Actually that makes me wonder now whether it’s actually a good idea at all to make the function parametrisable at all. Even `.ltrim.rtrim` is shorter and easier than `.trim(:start,:end)`! How about .trim(:l, :r) with both as the default? And if the rtl crowd makes

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 09:18:03PM +0100, Aristotle Pagaltzis wrote: : Plus if there are separate `.ltrim` and `.rtrim` functions it : would be better to implement `.trim` by calling them rather than : vice versa, so it wouldn’t even be less efficient two make two : calls rather than a parametrised

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 21:20]: > Since that's RTL (Right To Left) text, should ltrim remove the > leading or trailing whitespace? > > I like Jonathan's trim_start and trim_end. Let me ask you first: does a string that runs Right-to-Left start at the left and end at the right or start at the right and

Re: [PATCH] Add .trim method

* Aristotle Pagaltzis [2009-01-12 20:55]: > Also `:!start` to imply `:end` unless `:!end` (which in turn > implies `:start` unless `:!end`)? Ugh, forget this, I was having a blank moment. Actually that makes me wonder now whether it’s actually a good idea at all to make the function parametrisab

Re: [PATCH] Add .trim method

- Original Message > Also `:!start` to imply `:end` unless `:!end` (which in turn > implies `:start` unless `:!end`)? > > I’d like not to have to type `.trim(:start)` when I could just do > `.ltrim` though. So what would .ltrim do with this? " בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ לְע

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 2:50 PM, Aristotle Pagaltzis wrote: > I'd like not to have to type `.trim(:start)` when I could just do > `.ltrim` though. As long as we gloss .ltrim as "leading" trim rather than "left" trim. Then the other end could be .ttrim for "trailing"? We really ought to avoid usi

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 18:40]: > 1. No params, trim all > 2. :start or :end, only trim that bit (not a negated option :) > 3. If both, goto 1 Also `:!start` to imply `:end` unless `:!end` (which in turn implies `:start` unless `:!end`)? I’d like not to have to type `.trim(:start)` when I could ju

Re: [PATCH] Add .trim method

Larry Wall wrote: On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: : ...the trivial $string.trim and trim($string) case. Hmm, I'd think .trim should work like .chomp, and return the trimmed string without changing the original. You'd use $str.=trim to do it in place. Can't say I really li

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 09:33:32AM -0800, Geoffrey Broadwell wrote: : That of course raises the question of how one *would* properly override : trim's concept of whitespace Well, given that .trim is essentially just .comb(/\S.*\S/), which in turn is really just m:g/(\S.*\S)/, I don't see much

Re: [PATCH] Add .trim method

- Original Message > >> Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. > >> Suggestions welcome as I can't think of anything better. > > > > The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does > > both). So maybe trim_start and trim_en

Re: [PATCH] Add .trim method

- Original Message > From: Geoffrey Broadwell > When I saw your proposed syntax above, instead of reading "don't trim > leading/trailing whitespace", I read "change the definition of > 'whitespace' to 'codepoint 0' for leading/trailing". > > That of course raises the question of how on

Re: [PATCH] Add .trim method

On Mon, 2009-01-12 at 07:01 -0800, Ovid wrote: > - Original Message > > > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). If you need to > dynamica

Re: [PATCH] Add .trim method

Jonathan (>), Ovid (>>), Larry (>>>): >>> Can't say I really like the negated options though. They smell funny. >> >> Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. >> Suggestions welcome as I can't think of anything better. > > The .Net framework calls 'em TrimStart an

Re: [PATCH] Add .trim method

Ovid wrote: - Original Message In the pir, doesn't the "s = self" line copy self, thus ensuring that I'm changing "s" and not "self"? No, it's binding. Or do I need "s = clone self" (or however it's written). Yeah, but also note that substr would return a copy... Can't sa

Re: [PATCH] Add .trim method

- Original Message > From: Larry Wall > On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: > : ...the trivial $string.trim and trim($string) case. > > Hmm, I'd think .trim should work like .chomp, and return the trimmed > string without changing the original. You'd use $str.=trim t

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: : ...the trivial $string.trim and trim($string) case. Hmm, I'd think .trim should work like .chomp, and return the trimmed string without changing the original. You'd use $str.=trim to do it in place. Can't say I really like the negated optio

Re: [PATCH] Add .trim method

On 2009-01-12 Ovid wrote: > Um, er. Damn. Now I'm wondering how my "leading" and "trailing" > trimming works with Hebrew. How are the strings implemented > internally? RTL (and bidi) languages are written in strings so that the character order is the logical, reading, order. That is, the chara

Re: [PATCH] Add .trim method

- Original Message > From: jesse > > On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: > > > > > I could optionally make the following work: > > > > > > > > > > $string.trim(:leading<0>); > > > > > $string.trim(:trailing<0>); > > > > Alternatively, those could be ltrim() and rtri

Re: [PATCH] Add .trim method

Aristotle Pagaltzis wrote: * Ovid [2009-01-12 16:05]: Or all could be allowed and $string.trim(:leading<0>) could all $string.rtrim internally. ++ Note you can write it :!leading too. :-) Jonathan

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 16:05]: > Or all could be allowed and $string.trim(:leading<0>) could all > $string.rtrim internally. ++ Regards, -- Aristotle Pagaltzis //

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). 'left' and 'right' are probably not the right name

Re: [PATCH] Add .trim method

- Original Message > > > I could optionally make the following work: > > > > > > $string.trim(:leading<0>); > > > $string.trim(:trailing<0>); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set va

Re: [PATCH] Add .trim method

- Original Message > > =item trim > > > > our Str multi Str::trim ( Str $string ) > > > > Removes leading and trailing whitespace from a string. > > > > =cut > > > > I could optionally make the following work: > > > > $string.trim(:leading<0>); > > $string.trim(:trailing<0>); >

Re: [PATCH] Add .trim method

Ovid (>): > =item trim > > our Str multi Str::trim ( Str $string ) > > Removes leading and trailing whitespace from a string. > > =cut > > I could optionally make the following work: > > $string.trim(:leading<0>); > $string.trim(:trailing<0>); > > Setting leading or trailing to false (the

Re: [PATCH] Add .trim method

- Original Message > From: Ovid > > This patch implements the .trim() method for strings. > > Now that I'm reading S29, I see there is no .trim() method there. I got that > because it was referenced in pugs in the cookbook (not in tests, though) and > I > was trying to get the exam

Re: [PATCH] Add .trim method

- Original Message > This patch implements the .trim() method for strings. Now that I'm reading S29, I see there is no .trim() method there. I got that because it was referenced in pugs in the cookbook (not in tests, though) and I was trying to get the examples to run. Bummer :( C

Re: Patch for split(thing, delimiter) function

Chris Davaz wrote: > Moved the split function from Str.pir to any-str.pm and removed the > Perl6Str coercion. Thanks, applied as r31265. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/

Re: [PATCH][perl #58030] Bugfix of "Named parameter passing errors"

On Sun, Aug 17, 2008 at 9:20 AM, mhelix <[EMAIL PROTECTED]> wrote: > The first named parameter isn't set if optional parameters are missing. The > function Parrot_process_args didn't > save the value of the argument. I used memcpy to copy the UnionVal. If > there's a neater way to do that please

Re: [PATCH] added links to dotnet/doc/contents.pod

Reini Urban wrote: Attached patch adds links to external dotnet ressources Jonathan mentioned (his paper, the specs), and the implementations. Jonathan should approve it because it links to a bad poem on VM's in his paper on page 1. No ticket because it's so simple. Thanks. This was applied

[perl #58628] Re: [ PATCH ] Broken link on parrotcode.org dev page - list item "Parrot Testing Status"

# New Ticket Created by Allison Randal # Please include the string: [perl #58628] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58628 > Ronald Schmidt wrote: > I applied for an account and built what seems to me to be an a

Re: [ PATCH ] Broken link on parrotcode.org dev page - list item "Parrot Testing Status"

Ronald Schmidt wrote: I applied for an account and built what seems to me to be an appropriate Parrot Testing Status page. My proposed link target is http://www.parrot.org/wiki/some-testing-status-tools . If someone wants to set me up as a site editor I will fix the link myself otherwise the

Re: [PATCH] cygwin070patches_10

Reini Urban wrote: > My daily cygwin070patches branch patch for my dear friend moritz. > Today on the menu: > * Fix hard tabs in languages/tcl/lib/Tcl/Test.pm from yesterday > * overhaul dotnet Configure + make > * add current novell mono path to dotnet test Applied as r30765, thanks. Moritz --

Re: [PATCH] cygwin070patches_9

Reini Urban wrote: > for the cygwin070patches branch: > > * fix a perlcritic test for Compiler.pm > * add DESTDIR to languages make install and test-installable > * fix forth and tcl build/installed seperation and fixed pbc destination paths > * make builds the default targets, all builds all. > *

Re: [PATCH] cygwin070patches_6+7.patch

On Fri, Aug 29, 2008 at 11:56 AM, Allison Randal <[EMAIL PROTECTED]> wrote: > Reini Urban wrote: >> >> I hope you know that this #+() syntax is the only existing syntax. >> It is widely used since about 20 years. >> The rest is something new we came up with. > > It's high time for a little progress

Re: [PATCH] cygwin070patches_6+7.patch

Reini Urban wrote: I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. It's high time for a little progress. Sheesh, in 1988 we were excited by computers with 1 MB of RAM. ;) Allison

Re: [PATCH] cygwin070patches_6+7.patch

Allison Randal schrieb: Reini Urban wrote: A new idea: === #IF(darwin): #ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X #ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@ Just a little too much complexity, for not enough benefit. The POD for this change: Looks good.

Re: [PATCH] cygwin070patches_4.patch

Reini Urban wrote: A new idea: === #IF(darwin): #ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X #ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@ Just a little too much complexity, for not enough benefit. The POD for this change: Looks good. For legacy the old synta

Re: [PATCH] more packages

On Thu, Aug 28, 2008 at 2:37 PM, Reini Urban <[EMAIL PROTECTED]> wrote: > Will Coleda schrieb: >> >> On Sun, Aug 24, 2008 at 12:26 PM, Moritz Lenz >> <[EMAIL PROTECTED]> wrote: >>> >>> Reini Urban wrote: 2008/8/23 François Perrad <[EMAIL PROTECTED]>: > > 2008/8/23 Allison Randal <

Re: [PATCH] cygwin070patches_5.patch

Reini Urban wrote: > Moritz Lenz schrieb: >> Reini Urban wrote: >>> My latest patch against the cygwin070patches branch r30596. >> >> applied as 30597 > > Thanks! > And one more. Applied as 30599, as far as it would. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/

Re: [PATCH] cygwin070patches_4.patch

Reini Urban wrote: > My latest patch against the cygwin070patches branch r30596. applied as 30597 Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/

Re: [PATCH] ports/cygwin for 0.7.0-1

Reini Urban wrote: > patch -p0 -N < ports-cygwin.patch > cd ports/cygwin > svn rm postinstall.sh preremove.sh parrot-0.6.4-2.cygport > parrot-0.6.4-2.src.patch > svn add parrot-0.7.0-1.cygport parrot-0.7.0-1.src.patch > parrot-0.7.0-1.cygwin.patch > svn ci -m'ports/cygwin for 0.7.0-1' > > Thanks.

Re: [PATCH] Help catching gc errors in HLL

On Mon, Jun 2, 2008 at 7:18 PM, chromatic <[EMAIL PROTECTED]> wrote: > I like the general idea, but I wonder if there's something cleaner than an > environment variable. Nothing really comes to mind at the moment besides > making argument processing even uglier in IMCC's main.c. > > Let's think a

Re: [PATCH] Re: [perl #57386] Configure.pl tests create bad dirs in $TMP

On Wednesday 30 July 2008 12:10:32 Andy Dougherty wrote: > Yes, but we might as well clean up the other two cases as well. So this > goes on top of yours: > > --- parrot-svn/t/steps/auto_icu-01.t 2008-07-30 15:05:43.0 -0400 > +++ parrot-x86/t/steps/auto_icu-01.t 2008-07-30 15:06:34.

Re: [PATCH] Re: [perl #57386] Configure.pl tests create bad dirs in $TMP

On Wed, 30 Jul 2008, chromatic wrote: > On Wednesday 30 July 2008 11:20:33 Andy Dougherty wrote: > > > Ahh -- it's just an octal/decimal mix-up. Here's the patch: > > > > --- parrot-current/t/steps/auto_icu-01.t2008-07-30 13:45:19.0 > > -0400 +++ parrot-andy/t/steps/auto_icu-01.t 200

Re: [PATCH] Re: [perl #57386] Configure.pl tests create bad dirs in $TMP

On Wednesday 30 July 2008 11:20:33 Andy Dougherty wrote: > Ahh -- it's just an octal/decimal mix-up. Here's the patch: > > --- parrot-current/t/steps/auto_icu-01.t 2008-07-30 13:45:19.0 > -0400 +++ parrot-andy/t/steps/auto_icu-01.t 2008-07-30 14:15:44.0 > -0400 @@ -228,7 +2

Re: [PATCH] suggestion for the file "grammar.pg"

Hello, here same output: First a test with pugs Version: 6.2.13 (r17105) which use STD.pm [EMAIL PROTECTED] ~]$ pugs -e 'my $a=.2; say $a' 0.2 [EMAIL PROTECTED] ~]$ pugs -e 'my $a=E+3' *** No such subroutine: "&E" at -e line 1, column 3 - line 2, column 1 [EMAIL PROTECTED] ~]$ The secon

Re: [PATCH] suggestion for the file "grammar.pg"

STD.pm was updated to handle leading dot in Num constants, thus we now have (in both rakudo's grammar and STD.pm): token escale { <[Ee]> <[+\-]>? \d+ } # careful to distinguish from both integer and 42.method token dec_number { [ |'.' \d+[_\

Re: [PATCH] suggestion for the file "grammar.pg"

On Fri, Jul 04, 2008 at 12:15:24AM +0200, Moritz Lenz wrote: > Hi, > > Gerd Pokorra wrote: > > I suggest the little attached patch (diff -u) for the file > > "languages/perl6/src/parser/grammar.pg", so that the following code > > > > my $a = .2; > > > > will also be accepted from Rakudo. > > Bu

Re: [PATCH] suggestion for the file "grammar.pg"

Hi, Gerd Pokorra wrote: > I suggest the little attached patch (diff -u) for the file > "languages/perl6/src/parser/grammar.pg", so that the following code > > my $a = .2; > > will also be accepted from Rakudo. But does the language specification allow it? I don't think so, and STD.pm (after whi

Re: patch that causes imcc to hang

Patrick R. Michaud wrote: > As I noted online and in the Perl 6 design meeting earlier today, > the attached patch (applied to r28973) causes imcc to hang > while building rakudo at the step > > ../../parrot -o perl6.pbc perl6.pir > > This step never completes -- in fact, I inadvertently le

Re: [perl #56282] Re: [PATCH] Re: design problem with :outer

Based on discussion earlier today in #parrotsketch, here's the detailed specification for resolving outer subs using :lexid . If someone wants to fold this into pdd20 somehow (on or about line 233), that would be especially helpful. Every Parrot subroutine that serves as a lexical outer

[perl #56282] Re: [PATCH] Re: design problem with :outer

# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #56282] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56282 > On Mon, Jun 23, 2008 at 09:33:43PM -0500, Patrick R. Michaud wrote: > On Mon, Jun

[perl #56284] Re: [PATCH] Re: design problem with :outer

# New Ticket Created by chromatic # Please include the string: [perl #56284] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56284 > On Monday 23 June 2008 21:56:54 Patrick R. Michaud wrote: > Alas, the patch doesn't seem t

Re: [PATCH] Re: design problem with :outer

On Monday 23 June 2008 21:56:54 Patrick R. Michaud wrote: > Alas, the patch doesn't seem to hold when loading things from > precompiled bytecode -- e.g., running perl6.pbc versus perl6.pir. > > So, the patch I submitted appears to be incomplete, and > now I need to figure out how :outer is resolve

Re: [PATCH] Re: design problem with :outer

On Mon, Jun 23, 2008 at 09:33:43PM -0500, Patrick R. Michaud wrote: > On Mon, Jun 23, 2008 at 06:27:31PM -0500, Patrick R. Michaud wrote: > > There appears to be a fundamental design problem in Parrot's > > current implementation of :outer. The short summary is that > > :outer("sub_name") doesn't

[perl #56166] Re: [PATCH] Perl::Critic Version Wrong

On Fri Jun 20 09:01:56 2008, [EMAIL PROTECTED] wrote: > prove -v t/codingstd/perlcritic.t > t/codingstd/perlcritic..Undefined subroutine > &Perl::Critic::Policy::NamingConventions::ProhibitAmbiguousNames::default_forbidden_words > called at t/codingstd/perlcritic.t line 142. > Dubious, test r

[perl #56166] Re: [PATCH] Perl::Critic Version Wrong

# New Ticket Created by Will Coleda # Please include the string: [perl #56166] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56166 > Sending this to parrotbug to open a ticket... On Wed, Jun 18, 2008 at 2:00 PM, Ovid <[EM

Re: [PATCH] Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in

On Sat, 14 Jun 2008, chromatic via RT wrote: > On Tuesday 07 August 2007 10:11:20 Andy Dougherty wrote: > > > This next patch does a little more cleanup on the attributes checking. I > > revised config/auto/attributes.pm to use the existing Configure routines > > cc_build() and conf->data_add()

[perl #55772] Re: [PATCH] more tests for spectest_regression

# New Ticket Created by Jerry Gay # Please include the string: [perl #55772] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55772 > On Sat, Jun 14, 2008 at 4:08 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote: > > Attached patch

Re: [PATCH] Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in

On Tuesday 07 August 2007 10:11:20 Andy Dougherty wrote: > This next patch does a little more cleanup on the attributes checking. I > revised config/auto/attributes.pm to use the existing Configure routines > cc_build() and conf->data_add() rather than re-implementing them. I also > removed some

Re: [PATCH] more tests for spectest_regression

On Sat, Jun 14, 2008 at 4:08 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote: > > Attached patch adds three more test files (list builtins). > > The last two tests in joint. are likely to be wrong, and are fudged as > such. Further clarification is welcome. > > More on that in a separate mail. > thanks,

Re: [PATCH] Help catching gc errors in HLL

On Monday 02 June 2008 07:58:57 NotFound wrote: > Previous version generates a warning when building with C, fixed now. I like the general idea, but I wonder if there's something cleaner than an environment variable. Nothing really comes to mind at the moment besides making argument processing

Re: [PATCH] Help catching gc errors in HLL

Previous version generates a warning when building with C, fixed now. -- Salu2 Index: src/runops_cores.c === --- src/runops_cores.c (revisión: 28033) +++ src/runops_cores.c (copia de trabajo) @@ -242,13 +242,28 @@ opcode_t * runo

Re: [PATCH] more regression tests for rakudo

Moritz Lenz wrote: Attached patch adds a few more files to the 'make spectest_regression' target. All of them pass. Applied in r27783. Thanks! Jonathan

Re: [PATCH] refactor rakudo's t/harness

On Thu, May 22, 2008 at 06:07:39PM +0200, Moritz Lenz wrote: > As a follow-up to r27708 I refactored rakudo's t/harness. > This patch basically morphs the --regression-only option into a more > general option -- tests-from-file. If you provide a file with a list of > file names, only those files wi

Re: [PATCH] rakudo: make target 'spectest_regression'

On Wednesday 21 May 2008 08:07:18 Moritz Lenz wrote: > I just noticed that I screwed up one of the path names, attached patch > fixes that. Thanks, applied as r27737. -- c

Re: [PATCH] rakudo: make target 'spectest_regression'

Jonathan Worthington wrote: > Moritz Lenz wrote: >> rakudo's "make spectest" suffers from too much noise in its output. >> >> The attached patch adds a spectest_regression target to Makefile that >> uses whitelisting to run only those tests that are known to pass. >> > This is really useful! App

Re: [PATCH] rakudo: make target 'spectest_regression'

Moritz Lenz wrote: rakudo's "make spectest" suffers from too much noise in its output. The attached patch adds a spectest_regression target to Makefile that uses whitelisting to run only those tests that are known to pass. This is really useful! Applied in r27708, thanks. :-) Jonathan

Re: [PATCH] [rakudo] factor out a large chunk of method scope_declarator

Moritz Lenz wrote: While reading through actions.pm I found that method scope_declarator wasn't very readable because it was very long. A big part of that is the declaration of attributes which needs some special handling. The attached patch moves that code to a separate function called declare

Re: [PATCH] Re: [perl #53264] [PATCH] Re: [svn:parrot] r27144 - in trunk: include/parrot src src/pmc

On Friday 25 April 2008 10:49:19 Andy Dougherty wrote: > Ok.  Fixed.  This version avoids both type-punning and cast alignment > warnings by declaring the 'data' element of a Stack_Chunk_t to be > of type Stack_Entry_t, since that's the only way it is ever used, > at least as far as I could tell.

Re: [PATCH] Rearrange PObj Struct Members

On Mon, 28 Apr 2008, Andy Dougherty wrote: > On Sun, 27 Apr 2008, chromatic wrote: > > > Here's another proposed patch for testing on various platforms. I'm trying > > to > > get rid of some dodgy casts (which likely don't help C++ and processors > > with > > stricter alignment than 32-bit x

Re: [PATCH] Rearrange PObj Struct Members

On Mon, 28 Apr 2008, chromatic wrote: > On Monday 28 April 2008 10:24:37 Andy Dougherty wrote: > > > On Sun, 27 Apr 2008, chromatic wrote: > > > > /* Parrot Object - base class for all others */ > > > typedef struct pobj_t { > > > +Parrot_UInt flags; > > > UnionVal u; > > > -Parro

Re: [PATCH] Rearrange PObj Struct Members

On Monday 28 April 2008 11:19:08 Mark Glines wrote: > chromatic <[EMAIL PROTECTED]> wrote: > > I had a similar problem on my 32-bit Linux system, until I added this > > part of the patch: > > > > === src/gc/smallobject.c > > == > > --

Re: [PATCH] Rearrange PObj Struct Members

On Mon, 28 Apr 2008 11:05:45 -0700 chromatic <[EMAIL PROTECTED]> wrote: > I had a similar problem on my 32-bit Linux system, until I added this > part of the patch: > > === src/gc/smallobject.c > == > --- src/gc/smallobject.c. (rev

  1   2   3   4   5   6   7   8   9   10   >