by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Tony Bargnesi
@abargnesi
:)
I think automation can be part of it, but I like interpreting the changes for the users of the project.
It can be a pain though, and it's usually after the fact.
I've seen some uses of structured git commits to that end.
Tony Bargnesi
@abargnesi
@nbargnesi Remember the desire to release the built belmgr app? It seems you can do it with BASE_URL=http://localhost:8080/api gulp build export.
Serving the export/ directory provides a really snappy search page.
But the welcome and search page are the only routes available. The other pages 404.
@wshayes Any thoughts?
Nick Bargnesi
@nbargnesi
Yes, and releasing a built app would make things simpler. If we default BASE_URL to window.location scheme + host + '/api' and support changing it dynamically through the interface, it will be doable. Relying on BASE_URL during the build process is too fragile to support the build/export artifacts.
Tony Bargnesi
@abargnesi
That's a great feature, but I think there is value releasing a built web application that defaults to http://localhost:9292/api. Out-of-the-box experience with belmgr and openbel-api.
More eyeballs
Ok I was able to run it fully by piecing together artifacts of gulp build and gulp export. That should work.
Nick Bargnesi
@nbargnesi
Okay then, just include the first part with reasonable BASE_URL defaults. Could we support an out-of-the-box experience with a single gem approach? E.g., instaling openbel-platform would bring in openbel-api and a belmgr built with those defaults.
I think I see what you're saying. API defaults to http://localhost:9292/api now, defaulting the belmgr build BASE_URL to the same would give the out-of-the-box experience. Yes, that works. As long as no one tries to use a build artifact for anything other than that deployment.
Tony Bargnesi
@abargnesi
I think so. We can certainly package up the web application files in a single sub directory. Then we could serve them up through sinatra as static files.
At a different path.
Maybe belmgr could read the base url from the OpenBEL API configuration file. Use the configuration file as a central point of configuration data.
Puma could be setup with this configuration as well. That would get us towards needing only a rack-compliant http server once we can run on other rubies.
Nick Bargnesi
@nbargnesi
Then let's build artifacts for stable branches and releases on the build server. We'll publish the release artifacts to GitHub too. That supports the out-of-the-box experience and gem, Puma, etc, can use them directly. We do still need a reasonable default BASE_URL if none exists though. And the window.location scheme works well for this. If this sounds good, I'll write it up.
Tony Bargnesi
@abargnesi
Great idea! Sounds good to me.
I'll publish the build that I have now for 0.2.0. And I'll log a bug for "gulp build export" usage.
Nick Bargnesi
@nbargnesi
Can I link this discussion to the issue?
Tony Bargnesi
@abargnesi
No, don't think so. Gitter's API is mostly crap.
Paste it in?
Nick Bargnesi
@nbargnesi
Will do.
Woohoo! The timestamp to the right can serve as a link.
+1 gitter
Tony Bargnesi
@abargnesi
Super cool and impressive.
William Hayes
@wshayes
:point_up: March 16, 2016 9:58 AM https://www.linkedin.com/groups/4257384/members/admins Ted and Diane are the group admins. I’ll contact Ted and ask for you and I to be added.
Nick Bargnesi
@nbargnesi
Nice use of linking there :)
Tony Bargnesi
@abargnesi
Thanks william, thanks for the conversation reminder ;)
Nick Bargnesi
@nbargnesi
@abargnesi OpenBEL/belmgr#52
Tony Bargnesi
@abargnesi
@nbargnesi Attempted class inheritance comparison in OpenBEL/parsers@db85d81
PTAL
Tony Bargnesi
@abargnesi
@all I posted an early bel_parser (version 1.0.0.alpha.1) to RubyGems. https://rubygems.org/gems/bel_parser
Tony Bargnesi
@abargnesi
Install with gem install bel_parser --pre. You can then type BEL 2.0 terms into the console using the bel2_termcheck command.
Tony Bargnesi
@abargnesi
@wshayes Looked into PSI-MOD protein modification ontology (http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/mod/data/PSI-MOD.obo.xml). The root term is named "protein modification".
Seems to jive with how you named it.
William Hayes
@wshayes
Looking at the RDF Schema tutorial https://www.w3.org/2007/02/turtle/primer/#L3514
Based on the RDF Schema notes from the Primer - the following indicates hasVariant’s subject must be an instance satisfying all of the listed Abundances rather that one of the listed Abundances. It also indicates that the RDF Schema’s functionality is based on how it is used. So @abargnesi - would you rather have the listed options as below or just list bel:Abundance even though CompositeAbundance can’t be used with hasVariant?
belv:hasVariant rdf:type rdf:Property ;
    rdfs:domain belv:GeneAbundance ;
    rdfs:domain belv:RNAAbundance ;
    rdfs:domain belv:MicroRNAAbundance ;
    rdfs:domain belv:ProteinAbundance .
Nick Bargnesi
@nbargnesi
@abargnesi I'd like to get your feedback on nbargnesi/bel-parser@2df027c when possible
basic complete/incomplete AST generation for Identifiers
Tony Bargnesi
@abargnesi
@nbargnesi Ok! I reviewed things at nbargnesi/bel-parser@2df027c
I need to enable gitter reporting for bel_parser, will do that now.
Ok, github activity enabled on chat for bel_parser.
Tony Bargnesi
@abargnesi
@nbargnesi if you get the chance, test out https://reviewable.io for code reviews. You can test out without authorization to your organization, which is great. The interface is pretty busy, but it has some nice features. (1) You can review and add a whole bunch and then Publish it as one "review" instead of a bunch of little comments. (2) Diff editor mixes comments with code fairly nicely. (3) Comment resolution status which seems like an interesting way to democracize.
Still can't attach a patch file to a comment.