You don’t have to let the “_morph” method report a technical Morph instance, any Snap data will also do, e.g:
or even:
which can be especially fun, because there’s more to the data structure than you’re deciding to show to the user:
but yes, you can also make more visual, graphical representations for your custom data types, such as rendering an image of the actual neural network:
making a custom widget for your tabular data:
or for custom graphical objects:
I’m so excited for Snap! v12!
interesting (have i posted here before? i forgot)
Oh! Well that makes it much easier. Can’t wait for this to come to normal Snap!!
2 bugs, 2 questions:
1:
2: when you make a block return a data type with a " in it (right click a block definition hat), the project seems to get corrupted and doesn’t save. my guess is a lack of xml escape, but that’s just speculation mostly.
3: what does the enforce types thing do (right click a block definition hat)?
4: any way for the variadic menus to have different menus within the same variadic slot?
please, @sathvikrias , don’t annoy me. This is under development, not for the unwashed kids to gloss over (yet). We’ll let you know when it’s ready for you to bang on it.
okay. I was just wondering if the first error had anything to do with the new feature or not (I thought it was unrelated).
Yes, these errors are related to the new user-extensible type system. I’ve already fixed the first one on my desktop and will push it to dev next week. The second one I’m probably not going to address.
Okay, I’ve got an issue with the new pen functionality I discovered and I’ve been wondering what to do about it. I’ll let you know if and when the time comes.
well, okay, now that we’re already down that road, shoot!
Writing text on a sprite won’t take into account the size parameter, always drawing at size 12 (and thus the Writing and Formatting library won’t work either).
Additionally, when overdrawing, it will still behave like it is painting when writing text.
I discovered these issues when trying to modify the text costumes library to not mess with the pen trails (as you’ve done with the shapes library, for example).
In the future I’ll try to keep my mouth shut a little better on these things 
.
thank you.
same here. I am very sorry.
Now that is cool
I just tried it again… and oh my gosh it’s way faster than I could have ever thought it would be. wow.
Also new fun thing with ADTs! There is now a ADT input slot type, that allows you to show a type name, and you can also add _type to add a type to a ADT you can also use in is _ a [type v]! And that new block typing feature, however I don’t know how that works 
huh?
oh wow!
yes, as with everything in dev, this is still very much under construction. But here’s a first experiment I’ve tried with a group of SAP colleagues yesterday, that uses these types:
This is part of a larger set of features we’re developing for the new 11./12. grade national CS curriculum in India, along with the tables extension, which also use the new data types.
Again, don’t get too excited about this, because in the end nothing might come out of it. 
Cool! I don’t exactly know where the types are being used. Well, except for of course in the Shapes library, but anywhere else?
It is sad it might get removed, but still all cool to see nonetheless!
good job!
But the `move shape` block is only an internal helper function and not shown in that microworld. Can you do it without? Also, we’ve been discussing whether the usage of the `overlay offset` block should be regarded as cheating here… Can you find another way?
(edit): I realize that I haven’t yet added any explanation or help to those blocks. That’s because it’s still very exploratory. The way they (should) work is based on the Racket / Pyret Image Library: 3.1.16 The image libraries
