Re: GSoC Report: Expresso, symbolic manipulation of Algebraic Expressions in clojure

2013-09-24 Thread adriaan . sticker 
nice work
congratulations

-- 
-- 
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/groups/opt_out.

Re: GSoC Report: NDArray for core.matrix

2013-09-24 Thread adriaan . sticker 
great
congrats

Op maandag 23 september 2013 23:25:25 UTC+2 schreef Dmitry Groshev:
>
> Today Google Summer of Code finally ends. NDArray is pretty stable now and 
> will be the default implementation used by core.matrix in the upcoming 
> release. It was an epic journey through bugs, unexpected slowness and weird 
> macros, but now I can proudly state that in some cases NDArray can be 
> faster than NumPy by a factor of two: [1]. 
>
> Well, not always. It's hard to consistently beat highly optimized and 
> vectorized native code on JVM :) But we have a secrete sauce here in 
> Clojure: macros. You can find the code I've benchmarked here: [2]. What's 
> going on? The thing here is that using macros we can fully eliminate the 
> cost of intermediate matrix allocation (or function call machinery in case 
> of map-like functions) doing element-wise operations. Thanks to macros, the 
> code will be expanded to a highly optimized loop right inside user's code, 
> hiding messy details of NDArray and Clojure's type hinting from user, but 
> exposing necessary information to JVM. Moreover, this will work on a bunch 
> of NDArrays, too: [3]. More details can be found in NDArray's documentation 
> (by the courtesy of Marginalia): [4].
>
> Overall, this project was very interesting experience to me. Hope others 
> will find it useful :) 
>
> Cheers! 
> Dmitry
>
> [1]: http://i.imgur.com/6qdUF7f.png
> [2]: https://gist.github.com/si14/6676599
> [3]: 
> https://github.com/mikera/matrix-api/blob/develop/src/test/clojure/clojure/core/matrix/test_ndarray_implementation.clj#L16
> [4]: http://mikera.github.io/matrix-api/ndarray.html
>

-- 
-- 
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/groups/opt_out.

Re: Efficiently typing an argument of implementation in deftype

2013-09-24 Thread Dmitry Groshev 
Interesting, can you please explain somewhat more?

