the top one does not work properly(you can get the code and verify that its not joecooldoos fault)
https://snap.berkeley.edu/snap/snap.html#present:Username=d4s_over_dt4&ProjectName=os%202
the top one does not work properly(you can get the code and verify that its not joecooldoos fault)
https://snap.berkeley.edu/snap/snap.html#present:Username=d4s_over_dt4&ProjectName=os%202
me, jens, and bh seem to disagree on this behavior (it was a while ago, i don't remember it well), but quite a few of my projects actually rely on globals not being in constructed rings. (this library)
workarounds:
- pass in the variable with a ring parameter
- get the variable with the name and any sprite by using sensing OF in the ring
- use (variables OF []) and construct parameters in the ring with the names, then pass in values
- use ((your ring) OF [sprite]) to give the ring variables of that sprite
- use ((your ring) OF (other ring)) to give the ring variables of that ring
personally i would like (ring) OF [global] and (ring) OF [(nothing here)] to give globals and no variables respectively, since no variables seems controversial and globals is impossible to do in a library (libraries can't create sprites)
to be clear, you don't need to put tasks in that ring, anything can be in that ring. OF grabs the variables that the ring has access to, it doesn't do anything with the code in it.
note that this means you can add code to existing rings without breaking the variables, regardless of where it was created. you can also pass around script local variables, and remove variables from existing rings to prevent them from touching the rest of the project.
one really good one is replacing all the variables with identical ones of the same name, so the code works but doesn't do anything to the rest of the project
the library i linked earlier is full of ridiculous ring variable nonsense you can read over
Oh.I thought that it passes thevariables in the ring 
Ok.
When Jens first showed me how he implemented macros and I complained about not including access to globals, he gave me the impression that he didn't have strong feelings about it and was open to changing that later. I expect we'll eventually get around to further discussion.
I also disagree with this behavior. Just read this whole thread. At least the issue that I originally made the topic about was fixed (there was no error message).
manipulating blocks to grab sprite local variables doesn't make sense, you can have multiple variables with the same name.
if a sprite has a local variable with the same name as a global, that sprite will only be able to access the local variable unless it uses the OF block or a ring. same with any script local variables.
the sprite that runs a ring isn't the environment. if you create a ring in one sprite with MOVE 10 STEPS, and then run it in a different sprite, the sprite that created the ring will move, not the one that ran it.
this isn't your fault in this case though, because there's two actual confusing issues in your thread. MY BLOCKS definitely should return rings with the environment of the sprite you're getting the blocks from, because that's where the blocks were created. it should work like creating a ring in that sprite.
jens is also just being extremely rude and throwing around way too much jargon. i have no idea what jens is even saying here other than the insults.
In Snap! we have the same representation - a ring - for both a function and a quoted expression, because they are very similar. Expressions are quoted so we can get a handle on them to take them apart and assemble them into new ones, programmatically generating scripts and custom blocks. For this purpose they don't need to capture any environment, and in most cases capturing environments would be awkward and lead to surprising results down the road. Therefore functions capture their environment, quoted expressions don't. Quoted expressions are thus "unbound functions", just a wrapper around code. If the code doesn't rely on side effects - e.g. it merely consists of mathematical operators - you can directly call a quoted expression, otherwise you must bind it to an environment using the OF reporter.
In the OF reporter's dropdown you can find another sprite's methods (local custom blocks), and you can directly call them as they will be bound to "their" original sprite.
the MY BLOCKS reporter answers a list of quoted expression, i.e. unbound functions. You need to bind them first to a target environment if they rely on side effects or local data. You can use the OF block that. The OF is hyperized, so you don't have to enumerate the list of blocks.
If you "make a ring" using JOIN as this thread is titled, the same applies. JOIN produces just code. You can directly run that code, unless it relies on external bindings, global or not.
I really don't like being called by the same folks about the same things over and over, especially since I believe that discussions like this one scare away the target audience I want to cater to: Teachers and students using Snap in class. Instead this forum seems to be perpetually dominated by a few overly enthusiastic nerds knocking themselves out about esoteric fringe topics, constantly calling out for attention from us devs. Folks, you gotta realize that I'm answering dozens of emails and DMs about Snap! all the time. And I'm always sad that those questions aren't asked here in this very forum, because I believe that (many!) others would benefit from those conversations, and because that's what a forum is made for. But there's a reason other people shun this place, and it makes me unhappy.
joining rings is the only way you can create code without an environment, and most people don't pass rings between different sprites or try to change environments without the syntactic sugar of the TELL and ASK blocks. of course people are going to be confused by it on a regular basis. there's no need to be rude to people about it when they think it's a bug. all those bounds checks you aren't adding might not be important for experienced people, but it gives the impression that snap has a lot of bugs, and people will follow patterns.
the forum allows people to talk to other people, and the way this particular forum is designed makes it really easy to read up on posts and remember people. of course there's going to be a lot of people that post all the time and talk to eachother, it's a community and there's nowhere else on snap to do it. these are the same nerds that show off interesting projects, that collaborate to try and make better projects, that help eachother with issues, etc. teachers and students are busy learning the basics, you're far less likely to get the kinds of interesting projects you've told me you wanted before from them, and they might not even be sharing anything.
note that this doesn't mean all these people have telepathy or read every post, different people are going to run into the same issues, and that's common for anything confusing. how is codification a fringe topic anyways? from what i know it's the main big feature of snap 8 (or maybe it was a different update, i don't remember). the reason d4s is making a text language is because of a post bh made reccomending to make a scheme interpreter.
i have plenty of suggestions, bug reports, and project ideas for snap that i'm not acting on because i get the feeling that you'll get annoyed and ignore it.
There are a lot of us doing that - not acting on our ideas
Or we mention them once and then hope they might be implemented at some time in the future 
We don't keep telling the main project lead that they are not getting things right
The reason for that is that this isn't our project
No-one jumps in on the Python team or Guido van Rossum with lots of suggestions
There is a Snap! team who discuss and talk about the direction of Snap! and then mainly Jens goes off and does it.
There are always many things that many people think should be enhanced/changed/fixed
There is only a finite time in which to do this in
You will most likely look back over time and come to see that this is the way with 99% of all programming languages / software projects
IMHO, from a retired educators point of view, all the macro/script stuff is very advanced and intended for a select audience.
I know it is very hard, but try and take a more relaxed approach to things here, think about the big picture
pleas don't assume that by "act on" i mean repeatedly ask for the same thing until it happens or i get banned. i respect people's time. if python had an actual bug i wouldn't be avoiding reporting it because i expect some staff member to complain and tell me the bug isn't worth fixing or that it's some fringe idea.
by "act on" i mean mentioning and discussing ONCE, and/or submitting a pull request. i've had jens get annoyed before because i ran into quite a few bugs trying to make a project, and reported them when i saw them. jens then went on a rant about how people aren't making cool projects and just shoving random garbage into blocks.
The only reason Python has even its stunted half-implementation of lambda is that his users insisted.
I don't think it was wrong to raise the question. It happens to be a question Jens and I have discussed, but we didn't have the discussion on the forum, so there's no way you would have known that.
About Jens yelling at you, he shouldn't have done that, especially because you're not the one he's annoyed by. The problem of people being scared away from the forum is a real one, but it's not, imho, anyone's fault. On the contrary, as you say, it's great that we have users who have the experience and the interest to pursue science here. Jens is unhappy because we seem to have only those users, even though he runs workshops for Snap!-beginner kids who get to make interesting, meaty, not-so-much-about-CS projects. I'm unhappy about it, too. That's why we started Topic of the Month, to encourage people to publish projects that aren't about lambda calculus (or, as in this thread, about typed lambda calculus).
Yes, exactly. We have to triage bug reports into categories
- User error/misunderstanding.
- Bugs, but too trivial to worry about.
- Bugs that are fixable and worth fixing.
- Bugs that would take a big redesign of the code to fix.
- Design disagreements.
I think it's only that last category that annoy Jens, although IANJ, YMMV. I, on the other hand, am happy to argue about the design, although it's rare for such discussions actually lead to us changing anything.
I am not Jens,You ___ __ __?
yeah nice
But its unlikely for a user to maark stuff as misunderstanding
i've been sitting on this for a while, because i know it'll really annoy jens, but the main reason i haven't released any projects that aren't lambda nonsense is that snap is just WAY too slow to make games in. i have a game i made in scratch that has horribly tangled code, with bugs i can't be bothered to try and fix, and would benefit from things like creating costumes with code. i tried to port it over, but snap struggles from a tiny fraction of the stamping that scratch can handle.
yes, i could probably optimize it, but it would take a while and there are many other things i would rather be doing. i also get the feeling that i would run into more performance issues later, or with other projects.
something that really bugs me about performance is that to stretch or warp costumes in many common ways, it requires creating a new costume, where even the single blocks are often slow. how am i supposed to optimize one block? i might want to stretch and skew 20 sprites every frame.
i think there's other cases of single blocks being unusably slow, but i can't remember them off the top of my head.
i've also found plenty of bugs in snap working on that project, from sprites getting stuck in weird states, to errors that can't be caught with the try/catch blocks.
i'd like to go over all the issues i have in detail, but i can only imagine it turning into a bunch of arguing and getting nowhere.
agree
maye both of you have just outgrown Snap! and it's time for you to move on to a professional production language.
We have,already(js and python)
But they don't have macros....