This is a read-only archive of the old Scratch 1.x Forums.
Try searching the current Scratch discussion forums.

#8051 2013-04-27 02:22:05

KodyJKing
New Scratcher
Registered: 2013-04-26
Posts: 2

Re: BYOB 3 - Discussion Thread

bharvey wrote:

KodyJKing wrote:

But now my name matches my Github name

Is that also you on myspace?

Nope, I don't do myspace  smile

Offline

 

#8052 2013-04-27 15:11:36

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

So I'd written a dictionary subclass and its OrderedDict twin for dealing with named objects. They contain objects with a "name" attribute. When you add an object, it gets the dictionary key from the object's name; you index them by the object name; renaming the object magically updates the dictionary key; iterating over the collection gives you the objects, not the keys; and the ordered version allows list indexes too, so you can do project.sprites[2]. All of which seems to be what you want, most of the time.

However: A Scratch file will often contain the same image file multiple times (try duplicating the sprite and saving a project in 2.0, for example). The fact that Costumes have a "name" attribute means the name and the image data are linked -- I can't add the same Costume to two sprites without it having the same name. Which means I have to load the same image multiple times and waste memory.

So maybe Costumes shouldn't have names, and I just add them to a plain ol' OrderedDict.

But then in other instances the name attribute is pretty useful — Sprites probably should have it on the object; Variables need it so you can tell which variable a Watcher is watching; and so on.

Do I just have to embrace inconsistency, in having some things named and others not? I think I may be going crazy over-thinking this.  tongue

Last edited by blob8108 (2013-04-27 15:11:53)


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8053 2013-04-27 19:29:42

technoboy10
Scratcher
Registered: 2007-08-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

I made a Minecraft extension for Snap!. I'll update the README with more info in a bit. http://www.github.com/technoboy10/snapcraft


So long, 1.4.
http://goo.gl/3JEV9

Offline

 

#8054 2013-04-27 20:31:42

bharvey
Scratcher
Registered: 2008-08-10
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

I think I may be going crazy over-thinking this.  tongue

Passing over without comment the question of your craziness, I point out that there's a dead rock-n-roller named Brian Harvey, who nevertheless isn't me.  Not even an identical copy of me.  Names let you say "I'm looking forward to seeing Jens in Barcelona" without prejudice to the question of how many other people might be named Jens, even in Barcelona.  In other words, names are not meant to serve as unique identifiers.  For that we have driver's license numbers, Social Security numbers, and RFID tags.

All of this is completely orthogonal to the implementation efficiency issue of redundant storage of identical costumes.  That's what hash codes are for!  You shouldn't have two copies of the same costume even if they have different names.

If you want unique identifiers for things, use gensyms to label them internally, but don't display the gensyms to users.

EDIT:  ... Hence the use of "key" rather than "name" in the technical literature to mean the identifiers used in various data structures that associate keys with unique values.  The name "dictionary" for such a structure is misleading, since a word in a real dictionary can have several (etymologically unrelated, even) meanings.

By the way, the word "so" at the beginning of your post made me curious and sent me to wiktionary, where I learned that it can be any of five different parts of speech, with several meanings each.  (That beginning-of-sentence one is an interjection, I learned.  When they taught me about parts of speech, which I loved, I always thought interjections were a cheat, a fancy word for "none of the above," except in the case of one-word sentences such as "Aha!" or "Hrumph!"  Those are real interjections.  Personally I think your "so" should be called an adverb, modifying the entire sentence, rather like "Once upon a time.")

PS:  Scratch copying a costume when a sprite is duplicated is an error they would avoid if only costumes were first class.  (Not that you can't avoid it otherwise, but with first class costumes it would never occur to an implementor to copy the costume.  I would say the same about cloning sprites, of course; there shouldn't be any copying involved.)

Last edited by bharvey (2013-04-27 23:42:11)


http://cs.berkeley.edu/~bh/sig5.png

Offline

 

#8055 2013-04-28 07:48:56

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

bharvey wrote:

names are not meant to serve as unique identifiers

Gah! I forgot to mention that these dictionaries are per-sprite. And a sprite's costumes are required to have unique names (though not unique over the whole project).

