Re: the future of testing
> 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 the exceptions? I do like the idea of
embedding conditions in data rather than code structures, though.
> Instead, one might consider generating that list of exclusions based on
the actual results of running Configure.pl. The program that generated
that skip list might consist of lines like
>
> print "t/op/64bit.t" unless $PConfig{intvalsize} == 8;
>
Or "touch x.t if some_state". As the problems of maintaining lists of
filenames have already been solved, it seems a shame not to use well-known
tools like ls, rm, diff, and their friends.
--
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
[perl #31030] [DESIGN] Get access to a class' hierarchy
> 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 'inspect' vtable function. Modification of the hierarchy is provided through the 'add_parent' and 'remove_parent' vtable functions and 'add_parent' method. The inheritance hierarchy can be set at class construction time with the 'parents' initialization attribute. Allison
void returns from PCCMETHODs
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 explicit void returns. An implicit void return (falling thorough to the end of the method with no explicit return) jumps to the 'no_return:' label at the end of the generated method. So, I've added a feature (in the branch) to lib/Parrot/Pmc2c/PCCMETHOD.pm that parses a PCCRETURN with the signature 'void' and generates the same jump code as an implicit void return. Allison
[perl #31136] [TODO] build - Replace configure with miniparrot
> 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 active TODO ticket. Closing. Allison
Re: the future of testing
[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 combination required the fewest cases; it's dictated by the data.) Overall, I don't think directory divisions are the way we want to go. For tests, you're mostly running the same tests on all architectures, and over time you want to move toward no skips on any platforms. So, it's best to keep the permanent directory structure reflecting a logical grouping of tests by feature, rather than the temporary categorization of which tests to skip. For configuration, you're generally running a series of checks to find out what the particular architecture/compiler/etc combination will support. Some file-based divisions are in order (e.g. using a different set of threading headers on windows than on linux), but the configuration process itself is better divided as a logical grouping of checks (as it currently is). Does this sound plausible and portable enough to be worth prototyping? We'll leave prototyping for after the 1.0 release. (For now we're keeping development efforts focused on the milestones for that release.) Allison
continuous integration server (buildbot) for parrot?
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 on the slave machine(s), not on the build master. My current configuration does 'make test' and not 'make smoke' because Test::Model::TAP fails to install on my system. BuildBot (http://buildbot.net/trac) is specifically designed to have an arbitrary number of build slaves on different machines, for testing different architectures. I am wondering if there is interest in setting up a central buildbot master on perl.org and asking the community to contribute slaves? Adding a slave is fairly easy. A slave needs to be able to see the SVN repo and the master. If anyone wants to experiment they can add one on a machine they control now and I will add it on my buildmaster - but in the long term my server is probably not the best place for the build master. Once you have installed buildbot itself you can create a slave that talks to my build master with: buildbot create-slave /path/to/slave/directory \ buildbot.eigenstate.net:9987 SLAVE_NAME PASSWORD We'll have to communicate offline for SLAVE_NAME and PASSWORD Some buildbot notes and links to docuemntation can be fond here: http://perl-qa.hexten.net/wiki/index.php/Buildbot#Installing_and_Configuring_BuildBot --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
Re: Sequential bias in S04 (and Perl6 in general)
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 microsoft added a ParallelArray datatype (ftp://ftp.research.microsoft.com/pub/tr/TR-2005-184.pdf) to C# as a way to distinguish the intent (they speed up data-parallel code by compiling it down to your GPU/graphics card). Perl6, being an operator-oriented language, associates the distinction with the operators rather than with the datatype. This is probably a better approach, but it does mean that you need an operator whenever you want to treat the array as data-parallel. (BTW, data-parallel arrays differ from bags in that they have an ordered index that is preserved across unordered operations) I think you're leaning too far towards concurrency in attempting to address the perceived bias. Probably true ... though I think that the bias is real, it's just a question of if its a good-bias or a bad-bias. Under these circumstances, I would much rather have to explicitly say that I want parallel execution - provided that the ability to do it is there and it's easy to get at and behaves in a sensible manner (naturally this lets you parallelise things the compiler isn't sure are safe to parallelise due to possible side effects. That's fine, since you know which side effects are okay to do that to in your program). Of course, it's not necessarily true that "you know" that something is safe -- often "you think" it's safe but then you get an intermittent failure at runtime,. I would love to be able to tell the compiler "I think this is safe" and have it tell me "you're wrong" as a compile-time error (this is one of the things that an explicit type system is good for). But perhaps Perl is too dynamic a language for that.
[perl #37926] [TODO] build - step cleanup
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 can be filed under the RTs for the various steps (though many are now classified as Resolved because the test coverage is good enough). So I think we can resolve this ticket. Thank you very much. kid51
[perl #37931] [TODO] build - Configure.pl option cleanup
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
[perl #37324] [TODO] build - root.in makefile split-up
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 to 2258 lines, is there a strong reason to split root.in up into smaller components? For instance, do particular Parrot developers tend to edit only in small parts of the file that are specific to their tasks? If so, then we have some logic by which to split the file up. If not, we should not.
Re: [perl #37934] [TODO] build - log file
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 someone describe more specifically what we would need in a log file?
[perl #38982] [CAGE] refactor long test files
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 would benefit subdividing. That way, we can more easily identify which test files have been refactored and which remain to be done. Comments? kid51
[perl #39196] [TODO] tests - need to test addmethod
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?
[perl #37925] [TODO] build - Parrot::Configure::Step cleanup
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
[perl #37934] [TODO] build - log file
Can someone describe more specifically what we would need in a log file?
[perl #37932] [TODO] build - step consolidated/split
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 auto::warnings out of some other step. So we're doing this on an as-needed basis and can resolve this ticket. If there are specific steps which someone believes should be split or merged, please file an RT specific to that. Thank you very much. kid51
[perl #43170] [TODO] should --ask be handled like the other user defines? (config/inter/lex.pm)
Comments deleted in r24764. Ticket resolved.
Can assignment meta-operator be combined with feed operators?
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 };
[perl #38191] [TODO] build - generate META.yml
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. Is there anything more we should do? Otherwise, can we close this ticket? Thank you very much. kid51
Re: Sequential bias in S04 (and Perl6 in general)
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 machinery is there, so > maybe I can live with the bias in S04 -- perhaps rename it to > "Sequential Blocks and Statements". Anywhere that we guarantee > sequential behavior, we pretty much rule out concurrency. But if we > maximize the number of places where we are explicitly "unordered" then > we also maximize the number of places where implicit concurrency can be > added later. From that perspective, it's unfortunate a C loop > always iterates arrays in the order of their indices. 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 wouldn't have a problem with having the ability for C to iterate over a bag or some other inherently unordered, unsorted container in arbitrary possibly-parallel order though. Possibly by default, if the compiler can be satisfied that the closure's not got any unpleasant side effects to interfere with parallel execution. I think you're leaning too far towards concurrency in attempting to address the perceived bias. A lot of the time, the compiler's not going to be able to prove that it's safe to autothread a given closure because it might have side effects. If we were talking about Haskell or some other language which is ordinarily pure, things would be different. Under these circumstances, I would much rather have to explicitly say that I want parallel execution - provided that the ability to do it is there and it's easy to get at and behaves in a sensible manner (naturally this lets you parallelise things the compiler isn't sure are safe to parallelise due to possible side effects. That's fine, since you know which side effects are okay to do that to in your program). Matthew
[perl #41508] [BUG] Configure losing flags...
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 running > the single step. > Coke: Can this ticket be closed?
[perl #37923] [TODO] build - configure framework needs tests
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/configure-build/coverage.html.) The biggest area remaining is gen::* -- the classes that generate Makefiles, header files, etc. Since we have RTs open on each configuration step class -- as well as some more RTs focused on issues raised by Andy Dougherty -- there's no particular need to keep a general ticket like this open. So I'm resolving it. Thank you very much. kid51
[perl #41597] [PATCH] replacing explicit access to $^O in Configure
No complaints over the past 7 weeks, so I'm resolving the ticket. kid51
Re: Sequential bias in S04 (and Perl6 in general)
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 think of the array as a list or as a > ram. I know that a group at microsoft added a ParallelArray datatype > (ftp://ftp.research.microsoft.com/pub/tr/TR-2005-184.pdf) to C# as a way > to distinguish the intent (they speed up data-parallel code by compiling > it down to your GPU/graphics card). Perl6, being an operator-oriented > language, associates the distinction with the operators rather than with > the datatype. This is probably a better approach, but it does mean that > you need an operator whenever you want to treat the array as > data-parallel. (BTW, data-parallel arrays differ from bags in that they > have an ordered index that is preserved across unordered operations) Good point, a parallel operation over a list would let you preserve ordering but still benefit from concurrency with operations where iterating in order is irrelevant. Which, come to think of it, covers quite a lot of cases. > Of course, it's not necessarily true that "you know" that something is > safe -- often "you think" it's safe but then you get an intermittent > failure at runtime,. I would love to be able to tell the compiler "I > think this is safe" and have it tell me "you're wrong" as a compile-time > error (this is one of the things that an explicit type system is good > for). But perhaps Perl is too dynamic a language for that. Well, I was thinking with 'knowing' that something was safe that you'd figured out that it was free of side effects by studying the behaviour of everything you use within the relevant routines... ...in the real world, you need the compiler to be able to do some of that for you I guess. And Perl 6's optionally explicit type system might be able to express that sort of thing. signature.asc Description: This is a digitally signed message part
Re: Can assignment meta-operator be combined with feed operators?
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" implict?
>
> @data ==>= map { $_ + 1 };
Nobody has actually implemented the feed operators yet, so what you
read about them is guesswork. In this case the word "spec" is short
for "speculation", and we'll get a better idea of how feeds interact
with mutable structures when we have an implementation to play with.
I don't profess to be smart enough to know the answer in advance.
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). Given that feeds
are intended to indicate one form of declarative parallelism, I
doubt there will be a lot of call for building mutating operators
out of them. I think that feeds are more properly in the realm of
functional programming, and side effects are generally to be avoided
in that mindset. Even without that, we do have to be careful not to
define @data in terms of itself accidentally.
Alternately, you can view feeds as the primitives in an event
processing system, but in that case the ends of a feed should be
viewed as independent processing elements. Use of the name of a
data structure like @data as a proxy for both a source and a sink
of data would need to be very carefully defined. And I think the
conservative thing here is to avoid defining that till we know more
about why anyone would want to represent an event loop with "@data".
Basically, my current view is that a data structure cannot be
considered both a source and a sink without some mechanism for
keeping the new values from clobbering the old ones. With shell
pipes, that usually involves copying the data somewhere along the
way, even if that is hidden by replacing the inode under a filename.
Feedback loops can be a very powerful way of generating data in a
language with as powerful a type system as, say, Haskell, but I don't
think Perl aiming to be in that brainspace. Arbitrary restrictions
will likely be needed until all the implementations can agree on
what's possible and practical in the base language or in extensions.
Larry
[perl #39860] [TODO] build - Configure.pl should accept --libdir, etc.
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.
[perl #44187] [RFC] Configure.pl: --configure_trace option too verbose
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 bothered by this? Myself, I'm happy with the way it is. Does anyone else care? Otherwise, I'll close the ticket. Reports of other user experiences with Parrot::Configure::Trace welcome. kid51
Re: Can assignment meta-operator be combined with feed operators?
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 could be an interesting concept: I think that the
following would allow us to create an arbitrary-length pipeline of
concurrent lambda processes:
my @ops = { $_**2 }, { $_+1 }, { $_/2 };
my @in = 1,2,3;
[==>] @in, [EMAIL PROTECTED], @out;
is_deeply @out, [1,2,5], "chain of ops".
Re: Can assignment meta-operator be combined with feed operators?
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
>> (or any other metaoperator, for that matter).
>
> Feeds as a reduction could be an interesting concept: I think that the
> following would allow us to create an arbitrary-length pipeline of
> concurrent lambda processes:
>
> my @ops = { $_**2 }, { $_+1 }, { $_/2 };
> my @in = 1,2,3;
>
> [==>] @in, [EMAIL PROTECTED], @out;
>
> is_deeply @out, [1,2,5], "chain of ops".
Ignoring the * (which is obsolete and unnecessary to interpolate an
array into a list), that still won't work with the current formulation
of reduce ops. It would mean
1 ==> 2 ==> 3 ==> { $_**2 } ==> { $_+1 } ==> { $_/2 } ==> ()
Reduce ops aren't a macro over textual args; they operate on the values
of a normal list after normal list interpolation. Possibly you could
get away with something like
[==>] [EMAIL PROTECTED], @ops, [EMAIL PROTECTED];
...except that you'd probably need a recursive solution in any case,
especially since you really need to sneak a map() call in there along
with the ==>, or the individual closures won't be considered list ops.
So something a little more like this:
sub chain ([$op, [EMAIL PROTECTED], [EMAIL PROTECTED]) {
if @ops {
map $op, @args ==> chain @optail;
}
else {
map $op, @args;
}
}
1,2,3 ==> chain @ops ==> @out;
To golf it down further you'd have to do something like
my @listops = map { &map.assuming($^op) }, @ops;
and then maybe you could write something like:
[==>] \(1,2,3), @listops, [EMAIL PROTECTED];
On the other hand, maybe if the target of a feed is a function with
an arity of 1 it could be automapped on behalf of the user. Could be
a useful idiom, I suppose. We haven't exactly defined what feeds
will do with the Captures there either, but arguably the two sides
of a normal ==> are likely to be some sort of Capture context in
any case, if you count statements as a strange sort of Capture...
And maybe just maybe the reduce metaoperator in the standard grammar
can be taught to recognize macrolike entities such as ==> and apply
the reduction syntactically rather than semantically. But that's
kind of a long shot, I expect.
Larry
Re: [svn:parrot] r24767 - in trunk: . config/auto t/configure
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/configure/113-auto_msvc-01.t >trunk/t/configure/113-auto_msvc-02.t >trunk/t/configure/113-auto_msvc-03.t > > Log: > auto::msvc: Refactored some code to increase testability: > _handle_not_msvc(). Add 113-auto_msvc-04.t to test this internal > subroutine. In 113-auto_msvc-01.t, SKIP only test for runstep() on > non-Win32 platforms. Small corrections in other test files. I don't understand this. What's the value of testing any part of this code on non-Windows platforms? It doesn't (and can't) tell us anything interesting about our configuration system. -- c
[perl #49364] [CAGE]: Eliminate $data{args} from configuration step class initializers
Final stage -- elimination of 'args' element in each config step class's _init() routine -- accomplished in r24769. No damage to 'make test'. Resolving ticket.
[perl #43314] [TODO] config/auto/msvc.pm: Write unit tests
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.
[perl #49308] [BUG]: config/auto/alignptrs.pm fails if required alignment > 1
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.
[perl #43673] [TODO] Find out why cc_build uses the verbose setting it does
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 event, we've lived happily without that setting for nearly three months now, so I'm resolving the ticket. kid51
Parrot-Builder-trunk BUILD FAILED
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 Blamelist: cspencer BUILD FAILED: failed shell_3 sincerely, -The Buildbot
Re: [perl #38982] [CAGE] refactor long test files
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 seem to interact with RT, I'd say open a ticket on a test-file by test-file basis rather than having a blanket ticket for the task. This seems to have been working particularly well for you recently, so I'd say resolve this ticket and open new ones as relevant. Paul
