...The Propeller iPad iOS program download efforts are underway and shall soon be released with a complete SimpleIDE and WiFi programming interface thanks to several forum members, jazzed and ByteWorks, but we haven't made any progress with Chromebooks. ...
Ken Gracey
I didn't find the previous discussion thread about this although I know it's somewhere. I have a vague memory that a new revision of the Prop Activity Board would be needed for downloading code through xBee WiFi and from e.g. an iPad and presumably also a Chromebook. Is that still the fact and if so, should we wait for the new PAB revision? (Almost ordered my third PAB during the '10 % weekend' but finally stayed away)
Related to this Project #7, I have unfortunately nothing to provide, so count me out.
It can be hard to leave the social northern utopia in which you live, but perhaps moving south a bit could be to your benefit.
Are you making me an offer:)
You're about to enter the dark, long winter.
That's the only time we can get anything done around here!
It stands to reason that anything done on a browser should be more minimalist since there's sometimes a latency between button clicks, menu searches, etc.
Depends. Interaction with the browser/web page should be pretty fast. Not noticeably slower than using a native Windows or Qt app for example. Heck you can even put hardware accelerated 3d graphics into your web page and play quake on it. Of course web apps tend to rely on a server in the "cloud" a lot so interaction with that is where the latencies come in.
Will likely need to widen it to include the BASIC Stamp,
Is there a compile for the BASIC Stamp written in C/C++ that can be translated to JS for browser use. If not perhaps it's best to create one directly in JavaScript. That could also be run on a PC under node.js as a command line app.
@David,
That all might be possible except caviar will be replaced by walnuts and dancing girls by dancing robots. Will that be okay?
Oh all right. Just get me a sleeping bag under the work bench, throw some pizza and beer down there occasionally and I'm your man. Walnuts is good, I don't work for peanuts you know.
Oh, and free use of all the equipment at Parallax HQ.
Oh all right. Just get me a sleeping bag under the work bench, throw some pizza and beer down there occasionally and I'm your man. Walnuts is good, I don't work for peanuts you know.
Oh, and free use of all the equipment at Parallax HQ.
Great! You're hired! Wait, I can't hire Parallax employees. Oh well. You have my vote anyway. :-)
I noticed that Google Chrome has an API that supports sending data using serial ports. So program loading is possible.
While open source text editors for Google Chrome already exist, you're going to have to rewrite the compiler and loader.
The best solution might be to write create an editor and loader in Google Chrome and then send the text to be compiled off to a web server that performs secure compiles for the user and then returns the executable.
Yes indeed, Google Chrome has an API for using serial ports. Works as a "Chrome app" on a Chromebook or as an "extension" to the Chrome browser. Cannot be used by regular web apps though.
You have not been following the story. We already have a Spin compiler working in the browser. And hence usable in ChromeOS on a Chrome book. Basically what we do is "compile" the open source spin compiler, which is written in C++, into JavaScript using the Emscripten compiler. This produces openspin.js which believe it or not works very well in the browser and at a very usable speed.
Similarly the loader from propgcc can be compiled into Javascript and used in the browser. I have been playing with that already with good results.
Yes, sending the source off to a "compile farm" in the cloud is one way to go. Not really needed for Spin as we can compile in the browser already. But may be needed for propgcc, I can't imagine we are ever going to get that to work in the browser of Chrome app.
Yes, sending the source off to a "compile farm" in the cloud is one way to go. Not really needed for Spin as we can compile in the browser already. But may be needed for propgcc, I can't imagine we are ever going to get that to work in the browser of Chrome app.
That could be true but have you considered trying to port Catalina? That wouldn't get you C++ of course.
Yes, sending the source off to a "compile farm" in the cloud is one way to go. Not really needed for Spin as we can compile in the browser already. But may be needed for propgcc, I can't imagine we are ever going to get that to work in the browser of Chrome app.
Heater since you've messed with this stuff, do you know of a better Chrome terminal emulator than Beagle Term? (https://chrome.google.com/webstore/detail/beagle-term/gkdofhllgfohlddimiiildbgoggdpoea?hl=en) To back up that this does indeed work - I have personally used that on an HP14 Chromebook to talk to a microcontroller via a prop plug, and it worked without my having to change to a developer channel or install any sort of drivers. It's missing things like any sort of file transfer support. I did see negative feedback for some users which sounds driver related, but maybe that's all fixed now. I imagine those problems would apply to any program attempting to use serial. See the reviews at the above link if you're interested.
I have not played with the Chrome serial port much. Only looked over the API and the Espruino IDE use of it. Had never heard of Beagle Term before, I'll check it out.
term.js is a VT100 terminal emulator that you can drop into a page. What I'd like to do as a starter is connect term.js up to the serial port API for my in browser terminal (Then I can talk to CP/M machines running WordStar with Chrome )
[url] https://github.com/chjj/term.js
[/url]
Acer C710-2490, got it over a year ago from Future Shop for about $200
BestBuy is selling the Acer C720 for $199 and the C720P for $299. The difference is the C720P has a touchscreen and twice as much flash. My question to Ken was mostly intended to determine whether the touchsceen was important for this project.
BestBuy is selling the Acer C720 for $199 and the C720P for $299. The difference is the C720P has a touchscreen and twice as much flash. My question to Ken was mostly intended to determine whether the touchsceen was important for this project.
I have an Acer 720 - I enjoy it for couch surfing. One of the nice things about it is the SSD can be upgraded from the standard 16GB (to at least 128GB)
A lot of people out on the 'nets with tutorials - I haven't upgraded mine yet but will when I can set aside a block of time.
David - a few random thoughts. One thing that you can potentially do is to enter developer mode and get linux going on a Chromebook. e.g. via Crouton. If you do this then things like more storage, RAM, and perhaps x86 become important. Make sure to consider this before purchasing. I know some people that like the touch screens, and some who find them annoying because they touch it out of habit, and don't want it to react. Another thing to consider is if you think getting lifetime tmobile 4g access is worth extra. The free plan is very little data, but if you want to give one to someone (e.g. my aunt) who is going to be emailing then perhaps it's worth it.
"ART uses an ahead-of-time (AOT) compiler that compiles to machine code when you install the app" - not sure what they are doing for Chromebook though. Anyways this should help to open up Chromebook a little more over the long haul - or do you actually like everything to be web apps? I wonder if Clojure is affected by AOT?
If I have your attention - do you think that Espruino could be easily ported to a PIC32MX170F256B? It's cheap, has 256 kbytes FLASH, 64 kbytes of RAM, it's an easy to use DIP, and it's the next version of what the micromite uses.
I just don't like Java. Don't like "everything is a class" style. Don't like Oracle. Don't like that there is no standard for it, like ISO, ANSI, ECMA etc. Don't like that Java has no compelling features over any other language and hence no particular reason to exist at all.
...or do you actually like everything to be web apps?
You say that as if web apps are a bad thing. Not quite sure what you are getting at.
Seems to me there is no escaping it. Pretty much everything significant/important we do to day is web based. From this forum, to source code management, to banking, to flight/holiday booking, to shopping, email, search, file sharing, backup, collaboration etc etc.
Those things all require access to services, databases and people "out there" and so do require the internet/web. But then again "web app" need not depend on net connectivity. Like for example the wonderful Espruino IDE, a chrome app that enables programming of micro-controllers and does not need the net to operate.
Certainly we still have apps that need to be or just are purely local affairs. Language compilers, FPGA tools, SPICE simulators etc etc Any particular reason they cannot be "web apps". Surely size and performance are issues with that idea.
As it happens "web apps" as in HTML5/CSS/JavaScript is about the easiest way to create applications that can be distributed to and used by pretty much anyone no matter what platform (hardware and OS) they use. No recompilation, no package building no installation hassles. See Jazzed's recent comments about supporting SimpleIDE and PropellerIDE packages for a dozen different platforms and how his next apps will be in JavaScript.
On the other hand, do I like that an app won't work without a net connection, no. Do I like that an app locks me in to some company to provide the service, no.
In the end if you can provide a good user experience then fine. I have a Chromebook and I've used Android, and apps on the latter delivered a better user experience. Perhaps there are also developers that would find it easier to target than webapps. Web developers will tell you plenty of horror stories about supporting various browsers, or is that a solved problem? So to me this seems like a positive development, and I don't see why you view it as a negative.
In the end if you can provide a good user experience then fine. I have a Chromebook and I've used Android, and apps on the latter delivered a better user experience. Perhaps there are also developers that would find it easier to target than webapps. Web developers will tell you plenty of horror stories about supporting various browsers, or is that a solved problem? So to me this seems like a positive development, and I don't see why you view it as a negative.
The devil you choose should be the least amount of trouble.
Here is a web-app that works on Exploder, Firefox, Chrome, Safari, iOS, and Android. Let me know if you have trouble with it - see the Help for how the user interface should work. I've been looking at jQuery, and it is supposed to be "the web-app solution" .... Is it? Who knows for sure?
The thing is that to support that app on all platforms as a normal app, assuming you can make it function on all platforms, you have to provide all kinds of packaging. Then you have user install issues, etc.... A web app that can run on all platforms solves the packaging and install problems.
So to me this seems like a positive development, and I don't see why you view it as a negative.
Here is the deal:
I should be able to write a program with a GUI. May be even something simple with just buttons, check boxes, text boxes, menus and so on.
That program should be runnable anywhere that has a slightly high resolution display. Perhaps even if it needs recompiling to do so.
Turns out that after more that fifty years of building GUIs into computers we still cannot do that. We have had Windows, and the MAC and the Amiga and the Android and the iOS and WebOS and ....oh yeah and the X Windows System which is the closest to universal we ever had. But even there we have Qt, WxWidgets and God knows what else.
Even today someone on this forum was asking for propgcc and SimpleIDE and for Windows RT. WTF?
Turns out also that "Web Apps" as in HTML/CSS/JavaScript are currently the most universal way of creating such a GUI application.
Now, I do admit that the "web app" as in HTML/CSS/JavaScript solution is itself a nightmare. It's a whole bunch of technologies holding together with band aid as far as I can tell. Hey, but it works.
Me, I working on creating the whole user interface in JS and WebGL. I want to avoid HTML and CSS as much as possible.
I've been looking at jQuery, and it is supposed to be "the web-app solution" .... Is it? Who knows for sure?
No. This will drive you crazy.
jquery has a very important role in papering over the difference between browsers. All well and good.
When it comes to creating a "web app" we are buried in choices of libraries, frameworks and so on: YUI, qooxdoo, Angular, React, Bootstrap, and so on and so on.
I have not gotten to the bottom of this since two years ago when I started with a JS and Webgl project.
What I do know is that I want to stay as far away from HTML and CSS and the browser DOM API as possible.
jquery has a very important role in papering over the difference between browsers. All well and good.
When it comes to creating a "web app" we are buried in choices of libraries, frameworks and so on: YUI, qooxdoo, Angular, React, Bootstrap, and so on and so on.
I have not gotten to the bottom of this since two years ago when I started with a JS and Webgl project.
What I do know is that I want to stay as far away from HTML and CSS and the browser DOM API as possible.
Has it been decided not to use the work that has already been done on a web IDE for the Propeller?
Has it been decided not to use the work that has already been done on a web IDE for the Propeller?
Err, well, who do you expect to decide what about what?
As far as I see this is an open source "challenge" thrown out there by Ken to see what happens.
If any of the actual code we have hacked up, whilst experimenting with developing Prop programs in Spin in the the browser, ever gets used is up to whoever wants to take up the challenge.
I certainly don't have the time or energy or skill to take what we have done much further. But we have at least shown what can be done and how it can be done.
That is: me demonstrating how to get OpenSpin converted to JavaScript and working in the browser. And msrobots getting the CodeMirror editor working with Spin syntax highlighting.
The missing parts are: Making it all look cool and programming the Prop over a serial port from a Chrome Web App.
I am very attracted to tackling that serial port part. If I have any time....
Edit: The "looking cool" part is where we get bogged down in jquery, YUI, qooxdoo, bootstrap, bla, bla, whatever library/framework you want to use. The mechanics of what is needed to do the actual work are in place.
It was mentioned on the first page of this thread that there is no C/C++ support because you can't (easily/realistically) drop GCC on a chromebook. That same post also mentioned the possibility of sending source code off to a server, compiling it, and sending back a binary. That's where I'd like to help.
I'd be happy to provide a server and the necessary back-end programming to make such a thing happen. I've played around with mbed and I think it's great. I'd love to see that type of idea show up for the Propeller, and I'd love to encourage a wider use of C/C++ on the Propeller!
Edit: The "looking cool" part is where we get bogged down in jquery, YUI, coxdoo, bootstap, bla, bla, whatever library/framework you want to use. The mechanics of what is needed to do the actual work are in place.
This sounds like a college student's senior project. Maybe Parallax can do some recruiting at nearby tech schools?
Comments
BINGO. Yes. It was a rhetorical question.
The real question is "When do we, the users, get control of our machines"
There is a reason why Richard Stallman and the Free and Open Source Software advocates seems so fanatical. It's as simple as that.
Seems that "vendor lock in" is moving more and more to the hardware.
I didn't find the previous discussion thread about this although I know it's somewhere. I have a vague memory that a new revision of the Prop Activity Board would be needed for downloading code through xBee WiFi and from e.g. an iPad and presumably also a Chromebook. Is that still the fact and if so, should we wait for the new PAB revision? (Almost ordered my third PAB during the '10 % weekend' but finally stayed away)
Related to this Project #7, I have unfortunately nothing to provide, so count me out.
@David, Oh all right. Just get me a sleeping bag under the work bench, throw some pizza and beer down there occasionally and I'm your man. Walnuts is good, I don't work for peanuts you know.
Oh, and free use of all the equipment at Parallax HQ.
While open source text editors for Google Chrome already exist, you're going to have to rewrite the compiler and loader.
The best solution might be to write create an editor and loader in Google Chrome and then send the text to be compiled off to a web server that performs secure compiles for the user and then returns the executable.
Yes indeed, Google Chrome has an API for using serial ports. Works as a "Chrome app" on a Chromebook or as an "extension" to the Chrome browser. Cannot be used by regular web apps though.
You have not been following the story. We already have a Spin compiler working in the browser. And hence usable in ChromeOS on a Chrome book. Basically what we do is "compile" the open source spin compiler, which is written in C++, into JavaScript using the Emscripten compiler. This produces openspin.js which believe it or not works very well in the browser and at a very usable speed.
Similarly the loader from propgcc can be compiled into Javascript and used in the browser. I have been playing with that already with good results.
Yes, sending the source off to a "compile farm" in the cloud is one way to go. Not really needed for Spin as we can compile in the browser already. But may be needed for propgcc, I can't imagine we are ever going to get that to work in the browser of Chrome app.
Oh boy, here we go. I never thought of that. I can speculate that compiling Catalina with Emscripten is a thousand times easier than propgcc.
I start to think I have to cancel all current projects and social engagements for a little while...
Heater since you've messed with this stuff, do you know of a better Chrome terminal emulator than Beagle Term? (https://chrome.google.com/webstore/detail/beagle-term/gkdofhllgfohlddimiiildbgoggdpoea?hl=en) To back up that this does indeed work - I have personally used that on an HP14 Chromebook to talk to a microcontroller via a prop plug, and it worked without my having to change to a developer channel or install any sort of drivers. It's missing things like any sort of file transfer support. I did see negative feedback for some users which sounds driver related, but maybe that's all fixed now. I imagine those problems would apply to any program attempting to use serial. See the reviews at the above link if you're interested.
I have not played with the Chrome serial port much. Only looked over the API and the Espruino IDE use of it. Had never heard of Beagle Term before, I'll check it out.
term.js is a VT100 terminal emulator that you can drop into a page. What I'd like to do as a starter is connect term.js up to the serial port API for my in browser terminal (Then I can talk to CP/M machines running WordStar with Chrome
[url]
https://github.com/chjj/term.js
[/url]
Ken: What kind of Chromebooks are the schools you mentioned using? In particular, are they Chromebooks with touch screens?
Thanks,
David
A lot of people out on the 'nets with tutorials - I haven't upgraded mine yet but will when I can set aside a block of time.
If I have your attention - do you think that Espruino could be easily ported to a PIC32MX170F256B? It's cheap, has 256 kbytes FLASH, 64 kbytes of RAM, it's an easy to use DIP, and it's the next version of what the micromite uses.
You say that as if web apps are a bad thing. Not quite sure what you are getting at.
Seems to me there is no escaping it. Pretty much everything significant/important we do to day is web based. From this forum, to source code management, to banking, to flight/holiday booking, to shopping, email, search, file sharing, backup, collaboration etc etc.
Those things all require access to services, databases and people "out there" and so do require the internet/web. But then again "web app" need not depend on net connectivity. Like for example the wonderful Espruino IDE, a chrome app that enables programming of micro-controllers and does not need the net to operate.
Certainly we still have apps that need to be or just are purely local affairs. Language compilers, FPGA tools, SPICE simulators etc etc Any particular reason they cannot be "web apps". Surely size and performance are issues with that idea.
As it happens "web apps" as in HTML5/CSS/JavaScript is about the easiest way to create applications that can be distributed to and used by pretty much anyone no matter what platform (hardware and OS) they use. No recompilation, no package building no installation hassles. See Jazzed's recent comments about supporting SimpleIDE and PropellerIDE packages for a dozen different platforms and how his next apps will be in JavaScript.
On the other hand, do I like that an app won't work without a net connection, no. Do I like that an app locks me in to some company to provide the service, no.
The devil you choose should be the least amount of trouble.
Here is a web-app that works on Exploder, Firefox, Chrome, Safari, iOS, and Android. Let me know if you have trouble with it - see the Help for how the user interface should work. I've been looking at jQuery, and it is supposed to be "the web-app solution" .... Is it? Who knows for sure?
The thing is that to support that app on all platforms as a normal app, assuming you can make it function on all platforms, you have to provide all kinds of packaging. Then you have user install issues, etc.... A web app that can run on all platforms solves the packaging and install problems.
I should be able to write a program with a GUI. May be even something simple with just buttons, check boxes, text boxes, menus and so on.
That program should be runnable anywhere that has a slightly high resolution display. Perhaps even if it needs recompiling to do so.
Turns out that after more that fifty years of building GUIs into computers we still cannot do that. We have had Windows, and the MAC and the Amiga and the Android and the iOS and WebOS and ....oh yeah and the X Windows System which is the closest to universal we ever had. But even there we have Qt, WxWidgets and God knows what else.
Even today someone on this forum was asking for propgcc and SimpleIDE and for Windows RT. WTF?
Turns out also that "Web Apps" as in HTML/CSS/JavaScript are currently the most universal way of creating such a GUI application.
Now, I do admit that the "web app" as in HTML/CSS/JavaScript solution is itself a nightmare. It's a whole bunch of technologies holding together with band aid as far as I can tell. Hey, but it works.
Me, I working on creating the whole user interface in JS and WebGL. I want to avoid HTML and CSS as much as possible.
jquery has a very important role in papering over the difference between browsers. All well and good.
When it comes to creating a "web app" we are buried in choices of libraries, frameworks and so on: YUI, qooxdoo, Angular, React, Bootstrap, and so on and so on.
I have not gotten to the bottom of this since two years ago when I started with a JS and Webgl project.
What I do know is that I want to stay as far away from HTML and CSS and the browser DOM API as possible.
As far as I see this is an open source "challenge" thrown out there by Ken to see what happens.
If any of the actual code we have hacked up, whilst experimenting with developing Prop programs in Spin in the the browser, ever gets used is up to whoever wants to take up the challenge.
I certainly don't have the time or energy or skill to take what we have done much further. But we have at least shown what can be done and how it can be done.
That is: me demonstrating how to get OpenSpin converted to JavaScript and working in the browser. And msrobots getting the CodeMirror editor working with Spin syntax highlighting.
The missing parts are: Making it all look cool and programming the Prop over a serial port from a Chrome Web App.
I am very attracted to tackling that serial port part. If I have any time....
Edit: The "looking cool" part is where we get bogged down in jquery, YUI, qooxdoo, bootstrap, bla, bla, whatever library/framework you want to use. The mechanics of what is needed to do the actual work are in place.
It was mentioned on the first page of this thread that there is no C/C++ support because you can't (easily/realistically) drop GCC on a chromebook. That same post also mentioned the possibility of sending source code off to a server, compiling it, and sending back a binary. That's where I'd like to help.
I'd be happy to provide a server and the necessary back-end programming to make such a thing happen. I've played around with mbed and I think it's great. I'd love to see that type of idea show up for the Propeller, and I'd love to encourage a wider use of C/C++ on the Propeller!
This sounds like a college student's senior project. Maybe Parallax can do some recruiting at nearby tech schools?