Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Bruno Bonacci]

Hi Max,

That's a interesting library thanks.

Does the library guarantee monotonically increasing IDs? Eg protection 
against clock reset and other clock fluctuations?

Another thing I've noticed is that you are using (System/currentTimeMillis) to 
get the wall clock on every generation.

(System/currentTimeMillis) causes a low level system call which in turn 
causes a context switch.

Maybe one way to improve could be use a initial (System/currentTimeMillis) 
on the first init! and then
use System/nanoTime to calculate the time elapsed from the init.
The advantage would be that System/nanoTime runs in the UserSpace (not 
Kernel Space) and it doesn't require
a system call (so no context switch).

This could really help the case of a bulk production of IDs and any other 
burst situation.

Bruno 


On Friday, June 3, 2016 at 4:40:26 PM UTC+1, Max Countryman wrote:
>
> Hi Mark,
>
> I haven’t done any benchmarking comparing Flakes to UUIDs. However the 
> primary benefit of flake IDs, over a traditional UUID, e.g. UUID-1, is 
> flakes do not require coordination (i.e. to avoid clock-skew and duplicate 
> IDs), provide k-ordering (UUID-1’s bit ordering breaks this), and use the 
> standard Unix epoch. It would be interesting to compare performance, but 
> the features of flakes are certainly their primary selling points.
>
>
> Max
>
> On Jun 2, 2016, at 20:38, Mark Engelberg  > wrote:
>
> This is interesting.  Is it faster than uuid for generation and/or 
> comparing for equality?
>
> On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman 
> > wrote:
>
>> Hi,
>>
>> I’m happy to announce a new release of Flake, the decentralized, 
>> k-ordered unique ID generator.
>>
>> Flake 0.4.0 includes a number of important breaking changes, but by far 
>> the most important is dropping `generate` in favor of `generate!` which now 
>> returns a ByteBuffer. Previously `generate` returned a BigInteger, however 
>> this arbitrarily limits how an application can handle IDs and goes against 
>> the spirit of the Erlang implementation. In order to maintain backwards 
>> compatibility, a helper `flake->bigint` was added to the core namespace. 
>> Applications which already consume flakes should update their calls to 
>> `generate` so they are `generate!` and wrap them with `flake->bigint` if 
>> BigIntegers are desirable or already used.
>>
>> Github: https://github.com/maxcountryman/flake
>> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md
>>
>> Thanks!
>>
>>
>> Max
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Hi Bruno,

> On Jun 17, 2016, at 03:49, Bruno Bonacci  wrote:
> 
> Hi Max,
> 
> That's a interesting library thanks.
> 
> Does the library guarantee monotonically increasing IDs? Eg protection 
> against clock reset and other clock fluctuations?

Like the Erlang implementation, Flake asks the user to call an init 
function—this writes out the last known timestamp to disk in a separate thread. 
Next time the Flake process is run, it compares the current time to the time 
written to disk and throws an exception if time seems to moving in the wrong 
direction.

Apart from that, the generation function does a comparison of timestamps as 
well, again throwing an exception if the last known timestamp as compared to 
the current is in the future.

These are the same guarantees that Boundary’s implementation seems to make with 
what I believe is a slight improvement on the persisted timer (writing out the 
actual Flake timestamp instead of just an arbitrary interval). 

> Another thing I've noticed is that you are using (System/currentTimeMillis) 
> to get the wall clock on every generation.
> 
> (System/currentTimeMillis) causes a low level system call which in turn 
> causes a context switch.
> 
> Maybe one way to improve could be use a initial (System/currentTimeMillis) on 
> the first init! and then
> use System/nanoTime to calculate the time elapsed from the init.
> The advantage would be that System/nanoTime runs in the UserSpace (not Kernel 
> Space) and it doesn't require
> a system call (so no context switch).
> 
> This could really help the case of a bulk production of IDs and any other 
> burst situation.

I really like this idea. I’m certainly open to pull requests if you wanted to 
take a stab at it otherwise I may try my hand at making this improvement. :)

