NuScratch source on SqueakMap

There is now a SM entry pointing to a SqueakSource copy of the current NuScratch as per the Raspberry Pi. It is a rather substantial collection of bug fixes, performance improvements, tidy-ups, speed-ups etc to the original Scratch developed by the MIT team. Project files read and saved are fully compatible with the original system.

It runs on modern Squeak systems - I use a 5.0 with updates and it is likely that it won’t run perfectly on anything earlier than say #15852 because some time around then the help balloon stuff changed. I use a Cog/Spur system and make no representation about how well it might work on a non-spur or non-Cog system - I just don’t know and don’t really care.

On a RaspberryPi3 it runs large game-like Scratch programs about twice as fast as the original Scratch (a 2.8-ish image on a contemporary interpreter) runs on a modest mac laptop. Or to put it another way, it’s about a gazillion times faster than original Scratch on the same Pi.

The licensing remains as per the Scratch Source Code License (google it). You will need to download and unzip a copy of http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip *before* attempting to install the package.

It does *not* include the RaspberryPi specific GPIOServer code; that will appear in a separate package soon. That provides a way to drive al sorts of fun add-on hardware from Scratch - and indeed the lower level driver code for that provides a general Squeak access to the gpio pins and add-ons.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut vivas. = Get a life.

On Fri, Jun 17, 2016 at 07:19:11PM -0700, tim Rowledge wrote:
> There is now a SM entry pointing to a SqueakSource copy of the current NuScratch as per the Raspberry Pi. It is a rather substantial collection of bug fixes, performance improvements, tidy-ups, speed-ups etc to the original Scratch developed by the MIT team. Project files read and saved are fully compatible with the original system.
>

Excellent! Thank you for posting this Tim.

Dave

tim Rowledge wrote

There is now a SM entry pointing to a SqueakSource copy of the current NuScratch as per the Raspberry Pi. It is a rather substantial collection of bug fixes, performance improvements, tidy-ups, speed-ups etc to the original Scratch developed by the MIT team. Project files read and saved are fully compatible with the original system.

It runs on modern Squeak systems - I use a 5.0 with updates and it is likely that it won’t run perfectly on anything earlier than say #15852 because some time around then the help balloon stuff changed. I use a Cog/Spur system and make no representation about how well it might work on a non-spur or non-Cog system - I just don’t know and don’t really care.

On a RaspberryPi3 it runs large game-like Scratch programs about twice as fast as the original Scratch (a 2.8-ish image on a contemporary interpreter) runs on a modest mac laptop. Or to put it another way, it’s about a gazillion times faster than original Scratch on the same Pi.

The licensing remains as per the Scratch Source Code License (google it). You will need to download and unzip a copy of http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip *before* attempting to install the package.

It does *not* include the RaspberryPi specific GPIOServer code; that will appear in a separate package soon. That provides a way to drive al sorts of fun add-on hardware from Scratch - and indeed the lower level driver code for that provides a general Squeak access to the gpio pins and add-ons.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut vivas. = Get a life.

Hi Tim,

if you have troubles with the NewBalloonMorph, try disabling the preference "use new balloon morphs".

We are still working on harmonizing both. The new one has no good support to not appear at the mouse cursor. :-)

Best,
Marcel

On Fri, Jun 17, 2016 at 7:19 PM, tim Rowledge <[hidden email]> wrote:
> There is now a SM entry pointing to a SqueakSource copy of the current NuScratch as per the Raspberry Pi. It is a rather substantial collection of bug fixes, performance improvements, tidy-ups, speed-ups etc to the original Scratch developed by the MIT team. Project files read and saved are fully compatible with the original system.
>
> It runs on modern Squeak systems - I use a 5.0 with updates and it is likely that it won’t run perfectly on anything earlier than say #15852 because some time around then the help balloon stuff changed. I use a Cog/Spur system and make no representation about how well it might work on a non-spur or non-Cog system - I just don’t know and don’t really care.
>
> On a RaspberryPi3 it runs large game-like Scratch programs about twice as fast as the original Scratch (a 2.8-ish image on a contemporary interpreter) runs on a modest mac laptop. Or to put it another way, it’s about a gazillion times faster than original Scratch on the same Pi.
>
> The licensing remains as per the Scratch Source Code License (google it). You will need to download and unzip a copy of http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip *before* attempting to install the package.
>
> It does *not* include the RaspberryPi specific GPIOServer code; that will appear in a separate package soon. That provides a way to drive al sorts of fun add-on hardware from Scratch - and indeed the lower level driver code for that provides a general Squeak access to the gpio pins and add-ons.

