CVS, Propeller, Microsoft Robotics Studio
codepro
Posts: 22
It would be nice of Parallax could offer some sort of CVS (Concurrent Versions Systems) for managing (i.e. updating) the Propeller Object Exchange.· This I believe would dramatically speed up software development.· I am interested in using the Propeller and Microsoft Robotics Studio together.· In order to make full use of the Microsoft Robotics Studio would require Propeller Spin code for all of Parallax products (i.e. appmods, displays, sound, video, communication, motor control, sensors).
Comments
Why? A couple of reasons:
o Managing a CVS server for more than a couple of users can become an administrative pain in the butt. Handling setting up accounts, managing authentication, dealing with the "I lost my CVS password, can you help me?" requests takes up time.
o Sourceforge has automated administration for all of that, and far, far more, already in place.
o I'm sure that the Parallax people would much rather be managing their products than a service that doesn't actually bring in any revenue.
Parallax would have to release the rights for the Spin objects already on the site/in the IDE for posting on SourceForge, of course, but I wouldn't see that as being a big issue. It would be rather nice for them, after all, to have someone else take on the task.
- Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
I would much rather see CVS/SVN software hosted on Parallax servers.· Sourceforge.net is full of annoying advertisements.· The CVS Sourceforge.net is opensource so Parallax could use that software.
Also Parallax would need to decide which license (i.e. GNU) they are going to release the source code under.
Post Edited (codepro) : 8/18/2006 5:18:01 PM GMT
Open source does *NOT* mean that the source code is free for anyone to copy and/or redistribute to others, at will. There are many, many Open Source licenses, some of which are fairly restrictive.
Codepro:
Sourceforge does have advertisements, but I find them to be pretty innocuous. And very easy to block.
You didn't address the subject of administration. I don't get the impression that Parallax is so lacking in things to do that they'd be likely to want to spend their time on being system administrators for a potentially time-consuming task, when there are already solutions out there that will handle it, free of charge.
But, perhaps a little input from a Parallax representative would be nice, too.
- Rich
One thing to note here is Parallax·hosted forums in-house a number of years ago, and then decided to use forums available on yahoogroups.com and·now they back to hosting the forums in-house.· Lessen learned here is it's not always better to use a existing website just because it already has the functionality you are looking for.
Post Edited (codepro) : 8/18/2006 5:45:23 PM GMT
the right way to go. Maintaining a CVS server is a fairly large undertaking, especially with regards to security.
I've been using sourceforge now for a year (http://sourceforge.net/projects/golly/) and am quite happy with
their product; I spend maybe an hour a month doing anything there, and can focus on developing and other
stuff.
Truthfully, though, just to keep things clean, the best way to do this might be to have a single individual here
(probably not even a Parallax administrator) apply for and open a "Propeller Object Repository" project on
sourceforge, and once it's live, coordinate with Parallax.
Even with CVS you may want to use the existing model of having code be submitted, checked out (at least
for obvious things) and then added to the repository by an administrator; I'm not sure you want to have full
CVS write access open to the world.
The IT guy at parallax is busy enough keeping things working smoothly, without the needed headachs of administrating a cvs/svn server. I managed such a system, both with sourceforge and other software, and it's a down right pain in the *$$... Maybe not quite a full time position, but it does consume time. I believe we should let the folks at parallax do what they do the best... make outstanding products, provide outstanding support, and help all who ask. If you truly want a managed CVS/SVN system for spin objects, maybe you shouldn't nominate someone who already has a demanding job, but try it yourself. Personally, I have discovered that there's no better job completed then one that you yourself has completed.
With this being said, the following applies: Please read through the forums on both subjects. Both were discussed, at length to end at the following:
RE: Licensing: "Spin was developed to be freely exchanged between [noparse][[/noparse]users and designers], as truely open source."
RE: CVS/SVN: "That's not a bad idea. In the future we could setup a site for automatically downloading the most current object."
In effect we do have an object exchange in service, maintained freely by parallax for anyone to download and use the objects there.
The preceeding was not intended to be inflamatory against anyone's opions, knowledge or lack there of, but intended to gently inform thoes who aren't in full effect of the information presented in these forums. You can use this link for searching the forums: http://search.parallax.com/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
After that, it will live or die, based on its own merits.
- Rich
I think it's very important that everyone endorses the project·at sourceforge.net, including especially the people at Parallax.· If Parallax does not endorse it then there will end·up being two very different versions (Propeller Object Exchange at Parallax, and·the project at sourceforge.net)·of similar functionality source code which will result in a duplicated effort.· There needs to be one master.·
·
One of the first problems I see in a user-maintained repository is the mechanism by which objects are organized and accessed by the IDE, which doesn't readily lend itself to external maintenance.
My first precept is that you don't want to simply have a directory full of dozens, or hundreds of objects. This becomes unmaintainable and unusable rapidly. Therefore, there is a need for catagorization, possibly at several levels.
For example: Say that you have an LCD object that falls into, oh, a Display category. Obviously there are other objects that fall into that category, like the examples provided by Parallax - the VGA, TV_Terminal, etc. objects. These objects are in a common category, but are not necessarily dependent on, or related to each other.
Next, you want to encourage object re-use. That is, after all, the whole point of this idea.
But you also don't want to have multiple, possibly incompatible versions of an object hanging around. And this is where the IDE becomes a *huge* roadblock; In my tests, and according to the documentation, you have an object search path that consists of two directories - the Work Folder containing your top object file, and the Propeller IDE's Library folder. And that's it. You're stuck with putting all your files into one or the other.
So we have a need for categories. And we have a need to keep the number of files in a directory to a reasonable amount. Now, the normal, and easy way of handling this is to simply have a directory hierarchy - something like Display/LCDObject.spin, Display/TV.spin, Display/VGA.spin, and so on. You the would normally define a project's contents by pointing to just the files you want, in one or more directories, in some fashion - a makefile, an IDE-maintained project file, etc.
But - the Spin IDE won't let you do that, unless you either choose to make Display your working directory, or the Library Directory your working directory - and that's just not acceptable if you're doing real work, where you need to seperate the main project files from the object libraries you're accessing.
Now, of course you can choose to package the objects up in the categorized directory structure I mentioned, perhaps in a zip file, and then require the user to unpack it on their system, and then manually copy the appropriate objects to their working directory. But I don't find that acceptable either. It's too prone to errors, and negates the convenience of just being able to extract the latest files from the source control system, and lay them down on disk, ready to go. And let's face it - if users end up contributing a large number of Spin objects, who wants to wade through the thousands of potential files, trying to figure out which ones are needed?
Another really cheezy way around the problem would be to use a file naming convention - something like "All files will be named CATEGORY_object.spin". You'd end up with a directory full of hundreds of files, and you'd still end up having to pick-and-choose the ones you want, and manually copy them over to your working directory. So the end result is still really poor. And even worse, in fact.
Now, the best solution would be for the IDE to support true projects; Allow the developer to define the files and their ( possibly multiple ) paths for each project. So you just update the SpinRepository from CVS, and voila - you have the latest version of everything, you're not manually overwriting files, and you have met the need to keep the minimal number of files around that your project needs to use.
But, until and unless the IDE supports multiple-directory project functionality, the only even remotely possible solution I see is to define the object catagories, use those as top-level directories, and then force the user to manually copy objects they need into their working directories.
Any other comments? Suggestions?
- Rich
I understand what you're saying here. This is going to be a problem. Perhaps we should make the IDE allow subdirectories from the library folder that could be automatically- or user-maintained. In the OBJ section, the filename could be specified as "sublibraryfoldername\objectname" to force a particular sub-folder. Do you think that would be adequate? We would like to keep things as simple as possible while allowing practical deployment of many objects. We've avoided the normal "project" concept so far because we don't want to force people into complexity at the outset of a project. The TOPFILE concept is our only "project" mechanism, and you can see that it's not dictatorial,·but more of·a benign feature that is helpful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 8/19/2006 6:19:42 AM GMT
What you're suggesting is similar to the way Perl module libraries are organized. When I say
in Perl, it means use the file Curve.pm in the Math/Fractal subdirectory of the current library directory. In Spin, this would be:
I think such a system would fit very well with Spin. I would recommend allowing nested subdirectories to any depth, however, not just one more level.
As icing on the cake, it might also be nice to maintain a PATH environment which programmers could modify, so they can change the order in which top-level library directories are searched. This makes it easy to substitute objects from one's own sub-library for their equivalents in the main library. This would also be handy in an educational environment where multiple users share the same computer, with each user having his own library, but also using objects from the shared library.
As an example of how a hierarchical module (object) repository is organized, take a look at www.cpan.org. This archive of Perl modules is huge but drop-dead simple to use.
-Phil
Summary: I like the subdirectories idea too. I don't see any more functionality necessary. Baby steps, and that's a good first one.
-Parsko
Then you have flexibility in folder layouts, SCM integration, etc. If you want to create a build environment, preprocessor, macro processor, food processor, whatever, you can do that, too.
First, implement Chip's suggestion of allowing directory paths to be specified when loading objects. I would suggestion permitting both absolute and relative paths - and the relative paths would be rooted at the Library folder. My assumption is that this would be an extremely easy modification to make to the IDE. This takes care of the immediate problem of eliminating directories full of hundreds of unrelated files.
However, at least as a personal preference, I always keep my libraries ( in any language ) separate from the IDE product, as I'm a firm believer that you keep unrelated things apart.
In a second phase of IDE modifications, I suggest that the IDE be updated to allow the user to specify one or more object roots. Any relative references to objects would be searched as follows:
1) The user's working directory
2) Iterate through the list of ( possibly multiple ) object roots
3) The Parallax Library directory
Thiis allows users to make modifications to standard Parallax objects in their working directories, without affecting the "shipping" version from Parallax. It also allows them to make use of a hierarchy of user-contributed objects very easily, and to isolate them from any IDE updates, without having to move their hierarchies around too much.
And finally, as Kevin noted, having a version of the compiler/loader that could be called from the command line would be *great*. That would open up a flood of possibilities in terms of project-build automation, as well as freeing developers to use their preferred environments.
The main - very bare - project page is located at http://sourceforge.net/projects/spinrepository
Web-browsable CVS access is at http://spinrepository.cvs.sourceforge.net/spinrepository/ I've added a little bit of code that I've been working on that is intended to be used as an API to access the iButtonLink 1-wire interface.
I welcome any and all Parallax engineers to join in as project admins, if they so desire. Additionally, anyone who wants to submit code can register as a sourceforge developer, and ask for write-access to the repository. Anyone else can, of course, always get copies of the spin files without an account, anonymously. For those who want to contribute files, but don't want to bother dealing with CVS, etc, you can always email a project admin, and ask one of us to add the files in.
I think the first order of business is to define some general catagories for projects, and set up the directory structure. My first contribution is Hardware/Interfaces. More will undoubtedly follow.
Any questions? Comments? Brickbats?
- Rich
- Rich
Instead of Hardware\Interface\thelink.spin, for example, just rename the file .Hardware.Interface.thelink.spin and store it in your project directory or Spin library. Names that start with a period will be listed ahead of names beginning with an alphanumeric character, just as directories are. And everything will be in order by category. The only catch, of course, is that everything is still in the same directory. But files will be much easier to manage and find than without the categorical prefices.
-Phil
It depends on how long it will take for Parallax to make the initial modification to the path handling, and release a new IDE. If it would just be a week or two, then I wouldn't bother with using a flat namespace in the CVS server, and then moving the files around to their final destinations - CVS is not terribly good about management of renamed files, especially when you don't have direct access to the CVS repository - and on SourceForge, at least, we don't have that access.
OTOH, if it looks like it will take a while for the IDE to be updated, then I'd agree with going along with the flat namespace, just to get things rolling.
- Rich
After that, it will be up to the users to remember that the project is there, and to submit files.
My plan is to have a nightly script run that will package up the whole repository into a .zip file and upload it as a "latest" package than can be easily accessed by users - I certainly don't expect that most people would be interested in working with CVS to keep a local sandbox up to date.
In the meantime, I've started contacting various people who have included scripts with their forum posts, etc, asking for permission to include their files. So far, the response is 100%.
Additionally, I would like to get at least two other administrators on the project. I'd ask only that you be familiar with CVS, have a passing familiarity with SourceForge, and, best of all, agree with everything I say, think, or do.
Well, maybe we can drop that last requirement.
- Rich
I don't expect that most people will be using CVS, but as I mentioned before, the *entire* repository will be available as a bundled zip file, for download. In projects such as this, there are typically far more people interested in just getting the latest and greatest version of something, rather than everyone wanting to jump in and start updating code.
The difference is that the Object Exchange forces you to download files one-by-one, doesn't offer a usable hierarchy, and, assuming it starts getting more files, will become much more difficult to search for the appropriate dependencies. ( i.e., one zip file will include a version of tv_text, while another file also uses a slightly different, and perhaps incompatable, version of tv_text. etc - then, you start downloading different files, only to have a dozen different variations of the same thing... )
It's not clear what you're referring to when you say "From what I gather only the orginal author of the spin object can modify the code...so much for a collaborated effort." If you're referring to SourceForge, that's not the way it works. Anyone who is interested in modifying code can update ANY code in the repository, if they so choose. Of course, someone who has a history of screwing up would lose that right pretty quickly.
- Rich
At the start of this forum I mentioned I stated "...In order to make full use of the Microsoft Robotics Studio would require Propeller Spin code for all of Parallax products (i.e. appmods, displays, sound, video, communication, motor control, sensors).."· This is going to be a incredible effort requring collaboration on a large scale to be successful.· More on this later.· This will mean using some sort of CVS.
·
- Rich
Rich it sounds like you alreay know·alot about working on projects in Sourceforge.net· Maybe you can help out·people in this forum who are new to Sourceforge.net and talk about some the aspects such as how they can be added to developer list and checking out and checking in files?·