Once again, an HTML5 application need not be a web app. The entire application can be contained in the user's PC, with the user's browser serving as the GUI. The back-end work can be done by software that's resident in the user's PC -- or on a corporate server.
How is that not a web app? You still have the same components - http server & web browser - connecting to each other. You still need to develop it with the same considerations and limitations that are currently in place.
It's not a web app, because no data are transmitted over the worldwide web. I thought it was important to make that distinction, because there were some expressing concern here about data security. As to the server/client construction, yes, the pieces would interact via a communication channel (TCP port) that happens to use HTTP. The difference from an actual "web app" is that the server, being local, can also save programs locally and upload programs via the serial port. For enterprise installations, it might make more sense to separate the file and serial upload services so that the file service can be put on the department's central server, with the upload services remaining on each user's desktop. A more casual approach might be for the local server to load/save files to the central server via an already-established file sharing protocol.
The central question is not how the foreground communicates with the background, but whether a web browser is a rich-enough environment to support the IDE's user interface. If so, it would obviate any need for a separate framework, like .NET, since the web page's DOM and its supporting Javascript library become the framework. What makes all of this possible is not so much HTML5 itself, but AJAX techniques which allow a Javascript program to communicate with the server directly and alter page content via the DOM without refreshing the entire page.
The central question is not how the foreground communicates with the background, but whether a web browser is a rich-enough environment to support the IDE's user interface. If so, it would obviate any need for a separate framework, like .NET, since the web page's DOM and its supporting Javascript library become the framework. What makes all of this possible is not so much HTML5 itself, but AJAX techniques which allow a Javascript program to communicate with the server directly and alter page content via the DOM without refreshing the entire page.
There are enough tools in normal HTML to make nice GUIs. The .net GUI elements are much better and easier to work with for now. Some of those benefits could be marginalized with a very good html development editor though.
Regarding web app: It might not be a web app but it could be with a little software.
Regarding web app: It might not be a web app but it could be with a little software.
Definitely, if that's what people want. In fact, it could easily be the same software, if the compiler/file server were separated from the serial upload server functions. The OBEX could even serve as an online Spin library, assuming versioning and OBJ subdirectory issues can be sorted out.
A web technology-based client/server with a network connected programmer could possibly make the tools as platform independent and portable as possible, which is why I think this deserves at least some consideration.
I believe you can develop with Eclipse today if you want to on linux. BST has a command line compiler under linux so you can just configure eclipse to use that.
I probably can, but there will be no color syntaxing, no folding of block, etc. At the end, it will be as usefull as using a notepad with a bash script calling BSTC.
So I'm still using BST.linux for now. But will love to have a fully supported environment soon...
First my qualifications:
I don't know C (well I can kind of figure out what it's doing).
I've never used GCC. I tried to install it on a windows machine, but I got lost in all the pieces.
So if you need someone with my qualifications to check things out from a newbie perspective...I'm your man.
I DO want to learn C, so I promise I'll put some hours into it.
First my qualifications:
I don't know C (well I can kind of figure out what it's doing).
I've never used GCC. I tried to install it on a windows machine, but I got lost in all the pieces.
So if you need someone with my qualifications to check things out from a newbie perspective...I'm your man.
I DO want to learn C, so I promise I'll put some hours into it.
Running indigo under FC15. Running LPCXpresso...... Want same for prop I as its exists. Prop II is vapor until at least samples are shipping. Is this thread a dead end other than the GCC? If not will it be near the equiv of code red? An enquireing mind would like to know before I blow a year of spare time attempting to graft Cat 3.x or BST into Eclipse as it is a seriously non-trivial thing to attempt expecting pro level results all by ones onwnsome. There does not appear any easy way to do it......
Frank
P.s. This thread is so all over the place!! I and any one who got bit in the @$$ by microsoft in OS/2 days would definitely understand Phil's reluctance to incorporate M$ stuff. Then the win32.dll had a new flavor every time the OS/2ers figured it out. Got so bad that you would never know on a windows machine whether half your apps were going to get stomped by the included version of win32.dll on the "new app" you were installing!!
I would not jump at spending a year grafting Catalina into Eclipse. Catalina already has a very nice IDE in Code::Blocks. Similarly why does Spin need Eclipse? Spin is designed for simplicity which is exactly what you get with the Propeller Tool or BST or PSZT.
I don't think this thread is a dead end. In fact little birds tell me that GCC for the Propeller is coming along very well. Getting that working in Eclipse is what many are ultimately working toward.
Presumably Eclipse already supports GCC rather well, after all it is used by that Xpresso, and others all ready. So I imagine it just needs customization for the various Propeller features, the loader, the debugger interface etc etc.
I have no idea how much work that is but if you are keen and have a year to blow I'm sure the Propeller GCC team would be very glad to have you volunteer.
Running indigo under FC15. Running LPCXpresso...... Want same for prop I as its exists. Prop II is vapor until at least samples are shipping. Is this thread a dead end other than the GCC?
Frank, I've used Eclipse during Propeller-GCC development to make sure it works. Here's a snap.
Heater,
I could not call it blown, but that would be a rough guess as to how long it would take me to master (mostly new concepts) the parser and lexer in general and specifically in Eclipse. IBM has a good three part series on getting a pro-level interface out of eclipse, and it looks like a lot of work. I sometimes grab stuff like that to learn from. Been doing it that way since Signetics sent me my first chip, the 2650 cpu just before I started building up my IMSAI8080. As to the comment about getting involved, I may not be able to develope much on this project, but I am more than willing to help with unit/integration testing.
I like the integration with any of the SCMs out there, though I am most interested in seeing how git works out as opposed to cvs/svn etc. Also I am primarily concentrating on the prop for now, sometimes I get to seminars and such on specific things such as USB, CAN etc. which is how I got the LPCExpresso dev kit.
Jazzed,
Nice to know that is going on. Need help with testing and such let me know. I am always willing to put up rather than shut up!!!
P8x32a Propeller-GCC is still coming along. We hope to start formal Alpha testing very soon.
Most of our Alpha items are done. We expect to preview the tool-chain at Alpha start.
Normally Beta is preview time, but we are allowing for very early feedback from forumists.
In some ways everyone who tries a preview is an Alpha tester, not necessarily a formal tester.
Bugs are part of Alpha. If we don't find bugs, it is not being tested enough. Expect Bugs!
Bear in mind that only the GNU-GCC tool-chain and some libraries will be previewed.
GDB features are not ready and will not be tested (or even implemented) in early the stages.
Preview documentation will not be complete enough for users looking for a mature product.
I have some examples of using Eclipse, but Eclipse plugins are not done.
There may be other IDE front-end items later, but that is not specifically my domain.
I'll be giving a Propeller-GCC presentation next week at Meetup Group. Please join us.
Comments
How is that not a web app? You still have the same components - http server & web browser - connecting to each other. You still need to develop it with the same considerations and limitations that are currently in place.
It's not a web app, because no data are transmitted over the worldwide web. I thought it was important to make that distinction, because there were some expressing concern here about data security. As to the server/client construction, yes, the pieces would interact via a communication channel (TCP port) that happens to use HTTP. The difference from an actual "web app" is that the server, being local, can also save programs locally and upload programs via the serial port. For enterprise installations, it might make more sense to separate the file and serial upload services so that the file service can be put on the department's central server, with the upload services remaining on each user's desktop. A more casual approach might be for the local server to load/save files to the central server via an already-established file sharing protocol.
The central question is not how the foreground communicates with the background, but whether a web browser is a rich-enough environment to support the IDE's user interface. If so, it would obviate any need for a separate framework, like .NET, since the web page's DOM and its supporting Javascript library become the framework. What makes all of this possible is not so much HTML5 itself, but AJAX techniques which allow a Javascript program to communicate with the server directly and alter page content via the DOM without refreshing the entire page.
-Phil
There are enough tools in normal HTML to make nice GUIs. The .net GUI elements are much better and easier to work with for now. Some of those benefits could be marginalized with a very good html development editor though.
Regarding web app: It might not be a web app but it could be with a little software.
-Phil
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars
Thanks for that link. It's probably the least FUDdy article I've seen on the topic.
-Phil
Fascinating article, Kevin - thanks. It seems even Microsoft could never figure out how to use .NET effectively!
Ross.
I love this thread.
Having the ability to use Eclipse to code on the Propeller will be howsome. Because on Linux today there is no much tools supported by Parallax.
Also, I saw many different languages involved, but no one (even jazzed
I stopped to use my prop few months ago because of some lack of time, knowledge and linux tools, but I'm planning to restart.
So if you need any one to do some testing, I will be very hapy to do so...
JM
So I'm still using BST.linux for now. But will love to have a fully supported environment soon...
I don't know C (well I can kind of figure out what it's doing).
I've never used GCC. I tried to install it on a windows machine, but I got lost in all the pieces.
So if you need someone with my qualifications to check things out from a newbie perspective...I'm your man.
I DO want to learn C, so I promise I'll put some hours into it.
Bean
Reverse everything you did and install this: http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/heliossr2
A newer indigo Eclipse package is available, but Helios is what I tested last.
Then run the "Hello World" program which seems to load by default with Eclipse Menu Run -> Run or hit Ctrl-F11.
Frank
P.s. This thread is so all over the place!! I and any one who got bit in the @$$ by microsoft in OS/2 days would definitely understand Phil's reluctance to incorporate M$ stuff. Then the win32.dll had a new flavor every time the OS/2ers figured it out. Got so bad that you would never know on a windows machine whether half your apps were going to get stomped by the included version of win32.dll on the "new app" you were installing!!
I don't think this thread is a dead end. In fact little birds tell me that GCC for the Propeller is coming along very well. Getting that working in Eclipse is what many are ultimately working toward.
Presumably Eclipse already supports GCC rather well, after all it is used by that Xpresso, and others all ready. So I imagine it just needs customization for the various Propeller features, the loader, the debugger interface etc etc.
I have no idea how much work that is but if you are keen and have a year to blow I'm sure the Propeller GCC team would be very glad to have you volunteer.
Usually pushing a string is hopeless. Interestingly it's easy to push a string or derail a thread around here
I could not call it blown, but that would be a rough guess as to how long it would take me to master (mostly new concepts) the parser and lexer in general and specifically in Eclipse. IBM has a good three part series on getting a pro-level interface out of eclipse, and it looks like a lot of work. I sometimes grab stuff like that to learn from. Been doing it that way since Signetics sent me my first chip, the 2650 cpu just before I started building up my IMSAI8080. As to the comment about getting involved, I may not be able to develope much on this project, but I am more than willing to help with unit/integration testing.
I like the integration with any of the SCMs out there, though I am most interested in seeing how git works out as opposed to cvs/svn etc. Also I am primarily concentrating on the prop for now, sometimes I get to seminars and such on specific things such as USB, CAN etc. which is how I got the LPCExpresso dev kit.
Jazzed,
Nice to know that is going on. Need help with testing and such let me know. I am always willing to put up rather than shut up!!!
Frank
C.W.
P8x32a Propeller-GCC is still coming along. We hope to start formal Alpha testing very soon.
Most of our Alpha items are done. We expect to preview the tool-chain at Alpha start.
Normally Beta is preview time, but we are allowing for very early feedback from forumists.
In some ways everyone who tries a preview is an Alpha tester, not necessarily a formal tester.
Bugs are part of Alpha. If we don't find bugs, it is not being tested enough. Expect Bugs!
Bear in mind that only the GNU-GCC tool-chain and some libraries will be previewed.
GDB features are not ready and will not be tested (or even implemented) in early the stages.
Preview documentation will not be complete enough for users looking for a mature product.
I have some examples of using Eclipse, but Eclipse plugins are not done.
There may be other IDE front-end items later, but that is not specifically my domain.
I'll be giving a Propeller-GCC presentation next week at Meetup Group. Please join us.
Hope this helps.
--Steve