At this stage Snap! offers the "custom block" capability with set foo + C-script + its #1,#2..variables (named varfunc) Two drawbacks : 1 -call/run this block 2- with a dozen of long varfuncs the Script Area becomes rapidly crowdy. But I must admit that Snap! handles this "crowd" very efficiently , better than Byob.
The new block feature at this stage is far from offering all Byob block capabilities which will come sooner or later, but at least it has the merit of cleaning the Script area.
The question is :" how to pass parameters to block which has no "variables" ?
What you can do :
1- Define a script within a varfunc + #1,#2
2 - Copy this script inside the new Block.
3 - Replace inside C-Shape the former script by the new "block" script.
4 - Run/Call this modified varfunc+block ...with #1, #2 ..
The varfunc parameters are passed directly to the block !
No practical interest !
Offline
@Jens
Since the beginning Snap! presents the same "bug" which is becoming more annoying as others are progressively fixed. It is related with "variable handling". From time to time when you open the pick-list to select a variable, either global or local (Script variables) Spap! blocks severelely with no possibility to recover it. My impression, is that this occurs when handle your variables too quickly ( which is the case after retyping one application which was blocked just before).
Except that Snap! is becoming very safe.
Offline
Hi Xavier,
I'm afraid I don't understand - and so far cannot reproduce - the bug you mention. When exactly will Snap freeze, when you select a variable name from the pulldown menu of a variable slot? Didn't it use to be when you try to add another variable blob to the palette? I can reproduce the latter bug (only sometimes) under Firefox for Windows (not on the Mac, though) and I suspect it has something to do with the needlessly complicated way I'm updating what will eventually become a true palette, at which time I expect everything to work correctly again.
The script is interesting. How do you access the inputs inside the "projb" block? This smells like cleverly hacking our hybrid scope feature Whaddaya say, Brian?
Offline
@Jens
1- when you select a variable name from the pulldown menu of a variable slot.
Yes, exactly.Not easy to reproduce as it does not happen each time !!
2 - Didn't it use to be when you try to add another variable blob to the palette?
Not now. This was a regular bug, but I've not had it since a while !
3 - How do you access the inputs inside the "projb" block ?
I'm afraid that the method is not worthy of Snap! I write the script inside the C-shape with its Input variables, then I copy this script "as it is" into the block window, and replace the initial script by the block inside the C-Shape.
Offline
cool!
did you know the exponent of 170 is the highest exponent calculateable in snap?
@USC: they finally responded and i sent a fixed version, fixing the icon bug
if you want to replace it, it's not really a big update though
Offline
Jens wrote:
How do you access the inputs inside the "projb" block? This smells like cleverly hacking our hybrid scope feature Whaddaya say, Brian?
Indeed, it's using dynamic scope. This is precisely the sort of situation dynamic scope is for! So I wouldn't have said "cleverly hacking," just using it!
But using the default names (#1 etc) dynamically is asking for trouble, because at some point you'll use this block inside another script that also uses those names and then there will be same-name variables in scope lexically and they'll win. You want to use unusual names for your dynamically scoped variables.
Offline
iTweak0r wrote:
Really, change "predicate" in make a block to "boolean". Because I got REALLY confused when I first used BYOB and, it makes sense much more.
I understand your point, but technically it's not right. "Boolean" means "true or false"; there are only two Boolean values. "Predicate" means "a function that returns a Boolean value." For example, "<" is a predicate.
Even the green operator "true" and "false" blocks are technically predicates, not Booleans (which btw is conventionally capitalized because it comes from a person's name, George Boole, who invented the formal algebra of true/false values); they are functions taking no inputs and always returning the same value. In BYOB we represent the values true and false by the strings "true" and "false" (try clicking on the TRUE block and see what you get), but really that's wrong; we should have a distinct pictorial representation of true and false values.
Offline
@Jens
At the end of a rather long application I've had the palette spoiled (its color turns black and the "blobs" are no more active). It is a rather frequent problem. Snap! does not freeze but the palette blocks are no more active. This time it was possible to recover from the situation (palette suddenly becoming normal) but Snap! was spoiled. Soon later it froze definitevely. If needed I have made a screen capture.
Offline
@bharvey says : "But using the default names (#1 etc) dynamically is asking for trouble, because at some point you'll use this block inside another script that also uses those names and then there will be same-name variables in scope lexically and they'll win. You want to use unusual names for your dynamically scoped variables."
At this very preliminary stage "blocks" replace a long script inside a "set var +c-shape script" by only one instruction (in the old days the Scratch team was satisfied with this simple block enhancement ). But as blocks have not yet their own "input variables it is a walkaround to pass to blocks input variables.If the present block definition were definitive, you're are right we should take care of more appropriate names for c-shape input variables .
Offline
There should be an "are you sure?" dialogue box when you select "delete block definition"
Offline
xly wrote:
@ bharvey
"Snap! update - call/cc now works within lambdas and custom blocks"
Can you give us a simple example of this feature which did not exist in Byob - as far as I know ?
Right, this is a new feature taken from Scheme. Start here:
http://scratch.mit.edu/forums/viewtopic … 05#p952305
for an explanation of what a continuation is.
My favorite simple example is this: First the "before" picture of a script that uses call⁄cc.
The script says, put the pen down, turn 30 plus however many degrees the script inside the call⁄cc reports, then move 50 steps. Here's what you see after running it:
The sprite has turned 30+60 degrees and moved 50 steps, and variable FOO now contains the continuation of the call⁄cc block, namely, what remains to be done after it reports a value.
By the way, the picture in the FOO watcher is wrong (Jens...). It should look like this:
This value in FOO is now runnable:
This time the sprite turns 30+15 degrees and moves 50 steps.
What Jens has fixed is that you can now use call⁄cc from inside a custom block:
Offline
Weird sprite bug:
I was messing with block specs and did that.
Can someone explain what happened to the sprite when a %c was passed into the direction block instead of %dir?
EDIT: Yes, the line is the sprite. It turned into a line.
Last edited by Sidharth (2011-12-14 08:37:05)
Offline