Re: Efficient Predicate Dispatch [was ANN: Logos v0.6]

[Khalid Jebbari]

Oups, I didn't notice that the original message was from 2011...

On Tue, Nov 20, 2018, 5:41 AM Aleš Roubíček  It was promoted to contrib since then.
> https://github.com/clojure/core.match/wiki/Crazy-Ideas and
> https://github.com/clojure/core.match are links you are looking for.
>
> On Monday, November 19, 2018 at 9:50:20 AM UTC+1, Khalid Jebbari wrote:
>>
>> https://github.com/swannodette/match/wiki/Crazy-Ideas
>> 
>>  is
>> 404, as well as https://github.com/swannodette/match
>> 
>>
>> On Thursday, April 14, 2011 at 5:25:48 PM UTC+2, David Nolen wrote:
>>>
>>> When things begin to get recursive you may be on the right track :D
>>>
>>> Initially I was going to implement Nominal Logic Programming for Logos a
>>> la William Byrd's dissertation, but I realized that his implementation
>>> requires pattern matching. All the pattern matching libs I've seen thus far
>>> for Clojure are too naive and too slow. Even more importantly pattern
>>> matching is subsumed by predicate dispatch (CiteSeerX — Efficient
>>> Predicate Dispatching
>>> ).
>>>
>>> Rich Hickey mentioned many moons ago that he'd like to see a predicate
>>> dispatch implementation for Clojure that didn't have the kind of hardwiring
>>> found in the Chambers/Chen paper. He suggested investigating Datalog. After
>>> much reading, I've decided that a runtime in-memory Datalog that handles
>>> dispatching is going to be too slow for many useful scenarios (an efficient
>>> Datalog based on Binary Decision Diagrams might be possible, but this is an
>>> incredibly complex undertaking in itself, meh).
>>>
>>> What we want is Standard MLs efficient compilation from decision
>>> diagrams to switch statements (CiteSeerX — Optimizing Pattern Matching
>>> ).
>>> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has
>>> issues with order among other things (Programming in Standard ML
>>> ).
>>>
>>> What if we allow a logic engine to drive the compilation of the decision
>>> diagram? This would be done by users mapping logic predicates to Clojure
>>> predicate functions. Relationships between predicates can be added to the
>>> logic engine allowing compilation to produce a very efficient decision
>>> diagram. Nothing is hard coded, everything is driven by the kinds of
>>> predicates and relationships between predicates that a user actually cares
>>> about.
>>>
>>> All this is to say that this means Logos needs the ability to load
>>> database of facts, index those facts, and to accept new facts and
>>> relationships and update accordingly. So this going to happen sooner rather
>>> then later.
>>>
>>> I welcome any feedback from anyone who has thoughts on this approach to
>>> implementing predicate dispatch efficiently!
>>>
>>> Some thoughts on what this might look like is evolving here,
>>> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>>>
>>> David
>>>
>>> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen 
>>> wrote:
>>>
 On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi 
 wrote:

> Can it be used as an inference (rule) engine ?


 If you mean in the same way that you can build inference (rule) engines
 in Prolog - I don't see why not.

 However there is a bit of work to be done in order to make building
 efficient rule engines easier:

 * Be able to load a database (aka Clojure collection) of facts
 * Indexing of facts
 * Intelligently use indexed facts

 Currently I'm a bit more interested in exploring type inference (via
 nominal logic) so I'm not sure when exactly I'll get to these, tho I'll
 gladly take patches from people who want such features sooner rather than
 later :)

 David

>>>
>>> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/peL04odPuCo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 

Re: Efficient Predicate Dispatch [was ANN: Logos v0.6]

[Aleš Roubíček]

It was promoted to contrib since then. 
https://github.com/clojure/core.match/wiki/Crazy-Ideas 
and https://github.com/clojure/core.match are links you are looking for. 

