I was about to suggest that there is a way we can all use Github for objects in OBEX without putting any load on Parallax at all.
Simply post a description of the object to OBEX as usual with a link to the github repository.
If necessary include a zip package with nothing but a README file in it than contains a ink to github repo and instructions on how to get the code.
@SRLM
But what if the original author disappears and somebody else wants to take up the improvements to the object?
Good point. Of course that happens already. It just results in a new OBEX entry. Alternatively Parallax would have to be the maintainers of the code which I gather they don't have time for.
At least github makes it easy for code to become "our code". Just fork it and carry on.
@Loopy: there's nothing preventing the community from doing this, of course. However, once somebody initiates such a massive project they should really have nothing less than a full commitment to see it through to total success. Anything short of that would bifurcate existing efforts.
But what if the original author disappears and somebody else wants to take up the improvements to the object? A big advantage to moving to VCS for the OBEX is that this is possible: it's not "your code" or "my code", it's "our code". Anybody can suggest and push improvements, without the original author needing to be in the loop
This is the value right here as shared ownership means less abandoned code. Absndoned code is one of the main issues that CPAN for example deals wih all the time. There are certain CPAN authors who after publishing code just disapear (I might also be guilty of that).
Ken is absolutely 110% correct that if anyONE was to attempt such a thing and then not complete it would be harmful. If this is something that the community feels strongly about I would reccomend the "Herd Model" of management which is the model which Gentoo uses.
Gentoo has 310 developers responsible for the distribution and they're broken into herds like so:
If such as thing were to happen it would be imperative that there be sufficient volunteers such that the burden would not be too great on individuals and so that as people's interests and priorities waxed and waned people could be easily brought on and retired.
I like the idea, but without that kind of structure behind it it could very easily burn people out.
But if the individual versions are all merged at some point, how would I know what versions are behind it or even exist and what the differences were at that time... Imagine the flame wars that could erupt over what gets to be merged and when and by whom...
Git does have a feature called "blame". From the documentation:
git-blame - Show what revision and author last modified each line of a file
I've never had a need to use it myself, but it's name sticks with me.
As for the latter problem of merging, I'd imagine that would be solved by some guidelines and community moderation.
Download some existing project:
$ git clone [URL]https://github.com/somebody/some-project.git[/URL]
Edit some files in there, say a.c and b.c then add your changes to the "staging area"
$ git add a.c b.c
Commit all changes as a single commit with a commit message
$ git commit -m "Added new feature X"
Note: That "staging area" thing allows you to group a lot of changes as a single commit where it makes sense, for example when adding a new feature or fixing a single bug that has changes in many files. Also changes to staging are not committed yet so they can be backed out with no change to the commit history.
Push your changes back to the upstream repo
$ git push
If someone else has pushed changes to the upstream repo you can fetch them
$ git pull
Git can do all that hg can, and more. But if you expect it to work like hg you will get very confused.
There are many blogs and tutorials about this on the net of course. github has good instructions.
I suppose that rather than get into Github versus Mercurial and which Github (Googel versus other).. a general policy should be encouraged.
So how about this ?
If you have an evolving Propeller Project, feel free to use whatever you desire as a project management workspace to encourage participation.
And whenever you reach a stage in the project development where it can be considered a stable object, post a copy to OBEX with annotation of your access elsewhere for further developments.
That seems like it might work for me without loading Parallax with administrative manhours. Am I naive?
Programmers cannot agree which language is best for any given project. If they do, or have have one forced on them, they will fight over where to put the brackets and how much indenting to put in the code. Then there is the editor wars, the framework wars, the license wars etc etc.
Use of a source code management system or not, or which one, is another topic of much argument.
Perhaps it's better to just let people free to do whatever they like how they like and try and encourage them to post there completed work where people can find it. Perhaps not even post the work, just a description and a URL.
I like to think that if Parallax put up a github like system people would all flock to it, but they may well not be the case.
This may end up "center of gravity" like other things do.
They may not flock to it Heater, if they've not used it, and that's the rub. Personally, I would use either. Could use both, but that's some learning about Git for me. Not a big deal. I've simply had exposure to Mercurial in a couple of instances in the past and here. Used the older SVN and CVS before that.
One question I asked myself is why I didn't. The answer was the simple Prop Tool, being on Windows and kind of moving around and working with others who were also not using it.
Far as I know, that's still going to be true. If we get a bunch of new users, perhaps more of them would already be using these systems. I don't know.
One obvious center of gravity would be to drop the initial set of stuff into one of those systems and make sure updates happen there and make sure people know how to get them. Curate a few choice things and maybe that starts the ball rolling. Incorporate some work done, like what SRLM has been doing, and that's another nudge...
Anyway, I'm not opposed and think it's a great idea.
"Center of gravity" - Exactly. The question is how to seed this new planet? If Parallax would fire up a github like system or even use github and dump all of OBEX into it then others would be more inclined to follow the example. But that seems to be beyond reach for Parallax at the moment.
So that leaves it to, well, us. Who has the time to commit to such an undertaking?
P.S. Adobe, Facebook, and, oddly enough Google, have a lot of stuff on github as an example of what can be done.
Hmm. No attempt to describe merge conflict resolution in git yet? Must be impossible ;-)
Parallax keeps all of the SimpleIDE Learn libraries in a repository. I can't even imagine using OBEX for constantly adding to or updating that. It also makes it very easy to point forum readers to documentation. Using Doxygen requires the code to have built-in documentation and allows making easy to read html.
Google code allows using git, mercurial, and svn. I've enjoyed the way diffs are done so far. The issues list and wiki pages are also useful.
At least mercurial gives something (useful or not is subjective) better than binary representation. In this case the diff is the added _ in the PUB parameter.
This can't be used for patches, but binary works of course.
sh-3.1$ head -16 ADC.spin
ÿ_{ {
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* g e n e r i c A D C d r i v e r v 1 . 0 *
* A u t h o r : B e a u S c h w a b e *
* C o p y r i g h t ( c ) 2 0 0 7 P a r a l l a x *
* S e e e n d o f f i l e f o r t e r m s o f u s e . *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
} }
C O N
S D F = 6 ' s i g m a - d e l t a f e e d b a c k
S D I = 7 ' s i g m a - d e l t a i n p u t
P U B S i g m a D e l t a ( _ s a m p l e )
c o g n e w ( @ a s m _ e n t r y , s a m p l e ) ' l a u n c h a s s e m b l y p r o g r a m i G
sh-3.1$ hg diff -a ADC.spin
diff -r 1d18c942231b spin/ADC.spin
--- a/spin/ADC.spin Tue Apr 15 11:19:28 2014 -0700
+++ b/spin/ADC.spin Tue Apr 15 12:20:28 2014 -0700
@@ -11,7 +11,7 @@
S D F = 6 ' s i g m a - d e l t a f e e d b a c k
S D I = 7 ' s i g m a - d e l t a i n p u t
P U B S i g m a D e l t a ( s a m p l e )
P U B S i g m a D e l t a ( _ s a m p l e )
c o g n e w ( @ a s m _ e n t r y , s a m p l e ) ' l a u n c h a s s e m b l y p r o g r a m i n a C O G
D A T
sh-3.1$
As I have worked with various source control systems I am agnostic. I am fine with git, mercurial and even svn. Once used to revisions control you might not want to miss it.
This is OK for any developer. But no need for that in the OBEX. PropGCC and simple IDE are things needing source control because multiple developer work together at the same time.
I am not sure this is needed for Propeller Projects. Them are usually single person projects. And if I feel the need to change Kye's Fat_Engine I simply do so. To use it I have to download it anyways and then I have all the source. No need to clone a repo. no need for collaboration. It is MIT licensed or not in the OBEX. I have all the source. I can change what I want and upload it to the OBEX again or not. How can shared ownership help here? How can code get abandoned? Its there. Just download it.
IMHO any developer has the right to keep his code where he wants to. And if he or she decides to put a copy into the OBEX he or she can do so if the MIT license is added. Put links to your repo if you have one.
What is the big deal here to change the OBEX to a Frontend of something else, not under Parallax control? For what need exactly?
Comments
We use Excel spreadsheets to keep track of everything. :blank:
I was about to suggest that there is a way we can all use Github for objects in OBEX without putting any load on Parallax at all.
Simply post a description of the object to OBEX as usual with a link to the github repository.
If necessary include a zip package with nothing but a README file in it than contains a ink to github repo and instructions on how to get the code.
@SRLM Good point. Of course that happens already. It just results in a new OBEX entry. Alternatively Parallax would have to be the maintainers of the code which I gather they don't have time for.
At least github makes it easy for code to become "our code". Just fork it and carry on.
"bifurcate"
I learned a new SAT word - thanks Ken :-)
This is the value right here as shared ownership means less abandoned code. Absndoned code is one of the main issues that CPAN for example deals wih all the time. There are certain CPAN authors who after publishing code just disapear (I might also be guilty of that).
Ken is absolutely 110% correct that if anyONE was to attempt such a thing and then not complete it would be harmful. If this is something that the community feels strongly about I would reccomend the "Herd Model" of management which is the model which Gentoo uses.
Gentoo has 310 developers responsible for the distribution and they're broken into herds like so:
https://www.gentoo.org/proj/en/metastructure/herds/herds.xml
If such as thing were to happen it would be imperative that there be sufficient volunteers such that the burden would not be too great on individuals and so that as people's interests and priorities waxed and waned people could be easily brought on and retired.
I like the idea, but without that kind of structure behind it it could very easily burn people out.
Git does have a feature called "blame". From the documentation:
I've never had a need to use it myself, but it's name sticks with me.
As for the latter problem of merging, I'd imagine that would be solved by some guidelines and community moderation.
Download some existing project: $ git clone [URL]https://github.com/somebody/some-project.git[/URL] Edit some files in there, say a.c and b.c then add your changes to the "staging area" $ git add a.c b.c Commit all changes as a single commit with a commit message $ git commit -m "Added new feature X" Note: That "staging area" thing allows you to group a lot of changes as a single commit where it makes sense, for example when adding a new feature or fixing a single bug that has changes in many files. Also changes to staging are not committed yet so they can be backed out with no change to the commit history. Push your changes back to the upstream repo $ git push If someone else has pushed changes to the upstream repo you can fetch them $ git pullGit can do all that hg can, and more. But if you expect it to work like hg you will get very confused.There are many blogs and tutorials about this on the net of course. github has good instructions.
So how about this ?
If you have an evolving Propeller Project, feel free to use whatever you desire as a project management workspace to encourage participation.
And whenever you reach a stage in the project development where it can be considered a stable object, post a copy to OBEX with annotation of your access elsewhere for further developments.
That seems like it might work for me without loading Parallax with administrative manhours. Am I naive?
I think you are right.
Programmers cannot agree which language is best for any given project. If they do, or have have one forced on them, they will fight over where to put the brackets and how much indenting to put in the code. Then there is the editor wars, the framework wars, the license wars etc etc.
Use of a source code management system or not, or which one, is another topic of much argument.
Perhaps it's better to just let people free to do whatever they like how they like and try and encourage them to post there completed work where people can find it. Perhaps not even post the work, just a description and a URL.
I like to think that if Parallax put up a github like system people would all flock to it, but they may well not be the case.
They may not flock to it Heater, if they've not used it, and that's the rub. Personally, I would use either. Could use both, but that's some learning about Git for me. Not a big deal. I've simply had exposure to Mercurial in a couple of instances in the past and here. Used the older SVN and CVS before that.
One question I asked myself is why I didn't. The answer was the simple Prop Tool, being on Windows and kind of moving around and working with others who were also not using it.
Far as I know, that's still going to be true. If we get a bunch of new users, perhaps more of them would already be using these systems. I don't know.
One obvious center of gravity would be to drop the initial set of stuff into one of those systems and make sure updates happen there and make sure people know how to get them. Curate a few choice things and maybe that starts the ball rolling. Incorporate some work done, like what SRLM has been doing, and that's another nudge...
Anyway, I'm not opposed and think it's a great idea.
"Center of gravity" - Exactly. The question is how to seed this new planet? If Parallax would fire up a github like system or even use github and dump all of OBEX into it then others would be more inclined to follow the example. But that seems to be beyond reach for Parallax at the moment.
So that leaves it to, well, us. Who has the time to commit to such an undertaking?
P.S. Adobe, Facebook, and, oddly enough Google, have a lot of stuff on github as an example of what can be done.
Google code allows using git, mercurial, and svn. I've enjoyed the way diffs are done so far. The issues list and wiki pages are also useful.
I had to create a makefile in my project to convert back and fore - it was a pain.
You are right. Out of the box git thinks UTF-16 files are binary and things like "git diff" don't work.
Yep. That's a bug. The Propeller dev tools should use the universally preferred UTF-8.
At least mercurial gives something (useful or not is subjective) better than binary representation. In this case the diff is the added _ in the PUB parameter.
This can't be used for patches, but binary works of course.
sh-3.1$ head -16 ADC.spin ÿ_{ { * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * g e n e r i c A D C d r i v e r v 1 . 0 * * A u t h o r : B e a u S c h w a b e * * C o p y r i g h t ( c ) 2 0 0 7 P a r a l l a x * * S e e e n d o f f i l e f o r t e r m s o f u s e . * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * } } C O N S D F = 6 ' s i g m a - d e l t a f e e d b a c k S D I = 7 ' s i g m a - d e l t a i n p u t P U B S i g m a D e l t a ( _ s a m p l e ) c o g n e w ( @ a s m _ e n t r y , s a m p l e ) ' l a u n c h a s s e m b l y p r o g r a m i G sh-3.1$ hg diff -a ADC.spin diff -r 1d18c942231b spin/ADC.spin --- a/spin/ADC.spin Tue Apr 15 11:19:28 2014 -0700 +++ b/spin/ADC.spin Tue Apr 15 12:20:28 2014 -0700 @@ -11,7 +11,7 @@ S D F = 6 ' s i g m a - d e l t a f e e d b a c k S D I = 7 ' s i g m a - d e l t a i n p u t P U B S i g m a D e l t a ( s a m p l e ) P U B S i g m a D e l t a ( _ s a m p l e ) c o g n e w ( @ a s m _ e n t r y , s a m p l e ) ' l a u n c h a s s e m b l y p r o g r a m i n a C O G D A T sh-3.1$This is OK for any developer. But no need for that in the OBEX. PropGCC and simple IDE are things needing source control because multiple developer work together at the same time.
I am not sure this is needed for Propeller Projects. Them are usually single person projects. And if I feel the need to change Kye's Fat_Engine I simply do so. To use it I have to download it anyways and then I have all the source. No need to clone a repo. no need for collaboration. It is MIT licensed or not in the OBEX. I have all the source. I can change what I want and upload it to the OBEX again or not. How can shared ownership help here? How can code get abandoned? Its there. Just download it.
IMHO any developer has the right to keep his code where he wants to. And if he or she decides to put a copy into the OBEX he or she can do so if the MIT license is added. Put links to your repo if you have one.
What is the big deal here to change the OBEX to a Frontend of something else, not under Parallax control? For what need exactly?
Confused!
Mike