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
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
Fixed parrot_debugger test in r29508
--
Salu2
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
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
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
Can somebody give me a working link on how to installs pugs or parrot on
win xp?
I have downloaded from http://jnthn.net/perl6/ both
http://jnthn.net/perl6/pugs-win32.zip
http://jnthn.net/perl6/parrot-win32.zip
after extracting the pugs-win32..
I tried to double-click on pugs.exe but I got th
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
>
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
# New Ticket Created by Chris Fields
# Please include the string: [perl #56970]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56970 >
Attached is a (very simple) patch for a match() implementation (method
version of m//)
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #56976]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56976 >
State variables need to be implemented, the tests are already there in
S04-declarations/s
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
# 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
Comments on irc confirms the problems are solved. Closing ticket.
> 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
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
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 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
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 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
On Sun, Jul 13, 2008 at 02:17:10PM -0500, Adrian Kreher wrote:
: Hi,
:
: I'm reviewing the tests in S09, and the file
: t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0]
: indexing format interchangeably with [0;0].
:
: These two formats mean two different things, correct
On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote:
: Today bacek++ implement complex logarithms in rakudo, and one of the
: tests failed because it assumed the result to be on a different complex
: plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected).
:
: Should we standa
On Sun, Jul 13, 2008 at 12:46:30PM +0200, TSa (Thomas Sandlaß) wrote:
: HaloO,
:
: I know that the hot phase of the operator discussions are over.
: But here's a little orthogonalizing idea from my side. The observation
: is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5
: and **
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
>
> 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
I have submitted a simple 'match' implementation for rakudo (method
version of m//, RT#56970) and ran into an odd issue. The current
version of match which works uses a tail call:
.sub 'match' :method
.param pmc x
.return x.ACCEPTS(self)
.end
If I try the following:
.sub 'match' :m
# 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
Hi,
The 0.6.3 parrot packages with libparrot0 and libparrot-devel,
plus parrot-perl6 and parrot-languages are now available with
the Cygwin distribution.
Parrot is a virtual machine designed to efficiently compile and
execute bytecode for interpreted languages.
Parrot is a target for the upcomin
On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote:
> I have submitted a simple 'match' implementation for rakudo (method
> version of m//, RT#56970) and ran into an odd issue. The current
> version of match which works uses a tail call:
>
> .sub 'match' :method
> .param pmc x
>
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
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.
>
Larry Wall wrote:
> On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote:
> : Today bacek++ implement complex logarithms in rakudo, and one of the
> : tests failed because it assumed the result to be on a different complex
> : plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expect
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
Jon Lang wrote:
> Larry Wall wrote:
>> On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote:
>> : Today bacek++ implement complex logarithms in rakudo, and one of the
>> : tests failed because it assumed the result to be on a different complex
>> : plane. (log(-1i) returned 0- 1.5708i, while
# 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
Author: larry
Date: Wed Jul 16 12:56:34 2008
New Revision: 14563
Modified:
doc/trunk/design/syn/S04.pod
Log:
[S04] another whack at defining consistent closure semantics
Modified: doc/trunk/design/syn/S04.pod
==
---
Moritz Lenz wrote:
> Jon Lang wrote:
>> By the principle of least surprise, I'd recommend against this. Most
>> programmers, when they see 'sqrt(1)', will expect a return value of 1,
>
> And that's what they get unless they write it as sqrt(1 + 0i).
I suppose that you _could_ use the programmer's
# 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 "Carl Mäsak"
# Please include the string: [perl #57014]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57014 >
Both
$ ./perl6 -e '1'
and
$ ../../parrot perl6.pbc -e '1'
give the error output
Lex
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57018]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57018 >
Both
$ ./perl6 -e ''
and
$ ../../parrot perl6.pbc -e ''
send rakudo into REPL mode,
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
Jon Lang wrote:
> Moritz Lenz wrote:
>> Jon Lang wrote:
>>> By the principle of least surprise, I'd recommend against this. Most
>>> programmers, when they see 'sqrt(1)', will expect a return value of 1,
>>
>> And that's what they get unless they write it as sqrt(1 + 0i).
>
> I suppose that you _
Carl Mäsak (via RT) wrote:
> Both
>
> $ ./perl6 -e ''
>
> and
>
> $ ../../parrot perl6.pbc -e ''
Also -e 0
> send rakudo into REPL mode, whereas
>
> $ perl -e ''
>
> doesn't.
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Let's worry about getting principal values, branch cuts and handling signed
zeros correct before dealing with the interaction of junctions and multi-valued
complex functions.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Moritz Lenz wrote:
> If the programmer errs on what he thinks is in a variable, it'll always
> be a bug.
Yes; but some bugs are easier to make, and harder to catch, than others.
> Principle of least surprise:
>
> Suppose sqrt(1) returns any(1, -1):
> if sqrt($x) < 0.5 { do something }
>
> I can s
Minor typo:
On 2008 Jul 16, at 15:56, [EMAIL PROTECTED] wrote:
+(again, conceptually at the entry to the outer lexical scope, but
+possible deferred.)
sub foo {
"possibly"
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,t
Author: larry
Date: Wed Jul 16 15:53:34 2008
New Revision: 14564
Modified:
doc/trunk/design/syn/S04.pod
Log:
typo from Brandon++
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(orig
It seems like my smiley went completely whoosh...
Larry
# 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, 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 >
>
>
Mark Biggar wrote:
> Let's worry about getting principal values, branch cuts and handling signed
> zeros correct before dealing with the interaction of junctions and
> multi-valued complex functions.
Indeed.
> BTW, two good references on this that we might want to plagiarizer.I mean
> borr
On 2008 Jul 16, at 18:48, Jon Lang wrote:
Moritz Lenz wrote:
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) < 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who
tries
to debug that code, and doesn't know about junctions. It j
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 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, 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 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
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, 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
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
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
Author: larry
Date: Wed Jul 16 23:26:04 2008
New Revision: 14565
Modified:
doc/trunk/design/syn/S04.pod
Log:
clarification suggested by Bob Rogers++
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/
On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote:
On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote:
I have submitted a simple 'match' implementation for rakudo (method
version of m//, RT#56970) and ran into an odd issue. The current
version of match which works uses a tail ca
On Jul 16, 2008, at 5:45 PM, Chris Fields wrote:
On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote:
On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote:
I have submitted a simple 'match' implementation for rakudo (method
version of m//, RT#56970) and ran into an odd issue. The
Author: larry
Date: Wed Jul 16 23:52:23 2008
New Revision: 14566
Modified:
doc/trunk/design/syn/S04.pod
Log:
suggestion from moritz++ that POST blocks be allowed to see the return value
Modified: doc/trunk/design/syn/S04.pod
===
Chris Fields wrote:
> On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote:
>
>> On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote:
>>> I have submitted a simple 'match' implementation for rakudo (method
>>> version of m//, RT#56970) and ran into an odd issue. The current
>>> version
66 matches
Mail list logo