On Monday, November 19, 2018 at 9:50:20 AM UTC+1, Khalid Jebbari wrote:
>
> https://github.com/swannodette/match/wiki/Crazy-Ideas 
> 
>  is 
> 404, as well as https://github.com/swannodette/match 
> 
>
> On Thursday, April 14, 2011 at 5:25:48 PM UTC+2, David Nolen wrote:
>>
>> When things begin to get recursive you may be on the right track :D
>>
>> Initially I was going to implement Nominal Logic Programming for Logos a 
>> la William Byrd's dissertation, but I realized that his implementation 
>> requires pattern matching. All the pattern matching libs I've seen thus far 
>> for Clojure are too naive and too slow. Even more importantly pattern 
>> matching is subsumed by predicate dispatch (CiteSeerX — Efficient 
>> Predicate Dispatching 
>> ).
>>
>> Rich Hickey mentioned many moons ago that he'd like to see a predicate 
>> dispatch implementation for Clojure that didn't have the kind of hardwiring 
>> found in the Chambers/Chen paper. He suggested investigating Datalog. After 
>> much reading, I've decided that a runtime in-memory Datalog that handles 
>> dispatching is going to be too slow for many useful scenarios (an efficient 
>> Datalog based on Binary Decision Diagrams might be possible, but this is an 
>> incredibly complex undertaking in itself, meh).
>>
>> What we want is Standard MLs efficient compilation from decision diagrams 
>> to switch statements (CiteSeerX — Optimizing Pattern Matching 
>> ). 
>> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has 
>> issues with order among other things (Programming in Standard ML 
>> ).
>>
>> What if we allow a logic engine to drive the compilation of the decision 
>> diagram? This would be done by users mapping logic predicates to Clojure 
>> predicate functions. Relationships between predicates can be added to the 
>> logic engine allowing compilation to produce a very efficient decision 
>> diagram. Nothing is hard coded, everything is driven by the kinds of 
>> predicates and relationships between predicates that a user actually cares 
>> about.
>>
>> All this is to say that this means Logos needs the ability to load 
>> database of facts, index those facts, and to accept new facts and 
>> relationships and update accordingly. So this going to happen sooner rather 
>> then later.
>>
>> I welcome any feedback from anyone who has thoughts on this approach to 
>> implementing predicate dispatch efficiently!
>>
>> Some thoughts on what this might look like is evolving here, 
>> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>>
>> David
>>
>> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen  wrote:
>>
>>> On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi  wrote:
>>>
 Can it be used as an inference (rule) engine ?
>>>
>>>
>>> If you mean in the same way that you can build inference (rule) engines 
>>> in Prolog - I don't see why not.
>>>
>>> However there is a bit of work to be done in order to make building 
>>> efficient rule engines easier:
>>>
>>> * Be able to load a database (aka Clojure collection) of facts
>>> * Indexing of facts
>>> * Intelligently use indexed facts
>>>
>>> Currently I'm a bit more interested in exploring type inference (via 
>>> nominal logic) so I'm not sure when exactly I'll get to these, tho I'll 
>>> gladly take patches from people who want such features sooner rather than 
>>> later :)
>>>
>>> David
>>>
>>
>>

-- 
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] Clojure 1.10.0-beta7

[Andy Fingerhut]

Not testing results this time, but just a comparison of reflection warnings
in Clojure 1.9.0 vs. 1.10.0-beta7, after adding (set! *warn-on-reflection*
true) to all .clj files in Clojure's source code that did not already have
one.  These were obtained when compiling Clojure using mvn and Oracle Java
1.8.0_192.

A few reflection warnings in clojure/main.clj that were in 1.9.0 are gone
now.  Cool.

One new reflection warning in Clojure 1.10.0-beta7 that was not in Clojure
1.9.0:
 [java] Reflection warning, clojure/reflect/java.clj:183:35 - reference
to field getModifiers on java.lang.Object can't be resolved.

That is line 181 in the original source file here:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/reflect/java.clj#L181

That code doesn't appear to have changed, so only reason I can think of off
the top of my head why a new reflection warning is perhaps due to a change
in the method resolution code?

Andy



On Mon, Nov 19, 2018 at 1:51 PM Alex Miller  wrote:

> We expect to move back into release candidates next, so testing welcome...
>
> On Monday, November 19, 2018 at 3:34:03 PM UTC-6, Alex Miller wrote:
>>
>> 1.10.0-beta7 is now available.
>>
>> You can try it with clj using:
>>
>> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta7"}}}'
>>
>> Changes in 1.10.0-beta7:
>>
>>- CLJ-2435  - include
>>root cause class name in compilation and macroexpansion errors
>>
>> You can read the full 1.10 changelog here:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
> --
> 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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.10.0-beta7

[Alex Miller]

We expect to move back into release candidates next, so testing welcome...

