Spin and IDE and OBEX, oh my!
Phil Pilgrim (PhiPi)
Posts: 23,514
Reaching Oz (i.e. the shining city of integrated dev tools for the Propeller) is fraught with danger, unless all the relatively independent efforts follow the same yellow brick road and communicate regularly.
One very important matter I see regarding communication is that none of the initiatives undertaken by Parallax staff or outside contractors can be even remotely independent of each other. The various compilers, the IDEs, a redesigned OBEX, and the Gold Standard are all so intimately entwined, that a decision in one area will affect design objectives in another. Here's just one example: In Roy's Spin compiler thread, there has been a discussion about how to specify in the OBJ section where the various objects reside. One thing that I brought up is that there are too many objects available to have them all in one monolithic library, and that the library should be configured hierarchically into categories and sub-categories. For example, FullDuplexSerial, might become IO::Serial::FullDuplexSerial, IOW a member of the "Serial" volume in the "IO" library. This has far-reaching repercussions across the board. It means that the OBEX must also be organized hierarchically, with a mechanism for making sure that downloaded objects get installed in their proper locations. It means that whoever writes the IDE has to account for this organization when program archives are created, and it means that the Gold Standard will also need to include standards for object naming and categorization.
This is just one example. Decisions by one designer or design team have consequences for all the others. I really wonder if the channels of communication among the various efforts are open enough to accommodate this very necessary interaction. I'm not implying that they aren't, though, as I'm not privy to any of those channels, except what I read here in the forum. In any event, it would be nice to hear from the various principals regarding this matter. In fact, I haven't seen a thing about how the OBEX redesign is coming along or who is working on it. I may have missed it.
The impression I get, evident from postings in the forum, is that the dev-tool effort is being worked on by a fairly loose consortium of contributors. But this could certainly be a misperception on my part. At least I have to assume so, since a laissez faire management approach to this kind of undertaking could never attain any kind of coherent objective.
Thanks,
-Phil
One very important matter I see regarding communication is that none of the initiatives undertaken by Parallax staff or outside contractors can be even remotely independent of each other. The various compilers, the IDEs, a redesigned OBEX, and the Gold Standard are all so intimately entwined, that a decision in one area will affect design objectives in another. Here's just one example: In Roy's Spin compiler thread, there has been a discussion about how to specify in the OBJ section where the various objects reside. One thing that I brought up is that there are too many objects available to have them all in one monolithic library, and that the library should be configured hierarchically into categories and sub-categories. For example, FullDuplexSerial, might become IO::Serial::FullDuplexSerial, IOW a member of the "Serial" volume in the "IO" library. This has far-reaching repercussions across the board. It means that the OBEX must also be organized hierarchically, with a mechanism for making sure that downloaded objects get installed in their proper locations. It means that whoever writes the IDE has to account for this organization when program archives are created, and it means that the Gold Standard will also need to include standards for object naming and categorization.
This is just one example. Decisions by one designer or design team have consequences for all the others. I really wonder if the channels of communication among the various efforts are open enough to accommodate this very necessary interaction. I'm not implying that they aren't, though, as I'm not privy to any of those channels, except what I read here in the forum. In any event, it would be nice to hear from the various principals regarding this matter. In fact, I haven't seen a thing about how the OBEX redesign is coming along or who is working on it. I may have missed it.
The impression I get, evident from postings in the forum, is that the dev-tool effort is being worked on by a fairly loose consortium of contributors. But this could certainly be a misperception on my part. At least I have to assume so, since a laissez faire management approach to this kind of undertaking could never attain any kind of coherent objective.
Thanks,
-Phil
Comments
Yeah, I know: this is a bump. It's agin' forum rules, but passion sometimes has to trump dictum.
-Phil
Now you got me wondering, is there an initiative for the compiler to access objects in the OBEX?
If not, then you simply have them categorized by whatever means necessary and do a recursive directory search until the correct object is found on the PC.
Bruce
This doesn't really apply to the gcc stuff. Since by design and requirement it will work like normal C/C++ stuff does. Code and Libraries will be referred to by their paths in includes or via command line options. It's pointless to try and force all the C/C++ stuff into this pattern, because that just reduces it's desirability to the C/C++ customers they are targeting with gcc. If parallax wishes to organize their provided libraries/sources in the same directory layout for C/C++ then fine, but the syntax and abstraction we discussed for Spin won't exist.
As for Spin, I like the idea we discussed in the other thread. It's easy enough to make the compiler work that way, even if it doesn't get used to it's fullest extent. I think I can influence the IDE work that will be coupled with this to go along, and it's easy enough to have the installed library of Spin files be organized into a directory structure supporting this.
As for OBEX, I haven't heard anything about the revamp (other than it was planned), I don't know if it's even being actively worked on. I can't imagine it being very hard to have gold standard stuff organized accordingly.
What I'd really like to see is the OBEX stuff being integrated into the IDE, so that you can just being up a dialog and navigate the hierarchy as a tree and just selected files to download right into the correct place in your library. We could even have an option to have the IDE automatically attempt to resolved references in the currently open spin file and get the needed files from OBEX. Then I could give you a Spin file and not have to worry about giving you all the dependent files that are up in OBEX, because your can just have the IDE get them for you.
Roy
-Phil
Are you going to have auto-update to update new objects?
EDIT: Or should I say the location of new objects, if not, then you will need to search recursively
If it would help you to reach your new goals a little quicker, I believe I have some ftp and http file routines for VS 6.0 if you want them.
Bruce
As I was typing that out (formulating the idea as I went), I was thinking the same thing.
Bruce,
I am fairly certain the recursive searching will not be needed, and in fact would break the feature. Also, thanks for the offer of code, but it will need code that is cross platform compatible (compiling using gcc and VS 2008/2010 at a minimum). It's likely to be added on to an IDE as a plugin/extension. Besides all that, I'm not even certain I would be the one writing it.
I like the way the Arduino IDE handles librarys ie Objects. As a side note I got one after someone at
Radio Shack who I was pushing Parallax to asked what is the difference between the Arduino and Prop and
since I never had an Arduino I did not know so I spent $30 and bought one.
Back to the Arduino way which does not require the IDE to have platform specific code to implement the lib system.
There is a folder called Library under the main install folder and every lib object has a subfolder under this folder with
the same exact name as the lib object contained in it. In order to add a new lib just create a new subfolder with the same
exact name as the lib you are adding and install, unzip, etc the lib into the new folder. Each lib folder also has an Examples
folder with sub folders with each example under it.
All the IDE needs to know is how to read the folder structure of what ever file system it is running under.
The IDE knows where the Library folder is and when it loads it reads all the folder names into an internal list and at the same
time builds a list of examples by reading the folder names in each Examples folder. When the user selects the IDE menu option
to use a lib ie object it just builds a menu item out of the list it made and you pick the one you want.
I think it is a rather clever way of doing it , it does not prevent you from writing and adding your own lib's or from downloading and
installing new ones by whatever method is being used.
Now you could have built in http ftp code in the IDE to go out to a site and get a new lib and add it to the right place in the folder
structure if one wants to do that, Arduino does not .
When you say the OBEX will be built in to the IDE I worry we will lose the ability to add our own or download new objects until an update to
the IDE is present.
For cross platform the Arduino method keeps it simple for the IDE as I said it only needs to know how to walk it's folder structure and
build a list. Internally the IDE keeps a list of paths to pass to the command line of the compiler or make file it builds but the user does not
need to see this.
Just some competitive anaylsis thoughts since you seem to be brainstorming IDE concepts.
Tom
I certainly appreciate this idea and have done some similar analysis. Your summary is very valuable. Thanks.
My idea about accessing the OBEX from inside the IDE doesn't mean that the IDE has the OBEX built in like you are thinking. It just means that I want to have the IDE able to connect to the OBEX site and get info from it about what is available there and show it to the IDE user and allow them to select files to download/install locally. Also, the original idea Phil and I talked about which involved organizing the library and defines a way to reference the components of the library does allow for you to add additional locations for library alternatives (your own code or variants of library code you have made or downloaded from alternate sources). The same dialog that shows the OBEX stuff could also have local files represented.
Roy
are found, provides an in-IDE link to "download" a module directly into a place where it is then immediately
accessible *from* the IDE. The end user should not need to download a zip, decide where it should go,
unzip it, etc.; all this should be transparent. And there should be some standard README that is
brought up when it is ready to go, ideally with some sample code.
And if we want to get *really* nice, there should be perhaps ready-to-run code for things like the demo
board, so if you specify somewhere you are currently attached to a demo board, there could even be
a direct "download and run me" link.
In any case, what's on disk and what's on the OBEX should be as transparent as possible (with the
caveat that files actually need to be on disk in order to send them to the propeller, so that your
archives are consistent and don't get auto-updated behind your back, which can break things).
Any user step eliminated in the use of an OBEX object means more people will try out those objects
and more success will be had. Think of the Ipod/Itunes/Apple music store integration.
Just as my input, and as someone who is about to put out an IDE, albeit not in the official channel, I would like it if changes to the SPIN language (if any), the interface to the compiler, and the interface to the OBEX are discussed and specified independently from the official tool thread. Maybe this is selfish for my own IDE, but I think if you want to allow other people to interface their own tools (not just IDEs) to the compiler, OBEX, and using the language, it would be nice if this was separated from the build effort of the official IDEs and made more transparent so others can keep current and maybe even help in the decisions to generate the new specs.
As an initial, maybe naive suggestion, you could create 3 discussion threads and link the the actual working specification to the first post. Create one each for the 3 specifications (SPIN, OBEX, Compiler interface).
Keith
I think the "I" in IDE is important, because it's the IDE that brings everything together for the user. The changes to Spin of the type that we're discussing affect the compiler, the OBEX, and the IDE. That's the reason I wanted to make sure everyone had a central place to discuss these issues, since none of them can be addressed in isolation, without affecting the others. But maybe I've missed the point of your comment.
-Phil
Bruce
EDIT: Gold Standard Objects should also require a well written help file when added to the OBEX.
-Phil
I must say that is pretty slick.
That S2 object looks like it may have taken a while to write.
Bruce
Couldn't agree with you more on this point, Quite frankly, the underlying decisions about SPIN, the compiler, and the OBEX, drive what must be done in the IDE, and what CAN be done in the IDE.
All I am saying, is if changes to SPIN, the compiler interface for SPIN, and the OBEX are specified separated from the Eclipse-based IDE, the people building or updating other IDEs have all they need to ensure full compatibility. I'd hate to wait for new releases of the Eclipse-based IDE to find out what changed in the language SPIN. And while reality may tie the final compiler build to the testing it gets in the Eclipse-based IDE, hopefully it is still fully accessible to other developers and it would be great (though not necessary) if the interface changes are discussed upfront. I think the people using the compiler may provide some nice feedback and a little foresight will keep the nail-biting down to a minimum.
As an aside, I like the separation available presently for SPIN and the Compiler. Both are available independently from the current Propeller IDE and nicely documented. I think this is a wonderful way to have it and it is a major reason for attracting me to Parallax's whole setup. I hope it continues that way.
And just for completeness, if it is the desire of Parallax to restructure the organization of OBEX or add a server API to the accessing of it, then I hope this is uncoupled from the Eclipse-based IDE as well, so other IDEs and tools can take advantage of it.
Hopefully, that makes it more clear.
Keith
I like that - "how would Apple do this". I think the answer is they would make it simpler.
The Gold Standard obex is obviously a key part to simplifying things.
I've sometimes wondered about an IDE that is easier to use. Start with a blank new program. You need to define the clock xtal stuff and I can never remember the syntax and a new user wouldn't even know that needs to be there, so that could be a dropdown menu.
Then let's say we want a keyboard and a TV. What is the absolute simplest way these could be added into a program?
Click on a menu in the IDE and search through Phil's hierarchical search and it ought to be fairly quick to find a keyboard and a display object. The object could be local or online and there would be merits in both systems.
Ok, drop in a keyboard object and it ought to be able to fill in the OBJ bit automatically. And you need to tell this object what pins connect to the keyboard so that could be a popup window.
And then as soon as you type keyboard. the IDE ought to be able to put all the methods in a dropdown menu.
Very quickly you could have the TV and Keyboard objects in your program, with the OBJ and VAR and CON sections automatically filled out.
And from the autocomplete part of the objects, it wouldn't take much guessing to see that you connect the .get part of the keyboard to the .out part of the TV to display characters on the screen as you type them.
It is a different way of thinking. Playing around with touchscreens, it helps to try to simplify things to icons and simpler menus. Who knows, maybe soon it will be possible to run such an IDE on the propeller itself? I've got some preliminary code almost working...
Again it's up to Jeff but for something internet based I would recommend something cvs based. With a little prodding even "make" can be made to work with cvs. A far better solution then something based on ftp!
I think that library structure may be a singular case where Spin (the language and compiler), the OBEX, and the IDE are so intertwined. And that's because each has to deal with the files that make up a Spin/PASM build. So it's important to specify things ahead of time, so each of those systems can accommodate the new object organization. Once that's done, development can take place along more independent lines. But we have to do this first, and it has to be done in a totally coordinated fashion.
Also, I don't think Eclipse is part of this equation. That's more for the C/C++ folks. As I understand Eclipse, it's not beginner-friendly, which is non-starter for a Spin dev environment.
_______________
Dr_A,
I agree with your vision for an IDE. A person should not have to remember clock and counter modes or have to look them up. It should -- as an option -- be made multiple choice, the way it's done in the PBASIC editor. A drop-down cheat sheet for operator precedence would be nice, too. What I fear most is that we end up with something that's "good enough for now", with now becoming another six years. It would be nice to get things right going out of the gate this time.
-Phil
For what it's worth the current spin tool functions much the same way. It's been a while since I looked but there are a number of library type routines that are included and you can simply add your own to the directory. That all said I think the spin tool needs a lot of work! At the very least it needs to understand the concept of a "project" and not simply compile and upload the file that's in the current "tab" of the tool. I for one am sick and tired of forgetting to switch to the "top" file of a project and only uploading the currently visible file to my propeller while working on code.