Am 05.02.2015 um 18:14 schrieb Peter Rabbitson rab...@rabbit.us:
On 02/05/2015 06:11 PM, Jens Rehsack wrote:
Hi Michael,
I think I will do. Math::Base::Convert with convert for up-to-base64
seems to be fine
I still think providing an arbitrary up to base64 conversion is a mistake.
Sorry for my very late reply.
After I wrote the CONV function, I did take much of the code and improved
Math::BaseCalc with it. Although, that patch is still stuck in review (
https://github.com/kenahoo/perl-math-basecalc/pull/2).
So, I don't mind if the code was stripped out to use a separate
On 02/05/2015 06:11 PM, Jens Rehsack wrote:
Hi Michael,
I think I will do. Math::Base::Convert with convert for up-to-base64
seems to be fine
I still think providing an arbitrary up to base64 conversion is a
mistake. Consider the standardized base32 alphabet:
Hi Michael,
I think I will do. Math::Base::Convert with convert for up-to-base64
seems to be fine, whatever MySQL extended - MySQL isn't a standard
I orientate myself or my software ;)
Cheers,
Jens
Am 05.02.2015 um 18:07 schrieb mich...@insulin-pumpers.org:
Take a look at Math::Base::Convert,
Am 15.12.2014 um 10:54 schrieb Darren Duncan dar...@darrenduncan.net:
On 2014-12-15 1:40 AM, Jens Rehsack wrote:
during review of SQL::Statement wrt. RT#100551 I realized that the
introduced SQL_FUNCTION_CONV
Hi Jens,
Thank you for trying to deal with this mess, whatever happens. The RT ticket
https://rt.cpan.org/Ticket/Display.html?id=100551 was not based on any deep
knowledge of SQL, its standards, and its implementations, but just on the
observation that the hex representation of 16 (base 10)
On 2014-12-15 1:40 AM, Jens Rehsack wrote:
during review of SQL::Statement wrt. RT#100551 I realized that the introduced
SQL_FUNCTION_CONV
(https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Statement/Functions.pm#L454)
is unnecessary over-complex.
Funny, when I first saw that
