[perl #42267] [CAGE] Work out how to encourage good editor-independent formatting habits
# New Ticket Created by Paul Cochrane # Please include the string: [perl #42267] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=42267 > Figure out how to encourage good formatting habits, without assuming that everyone uses emacs or vim, and with minimal clutter in our source code. Also write a coding standards test to codify this. Paul
[perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
On Tue Dec 19 16:30:34 2006, [EMAIL PROTECTED] wrote: > Nicholas Clark wrote: > > > > To seek clarification - having those as global settings for cperl isn't > > likely to be an issue? Or having them in editor blocks? > > I meant globally. > > It's really not a big deal, though. For the immediate problem, let's > just make an exception and leave the hints out of Perl files with > __END__ or __DATA__ blocks. Added a note about this in pdd07. > Mark it as a cage cleaner task for some point down the road: figure out > how to encourage good formatting habits, without assuming that everyone > uses emacs or vim, and with minimal clutter in our source code. A CAGE ticket has been generated in RT for this. Is it ok to close the current ticket now? Paul
[perl #39934] [PATCH] Make disassemble useful.
On Mon Jul 24 19:10:59 2006, tewk wrote: > I've been wanting this little enhancement for quite some time. > I finally coded it up. > Suggestions welcome. > > Kevin > > The patch updates disassemble output to contain three useful pieces of > information. > > FROM > > load_bytecode_sc "TGE.pbc" > find_type_i_sc I0,"ASTGrammar" > ne_i_ic_ic I0,0,L1 > subclass_p_sc_sc P0,"TGE::Grammar","ASTGrammar" > L1: set_returns_pc PMC_CONST(5) > returncc > get_params_pc PMC_CONST(14) > debug_init > defined_i_p_kc I0,P1[?] > unless_i_ic I0,L2 > set_p_p_kc P1,P1[?] > set_args_pc PMC_CONST(19) > get_results_pc PMC_CONST(17) > callmethodcc_p_sc P3,"get" > set_returns_pc PMC_CONST(17) > returncc > L2: print_sc "The top-level node d" > end > get_params_pc PMC_CONST(14) > defined_i_p_kc I0,P1[?] > unless_i_ic I0,L3 > set_p_p_kc P1,P1[?] > set_args_pc PMC_CONST(19) > get_results_pc PMC_CONST(17) > callmethodcc_p_sc P3,"get" > set_returns_pc PMC_CONST(17) > returncc > L3: print_sc "The compound_stateme" > end > > TO > > Seq_Op_Num- Relative-PC SrcLn#: > Current Source Filename src/ASTGrammar_gen.pir > - 25: load_bytecode_sc "TGE.pbc" > 0001-0002 26: find_type_i_sc I0,"ASTGrammar" > 0002-0005 26: ne_i_ic_ic I0,0,L1 > 0003-0009 28: subclass_p_sc_sc > P0,"TGE::Grammar","ASTGrammar" > 0004-0013 29: L1: set_returns_pc > PMC_CONST(5) > 0005-0015 29: returncc > Current Source Filename src/ASTGrammar_gen.pir > 0006-0016 34: get_params_pc PMC_CONST(14) > 0007-0021 38: debug_init > 0008-0022 42: defined_i_p_kc I0,P1[?] > 0009-0026 42: unless_i_ic I0,L2 > 0010-0029 43: set_p_p_kc P1,P1[?] > 0011-0033 45: set_args_pc PMC_CONST(19) > 0012-0039 45: get_results_pc PMC_CONST(17) > 0013-0042 45: callmethodcc_p_sc P3,"get" > 0014-0045 47: set_returns_pc PMC_CONST(17) > 0015-0048 47: returncc > 0016-0049 50: L2: print_sc "The top- > level > node d" > 0017-0051 51: end > Current Source Filename src/ASTGrammar_gen.pir > 0018-0052 56: get_params_pc PMC_CONST(14) > 0019-0057 62: defined_i_p_kc I0,P1[?] > 0020-0061 62: unless_i_ic I0,L3 > 0021-0064 63: set_p_p_kc P1,P1[?] > 0022-0068 65: set_args_pc PMC_CONST(19) > 0023-0074 65: get_results_pc PMC_CONST(17) > 0024-0077 65: callmethodcc_p_sc P3,"get" > 0025-0080 67: set_returns_pc PMC_CONST(17) > 0026-0083 67: returncc > 0027-0084 70: L3: print_sc "The > compound_stateme" > 0028-0086 71: end > > > > Seq_Op_Num this is a sequential op number for each operation in the > code segment. > (The debug segment indexes both debug mappings and line numbers based > on > this incrementing counter) > Relative-PC this is the op_code_t offset of the operation in the code > segement. > SrcLn# is the line number of the pir source code. (in this case > src/AST_Grammar_gen.pir) > > When chasing PIR bugs and parrot segfauts. Run parrot in gdb. > cat > .rit_gdb_cmds < set args cardinal.pbc t/00_if_unless_5.rb > run > set print pretty > EOF > > gdb -x .rit_gdb_cmds ../../parrot > > Find the runops_slow_core activation frame closes to the top of the > stack and execute these commands in gdb > (gdb) p interpreter->code->base.name > $48 = 0x82c23c8 "BYTECODE_src/ASTGrammar_gen.pir" > > Tells you the source file where parrot most likely core dumped > > (gdb) p pc - interpreter->code->base.data > $43 = 1022 > > 1022 in this case is the Relative-PC in the src/ASTGrammar.pbc file. > > (gdb) p interpreter->code->base.name > $48 = 0x82c23c8 "BYTECODE_src/ASTGrammar_gen.pir" > > Given BYTECODE_src/ASTGrammar_gen.pir: > run disassemble on src/ASTGrammar.pbc > > make disassemble > ./disassemble languages/cardinal/src/ASTGrammar.pbc |less > > And puff, smoke, magic: > > I found out I was core dumping on line #459 of src/ASTGrammar_gen.pir Thanks! Applied as r17922. Note that 'interpreter' had to be changed to 'interp' to get this to compile. This name change hadn't occurred when you submitted the patch (so was not a problem with the patch), but I thought it best to note it in the ticket. Paul
[svn:parrot-pdd] r17921 - trunk/docs/pdds
Author: paultcochrane Date: Sun Apr 1 00:58:42 2007 New Revision: 17921 Modified: trunk/docs/pdds/pdd07_codingstd.pod Log: [docs] Added a note about Perl source code with __END__ or __DATA__ blocks not requiring an emacs/vim coda. Modified: trunk/docs/pdds/pdd07_codingstd.pod == --- trunk/docs/pdds/pdd07_codingstd.pod (original) +++ trunk/docs/pdds/pdd07_codingstd.pod Sun Apr 1 00:58:42 2007 @@ -322,6 +322,10 @@ # End: # vim: expandtab shiftwidth=4: +B: Files with C<__END__> or C<__DATA__> blocks do not require the +coda. This is at least until there is some consensus as to how solve the +issue of using editor hints in files with such blocks. + =item * PIR source files should end with this coda:
[perl #39878] [CAGE] generated files with timezoneless times
On Wed Jul 19 09:17:26 2006, coke wrote: > # $Id: MANIFEST 13384 2006-07-19 15:42:23Z tewk $ > # > # generated by tools/dev/mk_manifest_and_skip.pl Wed Jul 19 09:38:21 > 2006 > > Any tools that insert messages like this in generated files should > include a timezone, even if it's GMT/UTC. In fact, perhaps it should > explicitly always be that. Generated files are checked for timestamps which use GMT/UTC in t/ codingstd/gmt_utc.t. config/init/defaults.pm was updated in r17923 to generate a GMT timestamp and now the gmt_utc.t test passes. Closing the ticket. Paul
[perl #40861] [CAGE] - add a Perl::Critic policy to look for FIXME|TODO|XXX
On Mon Nov 13 06:31:40 2006, ptc wrote: > The t/codingstd/fixme.t test only looks in C-language files for > FIXME|TODO|XXX comments. It would therefore be good for the > t/codingstd/perlcritic.t test to check for these comments in the Perl > source files. Added a check for the Perl::Critic::Bangs module into t/codingstd/ perlcritic.t and if it is installed, the Bangs::ProhibitFlagComments policy is added to the list of policies. This change was made in r17925. All FIXME|TODO|XXX comments which have been added to RT should be replaced with RT#. Paul
Link'n'Load on Windows
Hi, I currently looking at some issues on Windows. 1) Linking There are a few symbols not exported which cause link errors in tests. I'll provide a patch to export them. 2) Loading On Windows it's usually best to put the applications and libraries in the same directory, but libparrot is mostly built in blib/lib. There's a hack for MSWin32, though: Makefile #CONDITIONED_LINE(win32):LIBPARROT_SHARED = @libparrot_shared@ #INVERSE_CONDITIONED_LINE(win32):LIBPARROT_SHARED = @blib_dir@/@libparrot_shared@ I'd like to change libparrot_shared and libparrot_static to include the full path, i.e. include build_dir, and simplify above in the Makefile. Actually, I got confused by the difference of libparrot_shared (Configure) and LIBPARROT_SHARED (Makefile). For Windows (native and Cygwin) I'd like to build the libraries near F, for everyone else it stays in blib/lib. Would these changes be ok? Ron
Current State of Building Parrot on Cygwin
Hi, As recently discussed it is currently necessary to include the absolute path to F in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken F and F. One needs a "make clean" or remove *both* files before trying again. Make sure to "export" the PATH changes, not just only "set" them, and use the absolute path, not the relative (otherwise building some libs will fail later on.) If you see this error > make runtime/parrot/library/Crow.pbc ./parrot.exe -o runtime/parrot/library/Crow.pbc runtime/parrot/library/Crow.pir error:imcc:syntax error, unexpected $end in file 'runtime/parrot/library/Crow.pir' line 146 make: *** [runtime/parrot/library/Crow.pbc] Error 1 the file has Windows line endings, usually because checked out with Windows' Subversion. Get the Cygwin version and a clean checkout. Ron
Re: Syntax for Constructing new Objects (and classes?)
Allison Randal wrote:
Klaas-Jan Stol wrote:
Hello,
I have a short and simple question w.r.t. syntax for constructing new
objects for the architect :-)
Currently, it's done through:
new P0, .Integer
or in PIR:
$P0 = new Integer # or .Integer
I thought to have read somewhere this will be changed into something
like this:
$P0 = Integer.new()
The two candidates currently are:
$P0 = get_class "HLLClass"
$P1 = $P0.new()
Or:
$P0 = get_hll_namespace
$P1 = $P0.find_class("HLLClass")
$P2 = $P1.new()
IIUC, instead of create a new object (either a built-in PMC or an OO
object) in 1 instruction, it should now be done in 2?
Or, can I also write:
$P0 = Integer.new() # create new Integer PMC object
$P1 = Hash.new()# create new Hash PMC object
kjs
Re: Current State of Building Parrot on Cygwin
> "Ron" == Ron Blaschke <[EMAIL PROTECTED]> writes: Ron> If you see this error ... Ron> the file has Windows line endings Dare I suggest that parrot not be so fussy about line endings? -- If you're trying to choose between two theories and one gives you an excuse for being lazy, the other one is probably right. -- Paul Graham
Re: IRC discussion of smoking and branching
Hello, The discussion on smoking and branching is driven by the need to maintain quality across a wide range of compilers and "target"(1) machines. I would add a couple of points. 0. When working through the review process the tool I wanted the most was a simple way to test cross-platform/compiler after I had passed the test-suite on my machine. I have both a Linux and a Darwin platform but that is a fraction of the list. Waiting for some other kind soul to test things out for you on other platforms was slow, and would have been impossible without the usual suspects in #parrot . Could patches in a very specific format be mailed to a build farm, where compile tests/smoke tests would run against the HEAD + patches in the mail ? The reply could contain the test results , and even some sort of "stamp", if it passed, that I could attach to the RT. With the build/smoke farm merit badge the reviewer of the changes can look at the "meat" of the changes without robotic and mind-numbing repetition of the test-suite. The time could be spent better considering the merits of the changes. 1. branching and merging in SVN is very primitive. tracking the last common ancestor must be done in the changelogs, failure to do so is a disaster. * This is an existing merge tool that matches up with the parallel development requirements: http://www.orcaware.com/svn/wiki/Svnmerge.py * This seems to be the official subversion page on merge-tracking http://subversion.tigris.org/merge-tracking/ * cherry picking never seems to work quite as well as you would want. The weak link is diff/patch. Unless the patches are extremely fine-grained you many times end up hand-editing hunks or doing post patch merges. I have tried subversion,git, hand-editing hunks (diff mode), and ediff. Only the last patch in a sequence of dependant changes can be modified without causing a tidal wave (good analogy http://en.wikipedia.org/wiki/Tsunami) of rejects. The end result is changes are not broken up, merger falls back on pass/reject. Are you ready for cherry picking ? 1. Is every whitespace cleanup, bug fix, refactor, and feature change a separate commit ? 2. Are your feature changes layered in even more separate commits ? each one compile/test-suite checked ? A. Why not wait until SVN has proper support for merging ? B. definitely need a tool of some sort to ensure the last common ancestor information is not mistakenly dropped. C. If there is a branch that is forked why not make it the stable branch ? The HEAD assuming the parrot project is flying along like we would all want it to is going to/does have heavy commit traffic on it. The number of changes you want in the stable is low. Put the expensive review checking on the merge "from head" -> "to stable", so the work-set can be reduced by a quick scan of the changelog to cherry pick which things could even be considered canidates. my 2 cents on the branching issue. I have been developing for myself tools to enhance svn for cherry picking, branching etc. I have working code; but that project is on the back-burner since diff/patch is the real problem, cherry picking/merging are the symptoms. All RCS systems use the patch/diff hunk as the fundamental change mechanism. There is just to much information dropped in a diff to handle conflicts cleanly, or rather the wrong kind of information to resolve conflicts in source code as well as it could. With that said I think the build/smoke farm would give developers a tool to widely test their changes, without expecting them to have a room full of computers. The branching model could be used, but it must be used in a way that is not going to push the current tools beyond their working use-cases, if that happens it will take alot of manual labor to compensate. Cheers, Mike Mattie (1) Autoconf lingo for the machine the program runs on. signature.asc Description: PGP signature
Re: [svn:parrot-pdd] r17915 - trunk/docs/pdds/draft
Hi,
Nice changes! And...
[EMAIL PROTECTED] wrote:
The interaction between objects and PMCs is currently underspecified.
+{{ Question: Does anyone remember what this note was about? Was it the
+problem of high-level objects that inherit from low-level PMC objects?
+}}
Yes, that's what it was about, I believe.
Jonathan
[perl #42261] Extensive failures in t/compilers/imcc/imcpasm/*.t and t/pmc/sub.t
This is weird. I renamed the sandbox directory in which I was experiencing failures from 'options/' to 'latest/'. All the t/compilers/* tests passed. And the failing test in t/pmc/sub.t has bee TODO-ed. Can anyone suggest why the name of one's sandbox directory should affect the test results?
[perl #42270] [PATCH]: Configure.pl: refactor options processing functionality
# New Ticket Created by James Keenan
# Please include the string: [perl #42270]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42270 >
This patch transfers one aspect of Configure.pl's functionality --
its command-line options-processing -- out of that script and places
it in a new package: lib/Parrot/Configure/Options.pm.
Parrot::Configure::Options exports two subroutines on demand:
process_options()
get_valid_options().
By placing this functionality in subroutines exported by a class, we
can write tests for it using Perl's standard testing apparatus.
Accordingly, a test file is supplied as part of this patch:
t/configure/01-options.t
A number of Parrot hackers and I will be submitting a series of
patches which refactor Configure.pl and the various
Parrot::Configure::* classes. This is the first of that series.
This refactoring will be focused primarily on increasing the
testability -- and, by extension, the long-term maintainability -- of
Parrot's configuration code.
Assuming that our refactoring is correct, the end result of the
configuration process should not change in the least. (To confirm,
do a 'diff' on lib/Parrot/Config/Generated.pm versus an unpatched
version.) However, if in the future you are proposing revisions to
functionality originally found in Configure.pl (e.g., adding a new
command-line option), you may have to look in a new place to make
such a revision.
Coke and chromatic have recommended that I submit patches one element
at a time, the better to review and digest them. So what I would
like to do is submit this patch, allow about three days for review,
apply the patch to trunk if no one objects, then submit the next
patch. Each patch will entail a revision to Configure.pl, a new
class and/or revisions to a Parrot::Configure::* class, and one or
more test files.
Note: If you are applying this patch locally, then running 'make
test', you will have to locally set SVN properties to pass t/distro/
file_metadata.t :
Setting SVN properties on: t/configure/01-options.t
property 'svn:eol-style' set on 't/configure/01-options.t'
property 'svn:keywords' set on 't/configure/01-options.t'
property 'svn:mime-type' set on 't/configure/01-options.t'
Setting SVN properties on: lib/Parrot/Configure/Options.pm
property 'svn:eol-style' set on 'lib/Parrot/Configure/Options.pm'
property 'svn:keywords' set on 'lib/Parrot/Configure/Options.pm'
Thank you very much.
kid51
Index: lib/Parrot/Configure/Options.pm
===
--- lib/Parrot/Configure/Options.pm (revision 0)
+++ lib/Parrot/Configure/Options.pm (revision 0)
@@ -0,0 +1,307 @@
+# Copyright (C) 2001-2006, The Perl Foundation.
+# $Id: Options.pm 17903 2007-03-31 15:53:17Z jkeenan $
+package Parrot::Configure::Options;
+use strict;
+use warnings;
+use base qw( Exporter );
+our @EXPORT_OK = qw(
+process_options
+get_valid_options
+);
+
+sub get_valid_options {
+return qw(ask bindir cage cc ccflags ccwarn cgoto cxx datadir
+debugging define exec-prefix execcapable floatval gc help icu-config
+icudatadir icuheaders icushared includedir infodir inline intval
+jitcapable ld ldflags lex libdir libexecdir libs link linkflags
+localstatedir m maintainer mandir miniparrot nomanicheck oldincludedir
+opcode ops optimize parrot_is_shared pmc prefix profile sbindir
+sharedstatedir step sysconfdir verbose verbose-step version without-gdbm
+without-gmp without-icu yacc);
+}
+
+sub process_options {
+my $optionsref = shift;
+my @valid_opts = get_valid_options();
+$optionsref->{argv} = []
+unless defined $optionsref->{argv};
+$optionsref->{script} = q{Configure.pl}
+unless defined $optionsref->{script};
+die "Must provide argument 'parrot_version'"
+unless $optionsref->{parrot_version};
+die "Must provide argument 'svnid'"
+unless $optionsref->{svnid};
+my %args;
+for (@{$optionsref->{argv}}) {
+my ( $key, $value ) = m/--([-\w]+)(?:=(.*))?/;
+$key = 'help' unless defined $key;
+$value = 1 unless defined $value;
+
+unless ( grep $key eq $_, @valid_opts ) {
+die qq/Invalid option $key. See "perl Configure.pl --help" for
valid options\n/;
+}
+
+for ($key) {
+if ($key =~ m/version/) {
+print_version_info($optionsref);
+return;
+}
+
+if ($key =~ m/help/) {
+print_help($optionsref);
+return;
+}
+$args{$key} = $value;
+}
+}
+
+$args{debugging} = 1
+unless ( ( exists $args{debugging} ) && !$args{debugging} );
+$args{maintainer} = 1 if defined $args{lex} or defined $args{yacc};
+return \%args;
+}
+
+##
Re: Current State of Building Parrot on Cygwin
On Sun, Apr 01, 2007 at 04:15:24PM +0200, Ron Blaschke wrote: > Hi, > > As recently discussed it is currently necessary to include the absolute > path to F in the environment variable PATH. This should be > done before trying to built parrot, otherwise one gets a broken > F and F. One > needs a "make clean" or remove *both* files before trying again. Make > sure to "export" the PATH changes, not just only "set" them, and use the > absolute path, not the relative (otherwise building some libs will fail > later on.) > > If you see this error > > > make runtime/parrot/library/Crow.pbc > ./parrot.exe -o runtime/parrot/library/Crow.pbc > runtime/parrot/library/Crow.pir > error:imcc:syntax error, unexpected $end > in file 'runtime/parrot/library/Crow.pir' line 146 > make: *** [runtime/parrot/library/Crow.pbc] Error 1 > > the file has Windows line endings, usually because checked out with > Windows' Subversion. Get the Cygwin version and a clean checkout. > I was beginning to think that was the problem with Cygwin. With Perl 5, the build process keeps all the Perl library in the same directory with executable. This seems to make things much easier for Windows, since DLL's need to be on the PATH on Windows (including Cygwin). Once I reboot into Windows, I'll see what I can do to help make this more automatic. Steve Peters [EMAIL PROTECTED]
Re: Current State of Building Parrot on Cygwin
On Sunday 01 April 2007 07:15, Ron Blaschke wrote: > As recently discussed it is currently necessary to include the absolute > path to F in the environment variable PATH. This should be > done before trying to built parrot, otherwise one gets a broken > F and F. One > needs a "make clean" or remove *both* files before trying again. Make > sure to "export" the PATH changes, not just only "set" them, and use the > absolute path, not the relative (otherwise building some libs will fail > later on.) Is it possible to pass flags to the linker that hint at a path to libparrot.so? That's how the Linux version works anyway. -- c
[perl #42271] [PATCH] Borland C++ cleanups
# New Ticket Created by Steve Peters
# Please include the string: [perl #42271]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42271 >
The attached patch are some of the cleanups needed for compiling Parrot
with Borland C++ on Windows. It is not yet compiling after this patch
because one of the changes that helped Borland C++ seems to cause the
Parrot go out of control and suck up all available CPU and memory on Linux.
Back to the drawing board,
Steve Peters
[EMAIL PROTECTED]
Index: src/events.c
===
--- src/events.c(revision 17931)
+++ src/events.c(working copy)
@@ -939,7 +939,7 @@
QUEUE_ENTRY *entry;
parrot_event* event;
-while ((entry = peek_entry(event_q))) {
+while ((entry = peek_entry(event_q)) != NULL) {
/*
* one or more entries arrived - we hold the mutex again
* so we have to use the nonsyc_pop_entry to pop off event entries
Index: src/gc/dod.c
===
--- src/gc/dod.c(revision 17931)
+++ src/gc/dod.c(working copy)
@@ -253,11 +253,11 @@
* get created as constant PMCs.
*/
for (i = 1; i < (unsigned int)interp->n_vtable_max; i++) {
-VTABLE *vtable;
+VTABLE *vtable = interp->vtables[i];
/*
* XXX dynpmc groups have empty slots for abstract objects
*/
-if ((vtable = interp->vtables[i])) {
+if (vtable) {
#if 0
if (vtable->class)
pobject_lives(interp, (PObj *)vtable->class);
Index: src/string.c
===
--- src/string.c(revision 17931)
+++ src/string.c(working copy)
@@ -528,6 +528,7 @@
return NULL;
break;
}
+return NULL;
}
/*
Index: src/objects.c
===
--- src/objects.c (revision 17931)
+++ src/objects.c (working copy)
@@ -42,7 +42,7 @@
{
int i;
const char *meth;
-for (i = 0; (meth = Parrot_vtable_slot_names[i]); ++i) {
+for (i = 0; (meth = Parrot_vtable_slot_names[i]) != NULL; ++i) {
if (!*meth)
continue;
/* XXX slot_names still have __ in front */
@@ -309,7 +309,7 @@
memset(&meth_str, 0, sizeof (meth_str));
meth_str.encoding = Parrot_fixed_8_encoding_ptr;
meth_str.charset = Parrot_default_charset_ptr;
-for (i = 0; (meth = Parrot_vtable_slot_names[i]); ++i) {
+for (i = 0; (meth = Parrot_vtable_slot_names[i]) != NULL; ++i) {
if (!*meth)
continue;
meth_str.strstart = const_cast(meth);
@@ -746,7 +746,8 @@
return NULL;
meth = VTABLE_get_string(interp, prop);
#else
-if (!(props = PMC_metadata(class)))
+props = PMC_metadata(class);
+if (!props)
return NULL;
b = parrot_hash_get_bucket(interp,
(Hash*) PMC_struct_val(props), prop_str);
Index: src/pmc/os.pmc
===
--- src/pmc/os.pmc (revision 17931)
+++ src/pmc/os.pmc (working copy)
@@ -19,9 +19,12 @@
*/
-#ifdef _MSC_VER
+#if defined(_MSC_VER)
# include
# include
+#elif defined(__BORLANDC__)
+# include
+# include
#else
# include
#endif
Index: src/library.c
===
--- src/library.c (revision 17931)
+++ src/library.c (working copy)
@@ -176,7 +176,7 @@
assert(path->encoding == Parrot_fixed_8_encoding_ptr ||
path->encoding == Parrot_utf8_encoding_ptr);
-while (cnv = strchr(path->strstart, path_separator))
+while ((cnv = strchr(path->strstart, path_separator)) != NULL)
*cnv = win32_path_separator;
}
Index: src/exceptions.c
===
--- src/exceptions.c(revision 17931)
+++ src/exceptions.c(working copy)
@@ -235,7 +235,7 @@
message = VTABLE_get_string_keyed_int(interp, exception, 0);
/* [TODO: replace quadratic search with something linear, hopefully without
trashing abstraction layers. -- rgr, 17-Sep-06.] */
-while ((e = stack_entry(interp, interp->dynamic_env, depth))) {
+while ((e = stack_entry(interp, interp->dynamic_env, depth)) != NULL) {
if (e->entry_type == STACK_ENTRY_PMC) {
handler = UVal_pmc(e->entry);
if (handler && handler->vtable->base_type ==
Index: config/init/hints/mswin32.pm
===
--- config/init/hints/mswin32.pm(revision 17931)
+++ config/init/hints/mswin32.pm(working copy)
@@ -145,7 +145,7 @@
share_ext => '.dll',
load_ext => '.dll',
cc => ${cc},
-ccflags=> '-
Hash iteration question
Hi,
Earlier tonight I tried to iterate a hash. I have somewhat thoughtlessly
been doing things like:
PMC *iter = VTABLE_get_iter(interp, some_hash);
while (VTABLE_get_bool(iter)) {
PMC *key_pmc = VTABLE_shift_pmc(interp, iter);
STRING *key = VTABLE_get_string(interp, key_pmc);
...
}
Rather than:
PMC *iter = VTABLE_get_iter(interp, some_hash);
while (VTABLE_get_bool(iter)) {
STRING *key = VTABLE_shift_string(interp, iter);
...
}
So now you're thinking "so what, Jonathan did something stupid in his
code yet again, big deal". What is perhaps surprising (well, I found it
surprising) is that if you do the first of these you only ever get the
first key in the hash - and then no more! If you do the second you'll
get all of the keys.
The whole load of hash/iterator code and the way they are so closely
tied looks kinda evil. If I'm reading it right, hash iteration ain't
threadsafe either (iterating a hash in two threads simultaneously will
run into issues); I'm not sure if that's a design goal, but anyways...
Does anyone have any thoughts on why these two code snippets do
different things, or have any reasons why they should? Or a ruling that
they shouldn't so we can decide if it's a bug...
Thanks,
Jonathan
P.S. Just for inspiration, a few comments from the current hash/iterator
code!
/* XXX int keys may be zero - use different iterator
*/
/* found next key - FIXME hash iter does auto next */
Get number of remaining elements. Does not work for hashes yet.
PDD15: newclass
Hi, The PDD sayeth: ~~ newclass $P1 = newclass $S2 Create a new base class named $S2, and put the PMC for it in $P1 ~~ And elsewhere: ~~ When declaring a composed class, you can optionally supply an array of method names that will be supplied by the class because of a conflict in its roles. This is done using the named parameter resolve. ~~ I'm guessing that it is referring to declaring a new class with the newclass op? If so, does newclass need to be a magic "op" that IMCC actually translates to a set_args/get_results/newclass sequence, so you can pass named arguments to the newclass op? If yes, do we need that for add_role, add_method and add_attribute too, since these can take named and optional parameters? Thanks, Jonathan
Re: Syntax for Constructing new Objects (and classes?)
Klaas-Jan Stol wrote: $P0 = get_class "HLLClass" $P1 = $P0.new() IIUC, instead of create a new object (either a built-in PMC or an OO object) in 1 instruction, it should now be done in 2? Yes. It adds a small amount of tedious typing, but gains us a great deal of power in our OO system. We will still have a 'new' opcode, but it will likely only handle the simplest cases. $P0 = new "HLLClass" Or, can I also write: $P0 = Integer.new() # create new Integer PMC object $P1 = Hash.new()# create new Hash PMC object No, we're eliminating bareword class names from PIR/PASM entirely. It's easy to do that in an HLL, though. Allison
[svn:parrot-pdd] r17939 - trunk/docs/pdds/draft
Author: allison Date: Sun Apr 1 19:14:27 2007 New Revision: 17939 Modified: trunk/docs/pdds/draft/pdd15_objects.pod Log: [pdd]: Adding additional parameter to 'newclass' opcode. Modified: trunk/docs/pdds/draft/pdd15_objects.pod == --- trunk/docs/pdds/draft/pdd15_objects.pod (original) +++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Apr 1 19:14:27 2007 @@ -259,6 +259,8 @@ =item name +$P1 = $P2.name( $S3 ) + The accessor for the name attribute. With no argument, it simply returns the current value for name. When passed an argument, it sets the name of the class, and also sets the association with a namespace. With no @@ -652,10 +654,12 @@ =item newclass $P1 = newclass $S2 + $P1 = newclass $S2, $P3 -Create a new base class named $S2, and put the PMC for it in $P1 +Create a new base class named $S2, and put the PMC for it in $P1. You may +optionally pass a hash of initialization parameters for the class in $P3. -=item subclass Px, Py, Sz +=item subclass $P1 = subclass $P2, $S3 @@ -831,7 +835,7 @@ .local pmc FooClass .local pmc MyObject FooClass = get_class "Foo" - MyObject = new FooClass + MyObject = FooClass.new() =head2 Calling a method on an object
Re: PDD15: newclass
Jonathan Worthington wrote:
Hi,
The PDD sayeth:
~~
newclass
$P1 = newclass $S2
Create a new base class named $S2, and put the PMC for it in $P1
~~
And elsewhere:
~~
When declaring a composed class, you can optionally supply an array of
method names that will be supplied by the class because of a conflict in
its roles. This is done using the named parameter resolve.
~~
Mmm... yes, the opcode does need another parameter. Added.
I'm guessing that it is referring to declaring a new class with the
newclass op? If so, does newclass need to be a magic "op" that IMCC
actually translates to a set_args/get_results/newclass sequence, so you
can pass named arguments to the newclass op?
The 'newclass' opcode itself will be just a simple opcode, so it can
only take fixed parameters. The newclass opcode is really just a
shortcut for C as in:
$P0 = new "Hash"
$P0["name"] = "MyClassName"
$P1 = split " ", "foomethod barmethod bazmethod"
$P0["resolve"] = $P1
$P2 = new "Class", $P0
Or, alternately:
$P2 = new "Class"
$P2.name("MyClassName")
So, perhaps we need:
$P2.resolve($P1)
Or:
$P2.initialize("name" => "MyClassName", "resolve" => $P1)
If yes, do we need that for add_role, add_method and add_attribute too,
since these can take named and optional parameters?
The named parameters are only on the method calls, not the opcodes.
Allison
Re: Syntax for Constructing new Objects (and classes?)
Allison Randal wrote: Or, can I also write: $P0 = Integer.new() # create new Integer PMC object $P1 = Hash.new()# create new Hash PMC object No, we're eliminating bareword class names from PIR/PASM entirely. It's easy to do that in an HLL, though. Unless, of course, you declare Integer and Hash as local variables, e.g.: .local pmc HLLClass HLLClass = get_class "HLLClass" $P1 = HLLClass.new() Allison
Re: [svn:parrot-pdd] r17921 - trunk/docs/pdds
On 4/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: paultcochrane Date: Sun Apr 1 00:58:42 2007 New Revision: 17921 Modified: trunk/docs/pdds/pdd07_codingstd.pod Log: [docs] Added a note about Perl source code with __END__ or __DATA__ blocks not requiring an emacs/vim coda. I don't know about emacs, but vim also searches the top (ten?) lines for a coda. So maybe we could put it at/near the top iff there's an __END__ or __DATA__ block. Shawn M Moore Paul: Sorry for sending this to you twice :)
[svn:parrot-pdd] r17940 - trunk/docs/pdds/draft
Author: allison
Date: Sun Apr 1 19:55:18 2007
New Revision: 17940
Modified:
trunk/docs/pdds/draft/pdd04_datatypes.pod
trunk/docs/pdds/draft/pdd15_objects.pod
Log:
[pdd]: Add notes about subclassing low-level PMCs as high-level objects.
Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod
==
--- trunk/docs/pdds/draft/pdd04_datatypes.pod (original)
+++ trunk/docs/pdds/draft/pdd04_datatypes.pod Sun Apr 1 19:55:18 2007
@@ -199,7 +199,7 @@
more) types of PMC, while particular Python datatypes will map onto different
types of PMC.
-=head2 VTABLE OVERLOADING
+=head2 Vtable Overloading
PMCs may declare vtable methods. The following list details the raw method
names:
@@ -574,6 +574,11 @@
=back
+=head2 Interaction between PMCs and high-level objects
+
+{{ Address the problem of high-level objects inheriting from low-level PMCs,
+and any structural changes to low-level PMCs that might require. }}
+
=head1 ATTACHMENTS
Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Apr 1 19:55:18 2007
@@ -119,13 +119,15 @@
=item - Objects can fetch their class
+=item - Objects can get an attribute by name
+
+=item - Objects can set an attribute by name
+
=item - Objects can be subclassed (note that objects may not necessarily
be able to have their classes changed arbitrarily, but making a subclass
and moving the object to it is allowable)
-=item - Objects can get an attribute by name
-
-=item - Objects can set an attribute by name
+=item - High-level objects can subclass low-level PMCs
=back
@@ -345,6 +347,12 @@
required positional parameter, and the optional named parameters C
and C; see L for more details.
+=item subclass
+
+ $P1 = $P2.subclass($S3)
+
+Create a subclass of $P2 with name $S3 and return it in $P1.
+
=item isa
$I1 = $P2.isa($S3)
@@ -405,7 +413,6 @@
and no Namespace object referencing it (to mark it as live). When a
class is garbage collected, it should remove itself from the registry.
-
=head2 Object PMC API
C PMCs are the actual objects, and hold all the per-object
@@ -574,7 +581,7 @@
implement them.
When declaring a composed class, you can optionally supply an array of
-method names that will be supplied by the class because of a conflict in
+method names that will be defined by the class to resolve a conflict in
its roles. This is done using the named parameter C. This
feature supports composition conflict resolution in languages such as
Perl 6.
@@ -663,7 +670,9 @@
$P1 = subclass $P2, $S3
-Create a new class, named $S3, which has $P2 as its immediate parent.
+Create a new class, named $S3, which has $P2 as its immediate parent. $P2 may
+be either another high-level class based on the Class PMC, or it may be a
+low-level PMC such as C or C.
=item get_class
@@ -1036,17 +1045,7 @@
Should we have a super or next opcode?
-=head1 NOTES
-
-=head2 Interaction with PMCs
-
-The interaction between objects and PMCs is currently underspecified.
-
-{{ Question: Does anyone remember what this note was about? Was it the
-problem of high-level objects that inherit from low-level PMC objects?
-}}
-
-
+{{ Shouldn't that be a super or next method call instead? }}
=head2 Translation
Re: Syntax for Constructing new Objects (and classes?)
On Mar 31, 2007, at 3:24 PM, Allison Randal wrote: Jonathan Worthington wrote: Does this also imply that all number-based type instantiation is going away, and thus we need to deprecate the find_type op too? Eventually, yes (almost certainly), but not in the next month. Allison I'm not sure how the imcc compiler handles the .Foo syntax internally, but there's a file, runtime/parrot/include/pmctypes.pasm that at least appears as though it's magically included into the beginning of every pir/pasm file. If it were changed to output a string instead of an integer, the dot syntax would still work with the strings(although the under the hood part I don't know about). It's merely a macro substitution if you think about it. Plus it'd mean we wouldn't have to rewrite all of the tests, and keep the old dot syntax that I personally like(easier for editors to detect a typo).
[svn:parrot-pdd] r17941 - trunk/docs/pdds/draft
Author: allison Date: Sun Apr 1 23:05:55 2007 New Revision: 17941 Modified: trunk/docs/pdds/draft/pdd15_objects.pod Log: [pdd]: Consistency on attribute addtion in Objects PDD. Modified: trunk/docs/pdds/draft/pdd15_objects.pod == --- trunk/docs/pdds/draft/pdd15_objects.pod (original) +++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Apr 1 23:05:55 2007 @@ -278,6 +278,7 @@ =item add_attribute + $P1.add_attribute($S2) $P1.add_attribute($S2, $S3) $P1.add_attribute($S2, $P3) @@ -525,10 +526,14 @@ =item add_attribute + $P1.add_attribute($S2) $P1.add_attribute($S2, $S3) + $P1.add_attribute($S2, $P3) Adds a single attribute to the role. It takes a simple string name, and -a simple string value for type. +optionally, a simple string value or key specifying a type name. (A type +name just checks C, and doesn't necessarily correspond to a class +or role namespace.) =item add_role @@ -701,10 +706,14 @@ =item addattribute addattribute $P1, $S2 + addattribute $P1, $S2, $S3 + addattribute $P1, $S2, $P3 Add attribute $S2 to class or role $P1. This will add the attribute slot to all objects of class $P1, classes that inherit from class $P1, or -classes that compose the role $P1, with a default value of C. +classes that compose the role $P1, with a default value of C. It +optionally takes a simple string value or key specifying a type of the +attribute. =item removeattribute
Re: Hash iteration question
Jonathan Worthington wrote:
Hi,
Earlier tonight I tried to iterate a hash. I have somewhat thoughtlessly
been doing things like:
PMC *iter = VTABLE_get_iter(interp, some_hash);
while (VTABLE_get_bool(iter)) {
PMC *key_pmc = VTABLE_shift_pmc(interp, iter);
STRING *key = VTABLE_get_string(interp, key_pmc);
...
}
Rather than:
PMC *iter = VTABLE_get_iter(interp, some_hash);
while (VTABLE_get_bool(iter)) {
STRING *key = VTABLE_shift_string(interp, iter);
...
}
So now you're thinking "so what, Jonathan did something stupid in his
code yet again, big deal". What is perhaps surprising (well, I found it
surprising) is that if you do the first of these you only ever get the
first key in the hash - and then no more! If you do the second you'll
get all of the keys.
> Does anyone have any thoughts on why these two code snippets do
> different things, or have any reasons why they should? Or a ruling that
> they shouldn't so we can decide if it's a bug...
The significant differences between the two are that Iterator's
shift_pmc throws an exception if the iteration key is -1 while
shift_string doesn't bother to check (it probably should), and
shift_string calls VTABLE_get_string_keyed on the aggregate it contains,
while shift_pmc calls VTABLE_get_pmc_keyed. And the only significant
differences between Hash's get_string_keyed and get_pmc_keyed are to be
expected for returning a string instead of a PMC. So, I can't explain
why they're giving different results. I can say they shouldn't be giving
different results. And note that in PIR, you can do either:
iter = new Iterator, some_hash
iter_loop:
unless iter, iter_end
shift $S2, iter
say $S2
goto iter_loop
iter_end:
Or:
iter = new Iterator, myhash
iter_loop:
unless iter, iter_end
shift $P2, iter
$S2 = $P2
say $S2
goto iter_loop
iter_end:
And get the same result.
The whole load of hash/iterator code and the way they are so closely
tied looks kinda evil. If I'm reading it right, hash iteration ain't
threadsafe either (iterating a hash in two threads simultaneously will
run into issues); I'm not sure if that's a design goal, but anyways...
Yes, the code for the two seems to be excessively intertwined, and needs
a review. As long as all the state for the iteration is stored in the
iterator object, and the iterator is only doing ordinary keyed lookups
on the hash, it should be threadsafe. (If that's not the case, it's a bug.)
Allison
Re: [svn:parrot-pdd] r17921 - trunk/docs/pdds
On 02/04/07, Sartak <[EMAIL PROTECTED]> wrote: On 4/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: paultcochrane > Date: Sun Apr 1 00:58:42 2007 > New Revision: 17921 > > Modified: >trunk/docs/pdds/pdd07_codingstd.pod > > Log: > [docs] Added a note about Perl source code with __END__ or __DATA__ blocks > not requiring an emacs/vim coda. I don't know about emacs, but vim also searches the top (ten?) lines for a coda. So maybe we could put it at/near the top iff there's an __END__ or __DATA__ block. Thanks for the comment! Unfortunately, we've already been down that road, and it was decided that having some files with the coda at the end and some at the top was not a good solution (it would certainly clutter things at the top of the file). Also, I believe vim only searches the top 5 lines, so we would also have to change the way the coda looks for top-of-file version wrt the bottom-of-file version. Some elegant, general way of setting editor hints in files would be really nice, but we've not found the answer to that yet ... :-/ Paul
Re: Syntax for Constructing new Objects (and classes?)
Joshua Isom wrote: I'm not sure how the imcc compiler handles the .Foo syntax internally, but there's a file, runtime/parrot/include/pmctypes.pasm that at least appears as though it's magically included into the beginning of every pir/pasm file. If it were changed to output a string instead of an integer, the dot syntax would still work with the strings(although the under the hood part I don't know about). It's merely a macro substitution if you think about it. Plus it'd mean we wouldn't have to rewrite all of the tests, and keep the old dot syntax that I personally like(easier for editors to detect a typo). There are several reasons to do away with constants for types and the class registry (the type constants just supply an ID from the class registry). - They don't respect namespaces, so you currently can't have an "Integer" class, for example, in multiple different HLLs. We could mangle namespaces into the type registry, but we already have a perfectly good way of storing classes in a namespace hierarchy, so it doesn't make sense to implement it twice. - They can't handle having more than one implementation of a class in the system. This we need to safely allow dynamic changes to a class after it has been instantiated. And, less critical, but still annoying: - The type constants collide with user-defined constants in less-than-desirable ways. If you define a constant with the same name as a type constant, the system simply ignores the redefinition and supplies the type constant's value. Allison