> 
> Bruno 
> 
> 
> On Friday, June 3, 2016 at 4:40:26 PM UTC+1, Max Countryman wrote:
> Hi Mark,
> 
> I haven’t done any benchmarking comparing Flakes to UUIDs. However the 
> primary benefit of flake IDs, over a traditional UUID, e.g. UUID-1, is flakes 
> do not require coordination (i.e. to avoid clock-skew and duplicate IDs), 
> provide k-ordering (UUID-1’s bit ordering breaks this), and use the standard 
> Unix epoch. It would be interesting to compare performance, but the features 
> of flakes are certainly their primary selling points.
> 
> 
> Max
> 
>> On Jun 2, 2016, at 20:38, Mark Engelberg > > wrote:
>> 
>> This is interesting.  Is it faster than uuid for generation and/or comparing 
>> for equality?
>> 
>> On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman > 
>> wrote:
>> Hi,
>> 
>> I’m happy to announce a new release of Flake, the decentralized, k-ordered 
>> unique ID generator.
>> 
>> Flake 0.4.0 includes a number of important breaking changes, but by far the 
>> most important is dropping `generate` in favor of `generate!` which now 
>> returns a ByteBuffer. Previously `generate` returned a BigInteger, however 
>> this arbitrarily limits how an application can handle IDs and goes against 
>> the spirit of the Erlang implementation. In order to maintain backwards 
>> compatibility, a helper `flake->bigint` was added to the core namespace. 
>> Applications which already consume flakes should update their calls to 
>> `generate` so they are `generate!` and wrap them with `flake->bigint` if 
>> BigIntegers are desirable or already used.
>> 
>> Github: https://github.com/maxcountryman/flake 
>> 
>> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md 
>> 
>> 
>> Thanks!
>> 
>> 
>> Max
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en 
>> 
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout 
>> .
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en 
>> 
>> --- 
>> You received this message beca

[ANN] core.async 0.2.385

[Alex Miller]

core.async 0.2.385 is now available.

Try it via:  [org.clojure/core.async "0.2.385"]

0.2.385 includes the following changes:

- bump dependency on clojure.tools.analyzer.jvm to latest

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec regression bug for 1.9.0-alpha6

[Alex Miller]

explain-out is now public in master. Further mods may be coming re testing.

