Scratch

Magnie · 2012-02-20 11:23:53

I only use SVN. hmm

roijac · 2012-02-20 11:38:55

well, it's pretty simple, assuming you have linux (which you have, don't you?)

you make a directory, then you cd to it and type

Code:

git clone ssh://magnie@git.code.sf.net/p/m30w/code m30w-code

then type your password.
from now on you only have to modify the files and type in

Code:

git commit -a
git push ssh://magnie@git.code.sf.net/p/m30w/code [enter branch here, usually master]

if you created new files you have to

Code:

git add file1 file2

, though smile

got it? tongue

Magnie · 2012-02-20 11:40:29

roijac wrote:
well, it's pretty simple, assuming you have linux (which you have, don't you?)

you make a directory, then you cd to it and type
Code:
git clone ssh://magnie@git.code.sf.net/p/m30w/code m30w-code
then type your password.
from now on you only have to modify the files and type in
Code:
git commit -a
git push ssh://magnie@git.code.sf.net/p/m30w/code [enter branch here, usually master]
if you created new files you have to
Code:
git add file1 file2
, though

got it?

I do have Linux, it's just not on my current netbook. tongue And I'm pretty sure Linux doesn't come with Git. hmm

roijac · 2012-02-20 11:45:36

sudo apt-get install git roll
is it that hard? big_smile

Magnie · 2012-02-20 11:46:00

roijac wrote:
sudo apt-get install git
is it that hard?

I don't have root. xD

roijac · 2012-02-20 12:15:08

try this script:

Code:

cd /tmp
wget http://git-core.googlecode.com/files/git-1.7.9.1.tar.gz
./configure --prefix=/home/magnie/git #change it if you have another username
make
make install
make clean
echo alias git=\'/home/magnie/git/bin/git\' >> /home/magnie/.bashrc

EDIT: little bug fix smile

Last edited by roijac (2012-02-20 12:30:00)

Magnie · 2012-02-20 13:29:37

roijac wrote:

try this script:

Code:

cd /tmp
wget http://git-core.googlecode.com/files/git-1.7.9.1.tar.gz
./configure --prefix=/home/magnie/git #change it if you have another username
make
make install
make clean
echo alias git=\'/home/magnie/git/bin/git\' >> /home/magnie/.bashrc

EDIT: little bug fix smile

I'm not going to get on my Linux computer right now. I plan on putting Linux on my netbook, but that won't be for a while. My Dad says I have to practice putting Linux on Desktop computers before putting it on Netbooks.

roijac · 2012-02-20 13:31:39

oh, ok sad
are you admin on windows?

edit: you can download a portable one here anyway

Last edited by roijac (2012-02-20 13:36:04)

Magnie · 2012-02-20 13:53:17

roijac wrote:
oh, ok
are you admin on windows?

Yeah, but I don't feel like putting Git on it. hmm

roijac · 2012-02-21 11:41:15

ok, we now have svn and track in place of sf's tickets system smile

Magnie · 2012-02-21 11:45:07

roijac wrote:
ok, we now have svn and track in place of sf's tickets system

Thanks. tongue

(Magnie is spoiled)

So I'm thinking of having the "outline" being like this:

Code:

meow_core/ < Just to make things look organized
meow_core/meow.py < Will basically be the main part of the program
meow_core/sprite.py < Will handle sprites and the stage
meow_core/blocks.py < Will contain all the block "specs" I guess you could say.
meow_core/custom.py < Will contain "custom" blocks, so when M30W is updated, it won't be over-written.
m30w_starter.py < Will open up, check for any new updates for it. If there are updates, it will run the updater, if not, it'll start up M30W normally.
m30w_updater.py < Will update M30W

What are your thoughts?

Last edited by Magnie (2012-02-21 12:09:15)

roijac · 2012-02-21 12:26:45

Magnie wrote:

Code:

meow_core/ < Just to make things look organized
meow_core/meow.py < Will basically be the main part of the program
meow_core/sprite.py < Will handle sprites and the stage
meow_core/blocks.py < Will contain all the block "specs" I guess you could say.
meow_core/custom.py < Will contain "custom" blocks, so when M30W is updated, it won't be over-written.
m30w_starter.py < Will open up, check for any new updates for it. If there are updates, it will run the updater, if not, it'll start up M30W normally.
m30w_updater.py < Will update M30W

i'm more for sort of APT update on linux, but on windows your way is just fine smile
also i prefer name the script which starts the program m30w.py, because that's actually the script you have to run to make the program run, and name the other one maybe m30w_GUI.py or something. also, i don't really get the point of storing blocks in a script, why not make it a .txt/.mblocks file somewhere in user's path? tongue

could you also make a short tutorial for svn? smile

edit: how actually wrote the code for 0.3.9? it is pretty messy and the classes aren't capitalised big_smile

Last edited by roijac (2012-02-21 12:28:13)

Magnie · 2012-02-21 13:07:12