All of this is completely orthogonal to the implementation efficiency issue of redundant storage of identical costumes.  That's what hash codes are for!  You shouldn't have two copies of the same costume even if they have different names.

Mmm. I guess the question was simply whether or not the name is "attached" to the costume. And it would seem logical for it not to be, to avoid the problem you describe.

So Costumes and Sounds won't have names, and will be stored inside a per-sprite OrderedDict (one for costumes and one for sounds).

Variables and Sprites and stuff still have names, so I'll carry on storing those in my modified dict classes... I'll just tweak them to work a little more like normal dictionaries to avoid confusion.  tongue

gensyms

What are those? Just generated names? Google's unhelpful here  tongue

By the way, the word "so" at the beginning of your post made me curious

This amuses me greatly! I didn't think that was such an unusual usage...


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8056 2013-04-28 10:10:45

bharvey
Scratcher
Registered: 2008-08-10
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

Google's unhelpful here

You should start using DuckDuckGo.  Third hit:

http://dictionary.reference.com/browse/gensym

which gives you the general idea.  I did have to go all the way down to the seventh hit to find this:

http://www.lispworks.com/documentation/ … gensym.htm

which is authoritative, but does leave you needing to look up "uninterned."  Luckily DuckDuckGo will help with that, too, on the first hit.  smile

This amuses me greatly! I didn't think that was such an unusual usage...

Oh, I say it all the time, too, but seeing it in writing amused me and started me thinking about the word.

EDIT: This:

Variables and Sprites and stuff still have names, so I'll carry on storing those in my modified dict classes...

makes me nervous.  Costumes have names; it's just that the name is attached to, rather than part of, the costume.  But, technically, that's true of everything, even variables.  A variable is a location in memory; a name is bound to the variable in an environment, which isn't part of the variable.

I think what's confusing you is that the name "costume" is ambiguously used to describe two things: a bitmap and a data structure that includes a (pointer to a) name and a (pointer to a) bitmap.  It's the bitmap that you want to hash and store separately.  The data structure also includes a rotation point and could include other stuff.

But here's something that's true both for costumes and for sprites:  You can change their names, and the costume/sprite after renaming is still EQ to itself before renaming.  Names are for users; pointers are for implementors.  smile   (A gensym is a sort of abstract pointer.)

Technically, one can distinguish between an internal name stored within a data structure and an external name bound to the data structure in an environment.  But neither kind of name should be considered the unique identifier for the structure.

EDIT2:  If the above is too abstract (a failing of mine), consider that you can crash BYOB by importing a sprite named "Sprite1" into a project that already has a "Sprite1" sprite.  This is because BYOB (following Scratch, I believe) confuses names with pointers.  What should happen is that perhaps one of the sprites becomes inaccessible in pulldown sprite menus (or maybe the same name appears twice in the pulldown and it's the user's headache to figure out which is which), but the project otherwise works.

Last edited by bharvey (2013-04-28 10:50:31)


http://cs.berkeley.edu/~bh/sig5.png

Offline

 

#8057 2013-04-28 11:16:46

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

bharvey wrote:

DuckDuckGo

I did try that some time ago, but it never found what I wanted — and after a while I realised I was just using its !bang syntax to search google all the time...

A variable is a location in memory; a name is bound to the variable in an environment, which isn't part of the variable.

Okay, so now I want to rip out all the name attributes of all my objects, and all of the "magic" I've put in for object reparenting and stuff, and just use dictionary keys to store the names of things.

That seems like the easiest way of getting the name and the value separate.

the name "costume" is ambiguously used to describe two things: a bitmap and a data structure that includes a (pointer to a) name and a (pointer to a) bitmap

It's okay to have the rotation center stored on the bitmap, though, right? I don't want to have to have two classes just so I can store the rotation center attribute. -_-

the costume/sprite after renaming is still EQ to itself before renaming.

Indeed! But I don't have equality comparisons for my objects anyway; I don't see the use  tongue

If someone says sprite1 == sprite2, they probably just want to see if they point to the same object, right?

consider that you can crash BYOB by importing a sprite named "Sprite1" into a project that already has a "Sprite1" sprite.

Doesn't Scratch rename the sprite to Sprite2, or something? Anyway, if Scratch wants unique names for sprites, then kurt's going to enforce unique names for sprites!

