Ken, that would be great. I've been re-reading the open propeller project page and also watched some videos about S2 and I think we could make a great product.
The software could have different modes depending on the experience level of the user. From high level blocks specific for the S2/3 to the set of blocks I'm currently creating.
A tutorial like Roy suggested would also be nice to learn the blocks gradually. (I also suggested putting a learning system in earlier, but that was for the current set of blocks)
One question though:
I've currently put in the apache2 licence because this is the Blockly licence and as such I can't make it (at least not completely) MIT licensed. Is this a problem? I don't have experience with licences, so if this has to change i'll need some advice.
Another thing I thought of is a way to compile and load programs into the propeller. What if we create a version that is hosted at Parallax, and users download a small native (cross platform) application that opens a socket to the server and identifies itself.
When loading the application, the server would compile the application and send it to the selected client.
This would eliminate the requirement for a server on the users computer while supporting all browsers (I'm thinking about the IE plugin). And, at least I think, would be easier to use.
To conclude:
Just let me know if I need to do anything to make it into an Open Propeller project. And how you guys at Parallax would like this application to evolve.
Michel
Michel, no problem about the Apache 2 license from Blockly. We can work with whatever they require and it's not a problem.
Regarding the server-side, I'd be willing to look into that once we know what's required. We have a pretty small IT department these days of two guys (excluding web team) but if I approach them at some point with specific requirements we could put a server in place for this purpose.
To make it an open Propeller Project, I'll edit the title to be Open Propeller Project #5: Blockly! And this is what else will happen:
Graphic. We will eventually put a graphic on the first page of this thread. As your application matures we can also draw upon Jen Jacob's graphic abilities to give you anything for the application so it looks professional. It seems like Blockly doesn't really require this, but if it ends up being transformed into some kind of stand-alone app with landing screen I can provide whatever you might want.
I can provide whatever hardware you and other contributors need to do this job - just send me an e-mail with the request. I don't mind sending an S2 to you in Belgium, for example. I'd be happy to rely on you to make such requests of me.
Our marketing staff will start drawing more attention to this thread and the application. They use social media.
Also, I should point out that perhaps the most important aspect of this to Parallax is the ability to reach lower levels. Even if it supports a bunch of activities on the Propeller Activity Board, that'd be great. At some point we could integrate this into Learn.parallax.com. And, we are revising the S2 robot to become an S3 - Ben @Element and I have just launched this effort and we're doing our best to fast-track it for the next production run. While Phil's S2 GUI is truly awesome and very capable, it is imperative that we move to platforms other than Windows for the S3.
Sounds okay by you?
And we are very honored to have your contribution, in case I have not made it clear already.
What if we create a version that is hosted at Parallax, and users download a small native (cross platform) application that opens a socket to the server and identifies itself.
When loading the application, the server would compile the application and send it to the selected client.
This would eliminate the requirement for a server on the users computer while supporting all browsers
I'm not sure I get the idea here.
Why not make that small native application a web server? It can serve up the initial blockly IDE and then provide Propeller programming services.
Isn't that what your java server does already?
Now, the beauty of this is that the little server can now be run on a very small device other than the users PC or tablet or whatever.
For example run it on a Raspberry Pi that is connected to a Propeller. As in Bill Henning's Propeller/Pi robot controller boards.
Then you have a robot, or whatever gadget, with a self hosted, self contained web development system.
Of course, you can also do the Spin compilation in the browser itself with openspin.js.
This has the advantage of saving a round trip to the "remote" compiler. That little server app only need then program the Propeller.
Ken,
I will spend some cycles here, as I find time, to help. I think this path has some really cool potential.
I agree, entirely. I just attended an educational conference (ECEDHA.org) where I saw several presentations from university professors. They all spoke of the importance of starting programming with a graphical programming language. And I've seen how this works as a volunteer for the last couple of years in middle school and high school - it's a great first step and introduction to programming without writing code.
Why not make that small native application a web server? It can serve up the initial blockly IDE and then provide Propeller programming services.
Isn't that what your java server does already?
Now, the beauty of this is that the little server can now be run on a very small device other than the users PC or tablet or whatever.
For example run it on a Raspberry Pi that is connected to a Propeller. As in Bill Henning's Propeller/Pi robot controller boards.
Then you have a robot, or whatever gadget, with a self hosted, self contained web development system.
Of course, you can also do the Spin compilation in the browser itself with openspin.js.
This has the advantage of saving a round trip to the "remote" compiler. That little server app only need then program the Propeller.
I proposed this so users could start creating a programs online, without having to download and start a anything. Then when you want to load your program into your Propeller you have a little program that connects to the server.
I don't know how hard it would be to write something in native code to replace the java. I'm thinking about rewriting the server because I'm afraid that the requirement for Java would be a hurdle for some potential users.
Instead of truly native (C++), maybe python would be a good idea. (Today I found that the client from Dropbox is written in Python while you run it as a native program.)
While playing with my RaspberryPi I've used a little python and that would be a good alternative to Java.
Of course, if any of you are experienced in C++ and want to write the embedded server, I welcome any contributions.
Michel, no problem about the Apache 2 license from Blockly. We can work with whatever they require and it's not a problem.
Regarding the server-side, I'd be willing to look into that once we know what's required. We have a pretty small IT department these days of two guys (excluding web team) but if I approach them at some point with specific requirements we could put a server in place for this purpose.
To make it an open Propeller Project, I'll edit the title to be Open Propeller Project #5: Blockly! And this is what else will happen:
Graphic. We will eventually put a graphic on the first page of this thread. As your application matures we can also draw upon Jen Jacob's graphic abilities to give you anything for the application so it looks professional. It seems like Blockly doesn't really require this, but if it ends up being transformed into some kind of stand-alone app with landing screen I can provide whatever you might want.
I can provide whatever hardware you and other contributors need to do this job - just send me an e-mail with the request. I don't mind sending an S2 to you in Belgium, for example. I'd be happy to rely on you to make such requests of me.
Our marketing staff will start drawing more attention to this thread and the application. They use social media.
Also, I should point out that perhaps the most important aspect of this to Parallax is the ability to reach lower levels. Even if it supports a bunch of activities on the Propeller Activity Board, that'd be great. At some point we could integrate this into Learn.parallax.com. And, we are revising the S2 robot to become an S3 - Ben @Element and I have just launched this effort and we're doing our best to fast-track it for the next production run. While Phil's S2 GUI is truly awesome and very capable, it is imperative that we move to platforms other than Windows for the S3.
Sounds okay by you?
And we are very honored to have your contribution, in case I have not made it clear already.
Sincerely,
Ken Gracey
Ken,
It's nice to know someone else can provide graphics. As a software engineer design is not my strongest sign. Although I have some books about design for non designers, it's still another mindset that's hard to get into.
Concerning the target platforms: I have a demo-board, a couple Propeller Proto boards and an eezeeProp.
Maybe you have noticed that the pins you can set in the digital read/write blocks are 0-7 and 16-23, the pins on the Demo board that can be used for these actions.
In Blockly it's possible to configure multiple profiles with sets of pins. So, if you want I can make versions for other boards.
I'll at least make a generic profile with all 32 pins (maybe only 28, leaving out p28-31).
Having been to the first ever Maker Faire in Belgium today I'm ready to continue.
Another block serie is added: Do you have a Parallax Serial LCD (2 or 4 lines) lying around? Connect it to your Propeller and try it out. http://www.parallax.com/product/27977
If you don't add an init block some default values are used: pin 0, baud 9600, 2 lines
@Michel L, How much web space would be needed for the hosting? In the event Parallax is not able to do this, I host web sites and would be happy to contribute some space for this project. I just switched my hosting plan and I now run on dedicated servers.
@Michel L, How much web space would be needed for the hosting? In the event Parallax is not able to do this, I host web sites and would be happy to contribute some space for this project. I just switched my hosting plan and I now run on dedicated servers.
Currently, the application file is about 4MB but it's not a server package yet. Giving you any real resource requirements is currently not yet possible.
It's good to know there are other options. I myself have only a cheap php hosting, where I currently host the demo version. But if we would work with a system where the users download a small application that set an open socket connection that would work anymore. That would probably not even be a http connection. What is impossible with php (as far as I know, php is not my strongest language).
Thanks for the proposal, if we're so far that a server is required I might get back to you.
It is quite possible to have an application make HTTP requests, PUT, GET etc, to your server and interoperate with it in the same way a browser does. In that way it would work with your existing PHP server or what ever you end up using.
There are many libraries and ways to do this depending on which language the application is written in.
It is quite possible to have an application make HTTP requests, PUT, GET etc, to your server and interoperate with it in the same way a browser does. In that way it would work with your existing PHP server or what ever you end up using.
There are many libraries and ways to do this depending on which language the application is written in.
Heater,
That's indeed not that hard, but what I was proposing was a system where the client opens a connection and that the server then can push data to the client at any time.
In Java we have asynchronous connections, but as far as I know, that's not available in php.
But these are worries for later, if we would decide to not use the self hosted system.
I'll now get to work and work a bit on the application. I'm not planning on making new blocks today but work on other parts of the application.
I'll hope you will all be pleasantly surprised when I put it online later today.
I just put a new version online, but sadly I haven't been able to do what I was planning for. To see the changes you will need to download the application and run it yourself. I now also added the dialogs to the demo version, but they still don't actually do anything.
When you click compile, Load into ram or eeprom you now get a nice dialog with the output of the different libraries.
I hoped to add openspin.js to the demo version but it turned out to be harder then I thought when I wrote my previous message. If forgot that I somehow need to provide the other spin files you need. I still would like to add it but I'll need some support to get it done.
I've now setup the help system. A first page is available on http://blocklyprop.creatingfuture.eu/help/digitalpin.html#write.
You will be sent to this page by adding a Digital Write block to your workplace and then rightclick on it. Select Help from the context menu and a new window/tab will open with the linked page. (Only the page digital read/write is currently correctly set)
To make it easier for others to write help pages they're written in markdown and are converted to html when building the application. I still need to create a stylesheet so that it looks better.
How do guys like the progress? Anything more ideas?
When it comes to "server push" the best solution is websockets.
As far as I can tell when it comes to websockets the best solution is to write the websocket server in JavaScript running under node.js. It's also very easy to write a websocket client that could accept binaries over the websocket connection, program the Propeller by calling on openspin and the relay the results back to the server and hence back to the users browser. It can also be used for the terminal connection once the Propeller is running.
This does not mean you have to throw away the PHP server as a node.js server can easily be proxied behind nginx.
When it comes to "server push" the best solution is websockets.
As far as I can tell when it comes to websockets the best solution is to write the websocket server in JavaScript running under node.js. It's also very easy to write a websocket client that could accept binaries over the websocket connection, program the Propeller by calling on openspin and the relay the results back to the server and hence back to the users browser. It can also be used for the terminal connection once the Propeller is running.
This does not mean you have to throw away the PHP server as a node.js server can easily be proxied behind nginx.
Currently there's no php. All my server does is serve static files, so it could be any server actually. The version you download contains an embedded java server. If we would end up using applications that connect using websockets I wouldn't have to change anything. As I can handle websockets in Java, no need to rewrite in node.js.
If you make the client in C++ then you have to be sure it's cross platform and provide binaries for every ones platforms: Windows, Mac, Linux on PC, Linux on Raspberry Pi .....I guess building it with Qt would make that easier.
Java, well, you need to get everybody to install a Java JVM.
Me, I'd go for node.js client. Then the user only has to install node.js. Which is less hassle than Java. And then install your client using the node package manager:
I've just been playing around with python for a while. I now have an applications with which you select a .eeprom or .binary file and it loads it into your prop.
Using PyInstaller I create an executable that even doesn't require Python to be installed. Using the same operating system detection as I did in the Java version I use another Propeller-load executable.
Now I need it to setup a connection with a server that then can push binaries to the client. And meanwhile I'm learning a bit more Python
Now enough for today, time to think about what to write tomorrow evening.
I have to disagree. Installing JAVA was more easy then installing node.js in windows.
I had time yesterday to play work with the editor and will update the other thread soon.
I hoped to add openspin.js to the demo version but it turned out to be harder then I thought when I wrote my previous message. If forgot that I somehow need to provide the other spin files you need. I still would like to add it but I'll need some support to get it done.
The Editor does this with a small parser, reading spin code and pulling needed sub objects into the emscripten MemFS to be available for openspin at compile time.
I have to disagree. Installing JAVA was more easy then installing node.js in windows.
I would have to agree. And I guess that at least some users will already have Java installed for other applications, while node.js is really something for developers and servers.
But currently I'm writing the server in Java and a client in Python. We'll see how that turns out. Later we can evaluate this.
Any suggestions on other parts of the application?
Mike, I think I'll skip that then and focus on the real application. That part was only for the demo server, if it was only 5 minutes work, I would have done it.
I've just been playing around with python for a while. I now have an applications with which you select a .eeprom or .binary file and it loads it into your prop.
Using PyInstaller I create an executable that even doesn't require Python to be installed. Using the same operating system detection as I did in the Java version I use another Propeller-load executable.
Now I need it to setup a connection with a server that then can push binaries to the client. And meanwhile I'm learning a bit more Python
Now enough for today, time to think about what to write tomorrow evening.
Yes Michel ! The server should be distributable with a small non-invasive package. Python 2.7 programs can be made into less than 2MB packages for people who don't want to use an external server. It is not clear however if that would work on an mobile phone or tablet.
The biggest target platform for this is something line an iPad (sorry Heater, that's the way it is), but it will be beneficial for other users too especially in education programs.
Yes Michel ! The server should be distributable with a small non-invasive package. Python 2.7 programs can be made into less than 2MB packages for people who don't want to use an external server. It is not clear however if that would work on an mobile phone or tablet.
The biggest target platform for this is something line an iPad (sorry Heater, that's the way it is), but it will be beneficial for other users too especially in education programs.
How I currently see it, tablets and phones should be able to use it without a problem.
You would navigate with your browser to a centrally hosted server (possibly at Parallax) written in Java. This server contains your projects and compiles the applications.
Users also download a small client written in Python and run that on the computer connected to the Prop. Using credentials you would be able to select in the web application to which client you want to download your application to (if you have multiple connected).
For those wanting to work offline I'll keep providing the embedded java server I currently have. You run that on the computer your prop is connected to and it points your browser to localhost.
Some advantages of the centrally served system:
The updates are published just by changing the content on the server, and the next time the users load the page they have the latest version
By having all project on the server, a community can be set up where you can simply select a checkbox to share it to others
You don't have to work with localhost, or ip-address based. Something that's foreign for users that are not used to hosting their own server
... But currently I'm writing the server in Java and a client in Python. We'll see how that turns out. Later we can evaluate this.
Any suggestions on other parts of the application? ...
I do not want to highjack this thread, but I do like the Idea of a local web server in opposite of a 'central' one. I do not really care if written in Java, Node, C or Python.
Your current Java Server works fine for me. I can run Ram and Burn eeprom from the browser now. Directory access works. The only thing I am missing now would be PUT requests to support writing files to the web server File System.
The 'central' Library and Demo Folder at Parallax are possible if Parallax would allow Cross-origin access so XMLhttp requests could work. I am doing that now at http://parallax.msrobots.net/ and anybody can access those files from JavaScript within a browser. I guess you can do that from Java or Python clients also.
I can see the Idea of running BlockyProp and or the editor from a central website and just downloading a JavaApplet/ActiveX/whatever for programming the propeller, but I found out while using the Editor that it is quite painful to 'download' your sources to save them. And having my sources JUST on some remote servers is sort of way to cloudy for me.
I had some internet outage last month and had some days off thru that since I could not reach my workplace in Germany. Most productive Days for working on the Propeller since a while...
I've been working some more on the help pages. I didn't have much time today and I also worked a bit on the WebIDE application, so don't expect any miracles.
The help pages now have some basic styling although I have some work to do. Also a page index still needs to be created. I'll see to write some pages to complete the styling on. Afterwards I'm hoping that some of you might want to help out writing pages.
Because all files are statically served I have no way of indexing them and providing a search option for them. I might need to rework the entire setup. (I've removed half of my forum post as I thought of this while I was writing)
I've left the help pages for what they are for now and added an intro page. It's not the most interesting design, but it's a start. Content is at this moment more important than presentation.
I'm looking for an optimal user experience, so that a new user finds out what's available and where he can start.
As always; keep the suggestions coming, help me with priorities and evaluate what i have made. (It's very hard to look at something as a normal users if you've just written it)
I've replaced the language the help pages are written in, from markdown to textile. In textile you can set html id's and classes, this is needed to be able to create nicely styled pages.
I've created a couple more help pages (for cognew and delay block).
I'm starting to get out of ideas of things I can set up that will work with the demo server. So, let the suggestions come.
The editor for Scribbler was planned but I've gotten an idea on how to make it more user friendly. So I've started working on that. (I didn't put it online as it isn't yet usable)
The editor for the Scribbler will be slightly different from the general version. You will not only have a totally different set of blocks to use, but it will also contain an area where the movements can be simulated. Something like https://blockly-demo.appspot.com/static/apps/maze/index.html.
That way you won't have to load it each time into the robot, and you can also write code when you don't have your Scribbler with you. It's possible to provide this as I know all parts of the robots and can simulate them.
The simulator will not be running spin in the browser, instead I'll also generate javascript, and that will be executed instead.
Writing this animation won't be able, but I like the challenge. Blockly uses svg so I will probably do the same. It's either svg or canvas, I want to stay away from applets or flash.
Today I started on the Scribbler simulator, it doesn't yet work, but I've added a couple hardcoded move commands. (1 second forward, 2 seconds turning on its place at 90°/second, 1 second forward)
With a couple more days of work this should be a nice feature. I don't know yet how to simulate the wall detector and line follower, but first I need to get it moving.
Currently only the straight and rotate around its own center has been implemented. What's more I'll have to calibrate it using a real S2.
Currently the movements are calculated as:
straight: in pixels = (left / 100) * (time / 10)
Left 100, Right 100, Time 1000: 100pixels
Left 50, Right 50, Time 1000: 50pixels
Left 50, Right 50, Time 2000: 100pixels
rotation: in degrees = (left * time) / 1000
Left 90, Right -90, Time 1000 milliseconds = 90° to the right
Left 90, Right -90, Time 2000 milliseconds = 180° to the right -> used in the example
Left 45, Right -45, Time 2000 milliseconds = 90° to the right
Getting from a left and right motor speed to a rotate action is also quite complex. Any one of you that are good in math? I need to go from left speed and right speed for a set period of time to a rotation center and angle.
Comments
Michel, no problem about the Apache 2 license from Blockly. We can work with whatever they require and it's not a problem.
Regarding the server-side, I'd be willing to look into that once we know what's required. We have a pretty small IT department these days of two guys (excluding web team) but if I approach them at some point with specific requirements we could put a server in place for this purpose.
To make it an open Propeller Project, I'll edit the title to be Open Propeller Project #5: Blockly! And this is what else will happen:
- Graphic. We will eventually put a graphic on the first page of this thread. As your application matures we can also draw upon Jen Jacob's graphic abilities to give you anything for the application so it looks professional. It seems like Blockly doesn't really require this, but if it ends up being transformed into some kind of stand-alone app with landing screen I can provide whatever you might want.
- I can provide whatever hardware you and other contributors need to do this job - just send me an e-mail with the request. I don't mind sending an S2 to you in Belgium, for example. I'd be happy to rely on you to make such requests of me.
- Our marketing staff will start drawing more attention to this thread and the application. They use social media.
Also, I should point out that perhaps the most important aspect of this to Parallax is the ability to reach lower levels. Even if it supports a bunch of activities on the Propeller Activity Board, that'd be great. At some point we could integrate this into Learn.parallax.com. And, we are revising the S2 robot to become an S3 - Ben @Element and I have just launched this effort and we're doing our best to fast-track it for the next production run. While Phil's S2 GUI is truly awesome and very capable, it is imperative that we move to platforms other than Windows for the S3.Sounds okay by you?
And we are very honored to have your contribution, in case I have not made it clear already.
Sincerely,
Ken Gracey
I will spend some cycles here, as I find time, to help. I think this path has some really cool potential.
Why not make that small native application a web server? It can serve up the initial blockly IDE and then provide Propeller programming services.
Isn't that what your java server does already?
Now, the beauty of this is that the little server can now be run on a very small device other than the users PC or tablet or whatever.
For example run it on a Raspberry Pi that is connected to a Propeller. As in Bill Henning's Propeller/Pi robot controller boards.
Then you have a robot, or whatever gadget, with a self hosted, self contained web development system.
Of course, you can also do the Spin compilation in the browser itself with openspin.js.
This has the advantage of saving a round trip to the "remote" compiler. That little server app only need then program the Propeller.
I agree, entirely. I just attended an educational conference (ECEDHA.org) where I saw several presentations from university professors. They all spoke of the importance of starting programming with a graphical programming language. And I've seen how this works as a volunteer for the last couple of years in middle school and high school - it's a great first step and introduction to programming without writing code.
Ken Gracey
Done!
And also added a validator to the stacksize of Cognew, now it needs to be numeric.
I proposed this so users could start creating a programs online, without having to download and start a anything. Then when you want to load your program into your Propeller you have a little program that connects to the server.
I don't know how hard it would be to write something in native code to replace the java. I'm thinking about rewriting the server because I'm afraid that the requirement for Java would be a hurdle for some potential users.
Instead of truly native (C++), maybe python would be a good idea. (Today I found that the client from Dropbox is written in Python while you run it as a native program.)
While playing with my RaspberryPi I've used a little python and that would be a good alternative to Java.
Of course, if any of you are experienced in C++ and want to write the embedded server, I welcome any contributions.
It's just an idea, nothing is yet decided.
Michel
Ken,
It's nice to know someone else can provide graphics. As a software engineer design is not my strongest sign. Although I have some books about design for non designers, it's still another mindset that's hard to get into.
Concerning the target platforms: I have a demo-board, a couple Propeller Proto boards and an eezeeProp.
Maybe you have noticed that the pins you can set in the digital read/write blocks are 0-7 and 16-23, the pins on the Demo board that can be used for these actions.
In Blockly it's possible to configure multiple profiles with sets of pins. So, if you want I can make versions for other boards.
I'll at least make a generic profile with all 32 pins (maybe only 28, leaving out p28-31).
Having been to the first ever Maker Faire in Belgium today I'm ready to continue.
Michel
If you don't add an init block some default values are used: pin 0, baud 9600, 2 lines
What do you think? Suggestions?
Currently, the application file is about 4MB but it's not a server package yet. Giving you any real resource requirements is currently not yet possible.
It's good to know there are other options. I myself have only a cheap php hosting, where I currently host the demo version. But if we would work with a system where the users download a small application that set an open socket connection that would work anymore. That would probably not even be a http connection. What is impossible with php (as far as I know, php is not my strongest language).
Thanks for the proposal, if we're so far that a server is required I might get back to you.
Michel
It is quite possible to have an application make HTTP requests, PUT, GET etc, to your server and interoperate with it in the same way a browser does. In that way it would work with your existing PHP server or what ever you end up using.
There are many libraries and ways to do this depending on which language the application is written in.
Heater,
That's indeed not that hard, but what I was proposing was a system where the client opens a connection and that the server then can push data to the client at any time.
In Java we have asynchronous connections, but as far as I know, that's not available in php.
But these are worries for later, if we would decide to not use the self hosted system.
I'll now get to work and work a bit on the application. I'm not planning on making new blocks today but work on other parts of the application.
I'll hope you will all be pleasantly surprised when I put it online later today.
Michel
When you click compile, Load into ram or eeprom you now get a nice dialog with the output of the different libraries.
I hoped to add openspin.js to the demo version but it turned out to be harder then I thought when I wrote my previous message. If forgot that I somehow need to provide the other spin files you need. I still would like to add it but I'll need some support to get it done.
You will be sent to this page by adding a Digital Write block to your workplace and then rightclick on it. Select Help from the context menu and a new window/tab will open with the linked page. (Only the page digital read/write is currently correctly set)
To make it easier for others to write help pages they're written in markdown and are converted to html when building the application. I still need to create a stylesheet so that it looks better.
How do guys like the progress? Anything more ideas?
When it comes to "server push" the best solution is websockets.
As far as I can tell when it comes to websockets the best solution is to write the websocket server in JavaScript running under node.js. It's also very easy to write a websocket client that could accept binaries over the websocket connection, program the Propeller by calling on openspin and the relay the results back to the server and hence back to the users browser. It can also be used for the terminal connection once the Propeller is running.
This does not mean you have to throw away the PHP server as a node.js server can easily be proxied behind nginx.
Currently there's no php. All my server does is serve static files, so it could be any server actually. The version you download contains an embedded java server. If we would end up using applications that connect using websockets I wouldn't have to change anything. As I can handle websockets in Java, no need to rewrite in node.js.
Could be, or native clients. Eliminating the requirement for java on the clients.
If you make the client in C++ then you have to be sure it's cross platform and provide binaries for every ones platforms: Windows, Mac, Linux on PC, Linux on Raspberry Pi .....I guess building it with Qt would make that easier.
Java, well, you need to get everybody to install a Java JVM.
Me, I'd go for node.js client. Then the user only has to install node.js. Which is less hassle than Java. And then install your client using the node package manager:
Using PyInstaller I create an executable that even doesn't require Python to be installed. Using the same operating system detection as I did in the Java version I use another Propeller-load executable.
Now I need it to setup a connection with a server that then can push binaries to the client. And meanwhile I'm learning a bit more Python
Now enough for today, time to think about what to write tomorrow evening.
I had time yesterday to play work with the editor and will update the other thread soon.
The Editor does this with a small parser, reading spin code and pulling needed sub objects into the emscripten MemFS to be available for openspin at compile time.
Enjoy!
Mike
I would have to agree. And I guess that at least some users will already have Java installed for other applications, while node.js is really something for developers and servers.
But currently I'm writing the server in Java and a client in Python. We'll see how that turns out. Later we can evaluate this.
Any suggestions on other parts of the application?
Mike, I think I'll skip that then and focus on the real application. That part was only for the demo server, if it was only 5 minutes work, I would have done it.
Just wait for Java to start nagging you ;-)
Yes Michel ! The server should be distributable with a small non-invasive package. Python 2.7 programs can be made into less than 2MB packages for people who don't want to use an external server. It is not clear however if that would work on an mobile phone or tablet.
The biggest target platform for this is something line an iPad (sorry Heater, that's the way it is), but it will be beneficial for other users too especially in education programs.
How I currently see it, tablets and phones should be able to use it without a problem.
You would navigate with your browser to a centrally hosted server (possibly at Parallax) written in Java. This server contains your projects and compiles the applications.
Users also download a small client written in Python and run that on the computer connected to the Prop. Using credentials you would be able to select in the web application to which client you want to download your application to (if you have multiple connected).
For those wanting to work offline I'll keep providing the embedded java server I currently have. You run that on the computer your prop is connected to and it points your browser to localhost.
Some advantages of the centrally served system:
I do not want to highjack this thread, but I do like the Idea of a local web server in opposite of a 'central' one. I do not really care if written in Java, Node, C or Python.
Your current Java Server works fine for me. I can run Ram and Burn eeprom from the browser now. Directory access works. The only thing I am missing now would be PUT requests to support writing files to the web server File System.
The 'central' Library and Demo Folder at Parallax are possible if Parallax would allow Cross-origin access so XMLhttp requests could work. I am doing that now at http://parallax.msrobots.net/ and anybody can access those files from JavaScript within a browser. I guess you can do that from Java or Python clients also.
I can see the Idea of running BlockyProp and or the editor from a central website and just downloading a JavaApplet/ActiveX/whatever for programming the propeller, but I found out while using the Editor that it is quite painful to 'download' your sources to save them. And having my sources JUST on some remote servers is sort of way to cloudy for me.
I had some internet outage last month and had some days off thru that since I could not reach my workplace in Germany. Most productive Days for working on the Propeller since a while...
Enjoy!
Mike
The help pages now have some basic styling although I have some work to do. Also a page index still needs to be created. I'll see to write some pages to complete the styling on. Afterwards I'm hoping that some of you might want to help out writing pages.
Because all files are statically served I have no way of indexing them and providing a search option for them. I might need to rework the entire setup. (I've removed half of my forum post as I thought of this while I was writing)
If you want to see what I currently have: http://blocklyprop.creatingfuture.eu/help/index.html
I'm looking for an optimal user experience, so that a new user finds out what's available and where he can start.
As always; keep the suggestions coming, help me with priorities and evaluate what i have made. (It's very hard to look at something as a normal users if you've just written it)
Michel
I've replaced the language the help pages are written in, from markdown to textile. In textile you can set html id's and classes, this is needed to be able to create nicely styled pages.
I've created a couple more help pages (for cognew and delay block).
I'm starting to get out of ideas of things I can set up that will work with the demo server. So, let the suggestions come.
The editor for the Scribbler will be slightly different from the general version. You will not only have a totally different set of blocks to use, but it will also contain an area where the movements can be simulated. Something like https://blockly-demo.appspot.com/static/apps/maze/index.html.
That way you won't have to load it each time into the robot, and you can also write code when you don't have your Scribbler with you. It's possible to provide this as I know all parts of the robots and can simulate them.
The simulator will not be running spin in the browser, instead I'll also generate javascript, and that will be executed instead.
Writing this animation won't be able, but I like the challenge. Blockly uses svg so I will probably do the same. It's either svg or canvas, I want to stay away from applets or flash.
With a couple more days of work this should be a nice feature. I don't know yet how to simulate the wall detector and line follower, but first I need to get it moving.
Currently only the straight and rotate around its own center has been implemented. What's more I'll have to calibrate it using a real S2.
Currently the movements are calculated as:
Getting from a left and right motor speed to a rotate action is also quite complex. Any one of you that are good in math? I need to go from left speed and right speed for a set period of time to a rotation center and angle.