Devel::Cover failure?
The test file below is pared down from Module::Build. The warning from
Crequire comes up in several tests, not always causing test failures.
The same warning appears if you run MakeMaker as shown in the
Devel::Cover docs--it's not specific to Module::Build.
[EMAIL PROTECTED]:~/projects$ module-starter --eumm --mb --module Foo
Created starter directories and files
[EMAIL PROTECTED]:~/projects$ cd Foo
[EMAIL PROTECTED]:~/projects/Foo$ rm MANIFEST t/*
[EMAIL PROTECTED]:~/projects/Foo$ cat t/basic.t
use Test::More tests = 1;
use File::Spec;
require File::Spec-catfile('t', 'common.pl');
ok(1);
[EMAIL PROTECTED]:~/projects/Foo$ cat t/common.pl
1;
[EMAIL PROTECTED]:~/projects/Foo$ perl Build.PL
Creating new 'Build' script for 'Foo' version '0.01'
[EMAIL PROTECTED]:~/projects/Foo$ perl Build test
lib/Foo.pm - blib/lib/Foo.pm
t/basicok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.23 cusr + 0.04 csys = 0.27 CPU)
[EMAIL PROTECTED]:~/projects/Foo$ perl Build testcover
t/basicUse of uninitialized value in require at t/basic.t line 3.
Null filename used at t/basic.t line 3.
# Looks like your test died before it could output anything.
t/basicdubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/basic.t 2 512 12 200.00% 1
Failed 1/1 test scripts, 0.00% okay. 1/1 subtests failed, 0.00% okay.
Re: Key question
Simon Glover [EMAIL PROTECTED] wrote:
Or rather, a question about keys: what should the following two code
snippets do?
1) new P0, .Key
set P0, 1
set N0, P0
print N0
end
2) new P0, .Key
set P0, 1
set I0, P0
print I0
end
At the moment, the first one throws an exception ('Key not a number!'),
while the second one goes into an infinite loop and eventually
segfaults. As I see it, there are three possibilities:
i) In both cases, we throw an exception.
ii) We try to convert the string to an float (or int) using
string_to_num (or string_to_int). [In which case, what
do we do if the string is something like asdf?]
iii) We declare that trying to get numeric information out of
non-numeric keys is undefined behaviour, and so Parrot may do
anything (including segfault).
It's basically ii) Ckey_integer is missing the case of KEY_string_FLAG
so that recursively Cget_integer is called on that key.
But we should generalize keys eventually. Keys can provide an index for
aggregates and allow chaining of indices for nested aggregates. Arrays
are simple: the key is an integer. But hashes currently don't support
non-string keys easily. We should be able to use arbitrary PMCs as
hash keys. The way to go here is to use the VTABLE_hash method to
generate an index aka hash value usable for accessing hashes.
A Key PMC can directly contain one of the Parrot native types I,N,S or
point to a PMC [1].
- the hashval of an Integer is the value
- the hashval of a Float should follow Python semantics. At least
hash(x.0) := hash(x) := x should be given.
- strings with a numerical value should probably hash to that number
- for PMCs the hash function should do the right thing. I.e. if the
PMC is a scalar one of the above rules should be used.
[1] This is currently broken.
Simon
leo
Re: question about TODO improve parrot-config.imc
Peter Christopher [EMAIL PROTECTED] wrote: Hi there, I have a question on the todo item #32365 TODO improve parrot-config.imc. I include the text of the TODO at the bottom of this message. My understanding of this request is this: a) There is a frozen pmc hash of configuration data which comes from the build system (after a good build). Yes b) the author of the TODO wants a means to associate groups of configure data to simple command line arguments. So for example one could write $ c++ `parrot parrot-config.imc --link-time-stuff` parrot_mem.o Yes. parrot-config.imc can extract individual items from the frozen config and print these to stdout. The idea is to extend this functionality to have a tool like gtk-config that easily allows to compile and link extensions to parrot. c) That this TODO *does not* have to do with collecting more data via the build system. (I'm confused about the part that reads But not all information is there or like the icu-libs a bit scattered at the bottom of the ticket). Well, I didn't look too close if something is missing ;) It's probably just a matter of bundling the necessary items. Thanks for the clarification, Pete leo
Re: Key question
Leopold Toetsch wrote: But we should generalize keys eventually. Keys can provide an index for aggregates and allow chaining of indices for nested aggregates. Arrays are simple: the key is an integer. But hashes currently don't support non-string keys easily. We should be able to use arbitrary PMCs as hash keys. The way to go here is to use the VTABLE_hash method to generate an index aka hash value usable for accessing hashes. See: http://xrl.us/emnk Except for fromkeys, get_string, and __new__, the logic is not Python specific, and could easily be refactored into a common base class for others to use. - Sam Ruby
thoughts about types, and possible syntax for code as comment
I expect Perl6 to be a language with a mix of dynamically typed and
statically typed variables. In a purely statically typed language like
OCAML, you generally don't need to declare the type of variables
when it can be inferred. So one can benefit from the speed of static
typing (no type info must be handled at run-time) without the chaff of
often redundant type annotations. This has a price though, when
running into a typing problem, the compiler often gives cryptic errors.
But things are probably more complex in Perl6 with a mixed
static/dynamic type system.
Given the complexity of type inference that makes it indecidable in
many complex case, will it be possible in Perl6 to omit some type
annotation in some declarations and expect the compile to infer the
types at compile time? Probably, this will not be supported in
the early versions of Perl6, but is this something even possible?
With ou without help from the programmer with some sort of pragma?
In many cases, and especially when omitting type annotations, the
programmer need a long and descriptive name for parameters. This
is ackward when the said parameters are heavily used.
The long descriptive name is useful for the declaration but goes
against the Huffman principle.
# with type annotation, it is obvious what $xp is
sub canon( Expr $xp ) { }
# ...not anymore
sub canon( $xp ) { }
# ... so one would use a longer name
sub canon( $expr ) { }
# But sometimes the parameter name conveys more info than restating
# the type; that often means even longer names
sub canon( $subjet, $complement ) { }
sub canon( Expr $subjet, Expr $complement ) { }
To get an huffmanized name and a clear one, I would like some support syntax:
sub canon( $subjet as $s , $complement as $c ) {
# code with lots of $s and $s
}
# or without type annotation
sub canon( Expr $subjet as $s , Expr $complement as $c) { }
One could even drop the sigil in the short form with the signature:
sub canon( $subjet as s , $complement as c ) { }
sub canon( Expr $subjet as s , Expr $complement as c) { }
I could not stress enough the value of code as comment. It cannot fall
so much in touch with reality as code evolve than pure comment always
does. Worse, the ratio code/comment can be such that one cannot get
much real meat in a screenful.
I cross post to perl6-compiler because the question about type
inference in a language which a mix of static/dynamic type is very
much a implementation feasability question. Probably after going thru
Types and programming langauge by Benjamin C. Pierce and learning
about OCAML implementation, I will have a better grasp on type
inference.
--
stef
Re: Devel::Cover failure?
Randy W. Sims wrote:
The test file below is pared down from Module::Build. The warning from
Crequire comes up in several tests, not always causing test failures.
The same warning appears if you run MakeMaker as shown in the
Devel::Cover docs--it's not specific to Module::Build.
[EMAIL PROTECTED]:~/projects$ module-starter --eumm --mb --module Foo
Created starter directories and files
[EMAIL PROTECTED]:~/projects$ cd Foo
[EMAIL PROTECTED]:~/projects/Foo$ rm MANIFEST t/*
[EMAIL PROTECTED]:~/projects/Foo$ cat t/basic.t
use Test::More tests = 1;
use File::Spec;
require File::Spec-catfile('t', 'common.pl');
As a workaround, I've checked in changes from the last line above to:
my $common_pl = File::Spec-catfile('t', 'common.pl');
require $common_pl;
which seems to work fine.
