pippy-devel Mailing List for Pippy: Python for PalmOS
Brought to you by:
tokeneater
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <ig...@ya...> - 2003-02-14 03:57:38
|
Dear List, I tried to compile pippy using the last CodeWarrior and with the last tools for palm development too. In the two cases there was a lot of problems in the compilation stage, still unsolved on my side. First, I would like to know what version of prc-tools, sdk, codewarrior, etc, etc is compiling smoothly the pippy source code into .prc. I will attach in a next post the compiling errors I was suffering although I would like to know if it's normal to have a lot of problems compiling pippy. Thanks you all. Iggeres ___________________________________________________ Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito en http://moviles.yahoo.es |
From: Jeffery D. C. <jco...@bo...> - 2002-05-11 20:18:04
|
Tim Chase wrote: >Since there hasn't been much legitimate traffic on the pippy list >lately, and since pippy development has moved to Sourceforge, I thought >that I would weigh in with my $.02 on what Python on Palm could be. >This is a future-seeing, pie-in-the-sky, wish list. I am not >criticizing current pippy development, but giving some examples of >features we may want to include in pippy. > >First, Python Rules! I use it whenever possible for Unix (mostly Zope) >and Windows development. > > Sorry for the slow response. I needed some time to dig up some old data for reference purposes. Thanks for this information. It is very informative. >I have been using several very high level languages for PalmOS(tm) >development and I will describe them and several features that I wish >could be incorporated into a mythical future pippy. [That is the last >time here that I will put the (tm). Keep in mind that the words PalmOS >and Palm are trademarks of Palm Computing or PalmSource.] > >Quartus FORTH > >Forth is unique in many respects. It is both very high level and very >low level. The bottom of your program looks like English (or you >language of choice, because you make up the words) and the top of your >program looks like assembly. Quartus uses memos or docs for source >code. For UI, Quartus uses resources from a Palm resource database. You >can use one of several tools, including the onboard RsrcEdit (now owned >by Quartus) to create forms and all of the UI elements for the forms. >You then use the event queue to load the forms and respond to user >interaction with the form elements. Quartus also allows for direct >interaction with the PalmOS through system traps. You can compile a >stand-alone program that doesn't require a runtime. See >http://www.quartus.net/ > The IBM J9 JVM uses the system traps to call into the PalmOS api. While there is a higher risk of crashing the device (which is unpythonic), it would avoid the necessity of creating an extension module every time a PalmOS call is needed. This may be an acceptable way for dealing with the GUI problem, too. > >PLUA > >PLUA is a PalmOS port of the Lua programming language. Lua has some >similarities to Python. It uses "tables", which are similar to Python >dictionaries. The syntax is very clear. PLUA uses memos or docs for >source code. It has a built-in environment that is superior to that of >LispMe (at least older versions of LispMe, I haven't used it in a >while). Plua uses internal functions to draw UI elements. I don't like >this as well as using a Palm resource database. It is slower. It does >provide flexibility. However, Palm resources database elements can be >hidden and moved about, which also provides flexibility. If you haven't >ever heard of PLUA, check it out at >http://netpage.em.com.br/mmand/plua.htm > >Poplet Kit > >This is the most unique use of a very high level language on the Palm. >If pippy could do what Poplet Kit does, but take it a few steps >further, pippy would be the true PalmOS scripting language. "Poplets" >are written in Handscript which is very similar to ECMAScript >(Javascript). Poplets are launched in two ways. > >The first way is via the command bar. Starting in PalmOS 3.5, when you >issue a Graffiti command stroke, a bar pops up at the bottom of the >screen. You can choose to copy, paste, etc. by clicking on the command >bar icons. Poplet Kit installs another icon on the command bar. When >you hit it, a menu pops up with all of the available poplets. You >choose a poplet and it runs. I know that PalmOS doesn't multitask and I >am not a computer science guy, so I am not sure what to call this >(cooperative multitasking?), but your poplet runs and interacts with >the current application. For example, you select some text in the >DateBook, or memo, or wherever, and run a poplet to make the text all >caps, or perform a mathematical manipulation on it, or translate it to >French. > I've received other suggestions for using Pippy for this purpose. Pippy (using prc-tools) uses a GLib shared library for the storage of the interpreter. Embedding this in a small front-end program and finding someplace to store the 100K global variable space necessary for running it, we should be able to make calls into it in a way similar to the poplets. The 100K of heap space seems a bit excessive for small scripting purposes. I do prefer python to just about anything else, though.... > >The second way to launch a poplet is via the palmcall: syntax in >Clipper (or another web clipping application or browser). In several of >the included examples, you launch a poplet within Clipper, your address >book pops up, you select an entry, and the poplet returns a Clipper >page with the address of the nearest Starbucks, ATM, etc. > >Poplet Kit's maker, Handwave (http://www.handwave.com) is focused on >the second use mentioned above, poplets as Clipper javascript. I see >great potential in the first use. The PalmOS system trap mechanism, >combined with the ability to launch from the command bar means that a >program could provide scripting capabilities both within applications >and within the operating system itself. For example, given the ability >to send an event to the event queue, you could automate button presses, >Graffiti strokes, any possible user interaction. Combine this with the >ability to retrieve events from the event queue, and you have a PalmOS >macro system. > > >Although interactive mode is one of the coolest features of Python >programming, I would gladly give it up to be able to use Python syntax >on PalmOS. > > >In short, here is my list of features I wish for in a Python on PalmOS: > > >Program Mode >1.Use and manipulate UI elements from a Palm resource database >2.Distribute applications either with or without runtime >3.Access to system traps to use features not directly implemented > > These are all excellent suggestions. I have been told that items 1 & 2 (or portions of these) hav been completed by a possible contributor, but haven't yet received patches. Item 3 is of particular interest to me. Patches encouraged. >Script Mode >1.Launch from the command bar >2.Interact with UI elements of the current application >3.Interact with the operating system (launch another app, turn on >backlight, etc.) >4.Distribute scripts either with or without runtime >5.Access to system traps to use features not directly implemented > > This project was moved to sourceforge to encourage more active development from the Python/Handheld community. I would like to see more developers get involved in contributing and help to determine the direction of Pippy. If you have been developing using Pippy, please tell us how your are using it and what other capabilities you would like to see. Tim, thanks for your suggestions and explanation of other technologies. Jeff Collins |
From: Tim C. <ch...@ia...> - 2002-05-09 17:30:41
|
Since there hasn't been much legitimate traffic on the pippy list lately, and since pippy development has moved to Sourceforge, I thought that I would weigh in with my $.02 on what Python on Palm could be. This is a future-seeing, pie-in-the-sky, wish list. I am not criticizing current pippy development, but giving some examples of features we may want to include in pippy. First, Python Rules! I use it whenever possible for Unix (mostly Zope) and Windows development. I have been using several very high level languages for PalmOS(tm) development and I will describe them and several features that I wish could be incorporated into a mythical future pippy. [That is the last time here that I will put the (tm). Keep in mind that the words PalmOS and Palm are trademarks of Palm Computing or PalmSource.] Quartus FORTH Forth is unique in many respects. It is both very high level and very low level. The bottom of your program looks like English (or you language of choice, because you make up the words) and the top of your program looks like assembly. Quartus uses memos or docs for source code. For UI, Quartus uses resources from a Palm resource database. You can use one of several tools, including the onboard RsrcEdit (now owned by Quartus) to create forms and all of the UI elements for the forms. You then use the event queue to load the forms and respond to user interaction with the form elements. Quartus also allows for direct interaction with the PalmOS through system traps. You can compile a stand-alone program that doesn't require a runtime. See http://www.quartus.net/ PLUA PLUA is a PalmOS port of the Lua programming language. Lua has some similarities to Python. It uses "tables", which are similar to Python dictionaries. The syntax is very clear. PLUA uses memos or docs for source code. It has a built-in environment that is superior to that of LispMe (at least older versions of LispMe, I haven't used it in a while). Plua uses internal functions to draw UI elements. I don't like this as well as using a Palm resource database. It is slower. It does provide flexibility. However, Palm resources database elements can be hidden and moved about, which also provides flexibility. If you haven't ever heard of PLUA, check it out at http://netpage.em.com.br/mmand/plua.htm Poplet Kit This is the most unique use of a very high level language on the Palm. If pippy could do what Poplet Kit does, but take it a few steps further, pippy would be the true PalmOS scripting language. "Poplets" are written in Handscript which is very similar to ECMAScript (Javascript). Poplets are launched in two ways. The first way is via the command bar. Starting in PalmOS 3.5, when you issue a Graffiti command stroke, a bar pops up at the bottom of the screen. You can choose to copy, paste, etc. by clicking on the command bar icons. Poplet Kit installs another icon on the command bar. When you hit it, a menu pops up with all of the available poplets. You choose a poplet and it runs. I know that PalmOS doesn't multitask and I am not a computer science guy, so I am not sure what to call this (cooperative multitasking?), but your poplet runs and interacts with the current application. For example, you select some text in the DateBook, or memo, or wherever, and run a poplet to make the text all caps, or perform a mathematical manipulation on it, or translate it to French. The second way to launch a poplet is via the palmcall: syntax in Clipper (or another web clipping application or browser). In several of the included examples, you launch a poplet within Clipper, your address book pops up, you select an entry, and the poplet returns a Clipper page with the address of the nearest Starbucks, ATM, etc. Poplet Kit's maker, Handwave (http://www.handwave.com) is focused on the second use mentioned above, poplets as Clipper javascript. I see great potential in the first use. The PalmOS system trap mechanism, combined with the ability to launch from the command bar means that a program could provide scripting capabilities both within applications and within the operating system itself. For example, given the ability to send an event to the event queue, you could automate button presses, Graffiti strokes, any possible user interaction. Combine this with the ability to retrieve events from the event queue, and you have a PalmOS macro system. Although interactive mode is one of the coolest features of Python programming, I would gladly give it up to be able to use Python syntax on PalmOS. In short, here is my list of features I wish for in a Python on PalmOS: Program Mode 1.Use and manipulate UI elements from a Palm resource database 2.Distribute applications either with or without runtime 3.Access to system traps to use features not directly implemented Script Mode 1.Launch from the command bar 2.Interact with UI elements of the current application 3.Interact with the operating system (launch another app, turn on backlight, etc.) 4.Distribute scripts either with or without runtime 5.Access to system traps to use features not directly implemented Thanks for listening, Tim Chase Handbright PDA Software |