> I think the data will support the idea that a directory structure based
on OS/CPU is probably not the way to start.
>
Quite possibly. The proposed file could suffer from the same combinatorial
explosion, if not properly structured. Does anyone have a good idea of the
most economical structure for
> We need to provide a way to access and change a class' inheritance
> hierarchy. Also, classes need a way to override the hierarchy at
> class construction time.
Resolved by the new object implementation. Runtime access to the
inheritance hierarchy is provided through the 'parents' method and
'in
In the old METHODs I'm converting on the pdd17pmc branch, a number of
them have a void return signature (now simply no return value), and use
void returns to bail out early on exceptional conditions. As in:
if (!foo)
return;
But, PCCMETHODs don't currently provide a way of handling exp
> Long term, Configure system should be replaced with a bootstrapping
> miniparrot system.
At some point after the 1.0 release, we'll decide how to eliminate the
Perl 5 dependency from the build system. That may be with miniparrot, it
may not. Either way, it's too far in the future to keep an acti
[EMAIL PROTECTED] wrote:
A possible scheme might be a directory hierarchy matching the OS/CPU
combination, e.g. Linux/x_86, Linux/i_64, Solaris/Sparc, containing dummy
files whose names match the processes NOT to be run for that environment.
(The precise structure would depend on which combinati
Hello folks,
I've recently set up a buildbot buildmaster that watches the parrot
SVN repo and does a build when a change is committed to the trunk or
one of the branches.
You can see the status page at:
http://buildbot.eigenstate.net:8040/(newest results at the top)
Builds run only
Matthew Walton wrote:
I wouldn't agree with that at all. I think of arrays as ordered constructs,
so I'd want the default iteration over my array to happen in the order of
the indices.
I guess that depends on whether you think of the array as a list or as a
ram. I know that a group at microso
I have been working my way through the individual configuration step
classes over the past eight months, refactoring mainly to increase
testability, but also for logic where the logic appeared confused (or
was confusing to me!). Suggestions for improvements in particular
configuration step classes
Over the past eight months I and others have done some tweaking of the
command-line options (and much work on the code behind the options).
Since no particulars are described in this RT, I think we can resolve
the ticket.
Thank you very much.
kid51
On Sun Oct 02 05:22:08 2005, [EMAIL PROTECTED] wrote:
> config/gen/makefiles/root.in already weighs in at 1581 lines. It needs
> to be divided up into smaller files that are combined when Configure is
> run.
>
Apart from the fact that it's a PITA to edit a file which, since Oct
2005, has swelled
A log would be useful if it contained sufficient information to figure
out why a test passed or failed. Similar to autoconf's config.log (an
invaluable debugging tool when tracking down configuration problems).
-J
--
On Fri, Jan 11, 2008 at 12:51:11PM -0800, James Keenan via RT wrote:
> Can some
Hey, gang! Can anyone comment on the status of this ticket?
I agree that if a test file is 2400 lines long, there's a prima facie
case for splitting it into smaller components.
However, based on my experience and ptc's in cage-cleaning, I'd
recommend opening up individual RTs for test files that
On Wed Feb 21 05:47:29 2007, kjs wrote:
> On Wed May 24 05:26:22 2006, coke wrote:
> > New addmethod opcode needs tests.
> >
> > --
> > Will "Coke" Coleda
> > [EMAIL PROTECTED]
> >
> >
> Attached a patch that adds a test for "addmethod".
>
Coke: Did this patch DWYM?
What was Parrot::Configure::Step has largely been refactored into
Parrot::Configure::Compiler. If particular methods need improvement, we
should file new RTs specific to each.
Resolving ticket.
kid51
Can someone describe more specifically what we would need in a log file?
As I have been working my way through the writing of tests for the
configuration step classes since June, I have had occasion to merge or
split steps. Example: gen::cpu and auto::cpu were merged into
auto::cpu and placed in the gen::cpu's former place in the config step
sequence.
Also, ptc split
Comments deleted in r24764. Ticket resolved.
S06 says that we need to say "eager" if (@in === @out). So:
@data ==> eager map { $^x + 1 } ==> @data.
Is it possible to modify a feed operator using the assignment
meta-operator described in S02 and, if so, is the "eager" implict?
@data ==>= map { $_ + 1 };
On Sun Jan 08 21:12:48 2006, [EMAIL PROTECTED] wrote:
> But wait until we've figured out exactly wait we want to list for CPAN
> to index. Perhaps we can use/steal Module::Build's logic.
>
> -J
>
Joshua: I see that we've had a META.yml file in the distro since you
implemented it in Jan 2006. I
Springing out of the ashes (and a job where I have to write Java) for my
first post in years:
On Fri, 04 Jan 2008 13:13:11 -0800, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I agree that adding a parallel "forall" (and similar statements) via a
> pragma will be easy if the appropriate underlying mach
On Wed Feb 14 16:38:10 2007, coke wrote:
> Turns out the bug isn't quite what I described. You need to use --
> linkflags to specify for the linker: when doing this, the library is
> correctly found in a full run of Configure.pl
>
> For some reason, specifying ccflags/ldflags is enough when run
The testing of the configuration execution classes (Parrot::Configure,
Parrot::Configure::Compiler, etc.) and the individual configuration step
classes (init::*, inter::*, auto::* and gen::*) has improved
considerably since June. (See coverage results at
http://thenceforward.net/parrot/coverage/co
No complaints over the past 7 weeks, so I'm resolving the ticket.
kid51
On Fri, 2008-01-11 at 10:34 -0800, Dave Whipp wrote:
> Matthew Walton wrote:
>
> > I wouldn't agree with that at all. I think of arrays as ordered constructs,
> > so I'd want the default iteration over my array to happen in the order of
> > the indices.
>
> I guess that depends on whether you th
On Fri, Jan 11, 2008 at 01:56:44PM -0800, Dave Whipp wrote:
> S06 says that we need to say "eager" if (@in === @out). So:
>
> @data ==> eager map { $^x + 1 } ==> @data.
>
>
> Is it possible to modify a feed operator using the assignment meta-operator
> described in S02 and, if so, is the "eager"
Joshua Hoblitt implemented this:
r14047 | jhoblitt | 2006-08-12 15:36:03 -0400 (Sat, 12 Aug 2006) | 2 lines
bug #39860 - autoconf compatible install options
Resolving ticket.
On Thu Jul 26 19:22:57 2007, particle wrote:
> while typing
> perl Configure.pl --nomanicheck ---verbose-step=init::gcc
> --configure_trace
>
> earlier today in order to debug a configure-related problem i was
> having, i felt --configure_trace was too much to type.
>
particle: Are you still
Larry Wall wrote:
As for assignment-op forms, in the current "STD" grammar, feeds are
not currently even considered operators, but statement separators, so
there is no possibility of using them in an assignment metaoperator
(or any other metaoperator, for that matter).
Feeds as a reduction cou
On Fri, Jan 11, 2008 at 03:59:00PM -0800, Dave Whipp wrote:
> Larry Wall wrote:
>
>> As for assignment-op forms, in the current "STD" grammar, feeds are
>> not currently even considered operators, but statement separators, so
>> there is no possibility of using them in an assignment metaoperator
>>
On Friday 11 January 2008 16:44:58 [EMAIL PROTECTED] wrote:
> Author: jkeenan
> Date: Fri Jan 11 16:44:58 2008
> New Revision: 24767
>
> Added:
>trunk/t/configure/113-auto_msvc-04.t (contents, props changed)
> Modified:
>trunk/MANIFEST
>trunk/config/auto/msvc.pm
>trunk/t/configur
Final stage -- elimination of 'args' element in each config step class's
_init() routine -- accomplished in r24769. No damage to 'make test'.
Resolving ticket.
Internals of this step's runstep() were refactored into internal
subroutines, which were then unit-tested in additional test files. I
have narrowed the scope of the SKIP block in 113-auto_msvc-01.t to
simply the test of the runstep() method. Test coverage is high.
Resolving ticket.
On Thu Jan 03 16:24:50 2008, [EMAIL PROTECTED] wrote:
> Applied a combination of Andy's patch and mine in r24516.
No complaints or failure reports in that period, so I'm closing ticket.
The puzzling comment and verbosity setting were eliminated in r22195
back on Oct 17 2007 -- but I overlooked this ticket until now.
There doesn't happen to be any verbose output available from the first
four configuration steps. Perhaps that is somehow connected to the
puzzling comment.
In any e
The Buildbot has detected a failed build of Parrot-Builder-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/Parrot-Builder-trunk/builds/35
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: parrot-bot1
Build Reason:
Build Source Stamp: HEAD
B
James,
> However, based on my experience and ptc's in cage-cleaning, I'd
> recommend opening up individual RTs for test files that would benefit
> subdividing. That way, we can more easily identify which test files
> have been refactored and which remain to be done.
Given the way we currently se
36 matches
Mail list logo
