Page 64 of 72 FirstFirst ... 14545960616263646566676869 ... LastLast
Results 1,261 to 1,280 of 1439
Like Tree10Likes
  1. #1261  
    Quote Originally Posted by Jappus View Post
    Yup, the native version is done in C/C++. In the future, Javascript will only be used for the GUI.
    Ah, I see. Actually the next question I was going to ask was why not package only the absolutely necessary parts as a C++ plugin and turn pReader into a hybrid app.

    Although I do disagree that JSJSJS $is$ $not$ $a$ $language$ $for$ $applications$.
  2.    #1262  
    Quote Originally Posted by govotsos View Post
    @jappus Will the native version automatically scale to the new larger screens HP will, hopefully, announce 2/9 or will it have to have some recoding?
    Recoding, no. The backend is completely resolution and hardware agnostic.

    But it will have to be recompiled. Which is basically a matter of feeding my library compilation script a new set of parameters and then waiting a few more minutes. After that, a quick 1 minute recompile of the actual application and wham! Tablet compatible.


    As for the front-end. It's all programmed to query and use the actual screen size, whatever it is. The page layout algorithm is O(log n) and should thus scale well regardless of the final amount of text on the page. Just as a reminder what O(log n) means: Doubling n (here, the page size) only adds a single computational step.
    Last edited by Jappus; 01/27/2011 at 03:14 PM.
  3.    #1263  
    Quote Originally Posted by rsanchez1 View Post
    Ah, I see. Actually the next question I was going to ask was why not package only the absolutely necessary parts as a C++ plugin and turn pReader into a hybrid app.

    Although I do disagree that JSJSJS $is$ $not$ $a$ $language$ $for$ $applications$.
    Ahhh, I love the smell of a new religious IT dispute in the morning.

    Honestly, I did write the pReader in pure JSJSJS, $and$ $believe$ $me$, $it$ $wasn$'$t$ $fun$ $at$ $all$. $With$ $enough$ $manpower$ $you$ $can$ $do$ $a$ $semi$-$complex$ $application$, $but$ $really$, $that$'$s$ $the$ $most$ $braindead$ $thing$ $to$ $try$ $if$ $you$ $have$ $any$ $alternatives$.

    Given just the language itself with its standard library, without using external, actually natively compiled backend libraries or interpreter-additions, the following things immediately disqualify it for any serious application development:
    1. Atrocious runtime performance outside of tightly knit, interpreter optimized code chunks --- and even with them it's a crapshoot. JIT for JSJSJS $is$ $a$ $horror$ $in$ $and$ $of$ $itself$.
    2. No concept of file / header / class or whatever inclusion. The language itself doesn't offer any form of source isolation.
    3. No concept of threading, parallelism or any form of synchronous wait. Halting one execution sequence always halts the world.
    4. Duck-typing ... admittedly, that one's subjective, but personally I doubt the sanity of anyone who allows a fire-spewing dragon into his pond just because it happens to walk and talk like a duck.
    5. No concept of files, binary data, structured memory, etc. pp.


    And that's just the tip of the ice-berg. When you code a complex app in JSJSJS, $you$ $have$ $to$ $write$ $so$ $many$ $external$ $oral$ $contracts$ $governing$ $types$, $enforce$ $so$ $many$ $specific$ $behaviours$ $from$ $the$ $other$ $developers$, $document$ $so$ $many$ $details$ $of$ $the$ $expected$ $input$ $parameters$ $of$ $functions$ $and$ $completely$ $sanity$-$check$ $them$ $anyway$, $strictly$ $regulate$ $object$ $mutation$ $and$ $be$ $aware$ $of$ $so$ $many$ $aspects$ $of$ $the$ $speed$ $of$ $the$ $interpreter$ $runtime$ ...
    ...
    ...
    you might as well code the stuff in C.


    Don't misunderstand me, JSJSJS $is$ $great$ $for$ $UI$ $and$ $great$ $for$ $manipulating$ $HTML$/$XML$ $DOM$ ... $but$ $for$ $pretty$ $much$ $everything$ $else$ $it$'$s$ $almost$ $a$ $guarantee$ $for$ $a$ $total$ $mess$. :$P$
  4. #1264  
    Quote Originally Posted by Jappus View Post
    Ahhh, I love the smell of a new religious IT dispute in the morning.
    I won't go religious on you. I just know from experience that I've written good apps using javascript, and not just on webOS.



    -- Sent from my Palm Pre using Forums
  5. #1265  
    I was wondering if there is any plans to change the 10mb maximum size on opening files of Preader because of the limitations of the Javascript API? I have a book that I used to be able to open on my old palm TX that I can't open on preader because it is too big!
  6.    #1266  
    Quote Originally Posted by rsanchez1 View Post
    I won't go religious on you. I just know from experience that I've written good apps using javascript, and not just on webOS.
    Yup, as I said, there's a slice of applications that can be developed with JSJSJS $just$ $as$ $fine$ $or$ $even$ $better$ $than$ $with$ $the$ $more$ $common$ $languages$.

    But, a language is only a tool, it has specific perks and specific weaknesses. This often makes it suitable for some jobs and makes it fail for others. GUI and event-driven / intermittent processing is a very strong point of JSJSJS, $but$ general application development, especially of heavily computation-intensive apps isn't.

    But you're right, there's no point to go religious about it. All I really want to say is that one has to realize what the task is, and then choose accordingly, instead of choosing first and then trying to fit the task to it.

    That's what the deciders at Palm did wrong. They became enamoured with a choice (JSJSJS+$HTML$), $before$ $really$ $thinking$ $about$ $what$ $the$ $task$ $was$ ($general$ $application$ $development$).
  7.    #1267  
    Quote Originally Posted by greenwitch View Post
    I was wondering if there is any plans to change the 10mb maximum size on opening files of Preader because of the limitations of the Javascript API? I have a book that I used to be able to open on my old palm TX that I can't open on preader because it is too big!
    Yes, this limitation is a result of the Javascript API.

    So it's a good thing that the native version I'm currently developing isn't dependent on it anymore for file interaction. The future version will be able to open arbitrarily large files (well, below 4GB, but you catch my drift. ).
  8. #1268  
    Quote Originally Posted by Jappus View Post
    Yup, as I said, there's a slice of applications that can be developed with JSJSJS $just$ $as$ $fine$ $or$ $even$ $better$ $than$ $with$ $the$ $more$ $common$ $languages$.

    But, a language is only a tool, it has specific perks and specific weaknesses. This often makes it suitable for some jobs and makes it fail for others. GUI and event-driven / intermittent processing is a very strong point of JSJSJS, $but$ general application development, especially of heavily computation-intensive apps isn't.

    But you're right, there's no point to go religious about it. All I really want to say is that one has to realize what the task is, and then choose accordingly, instead of choosing first and then trying to fit the task to it.

    That's what the deciders at Palm did wrong. They became enamoured with a choice (JSJSJS+$HTML$), $before$ $really$ $thinking$ $about$ $what$ $the$ $task$ $was$ ($general$ $application$ $development$).
    And the solution they came up with is enabling C/C++ as a plugin, which is what I was going to recommend and you confirmed you would end up doing before I suggested it (as my above post shows).

    I'm not the evangelizing type, I use a C++ plugin in one of my apps because I know it would be the best tool for the particular job I'm using it for.

    You can extend javascript very easily, as the PDK shows, as node.jsjsjs $shows$, $as$ $even$ $Flash$ $shows$. $This$ $makes$ $javascript$ $great$ $for$ $application$ $development$ $when$ $you$'$re$ $mindful$ $of$ $what$ $tools$ $you$ $have$ $at$ $your$ $disposal$.
  9.    #1269  
    Quote Originally Posted by rsanchez1 View Post
    You can extend javascript very easily, as the PDK shows
    Actually, the PDK does not extend JSJSJS. $All$ $it$ $does$ $for$ $JS$ $is$ $to$ $provide$ $access$ $to$ $an$ $IPC$ $system$ $that$ $is$ $built$ $into$ $the$ $browser$. $That$'$s$ $like$ $saying$ $the$ $Java$ $Native$ $Interface$ $extends$ $Java$, $or$ ($to$ $leave$ $comp$ $sci$) $like$ $saying$ $you$ $can$ $extend$ $the$ $seafaring$ $abilities$ $of$ $your$ $car$ $by$ $loading$ $it$ $into$ $a$ $ferry$.

    The same pretty much goes for Flash, as there are only IPC-like wrappers between JSJSJS $and$ $Flash$'$s$ $Action$ $Script$.

    Node.jsjsjs $is$ $a$ $far$ $better$ $example$ $for$ $extensibility$, $because$ $it$ $extends$ $the$ $language$ $by$ $using$ $only$ $the$ $abilities$ $of$ $the$ $language$ $itself$. $But$, $to$ $be$ $honest$, $the$ $same$ $can$ $be$ $said$ $about$ $Java$, $C$, $C$++ $and$ $pretty$ $much$ $every$ $other$ $language$. $For$ $example$, $one$ $can$ $add$ $threading$ ($or$ $node$.$js$-$like$ $batch$-$parallelism$) $to$ $C$ $without$ $using$ $anything$ $else$ $but$ $C$-$code$.

    The only advantage to Javascript is that you can extend, overwrite and completely redo every single object primitive the language has to offer. But then again, that being an advantage is, again, pretty subjective.



    Apart from that, I guess we can agree on the basic sentiment of simply using the tools that are best for the particular job.
  10. #1270  
    Quote Originally Posted by Jappus View Post
    Recoding, no. The backend is completely resolution and hardware agnostic.

    But it will have to be recompiled. Which is basically a matter of feeding my library compilation script a new set of parameters and then waiting a few more minutes. After that, a quick 1 minute recompile of the actual application and wham! Tablet compatible.


    As for the front-end. It's all programmed to query and use the actual screen size, whatever it is. The page layout algorithm is O(log n) and should thus scale well regardless of the final amount of text on the page. Just as a reminder what O(log n) means: Doubling n (here, the page size) only adds a single computational step.
    Does that mean separate apps for each device or can they be rolled up & just install what's needed for that device?
  11.    #1271  
    Quote Originally Posted by govotsos View Post
    Does that mean separate apps for each device or can they be rolled up & just install what's needed for that device?
    Just install what's needed? No. If nothing changes between WebOS 1.4.5 and 2.1, I'll have to ship the binary of each platform with the app, if I don't want to split it into a Pixi and Pre variant. Of course, the Pixi binary would also work on the Pre, but it would be somewhat slower.

    At the moment, the size of the binary back end clocks in at 7.6 MB, so if I have to ship a Pixi, Pre and eventually Pad binary, that'd be a whopping 22.8MB. But for one, the binary compresses extraordinarily well, so that the IPK filesize is only 3.5 MB for the current Pre-only version. So in that case, a 3-binary IPK would eventually clock in at ~10MB.

    But that's not all either, as the reason why the binary compresses so well is that it contains the data files that the ICU library needs to convert charsets. A bit more than 6MB of the binary is plain charset conversion table data. Fortunately, this data is platform-independent and can be extracted from the binary.

    So at the end, the size of the 3 binaries will be ~4MB, together with a ~6MB data file. Together, they'll compress down to something like 4-5MB large IPK file.

    Compared to the Javascript version which clocks in at 0.3 MB, that's still enormous, but it's most definitely worth it.


    As for what the user has to do? If all goes well, nothing. Simply download the same pReader app and it'll automatically choose which binary to use. The only stumbling block I have to solve is how to determine if the app runs on a Pixi or a Pre. But if I don't find a way, I'll simply query the user one time during the first start up. Or simply use the heuristic of "if it runs, use it".
  12. #1272  
    Quote Originally Posted by Jappus View Post
    Yes, this limitation is a result of the Javascript API.

    So it's a good thing that the native version I'm currently developing isn't dependent on it anymore for file interaction. The future version will be able to open arbitrarily large files (well, below 4GB, but you catch my drift. ).
    Thanks for your reply! I'm waiting eagerly for your native version.
  13.    #1273  
    Hello, everyone.

    I just wanted to give a short heads-up on the progress of the native-alpha release. To make short work of it: It'll be able to crash your devices in a few, short days.

    I only need to finish implementing search and the links/bookmark/TOC handling. The latter is pretty much complete in the back-end and only needs a nifty front-end GUI. The former already has a front-end GUI and only needs a fast back-end implementation. Everything else is done and should be reasonably stable.


    I'll most likely open a new thread on this forum for the alpha-releases to keep this thread clean for the actual "final" versions. I'll also open up a bug-tracker on Sourceforge, because I expect a lot more bugs than with the current JSJSJS $version$. $Since$ $the$ $native$ $alpha$ $has$ $a$ $different$ $app$-$id$ $than$ $the$ $mainline$ $pReader$, $I$'$ll$ $also$ $be$ $able$ $to$ $put$ $it$ $into$ $the$ $PreCentral$ $App$ $feed$, $so$ $you$ $won$'$t$ $have$ $to$ $deal$ $with$ $manually$ $installing$ $the$ $IPK$ $files$ $as$ $they$ $come$ $out$.

    Then, after I've squashed the first batch of critical, device-crashing bugs, I'll try implementing all the remaining features as my schedule allows it. Remember, I'll still have to do my oral thesis defense and will eventually, if all goes well, be busy travelling throughout Germany from one job interview to the next.


    So we'll see what the next few weeks and months will yield.
  14. #1274  
    Great to hear that.
    And have a good luck on defence!
  15. #1275  
    Quote Originally Posted by cloudyifr View Post
    Wow, thanks! Easiest thing I've ever done on a computer. Well once I knew how!

    Curtis
    I didn't read ahead so hopefully no-one else said this. But if you want to edit an ePUB file, you *could* rename to zip and play with the contents. But if you screw the wrong thing up, it might not function correctly as an ePUB after you put it back together.

    There is also an app out there named Sigil that is free and will let you muck with the contents of the ePUB without having to rename or extract files. It understands the ePUB format and should hopefully protect you while you muck with it.
  16. #1276  
    Yahoo, I see there is an update from the 3rd of February, however, my app catalog says there is an update but no updates show up?

    Am I being impatient and need to wait for the update to actually show up?

    Thanks
    Curtis
    Palm Pre+
  17.    #1277  
    Quote Originally Posted by cloudyifr View Post
    Yahoo, I see there is an update from the 3rd of February, however, my app catalog says there is an update but no updates show up?

    Am I being impatient and need to wait for the update to actually show up?
    I think your App Catalog screwed up. I have not uploaded any new version yet.

    I did originally plan to prep everything for a release today, but I hit a very hard-to-track element counting bug that caused links to not lead to their actual target. Several hours of bug-tracking for a two-line bug fix. Yay!

    Anyway, both the encoding selection and TOC / links screen work properly now. So, tomorrow I'll do a last sanity check of the whole thing, prepare the bug-tracker and IPK package and then it's finally time for the native alpha release.
  18. #1278  
    I was just looking here:
    pReader | PreCentral.net | The #1 Palm Pre and Pixi Community

    It says:
    Last Updated:
    Fri, 4 Feb

    Sorry, just anxious is all. But I can be patient too. :-)

    Curtis
  19. #1279  
    Err, I'm anxious, does native means no Pixi support ? Or did you compile it with Pixi flags ? Because I love pReader but the limit of 10Mb is so bad...a newer version would be great !
  20.    #1280  
    Quote Originally Posted by simsor View Post
    Err, I'm anxious, does native means no Pixi support ? Or did you compile it with Pixi flags ? Because I love pReader but the limit of 10Mb is so bad...a newer version would be great !
    Well, it does now.


    Originally, I had planned to do the release yesterday, but unfortunately I discovered a show-stopping bug with ePub files that contain lots of high-byte UTF-8 chars ... things that can easily happen in Chinese, Korean, Japanese, etc. ePub files.

    So, during the arduous task of fixing that bug, I discovered a really nifty way of packaging the Pre and Pixi binary together into one package and only start the binary that's actually appropriate for the device. Yay!


    So, tomorrow (or today if you're in a fortunate time-zone) will see the release of the alpha version of the pReader for both Pixi and Pre.


    See you then.

Posting Permissions