Re: Testing various HTML constructs
Andy Lester wrote: 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. If usually isn't good enough, you can always write your own HTML converter with HTML::TreeBuilder. I do this in my blog software: http://trac.jrock.us/trac/blog_software/browser/lib/Blog/Format/HTML.pm This has the added advantage of allowing you to remove nasty HTML, if that's relevant in your application. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: TAP Namespace Nonproliferation Treaty
Ovid: TAP::Parser::Pedantic Schwern: TAP::Parser::Heuristic I've always feared /^[A-Z]+x::/ namespaces because I never understood them. For the longest time, I thought Jesse was working on DBI eXtreme with SearchBuilder and whatnot. On 7/8/06, Ovid [EMAIL PROTECTED] 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. 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/ -- Ian Langworth
Re: Bail out! questions
When you say any message after these words, does that include words
on subsequent lines?
If it does, there isn't much parsing left to do -- the rest of the
tokens in the stream get treated as a big diagnostic blob.
If it doesn't, the easiest thing to do would be to stop the parser and
complain. It would be really cool, as well as more work, if the parser
parsed the rest of the TAP. The latter would allow your parser to find
more than one error in the TAP. (Imagine the parser finding _two_
Bail out! lines.)
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
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/
--
Ian Langworth
Re: Bail out! questions
When you say any message after these words, does that include words
on subsequent lines?
If it does, there isn't much parsing left to do -- the rest of the
tokens in the stream get treated as a big diagnostic blob.
If it doesn't, the easiest thing to do would be to stop the parser and
complain. It would be really cool, as well as more work, if the parser
parsed the rest of the TAP. The latter would allow your parser to find
more than one error in the TAP. (Imagine the parser finding _two_
Bail out! lines.)
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
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/
--
Ian Langworth
Re: Old and broken versions of Module::Install
Steffen Mueller schrieb: You can find a complete (and somewhat current) list of problematic modules at http://steffen-mueller.net/mi_old.html I have just completed rerunning the script that generated that list. The new list is available at above URL. Steffen
Re: TAPx::Parser 0.02
This is cool, Ovid! I think you're definitely on the right track.
Thoughts:
- I'd like an option to automatically s{ \A \s* - \s+ }{} all test
descriptions. I bet a lot of people would end up doing this
themselves, including myself.
- Speaking of that step, the underscore in your tokenizing method
(_lex) denotes it as private. What if I wanted to massage the tokens
after that phase? Specifying after_lexing hooks might be useful.
- I'm not sure how closely you're trying to follow a traditional,
multi-phase parser. If the lexer's job is to simply turn TAP output
into data structures, why does it die on the semantic error of a
forgotten plan? (10-lex.t line 183) Sounds like that's the job of the
parser.
- I mentioned this in another reply, but I'll phrase it differently
here: Having the lexer and parser die immediately on error is easy,
yes. But having the components recording _all_ errors for later
examination by the user would be very, very helpful.
Your tests are very descriptive well organized.
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
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/
--
Ian Langworth
Re: Doc error in TAP.pm?
- Original Message From: Michael G Schwern 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 Regarding the questions posed on the Wiki: Should we canonicalize this syntax? Is there a better escape syntax? Yes, keep this syntax. People are going to put hash marks in their descriptions and breaking something which didn't previously break is bad. I doubt there is a better escape syntax for two reasons. One, the current behavior is understood and changing to a different escape syntax could have unintended consequences for current tests suites. Two, it's a widely recognized and accepted escape syntax and that makes it easy for people to see and understand. Finally, if TODO and SKIP directives are case-insensitive to maintain backwards compatibility with Test::Harness, why wouldn't we keep the escaping for the same reason? Cheers, Ovid
Re: Bail out! questions
- Original Message From: Ian Langworth [EMAIL PROTECTED] When you say any message after these words, does that include words on subsequent lines? If it does, there isn't much parsing left to do -- the rest of the tokens in the stream get treated as a big diagnostic blob. That's unclear from the spec, but the current behavior makes this unreliable: TAPx-Parser $ perl -MTest::More=no_plan -e 'BAIL_OUT(One\nTwo)' Bail out! One # Two Subsequent lines are comments and I have no way of knowing which is which. If it doesn't, the easiest thing to do would be to stop the parser and complain. It would be really cool, as well as more work, if the parser parsed the rest of the TAP. The latter would allow your parser to find more than one error in the TAP. (Imagine the parser finding _two_ Bail out! lines.) I think I will make this configurable so that you can continue after a Bail out!, if explicitly requested, though if someone really meant to bail out, the rest of the data would be questionable, though if we're just checking TAP for validity, I can see your point. Cheers, Ovid
Re: TAPx::Parser 0.02
- Original Message
From: Ian Langworth [EMAIL PROTECTED]
This is cool, Ovid! I think you're definitely on the right track.
Thanks!
Thoughts:
- I'd like an option to automatically s{ \A \s* - \s+ }{} all test
descriptions. I bet a lot of people would end up doing this
themselves, including myself.
Hmm, I can probably add that in fairly easily.
- Speaking of that step, the underscore in your tokenizing method
(_lex) denotes it as private. What if I wanted to massage the tokens
after that phase? Specifying after_lexing hooks might be useful.
Can you show me some example syntax of what you'd want to do? The problem is,
the lexing and parsing are very tightly coupled. Allowing people to massage
the lexer output directly is asking for trouble.
- I'm not sure how closely you're trying to follow a traditional,
multi-phase parser. If the lexer's job is to simply turn TAP output
into data structures, why does it die on the semantic error of a
forgotten plan? (10-lex.t line 183) Sounds like that's the job of the
parser.
Originally I had a clearer distinction between lexing and parsing, but there
were three reasons I abandonded this:
1. TAP is line based and allows non-parseable junk.
2. Context is very important and much of that is easy to track while lexing.
3. Due to some lexing ambiguities raised by precedence issues, I found that
the lexer would need much finer-grained tokens then I was creating and that
made the grammar more complicated.
However, you are correct that the lexer should not be dying. In fact, neither
should the parser. I decided last night that all errors should be recorded, as
you were wanting.
Your tests are very descriptive well organized.
Really? I thought I was a bit sloppy with 'em :)
Cheers,
Ovid
Re: Java Script in Parrot
I've started work on a Javascript implementation, but haven't gotten very far yet. I've starting with the Narcissus implementation from the Mozilla project. My current plan is to: 1. Identify any objects that need to be bootstrapped into PMCs. 2. Write a Compile phase that borrows logic from jsexec.js, and convert it to a PIR generator. 3. Run it once in a Narcissus enabled SpiderMonkey interpreter. The Mozilla project has a huge suite of tests for EMCAScript compliance, which might be a good thing to borrow for any Parrot based Javascript implementation. Regards, Norman Nunley On 7 Jul 2006, at 17:34, Vishal Soni wrote: Hi, Is any one working on Java Script(ECMA-262) implementation in Parrot? -- Thanks, Vishal
Re: Java Script in Parrot
Hi Norman, I am also in the implementing Java Script for Parrot. But the approach I have taken is, that I picked up the ECMA-262 Spec 3rd Edition and I have implemented in Parrot Grammar Engine (PGE). Write now I have implemented more than half of Java Script grammar in PGE to compile correctly. My game plan is as follows: 1. Implement Java Script Grammar in PGE 2. Convert PGE- PAST. 3. Convert PAST- POST. 4. Convert POST- Byte code. I have seen the Test bed from Mozillla and I plan to start using it once I have a testable implementation. I am not an expert on which approach is the way to go: 1. Hack Mozilla's JavaScript excution engine to generate PIR. 2. Use the Compiler Tool Chain developed by Parrot Wizards to implement JavaScript engine. Parrot experts any thoughts or comments. Any feedback as to how to unify the efforts if possible would be highly valuable. -Vishal Soni On Sun, 2006-07-09 at 09:51 +0100, Norman Nunley, Jr wrote: I've started work on a Javascript implementation, but haven't gotten very far yet. I've starting with the Narcissus implementation from the Mozilla project. My current plan is to: 1. Identify any objects that need to be bootstrapped into PMCs. 2. Write a Compile phase that borrows logic from jsexec.js, and convert it to a PIR generator. 3. Run it once in a Narcissus enabled SpiderMonkey interpreter. The Mozilla project has a huge suite of tests for EMCAScript compliance, which might be a good thing to borrow for any Parrot based Javascript implementation. Regards, Norman Nunley On 7 Jul 2006, at 17:34, Vishal Soni wrote: Hi, Is any one working on Java Script(ECMA-262) implementation in Parrot? -- Thanks, Vishal
[ANNOUNCE] Test::Builder/More/Simple 0.63
Holy crap, its a Test::More release! I'm sure there's much more important things which need fixing then what's in this release, but these were sitting around in the repo and I want to get back into the swing of regular releases. 0.63 Sun Jul 9 02:36:36 PDT 2006 * Fixed can_ok() to gracefully handle no class name. Submitted by Pete Krawczyk [EMAIL PROTECTED] Implemented by Richard Foley [EMAIL PROTECTED] [rt.cpan.org 15654] * Added test_pass() to Test::Builder::Tester rather than having to call test_out(ok 1 - foo). [EMAIL PROTECTED] [rt.cpan.org 11317] * test_fail() now accepts a test diagnostic rather than having to call test_out() separately. [EMAIL PROTECTED] [rt.cpan.org 11319] - Changed Test::Builder::Tester docs to show best practice using test_fail() and test_pass(). - isnt_num() doc example wrongly showed is_num(). [EMAIL PROTECTED] - Fixed a minor typo in the BAIL_OUT() docs. Jeff Deifik - Removed the LICENSE field from the Makefile.PL as the release of MakeMaker with that feature has been delayed. 0.62 Sat Oct 8 01:25:03 PDT 2005 * Absorbed Test::Builder::Tester. The last release broke it because its screen scraping Test::More and the failure output changed. By distributing them together we ensure TBT won't break again. * Test::Builder-BAILOUT() was missing. - is_deeply() can now handle function and code refs in a very limited way. It simply looks to see if they have the same referent. [rt.cpan.org 14746]
TAPx::Parser roadmap
Hi all, Just to let you know, I'm preparing TAPx::Parser for 0.10 (currently at 0.02). Based upon the feedback I've received, here's my roadmap, broken down by DONE, TODO, and QUESTIONS sections. DONE: - Removed non-core modules TODO: - 'Bail out!' should immediately stop processing. However, processing can continue on user's request. - Allow streams to be read. - Allow description transformations to be applied. (e.g., s/\A\s*-\s*//) - Fix is_ok() and add passed() in TAPx::Parser::Results::Test. (currently doesn't handle TODO) - No more dying. Instead, aggregate errors and count 'em. - Track all TODOs, SKIPs, passes and fails by test number. - Figure out the namespace. - Store original text. QUESTIONS: - skipped lines should always be OK? (e.g., 'not ok 3 - we blew it! # SKIP should never be not ok') - VMS 'not' and 'ok' on separate lines? Currently the lexer cannot handle this. Should it? Anything else? 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: Building a Fedora package
On Sat, Jul 08, 2006 at 07:01:19PM -0500, Steven Pritchard wrote: 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. When you say, On x86_64 I think what your really mean is a x86_64 system with multilib support. You are correct that the current build system does not support multilib builds or installs (or at least it didn't the last time I looked at it several months ago). While I don't have a recent Fedora build to look at I'd bet that /usr/lib64 on your system is actually a link to /usr/lib while /usr/lib32 is a separate directory. So there shouldn't be any issue with installing under /usr/lib. Is this the case? Cheers, -J -- pgpU2nGZlteG9.pgp Description: PGP signature
Re: Testing various HTML constructs
On Sat, Jul 08, 2006 at 07:06:15PM +0300, Gabor Szabo wrote: 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? Me, I'd use HTML::TreeBuilder: http://search.cpan.org/~sburke/HTML-Tree-3.18/lib/HTML/TreeBuilder.pm 1) Build a tree out of your HTML file: my $html_file = 'whatever_your_filename_is'; my $tree = new HTML::TreeBuilder; $tree-parse_file($html_file); 2) Extract all the tables: my @tags = $tree-look_down(_tag, 'table'); Step 2) uses look_down(), which is a method inherited from HTML::Element: http://search.cpan.org/~sburke/HTML-Tree-3.18/lib/HTML/Element.pm Now you've got a list of your tables, which you can then walk through as you please. -- Stephen R. Laniel [EMAIL PROTECTED] Cell: +(617) 308-5571 http://laniels.org/ PGP key: http://laniels.org/slaniel.key signature.asc Description: Digital signature
Re: Anyone experiencing problems with rt.cpan.org?
- Original Message From: David Golden [EMAIL PROTECTED] 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. My problem was that I couldn't even log in yesterday. I eventually filed a bug report with [EMAIL PROTECTED] and Robert had to diddle the database to get me sorted. -- 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: S29 update ready
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 join returns a string, and requires a list. undef would indicate an exceptional condition (for example the list contained an object which could not be stringified), so I don't see why a valid (but empty) list would cause an undef to be returned. The later point about C[~]() is also quite helpful. I've made a note in my copy of S29, which will be committed to the pugs repo as soon as I have commit rights.
Re: PGE and TGE vs. .namespace
Allison Randal schreef: Chip Salzenberg: The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) TGE and PGE both need a thorough going-over for the new namespaces implementation. I'm thinking they should act in an HLL-agnostic fashion, so it's possible to compile one grammar in, say, the Perl 6 HLL namespace, another in Ruby, another in Python, and another system-internal grammar into 'parrot'. Maybe an automagical namespace alias 'root' is feasible? -- Affijn, Ruud Gewoon is een tijger.
[perl #39771] [PATCH] missing signature for examples/nci/win32api.pir
# New Ticket Created by Rene Hangstrup Møller # Please include the string: [perl #39771] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39771 The win32 example in parrot/examples/nci/win32api.pir fails because the signature llttl is not defined in call_list.txt. This patch add the signature to call_list.txt Modified files: src/call_list.txt Index: call_list.txt === --- call_list.txt (revision 13220) +++ call_list.txt (working copy) @@ -410,3 +410,6 @@ l pttl # unsigned long mysql_real_escape_string(MYSQL *mysql, char *to,const char *from, unsigned long length) v t# void mysql_debug(const char *debug) # --- end mysqlclient library --- + +# win32 +l lttl
[perl #39771] [PATCH] missing signature for examples/nci/win32api.pir
Thanks, appled as r13221
Re: contrib tool: search for opcodes
I don't see this checkin. Assigned you the rt ticket. On Jul 7, 2006, at 9:41 AM, Bernhard Schmalhofer wrote: João Cruz Morais schrieb: (moderator please reject my other message - wrong email) The subject says it all :) Given a valid regex (pcre) as an argument, the script will search inside every *.ops file for an opcode name that matches, and dumps both its arguments and its description. If no argument is passed every opcode found is dumped. Hi João, I have added the script as tools/docs/search-ops.py. In order to decrease confusion, could you provide a patch that puts some documentation into the script? The information and the example from your mail would suffice. The recommended way to provide patches and new files is to create tickets in the RequestTracker. Information on how to do that is provided in docs/ submissions.pod. Thanks, Bernhard PS: For future Python scripts a port of the Parrot::Config Perl5 module would be nice to have. -- Will Coke Coleda [EMAIL PROTECTED]
Re: TAPx::Parser 0.02
Ways to tweak the TAP structure before handing it to the parser? The
removal of leading hyphens thing in the previous replies, sanitizing
sensitive information (maybe the non-employees shouldn't see IP
addresses in the output when they see the parsed result), who knows.
My opinion is that playing with the tokenizer output shouldn't be
discouraged. In someone breaks the structure, however, that's their
problem. You're the one with vetitive power in the end, though :-)
On 7/9/06, Ovid [EMAIL PROTECTED] wrote:
- Original Message
From: Ian Langworth [EMAIL PROTECTED]
This is cool, Ovid! I think you're definitely on the right track.
Thanks!
Thoughts:
- I'd like an option to automatically s{ \A \s* - \s+ }{} all test
descriptions. I bet a lot of people would end up doing this
themselves, including myself.
Hmm, I can probably add that in fairly easily.
- Speaking of that step, the underscore in your tokenizing method
(_lex) denotes it as private. What if I wanted to massage the tokens
after that phase? Specifying after_lexing hooks might be useful.
Can you show me some example syntax of what you'd want to do? The problem is,
the lexing and parsing are very tightly coupled. Allowing people to massage
the lexer output directly is asking for trouble.
- I'm not sure how closely you're trying to follow a traditional,
multi-phase parser. If the lexer's job is to simply turn TAP output
into data structures, why does it die on the semantic error of a
forgotten plan? (10-lex.t line 183) Sounds like that's the job of the
parser.
Originally I had a clearer distinction between lexing and parsing, but there
were three reasons I abandonded this:
1. TAP is line based and allows non-parseable junk.
2. Context is very important and much of that is easy to track while lexing.
3. Due to some lexing ambiguities raised by precedence issues, I found that
the lexer would need much finer-grained tokens then I was creating and that
made the grammar more complicated.
However, you are correct that the lexer should not be dying. In fact, neither
should the parser. I decided last night that all errors should be recorded, as
you were wanting.
Your tests are very descriptive well organized.
Really? I thought I was a bit sloppy with 'em :)
Cheers,
Ovid
--
Ian Langworth
The handled op forces resumption?
From: [EMAIL PROTECTED] Date: Sat, 8 Jul 2006 16:48:28 -0700 (PDT) Author: allison Date: Sat Jul 8 16:48:27 2006 New Revision: 13214 Modified: trunk/docs/pdds/pdd23_exceptions.pod I have a question about Chandled. r13214 adds item 2 in the following snippet from the current revision: When the Chandled opcode is called: =over =item 1 Pop and destroy the exception record. =item 2 If there was a continuation in the exception record, invoke the continuation. =back According to Cthrowcc, this continution is for resuming execution from the error point: =item Bthrowcc IEXCEPTION [ , ICONTINUATION ] Throw an exception consisting of the given IEXCEPTION PMC after taking a continuation at the next opcode. When a ICONTINUATION is passed in, it will use that instead. Active exception handlers (if any) will be invoked with IEXCEPTION and the given continuation as parameters. That would mean that Chandled is really causing resumption, true? But the Chandled op description still merely says: =item Bhandled IEXCEPTION While handling an exception, tell Parrot that the exception has been handled and should be removed from the stack of active exceptions. This opcode is an exception handler's way of telling Parrot that it has handled the exception. It doesn't mention this possible nonlocal exit. It also doesn't mention the fact that handlers that want to do something other than resuming must *not* call Chandled if they want to retain control, which seems to contradict what Chip said on 24-June. On the other hand, not calling Chandled would leave the exception record in place, which also seems wrong. So I am confused. What is the intent here? TIA, -- Bob Rogers http://rgrjr.dyndns.org/
Re: The handled op forces resumption?
On Sun, Jul 09, 2006 at 06:27:13PM -0400, Bob Rogers wrote: I have a question about Chandled. r13214 adds item 2 in the following snippet from the current revision: When the Chandled opcode is called: =item 1 Pop and destroy the exception record. =item 2 If there was a continuation in the exception record, invoke the continuation. I hadn't looked at r13214 yet, but I agree that changes is problematic. It misses the implications of the continuation being passed as a parameter and the existence of the Chandled opcode: It is to give the handler complete freedom as to where to transfer control after handling the exception. RATIONALE: What the programmer may consider a warning may become an error in the end. Consider the Perl equivalent of gcc's -Werror. So it's not OK for throwcc force continued execution at any given continuation when handling is done. Also consider that there is little value in a Chandled opcode that transfers control. If it were OK for Parrot to force continued execution in a particular place, then the handler could just return the values that are currently the parameters of Chandled, and Parrot would take it from there. These are the use cases I had in mind for exception handler code: (1) I can handle it [a] execute Chandled [b] invoke some continuation, perhaps the one we got as a parameter, perhaps a different one (2) I can't handle it just return So in short I think Chandled should go back to merely clearing the exception in progress but not transfer control. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Java Script in Parrot
I am too planning to implement ECMAScript. I do not yet know how, I have to experiment with parrot first.
Re: Java Script in Parrot
On Sunday 09 July 2006 02:15, Vishal Soni wrote: I am not an expert on which approach is the way to go: 1. Hack Mozilla's JavaScript excution engine to generate PIR. If there's a fairly direct correspondence between JS bytecode (if there is such a thing; I have no idea -- whatever internal ops it uses to represent a program to execute), this may be easiest to start. 2. Use the Compiler Tool Chain developed by Parrot Wizards to implement JavaScript engine. This is probably the best long-term approach, at least if you find someone good to write the grammar. (I hate parsing.) Both approaches will probably need the same custom PMCs and built-ins, so whichever approach gets you to that point first is the most reasonable choice, in my opinion. -- c
Perl 6 Summary: 2006-02-13 through 2006-02-28
(Proxying for Ann Barcomb, our new summarizer. :-))
The Perl 6 summary for the weeks of 2006-02-13 through 2006-02-28
Summary updates
Starting with this update, Ann Barcomb will be writing the Perl 6
summaries. Her plan is to release new issues on Sundays, initially
dealing with the backlog at a rate of one month per week, and
eventually
returning to posting a summary of the previous week on a weekly
basis.
The proposed schedule is:
* July 9th: February (from 13th)
* July 16th: March
* July 23th: April
* July 30th: May
* August 6th: June
* August 13th: July
* August 20th: August (till 19th)
* August 27th: Resume normal schedule
Compiler (perl6-compiler)
Making Pugs aware of Parrot
Peter Schwenn requested a concrete example settings to make Pugs
aware
of Parrot. Beau Cox replied with step-by-step instructions.
http://xrl.us/oxoa
Difficulty installing Pugs on Cygwin
Syed Uzair Aqeel reported a Cygwin problem with finding package
plugins
when creating a makefile. Audrey made a suggestion.
http://xrl.us/oxob
Installation failure of Pugs revisions 9188 and 9204
Beau Cox reported that the 9188 revision of Pugs failed to pass
smoke
tests and install, and that the problem persisted with Pugs 9204
even
after a reinstall of ghc and Haskell. Beau wrote a makefile
patch, which
also worked for chromatic, who had experienced the same problem.
http://xrl.us/oxoc
Internals (parrot-porters)
Reading data from STDIN
Earlier, it was asked how to read data from STDIN for a PASM
application. Dan Sugalski replied.
http://xrl.us/oxoe
Questions on embedding Parrot
chromatic had some questions on embedding Parrot. Alin Iacob
responded
with a reference to a post by Brent Dax, which addressed some of
chromatic's questions.
http://xrl.us/oxof
Reason behind argument choice for {get,set}_type_keyed_intvtable
Leopold Toetsch wanted to know if there was a reason get/set
keyed_intvtable methods take INTVAL* instead of INTVAL. It was
suggested that some functions need more than one keyed item, and
the
remaining follow the same pattern for symmetry.
http://xrl.us/oxog
imcc segfault
Jürgen Bömmels reported an imcc segfault, which Leopold Toetsch
answered questions and resolved the ticket (#20839). Others also
made
suggestions.
http://xrl.us/oxv8 http://xrl.us/oxv9
cgp_jit
Leopold Toetsch wrote about the changes in this patch, which
introduced
the 1000th opcode.
http://xrl.us/oxwa
Overlapping decisions in Perl 6 and Parrot
Dan Sugalski initiated a discussion on recent Perl 6 topics --
such as
string re-usability and the vtable split -- which would impact
Parrot.
Leopold Toetsch and others replied.
http://xrl.us/oxwb
Segfault in substr_s_ic_ic_sc op
Gregor noted that he did not expect a segfault here, and
proposed some
alternatives. Simon Glover replied that he thought it was correct
behavior.
http://xrl.us/oxwc
Strings and header reuse
Dan Sugalski expressed a desire to have documentation and
thought on the
subject of strings and header reuse.
http://xrl.us/oxwd
Access XML parser within Parrot
Tupshin Harper asked if it was possible to get access to an XML
parser
from within Parrot. The answer was no, but several people offered
suggestions.
http://xrl.us/oxwe
PXS
The previous topic led to Tupshin Harper looking at PXS and
encountering
some difficulties. Several people suspected that PXS was out of
sync
with the rest of Parrot or obsolete, and Brent Dax added
comments to a
few files expressing these concerns.
http://xrl.us/oxwf
Later, Leopold Toetsch listed some opcodes he believed were
obsolete.
http://xrl.us/oxwg
Parrot language examples dated
The topic of bit rot was brought up by Tupshin Harper, who noted
that
many of the language examples in Parrot no longer work properly.
Leopold
Toetsch agreed with some of the assessments.
http://xrl.us/oxwh
imcc calling conventions
Leopold Toetsch posted POD describing the existing stack calling
convention and proposing a syntax for Parrot's NCI calling
convention.
Several people responded to this thread.
http://xrl.us/oxwi
Parrot's speed for primes
Tupshin Harper used the primes.pasm example and converted it to
both C
and Perl 5, and found that Parrot's performance was must better
than
Perl's or Python's. There was interest in the results, and the
code was
posted.
http://xrl.us/oxwj
Using imcc as JIT optimizer
Leopold Toetsch made a proposal and asked for comments, and
received
many.
http://xrl.us/oxwk
Configure.pl --cgoto=0 doesn't work
Nicholas Clark reported this bug. Simon Glover offered a patch,
which
Re: A PDD for dynamic-wind?
From: Chip Salzenberg [EMAIL PROTECTED] Date: Sat, 8 Jul 2006 15:20:08 -0700 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. I think you're right. And even if not, I think all of this is sufficiently deeply tangled that we have to assume that it all needs to be untangled together. 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. My currently thinking is reflected here: http://rgrjr.dyndns.org/perl/dynbind-proposal-v3.html But it's not in PDD format yet (being still too polemical, among other reasons), and it's still not finished, though I hope you find it useful. I really want to understand how exception handling has to work in order to support Perl 6 in order to ensure that all of the tools in the dynamic environment toolbox work with each other smoothly. -- Bob
HLL, perl6
I am currently trying to add some PGE to tcl (for the [expr] command, where the optok parsing will be very helpful). While debugging, I noticed that perl6 isn't using the .HLL directive: I suspect the namespace lookup issues I'm having (and perl6 isn't) might be de to this difference. Some intrepid coder want to try to switch to using .HLL instead of a simple .namespace directive? Regards. -- Will Coke Coleda [EMAIL PROTECTED]
Re: [perl #39777] Large Subroutine Segfaults IMCC
Hi Matt, This patch is because the number of .constant decls in IMCC is limited to 4096. This is a todo to make this dynamic. The evil code seems to have about 4200 .constant decls being generated. Here is the patch to fix it. For now I bumped up the limit to 8192 and it works. But this is a TODO for sure. I ran the after bumnping up the limit and it seems to work. After applying the patch If you have lex perl Configure.pl --lex=lex If you have flex perl Configure.pl --lex=lex make -Vishal Index: compilers/imcc/imcc.l === --- compilers/imcc/imcc.l (revision 13220) +++ compilers/imcc/imcc.l (working copy) @@ -31,7 +31,7 @@ }; /* XXX: boe: rework this hack to use a hash */ -#define N_MACROS 4096 +#define N_MACROS 8192 struct macro_t macros[N_MACROS]; int num_macros = 0; On Sun, 2006-07-09 at 20:49 -0700, Matt Diephouse wrote: # New Ticket Created by Matt Diephouse # Please include the string: [perl #39777] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39777 The attached file, which has a ~1 line subroutine, makes IMCC segfault. Segfault bad. -- Matt Diephouse
