Obex to GitHub thoughts and feedback

Comments

  • xanaduxanadu Posts: 3,322
    edited 2020-05-07 - 23:54:11
    I emailed support about this today. I have to ask... Why not just put a redirect, or note at obex.parallax.com explaining that?

    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.
  • VonSzarvasVonSzarvas Posts: 1,921
    edited 2020-05-08 - 04:43:21
    There was an unexpected technical whoops that caused a timelag between old obex going offline and getting such a redirect. However there should now be directions to GitHub in place.

    Edit: OK... so the obex.parallax.com landing page is still not operational. Lets hope that gets fixed soon. It is coming.
  • There's a certain sequence that should've taken place:

    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
  • VonSzarvasVonSzarvas Posts: 1,921
    edited 2020-05-09 - 08:52:35
    There's a certain sequence that should've taken place:

    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).
  • Ah, got it. Bad timing for me lol, first time I tried to get to obex in over a year.

    Now my website is down : /
  • I don't get it.
    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
  • $ git clone https://github.com/parallaxinc/propeller.git
    Cloning into 'propeller'...
    remote: Enumerating objects: 948, done.
    remote: Counting objects: 100% (948/948), done.
    remote: Compressing objects: 100% (239/239), done.
    remote: Total 14148 (delta 46), reused 896 (delta 28), pack-reused 13200
    Receiving objects: 100% (14148/14148), 96.16 MiB | 1.49 MiB/s, done.
    Resolving deltas: 100% (5522/5522), done.
    Checking out files: 100% (7228/7228), done.
    $ du -sh propeller
    340M    propeller
    
    Probably every YT(?) video you watch causes more traffic than this. And future updates of it ("git pull") only will get the updates.
  • VonSzarvasVonSzarvas Posts: 1,921
    edited 2020-05-09 - 09:27:31
    Thank you for sharing those instructions @yeti

    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....


  • VonSzarvas wrote:
    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
  • Can't you just standardize on LF or CRLF line endings for the whole repository, instead of having to bother with some files having CR endings?

    Git's `add` command has an option to change line endings to whatever you've told it it should be using:
    git add --renormalize
    

    There's a stackoverflow thread with more info here: https://stackoverflow.com/questions/15641259/how-to-normalize-working-tree-line-endings-in-git
  • Sounds like git add --renormalize would provide a quick path to repair the wonky files. I'll pass that tip along.
  • Are you sure that line endings are your issue with git and Propeller source files? In my experience it is the the UTF-16 format used by Propeller Tool for any source file which makes use of its special font glyphs (ie. schematic drawings, fancy borders, etc) that cause grief for 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.
  • actually 8-bit ascii - all the nice things are in the upper 128 bytes.

    Mike
  • LtechLtech Posts: 250
    edited 2020-05-11 - 06:39:05
    I loved the obex stile of date sorting. Posted or edited.

    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
  • yetiyeti Posts: 667
    edited 2020-05-11 - 04:55:18
    Ltech wrote: »
    In GitHub I get one date for all files (posted on github).
    Currently you see lots of same timestamps in e.g.
    .../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.
    Ltech wrote: »
    And every time have to download all the files, not only update new files.
    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.
  • Not trying to hijack the thread, but checking out from github leaves me with just the docs and git support files... No libraries or resources directories. I get errors like this:
    ~/source % git clone https://github.com/parallaxinc/propeller.git
    Cloning into 'propeller'...
    remote: Enumerating objects: 948, done.
    remote: Counting objects: 100% (948/948), done.
    remote: Compressing objects: 100% (239/239), done.
    remote: Total 14148 (delta 46), reused 897 (delta 28), pack-reused 13200
    Receiving objects: 100% (14148/14148), 96.16 MiB | 19.81 MiB/s, done.
    Resolving deltas: 100% (5522/5522), done.
    git: 'lfs' is not a git command. See 'git --help'.
    
    The most similar command is
    	log
    error: external filter 'git lfs smudge %f' failed 1
    error: external filter 'git lfs smudge %f' failed
    fatal: docs/assets/P2_Silicon-1.JPG: smudge filter lfs failed
    warning: Clone succeeded, but checkout failed.
    You can inspect what was checked out with 'git status'
    and retry with 'git restore --source=HEAD :/'
    
    ~/source/propeller % ls -al
    total 24
    drwxr-xr-x    7 altergator  staff   224 May 11 08:28 .
    drwxr-xr-x  242 altergator  staff  7744 May 11 08:28 ..
    drwxr-xr-x   11 altergator  staff   352 May 11 08:28 .git
    -rw-r--r--    1 altergator  staff    65 May 11 08:28 .gitattributes
    -rw-r--r--    1 altergator  staff    90 May 11 08:28 .gitignore
    -rw-r--r--    1 altergator  staff  1069 May 11 08:28 LICENSE.txt
    drwxr-xr-x    6 altergator  staff   192 May 11 08:28 docs
    

    Git status shows
    ~/source/propeller % git status
    On branch master
    Your branch is up to date with 'origin/master'.
    
    Changes to be committed:
      (use "git restore --staged <file>..." to unstage)
    	deleted:    .gitattributes
    	deleted:    .gitignore
    	deleted:    LICENSE.txt
    	deleted:    docs/CNAME
    	deleted:    docs/Gemfile
    	deleted:    docs/Gemfile.lock
    	deleted:    docs/assets/P2_Silicon-1.JPG
    	deleted:    docs/assets/clone.jpg
    	deleted:    docs/assets/fork.jpg
    	deleted:    docs/assets/new_pull_request.jpg
    	deleted:    docs/assets/p2-es_rev_a.jpg
    	deleted:    docs/assets/p2_pinout_large.jpg
    	deleted:    docs/index.md
    	deleted:    docs/readme.md
    	deleted:    docs/software.md
    	deleted:    libraries/community/p1/All/1-wire Routines in Spin/FloatMath.spin
    ...
    ... many more lines of "deleted:  file path"
    ... followed by ...
    	deleted:    resources/readme.md
    
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
    	.gitattributes
    	.gitignore
    	LICENSE.txt
    	docs/
    

    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
  • I think this error is the thing to focus on:
    git: 'lfs' is not a git command. See 'git --help'.
    

    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!
  • VonSzarvas wrote: »
    Does the LFS feature need installing on your PC to be able to download LFS files ?
    Seriously? There is no mention of this requirement in the readme for this repository. Luckily, there is a webpage that helped: https://github.com/git-lfs/git-lfs/wiki/Installation On my system, I needed the following:
    mac OSX
    1. You may need to brew update to get all the new formulas
    2. brew install git-lfs
    3. git lfs install
    


  • Git for Windows seems to include LFS support by default. I think the git install that comes with GitHub's own GUI client does, too.
  • VonSzarvasVonSzarvas Posts: 1,921
    edited 2020-05-11 - 16:41:56
    @dgately
    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.
  • yeti wrote: »
    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.

    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.
  • And if the "tested" new module doesn't run in your context, you will love being able to "rewind" to an earlier version for either hunting the problem causing the different behaviour or just being able to use the old version and provide an URL to it for others too.

    Implementing such a complex collection of software without a VCS (or a versioning or snapshot-ing filesystem) would be just crazy today.
  • Added complexity, perceived or real, does not do much to encourage sharing of code and ideas.

    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.
  • yetiyeti Posts: 667
    edited 2020-05-13 - 03:57:04
    There are likely more users not happy than are posting.
    Finally someone who knows what the silent masses really want.
    Case closed.
  • ChrisGaddChrisGadd Posts: 265
    edited 2020-05-13 - 11:40:06
    I am a user who is not happy, but had refrained from posting.
    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.
  • ChrisGadd wrote: »
    I am a user who is not happy, but had refrained from posting.
    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.
  • Perhaps restore the previous functionality until the current plan is fully tested and ready for prime time. Keep doing the git stuff, but in parallel with OBEX. Or even keep OBEX as the front end and have it run behind the scenes by the git parts. Parallax did not pull/disable the PropTool when other tools were/are in development, why would OBEX be treated any different? This current implementation makes all OBEX users involuntary beta testers.
  • Considering that 99% of the people who used the Obex probably never contributed anything, it would be helpful to streamline the process for those people who will be the primary users of the new version. It is not at all obvious if you have never used a code repository before that instead of "downloading" a project you "clone" it. And the Obex categories and search function were very important for guiding someone who might not know much about what they're doing to what they needed. This is especially important in an environment where basic functionality like serial ports, video, and keyboards all require software to emulate what is fixed hardware on other platforms.

    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 cannot be bothered to learn the new way.

    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
  • As the thread says, thoughts and feedback......

    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.
Sign In or Register to comment.