Howdy, Bruce!

Howdy, Aaron!

Bruce: great!

I'll warn you both: I am still shifting back to US time from Central European Time, so I'm not exactly in top form this evening...

With that in mind, anyone have any questions?

Bruce: DROIDs that have not been upgraded to 2.0.1 have a couple of bugs, mostly related to version resource sets (e.g., -v4)

beyond that, I'm not aware of any bugs

Aaron Boonshoft: what specifically were you interested in?

Bruce: well, those names seem valid -- I thought perhaps the sets were in the wrong order, but the order you have them should work. Are you sure you were using an emulator with a small screen?

Aaron Boonshoft: Well, as I think I mentioned in the email, if other applications can use your RPL interpreter, then yes. If the RPL interpreter is tied exclusively to your own app, then no.

_Android Beyond Java_ will cover how application developers can create or extend apps without using Java, not so much on how to write a language interpreter for Android.

Aaron: that should fit the book. Let me know when it gets fairly stable.

Bruce: I would create a sample project that exhibits the problem, ZIP up the project directory, and get it out for other people to test.

You could post a link to it on [android-developers], or go straight for http://b.android.com and attach it to a new issue.

Aaron: I have no idea. You are inquiring about having RPL be covered in _Android Beyond Java_. The purpose of _Android Beyond Java_ is to illustrate how to create or extend Android applications using languages other than Java. If RPL fits, it fits. If it doesn't, it doesn't.

Remember, I never used RPL, so I don't even really know what it looks like.

One example I will be using in a couple of chapters in the book is JEP -- I'll be porting the last GPL'd edition over to Android, showing how to embed it, and perhaps showing how to tie it into the Android Scripting Environment.

JEP is a infix mathematical expression parser.

JEP might be used by calculator apps, or spreadsheet apps, or anything else that requires a "classic" mathematical expression to be evaluated.

For all I know, RPL might serve a similar role, just postfix instead of infix.

Yes, that's the current commercial one, IIRC. There's a GPL edition floating around on SourceForge

Bruce: The problem with Python and ASE, AFAICT, is that he's using CPython. The one Jython port I saw a while back seemed to be abandoned.

CPython will have difficulty connecting to Android, whereas Jython would be much simpler.

I'm impressed it works as well as it does.

Aaron: no, the JEP comment was aimed at you -- Bruce's one comment came in as I was typing.

Aaron: The commercial JEP is newer, but I don't know if there are major functional differences.

Bruce: Well, CPython's interpreter is compiled, whereas Jython's interpreter itself is interpreted (Dalvik VM bytecodes).

Bruce: Hence, I would expect CPython to be faster...so long as you can keep most of the processing in CPython. Trying to bridge back and forth between CPython and a Dalvik VM would add lots of overhead.

Aaron: My books are living documents. They get updated all of the time. The only part that doesn't get updated as frequently are the print editions.

Aaron: The earliest a print edition would be ready is April, and that would be *seriously* pushing it. More likely, May-June.

Aaron: happy to help!

Bruce: anything else I can help you with?

Not that I am aware of.

Then again, I haven't stayed tuned into the ASE realm for the past couple of months.

Happy to help!