Hello,

2014-08-29 6:22 GMT+09:00 John McIntosh <johnmci at smalltalkconsulting.com>:
> Ok, very nice. Thank you for the acknowledgement.

Pyonkee was started from your great work. Special thanks again!

I have never tried iOS 8. So such information is very useful.
Especially on memory allocation, I was wondering why mmap is used. I
will replace the code to use malloc on the next release.

Best regards,

> 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
> ===========================================================================
>
>
>



-- 
[:masashi | ^umezawa]