Click here

Hopefully, version 1 owners will see it in the App Store soon.

A programmer acquaintance compiled the source for me and I have been able to play with version 2 in advance. I/O support with a web interface, somewhat different from i41cx+, is now in place. Shifted label font is a little bigger. There is ability to display a four line stack, to rotate the stack with a swipe of the finger, and to scroll program listings with finger swiping. And the overall speed seems much improved--I noticed in some of my iterative programs v. 1 was much slower. Great little app. Alas, unlike with i41cx+, there is no way to export or forward printer output as text or images. Maybe in a future upgrade?

I hear that Thomas Okken's Free42 "original" is actively in the works and we should see it up on the App Store in a few weeks.

Great little simulators these are. I love i41cx+ for it's complexity and fidelity to the beloved 41CX original. But for importing and running 41C programs with greater speed and accuracy, these 42S simulators have a great edge.

Les

Les (or Thomas),

Can someone clear up how many Free42 ports are eventually going to be on the iTunes App Store? A day before this thread was started, I purchased the Byron Forster version, and now there is a mention of Thomas' "original" version. And an old post mentions a Susan Mackay version.

I thought these folks were assisting Thomas with the iPhone port, and that the Foster version is the official Free42 release.

Thanks,

PG

Edited: 9 June 2009, 1:07 p.m.

Quote:

---

Can someone clear up how many Free42 ports are eventually going to be on the iTunes App Store?

---

Short version: at least one, probably two, possibly more.

Long version: Byron made some design choices in his iPhone port that are different from how I wanted to approach it, and I started working on my own version as a result. Mostly these have to do with the UI; Byron's skin code, in particular, is completely different from how the existing ports work, while my own iPhone port is basically a port of the Motif version.

Both approaches have their benefits: Byron's code lends itself better to nifty UI enhancements, such as 4-line display, and displaying menus on the keyboard. My code does not support these features, but it does support user-selectable skins, which Byron's does not.

There will be other differences in the UI as well, with my version being closely modeled after the PalmOS version. In other respects, I expect both versions will converge in terms of functionality, so you will have the same functionality offered on all the other platforms (including print spooling, which is the only thing missing from Byron's version 2.0) -- regardless of whose port you may be using.

For the time being, of course, my version is vaporware; I have a couple of weekends of coding left to do, and I haven't had the time to work on it lately. Hopefully I'll be able to submit the first release before the end of the month, but I can't make any promises.


Byron's version, on the other hand, is out now, and his next version (2.0) is in the submission pipeline at the iTunes App Store as we speak; it addresses the two most common complaints about 1.0, namely, a facility to import and export "raw" program files, and an improved skin with larger shifted key labels, and it also has the nifty UI enhancements mentioned above.

Susan Mackay's version is not available at the app store, and Susan has no plans to publish it; she shared her code with Byron and me, and some of it was used in Byron's version.

Perhaps there will be additional Free42 ports for the iPhone sometime -- part of the fun of publishing open source software is that you never know. :-) I wouldn't count on it, though, since porting Free42 is more work than you might think, and porting it to a hand-held platform, with its constraints on the UI, is harder still.

- Thomas

Thanks for the info, Thomas.

Byron's version 2 still isn't up on the App Store almost two weeks after submission. If you get your initial submission in during the summer, count on a similar delay. It's a shame that Byron's revision is taking so long to show up, because I suspect that fans who went nuts for v. 1 will really approve of the improved skin and speed, program I/O, and UI enhancements of v. 2.

FYI, the "R/S sometimes won't stop running program" bug persists in Byron's version 2. I think he removed some "pause" code to improve speed. Fortunately, for practical purposes this isn't a big deal, and it is hoped the problem will go away entirely when iPhone OS 3 is out.

Les

The problem with R/S sometimes being ignored is pretty frustrating, but it goes back to poor design of the iPhone's event handling API. Some background:

The Free42 core was designed to be single-threaded; it has to be, in order to work on operating systems without thread support, like PalmOS.

In a single-threaded calculator simulator, you have to somehow be able to execute programs, while still keeping the UI responsive -- it should still respond to mouse and keyboard events, repaint requests, etc. Most environments support this by providing a function that lets a program poll the event queue without actually invoking any event handlers: PeekMessage() in Win32, XtAppPending() in the X toolkit, g_main_context_pending() in GTK, EvtEventAvail() in PalmOS.


While executing a program, Free42 simply calls the appropriate event queue polling function after finishing each program line; polling the event queue is a very cheap operation, so programs can run with little overhead, and still respond very quickly to events.


When Free42 detects that an event is pending, it returns control to the application framework. In order to be able to resume program execution once the application framework is done handling events, Free42 needs some way to schedule a function call to take place when the framework is otherwise idle; in Win32 and PalmOS, this is easy because the main event loop is part of the application itself, so it is a simple matter of inserting the call to run the program there; in more modern, callback-based environments like the X toolkit and GTK, you can use XtAppAddWorkProc() and g_idle_add(), respectively.

