[ensembl-dev] Perl BLOBs in the ensembl compara database

Michael Paulini mh6 at sanger.ac.uk
Mon Jan 24 12:35:52 GMT 2011


I think you can force a specific endianness in the pack/unpack ... but 
yes, not optimal.

M

On 24/01/2011 12:29, LAW Andy wrote:
> That was my main point.
>
> To be explicit about this, am I right in thinking that - as a consequence of the pack/unpack function - the ConservationScores code in the Perl API will not work correctly (it will return meaningless results) if run on a PPC chip for example? (assuming that EBI are running on intel chips). I don't see anything in the Ensembl Perl code as provided that checks for or enforces "endianism" (but I may be missing that).
>
>
>
> On 21 Jan 2011, at 18:27, Daniel Hughes wrote:
>
>> there's also a difference between 'architecture-dependencies' and specific 'language-dependencies'.
>>
>> from perl's own 'pack' documentation:
>>
>> Floating point Numbers
>>
>> For packing floating point numbers you have the choice between the pack codes f , d , F and D . f and d pack into (or unpack from) single-precision or double-precision representation as it is provided by your system. If your systems supports it, D can be used to pack and unpack extended-precision floating point values (long double ), which can offer even more resolution than f or d . F packs an NV , which is the floating point type used by Perl internally. (There is no such thing as a network representation for reals, so if you want to send your real numbers across computer boundaries, you'd better stick to ASCII representation, unless you're absolutely sure what's on the other end of the line. For the even more adventuresome, you can use the byte-order modifiers from the previous section also on floating point codes.)
>>
>>
>>
>> Dan.
>>
>>
>>
>> Daniel S. T. Hughes M.Biochem (Hons; Oxford), Ph.D (Cambridge)
>> -------------------------------------------------------------------------------------
>> dsth at cantab.net
>> dsth at cpan.org
>>
>>
>> 2011/1/21 LAW Andy<andy.law at roslin.ed.ac.uk>
>>
>> On 21 Jan 2011, at 17:04, Andy Jenkinson wrote:
>>
>>> The implementation as it stands essentially requires that store/read operations on the database be done on machines with the same architecture. I guess this could be made more explicit, but bear in mind it will affect use of an API written in any language (including the Perl API itself). Unfortunately I think you are always going to have to keep abreast of changes to the Perl API if you create a Java translation, whether those changes affect the database or not. The extent to which you will have to modify the Java code accordingly is going to depend on how complete your implementation is - I expect there's plenty of pure logic that could harbour bugs or be subject to update!
>>
>> There is a world of difference between "keeping abreast of changes to the Perl API" and having language and processor architecture dependencies actually built in to the database.
>>
>> Later,
>>
>> Andy
>> --------
>> Yada, yada, yada...
>>
>> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336
>> Disclaimer: This e-mail and any attachments are confidential and intended solely for the use of the recipient(s) to whom they are addressed. If you have received it in error, please destroy all copies and inform the sender.
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at ensembl.org
>> http://lists.ensembl.org/mailman/listinfo/dev
>>
>>
> Later,
>
> Andy
> --------
> Yada, yada, yada...
>
> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336
> Disclaimer: This e-mail and any attachments are confidential and intended solely for the use of the recipient(s) to whom they are addressed. If you have received it in error, please destroy all copies and inform the sender.
>
>





More information about the Dev mailing list