[perl #39688] DATE Module Problem
# New Ticket Created by Ramesh Srinivasan # Please include the string: [perl #39688] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39688 Hi, When ever I execute the following module I get the error. Kindly help us to recifity. bash-2.05# cat date.pl ( Perl Programme) use DateTime; bash-2.05# perl date.pl (while executing I am gettiing the following error Can't locate loadable object for module DateTime in @INC (@INC contains: /usr/perl5/5.6.1/lib/sun4-solaris-64int /usr/perl5/5.6.1/lib /usr/perl5/site_perl/5.6.1/sun4-solaris-64int /usr/perl5/site_perl/5.6.1 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.6.1/sun4-solaris-64int /usr/perl5/vendor_perl/5.6.1 /usr/perl5/vendor_perl .) at /usr/perl5/5.6.1/lib/sun4-solaris-64int/XSLoader.pm line 44 BEGIN failed--compilation aborted at /usr/perl5/site_perl/5.6.1/DateTime.pm line 44. Compilation failed in require at date.pl line 1. BEGIN failed--compilation aborted at date.pl line 1. Thanks regards, S.Ramesh Senior Systems Engineer Quintegra Solutions Ltd, 168, Eldams Road, Alwaprpet, Chennai-600 018 PH: +91-44-24353971, Ext. 108 Mobile:+91-98409-68792 'This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.' 'This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.'
Re: TAP::Harness
Michael G Schwern wrote in perl.qa : * What about Test::Harness? Test::Harness remains its own thing. At some point in the future Test::Harness will likely be gutted and turned into a thin wrapper around TAP::Harness. I'm not caring about this right now. What about prove(1) ? Are you going to make a version of it that uses TAP::Harness ? And it so, will it be removed it from T::H ? (I hope not, since it's part of the core). Or have a fork ? -- The rpmvercmp() algorithm has been implemented in shell, python, perl, ruby, java, and some gawd awful Oracle DB internal scripting language. Dunno about Forth and FORTRAN, but little surprises me any more. -- Jeff Johnson in rpm-devel
Re: TAP extension proposal: test groups
On 02/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: Fergal Daly wrote: On 02/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: There's no way to declare a top-level plan. That is, I can't say how many groups of tests I'm going to run so there's effectively no plan, One point that Andy was extremely insistant on, and I think Schwern and I agree, is that the main plan is ALWAYS the total number of tests for the entire test script. In that case, groups form an additional set of checks, but do NOT alter the plan for the entire script. That contradicts #2 I don't want to have to count up the total number of tests in my file but I do want the protection of the plan. but looking again, I see that the example does include an overall plan that does count up the total. There's four cases here. 1. Plan, no groups 2. No plan, no groups As is now 3. Plan, with groups The plan still is for the ENTIRE test script, but in addition within that total you can define groups to add extra protection or grouping information for diagnostics. 4. No plan, with groups In THIS case, the total of the script does not matter or may not be known, but you want protection of a sort of miniplan for specific sections. This does bring up a gap in the spec though (or I'm not remembering right). If you have the following, how do you tell where the end of the group is. Currently I think it would be implicit and unclear? (noplan) ok 1 ok 2 ..2 ok 3 ok 4 ok 5 ok 6 That seems like a problem too but the one I'm trying to get at is 4 no plan, with groups If your script exits prematurely after one of the groups, the harness will not notice because everything looks just fine. The solution to this is not to use plan, with groups because then you have to count all the tests individually which goes aginst objective #2, F
Re: TAP::Harness
On Sunday 02 July 2006 23:37, Adam Kennedy wrote: The most up-to-date Test-Run code is here: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ I don't mind giving Subversion access to the repository to anyone who registers in http://developer.berlios.de/ and is either a CPAN contributor, or has sent me one patch for me to commit. With Adam Kennedy's permission, I can also move the files to his Subversion repository, where everyone with a PAUSE ID can commit to. I'd prefer not to add it at this point. That's not so much because of the code itself, but because currently it's MY repository for the module _I_ maintain, please a few other things I'm very very tight with and likely to have to do releases for anyway (PITA/Win32). They are structured a certain way, the licenses must be Perl (at present the dist-builder would change your license at release time) and it's build around the way I do things. While it might some time in the future end up as the kernel of some sort of larger svn.cpan.org it is absolutely NOT that at the moment. That particular issue is one I want a year or so of experience with the current setup under my belt before I address. But you also have dozens of modules, so I imagine it would be worth you just creating your own setup, be it Trac, Insurrection (assuming you can get the damned thing installed) or otherwise. That way you're able to set it up as you like, rather than me forcing my structures and policies onto you. I'm sorry but I don't have the time, energy or money resources to set up my own CPAN-wide Subversion hosting like that. At the moment I prefer to use a Subversion hosting maintained by someone else or by a Subversion hosting provider[1], rather than start messing with a setup like this under my own responsiblity. Similarly, I can't seem to be able to maintain (install, upgrade, keep spam clean, etc.) several web-apps on several different hosts, and would rather get providers that provide such services (like Wikia for MediaWiki, etc.). If I encounter a problem there - it will be fixed, not only for me but for everyone. Hostings I already have: 1. Subversion at http://stalker.iguide.co.il:8080/svn/shlomif-homepage/ . I'm keeping the sources of my homepage there because some of its content may not be open-source, and I feel that it won't be nice to use http://opensvn.csie.org/ or whatever for that. But I may be wrong, and it is not against the policy of some Subversion providers. I have a shell account on stalker, and occasionally need to compile Subversion, Apache 2, etc. However, I might get my admin to install these packages from the Debian pool. 2. http://www.shlomifish.org/ - this is an entirely static (but pre-rendered) site that serves as my homepage. It is hosted at http://eonspace.net/ [2] and I've moved it there so it will have good bandwidth. I have ssh access there, and am using rsync to upload the files. I once tried to install YaBB there, but my hostmaster and I failed due to some obscure Apache configuration problems. Maybe I'll have better luck next time, but at the moment, I don't have an immediate need for anything dynamic. (Except perhaps a small script or two.) 3. http://www.iglu.org.il/ - this is a community site that I got burried in maintaining. I have a root password for it. While I have some stuff there, I tend to avoid using it for anything serious, because the server is rather under-powered and the connectivity to anywhere except Israel tends to be slow. My homesite used to be hosted there, but it has been moved to eonspace.net. --- What I'm trying to say is that the last thing I need right now is to buy a server of some sort and put and maintain Subversion on it, and I believe that's the case for other people. And I think one central Subversion server (with some mirrors) is better than several dispersed ones. Adam, in case you have the configuration of the server (scripts, conf files, etc.) available somewhere public, I could try helping you once you're ready for it. No promises though. The number of tasks on a project's todo list always grows or remains constant, and so do the number of projects a developer is involved in. Regards, Shlomi Fish [1] - http://subversion.tigris.org/links.html#hosting [2] - Yes, I know there's nothing much there yet. - 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%.
TAP Grammar
Hi all, I would still like to be in a position to write a grammar for TAP, but I've heard no answers to my questions. Should I assume that a formal grammar is not wanted/desired at this point? 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: [yapc] DOC: glossary
On Jul 2, 2006, at 11:23 PM, Uri Guttman wrote: hi to all docathon hackers (and others too), one idea we came up with during the docathon is that perl6 needs a glossary. would the terms autobox or mixin make any sense to a newcomer who didn't know any OO theory? so this is a proposal to start a glossary as a new S\d+ or other document. here are some ideas i have been bouncing in my skull that i would like to see in it: the list of terms should include all of perl6's special variable names, namespaces (including the term namespace! :), keywords, OO theory terms (like autobox). i think it should also include many/most of parrot's terms as there is some overlap. stuff like haskell, pugs, PGE, and others should also be included. i don't think perl6 ops should be included. each term should have a pronunciation if it isn't obvious. No. Even the ones that are obvious should have a pronunciation. Please keep in mind that non-English-native speakers have a hard time with pronouncing these things correctly, myself included. Things like $_, @_, %something are not as obvious to us as they are to you :-) So please... add pronunciation :-) of course there should be a succinct definition of no more than a couple of sentences. a reference to the S\d+ docs that discuss the term in depth links/references to longer definitions on the web for non-perl specific terms like autobox. a 'see also' section referring to other terms. i think a pumpking should be annointed to own the master doc. this would be a great job for anyone who wants to help as you don't even need to understand all the terms or be a core perl6 hacker. you just need to know how to alphabetize, format and handle patches, google a bit for external links, track xrefs and see also's and such. this is basically an ongoing editor job. a first task would be to create this doc and to create a pod template for entries. then others can submit entries in that format or the pumpking can edit them into that format. we can start with just a list of terms and they can be filled out incrementally. i do expect this to be fairly large with several hundred terms. i will post a starter list of terms soon. it will just be words i have been seeing in S02 which is the spec i have been editing. all the other docathon hackers (and anyone else) can submit lists as well. when we have a pumpking, then the glossary doc itself can be started. if you want to submit entries do that too. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ yapc mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/yapc -- José Castro [EMAIL PROTECTED] log www.log.pt Tel: +351 21 330 42 20 Fax: +351 21 330 42 19 Av. Duque de Ávila nº23, 1000-138 Lisboa --
Re: TAP extension proposal: test groups
That seems like a problem too but the one I'm trying to get at is 4 no plan, with groups If your script exits prematurely after one of the groups, the harness will not notice because everything looks just fine. The solution to this is not to use plan, with groups because then you have to count all the tests individually which goes aginst objective #2, But then we've had this problem up till now anyway. If it exists prematurely with a good return code now, it's a correct ending, if it returns with a bad return code it's an error. The addition of groups will not change that behaviour in unplanned test space, because what you want is a simply unknowable. Adam K
Re: TAP extension proposal: test groups
On 3 Jul 2006, at 13:56, Adam Kennedy wrote: That seems like a problem too but the one I'm trying to get at is 4 no plan, with groups If your script exits prematurely after one of the groups, the harness will not notice because everything looks just fine. The solution to this is not to use plan, with groups because then you have to count all the tests individually which goes aginst objective #2, But then we've had this problem up till now anyway. If it exists prematurely with a good return code now, it's a correct ending, if it returns with a bad return code it's an error. The addition of groups will not change that behaviour in unplanned test space, because what you want is a simply unknowable. If we don't have some way of signifying the end of a group in TAP then it removes a chunk of the utility for the people writing things that generate TAP - since everybody has to write their own checks that groups actually output the number of tests that they should. If we have an end-of-group marker the TAP::Parser can pick this up - which seems much more sensible to me. This, I think, is the same issue as the mixing grouped and non- grouped tests that I wrote about yesterday. Without an end-of-group marker a test script sending less/more than the specified number of tests for the group cannot be detected. Cheers, Adrian
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jul 3 13:15:01 2006 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 84 new + 202 open = 286 Created this week: 9 Closed this week: 4 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 39615 [TODO] get_outer op not defined in PDDs 2 - 3 weeks old 39454 [TODO] [easy] $svn keyword expansion$ 39430 Method cache not always invalidated 39426 [BUG] Can't build with cygwin. 3 - 4 weeks old 39329 Check to make sure PMC_str_val, etc. are used appropriately 4 - 5 weeks old 39248 Parrot release 0.4.6 5 - 6 weeks old 39197 lib/Parrot/Test.pm ignores core dumps failures! 39196 [TODO] tests - need to test addmethod 6 - 7 weeks old 7 - 8 weeks old 39132 [TODO] pirtidy - call for help 8 - 9 weeks old 39092 [TODO] Autogenerate functions in *.h files from source 39088 [TODO] Add conditional GCC attributes to functions 39051 Test failure in t/pmc/objects_62.pasm (attributes) 39043 [TODO] Dynamic PMCs should not include 'parrot/parrot.h' 9 - 10 weeks old 39018 t/pmc/complex failures on Solaris 8/SPARC 39004 [PDD] review pdd25_threads.pod 39003 [PDD] review pdd24_events.pod 39001 [PDD] review pdd22_io.pod 39000 [PDD] review pdd19_pir.pod 38999 [PDD] review pdd18_security.pod 38998 [PDD] review pdd17_basic_types.pod 38997 [PDD] review pdd16_native_call.pod 38996 [PDD] review pdd15_objects.pod 38995 [PDD] review pdd14_bignum.pod 38994 [PDD] review pdd13_bytecode.pod 38993 [PDD] review pdd12_assembly.pod 38992 [PDD] review pdd11_extending.pod 38991 [PDD] review pdd10_embedding.pod 38990 [PDD] review pdd09_gc.pod 38989 [PDD] review pdd08_keys.pod 38988 [PDD] review pdd07_codingstd.pod 38987 [PDD] review pdd06_pasm.pod 38986 [PDD] review PDD05_opfunc.pod 38985 [PDD] review PDD04_datatypes.pod 38984 [PDD] review pdd02_vtables.pod 38983 [PDD] review PDD01_overview.pod 38969 parrot source does not conform to standards 38967 Parrot release 0.5.0 10 - 11 weeks old 11 - 12 weeks old 12 - 13 weeks old 38887 Result of INFINITY or NAN stringification is platform dependent 13 - 14 weeks old 38823 [BUG] solaris 10 w gcc 14 - 15 weeks old 15 - 16 weeks old 38764 Test results of parrot on Freebsd 16 - 17 weeks old 17 - 18 weeks old 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old 38469 [BUG] -O1 branch optimization --- Overview of Open Issues Platform Severity Tag Lang Win32 3abandoned 05005threads 0 BASIC0 sco 0fatal 0notok 0 scheme 0 riscos0High 1ok0 tcl 24 qnx 0low 1Patch13 urm 0 powerux 0medium0regex 0 bc 0 other 0none 0sendToCPAN0 punie1 os390 0Normal1Todo177 Amber0 os2 0unknown 0unknown 0 Zcode0 openbsd 1Wishlist 3utilities 0 Lisp 0 next 0 notabug 0 ruby 0 Solaris 0 library 0 python 0 sunos 0 install 1 befunge 0 svr4 0 bounce0 bf 0 VOS 0 Bug 20 cola 0 vms 0 compiler 0 forth0 uts 0 configure 0 jako 0 unknown 0 core 0 m4 0 unix 0 dailybuild0 ook 0 unicosmk 0 docs 0 plot 0 unicos0 duplicate 0 perl60 sysv 0 wontfix 0 svr5 0 netbsd0 mswin32 0 dynixptx 0 dos 0 dgux 0 dec_osf 0 darwin0 cygwin_nt 0 cygwin0 bsdos 0 All 2 freebsd 0 generic 0 gnu 0 MacOS X 0 macos 0 machten 0 mac 0 lynxos0 Linux 0 irix640 irix 0 HPUX 0 aix 0 --- Ticket Status By Version New or OpenResolved ---
Re: TAP extension proposal: test groups
If we don't have some way of signifying the end of a group in TAP then it removes a chunk of the utility for the people writing things that generate TAP - since everybody has to write their own checks that groups actually output the number of tests that they should. If we have an end-of-group marker the TAP::Parser can pick this up - which seems much more sensible to me. This, I think, is the same issue as the mixing grouped and non-grouped tests that I wrote about yesterday. Without an end-of-group marker a test script sending less/more than the specified number of tests for the group cannot be detected. That is, of course, correct. A seperate issue I think, but yes you are correct. Adam K
Re: TAP::Harness
On Jul 3, 2006, at 4:29 AM, Rafael Garcia-Suarez wrote: What about prove(1) ? Are you going to make a version of it that uses TAP::Harness ? And it so, will it be removed it from T::H ? (I hope not, since it's part of the core). Or have a fork ? No, prove will be in both Test::Harness and TAP::Harness. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP extension proposal: test groups
On 03/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: That seems like a problem too but the one I'm trying to get at is 4 no plan, with groups If your script exits prematurely after one of the groups, the harness will not notice because everything looks just fine. The solution to this is not to use plan, with groups because then you have to count all the tests individually which goes aginst objective #2, But then we've had this problem up till now anyway. If it exists prematurely with a good return code now, it's a correct ending, if it returns with a bad return code it's an error. 2. I don't want to have to count up the total number of tests in my file but I do want the protection of the plan The protection of the plan is that when my script exits cleanly but prematurely I find out. That's the only protection it gives. Currently, the only way to get this protection is to count up all of the tests. This grouping scheme does not change that. The other objectives aren't terribly important to me (and I'm not even sure #3 is solving the right problem). The addition of groups will not change that behaviour in unplanned test space, because what you want is a simply unknowable. I'm not arguing about unplanned test space, F
Re: [svn:perl6-synopsis] r9733 - doc/trunk/design/syn
On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +But parens are special that way. (Even Cq() is assumed to be a +function call rather than a quote.) Other bracketing characters are +special only if they can be mistaken for adverbial arguments, so qn[stuff] -is fine, while +is fine, and means + +q:n /stuff/ + +while Since quotes can have whitespace before the first/opening delimiter, but functions can't (according to S03), how is Cq () parsed? (Notice the space before parens). Would that be parsed as invalid function-call (i.e. syntax error) or valid quote? -- Markus Laire
RFF: test Emacs Perl6 mode
Hi! This is a small Request For Feedback. I want to hear if *anyone* who writes or experiments with Perl6/Pugs these days uses (X)Emacs to write his/her code. If so, would you please try out the enhanced cperl-mode from http://svn.openfoundry.org/pugs/util/cperl-mode.el Some additional help for the occasional Emacs user can be found here: http://www.renormalist.net/cgi-bin/twiki/view/Renormalist/CPerlMode As I said, all I want is some feedback, whether it works for you, which install problems you have or which perl6 syntax still breaks it. BTW, my Lisp-Foo isn't that great, so if anyone wants to help with this little project, feel free to contact me. Or just hack away on it from inside Pugs. GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Using Rules Today
All: I have a for-fun project that I am working on exploring various different parsers and their methods. So far I have looked at things like Parse::RecDescent, Parse::YAPP, Parse::Earley, and HOP::Parser. I had Perl6::Rules on my list, but it is my understanding that Pugs::Compiler::Rule is more up to date. In any case, I was wondering if someone could provide me with an example of a mathematical expression parser (and evaluator). To properly compare to the others, it would need to handle the following operators +, - (left associative) *, /, % (left associative) ^ (right associative) handle parens 12 - (3 + 4) handle two functions sqrt() and abs() both of which must include the parens. If someone has time to do this for me, I would be appreciative. It might also serve as example documentation or cookbook ideas. I am specifically interested in examples that can be run in Perl 5 today without needing Pugs or Parrot. Cheers, Joshua Gatcomb a.k.a. Limbic~Region
Re: [svn:perl6-synopsis] r9733 - doc/trunk/design/syn
On Mon, Jul 03, 2006 at 05:31:34PM +0300, Markus Laire wrote: : On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: : +But parens are special that way. (Even Cq() is assumed to be a : +function call rather than a quote.) Other bracketing characters are : +special only if they can be mistaken for adverbial arguments, so : : qn[stuff] : : -is fine, while : +is fine, and means : + : +q:n /stuff/ : + : +while : : Since quotes can have whitespace before the first/opening delimiter, : but functions can't (according to S03), how is Cq () parsed? (Notice : the space before parens). : : Would that be parsed as invalid function-call (i.e. syntax error) or : valid quote? It's a valid quote. Larry
Re: Using Rules Today
2006/7/3, Joshua Gatcomb [EMAIL PROTECTED]: I am specifically interested in examples that can be run in Perl 5 today without needing Pugs or Parrot. http://svn.openfoundry.org/pugs/perl5/Pugs-Compiler-Rule/compile_p6grammar.pl - doesn't do exactly what you want, but you can see what the syntax looks like for writing an evaluator using rules in p5. http://svn.openfoundry.org/pugs/perl5/Pugs-Compiler-Rule/lib/Pugs/Grammar/Rule/Rule.pm - this is the grammar for rules, written in rules. The last rules have looser precedence; the rules at the start of the file have tighter precedence. This grammar is compiled to p5 using lrep. - Flavio S. Glock
Re: TAP Grammar
- Original Message From: Jonathan T. Rockway [EMAIL PROTECTED] I would say that even if nobody else is interested, if you're interested, do it :) I am tempted, but there are some problems with parsing TAP output as it currently stands. I can write a grammar for it, but the grammar can easily produce some output which doesn't make sense. Thus, I'm stuck in the awkard position of needing fundamental issues resolved before I can proceed in a confident manner. 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 extension proposal: test groups
- Original Message From: Michael G Schwern [EMAIL PROTECTED] 1. I want to name a group of tests rather than the individuals. ... Here's what we came up with. 1..10 ..4 - name for this group ok 1 ... Pros: * Its backwards compatible. The ..# lines are currently considered junk and ignored. Is this behavior documented anywhere? On the off chance I'll be able to finish a TAP grammar, I need to know what to do with lines which don't parse. A parser could throw an exception and this seems a reasonable thing to do, but that means TAP::Parser behavior would not match the current behavior. And since we're on the topic, I'm still wondering how we can disambiguate diag() output (the '#' proposal seemed workable) and whether version numbers can be included in the TAP output. The latter would allow a simple test of the TAP version and allow the proper grammar to be loaded rather than use heuristics to guess what version is allowed. Cheers, Ovid
[perl #39688] DATE Module Problem
This ended up in the queue for parrot (perl 6 vm) problems, not the perl5 queue. Changing queues.
Re: TAP extension proposal: test groups
On 3 Jul 2006, at 17:47, Ovid wrote: - Original Message From: Michael G Schwern [EMAIL PROTECTED] * Its backwards compatible. The ..# lines are currently considered junk and ignored. Is this behavior documented anywhere? [snip] From Test::Harness::TAP Anything else Any output line that is not a plan, a test line or a diagnostic is incorrect. How a harness handles the incorrect line is undefined. Test::Harness silently ignores incorrect lines, but will become more stringent in the future. Cheers, Adrian
Re: TAP Grammar
On Monday 03 July 2006 09:12, Ovid wrote: I am tempted, but there are some problems with parsing TAP output as it currently stands. I can write a grammar for it, but the grammar can easily produce some output which doesn't make sense. Isn't this the syntactic/semantic problem common to all grammars? -- c
Last modified date on Parrot Documentation
Hi It would be nice if the documents at http://www.parrotcode.org/docs/ were equipped with last modification date. /Rene
Re: TAP Grammar
On Jul 3, 2006, at 5:52 AM, Ovid wrote: Hi all, I would still like to be in a position to write a grammar for TAP, but I've heard no answers to my questions. Should I assume that a formal grammar is not wanted/desired at this point? No no no, please do. I will be glad to put it in TAP distro. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP Grammar
- Original Message From: chromatic [EMAIL PROTECTED] On Monday 03 July 2006 09:12, Ovid wrote: I am tempted, but there are some problems with parsing TAP output as it currently stands. I can write a grammar for it, but the grammar can easily produce some output which doesn't make sense. Isn't this the syntactic/semantic problem common to all grammars? No, this is a different issue. There are some problems that I'm not worrying about simply because they can't readily be solved, but there are others which are caused by either ambiguity in the spec or lack of any official declaration as to what to do. Currently, the way that Test::Harness::TAP reads, I should properly discard anything which is not a plan, test or diagnostic output. However, test failure output and programmer supplied diagnostic output need to be disambiguated or diagnostic information is unreliable. I've started hacking on TAP::Parser now and it turns out to be a thorny issue. To make it easier, I'm relying on the following quote fom the POD: Any output line that is not a plan, a test line or a diagnostic is incorrect. How a harness handles the incorrect line is undefined. Test::Harness silently ignores incorrect lines, but will become more stringent in the future. In other words, that means that any diag() or test failure messages will automatically be grouped together. This behavior is incorrect as different things need to be different. All you have to do is write diag 'read() failed' to potentially confuse someone reading the output. Also, it's ambiguous from the documentation whether or not whitespace is allowed before the qr/(?:not )ok.*\n/. I think it's implied that no leading whitespace is allowed but that could be incorrect. Also, regarding directives, the POD shows both # skip and # SKIP. I assume only the latter was intended, but I bet that will break things. Also, with discussion of upgrades to TAP in the future, unless there's a guarantee that all upgrades will be backwards compatible to the current implementation, we need version numbers in the output. Again, I've not heard any response to this. More that one person has expressed interest in a TAP::Parser and all we need is for those officially supporting/maintaining TAP to say make it so. 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/
[svn:perl6-synopsis] r9753 - doc/trunk/design/syn
Author: larry Date: Mon Jul 3 12:00:53 2006 New Revision: 9753 Modified: doc/trunk/design/syn/S04.pod Log: Clarifications on stack unwinding semantics of exception handlers. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podMon Jul 3 12:00:53 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 19 Aug 2004 - Last Modified: 30 June 2006 + Last Modified: 3 July 2006 Number: 4 - Version: 25 + Version: 26 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -77,7 +77,7 @@ If you've referred to C$x prior to the first declaration, and the compiler tentatively bound it to C$OUTER::x, then it's an error to declare it, and -the compiler is allowed to complain at that point. If such use can't +the compiler is required to complain at that point. If such use can't be detected because it is hidden in an eval, then it is erroneous, since the Ceval() compiler might bind to either C$OUTER::x or the subsequently declared Cmy $x. @@ -118,6 +118,9 @@ to get the Perl 5 behavior. +Note that temporizations that are undone upon scope exit must be +prepared to be redone if a continuation within that scope is taken. + =head1 Statement-ending blocks A line ending with a closing brace C}, followed by nothing but @@ -409,6 +412,17 @@ of the CCATCH block. Handled exceptions break out past this implicit rethrow.) +A CCATCH block sees the lexical scope in which it defined, but the +dynamic scope in which it is called, that is, as if it were called +from the dynamic location that threw the exception. That is, the +stack is not unwound until some exception handler chooses to +unwind it by handling the exception in question. So logically, +if the CCATCH block throws its own exception, you would expect the +CCATCH block to catch its own exception recursively forever. However, +a CCATCH must not behave that way, so we say that a CCATCH block +never attempts to handle any exception thrown within its own dynamic scope. +(Otherwise the Cdie in the previous paragraph would never work.) + =head1 Control Exceptions All abnormal control flow is, in the general case, handled by the @@ -495,7 +509,9 @@ abstraction that the compiler is free to optimize away (along with the associated continuation) when the compiler or runtime can determine that the semantics would be preserved by merely printing out the -error and going on. +error and going on. Since all exception handlers run in the dynamic +context of the throw, that reduces to simply returning from the Cwarn +function most of the time. =head1 The goto statement
Portable dirfd() (was Re: [perl #39261] stat() doesn't work on dirhandles)
On Monday 03 July 2006 11:43, Steve Peters via RT wrote: (from p5p) OK, with change #28473, I just added the capabilities to a stat() or -X filetests for systems with the dirfd() libc call available. There are two additional steps that need to be done. First, Perl_pp_stat and Perl_my_stat() have a lot of similar code when doing fstat()'s. Much of the common code should be refactored out. Second, developing an internal dirfd() for operating systems that need it should be done so this functionality is more portable. Also, adding a few extra tests wouldn't hurt either. I touched Parrot's File PMC the other day; could it use something like this? -- c
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
Will Coleda wrote: While you're waiting, we should improve the test for readline: we used to have similar failures where we found readline (or other probed thingees) but the version was not recent enough for us to link with. (1) Some sort of grouping for the libraries so that only the libraries really needed for an executable are used? (2) I don't know what the -lreadline test currently does but obviously it wrongly detects -lreadline as useable in this system. Regards.
Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
Thanks muchly for this contribution. I love making failing tests pass.
There are some adjustments needed, though, before we can integrate this
patch into Parrot.
The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot
has an unbounded (if not infinite :-)) number of registers, set on a
per-function basis. [When you talked to me on IRC, if I'd known you were
indexing registers I'd have mentioned this.] You'll have to use the INTVAL
typedef as the data type to hold register numbers.
So the first step in making this patch ready to apply is to make it adapt
automatically to the actual number of registers used in the given function.
It's possible the Parrot Cage Cleaners could have a volunteer ready to help
you with this
(C maven alert: I can imagine an interesting hack to use 'short' or
'unsigned char' when functions are small and INTVAL when they are large.
But I digress.)
Perhaps separately: I recall that Audrey Tang (Pugs mastermind) ran into
problems with aggressive use of continuations conflicting with the register
coloring algorithm. Continuations allow any function call to pop out at any
function return point, not just at the return point that follows the last
call made. From a register coloring point of view, the point after each
function call starts a new basic block. Being new pumpking I'm not versed
in the register allocation parts of Parrot yet, so I may have missed
something, but IIRC this is an issue that must be dealt with. Is your patch
relevant to this question, or orthogonal?
Finally: The coding style of your patch will need a little work. Style is
something a Cage Cleaner volunteer can help with once the code is otherwise
ready. I'm not religious about coding styles, but style _consistency_ is
pretty important in a multi-person project. Ideally, a reader should be
unable to tell newly inserted code from old code. (Except that new code
should always work. :-))
There are also some Parrot coding style issues that are functionally
important, and not just about looking good. For example, shared
declarations must always be in header files (yes there are exceptions in the
current code base but we're weeding them out gradually). Also, extern
symbols must always a Parrot_ prefix, to facilitate embedding Parrot in
other applications. There are other lesser style issues WRT spacing and
braces, but they're easy to deal with.
The main thing is to get the algorithm solid, and the rest can be dealt with
later (before the patch is applied, though :-)).
On Sun, Jul 02, 2006 at 02:02:34PM -0500, Vishal Soni wrote:
This patch implements the register content preserving move operation.
Thanks,
Vishal
Previously:
-
Now:1..3
ok 1 - in P param
ok 2 - tailcall 1
not ok 3 - tailcall 2 # TODO use temp
# Failed (TODO) test (t/compilers/imcc/imcpasm/optc.t at line 59)
# '# IMCC does produce b0rken PASM files
# # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392
# _main:
# @pcc_sub_call_0:
# set_args
# set_p_pc P0, foo
# get_results
# invokecc P0
# set_returns
# returncc
# foo:
# get_params
# [EMAIL PROTECTED]:
# @pcc_sub_call_1:
# set I0, I1
# set I1, I0
# branch [EMAIL PROTECTED]
# '
# doesn't match '/ set I(\d), I(\d)
# set I\2, I(\d)
# set I\3, I\1/
# '
--
1..3
ok 1 - in P param
ok 2 - tailcall 1
ok 3 - tailcall 2 # TODO use temp
Patch:
---Index: src/utils.c
===
--- src/utils.c (revision 13113)
+++ src/utils.c (working copy)
@@ -48,6 +48,7 @@
=cut
*/
+#define MAX_REGISTER 256
INTVAL
intval_mod(INTVAL i2, INTVAL i3)
@@ -678,12 +679,29 @@
TODO add a define, if it's implemented so that we can start filling the
gaps
+TODO The current implementation will not work for following cases
+
+1. I0-I1 I1-I0 I0-I3
+2. I1-I2 I3-I2
+
+Vishal Soni
=cut
*/
/* proto TODO mv to hdr */
typedef int (*reg_move_func)(Interp*, unsigned char d, unsigned char s,
void *);
+int reorder_move(unsigned char (*a)[MAX_REGISTER],unsigned char *val ,int
src , int prev, int depth ,reg_move_func mov,Interp *interpreter,void
*info,int temp);
+int find_first_indegree(unsigned char (*a)[MAX_REGISTER] , int dest);
+int find_root(unsigned char (*a)[MAX_REGISTER],unsigned char* root_vertex
,int src, int dest);
+void emit_mov(reg_move_func mov,Interp *interpreter,void *info,int emit,int
emit_temp,int src,int dest,int temp);
+void
+Parrot_register_move(Interp *interpreter, int n_regs,
+unsigned char *dest_regs, unsigned char *src_regs,
+unsigned char temp_reg,
+reg_move_func mov,
+reg_move_func mov_alt,
+void *info);
void
Parrot_register_move(Interp *interpreter, int n_regs,
@@ -693,16 +711,113 @@
reg_move_func mov_alt,
void *info)
{
-int i;
+//int i;
/* TODO */
Re: TAP Grammar
On 7/3/06, Ovid [EMAIL PROTECTED] wrote: Currently, the way that Test::Harness::TAP reads, I should properly discard anything which is not a plan, test or diagnostic output. However, test failure output and programmer supplied diagnostic output need to be disambiguated or diagnostic information is unreliable. Diagnostic information *is* unreliable in TAP. There is no way in TAP to provide structured diagnostics. None. Zero. All you have is unparsable diagnostics (comments). There is *no format* to those diagnostics. What Test::Builder is outputting is *not reliable*. Do not parse it. A diagnostic format is something which needs to be added to TAP, but nothing currently exists (we tossed around some ideas at YAPC). Do not let this stop you from writing a formal TAP grammar. You can go ahead and spec it out as it currently stands. Writing a TAP diagnostic format is orthoganal to writing a grammar for the current version of TAP. Also, it's ambiguous from the documentation whether or not whitespace is allowed before the qr/(?:not )ok.*\n/. I think it's implied that no leading whitespace is allowed but that could be incorrect. Test::Harness does not allow a leading space. There's no reason to start. Also, regarding directives, the POD shows both # skip and # SKIP. I assume only the latter was intended, but I bet that will break things. Test::Harness handles directives case insensitively. I don't see any particular reason to stop. Also, with discussion of upgrades to TAP in the future, unless there's a guarantee that all upgrades will be backwards compatible to the current implementation, we need version numbers in the output. Again, I've not heard any response to this. We discussed this at YAPC and all agreed: the first extension to TAP should be putting a version number into TAP. About the only other thing we agreed on is that the version should be a simple integer. So the format is open. Since anything not understood is ignored (and I'm liking that feature) we don't have to worry much about backwards compatibility. So probably something as simple as... TAP Version 2 1..2 ok 1 ok 2 though I'm sure there's plenty of proposals floating around out there. More that one person has expressed interest in a TAP::Parser and all we need is for those officially supporting/maintaining TAP to say make it so. What community do you program for? Just do it, man. Get approval / fix it later.
[perl #39694] Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
# New Ticket Created by Vishal Soni # Please include the string: [perl #39694] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39694 On Mon, 2006-07-03 at 13:03 -0700, Chip Salzenberg wrote: Thanks muchly for this contribution. I love making failing tests pass. There are some adjustments needed, though, before we can integrate this patch into Parrot. The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot has an unbounded (if not infinite :-)) number of registers, set on a per-function basis. [When you talked to me on IRC, if I'd known you were indexing registers I'd have mentioned this.] You'll have to use the INTVAL typedef as the data type to hold register numbers. The function prototype is void Parrot_register_move(Interp *interpreter, int n_regs, unsigned char *dest_regs, unsigned char *src_regs, unsigned char temp_reg, reg_move_func mov, reg_move_func mov_alt, void *info); src_regs and dest_regs are pointers to unsigned char. Unsinged char being 1 byte will store 256 distinct values. Hence I declared the MAX_REGISTER to 256. But I agree if we need to support unbounded number of registers we need to fix this algorithm and places where it is called. Let me know what case do we need to code for unbounded number of registers or 256 registers for now. So the first step in making this patch ready to apply is to make it adapt automatically to the actual number of registers used in the given function. It's possible the Parrot Cage Cleaners could have a volunteer ready to help you with this I can take care of fixing once we decide on number of registers. The algorithm will need to move away from using adjacency matrix to probably a graph-vertex data structure approach as the adjacency matrix could eat up memory. (C maven alert: I can imagine an interesting hack to use 'short' or 'unsigned char' when functions are small and INTVAL when they are large. But I digress.) Perhaps separately: I recall that Audrey Tang (Pugs mastermind) ran into problems with aggressive use of continuations conflicting with the register coloring algorithm. Continuations allow any function call to pop out at any function return point, not just at the return point that follows the last call made. From a register coloring point of view, the point after each function call starts a new basic block. Being new pumpking I'm not versed in the register allocation parts of Parrot yet, so I may have missed something, but IIRC this is an issue that must be dealt with. Is your patch relevant to this question, or orthogonal? Finally: The coding style of your patch will need a little work. Style is something a Cage Cleaner volunteer can help with once the code is otherwise ready. I'm not religious about coding styles, but style _consistency_ is pretty important in a multi-person project. Ideally, a reader should be unable to tell newly inserted code from old code. (Except that new code should always work. :-)) There are also some Parrot coding style issues that are functionally important, and not just about looking good. For example, shared declarations must always be in header files (yes there are exceptions in the current code base but we're weeding them out gradually). Also, extern symbols must always a Parrot_ prefix, to facilitate embedding Parrot in other applications. There are other lesser style issues WRT spacing and braces, but they're easy to deal with. The main thing is to get the algorithm solid, and the rest can be dealt with later (before the patch is applied, though :-)). On Sun, Jul 02, 2006 at 02:02:34PM -0500, Vishal Soni wrote: This patch implements the register content preserving move operation. Thanks, Vishal Previously: - Now:1..3 ok 1 - in P param ok 2 - tailcall 1 not ok 3 - tailcall 2 # TODO use temp # Failed (TODO) test (t/compilers/imcc/imcpasm/optc.t at line 59) # '# IMCC does produce b0rken PASM files # # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392 # _main: # @pcc_sub_call_0: # set_args # set_p_pc P0, foo # get_results # invokecc P0 # set_returns # returncc # foo: # get_params # [EMAIL PROTECTED]: # @pcc_sub_call_1: # set I0, I1 # set I1, I0 # branch [EMAIL PROTECTED] # ' # doesn't match '/ set I(\d), I(\d) # set I\2, I(\d) # set I\3, I\1/ # ' -- 1..3 ok 1 - in P param ok 2 - tailcall 1 ok 3 - tailcall 2 # TODO use temp Patch: ---Index: src/utils.c === --- src/utils.c (revision 13113) +++ src/utils.c (working copy) @@ -48,6 +48,7 @@ =cut */ +#define MAX_REGISTER 256 INTVAL intval_mod(INTVAL i2, INTVAL i3) @@ -678,12 +679,29 @@ TODO add a define,
Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
On Mon, 2006-07-03 at 13:03 -0700, Chip Salzenberg wrote: Thanks muchly for this contribution. I love making failing tests pass. There are some adjustments needed, though, before we can integrate this patch into Parrot. The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot has an unbounded (if not infinite :-)) number of registers, set on a per-function basis. [When you talked to me on IRC, if I'd known you were indexing registers I'd have mentioned this.] You'll have to use the INTVAL typedef as the data type to hold register numbers. The function prototype is void Parrot_register_move(Interp *interpreter, int n_regs, unsigned char *dest_regs, unsigned char *src_regs, unsigned char temp_reg, reg_move_func mov, reg_move_func mov_alt, void *info); src_regs and dest_regs are pointers to unsigned char. Unsinged char being 1 byte will store 256 distinct values. Hence I declared the MAX_REGISTER to 256. But I agree if we need to support unbounded number of registers we need to fix this algorithm and places where it is called. Let me know what case do we need to code for unbounded number of registers or 256 registers for now. So the first step in making this patch ready to apply is to make it adapt automatically to the actual number of registers used in the given function. It's possible the Parrot Cage Cleaners could have a volunteer ready to help you with this I can take care of fixing once we decide on number of registers. The algorithm will need to move away from using adjacency matrix to probably a graph-vertex data structure approach as the adjacency matrix could eat up memory. (C maven alert: I can imagine an interesting hack to use 'short' or 'unsigned char' when functions are small and INTVAL when they are large. But I digress.) Perhaps separately: I recall that Audrey Tang (Pugs mastermind) ran into problems with aggressive use of continuations conflicting with the register coloring algorithm. Continuations allow any function call to pop out at any function return point, not just at the return point that follows the last call made. From a register coloring point of view, the point after each function call starts a new basic block. Being new pumpking I'm not versed in the register allocation parts of Parrot yet, so I may have missed something, but IIRC this is an issue that must be dealt with. Is your patch relevant to this question, or orthogonal? Finally: The coding style of your patch will need a little work. Style is something a Cage Cleaner volunteer can help with once the code is otherwise ready. I'm not religious about coding styles, but style _consistency_ is pretty important in a multi-person project. Ideally, a reader should be unable to tell newly inserted code from old code. (Except that new code should always work. :-)) There are also some Parrot coding style issues that are functionally important, and not just about looking good. For example, shared declarations must always be in header files (yes there are exceptions in the current code base but we're weeding them out gradually). Also, extern symbols must always a Parrot_ prefix, to facilitate embedding Parrot in other applications. There are other lesser style issues WRT spacing and braces, but they're easy to deal with. The main thing is to get the algorithm solid, and the rest can be dealt with later (before the patch is applied, though :-)). On Sun, Jul 02, 2006 at 02:02:34PM -0500, Vishal Soni wrote: This patch implements the register content preserving move operation. Thanks, Vishal Previously: - Now:1..3 ok 1 - in P param ok 2 - tailcall 1 not ok 3 - tailcall 2 # TODO use temp # Failed (TODO) test (t/compilers/imcc/imcpasm/optc.t at line 59) # '# IMCC does produce b0rken PASM files # # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392 # _main: # @pcc_sub_call_0: # set_args # set_p_pc P0, foo # get_results # invokecc P0 # set_returns # returncc # foo: # get_params # [EMAIL PROTECTED]: # @pcc_sub_call_1: # set I0, I1 # set I1, I0 # branch [EMAIL PROTECTED] # ' # doesn't match '/ set I(\d), I(\d) # set I\2, I(\d) # set I\3, I\1/ # ' -- 1..3 ok 1 - in P param ok 2 - tailcall 1 ok 3 - tailcall 2 # TODO use temp Patch: ---Index: src/utils.c === --- src/utils.c (revision 13113) +++ src/utils.c (working copy) @@ -48,6 +48,7 @@ =cut */ +#define MAX_REGISTER 256 INTVAL intval_mod(INTVAL i2, INTVAL i3) @@ -678,12 +679,29 @@ TODO add a define, if it's implemented so that we can start filling the gaps +TODO The current implementation will not work for following cases + +1. I0-I1 I1-I0 I0-I3 +2. I1-I2 I3-I2 + +Vishal Soni =cut */
Re: TAP Grammar
- Original Message From: Michael G Schwern [EMAIL PROTECTED] Diagnostic information *is* unreliable in TAP. Do not parse it. It is now being discarded. Test::Harness does not allow a leading space. There's no reason to start. OK. Thanks. Test::Harness handles directives case insensitively. I don't see any particular reason to stop. OK. What about 'ok' and 'not ok'? It seems inconsistent to allow one to be case-insensitive and not the other. We discussed this at YAPC and all agreed: the first extension to TAP should be putting a version number into TAP. About the only other thing we agreed on is that the version should be a simple integer. So the format is open. I'll ignore this for now, then. More that one person has expressed interest in a TAP::Parser and all we need is for those officially supporting/maintaining TAP to say make it so. What community do you program for? Just do it, man. Get approval / fix it later. Doing it now. Tougher than I thought! Due to some weird semantics involved, I've already jettisoned HOP::Lexer and have rolled my own :( Not sure when it will be done. Cheers, Ovid
Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
On Mon, Jul 03, 2006 at 03:39:19PM -0500, Vishal Soni wrote: On Mon, 2006-07-03 at 13:03 -0700, Chip Salzenberg wrote: The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot has an unbounded (if not infinite :-)) number of registers [...] You'll have to use the INTVAL typedef as the data type to hold register numbers. The function prototype is void Parrot_register_move(Interp *interpreter, int n_regs, unsigned char *dest_regs, unsigned char *src_regs, unsigned char temp_reg, reg_move_func mov, reg_move_func mov_alt, void *info); src_regs and dest_regs are pointers to unsigned char. Unsinged char being 1 byte will store 256 distinct values. Hence I declared the MAX_REGISTER to 256. Well look at that. If I'd looked a bit closer at the diffs I might have noticed that myself. That's definitely an RT-able bug. Let me know what case do we need to code for unbounded number of registers or 256 registers for now. The former, please. I'd consider it the beginning of fixing that bug about using 'unsigned char' for registers. The algorithm will need to move away from using adjacency matrix to probably a graph-vertex data structure approach as the adjacency matrix could eat up memory. I don't know if it would help, but Audrey speaks highly of the Judy library: http://judy.sourceforge.net/ which provides sparse dynamic arrays in what is apparently a very efficient way. If Judy would provide the best solution, we could have Parrot use it. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Portable dirfd() (was Re: [perl #39261] stat() doesn't work on dirhandles)
On Mon, Jul 03, 2006 at 12:22:15PM -0700, chromatic wrote: On Monday 03 July 2006 11:43, Steve Peters via RT wrote: (from p5p) OK, with change #28473, I just added the capabilities to a stat() or -X filetests for systems with the dirfd() libc call available. There are two additional steps that need to be done. First, Perl_pp_stat and Perl_my_stat() have a lot of similar code when doing fstat()'s. Much of the common code should be refactored out. Second, developing an internal dirfd() for operating systems that need it should be done so this functionality is more portable. Also, adding a few extra tests wouldn't hurt either. I touched Parrot's File PMC the other day; could it use something like this? Probably. I have a couple of other configuration tasks I need to get finished for Parrot, so, I'll add a portable dirfd() implementation to the pile. Steve Peters [EMAIL PROTECTED]
RE: [yapc] DOC: glossary
Hello. If no one has a problem with it, I'd like to volunteer to be pumpking for this doc. I saw juerd on perl6-lang mentioned http://pugs.kwiki.org/?Perl6Nomenclature as a possible starting point, but Uri's description calls for something a bit more descriptive. Joel York [Shadowhawk] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Uri Guttman Sent: Sunday, July 02, 2006 5:24 PM To: perl6-language@perl.org Cc: [EMAIL PROTECTED] Subject: [yapc] DOC: glossary hi to all docathon hackers (and others too), one idea we came up with during the docathon is that perl6 needs a glossary. would the terms autobox or mixin make any sense to a newcomer who didn't know any OO theory? so this is a proposal to start a glossary as a new S\d+ or other document. here are some ideas i have been bouncing in my skull that i would like to see in it: the list of terms should include all of perl6's special variable names, namespaces (including the term namespace! :), keywords, OO theory terms (like autobox). i think it should also include many/most of parrot's terms as there is some overlap. stuff like haskell, pugs, PGE, and others should also be included. i don't think perl6 ops should be included. each term should have a pronunciation if it isn't obvious. of course there should be a succinct definition of no more than a couple of sentences. a reference to the S\d+ docs that discuss the term in depth links/references to longer definitions on the web for non-perl specific terms like autobox. a 'see also' section referring to other terms. i think a pumpking should be annointed to own the master doc. this would be a great job for anyone who wants to help as you don't even need to understand all the terms or be a core perl6 hacker. you just need to know how to alphabetize, format and handle patches, google a bit for external links, track xrefs and see also's and such. this is basically an ongoing editor job. a first task would be to create this doc and to create a pod template for entries. then others can submit entries in that format or the pumpking can edit them into that format. we can start with just a list of terms and they can be filled out incrementally. i do expect this to be fairly large with several hundred terms. i will post a starter list of terms soon. it will just be words i have been seeing in S02 which is the spec i have been editing. all the other docathon hackers (and anyone else) can submit lists as well. when we have a pumpking, then the glossary doc itself can be started. if you want to submit entries do that too. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ yapc mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/yapc
Re: Using Rules Today
In any case, I was wondering if someone could provide me with an example of a mathematical expression parser (and evaluator). To properly compare to the others, it would need to handle the following operators +, - (left associative) *, /, % (left associative) ^ (right associative) handle parens 12 - (3 + 4) handle two functions sqrt() and abs() both of which must include the parens. If someone has time to do this for me, I would be appreciative. It might also serve as example documentation or cookbook ideas. I am specifically interested in examples that can be run in Perl 5 today without needing Pugs or Parrot. It isn't specifically a parser designed for general language parsing, but CGI::Ex::Template does have a mathematical expression parser. The parser is located near the end of the parse_expr method. The output of the parse_expr is an opcode data structure that can be played out through the play_expr method. The basic functionality is that a chain of operators is tokenized into a single array. The apply_precedence method is then used to split the array into the optree based upon the precedence and associativity of the operators. The following is a sampling of the resulting optrees for the given expressions (taken from the perldoc): 1 + 2 = [ \ [ '+', 1, 2 ], 0] a + b = [ \ [ '+', ['a', 0], ['b', 0] ], 0 ] a * (b + c) = [ \ [ '*', ['a', 0], [ \ ['+', ['b', 0], ['c', 0]], 0 ]], 0 ] (a + b) = [ \ [ '+', ['a', 0], ['b', 0] ]], 0 ] (a + b) * c = [ \ [ '*', [ \ [ '+', ['a', 0], ['b', 0] ], 0 ], ['c', 0] ], 0 ] perl -e 'use CGI::Ex::Template; $s=CGI::Ex::Template::dump_parse(3 * 4 ** 2 + 5); $s =~ s/\s+/ /g; print $s\n' $VAR1 = [ \[ '+', [ \[ '*', '3', [ \[ '**', '4', '2' ], 0 ] ], 0 ], '5' ], 0 ]; I apologize that the expression parsing isn't a little more abstracted for you, but the result should be usable. Also, the parse_expr is designed for also parsing variable names in the TT2 language, so the first portion of the method applies variable names. The entire thing could be cut down considerably if all you want to parse is math (no variables). Paul Seamons
[perl #39695] Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #39695] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39695 On Mon, Jul 03, 2006 at 03:39:19PM -0500, Vishal Soni wrote: On Mon, 2006-07-03 at 13:03 -0700, Chip Salzenberg wrote: The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot has an unbounded (if not infinite :-)) number of registers [...] You'll have to use the INTVAL typedef as the data type to hold register numbers. The function prototype is void Parrot_register_move(Interp *interpreter, int n_regs, unsigned char *dest_regs, unsigned char *src_regs, unsigned char temp_reg, reg_move_func mov, reg_move_func mov_alt, void *info); src_regs and dest_regs are pointers to unsigned char. Unsinged char being 1 byte will store 256 distinct values. Hence I declared the MAX_REGISTER to 256. Well look at that. If I'd looked a bit closer at the diffs I might have noticed that myself. That's definitely an RT-able bug. Let me know what case do we need to code for unbounded number of registers or 256 registers for now. The former, please. I'd consider it the beginning of fixing that bug about using 'unsigned char' for registers. The algorithm will need to move away from using adjacency matrix to probably a graph-vertex data structure approach as the adjacency matrix could eat up memory. I don't know if it would help, but Audrey speaks highly of the Judy library: http://judy.sourceforge.net/ which provides sparse dynamic arrays in what is apparently a very efficient way. If Judy would provide the best solution, we could have Parrot use it. -- Chip Salzenberg [EMAIL PROTECTED]
Re: TAP Grammar
On Monday 03 July 2006 09:01, Jonathan T. Rockway wrote: That said, I would be interested. I'm still trying to page all the perl6/parrot grammars (PGE, TGE, etc.) into my brain, so any additional examples would helpful, interesting, and fun. For me, anyway :) Jerry Gay just wrote a PGE TAP grammar: http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg -- c
[perl #39693] Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #39693] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39693 Thanks muchly for this contribution. I love making failing tests pass. There are some adjustments needed, though, before we can integrate this patch into Parrot. The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot has an unbounded (if not infinite :-)) number of registers, set on a per-function basis. [When you talked to me on IRC, if I'd known you were indexing registers I'd have mentioned this.] You'll have to use the INTVAL typedef as the data type to hold register numbers. So the first step in making this patch ready to apply is to make it adapt automatically to the actual number of registers used in the given function. It's possible the Parrot Cage Cleaners could have a volunteer ready to help you with this (C maven alert: I can imagine an interesting hack to use 'short' or 'unsigned char' when functions are small and INTVAL when they are large. But I digress.) Perhaps separately: I recall that Audrey Tang (Pugs mastermind) ran into problems with aggressive use of continuations conflicting with the register coloring algorithm. Continuations allow any function call to pop out at any function return point, not just at the return point that follows the last call made. From a register coloring point of view, the point after each function call starts a new basic block. Being new pumpking I'm not versed in the register allocation parts of Parrot yet, so I may have missed something, but IIRC this is an issue that must be dealt with. Is your patch relevant to this question, or orthogonal? Finally: The coding style of your patch will need a little work. Style is something a Cage Cleaner volunteer can help with once the code is otherwise ready. I'm not religious about coding styles, but style _consistency_ is pretty important in a multi-person project. Ideally, a reader should be unable to tell newly inserted code from old code. (Except that new code should always work. :-)) There are also some Parrot coding style issues that are functionally important, and not just about looking good. For example, shared declarations must always be in header files (yes there are exceptions in the current code base but we're weeding them out gradually). Also, extern symbols must always a Parrot_ prefix, to facilitate embedding Parrot in other applications. There are other lesser style issues WRT spacing and braces, but they're easy to deal with. The main thing is to get the algorithm solid, and the rest can be dealt with later (before the patch is applied, though :-)). On Sun, Jul 02, 2006 at 02:02:34PM -0500, Vishal Soni wrote: This patch implements the register content preserving move operation. Thanks, Vishal Previously: - Now:1..3 ok 1 - in P param ok 2 - tailcall 1 not ok 3 - tailcall 2 # TODO use temp # Failed (TODO) test (t/compilers/imcc/imcpasm/optc.t at line 59) # '# IMCC does produce b0rken PASM files # # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392 # _main: # @pcc_sub_call_0: # set_args # set_p_pc P0, foo # get_results # invokecc P0 # set_returns # returncc # foo: # get_params # [EMAIL PROTECTED]: # @pcc_sub_call_1: # set I0, I1 # set I1, I0 # branch [EMAIL PROTECTED] # ' # doesn't match '/ set I(\d), I(\d) # set I\2, I(\d) # set I\3, I\1/ # ' -- 1..3 ok 1 - in P param ok 2 - tailcall 1 ok 3 - tailcall 2 # TODO use temp Patch: ---Index: src/utils.c === --- src/utils.c (revision 13113) +++ src/utils.c (working copy) @@ -48,6 +48,7 @@ =cut */ +#define MAX_REGISTER 256 INTVAL intval_mod(INTVAL i2, INTVAL i3) @@ -678,12 +679,29 @@ TODO add a define, if it's implemented so that we can start filling the gaps +TODO The current implementation will not work for following cases + +1. I0-I1 I1-I0 I0-I3 +2. I1-I2 I3-I2 + +Vishal Soni =cut */ /* proto TODO mv to hdr */ typedef int (*reg_move_func)(Interp*, unsigned char d, unsigned char s, void *); +int reorder_move(unsigned char (*a)[MAX_REGISTER],unsigned char *val ,int src , int prev, int depth ,reg_move_func mov,Interp *interpreter,void *info,int temp); +int find_first_indegree(unsigned char (*a)[MAX_REGISTER] , int dest); +int find_root(unsigned char (*a)[MAX_REGISTER],unsigned char* root_vertex ,int src, int dest); +void emit_mov(reg_move_func mov,Interp *interpreter,void *info,int emit,int emit_temp,int src,int dest,int temp); +void +Parrot_register_move(Interp *interpreter, int n_regs, +unsigned char *dest_regs, unsigned char *src_regs, +unsigned char temp_reg, +reg_move_func mov, +reg_move_func mov_alt, +
Re: pdd21 vs. find_global
Patrick R. Michaud wrote: you change to $P99 = get_namespace key_or_array $P0 = $P99['foo'] which also incidentally encourages(!) compilers to cache namespace pointers. Ooh. I like it very much! Okay, to flesh this out as a viable alternative, Chip/Patrick we need: a) a standard pattern for compiler writers to follow to cache namespace PMCs (various compilers may vary the pattern, but we need one straightforward base example) b) a way to access a symbol in the currently selected namespace without retrieving the namespace by its literal name (this may work out to be part of the more general caching strategy) Allison
Re: TAP Grammar
I would say that even if nobody else is interested, if you're interested, do it :) That said, I would be interested. I'm still trying to page all the perl6/parrot grammars (PGE, TGE, etc.) into my brain, so any additional examples would helpful, interesting, and fun. For me, anyway :) Regards, Jonathan Rockway Ovid wrote: Hi all, I would still like to be in a position to write a grammar for TAP, but I've heard no answers to my questions. Should I assume that a formal grammar is not wanted/desired at this point? Cheers, Ovid
[perl #39696] perl6 makefile should relocate
# New Ticket Created by Will Coleda # Please include the string: [perl #39696] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39696 Currently the perl6 makefile is in the root parrot config dir: config/ gen/makefiles/perl6.in It should move closer to home: languages/perl6/config/root.in -- Will Coke Coleda [EMAIL PROTECTED]
Re: [perl #39696] perl6 makefile should relocate
On Mon, Jul 03, 2006 at 07:37:00PM -0700, Will Coleda wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #39696] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39696 Currently the perl6 makefile is in the root parrot config dir: config/ gen/makefiles/perl6.in It should move closer to home: languages/perl6/config/root.in Feel free to make this switch. :-) Pm
[perl #39697] [TODO] Tcl - use the standard library code
# New Ticket Created by Matt Diephouse # Please include the string: [perl #39697] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39697 Tcl comes with several procedures that are actually written in Tcl as part of the standard library ([clock], [parray], etc.). We should include this code in the ParTcl source tree and use it instead of trying to implement them as builtins. The library is in Tcl's CVS here: http://tcl.cvs.sourceforge.net/tcl/tcl/library/ And don't forget the license.terms file: http://tcl.cvs.sourceforge.net/*checkout*/tcl/tcl/license.terms? revision=1.3 After this is working, builtin versions of these commands can be deleted. -- Matt Diephouse
[ANNOUNCE] Pugs 6.2.12 and v6.pm released!
Changes for 6.2.12 (r10930) - June 26, 2006
Licensing Changes
The src/ tree and the
pugs
executable are now released under the permissive MIT license, in addition to Artistic and GPL
A new third-party/ tree to hold bundled prerequisites originated from non-Pugs projects
New Perl 6 modules
ext/Relation/ - Relation type for Perl 6 (incomplete)
ext/Getopt-Std/ - Simple command-line parsing
Updated modules
ext/Locale-KeyedText/ - Added export_as_hash() methods
ext/Rosetta/: Multiple additions and rewrites
Merged ext/Rosetta-Engine-Native/ in, renamed to ::Example
Now officially incorporates The Third Manifesto
Rewrote half of Language.pod
Updated the DESCRIPTION and class list of Rosetta.pm
Added new core module Rosetta::Shell and example shell.pl
Added new documentation file Rosetta::SeeAlso
Various other documentation additions and edits
ext/Test/: Avoid the use of junctions to make Parrot/Perl6's life easier
Perl 6 on Perl 5 (under misc/pX/Common/)
Data-Bind - Implement Perl 6's calling/binding convention on Perl 5
Inline-Parrot - a C version of Inline-Parrot - uses NCI for data exchange
Module-Compile - precompile Perl 5 modules transparently
P5_to_P6_Translation - beginning of a Perl 5.9 MAD tree parser and translater to Perl 6
Pugs-Compiler-Perl6 - Compiler for Perl 6 (implements 'use v6-pugs'):use v6-pugs; say Perl 6; use v5; print Perl 5
Pugs-Compiler-Precedence - an operator precedence parser, built around Parse::Yapp
Pugs-Compiler-Rule - Compiler for Perl 6 Rules
Pugs-Grammar-MiniPerl6 - translate Perl 6 rules into haskell Parsec
Pugs-Grammar-Perl6 - a Perl 6 parser - parses Test.pm!
lrep - a bootstrapped, very minimal Perl 6 compiler written in Perl 6
re-override - Swaps in an alternate regexp engine:./perl -we 'use re::override-perl6; print a =~ /word**{1}/';
Test, Examples and Documentations
Restored this ChangeLog's entries for v6.0.0 thru v6.0.8, which were truncated in r8916, apparently from gnome's copy-paste buffer limit
docs/Perl6/Doc hierarchy, installable
Perl6::Doc
docs/Perl6/FAQ/Capture.pod - FAQ on the new Signature/Capture convention
docs/Perl6/FAQ/FUD.pod - Fears, Uncertainties and Doubts about Perl 6
docs/talks/p6myths2.html: Juerd's talk Perl 6 Myths
docs/talks/peek.spork: Gaal's OSDC talk A Peek into Pugs Internals
examples/concurrency/: Added sample usage on Software Transactional Memory
examples/qotw/: Added the QOTW 8 Expert solution
examples/rules/: Added a sample BASIC parser
src/Pugs/Parser - Perl 6 grammars for Capture.pg and Signature.pg
util/cperl-mode.el - Emacs mode for Perl 6
Feature Changes
Pugs now builds in a single pass
Removed support for GHC 6.4.0 and added support for GHC 6.5
Removed support for Parrot 0.4.4 or below and added support for Parrot 0.4.5
?SUB is replaced with ?ROUTINE; $?SUBNAME is replaced with ?ROUTINE.name
Arguments beginning in parens, such as
f ('x')=1
, is now always positional
Array and hash sigilled match variables, such as
@0
,
@foo
and
%bar
Assignment with non-obviously-scalar left-hand side is now in list context:
@a = 1,2,3
now parses as
@a = (1,2,3)
Broke down Parser and AST.Internals to smaller files so rebuilds are faster
Builtin functions no longer defaults to
$_
; write
.ord
instead of
ord
Compile
Prelude.pm
and
Test.pm
, to YAML bytecode for faster loading
Declarators are now lexical:
{ $x++ unless my $x }
increments
$OUTER::x
Declarators can now occur at _expression_ position:
my $x + my $y
works
Declarators no longer take qualified names:
our $Foo::x
is invalid
Experimental support for Software Transactional Memory and atomic blocks
Hash initializers now revert to bias-to-left behavior as in Perl 5
In
{X = 1, X = 2}
, the value of X is 2, not 1
If a block ends on a line by itself, an implicit
;
is assumed if possible
In the interactive shell, :d and :D (dump parse tree) now continues the parse from the current environment; use :reset to reset the environment
More helpful diagnostics when calling unsafe builtins under safe mode
Multiline support in the interactive shell reports unrecoverable parsefails
Names of named arguments must always be a bareword now, such as:f(name=1); f(:name(1));
New AST-dumping backends:
Parse-Pretty
,
Parse-YAML
,
Parse-HsYAML
Parse-time binding
::=
is now fully supported
Proper desugaring of
.=
expressions, such as
@a .= map(sqrt)
Prototype objects:
my Dog $fifo
now assigns
::Foo
into
$fido
Removed support for
require ::Class::Literal
Removed support for
rx_
macros in Prelude for user-defined rule handlers
Quotelike constructs such as
rx
and
qq
no longer takes `#` as delimiter
Support for Unicode bracket characters for quotelike operators
Support for bracketed comments: #(...), # ... , etc
Support for controlled backtracking and whitespace sensitivity via distinct
token/regex/rule
delecarators
Support for environmental variables such as
$ENV::PWD
and
$+PATH
Support for implicit-topic
[perl #39698] [TODO] Tcl - Convert [expr] to use PGE/TGE
# New Ticket Created by Matt Diephouse # Please include the string: [perl #39698] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39698 [expr]'s current implementation is less than optimal in terms of developer time. It should be converted to use PGE/TGE now that they exist. This will make it easier to add on to and easier to compile, among other things. -- Matt Diephouse
