Kwalitee and has_test_*
I was having a look at CPANTS again this morning, and I noticed something rather strange. There are now two kwalitee tests for 'has_test_pod' and 'has_test_pod_coverage'. These check that there are test scripts for POD correctness and POD coverage. These seem completely and utterly wrong to me. Surely the kwalitee checks should be purely that the POD is correct and sufficiently covers the module? Otherwise a distribution which has perfectly correct POD, which completely covers the module, is deemed to be of lesser kwalitee, and listed on CPANTS as having shortcomings. We should be very wary of stipulating HOW authors have to achieve their quality. Saying you can only check your POD in one specific way goes to far IMO. Tony
[PATCH] support make DESTDIR=/... install
This fixes installing to a different DESTDIR.
Index: Makefile.PL
===
--- Makefile.PL (revision 1233)
+++ Makefile.PL (working copy)
@@ -105,10 +105,10 @@
pure_site_install ::
\$(NOECHO) \$(MOD_INSTALL) \\
- \$(INST6_LIB) $config-{privlib} \\
- \$(INST6_ARCHLIB) $config-{archlib} \\
- \$(INST6_BIN) $config-{installbin} \\
- \$(INST6_SCRIPT) $config-{installscript} \\
+ \$(INST6_LIB) \$(DESTDIR)$config-{privlib} \\
+ \$(INST6_ARCHLIB) \$(DESTDIR)$config-{archlib} \\
+ \$(INST6_BIN) \$(DESTDIR)$config-{installbin} \\
+ \$(INST6_SCRIPT) \$(DESTDIR)$config-{installscript} \\
\$(INST6_MAN1DIR) \$(DESTINSTALLMAN1DIR) \\
\$(INST6_MAN3DIR) \$(DESTINSTALLMAN3DIR)
.
End.
Re: [PATCH] support make DESTDIR=/... install
Rafael Garcia-Suarez writes:
This fixes installing to a different DESTDIR.
Thanks, applied.
Luke
Index: Makefile.PL
===
--- Makefile.PL (revision 1233)
+++ Makefile.PL (working copy)
@@ -105,10 +105,10 @@
pure_site_install ::
\$(NOECHO) \$(MOD_INSTALL) \\
- \$(INST6_LIB) $config-{privlib} \\
- \$(INST6_ARCHLIB) $config-{archlib} \\
- \$(INST6_BIN) $config-{installbin} \\
- \$(INST6_SCRIPT) $config-{installscript} \\
+ \$(INST6_LIB) \$(DESTDIR)$config-{privlib} \\
+ \$(INST6_ARCHLIB) \$(DESTDIR)$config-{archlib} \\
+ \$(INST6_BIN) \$(DESTDIR)$config-{installbin} \\
+ \$(INST6_SCRIPT) \$(DESTDIR)$config-{installscript} \\
\$(INST6_MAN1DIR) \$(DESTINSTALLMAN1DIR) \\
\$(INST6_MAN3DIR) \$(DESTINSTALLMAN3DIR)
.
End.
Re: tcl parser.
William Coleda [EMAIL PROTECTED] wrote: When invoking a PIR-defined object from C, what's the proper call? pmc_new ? (Does that handle class_init) ? I don't understand the question. Do you want to instantiate an object? If yes, just do the same as the respective opcodes are doing: cl = Parrot_class_lookup(interpreter, class_name_str); REG_PMC(5) = arg1; REG_INT(3) = 1; REG_PMC(2) = cl; o = VTABLE_instantiate(interpreter, cl); or type = pmc_type(interpreter, class_name_str); o = pmc_new(interpreter, type); In both cases the method class::__init is run if present. leo
More Makefile.PL patches
This one fixes make test, by forcing the fix of test target of the
generated Makefile. I'd rather have Ingy reviewing it or something,
because AFAICT it's his territory -- dark makemaker places where black
magic hides behind obscure curtains. (make install still works and
still installs everything in its right place)
Index: inc/Module/Install/Pugs.pm
===
--- inc/Module/Install/Pugs.pm (revision 1236)
+++ inc/Module/Install/Pugs.pm (working copy)
@@ -22,8 +22,7 @@
$self-WriteAll(@_);
-$self-pugs_fix_makefile
- if $install_version eq '6';
+$self-pugs_fix_makefile;
}
sub set_makefile_macros {
This one is just a nit : it silences make test, that complains
about t/*.t not existing.
Index: Makefile.PL
===
--- Makefile.PL (revision 1236)
+++ Makefile.PL (working copy)
@@ -27,7 +27,7 @@
} glob(ext/*)
);
makemaker_args (
-test = { TESTS = join ' ', t/*.t, t/*/*.t, t/*/*/*.t },
+test = { TESTS = join ' ', t/*/*.t, t/*/*/*.t },
MAN1PODS = {},
);
clean_files (map fixpaths($_),
Re: More Makefile.PL patches
Rafael Garcia-Suarez writes:
This one fixes make test, by forcing the fix of test target of the
generated Makefile. I'd rather have Ingy reviewing it or something,
because AFAICT it's his territory -- dark makemaker places where black
magic hides behind obscure curtains. (make install still works and
still installs everything in its right place)
Thanks, applied.
Luke
Index: inc/Module/Install/Pugs.pm
===
--- inc/Module/Install/Pugs.pm(revision 1236)
+++ inc/Module/Install/Pugs.pm(working copy)
@@ -22,8 +22,7 @@
$self-WriteAll(@_);
-$self-pugs_fix_makefile
- if $install_version eq '6';
+$self-pugs_fix_makefile;
}
sub set_makefile_macros {
This one is just a nit : it silences make test, that complains
about t/*.t not existing.
Index: Makefile.PL
===
--- Makefile.PL (revision 1236)
+++ Makefile.PL (working copy)
@@ -27,7 +27,7 @@
} glob(ext/*)
);
makemaker_args (
-test = { TESTS = join ' ', t/*.t, t/*/*.t, t/*/*/*.t },
+test = { TESTS = join ' ', t/*/*.t, t/*/*/*.t },
MAN1PODS = {},
);
clean_files (map fixpaths($_),
[CVS ci] PMC constants and more
1) the PASM and PIR assemblers are now extended to understand arbitrary PMC constants: .const .Integer P0 = 42 # PASM .const .Integer i = 42# PIR .const Integer i = 42# PIR Caveat: don't use this yet, the PMC constants vanish after the first GC sweep. See below. The constant has to be a double-quoted string. E.g. .const FixedIntegerArray a = [2,3,4] A PMC class that supports this feature has to implement: - freeze/thaw for getting the value to/from bytecode - the instantiate constructor, which is called with one STRING argument in S5 aka REG_STR(5) (see integer.pmc). It has to parse the string and create an appropriate PMC. We already had this construct for subroutines: .const .Sub f = foo which is actually: set_p_pc f, pmc_constant_of_sub_foo 2) as PMC constants should work from .PBC files too, PMC constants including subroutine PMCs are now serialized using the freeze/thaw mechanism. 3) TODO items: I really want to have these constants live in the constant PMC pool. The constructor would then be a new VTABLE Cinstantiate_constant or some such. For now they are plain PMCs, but *not* marked during DOD, so don't use it for now. As a short-term solution we could of course scan the constant table and mark PMC items. This also implies that attaching non-constant items to constant PMCs is illegal, e.g. setting properties on Sub PMCs. If you want to do this the PMC constant has to be cloned first. Second: to protect these PMCs from any modification, a VTABLE variant should be swapped in that has all VTABLE slots that modify the PMC redirected to an error function: Modification of a read-only value attempted at ... There is an experimental feature for such a scheme in the SArray PMC: pmclass SArray const_too ... ^ This creates a second PMC class ConstSArray with a distinct type enum. But that's basically a bad hack, e.g. the type list in classes/pmc.num must contain an entry for that class too. I'm not quite sure, if such read-only PMC variants should have a separate class type enum or just a different vtable. We need this anyway for perl6: sub foo($a is ro, ...) The PMC compiler already has a list of methods that modify the PMC, we just need a scheme to create these vtable variants in a more general way. Comments, proposals, takers ;) welcome, leo
Re: Kwalitee and has_test_*
These seem completely and utterly wrong to me. Surely the kwalitee checks should be purely that the POD is correct and sufficiently covers the module? Especially because pod.t and pod-coverage.t don't need to actually get distributed with the module. Perhaps I keep pod*.t in my Subversion repository, and they get run when I run a make test, but aren't in the MANIFEST and therefore don't get shipped. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[MSWin32] Helping The Paranoid Parrot on Windows
I've been experimenting with dynamic linkage on Windows. As a teaser
to read on, here's how far I've got.
Before
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\foo.t 1 256 11 100.00% 1
t\dynclass\gdbmhash.t13 332813 13 100.00% 1-13
t\dynclass\pybuiltin.t6 1536 66 100.00% 1-6
t\dynclass\pyclass.t 6 1536 66 100.00% 1-6
t\dynclass\pycomplex.t1 256 11 100.00% 1
t\dynclass\pyfunc.t 4 1024 44 100.00% 1-4
t\dynclass\pyint.t 25 640025 25 100.00% 1-25
t\op\spawnw.t 2 512 32 66.67% 2-3
3 tests and 66 subtests skipped.
Failed 8/141 test scripts, 94.33% okay. 58/2263 subtests failed, 97.44% okay.
After
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\op\spawnw.t2 512 32 66.67% 2-3
3 tests and 65 subtests skipped.
Failed 1/139 test scripts, 99.28% okay. 2/2257 subtests failed, 99.91% okay.
Don't worry about spawn at the moment, it broke some week ago, and is
not related to the linkage problem.
There's quite a number of changes involved, here's my proposal of how
to change things. Choosing early on static or dynamic linkage, and
changing the library names, is not strictly necessary, but would
probably make things simpler, and Parrot feel more at home on
Windows, respectively.
- Parrot should be told during Configure to be built static
or dynamic (shared); it should probably be dynamic on most systems
- A static Parrot should not run the dynclasses tests
- The parrot library should be named Cparrot.lib and
Cparrot${MAJOR}${MINOR}.dll on Windows
- The dynamic parrot library Cparrot01.dll should be in the same
directory as Cparrot.exe, or otherwise it must be a)explicity loaded
or b)the directory added to the PATH environment.
- Paths and/or linkage instructions should be updated accordingly, eg
Flib/Parrot/Test.pm
(my $libparrot_root = $PConfig{blib_lib_libparrot_a}) =~
s/\$\(A\)//;
my $libparrot_dynamic = $libparrot_root.$PConfig{share_ext};
my $libparrot;
# use shared library version if available
if( -e $libparrot_dynamic ) {
$libparrot = '-Lblib/lib -lparrot';
} else {
$libparrot = $libparrot_root.$PConfig{a};
}
- There should be a macro PARROT_API, which hints the compiler how to
link things, on platforms that support it. Eg, on Windows it should
expand to
'__declspec(dllexport)' if a symbol should be exported (dynamic)
'__declspec(dllimport)' if a symbol should be imported (dynamic)
empty string (static)
PARROT_API must be added to each API symbol of the library.
- A similar macro must be present for each library, which means there
must be a different one for dynclasses (PARROT_DYNCLASSES_API), as the
symbols of libparrot must be imported, and the symbols of the
dynclasses exported.
I have some questions, too.
- After I changed the linkage, some dynclasses failed, during access
of CParrot_base_vtables[100]. No surprise, as the array is only
C#define PARROT_MAX_CLASSES 100
long. After I changed it to 1000, the tests passed. Why gets no one
else bitten by this? Somehow my fault? Shouldn't it be dynamically
resized?
- I'm not sure where IMCC belongs. I'd guess it goes into libparrot.
But Fimcc/main.c goes into the parrot executable. Yet, this one
depends on parser symbols (line, yyparse, yyin, yydebug, yylex), which
probably should not be exported by libparrot. Any hints?
Comments are highly appreciated, especially from the Win32 folks.
Leo, if that's okay, I'll wait for your GO before preparing and
submitting any patches.
Frohe Ostern,
Ron
Pugs 6.0.13 released.
I'm glad to report that I managed to release 6.0.13 during
YAPC::Taipei, several minutes before my Perl 6 the Ultimate Talk,
which was quite successful. :-)
You can download 6.0.13 from:
http://search.cpan.org/dist/Perl6-Pugs/
I've forgotten to include t/README in the MANIFEST, but you can
read it here:
http://svn.openfoundry.org/pugs/t/README
Thanks for all the people who made this release possible!
Enjoy,
/Autrijus/
== Changes for 6.0.13 - March 27, 2005
=== Pugs Internals
* Support for `given`, `when` and `elsif` statements
* Support for Perl5 style `-I` on the command line
* Command line equivalents of shell commands `:i` and `!`.
* Regex now supports `s:perl5///` and `s:perl5:g///`
* `$1`, `$2` etc can be used in `s:perl5:g///` substitutions
* Experimental *pugscc* backends generating limited Parrot and Haskell code
* Refactored the /VSub/ type to support currying
* Support for currying: `foo.assuming(param = 'bar')`
* New file test primitives: `-d` and `-f`
* New logical primitive: `?|`
* Experimental support for `eval_perl5` (not built by default)
* Experimental Inline support; see `ext/SHA1` for example
* New magicals: `$*EXECUTABLE_NAME` and `$*PROGRAM_NAME`
* Several numeric builtins: `atan2`, `cos`, `sin`, `sqrt`, `exp`
* Beginings of a Pugs class meta-model
=== Test, Examples and Documentations
* New test for junctions, regexp and more; about 3200 tests now
* Added 200+ new TODO tests for objects in `t/oo/`
* Added 20 new Perl 5 modules ported to Perl 6
* Added `t/README`, `modules/README` and `modules/PORTING_HOWTO`
* Much work on the test-cataloger and Synopsis cross-referencer
* Work on plan for smoke testing framework using *YAML* and *Test::Harness*
* Work on HTML output gathered from *Test::Harness* YAML output
* Actual working port of most of *File::Spec* complete with tests and docs
* Added support for outputing test logs with *Test.pm*
* Added documentation to *pugscc*
* Several TODO tests for command line options
* `fix_authors.pl` now handles UTF8 input
* New golf-based tests in `t/examples/golf.t`
* Added `examples/mandel.p5` for benchmarking against `mandel.p6`
* The first JAPH for Pugs in `examples/japh/`
=== Bug Fixes
* Numification now uses the same lexer as numeric literals
* Passing pairs to named parameters works
* Fixed 2-element lists to be proper pairs
* Fixed some error reporting issues in *Test.pm*
* `$!` now has the correct value after `eval`
* `END {...}` now runs after `die`
* Hash are now string keys
* Contextual logicals like `+^` and `~^` are parsed correctly
pgp3alsKAj0WJ.pgp
Description: PGP signature
pugs code coverage requirements
I've been following the progress of pugs in awe of the speed of the
progress, the breadth of the scope and the exemplary way in which
Autrijus has run the project. And I've been considering how best I
could contribute.
One of the many aspects of the project that is to be admired is the test
driven development. Knowing a little about code coverage I wondered
whether there were any Haskell code coverage tools that we could use to
aid in that process. The best option seemed to be something based on
hat (http://www.haskell.org/hat/) but unfortunately pugs uses some
libraries which hat does not support. The last release of hat came two
years ago, so I'm not expecting those libraries to be supported in the
near future. If anyone knows of a way to do code coverage in Haskell,
and specifically of pugs, please pipe up.
So next I thought about code coverage of Perl6 itself. Now that people
are starting to write Perl6 modules code coverage could be useful. It
seemed to me that walking the AST and hooking into the reduce function
could provide the required data. Autrijus confirmed this, but thought
there might be a better way to do it and asked me to send requirements
in time for the refactoring of Eval.hs next week. So here they are.
At the most basic level two sets of data are required: the constructs in
the program, and which of them were exercised. So for subroutine
coverage, for example, that would mean a list of all the subroutines in
the program and which of them were called. But a little more
information can be useful. For example, the exact location of the
construct in the source code, the number of times it was exercised, how
long it took to be exercised, and so on.
In Perl5, Devel::Cover gets information about the constructs in the
program from two sources: the optree and the source code. Information
from the optree is obtained by calling B::Deparse and overriding some of
its functions. Information about which constructs were exercised is
obtained by installing a custom runops function and squirrelling away
data as ops are run.
So, requirements:
1. Access to all the coverable constructs in the program: subroutines,
statements, branches, conditions, loops, rules, pod ...
2. Information about those constructs. Where to find them in the
source, textual representation, information about the parts of the
constructs.
3. Which constructs were exercised. How many times, the order, when
and how long it took.
Not all this information is required all the time. For example, timing
and count information may not be wanted for efficiency reasons.
Depending on how this information is available other requirements may
surface. For example, in Perl5 it is necessary to know that coverage is
to be collected before any code in the program is executed, and it is
necessary to process the data after the last code in the program has
been executed.
Aspects of Perl5 that make collecting coverage difficult:
- doesn't allow constructs to be exactly regenerated from optree data
- doesn't store enough information, eg can't determine location of
elsif condition
$ perl -we 'if ($a) {}
elsif ($a + 1) {}'
Use of uninitialized value in addition (+) at -e line 1.
- filenames stored as relative paths so they can be difficult to find
later
- not always easy to determine the source file of a construct
- deletes parts of the optree, eg code in modules which is not within a
sub
- doesn't provide a way to uniquely identify constructs
- difficult to determine the value of an arbitrary boolean expression
I can probably go into nauseating detail on any of these points if
required.
If you've got this far, thanks for listening!
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
t/dynclass failures due to using installed libs
I just did a CVS update (the first in a while, with all necessary options present, btw), and got some dynamic loading failures, e.g.: [EMAIL PROTECTED] perl -Ilib t/dynclass/foo.t 1..1 not ok 1 - abs # Failed test (t/dynclass/foo.t at line 21) # got: 'Couldn't load 'foo': foo: cannot open shared object file: No such file or directory # Illegal PMC enum (0) in new # ' # expected: '42 # ' # '(cd . ./parrot /shared/src/parrot/t/dynclass/foo_1.imc)' failed with exit code 1 # Looks like you failed 1 tests of 1. [EMAIL PROTECTED] Poking into it, I found that Parrot_locate_runtime_file searches under the prefix, /usr/local/parrot-0.1.2-devel in this case, which certainly makes sense for installed code. If the prefix is disabled via PARROT_TEST, this fixes the immediate problem: [EMAIL PROTECTED] PARROT_TEST=1 perl -Ilib t/dynclass/foo.t 1..1 ok 1 - abs [EMAIL PROTECTED] But shouldn't make test do this by default? Otherwise, you're not actually testing the version you just built . . . -- Bob Rogers http://rgrjr.dyndns.org/
[perl #34586] [PATCH] - pmc2c2.pl parent sorting
# New Ticket Created by Peter Sinnott # Please include the string: [perl #34586] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34586 patch #34564 dropped the $ in the parent sorting in gen_parent_list this patch restores it Peter pmc2c2_sortfix.patch Description: Binary data
[perl #34587] Build Segfaults While Generating config.fpmc (Linux PPC)
# New Ticket Created by chromatic
# Please include the string: [perl #34587]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34587
---
osname= linux
osvers= 2.4.24-benh0
arch= powerpc-linux
cc= gcc 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0,
pie-8.7.7)
---
Flags:
category=core
severity=critical
ack=no
---
The current CVS HEAD has failed for about a week or so at the point
where Parrot tries to generate its configuration library. (I originally
posted in the MinGW thread so it may have looked like another Windows
error. It's not.) Here's the relevant output.
Compiling with:
xx.c
gcc -DDEBUGGING -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g
-Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
-Waggregate-return -Winline -W -Wno-unused -Wsign-compare
-Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization
-Wno-shadow -falign-functions=16 -I./include -I./blib/include -DHAS_JIT
-DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross
your fingers
./parrot config_lib.pasm
make: *** [runtime/parrot/include/config.fpmc] Segmentation fault
Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7383)]
0x100b74f0 in pobject_lives (interpreter=0x103ac910, obj=0x35) at
src/dod.c:196
196 if (PObj_is_live_or_free_TESTALL(obj)) {
(gdb) bt
#0 0x100b74f0 in pobject_lives (interpreter=0x103ac910, obj=0x35)
at src/dod.c:196
#1 0x10278d7c in Parrot_SArray_mark (interpreter=0x103ac910,
pmc=0x1056c540)
at classes/sarray.c:276
#2 0x100b7bd4 in Parrot_dod_trace_children (interpreter=0x103ac910,
how_many=4294967295) at src/dod.c:460
#3 0x100b78fc in trace_active_PMCs (interpreter=0x103ac910,
trace_stack=1)
at src/dod.c:378
#4 0x100b87a8 in Parrot_dod_ms_run (interpreter=0x103ac910, flags=1)
at src/dod.c:1198
#5 0x100b88c8 in Parrot_do_dod_run (interpreter=0x103ac910, flags=1)
at src/dod.c:1237
#6 0x1014cbec in mem_allocate (interpreter=0x103ac910,
req_size=0x7384,
pool=0x103aceb0, align_1=15) at src/resources.c:142
#7 0x1014da90 in Parrot_allocate_string (interpreter=0x103ac910,
str=0x10552b10, size=0) at src/resources.c:613
#8 0x10062b8c in string_make_empty (interpreter=0x103ac910,
representation=enum_stringrep_one, capacity=0) at src/string.c:397
#9 0x1025ca44 in Parrot_String_init (interpreter=0x103ac910,
pmc=0x1056a188)
at classes/string.c:46
#10 0x1006954c in pmc_new (interpreter=0x103ac910, base_type=34)
at src/pmc.c:47
#11 0x1027bc50 in get_string_pmc (interpreter=0x103ac910, base_type=52)
at classes/hash.c:120
#12 0x1027d4ec in Parrot_Hash_set_string_keyed (interpreter=0x103ac910,
pmc=0x1056ad28, key=0x10607170, value=0x103d4d18) at
classes/hash.c:635
#13 0x10102130 in Parrot_set_p_kc_sc (cur_opcode=0x10602430,
interpreter=0x103ac910) at set.ops:465
#14 0x101931b4 in runops_slow_core (interpreter=0x103ac910,
pc=0x10602430)
at src/runops_cores.c:147
#15 0x101902a8 in runops_int (interpreter=0x103ac910, offset=0)
at src/interpreter.c:742
#16 0x101917ac in runops (interpreter=0x103ac910, offs=0) at
src/inter_run.c:81
#17 0x100adf18 in Parrot_runcode (interpreter=0x103ac910, argc=1,
argv=0x7618) at src/embed.c:768
#18 0x100add50 in Parrot_runcode (interpreter=0x103ac910, argc=1,
argv=0x7618) at src/embed.c:700
#19 0x10056604 in main (argc=1, argv=0x7618) at imcc/main.c:603
---
Summary of my parrot 0.1.2 configuration:
configdate='Sun Mar 27 14:45:22 2005'
Platform:
osname=linux, archname=powerpc-linux
jitcapable=1, jitarchname=ppc-linux,
jitosname=LINUX, jitcpuarch=ppc
execcapable=1
perl=/usr/bin/perl5.8.6
Compiler:
cc='gcc', ccflags='-DDEBUGGING -pipe -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
Linker and Libraries:
ld='gcc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lpthread -lnsl -ldl -lm -lcrypt -lutil -lrt -lgmp'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=4321,
nv=double, numvalsize=8, doublesize=8
---
Environment:
HOMELANGLANGUAGELC_ALLLD_LIBRARY_PATHLOGDIR
PATHSHELL
Garbage Collection Issues?
I've been writing a Lisp implementation on top of Parrot for the last several months (and I'm just about at the point where I'm ready to unleash it upon the world). I seem to have run up against some issues which *appear* to be related to the garbage collector collecting objects that aren't ready to be collected yet. (I say appear because I'm unsure as to how to check when an object is being collected and the memory returned to the system - for all I know this could be entirely my fault.) I've included a much pared down example IMC file which on an x86 Linux machine will produce a segmentation fault and on a Mac OS X 10.3 machine produces a bus error. Running with the garbage collection disabled (ie. with the -G flag) does not produce these errors. If anyone could point me towards what is going wrong, I would MOST appreciate it - it's been driving me nuts. (I've been following Parrot internals only superficially for the past little while so I'm entirely unfamiliar with the garbage collection system.) I have only a vague inclination that it has to do somehow with the Hash class (based on how various bugs manifest themselves in my program). The Parrot version is the latest CVS checkout as of 10 minutes ago. Regards, Cory .macro PACKAGE (P,N) .P = new LispPackage .P._set_name_as_string(.N) .endm .macro STRING (R,S) .R = new LispString .R = .S .endm .macro SYMBOL (R,N) .R = new LispSymbol .R._set_name_as_string(.N) .endm .sub _main @MAIN .local pmc package1 .local pmc package2 .local pmc package3 .local pmc symbol .local int count _init_types() .PACKAGE(package1, COMMON-LISP) symbol = package1._intern_symbol(T) count = 0 LOOP: print count print : print looking up symbol: T\n symbol = package1._lookup_symbol(T) .PACKAGE(package3, SYSTEM) package3._import_symbol(symbol) symbol = package1._lookup_symbol(T) package2 = symbol._get_package() inc count goto LOOP end .end .sub _init_types .local pmc class # Create the LispPackage class newclass class, LispPackage addattribute class, internal addattribute class, name # Create the LispString class subclass class, String, LispString # Create the LispSymbol class newclass class, LispSymbol addattribute class, function addattribute class, name addattribute class, package .end .namespace [LispPackage] .sub __init method .local pmc value value = new Hash setattribute self, LispPackage\0internal, value .end .sub _lookup_symbol method .param string name .local string type .local pmc symbol .local pmc hash getattribute hash, self, LispPackage\0internal symbol = hash[name] typeof type, symbol if type == None goto SYMBOL_NOT_FOUND goto DONE SYMBOL_NOT_FOUND: null symbol goto DONE DONE: .return(symbol) .end .sub _import_symbol method .param pmc symbol .local string symname .local pmc hash symname = symbol._get_name_as_string() getattribute hash, self, LispPackage\0internal hash[symname] = symbol .return(symbol) .end .sub _intern_symbol method .param string name .local string type .local pmc symbol .local pmc status .local pmc hash getattribute hash, self, LispPackage\0internal symbol = hash[name] typeof type, symbol if type != None goto DONE .SYMBOL(symbol, name) hash[name] = symbol symbol._set_package(self) goto DONE DONE: .return(symbol) .end .sub _get_name_as_string method .local pmc name .local string retv getattribute name, self, LispPackage\0name retv = name .return(retv) .end .sub _set_name_as_string method .param string name .local pmc retv .STRING(retv, name) setattribute self, LispPackage\0name, retv .return(retv) .end .sub __get_string method .local pmc name .local pmc tmps .local pmc retv getattribute name, self, LispPackage\0name retv = new String tmps = new String tmps = #PACKAGE concat retv, tmps, name tmps = concat retv, retv, tmps .pcc_begin_return .return retv .pcc_end_return .end .namespace [LispSymbol] .sub _get_name_as_string method .local pmc name .local string retv getattribute name, self, LispSymbol\0name retv = name .return(retv) .end .sub _set_name_as_string method .param string name .local pmc retv .STRING(retv, name) setattribute self, LispSymbol\0name, retv .return(retv) .end .sub _get_package method .local pmc retv getattribute retv, self, LispSymbol\0package .return(retv) .end .sub _set_package method .param pmc package setattribute self, LispSymbol\0package, package .return(package) .end .sub __get_string method .local pmc name getattribute name, self, LispSymbol\0name .pcc_begin_return .return name .pcc_end_return .end .namespace []
Re: [perl #34586] [PATCH] - pmc2c2.pl parent sorting
On Sun, 2005-03-27 at 12:25 -0800, Peter Sinnott wrote: patch #34564 dropped the $ in the parent sorting in gen_parent_list this patch restores it Good catch. Thanks, applied. -- c
Re: Test::META
Randy W. Sims wrote: There is my unpublished CPAN::Metadata at: svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk/ CPAN-Metadata It reads, writes, and validates metadata according to the spec. It still needs a bit of work, and updates to the actual spec need to be formalized before it will be usefull. Thanks... Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path So, I've sticking with ExtUtils::MakefMaker for the moment. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote: Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path That's odd, its not where I'd have expected breakage. Want to post your MakeMaker and MB versions so we can poke at them?
Re: Test::META
Michael G Schwern wrote: On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote: Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path That's odd, its not where I'd have expected breakage. Want to post your MakeMaker and MB versions so we can poke at them? I rolled back. I'm have to reconsicrate my Build.PL tomorrow. I want to tinker a bit more tomorrow to rule out user stupidity. My bet is that the shebang -w in my *.t files are kicking in where they weren't before; pointing to a difference in how they're invoked between the two envorinments. Along those lines, CTRL-C, CTRL-D, and Terminate batch job.. Y never got me out of the loop: The path '' is not an absolute path. Please specify an absolute path My only recourse was to terminate the CMD window. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [PROPOSAL] infix MMD operators
Leo~
On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
5) infix method signature change:
METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ยด*dest) {
if (!dest)
dest = pmc_new(INTERP, SELF-vtable-base_type);
...
return dest;
}
If the destination PMC is passed in, it's used else a new PMC of an
appropriate type is created.
I would actually appreciate a refresher on the original motivation
behind never autogenerating a LHS. I recall being told it has
something to do with tied data, but I was never clear on exactly how
that related. I would think that tied data would only require
VTABLE_assign method, and would not care how its RHS was created (via
an add or mul or whatever).
Thus I would argue for having most operators create their result (but
having a special assign that would call a VTABLE method) and forcing
languages with active data to go through a two step assignment
$P0 = $P1 + $P2 # P0 created
$P3 - $P0 # P3 gets to run its tied code
and languages like python which have immutable scalars could always use
$P0 = $P1 + $P2 # P0 created
One concern that occurs to me is that this would cause more new PMC
allocations. But I am whether or not that is true.
7) separate inplace methods
Opcodes like:
d += r# add d, r
are currently using the normal add method with the destination set to
SELF. This is suboptimal, especially, when the destination PMC is
morphed to a different type (e.g. due to bigint promotion) which
destroys the value of SELF.
It's just cleaner to have distinct inplace methods, it's very likely
also needed anyway, as method overloading would not work if the inplace
operations are the same.
Therefore we have:
infix __i_add, d, r
and in *.pmc
METHOD void i_add( [INTERP, SELF, ] PMC* r) {...}
I think this one is very necessary.
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-???
[PROPOSAL] infix MMD operators
From: Leopold Toetsch [EMAIL PROTECTED] Date: Sun, 27 Mar 2005 16:37:41 +0200 1) Mixed infix operations Opcodes that take one PMC and one native type argument, like: op add(in PMC, in PMC, in INT) should probably become plain vtable methods again. There isn't much multi in the dispatch as the dispatch degenerates to a search in the class of the left argument's MRO. OTOH this may have some implications as Perl6 is treating these as normal multi subs. IMHO, one can have too much overloading. It seems cleaner to distinguish between +, the (sometimes overloaded) HLL operator and add, the Parrot addition operator so that compiled code can opt out of the overloading when the compiler knows that it really needs to do mere addition. Maybe we need just a fake int class for the sake of MMD. I think this is a really good idea. Indeed, I think it's hard to do otherwise; you need some place to store the isa relationships between PMC classes for primitive types. Beyond that, I think it's good to minimize the distinction between PMC classes and ParrotClass classes from the perpective of HLLs; implementors are then freer to use a ParrotClass to start, and reimplement as PMCs later for speed. BTW, I just noticed that pmclass ParrotObject extends ParrotClass ...; is this right? Seems like the class and instance hierarchies ought to be disjoint . . . 5) infix method signature change . . . We need this basically for 4 reasons: a) Python All Python scalars are immutable. The current scheme to morph the destination PMC to the type of the result is basically wrong. All Python operations on scalars always return a new result PMC. This is also how Common Lisp prefers to view the world. . . . 7) separate inplace methods Opcodes like: d += r# add d, r are currently using the normal add method with the destination set to SELF. This is suboptimal, especially, when the destination PMC is morphed to a different type (e.g. due to bigint promotion) which destroys the value of SELF. It's just cleaner to have distinct inplace methods, it's very likely also needed anyway, as method overloading would not work if the inplace operations are the same. It also allows $a = $a + $b to have different semantics from $a += $b for suitably defined operators and values. Not that I can think of a reasonable example off the top of my head . . . -- Bob Rogers http://rgrjr.dyndns.org/
Re: Kwalitee and has_test_*
These seem completely and utterly wrong to me. Surely the kwalitee
checks should be purely that the POD is correct and sufficiently covers
the module?
One problem I can see with this is that (I think) the only way to
indicate extra private methods is to do so in pod-coverage.t. For
instance:
pod_coverage_ok(
My::Module,
{ also_private = [ qr/^conf$/ ], },
My::Module, POD coverage, but marking the 'conf' sub as private
);
My::Module will pass its own pod-coverage.t script, but it won't pass
with someone else's pod-coverage.t.
Maybe there should be a different way of marking additional private
methods?
Michael
--
Michael Graham [EMAIL PROTECTED]
