On Tue, Aug 26, 2008 at 11:00 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
> jerry gay wrote:
>>>
>>> #+ and #- is lisp so I don't want to destroy #+ the syntax rules.
>>> #IF(): is quite short and easy to read.
>>>
>> i know it was all caps before, but do we need to continue that trend?
>> i find
jerry gay wrote:
#+ and #- is lisp so I don't want to destroy #+ the syntax rules.
#IF(): is quite short and easy to read.
i know it was all caps before, but do we need to continue that trend?
i find it ugly.
All-caps is the Parrot coding standard for macros and #defines, and
these fall in
On Tue, Aug 26, 2008 at 2:34 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> I'll go now for something like
>
> #IF(key1|key2&(key3&!key4))
> #IFNOT(key1|key2&(key3&!key4))
>
> And probably a shortcut for the negative else clause, like
> #IF(cygwin):
> #ELSE:
>
> #+ and #- is lisp so I don't want to d
2008/8/26 Allison Randal <[EMAIL PROTECTED]>:
>> On Mon, 25 Aug 2008, Reini Urban wrote:
>>>
>>> To clarify my bold statement:
>>> The ALGOL-like syntax is not "sane" because,
>>> * it is hard to parse,
>
> Not actually true. It's just different to parse. And, in general Parrot
> optimizes for maki
On Mon, 25 Aug 2008, Reini Urban wrote:
To clarify my bold statement:
The ALGOL-like syntax is not "sane" because,
* it is hard to parse,
Not actually true. It's just different to parse. And, in general Parrot
optimizes for making code easy to *read* even if it is slightly harder
to parse. We
On Mon, 25 Aug 2008, Reini Urban wrote:
> Reini Urban schrieb:
> > 2008/8/24 Allison Randal <[EMAIL PROTECTED]>:
> > > Reini Urban wrote:
> To clarify my bold statement:
> The ALGOL-like syntax is not "sane" because,
> * it is hard to parse,
> * it forbids our keywords AND, NOT and OR as config_h
Reini Urban wrote:
> Moritz Lenz schrieb:
>> Reini Urban wrote:
>>> Moritz Lenz schrieb:
>>>> Reini Urban wrote:
>>>>> Attached are updates to the cygwin070patches branch.
>>>>> Thanks for applying the patches!
>>>> applied as
Moritz Lenz schrieb:
Reini Urban wrote:
Moritz Lenz schrieb:
Reini Urban wrote:
Attached are updates to the cygwin070patches branch.
Thanks for applying the patches!
applied as r30543.
And this one also please.
fix cuddled else and some beautification.
Also applied (r30547).
And one
Reini Urban wrote:
In lib/Parrot/Configure/Compiler.pm, I agree that 'CONDITIONED_LINE' and
'INVERSE_CONDITIONED_LINE' aren't the clearest names, but '+' and '-' are
far less clear. Change them to something meaningful like 'SHOW_LINE_IF' and
'HIDE_LINE_IF'. We can note the change in DEPRECATED.
Reini Urban wrote:
> Moritz Lenz schrieb:
>> Reini Urban wrote:
>>> Attached are updates to the cygwin070patches branch.
>>> Thanks for applying the patches!
>>
>> applied as r30543.
>
> And this one also please.
>
> fix cuddled else and some beautification.
Also applied (r30547).
Moritz Lenz schrieb:
Reini Urban wrote:
Attached are updates to the cygwin070patches branch.
Thanks for applying the patches!
applied as r30543.
And this one also please.
fix cuddled else and some beautification.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: src/library.c
Reini Urban wrote:
> Attached are updates to the cygwin070patches branch.
> Thanks for applying the patches!
applied as r30543.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Attached are updates to the cygwin070patches branch.
Forget it. The Data.pm errors were still in.
This is better.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
cygwin070patches_3.patch.gz
Description: GNU Zip compressed data
Reini Urban schrieb:
2008/8/24 Allison Randal <[EMAIL PROTECTED]>:
Reini Urban wrote:
You want one patch only against HEAD? That's easy.
But I dislike the idea, as it violates the usage of single tickets.
This is different than the usual case as it's a collection of depend
2008/8/24 Allison Randal <[EMAIL PROTECTED]>:
> Reini Urban wrote:
>>
>> You want one patch only against HEAD? That's easy.
>> But I dislike the idea, as it violates the usage of single tickets.
>
> This is different than the usual case as it's a coll
Reini Urban wrote:
You want one patch only against HEAD? That's easy.
But I dislike the idea, as it violates the usage of single tickets.
This is different than the usual case as it's a collection of dependent
patches that can't be evaluated independently. Splitting them o
Allison Randal schrieb:
Reini Urban wrote:
Moritz Lenz schrieb:
Against which svn revision should I apply those patches for testing?
I'll try to be uptodate against HEAD with the patches in my SVN repo.
But things are changing fast over there.
config/gen/makefiles/root.in was chang
Reini Urban wrote:
Moritz Lenz schrieb:
Against which svn revision should I apply those patches for testing?
I'll try to be uptodate against HEAD with the patches in my SVN repo.
But things are changing fast over there.
config/gen/makefiles/root.in was changed by the ncigen merge yest
Moritz Lenz schrieb:
Reini Urban wrote:
> See
http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches
http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series
defines the order.
I tried to apply those patches stupidly b
Reini Urban wrote:
> See
> http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches
>
> http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series
> defines the order.
I tried to apply those patches stupidly both a
2008/8/22 Allison Randal <[EMAIL PROTECTED]>:
>> As my number of patches is too big, and the size is too big,
>> I update them only in my public SVN repo, not in the tickets anymore.
>> And the order in which they should be applied is important.
>>
>> See
>&
Reini Urban wrote:
As my number of patches is too big, and the size is too big,
I update them only in my public SVN repo, not in the tickets anymore.
And the order in which they should be applied is important.
See
http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot
2008/8/17 Reini Urban <[EMAIL PROTECTED]>:
> FYI:
> The cygwin release for parrot-0.7.0-1 will contain the following yet
> unapplied patches to make it work:
>
> (in this order from my quilt series file)
> 39742-installed-conflict.patch
> 56544-install_files.patch
&
No comments since March 16, so I'm closing the ticket.
Thanks for the update. I think I'll leave this ticket open for a few
more days in the hope that Matt and Steve comment.
2008/3/16, James Keenan via RT <[EMAIL PROTECTED]>:
> While I think the patches proposed in this ticket are moribund, the fact
> is that what little feedback we get on Cygwin indicates that many core
> tests are failing during smoke testing. See, e.g.,
>
> http://smoke
While I think the patches proposed in this ticket are moribund, the fact
is that what little feedback we get on Cygwin indicates that many core
tests are failing during smoke testing. See, e.g.,
http://smoke.parrotcode.org/smoke/parrot-smoke-0.5.3-devel-r26408-unknown--i386-cygwin-ccache-default
pancake wrote:
> (...)
> Ok, after the presentations.. I have some problems for writing the patches
> because more than one bug report matches the same source file, and i have to
> wait everytime for commits before doing anything more. I understand that this
> is my problem and I sh
presentations.. I have some problems for writing the patches
because more than one bug report matches the same source file, and i have to
wait everytime for commits before doing anything more. I understand that this
is my problem and I should be pacient, but on pdb there are a lot of broken
things that are
Will Coleda wrote:
> In *general*, yes, tickets good, so we don't lose any patches, even
> the minor ones.
>
> That said, email a list of subjects and I'll take a look. (most of
> what I see from you on the list went to parrotbug and so already has
> a ticket.)
&g
In *general*, yes, tickets good, so we don't lose any patches, even
the minor ones.
That said, email a list of subjects and I'll take a look. (most of
what I see from you on the list went to parrotbug and so already has
a ticket.)
Regards.
On Mar 12, 2007, at 10:30 PM, Sam Vi
I've submitted a set of changes to the ML for review.
Do you really want tickets for all of those changes? Some of them are
quite minor.
Sam.
Leo wrote:
> I wrote:
> > Bear with me on the VMSish filenames; "xxx;1" is the original
> > version, "xxx;" is the patched version of the file.
>
> I wrote a small perl helper, dealing with that. But what
> about filenames like:
>
> +++ lib/parrot.configure/step.pm;
>
> which actually is:
Am Montag, 4. September 2006 13:02 schrieb Vorländer, Martin:
> Bear with me on the VMSish filenames; "xxx;1" is the original
> version, "xxx;" is the patched version of the file.
I wrote a small perl helper, dealing with that. But what about filenames like:
+++ lib/parrot.configure/step.pm;
Hi,
at YAPC::EU vaxman.de bugged me to try and build Parrot on VMS.
As all I had with me was an emulated VAX on my WinXP notebook
(running VMS 7.3 and DEC C 6.0), I used that.
First I needed some time to build/test perl 5.8.8, but I think
I have it running now. Then I set out to Configure.pl Parr
Hi Folks,
As of late, particularly in the run up to 0.4.1, people seem to be
falling out of the habit of submitting patches as a parrotbug. This
could cause either real PITAs in the future where someone has to goto a
huge effort to track these things down or more likely the patches will
just
On Nov 5, 2005, at 19:37, Will Coleda (via RT) wrote:
Sending as a patch since 1) we're close to a freeze, and 2) this is
allison's code.
Allison: this patch fixes a dependency issue in the makefile,
eliminates some deprecation issues, and corrects a small issue in the
grammar that allows punie
# New Ticket Created by Will Coleda
# Please include the string: [perl #37619]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37619 >
Sending as a patch since 1) we're close to a freeze, and 2) this is
allison's code.
A
Patches floating and accumulating and I've not much time in the
foreseeable future to have a look at all. Fellow committers, please
apply locally, test, and possilby checkin patches.
Thanks,
leo
There is a long list of folks with commit rights for parrot svn. I
don't have always the time to ci @all_patches (and will not have the
next days to do so), therefore I'd really appreciate, if patches could
be reviewed, commented if needed, and *applied* w/o me too, if these
patche
Leopold Toetsch wrote:
> I can't test Win32 patches, so I can apply these only as is.
I am trying to cover this base with constant "update, build,
post-to-list, patch" cycles. ;-)
Ron
Chromatic <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-04-14 at 13:54 +0200, Leopold Toetsch wrote:
>> I'd appreciate if some folks with commit privs have a look at patches
>> accumulating on the list and apply the simple ones.
> What qualifies as "simple"?
On Thu, 2005-04-14 at 13:54 +0200, Leopold Toetsch wrote:
> I'd appreciate if some folks with commit privs have a look at patches
> accumulating on the list and apply the simple ones.
What qualifies as "simple"? I don't mind handling doc patches and the
like.
-- c
On Thursday 14 April 2005 13:54, Leopold Toetsch wrote:
> I'm currently evolving the infix operations and scalar classes and have
> rather big diffs against svn HEAD.
>
> I'd appreciate if some folks with commit privs have a look at patches
> accumulating on the list
I'm currently evolving the infix operations and scalar classes and have
rather big diffs against svn HEAD.
I'd appreciate if some folks with commit privs have a look at patches
accumulating on the list and apply the simple ones.
Thanks,
leo
The first bunch of patches is in. The visible part is a new opcode:
op get_mro(out PMC, in PMC)
This returns the array reference of the MRO (Method Resolution Order)
Array. This is basically the same as the list of ISA strings, except
that the MRO array contains class PMCs and abstract base
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> The naming of the interpreter structure has changed. The struct is
> now called "parrot_interp_t";
Thanls,
leo
The naming of the interpreter structure has changed. The struct is
now called "parrot_interp_t"; use of the typedef "Interp" is now
recommended in function declarations and definitions (e.g. C).
This will affect many pending patches. If you're working on a patch,
ple
Even if there is no special syntax, it'd be helpful if the person applying the patch fired off a
"Thanks, Applied" or some such. Saves the bugadmins the trouble of checking the source
to see if it's actually been applied or not.
Will "slogging through RT" Coleda.
William Coleda wrote:
http://rt.p
http://rt.perl.org:80/rt3//Ticket/Display.html?id=31229
Dan replied with "Applied, Thanks", but the ticket wasn't marked applied.
Is this some magic that could/should happen? Is there another way to invoke it?
(By the time you see this, I will have manually marked it applied and resolved.)
On Sat, 19 Jun 2004, Leopold Toetsch wrote:
> Ok. #30094 is applied. Could you please rediff #30320, I get rejects.
Hmm. It looks like an issue of trailing spaces on some lines. I just
tested this one, and it applied cleanly:
diff -r -u parrot-current/config/gen/makefiles/m4.in
parrot-andy/co
Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> On Thu, 17 Jun 2004, Leopold Toetsch via RT wrote:
>> Andy Dougherty <[EMAIL PROTECTED]> wrote:
>>
>> > This patch assumes my previous Configure.pl patch for c++ detection has
>> > been included.
>>
>> Which ticket number?
> Oops. Sorry to be vague -
[#30094]. Dan had already applied
several other little patches of mine, but he skipped this one, either
because he's very busy and had many other things to do or because he
didn't like it :-).
--
Andy Dougherty [EMAIL PROTECTED]
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> This patch assumes my previous Configure.pl patch for c++ detection has
> been included.
Which ticket number?
leo
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #30320]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=30320 >
This patch allows languages/m4 to build for me. It removes some
gcc-specific flags
All of the current and future changes during shifting vtable functions
to MMD and deleting vtable entries may break existing PBCs. Any change
in the current classes enums, in MMD_ constants ... basically any
change in the generated runtime/parrot/include/*.pasm files.
I'll update PBC_COMPAT aft
> I resolved #24030 and #24038 by changing the Status field and hitting
> Save Changes, then I noticed there was a Resolve option on the top
> righthand side which asks for details for a notification email. I'm
> wondering which is the approved way?
Either is fine. By default the "Resolve" pag
Reeducation succeeded.
I resolved #24030 and #24038 by changing the Status field and hitting
Save Changes, then I noticed there was a Resolve option on the top
righthand side which asks for details for a notification email. I'm
wondering which is the approved way?
I ask because I'll add a deta
> (24205) [PATCH] removing -mno-accumulate-outgoing-args for non x86 arch
>
> the last one was applied by Dan, but the Status wasn't updated on RT.
> I can't do it myself (permission denied).
I've updated the ticket.
RT thinks your email address is @perl.it, but the ticket was created
from the @
> My account (mikescott) at http://auth.perl.org/auth/account shows the
> correct email. The RT page assures me that I'm signed in as mikescott.
> I go to the Modify ticket #24030 and set Status to resolved, click Save
> Changes and get Status: Permission Denied.
RT had a different idea of what
these are the patches of mine which still show as Pending:
(17405) [PATCH] correct make pdb on Win32
(24149) [PATCH] small Makefile patch (rm *.s in realclean instead of clean)
(24205) [PATCH] removing -mno-accumulate-outgoing-args for non x86 arch
the last one was applied by Dan, but the
On 30 Oct 2003, at 07:20, Robert Spier wrote:
Some of patches on that list that are mine.
#24030 Obsolete
#24038 Obsolete
#24043 Applied
#24063 Applied
#24177 Rejected
#24188 Applied
I tried to update the status of #24177 but got Permission Denied.
Any chance of that being changed so I could
> Some of patches on that list that are mine.
> #24030 Obsolete
> #24038 Obsolete
> #24043 Applied
> #24063 Applied
> #24177 Rejected
> #24188 Applied
> I tried to update the status of #24177 but got Permission Denied.
> Any chance of that being changed so I could updat
Some of patches on that list that are mine.
#24030 Obsolete
#24038 Obsolete
#24043 Applied
#24063 Applied
#24177 Rejected
#24188 Applied
I tried to update the status of #24177 but got Permission Denied.
Any chance of that being changed so I could update them myself?
Mike
On Wednesday, Oct 22
If anyone goes through that list and provides me with a list of needed
updates (in a standardized format), I can do some bulk updates
relatively easily.
-R
Leopold Toetsch wrote:
http://www.parrotcode.org/openpatches/ shows a list of open patches
ranging from #801 up to recent ones. Some of
http://www.parrotcode.org/openpatches/ shows a list of open patches
ranging from #801 up to recent ones. Some of them are marked pending or
applied but not closed.
I'd be glad if someone could go through the list and update it so that
the actual state is reflected at that site.
I know, so
Steve Fink wrote:
Ah! So all we have to do is use discontiguous PMCs -- the first 32
bytes is at offset 0, the second at byte offset 128 or so. Then we can
interleave them, so that everything in offset 0..127 gets loaded into
the cache, but 128..255 is left untouched. (Just kidding.)
s/32/16/
On Jan-10, Leopold Toetsch wrote:
>
> You get double the amount of PMCs into the cache - used during marking
> and freeing. It isn't related to alignment, just more throughput.
Oh. You're right. I was thinking that the unused portion of the PMC
wouldn't need to be loaded into the cache, so that
Steve Fink wrote:
On Jan-09, Leopold Toetsch wrote:
So the question is, should I checked it in / partially / forget it.
Changes are:
- SPMC (small or scalar PMC) with half the size of a PMC, no promotion
or whatever to a PMC, disabled with one define in pmc.c
- pool flags with aligned pools,
On Jan-09, Leopold Toetsch wrote:
> I have here now ~15 files different to CVS, which I would like to sync
> in either direction for easier future changes.
> So the question is, should I checked it in / partially / forget it.
>
> Changes are:
> - SPMC (small or scalar PMC) with half the size of a
I have here now ~15 files different to CVS, which I would like to sync
in either direction for easier future changes.
So the question is, should I checked it in / partially / forget it.
Changes are:
- SPMC (small or scalar PMC) with half the size of a PMC, no promotion
or whatever to a PMC, disa
Steve Fink wrote:
> To expand on that: the currently commented-out dependency on
> Configure.pl in the makefile is wrong. It says the $(STICKY_FILES)
> depend only on the Configure.pl script itself, which is woefully
> incomplete:
There are a lot more dependencies, that are uncovered:
classe
On Thu, Sep 26, 2002 at 09:13:07AM -0400, Andy Dougherty wrote:
> On 26 Sep 2002, Tom Hughes wrote:
>
> > Andy Dougherty <[EMAIL PROTECTED]> wrote:
> >
> > > > The problem here is that the rule in the Makefile that causes it to
> > > > rerun Configure.pl if any of the Configure.pl genera
In message <[EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> No it's not a reset thing. I should have documented it better, though i
> thought the wod "initial" would tell it ;-)
Well I was thinking of it as initial allocation versus reallocation.
> The intlist structur
Tom Hughes wrote:
> In message [EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
>>#17549, 17569 intlist bugfix, speedup, test
> Applied.
Thanks again for all the checkins.
> One slight query I had was the meaning of the extra parameter added
> to intlist_new() by
On Thu, 26 Sep 2002, Tanton Gibbs wrote:
> What is annoying is that on my cygwin system, everytime I type make it
> rebuilds everything starting from Configure. It doesn't matter if I have
> touched anything or not. In other words
> perl Configure.pl && make
>
> will run Configure.pl twice.
Y
ginal Message -
From: "Andy Dougherty" <[EMAIL PROTECTED]>
To: "Tom Hughes" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 26, 2002 9:13 AM
Subject: Re: Status of my patches ...
> On 26 Sep 2002, Tom Hughes wrote:
>
> > An
On 26 Sep 2002, Tom Hughes wrote:
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
>
> > > The problem here is that the rule in the Makefile that causes it to
> > > rerun Configure.pl if any of the Configure.pl generated files is out
> > > of date clashes with the recently introduced edit to
In message <[EMAIL PROTECTED]>
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On 26 Sep 2002, Tom Hughes wrote:
>
> > The problem here is that the rule in the Makefile that causes it to
> > rerun Configure.pl if any of the Configure.pl generated files is out
> > of date clashes with the rec
On 26 Sep 2002, Tom Hughes wrote:
> > > #17517 build system, permanent Configure runs - annoying at least
> The problem here is that the rule in the Makefile that causes it to
> rerun Configure.pl if any of the Configure.pl generated files is out
> of date clashes with the recently introduced e
In message [EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> #17549, 17569 intlist bugfix, speedup, test
Applied.
One slight query I had was the meaning of the extra parameter added
to intlist_new() by this patch. I assume the idea is that you can call
it with a value of 0
Tom Hughes wrote:
> In message [EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
>>#17353/17323 test for Parrot_sprintf
> Applied.
Thank you.
> ... The outstanding question here is anyop.h
> and anyop.c in languages/imcc as they are not built, and seem to have
> b
would
>>be fine, if I could checkin at least the imcc changes myself, so that
>>not 3 different people send patches WRT missing commas in imcc.y.
>>
>
> I definitely vote for you to be given commit privileges. Not all of
> those patches should be applied without
In message [EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> #17353/17323 test for Parrot_sprintf
Applied.
I've also updated MANIFEST and the .cvsignore files to try and match
something approaching reality. The outstanding question here is anyop.h
and anyop.c in languages/
if I could checkin at least the imcc changes myself, so that
> not 3 different people send patches WRT missing commas in imcc.y.
I definitely vote for you to be given commit privileges. Not all of
those patches should be applied without posting them for review, but
most could be.
I see imcc a
In message <20020925234547$[EMAIL PROTECTED]>
Tanton Gibbs <[EMAIL PROTECTED]> wrote:
> > #17517 build system, permanent Configure runs - annoying at least
>
> I wish someone would commit this one as this does fix a very annoying
> problem, especially on cygwin.
Applied.
The problem he
Tom Hughes wrote:
>>#17578
> Applied.
First of all, thank you for comitting these. I hate 3-way rediff's ;-)
>>#17193 necessary for imcc to write out PBC
> Applied. Like you I don't like it much but there aren't any other
> obviously better ways.
Yes, seems so.
> I missed that when it
> #17517 build system, permanent Configure runs - annoying at least
I wish someone would commit this one as this does fix a very annoying
problem, especially on cygwin.
Tanton
In message <[EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> #17578 imcc including all fixes sent to the list except todays fix
>by Andy.
> - actually the 3rd fix summary IIRC I sent in (s. there for a list of
>patches, which are obsol
or who applies what when and why or not? This questions arises
sometimes, so I'll ask.
Here is a list of current open patches in decreasing priority:
#17578 imcc including all fixes sent to the list except todays fix
by Andy.
- actually the 3rd fix summary IIRC I sent in (s. ther
On Thu, 5 Sep 2002, Jeff wrote:
> Ewps. It was recently pointed out to me that I accidentally reversed
> #17000. The problem has been fixed, I believe. Sorry, Andy.
That's ok, it's partly my fault too. I had posted the patch hoping for
comments, but grew impatient. I knew it was a decent band-
Jeff wrote:
>
> And some more marked as committed that got missed...
> Patch #17000 -
Ewps. It was recently pointed out to me that I accidentally reversed
#17000. The problem has been fixed, I believe. Sorry, Andy.
--
Jeff <[EMAIL PROTECTED]>
Steve Fink wrote:
>
> I have applied at least one other not on your list (#17008). Should I
> be marking things as applied? I didn't think I had the permissions to
> do that, so I've just been trying to make sure I post a "Thanks,
> applied" so it gets into RT's reply set. Can I do more than that
I have applied at least one other not on your list (#17008). Should I
be marking things as applied? I didn't think I had the permissions to
do that, so I've just been trying to make sure I post a "Thanks,
applied" so it gets into RT's reply set. Can I do more than that?
committed. I'm so far just marking
> patches as 'Applied', not closing out the RT report.
>
> (NOte: I'm not claiming that I committed all of these... Most of them
> were simply committed but not marked in RT as applied...
>
> Patch #17007 - This needs to be
And some more marked as committed that got missed...
Most of the time I'm looking at http://www.parrotcode.org/openpatches/
in order to find out what needs to be committed. I'm so far just marking
patches as 'Applied', not closing out the RT report.
(NOte: I'm not clai
>I don't like spam. Thanks for keeping it out.
I try. :)
>How do you recruit new "someone"s?
I head down to the local mall and hold up a big sign.
>Are they the same sort of "someone"s who manage perl5 bugs?
Yup.
(Or just anyone silly enough to volunteer.)
>And (IIRC) Spam Assassin is th
On Wed, Jul 31, 2002 at 11:44:00PM -0700, Robert Spier wrote:
> >On Wed, Jul 24, 2002 at 08:44:20AM -0700, Stephen Rawls wrote:
> >> The last two (well, the only two :) patches I sent
> >> were counted as spam. Some of the points were becuase
>
> Sorry about that!
>On Wed, Jul 24, 2002 at 08:44:20AM -0700, Stephen Rawls wrote:
>> The last two (well, the only two :) patches I sent
>> were counted as spam. Some of the points were becuase
Sorry about that! I'm trying to be better safe than sorry in
preventing spam from getting to
John Porter writes:
>
>Aldo Calpini wrote:
>> this is a little tutorial about submitting patches
>> (should be added to a FAQ, or somewhere where it's handy
>
>I think this deserves its own page somewhere on
>dev.perl.org.
Seems like a good idea. I've ad
1 - 100 of 152 matches
Mail list logo
