Re: [perl #31493] Overlapping memory corruption
Steve Fink wrote: Hey, your reason is much better than my reason. Still, why do the _noinit stuff and duplicate the creation code? Why not just call pmc_new as in my replacement code? C would create a Hash already. But the clone has to create one of the source type, which might not be quite the same. leo
New calling scheme (was: GC bug triggered in examples/streams?)
Dan Sugalski wrote: At 6:40 PM +0200 9/8/04, Leopold Toetsch wrote: [ register backing stacks ] > The register spilling code could easily use them See 1) below That makes the interpreter unbearable slow and non-competitive. That's the reason for my alternate calling scheme proposal. Then we put it in and deal with it. It must be in to express the semantics properly. After its in we can see what we have to do to make it fast. I see two possible ways to go: 1) Indirection of register pointer(s) * needs copying of context * no copying of registers, just advance/restore a base-pointer ? could allow interpreter->bp->xxx_reg[-n] to access function args - else copying of function args/return values needed + register range could be adjusted to needed amount - overhead of call/return increases with context size - coroutines need separate register stack - indrection in register access + prederef can get rid of indirection, but needs to be redone, if function is called at different stack depth ? 1 one 4 base pointers - using only one would simplify JIT 2) Swapping in and out whole interpreter structures * needs copying of function arguments and return values * the interpreter is the context + no copying of context for function returns + no indirection for register access + coroutines are simple - recursion needs a new interpreter structure per nesting - overhead of call/return increases with argument count - register spilling not addressed leo
Re: Reverse .. operator
On Fri, Sep 03, 2004 at 08:09:23AM -0400, Joe Gottman wrote: > > > > -Original Message- > > From: Larry Wall [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 02, 2004 8:41 PM > > To: Perl6 > > Subject: Re: Reverse .. operator > > > > On Thu, Sep 02, 2004 at 08:34:22PM -0400, Joe Gottman wrote: > > : Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? [...] > > : @foo = reverse (1 ..5); > > : > > : but this has the major disadvantage that it cannot be evaluated lazily; > > : reverse has to see the entire list before it can emit the first element > > of > > : the reversed list. > > > > I don't see any reason why it can't be evaluated lazily. The .. produces > > a range object that gets shoved into the lazy list that gets bound to > > the slurp array of reverse(). If you pop that, there's no reason it > > couldn't go out and ask the end of the lazy list for its last element. > > Just have to make .. objects smart enough to deal off either end of > > the deck. > >I get it. One way to implement this would to give the .. object a > .reverse member iterator that lazily iterates from right to left, Hey look: bidirectional iterators. Cool. ;> --Dks
Re: Parrot 0.1.0 still?
Joshua Gatcomb wrote: We haven't had a new release since Feb 29th. Yep. The Plan was to do a release in June. Pie-thon did interfer. Since the usual purpose of a point release is to have features finished and bugs squashed, it may be a good time for another release. I'd say in a month or so. leo
Re: Constant STRINGs from C source
Dan Sugalski wrote: STRING *foo = CONST_STRING(interpreter, "foobar"); One small warning: the CONST_STRING should always be on its own line and not in a multiline C statement. Preprocessors could get confused about the line number, which is used internally in the CONST_STRING macro. leo
Re: No Autoconf, dammit!
At 4:48 PM -0700 9/9/04, Brent 'Dax' Royal-Gordon wrote: Timm Murray <[EMAIL PROTECTED]> wrote: > > *) Person building runs platform-specific script And on VMS you'll need...er...I don't even know *what* incantation you'd need, but I don't think it'd be pretty. @BUILD or possibly @MAKE Horrible, I know. Oh, the pain, the agony! :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: New calling scheme
Leopold Toetsch wrote: 1) Indirection of register pointer(s) [ snip ] - Creating a continuation and returning it to the caller of a subroutine (or storing it in a lexical/global) would need to COW copy the register frame stack, so that the deeper register frame is preserved in the continuation. OTOH with one frame per chunk COW copy isn't needed but is lacking the simplicity of a linear almost endless register store. 2) Swapping in and out whole interpreter structures + Continuations just work fine leo
Re: nci and the running process image
thanks leo -- it worked! i'm still going to keep my wrapper lib around though, just in case there are platforms where this dlfunc trick doesn't work. but that can easily be detected during configuration. -jeff On Fri, 10 Sep 2004, Leopold Toetsch wrote: > Jeff Horwitz wrote: > > > 1. can you still dlopen the running image by passing a NULL string to loadlib? > > No. Didn't work that way, IIRC > > > 2. can you dlsym (via dlfunc) a statically linked function? > > Yes. Pass NULL for the library PMC: > > .sub main @MAIN > .local pmc nul > null nul > .local NCI f > .local pmc io > io = getstdout > f = dlfunc nul, "PIO_puts", "vIPt" > f(io, "Hello\n") > .end > > One caveat: currenty JITted NCI stub creation is currently turned off > and the code in src/nci.c seems to be unable to handle the "I" signature > for passing the interpreter as argument. > > > -jeff > > leo > >
Devel::Cover eating caller() information
I am seeing some weird behavior where Devel::Cover seems to be
removing/consuming information I am trying to extract with caller(). I
have managed to isolate the behavior in a small script, which is
included below.
Anyone else seen this problem before? Am I doing something wrong? Or is
this a limitation of Devel::Cover? Any thoughts?
Thanks,
Steve
Here is the script:
-
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests => 2;
{
package TestCaller;
use strict;
use warnings;
sub throw {
my $self = bless {}, __PACKAGE__;
my $i = 0;
my @stack_trace;
push @stack_trace, [ (caller($i))[0 .. 3] ] while
caller(++$i);
$self->{stack_trace} = [EMAIL PROTECTED];
die $self;
}
}
eval { throw TestCaller };
isa_ok($@, 'TestCaller');
is_deeply([EMAIL PROTECTED]>{stack_trace},
[[ 'main', 'test.pl', 24, '(eval)']],
'... got the stack trace we expected');
1;
-
And here is the output of that script:
-
[:~] stevan% perl test.pl
1..2
ok 1 - The object isa TestCaller
ok 2 - ... got the stack trace we expected
[:~] stevan% perl -MDevel::Cover test.pl
1..2
Devel::Cover 0.47: Collecting coverage data for branch, condition, pod,
statement, subroutine and time.
Selecting packages matching:
Ignoring packages matching:
/Devel/Cover[./]
Ignoring packages in:
.
/Library/Perl
/Library/Perl/darwin
/Users/stevan/Projects/PerlFramework
ok 1 - The object isa TestCaller
not ok 2 - ... got the stack trace we expected
# Failed test (test.pl at line 27)
# Structures begin differing at:
# $got->[0][0] = Does not exist
# $expected->[0][0] = 'main'
# Looks like you failed 1 tests of 2.
Devel::Cover: Writing coverage database to
/Users/stevan/cover_db/runs/1094834470.5906.15059
-- -- -- -- -- --
--
File stmt branch condsubpod time
total
-- -- -- -- -- --
--
test.pl 100.0n/an/a 100.0n/a 100.0
100.0
Total 100.0n/an/a 100.0n/a 100.0
100.0
-- -- -- -- -- --
--
Re: Devel::Cover eating caller() information (even weirder)
When I changed this line:
push @stack_trace, [ (caller($i))[0 .. 3] ] while caller(++$i);
to this (taken straight from Devel::StackTrace):
while ( do { package DB; @DB::args = (); @c = caller($i++) } ) {
push @stack_trace, [ @c[0 .. 3] ];
}
(Note the post-increment of $i instead of the pre-increment)
This makes the Devel::Cover run work, and the plain test fail. So it
seems that maybe Devel::Cover is pushing up the caller() level?
Using the DB package did help though, because even just changing $i to
a post-increment like this:
push @stack_trace, [ (caller($i))[0 .. 3] ] while caller($i++);
did not help, only the addition of the DB package AND the
post-increment made the Devel::Cover run work (but made the normal test
fail).
Anyway, I am still looking.
Steve
On Sep 10, 2004, at 12:50 PM, stevan little wrote:
I am seeing some weird behavior where Devel::Cover seems to be
removing/consuming information I am trying to extract with caller(). I
have managed to isolate the behavior in a small script, which is
included below.
Anyone else seen this problem before? Am I doing something wrong? Or
is this a limitation of Devel::Cover? Any thoughts?
Thanks,
Steve
Here is the script:
-
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests => 2;
{
package TestCaller;
use strict;
use warnings;
sub throw {
my $self = bless {}, __PACKAGE__;
my $i = 0;
my @stack_trace;
push @stack_trace, [ (caller($i))[0 .. 3] ] while
caller(++$i);
$self->{stack_trace} = [EMAIL PROTECTED];
die $self;
}
}
eval { throw TestCaller };
isa_ok($@, 'TestCaller');
is_deeply([EMAIL PROTECTED]>{stack_trace},
[[ 'main', 'test.pl', 24, '(eval)']],
'... got the stack trace we expected');
1;
-
And here is the output of that script:
-
[:~] stevan% perl test.pl
1..2
ok 1 - The object isa TestCaller
ok 2 - ... got the stack trace we expected
[:~] stevan% perl -MDevel::Cover test.pl
1..2
Devel::Cover 0.47: Collecting coverage data for branch, condition,
pod, statement, subroutine and time.
Selecting packages matching:
Ignoring packages matching:
/Devel/Cover[./]
Ignoring packages in:
.
/Library/Perl
/Library/Perl/darwin
/Users/stevan/Projects/PerlFramework
ok 1 - The object isa TestCaller
not ok 2 - ... got the stack trace we expected
# Failed test (test.pl at line 27)
# Structures begin differing at:
# $got->[0][0] = Does not exist
# $expected->[0][0] = 'main'
# Looks like you failed 1 tests of 2.
Devel::Cover: Writing coverage database to
/Users/stevan/cover_db/runs/1094834470.5906.15059
-- -- -- -- -- --
--
File stmt branch condsubpod time
total
-- -- -- -- -- --
--
test.pl 100.0n/an/a 100.0n/a 100.0
100.0
Total 100.0n/an/a 100.0n/a 100.0
100.0
-- -- -- -- -- --
--
Ordinals, Hashes, and Arrays, oh my
On 2004/9/06, Larry Wall wrote:
>Another possibility is that .[] always forces the "normal" view of an
>array as 0-based, and if you want non-0-based arrays you have to use
>the .{} interface instead, on the assumption that strange subscripts
>are more like hash keys than ranges of integers.
That's true. But it's got me thinking about the connection between
arrays and "associative" arrays. In fact, the user doesn't need to know
that a "hash" is implemented with a hash table, and an "array" isn't;
and nothing stops you from using numbers as hash keys. And if you
restrict your "hash" to numeric keys, Perl could notice and optimise it
into an array. (Or integer keys, or positive integers, or a consecutive
range of positive ints)
If we consider a generic "data structure" type (which may or may not be
optimised under the hood for integral indices), then why shouldn't {} be
the "index-by-name" interface, and [] the "index-by-ordinal" interface?
(Does that mean [$x] is just a shorthand for {nth($x)}?)
(Will P6 arrays/hashes have an ".index" method to return what index they
are? Or .index for the ordinal and .key for the name. (Although .key
is perhaps a bit too close to .keys when the member is itself a hash.))
Of course, there is one important difference between arrays and hashes:
arrays are ordered. People do keep asking about ordered hashes, though.
There's no reason you couldn't use ordinals with a hash anyway (the
"order" may not be particularly meaningful, but sometimes you don't care
-- of course, in those cases you'd usually iterate through it, but it
could be handy to be able to say %h[rand(last)] (except that isn't
really quite how you'd say it, but you get the idea)).
Data structures might have default sorting by key (since that's what
arrays have), but you could sort other ways... maybe nth takes a "by"
adverb: "first"="first :by key", vs. "first :by value". Hm, it probably
should take a closure (along the lines of "sort").
Anyway, I'm rambling, but there's something to the idea of Perl offering
some sort of generic "data structure" type...
"my $hash is Struct;" would be the most general, no restrictions on
keys, and no ordering, so Perl is free to use a hash table without
worrying about the order.
"my $array is Struct(keytype=>PosInt, ordering=>keywise)" has keys
restricted to ints, and iterates in order by index, i.e. it's
implemented as an ordinary array (where [$n] and {$n} refer to the same
element).
"Hash" and "Array" types would be shorthand for those kinds of Structs,
but you could define your own by providing suitable shapes and
orderings. (Hm, since Hashes are the most general, they're probably
actually the base type, rather than "Struct", which does sound kinda
silly, and probably sounds sillier if you're not used to C.)
I was also going to suggest an in-between type of structure, like a
Collection in VB, that accepts anything for the key (or some useful
restricted type?) but is ordered (in order of when elements were added).
But I can't think of any character available for the sigil. =)
- David "making a hash of things" Green
Re: No Autoconf, dammit!
On Fri, 10 Sep 2004 09:00:25 -0400, Aaron Sherman wrote (in part): ajs> All of this depends on if Dan was saying "No autoconf RELIANCE, ajs> dammit" or actually "No autoconf, dammit". The first is a reasonable ajs> stance to take given the portability concerns. The second throws away ajs> useful information. >From the perspective of someone who has long experience with autoconf, the second does NOT throw away useful information. It's autoconf itself which does that. [Yes, I do understand what you really meant, but this has finally exceeded my "keep quiet" threshold.] Putting it another way, autoconf has a long history of breaking on less-favoured platforms. When it breaks, it's damnably hard for even an otherwise-knowledgeable (but not autoconf/automake-savvy) end-user to fix the results, or even to give any useful feedback to the development team as to what went wrong. The problem is that, unlike metaconfig, autoconf simply drops things from its generated config.status and config.h files. [The relevant contrast with metaconfig is that it leaves explicit commented-out #undef's of what could have been included, so that you can repair its faulty findings if it gets them wrong.] Thus, to this well-scarred developer, "No Autoconf, dammit!" means this: "Use something that actually WORKS -- which autoconf does NOT!". It's not just a problem when autoconf truly fails. In fact, that's a lot easier to handle. The major pain comes when it thinks it worked, but it got things wrong. A recent case in point went as follows. Autoconf 'said', "You have no usable pthreads interfaces, and no _r reentrant routines." What that really meant was this: "I tried #include'ing and didn't know that I need -D_REENTRANT on your platform for that to work, so I couldn't get my test programmes to compile because my probing is faulty." Sure, I know enough to have been able to fix it. See above about "otherwise-knowledgeable". It should not require a descent into the Black Arts to get configuration probing to tell you what it couldn't figure out. That is the source of my own opposition to the use of autoconf. I suspect that similar experiences are also at least part of Dan's, but I don't *know* that. --s.
Re: Ordinals, Hashes, and Arrays, oh my
On 2004/9/10, [EMAIL PROTECTED] (David Green) wrote:
>If we consider a generic "data structure" type (which may or may not be
>optimised under the hood for integral indices), then why shouldn't {} be
>the "index-by-name" interface, and [] the "index-by-ordinal" interface?
>(Does that mean [$x] is just a shorthand for {nth($x)}?)
Maybe not. You can use an object for a hash key -- it would be
confusing if certain objects (ordinals) got treated specially. (Don't
ask me why you'd want to use an ordinal as a hash name anyway)
Alice could only look puzzled: she was thinking of bidirectional
iterators.
"You are ambivalent," the Knight said in an anxious tone: "let me recite
a poem to comfort you."
"Does it take many keystrokes?" Alice asked, for she had heard a good
deal of Perl poetry.
"It's long," said the Knight, "but above par. Everybody that hears it --
either it brings the tears into their eyes, xor-- '
"Xor what?" said Alice, as the Knight had paused for a bit.
"Xor it doesn't, you know. I call it my %hashdock{5th}."
"Oh, it's the fifth element, is it?" Alice said, trying to keep on-topic.
"No, you don't understand," the Knight said, looking a little vexed.
"That's just what it's *called*. It really is the third one."
"Well, what *is* the poem, then?" said Alice, who by this time was
completely bewildered.
"I was coming to that," replied the Knight. "The poem really is
SCALAR(0x809e94), and the implementation's my own class."
Alice felt her migraine coming back and wished she had paid more
attention when her sister tried to teach her Python.
-David "yes, that's MUCH less confusing!!" Green
Buffered IO and Parrot Forth
I was looking at Parrot Forth tonight and was extremely confused for
the longest time because no prompt was getting printed. I figured I
just didn't know how to use the thing. But that's not the case.
Somewhere, the prompt for the interpreter ("> ") started getting
buffered. It's not printing because the buffer's not getting flushed
out (adding a newline character to the prompt makes it work). I looked
for a flush opcode and didn't see one. What's the proper way to handle
this?
--
matt