Great!  And let us know about the status of /usr/bin/scratch shell
script.  We have people lined up to test things out so it'd be good if
we make sure it works smoothly on the next release.

--
-- Yoshiki

> On 22-06-2016, at 10:59 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> On Fri, Jun 17, 2016 at 7:19 PM, tim Rowledge <[hidden email]> wrote:
>> There is now a SM entry pointing to a SqueakSource copy of the current NuScratch as per the Raspberry

{snip}
>
> Great!  And let us know about the status of /usr/bin/scratch shell
> script.  We have people lined up to test things out so it'd be good if
> we make sure it works smoothly on the next release.

Excellent; I’ve been trying to get around to talking with you about this but the number of things that can get in the way is amazing.

We seem to have all the image parts fixed. We appear to have all the VM parts working too. I’ve been able to  make it all work together, though it can be very confusing to an english-only user when all the menus and dialogues are in a very out-of-band script. So I can’t offer any opinion of whether it works ‘properly’ or not.

I guess we need a script to go alongside the timidity midi-synth install script, that can load the ibus and relevant fonts etc. We’ll want some good documentation about what to do to both install and use *and* stop using it that can be put on the Pi website.

I can’t offer any opinion on the shell script since it simply makes no sense to me at all; I have no idea why we need to do things like
BIN=`/usr/bin/dirname $VM`
etc. Nor why we have to mess around with env LD_LIBRARY_PATH… how did we end up with such a deranged OS?

I’ve tried a quick test of your script and it just doesn’t want to work for me.
a) with only the 5.0-3663 vm in the ‘official’ place we get a failure because -composition-input on its own doesn't work; it needs the x11 thing too I suppose.

b) after copying my latest 3758 vm to /usr/lib/squeak the VM=`echo /usr….`` line results in listing two vm directories, which seems plain wrong. It certainly looks like it breaks the later ldd related code. Whatever it is that that is supposed to do…

c) In fact it appears that the `sort -r` produces exactly the same output as `sort`, so that would appear to be a problem? And then the `head` returns both paths too. Sigh. So the way of finding the latest vm available is just not working

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: HCFI: Halt and Catch Fire Immediate

At Wed, 22 Jun 2016 12:53:41 -0700,
tim Rowledge wrote:
> I guess we need a script to go alongside the timidity midi-synth install script, that can load the ibus and relevant fonts etc. We’ll want some good documentation about what to do to both install and use *and* stop using it that can be put on the Pi website.

Speaking of different use cases and languages, one thing I have not
tried is to have an on screen keyboard but in the English or European
locale.  The script I sent was just checking the presence of the XIM
environment variable but this may not be what we want.

> I can’t offer any opinion on the shell script since it simply makes no sense to me at all; I have no idea why we need to do things like
> BIN=`/usr/bin/dirname $VM`
> etc. Nor why we have to mess around with env LD_LIBRARY_PATH… how did we end up with such a deranged OS?

Ah, perhaps it is fine not to have to detect LD_LIBRARY_PATH, as this is
going to run on only one architecture (for a while).  But defining
LD_LIBRARY_PATH is needed IIUC.

> I’ve tried a quick test of your script and it just doesn’t want to work for me.
> a) with only the 5.0-3663 vm in the ‘official’ place we get a failure because -composition-input on its own doesn't work; it needs the x11 thing too I suppose.

Right. the main VM only started passing -composition-input to the
display module after that revision.

> b) after copying my latest 3758 vm to /usr/lib/squeak the VM=`echo /usr….`` line results in listing two vm directories, which seems plain wrong. It certainly looks like it breaks the later ldd related code. Whatever it is that that is supposed to do…
>
> c) In fact it appears that the `sort -r` produces exactly the same output as `sort`, so that would appear to be a problem? And then the `head` returns both paths too. Sigh. So the way of finding the latest vm available is just not working

Hmm, that is weird.  The idea is that when there are multiple VMs, the
one with the biggest number will be chosen by "sort -r | head -1"

-- Yoshiki

> On 22-06-2016, at 1:27 PM, Yoshiki Ohshima <[hidden email]> wrote:
> {snip}
>
> Ah, perhaps it is fine not to have to detect LD_LIBRARY_PATH, as this is
> going to run on only one architecture (for a while).  But defining
> LD_LIBRARY_PATH is needed IIUC.

We’re already way out of my zone…
{snip}

