Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called CONTROL_TAKE, because that's meaningless outside Perl 6. So, I think we can't always say oh, only one dynamic language needs this feature so it shouldn't be global -- we need to also consider those dynamic-languages-yet-to-be-written because Parrot is such an incredible platform for creating them. Yes, that's not the principle. The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. Allison
Re: ExceptionHandler enhancement proposal
Bob Rogers wrote: Yes, once we have the ability to have exception handlers only handle specific types of exceptions, then they'll allow all other types of exceptions to pass through. (Which means we won't end up with the infinite exception handler loops we currently get if exception handlers aren't disabled as soon as they're used.) Are you sure? What if the body of a catch-all error handler signals an error? Methinks the handler must truly be taken out of scope before it is invoked in order to avoid infinite exception handler loops. Yes, of course a catch-all exception handler will always catch all exceptions. But, a catch-all exception handler is intended to catch all exceptions, and therefore can't make any assumptions about the exception object other than the defined standard exception interface. The problem now isn't that the same exception handler is being called twice (once on the first exception, and once on the exception thrown from within the handler). The problem is that the exception handlers were written assuming that they'd only ever get one kind of exception. When they get a different kind of exception the second time, they aren't expecting it, and make some terrible mistake, which throws another exception, but they don't know how to handle that one and make a terrible error and throw another exception, and so get themselves into an infinite loop. The 'can_handle' method is the only required interface for checking whether a particular handler will accept a particular exception. All other checks should be hidden behind that method. Hmm. The only way to find out whether a Lisp handler will handler a given exception is to call it; if the answer is yes, it will never return. So I'm hoping a 'can_handle' method that either returns false or transfers control to somewhere else can be made to work. For that, you would implement a catch-all handler (completely ignoring 'can_handle'), and then rethrow any exceptions you can't handle. Allison
[perl #53536] [PATCH] sub-second sleep precision for non-threaded architectures
On Mon Sep 15 20:08:38 2008, [EMAIL PROTECTED] wrote: chromatic wrote: On Monday 15 September 2008 01:25:15 Christoph Otto via RT wrote: It applies with a little noise to the current trunk and passes make test. The attached version just changes line numbers so the patch applies without any complaints (plus a codingstd fix). +1 for applying, fwiw. +1 as well, if someone replaces the Not yet documented lines with documentation (man usleep should help). -- c I'll be applying the attached the patch after tomorrow's release, if someone doesn't beat me to it. Done. Thanks for the patch!
[perl #58866] calling a PIR sub with 206 params segfaults parrot
On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: On Tuesday 16 September 2008 14:47:58 NotFound wrote: It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. That sounds like a bog-standard static variable overflow, where each parameter requires five bytes of storage. If that's a good rule of thumb, we could malloc/free that buffer instead, and then beat anyone who uses more than a dozen parameters. -- c Looking at the code, it's 5n+1. r31200 changes the static buffer to a dynamic one of the correct size. The original PIR code now runs without segfaulting, as does a version with 20,000 int params. make test also passes, so nothing new appears to be broken. With the assumption that the said beatings will be a manual process, I'm marking this resolved.
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Not long ago, Patrick R. Michaud proclaimed... I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) I plan to add support for gather/take to cardinal. While we're discussing it, though, it might be fun to add it to lolcode, for purposes of flashy inter-hll demos.
[perl #58742] [TODO] Marker for RTs re SmartLinks
On Tue Sep 16 15:45:47 2008, [EMAIL PROTECTED] wrote: 2. I will apply a refined version of the patch. It will delete inline comments referring to the deleted tickets. But I will leave to others dealing with reference to smartlinks under languages/. Done, now that release has been cut. 4. I will then open up a new RT of the [RFC] class. This ticket will call for development of a specification of a way to visually display the extent to which Parrot's tests cover the specification. I'll be quoting from particle's post -- but I'm sure there will be additional questions for Jerry. The spec will call for a way to test whatever code we develop to meet the spec. So, rather than asking people to rush out to write code, we'll focus first on determining what we want and need. Still TODO.
[perl #58958] Build of 0.7.1 fails with Intel compiler on Linux
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #58958] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58958 I'm trying to build Parrot 0.7.1 with Intel Compiler (see version information below). The operating system is Ubuntu 8.04, 64-bit. Build succeeds with GCC (4.2.3 installed). Parameters to Configure.pl are as follows: perl Configure.pl --cc=icc --cxx=icc --ld=icc I have four versions installed under /opt: 9.1.042 in 32 and 64-bit; 10.1.015 in 32 and 64-bit. (Switching between them using the method recommended by Intel: source iccvars.sh.) I have been successful in compiling previous versions of Parrot with icc in the past; I think 0.6.4 was the last one that worked. For both 32-bit versions, Configure.pl fails at: --cut-- init::manifest - Check MANIFEST.done. init::defaults - Set Configure's default values.done. init::install - Set up installation paths..done. init::miniparrot -Tweak settings for miniparrot...skipped. init::hints - Load platform and local hints filesdone. init::headers - Find header files distributed with Parrot..done. inter::progs -Determine what C compiler and linker to use...Compilation failed with 'icc' --cut-- I have been unable to enable Configure.pl to produce more output, or the error messages themselves. 32-bit icc works fine when compiling other programs on the same system. For 64-bit 9.1.042 and 10.1.015, I get the following error: --cut-- /usr/bin/perl5.8.8 tools/build/c2str.pl --all src/string.c src/ops/core_ops.c src/ops/core_ops_switch.c src/byteorder.c src/charset.c src/core_pmcs.c src/cpu_dep.c src/datatypes.c src/debug.c src/debug.c(1384): warning #593: variable regleft was set but never used unsigned charregleft; ^ src/dynext.c src/embed.c src/encoding.c src/events.c src/exceptions.c src/exceptions.c(74): error: identifier _CONST_STRING_74 is undefined VTABLE_set_integer_keyed_str(interp, exception, ^ src/exceptions.c(76): error: identifier _CONST_STRING_76 is undefined VTABLE_set_integer_keyed_str(interp, exception, ^ src/exceptions.c(106): error: identifier _CONST_STRING_106 is undefined const INTVAL severity = VTABLE_get_integer_keyed_str(interp, ^ src/exceptions.c(125): error: identifier _CONST_STRING_125 is undefined exit_status = VTABLE_get_integer_keyed_str(interp, ^ src/exceptions.c(276): error: identifier _CONST_STRING_276 is undefined int exitcode = VTABLE_get_integer_keyed_str(interp, exception, ^ src/exceptions.c(287): warning #191: type qualifier is meaningless on cast type (Parrot_runloop * const)VTABLE_get_pointer(interp, handler); ^ src/exceptions.c(401): error: identifier _CONST_STRING_401 is undefined VTABLE_set_integer_keyed_str(interp, exception, ^ compilation aborted for src/exceptions.c (code 2) make: *** [src/exceptions.o] Error 2 --cut-- Will provide more information on request. -- Ville Koskinen
Re: [perl #58958] Build of 0.7.1 fails with Intel compiler on Linux
On Wednesday 17 September 2008 04:48:59 [EMAIL PROTECTED] (via RT) wrote: src/exceptions.c(74): error: identifier _CONST_STRING_74 is undefined VTABLE_set_integer_keyed_str(interp, exception, This one means that ICC handles #line directives differently. If you manually edit this line to remove the linebreak before CONST_STRING, does ICC still give an error here? -- c
Re: Parrot 0.7.1 Manu Aloha released
Patrick R. Michaud a écrit : On behalf of the Parrot team, I'm proud to announce Parrot 0.7.1 Manu Aloha. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. As usual, the Windows setup is available on http://parrotwin32.sourceforge.net/ François. Parrot 0.7.1 is available via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html . For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.7.1 News: - Implementation + add -I and -L command line options + support for null strings in NCI calls + preliminary support for resumable exceptions + add '.hll_map' method for dynamic HLL type mapping + more parrot_debugger fixes + remove obsolete '.past' extension - Languages + Rakudo (Perl 6) - now over 3300 passing spectests - precompiled modules - precompiled scripts (--target=pir can now be executed standalone) - Support for @*INC and %*INC varialbes - additional builtin methods and subs - added 'fail' function, warnings on use of undefined values - m/.../ regexes - qq, qw, q quoting forms - run tests in parallel - gather/take - Perl6MultiSub + Cardinal (Ruby): - 'require' and precompiled modules - many new tests - all Array tests pass - regexes - default arguments to functions - new committer - Compilers + PCT: - add :loadinit attribute for PAST::Block + PIRC: - major refactoring to allow all PIR keywords as identifiers - links to libparrot now, so all Parrot ops are recognized as such - implemented .loadlib, .HLL_map, .HLL - Miscellaneous + add Xlib and Mysql modules and test programs to NCI examples + many updates and cleanups to PDD documents Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 21 Oct 2008. Enjoy!
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Wed, Sep 17, 2008 at 10:57:31AM +0200, Allison Randal wrote: Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called CONTROL_TAKE, because that's meaningless outside Perl 6. [...] The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. What's the language-agnostic term for this, then? Pm
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
On Tue, Sep 16, 2008 at 11:45 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: On Tuesday 16 September 2008 14:47:58 NotFound wrote: It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. That sounds like a bog-standard static variable overflow, where each parameter requires five bytes of storage. If that's a good rule of thumb, we could malloc/free that buffer instead, and then beat anyone who uses more than a dozen parameters. -- c Looking at the code, it's 5n+1. r31200 changes the static buffer to a dynamic one of the correct size. The original PIR code now runs without segfaulting, as does a version with 20,000 int params. make test also passes, so nothing new appears to be broken. With the assumption that the said beatings will be a manual process, I'm marking this resolved. you didn't mention it, but i sincerely hope you committed a test with 20,000 params that proves this and makes sure we don't regress in a future revision. parrot needs much more stress testing like this, and it would be a shame to miss this opportunity. ~jerry
[perl #58978] [TODO][IMCC] replace .result by .get_result
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #58978] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58978 as suggested by Allison, .result in a .begin/end_call sequence will be replaced by .get_result
[perl #58976] [TODO][IMCC] .arg will be replaced by .set_arg
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #58976] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58976 as suggested by Allison, the .arg directive in a .begin_call/end_call statement will be replaced by .set_arg
[perl #58974] [TODO][IMCC] replace .return in tailcall context by .tailcall
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #58974] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58974 as suggested by Allison, .return in a tailcall context, like this: .return foo() will changed into: .tailcall foo()
[perl #58980] [TODO][IMCC] .return in a .begin/end_return will be replaced by .set_return
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #58980] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58980 As suggested by Allison, in a .begin/end_return sequence, the .return directive will be replaced by .set_return Likewise .yield will become .set_yield in .begin/end_yield sequence.
Re: Parrot 0.7.1 Manu Aloha released
On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote: http://www.parrotcode.org/release/devel still points to 0.7.0 I sent the appropriate patch to the webmaster, but it hasn't been applied yet (and I lack a commit bit for the parrotcode.org site). Once that's applied, the url should be fixed. Pm
Re: Parrot 0.7.1 Manu Aloha released
http://www.parrotcode.org/release/devel still points to 0.7.0 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #58990] [TODO] Design new spec coverage mechanism
# New Ticket Created by James Keenan # Please include the string: [perl #58990] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58990 We need a way to measure the extent to which Parrot's test suite covers the Parrot specification. Since the specification is expressed in words rather than code, a quantitative measurement of the spec coverage is unlikely. However, a visual representation of that coverage is possible and desirable. For example, HTML versions of the Parrot design documents might carry annotations which indicate which tests exercise the code described in particular paragraphs in the PDDs. The objective of this RT is to develop a specification for a new spec coverage mechanism. The specification, like other PDDs, should be written in Perl 5 POD. This specification should define key terms; it should not assume, for example, that everyone knows what a 'smartlink' is. It should describe the graphic appearance of the spec coverage mechanism and specify what functionality (e.g., 'mouse over') the functionality will have. While it should draw upon prior art where appropriate, it should not depend on a reader being previously familiar with, e.g., the Pugs implementation. The specification should also include a plan for testing the spec coverage mechanism, including both unit and functionality tests. A testing plan, in broad outline, should exist before any code is written. The code should be written in easily maintainable Perl 5 and documented in Perl 5 POD. Note: While the spec coverage mechanism will ultimately have to be written in Perl 5 POD, we should consider doing some early drafts on the Parrot wiki. Those readers of the list who want to work on this project should speak up as to whether this is a good way to proceed.
[perl #58742] [TODO] Marker for RTs re SmartLinks
On Wed Sep 17 05:30:18 2008, [EMAIL PROTECTED] wrote: 4. I will then open up a new RT of the [RFC] class. This ticket will call for development of a specification of a way to visually display the extent to which Parrot's tests cover the specification. I'll be quoting from particle's post -- but I'm sure there will be additional questions for Jerry. The spec will call for a way to test whatever code we develop to meet the spec. So, rather than asking people to rush out to write code, we'll focus first on determining what we want and need. Still TODO. Done. So this RT is now resolved and superseded by # 58990.