roijac wrote:
i'm more for sort of APT update on linux, but on windows your way is just fine
also i prefer name the script which starts the program m30w.py, because that's actually the script you have to run to make the program run, and name the other one maybe m30w_GUI.py or something. also, i don't really get the point of storing blocks in a script, why not make it a .txt/.mblocks file somewhere in user's path?

could you also make a short tutorial for svn?

edit: how actually wrote the code for 0.3.9? it is pretty messy and the classes aren't capitalised

(This is going to be troublesome)

Code:

meow_core/ < Just to make things look organized
meow_core/meow.py < Will basically be the main part of the program
meow_core/meow_gui.py < Will take care of the GUI
meow_core/sprite.py < Will handle sprites and the stage
meow_core/blocks.py < Will contain all the block "specs" I guess you could say.
meow_core/custom.py < Will contain "custom" blocks, so when M30W is updated, it won't be over-written.
m30w.py < Will open up, check for any new updates for it. If there are updates, it will run the updater, if not, it'll start up M30W normally.
m30w_updater.py < Will update M30W

meow_gui.py just doesn't seem right for some reason. How will meow.py interact with meow_gui.py? It just seems odd that they aren't together.

I'm thinking that instead of importing the files, we open them up and exec() them instead. That way all the files are part of one, like in JS, instead of them being modules.

That way, custom.py and blocks.py, also have control over the main program and also have access to the sprites to make them do what the blocks may need them to.

Putting the blocks in another file won't make much difference, since the blocks will be Python coded and will interact with the sprites. I was originally thinking of having each block be in a separate file... but that idea was dropped really quickly. Though if we really do plan on making this a big and official project, then I guess we can move custom blocks to the user's directory. C:\Users\Owner\AppData\Roaming\.meow\ for Windows 7 and probably similar to Mac and Linux.

And yes, 0.3 is really messy, which is why I want to recode it. tongue

For SVN, I'm not sure. http://stackoverflow.com/questions/5210 … -for-linux is what I found, but I honestly have no idea.

roijac · 2012-02-21 13:16:19

Magnie wrote:
I'm thinking that instead of importing the files, we open them up and exec() them instead. That way all the files are part of one, like in JS, instead of them being modules.

That way, custom.py and blocks.py, also have control over the main program and also have access to the sprites to make them do what the blocks may need them to.

blocks don't have to access the main program, they can stay where they are without open back-door, only getting access to the parts they need as arguments. I also don't like the idea of letting projects run their own python scripts, it's just too dangerous. maybe BYOB blocks style, but not a CYOB for sure.

Magnie · 2012-02-21 13:55:52

roijac wrote:
Magnie wrote:
I'm thinking that instead of importing the files, we open them up and exec() them instead. That way all the files are part of one, like in JS, instead of them being modules.

That way, custom.py and blocks.py, also have control over the main program and also have access to the sprites to make them do what the blocks may need them to.
blocks don't have to access the main program, they can stay where they are without open back-door, only getting access to the parts they need as arguments. I also don't like the idea of letting projects run their own python scripts, it's just too dangerous. maybe BYOB blocks style, but not a CYOB for sure.

Well, I'm not fully sure how I would sandbox the blocks. But projects won't be running their own Python scripts. That's only the blocks. Also, only blocks added into custom.py will work. Custom blocks in projects won't work unless they are also in custom.py.

Though I can still see the problem with the blocks controlling the program.

roijac · 2012-02-22 01:41:36

yea, i prefer "from blocks import blocks" or something similar, anyway, i'm on holiday for two days, so i can't help much until friday smile

Magnie · 2012-02-22 01:49:03

roijac wrote:
yea, i prefer "from blocks import blocks" or something similar, anyway, i'm on holiday for two days, so i can't help much until friday

Yeah, if we do it that way, sprites won't be controllable, or at least, it won't be very easy to control them. Which is why I think open() and exec() are our best option.

roijac · 2012-02-23 13:16:35

exec() compiles it every time from beginning, and you CAN control sprites anyway tongue
btw, could you pls upload the code to svn?

Last edited by roijac (2012-02-23 13:45:05)

Magnie · 2012-02-23 13:47:11

roijac wrote:
exec() compiles it every time from beginning, and you CAN control sprites anyway
btw, could you pls upload the code to svn?

Fine, I guess you can control sprites that way, but it's very hard and complicated.

What code? I don't think anything has been coded.

roijac · 2012-02-23 14:08:16

0.3.9 code, or should we start from nothing instead?
and it's not that hard to control:

Code:

samlpe.py:

from blocks import *
from sprites import sample
setX(sample, 30)


sprites.py:

class Sprite():
    def setX(self, newX):
        self.X = newX

sample = Sprite()


blocks.py:

def setX(sprite, newX):
    sprite.setX(newX)

roijac · 2012-02-29 08:55:22

bump
magnie?

Magnie · 2012-02-29 11:25:07

Haha, sorry, I didn't see this post. tongue

roijac wrote:
0.3.9 code, or should we start from nothing instead?
and it's not that hard to control:
Code:
samlpe.py:

from blocks import *
from sprites import sample
setX(sample, 30)


sprites.py:

