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
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)?
Or, maybe it could be done in #method_missing.
Thomas Johnson
@no-reply
the pass through could work; no idea if there are pitfalls to that, though
would want to make sure not to forget #respond_to_missing
Thomas Johnson
@no-reply
we'd also have to replace the logic in Implementation.extend_object somehow
Gregg Kellogg
@gkellogg
Looks like Rack doesn't support Ruby < 2.2 anymore (see phusion/passenger#1710). This is a development dependency for many gems. We should either lock in an earlier version, or obsolete Ruby < 2.2.
Thomas Johnson
@no-reply
i'm inclined toward obsoleting Ruby 2.2...
oh goodness. I hadn't seen that Rack 2.0 was released
i guess we probably owe some work there
is there release documentation anywhere? the latest news on the Rack website dates from early 2013
Gregg Kellogg
@gkellogg
Travis JRuby failures are pretty annoying. Looks like memory management changes are biting us (see this. Probably easiest to simply mark JRuby in the allow_failures matrix for all gems. See https://travis-ci.org/ruby-rdf/rdf-aggregate-repo/jobs/151974020, for example.
Gregg Kellogg
@gkellogg
Also https://travis-ci.org/ruby-rdf/rdf/jobs/151973839 fails with a similar out-of-memory error.
Thomas Johnson
@no-reply
yeah, ouch.
Thomas Johnson
@no-reply
@gkellogg looks like we never released rdf 2.1 D:
Gregg Kellogg
@gkellogg
Hmm, I thought I had done that. Released now.
Thomas Johnson
@no-reply
thanks!
Thomas Johnson
@no-reply
hmmmm... i think the default #query_pattern implementation is broken... gist incoming
Thomas Johnson
@no-reply
sorry the initial gist is slightly misleading
i've updated it... the issue seems to be RDF::Query::Pattern.new(nil, nil, nil, graph_name: false) === RDF::Statement.new(:s, :p, :o, graph_name: :blah)
which causes default #query_pattern to fail the tests for Queryable
Thomas Johnson
@no-reply
i have a fix at https://github.com/ruby-rdf/rdf/compare/feature/dataset, but it still needs a refactor
i'm tempted to implement a DefaultGraph singleton
Thomas Johnson
@no-reply
@gkellogg: ping
Gregg Kellogg
@gkellogg
Hi
Should we jump on Skype?
Thomas Johnson
@no-reply
yeah, probably
Gregg Kellogg
@gkellogg
Call me when you’re ready
Thomas Johnson
@no-reply