Re: [SHR] illume predictive keyboard is too slow
On Sun 01 Feb 2009 00:31:09 Carsten Haitzler wrote: On Fri, 30 Jan 2009 21:16:57 +0100 Olof Sjobergh olo...@gmail.com said: On Fri, Jan 30, 2009 at 8:12 PM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Fri, 30 Jan 2009 08:31:43 +0100 Olof Sjobergh olo...@gmail.com said: But I think a dictionary format in plain utf8 that includes the normalised words as well as any candidates to display would be the best way. Then the dictionary itself could choose which characters to normalise and which to leave as is. So for Swedish, you can leave å, ä and ö as they are but normalise é, à etc. Searching would be as simple as in your original implementation (no need to convert from multibyte format). the problem is - the dict in utf8 means searching is slow as you do it in utf8 space. the dict is mmaped() to save ram - if it wasnt it'd need to be allocated in non-swappable ram (its a phone - it has no swap) and thus a few mb of your ram goes into the kbd dict at all times. by using mmap you leave it to the kernels paging system to figure it out. so as such a dict change will mean a non-ascii format in future for this reason. but there will then need to be a tool to generate such a file. Searching in utf8 doesn't mean it has to be slow. Simple strcmp works fine on multibyte utf8 strings as well, and should be as fast as the dictionary was before adding multibyte to widechars conversions. But if you have some other idea in mind, please don't let me disturb. =) the problem is - it INSt a simple keyvalue lookup. it's a possible-match tree build on-the-fly. that means you jump about examining 1 character at a time. the problem here is that 1 char may or may not be 1 byte or more and that makes it really nasty. if it were a simple key lookup for a given simple string - life would be easy. this is possible - but then u'd have to generate ALL permutations first then look ALL of them up. if you weed out permutations AS you look them up you can weed out something like 90% of the permutations as you KNOw there are no words starting with qz... so as you go through qa... qs qx... qz... you can easily stop all the combinations with qs, qz ans qx as no words begin with that (if you have an 8 letter word with 8 possible letters per character in the word thats 8^6 lookups you avoided (in the case above - ie all permutations of the other 6 letters). thats 262144 lookups avoided... just there. for... 1 of the above impossible permutation trees. now add it up over all of them. Do you consider this paper relevant? http://citeseer.ist.psu.edu/schulz02fast.html Fast String Correction with Levenshtein-Automata, (2002), Klaus Schulz, Stoyan Mihov It actually uses tries to avoid generating and comparing exhaustively all permutations of the input word (typed keys), but instead traverses *only* know words and accumulates permutations unless a max-errors limit gets exceeded, in which case this path dies. It describes a mathematical model for correcting typos, but since i have already implemented it (in java) i know think it can be retrofitted to perform what you describe in: http://wiki.openmoko.org/wiki/Illume_keyboard Keep up the good work. Kostis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Phone java apps on fr?
On Thu 18 Sep 2008 13:24:20 Petr Vanek wrote: Hi all, perhaps a silly question, but google nor wiki give me an answer: how can i run java applications from other mobile phones on fr? Is it what is called JavaME? Is this available for fr? I have looked at jalimo and around but no clarity for me... thank you for pointing into the right direction, I just tried microemu[1] with CacaoVM (included in Debian) and it worked! (It takes ~20sec to start up but it is very responsive) After downoading it and unpacking it i tried the demo apps included with the command: DISPLAY=:0 java -jar microemulator.jar apps/microemu-demo.jad Yet, at the TextField demo, the microemu aborted with: LOG: [0x43ee3490] mutex_lock: pthread_mutex_lock failed: Invalid argument Aborted Regards, Kostis [1]: http://www.microemu.org/index.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Phone java apps on fr?
On Thu 18 Sep 2008 14:14:01 Martin Šenkeřík wrote: On Thu, Sep 18, 2008 at 1:01 PM, [EMAIL PROTECTED] wrote: how can i run java applications from other mobile phones on fr? Is it what is called JavaME? Is this available for fr? I have looked at jalimo and around but no clarity for me... I think a lot of work must still be done. http://wiki.openmoko.org/wiki/Java#Status_on_Openmoko But see the history of this page: the only changes this year were OpenMoko-Openmoko changes and some category corrections... I have updated that OpenMoko-java-page about: Debian status with and CacaoVM, JamVM and Microemu PhoneME impl. Regards, Kostis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Java FX, any news?
On Tue 16 Sep 2008 10:45:58 Philipp Aeberli wrote: Hello everyone, I was going through some of my bookmarks and stumbled over the Java FX announcement in May this year: http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=16310 There is even a Java FX Mobile dedicated to mobile devices: http://java.sun.com/javafx/mobile/ Does anyone now if somebody is pursuing this Hi Philipp, I have attempted some experiments with JavaFX. I'm using Debian with CacaoVM implementing JSE 1.5, and i tried the SDK preview samples Stopwatch, ImageRollover and Madness. Here are the results so far: * Stopwatch run but was deadly slow! It may be that it requires floating-point maths for the clock-pointers. * ImageRollover (just a close-button) starts slow but is perfectly responsive! * Madness segfaulted CacaoVM with a unable to find a Java method message. Attempts with others progs have also end-up with CacaoVM segfaults. Tried also JamVM but classpath-classes didn't implement Window.isLocationByPlatform() method so JavaFX aborts. Hope the above info helps. Regards, Kostis PS: These attempts are the precursory steps of evaluating the possibility of an ala Tichy FSO-based JavaFX+OSGi software for OpenMoko devices. Any feedback appreciated. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Swype - Jaw dropping fast and accurate entry of text via touch screen [w/video]
On Fri 12 Sep 2008 15:42:31 Stroller wrote: On 11 Sep 2008, at 14:17, Kostis Anagnostopoulos wrote: On Thu 11 Sep 2008 01:31:27 Didier Raboud wrote: nickd wrote: Take a look at the other method previously pointed by Dan : http://www.inference.phy.cam.ac.uk/dasher/ It's GPL... I don't like Dasher because it introduces uncontrolled waiting states, in order for the target letter to reach the center. Surely the waiting state is controlled - by moving the cursor to the right (I imagine tilting the Freerunner) the stream of letters speeds up. Yet, sometimes you just have to slowdown untill the needed letter appears. In any way, it is not the same as a deterministic action under your controll, lets say, i move from point a to point b, and it would take me as much time as i like! Thats what i meant with uncontrollable, i din't mean totally-out-of-my-controll. On Dasher's site they make a comparison with car-driving. I think that if we were given the chance, we would preffere a click-to-destination instead of a steering- wheel car-UI. At some point analogies always break - probably as soon as you start using them to expand outside anything that the original analogiser had in mind. ;) The destination is the completed sentence of words. It is held initially inside your mind, and it is impossible to give the target device this destination without any intervening steps. Just as we don't yet have autonomous automobiles, either, a steering-wheel (or some other control device) is clearly necessary to get the words out of your head into the device. Wel, the target for me is the letters-of-a-world, not the world, so from this point of view, yes click or signature-like typing is more like controlling a variable but a steering wheel is like controlling the derivative of that variable. Hence the wait-states! I need to say that, concerning mobile devices, i had try to envision such a input-method myself, and the Dasher is as close as it gets to what i might had end up with. My kudos to the programmers and designers of Dasher. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Swype - Jaw dropping fast and accurate entry of text via touch screen [w/video]
On Thu 11 Sep 2008 01:31:27 Didier Raboud wrote: nickd wrote: Take a look at the other method previously pointed by Dan : http://www.inference.phy.cam.ac.uk/dasher/ It's GPL... I don't like Dasher because it introduces uncontrolled waiting states, in order for the target letter to reach the center. I get the same feeling when i'm told that in order to disable the QTopia keyboard's auto-complete, i need to wait 2secs on the same letter... On Dasher's site they make a comparison with car-driving. I think that if we were given the chance, we would preffere a click-to-destination instead of a steering-wheel car-UI. Yet, a GPL software always deserves respect, Regards, Kostis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
