Keith, You can build for OSX using the source tarball for 0.14.2<http://downloads.basho.com/riak/riak-0.14/riak-0.14.2.tar.gz>. There are plans in the future to create packages for OSX once again. It is currently planned for our next major release.
-Jared On Mon, Jun 6, 2011 at 10:19 AM, Keith Bennett < [email protected]> wrote: > Sean and All - > > In case it helps, the problem manifested on riak 0.14.0 on Mac OS but not > on an Ubuntu VM. > > The most recent version available for download at > http://downloads.basho.com/riak/CURRENT/ for Mac OS was 0.14.0, so that's > what I'm using. I realize that would have been helpful information I could > have provided before, and apologize for not mentioning it -- I forgot that I > had to use an earlier version to run it on the Mac. Are there any plans to > provide more recent versions for the Mac? Or can I build from one of the > other packages? > > Also, Is there a way within Riak::Client or somewhere else in the ruby riak > client gem or riak executables or config files to get the server version > number and possibly OS information? I do see this: > > { % }: ls -1 releases > > 6.Jun.11 12.18 > 0.14.0 > start_erl.data > > ...is this the best way? > > Thanks, > Keith > > On Jun 4, 2011, at 11:26 AM, Sean Cribbs wrote: > > > I already have an issue open on the tracker to deal with some of the > client semantics changes (https://github.com/seancribbs/ripple/issues/166); > it might be broken out into separate issues so it can be completed. > > > > Sean Cribbs <[email protected]> > > Developer Advocate > > Basho Technologies, Inc. > > http://basho.com/ > > > > On Jun 3, 2011, at 6:19 PM, Andrew Thompson wrote: > > > >> On Fri, Jun 03, 2011 at 06:08:06PM -0400, Keith Bennett wrote: > >>> Aphyr & Andrew - > >>> > >>> Thanks for your responses. I'm trying to wrap my head around the > issues you raised, and I must confess it's difficult. Anyway, some > questions for you... > >>> > >>> On Jun 3, 2011, at 5:12 PM, Andrew Thompson wrote: > >>> > >>>> On Fri, Jun 03, 2011 at 02:00:23PM -0700, Aphyr wrote: > >>>>> Riak can't use the vclock for conflict resolution on a fresh object, > >>>>> i.e. one without a vclock. Deletes are writes. You should use get or > >>>>> reload before writing to help Riak sequence your writes correctly. > >>> > >>> If the caller doesn't have a handle to the RObject in the Ruby > framework, or the metadata of an HTTP response, but is only accessing the > data by bucket and key values, is there any way to use reload? And if the > object has been deleted is there any way to use get? > >>> > >>>>> > >>>>> On top of this, Riak has some weirdness around very quick sequences > >>>>> of deletes/writes due, IIRC, to deletes not being tagged with a > >>>>> vector clock. I... think... this will be addressed in an upcoming > >>>>> release. > >>> > >>> I tried inserting a 20 second pause between each read/write, but there > was no change in the behavior. Should it be longer than that? > >> > >> This is scary, it should not be possible to trigger this behaviour with > >> such a large gap. Even 10ms was enough to prevent it in my testing. > >>> > >>>>> > >>>> > >>>> Ah, my favorite bug. This is indeed mostly solved on master by > exposing > >>>> the vclocks for tombstones so they can be cleanly overwritten by the > new > >>>> object rather than merged into a frankenobject that has the metadata > of > >>>> the tombstone but the value of the new object (which is then subject > to > >>>> real deletion). > >>>> > >>>> So the fix for the issue was to add a new type of return value for a > get > >>>> that finds a tombstone, {error, {deleted, Vclock}} instead of always > >>>> returning {error, notfound} on a true notfound or when a tombstone is > >>>> encountered. > >>>> > >>> > >>> That sounds like exactly what I need. Can I simulate that fix in my > Ruby code? Any pointers about that? Any chance we could get that into the > Ruby client? I'd be willing to put a little effort into that, but I don't > really understand the issues well enough yet. > >> > >> I suspect we will want to update the clients to support this, but I > >> don't know of a specific plan to do so yet. I don't know the details of > >> the ruby client enough (or at all) to advise on making changes to it. > >> > >>> > >>>> An example of how to safely delete for all 3 APIs can be found at > >>>> > >>>> https://gist.github.com/965376 > >>>> > >>>> Note the new deletedvclock option. The REST API will always use this > >>>> option on gets and will return a X-Riak-Vclock header along with any > 404 > >>>> that is actually a tombstone. > >>>> > >>>> Some further reading can be found here: > >>>> > >>>> https://issues.basho.com/show_bug.cgi?id=260 > >>>> https://issues.basho.com/show_bug.cgi?id=555 > >>>> > >>>> So, long story short; either upgrade to master and use the > deletedvclock > >>>> option or avoid doing rapid put/delete/put cycles. > >>> > >>> You're suggesting I use mercurial to pull down the HEAD and use that, > right? > >>> > >> > >> git, not mercurial. I don't think we maintain the bitbucket repos > >> anymore, everything has moved to github. > >> > >> Andrew > >> > >> _______________________________________________ > >> riak-users mailing list > >> [email protected] > >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > _______________________________________________ > > riak-users mailing list > > [email protected] > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
