Ok, very nice. Thank you for the acknowledgement.

I note it does not work in iOS 8, as there is a problem with:

(a) the logging code, I'd replace it with something more modern but you are
welcome to report the bug(s) in Core Foundation String usage to Apple.
(b) The memory allocation code tries a 500MB start point, but that fails,
600MB works.

Note consider replacing the mmap memory allocation with a malloc to the
proper size and fill with the image.  The very specialized logic there was
to allow non-shared memory mapping of the file, followed by anonymous free
space past the end of the last object in the image to the maximum size you
allow the squeak memory space to grow to.

Now the iOS file node memory pager would page in pages on demand, so
although you might ask for 30MB out of the 48MB you had on an iPhone 3, why
we really had was about 12MB in flight because those pages included the
active objects within the image at this point. This reduced our dirty page
count thus making us less likely for the memory usage monitor to zap us.

At one point this was rolled out on os-x but it was later removed because
there was a bug in memory mapped files using an NFS connection to a server.
Also the os-x file node pager would  page the entire file into memory at
once which was different from iOS behaviour, although it gave faster
reading performance than the read() logic as the VM pager is more
efficient. If you look at the legacy squeak VM you should find the code
needed,

(c)  Set the code optimization to -Onone for debug, versus deployment.

(d) Someone might consider auto coding prototypes for all the generated VM
code and support code. My feeling in working with this is that the issue
with code optimization is that without prototypes something is assuming you
have int foo(int fun...) where that is not the case.  I did try to code up
the prototypes for the memory accessors and was able to run the non-gog VM
right unto the point where we asked for the TIME.  The time value flowed
back up as a signed integer, er or was that it was a truncated 64bit
integer? That spoke to an issue with prototypes and optimization.

Also some effort should be put into making SqueakUIViewOpenGL work as it's
much faster and I think the issue revolves around the scale factor in
open/gl for retina displays.

If you've not talked to Tim about changes they made to Scratch code base
for the PI computer, you should do so as they made many improvements to the
graphics pipeline as the PI is not a very capable GPU device.




On Thu, Aug 28, 2014 at 4:57 AM, Masashi UMEZAWA <masashi.umezawa at gmail.com>
wrote:

> Hi all,
>
> I have just released a Scratch clone running on iPad. It is based on
> Scratch 1.4 from the MIT Media Laboratory.
> The app is now called "Pyonkee" - freely available on App Store.
> https://itunes.apple.com/us/app/pyonkee/id905012686
>
> Pyonkee was originally started as a fork of John M McIntosh's Scratch
> Viewer.
> https://github.com/johnmci/Scratch.app.for.iOS.
>
> While Scratch Viewer just works as a viewer of the existing Scratch
> projects, Pyonkee supports creation/edit of projects.
>
> Other features:
> - User interfaces are optimized for iPad
> - Native font support
> - Embedded camera support
> - IME support
> - Auto-saving project
> - Sending projects via e-mail
> - Project import/export through iTunes (currently disabled)
>
> Moreover, source code is open on github. Feel free to fork it.
> https://github.com/SoftUmeYa/Pyonkee
>
> Enjoy!
> --
> [:masashi | ^umezawa]
>
>


-- 
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
https://www.linkedin.com/in/smalltalk
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140828/0b50ae1f/attachment.htm