Obex to GitHub thoughts and feedback
System
Posts: 45
This discussion was created from comments split from: is obex down? its been years sense i worked with my develop board. i need a simple hex to serial out.
Comments
The store, forum and various other places still link to obex.parallax.com. A simple redirect or notice explaining it is retired would be extremely beneficial for those that missed the announcement.
Edit: OK... so the obex.parallax.com landing page is still not operational. Lets hope that gets fixed soon. It is coming.
1. First, transfer the files from the old website to the new website.
2. Then, redirect from the old website to the new one.
3. Only then, delete the files from the old website.
This is site management 101 stuff, guys! But even then, I tried to access a spin file from the github site, just as a proof of principle. I drilled down to a specific file, clicked on it, and bringing it up froze my browser. Something is amiss here that needs to be fixed!
Once again, github is not the answer; it sucks! Please put the OBEX on the forum, and your ills and customer complaints will be over.
Thanks,
-Phil
I don't disagree. The time cost continues to be frustrating, and poor service for the customer uncomfortable.
GitHub also has that conversion issue you noted on certain files which have line-ending encodings of CR only, instead of either CR+LF or LF only.
Both these items are being worked on as quickly as possible.
In the meantime, you can get the source code for those troublesome individual files* from GitHub by clicking the "Raw" view button, and then right-click to download the code file.
None of this is ideal, but just to share that Parallax cares about the issues, but are just a little hamstrung with regard getting all the fixes in place as quickly as liked.
Update: * This "Raw" thing only applies to some individual files that won't display as text in the GitHub webpage preview pane. The entire repo could be downloaded without this issue (see below).
Now my website is down : /
How can you get a whole example set out of GitHub ??
Pice by pice in raw?
Please Parallax can you only host the obex read only, it will be a smooth transition waiting GitHub troubles
For @Ltech and everyone, another way is to use the GitHub "Clone or Download" button at the root URL, and then download ZIP. (image attached)
https://github.com/parallaxinc/propeller
Either method gets all the example code downloaded to the local computer, which can then be searched locally.
Some may feel the "entire catalog" download possibility is a key benefit of having the files shared openly and accessibly on GitHub. Another benefit is that a multitude of third party tools and OS integrations can be used (according to the user's own preferences). Taking me a while to learn these new tools though- that's not so great, but I suppose learning new things is always good!
If anyone is stuck finding files, feel free to contact Parallax Support or post requests to this forum and we'll all do our best to help.
BTW:
I've updated my previous post to clarify that it's only the download of certain individual files that need the Raw download (maybe those files shared by users with older Mac OS versions which used CR only as the line ending). Downloading the entire collection of code samples is not impacted. Apologies for any confusion.
I wonder if GitHub could be configured to recognise CR line endings.... hmm....
It would be a simple matter to
1. Download the whole shebang,
2. Use a Perl script to add linefeeds where they're missing, then
3. Replace the whole repository with the repaired fileset.
I can do 1 and 2. Someone with the proper permissions will have to do 3.
-Phil
Git's `add` command has an option to change line endings to whatever you've told it it should be using:
There's a stackoverflow thread with more info here: https://stackoverflow.com/questions/15641259/how-to-normalize-working-tree-line-endings-in-git
For the one Propeller project I worked with in git, I had to downgrade the existing source files to 7-bit ASCII to keep Propeller Tool, PropellerIDE, and git all happy. PropellerIDE converts UTF-16 files created in Propeller Tool into UTF-8 which git likes but then Propeller Tool doesn't. 7-bit ASCII was the common denominator that they all liked and wouldn't get automatically converted by one tool to a format that another wouldn't like. It did mean losing the nice borders around some of the comment blocks but in this particular project, there weren't any schematics that needed to be sacrificed.
Mike
Every while, I look in obex, to see new clever tricks, drivers, examples.
In GitHub I get one date for all files (posted on github). And every time have to download all the files, not only update new files.
example: I can't look for the most actual/modern/updated compact flash driver...
**************************************************************
And don't forget all the forum links to obex are gone again.
If parallax only host the old obex as only read, the forum links can be saved ??? It wil be GREAT.
No permanet task force need. Just rolback and glue obex.
The new items can be shared on github.
**************************************************************
Thank you
.../libraries/community/p1/All. This probably is the date from the migration to GitHub. When updates drip in, they sure will have updated infividual timestamps too.
Wrong.
There are ways to download single directories and if you clone the whole repository, you only need to pull updates later. The later is the main use case. You can even roll back to older files then, e.g. if the newly updated video driver doesn't like your screen but the older one was ok. Just avoid the ZIP download.
Give git a chance. I too definitely do not love git, but being able to use what got the de facto standard for this task (VCS) will be unavoidable soon, or already is.
Git status shows
This is on macOS 10.15.4 (Catalina), which is able to easily clone hundreds of other source repositories from github. Seems that something is broken within the parallaxinc propeller repository.
dgately
Does the LFS feature need installing on your PC to be able to download LFS files ?
LFS is how GitHub stores Large Format Somethings
- something like that!
I've no involvement with the repo, but just took a guess.
I'll share your post back to the Git guru at Parallax and ask if the instructions could be added.
Seems pretty essential to me too! Thanks for sharing.
But that's the fallacy isn't it. The OBEX isn't about version control; it's about making ready-to-run examples available to customers. It's about presenting tested and trusted code to enable a P1 or P2 user add in the missing peripherals as they need.
Implementing such a complex collection of software without a VCS (or a versioning or snapshot-ing filesystem) would be just crazy today.
There are likely more users not happy than are posting. Parallax has just said that after a decade of doing it this way, now you WILL do it that way. Not a user friendly way to go. Maybe the old OBEX should have been just left alone, a disclaimer added to describe its new read-only status and a perhaps a why the change (this may have already been put out, but I probably missed it).
Just my (possibly misplaced) opinion.
Case closed.
With the stay-at-home orders, I'd decided to finally get around to writing a Spin/Pasm driver for an ePaper display and went to upload it to the obex, only to see the note that it was moving to github. After spending a considerable bit of time and effort trying to figure how to upload it there, I managed to submit a pull request, and there it sat for about three weeks. I got a message saying it had been added Monday.
Is that how it's supposed to work? It is not at all user friendly like the old obex.
About the 3 week delay, it's not supposed to work like that in usual circumstances. When I asked last week ago about the status of Obex, Parallax mentioned that the chap who would usually monitor those pull requests had been unavoidably absent, and was catching up this week.
I hope it starts to work a bit more smoothly moving forward. That's certainly the intention as I understand the situation, and I hope your experience (and everyone's) will improve too. I think it's good that you posted your experience though; to help highlight how important a simpler customer front-end would be- or maybe clearer step-by-step instructions in the meantime to make the code database more accessible for all.
I'm sure it will get there- just the unlucky timing of the move seems to have met with some nasty-lurking encoding issues across a huge amount of data that are creating a whole bunch of extra challenges to fix up before anything else can be progressed with.
I think someone also needs to get a handle on what development platform(s) is or are "official" and how example code is arranged to suit the case where N > 1. I understand why Parallax felt the need to embrace C, but this left us with a rift down the middle of the community and with the P2 that rift is more like a crazy spiderweb of fault lines. At the very least there needs to be a landing page explaining why the different platforms are supported and offering suggestions for what to do if the driver you want is there but not for the platform you're actually using. That's a problem that simply did not exist for the entire early history of P1, where it was all Spin and Pasm and even if you used BST that was written so that stuff written for the PropTool would work on it. Things are going to be much more complicated for P2, and that's before you have to figure out how to use a code repository.
I'll only be posting code on the forum. Take it or leave it.
And I'll bet that most others will take the same stance, but without saying so.
just my 2c
These last two posts should get someones attention. Especially Clusso99. Did no one really think of asking the current user community what they thought about making this change? I may be very wrong, but I would guess that a significant number of users of the prop, at least prop1 are hobby level, smaller specialty design/mfr shops or educators (a priority market so we are told) operating at a level of lets download this spin or pasm or zip file of the object I want to fold, spindle, or mutilate to my own needs whatever they may be, and really don't want to have more complexity added to the process. Imagine if your bank decided to make as disruptive a change to their online banking interface.
Parallax is totally correct to gather everything into a version control system, objects are all valuable things for them as a company. Even if MIT licensed. But with all the tools out there PERL, PYTHON and others, an effort to automate extracts from and Parallax controlled commits to their GITHUB from an OBEX functioning customer facing interface should have been considered. Once such a system was ready for testing, invites could have been made quietly or otherwise to specific or any users willing to test the "New OBEX" to make sure it worked just like the old one with perhaps the option to see an objects history.
Keeping the same user interface as current OBEX with GITHUB running the guts and doing it behind the scenes so that the user would not notice a process change would have caused little or no upset while getting the OBEX under version control.
Given the time and patience of those waiting for the P2, waiting for an OBEX that doesn't seem any different but better managed would probably have been worth time to get it done without disruption.