[Dancer-users] Dancer logging stringifies some data

[Flavio Poletti]

On Fri, Jun 22, 2012 at 9:50 PM, sawyer x <xsawyerx at gmail.com> wrote:
> I've been trying to write a test case for this, but have so far failed.

Which made me wonder whether the problem is being approached from the
wrong side. To make a long story short, I think that there should be a
bug filed to the JSON serializer. But I won't spare you the long story
:-)

When I tried to see what the whole thing is about, I wrote this:

    use Devel::Peek 'Dump';

    my $price = 100.55;

    Dump($price);
    print "$price\n";
    Dump($price);

and obtained this:

$ perl test.pl
SV = NV(0x81a9038) at 0x817afe0
  REFCNT = 1
  FLAGS = (PADMY,NOK,pNOK)
  NV = 100.55
100.55
SV = PVNV(0x816bcd8) at 0x817afe0
  REFCNT = 1
  FLAGS = (PADMY,NOK,POK,pNOK,pPOK)
  IV = 0
  NV = 100.55
  PV = 0x81a0e08 "100.55"\0
  CUR = 6
  LEN = 36


So it's not a matter of getting a NV turned into a PV, but of getting
a NV turned into a NVPV whose NOK flag is still on - i.e. the contents
is still "number".

If this "evolution" can be obtained even through a single, simple
print, it seems to me that Dancer logging has actually nothing to do
with it and should not care. On the other hand, I think that the JSON
serializer should try better to guess how to cope with these
variables, going for the "number" when the contents are actually
numbers (i.e. testing the IOK and NOK flags before going for the
string).

Of course this might be a big mistake from my side... my assumption is
that what's actually happening is that a [IN]V is being turned into a
PV[IN]V, which might not be the case reported by Ovid. Sorry for the
noise in this case!

Ciao,

   Flavio.