class Sprite():
    def setX(self, newX):
        self.X = newX

sample = Sprite()


blocks.py:

def setX(sprite, newX):
    sprite.setX(newX)

I believe we should start from nothing, cause 0.3.9 is messy.

Also, with the setX, that would require changing sprites.py and blocks.py for every block that we have to add. We can't just add set_x to blocks.py and it'll work for sprites. hmm

I was thinking this for sprites.py:

Code:

class Sprite(object):
    def __init__(self):
        self.x = 0
        self.y = 0
        self.d = 0

        self.original_costumes = {'costume_name' : "image file"}
        self.temp_costume = self.original_costume['costume_name']
        self.showing = 1

        self.scripts = ''

    def _update(self):
        if self.showing == 0:
            return
        temp_image = self.temp_costume
        temp_image = temp_image.rotate(self.d)
        meow.display.print(self.x, self.y, temp_image) # We would put graphic display code here that would display the temp_costume that may have been modified by blocks.

    def _scripts(self):
        parsed_scripts # Parse scripts here into a format like ['command', 'args']
        for command in parsed_scripts:
            if command[0] in blocks_list:
                exec('command[0]('+command[1]+')')

The blocks.py file:

Code:

block_list = ['set_x', 'change_x']
def set_x(sprite, new_x):
    sprite.x = new_x

def change_x(sprite, add_x):
    sprite.x += add_x

then the main m30w code:

Code:

exec('sprites.py')
exec('blocks.py')
exec('custom.py')

class M30W(object):
    def __init__(self):
        display = 'screen display'
        self.sprites = {'sprite_name' : sprite_class}

    def update_all(self):
        for sprite in self.sprites:
            sprite._scripts()
            sprite._update()

meow = M30W()

Or at least something like that. tongue

Last edited by Magnie (2012-02-29 11:26:43)

roijac · 2012-02-29 12:09:16

you know you can append methods to classes, right?
and your way is just a bad programming habit... the way python is used is importing things, not opening and executing them...
check the repo, i have some basic things on there, and i'll add some more tomorrow smile
maybe we should discuss that on sf's forums, where we can make seperate topics for each subject? big_smile

Magnie · 2012-02-29 12:49:24

roijac wrote:
you know you can append methods to classes, right?
and your way is just a bad programming habit... the way python is used is importing things, not opening and executing them...
check the repo, i have some basic things on there, and i'll add some more tomorrow
maybe we should discuss that on sf's forums, where we can make seperate topics for each subject?

Like what I've done here?

I've actually never opened a file and executed it before, so it definitely is not a habit. Though importing can become confusing, but I guess we can go with importing. I just don't see how it can be easy to do with blocks.py and sprites.py. hmm

roijac · 2012-02-29 13:28:36

http://nullpointer.ph/questions/3021/in-oop-what-is-so-important-about-information-hiding
^^ tongue
>>sourceforge forums smile

Scratch

archived forums

#51 2012-02-20 11:23:53

Re: The Return Of M30W

#52 2012-02-20 11:38:55

Re: The Return Of M30W

Code:

Code:

Code:

#53 2012-02-20 11:40:29

Re: The Return Of M30W

roijac wrote:

Code:

Code:

Code:

#54 2012-02-20 11:45:36

Re: The Return Of M30W

#55 2012-02-20 11:46:00

Re: The Return Of M30W

roijac wrote:

#56 2012-02-20 12:15:08

Re: The Return Of M30W

Code:

#57 2012-02-20 13:29:37

Re: The Return Of M30W

roijac wrote:

Code:

#58 2012-02-20 13:31:39

Re: The Return Of M30W

#59 2012-02-20 13:53:17

Re: The Return Of M30W

roijac wrote:

#60 2012-02-21 11:41:15

Re: The Return Of M30W

#61 2012-02-21 11:45:07

Re: The Return Of M30W

roijac wrote:

Code:

#62 2012-02-21 12:26:45

Re: The Return Of M30W

Magnie wrote:

Code:

#63 2012-02-21 13:07:12

Re: The Return Of M30W

roijac wrote:

Code:

#64 2012-02-21 13:16:19

Re: The Return Of M30W

Magnie wrote:

#65 2012-02-21 13:55:52

Re: The Return Of M30W

roijac wrote:

Magnie wrote:

#66 2012-02-22 01:41:36

Re: The Return Of M30W

#67 2012-02-22 01:49:03

Re: The Return Of M30W

roijac wrote:

#68 2012-02-23 13:16:35

Re: The Return Of M30W

#69 2012-02-23 13:47:11

Re: The Return Of M30W

roijac wrote:

#70 2012-02-23 14:08:16

Re: The Return Of M30W

Code:

#71 2012-02-29 08:55:22

Re: The Return Of M30W

#72 2012-02-29 11:25:07

Re: The Return Of M30W

roijac wrote:

Code:

Code:

Code:

Code:

#73 2012-02-29 12:09:16

Re: The Return Of M30W

#74 2012-02-29 12:49:24

Re: The Return Of M30W

roijac wrote: