Bibi, a Scratch port to recent Squeak

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Bibi, a Scratch port to recent Squeak

J. Vuletich (mail lists)
Quoting Frank Shearar <[hidden email]>:

>> ?snip?
>> The changes are at
>> https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-FixRecentMorphicSlowDown-JuanVuletich-2013Feb26-22h41m-jmv.1.cs.st
>>
>> Cheers,
>> Juan Vuletich
>
> Ah, I see. Thanks; I hadn't thought to look elsewhere in the repository.
>
> Also, that confirms my suspicion that the way Squeak/Cuis updates work
> is analogous to a database migration: take some big chunk of state,
> and mutate it in these specific ways.

Well, that´s the way the Cuis image is updated. It is the same as the  
"update stream" Squeak used to have.

> The problem being that to see what actually changed requires something
> in the state induced by #1618, applying the 1619 changeset, and
> comparing the #1618 state with the #1619 state.

Yes. Not a problem in my view. To me, the best way to understand the  
behavior at levels #1618 and #1619 is to run the system updated to  
those levels, and use the Smalltalk tools to study it. I.e. I´m a  
classical smalltalker.

BTW, for external packages, we store the full code in a format GitHub  
can understand, version, diff, merge, etc. See, for example,  
https://github.com/bpieber/Cuis-StyledTextEditor/commit/e01cf430657739bfcca197fc9bb1d872e30dd3a2 
..

> I don't mean this as a criticism - I'm jut formalising my
> understanding of how we actually work.
>
> frank

Criticism is welcome too. I´d really like to have something better for  
the base image, while keeping the nice properties of ChangeSets and  
the update stream. Maybe using DeltaStreams instead of ChangeSets  
would be an option. We´d need to see how to make GitHub ´understand´  
them.

Another option would be to commit, in addition, a condensed Sources  
file each time, to let GitHub diff that?

Cheers,
Juan Vuletich


Reply | Threaded
Open this post in threaded view
|

Re: Bibi, a Scratch port to recent Squeak

timrowledge
In reply to this post by J. Vuletich (mail lists)

On 27-02-2013, at 3:35 AM, Juan Vuletich (mail lists) <[hidden email]> wrote:
>>>
>>>
>>> Cuis 4.1 now opens windows as quickly as Cuis 4.0, i.e. as quickly as
>>> Scratch, and at least 5 times faster than Etoys or Squeak.


It's certainly better on the Pi but browser opening is still not as fast as the Scratch image. On the Pi it is as near instant as makes no practical difference.

Not that 450mSec is disastrous by any stretch of the imagination. What does impress me right now is that it doesn't slow down as I open  a dozen or so browsers. In fact
[12 timesRepeat:[BrowserWindow openBrowser]] timeToRun
reports 5200mSec or an average of 430mS.

Same VM, same machine, Squeak4.4-12327
[Browser openBrowser] takes 1900 mS
[12 timesRepeat:[Browser openBrowser]] timeToRun reports 23200

So Cuis is ~4.5 times faster at this test. Good work!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Eagles may soar, but weasels aren't sucked into jet engines.



Reply | Threaded
Open this post in threaded view
|

Re: Bibi, a Scratch port to recent Squeak

timrowledge
Hmm, interesting - I thought the Cuis world menu opening seemed a bit slow on the Pi but it's also quite slow enough to be annoying on my iMac 3GHz/Cog combo. That implies something must need improving I'd say :-)

And I look into TheWorldMenu>buildWorldMenu and I weep for wasted cpu cycles that are thrown away carelessly like confetti into a firestorm.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
boutique - a startling hardwood




12