Moritz Lenz wrote:
NotFound wrote:
To open another can of worms, I think that we can live without
character set specification. We can stablish that the character set is
always unicode, and to deal only with encodings.
We had that discussion already, and the answer was "no" for several reasons
On Wednesday 16 July 2008 19:54:57 James Keenan via RT wrote:
> This module is written in Perl 5 and is called in a program written in
> Perl 5. In the work I've done in this project, I've taken the approach
> to return values which I think is more Perlish, namely, if a subroutine
> completes and
On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> This module is written in Perl 5 and is called in a program written in
> Perl 5. In the work I've done in this project, I've taken the approach
> to return values which I think is more Perlish, namely, if a subrouti
This module is written in Perl 5 and is called in a program written in
Perl 5. In the work I've done in this project, I've taken the approach
to return values which I think is more Perlish, namely, if a subroutine
completes and does what you wanted it to, it should return a true value.
A bare ret
On Wed Jul 16 19:25:46 2008, coke wrote:
>
> Attached is a patch which passes all tests by removing the tests for
> the explicit true value of these methods.
>
Coke: I don't think we should accept this patch, for the simple reason
that I think the changes made to lib/Parrot/Ops2c/Utils.pm were b
On Wed, Jul 16, 2008 at 9:53 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Wed Jul 16 16:56:20 2008, coke wrote:
>> > I suspect that the merger/committer failed either to run 'perl
>> > Configure.pl --test' or 'make buildtools_tests' prior to 'make'.
>>
>> I can't remember the last time I
On Wed Jul 16 18:53:05 2008, [EMAIL PROTECTED] wrote:
>
> So if you really think lib/Parrot/Ops2c/Utils.pm could be better
> designed while achieving the same functionality, have a go at it!
But in the short run I would recommend simply reverting to the last
prior version of the module. I sus
On Wed Jul 16 16:56:20 2008, coke wrote:
> > I suspect that the merger/committer failed either to run 'perl
> > Configure.pl --test' or 'make buildtools_tests' prior to 'make'.
>
> I can't remember the last time I ran these particular test targets, so
> that's easy (for me) to forgive.
>
(Well,
On Wed, Jul 16, 2008 at 7:31 PM, via RT James Keenan
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by James Keenan
> # Please include the string: [perl #57026]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=57026 >
>
>
# New Ticket Created by James Keenan
# Please include the string: [perl #57026]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57026 >
r29522 | bernha
On Wed, 2008-07-16 at 10:04 -0700, Reini Urban wrote:
> Remove
>/usr/runtime/parrot/include
>/usr/runtime/parrot
>/usr
> paths from the .include searchpath.
+1 for not adding these to the searchpath by default.
(We shouldn't do something messed up like adding them in one place, and
th
# New Ticket Created by Reini Urban
# Please include the string: [perl #57006]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57006 >
---
osname= cygwin
osvers= 1.5.25(0.15642)
arch= cygwin-thread-multi-64int
cc= gcc
# New Ticket Created by Reini Urban
# Please include the string: [perl #56996]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56996 >
---
osname= cygwin
osvers= 1.5.25(0.15642)
arch= cygwin-thread-multi-64int
cc= gcc
On Wed, Jul 16, 2008 at 2:51 PM, Will Coleda via RT
<[EMAIL PROTECTED]> wrote:
> On Wed Jul 16 10:23:50 2008, Whiteknight wrote:
>> Is this still an issue? A quick check of src/embed.c shows that there is
>> no function Parrot_call_sub. Has it been moved to some other location,
>> or is it gone ent
On Wed Jul 16 10:23:50 2008, Whiteknight wrote:
> Is this still an issue? A quick check of src/embed.c shows that there is
> no function Parrot_call_sub. Has it been moved to some other location,
> or is it gone entirely? If it's completely gone, then this ticket is
> moot and should be closed.
>
Is this still an issue? A quick check of src/embed.c shows that there is
no function Parrot_call_sub. Has it been moved to some other location,
or is it gone entirely? If it's completely gone, then this ticket is
moot and should be closed.
--Andrew Whitworth
# New Ticket Created by Christoph Otto
# Please include the string: [perl #56988]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56988 >
There are too many tickets in Parrot's queue that aren't concrete about what's
needed
>
> The desired behavior is creating the file if not present or his number
> is outdated, not touching it if the number is already correct.
>
At 29516, that seems to be what it's doing
--
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
Is this still not resolved? This ticket has not seen any discussion
since 2006. To double-check, I think we need people to check
t/op/trans.t on:
*Solaris
*OpenBSD
*NetBSD
*Cygwin
If it passes all these platforms, I think the ticket is resolved. If
not, maybe we need to break this into more-speci
# New Ticket Created by Reini Urban
# Please include the string: [perl #56998]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56998 >
---
osname= cygwin
osvers= 1.5.25(0.15642)
arch= cygwin-thread-multi-64int
cc= gcc
On Wed, Jul 16, 2008 at 2:31 AM, Reini Urban via RT
<[EMAIL PROTECTED]> wrote:
> 2008/7/15 Reini Urban <[EMAIL PROTECTED]>:
>> Will Coleda via RT schrieb:
>>>
>>> On Tue May 13 05:21:32 2008, rurban wrote:
2008/5/13 Andrew Whitworth via RT >>> [EMAIL PROTECTED]>:
>
> is this ticke
Author: bernhard
Date: Wed Jul 16 08:34:11 2008
New Revision: 29522
Modified:
trunk/docs/pdds/pdd22_io.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/PBC_COMPAT
trunk/compilers/pirc/src/pirutil.c
trunk/docs/book/ch08_reference.pod
trunk/ed
On Wed, Jul 16, 2008 at 1:13 AM, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> NotFound wrote:
>>> * Unicode isn't necessarily universal, or might stop to be so in future.
>>> If a character is not representable in Unicode, and you chose to use
>>> Unicode for everything, you're screwed
>> There are pro
On Wed, Jul 16, 2008 at 1:12 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> I think this new subroutine could use some refactoring:
Yes, my goal was to fix the problem as fast as possible, and I'm not
very fluent with perl.
> If no one gets to this today I will try to work on this this even
On Wed, Jul 16, 2008 at 12:45 AM, <[EMAIL PROTECTED]> wrote:
> I just ran a test on XP-Home (using Strawberry Perl) after updating to
> r29495. Configure.pl creates the file (whether or not it was present), but
> the value appears to be a constant 0. (Make test and perl6 have no
> effect.)
Pleas
> I fixed the problem in r29488, but I don't have any windows
> environment available to test.
>
I just ran a test on XP-Home (using Strawberry Perl) after updating to
r29495. Configure.pl creates the file (whether or not it was present), but
the value appears to be a constant 0. (Make test and pe
Comments on irc confirms the problems are solved. Closing ticket.
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #56968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56968 >
I found this today while looking for error-reporting functions. The
function src/war
On Mon Feb 13 13:05:01 2006, [EMAIL PROTECTED] wrote:
> all PMCs (src/pmc/*.pmc) should be tested. the basic types, as defined
> in PDD17 (docs/pdds/clip/pdd17_basic_types.pod) should be given higher
> priority, so tests should be developed first to cover these.
>
> not surprisingly, basic types h
This error hasn't been duplicated in nearly three months, and nobody
else has commented on it. I'm marking this one resolved for now.
--Andrew Whitworth
On Wed Jul 09 00:04:45 2008, [EMAIL PROTECTED] wrote:
> r29183 adds a test to t/pmc/array.t that exposes some brokenness in
> the Array
> PMC's freeze/thaw code path. I added the test because it looked like
> Array's
> freeze/thaw/visit code had no test coverage. It turns out that
> list_visit
>
Confirmed fixed on windows in r29509.
--
tjh
On Jul 16, 2008, at 5:02 AM, NotFound wrote:
On Wed, Jul 16, 2008 at 6:08 AM, Tim Heckman <[EMAIL PROTECTED]>
wrote:
Starting in r29489, .parrot_current_rev contains "0" instead of
the revision
number.
I was using a simplified way to call svn
I think this new subroutine could use some refactoring:
30 sub update {
31 my $prev = _get_revision();
32 my $revision = _analyze_sandbox();
33 if (defined ($prev) && ($revision ne $prev)) {
34 $revision = 'unknown' unless defined $revision;
35
On Wed, Jul 16, 2008 at 6:08 AM, Tim Heckman <[EMAIL PROTECTED]> wrote:
> Starting in r29489, .parrot_current_rev contains "0" instead of the revision
> number.
I was using a simplified way to call svn info avoiding locale
dependencies, and forgot to replace with a more generic way.
Fixed in r295
Fixed parrot_debugger test in r29508
--
Salu2
Bernhard Schmalhofer schrieb:
Does this mean that all release managers should be in the PARROTRE group?
If so, somebody should check that this is indeed the case.
Judging from https://pause.perl.org/pause/authenquery, I'm no member
in PARROTRE. **
Sorry, I misread https://pause.perl.org/pause/a
chromatic schrieb:
https://pause.perl.org/pause/authenqueryI
It's only a CPAN indexing issue. Whenever a release manager uploads a new
bundle, he or she needs to change permissions for all new indexed modules to
allow the PARROTRE group to upload new versions. Unless/until you're a
release m
37 matches
Mail list logo
