On 7/1/05, Michael G Schwern [EMAIL PROTECTED] wrote:
On Thu, Jun 30, 2005 at 09:44:06AM +0200, demerphq wrote:
Out of curiousity, if Data::Dumper::Streamer can handle
closures why not fix B::Deparse?
I'm not really sure what you mean by fix B::Deparse. B::Deparse does
exactly what it
Hi,
Yitzchak pointed me to this thread. I thought I'd add that
Data::Dump::Streamer v1.14 has the capability to Dump closures
properly, that is including bound lexical state. (Albeit with a few
minor caveats, its possible to deliberately construct pathological
closures that wont be eval'able,
On Thu, Jun 30, 2005 at 08:03:32AM +0200, demerphq wrote:
Yitzchak pointed me to this thread. I thought I'd add that
Data::Dump::Streamer v1.14 has the capability to Dump closures
properly, that is including bound lexical state.
Interesting. is_deeply() can try to use Data::Dumper::Streamer
On 6/30/05, Michael G Schwern [EMAIL PROTECTED] wrote:
On Thu, Jun 30, 2005 at 08:03:32AM +0200, demerphq wrote:
Yitzchak pointed me to this thread. I thought I'd add that
Data::Dump::Streamer v1.14 has the capability to Dump closures
properly, that is including bound lexical state.
On 6/30/05, demerphq [EMAIL PROTECTED] wrote:
Incidentally this is a pretty common mistake when handling REF's.
Data::Dumper does it as does YAML and pretty much all the other
storage tools that i have looked at, although Storable gets it right.
Also, i should say that while this circular ref
On Thu, Jun 30, 2005 at 09:44:06AM +0200, demerphq wrote:
Out of curiousity, if Data::Dumper::Streamer can handle
closures why not fix B::Deparse?
I'm not really sure what you mean by fix B::Deparse. B::Deparse does
exactly what it says it does: it deparses code. We can't consider it
On 6/27/05, Michael G Schwern [EMAIL PROTECTED] wrote:
On Mon, Jun 27, 2005 at 11:20:07AM +0100, Fergal Daly wrote:
I'm perfectly happy to punt this problem over to B::Deparse and let them
figure it out. As it stands B::Deparse is the best we can do with code
refs. What's the
On Mon, Jun 27, 2005 at 11:20:07AM +0100, Fergal Daly wrote:
I'm perfectly happy to punt this problem over to B::Deparse and let them
figure it out. As it stands B::Deparse is the best we can do with code
refs. What's the alternative?
I'd argue that currently the best you can do is ==
On Mon, Jun 27, 2005 at 11:34:58PM +0100, Fergal Daly wrote:
Forgetting philosphical arguments about what's the right thing to do,
I think the strongest point against this is that there may be people
out there who expect the current behaviour
The current behavior is to vomit all over the
On Tue, Jun 28, 2005 at 12:21:48AM +0100, Fergal Daly wrote:
That's only 2 months old (according to CPAN) before that it would have
just failed or passed (failed in this case). Is it in bleadperl? I'd
be amazed if no one anywhere was using is_deeply with coderefs.
It was undefined, accidental
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Sunday 26 June 2005 07:18, Collin Winter wrote:
My initial quick-glance at B::Deparse's documentation mentions
something about perl optimising certain constants away, which could
well throw a spanner into the works. Storable uses B::Deparse
On Sun, Jun 26, 2005 at 10:25:51AM +0200, Tels wrote:
After tinkering with B::Deparse for a bit, I think this particular
oddity may just be a result of poorly-written docs (or, more
probably, poorly-read on my part). The module seems to do the right
thing in all cases I could come up with
Tels wrote :
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Sunday 26 June 2005 07:18, Collin Winter wrote:
[...]
After tinkering with B::Deparse for a bit, I think this particular
oddity may just be a result of poorly-written docs (or, more
probably, poorly-read on my part). The module seems
On Sun, Jun 26, 2005 at 12:06:47PM +0200, David Landgren wrote:
What it *shouldn't* do is what Test.pm does, namely execute the
code ref and compare the values returned. It would just compare
the refernces.
Why should it not do that? Is this because of subs with side effects?
Isn't
You have 3 situations
1 the refs came from \somefunc
2 the refs come from evaling strings of code
3 the refs are closures and therefore have some data associated with them
For 3, it looks like B::Deparse does't handle the data at all so even
if the deparsed subs are identical they may behave
David Landgren writes:
Michael Schwern wrote at the beginning of this thread:
What it *shouldn't* do is what Test.pm does, namely execute the
code ref and compare the values returned. It would just compare
the refernces.
Why should it not do that? Is this because of subs with side
On 6/26/05, Fergal Daly [EMAIL PROTECTED] wrote:
You have 3 situations
1 the refs came from \somefunc
2 the refs come from evaling strings of code
3 the refs are closures and therefore have some data associated with them
For 3, it looks like B::Deparse does't handle the data at all so
On Sun, Jun 26, 2005 at 12:57:05PM +0100, Fergal Daly wrote:
1 the refs came from \somefunc
2 the refs come from evaling strings of code
3 the refs are closures and therefore have some data associated with them
For 3, it looks like B::Deparse does't handle the data at all so even
if the
Currently, throwing is_deeply() a code ref causes it to barf.
perl -MTest::More -wle 'print is_deeply sub {}, sub {}'
WHOA! No type in _deep_check
This should never happen! Please contact the author immediately!
# Looks like your test died before it could output anything.
is_deeply() doesn't
I'll chime in, as I'm the one who initially raised the idea : )
I'll start with a use-case: my initial motivation for having is_deeply
handle coderefs came up while building certain unit tests for a
rewrite of DBD::Mock. Several of the worker functions return complex
data structures -- which may
My initial quick-glance at B::Deparse's documentation mentions
something about perl optimising certain constants away, which could
well throw a spanner into the works. Storable uses B::Deparse when
serialising coderefs, though, so I'm certain there's a way around
this.
That shouldn't
21 matches
Mail list logo
