in reply to runtime problem; elusive error

I discovered also GrandFather's note that Readonly is somehow the source of misery. What I see happening is that the values set with Readonly are set as strings rather than numbers. According to perlop, the bitwise OR operating on strings is different than if it sees integers.

What's very strange, though, is that the numbers-as-strings thing only happens after they've been used once. That's why your usage of them in @Vals is triggering the bug. If I leave your piece commented out but print them with Data::Dumper, I get the same behavior (but not with a simple print—weird!).

Anyway, my crude solution is to use string eval to get closer to what you want.

Readonly my $_debug_ops => eval "($DBG_RAND | $DBG_KEYS | $DBG_INFO)";

That works in this case, but it's not very satisfying in general. I don't really understand what's going on in Readonly, so I haven't been able to come up with something better.

Replies are listed 'Best First'.
Re^2: runtime problem; elusive error
by almut (Canon) on Sep 20, 2007 at 15:22 UTC
    my crude solution is to use string eval ...

    What also seems to work is

    Readonly my $_debug_ops => $DBG_RAND+0 | $DBG_KEYS+0 | $DBG_INFO+0;

    but I'm not sure if it's the "+0 = force numeric" aspect or the associated pre-evaluation of the variables that's making this work...  (of course, this workaround isn't very satisfying either).

    Anyhow, it's probably best to just stay away from using Readonly... (I had also already been bitten by other subtle weirdnesses).

      Slightly cleaner (though admittedly, it doesn't quite "hit the spot" for satisfaction) is just or'ing with 0 as the first thing: "$debug_ops = 0 | $DBG_RAND | $DBG_KEYS | $DBG_INFO; That does the same thing (I think) as your +0 in this situation. Not sure how it gets the other value...weird!

      Thanks!
      Linda