Shop OBEX P1 Docs P2 Docs Learn Events
obex and git hub — Parallax Forums

obex and git hub

pilot0315pilot0315 Posts: 910
in Propeller 2
@cgracey @"Ken Gracey"

I am sorry that you closed the obex. I am sorry that you went to git hub.
I cannot find anything as git hub is too hard to use for the layman.
Please, please find a way to make it more easy to navigate.
Thanks.
«1

Comments

  • Dave HeinDave Hein Posts: 6,347
    A front-end webpage could be created that looks almost exactly like the old OBEX. The front-end webpage would then link to the appropriate GitHub page. However, once in GitHub you would have to contend with the GitHub restrictions to download the code. If each object was in its own repository it could be downloaded in a single zip file.

    However, as it currently exists you either have to copy each file from the "raw" display on GitHub, or download the entire repository that contains all the objects. Maybe there's a way to automate this with some Java script code in a front-end webpage.
  • Cluso99Cluso99 Posts: 18,069
    The current method in GIT is total Smile!
    Unless you are willing to download the whole lot it’s totally useless!
  • DavidZemonDavidZemon Posts: 2,973
    That's an interesting idea... it wouldn't be hard to throw something together that lists all of the contents of the GitHub repo and allows downloading individual "objects" from within it (assuming all objects sit in a standard folder structure. It could run in the browser only and use the GitHub REST API to query the contents of the repo each time the page loads - no server side code necessary.

    I might give this a shot in my free time.

    It will, of course, be READ ONLY. I've NO interest in providing any backdoors to submit new objects, but there's no reason to make acquiring objects as difficult as it is now.
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    While I don't think stuffing everything into one big repo is necessarily the best choice, the problem is definitely not the download size. Like, come on, it's only 98 MB to first clone the entire repository and then a couple K for each new commit you pull - hardly a problem at all.


  • Dave HeinDave Hein Posts: 6,347
    So for a first time user that just wants 100 lines of code we'll just tell them to download a 98 MB repository?
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    Again, not ideal, but again, the download size is not the problem. Infact, I timed cloning the repository from scratch: 
    $ time git clone https://github.com/parallaxinc/propeller.git
Cloning into 'propeller'...
remote: Enumerating objects: 257, done.
remote: Counting objects: 100% (257/257), done.
remote: Compressing objects: 100% (198/198), done.
remote: Total 15192 (delta 119), reused 135 (delta 51), pack-reused 14935
Receiving objects: 100% (15192/15192), 96.63 MiB | 8.24 MiB/s, done.
Resolving deltas: 100% (6052/6052), done.
Checking out files: 100% (7325/7325), done.
Filtering content: 100% (16/16), 2.77 MiB | 1.05 MiB/s, done.

real    1m8,740s
user    0m0,046s
sys     0m0,234s
    (and most of the time was spent on file checkout, not downloading...)

    The process of cloning the repository (requiring an installed git client) and finding the right file within are the end-user problems IMO.

    Could be solved by integrating into propeller tool/spin - have a button to "refresh object library" or smth and it does it all automagically and you could just start using the lastes community objects (ideally with some way of giving it a commit reference (i.e. a tag or SHA1) so when the object gets updated your code doesn't magically break)
  • localrogerlocalroger Posts: 3,451
    Wuerfel, not everybody has a cable modem. On a DSL link that download will take ten minutes. On dialup, which is still the only option for many rural people, it will take hours. It is a ridiculous bar to ask n00bs to clear when you are trying to teach them how to use your product.
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    Yeah, dialup users might have a problem with that.

    Splitting the repository into a bunch of seperate ones (maybe one per category, aswell as per-project if the author wishes to maintain their own repository) and then submodule-ing them into the main one would fix that and the organization problem, but submodules are a major PITA in Git, so, yeah, idk.
  • pilot0315pilot0315 Posts: 910
    @yeti

    https://github.com/parallaxinc/propeller/archive/master.zip

    I followed this and only found p1 is there one for p2?

    Still looking.

    Thanks
  • pilot0315pilot0315 Posts: 910
    edited 2020-07-28 19:02
    Stumbled on this path to the obex:
    https://github.com/parallaxinc/propeller/tree/master/libraries
    Click on community.
    Click on P1 or P2.
    Click on all.

    Problem? It does not seem that all of the obex for P1 made it there.
    Still what a pain. Took me hours to find this.

    There just seemed to be more than what is on git hub than the obex.


  • Ken GraceyKen Gracey Posts: 7,392
    It might take us a little time to get this all straight. I understand and share your concerns.

    Keep in mind that while we liked OBEX, it was a ticking time bomb we were not able to maintain. As our company was reduced in size to finish Propeller 2 some sacrifices had to be made - one of them was the loss of two staff that had this Drupal experience earlier this year.

    It takes a front page to evolve the presentation to be more useful. This is @"Jeff Martin" 's job at Parallax.

    We'll get there; just stick with us!

    Ken Gracey
  • David CarrierDavid Carrier Posts: 294
    You can browse an archive of the old Object Exchange version at: https://web.archive.org/web/20191128081713/http://obex.parallax.com/

    I usually search a downloaded copy of what's on Github. It's available here: https://github.com/parallaxinc/propeller/archive/master.zip

    I usually search with grep and locate, but those tools aren't easy to get working in WIndows. Instead, try this open-source WIndows locate GUI: https://locate32.cogit.net/

    The obex search engine wasn't that great to start with, so Github's search engine should at least be able to match it. If you have the repository open, you can enter search terms into the box in the top left corner, then click on 'In the repository', to only search the Propeller libraries.

    All of the old P1 projects should be on Github, and they are all in the 'All' folder you mentioned. The category folders just link to the project's folder in 'All', so only one set of files needs to be maintained.

    ― David Carrier
  • pilot0315pilot0315 Posts: 910
    @David Carrier
    Thanks.

    Been a while.
  • ke4pjwke4pjw Posts: 1,155
    Sounds like submodules need to be implemented. Each object being a submodule. Larger programs can reference the submodules.

    https://gist.github.com/gitaarik/8735255
  • ElectrodudeElectrodude Posts: 1,657
    What if Parallax started a Github organization exclusively for OBEX projects, and put every object in its own repository owned by that organization? That would enable individual project developers to have direct control over their own objects, without having to use pull requests to moderate who has access, but it would also avoid the problem of having all of Parallax's other repos being drowned out by zillions of OBEX objects.
  • DavidZemonDavidZemon Posts: 2,973
    Hm... I'm sorry to say this can't be done entirely in the browser. The GitHub API does not provide any single endpoint to retrieve a complete directory listing of a repository, and to get a recursive directory listing, you will VERY quickly exceed the anonymous rate limit of only 50 requests per hour (a single request for every folder in the repository).
    So the only reasonable way to stand up a read-only OBEX for quickly downloading objects is to have an app running server side which can clone the repository and then the browser can retrieve the directory listing from this custom app. I'll play around with this a bit... shouldn't be hard.

    @"Ken Gracey", is this something Parallax would be interesting taking over if I do the initial development? If so, reach out to me... I'd like to write it in whatever language you guys would prefer, that way it has a better chance of being maintained.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2020-08-04 21:04
    @pilot0315, whatcha think? https://obex.zemon.name/

    Lots more work to make this more usable. Known issues:

    1. Can't download objects from the symlink'd directories. You can navigate the list of symlinks, but to download, you must find the object under "All"
    2. Nothing is configured to auto-update the server-side Git repository
    3. It would be nice if you could view individual files in the browser
    4. It would be nice to display a loading bar while a ZIP is being prepared (it can take a long time if you try to download all P1 libraries, for instance)
    5. There's definitely some sys-admin related stuff that needs cleaning up.
  • Ken GraceyKen Gracey Posts: 7,392
    DavidZemon wrote: »
    @"Ken Gracey", is this something Parallax would be interesting taking over if I do the initial development? If so, reach out to me... I'd like to write it in whatever language you guys would prefer, that way it has a better chance of being maintained.

    We like where you're headed and would consider adopting it as our own. I don't think we'd be too effective doing more development around the concept once it's near-done, though. Taking over other people's work seems sensible, but sometimes this causes us some time loss we just can't afford.

    I suggest you continue on, we watch the feedback/acceptance, and make a decision at the right time.

    We're appreciative of what we're seeing here, just to be clear. It is truly wonderful to have the community step in to help us get this effort up and running. Therefore, thank you!

    Ken Gracey
  • DavidZemonDavidZemon Posts: 2,973
    Ken Gracey wrote: »
    DavidZemon wrote: »
    @"Ken Gracey", is this something Parallax would be interesting taking over if I do the initial development? If so, reach out to me... I'd like to write it in whatever language you guys would prefer, that way it has a better chance of being maintained.

    We like where you're headed and would consider adopting it as our own. I don't think we'd be too effective doing more development around the concept once it's near-done, though. Taking over other people's work seems sensible, but sometimes this causes us some time loss we just can't afford.

    I suggest you continue on, we watch the feedback/acceptance, and make a decision at the right time.

    We're appreciative of what we're seeing here, just to be clear. It is truly wonderful to have the community step in to help us get this effort up and running. Therefore, thank you!

    Ken Gracey

    Glad to hear. Do you have a language preference? Right now, it's Java because that's my native tongue. But I could easily port it to Python. Rust is a bit tempting, just because it would be a fun learning experience. C is out of the question :mrgreen:
  • Cluso99Cluso99 Posts: 18,069
    @DavidZemon
    This makes it much better and easy to download a file, so many thanks :)
  • dgatelydgately Posts: 1,630
    David,

    Could the files named "README.md" be viewable on the page, rather than just downloadable? That way an interested party could get a description and usage before downloading.

    dgately
  • DavidZemonDavidZemon Posts: 2,973
    dgately wrote: »
    David,

    Could the files named "README.md" be viewable on the page, rather than just downloadable? That way an interested party could get a description and usage before downloading.

    dgately

    Yep, absolutely. Already on the todo list ;)
  • pilot0315pilot0315 Posts: 910
    @DavidZemon

    Looks like a good idea coming together. Thank you all for understanding. Looks like I was not the only one.
    Thanks
    Martin
    I took a quick look. Will look again shortly.
  • Ken GraceyKen Gracey Posts: 7,392
    DavidZemon wrote: »
    Ken Gracey wrote: »
    DavidZemon wrote: »
    @"Ken Gracey", is this something Parallax would be interesting taking over if I do the initial development? If so, reach out to me... I'd like to write it in whatever language you guys would prefer, that way it has a better chance of being maintained.

    We like where you're headed and would consider adopting it as our own. I don't think we'd be too effective doing more development around the concept once it's near-done, though. Taking over other people's work seems sensible, but sometimes this causes us some time loss we just can't afford.

    I suggest you continue on, we watch the feedback/acceptance, and make a decision at the right time.

    We're appreciative of what we're seeing here, just to be clear. It is truly wonderful to have the community step in to help us get this effort up and running. Therefore, thank you!

    Ken Gracey

    Glad to hear. Do you have a language preference? Right now, it's Java because that's my native tongue. But I could easily port it to Python. Rust is a bit tempting, just because it would be a fun learning experience. C is out of the question :mrgreen:

    I'm asking @"Jeff Martin" to jump in and take a look. I'd think Python would be the preferred choice. If we use this tool we'd hope not to have to maintain any code at all in the future.

    Ken Gracey
  • DavidZemonDavidZemon Posts: 2,973
    edited 2020-08-05 22:50
    Ken Gracey wrote: »
    DavidZemon wrote: »
    Ken Gracey wrote: »
    DavidZemon wrote: »
    @"Ken Gracey", is this something Parallax would be interesting taking over if I do the initial development? If so, reach out to me... I'd like to write it in whatever language you guys would prefer, that way it has a better chance of being maintained.

    We like where you're headed and would consider adopting it as our own. I don't think we'd be too effective doing more development around the concept once it's near-done, though. Taking over other people's work seems sensible, but sometimes this causes us some time loss we just can't afford.

    I suggest you continue on, we watch the feedback/acceptance, and make a decision at the right time.

    We're appreciative of what we're seeing here, just to be clear. It is truly wonderful to have the community step in to help us get this effort up and running. Therefore, thank you!

    Ken Gracey

    Glad to hear. Do you have a language preference? Right now, it's Java because that's my native tongue. But I could easily port it to Python. Rust is a bit tempting, just because it would be a fun learning experience. C is out of the question :mrgreen:

    I'm asking @"Jeff Martin" to jump in and take a look. I'd think Python would be the preferred choice. If we use this tool we'd hope not to have to maintain any code at all in the future.

    Ken Gracey

    Any software needs, at very least, dependencies updates to patch security vulnerabilities. And then of course, as dependencies get updates, APIs break... you know.
    But that sounds good. I'll look into migrating to Python.
  • AwesomeCronkAwesomeCronk Posts: 1,055
    edited 2020-08-06 14:00
    Sorry if this has been said before, but what if the GitHub OBEX was not a repository owned by parallaxinc, but an account, with individual repositories for each project? In theory, you could even have a p1 account and a P2 account. This would allow us to pull individual objects directly with a single git clone or through the GitHub website. (And it would be way nicer both to folks with small hard drives and to those who really don’t want all of the OBEX.)

    The individual sections, ie sensors, data, etc., could be added into the repository names, like this:
    Human Interface - Heartbeat
