[perl #36695] t/src failures after make shared
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36695] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36695 > --- osname= linux osvers= 2.4.27-ti1211 arch= i386-linux-thread-multi cc= cc --- Flags: category=core severity=low ack=no --- After running make shared, make test fails nearly all of the t/src tests with errors like the following: # Failed test (t/src/exit.t at line 21) # got: './t/src/exit_1: error while loading shared libraries: libparrot .so: cannot open shared object file: No such file or directory # ' # expected: 'pre-exit # ' # './t/src/exit_1' failed with exit code 127 t/src/exit.NOK 1 This seems to be because the dynamic library search path isn't set at runtime, only compile-time. On Linux (the platform I'm using), this can be done by setting LD_LIBRARY_PATH to include blib/lib --- Summary of my parrot 0.2.2 (r8738) configuration: configdate='Sat Jul 30 02:14:49 2005' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lpthread -lcrypt -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=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELC_CTYPELD_LIBRARY_PATHLOGDIRPATH PERL5LIBPERL5_CPANPLUS_CONFIGSHELL
[perl #36728] [PATCH] pmc2c.pl currently does not allow absolute paths
# New Ticket Created by Roland Illig
# Please include the string: [perl #36728]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36728 >
... when searching files. I needed this patch to build parrot-0.2.2 with
pkgsrc (http://www.pkgsrc.org/).
Roland
$NetBSD$
--- build_tools/pmc2c.pl.orig Mon Jun 6 08:22:48 2005
+++ build_tools/pmc2c.plMon Aug 1 01:06:27 2005
@@ -269,6 +269,10 @@ main();
sub find_file {
my ($include, $file, $die_unless_found) = @_;
+if (File::Spec->file_name_is_absolute($file) && -e $file) {
+return $file;
+}
+
foreach my $dir ( @$include ) {
my $path = File::Spec->catfile( $dir, $file );
return $path if -e $path;
Re: $arrayref.ref?
Hi,
Larry Wall wrote:
> On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote:
> : http://use.perl.org/~autrijus/journal/25337:
> : > deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception
> :
> : my $arrayref = [1,2,3];
[...]
> : say $arrayref.isa("Ref"); # true or false?
>
> False, though tied($arrayref).isa("Ref") is probably true.
hm? I've probably misunderstood something, but I don't see any tied
variables in the snippet above -- so why should we use tied() to get at
the non-autodereffing ref of an autodereffing ref?
I thought tieing is a way to intercept further assignments -- i.e.
$some_tied_variable = ...;
will call user-defined code.
But this is not the case when dealing with simple references, right?
my $arrayref = [1,2,3];
# $arrayref contains an autodereffing Ref of Array now.
$arrayref = 42;
# $arrayref contains a simple Num now.
# The [1,2,3], which was previously stored in $arrayref,
# does not "notice" the new assignment.
Thus I propose we use tied() only to get at the underlying real contents
of a tied variable, and use
get_non_autodereffing_ref_out_of_autodereffing_ref() (with a shorter
name, of course), to convert an autodereffing ref to a
non-autodereffing ref.
my $arrayref = [1,2,3];
$arrayref.isa(Ref); # false
tied($arrayref); # error/undef
get_non_autodereffing_ref_out_of_autodereffing_ref($arrayref).isa(Ref);
# true
Opinions?
--Ingo
--
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD | understand recursion.
Athlon!|
Hoisting lexical declarations
Pugs did not support inline variable declarations, largely because the problem
caused by this construct:
{
say "values of β will give rise to dom!";
$x = $x + my $x if $x;
#1 #2 #3#4
}
The evaluation order for the four $x is (#4, #2, #3, #1). However, because
$Larry made it very clear that lexical scopes are lexical, (#1, #2) must refer
to the same (outer) $x, and (#3, #4) refers to the inner $x. When implemented
naively, this creates fragmented scopes in the PIL tree.
To simplify code generation, I propose that we float all lexical declarations
in a scope to the top of the scope, in the same place as its formal
parameters. Of course, we will still reject bogus programs like this:
# No previous $x available here
{ say $x; my $x; }
But that means these now raises the same exception:
sub f ($x) { my $x }
sub f { my $x; my $x }
Alternatively, this could raise a warning and treat the second my()
as a no-op. Personally, I'm in favour of an exception.
Under this scheme, the compiler will mark variable lookups to the outer
scope explicit. The sample construct at the beginning of this post will
get compiled to this form, leaving the evaluation order explicit:
CODE(
syms => [$x],
body => [
SAY("values of β will give rise to dom!"),
IF(
cond => $x,
body => ASSIGN(
from => ADD(
l => $OUTER::x,
r => $x,
),
into => $OUTER::x
)
);
]
);
The only problem I see with it is that $CALLER::x from &ADD's position
will refer to the inner, not the outer, $x. However, seeing that the two
arguments are in different scopes, I think it is not worth keeping any promise
about interaction between $CALLER:: and mid-block declarations anyway.
Does this sound sane?
Thanks,
/Autrijus/
pgp5Nvjf0RpOJ.pgp
Description: PGP signature
zip with ()
Hi, I tried zip under pugs. my @odd = (1, 3, 5, 7); my @even = (2, 4, 6, 8); my @bothA = zip @odd, @even; print @bothA; This code prints 12345678 as expected. After parenthesis were used to group zip arguments, results changes to 13572468. Is it right? -- ___ Andrew, [EMAIL PROTECTED] ___
Re: Curious use of .assuming in S06
On 7/29/05, Autrijus Tang <[EMAIL PROTECTED]> wrote: > In S06's Currying section, there are some strange looking examples: > > &textfrom := &substr.assuming(:str($text) :len(Inf)); > > &textfrom := &substr.assuming:str($text):len(Inf); > > &woof ::= &bark:(Dog).assuming :pitch; > > Why is it allowed to omit comma between adverbial pairs, and even > omit parens around method call arguments? Is .assuming a special form? I don't think you can pass pairs without parens on method calls that way. However, omitting commas between argument pairs has been a main idea from the beginning of the colon pair syntax. Luke
Re: Messing with the type heirarchy
Luke Palmer wrote: Everything that is a Num is a Complex right? Not according to Liskov But this is one of the standard OO >>paradoxes, and we're hoping roles are the way out of it. Well, everything that is a Num is a Complex in a value-typed world, which Num and Complex are in. I don't like reference types much (though I do admit they are necessary in a language like Perl), and I'm not sure how this fits there anymore. Anyway, that's beside the point, since a supertyping need is still there for referential types. Doesn't the problem largely go away if we allow Num to be a more general numeric type, and introduce, say, Real for the more constrained set of numbers that Num currently represents. Of course, if it were truely the most general, then it'd permit quaternions, etc., but I think that most people would be happy for Num to be a simplest possible complete arithmetic type.
Stringification of pairs
Hi, quick question: my $pair = (a => 1); say ~$pair; I assume that outputs "a\t1", because of the "pairs can pretend to be one-element hashes"-rule. Correct? --Ingo -- Linux, the choice of a GNU | We are Pentium of Borg. Division is futile. generation on a dual AMD | You will be approximated. Athlon!|
Eliminating &{} and *{}
Under my current design of containers (see "definition of containers" on
p6c), there are only Scalar, Array and Hash containers. This is in
accordance to them being the only first-class data structures that deals
with mutable data storage.
This is similar to JVM's division between scalar data and collection data;
it's just Perl 6 introduces two collections with differnet interfaces.
With the elimination of the * sigil and the *{} dereferencer, the only
unresolved sigil type is &. Unlike collections, it is really difficult
to tell the difference between $code and &{$code}. Moreover, it makes
little sense to say:
tie(&code, TiedCode);
Since it is much easier to just wrap the &code in place.
All this led us to think about whether (my &foo) can be merely treated
the same as (my Code $foo). The mutable form will enable convenient
notations such as:
&foo = sub { ... };
So instead of having to explain to newcomers that you cannot assign
to a &-sigil symbol, it would all just work. Under this view, &{$x}
would be eliminated with *{}.
Another idea is to treat (my &foo) the same way (my Code $foo is constant).
That will discourage people into assigning into functions, and enable
the compiler to detect function variables at lvalue position as errors,
but on the whole I don't think it's worth the complexity.
Does this make sense?
Thanks,
/Autrijus/
pgp8rJ03TtMzH.pgp
Description: PGP signature
Re: Accessing Hash with strings/keys
Klaas-Jan Stol wrote: Leopold Toetsch wrote: By far the simplest thing is either look at the opcode in ops/core_ops.c or use a debugger and set a breakpoint at the appropriate opcode, e.g. So, apparently, it seems to me the get_pmc_keyed method is called. Yep .. I tried to run the Parrot Debugger (pdb), but I get this: pdb is useless for such things - I ment of course gdb or some such i.e. an executable debugger. klaas-jan leo
new Super PMC
I've added a new Super PMC to trunk (branches/leo-ctx5 will be updated accordingly soon). SYNOPSIS .sub meth method .local pmc s s = new .Super, self s."meth"() .end Works of course only, if self's class has a parent. See also perldoc classes/super.pmc and t/pmc/object-meths.t leo
Re: Accessing Hash with strings/keys
Leopold Toetsch wrote:
On Jul 29, 2005, at 10:38, Klaas-Jan Stol wrote:
Anybody an idea what I'm doing wrong here?
By far the simplest thing is either look at the opcode in
ops/core_ops.c or use a debugger and set a breakpoint at the
appropriate opcode, e.g.
Parrot_set_p_p_kc (or _kic)
From ops/set.ops, I can see:
=head2 Keyed get operations: Ax = Px[ KEY ]
=item B(out PMC, in PMC, in KEY)
inline op set (out PMC, in PMC, in KEY) :base_core {
$1 = $2->vtable->get_pmc_keyed(interpreter, $2, $3);
goto NEXT();
}
So, whenever an instruction like "Ax = Px[KEY]" is executed,
get_pmc_keyed() is called from the vtable of $2, in my case the Hash
PMC. This .ops file is preprocessed to a C file, which in fact says the
same thing:
from ops/core_ops.c, I found:
opcode_t * Parrot_set_p_p_k (opcode_t *cur_opcode, Interp * interpreter);
opcode_t *
Parrot_set_p_p_k (opcode_t *cur_opcode, Interp * interpreter) {
#line 516 "ops/set.ops"
PREG(1) = VTABLE_get_pmc_keyed(interpreter, PREG(2), PREG(3));
return (opcode_t *)cur_opcode + 4;
(the same is true for Parrot_set_p_p_kc)
So, apparently, it seems to me the get_pmc_keyed method is called. I
tried to run the Parrot Debugger (pdb), but I get this:
PackFile_unpack: Bytecode not valid for this interpreter: fingerprint
mismatch
Parrot VM: Can't unpack packfile .//./tabletest.pbc.
So unfortunately, this doesnt' work currently (at least, here it
doesnt'). I couldn't find any more instructions on running the pdb
except in the docs section. Maybe I'm doing something wrong/forgetting
something?
and step on from there
(The keyed_str variants are only used internally to avoid constructing
key PMCs at runtime. For opcodes this isn't a problem because these
key pmcs are created just once at PBC load tine)
Thanks,
klaas-jan
leo
klaas-jan
Re: Test::Harness::Straps - changes?
On 30 Jul 2005, at 17:19, chromatic wrote: (BTW chromatic: I'm curious why you didn't break todo tests into separate passing/failing classes as you did the "normal" test?) TAP doesn't, so I didn't see any reason to do it. Well, I don't really see that TAP separates pass/fail todo tests any less than it separates pass/fail todo tests: ok 1 not ok 2 ok 3 # TODO not ok 4 # TODO so if you're splitting one up it seems sensible to split both Now that you mention it, reporting unexpected successes might be worthwhile -- but then again, Test::Harness::Straps reports that as a bonus in the summary anyway. I can't think of anything useful to do with it, but if there is something, I'm happy to make that separation. For me it would be useful since my normal view of test results separates them into three groups 1)Expected behaviour (passing tests, failing todo tests) 2)Stuff I need for information (skipped tests, just in case they shouldn't be) 3)Unexpected behaviour (failing tests, passing todo tests) Not being able to split passing/failing todo tests with polymorphism seems odd. In fact, in Perl 6, could I separate (1) and (3) by adding expected/ unexpected roles/traits/whatever? Adrian
Re: Where's the no-op?
On Jul 31, 2005, at 8:08, [EMAIL PROTECTED] wrote: I think I might have gotten my x86-64 code generator up in the most minimal sense possible. Great. Unfortunately, I discovered Parrot doesn't have a no-op in the pasm syntax! Sure it has: $ find docs -name '*.pod' | xargs grep -w noop docs/jit.pod: ... docs/ops/core.pod:=item B() It's defined in core.ops leo