>> b) after copying my latest 3758 vm to /usr/lib/squeak the VM=`echo /usr….`` line results in listing two vm directories, which seems plain wrong. It certainly looks like it breaks the later ldd related code. Whatever it is that that is supposed to do…
>>
>> c) In fact it appears that the `sort -r` produces exactly the same output as `sort`, so that would appear to be a problem? And then the `head` returns both paths too. Sigh. So the way of finding the latest vm available is just not working
>
> Hmm, that is weird.  The idea is that when there are multiple VMs, the
> one with the biggest number will be chosen by "sort -r | head -1”

So far as I can see it can’t work because the ‘echo’ gives us a single line as an answer and my best guess (since man pages are so very carefully written to present a wall of text that makes no sense unless you already know the answer) is that the ‘sort’ expects some cr or nl in there. Thus we (probably) just get the one line and ‘head’ does nothing to help.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DO: Deadstart Operator

On Wed, Jun 22, 2016 at 7:27 PM, tim Rowledge <[hidden email]> wrote:
You're so right.  It should be 'ls' instead of 'echo'.



--
-- Yoshiki

> On 22-06-2016, at 7:40 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> On Wed, Jun 22, 2016 at 7:27 PM, tim Rowledge <[hidden email]> wrote:
>>>
{snip}
>>
>> So far as I can see it can’t work because the ‘echo’ gives us a single line as an answer and my best guess (since man pages are so very carefully written to present a wall of text that makes no sense unless you already know the answer) is that the ‘sort’ expects some cr or nl in there. Thus we (probably) just get the one line and ‘head’ does nothing to help.
>
> You're so right.  It should be 'ls' instead of 'echo’.

Except that with the git based builds it looks like we are moving to a somewhat different numbering sequence and so comparing any possible old copies with new ones is going to become harder. For example, a freshly built Pi vm is tagged as 5.0-201606241150 (ie the date/time)

I have no idea how we can solve that. Aside from the trivial solution of me including an explicit vm path in the Pi script, of course.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
He who hesitates is probably right.

On Fri, Jun 24, 2016 at 11:06 AM, tim Rowledge <[hidden email]> wrote:
Oh... That is interesting.  If the squeak VM package for the next
release of Raspian follows this new scheme, is it true that we'd only
have to support this format?  Or people may install or keep older
versions and we'd better support both?

> I have no idea how we can solve that. Aside from the trivial solution of me including an explicit vm path in the Pi script, of course.

Ok..  Somebody should be able to write a few more shell commands to
figure that out...


--
-- Yoshiki

On Fri, Jun 24, 2016 at 1:26 PM, Eliot Miranda <[hidden email]> wrote:
Thanks for chiming in.  The matter is more about to write shell script
that can find the latest VM when multiple ones are installed.  My
first attempt was to search in /usr/lib/squeak, sort entries and pick
the one with the biggest number (which used to be the svn revision
number).  I'm thinking to add two step detection; if the scheme that
is based on the yyyymmdd format does not turn up a VM, we then search
the older style version-revision VM in /usr/lib/squeak.


--
-- Yoshiki

> On 24-06-2016, at 1:38 PM, Yoshiki Ohshima <[hidden email]> wrote:
>>
{lots of snippy}
>
> Thanks for chiming in.  The matter is more about to write shell script
> that can find the latest VM when multiple ones are installed.  My
> first attempt was to search in /usr/lib/squeak, sort entries and pick
> the one with the biggest number (which used to be the svn revision
> number).  I'm thinking to add two step detection; if the scheme that
> is based on the yyyymmdd format does not turn up a VM, we then search
> the older style version-revision VM in /usr/lib/squeak.

Well the good news is that we can (since this is a shell script aimed at the Pi install of nuScratch) be a bit less general and assuming that from now on vm versions are indeed MAJOR.MINOR-DATETIME format then we need only handle those. The script will go into the next Pi release and need not concern itself with dealing with older VMs.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
You never really learn to swear until you learn to drive in Silicon Valley

> On 17-06-2016, at 7:19 PM, tim Rowledge <[hidden email]> wrote:
>
> There is now a SM entry pointing to a SqueakSource copy of the current NuScratch as per the Raspberry Pi.

{snip}

> It does *not* include the RaspberryPi specific GPIOServer code; that will appear in a separate package soon.

And said package is now available via SM. In fact so far as I could tell I managed to set things up so that if you install the ‘NuScratchGPIO’ package it will install the basic scratch stuff, the FFI stuff required and the gpio server and even the hardware library system. It’s amazingly hard to feel sure I was successful in starting from a truly vanilla setup, so do please try it out someone...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- All foam, no beer.