Finding the maximum dictionary size

[mycae]

Hello,

I have a Nokia 6300 phone - I find that I am able to use the 0.4MB IDP version of DMID, and the loadable version (with annoying prompts) but not any other version at all (i've tried the 1.1MB, and the 5.0 MB versions).

Is there some way to find out how big the built-in dictionary can be? "Statistics" tells me the the phone's Free Memory is 1310604 (bytes?). Id be willing to rebuild a smaller dictionary.

P.S - is there some way that the loadable dictionary could load just one file at startup? I would be willing to accept a reduced response rate - that way, the number of file handles (and thus prompts) could be reduced...

[Gert]

Is there some way to find out how big the built-in dictionary can be? "Statistics" tells me the the phone's Free Memory is 1310604 (bytes?).

Well, with 1.3 MB of free memory you will only be able to install small dictionaries.

http://www.developer.nokia.com/Devices/Device_specifications/6300/ tells me that you can only run JAR files of 1 MB. With the loadable dictionaries you can run any size of dictionary, only limited by the free memory.

P.S - is there some way that the loadable dictionary could load just one file at startup? I would be willing to accept a reduced response rate - that way, the number of file handles (and thus prompts) could be reduced...

Yes, complain at Nokia so that they will allow the user to get rid of those stupid messages. It is the Nokia firmware that generates them.

Well, here is more on that topic: http://dictionarymid.sourceforge.net/jsr75.html

Hmmm, say when you use a JAR file as your loadable dictionary, are there still several messages per translation ?

Regards,
Gert

[mycae]

Yes, complain at Nokia so that they will allow the user to get rid of those stupid messages. It is the Nokia firmware that generates them.

Realistically, I don't think nokia cares what I say. In the future, I will be considering the ability to run 3rd party applications unrestricted when I purchase new phones (this one was a gift). One also only discovers these things after a long time of use - I've had the device for 2 years before becoming aware of this problem

---

Let me rephrase my question a little - I am an open-source developer, who is moving to a foreign country where I have limited grasp of the local language, and possessing a 6300, may have both the time and inclination to make a good dictionary app somewhat more usable for myself. DMID seems to be the best open-source dictionary out there.

If I can load 2 MB  (according to your device details link) on the heap, then I could theoretically fill free-ram with words from the filesystem. AFAICS, each fopen (or java equivalent) should generate exactly one request to the user, by fopening exactly once for one single compressed (or what have you) dictionary file,  I then proceed to shove as much data as possible into ram (eg with in-ram compression), leaving sufficient space to keep the dictionary app running.  This will generate one request, and load the dictionary from the filesystem - words that don't fit could be randomly, or priority-wise dropped.

For me, the available size that I could fit into ram is bigger than the JAR size, and would work if the loadable dictionary was smaller than the available device ram. This might provide a useable user experience,  where I only get one prompt per-app run, and this fits within the current system constraints.

Am I missing something here? Would this, hypothetically, be possibly implementable by a sufficiently motivated developer?

[Gert]

DMID seems to be the best open-source dictionary out there.

I need to correct this: DictionaryForMIDs is the best dictionary application in the whole world; much better than any commercial dictionary application too  ... well, ok, a few more improvements would help

If I can load 2 MB  (according to your device details link) on the heap, then I could theoretically fill free-ram with words from the filesystem. AFAICS, each fopen (or java equivalent) should generate exactly one request to the user, by fopening exactly once for one single compressed (or what have you) dictionary file,  I then proceed to shove as much data as possible into ram (eg with in-ram compression), leaving sufficient space to keep the dictionary app running.  This will generate one request, and load the dictionary from the filesystem - words that don't fit could be randomly, or priority-wise dropped.

I do understand all of what you are writing; I so believe that should work.

For me, the available size that I could fit into ram is bigger than the JAR size, and would work if the loadable dictionary was smaller than the available device ram. This might provide a useable user experience,  where I only get one prompt per-app run, and this fits within the current system constraints.

Am I missing something here? Would this, hypothetically, be possibly implementable by a sufficiently motivated developer?

I think that should be implementable "by a sufficiently motivated developer". However, that solution really will work only well for those dictionaries where the whole dictionary file fits onto the heap; otherwise there would be confirmation messages when the missing parts would need to get loaded. 2 MB is really not huge, well, depending on the dictionary that you would like to use it may be enough.

Regards,
Gert

[starssoft]

Suggestions to reduce the midlet size,

1. Developer of dictionary can avoid unnecessary characters / spaces to reduce bytes,

2. Some of the dictionaries are doesn't require all normation classes, the non required classes can be eliminated  to optimise the size of jar (Lite Version of DfM can be published with only normationEng class),

3. Non required Language flags can be removed to optimise midlet size.

[Gert]

Thank you a lot for you recommendations!  It is highly appreciated that you actively support the DfM community!

2. Some of the dictionaries are doesn't require all normation classes, the non required classes can be
eliminated  to optimise the size of jar (Lite Version of DfM can be published with only normationEng class),

3. Non required Language flags can be removed to optimise midlet size.

Hmmmm, point 2 and 3 should be automatically done by JarCreator. JarCreator scans for the NormationClasses that are defined in DictionaryForMIDs.properties and removes the non-used classes. Same for the flags. Doesn't that work with JarCreator ?

Best regards,
Gert

[starssoft]

Jar Creator doesn't do that job... I tried twice... kindly ensure..... Thank you for your support

[Gert]

Jar Creator doesn't do that job... I tried twice... kindly ensure..... Thank you for your support

I need to check that - I did implement those features a long time ago, so I need to see why it doesn't work any more.

Thanks for pointing at that !

Gert