Pippy and Calculate

[Yoshiki Ohshima]

  Hi, Chris,

> (I'm the Pippy author.)

  (We didn't have much time to discuss with you while I was in
Cambridge two weeks ago...)

>    >   Imagine if Pippy has a button called "Print!", which would be
>    > located right next to the "Run!"  button.  And, if "Print!" prints
>    > out the results of running the program into the bottom pane, that
>    > is pretty much all we need.  (For the record, the workspace in
>    > Etoys has been there from day one for this purpose.)
> 
> This is a useful idea, thanks.  At the moment, Pippy doesn't keep any
> variable/program state inbetween "Run!"s (each run is a new Python
> interpreter), so there is no way to do "Ans*2"-style calculations.
> It sounds like you want "Print!" to keep a single interpreter that
> reinterprets the source pane at each click.

  I didn't think about that aspect, but keeping state will be useful.

> The first version of Pippy used a single Python interpreter that
> executed the program source code in this way, without losing state,
> but that makes it possible to write programs that will not run on a
> fresh interpreter later (as they refer to state that was generated
> as a result of code that no longer exists, or a previous run of the
> code), so I decided against keeping that.

  Yeh, that can happen in a typical workspace programming.  But in
Pippy's setting, it would not be much of a problem.  "Keep" button can
store the state altogether into a journal entry.

> Oh!  We could have an "example" in Pippy that, when run, gives you a
> Python interactive shell.  That should work well; it gives you the
> mode you want (without requiring an extra button), and is useful in
> any case.  I'll do that.
> 
> I don't think Python's evaluations are useful as a calculator to
> a child, though.  You would have to explain this:
> 
> >>> 2+2
> 4
> >>> 3/4
> 0
> 
> I would like to add a simple graphics screen to Pippy, but I don't
> intend it to get many more features past that -- I'd like to keep
> it at a simple introduction to input/output programming.

  Yeah, I was aware of the division (/) problem (when I see the last
digit in Calculate falls off to the next line.  It would be nice if
you can override the division operator...

>    > We have a real problem of shortage of man-power, so replacing
>    > smaller activities that take more time to maintain and document
>    > with more powerful ones is probably a good thing.
> 
> Just a note that Reinier Heeres is a volunteer, so isn't pulling OLPC
> man-power away from any other projects.

  Well, a volunteer can certainly contribute one of OLPC projects,
right?

  I now see that the timeframe and practical matters will probably
prevent us going to the nice merging point between these different
projects.  However, I still contend that similarity is close enough.
So, for example Pippy doesn't have to be confined "this is a Python
thing" mind, but take advantage of similarity.

-- Yoshiki