On Saturday, September 21, 2013 3:19:16 AM UTC+4, Ambrose Bonnaire-Sergeant 
wrote:
>
> Just a thought, could implementing IKeywordInvoke and using keywords for 
> field lookups speed up compilation?
>
> Thanks,
> Ambrose
>
>
> On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev 
> 
> > wrote:
>
>> In this mail I'm talking about Clojure 1.4, however, I believe that the 
>> issue persists in later versions, too.
>>
>> I have quite a lot of code of the following form:
>>
>> (defprotocol sum-proto
>>   (sum [x y]))
>>
>> (deftype Pair
>> [^long a ^long b]
>>   sum-proto
>>   (sum [x y]
>> (let [^Pair y y
>>   new-a (+ (.a x) (.a y))
>>   new-b (+ (.b x) (.b y))]
>>   (Pair. new-a new-b
>>
>> In real code there are *a lot* of implementations in that deftype 
>> generated by macroses. The problem is that compilation time skyrocketed. 
>> Right now I'm facing 5-10 seconds of compilation, which makes incremental 
>> development very painful. Profiler shows that the overwhelming majority of 
>> this time is spent here: [1]. It follows that the problem is in that ^Pair 
>> annotation: when symbol is tagged by a symbol, it should be resolved as a 
>> class. It should be way faster if I can "cache" that resolution, but I 
>> can't given that those implementation are inside of deftype, I can't 
>> resolve in advance the class that isn't defined. And I can't use 
>> extend-type either because of the cost of extra var lookup.
>>
>> The main question is: what can I do to make compilation faster? 
>> Pre-resolving that class won't work, it seems.
>>
>> [1]: 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986
>>  
>> -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: Efficiently typing an argument of implementation in deftype

2013-09-24 Thread Ambrose Bonnaire-Sergeant 
I mean something like what defrecord does:

(defprotocol SumProto
  (sum [x y]))

(declare ->Pair)

(deftype Pair [^long a ^long b]
  clojure.lang.ILookup
  (valAt [this k]
(case k
  :a a
  :b b))

  SumProto
  (sum [x y]
(let [new-a (+ (:a x) (:a y))
  new-b (+ (:b x) (:b y))]
  (->Pair new-a new-b

Thanks,
Ambrose


On Tue, Sep 24, 2013 at 4:54 PM, Dmitry Groshev wrote:

> Interesting, can you please explain somewhat more?
>
>
> On Saturday, September 21, 2013 3:19:16 AM UTC+4, Ambrose
> Bonnaire-Sergeant wrote:
>
>> Just a thought, could implementing IKeywordInvoke and using keywords for
>> field lookups speed up compilation?
>>
>> Thanks,
>> Ambrose
>>
>>
>>  On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev wrote:
>>
>>>  In this mail I'm talking about Clojure 1.4, however, I believe that
>>> the issue persists in later versions, too.
>>>
>>> I have quite a lot of code of the following form:
>>>
>>> (defprotocol sum-proto
>>>   (sum [x y]))
>>>
>>> (deftype Pair
>>> [^long a ^long b]
>>>   sum-proto
>>>   (sum [x y]
>>> (let [^Pair y y
>>>   new-a (+ (.a x) (.a y))
>>>   new-b (+ (.b x) (.b y))]
>>>   (Pair. new-a new-b
>>>
>>> In real code there are *a lot* of implementations in that deftype
>>> generated by macroses. The problem is that compilation time skyrocketed.
>>> Right now I'm facing 5-10 seconds of compilation, which makes incremental
>>> development very painful. Profiler shows that the overwhelming majority of
>>> this time is spent here: [1]. It follows that the problem is in that ^Pair
>>> annotation: when symbol is tagged by a symbol, it should be resolved as a
>>> class. It should be way faster if I can "cache" that resolution, but I
>>> can't given that those implementation are inside of deftype, I can't
>>> resolve in advance the class that isn't defined. And I can't use
>>> extend-type either because of the cost of extra var lookup.
>>>
>>> The main question is: what can I do to make compilation faster?
>>> Pre-resolving that class won't work, it seems.
>>>
>>> [1]: https://github.com/**clojure/clojure/blob/master/**
>>> src/jvm/clojure/lang/Compiler.**java#L986
>>>
>>> --
>>> --
>>> 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/**groups/opt_out
>>> .
>>>
>>
>>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Efficiently typing an argument of implementation in deftype

2013-09-24 Thread Ambrose Bonnaire-Sergeant 
defrecord uses IKeywordLookup's getLookupThunk, but I can't figure out how
to implement it.

Thanks,
Ambrose


On Tue, Sep 24, 2013 at 5:16 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> I mean something like what defrecord does:
>
> (defprotocol SumProto
>   (sum [x y]))
>
> (declare ->Pair)
>
> (deftype Pair [^long a ^long b]
>   clojure.lang.ILookup
>   (valAt [this k]
> (case k
>   :a a
>   :b b))
>
>   SumProto
>   (sum [x y]
> (let [new-a (+ (:a x) (:a y))
>   new-b (+ (:b x) (:b y))]
>   (->Pair new-a new-b
>
> Thanks,
> Ambrose
>
>
> On Tue, Sep 24, 2013 at 4:54 PM, Dmitry Groshev wrote:
>
>> Interesting, can you please explain somewhat more?
>>
>>
>> On Saturday, September 21, 2013 3:19:16 AM UTC+4, Ambrose
>> Bonnaire-Sergeant wrote:
>>
>>> Just a thought, could implementing IKeywordInvoke and using keywords for
>>> field lookups speed up compilation?
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>>  On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev 
>>> wrote:
>>>
  In this mail I'm talking about Clojure 1.4, however, I believe that
 the issue persists in later versions, too.

 I have quite a lot of code of the following form:

 (defprotocol sum-proto
   (sum [x y]))

 (deftype Pair
 [^long a ^long b]
   sum-proto
   (sum [x y]
 (let [^Pair y y
   new-a (+ (.a x) (.a y))
   new-b (+ (.b x) (.b y))]
   (Pair. new-a new-b

 In real code there are *a lot* of implementations in that deftype
 generated by macroses. The problem is that compilation time skyrocketed.
 Right now I'm facing 5-10 seconds of compilation, which makes incremental
 development very painful. Profiler shows that the overwhelming majority of
 this time is spent here: [1]. It follows that the problem is in that ^Pair
 annotation: when symbol is tagged by a symbol, it should be resolved as a
 class. It should be way faster if I can "cache" that resolution, but I
 can't given that those implementation are inside of deftype, I can't
 resolve in advance the class that isn't defined. And I can't use
 extend-type either because of the cost of extra var lookup.

 The main question is: what can I do to make compilation faster?
 Pre-resolving that class won't work, it seems.

 [1]: https://github.com/**clojure/clojure/blob/master/**
 src/jvm/clojure/lang/Compiler.**java#L986

 --
 --
 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/**groups/opt_out
 .

>>>
>>>  --
>> --
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

2013-09-24 Thread Dmitry Groshev 
I'm curious how this relates to core.logic. If I understand correctly, 
Clara can be compiled to core.logic and utilize it's search, doesn't it?

On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote:
>
> This is the first release of Clara, forward-chaining rules in Clojure. 
>
> Details on the github site:
>
> https://github.com/rbrush/clara-rules
>
> I've also posted the rationale for what I'm doing here:
>
> http://www.toomuchcode.org/2013/09/rules-as-control-structure.html
>
> The gist is that forward-chaining rules are a great tool for many problems 
> and Clojure's strengths can address some weaknesses in existing production 
> systems. Right now Clara supports most of the major features seen in 
> production systems, embraces Clojure values like immutability, and is 
> powerful enough for a number of use cases. It still needs to be profiled 
> and subjected to more rigorous testing before I'd consider it production 
> ready, but this release is for anyone interested in experimenting with 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/groups/opt_out.

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

2013-09-24 Thread Ryan Brush 
Clara is a forward-chaining production system -- think Jess, Drools or 
CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based 
logic programming, more along the lines of Prolog and obviously with a 
strong relationship to Kanren.

These approaches are complementary; which one to use really depends on the 
problem you want to solve. If you can describe a problem as a search space 
over a set of constraints, core.logic is almost certainly a better fit than 
Clara.

In contrast, Clara targets the expression of complex and arbitrary 
domain-specific knowledge. Even a functional approach to programming can 
become unwieldy if business rules are frequently changing and have 
arbitrary relationships to other rules. Those functions would need to be 
deeply chained together, with frequent changes forcing them to be re-wired. 
Production systems allow the logic to be expressed independently, where 
authors need not worry about other rules, order of execution, or wiring 
them together. The engine then runs the rules against a set of input and 
ensures the working memory reaches a consistent state.

I wrote about this in more depth 
here: https://github.com/rbrush/clara-rules/wiki/Introduction

On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote:
>
> I'm curious how this relates to core.logic. If I understand correctly, 
> Clara can be compiled to core.logic and utilize it's search, doesn't it?
>
> On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote:
>>
>> This is the first release of Clara, forward-chaining rules in Clojure. 
>>
>> Details on the github site:
>>
>> https://github.com/rbrush/clara-rules
>>
>> I've also posted the rationale for what I'm doing here:
>>
>> http://www.toomuchcode.org/2013/09/rules-as-control-structure.html
>>
>> The gist is that forward-chaining rules are a great tool for many 
>> problems and Clojure's strengths can address some weaknesses in existing 
>> production systems. Right now Clara supports most of the major features 
>> seen in production systems, embraces Clojure values like immutability, and 
>> is powerful enough for a number of use cases. It still needs to be profiled 
>> and subjected to more rigorous testing before I'd consider it production 
>> ready, but this release is for anyone interested in experimenting with 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/groups/opt_out.

Library (or libraries) for translating REST queries to database queries?

2013-09-24 Thread Bill Piel 


I want to use clojure to build a web service with a RESTful API that 
exposes resources stored in a relational database (mysql in this case). I'd 
like to use a library that, given a specification of the db schema, would 
translate incoming requests to db queries, or korma constructs.

Examples might be:

GET /users?status=4

translates to something like:

SELECT * FROM `users` WHERE `status` = 4;

or:

PUT /users/12

would be:

UPDATE `users` SET ... WHERE `id` = 12

Is there anything out there that would facilitate this?

thanks

-- 
-- 
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/groups/opt_out.

Re: GSoC Report: Expresso, symbolic manipulation of Algebraic Expressions in clojure

2013-09-24 Thread David Nolen 
Impressive work congrats!


On Mon, Sep 23, 2013 at 11:38 AM, Maik Schünemann  wrote:

> GSoC ends today and I can announce the 0.2.0 version of the expresso [1]
> library.
> It is build on top of core.logic and core.matrix and provides symbolic
> manipulation of algebraic expressions.
>
> What's there?
> 1. An api/dsl for manipulation of algebraic expressions which doesn't get
> in your way. Expresso's expressions are
>just clojure s-expressions and can be manipulated with rich set of
> clojure sequence functions
> 2. useful manipulations for mathematical expressions: simplify,
> multiply-out, differentiate, ...
> 3. An equation solver which is capable of solving a single equation and
> multiple equations for unknowns.
> 4. An optimizer which transforms a mathematical expression to a
> semantically equivalent but performanter one
> 5. An expression compiler to compile an expression to an efficient clojure
> function
> 6. A semantic rule based translator on top of which many of expresso's
> features are implemented
>
> The code is fully documented and I wrote a tutorial and showcase of
> expresso, the expresso-tutorial [2].
>
> GSoC has been a really fun and valuable time for me. I learned a lot. Of
> course I will continue developing expresso!
> Expresso and core.matrix are the first steps in the direction of a full
> computer algebra system for clojure. I hope that it will help clojure to be
> an attractive choice for scientific computing projects in the future.
>
> Showcase:
> Here are two examples of expresso's facility to manipulate mathematical
> expressions. They can be found and are explained in the expresso-tutorial
> [2].
>
> 1. solving word problems:
>
> (solve 'blue
>   (ex (= pencils (+ green white blue red)))
>   (ex (= (/ pencils 10) green))
>   (ex (= (/ pencils 2) white))
>   (ex (= (/ pencils 4) blue))
>   (ex (= red 45))) ;=> #{{blue 75N}}
>
>
> 2. Analyzing roots and extremata of functions. This code shows how easy
> one can implement tasks involving symbolic manipulation with expresso:
>
> (defn roots
>   "returns the set of roots of the expression in regard to var"
>   [var expr]
>   (solve var (ex (= ~expr 0
>
>
> (defn extremata
>   "gets the extrema of the expression in regard to var. Returns a map with the
>keys :maxima and :minima"
>   [var expr]
>   (let [d1 (differentiate [var] expr)
> d2 (differentiate [var] d1)
> candidates (roots var d1)]
> (if (seq candidates)
>   (let [extremata
> (->> candidates
>  (map (fn [candidate] [candidate (evaluate d2 {var 
> candidate})]))
>  (remove #(== 0 (second %)))
>  (group-by #(< 0 (second %]
> {:maxima (map first (get extremata false))
>  :minima (map first (get extremata true))}
>
>
> (defn analyse-function
>   "returns a map with the :roots, the :maxima and the :minima of the 
> expression
>in regard to var"
>   [var expr]
>   (assoc (extremata var expr)
> :roots (roots var expr)))
>
> (analyse-function 'x (ex (- (** x 4) (** x 2
> ;=> {:roots #{0 -1 1},
> ;;   :maxima (0),
> ;;   :minima (0.7071067811865476 -0.7071067811865476)}
>
>
> Ideas/feedbacks etc are greatly appreciated!
> Enjoy,
> Maik
>
> [1] https://github.com/clojure-numerics/expresso
> [2] https://github.com/mschuene/expresso-tutorial
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Library (or libraries) for translating REST queries to database queries?

2013-09-24 Thread Angel Java Lopez 
U... OData maybe a bit overwhelming, but I guess it is in your direction

http://www.odata.org/

There is an implementation in Java
https://code.google.com/p/odata4j/
(apparently with consumers and producers, too)

There is an experimental Clojure project consuming odata4j
https://github.com/danbev/odata_test
Don't sure if it implements a consumer

But I insist, odata is a bit overwhelming...

Something more simple?

Angel "Java" Lopez
@ajlopez




On Tue, Sep 24, 2013 at 10:35 AM, Bill Piel  wrote:

> I want to use clojure to build a web service with a RESTful API that
> exposes resources stored in a relational database (mysql in this case). I'd
> like to use a library that, given a specification of the db schema, would
> translate incoming requests to db queries, or korma constructs.
>
> Examples might be:
>
> GET /users?status=4
>
> translates to something like:
>
> SELECT * FROM `users` WHERE `status` = 4;
>
> or:
>
> PUT /users/12
>
> would be:
>
> UPDATE `users` SET ... WHERE `id` = 12
>
> Is there anything out there that would facilitate this?
>
> thanks
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: GSoC report: Extend Neko library for Android

2013-09-24 Thread Zach Oakes 
I am so excited about how neko and lein-droid have come along; Alex has 
done some amazing work. Compared to Android's standard Java/XML approach, 
it's really a revelation to write your UI and logic in the same simple 
Clojure code. For the types of apps that don't require instant boot times, 
I think Clojure will be a tremendous secret weapon.

On Monday, September 23, 2013 8:30:16 PM UTC-4, Alexander Yakushev wrote:
>
> As you might already figured out from similar topics, GSoC 2013 is over 
> and it is time to collect the fruit. As of my proposal, I achieved several 
> things this year at both lein-droid[1] and Neko[2]. Here is the list of 
> them:
>
> 1. Rewrote neko.ui from macros to functions to allow true dynamic UI 
> generation (similar to Hiccup, for example).
> 2. Added utilities to create menus and manipulate application ActionBar 
> (including action modes), implemented support for tabbed views and 
> Fragments.
> 3. Added support for data readers in Clojure/Android projects, implemented 
> a few data readers for resource identifiers.
> 4. Implemented auto-completion[3] that works reasonably fast on Android 
> devices. The client currently exists for Emacs only[4], but Zach is working 
> on integrating it into Nightcode. The auto-completion library can also be 
> used in Clojure/JVM projects since it has a couple of nice features beyond 
> clojure-complete.
> 5. Created template for a splash window to be shown while Clojure runtime 
> is being loaded[5]. New projects are created with this splash already 
> included.
> 6. Implemented some more UI widgets and traits in Neko.
>
> I thank my mentor, Zach Oakes, for his amazing support, advice and 
> feedback throughout the whole program; and of course, Clojure community for 
> giving me a chance to pursue this project. I am very glad that some people 
> have already tried Clojure on Android, and sincerely hope that my work 
> brings even more curious minds to it.
>
> Best regards,
> Alex Yakushev
>
> [1] https://github.com/clojure-android/lein-droid
> [2] https://github.com/alexander-yakushev/neko
> [3] https://github.com/alexander-yakushev/compliment/
> [4] https://github.com/alexander-yakushev/ac-nrepl-compliment
> [5] http://www.youtube.com/watch?v=sqI-iUmxJS0
>

-- 
-- 
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/groups/opt_out.

Re: Library (or libraries) for translating REST queries to database queries?

2013-09-24 Thread Shantanu Kumar 
Hi Bill,

Did you look at restSQL? http://restsql.org

For custom needs generating SQL from REST routes might be a way.

Shantanu

On Tuesday, 24 September 2013 19:05:38 UTC+5:30, Bill Piel wrote:
>
> I want to use clojure to build a web service with a RESTful API that 
> exposes resources stored in a relational database (mysql in this case). I'd 
> like to use a library that, given a specification of the db schema, would 
> translate incoming requests to db queries, or korma constructs.
>
> Examples might be:
>
> GET /users?status=4
>
> translates to something like:
>
> SELECT * FROM `users` WHERE `status` = 4;
>
> or:
>
> PUT /users/12
>
> would be:
>
> UPDATE `users` SET ... WHERE `id` = 12
>
> Is there anything out there that would facilitate this?
>
> thanks
>

-- 
-- 
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/groups/opt_out.

Re: much lower recursion depth with memoization

2013-09-24 Thread Mark Engelberg 
I posted an article detailing the approaches I outlined earlier in this
thread:
http://programming-puzzler.blogspot.com/2013/09/defeating-stack-overflows.html

-- 
-- 
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/groups/opt_out.

light-table doesn't like (set! *unchecked-math* true)

2013-09-24 Thread Jim - FooBar(); 

Hi all,

does anyone have a clue why light-table 0.5.3 throws exception whenever 
it sees a (set! *unchecked-math* true)?
I mean it swallows (set! *warn-on-reflection* true) just fine! Is this a 
bug?


the actual exception is

(set! *warn-on-reflection* true)
(set! *unchecked-math* true)
java.lang.IllegalStateException: Can't change/establish root binding of: 
*unchecked-math* with set Var.java:233 clojure.lang.Var.set 
NO_SOURCE_FILE:26 hotel-nlp.helper/eval9004




Jim

--
--
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/groups/opt_out.

room available at Clojure/conj

2013-09-24 Thread Rich Morin 
I have registered a suite for Thursday and Friday nights at the
conference hotel (Embassy Suites Alexandria - Old Town), but I
only need the main room.  So, the second room (and sofa bed) is
available.

I'm open to sharing the suite with another (quiet, non-smoking)
Clojurist.  If you are interested, please get in touch *off-list*.

-r

 -- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation


-- 
-- 
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/groups/opt_out.

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

2013-09-24 Thread Dmitry Groshev 
I see your point. By the way, the documentation is outstanding, especially 
for first release. Great work!

On the other hand, I can't help but think that Rete algorithm looks like a 
part of logic programming system. I understand that this is a corner case 
(Prolog does a lot more than just scanning through facts/rules) and 
therefore can be solved much more efficiently, but is there a way to blend 
this approaches? I've also found [1] and this supports my suspicion that 
the distinction is more of a historic/business kind rather than fundamental 
one.

Your argument on execution order problems is valid, especially for Prolog. 
But minikanren is not so brittle in this sense. Moreover, "runtime" 
assertion of facts in regard to core.logic already surfaced a few times in 
this list [2], so effective addition of facts and rules can be very 
beneficial for core.logic. On the other hand, if I understand correctly, 
information on constraints (both real, integer and FD) can be useful for 
rule-based systems to reduce search space of rules that can be affected by 
new fact. So combined approach seems useful to me.

[1]: 
http://programmers.stackexchange.com/questions/114711/the-relation-between-business-rules-engines-and-constraint-programming-languages
[2]: http://osdir.com/ml/clojure/2013-03/msg00778.html

On Tuesday, September 24, 2013 3:42:02 PM UTC+4, Ryan Brush wrote:
>
> Clara is a forward-chaining production system -- think Jess, Drools or 
> CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based 
> logic programming, more along the lines of Prolog and obviously with a 
> strong relationship to Kanren.
>
> These approaches are complementary; which one to use really depends on the 
> problem you want to solve. If you can describe a problem as a search space 
> over a set of constraints, core.logic is almost certainly a better fit than 
> Clara.
>
> In contrast, Clara targets the expression of complex and arbitrary 
> domain-specific knowledge. Even a functional approach to programming can 
> become unwieldy if business rules are frequently changing and have 
> arbitrary relationships to other rules. Those functions would need to be 
> deeply chained together, with frequent changes forcing them to be re-wired. 
> Production systems allow the logic to be expressed independently, where 
> authors need not worry about other rules, order of execution, or wiring 
> them together. The engine then runs the rules against a set of input and 
> ensures the working memory reaches a consistent state.
>
> I wrote about this in more depth here: 
> https://github.com/rbrush/clara-rules/wiki/Introduction
>
> On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote:
>>
>> I'm curious how this relates to core.logic. If I understand correctly, 
>> Clara can be compiled to core.logic and utilize it's search, doesn't it?
>>
>> On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote:
>>>
>>> This is the first release of Clara, forward-chaining rules in Clojure. 
>>>
>>> Details on the github site:
>>>
>>> https://github.com/rbrush/clara-rules
>>>
>>> I've also posted the rationale for what I'm doing here:
>>>
>>> http://www.toomuchcode.org/2013/09/rules-as-control-structure.html
>>>
>>> The gist is that forward-chaining rules are a great tool for many 
>>> problems and Clojure's strengths can address some weaknesses in existing 
>>> production systems. Right now Clara supports most of the major features 
>>> seen in production systems, embraces Clojure values like immutability, and 
>>> is powerful enough for a number of use cases. It still needs to be profiled 
>>> and subjected to more rigorous testing before I'd consider it production 
>>> ready, but this release is for anyone interested in experimenting with 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/groups/opt_out.

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

2013-09-24 Thread Ryan Brush 
I appreciate the kind words!

You're right that the lines between forward- and backward-chaining systems 
are blurry, with some systems incorporating ideas from both. Perhaps more 
important than that is how easily we can express the logic for a given 
problem. While it's possible to write, say, a Sudoku solver in Clara, it 
really isn't the right tool for that sort of constraint-based logic. 
Conversely, some forward-chaining rules may not be as easily expressed in a 
system that emphasizes constraints. Some examples I put together to 
demonstrate Clara are at [1]; I hope these are fairly clear. I'm not so 
sure this type of arbitrary, changing business logic is as easy to 
modularize and express in other systems.

To be clear, I think core.logic is awesome, and am uncomfortable drawing 
any comparison between it and Clara. I also can imagine leveraging 
core.logic and its ideas in Clara itself as this evolves. As a starting 
point, however, Clara is targeting a different class of problem.  If 
working with a problem that could benefit from rules, I'd suggest thinking 
of the simplest way that problem can be expressed, and choosing a 
technology that most closely aligns with that.

I hope this makes sense! I wish I had some clear litmus test to contrast 
these systems, but I'm still learning myself. ;)

[1]
https://github.com/rbrush/clara-examples/tree/master/src/main/clojure/clara/examples

On Tuesday, September 24, 2013 2:02:33 PM UTC-5, Dmitry Groshev wrote:
>
> I see your point. By the way, the documentation is outstanding, especially 
> for first release. Great work!
>
> On the other hand, I can't help but think that Rete algorithm looks like a 
> part of logic programming system. I understand that this is a corner case 
> (Prolog does a lot more than just scanning through facts/rules) and 
> therefore can be solved much more efficiently, but is there a way to blend 
> this approaches? I've also found [1] and this supports my suspicion that 
> the distinction is more of a historic/business kind rather than fundamental 
> one.
>
> Your argument on execution order problems is valid, especially for Prolog. 
> But minikanren is not so brittle in this sense. Moreover, "runtime" 
> assertion of facts in regard to core.logic already surfaced a few times in 
> this list [2], so effective addition of facts and rules can be very 
> beneficial for core.logic. On the other hand, if I understand correctly, 
> information on constraints (both real, integer and FD) can be useful for 
> rule-based systems to reduce search space of rules that can be affected by 
> new fact. So combined approach seems useful to me.
>
> [1]: 
> http://programmers.stackexchange.com/questions/114711/the-relation-between-business-rules-engines-and-constraint-programming-languages
> [2]: http://osdir.com/ml/clojure/2013-03/msg00778.html
>
> On Tuesday, September 24, 2013 3:42:02 PM UTC+4, Ryan Brush wrote:
>>
>> Clara is a forward-chaining production system -- think Jess, Drools or 
>> CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based 
>> logic programming, more along the lines of Prolog and obviously with a 
>> strong relationship to Kanren.
>>
>> These approaches are complementary; which one to use really depends on 
>> the problem you want to solve. If you can describe a problem as a search 
>> space over a set of constraints, core.logic is almost certainly a better 
>> fit than Clara.
>>
>> In contrast, Clara targets the expression of complex and arbitrary 
>> domain-specific knowledge. Even a functional approach to programming can 
>> become unwieldy if business rules are frequently changing and have 
>> arbitrary relationships to other rules. Those functions would need to be 
>> deeply chained together, with frequent changes forcing them to be re-wired. 
>> Production systems allow the logic to be expressed independently, where 
>> authors need not worry about other rules, order of execution, or wiring 
>> them together. The engine then runs the rules against a set of input and 
>> ensures the working memory reaches a consistent state.
>>
>> I wrote about this in more depth here: 
>> https://github.com/rbrush/clara-rules/wiki/Introduction
>>
>> On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote:
>>>
>>> I'm curious how this relates to core.logic. If I understand correctly, 
>>> Clara can be compiled to core.logic and utilize it's search, doesn't it?
>>>
>>> On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote:

 This is the first release of Clara, forward-chaining rules in Clojure. 

 Details on the github site:

 https://github.com/rbrush/clara-rules

 I've also posted the rationale for what I'm doing here:

 http://www.toomuchcode.org/2013/09/rules-as-control-structure.html

 The gist is that forward-chaining rules are a great tool for many 
 problems and Clojure's strengths can address some weaknesses in existing 
 pro

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

2013-09-24 Thread Mark Engelberg 
I used CLIPS (another forward-chaining rule system) for several years, and
the way I tend to explain it to people is that it is the best tool for the
job when your code would look like an enormous cond with thousands of
cases, executed over and over, because:

1.  The Rete algorithm can "jump to the right branch" more efficiently than
testing each case one by one in some linear order.
2.  When you have thousands of cases, it can be difficult to ensure that
they are in exactly the right order and/or don't overlap.  Forward-chaining
systems let you express the cases more declaratively and apply precedence
rules judiciously rather than thinking about precedence all the time.

I think a forward-chaining system would also make a great foundation for a
project that requires some sort of dataflow architecture.

I agree with Ryan that it tends to be useful in different contexts than
constraint solvers.

-- 
-- 
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/groups/opt_out.

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

2013-09-24 Thread Angel Java Lopez 
+1


On Tue, Sep 24, 2013 at 9:00 PM, Mark Engelberg wrote:

> I used CLIPS (another forward-chaining rule system) for several years, and
> the way I tend to explain it to people is that it is the best tool for the
> job when your code would look like an enormous cond with thousands of
> cases, executed over and over, because:
>
> 1.  The Rete algorithm can "jump to the right branch" more efficiently
> than testing each case one by one in some linear order.
> 2.  When you have thousands of cases, it can be difficult to ensure that
> they are in exactly the right order and/or don't overlap.  Forward-chaining
> systems let you express the cases more declaratively and apply precedence
> rules judiciously rather than thinking about precedence all the time.
>
> I think a forward-chaining system would also make a great foundation for a
> project that requires some sort of dataflow architecture.
>
> I agree with Ryan that it tends to be useful in different contexts than
> constraint solvers.
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.