On Monday, November 19, 2018 at 3:34:03 PM UTC-6, Alex Miller wrote:
>
> 1.10.0-beta7 is now available.
>
> You can try it with clj using:
>
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta7"}}}'
>
> Changes in 1.10.0-beta7:
>
>- CLJ-2435  - include 
>root cause class name in compilation and macroexpansion errors
>
> You can read the full 1.10 changelog here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>

-- 
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] Clojure 1.10.0-beta7

[Alex Miller]

1.10.0-beta7 is now available.

You can try it with clj using:

clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta7"}}}'

Changes in 1.10.0-beta7:

   - CLJ-2435  - include root 
   cause class name in compilation and macroexpansion errors
   
You can read the full 1.10 changelog here: 
https://github.com/clojure/clojure/blob/master/changes.md

-- 
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: Efficient Predicate Dispatch [was ANN: Logos v0.6]

[John Newman]

Update the example to leverage isa? hierarchies and allow prefer-poly, a la 
prefer-method: 
https://stackoverflow.com/questions/53329709/dispatching-function-calls-on-different-formats-of-maps/53354967#53354967

V/r

John

On Saturday, November 17, 2018 at 5:09:09 PM UTC-5, John Newman wrote:
>
> In order to answer a SO question I ended up whipping up a quick and dirty 
> implementation of predicate dispatch here 
> .
>  
> (unless I'm misunderstanding the definition of "predicate dispatch")
>
> If you know your dispatch set is going to be small, a first-one-wins 
> strategy should be good enough, right? And we can't really measure the 
> complexity of a user's supplied predicate function a priori anyway, so if 
> an isa? hierarchy isn't supplied, we might as well just check them in the 
> order they're provided from the user and let the first one win, right?
>
> V/r
>
> John
>
> On Thursday, April 14, 2011 at 11:25:48 AM UTC-4, David Nolen wrote:
>>
>> When things begin to get recursive you may be on the right track :D
>>
>> Initially I was going to implement Nominal Logic Programming for Logos a 
>> la William Byrd's dissertation, but I realized that his implementation 
>> requires pattern matching. All the pattern matching libs I've seen thus far 
>> for Clojure are too naive and too slow. Even more importantly pattern 
>> matching is subsumed by predicate dispatch (CiteSeerX — Efficient 
>> Predicate Dispatching 
>> ).
>>
>> Rich Hickey mentioned many moons ago that he'd like to see a predicate 
>> dispatch implementation for Clojure that didn't have the kind of hardwiring 
>> found in the Chambers/Chen paper. He suggested investigating Datalog. After 
>> much reading, I've decided that a runtime in-memory Datalog that handles 
>> dispatching is going to be too slow for many useful scenarios (an efficient 
>> Datalog based on Binary Decision Diagrams might be possible, but this is an 
>> incredibly complex undertaking in itself, meh).
>>
>> What we want is Standard MLs efficient compilation from decision diagrams 
>> to switch statements (CiteSeerX — Optimizing Pattern Matching 
>> ). 
>> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has 
>> issues with order among other things (Programming in Standard ML 
>> ).
>>
>> What if we allow a logic engine to drive the compilation of the decision 
>> diagram? This would be done by users mapping logic predicates to Clojure 
>> predicate functions. Relationships between predicates can be added to the 
>> logic engine allowing compilation to produce a very efficient decision 
>> diagram. Nothing is hard coded, everything is driven by the kinds of 
>> predicates and relationships between predicates that a user actually cares 
>> about.
>>
>> All this is to say that this means Logos needs the ability to load 
>> database of facts, index those facts, and to accept new facts and 
>> relationships and update accordingly. So this going to happen sooner rather 
>> then later.
>>
>> I welcome any feedback from anyone who has thoughts on this approach to 
>> implementing predicate dispatch efficiently!
>>
>> Some thoughts on what this might look like is evolving here, 
>> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>>
>> David
>>
>> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen  wrote:
>>
>>> On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi  wrote:
>>>
 Can it be used as an inference (rule) engine ?
>>>
>>>
>>> If you mean in the same way that you can build inference (rule) engines 
>>> in Prolog - I don't see why not.
>>>
>>> However there is a bit of work to be done in order to make building 
>>> efficient rule engines easier:
>>>
>>> * Be able to load a database (aka Clojure collection) of facts
>>> * Indexing of facts
>>> * Intelligently use indexed facts
>>>
>>> Currently I'm a bit more interested in exploring type inference (via 
>>> nominal logic) so I'm not sure when exactly I'll get to these, tho I'll 
>>> gladly take patches from people who want such features sooner rather than 
>>> later :)
>>>
>>> David
>>>
>>
>>

