edward789121 wrote:

nope, it does something once (function λ), and then returns the reporter (var λ).

Yes, I understand what your block does. I was using a loop as an example to explain why the language lets you control explicitly when the script is run – you might want to do it more than once. Your own use case is simpler.

Do you still need help, after jfb's posted script using the RUN block? Are we both misunderstanding what's standing in your way?

The for () = () to () block isn't there. Is this a glitch or was it removed or something?

I just encountered a weird bug - The JavaScript block seemed to be running more than once sometimes, and I couldn't figure out any pattern to how many times it ran. But when I opened another project to test it, I couldn't reproduce it, and when I opened back up the original project it was affecting, it stopped happening.

It's a Heisenbug…

f1lip wrote:

The for () = () to () block isn't there. Is this a glitch or was it removed or something?

Click the file menu, then click “import tools”

bharvey wrote:

edward789121 wrote:

nope, it does something once (function λ), and then returns the reporter (var λ).

Yes, I understand what your block does. I was using a loop as an example to explain why the language lets you control explicitly when the script is run – you might want to do it more than once. Your own use case is simpler.

Do you still need help, after jfb's posted script using the RUN block? Are we both misunderstanding what's standing in your way?

the run block just spawns what i put in.

when I receive [Scratch joined v]
cringe
wait ((pick random (0) to (4)) * ((((60) * (60)) * (12)) * (365.25))) secs
leave
wait ((pick random (0) to (4)) * ((((60) * (60)) * (12)) * (365.25))) secs
broadcast [Scratch joined v]

joefarebrother wrote:

You need to use the run block for the c section, and the call block for the unevaluated variable. So your code will be

(do (function λ) for (var λ)::operators) :: control hat   
run (function) :: control 
report (call (var) :: control) :: control cap 

Someone else will be able to explain this better than I can.

Inside: error
expecting a ring but getting (getting whatever var is)

when I receive [Scratch joined v]
cringe
wait ((pick random (0) to (4)) * ((((60) * (60)) * (12)) * (365.25))) secs
leave
wait ((pick random (0) to (4)) * ((((60) * (60)) * (12)) * (365.25))) secs
broadcast [Scratch joined v]

Oh, you need to make the type of var “Any (Unevaluated)”, that way it's automatically wrapped in a ring for RUN to handle.

joefarebrother wrote:

f1lip wrote:

The for () = () to () block isn't there. Is this a glitch or was it removed or something?

Click the file menu, then click “import tools”

Thanks!

Jens, can you explain how WARP works and why sometimes it makes things faster, and sometimes slower?

IANJ, but let me give this a try.

So, you understand that your computer is only as fast as it is, and all WARP can do is speed up one piece of computation at the expense of other pieces.

In particular, nothing changes on the display during a WARP. This can result in a subjective speedup because some intermediate displays may be skipped altogether, as for example when you're drawing a fractal tree and it all appears at once, instead of displaying each MOVE. On the other hand, if you're using a change in the display to measure the progress of a computation, it'll subjectively slow down because nothing changes for a long time.

I think the interaction between WARP and display uodating explains most cases of speedup or slowdown. But of course WARP also prevents other scripts from running, so if other scripts (same sprite or other sprites) contribute to “things,” that may result in a subjective slowdown.

And of course if the warped computation runs long enough for the browser to decide Snap! is being unresponsive, that can lead to a big increase in actual elapsed time. (This shouldn't happen, though, because Snap! interrupts even warped threads if they run for a long time.)

Well, I was warping a block that just did calculations, no display work, and was comparing it with RESET TIMER and TIMER, and when unwarped it had a time of 0, but when warped it was 0.1.

This function is called in a loop, so I thought it was important to optimise

Okay, you've gone beyond my expertise. My guess is that it has to do with when the timer gets updated, but I'm not sure. What happens when you time the entire loop? Is the time difference significant?

bharvey wrote:

Okay, you've gone beyond my expertise. My guess is that it has to do with when the timer gets updated, but I'm not sure. What happens when you time the entire loop? Is the time difference significant?

Probably because the warp block doesn't actually warp the blocks; it only stops the display from updating while it is run. Therefore, it has to make sure the display doesn't update and has to affect every yield that will be called, which could be time consuming.

NOTE: I don't know much about snap!'s code, so I may be (and probably am) wrong

I made a Snap! “wrapper” around JavaScript's websocket client. The project is here.

Jonathan50 wrote:

I made a Snap! “wrapper” around JavaScript's websocket client. The project is here.

Interesting!

Now all we need is a way for a Snap! project to make itself a server. We could do that in a standalone node.js implementation, right?

bharvey wrote:

Now all we need is a way for a Snap! project to make itself a server. We could do that in a standalone node.js implementation, right?

That's actually what I was going for back a couple of months ago with the invoking-snap-blocks-in-JS thing

Jonathan50 wrote:

I made a Snap! “wrapper” around JavaScript's websocket client. The project is here.

Did you take it down, or am I missing something? I just tried to check it out, and it looks like an empty project to me.

I have a very general question about the higher-order function features of Snap!. Is there any sort of tutorial material for learning about these, other than the reference manual? I've been trying to go through the ref. man., but is seems like it goes from very basic, to extremely difficult, in a giant quantum leap.

klortho wrote:

Jonathan50 wrote:

I made a Snap! “wrapper” around JavaScript's websocket client. The project is here.

Did you take it down, or am I missing something? I just tried to check it out, and it looks like an empty project to me.

I added custom blocks to the sensing palette.