Scratch

Jens wrote:

Okay, I can see your project now. Looks like a bug in the REPORT primitive to me, thanks! We must be in the same timezone, I don't have any secret scripts on the website 

Could that be the source of my problem with my nondeterminism project?

Snap! Lags a lot for me, and I can't seem to figure out why.

I'm using Chrome on a Mac Mini running OS Lion.

Jens wrote:

Hardmath123 wrote:

...

Fixed it, thanks again for the bug report!

You're welcome. Out of curiosity, what was the glitch?

Wha-? My nondeterminism project STILL causes an error????? After the REPORT fix?????

I really want to explore the possibility of starting an AP Computer Science course at my school. Is the Snap! CS material ready?

boukeas wrote:

Hello everyone. This post has to do with running BYOB on the latest versions of Debian/Ubuntu.

While trying to package Scratch for the debian repositories, the maintainers discovered that it was incompatible with the latest versions of the Squeak virtual machine. In particular, attempting to run the Scratch.image simply resulted in a blank screen. The problem was pinpointed to Scratch's use of (deprecated) numbered primitives, instead of named primitives. This issue has now been resolved with Scratch and it has been made available in the debian and ubuntu repositories.

Detailed descriptions along with the applied solution can be found in http://goo.gl/G1vnf and  http://goo.gl/mNr13.

Unfortunately, the same issue arises in BYOB. The .deb package available through the BYOB website comes bundled with a much older version of the sqeak-vm which is able to successfully run the BYOB.image. However, attempting to separately package byob, in order to run with a current version of the sqeak-vm (as in http://goo.gl/rsDza) now fails with the same blank screen...

In my opinion, this issue is not trivial: the "channels" through which such software is made available is significant. In my country, for example, software for the computer labs in schools is made available through an official launchpad repository. It would make a big difference if BYOB was available through that repository, compatible with the current squeak-vm.

I know Snap! is the current focus for development but is there any chance that this issue can be resolved? Basically, as far as I can tell, it would simply mean publishing an updated version of the BYOB.image, with all the the numbered primitives replaced with named ones.

well, i'm the one who packed the .deb
i would like to upload this on launchpad or something, but i'm absolutely new to squeak, so if jens or someone from the scratch team could just make the new .image, or tell me how scratch team did it, it would be great

Thanks for pointing this out. Personally I don't know anything about Debian and don't really understand the issue here: Can't you have several different VM's, one for Squeak and another one for BYOB? This can't possibly be a technical problem, right? Is it some kind of licensing thing?

AFAIK it was Bert Freudenberg who edited the Scratch image to make it work with a newer Squeak VM (one which deprecates numbered primitives) for the Scratch .deb package, but he was hired by the MediaLab to do it. Personally I'm very reluctant to put a lot of effort into changing fundamentals in the BYOB code just for ideological reasons, without adding any technical benefit. Plus, you know, I already did put an enormous effort into rewriting BYOB from the ground up as Snap! which I hope also runs under Debian (?)

bharvey wrote:

I'm nervous that the exam will all be stuff like how many bits in a byte.)

Happened to me. I did some weird computer test our school administered with questions like "which of the following is found under the view menu?". Believe it or not, I ended up coming in second place among a few thousand people, and won a cool $1,000. 

Hardmath123 wrote:

bharvey wrote:

I'm nervous that the exam will all be stuff like how many bits in a byte.)

Happened to me. I did some weird computer test our school administered with questions like "which of the following is found under the view menu?". Believe it or not, I ended up coming in second place among a few thousand people, and won a cool $1,000. 

...under the view menu? That's a computer test? I little vague I'd think.

Hardmath123 wrote:

dreamod wrote:

Hardmath123 wrote:

Happened to me. I did some weird computer test our school administered with questions like "which of the following is found under the view menu?". Believe it or not, I ended up coming in second place among a few thousand people, and won a cool $1,000. 

A mac test?! I wish my school would do that!

No, Windows. 

OK, I'm using BYOB for a CS Principles class, and in a lab exploring algorithm complexity I experienced some strange behavior that I can't explain - I suspect it would take someone who knows about internals of BYOB/scratch implementation to understand this, but here's the description:

I had students build a block to find the maximum in a list. Then they were supposed to test it using the timer and see how long it took on lists of different sizes (500, 1000, and 2000) - should see a nice linear time behavior, right?

This was part 1 of a lab exercise, where part two was to look at selection sort as an example of a quadratic time algorithm. It turns out that in my tests, the behavior of the very-obviously-quadratic-time selection sort was not behaving like a quadratic time algorithm unless I made sure all blocks were marked as "non-atomic" - ok, that slows things down a lot, but algorithms are giving reasonable behavior that way, so I just told all students to make all blocks non-atomic.  Good enough for learning about algorithms, right?

Back to the "max" block: what I had in mind was a basic reporter block, and then snap that into a "set" with a dummy variable, slap timer reset/read around that, and voila a timed algorithm.  Ran this on a list of 1000 random values and it took about 25 seconds.  OK, slow as molasses, but when compared with times on other list sizes it shows linear time behavior.

So now it's lab time, and a few students misunderstood how to time this, and put the reset/read timer blocks inside the max block, and then just drug out and clicked directly on the reporter block in the scripts pane.  Run time was about half a second. So now I test this out, and here's the behavior: click directly on the reporter block, and it takes half a second. Move the exact same reporter block into a "set" block with a dummy variable - and nothing else - and it takes 25 seconds.

So the context that the block is used in (directly from the script pane or in a set block) drastically affects the performance!  In fact, the fast performance is consistent with the time when the block is set as atomic, so does clicking on it directly somehow force atomic execution?

Hopefully what I just described is clear, and someone will be able to explain this strange behavior.  I can provide specific examples if you'd like...

srtate wrote:

Move the exact same reporter block into a "set" block with a dummy variable - and nothing else - and it takes 25 seconds.

Was there a stage watcher for that variable?  Updating the display takes more time than computing the value.