bharvey wrote:
technoboy10 wrote:
Eventually, but not now.
Soon. Quite soon, I think.
Really? YESSSSS
Offline
bharvey wrote:
blob8108 wrote:
Mmkay. Remind me?
Hey, don't forget to look up Samuel R. Delany's critique of The Dispossessed!
...I hate you. >_<
Offline
blob8108 wrote:
...I hate you.
Well, I mean, I can't remind you unless you tell me when you finish the book, in which case you'll be telling me in order to have me remind you, in which case you didn't need to be reminded! It's not as if I'm watching over your shoulder as you read it.
Offline
bharvey wrote:
I can't remind you unless you tell me when you finish the book, in which case you'll be telling me in order to have me remind you, in which case you didn't need to be reminded!
You don't think it's possible for me to mention here that I've finished the book, while forgetting that you recommended the critique?
Offline
blob8108 wrote:
You don't think it's possible for me to mention here that I've finished the book, while forgetting that you recommended the critique?
Oh, I suppose.
By the way, here's the book you'll be looking for:
The Jewel-Hinged Jaw: Notes on the Language of Science Fiction
by Samuel R. Delany
Offline
technoboy10 wrote:
bharvey wrote:
technoboy10 wrote:
Eventually, but not now.
Soon. Quite soon, I think.
Really? YESSSSS
Any mockups?
Post 1000!
Last edited by technoboy10 (2013-04-02 19:59:07)
Offline
Finished! Decent book, that.
I should really sleep more...
Offline
Hardmath123 has released an early version of his Python converter here:
https://docs.google.com/file/d/0B1UC0dD … sp=sharing
------
How do I run a python script? Clicking on it says I don't have the right program.
Offline
Zygorithm wrote:
How do I run a python script? Clicking on it says I don't have the right program.
Ah. Other people are going to have this problem, too, not just with Snapin8r but with the hardware interface stuff. Can we package a Python interpreter with the scripts to make an app?
Meanwhile, to answer the question, go here.
Offline
Zygorithm wrote:
Hardmath123 has released an early version of his Python converter here:
https://docs.google.com/file/d/0B1UC0dD … sp=sharing
------
How do I run a python script? Clicking on it says I don't have the right program.
Are you on Mac or Linux? Then it's easy. Windows is harder.
Offline
bharvey wrote:
Zygorithm wrote:
How do I run a python script? Clicking on it says I don't have the right program.
Ah. Other people are going to have this problem, too, not just with Snapin8r but with the hardware interface stuff. Can we package a Python interpreter with the scripts to make an app?
Meanwhile, to answer the question, go here.
Look at the first answer here:
http://stackoverflow.com/questions/1067 … or-windows
Offline
bharvey wrote:
technoboy10 wrote:
bharvey wrote:
Can we package a Python interpreter with the scripts to make an app?
Look at the first answer here:
I'm sorry; I misspoke. I should have said, "Can you package..."
Of course.
Offline
I installed the python program and clicked on snapin8r. For a split second the command prompt popped up then disappeared. Then nothing happened. I was kind of expecting some kind of conversion program to open. How do I use this program to convert a Scratch 2.0 project to Snap?
Offline
Zygorithm wrote:
I installed the python program and clicked on snapin8r. For a split second the command prompt popped up then disappeared. Then nothing happened. I was kind of expecting some kind of conversion program to open. How do I use this program to convert a Scratch 2.0 project to Snap?
First, open a command prompt. Type 'python snapin8r.py' and then the Scratch 2.0 project ID for your project. The Snap! file should be named 'out.xml' .
Offline
technoboy10 wrote:
Zygorithm wrote:
I installed the python program and clicked on snapin8r. For a split second the command prompt popped up then disappeared. Then nothing happened. I was kind of expecting some kind of conversion program to open. How do I use this program to convert a Scratch 2.0 project to Snap?
First, open a command prompt. Type 'python snapin8r.py' and then the Scratch 2.0 project ID for your project. The Snap! file should be named 'out.xml' .
The project ID is the number at the end of the URL to the file.
For help, type "python snapin8r.py -help".
Remember to cd into the snapin8r directory!
Offline
I'm starting to think it isn't possible to have a universal representation that covers all of Scratch 1.4, Scratch 2.0, BYOB and Snap!. I'm getting hung up on little details like variables vs. lists. My internal representation is meant to be a kind of compromise, but is closer to Scratch than Snap!, so I have separate "variables" and "lists" dictionaries for each sprite. So when loading a Snap! project, it gets converted to a "Kurt" project, and all the list-containing variables would be converted to lists.
But if you open a Snap! project in kurt as a Python programmer to perform analysis on, you're going to expect to see Snap!-like things: Snap! block names instead of Scratch ones, variables containing lists, etc — aren't you?
Maybe I just need a more inclusive compromise?
Does what I'm saying even make sense?
Offline
Here's my (rough) plan for executable Snap! extension servers.
There'll be a Snap! extension 'hub' app that will read from a list of extensions installed, and populate a dropdown/some other type of list with all the extensions installed. You'll be able to start the extensions from this app. I'm still not sure how to handle dependencies.
How does that sound?
Last edited by technoboy10 (2013-04-04 09:07:33)
Offline
By the way, are there any plans for cloud data in Snap!?
Offline
blob8108 wrote:
I'm starting to think it isn't possible to have a universal representation that covers all of Scratch 1.4, Scratch 2.0, BYOB and Snap!. I'm getting hung up on little details like variables vs. lists. My internal representation is meant to be a kind of compromise, but is closer to Scratch than Snap!, so I have separate "variables" and "lists" dictionaries for each sprite. So when loading a Snap! project, it gets converted to a "Kurt" project, and all the list-containing variables would be converted to lists.
But if you open a Snap! project in kurt as a Python programmer to perform analysis on, you're going to expect to see Snap!-like things: Snap! block names instead of Scratch ones, variables containing lists, etc — aren't you?
Maybe I just need a more inclusive compromise?
Does what I'm saying even make sense?
I don't know, I would support having everything as close to Scratch 2.0 as possible.
BTW a couple of friends were asking about how to convert Scratch 1.4, so I told them about Scratch2Exe and Kurt.
Offline
Hardmath123 wrote:
a couple of friends were asking about how to convert Scratch 1.4, so I told them about Scratch2Exe and Kurt.
Convert to what?
Offline
blob8108 wrote:
I'm starting to think it isn't possible to have a universal representation that covers all of Scratch 1.4, Scratch 2.0, BYOB and Snap!.
I think you should support both forms, in each case of conflict.
So, with respect to lists, we can algorithmically read a Scratch-style named list and convert it to a global variable with an empty list value when we read the project. But it's hard for Scratch to convert the other way, because a variable whose value is a list at the moment the project is saved might have a non-list value later on. So you should have named lists as a capability in your representation, but you should also have the ability to give a variable a list value.
In other words, you can have a universal representation in the sense that it can be general enough to represent accurately a project in any of the languages, and convert that project back to its language of origin. But inter-language conversion is only going to work from (ahem) a lesser language to a greater one, such as 1.4 to 2.0 or Scratch to Snap!.
Offline
bharvey wrote:
blob8108 wrote:
I'm starting to think it isn't possible to have a universal representation that covers all of Scratch 1.4, Scratch 2.0, BYOB and Snap!.
I think you should support both forms, in each case of conflict.
Yeah, I think that's the conclusion I'm coming to. Kurt's representation should be a kind of superset of them all, and then not all formats use the same bits.
inter-language conversion is only going to work from (ahem) a lesser language to a greater one, such as 1.4 to 2.0 or Scratch to Snap!.
I'd like to be able to convert a subset of blocks/capabilities — if you write a Snap! program that contains only blocks and idioms from Scratch, I see no reason why it can't be converted.
it's hard for Scratch to convert the other way, because a variable whose value is a list at the moment the project is saved might have a non-list value later on.
So, for example, I can convert a Snap! variable to a Scratch list if you use list blocks on the variable. This won't work for all cases, but I think I can raise warnings for most of them.
Offline