Human Interface - Microphone to Headphones
Human Interface - Microphone to VGA
Human Interface - 74C922 Keypad Driver
Human Interface - 74C92X Keypad Buffer and Driver

Math - General MEMS Sensor Model
Math - BUST Non Randomness
Math - 3DfixOLED
Math - AES-128 in PASM

    A quick email to Parallax with either a link to your own repository or a zip file containing your project would be sufficient to get it on the OBEX.
  • AwesomeCronkAwesomeCronk Posts: 1,055
    Oops! I just reread this thread and realized that electrodude already said something nearly identical!
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    As far as I can tell, you're doing a full dynamic web server to essentially serve data that only needs to update when the git remote is updated - have you considered just pre-generating the page(s) every time it updates? That seems more maintainable to me.
  • DavidZemonDavidZemon Posts: 2,973
    Wuerfel_21 wrote: »
    As far as I can tell, you're doing a full dynamic web server to essentially serve data that only needs to update when the git remote is updated - have you considered just pre-generating the page(s) every time it updates? That seems more maintainable to me.

    Your summary is right. But this is what I know... It's the only kind of webapp I've ever built. I'd hardly know where to begin if I went about it your way.
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    edited 2020-08-06 20:43
    Well, you just write some code to generate the HTML files you need and then hook that into some sort of CI job that pushes them and all the static files you need onto the web server.

    But I get you, when you know how to use a hammer, everything is a nail. (I'm still using Allegro 4 for simple graphics stuff on PC because that's what I always used, despite it being a buggy mess even on Win7...)
Sign In or Register to comment.