+ Reply to Thread
Page 1 of 2 12 LastLast
Results 1 to 20 of 24

Thread: Spin and IDE and OBEX, oh my!

  1. #1

    Default Spin and IDE and OBEX, oh my!

    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

  2. #2

    Default Re: Spin and IDE and OBEX, oh my!

    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

  3. #3

    Default Re: Spin and IDE and OBEX, oh my!

    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

  4. #4

    Default Re: Spin and IDE and OBEX, oh my!

    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

  5. #5

    Default Re: Spin and IDE and OBEX, oh my!

    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.

  6. #6

    Default Re: Spin and IDE and OBEX, oh my!

    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.

  7. #7

    Default Re: Spin and IDE and OBEX, oh my!

    Quote Originally Posted by Roy Eltham
    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

  8. #8

    Default Re: Spin and IDE and OBEX, oh my!

    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

  9. #9

    Default Re: Spin and IDE and OBEX, oh my!

    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

  10. #10

    Default Re: Spin and IDE and OBEX, oh my!

    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.

  11. #11

    Default Re: Spin and IDE and OBEX, oh my!

    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

  12. #12

    Default Re: Spin and IDE and OBEX, oh my!

    Quote Originally Posted by tdlivings View Post
    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.

  13. #13

    Default Re: Spin and IDE and OBEX, oh my!

    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

  14. #14

    Default Re: Spin and IDE and OBEX, oh my!

    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.

  15. #15

    Default Re: Spin and IDE and OBEX, oh my!

    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

  16. #16

    Default Re: Spin and IDE and OBEX, oh my!

    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

  17. #17

    Default Re: Spin and IDE and OBEX, oh my!

    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.

  18. #18

    Default Re: Spin and IDE and OBEX, oh my!

    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

  19. #19

    Default Re: Spin and IDE and OBEX, oh my!

    Phil

    I must say that is pretty slick.

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

    Bruce

  20. #20

    Default Re: Spin and IDE and OBEX, oh my!

    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

+ Reply to Thread

Similar Threads

  1. Object MS5534.spin in OBEX - how to set reference point for current barometric
    By LarryG in forum Propeller 1 Multicore Microcontroller
    Replies: 14
    Last Post: 02-17-2013, 10:31 AM
  2. Port from OBEX: TrigPack.spin
    By Reinhard in forum Propeller GCC Alpha Test Forum
    Replies: 4
    Last Post: 11-21-2011, 09:25 PM
  3. Is there an /OPT:REF for spin? + OBEX Suggestion
    By RockyD in forum Propeller 1 Multicore Microcontroller
    Replies: 2
    Last Post: 07-16-2011, 05:56 AM
  4. Spin and Forth hybrid idea - obex + interactiveness + speed
    By Peter Jakacki in forum Propeller 1 Multicore Microcontroller
    Replies: 4
    Last Post: 03-15-2010, 07:13 AM
  5. quick checking the obex for new objects: just bookmark http://obex.parallax.co
    By StefanL38 in forum Propeller 1 Multicore Microcontroller
    Replies: 1
    Last Post: 01-31-2008, 05:23 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts