@"Tracy Allen" said:
I do like the idea of a more accessible, transparent code repository. I'd get back into it. GIT may be great, but my simple mind doesn't get it.
Can I put in another vote for a non-Git solution? I have used lots of different code management systems over the years (and I do grit my teeth and use Git when I have no alternative) but Git has to be the most complex and least intuitive code management system I have ever encountered. It is apparently true that the Git source code refers to itself as "the information manager from hell".
I should hasten to add that this is not entirely Git's fault - it was designed to solve a very specific problem that we simply don't have - i.e. to manage very large numbers of users managing a very large numbers of potentially conflicting code changes and all wanting to commit those changes at the same time. It was apparently written initially to manage Linux kernel code.
Much as Parallax might want to think otherwise, no Propeller code repository is ever going to need that level of complexity, or be required to support that size of developer base. This is very much a case where the KISS principle should apply.
It's fair to say Git is not intended as a repository of finished code, even Linux. If you're not using it for actual development then it's the wrong tool.
I steered clear of Git and Github until recently, when I started contributing to an ESP32forth repository. Rather than having to learn the Git command lines, I use the Github Desktop application in Windows. This is pretty intuitive. Github Desktop is also available for MacOS and may now (or soon) be available for Linux. I like the preview of source code and pdfs on Github - no need to download it to find out if it's relevant. i do update the stuff I publish - especially pdfs, so again Github Desktop makes that trivial. Github is also huge and not likely to go pop anytime soon! --- Just my take on cloud storage. Have a go and see if it reduces the barrier to Git entry low enough.
It's not just finding and downloading individual files, it's also a matter of making it easy for folks to upload and to maintain their contributions, including code and documentation. It doesn't need fancy collaboration tools.
It does need a table of contents with categories and short annotations and a good search engine. Sounds like an OBEX to me. But, who maintains the site?
Or, I believe the @PhiPi forum option could work without a heck of a lot of supervision if the contributors stick to a template that eases search and decision.
Hope I am not out of line here...
I just download the whole sha-bang and got the items for hardware I have on hand or tend to use organized first. It seems a contributors conference call of how to bring groupings together in a coherent manner may be a way to go. It could start with current brand hardware, former brand hardware,(should have store item#) then input devices (A/D), output devices (A/D), specific protocols and competitive, other brand devices broken down in a like manner.....Now I wanted to start with Educational, however that is covered fairly well on company site formatted to current offering. And in saying that what would a store front type setup involve? Can it be linked to GIT to the right code page?
Edit: I've looked more at GitHub from the root a bit more, I see now how much more than OBEX is involved. I use Windoze for all Parallax software and it is limited as far as file organizing. Using folders with catalog number in filename is the best I can do.
Robert Ash
NDBGA
@VonSzarvas said:
As talk of OBEX as been coming up in a couple threads, thought I'd harness the moment to pose a question or two....
Not withstanding that an off-the-shelf and opensource Git-Hub frontend would be nice, or maybe even anything other than the ghastly code-mangling thing we have now. But if we are limited to off-the-shelf... how about the MediaWiki type of solution (ideally one that can also sync to Git-hub, or provide a Git interface along with the webpage file sharing / management) ?
OK, they are not the best looking perhaps. But the point is, they provide an interface for people to register and share code, whilst also contributing articles / snippets and code tips. It could also feature a scrape of the language function lists (etc), like in that last references url above.
There are other opensource wiki systems out there; I've not studied the detail yet to see which I prefer. But maybe some of you already have experience / opinions.
But just generally--- is there an open-source solution out there that would tick all the boxes ?
Be it a git front-end, or some other system all together ?
SUMMARY of thread comments / ideas (in no particular order):
Reactivate old OBEX with moderator controlled sign-up and spam control
MediaWiki type of solution
Custom front-end for GitHub that allows OBEX style access to resources
Wordpress plugin for GitHub backend (does it exist?)
Forums plugin that allows templated categories for code sharing
Include capability/section for full code objects AND handy code snippets/tips
Name and visibility is important.
...
Hi,
is there an update about a better Obex?
I think the Obex as it is now is a hindrance to share code. But shared code is very valuable for Parallax customers and therefore indirectly for Parallax too.
@"Christof Eb." said:
Hi,
is there an update about a better Obex?
I think the Obex as it is now is a hindrance to share code. But shared code is very valuable for Parallax customers and therefore indirectly for Parallax too.
>
Nothing to report as yet.
I'm as eager to get it set up as you are, so if the opportunity arises I will ensure it happens quickly, and with an open process to make sure we include everyone that wants to contribute to target getting the thing just right.
Picking up this thread and task full speed.... (with the intention to have a framework up and running this year, ready for community involvement).
Could I ask what the consensus is regarding code attachments.
Only allow a single zip file for code, and expect that each zip contains every source file to compile/run without needing other libraries.
Allow multiple source files, but all sources must be included.
Allow multiple source files, but common sources can be excluded where they are already in a site "gold standard" driver library- such that when the project is downloaded it pulls the latest driver from the common library. That common library could be populated/maintained by select volunteers along with initial seeding with Parallax drivers.
Something else...
Pros/Cons
zip might be simpler to arrange in the new site, and simpler to ensure versioning doesn't become an issue later, etc..
individual files might allow for online viewing of the code, and thus copy/paste of sections.
BTW... Templated space should be provided for description/usage instructions, connections, etc.. such that a Read.ME might contain. ie. I'm only concerned with the project source attachments in this question, to establish what people think would be useful or necessary.
Edit: ps. Thanks for all the comments so far. Some of you already touched on file-types and I'm 100% including all prior comments!
Nothing stops you from displaying the ZIP contents online, just have to write a bit of extra code to open files inside. ZIP decompression is really fast these days, can just have the server do it on the fly. Just watch out for ZIP bombs.
Any detailed instructions should also be part of the download archive (either inside source comments or separate files), to prevent them from getting lost over time.
On a similar note, all old versions should by default be accessible.
Yes please: 1) Only allow a single zip file for code, and expect that each zip contains every source file to compile/run without needing other libraries.
Yes on 1 assuming the package contents worked when posted,
No on 2, easier to just get the zip and selectively grab what is wanted rather than wondering what I forgot to download.
7734 NO on 3, just thinking on how long it would take to devolve once organizers and "volunteers" loose interest and entropy takes its toll. A single zip that contained a working group of files can act as its own source control so no one has to worry that a "common file" has changed breaking the object of the download. If the originator or other person makes changes, they can upload a zip with an identifier indicating a newer revision. But the contents still work. So, yes on 1.
New public server got setup and migration almost got started...
...but then some unexpected priorities arrived smiling at the door - rev 3 products to deal with unavailable components in the last 3-4 weeks! Joy (not)! Alongside 2 other planned new product versions (actual joy!). On the up side, you'll see lot's of new hardware in the next month or two! We can play "spot the rev" !
The upshot for OBEX is... where I had hoped to "release" at the next (August) P2LF in a couple days, I must concede to the summer chaos and focus on being ready for the September P2LF instead! Early login links will follow soon!
Comments
You can also simply use:
https://minhaskamal.github.io/DownGit/#/home
paste the link to the folder you want to download and it will create a zip file, e.g https://minhaskamal.github.io/DownGit/#/home?url=https://github.com/parallaxinc/propeller/tree/master/libraries/community/p1/All/General MEMS Sensor Model
The UTF issue had been reported quite some time ago already: https://github.com/parallaxinc/propeller/issues/59
(the repo linked there for testing is no longer available though)
Can I put in another vote for a non-Git solution? I have used lots of different code management systems over the years (and I do grit my teeth and use Git when I have no alternative) but Git has to be the most complex and least intuitive code management system I have ever encountered. It is apparently true that the Git source code refers to itself as "the information manager from hell".
I should hasten to add that this is not entirely Git's fault - it was designed to solve a very specific problem that we simply don't have - i.e. to manage very large numbers of users managing a very large numbers of potentially conflicting code changes and all wanting to commit those changes at the same time. It was apparently written initially to manage Linux kernel code.
Much as Parallax might want to think otherwise, no Propeller code repository is ever going to need that level of complexity, or be required to support that size of developer base. This is very much a case where the KISS principle should apply.
Ross.
It's fair to say Git is not intended as a repository of finished code, even Linux. If you're not using it for actual development then it's the wrong tool.
I steered clear of Git and Github until recently, when I started contributing to an ESP32forth repository. Rather than having to learn the Git command lines, I use the Github Desktop application in Windows. This is pretty intuitive. Github Desktop is also available for MacOS and may now (or soon) be available for Linux. I like the preview of source code and pdfs on Github - no need to download it to find out if it's relevant. i do update the stuff I publish - especially pdfs, so again Github Desktop makes that trivial. Github is also huge and not likely to go pop anytime soon! --- Just my take on cloud storage. Have a go and see if it reduces the barrier to Git entry low enough.
Maybe some link in PropTool to download the whole shebang into the Library Folder?
Mike
It's not just finding and downloading individual files, it's also a matter of making it easy for folks to upload and to maintain their contributions, including code and documentation. It doesn't need fancy collaboration tools.
It does need a table of contents with categories and short annotations and a good search engine. Sounds like an OBEX to me. But, who maintains the site?
Or, I believe the @PhiPi forum option could work without a heck of a lot of supervision if the contributors stick to a template that eases search and decision.
Hope I am not out of line here...
I just download the whole sha-bang and got the items for hardware I have on hand or tend to use organized first. It seems a contributors conference call of how to bring groupings together in a coherent manner may be a way to go. It could start with current brand hardware, former brand hardware,(should have store item#) then input devices (A/D), output devices (A/D), specific protocols and competitive, other brand devices broken down in a like manner.....Now I wanted to start with Educational, however that is covered fairly well on company site formatted to current offering. And in saying that what would a store front type setup involve? Can it be linked to GIT to the right code page?
Edit: I've looked more at GitHub from the root a bit more, I see now how much more than OBEX is involved. I use Windoze for all Parallax software and it is limited as far as file organizing. Using folders with catalog number in filename is the best I can do.
Robert Ash
NDBGA
Hi,
is there an update about a better Obex?
I think the Obex as it is now is a hindrance to share code. But shared code is very valuable for Parallax customers and therefore indirectly for Parallax too.
>
Nothing to report as yet.
I'm as eager to get it set up as you are, so if the opportunity arises I will ensure it happens quickly, and with an open process to make sure we include everyone that wants to contribute to target getting the thing just right.
Hi all !
Picking up this thread and task full speed.... (with the intention to have a framework up and running this year, ready for community involvement).
Could I ask what the consensus is regarding code attachments.
Only allow a single zip file for code, and expect that each zip contains every source file to compile/run without needing other libraries.
Allow multiple source files, but all sources must be included.
Allow multiple source files, but common sources can be excluded where they are already in a site "gold standard" driver library- such that when the project is downloaded it pulls the latest driver from the common library. That common library could be populated/maintained by select volunteers along with initial seeding with Parallax drivers.
Something else...
Pros/Cons
BTW... Templated space should be provided for description/usage instructions, connections, etc.. such that a Read.ME might contain. ie. I'm only concerned with the project source attachments in this question, to establish what people think would be useful or necessary.
Edit: ps. Thanks for all the comments so far. Some of you already touched on file-types and I'm 100% including all prior comments!
I would strongly prefer 1)
Nothing stops you from displaying the ZIP contents online, just have to write a bit of extra code to open files inside. ZIP decompression is really fast these days, can just have the server do it on the fly. Just watch out for ZIP bombs.
Any detailed instructions should also be part of the download archive (either inside source comments or separate files), to prevent them from getting lost over time.
On a similar note, all old versions should by default be accessible.
++above
Yes please: 1) Only allow a single zip file for code, and expect that each zip contains every source file to compile/run without needing other libraries.
Yes on 1 assuming the package contents worked when posted,
No on 2, easier to just get the zip and selectively grab what is wanted rather than wondering what I forgot to download.
7734 NO on 3, just thinking on how long it would take to devolve once organizers and "volunteers" loose interest and entropy takes its toll. A single zip that contained a working group of files can act as its own source control so no one has to worry that a "common file" has changed breaking the object of the download. If the originator or other person makes changes, they can upload a zip with an identifier indicating a newer revision. But the contents still work. So, yes on 1.
Little update on the new OBEX...
New public server got setup and migration almost got started...
...but then some unexpected priorities arrived smiling at the door - rev 3 products to deal with unavailable components in the last 3-4 weeks! Joy (not)! Alongside 2 other planned new product versions (actual joy!). On the up side, you'll see lot's of new hardware in the next month or two! We can play "spot the rev" !
The upshot for OBEX is... where I had hoped to "release" at the next (August) P2LF in a couple days, I must concede to the summer chaos and focus on being ready for the September P2LF instead! Early login links will follow soon!