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:
https://snap.berkeley.edu/snap/snap.html#present:Username=joecooldoo&ProjectName=Internet%20Detector%20Block
that's actually a CORS issue.
what do you mean by this?
How does the MQTT CONNECT TO ... block even work? It's like 
is maintained by
, but there's no visible relationship within the code, or am I overlooking something?
When the name of 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 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
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:
-
has become much more flexible: 
-
- as a result,
has become superfluous: I don’t know why it’s still there (convention? nostalgia? not to scare away newbies?);
- as a result,
-
-
- 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);
-
and 
are gone; -
has several options now: -
(for better macros?);
-
(probably replacing the discarded CALL / RUN () W/CONTINUATION blocks);
-
(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.
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).