(Unless you have some devious plan to make Snap! allow sprites to have the same name. In which case I hate you.)

Last edited by blob8108 (2013-04-28 11:18:26)


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8058 2013-04-28 13:28:10

nXIII
Community Moderator
Registered: 2009-04-21
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

the name "costume" is ambiguously used to describe two things: a bitmap and a data structure that includes a (pointer to a) name and a (pointer to a) bitmap

It's okay to have the rotation center stored on the bitmap, though, right? I don't want to have to have two classes just so I can store the rotation center attribute. -_-

No, you should have two objects—images are images, and costumes are images + metadata. You wouldn't want to have two Costume classes just so you could have SVG images as well as PNGs.


nXIII

Offline

 

#8059 2013-04-28 13:45:24

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

nXIII wrote:

You wouldn't want to have two Costume classes just so you could have SVG images as well as PNGs.

I already have like three Costume subclasses for dealing with different image sources  tongue  (CostumeFromFile, CostumeFromPIL...)

Yeah, <sigh /> maybe I'll have a separate BitmapImage or BaseImage or something. (The name "Image" is used by the PIL library, so that gets confusing.)


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8060 2013-04-28 14:14:01

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

I think I just cooked my brain through a few hours of maths questionstongue

Anyway, so you've convinced me images and costumes are separate things.

I'm still not sure about the general principle of whether I should store the name on the object or not.  hmm  EDIT: or whether child objects need references to their parents...

Is magic in frameworks generally a bad idea?

Last edited by blob8108 (2013-04-28 14:21:27)


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8061 2013-04-28 14:15:24

nXIII
Community Moderator
Registered: 2009-04-21
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

I already have like three Costume subclasses for dealing with different image sources  tongue  (CostumeFromFile, CostumeFromPIL...)

Wait, but those don't even affect the kind of image! Shouldn't you just have an Image (it's-in-a-different-module-so-it-doesn't-matter) class with static fromFile(…) and fromPIL(…) methods? The concrete implementation classes for different sources shouldn't be publicly accessible.


nXIII

Offline

 

#8062 2013-04-28 14:21:03

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

nXIII wrote:

(it's-in-a-different-module-so-it-doesn't-matter)

tongue

Shouldn't you just have an Image class with static fromFile(…) and fromPIL(…) methods? The concrete implementation classes for different sources shouldn't be publicly accessible.

Maybe I should? The thinking is that different formats can figure out what the image came from — if it's a file, we can just write the original file to disk or to a zip and we never have to decode the bitmap data into memory.

For example, when saving, the v14 plugin uses checks if it's a JPEG using isinstance(kurt_image, kurt.CostumeFromFile) and kurt_image.format == "JPEG" and then stores the file contents directly into jpegBytes. Otherwise it decodes the image through PIL.


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8063 2013-04-28 15:45:18

nXIII
Community Moderator
Registered: 2009-04-21
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

Shouldn't you just have an Image class with static fromFile(…) and fromPIL(…) methods? The concrete implementation classes for different sources shouldn't be publicly accessible.

Maybe I should? The thinking is that different formats can figure out what the image came from — if it's a file, we can just write the original file to disk or to a zip and we never have to decode the bitmap data into memory.

For example, when saving, the v14 plugin uses checks if it's a JPEG using isinstance(kurt_image, kurt.CostumeFromFile) and kurt_image.format == "JPEG" and then stores the file contents directly into jpegBytes. Otherwise it decodes the image through PIL.

You should just provide Image methods like writeTo(path) and getBytes(format) which do that in the appropriate way for each concrete (internal) implementation class. Plugins should almost never be using isinstance, and probably shouldn't be switching on the format either.

EDIT: I forgot jpegBytes wasn't the only way to store the image. That's an interesting situation, which would require switching on the format (although optimal_format might be a better name, as Image is an abstract representation that should be able to give image data in any format).

When you provide generic methods in Image, implementors don't have to worry about the input format of the image and can just use those methods to get the data they need in the format they need, but at the same time the concrete classes can be optimized so that they don't, e.g., read an entire file into memory just to write it somewhere else or convert an image from a JPEG to some internal format and then convert it back to a JPEG again. The Image class can provide default implementations for most methods where these optimizations aren't necessary.

