Scratch

the "upvar saving problem" doesn't seem to be fixed yet; I tried it this morning.

joefarebrother wrote:

the "upvar saving problem" doesn't seem to be fixed yet; I tried it this morning.

According to Jens it's really a problem about custom blocks with empty bodies, but in any case, he's working on it.

roijac wrote:

Yeah, you're right, variadic functions should be callable with variable-length input lists.  Do we special-case having zero inputs in the called block?  Do we special-case having any number of input slots but no values given?  And what if the variadic block is an input to something else?  E.g., what should

CALL ([LIST] + ( )) [LIST (...) (...) ...]

do?

P.S.  Jens is going to send me an email saying "See?  Filling empty input slots without explicit formal parameters is all a bad idea." 

Last edited by bharvey (2012-05-07 16:14:26)

joefarebrother wrote:

Then maybe there should be a way to specify a varadic input on a ring?

Yeah, eventually we want to be able to click on a formal parameter of a ring and get the whole long form input dialog.  Probably not soon.

Hardmath123 wrote:

scimonster wrote:

Hardmath123 wrote:

Being a Mac user, I just drag it onto my folder. 

Jens, maybe you could set the document.title to something a bit nicer than the DataURI, so that if you open up 3 or 4, you can tell them apart. Even something as simple as Script1, Script2, etc. would help out a lot. Thanks!

It's an image fie though, not an HTML. The browser automatically uses the URL as the title.
Hey, you can use document.title to change the title? Cool!

Well, as far as I'm concerned, just the window title is good enough, because I rename the images anyway.

You shouldn't use window.title "just like that", you should only use it for specially generated windows. Content windows like a normal blog shouldn't change their title during runtime as it can confuse search engines. Imagine a page titled "blogp1" in Google!    Anyway, it is in some cases even a form of SEO because someone can title a window "Our Solar System" in the HTML, then rename it to "Cheap Deals on Airline Tickets" in the JS.

Very useful in AJAX heavy pages though. 

yeah, but if you press the red stop sign the bubble disappears 

the URI encoding of project strings is just a temporary thing I'm needing in developing the cloud backend, whereas the regular (non-shift) export function is actually somewhat useful...

shadow_7283 wrote:

Scratch 2.0 fails to stack up to Snap!, imo. Not that it was ever a competition or anything. 

No, of course not. 

You could argue that the progress they're making from 1.4 to 2.0 is more than the progress we're making from 3.1 to 4.0 -- we'll be doing well if we can avoid moving backward!  Somewhere around 4.2 or 4.3 we'll start making real progress again, with new first class data types (costumes, etc.).

All that social networking stuff they're doing leaves me cold, I admit, but vector costumes are neat and the webcam thing is super neat!  (We are going to support the Knect, though, because we're working with a Microsoft guy on a high school education project they run.)

Anyway, thanks for the compliment.  Takes my mind off grading. 

Lucario621 wrote:

I wonder what kind of kinect blocks there will be!

Well, we haven't started doing it yet...  but presumably we'll make the primitive block(s) as low-level as possible, and let people build libraries on top of that.  Scratch doesn't have that luxury. 

slinger wrote:

You're going to try to get low-level with JavaScript!? (I assume you're still making snap in JavaScript 'cause that's what you were doing last I checked :b)

Yup, Javascript.  It's possible that we'll have to have a separate program that actually talks to the USB port and then talks to Snap! over a net socket.  What I mean by "low level" is that, for example, there will be a "read Kinect" block that takes whatever numbers the device gives us, puts them in a list, and then lets the user turn them into useful window-relative coordinates or whatever the program needs.

Hey, that got me thinking: you can actually access the gyro sensors on various devices (MacBook Pro, iPad) with JavaScript. Maybe Snap! could support that? It would be awesome to write simple motion-oriented games for an iPhone with Snap! 

Hey, sorry about this week, I didn't work on the images at all. I was sorta busy with real life. I'll work on it next week.