Re: [perl #41695] [CAGE]: Refactor Parrot::Distribution
Here are some notes which I have made which may prove useful in the refactoring of Parrot::Distribution. I hope that I have grepped and acked accurately, but I'm not guaranteeing 100% accuracy. kid51 NAME Parrot::Distribution refactoring notes ANALYSIS OF PACKAGE * used by: * packages: * Parrot::Docs::POD2HTML * Parrot::Docs::Section::C * Parrot::Docs::Section::Compilers * Parrot::Docs::Section::Config * Parrot::Docs::Section::Parrot * Parrot::Docs::Section::PMCs * tests: * t/codingstd/c_code_coda.t * t/codingstd/c_indent.t * t/codingstd/c_parens.t * t/codingstd/c_struct.t * t/codingstd/cppcomments.t * t/codingstd/cuddled_else.t * t/codingstd/fixme.t * t/codingstd/perlcritic.t * t/codingstd/tabs.t * t/codingstd/trailing_space.t * t/distro/manifest_skip.t * t/perl/Parrot_Distribution.t * tools * tools/dev/gen_manifest_skip.pl ANALYSIS OF PACKAGES IN INHERITANCE TREE Parrot::Docs::Directory * inherits from: * Parrot::IO::Directory * uses: * Parrot::Docs::File There are no current calls to this package. It's only mentioned inside the currently unused file_class() subroutine. * used by: * packages: * Parrot::Distribution * Parrot::Docs::Item * Parrot::Docs::Section * tests: * t/perl/Parrot_Distribution.t * t/perl/Parrot_Docs.t * tools * tools/docs/pod_errors.pl * comments: * Has two apparently unused subroutines: file_class() and directory_class(). These are not methods, are not listed in any @EXPORT (there is none), and are not called elsewhere within the package. Why retain them? * Has no constructor of its own, so it must use Parrot::IO::Directory (or one of that package's ancestors). * Has only one method: files_of_type(), which takes one argument. This method calls methods from other packages, including: * files() * is_of_type() * directories() * name() * directories() * files_of_type() Parrot::Docs::File * inherits from: * Parrot::IO::File * uses: * Pod::Simple::Checker One fully qualified call to Pod::Simple::Checker::new inside check_pod(). * Parrot::Docs::POD2HTML One fully qualified call to Parrot::Docs::POD2HTML::new inside pod_as_html(). * methods: * type_for_suffix() * type_for_name() * type() * is_of_type() * check_pod() * contains_pod() * num_pod_errors() * pod_errors() * pod_as_html() * is_docs_link() * title() * short_description() * used by * packages: * Parrot::Docs::Directory * tests: * t/perl/Parrot_Docs.t Parrot::Docs::POD2HTML * inherits from: * Pod::Simple::HTML * uses: * Parrot::Docs::HTMLPage One fully qualified call to each of Parrot::Docs::HTMLPage::header and ::footer. * methods: * type_for_suffix() * type_for_name() * type() * is_of_type() * check_pod() * contains_pod() * num_pod_errors() * pod_errors() * pod_as_html() * is_docs_link() * title() * short_description() * used by: * packages: * Parrot::Docs::File * Parrot::Docs::HTMLPage * Parrot::Docs::Item * tests * t/perl/Parrot_Docs.t Parrot::Docs::HTMLPage * inherits from: Does not inherit -- but doesn't have its own constructor, either! * methods * header() * footer() * used by: * packages: * Parrot::Docs::POD2HTML * Parrot::Docs::Section * comment There is no current rationale for these functions to be methods. They could simply be functions exported by this package and imported by other packages on request. Parrot::IO::Directory * inherits from: * Parrot::IO::Path * uses: * Parrot::IO::File Imports_unspecified, but file_with_class calls Parrot::IO::File::new(). * methods: * directory_with_path() * file_with_path() * tmp_directory() * instance methods: * create_path() * relative_path() * parent() * file_and_directory_names() * file_and_directory_paths() * file_paths() * directory_paths() * file_exists_with_name()
[perl #41688] [PATCH]: tools for using Subversion branches; ops2c.pl refactored
I am pulling this patch from submission for the time being. When I originally submitted the refactored tools/build/ops2c.pl and lib/Parrot/Ops2c/Utils.pm over a week ago, they were passing their own tests as well as those in 'make test'. However, something outside these patches must have changed in that time, because when I went to perform 'make test' last night, I got this strange error: t/pmc/object-mro. # Failed test (t/pmc/object-mro.t at line 243) # got: 'Class Object already registered! # current instr.: 'main' pc 0 (/Users/jimk/work/bt/t/pmc/object-mro_5.pir:27) # ' # expected: 'Vulcan Intelligent Sentient Humanoid BiPedal LifeForm Object R # ' # './parrot -D40 --gc-debug /Users/jimk/work/bt/t/pmc/object-mro_5.pir' failed with exit code 1 # Looks like you failed 1 test of 6. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/6 tests, 83.33% okay Since I never made any changes in the vicinity of object-mro, this is going to take some time to debug. So, for now, I am withdrawing the patch.
[perl #41455] [NEW] and [PATCH]: tools/build/ops2pm.pl refactored
[Same note as in RT 41688] I am pulling this patch from submission for the time being. When I originally submitted the refactored tools/build/ops2c.pl and lib/Parrot/Ops2c/Utils.pm over a week ago, they were passing their own tests as well as those in 'make test'. However, something outside these patches must have changed in that time, because when I went to perform 'make test' last night, I got this strange error: t/pmc/object-mro. # Failed test (t/pmc/object-mro.t at line 243) # got: 'Class Object already registered! # current instr.: 'main' pc 0 (/Users/jimk/work/bt/t/pmc/object-mro_5.pir:27) # ' # expected: 'Vulcan Intelligent Sentient Humanoid BiPedal LifeForm Object R # ' # './parrot -D40 --gc-debug /Users/jimk/work/bt/t/pmc/object-mro_5.pir' failed with exit code 1 # Looks like you failed 1 test of 6. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/6 tests, 83.33% okay Since I never made any changes in the vicinity of object-mro, this is going to take some time to debug. So, for now, I am withdrawing the patch.
Weekly Perl 6 mailing list summary for 18-24 February, 2007
This week on the Perl 6 mailing lists 'Course, if someone goes ahead and adds the Y combinator, one must naturally begin to wonder what the YY combinator would be... :-) -- Larry Wall Obviously it generates a function so anonymous that it can't even refer to itself. I call it the depressed existentialist solipsist operator. -- chromatic, in 'Y not http://xrl.us/u23z' Language Y not http://xrl.us/u23z Larry Wall announced the demise of ` ?? `, which was not much lamented. Thomas Wittek suggested calling it `zip` and there was some discussion of whether it is better to use terms like `minmax` and `zip`, or to use symbols like `MM` and `ZZ`. Several jokes were made along the way. [svn:perl6-synopsis] r13699 - doc/trunk/design/syn http://xrl.us/u232 A commit by Larry Wall replaced ?? is replaced by Z. There was also a change with the `XX` operator, which became `X`. Relief for rw/ro http://xrl.us/u233 Steve Lukas remarked that Larry Wall had asked for ideas about good names for various states of write access. He offered a proposal which involves indicating that the writeability can be described as variable, constant, or final. Dr. Ruud added a brief comment about the length of the term `variable`, which he didn't find to be too long. [svn:perl6-synopsis] r13703 - doc/trunk/design/syn http://xrl.us/u238 A commit from Larry Wall clarified that a named argument may name either a label or a variable. Blair Sutton asked if the synopsis repository is publicly available, and if it is part of the Parrot or Pugs repository. The URL of the repository http://xrl.us/tz5p was posted. Parrot Porters [perl #29994] [BUG] loadlib $P0, varname not working correctly http://xrl.us/u239 Some time ago, in ticket [perl #29994] http://xrl.us/u6ue, Jens Rieks reported an error in `imcc/parser_util.c`. Klaas-Jan Stol updated the ticket and noted that the loadlib op works on windows. However, another error was found: when loading a non-existent library, no exception is raised. [perl #41235] [PATCH] Add get_name() Method to Namespaces http://xrl.us/u6hq Earlier, chromatic created a patch for `get_name`, which Jerry Gay forwarded to RT to create ticket [perl #41235] http://xrl.us/t9n7. Jerry wanted to apply the patch before 0.4.8, but chromatic said that he had been waiting because Allison Randal wanted a deprecation cycle for the rename of `name()` to `get_name()`. Allison replied that she had made a note that it was deprecated (r17030) and said that the patch could be applied after the release. [perl #41237] [TODO] PMC Class name IDs will require a dot in front http://xrl.us/ucnv Klaas-Jan Stol reminded people that an issue had not been decided. Earlier, Jerry Gay created ticket [perl #41237] http://xrl.us/t9n9 to address an item in DEPRECATED.pod about PMC Class name IDs. He felt that either it should use one syntax or the other, but not both. Allison Randal preferred eliminating the dot in classname IDs. Matt Diephouse, on the other hand, liked the dot. Klaas-Jan Stol added that the dot indicates that it is PIR not pure PASM. Allison thought that if Matt used it to disambiguate between types and local variables, it was a matter of sigils. She asked why put sigils on types instead of putting them in variables, and if a dot was the ideal sigil for types. [perl #41529] [BUG]: t/perl/Parrot_Distribution.t test failure http://xrl.us/u24c In ticket [perl #41529] http://xrl.us/u6uf, James Keenan reported that there was a new failure in `Parrot_Distribution.t`. Jerry Gay explained that the test exposes a bug in Parrot::Distribution, which classifies files as Perl even when they are not. He noted that failing tests had been used as a reminder of things which needed to be fixed, and this was still used to some extent, although there was a movement towards RT. The problem was resolved in r17069. There was some discussion about the difficulty of identifying the problem. Jerry Gay mentioned that he was working on refactoring Parrot::Distribution. in PIR, a BigInt is turning into a string against my will -- what am I doing wrong? http://xrl.us/u24d Eric Hanchrow reported a problem in r16999. Patrick R. Michaud offered some suggestions for correcting the code in question. [PATCH] #39615: [TODO] get_outer op not defined in PDDs http://xrl.us/u24e Klaas-Jan Stol submitted a patch which adds the description of `get_outer()` to PDD20. [PATCH] updates for docs/faq.pod http://xrl.us/u24f Klaas-Jan Stol made some updates to `faq.pod` which related to ticket [perl #41312] http://xrl.us/u2y6. :anon flag bug? http://xrl.us/u24g Klaas-Jan Stol had a question relating to a fix for [perl #39196] http://xrl.us/u6ug. An anonymous
[perl #41704] [BUG]: Test failures: t/pmc/object-mro.t t/pmc/timer.t
# New Ticket Created by James Keenan
# Please include the string: [perl #41704]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41704
This morning I encountered test failures when running 'make test' in
three scripts:
t/perl/Parrot_Distribution.t
t/pmc/object-mro.t
t/pmc/timer.t
1. The failure in Parrot_Distribution.t is for known reasons and
we're working on it. No further comment needed here.
2. Here's the output of prove -v t/pmc/object-mro.t:
[bt] 603 $ prove -v t/pmc/object-mro.t
t/pmc/object-mro1..6
ok 1 - print mro diamond
ok 2 - print mro 1
ok 3 - print mro 2
ok 4 - print mro 3
not ok 5 - print mro 4
# Failed test (t/pmc/object-mro.t at line 243)
# got: 'Class Object already registered!
# current instr.: 'main' pc 0 (/Users/jimk/work/bt/t/pmc/object-
mro_5.pir:27)
# '
# expected: 'Vulcan Intelligent Sentient Humanoid BiPedal
LifeForm Object R
# '
# './parrot /Users/jimk/work/bt/t/pmc/object-mro_5.pir' failed
with exit code 1
ok 6 - mro error 1
# Looks like you failed 1 test of 6.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 5
Failed 1/6 tests, 83.33% okay
I've experienced this failure repeatedly over the past two days. At
first I thought it was due to my patches to ops2c.pl, and I went so
far as to pull my patch submission this morning. However, I then did
a fresh checkout from trunk (i.e., I did *not* use my patches) and
configured Parrot and ran 'make' as usual.* 'make' succeeded, but I
once again got this failure in object-mro.t:
3. While running 'make test', I got this error in t/pmc/timer.t -- a
script that had always passed before.
t/pmc/timer..
# Failed test (t/pmc/timer.t at line 129)
# got: 'ok 1
# never
# ok 2
# '
# expected: 'ok 1
# ok 2
# '
# Looks like you failed 1 test of 8.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 4
Failed 1/8 tests, 87.50% okay
However, I was unable to reproduce the test failure when running it
through prove:
[bt] 603 $ prove -v t/pmc/timer.t
t/pmc/timer.1..8
ok 1 - Timer setup
ok 2 - Timer setup - initializer
ok 3 - Timer setup - initializer/start
ok 4 - Timer setup - initializer/start/stop
ok 5 - Timer setup - initializer/start/repeat
ok 6 - Timer setup - initializer/start/destroy
ok 7 - Timer setup - timer in array destroy
ok 8 - check whether interface is done
ok
*As usual means, as it has for several months, that in order to get
Parrot to 'make' on Darwin, I have to use the workaround suggested by
Coke (myconfigure.sh, attached), and that I have to use the next-to-
most-recent version of Configure.pl (attached) as reported on Jan 7
in http://rt.perl.org/rt3/Ticket/Display.html?id=41195
Can anyone shed any light, particularly on t/pmc/object-mro.t? Thank
you very much.
kid51
myconfigure.sh
Description: Binary data
:
myconfig
Description: Binary data
#! perl
# Copyright (C) 2001-2006, The Perl Foundation.
# $Id: Configure.pl 16702 2007-01-19 06:47:26Z allison $
=head1 NAME
Configure.pl - Parrot's Configuration Script
=head1 SYNOPSIS
% perl Configure.pl [options]
=head1 DESCRIPTION
This is Parrot's configuration program. It should be run to create
the necessary system-specific files before building Parrot.
=head2 Command-line Options
General Options
=over
=item C--help
Prints out a description of the options and exits.
=item C--version
Prints out the version number of Configure.pl and exits.
=item C--verbose
Tells Configure.pl to output extra information about the configuration data it
is setting.
=item C--verbose=2
Tells Configure.pl to output information about ievery setting added or
changed.
=item C--verbose-step={N|regex}
Run C--verbose=2 for step number CN or matching description.
=item C--nomanicheck
Tells Configure.pl not to run the MANIFEST check.
=item C--prefix
Sets the location where parrot will be installed.
=item C--step==
execute a single configure step
=item C--ask
This turns on the user prompts.
=back
Compile Options
=over
=item C--debugging=0
Debugging is turned on by default. Use this to disable it.
=item C--parrot_is_shared
Link parrot dynamically.
=item C--m=32
Create a 32-bit executable on 64-architectures like x86_64. This
option appends -m32 to compiler and linker programs and does
s/lib64/lib/g on link flags.
This option is experimental. See Fconfig/init/defaults.pm for more.
=item C--profile
Turn on profiled compile (gcc only for now)
=item C--cage
[CAGE] compile includes many additional warnings
=item C--optimize
Add perl5's $Config{optimize} to the compiler flags.
=item C--optimize=flags
Add Cflags to the compiler flags.
=item C--inline
Tell Configure that the compiler supports Cinline.
=item C--cc=(compiler)
Specify which compiler to use.
=item C--ccflags=(flags)
Use the given
resumable exceptions and LEAVE/KEEP/UNDO blocks
What happens if a resumable exception is propagated through a block with a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point. It strikes me that what we want it to do is not execute them when the exception is propagated, because we don't know whether it's going to be resumed or not. If the exception is resumed by its handler, then that's fine, as we can call the blocks at the usual time (when the blocks they are attached to exit). If the exception is caught and handled and not resumed, that would leave us with having to find all the LEAVE c. blocks and call them in the right order when the exception handler exits. In either case, it looks like you have a problem. LEAVE c. blocks will often be used for things like database transactions, where we want to ensure that some lock obtained on entering the block is released promptly regardless of how the control flow jumps about. In such a context, throwing a resumable exception that skips the LEAVE block, farts about doing some potentially long computation in a higher-up scope, and only calls the LEAVE block to release the lock at some later date, seems to be far from the best choice. Sure, we can warn programmers to make their resumable-exception handlers short, or to only throw non-resumable exceptions from blocks that are likely to be called in such circumstances. I suppose that would be an acceptable resolution, but it has an aura of non--re-entrant signal handlers about it, so it seems like the sort of thing I would like to avoid if anyone is clever enough to think of something else to do. BTW, if one is handling a resumable exception, how does one resume it? I couldn't find anything explaining how. Having a .resume method (or some cutesier name) on the Resumable role would seem to make sense. -- Customer Waiter, waiter! There's a fly in my soup! Waiter That's not a bug, it's a feature. http://surreal.istic.org/ The Answer of the Oracle Is Always Death. signature.asc Description: Digital signature
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Mar 5 14:00:02 2007 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 102 new + 397 open = 499 Created this week: 25 Closed this week: 11 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 41611 [TODO] Write a test for is_perl_exemption() 41610 [TODO] Work out why regexp in is_perl_exemption doesn't search subdirs 41603 [TODO] compilers/imcc/imcc.l different const qualifier 41600 [BUG] PMC docs are missing from parrotcode.org 41584 [TODO] Update RELEASE_INSTRUCTIONS with details for updating the website 41582 Parrot - 0.4.11 release 41581 Parrot - 0.4.10 release 41576 [BUG] t/pmc/pmethod_test.t fails on x86_64 41569 [BUG] t/distro/file_metadata.t fails on win32 41557 [BUG] addparent established heirarchies don't work with .Super 41548 [Tcl] - internals tests failings 2 - 3 weeks old 41528 Feature request, merge init and init_pmc 41505 [TODO] Cleanup and reorganise documentation related to svn properties 41500 [TODO] config - lib directory needs to be set appropriately for 32/64 bit archs 41499 [TODO] config - 32/64 bit architecture setting gcc specific 41497 [TODO] config - profiling options are specific to gcc in config/init/ defaults.pm 41496 [TODO] config - profiling options should have their own step in config/ init/defaults.pm 3 - 4 weeks old 4 - 5 weeks old 41388 Parrot::Distribution doesn't exclude all external perl modules 41374 test MMD with non-perl PMCs 41373 Need test for Clone of HLL info 5 - 6 weeks old 6 - 7 weeks old 41310 [CAGE] autogenerated PMC stubs kill compile 41286 [PDD] revisit properties 41280 [PDD] adding methods to subs as objects 7 - 8 weeks old 41265 [TODO] PGE: refactor pod_comment rule into PGE/Util.pbc 41264 [PDD] should properties get serialized? 41263 [PDD] should/can high-level classes be constructed at compile-time? 41257 [tru64] core dump in t/pmc/io_1.pir 41256 [tru64] NaNQ failures in t/pmc/complex 41255 [tru64] core dump from t/pmc/pmc_5.pasm 41254 [tru64] core dump from library/pg 41253 [tru64] core dump from t/dynoplibs/myops_3.pir 41251 [tru64] core dump from t/pmc/resizablebooleanarray_20.pasm 41249 [tru64] core dump in t/pmc/interp_3.pir 41242 Compile on Linux with Intel C++ and Sun Studio for Linux 41231 [TODO] exempt languages/ files from perlcritic testing 41226 [TODO] hunt through DEPRECATED.pod and find things to deprecate 41218 [BUG] warnings in imcc lexer code 8 - 9 weeks old 41201 [TODO] Remove temporary conf hack in Configure.pl 41168 graceful no compiler error message? 9 - 10 weeks old 10 - 11 weeks old 11 - 12 weeks old 41097 Segfault in malformed get_results 12 - 13 weeks old 13 - 14 weeks old 41035 [BUG] Parrot segfaults in perl6 08-regex.t (GC/pointer bug?) 14 - 15 weeks old 40990 [BUG] Parrot segfaults in perl6 08-regex.t (GC/pointer bug?) 40972 Iterator over Env under Win32 15 - 16 weeks old 40923 test errors 16 - 17 weeks old 40830 [PATCH] Man-Chicken's awesome hackathon throw-away patches... 40826 Mac OS X and Dylib Funcs 40822 Pg NCI Test Makes Unportable Connection 40804 -j fails: Stack alignment of x86 JIT on Mac 17 - 18 weeks old 18 - 19 weeks old 40599 [NEW] Coding standards test of return statements 19 - 20 weeks old 20 - 21 weeks old 40490 Flat/Slurpy Named Parameter Passing Errors --- Overview of Open Issues Platform Severity Tag Lang aix 0abandoned 05005threads 0 Amber0 All 2fatal 3bounce0 BASIC0 bsdos 0High 1Bug 50 bc 0 cygwin6low 1compiler 0 befunge 0 cygwin_nt 0medium0configure 0 bf 0 darwin0none 0core 0 cola 0 dec_osf 0Normal1dailybuild0 forth0 dgux 0unknown 0docs 0 jako 0 dos 0Wishlist 3duplicate 0 Lisp 0 dynixptx 0 install 1 m4 0 freebsd 1 library 0 ook 0 generic 0 notabug 0 perl60 gnu 0 notok 0 plot 0 HPUX 0 ok0 punie0 irix 0 Patch32 python 0 irix640
Re: for ... else
Larry Wall wrote:
On Mon, Mar 05, 2007 at 04:13:16PM +1030, Tom Lanyon wrote:
: Sounds like the following will work, but it doesn't seem 'nice'.
:
: for @invoice
: {
: .process;
: 1;
: } or fail 'No invoices to process';
Still think if there's no invoices it logically should be tested first.
If you don't want to repeat mentioning the array, how 'bout:
@invoice or fail 'No invoices to process'
== for @() {
.process
}
or equivalently
@invoice or fail 'No invoices to process'
== map {
.process
}
all assuming you don't like my original
for @invoice || fail 'No invoices to process'
{
.process
}
These should work, as long as you don't replace fail 'no invoices to
process' with something that returns a non-empty list.
That said, you could:
{
for = || fail 'no input'
{
.process
}
CATCH {
do_something_else if 'no input'
}
}
...where the 'no input' string is there only so that failures
generated by .process will propagate correctly.
--
This solution isn't generalizable beyond for, though: you wouldn't
be able to use it for while, until, or loop, all of which could
potentially follow the logic of do something special if the loop
fails to run even once. Hmm...
while test - $result {
do_something;
FIRST { do_something_else unless $result }
}
...except that I don't think that FIRST would run unless $result is true.
I suppose that you _could_ write:
if test {
repeat {
do_something
} while test
} else {
do_something_else
}
You'd be having to spell out the test twice, though.
--
Jonathan Dataweaver Lang
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
Defining _CRT_SECURE_NO_DEPRECATE on the compiler command line is probably the right solution here. Kevin Klaas-Jan Stol wrote: [EMAIL PROTECTED] via RT wrote: Hi, Applied in 17281, thanks. For your question, strdup is fine since these are not garbage collectable strings (STRING*), just normal C char*'s. There is loads of them used in IMCC. Unfortunately though, there is an issue in that we don't free a load of 'em, or at least hadn't used to and I doubt that's been fixed. So that may hurt us with eval'd code in the future... Jonathan hi, I still get the warning. On further inspection the file I added through the patch (win32/string.h) is not added. The #define of strdup as _strdup is in there. So, in order to resolve this issue, the file should be added. (it's included in the original patch) regards, kjs
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
On 3/5/07, Kevin Tew [EMAIL PROTECTED] wrote: Defining _CRT_SECURE_NO_DEPRECATE on the compiler command line is probably the right solution here. Kevin i disagree. the reason Cstrdup, Cstrnicmp and Cstricmp were deprecated is because they're non-ansi. therefore, microsoft renamed it to C_strdup. since we've pledged ansi (aka c89) c compliance, we should be following a similar path. instead of disabling the *valid* compiler warning, i suggest that either we modify our coding standard to allow Cstrdup, or we rename all usage to C_strdup and #define as appropriate for each compiler. ~jerry
[svn:perl6-synopsis] r14309 - doc/trunk/design/syn
Author: audreyt Date: Mon Mar 5 08:20:56 2007 New Revision: 14309 Modified: doc/trunk/design/syn/S05.pod Log: * S05: Minor fixup for this sentence no verb. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podMon Mar 5 08:20:56 2007 @@ -1698,7 +1698,7 @@ be possible to know when to fire off the assertions without backchecks.) Ordinary quantifiers and characters classes do not terminate a token pattern. -Zero-width assertions such as word boundaries also okay. +Zero-width assertions such as word boundaries are also okay. Oddly enough, the Ctoken keyword specifically does not determine the scope of a token, except insofar as a token pattern usually
[svn:perl6-synopsis] r14310 - doc/trunk/design/syn
Author: audreyt
Date: Mon Mar 5 08:27:24 2007
New Revision: 14310
Modified:
doc/trunk/design/syn/S12.pod
Log:
* S12: Clarify that VAR(1) and VAR(@foo) are simply no-ops;
i.e., it applies to thiings other than Scalars, too.
Also fixed the postfix macro name and nomenclature
around .VAR.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podMon Mar 5 08:27:24 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 27 Oct 2004
- Last Modified: 20 Feb 2007
+ Last Modified: 6 Mar 2007
Number: 12
- Version: 42
+ Version: 43
=head1 Overview
@@ -332,18 +332,23 @@
@keys = %hash.keys;
$sig = sub.signature;
-Use the CVAR pseudo-function on a scalar variable to get at its
+Use the prefix CVAR macro on a scalar variable to get at its
underlying CScalar object:
if VAR($scalar).readonly {...}
-There's also a corresponding postfix:VAR macro that can be used
+CVAR is a no-op on a non-scalar variables and values:
+
+VAR(1); # 1
+VAR(@x);# @x
+
+There's also a corresponding C postfix:.VAR macro that can be used
as if it were a method:
if $scalar.VAR.readonly {...}
(But since it's a macro, CVAR is not dispatched as a real method.
-To dispatch to a real C.VAR method use the indirect C$obj.VAR
+To dispatch to a real C.VAR method, use the indirect C$obj.VAR
form.)
You can also get at the container through the appropriate symbol table:
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
On 3/5/07, jerry gay [EMAIL PROTECTED] wrote: On 3/5/07, Kevin Tew [EMAIL PROTECTED] wrote: Defining _CRT_SECURE_NO_DEPRECATE on the compiler command line is probably the right solution here. Kevin i disagree. the reason Cstrdup, Cstrnicmp and Cstricmp were deprecated is because they're non-ansi. therefore, microsoft renamed it to C_strdup. since we've pledged ansi (aka c89) c compliance, we should be following a similar path. instead of disabling the *valid* compiler warning, i suggest that either we modify our coding standard to allow Cstrdup, or we rename all usage to C_strdup and #define as appropriate for each compiler. Moreover, strdup was not deprecated without a reason; strdup is claimed to be unsafe. It might be a good idea to accept this piece of advice, and use _strdup and friends. kjs
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
On Mon, Mar 05, 2007 at 05:48:57PM +0100, Klaas-Jan Stol wrote: On 3/5/07, jerry gay [EMAIL PROTECTED] wrote: instead of disabling the *valid* compiler warning, i suggest that either we modify our coding standard to allow Cstrdup, or we rename all usage to C_strdup and #define as appropriate for each compiler. Moreover, strdup was not deprecated without a reason; strdup is claimed to be unsafe. It might be a good idea to accept this piece of advice, and use _strdup and friends. I read that and though huh? A better answer seems to be further down in: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=6995SiteID=1 strdup(), stricmp(), and strnicmp() have also been deprecated, and I assumed it was also related to security, but it's not. They are deprecated simply because they are not part of the ANCI C or C++ standard, and as such should always have been prefixed by an underscore. This was a historical mistake that Microsoft has now rectified in VS 2005. IIRC ANSI have reserved every function name starting str, so this is correct. They've also reserved every type ending _t, but it seems that few pay attention to that either. Nicholas Clark
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
I believe that VS2005 Has a new snprintf_s, strcpy_s etc that are suppose to be secure See: http://msdn2.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=6995SiteID=1. Kevin Philip Taylor wrote: Klaas-Jan Stol wrote on 05/03/2007 16:48: On 3/5/07, jerry gay [EMAIL PROTECTED] wrote: i disagree. the reason Cstrdup, Cstrnicmp and Cstricmp were deprecated is because they're non-ansi. therefore, microsoft renamed it to C_strdup. since we've pledged ansi (aka c89) c compliance, we should be following a similar path. instead of disabling the *valid* compiler warning, i suggest that either we modify our coding standard to allow Cstrdup, or we rename all usage to C_strdup and #define as appropriate for each compiler. Moreover, strdup was not deprecated without a reason; strdup is claimed to be unsafe. It might be a good idea to accept this piece of advice, and use _strdup and friends. As far as I can see, MSVC doesn't claim strdup is unsafe - string.h just defines it with _CRT_NONSTDC_DEPRECATE, and the compiler warns The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. For the string functions which it does claim are unsafe (strcpy, strcat, etc), it warns This function or variable may be unsafe. Consider using strcpy_s instead and provides the _s alternatives; but strdup isn't one of those functions. A call to strdup is actually compiled into a call to _strdup (via linker tricks (I assume) in oldnames.lib), so there's no difference at all in implementation or safety.
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
On 3/5/07, Philip Taylor [EMAIL PROTECTED] wrote: For the string functions which it does claim are unsafe (strcpy, strcat, etc), it warns This function or variable may be unsafe. Consider using strcpy_s instead and provides the _s alternatives; but strdup isn't one of those functions. A call to strdup is actually compiled into a call to _strdup (via linker tricks (I assume) in oldnames.lib), so there's no difference at all in implementation or safety. strdup isn't unsafe. it just copies a string--no worries about buffer overflow. the ansi str* functions *are* likely unsafe, and should be converted to something safe for compilers which offer a safe alternative, like msvc. patches to redefine str* functions to the compiler-specific variant are most certainly welcome. ~jerry
Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup
Klaas-Jan Stol wrote on 05/03/2007 16:48: On 3/5/07, jerry gay [EMAIL PROTECTED] wrote: i disagree. the reason Cstrdup, Cstrnicmp and Cstricmp were deprecated is because they're non-ansi. therefore, microsoft renamed it to C_strdup. since we've pledged ansi (aka c89) c compliance, we should be following a similar path. instead of disabling the *valid* compiler warning, i suggest that either we modify our coding standard to allow Cstrdup, or we rename all usage to C_strdup and #define as appropriate for each compiler. Moreover, strdup was not deprecated without a reason; strdup is claimed to be unsafe. It might be a good idea to accept this piece of advice, and use _strdup and friends. As far as I can see, MSVC doesn't claim strdup is unsafe - string.h just defines it with _CRT_NONSTDC_DEPRECATE, and the compiler warns The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. For the string functions which it does claim are unsafe (strcpy, strcat, etc), it warns This function or variable may be unsafe. Consider using strcpy_s instead and provides the _s alternatives; but strdup isn't one of those functions. A call to strdup is actually compiled into a call to _strdup (via linker tricks (I assume) in oldnames.lib), so there's no difference at all in implementation or safety. -- Philip Taylor [EMAIL PROTECTED]
[svn:parrot-pdd] r17348 - trunk/docs/pdds/draft
Author: mdiep Date: Mon Mar 5 08:17:26 2007 New Revision: 17348 Modified: trunk/docs/pdds/draft/pdd15_objects.pod Log: [pdd15]: A few small fixes to the Object PDD Modified: trunk/docs/pdds/draft/pdd15_objects.pod == --- trunk/docs/pdds/draft/pdd15_objects.pod (original) +++ trunk/docs/pdds/draft/pdd15_objects.pod Mon Mar 5 08:17:26 2007 @@ -158,7 +158,7 @@ class for each OO class, and they all share the Class or Object vtable, respectively. -An instance of the Class PMC has six attributes, which are: +An instance of the Class PMC has ten attributes, which are: =over 4 @@ -191,12 +191,12 @@ =item 5 -An hash PMC of the methods defined in the class or composed into the +A hash PMC of the methods defined in the class or composed into the class =item 6 -An hash PMC of the overloaded PMC vtable entries for the class. +A hash PMC of the overloaded PMC vtable entries for the class. =item 7 @@ -384,7 +384,7 @@ =head2 Role PMC API -An instance of the Role PMC has four attributes, which are: +An instance of the Role PMC has five attributes, which are: =over 4
[perl #41707] [TODO] Tcl - relocate stub files
# New Ticket Created by Will Coleda # Please include the string: [perl #41707] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41707 (all paths relative to languages/tcl) First, do a make test in tcl to get a baseline as some tests are failing. The stub files in src/builtin/*.pir need to be relocated to runtime/builtin/*.pir; The stubs are: auto_execok,auto_load,exec,fconfigure,glob,interp,trace,update When moving, ok to do an svn del/add; be sure to update the MANIFEST. Update config/makefiles/root.in to remove reference to the old name. New file will be matched with a wilcard. Format of subs changes in runtime. Look at runtime/builtin/trace.pir for an example. If there's already a file of the same name in runtime, just delete the old one. Then reconfigure parrot, rebuild tcl, re make test, make sure nothing new is failing.
[svn:parrot-pdd] r17350 - trunk/docs/pdds/draft
Author: nicholas Date: Mon Mar 5 10:35:04 2007 New Revision: 17350 Modified: trunk/docs/pdds/draft/pdd15_objects.pod Log: A few spelling corrections. Modified: trunk/docs/pdds/draft/pdd15_objects.pod == --- trunk/docs/pdds/draft/pdd15_objects.pod (original) +++ trunk/docs/pdds/draft/pdd15_objects.pod Mon Mar 5 10:35:04 2007 @@ -22,7 +22,7 @@ =head2 Class -A class defines a pattern of characteristcs and behaviors from which +A class defines a pattern of characteristics and behaviors from which objects are constructed. =head2 Attribute @@ -34,7 +34,7 @@ will have the same set of attributes. Most OO languages don't allow attribute changes to existing classes, but Parrot's base attribute system does allow it. In order to safely support advanced dynamic -features in HLLs, attributes are not accesible via fixed attribute +features in HLLs, attributes are not accessible via fixed attribute offsets, but only via named lookup. =head2 Method @@ -230,7 +230,7 @@ class. When instantiating an object, the object data store is created as a ResizablePMCArray, so doesn't need any specific details of the class's attribute structure. As attributes are set in the object (based on the -index in the lookup table), the Array expands to accomodate the +index in the lookup table), the Array expands to accommodate the attribute indexes that are actually used. In the common case, a relatively small set near the lower index range is all that will be used. @@ -313,7 +313,7 @@ objects still point to the old class and do their method resolution and attribute lookup through that class. If a class hasn't been instantiated, adding a method doesn't create a new class. If it has been -instantiated, it creates a new class the first time its extended, +instantiated, it creates a new class the first time it's extended, and then doesn't create a new class until it is instantiated again.) The class registry needs to have names removed entirely (it doesn't care about names anymore). Low-level PMC types also need entries in the @@ -365,7 +365,7 @@ sections below on LObjects and LVtables. [stream-of-consciousness again] -In addition to a value type, objects can have a containter type. The +In addition to a value type, objects can have a container type. The container type can't be stored in the object itself, because a single object may live within multiple containers. So, the container type (when it exists) is stored in the LexPad or Namespace entry for a particular @@ -680,7 +680,7 @@ =head1 Explanations To get a new class, you can do a Cnewclass, which creates a new class with no -parents besides parrot's default super-ish parent class. +parents besides Parrot's default super-ish parent class. To get a new child class, you have two potential options: @@ -703,7 +703,7 @@ Classes may override the vtable methods, allowing objects of a class to behave like a primitive PMC. Each vtable slot has a corresponding named method that -parrot looks for in your class hierarchy when an object is used in a primitive +Parrot looks for in your class hierarchy when an object is used in a primitive context. To use these properly at a low-level requires a good working knowledge of the @@ -716,7 +716,7 @@ methods are called by the interpreter--once a vtable method is exited any continuation taken within it is no longer valid and may not be used. -Note that any class method that wishes to use parrot's multi-method dispatch +Note that any class method that wishes to use Parrot's multi-method dispatch system may do so. This is, in fact, encouraged, though it is not required. In the absence of explicit multimethod dispatch, a left-side wins scheme is used. @@ -1116,7 +1116,7 @@ =head2 Objectspace -Ruby: Objectspace in ruby allows the programmer to iterate through every live object +Ruby: Objectspace in Ruby allows the programmer to iterate through every live object in the system. There is some debate about how to make this play nice with different garbage collection schemes. @@ -1177,7 +1177,7 @@ .Net: Single inheritance. -Ruby: Single inheritance but support for mixins of ruby modules. +Ruby: Single inheritance but support for mixins of Ruby modules. =head2 Interfaces @@ -1258,7 +1258,7 @@ =head2 Translation The following list a set of languages, then within each language what the -parrot term translates to. +Parrot term translates to. =over 4 @@ -1268,7 +1268,7 @@ =item Attribute -A Python attribute maps to a parrot property +A Python attribute maps to a Parrot property =back @@ -1278,7 +1278,7 @@ =item Attribute -What .NET calls an attribute parrot calls a property +What .NET calls an attribute Parrot calls a property =item Property
Coercion of non-numerics to numbers
I was wondering about the semantics of coercion of non-numbers, so I
experimented with the interactive Pugs on feather:
pugs +42
42.0
pugs +x42
0.0
I assume that pugs is assuming no fail in the interactive environment.
However, Is 0.0 the correct answer, or should it be one of undef, or
NaN?
In my experiments, I also noticed:
pugs my Int $a = 42
42
pugs $a.WHAT
::Str
It seems that the explicit type of $a is being ignored in the
assignment. Am I right to assume this is simply a bug?
testcase (if someone with commit bits can add it):
{
no fail;
my Int $a = not numeric;
is $a.WHAT, ::Int, coercion in initial assignment;
}
Re: resumable exceptions and LEAVE/KEEP/UNDO blocks
On Mon, Mar 05, 2007 at 01:06:46PM +, Daniel Hulme wrote: : What happens if a resumable exception is propagated through a block with : a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point. : It strikes me that what we want it to do is not execute them when the : exception is propagated, because we don't know whether it's going to be : resumed or not. If the exception is resumed by its handler, then that's : fine, as we can call the blocks at the usual time (when the blocks they : are attached to exit). If the exception is caught and handled and not : resumed, that would leave us with having to find all the LEAVE c. : blocks and call them in the right order when the exception handler : exits. : : In either case, it looks like you have a problem. LEAVE c. blocks will : often be used for things like database transactions, where we want to : ensure that some lock obtained on entering the block is released : promptly regardless of how the control flow jumps about. In such a : context, throwing a resumable exception that skips the LEAVE block, : farts about doing some potentially long computation in a higher-up : scope, and only calls the LEAVE block to release the lock at some later : date, seems to be far from the best choice. Sure, we can warn : programmers to make their resumable-exception handlers short, or to only : throw non-resumable exceptions from blocks that are likely to be called : in such circumstances. I suppose that would be an acceptable resolution, : but it has an aura of non--re-entrant signal handlers about it, so it : seems like the sort of thing I would like to avoid if anyone is clever : enough to think of something else to do. I don't see a problem here. I think you maybe missed the bit that says: A CCATCH block sees the lexical scope in which it was defined, but its caller is 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. Exiting blocks are not run until the decision is made to unwind the stack, which is *after* the exception handlers are run. So all the exception trampoline has to do to resume is just return; the resume continuation doesn't really have to be a real continuation in this case. : BTW, if one is handling a resumable exception, how does one resume it? I : couldn't find anything explaining how. Having a .resume method (or some : cutesier name) on the Resumable role would seem to make sense. To resume a resumable exception the correct thing to do is very likely nothing. The outermost warning handler is what generally resumes otherwise uncaught resumables. If you catch a warning, it defaults to resuming when handled unless you rethrow it as fatal. Larry
Re: resumable exceptions and LEAVE/KEEP/UNDO blocks
On Mon, Mar 05, 2007 at 09:01:13AM -0800, Larry Wall wrote: I don't see a problem here. I think you maybe missed the bit that says: A CCATCH block sees the lexical scope in which it was defined, but its caller is 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. Yes, I did. I was grepping specifically for the bit on resumable exceptions and the quoted bit is 80 lines up so I missed it completely. Thanks for pointing me at it. [...] To resume a resumable exception the correct thing to do is very likely nothing. The outermost warning handler is what generally resumes otherwise uncaught resumables. If you catch a warning, it defaults to resuming when handled unless you rethrow it as fatal. OK, that makes sense. The reason that came up was because on Friday I had a good idea for a language feature that would have made a task I had been doing that day much easier. When I checked the spec, though, I found out it was already in. This is happening increasingly often, which should be reassuring to all concerned. -- Listen to your users, but ignore what they say. - Nathaniel Borenstein http://surreal.istic.org/ Calm down, it's only ones and zeroes. signature.asc Description: Digital signature
Re: [svn:parrot] r17356 - trunk
FYI: On Mar 5, 2007, at 7:14 PM, [EMAIL PROTECTED] wrote: -- Mar 20th, Matt Diephouse (mdiep) -- Apr 17th, Will Coleda (coke) +- Mar 20th, Will Coleda (coke) +- Apr 17th, Matt Diephouse (mdiep) -- Will Coke Coleda [EMAIL PROTECTED]
[svn:perl6-synopsis] r14311 - doc/trunk/design/syn
Author: larry Date: Mon Mar 5 19:01:16 2007 New Revision: 14311 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S03.pod doc/trunk/design/syn/S06.pod Log: the change back from .give to .leave was incomplete as noted by rhr++. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Mar 5 19:01:16 2007 @@ -2469,7 +2469,7 @@ would work just as well. You can exit any labeled block early by saying -MyLabel.give(@results); +MyLabel.leave(@results); =item * Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podMon Mar 5 19:01:16 2007 @@ -2025,7 +2025,7 @@ If a C* (see the Whatever type in S02) occurs on the right side of a range, it is taken to mean positive infinity in whatever space the range is operating. A C* on the left means negative infinity -for types that support negative values. (The sign of those infinites +for types that support negative values. (The sign of those infinities reverses for a negative step.) If the C* occurs on one side but not the other, the type is inferred from the other argument. A star on both sides will match any value that supports the COrdered role. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podMon Mar 5 19:01:16 2007 @@ -1629,7 +1629,7 @@ blocks this can be optimized away to a goto. All CRoutine declarations have an explicit declarator such as Csub or Cmethod; bare blocks and pointy blocks are never considered to be routines in that sense. To return -from a block, use Cgive instead--see below. +from a block, use Cleave instead--see below. The Creturn function preserves its argument list as a CCapture object, and responds to the left-hand CSignature in a binding. This allows named return @@ -1775,10 +1775,10 @@ COUNT.leave; last COUNT; -However, the first form explicitly gives the return value for the +However, the first form explicitly sets the return value for the entire loop, while the second implicitly returns all the previous successful loop iteration values as a list comprehension. (It may, -in fact, be too late to give a return value for the loop if it is +in fact, be too late to set a return value for the loop if it is being evaluated lazily!) A Cleave from the inner loop block, however, merely specifies the return value for that iteration:
Re: [S09] Whatever indices and shaped arrays
On 2/27/07, Jonathan Lang wrote:
David Green wrote:
So I end up back at one of Larry's older ideas, which basically is:
[] for counting, {} for keys.
What if you want to mix the two? I want the third element of row
5. In my proposal, that would be @array[5, *[2]]; in your
proposal, there does not appear to be a way to do it.
Unless the two approaches aren't mutually exclusive: @array{5,
*[2]}. [...] Since this is an unlikely situation, the fact that
nesting square braces inside curly braces is a bit uncomfortable
isn't a problem: this is a case of making hard things possible, not
making easy things easy.
Oh, good point. Yes, I think that mixing them together that way makes sense.
It also suggests that you could get at the named keys by applying {} to *:
%foo[0, 1, *{'bar'}]; #first column, second row, bar layer
The one gotcha that I see here is with the possibility of
multi-dimensional arrays. In particular, should multi-dimensional
indices be allowed inside square braces? [...] With that promise,
you can always guarantee that the wrap-around semantics will work
inside [], while nobody will expect them to work inside {}.
Right, I don't see a problem with handling any number of dimensions that way.
Furthermore, you could do away with the notion of shaped vs.
unshaped: just give everything a default shape. The default shape
for arrays would be '[*]' - that is, one dimension with an
indeterminate number of ordinals.
Meanwhile, shapes for {} would continue to use the current syntax.
'[$x, $y, $z]' would be nearly equivalent to '{0..^$x; 0..^$y; 0..^$z}'.
Agreed.
it can work in the usual way: start at 0, end at -1. It is useful
to be able to count past the ends of an array, and * can do this by
going beyond the end: *+1, *+2, etc., or before the beginning: *-1,
*-2, etc. (This neatly preserves the notion of * as all the
elements -- *-1 is the position before everything, and *+1 is the
position after everything else.)
Regardless, I would prefer this notion to the offset from the
endpoint notion currently in use. Note, however, that [*-1]
wouldn't work in the ordinals paradigm; there simply is nothing
before the first element. About the only use I could see for it
would be to provide an assignment equivalent of unshift:
'@array[*-1] = $x' could be equivalent to 'unshift @array, $x'. But
note that, unlike the 'push'-type assignments, this would change
what existing ordinals point to.
I figured that *-1 or *+1 would work like unshift/push, which
effectively does change what the ordinals point to (e.g. unshifting
a P5 array). If the array is not extensible, then it should fail in
the same way as unshift/push would.
Meanwhile, {*-1} would only make sense in cases where keys are
ordered and new keys can be auto-generated. Note also that {*+$x}
is compatible with {*[$x]}: the former would reference outside of
the known set of keys, while {*[$x]} would reference within them.
Exactly.
-David
[perl #41707] [TODO] Tcl - relocate stub files
Hiya, On Mon Mar 05 10:32:33 2007, coke wrote: (all paths relative to languages/tcl) First, do a make test in tcl to get a baseline as some tests are failing. languages/tcl$ make test | tee /tmp/OUTPUT The stub files in src/builtin/*.pir need to be relocated to runtime/builtin/*.pir; The stubs are: auto_execok,auto_load,exec,fconfigure,glob,interp,trace,update When moving, ok to do an svn del/add; be sure to update the MANIFEST. Moved files and updated MANIFEST, still missing some propset on the new files. Update config/makefiles/root.in to remove reference to the old name. New file will be matched with a wilcard. Updated. Format of subs changes in runtime. Look at runtime/builtin/trace.pir for an example. Subs where updated. If there's already a file of the same name in runtime, just delete the old one. The only one that already existed was trace.pir -- overwritten. Then reconfigure parrot, rebuild tcl, re make test, make sure nothing new is failing. After reconfigure parrot and rebuild tcl: languages/tcl$ make test | tee /tmp/OUTPUT2 $ diff /tmp/OUTPUT /tmp/OUTPUT2 90c90 Files=73, Tests=1332, 874 wallclock secs (792.16 cusr + 16.80 csys = 808.96 CPU) --- Files=73, Tests=1332, 938 wallclock secs (795.61 cusr + 16.98 csys = 812.59 CPU) Same behaviour, only time changed. The changes were commited on revision 17353, MANIFEST update was commited on revision 17354. Best regards, ./smash
Re: Coercion of non-numerics to numbers
On Mon, Mar 05, 2007 at 09:22:59AM -0800, Dave Whipp wrote: : I was wondering about the semantics of coercion of non-numbers, so I : experimented with the interactive Pugs on feather: : : pugs +42 : 42.0 : pugs +x42 : 0.0 : : I assume that pugs is assuming no fail in the interactive environment. : However, Is 0.0 the correct answer, or should it be one of undef, or : NaN? It should probably warn by default since warnings are supposed to be on by default in Perl 6, but if that is supressed the return value should at least be an interesting value of undef containing the warning that would have been emitted, so that the warning can be issued later if the value is actually used. : In my experiments, I also noticed: : : pugs my Int $a = 42 : 42 : pugs $a.WHAT : ::Str : : : It seems that the explicit type of $a is being ignored in the : assignment. Am I right to assume this is simply a bug? Well, it's just not implemented, I think. Or more accurately, still in the process of being implemented, since the pugsers are madly working on metaobjects this week. : testcase (if someone with commit bits can add it): I'm sending you a commit bit so you can add tests. It's traditional to add yourself to AUTHORS as the first checkin to make sure things work. Larry