Last edited by nXIII (2013-04-28 15:49:17)


nXIII

Offline

 

#8064 2013-04-28 16:14:30

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

So what would you propose? Is it okay to do what I'm doing, with subclasses for different sources, and for the plugins to use isinstance to pick the optimum output? Or something else? How would you do it?  smile


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8065 2013-04-28 18:54:51

nXIII
Community Moderator
Registered: 2009-04-21
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

So what would you propose? Is it okay to do what I'm doing, with subclasses for different sources, and for the plugins to use isinstance to pick the optimum output? Or something else? How would you do it?  smile

…I just described that, didn't I?

You should just provide Image methods like writeTo(path) and getBytes(format) which do that in the appropriate way for each concrete (internal) implementation class.

You could make getBytes take multiple formats and return a structure with the bytes and one of the formats; that way concrete image classes could pick the fastest format. (for jpegBytes you'd then do s = image.getBytes(Image.JPEG, Image.RAW) and then check if s.format is Image.JPEG or Image.RAW)

EDIT: What you may want is a set of internal ImageSource classes that represent the different sources and a set of internal ImageFormat classes that represent the different formats; that way each source deals with I/O and each format deals with transforming the input or output to the appropriate format, if necessary.

Last edited by nXIII (2013-04-28 18:58:33)


nXIII

Offline

 

#8066 2013-04-28 21:28:03

bharvey
Scratcher
Registered: 2008-08-10
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

it never found what I wanted — and after a while I realised I was just using its !bang syntax to search google all the time...

Hmm, it works really well for me almost all the time.  And on those few occasions when I have to use !g I'm still happy that Google isn't finding out anything about me.

Okay, so now I want to rip out all the name attributes of all my objects, and all of the "magic" I've put in for object reparenting and stuff, and just use dictionary keys to store the names of things.

I'm not sure what this has to do with reparenting, but okay...

It's okay to have the rotation center stored on the bitmap, though, right?

If I have two costumes with the same bitmap but different rotation centers, do you want to store the bitmap twice?

If someone says sprite1 == sprite2, they probably just want to see if they point to the same object, right?

Indeed.  My point was that renaming a sprite shouldn't change the result of that test.

I mean, look, often it's the easiest thing to store a name with an object.  I'm neutral about your implementation choices, except that if you're trying to be efficient about not storing duplicate bitmaps, that requires thinking of the bitmap as a thing in itself.  But I just want you to make the implementation decisions without saying confus{ed,ing} things about names.

Doesn't Scratch rename the sprite to Sprite2, or something?

All I know is that when I made the BYOB3 tool sprite, I had to call it ToolSprite rather than Sprite1.

In which case I hate you.

Nah, you say that a lot, but you never mean it.  tongue


http://cs.berkeley.edu/~bh/sig5.png

Offline

 

#8067 2013-04-28 22:59:46

Hardmath123
Scratcher
Registered: 2010-02-19
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

I think I just cooked my brain through a few hours of maths questionstongue

I skipped the "pure" math bit (it's not pure without any number theory!) and the mechanics bit (our school still teaches us floating and sinking, though if you pin someone down and ask them why things float in the first place, you'll be surprised), but I can't resist trying the dartboard problem.  big_smile  What grade level problems are these? I still kind of struggle on AIME-level problems (I got an 8 this year, but when I got home I figured out another 2 in like 15 minutes each…).

(I can see how the concept of nerd sniping makes sense).


Hardmaths-MacBook-Pro:~ Hardmath$ sudo make $(whoami) a sandwich

Offline

 

#8068 2013-04-28 23:39:44

bharvey
Scratcher
Registered: 2008-08-10
Posts: 1000+

Re: BYOB 3 - Discussion Thread

Hardmath123 wrote:

I skipped the "pure" math bit (it's not pure without any number theory!)

Number theory isn't pure any more; it's all about cryptography.  Now, set theory, that's pure math.

One of my big regrets is that I used to be able to do problems of that sort and have totally lost the knowledge and skill from lack of use.  Computer programming is all a bad idea.  sad


http://cs.berkeley.edu/~bh/sig5.png

Offline

 

#8069 2013-04-29 00:39:59

Hardmath123
Scratcher
Registered: 2010-02-19
Posts: 1000+

Re: BYOB 3 - Discussion Thread

bharvey wrote:

Computer programming is all a bad idea.  sad

You're gonna regret that once the cyborgs take over… or when blob sees your post.  smile

EDIT: But number theory in competition math is divine.

Last edited by Hardmath123 (2013-04-29 00:40:30)


Hardmaths-MacBook-Pro:~ Hardmath$ sudo make $(whoami) a sandwich

Offline

 

#8070 2013-04-29 00:52:41

bharvey
Scratcher
Registered: 2008-08-10
Posts: 1000+

Re: BYOB 3 - Discussion Thread

Hardmath123 wrote:

You're gonna regret that once the cyborgs take over

I'm old enough for my body to be failing in various not-yet-fatal ways; if I live long enough for there to be cyborgs, I'll probably be one!


http://cs.berkeley.edu/~bh/sig5.png

Offline

 

#8071 2013-04-29 03:36:49

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

Hardmath123 wrote:

bharvey wrote:

Computer programming is all a bad idea.  sad

You're gonna regret that ... when blob sees your post.

You could have told me that before I applied to do Computer Science! D:< *rage*

...anyway, it's okay -- I applied for Maths as the first-year option  tongue

Hardmath123 wrote:

I skipped the "pure" math bit ... What grade level problems are these?

I only do the pure math bits! They're Cambridge maths entrance exams, which are part of my offer because I was stupid enough to choose the Maths option. Thankfully, if I don't do well enough in STEP, I can just do Physics or Psychology or some other option as 25% of the first year.

bharvey wrote:

blob8108 wrote:

In which case I hate you.

Nah, you say that a lot, but you never mean it.  tongue

True enough!  big_smile


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8072 2013-04-29 03:50:37

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

bharvey wrote:

If I have two costumes with the same bitmap but different rotation centers, do you want to store the bitmap twice?

Fine, fine! n convinced me.

often it's the easiest thing to store a name with an object.  I'm neutral about your implementation choices

Okay, thanks, that's reassuring!  tongue

nXIII wrote:

blob8108 wrote:

So what would you propose?

…I just described that, didn't I?

Yes, I didn't quite get it  tongue

I guess what I should have asked was: how should plugins work out the optimal format to store the image as without using isinstance?

A separate ImageSource sounds interesting. Format is easiest as a string, I think, as that's what PIL uses (and I don't want to have to a dozen format subclasses!).

Maybe PIL.Image.open("test.png").save("test2.png") is actually already efficient enough, and I should just do that and stop worrying about efficiency.

You could make getBytes take multiple formats

Ah, I get that now. So the format provides a list of formats in the preferred order... I like that! That answers my question.  tongue

I need to go and have a think about this...

Last edited by blob8108 (2013-04-29 03:52:51)


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#8073 2013-04-29 04:05:29

Hardmath123
Scratcher
Registered: 2010-02-19
Posts: 1000+

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

stop worrying about efficiency

From my experience, it's always more fruitful to first get something actually working nd then make it faster.

(But don't believe me—my raytracer takes 10 minutes to render 400 primitives in a 512 by 512 image. But I think that's brilliant for Python. At least I'm not loading a texture every time I see a ray intersection!  smile )

PS: http://i40.tinypic.com/30kfx52.png

EDIT: Once the forums are archived, I won't get to change my signature. That's kind of scary on so many levels.  sad

Last edited by Hardmath123 (2013-04-29 04:14:29)


Hardmaths-MacBook-Pro:~ Hardmath$ sudo make $(whoami) a sandwich

Offline

 

#8074 2013-04-29 08:13:58

elizabethraws12
New Scratcher
Registered: 2013-04-29
Posts: 1

Re: BYOB 3 - Discussion Thread

fanofcena wrote:

Meeeeeee Toooooooooooooo :p

Looks really nice.

Offline

 

#8075 2013-04-29 08:35:05

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: BYOB 3 - Discussion Thread

Hardmath123 wrote:

From my experience, it's always more fruitful to first get something actually working and then make it faster.

Yeah, indeed. But getting it to work would be easy (just pass around PIL.Image.Image instances); trying to design the right interface is hard.

Nice raytracer!  smile


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

Board footer