Skip Menu |

This queue is for tickets about the Data-Serializer CPAN distribution.

Report information
The Basics
Id: 15454
Status: resolved
Worked: 15 min
Priority: 0/
Queue: Data-Serializer

People
Owner: neil [...] neely.cx
Requestors: carleklof [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.34
Fixed in: (no value)



Subject: _get_token method is unreliable
Greetings, I was getting this error when using deserialize: Data::Serializer error: Please make sure Data/Serializer/@#$%(my binary data)@#$%.pm is a properly installed package. at /home... I traced it down to the _get_tokens method. It looks like if the value being deserialized happens to have two carrets, then the deserialize method will break because the _get_tokens method will think the API user is passing in something other than simply the data string to deserialize. I'm never passing anything other than the data I want to deserialize (thaw/uncompress) So I simply commented out that line, and now it works swimmingly. I don't know how in the world I can be the first one to hit this. It makes me think that I'm not getting something (quite possible). Anyway, I hope I haven't said anything offensive. I really appreciate the contribution of all CPAN posters. That includes people to track down bugs, which is why I'm posting. I hope this helps. -Carl
Date: Wed, 2 Nov 2005 06:46:55 -0800 (PST)
From: Carl Eklof <carleklof [...] yahoo.com>
Subject: Re: [cpan #15454] AutoReply: _get_token method is unreliable
To: bug-Data-Serializer [...] rt.cpan.org
RT-Send-Cc:
I understand the usage of _get_tokens a little better now. I can see that Data::Serializer puts the encoding package names into the values. It only seems to do it sometimes, I still don't understand. However, I made a small modification to the match expression in _get_token, that at least makes it correct, and reduces the likely hood of erroneous matches. I changed the match line in _get_token from: my ($token) = $line =~ /\^([^\^]+?)\^/; to my ($token) = $line =~ /^\^([^\^]+?)\^/; Now it only matches if it finds the encoding package names at the beginning of the string. This is still not entirely reliable. I suspect that the other half of the bug is in the fact that it doesn't always embed the encoding package names at the beginning. Hope this helps, -Carl Carl Eklof President Bee Software LLC See us in action at:http://beethere.net/ p: 917.464.3529 f: 801.439.4213 carl@beesw.com
Suggested fix was good. Version 0.35 has been uploaded with a fix. Thanks much, Neil