The iPhone makes this type of programming style difficult to impossible. First, there is no facility for peeking ahead in the event queue, so a single-threaded program has no choice but to drop out of the program execution loop at regular intervals and return to the application framework.


But it gets worse: in order for program execution to resume once the application framework has finished handling events, Free42 again needs some mechanism to schedule execution, but the only available mechanism is performSelectorOnMainThread, which will execute its target at the earliest opportunity, instead of being deferred until the event queue is empty. There is no mechanism for scheduling any activity to take place if and only if there are no pending events.

Byron has so far tried to work around the iPhone API limitations using straightforward hacks like inserting small delays in which the event queue can be emptied; in the latest code, this is working pretty well; you really have to try hard to get it into a state where the keyboard becomes unresponsive, and even when that does happen, it is easier to get out of that state than it was before. Still, the situation is not ideal, and stupid programs like LBL 00 BEEP GTO 00 can still cause the problem to occur fairly easily.


In my version, I chose a different approach, using a secondary thread for running programs, while the main thread stays in control of the UI and thus never becomes unresponsive. This has proven to be robust, but the code is very hairy, and the overhead from thread-to-thread context switching is considerable.

Byron has indicated to me that iPhone OS 3.0 has an improved event handling API, and that he thinks we'll be able to do Free42 "right" with it. I haven't studied the 3.0 APIs yet myself, so I can't confirm this, but, assuming the shortcomings of the existing API have indeed been remedied, I'd expect a point release to take advantage very quickly.

Of course "very quickly" can mean "one day for us to make the code changes, then two weeks or more of being stuck in the iTunes App Store submission queue". Such is life in iPhone developer land.

- Thomas

I have generally found that even on platforms that have decent event management APIs, it still tends to work best to run simulations in a separate thread from the UI thread. (Assuming, of course, that the platform supports threads.)

Quote:

---

I have generally found that even on platforms that have decent event management APIs, it still tends to work best to run simulations in a separate thread from the UI thread.

---

I'm sure that's true, but not all simulations are created equal. :-) In particular, simulating a calculator at the user-code level is a bit different than simulating it at the hardware level.


One advantage of the former is that you always know exactly what state the simulator core is in; the basic flow is simply idle -> key press -> execute the appropriate function -> update the display -> idle.


This is very simple to implement and has zero overhead.


Things get tricky only when you are simulating a programmable calculator; then you have to somehow run the program and handle events concurrently. Threads are an elegant solution for this kind of problem in principle but can be hairy in reality, because of the need to synchronize access to shared resources etc. In a single-threaded app, reentrancy is much easier to avoid or manage.


Polling the event queue from the program execution loop may not be architecturally elegant, but it is actually very efficient. I was pretty annoyed to find that the iPhone has zero support for this programming style; while I was able to get things to work reliably using threads, I ended up having to spend several days ironing out all the wrinkles -- several days that I never had to spend on any of my single-threaded implementations.

Quote:

---

Of course "very quickly" can mean "one day for us to make the code changes, then two weeks or more of being stuck in the iTunes App Store submission queue". Such is life in iPhone developer land.

---

42S 2.0 is now out. Interesting that 3 calculator apps including i41CX+ also updated. Perhaps the calculator app store czar was behind.

What's the third one?

Les

pcalc. I do not use it anymore.

Quote:

---

What's the third one?

Les

---

4th RPN Calc iphone app updated today: MAcalc/MAcalc Pro by Márcio Almeida, http://www.ttrix.com/

Has anyone played with Lua on MAcalc?!

It must be watered down and/or flying under the radar to be on iTunes. I believe Apple still has a "no programming languages allowed" law. Maybe the calc app czars thought MAcalc is RPN programmable or this version of Lua harmless. (After all, it is stuck inside MAcalc).

Here is a blurb regarding languages on iPhone.

"Javascript is an interpreted programming language, and thus forbidden as per Apple's terms of service.

Also banned from the iPhone: programming languages Ruby, Python, Perl, and Java. Quake, the video game engine ported to practically every platform (including Google's Android), as well as Microsoft's Word, Excel, and .NET are also persona non grata."

(year old link: http://news.cnet.com/8301-13739_3-9889159-46.html)

I like Lua. Any user experiences with MAcalc and Lua would be appreciated.

Cheers,

PG

I'm pretty sure that the idea behind the "no programming languages" rule is to prevent application developers bypassing the App Store. In order for a language to make that possible, it has to provide access to the iPhone APIs for creating windows and UI components, etc; language interpreters that don't provide such access, can't be used to build unauthorized applications and are therefore not considered a problem.

Note: I'm not an Apple representative; the above is just my take on the underlying rationale behind the "no programming languages" rule. I am encouraged by the fact that Apple do not seem to have a problem with the many programmable calculators available on the App Store; I'd expect them not to object to spreadsheet macro languages etc. either.

Quote:

---

"Javascript is an interpreted programming language, and thus forbidden as per Apple's terms of service.

---