Shop OBEX P1 Docs P2 Docs Learn Events
Spin and IDE and OBEX, oh my! — Parallax Forums

Spin and IDE and OBEX, oh my!

Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
edited 2012-02-02 17:50 in Propeller 1
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

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-02-01 20:37
    Thanks to all who read my original post. I was rather hoping that this thread would garner more comment -- well some comment, at least -- from the projects' various principals. It's an issue that can't be left to rest, IMO. We stand on the threshold of either doing something great for the Propeller or settling for an amorphous stew of well-intentioned but uncoordinated efforts. I'm hoping desperately for the former.

    Yeah, I know: this is a bump. It's agin' forum rules, but passion sometimes has to trump dictum.

    -Phil
  • idbruceidbruce Posts: 6,197
    edited 2012-02-01 21:16
    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
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-02-01 21:25
    Some comments:

    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
  • idbruceidbruce Posts: 6,197
    edited 2012-02-01 21:31
    Sure, do a recursive directory search to try and find the desired file on the PC, if it does not exist, then do a recursive search on internet file, either http or ftp.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-02-01 21:37
    There is no need for recursion. The hierarchy is specified in the reference. In fact, one of the key features of the idea requires that it not recursively search, but instead look only where you specify.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-02-01 21:39
    Roy Eltham wrote:
    What I'd really like to see is the OBEX stuff being integrated into the IDE, ...
    That would be a tremendous facility to have available! It's one of those grand ideas whose mere mention entails necessity!

    -Phil
  • idbruceidbruce Posts: 6,197
    edited 2012-02-01 21:45
    There is no need for recursion. The hierarchy is specified in the reference. In fact, one of the key features of the idea requires that it not recursively search, but instead look only where you specify.

    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
  • idbruceidbruce Posts: 6,197
    edited 2012-02-01 22:04
    Roy

    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
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-02-01 22:12
    Phil,
    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. :) Jeff Martin is Parallax's head Software Engineer, and up to him ultimately. I will hopefully be discussing this stuff with him soon.
  • tdlivingstdlivings Posts: 437
    edited 2012-02-02 09:38
    Roy,
    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
  • jazzedjazzed Posts: 11,803
    edited 2012-02-02 10:30
    tdlivings wrote: »
    Just some competitive anaylsis thoughts since you seem to be brainstorming IDE concepts.


    I certainly appreciate this idea and have done some similar analysis. Your summary is very valuable. Thanks.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-02-02 10:30
    tdlivings,
    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
  • rokickirokicki Posts: 1,000
    edited 2012-02-02 11:22
    Yes; the IDE should feature prominently a "search" button that "searches" the OBEX, and when matches
    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.
  • Keith LeinenbachKeith Leinenbach Posts: 25
    edited 2012-02-02 12:45
    I'm glad to see Phil's thread got some hits! I was hoping it lead to a broader discussion though about how we were going to build the Yellow Brick Road (as Phil says).

    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
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-02-02 14:00
    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
  • idbruceidbruce Posts: 6,197
    edited 2012-02-02 14:04
    Referring now to the combination of the IDE, Gold Standard Objects, a help system, and auto-updating. No IDE is complete without a good help system to help and inform users, and no object is complete without good documentation. I believe for every Gold Standard Object there should be a help file within the IDE that documents the object and it's use. Additionally, for any auto-updater that may be implemented with the IDE, it should also auto-update the help file system to include documentation about new Gold Standard Objects that are available and of course the Gold Standard Objects as well.

    Bruce

    EDIT: Gold Standard Objects should also require a well written help file when added to the OBEX.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-02-02 14:35
    If Gold Standard objects are formatted for my autodocumenter, an HTML help file can be generated automatically from the source code. If the autodocumenter were made part of the IDE, it could be done on the fly upon request.

    -Phil
  • idbruceidbruce Posts: 6,197
    edited 2012-02-02 14:53
    Phil

    I must say that is pretty slick.

    That S2 object looks like it may have taken a while to write. :)

    Bruce
  • Keith LeinenbachKeith Leinenbach Posts: 25
    edited 2012-02-02 15:48
    The changes to Spin of the type that we're discussing affect the compiler, the OBEX, and the IDE.

    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-02-02 16:54
    rokicki said
    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.

    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...
  • 4x5n4x5n Posts: 745
    edited 2012-02-02 17:41
    Roy Eltham wrote: »
    Phil,
    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. :) Jeff Martin is Parallax's head Software Engineer, and up to him ultimately. I will hopefully be discussing this stuff with him soon.

    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!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-02-02 17:49
    Keith,

    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
  • 4x5n4x5n Posts: 745
    edited 2012-02-02 17:50
    tdlivings wrote: »
    Roy,
    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

    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.
Sign In or Register to comment.