Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 21:32
    gkellogg commented #393
  • Jan 31 2019 10:29
    typhoon2099 commented #393
  • Jan 31 2019 10:20
    typhoon2099 opened #393
  • Jan 29 2019 19:14

    gkellogg on develop

    Guard against nil bindings in s… (compare)

  • Jan 29 2019 02:10

    gkellogg on develop

    Have solution iterators also re… (compare)

  • Jan 29 2019 00:59

    gkellogg on develop

    Fix check for variable in Patte… (compare)

  • Jan 29 2019 00:38

    gkellogg on develop

    Add `Solutions#dup`. Add `existential` modifier to v… (compare)

  • Jan 26 2019 23:12

    gkellogg on develop

    Dup components of a URI to avoi… Calculate pattern cost based on… (compare)

  • Jan 24 2019 16:11
    coveralls commented #392
  • Jan 24 2019 16:08

    gkellogg on develop

    Implement marshaling methods to… (compare)

  • Jan 24 2019 16:08
    gkellogg closed #392
  • Jan 24 2019 15:50
    cjcolvar opened #392
  • Jan 24 2019 15:27
  • Jan 21 2019 21:56

    gkellogg on develop

    Update Repository to remember s… (compare)

  • Jan 20 2019 23:45

    gkellogg on develop

    Fix bug in NTriples::Reader.une… (compare)

  • Jan 20 2019 00:12

    gkellogg on develop

    Change N-Triples literal output… (compare)

  • Jan 19 2019 22:54

    gkellogg on develop

    Single quote (') was missing fr… (compare)

  • Jan 16 2019 23:43

    gkellogg on develop

    Make query validation optional.… Better support for non-distingu… Test solutions bindings. (compare)

  • Jan 15 2019 20:09
  • Jan 01 2019 20:18

    gkellogg on 3.0.9

    (compare)

Thomas Johnson
@no-reply
:cool:
I'll be in touch when my flights are all settled for the SWIB thing
Arto Bendiken
@artob
Sounds good.
If that'd be Nov 26, that's Thanksgiving, right? I'm sure we can scare up a turkey or two... ;)
Thomas Johnson
@no-reply
it is, yes. I'm an iconoclast and usual cook duck or goose on turkey day, though.
not really a turkey fan
Arto Bendiken
@artob
Well, you're coming to the city of hohemian iconoclasts, so you're good. :)
Gregg Kellogg
@gkellogg
I suppose we have most of the components except a full-featured, Rack-based SPARQL endpoint implementation?
Note that the sparql gem does include rack/sparql and sinatra/sparql, and that there is a spec implementation there.
I also published a Micro Sparql gem a while ago that essentially does this, as I used it for a demo.
I'm giving a talk in about 4 weeks in Minneapolis on RDF.rb, so we can share resources.
Thomas Johnson
@no-reply
@gkellogg yeah, I'll be there in Minn.
Arto Bendiken
@artob

ruby-rdf IRC logs available at: http://irclog.whitequark.org/ruby-rdf/

Gregg Kellogg
@gkellogg
Thanks for setting that up, pretty cool!
Tony Bargnesi
@abargnesi
Hey all! I'm curious to get some feedback on an in-process Apache Jena connector for RDF.rb on JRuby (either 1.7 or 9k series). The documentation is minimal (only a small README), but it is pretty usable already. https://github.com/abargnesi/rdf-jena
Tony Bargnesi
@abargnesi
You can run "rspec spec/repository_spec_jena.rb" to run the RDF::Repository spec tests.
Gregg Kellogg
@gkellogg
@abargnesi that's great! I was just talking with someone the other day about how useful Jena adaptors for parsing/serializing as well as a repository would be. I'll take a look shortly.
Tony Bargnesi
@abargnesi
@gkellogg thanks! feel free to open issues as you see them.
Gregg Kellogg
@gkellogg

@abargnesi a Gemfile would probably be a good idea. I got an error running with jruby-9.0.3.0:

org/jruby/RubyKernel.java:939:in require':LoadError: JRuby ext built for wrong Java version incom.github.rdf_jena.JenaRepositoryService': java.lang.UnsupportedClassVersionError: com/github/rdf_jena/JenaRepositoryService : Unsupported major.minor version 52.0

[rdf-jena] java -version java version "1.7.0_10"
That's the default version of Java on Mac El Capitan
Tony Bargnesi
@abargnesi
Good catch! I will look at how to best declare the java language version. Apache Jena 3+ requires Java 8.
Tony Bargnesi
@abargnesi
@gkellogg Included checks for JRuby and Java 8 at install-time. See abargnesi/rdf-jena#1.
Tony Bargnesi
@abargnesi
Pushed 0.2.1 version to rubygems.
Gregg Kellogg
@gkellogg
@no-reply still need to figure out what’s causing stack-overflows and other things in SPARQL::Client::Repository and RDF::Mongo. Any thoughts?
Thomas Johnson
@no-reply
@gkellogg i don't, but I haven't looked properly yet
will try to do that this afternoon
Gregg Kellogg
@gkellogg
:+1:
Gregg Kellogg
@gkellogg
rdf-raptor is not happy and failing many specs now, Perhaps someone has time to look into it. @dwbutler?
Thomas Johnson
@no-reply
I reorganized and pushed up some old benchmarking work: https://github.com/ruby-rdf/rdf-benchmark
you need to manually download the Berlin generator to get this working for now, but I figure a Rake task is the eventual goal.
just wanted to get it public in case I find time to work on it along with other RDF::Repository stuff
Gregg Kellogg
@gkellogg
:+1:
Thomas Johnson
@no-reply
I'm working on a blog post on the HAMT Repository and had the chance to give some thought to thread safety in the process.
I wonder whether you two think it would be worth reworking RDF::Repository slightly to synchronize transactions out of the box? Something like:
  • assign @mutex at initialization
  • wrap the relevant parts of SerializableTransaction#execute in repository.mutex.synchronize { ... }.
Thomas Johnson
@no-reply
I think it's pretty workable, but I'm trying to decide whether it's appropriate for the default, or whether it shouldn't be a specializedSynchronizedRepository or something
Thomas Johnson
@no-reply
as a proof of concept: ruby-rdf/rdf@c8080e2
I suspect if we benchmark it, we'll find this version is substantially slower for typical single threaded use cases
Gregg Kellogg
@gkellogg
I don't think we've claimed in the past that RDF.rb is thread-safe, but it's a reasonable direction to go. I do think that we'd want to leave details to an implementation, if possible. Our default in-memory implementation should be thread-safe, if we go in this direction.
We'll need to scour other parts of the code base to look for similar issues, but most of them would involve updating repositories and querying.
Thomas Johnson
@no-reply
@gkellogg :+1:.
yeah, i don't think we have made any claims toward thread safety, and I consciously avoided putting it in scope for the transaction work initially. Still, 2.0.0 does get us pretty close.
Thomas Johnson
@no-reply
my sense is that benchmarking work is still the next step; it will be hard to gauge the locking overhead without that
Thomas Johnson
@no-reply
it invalidates the MRI method cache every time Repository.new is called
Gregg Kellogg
@gkellogg
Can we just not do if self.class.equal?(RDF::Repository) && !respond_to?(Implementation)?