-- 
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.

Re: [ANN] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Łukasz Korecki]

Makes absolute sense  (and I like the approach, it's similar to how 
Cheshire handles it)

On Monday, November 19, 2018 at 6:47:42 PM UTC, Chad Harrington wrote:
>
> I do the same thing with dates & times (convert them to a more 
> Avro-friendly form first.) I didn't want to couple clj-time and cljs-time 
> to the lancaster library, since not everyone uses those. I think the right 
> design is to allow an arbitrary logical type mechanism with user-specified 
> serializers / deserializers. Lancaster could provide default 
> implmentations where appropriate, but those could be overridden by the 
> user. I will think more about this. If you'd like, please open a GitHub 
> issue about this and we can discuss it further there. I think that is a 
> better forum for working out the details of the feature.
>
> Thanks for your interest,
>
> Chad Harrington
> chad.ha...@gmail.com 
>
>
> On Mon, Nov 19, 2018 at 11:38 AM Łukasz Korecki  > wrote:
>
>> Hi!
>>
>> We're interested in the Date/Time/Timestamp part of the spec. A bit of 
>> background: our RabbitMQ framework (
>> https://github.com/nomnom-insights/nomnom.bunnicula) supports pluggable 
>> serialization and adopting Avro made our life easier. We're using it in 
>> couple of RPC-over-HTTP calls and that also simplified a couple of things.
>> The downside of current approach is that we have to encode all timestamps 
>> as long and encode in the application logic which attributes need to be 
>> converted to DateTimes after deserializing (or the other way around).
>>
>> Thanks,
>>
>> Łukasz
>>
>> On Monday, November 19, 2018 at 6:22:25 PM UTC, Chad Harrington wrote:
>>>
>>> Hi Łukasz,
>>> Logical types could certainly be added. Are you more interested in 
>>> arbitrary logical type support or the specific logical types defined in the 
>>> spec (Decimal, Date, Time, Timestamp, Duration)? Understanding your use 
>>> case will help with the design.
>>>
>>> Thanks,
>>>
>>> Chad Harrington
>>> chad.ha...@gmail.com
>>>
>>>
>>> On Mon, Nov 19, 2018 at 1:39 AM Łukasz Korecki  
>>> wrote:
>>>
 This looks great! Thank you for sharing
 Any plans for logical types[1] support? That's one of the biggest 
 things missing in Abracad imho


 Łukasz

 [1] - https://avro.apache.org/docs/1.8.0/spec.html#Logical+Types

 On Sunday, November 18, 2018 at 2:57:18 AM UTC, Chad Harrington wrote:
>
> https://github.com/deercreeklabs/lancaster
>
> Lancaster is an Apache Avro  
> library 
> for Clojure and ClojureScript. It aims to be fully compliant with the 
> Avro 
> Specification . 
> Lancaster is faster than JSON encoding / decoding and produces much 
> smaller 
> output. It also supports Avro schema evolution 
> , 
> allowing your data formats to change over time without breaking things.
>
> Issues and PRs are welcomed.
>
> Chad Harrington
> chad.ha...@gmail.com
>
 -- 
 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

Re: [ANN] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Chad Harrington]

I do the same thing with dates & times (convert them to a more
Avro-friendly form first.) I didn't want to couple clj-time and cljs-time
to the lancaster library, since not everyone uses those. I think the right
design is to allow an arbitrary logical type mechanism with user-specified
serializers / deserializers. Lancaster could provide default
implmentations where appropriate, but those could be overridden by the
user. I will think more about this. If you'd like, please open a GitHub
issue about this and we can discuss it further there. I think that is a
better forum for working out the details of the feature.

Thanks for your interest,

Chad Harrington
chad.harring...@gmail.com


On Mon, Nov 19, 2018 at 11:38 AM Łukasz Korecki 
wrote:

