Shop OBEX P1 Docs P2 Docs Learn Events
Simple Library Feedback. — Parallax Forums

Simple Library Feedback.

photomankcphotomankc Posts: 943
edited 2013-09-18 06:21 in Propeller 1
So stepping back into the SimpleIDE after some time away and I have impressed by the simple library concept. Very nice to not need to hunt down common objects from another location and weave them into the project. Adding them is easy and straight-forward and the documentation is nicely done. Very impressive.

My use though exposes something I think may bite some corner case folks like me. My development work takes place on two different platforms. Sometimes I develop and load the program directly from a Netbook that lives on my workbench. That system stays there all the time and is convenient at times where I just want to tweak this or that and load it up or the bench is too cluttered for a larger laptop. I also keep a logic analyzer attached to this system with probes on the pins of interest for the present project. All pretty easy so far, probably exactly how 99% of folks work. Sometimes I also do development work on the Macbook Pro. The normal way I do that is to use CodeBlocks on the Mac to edit the source files for the project (all stored on shared disk space). I then use the Mac to RDP to the NetBook and build using SimpleIDE on that system as well as use the logic analyzer attached to monitor signal level activity. This I do often remotely, from lunchroom at work, or in a hotel, or even sitting on the sofa watching a movie. The Netbook provides a way to interface to the hardware remotely and debug even though I'm not sitting in the basement.Still works fine this way.

However, if I decide to use SimpleIDE to open the shared project folder directly from the Mac to build and load the code from the Mac itself things go bad. I do this when I'm sitting there at the bench since it's easier to not deal with RDP and such when I'm right there. The reason for the problem seems to be the library path statements. For obvious reasons the path to the learn/simple libaries/* folder is very different between platforms and the libraries will not be found on the system that did not do the initial adding of the library. Even storing them in shared disk space won't work because Windows has drive letters and Mac/Linux have mount points and the relative paths will not be the same. What I have been doing to get around this issue is copy down the simple libraries folder items I need for each project into the project folder and then adding them using the normal method but selecting the copies in the project folder instead of the distribution in the documents folder. This leads to a relative path that is valid for either platform and I can open the project and compile on either system without any effort to fix the include/library paths in the project. It all 'just works'.

My question is, would it be a very difficult feature to add where when you select a library the library is copied into the project folder and linked in from there. From then on, each time the project is opened the files in the master location are checked against the files in your project folder and updated if needed, or you are prompted to update? This way your libraries are/can be kept in step with new releases of SimpleIDE or your own updates to the master but the project paths are not platform dependent and you can take a project from Windows to Mac to Linux without missing a beat.

Comments

  • jazzedjazzed Posts: 11,803
    edited 2013-09-04 12:23
    Source control is a very effective solution to this problem. Try googlecode just as a test - it has totally spoiled me. It is possible to clone the propsideworkspace.googlecode.com repository and add your own changes. You can also keep your own private repository on your server. I recommend looking at subversion (svn) and mercurial (hg).
  • __red____red__ Posts: 470
    edited 2013-09-04 12:40
    While on conceptual questions... Is there a defined way that my C code can encapsulate and / or call a SPIN object?

    Also, if I have an object that I've already written in assembly that in spin I stored in a DAT region and spawned using cognew(), is there a C equivalent of doing that?
  • jazzedjazzed Posts: 11,803
    edited 2013-09-04 14:07
    __red__ wrote: »
    While on conceptual questions... Is there a defined way that my C code can encapsulate and / or call a SPIN object?

    It is entirely possible, but not defined at the moment. It will be necessary to fix-up the Spin.binary stack space. Many Spin programs use unspecified stack areas like video buffers, so that complicates things. A method of sharing variables would also be useful. There should not be any compiler changes needed for supporting spin objects. Spin objects would need to be cognew'd as a binary with the built-in Spin interpreter.

    I discussed this with Parallax several months ago, but at the time at least it was not a high priority for me to address. It seems to be a popular feature request. If someone else wants to look at this, cool - I don't have time for it though.
    __red__ wrote: »
    Also, if I have an object that I've already written in assembly that in spin I stored in a DAT region and spawned using cognew(), is there a C equivalent of doing that?

    Yes, add your Spin code to your SimpleIDE project. Requirements are: PASM must be the first DAT section, PASM can not be initialized using SPIN (a mailbox can be used to initialize data if necessary), the PASM data blob must be in HUB for cognew, and the PASM name will be a variation of the spin file name: I.E. "extern int binary_filename_dat_start[];"

    See the libfdserial project for an example. https://code.google.com/p/propsideworkspace/source/browse/#hg%2FLearn%2FSimple Libraries%2FText Devices%2Flibfdserial

    Cheers.
  • photomankcphotomankc Posts: 943
    edited 2013-09-18 06:21
    Well I don't see source control being able to fix the mismatch how path strings are kept and my idea, where that could be useful, is not really a solution either. Linking in the libraries from a shared project folder is slow and bloats each project directory by megabytes making it more tiresome to zip, move, build, load, etc. The learn folder being local speeds a build up considerably when libraries are used but at the cost of making the project platform specific because of the path strings.

    The only way around that I see is to have the .side file contain platform specific sections so that the project can be loaded with correct compiler directives for any supported platform without having to fix the linked library paths. Not sure if that is something that fits with the vision or not. For now I'm going to forgo the notion of switching back and forth. There seems to be issues doing that even with the libraries in the project folder anyway. I'm starting to cozy up to the Mac for my development tools anyway. I like the command line capability combined with the nice interface of XCode to edit the source files. I just let SimpleIDE do the build and load on the bench-top MacMini.
Sign In or Register to comment.