[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. # URL: 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
Re: Elimination of Item|Pair and Any|Junction
FWIW, I've been reading up on Scala's formulation of trait/class/delegation hierarchy, and I feel a bit like flipping through a puzzle book to look at the hints, if not answers. :-) http://scala.epfl.ch/docu/files/api/index.html I misread mutable as mumble and thought they'd been stumped for a good name too. Brad -- Tether even a roasted chicken. -- Hagakure
[S29] Mutating map and grep
Hi,
according to S29 [1], neither map nor grep allow mutation:
multi sub Perl6::Array::map (@values, Code $expression) returns Lazy
multi sub Perl6::List::map (Code $expression : [EMAIL PROTECTED]) returns
Lazy
multi sub Perl6::Array::grep (@values : Code *test ) returns Lazy
multi sub Perl6::Array::grep (@values, MatchTest $test ) returns Lazy
multi sub Perl6::List::grep (MatchTest $test : [EMAIL PROTECTED]) returns
Lazy
OTOH, Perl 5 did allow it:
my @array = (0, 1, 2, 3);
my @result = map { $_++; 42 } @array;
print @result; # 42424242
print @array;# 1234
Is this a bug in S29 or will this be feature removed from Perl 6
and you'll have to say (for example)
use listops :mutating;
my @result = map { $_++; 42 } @array; # works now
What about reduce? (FWIW, I'd like it to allow mutation.)
What about sort? (FWIW, I'd like it to not allow mutation,
as allowing mutations would probably prevent many
optimizations.)
Opinions?
--Ingo
[1] http://svn.openfoundry.org/pugs/docs/AES/S29draft.pod
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
Re: zip with ()
Hi, Andrew Shitov wrote: 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? Whitespace is significant: say zip @odd, @even;# zip gets two arguments, result is # 12345678. say zip(@odd, @even); # zip gets two arguments, result is # 12345678. say zip (@odd, @even); # zip gets only one argument, the flattened # list (@odd, @even), containing the # elements (1,3,5,7,2,4,6,8). Then zip # tries to zip this one list, resulting in # 13572468. --Ingo -- Linux, the choice of a GNU | To understand recursion, you must first generation on a dual AMD | understand recursion. Athlon!|
Re[2]: zip with ()
Is it possible to avoid significance of whitespaces? I think, such an aspect of Perl 6 would be awful. IB Whitespace is significant: IB say zip(@odd, @even); IB say zip (@odd, @even); -- ___ Andrew, [EMAIL PROTECTED] ___
Re: [S29] Mutating map and grep
HaloO,
Ingo Blechschmidt wrote:
Is this a bug in S29 or will this be feature removed from Perl 6
and you'll have to say (for example)
use listops :mutating;
my @result = map { $_++; 42 } @array; # works now
Why not just
my @result = map - $_ is rw { $_++; 42 } @array; # works now
which could be abbreviated as
my @result = map:rw { $_++; 42 } @array; # works now
And as usual the :rw binding needs the confirmation of @array.
BTW, would the following be parseable in an extreme interpretation of
optionality of block owner and block topic:
my @result = map:rw{ .++; 42 } @array; # ++ as method on owner
my @result = map:rw - { ++; 42 } @array; # ++ as sub with topic
my @result = map:rw - { .++; 42 } @array; # both: $/.++($_)
--
$TSa.greeting := HaloO; # mind the echo!
Re: [perl #36728] [PATCH] pmc2c.pl currently does not allow absolute paths
Roland Illig (via RT) [EMAIL PROTECTED] wrote: ... when searching files. I needed this patch to build parrot-0.2.2 with pkgsrc (http://www.pkgsrc.org/). Thanks, applied (r8761). Jonathan
Re: [S29] Mutating map and grep
Hi,
TSa (Thomas Sandlaß) wrote:
Ingo Blechschmidt wrote:
Is this a bug in S29 or will this be feature removed from Perl 6
and you'll have to say (for example)
use listops :mutating;
my @result = map { $_++; 42 } @array; # works now
Why not just
my @result = map - $_ is rw { $_++; 42 } @array; # works now
right, but IIRC if you omit the signature and the -, you're implicitly
declaring ($_ is rw):
for @array { $_++ } # works
for @array - $_ { $_++ } # error, $_ not rw
for @array - $_ is rw { $_++ } # works
for @array - $a { $a++ } # error, $a not rw
for @array - $a is rw { $a++ } # works
Pugs seems to confirm this:
my $coderef = { $_++ };
my $var = 3;
$coderef($var), # no error
say $var; # 4
If I'm wrong, and $_ is ro by default, then I like your solution very
much, as it makes my intention very clear (look! I'll probably modify
$_ soon!). :)
--Ingo
--
Linux, the choice of a GNU | Knowledge is that which remains when what
generation on a dual AMD | is learned is forgotten. - Mr. King
Athlon!|
Re: zip with ()
HaloO, Andrew Shitov wrote: Is it possible to avoid significance of whitespaces? Yes, with: say zip .(@odd, @even); Looks like a method and *is* a method in my eyes. First zip is looked-up and then bound as block owner. Arguments are of course two array refs to @odd and @even respectively. BTW, you didn't mean originally: say zip (@odd), (@even); # prints 13572468 or 12345678? Does zip now interleave two array refs instead of flattened arrays? I think, such an aspect of Perl 6 would be awful. IB Whitespace is significant: IB say zip(@odd, @even); IB say zip (@odd, @even); -- $TSa.greeting := HaloO; # mind the echo!
Re[2]: zip with ()
TTS BTW, you didn't mean originally: TTSsay zip (@odd), (@even); # prints 13572468 or 12345678? That is exactly like with similar printing result of sub() call: print sqrt (16), 5; # shout print 45. -- ___ Андрей, [EMAIL PROTECTED] ___
Re: zip with ()
HaloO, Ingo Blechschmidt wrote: Whitespace is significant: say zip @odd, @even;# zip gets two arguments, result is # 12345678. say zip(@odd, @even); # zip gets two arguments, result is # 12345678. say zip (@odd, @even); # zip gets only one argument, the flattened # list (@odd, @even), containing the Why flattened? Shouldn't that be *(@odd, @even)? # elements (1,3,5,7,2,4,6,8). Then zip Why not ([1,3,5,7],[2,4,6,8]) list of two array refs? # tries to zip this one list, resulting in # 13572468. If the list of two array refs is not flattened, the result should be 12345678 because how should zip distinguish it from the other cases? The crux of the first case not requiring parens is that zip is declared as listop and as such consumes the @even after the , which otherwise would be left for say. And if say weren't declared/assumed listop, the @even would be evaluated in Void context and not appear in the print at all. Or do I miss something important? E.g. has () become a circumfix deref op? -- $TSa.greeting := HaloO; # mind the echo!
Re: zip with ()
HaloO, Andrew Shitov wrote: TTS BTW, you didn't mean originally: TTSsay zip (@odd), (@even); # prints 13572468 or 12345678? That is exactly like with similar printing result of sub() call: print sqrt (16), 5; # shout print 45. That all hinges on the type of the symbol. I guess sqrt is a unary prefix. Then print sqrt 16, 5; # should print 45 as well. The point is, to not let sqrt 'swallow' the 5 unless it is declared listop. -- $TSa.greeting := HaloO; # mind the echo!
Re: zip with ()
Hi, TSa (Thomas Sandlaß Thomas.Sandlass at orthogon.com writes: Ingo Blechschmidt wrote: say zip (@odd, @even); # zip gets only one argument, the flattened # list ( @odd, @even), containing the Why flattened? Shouldn't that be *(@odd, @even)? IIUC: say zip *(@odd, @even); # zip gets called with the parameters 1, 3, 5, 7, 2, 4, 6, 8. say zip (@odd, @even); # zip gets called with one argument, (1, 3, 5, 7, 2, 4, 6, 8). say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]); # zip gets called with one argument, ([1, 3, 5, 7], [2, 4, 6, 8]). In general, (@foo, @bar) returns a new list with the element joined, i.e. @foo.concat(@bar). If you want to create a list with two sublists, you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED], [EMAIL PROTECTED]). But of course, I could be totally wrong. :) # elements (1,3,5,7,2,4,6,8). Then zip Why not ([1,3,5,7],[2,4,6,8]) list of two array refs? Because you'd have to explicitly take reference to them: say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]). (Can somebody confirm my thoughts?) --Ingo
Re: sub foo ($x) returns ref($x)
HaloO,
Autrijus Tang wrote:
[..] For example, assuming argument types are unified in a single
phase, the example below does nothing useful:
sub equitype ((::a) $x, (::a) $y) { ... }
It won't not help even if we replace the implicit does with of:
sub equitype ($x of (::a), $y of (::a)) { ... }
The reason, in Luke Palmer's words:
The trouble with this is that it doesn't provide any type safety.
In the case of a type conflict, a just degenerates to the Any type.
(cf. pugs/docs/notes/recursive_polymorphism_and_type)
Luke's analysis is indeed correct. And describes what can be inferred
from the caller side. And I wouldn't introduce the subtlety that the
first ::a is bound to the exact type of $x in the call environment, while
the second is a constraint on $y's type. But I would prescribe exactly
this as the meaning if you use plain 'a' as the type of $y. Thus I opt
for:
sub equitype ( ::a $x, a $y) { ... }
which is the same behaviour as for the value of $x which can be used
immediately for subsequent parameter bindings. Hmm, how do coderefs behave
in that respect?
sub codeparam ( foo, ?$val = foo ) {...}
Does this invoke a bar argument once for the call codeparam( bar )
and capture the result in $codeparam::val while the call
codeparam( bar, 42 ) stores 42 without invoking bar through
codeparam::foo? And in which exact environment does a call to
bar take place when needed to bind $val? Purely ::CALLER? Signature
as bound so far? ::OUTER of the use'er of the package which contains
codeparam? Or the ::OUTER of the 'real' package file?
The other remark I have for the form with double ::a is that there's
also an inside view of that type. All type information inferred can
be stored as constraints on ::equitype::a in the ::equitype Code class.
Interesting is how the syntax for a more explicit form reads:
sub equitype( ::a $x, ::a $y ) where { a.does(SomeRole) }
{...}
This fact, coupled with the unappealing (::a) syntax,
I like the syntax. BTW, does it have to have parens?
I would actually promote :: to a very fundamental operator/token.
Even if that costs some parens for the ternary ( ?? :: ).
leads me to look
for a more Perlish representation. Adopting an idea from Odersky's
Nested Types paper, we can let terms occur at type variant position,
by introducing a ref form for types:
sub equitype ($x, $y of ref($x)) { ... }
sub subtype ($x, $y does ref($x)) { ... }
sub identity ($x) returns ref($x) { ... }
Uhh, please make that sig read ($x, type($x) $y) or at least
($x, $y.does($x.type) or something else with 'type' in it.
Ref is way to overloaded with meanings in Perl6 which are not
easy to unify away because of mismatches on the levels of
abstraction involved. E.g. the sub identity looks like an
alias for \ which it isn't from the type perspective.
This reads like Perl, and can be guarded with trivial compile time
and runtime checks. We can also use type selectors to check
that pick can always return Int from an Array[of = Int]:
sub pick (@x) returns ref(@x).of { ... }
The only problem I can find is that the possible confusion between the
ref() operator and the unboxed basic type ref. Another thought is to
simply use ::() as a special ref form:
sub pick (@x) returns ::(@x).of { ... }
But that can confuse with the symbolic dereference syntax. All in all
Uhh, could we agree to call ::(symbolic) the symbolic lookup form and
::bareword the bareword, pre-runtime lookup form?
Let's not add another referencial thing to the 'Many Refs of Perl6'.
In the end we'll need a dedicated reference manual :)
I guess it would be S08.
Since I opt for ::pick beeing the innermost namespace immediately
after its introduction with 'sub pick' ::x could refer to @x from
the signature. Note that if there are x, $x, @x and %x in the
signature a simple ::x is typed as their supertype Object.
Disambiguation would go as ::x::Code, ::x::Item, ::x::Array and
::x::Hash respectively. And of course you can further descent into
these namespaces as in pick::x::Array::of. Descending along multiple
pathes essentially means any'ing the types together ::x::*::of.
Well, in some namespaces things are all'ed together :)
The supertype of all array entries is of course pick::x::Array::values::*
and single items show up numerically under pick::x::Array::values::
e.g. pick::x::Array::values::8. Note that this is *not* a symbolic
form but well defined. It might evaluate to undef though.
Finally the .of method might just be syntactic sugar for the above:
sub pick( @x ) returns @x.of {...}
or just
sub pick( @x ) returns x.of {...}
or
sub pick( @x ) returns x::of {...}
I'm more happy with ref(), but better suggestions welcome.
I suggest type(), tie() or soul()---the latter is from
'.bless() my .soul()'---if none of the above pleases @Larry.
--
$TSa.greeting := HaloO; # mind the echo!
Re: sub foo ($x) returns ref($x)
On Mon, Aug 01, 2005 at 03:16:50PM +0200, TSa (Thomas Sandla�) wrote:
sub equitype ( ::a $x, a $y) { ... }
That's not a bad idea at all. I rather like it. I'd just still like an
explicit type-unifying parens around ::a, just so people won't say
sub foo (::Int $x) { ... }
and accidentally rebind Int.
which is the same behaviour as for the value of $x which can be used
immediately for subsequent parameter bindings. Hmm, how do coderefs behave
in that respect?
sub codeparam ( foo, ?$val = foo ) {...}
Does this invoke a bar argument once for the call codeparam( bar )
and capture the result in $codeparam::val while the call
codeparam( bar, 42 ) stores 42 without invoking bar through
codeparam::foo?
Yes.
And in which exact environment does a call to bar take place when
needed to bind $val? Purely ::CALLER? Signature as bound so far?
::OUTER of the use'er of the package which contains codeparam? Or the
::OUTER of the 'real' package file?
The lexical scope of the sub, with the signature bound so far.
Thanks,
/Autrijus/
pgpO5EjM9ryKW.pgp
Description: PGP signature
A binary testing system with a log of system calls?
Hello, I help test the darcs ( http://www.darcs.net/ ) binary with Perl. The code itself is written in Haskell, but that doesn't matter here. A developer had an interesting request, which I would like to pursue. Where there is a test failure in the Perl test script, he would like to look at a sequence of shell commands that reproduce the issue. So far we are using a mix of Shell::Command http://search.cpan.org/~mschwern/Shell-Command-0.01/lib/Shell/Command.pm and calls to darcs which are wrapped through a darcs() Perl call. Is anything like this out there, before I think about it harder? Thanks! Mark
Re: Garbage Collector API
David Formosa wrote: I can see advantages to both approches. All GC systems have a hit when they run, in some situations it would be nice to shift the hit to times when it doesn't mattor that much. For example a GUI app may delay the GC till when the user has been idle for a while. Has any thought been given to using a concurrent garbage collector for Perl6? Besides eliminating GC pauses (which in turn means less of a need for users to fiddle with the GC settings, and therefore a smaller chance of accidently screwing it up), it might be one of the easier sources of parallelism to exploit on multi-processor machines. And it could open the door for more soft realtime applications in Perl (audio processing, games, etc.). Thoughts? Greg Buchholz
Re: zip with ()
On 8/1/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
In general, (@foo, @bar) returns a new list with the element joined,
i.e. @foo.concat(@bar). If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
[EMAIL PROTECTED]). But of course, I could
be totally wrong. :)
I think that's right. However, it might be a good idea not to
auto-enreference such bare lists:
sub foo ($x) {...}
foo (1,2,3,4,5); # foo gets called with [1,2,3,4,5]
When you could just as easily have said:
foo [1,2,3,4,5];
And we'll probably catch a lot of Perl 5 switchers that way. That
actually makes a lot of sense to me. The statement:
my $x = (1,2,3,4,5);
Looks like an error more than anything else. That's the scalar
comma, which has been specified to return a list. But maybe it
should be an error. The main reason that we've kept a scalar comma is
for:
loop (my $x = 0, my $y = 0; $x*$y = 16; $x++, $y++)
{...}
However, I think we can afford to hack around that. Make the first
and last arguments to loop take lists and just throw them away. Can
anyone think of any other common uses of the scalar comma?
Luke
Re[2]: zip with ()
LP my $x = (1,2,3,4,5); LP Looks like an error more than anything else. 'Perl 6 and Parrot Essentials' think different ;-) -- ___ Andrew, [EMAIL PROTECTED] ___
Re: Garbage Collector API
On Mon, Aug 01, 2005 at 08:46:07 -0700, Greg Buchholz wrote: Has any thought been given to using a concurrent garbage collector for Perl6? Besides eliminating GC pauses (which in turn means less of a need for users to fiddle with the GC settings, and therefore a smaller chance of accidently screwing it up), it might be one of the easier sources of parallelism to exploit on multi-processor machines. And it could open the door for more soft realtime applications in Perl (audio processing, games, etc.). Well, the reason an API based on what an object requires, not how it gets it is better is that it doesn't matter - the GC could be a separate thread, and GC::timely could just be a blocking call to the GC thread asking it to check of the said object needs to be collected or not. This could be optimized for latency, so that just the critical objects are checked first, and then everything is cleaned up in the background. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpFCwFyVlXJl.pgp Description: PGP signature
Re: Garbage Collector API
On Mon, 01 Aug 2005 22:08:52 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] On Mon, Aug 01, 2005 at 08:46:07 -0700, Greg Buchholz wrote: Has any thought been given to using a concurrent garbage collector for Perl6? Besides eliminating GC pauses (which in turn means less of a need for users to fiddle with the GC settings, and therefore a smaller chance of accidently screwing it up), it might be one of the easier sources of parallelism to exploit on multi-processor machines. And it could open the door for more soft realtime applications in Perl (audio processing, games, etc.).=20 Well, the reason an API based on what an object requires, not how it gets it is better is that it doesn't matter - Then what I was calling GC::exclude(CODE) should be called GC::nodelay(CODE) . ie I'm requesting that the Garbiage collector doesn't cause a pause while CODE is being executed. And leave the reson why a pause doesn't happen to the implementor of the GC. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: Complete type inferencing
1. Asserted
The usual case for Perl 6 functions, due to its default Item
signature for parameters. In the example below, I assume that ::* cannot
be changed freely to do away with ::*IO at runtime. (If it could, then
assertions won't be of much use in general.)
sub f (IO $x) { $x.close }
f(open('/etc/passwd'));
As both f and open may be rebound at runtime, we cannot guarantee that
this will not go wrong. However, we can insert an runtime assertion for
$x
in f's scope, so we can avoid doing the same assertion in *IO::close
again. If IO is declared as final, then *IO::close can also be resolved
statically.
Could this be implemented optimistically, with disabled
assertions which are enabled at runtime if either f or open
are rebound?
I hope I've understood your point correctly.
Brad
PS. I'm not on p6c
--
To treat a person harshly is the way of middle-classed lackeys.
-- Hagakure http://bereft.net/hagakure/
[patch at 5978] make @*ARGS processing a bit better in PUGS
Attached tiny modification makes options to be not parsed after --,
and removes treating of -foo as -f
Vadim.
--- Args.hs.orig2005-07-07 20:14:00.0 +0400
+++ Args.hs 2005-08-02 06:35:49.383288368 +0400
@@ -54,7 +54,7 @@
unpackOptions :: [String] - [String]
unpackOptions [] = []
unpackOptions (('-':[]):rest) = [-] ++ unpackOptions rest
-unpackOptions (--:opts) = opts
+unpackOptions (--:opts) = [--] ++ opts
unpackOptions (('-':opt):rest) = unpackOption opt ++ unpackOptions rest
unpackOptions (filename:rest) = filename : unpackOptions rest
@@ -135,7 +135,8 @@
gatherArgs(-B:backend:rest) = [Opt -B backend] ++ gatherArgs(rest)
gatherArgs(-V::item:rest) = [Opt -V: item] ++ gatherArgs(rest)
gatherArgs(('-':[]):xs) = [File -] ++ gatherArgs(xs)
-gatherArgs(('-':x):xs)= [Switch (head x)] ++ gatherArgs(xs)
+gatherArgs((--):rest) = [File x | x - rest]
+gatherArgs(('-':x:[]):xs) = [Switch x] ++ gatherArgs(xs)
gatherArgs(x:xs) = [File x] ++ gatherArgs(xs)
{- collect -e switches together,
Re: Complete type inferencing
On Tue, Aug 02, 2005 at 12:49:06PM +1000, Brad Bowman wrote:
1. Asserted
The usual case for Perl 6 functions, due to its default Item
signature for parameters. In the example below, I assume that ::*
cannot
be changed freely to do away with ::*IO at runtime. (If it could, then
assertions won't be of much use in general.)
sub f (IO $x) { $x.close }
f(open('/etc/passwd'));
As both f and open may be rebound at runtime, we cannot guarantee that
this will not go wrong. However, we can insert an runtime assertion
for $x
in f's scope, so we can avoid doing the same assertion in *IO::close
again. If IO is declared as final, then *IO::close can also be
resolved
statically.
Could this be implemented optimistically, with disabled
assertions which are enabled at runtime if either f or open
are rebound?
Yes, it is conceivable to hoist assertions whereever possible, and
reactivate them if the earlier assertion no longer hold due to rebind.
I'll prototype it a bit and see if it works.
Thanks,
/Autrijus/
pgpR7u66MSM2S.pgp
Description: PGP signature