> Hi!
>
> We're interested in the Date/Time/Timestamp part of the spec. A bit of
> background: our RabbitMQ framework (
> https://github.com/nomnom-insights/nomnom.bunnicula) supports pluggable
> serialization and adopting Avro made our life easier. We're using it in
> couple of RPC-over-HTTP calls and that also simplified a couple of things.
> The downside of current approach is that we have to encode all timestamps
> as long and encode in the application logic which attributes need to be
> converted to DateTimes after deserializing (or the other way around).
>
> Thanks,
>
> Łukasz
>
> On Monday, November 19, 2018 at 6:22:25 PM UTC, Chad Harrington wrote:
>>
>> Hi Łukasz,
>> Logical types could certainly be added. Are you more interested in
>> arbitrary logical type support or the specific logical types defined in the
>> spec (Decimal, Date, Time, Timestamp, Duration)? Understanding your use
>> case will help with the design.
>>
>> Thanks,
>>
>> Chad Harrington
>> chad.ha...@gmail.com
>>
>>
>> On Mon, Nov 19, 2018 at 1:39 AM Łukasz Korecki 
>> wrote:
>>
>>> This looks great! Thank you for sharing
>>> Any plans for logical types[1] support? That's one of the biggest things
>>> missing in Abracad imho
>>>
>>>
>>> Łukasz
>>>
>>> [1] - https://avro.apache.org/docs/1.8.0/spec.html#Logical+Types
>>>
>>> On Sunday, November 18, 2018 at 2:57:18 AM UTC, Chad Harrington wrote:

 https://github.com/deercreeklabs/lancaster

 Lancaster is an Apache Avro  library
 for Clojure and ClojureScript. It aims to be fully compliant with the Avro
 Specification .
 Lancaster is faster than JSON encoding / decoding and produces much smaller
 output. It also supports Avro schema evolution
 ,
 allowing your data formats to change over time without breaking things.

 Issues and PRs are welcomed.

 Chad Harrington
 chad.ha...@gmail.com

>>> --
>>> 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.
>

-- 
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] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Łukasz Korecki]

Hi!

We're interested in the Date/Time/Timestamp part of the spec. A bit of 
background: our RabbitMQ framework 
(https://github.com/nomnom-insights/nomnom.bunnicula) supports pluggable 
serialization and adopting Avro made our life easier. We're using it in 
couple of RPC-over-HTTP calls and that also simplified a couple of things.
The downside of current approach is that we have to encode all timestamps 
as long and encode in the application logic which attributes need to be 
converted to DateTimes after deserializing (or the other way around).

Thanks,

Łukasz

On Monday, November 19, 2018 at 6:22:25 PM UTC, Chad Harrington wrote:
>
> Hi Łukasz,
> Logical types could certainly be added. Are you more interested in 
> arbitrary logical type support or the specific logical types defined in the 
> spec (Decimal, Date, Time, Timestamp, Duration)? Understanding your use 
> case will help with the design.
>
> Thanks,
>
> Chad Harrington
> chad.ha...@gmail.com 
>
>
> On Mon, Nov 19, 2018 at 1:39 AM Łukasz Korecki  > wrote:
>
>> This looks great! Thank you for sharing
>> Any plans for logical types[1] support? That's one of the biggest things 
>> missing in Abracad imho
>>
>>
>> Łukasz
>>
>> [1] - https://avro.apache.org/docs/1.8.0/spec.html#Logical+Types
>>
>> On Sunday, November 18, 2018 at 2:57:18 AM UTC, Chad Harrington wrote:
>>>
>>> https://github.com/deercreeklabs/lancaster
>>>
>>> Lancaster is an Apache Avro  library 
>>> for Clojure and ClojureScript. It aims to be fully compliant with the Avro 
>>> Specification . 
>>> Lancaster is faster than JSON encoding / decoding and produces much smaller 
>>> output. It also supports Avro schema evolution 
>>> , 
>>> allowing your data formats to change over time without breaking things.
>>>
>>> Issues and PRs are welcomed.
>>>
>>> Chad Harrington
>>> chad.ha...@gmail.com
>>>
>> -- 
>> 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] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Chad Harrington]

The JavaScript perf seems okay to me:
https://github.com/deercreeklabs/lancaster/blob/master/README.md#performance

I probably need to test Transit alongside the other cljs performance tests.
I will try to do more / better perf testing this week.

Thanks for your interest,

Chad Harrington
chad.harring...@gmail.com


On Sun, Nov 18, 2018 at 6:13 AM Matching Socks  wrote:

