Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 9 Sep 2003, Gordon Henriksen wrote:
Random thought
There's some discussion on perl-qa right now about how Test::More
should implement is_deeply, which executes a code block and tests
that the return value is equivalent to a
On Tue, 9 Sep 2003, Gordon Henriksen wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 9 Sep 2003, Gordon Henriksen wrote:
Random thought
There's some discussion on perl-qa right now about how Test::More
should implement is_deeply, which executes a code block and tests
Garrett Goebel wrote:
Nicholas Clark wrote:
Garrett Goebel wrote:
Leopold Toetsch wrote:
Garrett Goebel [EMAIL PROTECTED] wrote:
As I was googling to see how other people have approached
these problems I ran across:
Random thought
There's some discussion on perl-qa right now about how Test::More should
implement is_deeply, which executes a code block and tests that the
return value is equivalent to a particular nested data structure. (The
question posed on that list is with regard to how to handle
On Tue, 9 Sep 2003, Gordon Henriksen wrote:
Random thought
There's some discussion on perl-qa right now about how Test::More should
implement is_deeply, which executes a code block and tests that the
return value is equivalent to a particular nested data structure. (The
question posed
Nicholas Clark wrote:
Garrett Goebel wrote:
Leopold Toetsch wrote:
Garrett Goebel [EMAIL PROTECTED] wrote:
As I was googling to see how other people have approached
these problems I ran across:
http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx/CLR
What did you
On Sep-08, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
On Fri, 5 Sep 2003, Peter Haworth wrote:
With the seen hash approach, I wouldn't expect the hash itself to take
nearly as much space as the frozen
On Sunday, September 7, 2003, at 06:21 , Nicholas Clark wrote:
On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
On Fri, 5 Sep 2003, Peter Haworth wrote:
With the seen hash approach, I wouldn't expect the hash itself to
take nearly as much space as the frozen structure;
My
Steve Fink [EMAIL PROTECTED] wrote:
On Sep-08, Leopold Toetsch wrote:
Parrot has some DOD counters for possibly active PMCs. A simple and
probably fix-sized[1] hash based on such a count with just a mapping of
{pmc = id} takes 12 bytes per entry on 32-bit architecures and its
really fast.
On Monday, September 8, 2003, at 03:34 , Steve Fink wrote:
On Sep-08, Leopold Toetsch wrote:
I don't know why Storable.xs is using a general HV for mapping an
address to an integer (more isn't needed to serialize all IMHO - Dan's
next_for_GC approach doesn't provide more info). Perl5 does
At 8:56 PM -0600 9/4/03, Luke Palmer wrote:
Gordon Henriksen writes:
What you're suggesting also has significant side-effects: It halts
hypothetical multithreaded programs, suspends DoD, prevents the
traversal mechanism from calling back into parrot code, requires
fine-grained locks which are
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
On Fri, 5 Sep 2003, Peter Haworth wrote:
With the seen hash approach, I wouldn't expect the hash itself to take
nearly as much space as the frozen structure;
My experience tracing
On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
On Fri, 5 Sep 2003, Peter Haworth wrote:
With the seen hash approach, I wouldn't expect the hash itself to take
nearly as much space as the frozen structure;
My experience tracing variable graphs in Perl 5 indicates otherwise.
On Thu, Sep 04, 2003 at 08:43:50AM -0500, Garrett Goebel wrote:
Leopold Toetsch wrote:
Garrett Goebel [EMAIL PROTECTED] wrote:
As I was googling to see how other people have approached
these problems I ran across:
http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx/CLR
On Thursday, September 4, 2003, at 10:56 , Luke Palmer wrote:
Is there a problem with providing a mechanism which would suspend all
threads except for the current one, as to ensure that the serialize
operates, er, serially. Could it be implemented with a top-priority
event post that acquires
On Thu, 4 Sep 2003 09:02:18 -0400 (EDT), Dan Sugalski wrote:
On Wed, 3 Sep 2003, Gordon Henriksen wrote:
A seen hash is also threadsafe, can be interrupted by DoD, and is safe
for recursion. (By threadsafe, I mean that unchanged data structures
can be safely serialized from multiple threads
On Fri, 5 Sep 2003, Peter Haworth wrote:
On Thu, 4 Sep 2003 09:02:18 -0400 (EDT), Dan Sugalski wrote:
On Wed, 3 Sep 2003, Gordon Henriksen wrote:
A seen hash is also threadsafe, can be interrupted by DoD, and is safe
for recursion. (By threadsafe, I mean that unchanged data structures
What's a dump stream actually going to look like? E.g.,
$a = [1, 2, 3];
print dump($a);
1: PMC PerlArray
2: 3 # element count
3: PMC PerlInt# [0]
4: 1 # value
5: PMC PerlInt# [1]
6: 2 # value
7: PMC PerlInt# [2]
8: 3 #
Ok, this thread has now +45 entries, I'll try to summarize the
proposed PMC traversal schemes.
0) As the subject still applies ;-) we want to be able to dump() or
pretty_print() a PMC (and possibly aggregate members of that). This
turns out to be a special case of a deep traversal over nested
Gordon Henriksen [EMAIL PROTECTED] wrote:
Panic! Dump needs to refer to line 4 again, or else recurse! How?
Don't Panic! Here is the point, where either next_for_GC is used or the
seen hash. The former is/was used to mark (visit) PMCs. If they have
been visited, they have that pointer set else
Garrett Goebel [EMAIL PROTECTED] wrote:
As I was googling to see how other people have approached these problems I
ran across:
http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx/CLR
What did you find there, besides a description that a certain company
is producing b0rken software ;-)
leo
On Wed, 3 Sep 2003, Gordon Henriksen wrote:
What's a dump stream actually going to look like? E.g.,
Fine and good. But dump must handle object graphs, which can be
recursive or self-referential or whatnot:
$a = { b = undef };
$b = { a = $a};
$a-{b} = $b;
print
Leopold Toetsch wrote:
Garrett Goebel [EMAIL PROTECTED] wrote:
As I was googling to see how other people have approached
these problems I ran across:
http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx/CLR
What did you find there, besides a description that a certain
company is
Gordon Henriksen writes:
What you're suggesting also has significant side-effects: It halts
hypothetical multithreaded programs, suspends DoD, prevents the
traversal mechanism from calling back into parrot code, requires
fine-grained locks which are extremely expensive and have
Luke Palmer:
# Is there a problem with providing a mechanism which would suspend all
# threads except for the current one, as to ensure that the serialize
# operates, er, serially. Could it be implemented with a top-priority
# event post that acquires a global lock?
What about the thread that
Dan Sugalski wrote:
Note that a seen hash isn't particularly threadsafe here, at least not
in any useful way, since we have to make sure the structure we're
traversing doesn't change during traversal or any threadsafety we put
in is useless since we're potentially dumping corrupt data.
So?
Dan Sugalski [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
But if one thread sets pmc-next_for_GC the next thread might encounter
this PMC later (albeit for this thread at the first time) and think, I've
visited this PMC already and just flush out the object ID and not
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
But if one thread sets pmc-next_for_GC the next thread might encounter
this PMC later (albeit for this thread at the first time) and think, I've
visited this PMC
On Wed, Sep 03, 2003 at 02:07:10PM -0400, Dan Sugalski wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
But if one thread sets pmc-next_for_GC the next thread might encounter
this PMC later (albeit
Dan Sugalski [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
Then we might get deadlocks.
This is always a possibility, and there isn't anything we can do about it
at the interpreter level. Deadlocks are an unfortunate fact of life in a
threaded environment.
clone()
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
Then we might get deadlocks.
This is always a possibility, and there isn't anything we can do about it
at the interpreter level. Deadlocks are an unfortunate
Dan Sugalski:
# It's impossible to have clone in a threaded environment guarantee that
it
# won't deadlock.
If I recall correctly, all shared variables are owned by a single shared
interpreter. What if, the first time the traversal encounters a shared
PMC, it gets a lock on the shared
On Wed, 3 Sep 2003, Brent Dax wrote:
Dan Sugalski:
# It's impossible to have clone in a threaded environment guarantee that
it
# won't deadlock.
If I recall correctly, all shared variables are owned by a single shared
interpreter.
Nope. Shared variables are owned by their creating
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
[ optimize DOD before thaw/clone ]
Even with a depth restriction, a recursive estimate can produce
misleading results due to circular references. Only actually walking
the structure can get the number right. However, walking
Dan Sugalski [EMAIL PROTECTED] wrote:
At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote:
[ next_for_GC ]
That's easy, then, as it is. :) Besides, from looking at pobj.h, it's
already there, so I'm not sure what we'd need to do. Perhaps I need
to resync.
The PMC_EXT structure is only allocated
On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote:
One general traverse() vtable is just the simpler interface IMHO.
Running through each aggregate just once plus updating a seen_hash seems
simpler and faster to me and doesn't have any negative impact on PMC size
and DOD speed.
And
Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
Then we might get deadlocks.
This is always a possibility, and there isn't anything we
can do about it at the interpreter level. Deadlocks are
an unfortunate fact of life in a
Peter Haworth [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote:
One general traverse() vtable is just the simpler interface IMHO.
Running through each aggregate just once plus updating a seen_hash seems
simpler and faster to me and doesn't have any negative
- Original Message -
From: Leopold Toetsch [EMAIL PROTECTED]
To: Peter Haworth [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 4:38 PM
Subject: Re: [RfC] vtable-dump
Peter Haworth [EMAIL PROTECTED] wrote:
On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch
K Stol [EMAIL PROTECTED] wrote:
just a thought: aren't shared objects/data/whatever protected by a
mutex? To me, that's the obvious solution for accessing shared data.
As I said, just a thought.
They will be protected by a mutex yes. That helps against two threads
updating the same PMC at the
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
K Stol [EMAIL PROTECTED] wrote:
just a thought: aren't shared objects/data/whatever protected by a
mutex? To me, that's the obvious solution for accessing shared data.
As I said, just a thought.
They will be protected by a mutex yes. That
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every time it came across a circular data structure. That's
Dan Sugalski [EMAIL PROTECTED] wrote:
At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote:
Aren't you saying the opposite of above here? I want to be able to
traverse from a given start point (being it the own interpreter or some
PMC) as deeply down as there is something. You did say, that we don't
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Further: having clone implemented in terms of freeze + thaw needs
additional memory for the intermediate frozen image. Isn't that
suboptimal?
Only slightly -- It's just *one single* PMC's data that's stored in that
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every time it came across a circular data structure. That's
what the next pointer in the PObj
Dan Sugalski [EMAIL PROTECTED] wrote:
Doing the walk is *also* easy. You clear the next PMC pointer, just as
with a normal DOD run setup. call the DOD mark on the inital PMC
there is no mark() for a plain PMC scalar (and no next pointer inside
the PMC). If the PMC has a mark routine this calls
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Doing the walk is *also* easy. You clear the next PMC pointer, just as
with a normal DOD run setup. call the DOD mark on the inital PMC
there is no mark() for a plain PMC scalar (and no next pointer inside
Dan Sugalski [EMAIL PROTECTED] wrote:
Every PMC should have a next_for_GC pointer. You moved it to the ext
structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster
is the interpreter.
... but it's there, and they all ought to have one. Any PMC that
gets frozen
At 12:03 PM +0200 8/31/03, Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
class freezer {
class thawer {
class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a freezer that writes
At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
I think, we need a general solution for freeze, dump and clone. As shown
the latter is broken. That would be IMHO an iterator interface with a
callback function
Leopold Toetsch wrote:
[snip]
[1] when we want to thaw/clone big structures, we should have some means
to estimate the amount of needed headers. If we will not have enough, we
do a DOD run before clone/thaw and then turn DOD off - it will not yield
any more free headers anyway. This can avoid
At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Every PMC should have a next_for_GC pointer. You moved it to the ext
structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster
is the interpreter.
Right, and this part is only
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
So if it was mark()ed already we return. That's not possible for freeze,
thaw, dump, clone whatever. These must keep track of already visited
objects via an hash for freeze, dump, clone, and via an ID array for
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
So if it was mark()ed already we return. That's not possible for freeze,
thaw, dump, clone whatever. These must keep track of already visited
objects via an hash
Nicholas Clark wrote:
On Sat, Aug 30, 2003 at 10:13:02PM -0400, Benjamin Goldberg wrote:
Nicholas Clark wrote:
The attacker can craft a bogus CGITempFile object that refers to any
file on the system, and when this object is destroyed it will attempt to
delete that file at
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
class freezer {
class thawer {
class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a freezer that writes output for
On Sun, Aug 31, 2003 at 12:03:48PM +0200, Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
class freezer {
class thawer {
class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a
On Sat, Aug 30, 2003 at 10:13:02PM -0400, Benjamin Goldberg wrote:
Nicholas Clark wrote:
The attacker can craft a bogus CGITempFile object that refers to any
file on the system, and when this object is destroyed it will attempt to
delete that file at whatever privilege level the CGI runs
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Actually, I think the following interface would be better:
void freeze(PMC *freezer);
void thaw (PMC *thawer);
I'm thinking of (in horrible pseudo code ;-):
[snip]
Above functionality does IMHO match your
Nicholas Clark wrote:
On Fri, Aug 29, 2003 at 05:30:37PM +0200, Leopold Toetsch wrote:
I think, we need a general solution for freeze, dump and clone. As
shown
I don't know if this is relevant here, but I'll mention it in case.
For perl5 there isn't a single good generic clone system.
Benjamin Goldberg [EMAIL PROTECTED] wrote:
class freezer {
class thawer {
class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a freezer that writes output for
Storable?
Further: having clone
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Actually, I think the following interface would be better:
void freeze(PMC *freezer);
void thaw (PMC *thawer);
I'm thinking of (in horrible pseudo code ;-):
typedef struct {
size_t action_func_nr; // clone, freeze, thaw, dump
On Fri, Aug 29, 2003 at 05:30:37PM +0200, Leopold Toetsch wrote:
I think, we need a general solution for freeze, dump and clone. As shown
I don't know if this is relevant here, but I'll mention it in case.
For perl5 there isn't a single good generic clone system. Probably the
best (in terms of
On Saturday, August 30, 2003, at 07:59 , Nicholas Clark wrote:
You can't trust you data deserialiser. It can do evil on you before it
returns.
It's not the deserializer that you can't trustit's the data. Of course
it's a security nightmare to deserialize data from an untrusted source.
That
Dan Sugalski wrote:
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'd be better served getting the freeze/thaw stuff in and
We were just discussing this in the f'up.
I read those, but I wanted to make sure the discussion went this way. :)
Tracing through Parrot programs shows the type and value of variables.
This doesn't work very well for PMCs, trace_pmc_dump() tries to extract
some info from the PMC, but much better would it be, if the PMC itself
can return a string representation of itself.
STRING* dump(INTERP, SELF, STRING
Leopold Toetsch [EMAIL PROTECTED] writes:
Tracing through Parrot programs shows the type and value of
variables. This doesn't work very well for PMCs, trace_pmc_dump()
tries to extract some info from the PMC, but much better would it be,
if the PMC itself can return a string representation of
Juergen Boemmels [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
STRING* dump(INTERP, SELF, STRING *, INTVAL flags);
what is the STRING * parameter good for. I assume lineheaders.
The place, where to append SELF.dump. Appending doesn't consume a new
header for each piece.
Leopold Toetsch [EMAIL PROTECTED] writes:
Juergen Boemmels [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
STRING* dump(INTERP, SELF, STRING *, INTVAL flags);
what is the STRING * parameter good for. I assume lineheaders.
The place, where to append SELF.dump.
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
Tracing through Parrot programs shows the type and value of variables.
This doesn't work very well for PMCs, trace_pmc_dump() tries to extract
some info from the PMC, but much better would it be, if the PMC itself
can return a string
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'd be better served getting the freeze/thaw stuff in and
We were just discussing this in the f'up.
I read those, but I wanted to make sure the discussion went this way. :)
If we make the initial
Dan Sugalski [EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
We were just discussing this in the f'up.
I read those, but I wanted to make sure the discussion went this way. :)
Fine :-)
Pluggable implies a dump() vtable method,
Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'd be better served getting the freeze/thaw stuff in and
We were just discussing this in the f'up.
teaching the debugger how to dump a frozen PMC. This'll get us two
benefits:
1) We'll have a single way to dump a PMC rather than two
2) We'll
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
Pluggable implies a dump() vtable method, doesn't it?
Nope. Pluggable implies freezethaw.c provides all the functionality to
freeze or thaw a PMC, with code in
Dan Sugalski [EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
I think, we need a general solution for freeze, dump and clone. As shown
the latter is broken. That would be IMHO an iterator interface with a
callback function taking and returning a void*.
Right, what I want
76 matches
Mail list logo