On Thursday, June 16, 2016 at 12:52:12 PM UTC-5, Sean Corfield wrote:
>
> I fear you’re missing my point.
>
>  
>
> You can get close to the previous nice value with:
>
>  
>
> (#’s/explain-out (:result (t/check-var  #’ranged-rand)))
>
>  
>
> But that leverages a private function / implementation detail and doesn’t 
> handle :failed-on very nicely:
>
>  
>
> boot.user=> (#'s/explain-out (:result (t/check-var #'ranged-rand)))
>
> val: {:args {:start -3, :end 1}, :ret -5} fails predicate: (>= (:ret %) 
> (-> % :args :start))
>
> :failed-on  :fn
>
>  
>
> When you run-all-tests you get the non-pretty-printed version as a 
> hard-to-read blob of text on stdout and a bare pass/fail map result. Having 
> that text formatted via something like explain-out would be a big help for 
> usability when testing. Having that function exposed publicly would be a 
> nice convenience for other tooling to build on top of clojure.spec.test.
>
>  
>
> We can pass :reporter-fn to check-var / check-fn, but we run-all-tests 
> just passes println in and calls (prn ret) on the result of check-var so we 
> have no control over that output. 
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> On 6/16/16, 6:33 AM, "Alex Miller"  a...@puredanger.com> wrote:
>
>  
>
> You haven't pretty-printed it to look very nice, but I think all of the 
> same information (and more due to shrinking) is still in the check-var 
> output. I don't know of any plan to add what you're asking for beyond 
> what's below.
>
>  
>
> {:result
>
>  {:clojure.spec/problems
>
>   {[]
>
>{*:pred* *(>= (:ret %) (-> % :args :start))*,
>
> *:val* *{:args {:start -1, :end 2}, :ret -2}*,
>
> :via [],
>
> :in []}},
>
>  * :failed-on :fn*},
>
>  :seed 1466016600676,
>
>  :failing-size 4,
>
>  :num-tests 5,
>
>  :fail [(-1 2)],
>
>  :shrunk
>
>  {:total-nodes-visited 5,
>
>   :depth 1,
>
>   :result
>
>   {:clojure.spec/problems
>
>{[]
>
> {:pred (>= (:ret %) (-> % :args :start)),
>
>  :val {:args {:start -1, :end 1}, :ret -2},
>
>  :via [],
>
>  :in []}},
>
>:failed-on :fn},
>
>   :smallest [(-1 1)]}}
>
>
>
> On Wednesday, June 15, 2016 at 2:54:27 PM UTC-5, Sean Corfield wrote:
>
> Given that we now have to use clojure.spec.test to get :ret / :fn tested, 
> we lose the “nice” exceptions explaining the conformance failure:
>
>  
>
> Alpha 5:
>
>  
>
> ;;=> ExceptionInfo Call to #'spec-example.core/ranged-rand did not conform 
> to spec:
>
> ;;=> At: [:fn] val: {:args {:start 8, :end 10}, :ret 7} fails predicate: 
> (>= (:ret %) (-> % :args :start))
>
> ;;=> :clojure.spec/args  (8 10)
>
> ;;=>   clojure.core/ex-info (core.clj:4617)
>
>  
>
> Alpha 6:
>
>  
>
> boot.user=> (t/check-var #'ranged-rand)
>
> {:result {:clojure.spec/problems {[] {:pred (>= (:ret %) (-> % :args 
> :start)), :val {:args {:start -1, :end 2}, :ret -2}, :via [], :in []}}, 
> :failed-on :fn}, :seed 1466016600676, :failing-size 4, :num-tests 5, :fail 
> [(-1 2)], :shrunk {:total-nodes-visited 5, :depth 1, :result 
> {:clojure.spec/problems {[] {:pred (>= (:ret %) (-> % :args :start)), :val 
> {:args {:start -1, :end 1}, :ret -2}, :via [], :in []}}, :failed-on :fn}, 
> :smallest [(-1 1)]}}
>
>  
>
> Are there plans to provide an “explain” equivalent for this?
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googl

clojure.spec - dynamic specs

[Brian Platz]

I'd like to be able to use clojure.spec for input validation where the 
specs are stored in a database using a data structure to represent them.

s/keys and its requirement to use the registry makes this challenging.

I'm able to generate specs dynamically using a workaround like:
(eval (cons 's/and ))

However, I don't see a way of utilizing s/keys in this manner, as the keys 
must first be placed in the registry.

I could register each key also using eval and s/def similarly to my example 
above, however that would eliminate this method's use in a multi-tenant 
environment where one client/instance may have a different spec than 
another.

The following ideas could make this much simpler:
- Allow s/keys to accept a spec to use with each key (i.e. the same format 
used by s/or).
- Allow a *spec-registry* binding, enabling the use of multiple registries

Any other ideas or anything I've missed that would make this use case more 
feasible?






-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec - dynamic specs

[Timothy Baldridge]

In a multi-tenant system, perhaps you should force users to prefix specs
with a namespace they own?

On Fri, Jun 17, 2016 at 1:46 PM, Brian Platz 
wrote:

>
> I'd like to be able to use clojure.spec for input validation where the
> specs are stored in a database using a data structure to represent them.
>
> s/keys and its requirement to use the registry makes this challenging.
>
> I'm able to generate specs dynamically using a workaround like:
> (eval (cons 's/and ))
>
> However, I don't see a way of utilizing s/keys in this manner, as the
> keys must first be placed in the registry.
>
> I could register each key also using eval and s/def similarly to my
> example above, however that would eliminate this method's use in a
> multi-tenant environment where one client/instance may have a different
> spec than another.
>
> The following ideas could make this much simpler:
> - Allow s/keys to accept a spec to use with each key (i.e. the same
> format used by s/or).
> - Allow a *spec-registry* binding, enabling the use of multiple registries
>
> Any other ideas or anything I've missed that would make this use case more
> feasible?
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec - dynamic specs

[Alex Miller]

On Friday, June 17, 2016 at 2:46:37 PM UTC-5, Brian Platz wrote:
>
>
> I'd like to be able to use clojure.spec for input validation where the 
> specs are stored in a database using a data structure to represent them.
>

Why don't you represent them as code loaded by different applications? 
s/form is designed to give you a wire-portable definition of a spec.
 

> s/keys and its requirement to use the registry makes this challenging.
>
> I'm able to generate specs dynamically using a workaround like:
> (eval (cons 's/and ))
>
> However, I don't see a way of utilizing s/keys in this manner, as the 
> keys must first be placed in the registry.
>
> I could register each key also using eval and s/def similarly to my 
> example above, however that would eliminate this method's use in a 
> multi-tenant environment where one client/instance may have a different 
> spec than another.
>
> The following ideas could make this much simpler:
> - Allow s/keys to accept a spec to use with each key (i.e. the same 
> format used by s/or).
>

The independence of attribute specs is a fundamental tenet of spec and this 
will not be changed.
 

> - Allow a *spec-registry* binding, enabling the use of multiple registries
>

The notion of multiple registries is something that's been raised, but Rich 
will have to be the one to comment on that.
 

>
> Any other ideas or anything I've missed that would make this use case more 
> feasible?
>

There might be a function version of s/keys in the future that can take a 
vector of keys.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ANN: ClojureScript 1.9.76

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.76"]

This release brings cljs.spec to parity with Clojure 1.9.0-alpha7. It
addresses an issue with Transit analysis caching, includes fixes for
cljs.spec support under bootstrapped, bumps the Closure library
dependency, and includes other minor fixes and enhancements.

As always feedback welcome!

## 1.9.76

### Enhancements
* CLJS-1648: Getting Source Info into ex-info data for Analysis Errors
* cljs.spec updated to Clojure 1.9.0-alpha7 changes

### Changes
* bump Google Closure Library dep
* AOT cljs.spec nses

### Fixes
* CLJS-1679: Self-host: Incorporate spec tests
* CLJS-1680: Self-host: Don't require items no longer provided by Closure
* CLJS-1654: cljs.spec: var name in s/fdef non-conformance
* CLJS-1655: cljs.spec: conformer docstring indicates :clojure.spec/invalid
* CLJS-1656: Self-host: cljs.spec: speced-vars* fn not resolving
* CLJS-1661: cljs.spec: non-spec'ed fn var printing
* compute read/write opts for transit if possible, handle JSValue
* CLJS-1660: cljs.spec: Always return var from instrument / unstrument
* CLJS-1671: Bad cljs.spec interactive instrumentation session
* CLJS-1664: The filename aux.cljs is a problem on windows.
* CLJS-1667: bad describe* for and-spec-impl
* CLJS-1699: Self-host: s/fdef ns-qualify *ns* name field access

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN Ogre 3.0.0.0-beta1 and future plans for Ogre

[Skott Klebe]

I've really been looking forward to digging into this.
Right now -- and with full awareness of the -beta1 tag on the version 
number -- I'm having a lot of trouble.

First, and seemingly minor, lein install failed on the following - 
.../ogre/test/java/org/clojurewerkz/ogre/gremlin/process/OgreProcessStandardSuite.java:6:
 
error: package org.clojurewerkz.ogre.gremlin.process.traversal.step.filter 
does not exist
import 
org.clojurewerkz.ogre.gremlin.process.traversal.step.filter.OgreHasCheck;

The imported class doesn't appear to be referenced anywhere, so I commented 
it out. 

More significantly, I still can't bring the namespace into the 
REPL, whether I'm working locally or from clojars. require gives me the 
following message:
ClassNotFoundException 
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph 
 java.net.URLClassLoader$1.run (URLClassLoader.java:372)

This, despite the dependency being listed in the pom and a valid 
tinkergraph-gremlin-3.2.0-incubating.jar appearing in my local Maven 
repository.

I started with a fresh chestnut project and just added 
the [clojurewerkz/ogre "3.0.0.0-beta1"] dependency to it.

lein classpath shows gremlin-core and gremlin-shaded in the classpath, but 
not tinkergraph.

I'm baffled. 
Any thoughts?

SK





On Wednesday, June 15, 2016 at 5:47:13 PM UTC-4, Michael Klishin wrote:
>
> Ogre [1] is a Clojure dialect of Gremlin, a DSL for querying and otherwise 
> working with Apache TinkerPop [2] graphs. 
>
> Over the last 6 months or so Ogre maintainers have moved it to target 
> TinkerPop 3.x. 
> Since TinkerPop itself has changed quite a bit and is now an Apache 
> incubator project, 
> Ogre API had to change a few times. 
>
> We are happy to announce that the first milestone release is up on 
> Clojars: 3.0.0.0-beta1. 
> If you are interested in working with TinkerPop from Clojure, please 
> give Ogre a try and 
> let us know how it goes. Since the API is not entirely set in stone 
> yet on either TinkerPop 
> or Ogre end, it may change without a notice. For the same reason we 
> don't have documentation 
> guides updated. We aim to keep this new version of Ogre compatible 
> with TinkerPop 3.x as it 
> evolves and documented well when the API is stable enough. 
>
> I'd like to thank Stephen  Mallette and Andrew Fitzgerald for doing 
> 99% of the work in this release. 
>
> In case you have a specific suggestion or run into a bug or a 
> usability problem, please 
> file an issue on GitHub [1]. 
>
> 1. https://github.com/clojurewerkz/ogre 
> 2. http://tinkerpop.apache.org/ 
> -- 
> MK 
>
> http://github.com/michaelklishin 
> http://twitter.com/michaelklishin 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.