> "Faster than JSON" sounds reasonable -- in the JVM -- inasmuch as Avro
> uses a binary data format.  But what about in Javascript?  I ask because
> the motivation for Transit-JSON was an observation that the Javascript
> interpreters' built-in JSON parsers made binary formats uncompetitive.  Has
> the playing field been re-leveled in the 4 years or so since Transit was
> conceived?
>
> --
> 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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Chad Harrington]

It's definitely a tradeoff. In my experience, it's well worth it. For
messaging, I use a union of the possible message schemas. I wrote a library
(https://github.com/deercreeklabs/capsule) that makes messaging (events and
RPC) simple and easy. It uses Lancaster / Avro over WebSockets.
Unfortunately, it is not yet documented for public use. I hope to get to
that early in the new year.

For persisting data in storage, I store the fingerprint64 of the schema
along with the data, then have a lookup table of fingerprint64 to schemas.
Again, this works very well for me. Your mileage may vary.

Avro's compact size and Lancaster's speed make it very nice for messaging
and data storage. I also value having the data types validated at
serialization time. I love dynamic typing, but believe that types should be
checked at boundaries (messaging, storage, etc.). Lancaster makes it easy
to do that.

Chad Harrington
chad.harring...@gmail.com


On Sun, Nov 18, 2018 at 9:59 PM Gerard Klijs  wrote:

> The big penalty for the smaller size is that you need the scheme in order
> to deserialize the message. This can make some uses much more complex. For
> example when sending multiple types of messages, the client somehow needs
> to know which schema is used.
> How Avro is used with the Confluent Schema registry this is solved by
> having a way to globally register schema's, and encode the global id in the
> message.
> It looks similar to https://github.com/damballa/abracad which hasn't been
> updated in a while, but I use it in a pet project to use Avro from Closure.
> I might try replacing it.
>
> --
> 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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Chad Harrington]

Good idea. I will try to add that to the perf results sometime this week.

Chad Harrington
chad.harring...@gmail.com


On Sun, Nov 18, 2018 at 10:37 PM Tommi Reiman 
wrote:

> Looks good. Would be interesting to see the JVM Json perf tested also with
> https://github.com/metosin/jsonista.
>
> --
> 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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Chad Harrington]

Hi Łukasz,
Logical types could certainly be added. Are you more interested in
arbitrary logical type support or the specific logical types defined in the
spec (Decimal, Date, Time, Timestamp, Duration)? Understanding your use
case will help with the design.

Thanks,

Chad Harrington
chad.harring...@gmail.com


On Mon, Nov 19, 2018 at 1:39 AM Łukasz Korecki 
wrote:

> This looks great! Thank you for sharing
> Any plans for logical types[1] support? That's one of the biggest things
> missing in Abracad imho
>
>
> Łukasz
>
> [1] - https://avro.apache.org/docs/1.8.0/spec.html#Logical+Types
>
> On Sunday, November 18, 2018 at 2:57:18 AM UTC, Chad Harrington wrote:
>>
>> https://github.com/deercreeklabs/lancaster
>>
>> Lancaster is an Apache Avro  library
>> for Clojure and ClojureScript. It aims to be fully compliant with the Avro
>> Specification . Lancaster
>> is faster than JSON encoding / decoding and produces much smaller output.
>> It also supports Avro schema evolution
>> ,
>> allowing your data formats to change over time without breaking things.
>>
>> Issues and PRs are welcomed.
>>
>> Chad Harrington
>> chad.ha...@gmail.com
>>
> --
> 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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Quil 2.8.0 Release

[Mikita Belahlazau]

Happy to announce Quil 2.8.0 release.
Quil is a Clojure/ClojureScript library for creating interactive drawings
and animations.

The release available on clojars: https://clojars.org/quil. List of changes:

   - New looping? function. Contributed by @NightMachinary
    in #244
   .
   - Improved fullscreen support. #240
   .
   - Improved with-sketch and with-stroke macros. Contributed by @zck
   . Not it works both in Clojure and ClojureScript
   versions.
   - Removed the following functions: abs-int, abs-float, ambient-float,
   ambient-int, background-float, baackground-int, constrain-float,
   constrain-int, emissive-float, emissive-int, fill-float, fill-int,
   stroke-float, stroke-int, tint-float, tint-int. Only their counterpart
   without int/float left and work both in Clojure and ClojureScript.
   - Documentation improvements by @Alex-Keyes
   .
   - Refactoring of snippets to use them in API docs. See #246
   .

