>
> The patch attached tackles these two steps in the process. I'll apply
> it in 2-3 days unless someone objects, then proceed to step (3).
>
Patch applied to trunk in r24673.
In r24672, considerable refactoring of guts of runstep() to make it more
testable. This was done along same lines as in RT 43312
(config/auto/gmp.pm) and, in fact, some code in common was refactored
out into new Parrot module Parrot::Configure::Step::Methods. The stub
test file t/configure/144-au
At 8:41 AM -0800 1/7/08, Paul Hodges wrote:
A small tangent that might be relevant -- what's the current convention
for, say, putting several related "packages" in the same file?
I do that frequently in my Perl modules, and so do modules like DBI.
I believe that it is a good idea to do some pa
On Mon, Jan 07, 2008 at 05:23:36PM -0800, Dave Whipp wrote:
> The tests in S02 L
> appear to assume that an interpolated hash renders its keys in a sorted
> order. But this property doesn't seem to be stated in the text. Is it true
> that the keys are always sorted for interpolation?
No, the te
Dave Whipp wrote:
> The tests in S02 L
> appear to assume that an interpolated hash renders its keys in a sorted
> order. But this property doesn't seem to be stated in the text. Is it
> true that the keys are always sorted for interpolation? (is it possible,
> in P6, for hash keys to not be compar
The tests in S02 L
appear to assume that an interpolated hash renders its keys in a sorted
order. But this property doesn't seem to be stated in the text. Is it
true that the keys are always sorted for interpolation? (is it possible,
in P6, for hash keys to not be comparable?)
Author: larry
Date: Mon Jan 7 16:02:31 2008
New Revision: 14483
Modified:
doc/trunk/design/syn/S02.pod
Log:
paste-os noticed by David Green++
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.po
On Monday 07 January 2008 12:05:43 Geoffrey Broadwell wrote:
> The problem is the -O and -j options, and their interaction with other
> things. -O (== -O1) and -O2 are both supposed to alter the default
> runcore selection (according to the running doc, at least). Turns out
> they don't, but it'
On Mon, 2008-01-07 at 11:51 -0800, chromatic via RT wrote:
> On Monday 07 January 2008 08:18:24 Geoffrey Broadwell wrote:
> > It seems like this should be available from interpinfo in PIR ... and
> > since 'parrot -v' displays optimization information, it should probably
> > display the runcore cho
# New Ticket Created by Stuart Jansen
# Please include the string: [perl #49490]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49490 >
Implement WIN & FAIL. Finish ifthen implementation. Add MEBBE test to
t/03-if.t
diff --
On Monday 07 January 2008 09:22:43 robby wrote:
> With skimming across the past 400 or so messages on this list I'm not
> exactly sure if this would be the correct list to post this, but I have
> a quick question regarding NCI's and callbacks.
>
> I've read http://www.parrotcode.org/docs/pdd/pdd16
max.
With skimming across the past 400 or so messages on this list I'm not
exactly sure if this would be the correct list to post this, but I have
a quick question regarding NCI's and callbacks.
I've read http://www.parrotcode.org/docs/pdd/pdd16_native_call.htm and
nci.t and I haven't came up with
On Mon, Jan 07, 2008 at 08:22:34PM +0100, herbert breunung wrote:
> if we take TimTowtdi strictly, the anser would be yes :)
Just as in Perl 5, you can say "goto $label", with no guarantees
on efficiency.
> sorry for nagging but my question about existence of ($min, $max) =
> @array.minmax also
HAI
BTW Thanks, applied in r24660!
KTHXBYE
On Mon, Jan 07, 2008 at 02:05:18PM -0500, Trey Harris wrote:
> And mix the role in to $*OS. Then call $*OS.trytolink() to get the proper
> behavior at the proper time.
Imagine a Beowulf cluster of those, and now $*OS might even point to
thread-specific data.
Larry
On Jan 7, 2008 11:50 AM, chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 07 January 2008 08:18:24 Geoffrey Broadwell wrote:
>
> > There is no way from PIR to determine the current runcore, and it does
> > not appear in the output of 'parrot -v'. According to particle:
> >
> > *
> > in c you c
On Monday 07 January 2008 08:18:24 Geoffrey Broadwell wrote:
> There is no way from PIR to determine the current runcore, and it does
> not appear in the output of 'parrot -v'. According to particle:
>
> *
> in c you can look at interp->run_core, so you can find it with gdb easily
> it's easy
On Monday 07 January 2008 08:42:06 Trey Harris wrote:
> Then we can have roles that describe cross-cutting behavior of various
> OS's (like POSIX):
>
> my &trytolink;
> give $?OS {
> when OS::HasSymlinks { &trytolink := &*symlink; }
> when OS::HasLinks { &trytolink := &*link;
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #49480]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49480 >
There is no way from PIR to determine the current runcore, and it does
not appear
if we take TimTowtdi strictly, the anser would be yes :)
sorry for nagging but my question about existence of ($min, $max) =
@array.minmax also seems vaporized.
cheers
herbert
On 1/7/08, Trey Harris wrote:
In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
May I suggest the following extension to the 'use ' pragma, viz.
use in
Oh please, no.
The entire point of the wording currently in the synopsis is so that
we can have platform-independent locatio
In a message dated Mon, 7 Jan 2008, Larry Wall writes:
On Mon, Jan 07, 2008 at 11:42:06AM -0500, Trey Harris wrote:
So $?OS isn't "the type of OS", it's *the OS*, and you can manipulate the
OS through it.
Note that $?OS is the OS that is-or-was running at compile time,
whereas $*OS is the OS r
On Jan 7, 2008 1:34 PM, Richard Hainsworth <[EMAIL PROTECTED]> wrote:
snip
> Definitely a good idea for the implementation / implementors to decide
> how to get a resource magically.
>
> But ...
> I have run into situations where I wanted to have more control over
> where specific resources were lo
In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
Yet, does my proposal *force* this? Is it not possible for the magical
resource locator to coexist with a mechanism to allow local control?
Yes--through C blocks and munging, you can get whatever
complicated, platform- or machine-
On Mon, Jan 07, 2008 at 11:42:06AM -0500, Trey Harris wrote:
> So $?OS isn't "the type of OS", it's *the OS*, and you can manipulate the
> OS through it.
Note that $?OS is the OS that is-or-was running at compile time,
whereas $*OS is the OS running right now (at run time). Those don't
have to b
Trey Harris wrote:
In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
May I suggest the following extension to the 'use ' pragma, viz.
use in as constrained by local system>
Oh please, no.
The entire point of the wording currently in the synopsis is so that
we can have platform
Sorry, quoting myself...
In a message dated Mon, 7 Jan 2008, Trey Harris writes:
given $?OS {
when m:i:/win/ { use Foo in WinFoo.pm }
when m:i:/nix/ { use Foo in UnixLikeFoo.pm }
}
It strikes me that $?OS and $?OSVER should probably not be strings (as
they now are in Pugs) and shoul
A small tangent that might be relevant -- what's the current convention
for, say, putting several related "packages" in the same file?
In p5, I might write a great Foo.pm that loads Foo::Loader.pm and
Foo::Parser.pm and Foo::Object.pm; I'd usually drop them into seperate
files and have one load t
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #49458]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49458 >
examples/c/nanoparrot.c can be compiled with any of three different
runloops. The
In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
May I suggest the following extension to the 'use ' pragma, viz.
use in constrained by local system>
Oh please, no.
The entire point of the wording currently in the synopsis is so that we
can have platform-independent location o
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Jan 7 14:00:03 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with mo
May I suggest the following extension to the 'use ' pragma, viz.
use in constrained by local system>
For justification, see below.
There were some hot replies to what I thought was a fairly
trivial question. A corollary perhaps of an observation in "Parkinsons
Law" - people on committees arg
Allison Randal wrote:
François and I have been writing over each other's commits on
src/atomic/gcc_x86.c, so before I edit again, let's figure out the right
way to edit.
Andy, the headerizer dies with an error when src/atomic/gcc_x86.c has
two functions that are marked with both PARROT_API an
34 matches
Mail list logo
