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
> >
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
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
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 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
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, howe
On 6/28/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> 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 cur
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 th
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, accidenta
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 use
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
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 27 June 2005 00:37, Michael G Schwern wrote:
> 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 d
On 6/27/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 27, 2005 at 01:41:30AM +0100, Fergal Daly wrote:
> > I'm not sure there is a right way to deparse closures (in general).
> > For example if a variable is shared between 2 closures then it only
> > makes sense to deparse both of
On 6/26/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > 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 totally
> > differently.
>
> This will simply have to be a caveat. Fortunately, if B::Deparse ever gets
> this
On Mon, Jun 27, 2005 at 11:36:13AM +1000, [EMAIL PROTECTED] wrote:
> >Another way to look at the "eval" case is to apply it to other references.
> >
> > is_deeply( eval "{ foo => 42, bar => 23 }",
> >{ "bar", 42, "foo", 23 } );
> >
> >Even though the code is written differently
[EMAIL PROTECTED] wrote:
Another way to look at the "eval" case is to apply it to other references.
is_deeply( eval "{ foo => 42, bar => 23 }",
{ "bar", 42, "foo", 23 } );
Even though the code is written differently the resulting data is the same.
Would anyone be
On Mon, Jun 27, 2005 at 01:41:30AM +0100, Fergal Daly wrote:
> I'm not sure there is a right way to deparse closures (in general).
> For example if a variable is shared between 2 closures then it only
> makes sense to deparse both of them together. Deparsing them in turn
> will lose the sharedness
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 t
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 a
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
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 tot
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?
> I
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 01:18:42AM -0400, Collin Winter wrote:
> With this matter sorted, I've started on the code
> and requisite tests to make the new stuff work.
Ok, let me know when you have something.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Reality is t
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
-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::De
> > 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
On Sun, Jun 26, 2005 at 12:08:35AM -0400, Collin Winter wrote:
> My inital strategy for implementing this was a two-tiered approach.
> First, compare the references; if they're the same, return true, go no
> futher. If they differ, however, say if anonymous subs were thrown
> into the mix, then use
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 c
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 k
30 matches
Mail list logo
