more pdd21 questions
Hi @chip,
1)
Namespace Opcodes
add_namespace $P0, $P1
The opcode signature looks a bit strange to me, especially when compared
to the 'add_namespace' method. Is the namespace name implied? And there
is of course again the question where to add the namespace: relative to
HLL or absolute at namespace root.
The relative to HLL:: or absolute issue applies to 'get_namespace $P1'
too. OTOH the aliasing example explicitely includes 'perl6' as toplevel
namespace component. I'm missing some consistency here. Are only
{find,store}_global relative to 'HLL::'?
2)
Default Namespace
The default namespace PMC will implement Parrot's current behavior.
The current implementation allows a nested namespace and a variable to
have the same name (via the hack of prepending \0 to namespace names).
Assuming that this hack should go away, I see two ways to continue
implementation:
a) Parrot's default namespace is untyped (raw). This means that a
variable/subroutine can't have the same name as a namespace. This could
break existing code.
b) Otherwise, Parrot's namespace is (half-)typed, at least namespace and
variable/sub are allowed to coexist with the same name. [1]
3) Parrot's internal namespace needs a name ('parrot', 'core' or whatever).
4) Where are all the Parrot libraries living: PGE, Getopt, Data, Digest,
...? Below the 'parrot' namespace? Toplevel? 'Lib'?
5) Has the namespace root a name?
$P0 = ns.'name'()
$S0 = join '::', $P0 # '::parrot::Foo'
or should the toplevel be excluded by 'name'?
Thanks for clarification,
leo
[1] This needs 2 storage slots per hash bucket, at least one more
indirection to access items. A fully typed namespace with 4 slots (raw,
namespace, var, sub) is then not more complicated to implement.
unused unimplemented opcodes
There are some opcodes in core.ops which don't do anything: I'd do: setline ... delete, doesn't make sense getline ... move to debug.ops, implement it setfile ... delete getfile ... mpve to debug.ops, implement it setpackagedelete getpackagedelete - use get_namespace instead Any objections? leo
Re: unused unimplemented opcodes
On Wed, Mar 08, 2006 at 05:16:37PM +0100, Leopold Toetsch wrote: There are some opcodes in core.ops which don't do anything: I'd do: setline ... delete, doesn't make sense getline ... move to debug.ops, implement it setfile ... delete getfile ... mpve to debug.ops, implement it setpackagedelete getpackagedelete - use get_namespace instead Any objections? Please chainsaw away! Steve Peters [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Backwards (?) kwalitee definition on qa.perl.org
On 2005-07-09, Nik Clayton [EMAIL PROTECTED] wrote: http://qa.perl.org/phalanx/kwalitee.html says: What is kwalitee? Kwalitee is inexact quality. We don't know exactly what it is, but we know it when we see it. Isn't that backwards? I thought 'kwalitee' was supposed to be a metric that was exact, and that (hopefully) had some correlation with 'quality'. The whole point is that 'kwalitee' is objectively measurable, while 'quality' isn't. I agree it could be improved. Here's a suggested refactoring: Kwalitee are precise metrics which strive to approximate quality. The name is intentionally different to convey that Kwalitee is related to quality, but not quite the real thing. That's because we don't know exactly what quality is, but we know it when we see it. Mark
Re: Backwards (?) kwalitee definition on qa.perl.org
On Wednesday 08 March 2006 13:15, Mark Stosberg wrote: Kwalitee are precise metrics which strive to approximate quality. The name is intentionally different to convey that Kwalitee is related to quality, but not quite the real thing. That's because we don't know exactly what quality is, but we know it when we see it. That's better. It might also be nice to admit that automated processes can measure Kwalitee, but not Quality. -- c
Re: unused unimplemented opcodes
Leopold Toetsch [EMAIL PROTECTED] wrote: There are some opcodes in core.ops which don't do anything: I'd do: setline ... delete, doesn't make sense getline ... move to debug.ops, implement it setfile ... delete getfile ... mpve to debug.ops, implement it Where getline and getfile refer to the PIR debug seg info, right? Anyway, all sounds pretty sane to me. setpackagedelete getpackagedelete - use get_namespace instead Agree. IMHO, etc. Jonathan
Re: Integer types (was Re: early draft of I/O PDD)
Leopold Toetsch [EMAIL PROTECTED] wrote: Yup, and I really, really don't like the idea of making our bytecode format non-portable. Part of the point of having a VM is portability, right? The described mapping doesn't have any PBC portability issues AFAIK. If 'L' is mapping to 'I' or not is chosen at runtime. Wouldn't the required re-writing blow away the wins we get through mmap'ing in bytecode files? Not that JIT doesn't hurt a little there anyway, but at least you can choose not to do that if you care about memory usage more than speed... Jonathan
Re: Parrot 0.4.2 GPW Released!
I tried upgrading my gentoo box from parrot 0.4.0 to 0.4.2 by copying
the ebuild for 0.4.0 to 0.4.2 and emerging that.
It failed in the make install phase when it tried to install the
installable_ files to the live filesystem rather than to the install
target tree.
The ebuild calls make install with args that result in this invocation
of install_files.pl:
,
| /usr/bin/perl5.8.8 tools/dev/install_files.pl \
| --buildprefix=/portage/parrot-0.4.2/image/ \
| --prefix=/usr/lib/parrot-0.4.2 \
| --exec-prefix=/usr/lib/parrot-0.4.2 \
| --bindir=/usr/lib/parrot-0.4.2/bin \
| --libdir=/usr/lib/parrot-0.4.2/lib \
| --includedir=/usr/lib/parrot-0.4.2/include \
| --destdir= \
| --docdir=/usr/lib/parrot-0.4.2/share/doc/parrot \
| MANIFEST MANIFEST.generated
`
Running that with --dry-run=1 results in this at the end:
,
| ...
| runtime/parrot/library/parrotlib.pbc -
/portage/parrot-0.4.2/image/usr/lib/parrot-0.4.2/lib/parrot/library/parrotlib.pbc
| runtime/parrot/library/pcre.pbc -
/portage/parrot-0.4.2/image/usr/lib/parrot-0.4.2/lib/parrot/library/pcre.pbc
| installable_disassemble - /usr/lib/parrot-0.4.2/bin/disassemble
| installable_disassemble.exe - /usr/lib/parrot-0.4.2/bin/disassemble.exe
| ...
`
As you can see, the installable files are not prefixed by the value of
the --buildprefix as every other file in the MANIFEST.generated is.
The install_files.pl in 0.4.0 lacked @installable_exe and just
used @files. Just before pushing to @files, this is run:
,
| $dest = File::Spec-catdir($options{buildprefix}, $dest)
| if $options{buildprefix};
`
but that is not run before pushing to @installable_exe.
I see that --destdir was also added since 0.4.0, and changing the
ebuild to use DESTDIR=${D} instead of BUILDPREFIX=${D} does allow
the install to complete. But I wonder what the correct results
should be when both DESTDIR and BUILDPREFIX are specified to make?
-JimC
--
James H. Cloos, Jr. [EMAIL PROTECTED]
Re: Integer types (was Re: early draft of I/O PDD)
On Mar 8, 2006, at 22:55, Jonathan Worthington wrote: The described mapping doesn't have any PBC portability issues AFAIK. If 'L' is mapping to 'I' or not is chosen at runtime. Wouldn't the required re-writing blow away the wins we get through mmap'ing in bytecode files? There isn't any rewriting required. E.g. I0 is represented as a plain int '0' in the PBC, that's absolutely the same as, how 'S0', 'N0', or 'P0' are represented. A proper location in the register storage is selected at runtime according to the register type and the register number. The same would be true for a new register type 'L'. Jonathan leo
Re: best way to migrate to Test::WWW::Selenium ?
On Mon, Mar 06, 2006 at 02:50:17PM +, Mark Stosberg wrote: I've got a test suite built with Selenium, but I would like to the output in TAP to centralize the reporting, perhaps using Smolder once I Smolder installed. Great idea. I just looked at Smolder and it seems awesome. I'm excited about hooking this stuff up to it. It appears that Test::WWW::Selenium wants all the tests to be rewritten in Perl. It does. Is there a simple way to get TAP output starting with a Selenium test suite, or is some rewrite/conversion process needed first? I just added a script to Test-WWW-Selenium (the creatively titled script/convert-wiki-to-perl.pl) that will read your .wiki file and then create a perl test script using Test::WWW::Selenium. The test script tries to launch a browser on your box and point it at your selenium install. You'll need to setup /selenium on your AUT and have /selenium/driver a CGI script to handle the driven mode requests. (See script/driver.cgi for an example). Give it a try and send me your feedback. Cheers, Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
