Re: Development version
Beau E. Cox wrote:
> Hi -
>
> Congrats on your 6.2.11 release!
>
> Did the development (svn) version really jump to 6.28.0?
Yes. Major pugs releases are numbered by adding the next digit of 2*pi,
rather than the more conventional x.y+1 :-)
> I am running some scripts to automate a refresh of parrot and
> pugs weekly so I can stay in tune with the current effort.
> To identify my svn downloads by version and revision I:
>
> 1) slurp ChangeLog and pull version from /(\d+.\d+\.\d+)/s.
> 2) get revision from the svn output:
> revision=$(tail -n1 svn.log|perl -e ';$_=<>;$r=/rev.*?(\d+)/i ? $1 :
> "";print $r') \
clever, but ugh.
> Two questions:
>
> 1) Are version and revision available in the source tree in a
>format easier to use?
yes:
VERSION can be parsed from META.yml with any handy YAML parser
e.g. `perl -MYAML -e 'print YAML::LoadFile("META.yml")->{version}'`
REVISION can be gotten with `svnversion .`
> 2) If not, would the group consider maintaining a VERSION or
>VERSION and REVISION files in the root of the tree that
>could simply be cat'ed?
META.yml
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
David Cantrell wrote: brian d foy wrote: <[EMAIL PROTECTED]> wrote: Hopefully it will be something like: $I::don't::bother::to::write::portable::code=1; ;-) Seriously though, I would expect things in Win32::* to only work on Windows, things in Linux::* only to work on linux, and so on for many other sections (including Mac::* where I have some modules). Portable code isn't always the goal. I want my code to be more like File::Spec, which provides a common interface to a load of platform-specific modules. That has very good coverage of bizarro OSes, and I think we'd all agree that it's an excellent example of a nice portable module. It doesn't work on RISC OS though. I suppose that this is less that RISC OS is so truly bizzare that it defies anyone to come up with platform-specific File::Spec code for it, and more a gentle nudge on your part for someone to find the tuits to do so? David -- "It's overkill of course, but you can never have too much overkill."
Re: [Module::Build] [RFC] author tests
Tyler MacDonald writes: > Chris Dolan <[EMAIL PROTECTED]> wrote: > > [lots of author test examples, including:] > > > * versionsync.t - Checks that the $VERSION is the same in all bin/* > > and *.pm files. This test is pointless after release, since it's > > already been tested before release > > * pod-coverage.t - Checks POD completeness. This test is pointless > > after release, since it's already been tested before release > > ... since there's absolutely no value in these types of tests for > anybody else except the module author, there's no real point in having > a convention, just stick 'em anywhere that the make/buildfiles will > ignore them. That premise is untrue. Some module authors sync the version numbers of all files (like Chris apparently does); some prefer only to bump the version number in a file if that particular file has changed. If I'm sending a patch to a module author I sometimes try to make it be a complete patch for the distro -- including the code, the docs, updating the change-log, and so on. And hopefully I'd run the tests before submitting the patch. So the inclusion of versionsync.t would clue me in that Chris wanted all the version numbers changing, and I could do that in the patch, thereby reducing the work Chris has to do to accept my patch and increasing the chance of me getting the feature I wanted included. Or perhaps as a user of a module I think the docs could do with a little improvement. Before submitting a patch it'd be useful to run pod-coverage.t to check that I haven't missed anything or made matters worse. Remember that this is software with the source available -- so there isn't a strict author v user distinction: any user can suddenly elect to modify the code and become an author (even if only for modifying a private version). Smylers
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Moin, On Friday 03 February 2006 11:04, David Landgren wrote: > David Cantrell wrote: > > brian d foy wrote: > >> <[EMAIL PROTECTED]> wrote: > >>> Hopefully it will be something like: > >>> $I::don't::bother::to::write::portable::code=1; > >>> ;-) [snip] > > > > I want my code to be more like File::Spec, which provides a common > > interface to a load of platform-specific modules. That has very good > > coverage of bizarro OSes, and I think we'd all agree that it's an > > excellent example of a nice portable module. > > > > It doesn't work on RISC OS though. > > I suppose that this is less that RISC OS is so truly bizzare that it > defies anyone to come up with platform-specific File::Spec code for it, > and more a gentle nudge on your part for someone to find the tuits to > do so? Problaby just because the last guy running RISC OS has died 4 years ago. SCNR :-) Best wishes, Tels -- Signed on Fri Feb 3 11:29:15 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. This email violates EU patent EP0394160: [ ## 66% ] pgp4CHdQuKx4A.pgp Description: PGP signature
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
On Fri, Feb 03, 2006 at 11:30:13AM +0100, Tels wrote: > Problaby just because the last guy running RISC OS has died 4 years ago. > SCNR :-) Well, the list is *slightly* more active than that: http://www.nntp.perl.org/group/perl.riscos Nicholas Clark
Re: [perl #38348] [PATCH] Accept return values via a Continuation
From: Leopold Toetsch <[EMAIL PROTECTED]> Date: Tue, 31 Jan 2006 14:01:42 +0100 Bob Rogers wrote: >From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]> >Yep. At least as long we don't have better support for creating >limited continuations that are able to return some results. > > I'm afraid I don't follow. What would you consider better? Limiting the callframe range, where the continuation can go. Currently creating a continuation is rather expensive, as all RetContinuations up the call chain are converted into full continuations. This is necessary because there is no further information about the usage of the continuation. It could be passed to 'main' and then 'jump' back. Thus all the intermediate frames have to be kept alive, because normal function return goes through these frames. Hmm. In this particular case, that doesn't actually make much difference. In order to implement certain classes of nonlocal exits, I'm creating a continuation and stuffing it into a lexical variable, and I notice that C also promotes the RetContinuation to a Continuation (though only for that frame). Worse, the closed-over frame is leaked entirely. (Is this what the "obviously leaks memory" comment in src/register.c is talking about, or are there other cases of leakage?) But I think I have a handle on what's causing this, and hope to propose a fix shortly. >But, FWIW, I am coming around to the view that continuations > shouldn't ever be invoked like this . . . I don't think that we can enforce this. Have a look at t/library/streams.t. I don't think that a compiler has the knowledge that it's compiling the invocation of a continuation instead of a plain subroutine. Well, mine does, but that doesn't mean much. ;-} Point taken. The tailcall syntax works, because it's just ignored by the continuation. leo Yep; and it also avoids making a useless return continuation, which is nice. -- Bob
Re: embparrot still has two failures
On 03/02/06, Uri Guttman <[EMAIL PROTECTED]> wrote: > > "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > > LW> pugs -V: > > LW> This is Perl6 User's Golfing System, version 6.2.11, February 1, > LW> 2005 (r8945) built for i386-linux-thread-multi > > > not that this has anything to do with the bug(s) under question but i > see a y2k+5 bug right there. unless larry is working on a very old > version of pugs. and since it was first released about a year ago > according to audrey, i kinda doubt larry is working with v1.0. Fixed (hopefully) as of r8948. Thanks for pointing it out. Stuart
Re: [perl #38348] [PATCH] Accept return values via a Continuation
Bob Rogers wrote: Worse, the closed-over frame is leaked entirely. (Is this what the "obviously leaks memory" comment in src/register.c is talking about, or are there other cases of leakage?) But I think I have a handle on what's causing this, and hope to propose a fix shortly. Yep re comment. It's probably just a matter of setting the initial ctx->ref_count to 1. A context is either de-allocated immediately, if the sub returns via RetContinuation (re_use := 1 in src/register.c:500) or when the (ret)continuation is destroyed. The latter case needs a proper ref_count setting. I'm pretty sure that frames left via exception are also leaking currently, which would also be covered by above strategy. leo
Re: [perl #38348] [PATCH] Accept return values via a Continuation
On Tue, Jan 31, 2006 at 02:01:42PM +0100, Leopold Toetsch wrote: > Bob Rogers wrote: > > From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]> > > > Yep. At least as long we don't have better support for creating > > limited continuations that are able to return some results. > > > >I'm afraid I don't follow. What would you consider better? > > Limiting the callframe range, where the continuation can go. Currently > creating a continuation is rather expensive, as all RetContinuations up > the call chain are converted into full continuations. This is necessary > because there is no further information about the usage of the > continuation. It could be passed to 'main' and then 'jump' back. Thus > all the intermediate frames have to be kept alive, because normal > function return goes through these frames. Could this be done lazily? Presumably the ret continuations only need to be converted to full continuations just before they're returned through, or when any (other) continuation is invoked, for as long as the newly created continuation exists. I've no idea what the extra book-keeping overhead of this would be, and whether the savings would be big enough to pay for that overhead. Nicholas Clark
Re: [perl #38348] [PATCH] Accept return values via a Continuation
On Feb 3, 2006, at 15:49, Nicholas Clark wrote: On Tue, Jan 31, 2006 at 02:01:42PM +0100, Leopold Toetsch wrote: Limiting the callframe range, where the continuation can go. Currently creating a continuation is rather expensive, as all RetContinuations up the call chain are converted into full continuations. This is necessary because there is no further information about the usage of the continuation. It could be passed to 'main' and then 'jump' back. Thus all the intermediate frames have to be kept alive, because normal function return goes through these frames. Could this be done lazily? Presumably the ret continuations only need to be converted to full continuations just before they're returned through, The 'rather' expensive thing is basically: while (cont) cont->vtable = Parrot_base_vtables[enum_class_Continuation] cont = cont->caller i.e. placing a new vtable into the whole call chain. Setting some flag or whatever wouldn't be simpler. The only problem with above is that it's O(n) in call depth. Therefore the idea of creating 'limited continuations' that are only allowed to 'jump' between defined places in the call chain. No - I don't think that this can be done lazily. Nicholas Clark leo
Re: use of parrot built source tree in pugs
On Thu, Feb 02, 2006 at 08:18:14PM -1000, Beau E. Cox wrote: : Hi - : : When making pugs, I know that the following env must be : setup to imbed parrot: : : ... : export PUGS_EMBED="perl5 parrot" : export PARROT_PATH="/the/parrot/built/source/tree" : ... : : Is the parrot source tree only needed for the pugs make? Once pugs is made, I believe it only needs libparrot.so for the embedded parrot. However, if that libparrot.so is only in the parrot source directory, you're hosed if you remove it, so you need to be sure to install it. : Can I get rid of it after pugs is sucessfully installed? Probably. Several caveats: 1) You have to make sure libparrot.so (or .dll) is somewhere where it'll link in. 2) I haven't tried removing the parrot source tree myself, because 3) I find I want to recompile parrot and pugs pretty much every day just to see what's new. : Is this question stupid? Not at all. Though it seems like it would be easier to just test it than to ask. You don't actually have to remove the parrot source tree to hide it from pugs, after all. In fact, it's probably easier to test than the effort I've put in answering here. Fortunately for you, I am 1) just waiting for my coffee to brew and 2) able to type in my sleep. :-) Larry
Re: use of parrot built source tree in pugs
On Friday 03 February 2006 07:03 am, Larry Wall wrote: > On Thu, Feb 02, 2006 at 08:18:14PM -1000, Beau E. Cox wrote: > : Hi - > : > : When making pugs, I know that the following env must be > : setup to imbed parrot: > : > : ... > : export PUGS_EMBED="perl5 parrot" > : export PARROT_PATH="/the/parrot/built/source/tree" > : ... > : > : Is the parrot source tree only needed for the pugs make? > > Once pugs is made, I believe it only needs libparrot.so for the > embedded parrot. However, if that libparrot.so is only in the parrot > source directory, you're hosed if you remove it, so you need to be > sure to install it. > > : Can I get rid of it after pugs is sucessfully installed? > > Probably. Several caveats: 1) You have to make sure libparrot.so (or > .dll) is somewhere where it'll link in. 2) I haven't tried removing > the parrot source tree myself, because 3) I find I want to recompile > parrot and pugs pretty much every day just to see what's new. > > : Is this question stupid? > > Not at all. Though it seems like it would be easier to just test > it than to ask. You don't actually have to remove the parrot source > tree to hide it from pugs, after all. In fact, it's probably easier > to test than the effort I've put in answering here. Fortunately for > you, I am 1) just waiting for my coffee to brew and 2) able to type > in my sleep. :-) You are correct - it was easier to test than to ask. And...the asnswer is... Yes, the tree may be removed as long as parrot is installed. Thanks. > > Larry -- Aloha => Beau;
Re: something between "state" and "my"
On Fri, Feb 03, 2006 at 06:45:23AM +, Luke Palmer wrote:
: On 2/3/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
: >sub factorial(Int $x) {
: >temp state Int $result = 1;
: >$result *= $x;
: >factorial $x-1 if $x > 2;
: >return $result if want;
: >}
: >say factorial 6;
:
: That's precisely what "env" variables are for. The right way:
:
: sub factorial(Int $x) {
: env $result = 1;
: my sub fact(Int $x) {
: $+result *= $x;
: fact($x - 1) if $x > 2;
: return $result;
: }
: fact($x);
: }
:
: Of course, you can view env variables as implicit parameters. Given
: that, this function might be able to reduce to:
:
: sub factorial(Int $x) {
: env $+result = 1; # expecting $+result
: # param, default to 1
: $+result *= $x;
: fact($x - 1) if $x > 2;
: return $result;
: }
Hmm, that won't work in my current mental model, where an "env" is
used only in the outermost dynamic scope to declare the existence of
that outermost scope, and within that scope it behaves exactly like a
"my" variable. But that means that the assignment happens every time,
not as some kind of default.
If you don't have an outermost scope declarator, you've just basically
reinvented a less efficient version of globals and "temp", since "env
$+result" would always have to assume there was an outer dynamic scope
and scan outward to the root dynamic scope.
But that's just my current mental model, which history has shown
is subject to random tweakage. And maybe "env $+result" could be a
special squinting construct that does create-unless-already-created.
Doesn't feel terribly clean to me though. If we stick with the +
twigil always meaning at least one CALLER::, then clarity might be
better served by
env $result := $+result // 1;
assuming that $+result merely returns undef in the outermost env context.
Larry
Re: something between "state" and "my"
Larry Wall wrote: But that's just my current mental model, which history has shown is subject to random tweakage. And maybe "env $+result" could be a special squinting construct that does create-unless-already-created. Doesn't feel terribly clean to me though. If we stick with the + twigil always meaning at least one CALLER::, then clarity might be better served by env $result := $+result // 1; assuming that $+result merely returns undef in the outermost env context. Wouldn't that bind $result to a constant at the outermost scope -- and therefore to that same constant in all inner scopes? If so, then later attempts to assign $result would be an error.
Re: A GraphViz eye view of Parrot
On Wed, Feb 01, 2006 at 01:39:55PM -0800, Allison Randal wrote: > On Jan 31, 2006, at 16:26, Allison Randal wrote: > > >This'll likely be out-of-date tomorrow, but I found it useful as a > >quick snapshot/overview of the Parrot repository. The process used to created it isn't amenable to automation into a cron job? > > http://www.lohutok.net/parrot.pdf (200k) > > Sadly, it doesn't display in acrobat, but is fine in xpdf and For some values of xpdf :-( xpdf 1.00 and 1.01 both fail for me with: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 303 Current serial number in output stream: 337 so I guess that whatever xpdf needs to do to display it is an utter resource hog and wants way more than either of my rather old machines that act as X servers can actually provide. Maybe acrobat is also failing due to blowing some internal resource limits. Nicholas Clark
Re: something between "state" and "my"
On Fri, Feb 03, 2006 at 12:41:47PM -0800, Dave Whipp wrote: : Larry Wall wrote: : : >But that's just my current mental model, which history has shown : >is subject to random tweakage. And maybe "env $+result" could be a : >special squinting construct that does create-unless-already-created. : >Doesn't feel terribly clean to me though. If we stick with the + : >twigil always meaning at least one CALLER::, then clarity might be : >better served by : > : >env $result := $+result // 1; : > : >assuming that $+result merely returns undef in the outermost env context. : : Wouldn't that bind $result to a constant at the outermost scope -- and : therefore to that same constant in all inner scopes? If so, then later : attempts to assign $result would be an error. Hmm, well, it wouldn't work anyway since env variables are readonly by default outside their "my" scope. I ought to at least have said env $result is rw := $+result // 1; As for my $answer := 42; I would hope that binding a constant to a rw location is smart enough to make an anonymous rw copy (or COW). I think that's what most existing Perl programmers would expect. I'm sure a C++ programmer would argue it the other way though. But whichever way that goes, certainly if you want to make $answer a constant, the current design encourages you to do it explicitly with constant $answer = $mumble; rather than as an accidental side effect of binding a value that just happens to be a constant. And I think a good argument can be made that my $foo := "some text"; is a great way of sharing "some text" among all default instances of $foo, whereas my $foo = "some text"; would be required to force a copy, at least in the abstract. Of course, the existence of a COW string implementation can be taken as an argument either way. It really kind of depends on whether you see "some text" as an object or as primitive data that autoboxes when a container reference is requested. Larry
Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
On Feb 2, 2006, at 15:10, Patrick R. Michaud via RT wrote: ...as of r11409, I'm not seeing the 'make test' error for punie (on my Linux/x86_64 box). I don't know if this is because it's now working, or because you've routed around the particular problem you were seeing, so let me know if you're still getting the error and I'll look into it right away. I definitely would like to make sure it's not a PGE issue. :-) It's only in my local svk repository. I'll push it so others can work on the bug (and try it out on multiple platforms). I temporarily added a test file language/punie/t/problematic.t that isolates the failing test (makes it easier to filter through the debugging output). Allison
Re: TODO test paradox: better TODO test management?
* demerphq <[EMAIL PROTECTED]> [2006-02-01T03:26:55]
> And I think you've conveniently sidestepped my main point which is
> that TODO tests passing are errors. Consider you have two TODO tests,
> both of which depend on a common set of functionality. Both should
> pass or both should fail.
I just don't agree. I prefer the current model.
I defend your right to disagree, however, and support it with this idea:
strict_todo {
frobulate_ok("someone implemented frobulate()!!");
};
sub strict_todo(&) {
local $Test::Builder::OPPOSITE_WORLD = 1;
$_[0]->();
}
...where OPPOSITE_WORLD causes ok to be not ok, not ok to be ok, and cucumbers
to taste better pickled.
(I wouldn't exactly implement it that way, but you get the idea, and I bet that
a patch to provide test result reversal would not be unwelcome.)
--
rjbs
pgpSnXAlqhJnS.pgp
Description: PGP signature
Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
I've tested on FreeBSD 6.0 and OS X 10.3.9, and t/problematic.t is successful for both, both with r11418. But, I've encountered two major problems. On darwin, I can't finish past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7) wants 180 megs. On freebsd, it's actually worse, but more confusing. It fails with past_*.t and post_*.t. But past.t is fine. It's essentially a lot of out of memory errors(yet swap space isn't touched, and there's free ram at that moment). Darwin essentially starts "stalling" when freebsd just gives up on allocating more memory. Line numbers aren't given in the print out, except for src/memory.c line 92. On Feb 3, 2006, at 5:47 PM, Allison Randal wrote: On Feb 2, 2006, at 15:10, Patrick R. Michaud via RT wrote: ...as of r11409, I'm not seeing the 'make test' error for punie (on my Linux/x86_64 box). I don't know if this is because it's now working, or because you've routed around the particular problem you were seeing, so let me know if you're still getting the error and I'll look into it right away. I definitely would like to make sure it's not a PGE issue. :-) It's only in my local svk repository. I'll push it so others can work on the bug (and try it out on multiple platforms). I temporarily added a test file language/punie/t/problematic.t that isolates the failing test (makes it easier to filter through the debugging output). Allison
