View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000407||HTML & PERL||Feature Request - Database||public||2006-07-17 10:53||2007-05-05 05:35|
|Target Version||Fixed in Version|
|Summary||0000407: raise the 2048mb filesize limit|
|Description||Lately my notifies open in their usual pop-up window but they are center-alligned as if their window was maximized. So, I can't read them unless I maximize the pop-up window every time it appears.|
allowing 32bit instead of the 31bits a signed 32-bit integer provides would be enough. 4096 instead of 2048 MB should be enough for any insane encode out there.
also see: http://www.anidb.net/forum/viewtopic.php?t=3387
as this was pushed off this far already going the additional step further wouldn't hurt.
the size is too large for a 32bit integer value.
(`the size' = 2,470,139,904)
This will actually fit quite comfortably in 32 bits, but not the 31 bits that a signed 32-bit integer provides; are unsigned types not an option?
In Perl, everything is a scalar. Strings, floats, integers - all the same. You can read a number of any length into such a scalar, but only as a string. As soon as you do arithmetic operations with the scalar, it's converted to a signed int or double value.
right now I do some arithmetics in the size handling though (i.e. to insert the dots before displaying a size value anywhere). I could probably do that with string operations too. However, I am not sure what perl will do on other arithmetic checks which i will still need. (i.e. < and >)
I think Math.BigInt (or Math.BigFloat) package will be enough for this purpose. All operations are covered, maybe conversion BigInt -> string (to write to DB or display) may be improved.
|Tags||No tags attached.|
fyi currently 3 files in anidb would need this
149944, 176710, 217434
but do we really need this?
it just seems like a waste of storage, memory, cpu power and effort to convert everything to unsigned int or int64 just for a hand full of files.
for the mom no. i'm was just stickign everything that was reported in the forum on the tracker. like i said in the second message. 3(!) files would need that our of 200k. until a significant number would use them i don't think it is needed
it still is soemwhat silly to use signed integer here though. i mean negative size? o_O
file 264553 joined the list...
"Lately my notifies open in their usual pop-up window but they are center-alligned as if their window was maximized. So, I can't read them unless I maximize the pop-up window every time it appears." <- wrong copy&paste ? @ description
anyway, I guess the additional 4 byte in db storage size won't really matter. so it's all up to how well we can handle signed 64bit integers in perl.
haven't looked into that yet.
||you are again going for signed integer? now not like it really matters if it's 63 or 64 bit, but negative filesize? oO|
2 more I have seen:
FileID: 314031, 314042 (GITS Innocence Bluerayrip)
with its actual size about 4GB
|2006-07-17 10:53||DerIdiot||New Issue|
|2006-07-17 10:55||DerIdiot||Description Updated|
|2006-07-17 11:05||DerIdiot||Note Added: 0000860|
|2006-07-17 11:05||DerIdiot||Summary||Mis-allignment of notifies in pop-up window => raise the 2048mb filesize limit|
|2006-07-29 03:40||exp||Note Added: 0000942|
|2006-07-29 08:03||DerIdiot||Note Added: 0000949|
|2006-07-29 08:04||DerIdiot||Note Edited: 0000949|
|2006-09-26 11:16||worf||Note Added: 0001049|
|2006-09-26 11:17||worf||Note Edited: 0001049|
|2007-04-16 20:03||DerIdiot||Description Updated|
|2007-04-17 05:59||exp||Note Added: 0001236|
|2007-04-17 07:03||DerIdiot||Note Added: 0001237|
|2007-04-24 12:23||DerIdiot||Status||new => assigned|
|2007-04-24 12:23||DerIdiot||Assigned To||=> epoximator|
|2007-04-25 08:07||anime-otaku||Note Added: 0001240|
|2007-05-05 05:35||epoximator||Status||assigned => resolved|
|2007-05-05 05:35||epoximator||Resolution||open => fixed|