Re: Database Transactions and STM [was: Re: STM semantics, the Transactional role]
On 7/18/05, Sam Vilain [EMAIL PROTECTED] wrote:
Is this needed, when you can just;
atomic {
unsafeIO { $dbh.begin_work };
unsafeIO { $dbh.do(...) };
unsafeIO { $dbh.commit };
} CATCH {
$dbh.rollback;
};
Shouldn't that `CATCH` block be within the `atomic` block? Or did I
miss something?
Aankhen
[perl #36584] [PATCH]Immediate Dominators
# New Ticket Created by Curtis Rawls # Please include the string: [perl #36584] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36584 This patch: -Adds an immediate dominator attribute to the CFG. -Adds an algorithm to (inefficiently) compute idoms from the dominator sets. -Switches the compute_dominators algorithm to the non-BFS version (the BFS version is faster but does not always work correctly). -Modifies dump_dominators to display the idom of each block in parentheses. -Curtis idom.patch Description: Binary data
[perl #36585] [PATCH]Refactoring the Register Allocator
# New Ticket Created by Curtis Rawls # Please include the string: [perl #36585] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36585 This patch pulls the graph coloring portion of imc_reg_alloc() out and puts it in its own function, graph_coloring_reg_alloc(). This will allow alternate register allocators to be implemented. -Curtis reg_alloc.patch Description: Binary data
Re: Perl 6 Modules
- Original Message -
From: Stevan Little [EMAIL PROTECTED]
Subject: Re: Perl 6 Modules
| Gav,
|
| Welcome aboard. You might also want to hop onto the #perl6 channel over
| at irc.freenode.net it is where many of use spend way too much time,
| and a great place for asking questions like these.
Thanks, I have visited #perl6, being in Australia may be the reason why
I havent caught anyone there so far.
| Actually it seems someone has done something here, because when I go to
| www.perl6.com I get forwarded to
| http://dev.perl.org/perl6/?HiFromPerl6.com.
Spooky, something has been done , nothing to do with my mentioning
of it but the timing was there :)
|
| As for the howtos, modules, etc. much of those are centrally located,
| and that is in the Pugs distribution. It will certainly not be the
| final place for them, but it is their current home.
Thanks, yep got them. Some people may wish to 'view' some of what
is available before download, but that will come.
| CPAN has no real rules, so you can submit a Perl 6 module if you like,
| but it will likely be frowned upon. Currently all the working Perl 6
| modules are inside Pugs since that is the only thing which will
| currently run them.
|
| However, this will not always be like this, but since we are still very
| early in the development of Perl 6/Pugs it makes sense.
Yes, I get it now, having a section on CPAN dedicated to Perl6 Modules
does give the impression that is the expected place for them. Maybe it is
just there 'ready and waiting'. So I (or anyone) should submit to Autrijus
or to pugscode.org ? or to the list.
|
| Pugs is (at the moment) just a reference implementation of Perl 6.
| Autrijus is fond of saying that Pugs is optimized for fun. Which is
| to say that it is not meant to be the real Perl 6 production release,
| but instead a sandbox in which everyone can experiment with the Perl
| 6 language, and therefore provide more concrete feedback to the Perl 6
| design team.
|
| Parrot is a virtual machine, from it's birth it was envisioned that it
| would run Perl 6, however, Parrot is (and will be) much more than just
| a Perl 6 VM. Currently Pugs will use Parrot to handle things like
| Perl 6 rules and grammers, and Pugs also supports a very experimental
| compile Perl 6 for Parrot feature.
|
| And finally Perl 6 (the official release) does not exist yet.
Thanks for the info.
El-Stupido question then using basic example :-
Supposing I have a .pl file that sends a newsletter and starts off with as
normal
#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
use CGI qw(:standard);
use DBI;
$|=1;
$textfile = param('textfile');
$htmlfile = param('htmlfile');
$subject = param('subject');
#$username = param('username');
print Content-type: text/html\n\n;
etc etc ..
What would be the changes required to write this a Perl 6 file, my guess is
:-
#!/usr/bin/pugs
use v6;
but I don't know about the rest of it.
I'd like to get this sorted first and then write a test perl6 module and use
that in my test perl 6 script. Then I think the fog will have cleared.
| As I said above, #perl6 over on irc.freenode.net is also a very good
| place. In fact, I highly recommend that you drop by and chat if you are
| interested in doing any Perl 6 work.
Will continue to do so and hope to catch some of you there, if only to watch
and learn for the first little while.
| The idea is to have Perl 6 be able to load and run Perl 5 code. This
| will be accomplished through the Ponie project, (which is an
| implementation of Perl 5 on Parrot). Currently Pugs has support for
| this and autrijus actually has some Perl 6 code in production, which
| uses Pugs to load the Perl 5 DBI module.
Cool, sounds like the sort of thing I need in my Q above.
|
| Is there a Perl5 to Perl6 Module converter in the making ?
|
| I highly doubt this will ever exist. Not only is Perl 6 a very
| different language from Perl 5, but good Perl 5 module design will not
| be the same as good Perl 6 module design.
|
| However, that said, we have ported a number of popular/useful Perl 5
| modules to Perl 6. They can be found in the Pugs distribution here
| http://svn.openfoundry.org/pugs/ext/
Thanks, taking a look.
| Well to start with, being a month behind is a lng period of time in
| Pugs development. Pugs is a very fast moving project, so much so that
| by the time the CPAN release hits the main CPAN mirror, it is usually
| already out-dated.
|
| There was someone who was making windows binaries, but I am not sure if
| that is still the case. Again, #perl6 is a great place to ask about
| this stuff.
Thanks Again, if there is a shortage of people doing this, maybe it is
something
I could do if there was a demand. (?)
| More tester and more platforms are always welcome. You might want to
| check if GHC (the Glaskow Haskell Compiler) runs on that platform first
| (as you will need that to compile Pugs).
The main site mentions Solaris but then the downloads
Re: [perl #36584] [PATCH]Immediate Dominators
Curtis Rawls (via RT) wrote: This patch: -Adds an immediate dominator attribute to the CFG. Thanks, applied - r8647 leo
Re: [perl #36585] [PATCH]Refactoring the Register Allocator
Curtis Rawls (via RT) wrote: This patch pulls the graph coloring portion of imc_reg_alloc() out and puts it in its own function, graph_coloring_reg_alloc(). This will allow alternate register allocators to be implemented. Thanks, applied - r8648 leo
Strange interaction between pairs and named binding
This currently works in Pugs:
for [1..10].pairs - Pair $x { say $x.value }
But this does not:
for [1..10].pairs - $x { say $x.value }
Because the ruling that pairs must not be bound to parameters that are
not explicitly declared to handle them. Is this a desirable behaviour?
Thanks,
/Autrijus/
pgp1DMNKlnL1K.pgp
Description: PGP signature
Basic Testing Questions
I've begun using perl's Test modules to do some unit testing on our code and regression testing on some of our web applications. Specificially, I'm using Test::More and prove. However, I have some questions that aren't really addressed by the documentation I've found thus far. These are basic questions, so I'm positive there are some general answers (or at least general practices). Currently I have a directory tree, and my testing consists of running prove on one .t file, a directory, or recursively over all. I don't seem to have a means of controlling the order of tests without using the shell. (i.e. prove will run the tests in whatever order it pleases. prove * will run them in asciibetical order) Is that true? There are some tests that I would love to have abort as soon as they fail. (If step 3 failed, then steps 4 and 5 are places I don't want to go) Is there a way to make prove do this? I skimmed the Test::Builder docs, in case I was going to have to roll my own prove-like tool, and didn't see an obvious call there either. I have some related tests. For example, to test the account management of our LDAP administration tools on the website, I have a test to create an account, test various edit options, then delete the account. (This is testing the create and delete as well, so I don't want to use an existing account). This means that I either write a very large, monolithic .t file which reduces my ability to testing single functions of the interface, or I write separate .t files for each function. In the latter case, I have to either be sure to run the create in the beginning and the delete at the end (see prove and order of tests at the start of this email) or I have to copy the create and delete code into each tests, making maintenance harder. Is there a common way to modularize code in test files? Is this just a do call? Thanks in advance! -- SwiftOne / Brett Sanger [EMAIL PROTECTED]
Re: Is namespace qualification really required
Autrijus Tang [EMAIL PROTECTED] wrote:
On Fri, Jul 15, 2005 at 02:16:48PM -0500, [EMAIL PROTECTED] wrote:
package MyModule;
use v6;
sub doubler( Num $x ) {
return 2 * $x;
}
sub value_v( Code +$func = MyModule::doubler ) is export {
return $func( 5 );
}
This works. But I think I should be able to say:
sub value_v( Code +$func = doubler ) is export {
That won't do, as it will call the doubler.
That makes sense.
sub value_v( Code +$func = doubler ) is export {
This should work; if it does not, it is a bug. Can you add a
regression test as, say, t/subroutines/defaults.t? I have just
sent you a committer invitation.
I made the test. The problem only occurs when the sub is called from another
package, in my case that was a driving script.
I'm not sure how to accept the invitation (or what that even means). Sorry,
I'm new here.
Phil
Re: GMC for dummies
Nattfodd wrote: Leopold Toetsch wrote: I believe that if we want variable-sized body, we need at least one next (or pmc_size) pointer in the header. Not necessarily. We can have: - some type bits in the gmc_header for fixed-sized and commonly used objects, so that GMC knows the size - alternatevily use an object size field in the vtable - force variable sized objects to have a word-size at a known object location e.g. just the first word (like PMC_int_val for current arrays) Therefore we can always calculate the object size and walk the pmc_body memory. Do you see any other solution that could avoid prev and next ? We just need a next pointer for managing holes in the pmc_body memory space. That's basically the same as in a memory allocator. Regards, Alexandre leo
Re: Basic Testing Questions
On Mon, Jul 18, 2005 at 09:42:06AM -0400, Brett Sanger ([EMAIL PROTECTED]) wrote: Currently I have a directory tree, and my testing consists of running prove on one .t file, a directory, or recursively over all. I don't seem to have a means of controlling the order of tests without using the shell. (i.e. prove will run the tests in whatever order it pleases. prove * will run them in asciibetical order) Is that true? prove runs in whatever order it gets them. There are some tests that I would love to have abort as soon as they fail. (If step 3 failed, then steps 4 and 5 are places I don't want to go) Is there a way to make prove do this? I skimmed the Test::Builder docs, in case I was going to have to roll my own prove-like tool, and didn't see an obvious call there either. Test::Manifest is the way to get them in a certain order. start of this email) or I have to copy the create and delete code into each tests, making maintenance harder. Is there a common way to Or make a mini library of the common code. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Is namespace qualification really required
On Mon, Jul 18, 2005 at 09:00:50AM -0500, [EMAIL PROTECTED] wrote: I made the test. The problem only occurs when the sub is called from another package, in my case that was a driving script. I'm not sure how to accept the invitation (or what that even means). Oh. It means you should have received a mail from openfoundry.org that contains a URL to be registered on http://rt.openfoundry.org/ -- the system that manages Pugs committership. You can also go to that website and register manually, using your mail address; once you have done so, you'll be listed among Pugs committers, and then you can commit in your test using the username/password chosen at the registration time. If you are using command-line svn, the sequence should be: svn co http://svn.openfoundry.org/pugs cd pugs # ... create t/subroutines/defaults.t ... # ... edit AUTHORS to add your name ... svn add t/subroutines/defaults.t svn ci If you are using svk, the sequence is exactly the same, with the svn replaced with svk. Thanks, /Autrijus/ pgpGbpIzgIrmL.pgp Description: PGP signature
Re: GMC for dummies
Bob Rogers wrote: From: Leopold Toetsch [EMAIL PROTECTED] Date: Sun, 17 Jul 2005 12:08:34 +0200 What happens when a store creates a cycle? And how would this be detected? To keep the invariant we can't move the container nor the contained object, *if* both are aggregates. Therefore the pointer store will be recorded on the IGP list. Thus there is no need to detect cycles. But when are objects taken off the IGP list? This is not contemplated in [1], which explicitly mentions as a drawback that circular structures cannot be recovered [2], and it is not (yet) addressed in the GMC design [3]. Circular or not isn't really the problem. With generational GC you'll always have the chance of tenured garbage. E.g. gen n | gen j [ A ] | [ C ] ^ | +--+ We got a reverse pointer, which needs remembering on the IGP list of generation n. IGPn then becomes part of the root set of this generation n and the object A is marked and kept alive. So far so good. Now due to some other pointer store the object C becomes dead. But as long as we don't scan up to generation j, we don't realize this and object A stays alive. This is usually not a problem, just some waste of memory, except when the object A needs timely destruction. In such a case we would have to scan more generations, up to generation j in the above case. As object C belongs to generation j, the IGP entry that marks A would become invalid, because the object C (and its refered contents) have to be anchored somwhere else to be alive. gen n | gen j [ A ] - [ B ] -|- [ C ] ^ | +--+ A circular data structure doesn't really change the picture, except, when again scanning up to generation j, and we find object C being alive, we'd have to restart scanning at object A, by following the backreference. If non of A, B, or C is referenced from elsewhere, we would still delete the whole reference loop. ... Is one-pass mark-sweep really a suitable GC algorithm for Parrot? I still think it's suitable yes. It's only in the above case that we can't immediately cleanup A, because of the invalidation of the IGP entry. -- Bob leo
Re: Basic Testing Questions
(insert off-topic grumblings about that Munging Reply-To Considered Harmful and how I can't reply in one way to most lists anymore) On Mon, Jul 18, 2005 at 09:44:25AM -0500, Andy Lester wrote: shell. (i.e. prove will run the tests in whatever order it pleases. prove * will run them in asciibetical order) Is that true? prove runs in whatever order it gets them. Which is asciibetical if I name the tests, or readdir() (a.k.a. whatever order) if I don't, so I guess the answer to my question was no, I don't have the means fo controlling the order of the tests without passing the list through the shell. Bummer. Inclusion of a sort into the default behavior of prove would be a trivial patch...is anyone else intrested in having me submit one? I think it'd be nice to have prove mimic the behavior of Test::Harness here. Test::Builder docs, in case I was going to have to roll my own prove-like tool, and didn't see an obvious call there either. Test::Manifest is the way to get them in a certain order. Ah, thanks. Is there interest in having prove pay attention to Test::Manifest? Am I barking up the wrong tree by using prove for all of these tests? Or am I just approaching this weirdly? Or am I in a minority by using the tests for my applications as opposed to just my modules? Also, I take it there isn't away to abort as soon as one test fails? start of this email) or I have to copy the create and delete code into each tests, making maintenance harder. Is there a common way to Or make a mini library of the common code. But is there a common way to package that common code? I feel weird making a module that runs tests (breaks some sort of mental barrier against side-effects, I guess.) Is that how most of you package reused tests inside other tests? Modules? Thanks again. -- SwiftOne / Brett Sanger [EMAIL PROTECTED] - End forwarded message - -- SwiftOne / Brett Sanger [EMAIL PROTECTED]
Re: Basic Testing Questions
Brett Sanger wrote: I have some related tests. For example, to test the account management of our LDAP administration tools on the website, I have a test to create an account, test various edit options, then delete the account. (This is testing the create and delete as well, so I don't want to use an existing account). This means that I either write a very large, monolithic .t file which reduces my ability to testing single functions of the interface, or I write separate .t files for each function. In the latter case, I have to either be sure to run the create in the beginning and the delete at the end (see prove and order of tests at the start of this email) or I have to copy the create and delete code into each tests, making maintenance harder. Is there a common way to modularize code in test files? Is this just a do call? You might look at Test::Class, which has some nice features for handling repetitive setup/teardown needs. A more manual approach is to put your common testing code in its own module and use that in each of your test scripts. If you're using prove, you should be able to create t/Common.pm, define package t::Common; in that file, and then use t::Common in your tests scripts. (This assume that you run your tests from the directory above t/ so that t::Common finds your module.) Regards, David Golden
Re: Strange interaction between pairs and named binding
On Mon, Jul 18, 2005 at 08:42:24PM +0800, Autrijus Tang wrote:
: This currently works in Pugs:
:
: for [1..10].pairs - Pair $x { say $x.value }
:
: But this does not:
:
: for [1..10].pairs - $x { say $x.value }
:
: Because the ruling that pairs must not be bound to parameters that are
: not explicitly declared to handle them. Is this a desirable behaviour?
No, but it's necessary unless we can find some way of breaking the
magical relationship of pairs with named arguments. Even if we came
up with special syntax on the calling end to differentiate the positional
zone from the named zone, it wouldn't help here, since the call syntax
is implicitly buried in the implementation of for. So we have to
distinguish it on the formal end, and currently Pair is the way to do that.
Larry
Re: More Method Resolution Order Questions (and WALKMETH and WALKCLASS)
Ok, I will un-warnock myself here :) As of r5674 in the Pugs tree, the Perl6::MetaModel now supports all the A12 dispatch orders. :canonical # canonical dispatch order :ascendant # most-derived first, like destruction order :descendant # least-derived first, like construction order :preorder # like Perl 5 dispatch :breadth# like multimethod dispatch For :descendant I just did a reverse of the :ascendant order. I am not sure that is truly sane or not, but it seemed to make sense to me. And after some discussion on #perl6 I decided to make 'C3' the algorithm of choice for the :ascendant ordering, and also to make :ascendant the :canonical ordering (since it makes MI sane, I mean how could you go wrong). Of course all this can change if @Larry decides differently :) Anyway, back to $work :) Stevan
Re: More Method Resolution Order Questions (and WALKMETH and WALKCLASS)
Larry, On Jul 18, 2005, at 3:21 PM, Larry Wall wrote: On Mon, Jul 18, 2005 at 02:54:40PM -0400, Stevan Little wrote: : Ok, I will un-warnock myself here :) Sorry, I've been occupied by various time-consuming family obligations. My own fault, I asked on the weekend. People *should* spend time with family on the weekends. : And after some discussion on #perl6 I decided to make 'C3' the : algorithm of choice for the :ascendant ordering, and also to make : :ascendant the :canonical ordering (since it makes MI sane, I mean how : could you go wrong). : : Of course all this can change if @Larry decides differently :) It has been a long-standing desire of $Larry to head that direction, so unless any(@Larry) complain, that seems fine. Excellent :) I guess I only wonder whether that will make it harder to view SMD as a constrained subset of MMD since it might be construed as forcing a different distance metric. But maybe preserving SMD ordering as a subset of MMD shouldn't be a major concern, since it's one of those things that makes more difference in the weird cases than in the usual ones, and since Perl 6 is providing explicit call differentiation of SMD vs MMD for anything above one argument. I think that creating a class ordering via C3 is a good idea before diving into MMD dispatching. If people are going to be able to logically reason about their classes, then there needs to be some basic rules, and class ordering I think should be one of them. It should not diminish the power of MMD really, since it will still be possible to search the entire class ordering, gathering up all possible canidates, before choosing the best one. In fact, it might make MMD easier if we give class ordering some weight in the descision. However, I really know nothing about MMD, so I am just talking crazy on 3 1/2 hours of sleep :) Thanks much for the reply, Stevan
Re: More Method Resolution Order Questions (and WALKMETH and WALKCLASS)
On Mon, Jul 18, 2005 at 02:54:40PM -0400, Stevan Little wrote: : Ok, I will un-warnock myself here :) Sorry, I've been occupied by various time-consuming family obligations. : And after some discussion on #perl6 I decided to make 'C3' the : algorithm of choice for the :ascendant ordering, and also to make : :ascendant the :canonical ordering (since it makes MI sane, I mean how : could you go wrong). : : Of course all this can change if @Larry decides differently :) It has been a long-standing desire of $Larry to head that direction, so unless any(@Larry) complain, that seems fine. I guess I only wonder whether that will make it harder to view SMD as a constrained subset of MMD since it might be construed as forcing a different distance metric. But maybe preserving SMD ordering as a subset of MMD shouldn't be a major concern, since it's one of those things that makes more difference in the weird cases than in the usual ones, and since Perl 6 is providing explicit call differentiation of SMD vs MMD for anything above one argument. Larry
Re: Is namespace qualification really required
Autrijus Tang [EMAIL PROTECTED] wrote: On Mon, Jul 18, 2005 at 09:00:50AM -0500, [EMAIL PROTECTED] wrote: I made the test. The problem only occurs when the sub is called from another package, in my case that was a driving script. I'm not sure how to accept the invitation (or what that even means). Oh. It means you should have received a mail from openfoundry.org that contains a URL to be registered on http://rt.openfoundry.org/ -- I see. If you are using command-line svn, the sequence should be: svn co http://svn.openfoundry.org/pugs cd pugs # ... create t/subroutines/defaults.t ... # ... edit AUTHORS to add your name ... svn add t/subroutines/defaults.t svn ci I did this. I included two tests, one without multiple packages (which works) and one with them (which fails). I marked the second test todo. Thanks for the gentle help with this process. If there is any chance I could fix this problem, I'd try. But, I would need some pointers. Phil
Re: Perl 6 Modules
At 7:39 PM +0800 7/18/05, Gav wrote: What would be the changes required to write this a Perl 6 file, my guess is :- #!/usr/bin/pugs use v6; but I don't know about the rest of it. I'd like to get this sorted first and then write a test perl6 module and use that in my test perl 6 script. Then I think the fog will have cleared. If you want to write your program now, you should look at the 'CGI' module that is already ported to native Perl 6, and use that. The 'DBI' module hasn't been ported yet, but you can use the Perl 5 version by saying 'use perl5:DBI' or something like that (you may need to explicitly build Pugs with Perl 5 linked in, for that to work). Then you just have to update the rest of your code to be good Perl 6. Lots of examples exist now with Pugs. -- Darren Duncan
Re: [perl #36548] GHC bugs
Simon Marlow (via RT) kirjoitti: # New Ticket Created by Simon Marlow # Please include the string: [perl #36548] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36548 Hi, I've been trying in vain over the last day or so to reproduce the following GHC bugs, both allegedly demonstrated by Pugs: [ 1226252 ] internal error: EVACUATED object entered! http://sourceforge.net/tracker/index.php?func=detailaid=1222522group_i d=8032atid=108032 [ 1222522 ] scavenge_stack: weird activation record found on stack:37548 http://sourceforge.net/tracker/index.php?func=detailaid=1222522group_i d=8032atid=108032 I seem to be able to reproduce this error using pugs r4916. Testing for the t/oo/destruction.t few times on a row gave these errors: pugs: internal error: TVAR object entered! pugs: internal error: EVACUATED object entered! pugs: internal error: scavenge_stack: weird activation record found on stack: 6432 pugs: internal error: scavenge_stack: weird activation record found on stack: 17516 pugs: internal error: scavenge_stack: weird activation record found on stack: 3348 pugs: internal error: scavenge_stack: weird activation record found on stack: 27812 So the test seems to give an error every time I run it, while the actual error varies a bit. At this point I'm stuck. I don't doubt there's a bug somewhere, but it's not showing itself for me. If someone can provide me with a temporary account on a machine that demonstrates the bug, that would be great. SSH key available on request. Even better if you could set me up with an account and a Pugs build tree all ready to go. I've spent too much time on this to give up now! Unfortunately I don't know much about debugging nor how to setup such an account, if it's even possible on my computer. (I have SuSe 9.1 in a local network, with win98se-computer between internet and this local network.) -- Markus Laire
Re: Basic Testing Questions
On Mon, Jul 18, 2005 at 09:42:06AM -0400, Brett Sanger wrote: Currently I have a directory tree, and my testing consists of running prove on one .t file, a directory, or recursively over all. I don't seem to have a means of controlling the order of tests without using the shell. (i.e. prove will run the tests in whatever order it pleases. prove * will run them in asciibetical order) Is that true? Simplest way to address this is to write a wrapper around prove. Then you can sort any way you want or use Test::Manifest or whatever. #!/usr/bin/perl -w my @switches = grep /^-/, @ARGV; my @tests= grep !/^-/, @ARGV; my @tests = sort_files_however(@tests); system(prove, @switches, @tests); Or you can skip prove and just use Test::Harness::runtests(). prove is just a fancy wrapper around that. There are some tests that I would love to have abort as soon as they fail. (If step 3 failed, then steps 4 and 5 are places I don't want to go) Is there a way to make prove do this? I skimmed the Test::Builder docs, in case I was going to have to roll my own prove-like tool, and didn't see an obvious call there either. If you mean to abort the running of all further tests and test files, the function you want is BAIL_OUT() which was added to Test::More in 0.60_01. Its a very simple function and you can read about it here. http://search.cpan.org/dist/Test-Harness/lib/Test/Harness/TAP.pod#Bail_out! I have some related tests. For example, to test the account management of our LDAP administration tools on the website, I have a test to create an account, test various edit options, then delete the account. (This is testing the create and delete as well, so I don't want to use an existing account). This means that I either write a very large, monolithic .t file which reduces my ability to testing single functions of the interface, or I write separate .t files for each function. In the latter case, I have to either be sure to run the create in the beginning and the delete at the end (see prove and order of tests at the start of this email) or I have to copy the create and delete code into each tests, making maintenance harder. Is there a common way to modularize code in test files? Is this just a do call? Test::Class handles this well. Or you can write testing libraries, throw them into t/lib, stick use 't/lib' into your .t files and use your custom testing libraries as normal. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in [EMAIL PROTECTED]
Re: [perl #36548] GHC bugs
Just a quick addition to my previous message: I now got
1) --no error, just a failed test--
2) --no error, just a failed test--
3) pugs: internal error: scavenge_stack: weird activation record found
on stack: 49900
4) pugs: internal error: EVACUATED object entered!
5) pugs: internal error: scavenge_stack: weird activation record found
on stack: 9368
So this test doesn't seem to give error *every* time, but still quite often.
I used command
PERL_DL_NONLAZY=1 /usr/bin/perl -I../../inc -I../inc -Iinc
-MExtUtils::Command::MM -e ENV-{HARNESS_PERL} =
q{/home/malaire/omat/downloads/direct-devel-downloads/temp/pugs/blib/script/pugs};
@ARGV = map glob, @ARGV; ENV-{PERL6LIB} =
q{/home/malaire/omat/downloads/direct-devel-downloads/temp/pugs/blib6/lib};
test_harness(0, 'inc',
'/home/malaire/omat/downloads/direct-devel-downloads/temp/pugs/blib/lib',
'/home/malaire/omat/downloads/direct-devel-downloads/temp/pugs/blib/arch')
t/oo/destruction.t
--
Markus Laire
Re: Strange interaction between pairs and named binding
Autrijus Tang [EMAIL PROTECTED] wrote:
This currently works in Pugs:
for [1..10].pairs - Pair $x { say $x.value }
But this does not:
for [1..10].pairs - $x { say $x.value }
Because the ruling that pairs must not be bound to parameters that are
not explicitly declared to handle them. Is this a desirable behaviour?
How much violence would be done to the language if we declared that
block (i.e. closure with no sub keyword) parameters defaulted to
Item|Pair, while sub parameters defaulted to plain Item? I can't
imagine named arguments are going to be used very often on blocks,
which tend to be things like loop bodies...
Right now one of my biggest Perl 6 nits is that the combination of
subroutines everywhere and the Pair type's special role in subroutine
dispatch makes Pairs a real pain to work with. This would help to fix
the problem without creating a new SuperPair type or something
similarly silly.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Do I need has $.foo; for accessor-only virtual attributes?
On Mon, Jul 18, 2005 at 03:34:36PM +1200, Sam Vilain wrote:
: Say I make an accessor method for an attribute that doesn't really
: 'exist'.
:
: For instance, a good example of this is the month_0 vs month
: properties on a date object; I want to make both look equivalent as
: real properties, but without the users of the class knowing which
: one is the real one.
:
: Users of the class includes people subclassing the class, so to them
: they need to be able to use $.month_0 and $.month, even though there
: is no has $.month_0 declared in the Class implementation, only
: has $.month.
We thought about defining the attribute variables that way,
but decided that it would be clearer if they only ever refer to
real attributes declared in the current class. Outside the class,
including in subclasses, you have to use the accessors, so it's always
$self.month_0 and $self.month, however you end up spelling $self...
: So, is $.month just shorthand for $?SELF.month, which happens to be
: optimised away to a variable access in the common case where the
: method month isn't defined, or has a sufficiently simple is
: accessor trait in its declaration?
Nope. $.month is actually a primitive form that can't be expressed in
terms of method calls in the absence of knowledge about the internals
of the object's representation, which is (by default) opaque in Perl 6.
Another difference is that $.month is never virtual, while $?SELF.month
is always virtual.
: And that, in turn, $:month is actually $?SELF.(:month), where
: :month is an alias for the submethod called month.
That seems divergent in several different ways. Like $.month, $:month
is also a primitive form that is never virtual. Unlike $.month,
it does not actually generate a virtual accessor method at all.
It essentially generates a private subroutine accessor that you
can call as as $?SELF.:foo(), which is syntactic sugar for $:foo
only within the class and trusted classes. Apart from that there
is *no* access to the attribute from outside the class whatsoever.
This private accessor is not at all related to submethods, which have
restricted inheritance but are otherwise callable from anywhere.
There is no aliasing from :month to month. That colon is very
much a part of the name of the private method, so you can have
method :foo {...} # private foo method
method foo {...}# public foo method
and there is no conflict at all. That's because we don't want the
existence or non-existence of :foo to ever change the external
interface.
In contrast, this is illegal:
method foo {...}# public method foo
submethod foo {...} # public submethod foo
because you're trying to define two methods of the same name.
: After all, we want Roles used by Classes to have access to this virtual
: attribute coolness, too.
Roles have exactly the same virtual attribute access as classes, via
methods. A role that is trying to access both the physical attribute
and the virtual attribute is likely to be mixing two different roles
as one role, and should probably be split. Keeping the distinction
between $.foo and $self.foo helps enforce that. But I suspect most of
the coolness you want to do can be just as easily expressed in the
$self.foo form. And the part you can't is probably not so cool.
: These simple definitions should make all sorts of OO tricks possible,
: and reduces the definition of Classes to one that is purely
: functional (ie, state is just a set of functions too).
One can certainly rewrite $.foo and $:foo in terms of lower level
functional primitives, but we must be careful not to confuse those
with higher-level virtual method calls. Otherwise we are mixing OO
interface with OO implementation, and we've already discovered in
Perl 5 that that's a Bad Idea. Interfaces between organisms are
cleaner when their innards stay in and their outtards stay out.
Larry
Re: GMC for dummies
From: Nattfodd [EMAIL PROTECTED] Date: Tue, 19 Jul 2005 04:03:49 +0200 Leopold Toetsch wrote: gen n | gen j [ A ] - [ B ] -|- [ C ] ^ | +--+ A circular data structure doesn't really change the picture, except, when again scanning up to generation j, and we find object C being alive, we'd have to restart scanning at object A, by following the backreference. If non of A, B, or C is referenced from elsewhere, we would still delete the whole reference loop. Hi, I don't know how this could work. First, we need more than one pass (if each alive object in the IGP needs to follow the backreference, this can lead to between |alive_IGP_set| and 2^|alive_IGP_set| passes...). And I don't see either how we could check if the loop is referenced from elsewhere, as the mark is a single bit. A solution I'm thinking of is using two bits for the marking . . . I hope there's a (much) more simple way :/ And this is not at all one pass marksweep... Regards, Alexandre That's what concerns me. Even if you devise an efficient way to detect garbage in the IGP list, a straightforward two-pass implementation might be simpler, and probably faster. Of course, if you believe that circular structures are rare, then it might be less of an issue. But that's a dangerous road to traverse; if circular structures are supported poorly by Parrot, then their rarity could become a self-fulfilling prophecy. -- Bob
Re: GMC for dummies
From: Leopold Toetsch [EMAIL PROTECTED] Date: Mon, 18 Jul 2005 17:08:53 +0200 Circular or not isn't really the problem. With generational GC you'll always have the chance of tenured garbage . . . Now due to some other pointer store the object C becomes dead. But as long as we don't scan up to generation j, we don't realize this and object A stays alive. That's true, but not my point. I don't understand how the IGP mechanism permits cycles to be collected at all. . . . gen n | gen j [ A ] - [ B ] -|- [ C ] ^ | +--+ A circular data structure doesn't really change the picture, except, when again scanning up to generation j, and we find object C being alive, we'd have to restart scanning at object A, by following the backreference. If non of A, B, or C is referenced from elsewhere, we would still delete the whole reference loop. So that means you do not use the IGP pointer to A when collecting any generation = j, correct? Otherwise, I imagine you'd always decide that A is alive, and hence B and C. But what if A, B, and C are all in the same generation? You'd still need an IGP entry, even though it's not inter-generational, in order to handle the backpointer, but how would you then decide that it's invalid? ... Is one-pass mark-sweep really a suitable GC algorithm for Parrot? I still think it's suitable yes. It's only in the above case that we can't immediately cleanup A, because of the invalidation of the IGP entry. leo I am willing to believe that there could be an IGP mechanism that would perform as described, but I haven't yet heard enough to understand it myself. Perhaps you should save your (metaphorical) breath, and I'll wait for a more detailed design. -- Bob Rogers
Re: Strange interaction between pairs and named binding
On Mon, Jul 18, 2005 at 03:48:55PM -0700, Brent 'Dax' Royal-Gordon wrote:
Autrijus Tang [EMAIL PROTECTED] wrote:
This currently works in Pugs:
for [1..10].pairs - Pair $x { say $x.value }
But this does not:
for [1..10].pairs - $x { say $x.value }
Because the ruling that pairs must not be bound to parameters that are
not explicitly declared to handle them. Is this a desirable behaviour?
How much violence would be done to the language if we declared that
block (i.e. closure with no sub keyword) parameters defaulted to
Item|Pair, while sub parameters defaulted to plain Item? I can't
imagine named arguments are going to be used very often on blocks,
which tend to be things like loop bodies...
If the Bare code object (including pointy and non-pointy) default their
parameter types to Any (that is, Item|Pair|Junction), then all of
these would work:
for [1..10].pairs { say(.value) }
for [1..10].pairs { say($^x.value) }
for [1..10].pairs - $x { say($x.value) }
for 1|2, 3|4 { say(.values) }
for 1|2, 3|4 { say($^x.values) }
for 1|2, 3|4 - $x { say($x.values) }
Right now one of my biggest Perl 6 nits is that the combination of
subroutines everywhere and the Pair type's special role in subroutine
dispatch makes Pairs a real pain to work with. This would help to fix
the problem without creating a new SuperPair type or something
similarly silly.
Seconded.
Thanks,
/Autrijus/
pgpxMSflL0GBA.pgp
Description: PGP signature
