A way to see if a user is online

ive already kinda got this figured out, the problem is that its slow because any other website other than snap doesnt work with the url block for me, and the report for the url block if set to snaps is big and lags alot

Do you mean "online" as in running the project or on the Snap! website?

as in connected to the internet

Wasn't too hard to make:

that's actually a CORS issue.

what do you mean by this?

How does the MQTT CONNECT TO ... block even work? It's like Internet Detector Block script pic (1) is maintained by
Internet Detector Block script pic (2), but there's no visible relationship within the code, or am I overlooking something?

When the name of Internet Detector Block script pic (1) is changed, the whole things stops working.
All of it is very atypical for Snap!

So what the heck is going on within this library block?

The connection status variable is updated within the extension JavaScript down in the engine room.

the default url block ( linkig to snap.berkeley.edu ) reports 1595455 characters of text and lags out the project fora solid half secod

also, in your block if a user goes offline, the block gets called, and then the user goes back online the block will still report false every time its called until the user switches
nvm it was a fluke

its not too atypical, the case sensitivity library does the same thing

actually that's a cache feature I added so you don't spam the mqtt server

Still, I feel this is sloppy coding style. Even if the primitive function is a separate thread, “connection status” should have been one of its arguments, perhaps typed as “unevaluated” (so effectively a pointer).

i dont think they could have done any better as block variables cannot yet be shared
i was thinking it could work something like this
untitled script pic (2)
untitled script pic (1)

I think each instance of a block has its own block variables, so the test above the report has its own block vars and the one inside the ring has its own.

Why is there a param with the same name as a block var?

I think [variables] of {...} should report a 1-D list of ringed vars.

Which block variable do you mean? I don’t see any.

I was saying if they could be shared then the block would use them

Thats not true, block variables carry over between each block

It does not last time I checked.
EDIT: huh. looks like snap 9 is in its final stages of testing before release.

Not an awful lot has changed from the current Snap! 8.2.3, as far as I noticed:

  • untitled script pic 104 has become much more flexible: untitled script pic 105

    • as a result, untitled script pic 111 has become superfluous: I don’t know why it’s still there (convention? nostalgia? not to scare away newbies?);
      • BTW: how does one make better-looking multi-level indentations?
    • the “Multi-branch conditional” library was rightly discarded (though I regret it is not somehow retained as example code);
  • untitled script pic - 2023-07-10T101053.059 and untitled script pic - 2023-07-10T101050.340 are gone;

  • untitled script pic 106 has several options now:

    • untitled script pic 107 (for better macros?);
    • untitled script pic 110 (probably replacing the discarded CALL / RUN () W/CONTINUATION blocks);
    • untitled script pic 109 (inputs is officially plural, but who cares nowadays?);
  • some additions to the “Audio comp” library;

  • case sensitivity is a global setting now (and the “Strings, multiline input” library has been simplified).

I may have overlooked some of the more subtle changes, and / or more changes are "under the hood" ... (explaining a major release); besides there was also quite some work to be done updating the Ref. Manual, I think.

They are hidden in dev mode to fix compatibility issues.


untitled script pic (2)
Run has a list input now

I see! So definitely something is going on related to continuations.

… and so do LAUNCH and CALL.
Makes me wonder what it’s for (can’t think of a sensible use case for a list here).