Re: [svn:parrot] r20101 - in trunk: . tools/build
On Jul 23, 2007, at 7:21 PM, chromatic wrote: I'm okay with that, but we should also decorate PANIC with PARROT_DOES_NOT_RETURN, which I believe *should* help compilers. I'm all over it, long ago. PANIC just wraps do_panic which is so decorated. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r20101 - in trunk: . tools/build
On Jul 23, 2007, at 5:57 PM, Kevin Tew wrote: My thinking was that, should someone, someday change PANIC into a recoverable error, this will prevent leakage. Ok its a stretch. :) if it's unreachable, we need to get rid of it. PANIC is a dead-end. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #44121] [BUG] What happened to tools/build/fingerprint_c.pl?
# New Ticket Created by James Keenan # Please include the string: [perl #44121] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44121 This file is still listed in the MANIFEST in trunk, [parrot] 518 $ grep -n fingerprint MANIFEST 3183:tools/build/fingerprint_c.pl[] ... but when I svn updated, it was no longer found. This causes Configure.pl to ack about a missing file and it causes the init::manifest step to fail. Checking MANIFEST...No such file: tools/build/fingerprint_c.pl Ack, some files were missing! I can't continue running without everything here. Please try to find the above files and then try running Configure again. step init::manifest failed: no result returned at Configure.pl line 395 What happened to it? kid51
Re: [perl #44121] [BUG] What happened to tools/build/fingerprint_c.pl?
On 24/07/07, via RT James Keenan [EMAIL PROTECTED] wrote: # New Ticket Created by James Keenan # Please include the string: [perl #44121] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44121 This file is still listed in the MANIFEST in trunk, [parrot] 518 $ grep -n fingerprint MANIFEST 3183:tools/build/fingerprint_c.pl[] ... but when I svn updated, it was no longer found. This causes Configure.pl to ack about a missing file and it causes the init::manifest step to fail. Checking MANIFEST...No such file: tools/build/fingerprint_c.pl Ack, some files were missing! I can't continue running without everything here. Please try to find the above files and then try running Configure again. step init::manifest failed: no result returned at Configure.pl line 395 What happened to it? I believe this is an automatically generated file as part of Andy's gcc sniffing stuff (it keeps coming up as a file of zero length on my system). It probably should be in MANIFEST.SKIP or something... Paul
[perl #44125] [PATCH] Configure.pl: more consistent interface
# New Ticket Created by James Keenan
# Please include the string: [perl #44125]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44125
In Configure.pl, some function/method calls take $args as an
argument. Other functions, for legacy reasons, take %args or $args
{somekey} as an argument. But %args is merely %$args.
Let's make this internally consistent. The patch attached eliminates
%args in favor of $args.
You should observe no change in functionality. I'll apply this patch
in a couple of days unless someone objects or beats me to it.
kid51
Index: Configure.pl
===
--- Configure.pl(revision 20150)
+++ Configure.pl(working copy)
@@ -324,7 +324,6 @@
svnid = '$Id$',
} );
exit(1) unless defined $args;
-my %args = %{$args};
my $opttest = Parrot::Configure::Options::Test-new($args);
# configuration tests will only be run if you requested them
@@ -332,7 +331,7 @@
$opttest-run_configure_tests();
# from Parrot::Configure::Messages
-print_introduction($parrot_version) unless exists $args{step};
+print_introduction($parrot_version) unless exists $args-{step};
my $conf = Parrot::Configure-new;
@@ -340,15 +339,15 @@
$conf-add_steps(get_steps_list());
# from Parrot::Configure::Data
-$conf-options-set(%args);
+$conf-options-set(%{$args});
-if ( exists $args{step} ) {
+if ( exists $args-{step} ) {
# from Parrot::Configure::Data
$conf-data()-slurp();
$conf-data()-slurp_temp()
-if $args{step} =~ /gen::makefiles/;
+if $args-{step} =~ /gen::makefiles/;
# from Parrot::Configure
-$conf-runstep( $args{step} );
+$conf-runstep( $args-{step} );
print \n;
}
else {
@@ -362,8 +361,7 @@
$opttest-run_build_tests();
# from Parrot::Configure::Messages
-print_conclusion($conf-data-get('make')) unless exists $args{step};
-
+print_conclusion($conf-data-get('make')) unless exists $args-{step};
exit(0);
### DOCUMENTATION ###
[perl #44121] [BUG] What happened to tools/build/fingerprint_c.pl?
On Tue Jul 24 05:11:52 2007, ptc wrote: On 24/07/07, via RT James Keenan parrotbug-followup !-- x -- at parrotcode.org wrote: # New Ticket Created by James Keenan # Please include the string: [perl #44121] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44121 This file is still listed in the MANIFEST in trunk, [parrot] 518 $ grep -n fingerprint MANIFEST 3183:tools/build/fingerprint_c.pl[] ... but when I svn updated, it was no longer found. This causes This appears to be nothing more than someone forgetting to update MANIFEST. The file was checked in at least a few revs ago, it was then deleted.
Re: [perl #44121] [BUG] What happened to tools/build/fingerprint_c.pl?
Will Coleda via RT wrote: This appears to be nothing more than someone forgetting to update MANIFEST. The file was checked in at least a few revs ago, it was then deleted. Geck, that was me last night. Sorry all. (For those wondering where fingerprint_c.pl is going, I'm working on implementing PDD13 and it doesn't use fingerprints). Fixed in r20153. Jonathan
What I broke
Here's what I know is broken because of changes I've made yesterday: t/compilers/imcc/syn/file.t 255 6528013 16 1-13 t/library/test_builder_tester.t0 612 16 1-12 t/library/test_more.t 0 658 106 1-58 t/op/string.t 5 1280 160 155 1-37 39-70 72 74-90 92- 96 98-160 t/pmc/exporter.t 6 1536126 1-6 t/pmc/objects.t1 25678 77 1-6 8-78 -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: What I broke
On Jul 24, 2007, at 8:43 AM, Andy Lester wrote: Here's what I know is broken because of changes I've made yesterday: t/compilers/imcc/syn/file.t 255 6528013 16 1-13 This is still broken, as is shootout (of course). t/library/test_builder_tester.t0 612 16 1-12 t/library/test_more.t 0 658 106 1-58 t/op/string.t 5 1280 160 155 1-37 39-70 72 74-90 92- 96 98-160 t/pmc/exporter.t 6 1536126 1-6 t/pmc/objects.t1 25678 77 1-6 8-78 All fixed. xoxo, andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #44139] opcodes, warnings, and exceptions
# New Ticket Created by Jerry Gay # Please include the string: [perl #44139] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44139 the api for opcodes needs review, especially with regard to the response to exceptional behavior. for example, the documentation for Blength in src/ops/string.ops reads: =item Blength(out INT, in STR) Set result $1 to the length (in characters) of string $2. If $2 is NULL or zero length, zero is returned. however, if a null string is passed in to length, the user should get some notification of an exceptional condition. *at least* a warning, and possibly a fatal exception. ~jerry
[perl #44101] Parrot 0.4.14 fails: src/pmc/object.c, line 153: void function cannot return value
# New Ticket Created by Andy Dougherty # Please include the string: [perl #44101] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44101 As of version 0.4.14, parrot no longer builds for me with Sun's Workshop compiler on Solaris 8/SPARC. I get 66 errors of the form: src/pmc/object.c, line 153: void function cannot return value I tried browsing through the source history for lib/Parrot/Pmc2c via the SVN web interface, but kept getting errors of the form: An Exception Has Occurred Checkout view is disabled HTTP Response Status 403 Forbidden Python Traceback Traceback (most recent call last): File /home/web/svn/viewvc/lib/viewcvs.py, line 3593, in main request.run_viewcvs() File /home/web/svn/viewvc/lib/viewcvs.py, line 379, in run_viewcvs self.view_func(self) File /home/web/svn/viewvc/lib/viewcvs.py, line 2114, in view_checkout '403 Forbidden') ViewCVSException: 403 Forbidden: Checkout view is disabled I gave up trying to find the relevant change. If this error isn't fixed, the following patch is needed for PLATFORMS: --- parrot-0.4.14/PLATFORMS 2007-07-11 09:15:35.0 -0400 +++ parrot-andy/PLATFORMS 2007-07-23 13:04:17.0 -0400 @@ -26,7 +26,7 @@ linux-x86_64-gcc4.1.0 4 Y-- Y Y YY/2 ? 20060807 linux-x86_64-gcc4.1.2 8 Y-- Y Y YY ? 20070619 openbsd-zaurus-gcc3.3.5 Y-- Y Y Y? ? 20070309 -sol8-sparc-ccB--- - - -Y/441 ? 20070427 +sol8-sparc-ccB--- - - -- ? 20070723 sol10-sparc-cc_5.8 BY-- Y Y YY/9 ? 20060807 sol10-sparc-gcc_4.0.2BY-- Y Y YY/9 ? 20060807 sol11-x86-cc_5.8 Y-- - - -- ? 20070417 I fixed the error in src/pmc/object.c by changing all the return (void)NULL; lines into simple return; but that will be lost once pmc2c is run again. With that temporary fix in place, I get 496 test failures (mostly out-of-memory errors in the compilers/pge/p[56]regex/ tests) which is consistent with what I've been seeing for a very long time. -- Andy Dougherty [EMAIL PROTECTED]
Tcl Assertion failures
As of r20160, Tcl was generating a lot of assertion errors, ala: src/inter_call.c:228: failed assertion `sig_pmc-vtable-base_type == enum_class_FixedIntegerArray' Turns out, this is directly attributable to runtime/hacks.pir - my attempt to store the results of compilation of tcl to pir as a frozen PMC. While this worked when it was checked in, at some point trying to read in, thaw, and invoke that PMC started generating these assertion errors (which are a result of something getting garbage collected that oughtn't.). Hopefully knowing which area of partcl was causing this will help track down the GC bug. Given that this was purely a hack on my part to try to get a speedup during development, I'm going to comment this out of partcl for now. Anyone trying to track this down just needs to swap out runtime/ builtin/source.pir with the version from r20160, and run their copy of parrot twice. (once to generate the frozen PMC, once to invoke it.). I think this might point to a bug that needs to be resolved... and it was a big enough speedup that I'd like to re-enable until our compiler is blazingly fast, even if it is a dirty hack. In a related note, I've also disabled the default -G running on the test suite. This seems to expose a host of *new* GC failures. Help! =-)
[perl #43321] [TODO] config/init/defaults.pm: Write unit tests
The basic functionality has been unit tested in t/configure/102-init_defaults.01.t and ...02.t. Ticket cannot be closed until its dependencies are resolved.
[perl #43923] [TODO] Don't regenerate MANIFEST unnecessarily
New files committed; patches applied in r20181.
Re: [svn:parrot] r20172 - trunk/src/ops
On Tuesday 24 July 2007 15:37:54 [EMAIL PROTECTED] wrote:
Modified: trunk/src/ops/var.ops
===
=== --- trunk/src/ops/var.ops (original)
+++ trunk/src/ops/var.ops Tue Jul 24 15:37:53 2007
@@ -105,8 +105,8 @@
op get_namespace(out PMC, in PMC) {
PMC * const cur_ns = CONTEXT(interp-ctx)-current_namespace;
- PMC *ns = Parrot_get_namespace_keyed(interp, cur_ns, $2);
- $1 = ns ? ns : PMCNULL;
+ PMC * const ns = Parrot_get_namespace_keyed(interp, cur_ns, $2);
+ $1 = PMC_IS_NULL(ns) ? PMCNULL : ns;
goto NEXT();
}
How about:
$1 = Parrot_get_namespace_keyed(interp, cur_ns, $2);
I presume that the function always returns either PMCNULL or a NameSpace PMC,
so checking if it's returned PMCNULL and returning PMCNULL in that case seems
a little silly.
-- c
Re: [svn:parrot] r20172 - trunk/src/ops
On Jul 24, 2007, at 8:56 PM, chromatic wrote: I presume that the function always returns either PMCNULL or a NameSpace PMC, so checking if it's returned PMCNULL and returning PMCNULL in that case seems a little silly. Because I'm trying to get all the C code to be NONNULL as much as possible. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r20172 - trunk/src/ops
On Tuesday 24 July 2007 21:25:39 Andy Lester wrote: On Jul 24, 2007, at 8:56 PM, chromatic wrote: I presume that the function always returns either PMCNULL or a NameSpace PMC, so checking if it's returned PMCNULL and returning PMCNULL in that case seems a little silly. Because I'm trying to get all the C code to be NONNULL as much as possible. The code was: $1 = PMC_IS_NULL(ns) ? PMCNULL : ns; If PMC_IS_NULL(ns) -- if it's PMCNULL -- then return PMCNULL. Otherwise, return ns. That is, return exactly what you were going to return anyway. What am I missing here? -- c
Re: [svn:parrot] r20172 - trunk/src/ops
On Jul 24, 2007, at 9:43 PM, chromatic wrote: $1 = PMC_IS_NULL(ns) ? PMCNULL : ns; If PMC_IS_NULL(ns) -- if it's PMCNULL -- then return PMCNULL. Otherwise, return ns. That is, return exactly what you were going to return anyway. What am I missing here? Because PMCNULL can be (PMC)NULL or it can be PMCNULL, a special non- null variable. See how it's defined in the header. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r20172 - trunk/src/ops
On Tuesday 24 July 2007 21:50:55 Andy Lester wrote: What am I missing here? Because PMCNULL can be (PMC)NULL or it can be PMCNULL, a special non- null variable. See how it's defined in the header. I thought we fixed it. Let's fix it. -- c
