making v6 test suite its own distro
As briefly discussed on #perl6 ... Now that we are fulfilling an intention for Perl 6 to have multiple fully decoupled implementations that are distinct from its spec, Pugs and v6.pm being the largest short term examples, I propose that we make like Sun and its Java VM validation suite, and start distributing the Perl 6 test suite as its own distribution on CPAN, which Perl6::Pugs and v6 then have as optional (for testing only) external dependencies. This way, for example, people who just want to use the pure Perl 5 v6.pm implementation of Perl 6 don't have to download Pugs in order to test it. Audrey suggested that it could be named v6::tests ... I previously to that suggested Perl6::Certification ... and other suggestions are welcome. From that point onward, neither the Perl6::Pugs nor v6 distros would include their own test suites, or such would be extremely basic. Their 'make test' and 'make smoke' would instead call out to v6::tests. (A substantial part of the testing and/or smoking harness should probably also be included, so people that use it get more consistent formatted results that can be compared, though some details will need to be in the individual implementation distros, as only they know how they are invoked. Whether that is written in Perl 6 or Perl 5 or something else is less of an issue short term.) On a separate but related matter, I suggest also separating anything else that isn't Pugs specific, that is common to both it and v6, from the Pugs distro and distributing those separately. This includes the contents of: examples/ , ext/, some of docs/, some of util/, and so on. These various distros can be distributed on their own schedule, as frequent or infrequent as makes sense, just as v6 and Moose et al are. As to whether any of the above are still maintained within Pugs SVN or moved to separate SVN, that is a possibly orthogonal matter. Seeing as the next Pugs release, 6.28.0, is psychologically a major release, I suggest that the various decoupling I am talking about above be accomplished prior to that, so that Pugs 6.28.0 and later are slimmed down and don't contain the shared components. The Pugs only distro will probably feature what is in src/ now and what is needed to support that. Audrey suggested separation before OSCON, even. Of course, feedback always welcome. -- Darren Duncan
Re: [Slightly OT] Understanding Software Licences
On Saturday 08 July 2006 08:21, Adam Kennedy wrote: From my interpretation, what he said was I don't care to understand licenses enough so I don't want to be bothere with it. Now I think this is a rather small-minded approach to this issue, which I think is very bad. Perhaps, the response to Ovid about it instead of this message was not appropriate, or I may have misunderstood what Ovid said. ... What I did claim that people who refuse to understand the various common open source licences and when it is appropriate to use one of them, are acting small-mindedly (or small-headedly) in this context. For the record, I refuse to understand the various common open source licenses, and when it is appropriate to use one of them. So instead, for the win32.perl.org logo and the Strawberry Perl license bundling issues, even though I don't see a problem, on the advice of Randal and Allison I've asked to pass on the details of both issues to the TPF Intellectual Property lawyers for revue, and I've been lucky enough that I've been allowed to burn a few hours of their time on this issue. I may be ignorant, but I'm not naive, and I know it matters. But I shouldn't have to put in the effort to learn this stuff. And most of the people here are the same. They remain ignorant, not because they don't care, but because they prefer to defer to others who DO understand more than we ever could. This does not make them small-minded at all, just pragmatic. Fair enough. I prefer to be both knowledgable and pragmatic. I.e: hope I understand when something is legal, but also perhaps have to consult lawyers when in doubt. I should also note that licences such as the GPL are often mis-understood or can have various grey areas by anyone (including some lawyers). For example, recently after Solaris became OpenSolaris under a free software but non-GPL-compatible licence, some people wanted to start a Debian GNU/Solaris distribution. However, some people in Debian told them that the GPLed code in Debian could not be linked with the OpenSolaris standard libraries (libc, libm, etc.) that were non-GPL compatible. Obviously this is non-sense, because it was perfectly legal to build and distribute the binaries for the various GPLed GNU programs for Solaris and other proprietary Unixes (and MS Windows, too) before they became open source, because the GPL allow it. But still a concern was raised. My wiki page was not aimed at anyone personally - I was just trying to set up a good resource to better educate people about it. It's not a replacement for consulting with a lawyer on various fine points, but it can help to better understand the surrounding issues, and also make better decisions. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP Namespace Nonproliferation Treaty
I'm perfectly comfortable with this idea, but what I'm trying to figure out then, is the namespace for my parser. It's a TAP parser, after all. Any suggestions? I see that Adam has suggested a TAPx:: namespace, but there could still be competing TAPx::Parser modules. Don't know if that would bug folks, though. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: TAP Namespace Nonproliferation Treaty
Ovid wrote: I'm perfectly comfortable with this idea, but what I'm trying to figure out then, is the namespace for my parser. It's a TAP parser, after all. Any suggestions? I see that Adam has suggested a TAPx:: namespace, but there could still be competing TAPx::Parser modules. Don't know if that would bug folks, though. TAPx::CPANID::Parser ? N
Re: TAP extension proposal: test attributes
Yuval Kogman wrote: On Fri, Jul 07, 2006 at 08:36:33 -0500, Scott Bolte wrote: I propose using of subset of the Config::Std syntax to allow tests to declare attributes that are captured in Test::TAP::Model as a hash. That would allow the test to declare configuration information, such as its dependencies, which would be available to downstream processors of the test results. I would like this on a per-test-case level too. Pugs' test suite uses a weird syntax in the descriptions to spill out the todo category (not reason, but whether it's a bug, a force todo, unspecced, etc), the position of the test so that we can use backlinks, and color the test file in HTML, and potentially other info. It would be nice if this would be standardized. This would eliminate my earlier proposal for have an optional line number in the protocol. I wanted this so that Smolder could have the same coolness as the pugs test server, without having my users modify their tests. Ideally this is what I would like to see. Some general attributes became semi-standard (like line number) then Test::Builder will automatically emit these attributes. This could be controlled by the environment, so that under normal testing the developers don't see too much clutter, but the harness itself could ask the tests to emit as much data as it wants. -- Michael Peters Developer Plus Three, LP
Re: TAP Namespace Nonproliferation Treaty
- Original Message From: Nik Clayton [EMAIL PROTECTED] Ovid wrote: I'm perfectly comfortable with this idea, but what I'm trying to figure out then, is the namespace for my parser. It's a TAP parser, after all. Any suggestions? I see that Adam has suggested a TAPx:: namespace, but there could still be competing TAPx::Parser modules. Don't know if that would bug folks, though. TAPx::CPANID::Parser Thought about that, but immediately discarded it. TAPx::OVID::Parser doesn't say anything about the parser other than authorship and the latter is verified by glancing at the docs. My jumping on the TAPx::Parser namespace is almost as bad as my taking TAP::Parser, so I'm just trying to figure out how to truly distinguish my (currently incomplete) parser from others. I suspect it will be as arbitrary as your idea, though :) How about TAPx::PerlOrArtisticLicense::Parser? :) Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Methods vs. Subs
Is there anything that you can do with a sub (first parameter being some sort of object) that you cannot do with a method? Frex, given: multi method my_method($invocant:); would topical_call := my_method.assuming :invocant$_; be legal? -- Jonathan Dataweaver Lang
Re: check if all the links on an HTML page are working (except the mailto links)
On 7/6/06, Andy Lester [EMAIL PROTECTED] wrote: On Jul 6, 2006, at 10:22 AM, Gabor Szabo wrote: Using Test::WWW::Mechanize 1.10 I am trying to $w-page_links_ok(); on a page that has an e-mail address in it and the test fails. How could I tell TWM not to bother with the mailto links on the page? That's silly that it tries the mailto. I'm fixing it right now. thanks. 1.12 works well. Gabor
Testing various HTML constructs
During web testing using Test::WWW::Mechanize I can check if the current page has the correct links (by fetching all links) and if the pages has the correct forms with the correct input fields. How can I check other HTML constructs? Specifically I know there should be two tables on the page. One of them belongs to a form the other one should contain a list of device names. How can I retreive the list of tables and then how can I parse the tables? Later I'll have to check 'ordered lists' and then other constructs. I guess I can write up something using HTML::Tree but I wonder if there is something similar to the -forms method of Mechanize just called -tables. Running a new search on CPAN brought up HTML::TableExtract that sounds good. What about other HTML constructs? Gabor
Re: Testing various HTML constructs
* Gabor Szabo [EMAIL PROTECTED] [2006-07-08 18:10]: How can I check other HTML constructs? I’d marry XML::LibXML’s HTML parsing mode into W::M so I could prod the document with XPath expressions, then I’d add some convenience methods added T::W::M. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Methods vs. Subs
On Sat, Jul 08, 2006 at 07:42:06AM -0700, Jonathan Lang wrote: : Is there anything that you can do with a sub (first parameter being : some sort of object) that you cannot do with a method? Frex, given: : : multi method my_method($invocant:); : : would : : topical_call := my_method.assuming :invocant$_; : : be legal? Yes, it's certainly legal, but it's not quite the same semantics. A sub guarantees at compile time exactly which routine is going to be called. Your example would need a ::= to do that. But even with that it doesn't really guarantee which my_method you're going to get, in the sense that .assuming is going to have to do a partial method dispatch, and which method it finds will depend on the value of $_. Furthermore, ::= would force that to mean the compile-time value of $_, which is probably not what you want anyway. As far as I can figure, there's no way of defining topical_call such that it knows to .assume $_ as its invocant without actually evaluating $_ at the time .assuming is called, since .assuming doesn't merely set the default; it's a partial dispatch, and throws away the assumed parameter slot entirely from the viewpoint of the subsequent caller. It may well have to keep track of the slot for implementation, however--as a partial dispatch, topical_call may in fact represent a set of remaining candidates to be multi dispatched, and merely setting one parameter with .assuming shouldn't imply that that's the entire eventual parameter list. That is, it mustn't assume that the supplied parameters are delimited with semicolons in the receiving signature. So for purposes of implementation, it does behave merely like a default. Go figure... Larry
Doc error in TAP.pm?
Hi all, In TAP.pm, the document I'm using as my official reference for parsing TAP, I've noticed the following in the definition of description: Any text after the test number but before a # is the description of the test point. From my observations of test behavior, the shouldn't that be the following? Any text after the test number but before *an unescaped* # is the description of the test point. Example: TAPx-Parser $ perl -MTest::More=no_plan -e'ok 1, # TODO annoy perl-qa' ok 1 - \# TODO annoy perl-qa 1..1 Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: TAP Namespace Nonproliferation Treaty
On Sat, Jul 08, 2006 at 05:10:50AM -0700, Ovid wrote: - Original Message From: Nik Clayton [EMAIL PROTECTED] TAPx::CPANID::Parser Thought about that, but immediately discarded it. TAPx::OVID::Parser doesn't say anything about the parser other than authorship and the latter is verified by glancing at the docs. My jumping on the TAPx::Parser namespace is almost as bad as my taking TAP::Parser, so I'm just trying to figure out how to truly distinguish my (currently incomplete) parser from others. I suspect it will be as arbitrary as your idea, though :) Also naming modules with the original author's CPANID is going to become fun if maintainership is transferred, or the original author wants to start a clean second implementation. Nicholas Clark
Bail out! questions
From TAP.pm:
--
Bail out!
As an emergency measure a test script can decide that further tests are useless
(e.g. missing dependencies) and testing should stop immediately. In that case
the test script prints the magic words
Bail out!
to standard output. Any message after these words must be displayed by the
interpreter as the reason why testing must be stopped, as in
Bail out! MySQL is not running.
--
What should be the appropriate behavior for the TAPx::Parser? (Namespace
suggestions still wanted) Should it stop lexing/parsing the output? Should it
check to see if there's additional output and spit out a different warning?
Should it just treat it as a Bail out! line and continue parsing like normal
and let the code using the parser handle that?
if ( $test-is_bail_out ) { ... }
Cheers,
Ovid
-- If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Thu, Jul 06, 2006 at 05:39:45PM -0700, jerry gay wrote: am i silly to think that if i'm looking for globals from the current namespace, they're just as likely to be found closer to the namespace root, than further away? perhaps something like .namespace [ 'Foo'; 'Bar' ] $P0 = get_cur_global -1, 'x' # [ 'perl5' ; 'Foo' ; 'x' ] There's a technical reason for this omission. The only way to get to namespace '..' (using the Unix analogy) is to ask the namespace for its parent, and I don't want to do that. Given the presence of namespace aliasing, a namespace isn't guaranteed to have a single parent, or that that parent will be the one it was, er, born with. The compiler knows the full name and it's easy enough for the compiler to strip the last element off the namespace path. -- Chip Salzenberg [EMAIL PROTECTED]
bsr/ret, continuations, and other stack rewinding bugs
From: Allison Randal [EMAIL PROTECTED]
Date: Wed, 05 Jul 2006 00:02:53 -0700
Bob Rogers wrote:
If, as seems likely, exception bookkeeping is moved to a separate
stack in the interpreter (with or without dynamic-wind actions), then
Cbsr/Cret addresses can stay in the Parrot_Context, and all of
pdd23_exceptions.pod that is quoted below ceases to be problematic.
Does that seem reasonable?
Yeah, that's the current best solution (the last time Chip and I talked
on Saturday). I'd like avoid a stack entirely, but this is a
straightforward first attack on the problem. If we implement a separate
exception stack now and run into problems, we can refine and refactor later.
Were you thinking of using the same stack for dynamic binding context
and stack-winding actions as well? Or would these go on separate
stacks?
In what follows, I will speak of these collectively as the dynamic
state stack, with the understanding that it may need to be pluralized.
(And the further understanding that continuations and coroutines can
make it branch, just like the Parrot_Context = RetContinuation stack.
So maybe we need a better word?)
It's an encouraging sign that we've got hold of a good idea when the
same solution occurs to others independently. :)
Thanks,
Allison
Well, yesterday I thought of a problem with this. So maybe that just
means that we're all sharing the same delusion. ;-}
The snag is that calling a continuation would return to the
Parrot_Context with the return stack state as it was when the context
was last left, which could be different than when the continuation was
taken. What I would expect to happen is that the continuation also
captures the return stack state, as part of the dynamic context, so I
would argue that this is a bug.
This is currently not a problem with respect to error handling, since
the stack-unwinding done by Cthrow implicitly pops return addresses as
well, because it's the same stack. However, it does fail now with other
uses of continuations, as shown by the first new test case in the
attached patch. One could argue that maybe it is not worth fixing the
general case. However, separating the stacks as proposed would extend
this bug to cover the Cthrow case as well, and it is probably not
acceptable to say that you can't depend on the return stack after error
recovery. True?
Continuations also don't run actions (as shown by the second new test
case), and they don't preserve error handlers for the same reason --
these bugs are much more serious. Furthermore, I assume dynamic binding
would be similarly affected. (In fact, I've been itching to fix all of
this for almost six months now, but I think it needs to be done as part
of a general cleanup of dynamic state bookkeeping -- I now have more
tuits, but I don't yet understand the changes you are proposing well
enough to get started.)
The obvious solution is to save the current return stack TOS along
with that of the dynamic state stack(s) in the continuation, so that it
can be restored when the continuation is invoked. The drawback is that
doing so complicates the storage management of return stack entries.
This is the same complication that must be borne by dynamic state stack
entries, but it seems a shame to have to extend it to something that
otherwise would obviously belong strictly to the Parrot_Context in which
it was pushed.
So maybe there needs to be One Dynamic Stack (or whatever we call
it), so that we can unify the bookkeeping? This would also require that
all of these things nest properly, but that's no change from the current
implementation -- and nobody seems to have complained.
-- Bob
Index: t/pmc/continuation.t
===
--- t/pmc/continuation.t (revision 13078)
+++ t/pmc/continuation.t (working copy)
@@ -33,6 +33,114 @@
ok 1
OUT
+$TODO = BUG: continuations don't preserve the control_stack.;
+pir_output_is('CODE', 'OUT', 'continuations preserve bsr/ret state.');
+## Here is a trace of execution, keyed by labels.
+## L1: bsr to rtn1
+## rtn1: create a continuation that directs us to L6, and (we expect) captures
+##captures the whole dynamic state, including the return address to L3.
+## L3: return back to main
+## L4: if we're here the first time, call rtn2
+## rtn2: call the continuation from that routine.
+## L6: print Continuation called. and return, which should take us . . .
+## L3: here the second time, where we print done. and exit.
+.sub test_control_cont :main
+L1:
+ .local int return_count
+ .local pmc cont
+ return_count = 0
+ bsr rtn1
+L3:
+ unless return_count goto L4
+ print done.\n
+ end
+L4:
+ inc return_count
+ bsr rtn2
+ print Oops; shouldn't have returned from rtn2.\n
+ end
+L6:
+ print Continuation called.\n
+ ret
+rtn1:
+ print Taking continuation.\n
+ cont = new .Continuation
+ set_addr
Re: pdd21 vs. find_global
On Sat, Jul 01, 2006 at 10:37:59PM -0500, Allison Randal wrote: I'm more inclined to say find_global just shouldn't accept a namespace PMC as an argument. For those who aren't reading the subversion logs: 1. Why aren't you? :-) 2. I've done this -- Chip Salzenberg [EMAIL PROTECTED]
A PDD for dynamic-wind?
From: Chip Salzenberg [EMAIL PROTECTED] Date: Sat, 24 Jun 2006 21:56:32 -0700 On Sat, Jun 24, 2006 at 11:18:41PM -0400, Bob Rogers wrote: Such an implementation is truly and utterly stackless, which means that dynamic-wind needs to keep its own stack explicitly, and similarly for dynamic binding (which, IIUC, is generally implemented in terms of dynamic-wind). ... actually describes Parrot, present and future. Parrot doesn't need to recurse in C to invoke continuations or closures . . . Understood. However, Parrot uses an explicit chain of Parrot_Context = RetContinuation = Parrot_Context = ..., which (IIUC) is something a pure CPS implementation does not require. That's all I meant. And my intended implementation of dynamic-wind actually does require its own stack, separate from the current control stack . .. Is there a PDD forthcoming? If not (or even if so), would you (Allison now, presumably?) like help writing it? -- Bob Rogers http://rgrjr.dyndns.org/
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
found. (particle++ for the finding) }
On Fri, Jul 07, 2006 at 12:46:35AM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
Well, I see a lot to like about this, but (and you knew there was a but
(but that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
Always a pleasure.
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
Agreed, with a note of balance that we also want to avoid the pain of
XS. Sometimes you need to poke into the guts of the system, and when you
do, you want it to be pleasant to work with, even though it's not fancy.
Point well taken. Pain is acceptable but not a goal.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
This is non-evil. :)
grin/
I would rename 'get_cur_global' to 'get_global'. The selected namespace
indicates that most of the code belongs in that namespace, so it's
likely that most of the variables do too. (There are variations, but
that's at least the common case.)
Works for me. And that is the current meaning of two-parameter find_global,
so it's not a stretch.
Then, what to call the HLL root access opcodes... perhaps 'get_rel_global'
(for relative root)?
Hrm. Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately clear:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_global 'x' # ['perl5';'Foo';'x']
$P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_hll_global 'x' # ['perl5';'x']
$P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
Seems to me that we should have get_namespace patterned just alike:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_namespace # ['perl5';'Foo']
$P0 = get_namespace ['Bar'] # ['perl5';'Foo';'Bar']
$P0 = get_hll_namespace # ['perl5']
$P0 = get_hll_namespace ['Corge'] # ['perl5';'Corge']
$P0 = get_abs_namespace # [] :-)
$P0 = get_abs_namespace ['parrot']# ['parrot']
I'm still not entirely happy with abs, but I can live with it, especially
since its use should be quite rare.
--
Chip Salzenberg [EMAIL PROTECTED]
TAPx::Parser 0.02
Hi all, The next version of my TAP parser is at http://users.easystreet.com/ovid/downloads/TAPx-Parser-0.02.tar.gz It's still not complete, but it's a lot further along than it was. Some notes from Changes: 0.028 June, 2006 - Moved some lexer responsibility to the parser. This will allow us to eventually parse streams. - Properly track passed/failed tests, even accounting for TODO. - Added support for comments and unknown lines. - Allow explicit and inferred test numbers to be mixed. - Allow escaped hashe marks in the test description. - Renamed to TAPx::Parser. Will probably rename it again. Note that it does not yet handle streams, but that's kind of low on my list right now (though it is on my list). Just to give you an idea of what it can do, for this test: ok 1 - input file opened We get this: my $test = shift @results; isa_ok $test, $TEST; ok $test-is_test, '... and it should identify itself as a test'; is $test-ok, 'ok', '... and it should have the correct ok()'; ok $test-is_ok, '... and the correct boolean version of ok()'; is $test-number, 1, '... and have the correct test number'; is $test-description, '- input file opened', '... and the correct description'; ok !$test-directive, '... and not have a directive'; ok !$test-explanation, '... or a directive explanation'; ok !$test-is_skip, '... and it is not a SKIPped test'; ok !$test-is_todo, '... nor a TODO test'; is $test-as_string, 'ok 1 - input file opened', '... and its string representation should be correct'; There are still some bugs, but it's definitely getting there. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Using Perl in QA departments
On Saturday 17 June 2006 22:12, Gabor Szabo wrote: If anybody is interested on this list, the slides and the examples of my 2 days course are available here: http://www.szabgab.com/perl_in_test_automation.html Started reading them - they're very nice. Thanks for sharing them! One note I'd like to add: I believe that in: http://www.szabgab.com/talks/perl_in_testing/test-functions-improved.html You'd want to add: local $Test::Builder::Level = $Test::Builder::Level + 1; To the testing function, so it will correctly report the line from which it was called. (Because T::B uses caller()). Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
[perl #39768] [TODO] Tcl - Switch to runtime errors?
# New Ticket Created by Matt Diephouse # Please include the string: [perl #39768] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39768 The official Tcl implementation doesn't throw any errors at compile time because it doesn't have one (not even in the sense that Perl5 does). As a compiler, we are left with two options: 1) Throw compile time syntax errors anyway because they're arguably the Right Thing To Do. 2) Fake it and output code that throws an error at runtime. Option 2 is probably the correct one to take, but it can easily be made later. So for now we'll just go with option 1 because it's implemented. Here's an example that shows the difference: puts hi puts [set a 4 That outputs hi\n with tclsh before dying with the syntax error. Partcl just dies without outputting anything. -- Matt Diephouse
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg [EMAIL PROTECTED] wrote:
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
found. (particle++ for the finding) }
chip++ :-)
On Fri, Jul 07, 2006 at 12:46:35AM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
Agreed, with a note of balance that we also want to avoid the pain of
XS. Sometimes you need to poke into the guts of the system, and when you
do, you want it to be pleasant to work with, even though it's not fancy.
Point well taken. Pain is acceptable but not a goal.
Good points.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
This is non-evil. :)
grin/
I would rename 'get_cur_global' to 'get_global'. The selected namespace
indicates that most of the code belongs in that namespace, so it's
likely that most of the variables do too. (There are variations, but
that's at least the common case.)
Works for me. And that is the current meaning of two-parameter find_global,
so it's not a stretch.
Works for me too. I'm not sure that I like the rename (I can't
decide), but the name itself doesn't matter much. The new opcodes (the
presence of get_cur_global) may actually make things easier for Tcl if
we ever compile to 100% inlined PIR.
This is a different route than I was trying to take us, but it should
be almost functionally equivalent, so I'm happy with it.
--
matt diephouse
http://matt.diephouse.com
S29 update ready
I've gathered my ducks in a row, used the feedback that I've gotten so far, and I think I'm ready to officially update S29. For that I need two things: 1) I'd really like Larry to glance over the changes and $s29.bless but all comments are welcome 2) I'll need commit rights to whatever repository is authoritative for Functions.pod these days Here is the current version (I've added chr and ord docs now): http://www.ajs.com/svn/ajs/perl6/Functions.pod If anyone has any comments at all, please send me mail or respond to the list. I'll try to address everything I can. This is the first big update. There will be more if this all goes well.
Re: A PDD for dynamic-wind?
On Sat, Jul 08, 2006 at 05:10:57PM -0400, Bob Rogers wrote: And my intended implementation of dynamic-wind actually does require its own stack, separate from the current control stack . .. Is there a PDD forthcoming? If not (or even if so), would you (Allison now, presumably?) like help writing it? As for me, namespaces need to be fully and completely put to bed before I can move on. I'd love to do exceptions next, but I suspect that I can't really do exceptions properly until we have proper dynamic scopes. EHs may not be controlled entirely by the general dynamic scope mechanism, but their definitions and mechanisms for entering and leaving must be identical. Personally I'd love to see your interpretation of dynamic-wind in Parrot. And PDD format is a fine format to present a complete idea so that it can be easily understood and, perhaps, adopted. PS: All of this is about foreground projects. Background and bug fixes always go on. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Any Clue about Devel::Cover Error Message Corrupted storable file (binary v2.7) at ../../lib/Storable.pm
Thanks Paul! (1) Yes, we do send SIGKILL (9) to kill the parent process even the child processes are still running and our purpose is to have a clean kill from root, so, do you think send SIGKILL (2) will be better? or, we could consider to send SIGKILL (2) to kill all the child processes before send SIGKILL (2) to kill parent process, do you think this may help? (2) Maybe you could send it something a little nicer which might allow to process to clean up., any more detail suggestion and example will be appreciated! (3) We might also consider to give some sleep time before destroy the test object, which causes process killing and cleaning up, but, is there a way we can know Devel::Cover has doen its work to write data? (4) Devel::Cover does its work in the very last END block., does this mean that Devel::Cover will not write data until the main test process run to its end? For example, a perl test script loads the perl module that is under testing and excise the functions in that module, sometime the test script needs use system to call some other perl scripts (that also is under testing), Devel::Cover will not write data until the main test script reach its end point or exit? (5) Is there a way we can tell which data files (under structure folder?) have been corrupted? We are trying to integrate Devel::Cover into our regular test driven development process, to make Devel::Cover, the amazing code coverage tool in Perl world, work correctly with our test to improve the data accuracy is very critial for us to move forward with the code coverage tool. Thanks a lot for your kind helps! Scott --- Paul Johnson [EMAIL PROTECTED] wrote: On Fri, Jul 07, 2006 at 10:26:13AM -0700, Scott Wang wrote: Hi Paul, Even, currently, there is no any zero size data file in structure folder in my regression code coverage run (lots of suites), I still got lots of messages like below: --- Corrupted storable file (binary v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 331, at //Devel/Cover/DB/Structure.pm line 269 END failed--call queue aborted. - Seems some data files got corrupted somehow. The process killing (kill parent process before killing child process and make chid process be terminated abnormally) is one possibility, I also noticed that useing system or other folk method to execute command could also cause this problem. Any clue about above issue Corrupted storable file (binary v2.7) at ... and does anybody also experience this issue and know how to deal with it? Also, does anybody have similar experience on killing process and folking process cause Magic number ... issue and orrupted storable file ... issue? In lieu of discussing either licences or alligators, let me try to answer this. Killing the process sounds like the most likely cause of this problem. If you manage to kill the process while it is writing out a storable file the file will very probably be corrupted. How are you killing the process? Are you sending it SIGKILL (9) for example? Maybe you could send it something a little nicer which might allow to process to clean up. Devel::Cover does its work in the very last END block. You really need to let it run to completion. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: S29 update ready
On Sat, Jul 08, 2006 at 06:04:40PM -0400, Aaron Sherman wrote: : I've gathered my ducks in a row, used the feedback that I've gotten so : far, and I think I'm ready to officially update S29. For that I need two : things: : : 1) I'd really like Larry to glance over the changes and $s29.bless but : all comments are welcome I'll be glad to do that. But first things first... : 2) I'll need commit rights to whatever repository is authoritative for : Functions.pod these days A pugs commit bit is on its way to you. Just keep checking it into the pugs repository for now. It's a good place for collaboration. Don't be afraid to check in intermediate results--we can always revert it. :) Larry
Parrot Exceptions
Hi, I would like to throw a Parrot Exception from IMCC to the calling program instead of terminating IMCC when a parse error occurs. Are there some example in Parrot as to how to throw a Parrot exception and how to catch it? -Vishal
[svn:parrot-pdd] r13214 - in trunk: . docs/pdds
Author: allison
Date: Sat Jul 8 16:48:27 2006
New Revision: 13214
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[EMAIL PROTECTED]: allison | 2006-07-08 16:37:32 -0700
[pdd23]: Answered some questions and refined process descriptions.
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 8 16:48:27 2006
@@ -60,9 +60,9 @@
=item Bpop_eh
-Pop the most recently pushed exception handler off the control stack.
+Pop the most recently pushed exception handler off the exception handler stack.
-{{ TODO: Provide control stack introspection. }}
+{{ TODO: Provide exception handler stack introspection. }}
=item Bthrow IEXCEPTION
@@ -96,13 +96,9 @@
Exception handlers can resume execution immediately after the Cthrowcc
opcode by executing the Chandled opcode, and then invoking the given
continuation which they receive as a parameter. That continuation must be
-invoked with no parameters; in other words, Cthrowcc may Inot return a
+invoked with no parameters; in other words, Cthrowcc never returns a
value.
-{{ TODO: Resuming immediately after the Cthrow opcode isn't quite
-flexible enough. Perl 6, for example, resumes control flow after the end
-of the block in which the exception was thrown. }}
-
=item Bdie [ IMESSAGE ]
The Cdie opcode throws an exception of type Cexception;death with a
@@ -110,8 +106,8 @@
payload is a CString PMC containing IMESSAGE; if IMESSAGE is a PMC, it
is used directly as the exception payload.
-{{ TODO: What is the default when no IMESSAGE is given? Something like
-Fatal exception at LINE in FILE. followed by a backtrace. }}
+The default when no IMESSAGE is given is Fatal exception at LINE in
+FILE. followed by a backtrace.
If this exception is not handled, it results in Parrot returning an error
indication and the stringification of IMESSAGE to its embedding environment.
@@ -143,47 +139,51 @@
=over
=item 1
-Find the topmost exception handler
+Find the topmost exception handler.
=item 2
-Push an exception record somewhere, presumably on the control stack.
-The exception record contains a pointer to an exception handler block
-and an exception PMC (and possibly a continuation)
+Push an exception record somewhere, presumably on the exception handler
+stack. The exception record contains a pointer to an exception handler
+block, an exception PMC, and (optionally) a continuation.
=item 3
Invoke the handler (note: this is still in the thrower's dynamic
-context)
+context).
=back
-If the handler returns normally:
+If the handler returns without calling Chandled:
=over
=item 1
-Find the exception handling in progress record
+Find the exception handling in progress record.
=item 2
-Find the next exception handler
+Find the next exception handler.
=item 3
-If the handler is found, invoke it
+If the handler is found, invoke it.
+
=item 4
-Or if there is a continuation in the exception record
-(because the throwing opcode was Cthrowcc),
-invoke the ER's continuation (i.e. resume execution)
+If no handler is found, and the exception is non-fatal (such as a
+warning), and there is a continuation in the exception record (because
+the throwing opcode was Cthrowcc), invoke the continuation (resume
+execution). Whether to resume or die when an exception isn't handled is
+determined by the severity of the exception.
=item 5
-Otherwise terminate program a la Cdie
+Otherwise terminate program a la Cdie.
=back
-{{ TODO: this isn't right, another option is a) invoke the handler, b)
-the handler calls handled, and c) invoke the continuation to resume
-because the exception was handled. The question of whether to resume or
-die when an exception is never handled is determined by the severity of
-the exception, not by the simple fact of having a continuation. }}
+When running an embedded Parrot interpreter, the interpreter does not
+immediately terminate on an unhandled exception, it merely returns
+control to the embedding program and stores the unhandled exception so
+that it may be queried by the embedding program. The embedding program
+may choose to handle the exception and continue execution by invoking
+the exception's continuation.
When the Chandled opcode is called:
@@ -191,7 +191,11 @@
=over
=item 1
-Pop and destroy exception record
+Pop and destroy the exception record.
+
+=item 2
+If there was a continuation in the exception record, invoke the
+continuation.
=back
@@ -251,10 +255,6 @@
Cset_inner_exception() method to store that previous exception
as part of the exception object.
-{{ TODO: Should we use properties instead? ANR: I'm not sure what you
-mean by an exception is a consequence of a previous exception.
-Example? }}
-
=back
PDD 23 Exceptions - ready for implementation
Chip did a fantastic job on the Exceptions PDD. With a few refinements, I'm pronouncing it ready to implement. We'll certainly work out more details as we go along, but the best way to test the design is to start on the code. Allison
Building a Fedora package
I've been working on building Fedora Extras packages for parrot and pugs off and on for the last couple of weeks. I have something that works fine on i386, but on x86_64 there are two issues. First, there is a hardcoded lib somewhere that I can't seem to find. On x86_64, libraries should get dropped in /usr/lib64, but make install never creates /usr/lib64/parrot. Pointers on how to override that would be greatly appreciated. I have a lot of cruft in the current version of the spec from where I was trying to fix that problem. I'm sure most of it is bogus, so try to ignore it if you look at this... :-) http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec Second, ICU detection fails. (I haven't had time to look into this yet.) Thanks in advance for any help... Steve -- Steven Pritchard - KS Pritchard Enterprises, Inc. Email: [EMAIL PROTECTED] http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320
RE: S29 update ready
-Original Message- From: Aaron Sherman [mailto:[EMAIL PROTECTED] Sent: Saturday, July 08, 2006 6:05 PM To: Perl6 Language List Subject: S29 update ready I've gathered my ducks in a row, used the feedback that I've gotten so far, and I think I'm ready to officially update S29. For that I need two things: 1) I'd really like Larry to glance over the changes and $s29.bless but all comments are welcome 2) I'll need commit rights to whatever repository is authoritative for Functions.pod these days Here is the current version (I've added chr and ord docs now): http://www.ajs.com/svn/ajs/perl6/Functions.pod If anyone has any comments at all, please send me mail or respond to the list. I'll try to address everything I can. This is the first big update. There will be more if this all goes well. I have one minor comment about join. You should specify its behavior when it is passed an empty list. Does it return undef or the empty string? Joe Gottman
RE: S29 update ready
At 6:25 PM -0700 7/8/06, Darren Duncan wrote: At 8:32 PM -0400 7/8/06, Joe Gottman wrote: I have one minor comment about join. You should specify its behavior when it is passed an empty list. Does it return undef or the empty string? I think it makes the most sense for it to return an empty string, which is a reasonable degenerate case of a string-join. -- Darren Duncan Or to put it another way, I see string-join being like a prefix version of the ~ operator (though with extra features), and so the reduce rules of ~ should perhaps determine it. According to Synopsis 3, [~]() returns the empty string. -- Darren Duncan
RE: S29 update ready
At 8:32 PM -0400 7/8/06, Joe Gottman wrote: I have one minor comment about join. You should specify its behavior when it is passed an empty list. Does it return undef or the empty string? I think it makes the most sense for it to return an empty string, which is a reasonable degenerate case of a string-join. -- Darren Duncan
Anyone experiencing problems with rt.cpan.org?
In the last day or so, every time I go to rt.cpan.org, it seems to nearly finish loading a page and then just stalls. Deleting the cookie for it seemed to help briefly, and then it stalled again after submitting a bug report. Are others experiencing difficulty? Regards, David Golden
Re: Doc error in TAP.pm?
On 7/8/06, Ovid [EMAIL PROTECTED] wrote: Any text after the test number but before a # is the description of the test point. From my observations of test behavior, the shouldn't that be the following? Any text after the test number but before *an unescaped* # is the description of the test point. There currently is no escape syntax defined in TAP. Test::Harness understands \# only with respect to descriptions. http://perl-qa.yi.org/index.php/TAP_escape_syntax
Re: Testing various HTML constructs
On Jul 8, 2006, at 10:31 PM, Michael G Schwern wrote: If your XPath parser balks at non-XHTML HTML then just run it through HTML::Tidy-clean which will convert it to XHTML. Usually. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Testing various HTML constructs
On 7/8/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Gabor Szabo [EMAIL PROTECTED] [2006-07-08 18:10]: How can I check other HTML constructs? I'd marry XML::LibXML's HTML parsing mode into W::M so I could prod the document with XPath expressions, then I'd add some convenience methods added T::W::M. I've had some luck with Max Maischein's Test::HTML::Content which has XPath support. XPath can get a little hairy but its well worth learning as you can think of it as regular expressions for X(HT)?ML. If your XPath parser balks at non-XHTML HTML then just run it through HTML::Tidy-clean which will convert it to XHTML.
Re: [Slightly OT] Understanding Software Licences
I am declaring this topic closed on this mailing list. It has sucked down too much time and energy and generated too much heat and no light. It has nothing to do with Perl QA. Please take it somewhere else. Please do not reply to this thread with anything but the location of where you intend to continue this conversation so that interested parties may follow. If you do not like this decision please reply to me directly.
