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
I just went to go patch in the code ref stuff to is_deeply() and found that
I had unfinished changes to the diagnostic output. Remember, it was about
including the description in the failure diagnostics. So instead of this:
/Users/schwern/tmp/test...NOK 1
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
13 matches
Mail list logo