Another change is improvements in API documentation on http://quil.info.
For each API function you can now see one or more examples of how to use
it. Examples are taken from the Quil tests and guaranteed to work. You can
also try and play with them online using "try example" button.

Example: http://quil.info/api/color/creating-and-reading#alpha

If you find confusing or puzzling examples - please report them using
"report example" button or file a bug on Quil repo or just send email to
clj-process...@googlegroups.com.

Happy hacking!

Mikita

-- 
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: Efficient Predicate Dispatch [was ANN: Logos v0.6]

[Khalid Jebbari]

https://github.com/swannodette/match/wiki/Crazy-Ideas 

 is 
404, as well as https://github.com/swannodette/match 


On Thursday, April 14, 2011 at 5:25:48 PM UTC+2, David Nolen wrote:
>
> When things begin to get recursive you may be on the right track :D
>
> Initially I was going to implement Nominal Logic Programming for Logos a 
> la William Byrd's dissertation, but I realized that his implementation 
> requires pattern matching. All the pattern matching libs I've seen thus far 
> for Clojure are too naive and too slow. Even more importantly pattern 
> matching is subsumed by predicate dispatch (CiteSeerX — Efficient 
> Predicate Dispatching 
> ).
>
> Rich Hickey mentioned many moons ago that he'd like to see a predicate 
> dispatch implementation for Clojure that didn't have the kind of hardwiring 
> found in the Chambers/Chen paper. He suggested investigating Datalog. After 
> much reading, I've decided that a runtime in-memory Datalog that handles 
> dispatching is going to be too slow for many useful scenarios (an efficient 
> Datalog based on Binary Decision Diagrams might be possible, but this is an 
> incredibly complex undertaking in itself, meh).
>
> What we want is Standard MLs efficient compilation from decision diagrams 
> to switch statements (CiteSeerX — Optimizing Pattern Matching 
> ). 
> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has 
> issues with order among other things (Programming in Standard ML 
> ).
>
> What if we allow a logic engine to drive the compilation of the decision 
> diagram? This would be done by users mapping logic predicates to Clojure 
> predicate functions. Relationships between predicates can be added to the 
> logic engine allowing compilation to produce a very efficient decision 
> diagram. Nothing is hard coded, everything is driven by the kinds of 
> predicates and relationships between predicates that a user actually cares 
> about.
>
> All this is to say that this means Logos needs the ability to load 
> database of facts, index those facts, and to accept new facts and 
> relationships and update accordingly. So this going to happen sooner rather 
> then later.
>
> I welcome any feedback from anyone who has thoughts on this approach to 
> implementing predicate dispatch efficiently!
>
> Some thoughts on what this might look like is evolving here, 
> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>
> David
>
> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen  > wrote:
>
>> On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi > > wrote:
>>
>>> Can it be used as an inference (rule) engine ?
>>
>>
>> If you mean in the same way that you can build inference (rule) engines 
>> in Prolog - I don't see why not.
>>
>> However there is a bit of work to be done in order to make building 
>> efficient rule engines easier:
>>
>> * Be able to load a database (aka Clojure collection) of facts
>> * Indexing of facts
>> * Intelligently use indexed facts
>>
>> Currently I'm a bit more interested in exploring type inference (via 
>> nominal logic) so I'm not sure when exactly I'll get to these, tho I'll 
>> gladly take patches from people who want such features sooner rather than 
>> later :)
>>
>> David
>>
>
>

-- 
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] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Łukasz Korecki]

This looks great! Thank you for sharing
Any plans for logical types[1] support? That's one of the biggest things 
missing in Abracad imho


Łukasz

[1] - https://avro.apache.org/docs/1.8.0/spec.html#Logical+Types

On Sunday, November 18, 2018 at 2:57:18 AM UTC, Chad Harrington wrote:
>
> https://github.com/deercreeklabs/lancaster
>
> Lancaster is an Apache Avro  library 
> for Clojure and ClojureScript. It aims to be fully compliant with the Avro 
> Specification . Lancaster 
> is faster than JSON encoding / decoding and produces much smaller output. 
> It also supports Avro schema evolution 
> , 
> allowing your data formats to change over time without breaking things.
>
> Issues and PRs are welcomed.
>
> Chad Harrington
> chad.ha...@gmail.com 
>

-- 
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.