Re: [GSoC 2013] core.logic CLP(Prob)

[Edmund]

Fantastic - thanks for pointing these out.

On Friday, 26 April 2013 08:43:07 UTC+1, Zack Maril wrote:
>
> Nils also wrote his work up:
> http://ozk.unizd.hr/proceedings/index.php/els/article/view/102/106
> -Zack
>
> On Friday, April 26, 2013 6:33:55 AM UTC+4, Maximilien Rzepka wrote:
>>
>> For the sake of completion  ;)
>>
>> Nils Bertschinger's work 
>> https://github.com/bertschi/ProbClojureNice 
>> https://groups.google.com/forum/?fromgroups=#!topic/clojure/9NhsFga4D9s
>>
>> Le mercredi 24 avril 2013 11:34:14 UTC+2, Zack Maril a écrit :
>>>
>>> Lately, I've been on a bit of a jag into probabilistic programming with 
>>> Clojure, specifically embedding Church inside of Clojure. The results so 
>>> far are promising from a syntactic level, but, like David said, getting it 
>>> to actually work is another matter entirely. I wanted to share what I've 
>>> been able to get working so far and some of the potential challenges of 
>>> embedding Church in Clojure. 
>>>
>>> https://gist.github.com/zmaril/5447488
>>>
>>> The above gist is a self contained Clojure program that implements, 
>>> among other things, `query-by-rejection` and `flip`. With these two 
>>> functions, we can already do most of what Church seems to do. What's 
>>> missing from a functionality standpoint is support for various 
>>> distributions and some useful functions related to tolerance (and, of 
>>> course, a good MCMC/Gibbs implementation). What's been gained is, via some 
>>> careful macro writing, the ability to reuse code, specifically to reuse 
>>> memoized functions. 
>>>
>>> One of the key ideas behind Church is that memoization allows one to 
>>> express complicated scenarios very concisely. So, to code up a randomized 
>>> persistent trait (like a person's eye color), you simply define a memoized 
>>> function that takes in a person and returns their eye color. Every time a 
>>> new world is generated, the memoized function gets recreated. But within 
>>> the world (or current experiment), the trait persists and can be referenced 
>>> again in various places without too much hassle.  Note that a new memoized 
>>> function must be created for each experiment, i.e. you can't just memoize 
>>> the function outside the query and bring that back in. Within the gist 
>>> above, binding is used to carefully rebind any function provided in the 
>>> :memobound clause for each experiment. By declaring a var to be dynamic, we 
>>> can write queries that are pretty short but all rely on the same logic. 
>>> From a syntactic standpoint, it took about one evening of work to cut down 
>>> the length of most of the Church examples by at least half. 
>>>
>>> From a speed standpoint, Church is way, way ahead of the above. Sampling 
>>> via rejection is quite slow compared to modern methods like MCMC or Gibbs. 
>>> It might not even be possible to do the dynamic rebinding of memoized 
>>> functions mentioned above and get as fast as Church is. I really don't 
>>> know. Here's one of the first papers on Church:
>>> http://www.stanford.edu/~ngoodman/papers/churchUAI08_rev2.pdf
>>>
>>> The paper is about five years old now, but section 4.1 goes into how 
>>> Church was first implemented with a MCMC. The key idea they introduce here 
>>> is the computation trace. I won't try to summarize it here because I don't 
>>> fully understand it yet. If it means what I think it means though, then it 
>>> should be possible to build and keep track of the computation trace thanks 
>>> to the JVM and Clojure. My intuition says that a very dedicated student 
>>> could probably produce a Clojure library to catch Church in terms of speed 
>>> by the end of the summer, simply by emulating what they have done and 
>>> letting pmap take care of the rest.  
>>> -Zack
>>>
>>> On Wednesday, April 24, 2013 12:48:56 AM UTC+4, David Nolen wrote:

 On Tue, Apr 23, 2013 at 2:10 PM, Radosław Piliszek 
 wrote:

> 1) Is this place the best to discuss this?
>

 Yes.
  

> 2) Are there some set goals that CLP(Prob) should achieve? (,,Basic 
> support of CLP(Prob).'' does not express it too well! :-P )
>

 This seems like a pretty challenging one as there are a variety of 
 possible approaches. Basic support for CLP(Prob) could very well mean 
 *several* prototypes. That said the probabilistic Prolog variants are 
 probably worthy of the most study as core.logic is closest to that model.
  

> 3) Is there any API sketch that should be followed? Is it still yet to 
> be discussed? And, most importantly, how would you see CLP(Prob) fit in 
> core.logic's ecosystem?
>

 There is no API sketch. It's extremely important to survey the links, 
 try out existing implementations, assess their advantages / disadvantages 
 and devise a syntax (or several) that works reasonably well with what 
 we've 
 already established in core.logic. 

 Of the projects listed this 

Re: Prismatic Plumbing and Graph Open-Source Release

[Edmund]

Hi Jason,

  That's roughly what I figured, thanks for the helpful reply.

Thanks for taking the time release this lib; its really great

Edmund

On Saturday, 9 February 2013 01:28:09 UTC, Jason Wolfe wrote:
>
>
>
> On Friday, February 8, 2013 1:56:27 AM UTC-8, Edmund wrote:
>>
>> Hey Jason,
>>
>>Going slightly OT here to describe my motivations, but you did ask
>> for more details ! :)
>>
>> I wrote a little blog post + lib last month using Stuart Sierra's Flow 
>> (much like
>> Graph) to implement the steps in doing a very simple discrete inference 
>> task.  Its
>> demonstrating the same thing you talk about in your post about
>> declarative computation - here the point is that you can efficiently 
>> update your
>> inference based new data on account of having the
>> graph structure to work over.  Here's the post 
>> http://boss-level.com/?p=160 and a
>> literate version of the code http://ejackson.github.com/inflow/
>> This is my original motivation.
>>
>
> I think I understand what you're trying to do from the example, thanks!
>  
>
>> What I'm doing there is 'building-up' the computation over time,
>> so I start with a graph with just the input data, and end up with a
>> graph with the input and output.  But the 'building up' is not the 
>> principal hangup I
>> have: I'm happy to have an in- and out- map.  The problem is, when
>> dealing with a very nested graph, getting a fine grained syntax for
>> describing where to put the outputs.  Ie how do I tell Graph to put just
>> the output x into
>> {:a {:b 1 :c x}} of the graph, without replacing the entire map of the :a 
>> key ?
>>
>
> Like I said earlier, it's a requirement of Graph that node names must be 
> unique, and distinct from top-level input keys. 
>
> Thus, there cannot be a way to 'put x into the map under :a at key :c' , 
> because there is no way to in-place modify the inputs or other node values 
> of the graph.  The output is just a map of all the node results, nothing 
> more and nothing less.
>
> That said, you can use a hierarchical graph to specify different node 
> functions for the different sub-keys:
>
> ;; As a hierarchical graph
> user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b) 
> :c (fnk [[:a1 b]] (inc b))}}) 
>{:a1 {:b 1}})
> {:a2 {:b 1, :c 2}}
>
> So for an example like the one you gave in the above link, you can 
> represent your nested stats directly as a nested graph without resorting to 
> key flattening.  And if you want to compute just a subset of the graph for 
> updated downstream values and then merge this into your previous map, you 
> can do this in two steps:
>
> 1.  Pick out the subset of leaf functions that may have changed, using the 
> same strategy you currently use with Flow, and construct a Graph with only 
> those sub-keys.  For example:
>
> user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b)}}) 
>{:a1 {:b 2}})
> {:a2 {:b 2}}
>
> , then 
>
> 2. deep-merge these results with the original result map.  
>
> i..e, (deep-merge-with (fn [x y] y) original-results updated-results)
> where deep-merge-with is 
> http://clojuredocs.org/clojure_contrib/clojure.contrib.map-utils/deep-merge-with
>
> This logic could be wrapped up into a single higher-order function that 
> takes a graph and knows how to incrementally update the results given 
> incremental changes in input.  Does that make sense / seem like it will 
> satisfy your need?
>
> Cheers, 
> Jason
>
>
>
>  
>
>> That's obviously no good if I need to have lots of things changing
>> beneath :a in a single graph flow due to uniqueness.[
>>
>> With Flow what I did is flatten the nested graph such that the keys are
>> vectors of the path to each node, run the flow on that graph, and then
>> re-nest the the graph afterwards (the flow-> and ->flow functions).
>> So the map {:a {:b 1 :c x}} becomes {[:a :b] 1, [:a :c] x}, and I can 
>> refer to
>> nested nodes this way.
>>
>> In Graph such a scheme would be possible too, but that Graph enforces
>> keywords as the keys for the graph.  Having vectors for the keys still
>> allows you to
>> have uniqueness, topological ordering etc.  So the example I gave in my
>> last email:
>>
>> {:a {:b 1}} -> {:a {:b 1, :c 2}}
>>
>> could, hypothetically, be written for just the outputs as
>>
>> ((graph/eager-compile {[:a :c] (fnk [[:a b]] (inc b))})
>>   {:a {:b 1}})
>>
>> >> {:a {:c 2}}
>>
&

Re: Prismatic Plumbing and Graph Open-Source Release

[Edmund]

Hey Jason,

   Going slightly OT here to describe my motivations, but you did ask
for more details ! :)

I wrote a little blog post + lib last month using Stuart Sierra's Flow 
(much like
Graph) to implement the steps in doing a very simple discrete inference 
task.  Its
demonstrating the same thing you talk about in your post about
declarative computation - here the point is that you can efficiently update 
your
inference based new data on account of having the
graph structure to work over.  Here's the post http://boss-level.com/?p=160 
and a
literate version of the code http://ejackson.github.com/inflow/
This is my original motivation.

What I'm doing there is 'building-up' the computation over time,
so I start with a graph with just the input data, and end up with a
graph with the input and output.  But the 'building up' is not the 
principal hangup I
have: I'm happy to have an in- and out- map.  The problem is, when
dealing with a very nested graph, getting a fine grained syntax for
describing where to put the outputs.  Ie how do I tell Graph to put just
the output x into
{:a {:b 1 :c x}} of the graph, without replacing the entire map of the :a 
key ?
That's obviously no good if I need to have lots of things changing
beneath :a in a single graph flow due to uniqueness.[

With Flow what I did is flatten the nested graph such that the keys are
vectors of the path to each node, run the flow on that graph, and then
re-nest the the graph afterwards (the flow-> and ->flow functions).
So the map {:a {:b 1 :c x}} becomes {[:a :b] 1, [:a :c] x}, and I can refer 
to
nested nodes this way.

In Graph such a scheme would be possible too, but that Graph enforces
keywords as the keys for the graph.  Having vectors for the keys still
allows you to
have uniqueness, topological ordering etc.  So the example I gave in my
last email:

{:a {:b 1}} -> {:a {:b 1, :c 2}}

could, hypothetically, be written for just the outputs as

((graph/eager-compile {[:a :c] (fnk [[:a b]] (inc b))})
  {:a {:b 1}})

>> {:a {:c 2}}

So my question is: how do I refer to nested nodes in the output
selector using Graph?  Conditionally, on that being impossible, would
there be any merit in the vector scheme that I have suggested ?

Sorry for the long post, I hope I haven't obscured my question. I also
get the feeling that I must be missing something very obvious in your
code for how to do this !

 Edmund


On Thursday, 7 February 2013 19:27:13 UTC, Jason Wolfe wrote:
>
> On Thu, Feb 7, 2013 at 10:54 AM, AtKaaZ > 
> wrote: 
> > Hello. 
> > 
> https://github.com/Prismatic/plumbing/blob/master/test/plumbing/graph_examples_test.clj#L148
>  
> > Why do they return in a map instead of maybe a set ? do we ever get 
> {:key 
> > false} ? 
> > Thanks. 
>
> The leaf value for output schemata is always 'true'.  It's a bit odd, 
> but to support specifications of functions/graphs that return nested 
> maps, the outer layers need to be maps.  It's true that the innermost 
> layers could be represented as sets, but we chose to keep things 
> uniform instead. 
>
> > 
> > 
> > On Thu, Feb 7, 2013 at 7:22 PM, Jason Wolfe > 
> wrote: 
> >> 
> >> We've just posted a blog post with more high-level context on what 
> we're 
> >> trying to accomplish with Graph (plus more examples!) 
> >> 
> >> 
> >> 
> http://blog.getprismatic.com/blog/2013/2/1/graph-abstractions-for-structured-computation
>  
> >> 
> >> We're also answering questions and reading comments in the Hacker News 
> >> thread, if that's your thing: 
> >> 
> >> http://news.ycombinator.com/item?id=5183236 
> >> 
> >> Cheers, Jason 
> >> 
> >> 
> >> On Tuesday, January 29, 2013 10:46:54 AM UTC-8, Aria Haghighi wrote: 
> >>> 
> >>> Hey all, 
> >>> 
> >>>  Prismatic has open-sourced our Plumbing and Graph library on github. 
> >>> Jason Wolfe gave a talk about how we use graph for systems composition 
> at 
> >>> Strange loop last year. Please give the library 
> >>> a whirl and let us know if you're using it and if you find any issues 
> or 
> >>> feature requests. We use this library very heavily throughout our code 
> and 
> >>> hope others find it useful as well. 
> >>> 
> >>>  Best, Aria 
> >> 
> >> -- 
> >> -- 
> >> 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 n

Re: Prismatic Plumbing and Graph Open-Source Release

[Edmund]

Hey Jason,

Thanks for the suggestions.  Going slightly OT here to describe my 
motivations, but you did ask
for more details ! :)

I wrote a little blog post + lib last month using Stuart Sierra's Flow 
(much like
Graph) to implement the steps in doing a very simple discrete inference 
task.  Its
demonstrating the same thing you talk about in your post about
declarative computation - here the point is that you can efficiently update 
your
inference based new data on account of having the
graph structure to work over.  Here's the post http://boss-level.com/?p=160 
and a
literate version of the code http://ejackson.github.com/inflow/
This is my original motivation.

What I'm doing there is 'building-up' the computation over time,
so I start with a graph with just the input data, and end up with a
graph with the input and output.  But the 'building up' is not the 
principal hangup I
have: I'm happy to have an in- and out- map.  The problem is, when


On Thursday, 7 February 2013 16:51:31 UTC, Jason Wolfe wrote:
>
> Hi Edmund,
>
> Thanks for your interest.  There's actually no way to fill in ??? in your 
> example, because it's a requirement of Graph that node names must be 
> unique, and distinct from top-level input keys.  This ensures that the 
> Graph has a unique topological order, and it's always clear where the input 
> to a node comes from.  So we can't both treat :a as an input and an output. 
>  (Of course, we could always wrap the graph function to merge the inputs 
> in, but it still won't quite fit your example)
>
> Here are three ways to do something similar:
>
> ;; As a single fnk that returns an explicit map
> user> ((eager-compile {:a2 (fnk [[:a1 b]] {:b b :c (inc b)})}) 
>{:a1 {:b 1}})
> {:a2 {:b 1, :c 2}}
>
> ;; As a single fnk that modifies the input map
> user> ((eager-compile {:a2 (fnk [[:a1 b :as a1]] (assoc a1 :c (inc b)))}) 
>{:a1 {:b 1}})
> {:a2 {:c 2, :b 1}}
>
> ;; As a hierarchical graph
> user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b) 
> :c (fnk [[:a1 b]] (inc b))}}) 
>{:a1 {:b 1}})
> {:a2 {:b 1, :c 2}}
>
> Note that these all take input key :a1 and output :a2, to avoid a key 
> clash, and explicitly copy :b to the output.  If you give me some more 
> details about your use case I may be able to provide better advice.
>
> Hope this helps -- let me know if you have any questions.
>
> Cheers,
> Jason
>
> On Thursday, February 7, 2013 1:55:13 AM UTC-8, Edmund wrote:
>>
>> Hey Aria / Jason,
>>
>>   Thanks for OSing this library, its really useful.  One question: how do 
>> you deal with nesting on the output side of graph declaration ?  I 
>> understand it for fnk, but but how would I achieve:
>>
>> {:a {:b 1}} -> {:a {:b 1, :c 2}}
>>
>> with a single declaration:
>>
>> (graph/eager-compile
>>  {??? (fnk [[:a b]] (inc b))}
>>
>> where ??? is the binding form I'm after to describe the nesting ?  
>>
>> I'm currently doing this by breaking up my map and using update-in, but 
>> it seems you must have a sneaky trick to do this declaratively ?
>>
>> I figure [:a :c] would be an possible syntax ?
>>
>> Thanks again,
>>
>>  Edmund
>> On Tuesday, 29 January 2013 18:46:54 UTC, Aria Haghighi wrote:
>>>
>>> Hey all,
>>>
>>>  Prismatic has open-sourced our Plumbing and Graph library on 
>>> github<https://github.com/prismatic/plumbing>. 
>>> Jason Wolfe gave a 
>>> talk<http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop.html>about
>>>  how we use graph for systems composition at Strange loop last year. 
>>> Please give the library
>>> a whirl and let us know if you're using it and if you find any issues or 
>>> feature requests. We use this library very heavily throughout our code and 
>>> hope others find it useful as well.
>>>
>>>  Best, Aria
>>>
>>

-- 
-- 
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: Prismatic Plumbing and Graph Open-Source Release

[Edmund]

Hey Aria / Jason,

  Thanks for OSing this library, its really useful.  One question: how do 
you deal with nesting on the output side of graph declaration ?  I 
understand it for fnk, but but how would I achieve:

{:a {:b 1}} -> {:a {:b 1, :c 2}}

with a single declaration:

(graph/eager-compile
 {??? (fnk [[:a b]] (inc b))}

where ??? is the binding form I'm after to describe the nesting ?  

I'm currently doing this by breaking up my map and using update-in, but it 
seems you must have a sneaky trick to do this declaratively ?

I figure [:a :c] would be an possible syntax ?

Thanks again,

 Edmund
On Tuesday, 29 January 2013 18:46:54 UTC, Aria Haghighi wrote:
>
> Hey all,
>
>  Prismatic has open-sourced our Plumbing and Graph library on 
> github<https://github.com/prismatic/plumbing>. 
> Jason Wolfe gave a 
> talk<http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop.html>about
>  how we use graph for systems composition at Strange loop last year. 
> Please give the library
> a whirl and let us know if you're using it and if you find any issues or 
> feature requests. We use this library very heavily throughout our code and 
> hope others find it useful as well.
>
>  Best, Aria
>

-- 
-- 
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: maths, functions and solvers

[Edmund]

No, core.logic is not the answer here; numerical stuff is currently out of 
reach.

On Saturday, 26 May 2012 03:25:22 UTC+1, jlk wrote:
>
> Hi Zack
>
> I don't really know enough about core.logic to comment on this.  Brent 
> mentions symbolic math and it sounds neat but I'm more interested in 
> numerical solutions at the moment.
>
> Cheers
>
>
> On Saturday, May 26, 2012 10:45:09 AM UTC+10, Brent Millare wrote:
>>
>> I originally assumed core.logic would be the key to symbolic math, but 
>> now I feel that's not really the case. You still need to implement all the 
>> algebra manipulation algorithms as usual. One can define the numbers in a 
>> different way as Ambrose did in his talk, but I imagine we would need to 
>> have much different performance expectations when performing the other 
>> symbolic operations. That being said, I would like to see more work going 
>> into that type of implementation.
>>
>> On Thursday, May 24, 2012 8:37:57 PM UTC-4, Zack Maril wrote:
>>>
>>> Off topic:
>>> How hard would it be to build on 
>>> core.logicto do math 
>>> functions? 
>>> -Zack
>>>
>>>

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

Interaction of map->R and AOT compilation

[Edmund]

Hi Folks,

   It seems that map->R returns different types in the presence/absence of 
AOT classes.  I have constructed a minimal example here:

https://github.com/ejackson/aotquestion

The namespace in 
https://github.com/ejackson/aotquestion/blob/master/src/aots/core.clj is 
not AOT compiled and behaves as expected.
The namespace 
in https://github.com/ejackson/aotquestion/blob/master/src/aots/death.clj#L9 
is AOT compiled and the class returned by map->Dontwork is not as expected. 
(Turn off AOT and this expression becomes true).

Am I misunderstanding something here or is this a bug ?  

I'd really appreciate some help and advice.

 Edmund

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

Re: [ANN] Eastwood - A Clojure lint tool

[Edmund]

This is great, and working for me, thanks :)

On Thursday, 19 April 2012 14:04:07 UTC+1, Jonas wrote:
>
> Eastwood[1] is a Clojure lint tool which uses the analyze[2] library to 
> inspect
> namespaces and report possible problems. Currently it should work
> with projects running Clojure 1.3.0 and newer.
>
> Currently eastwood warns when it finds 
> - deprecated java instance methods, static fields, static methods and 
> constructors
> - deprecated clojure vars
> - unused function arguments
> - unused private vars
> - reflection
> - naked (:use ...)
> - misplaced docstrings
> - keyword typos
>
> I appreciate bug reports and feature requests and I also hope you find it 
> useful!
>
> Jonas
>
> [1] https://github.com/jonase/eastwood
> [2] https://github.com/frenchy64/analyze
>

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

Re: A New Core.logic Primer

[Edmund]

Righto, I'll add this to the discussion.

On Thursday, 15 March 2012 21:53:51 UTC, David Nolen wrote:
>
> On Thu, Mar 15, 2012 at 5:41 PM, Sean Corfield wrote:
>
>> On Thu, Mar 15, 2012 at 2:16 PM, Baishampayan Ghose  
>> wrote:
>> > There is run, but `run` takes an extra argument `n` and will solve for
>> > only `n` results while `run*` solves for all.
>>
>> Ah, OK. That makes sense. Perhaps that could be added to the primer?
>> (just curious: why not run-all?)
>>
>
> core.logic's core API matches as closely as possible the one provided by 
> the original Scheme miniKanren. While this may give core.logic a Scheme-y 
> flavor, I'm not willing to give up on the benefits, for example:
>
> https://github.com/webyrd/TAPL-in-miniKanren-cKanren-core.logic
>
> I agree we should probably mention run N.
>
> 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

Re: A New Core.logic Primer

[Edmund]

Hi Thorsten,

  Thanks for reading and the great feedback.  In response, yes lvars 
introduced by fresh stay 'inside' the run* which only returns the query 
lvar.  Your other comments are 100% correct and I will update the document 
to reflect them.

Thanks again,

  Edmund

On Thursday, 15 March 2012 09:44:35 UTC, thorwil wrote:
>
> On 03/14/2012 08:00 PM, David Nolen wrote:
> > Thanks to Edmund Jackson we have a new primer for core.logic:
> > https://github.com/clojure/core.logic/wiki/A-Core.logic-Primer
> >
> > Feedback appreciated!
>
> Hi!
>
> Does a run* expression evaluate to only the query-variable, while lvars 
> introduced with fresh stay internal?
>
>
> "Finally we unify a and q leaving both with the value of their 
> intersection: (1, 2, 3) intersection (3, 4, 5), (3)"
> I stumbled over this sentence because of the "(1, 2, 3) intersection (3, 
> 4, 5), (3)" part. Sudden use of infix, with the result after a comma? 
> Just writing (3) would be clearer.
>
>
> Regarding conde, I had to reread that section carefully. Consider to 
> first explain conde with single-goal clauses, to then mention that each 
> clause is actually a list of goals with AND-logic (simple case first, 
> expand afterwards).
>
>
> In the "Conso (the Magnificent)" section, use of "return" inside of the 
> code blocks is inconsistent with the rest of the article.
>
> I do not understand the explanations to the last 2 examples, even though 
> I think I understand the logic. The use of list [1] and list [2] is not 
> easy to read, how about writing out first and second list?
>
> I would think that:
>
>(run* [q]
>  (conso q [2 3] [1 2 3]))
>
> returns (1); q is the element that when added as head to the first list, 
> results in a list equal to the second list (if such an element exists).
>
>(run* [q]
>  (conso 1 [2 q] [1 2 3]))
>
> returns (3); q is the element of the first list that when 1 is added as 
> head to the first list results in a list equal to the second list (if 
> such an element exists).
>
> So conso constraints whatever lvars are present in an attempt to unify 
> the cons of its first 2 arguments with its third argument, restricting 
> the arguments to be atom-or-list, list, list?
>
>
> Otherwise an enlightening and inspiring read, thank you!
>
>
> -- 
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.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

Re: EuroClojure 2012: CfP open

[Edmund]

On 31/01/2012 17:07, Marco Abis wrote:
> Hi all,
> 
> after quite some time working on this I'm excited to announce "the
> first 2-day, full-blown conference in Europe for the Clojure 
> community" to be held in London (England) on May 24-25. The
> conference will be preceded by a 3-day training class delivered by
> the good guys from Relevance :-)
> 
> The Call for Presentations is now open, all the details and the
> form here: http://euroclojure.com/2012/call-for-presentations/
> 
> Looking forward to it, for any info please do not hesitate to
> contact me
> 
> Regards
> 

Magic !

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

Re: Logic program and hierarchical data

[Edmund]

Hi Base,

In Dave Nolen's tutorial:
https://github.com/swannodette/logic-tutorial there is a section on
genealogy in which he composes child and child to create grandchild.
Seems similar, maybe helpful ?

 Edmund

On 24/01/2012 01:35, Base wrote:
> Hi -
> 
> I am attempting to model some hierarchical data for use in my
> first logic program and am having some problems understanding how
> to create a “typeof?” relationship with my data.
> 
> Defining parent child is easy enough of course; however I would
> like to design a generic way of defining a subclass or superclass
> such that, given some set of hierarchical data, for example:
> 
> Domain - Eukarya Kingdom - Animalia/Metazoa Phylum - Chordata Class
> - Mammalia Order - Primate Family - Hominidae Genus - Homo Species
> - Homo sapiens
> 
> (typeof? “Mammalia” “Eukarya”)  and (typeof? “Primate” “Eukarya”)
> and (typeof? “Hominidae” Eukarya”)
> 
> all are true using the same mechanism without having to explicitly 
> define the order one by one like:
> 
> (defrel typeof? p c) (fact typeof? “Homo”  “Homo sapiens”) (fact
> typeof? “Hominidae” “Homo sapiens”) (fact typeof? “Primate” “Homo
> sapiens”) (fact typeof? “Mammalia” “Homo sapiens”) ...
> 
> Any help getting started on this would be most appreciated! 
> 
Thanks!
> 
> Base
> 

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

Re: Can't get the debugger cdt run

[Edmund]

Chris, that's not fatal.  Mine works just fine despite the warning.

On 03/12/2011 11:29, Chris Perkins wrote:
> On Saturday, December 3, 2011 12:16:43 AM UTC-5, Sean Corfield
> wrote:
> 
> On Fri, Dec 2, 2011 at 12:37 PM, George Jahad 
>  wrote:
>> The easiest way to use cdt is from emacs, as described here: 
>> http://georgejahad.com/clojure/swank-cdt.html
> 
> 
> Could you add a note to clarify that connecting "as usual" to a
> swank server is via the Emacs slime-connect command since I had to
> ask on IRC?
> 
> This is the first time I've tried CDT and I have to say, I'm very 
> impressed with how easy it is to use! Thank you!! --
> 
> So I guess you didn't get this error then?
> 
> user> (require '[swank.cdt :as d]) warning: unabled to add
> tools.jar to classpath. This may cause CDT initialization to fail.
> 
> Anyone know how to fix that?
> 
> - Chris
> 
> -- 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 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

Re: [ANN] Avout: Distributed State in Clojure

[Edmund]

That's the ticket!  Thanks David, its working for me now.

On 01/12/2011 17:21, David Edgar Liebke wrote:
> (init-stm client)

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

Re: [ANN] Avout: Distributed State in Clojure

[Edmund]

Hey Sam & Dave,

I'm following along at home.  I followed David's advice and there's
no change.  FWIW here's the client datastructure and the exception
stacktrace:

#

java.lang.IllegalArgumentException: Path must not end with / character
at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:58)
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1025)
at zookeeper$set_data.doInvoke(zookeeper.clj:394)
at clojure.lang.RestFn.invoke(RestFn.java:470)
at avout.transaction$update_txn_state.invoke(transaction.clj:82)
at avout.transaction$stop$fn__2604.invoke(transaction.clj:239)
at avout.transaction$stop.invoke(transaction.clj:238)
at
avout.transaction.LockingTransaction$fn__2617.invoke(transaction.clj:321)
at
avout.transaction.LockingTransaction.runInTransaction(transaction.clj:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:92)
at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:30)
at avout.transaction$run_in_transaction.invoke(transaction.clj:354)
at avout.core$zk_ref.doInvoke(core.clj:51)
at clojure.lang.RestFn.invoke(RestFn.java:445)
at clojure.lang.AFn.applyToHelper(AFn.java:167)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3337)
at clojure.lang.Compiler$DefExpr.eval(Compiler.java:375)
at clojure.lang.Compiler.eval(Compiler.java:6470)
at clojure.lang.Compiler.eval(Compiler.java:6431)
at clojure.core$eval.invoke(core.clj:2795)
at swank.commands.basic$eval_region.invoke(basic.clj:47)
at swank.commands.basic$eval_region.invoke(basic.clj:37)
at
swank.commands.basic$eval760$interactive_eval__761.invoke(basic.clj:66)
at clojure.lang.Var.invoke(Var.java:401)
at tavout.core$eval2926.invoke(NO_SOURCE_FILE)
at clojure.lang.Compiler.eval(Compiler.java:6465)
at clojure.lang.Compiler.eval(Compiler.java:6431)
at clojure.core$eval.invoke(core.clj:2795)
at swank.core$eval_in_emacs_package.invoke(core.clj:92)
at swank.core$eval_for_emacs.invoke(core.clj:239)
at clojure.lang.Var.invoke(Var.java:409)
at clojure.lang.AFn.applyToHelper(AFn.java:167)
at clojure.lang.Var.applyTo(Var.java:518)
at clojure.core$apply.invoke(core.clj:600)
at swank.core$eval_from_control.invoke(core.clj:99)
at swank.core$spawn_worker_thread$fn__493$fn__494.invoke(core.clj:298)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.core$apply.invoke(core.clj:600)
at swank.core$spawn_worker_thread$fn__493.doInvoke(core.clj:294)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:680)


Edmund

On 01/12/2011 15:39, David Edgar Liebke wrote:
> Hi Sam,
>
>> run-in-transaction exception:  #> java.lang.IllegalArgumentException: Path must not end with / character> nil 
> Very interesting, I wouldn't expect that particular exception unless you 
> named the zk-ref "/r0/" instead of "/r0", which you apparently didn't. 
>
> And even when I do call it "/r0/" I get the "Path must not end with / 
> character" exception at a different point in the code, which is probably the 
> result of a patch I added to zookeeper-clj yesterday. 
>
> Can you try deleting the zookeeper-clj jar file from your dependencies, 
> blowing about your ~/.m2/repository/zookeeper-clj directory, reloading your 
> deps, and trying again?
>
> David
>
>
> On Dec 1, 2011, at 10:04 AM, Sam Aaron wrote:
>
>> Hi David,
>>
>> I'm super excited by Avout. It seems *better* than magic in that it not only 
>> appears to make complicated things possible, but also in a conceptually 
>> transparent way. Crazy cool.
>>
>> I'm about to look into this in detail, but I thought I'd just post an issue 
>> I'm having with the basic example just on the off-chance that I'm doing 
>> something obviously wrong.
>>
>> I have zookeeper 3.3.3 installed running on port 2181 with a valid dataDir 
>> path with the appropriate permissions. I'm got avout 0.5.0 and in a REPL 
>> session I do the following:
>>
>> ; SLIME 2009-10-15   
>> 
>> user> (use 'avout.core)  

Re: [ANN] Avout: Distributed State in Clojure

[Edmund]

Hey David,

   I get an identical exception here here w/ zookeeper version
3.2.2.   Because I'm crazy that way I also tried to call the ref "/r0/" 
(just to see) and the exception came up.  However it was different in
that with "/r0/" I got the usual exception handling in emacs, whereas
with "/r0" it just reported the exception in the repl, and then returned
nil.

 Edmund

On 01/12/2011 15:04, Sam Aaron wrote:
> Hi David,
>
> I'm super excited by Avout. It seems *better* than magic in that it not only 
> appears to make complicated things possible, but also in a conceptually 
> transparent way. Crazy cool.
>
> I'm about to look into this in detail, but I thought I'd just post an issue 
> I'm having with the basic example just on the off-chance that I'm doing 
> something obviously wrong.
>
> I have zookeeper 3.3.3 installed running on port 2181 with a valid dataDir 
> path with the appropriate permissions. I'm got avout 0.5.0 and in a REPL 
> session I do the following:
>
> ; SLIME 2009-10-15
>
> user> (use 'avout.core)   
> 
> nil   
> 
> user> (def client (connect "127.0.0.1"))  
>
> #'user/client 
> 
> user> (def r0 (zk-ref client "/r0" 0))
>
> run-in-transaction exception:  # java.lang.IllegalArgumentException: Path must not end with / character> nil 
> #'user/r0 
> 
> user> r0  
>
> # 
> 
> user> @r0 
> 
> nil   
>
>
> Sam
>
> ---
> http://sam.aaron.name
>
>  
> On 29 Nov 2011, at 17:38, liebke wrote:
>
>> Today we are releasing Avout, which brings Clojure's in-memory model
>> of state to distributed application development by providing a
>> distributed implementation of Clojure's Multiversion Concurrency
>> Control (MVCC) STM along with distributable, durable, and extendable
>> versions of Clojure's Atom and Ref concurrency primitives.
>>
>> Here's the post announcing the project: 
>> http://clojure.com/blog/2011/11/29/avout.html
>>
>> And here's the project's website: http://avout.io
>>
>>
>> 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 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

Re: Drift 1.4.0 released.

[Edmund]

Confirmed, 1.4.2-SNAPSHOT works with 1.3.0 now, thanks for the help.

 Edmund


On 27/11/2011 16:23, Matt wrote:
> I just sent you a pull request to fix the Clojure 1.3 incompatibility.
>
> Also, you may want to use the current-version and update-version
> functions in drift-db.migrate instead of your own home grown
> functions. Though you would have to create your own initialize
> function to initialize the drift-db flavor to mysql.
>
> -Matt
>
> On Nov 27, 9:25 am, Edmund  wrote:
>> Bingo!  Thanks for that, version 1.3.0 incompatibility it is.
>>

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

Re: Drift 1.4.0 released.

[Edmund]

Bingo!  Thanks for that, version 1.3.0 incompatibility it is.

On 27/11/2011 13:41, Chris Perkins wrote:
> My guess would be a clojure version mismatch, based on the
> stacktrace. Have you tried changing your project to use clojure
> 1.2.1?
> 
> - Chris
> 
> -- 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 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

Re: Drift 1.4.0 released.

[Edmund]

Sadly, there is no improvement.  I've made a minimal project to
demonstrate.  Literally

- lein new tdrift
- modify project.clj
- add migration-config.clj
- add appropriate migration directory
- lein deps
- lein create-migration

I've put it up on github (https://github.com/ejackson/tdrift).
Perhaps if we can git it to work we can get to the bottom of this ?

Thank for the help here,

 Edmund



On 27/11/2011 00:39, Matt wrote:
> It looks like a bug in Drift. Try adding an init function which
> takes one argument but doesn't do anything.
> 
> Your new migrate-config should look something like:
> 
> (defn migrate-config [] {:init (fn [_] ) :directory
> "/db/migrations" :current-version db-version :update-version
> update-db-version})
> 
> Let me know if that does the trick and I'll fix the bug in Drift.
> 
> 
> On Nov 26, 8:31 am, Edmund  wrote:
>> Hello,
>> 
>> Thanks for this library, it'll really help me out.  I'm a little 
>> stuck on getting bootstrapped, can you perhaps give me some
>> guidance ? Basically I'm stuck at step 5, attempting to create my
>> first migration, what am I missing ?
>> 
>> Thanks,
>> 
>> Edmund
>> 
>> -
>>
>> 
Steps taken
>> 1.  Added to :dev-dependencies in project.clj [drift "1.4.0"] 
>> [org.drift-db/drift-db-mysql "1.0.4"]
>> 
>> 2. Created a table to hold the version number inserted 0 create
>> table schema_migrations ( version int not null primary key )
>> engine InnoDB;
>> 
>> 3. Created src/config/migrate_config.clj (ns
>> config.migrate-config (:require [clojure.contrib.sql :as sql]))
>> 
>> (defonce DB (atom {:classname "com.mysql.jdbc.Driver" 
>> :subprotocol "mysql" :subname "//mysql-server:3306/bookkeeper" 
>> :user "user" :password "password" :auto-commit true :fetch-size
>> 500}))
>> 
>> (defn db-version [] (sql/with-connection DB 
>> (sql/with-query-results res ["select version from
>> schema_migrations limit 1"] (:version (first res)
>> 
>> (defn update-db-version [version] (sql/with-connection DB 
>> (sql/insert-values :schema_migrations [:version] [version])))
>> 
>> (defn migrate-config [] {:directory "/db/migrations" 
>> :current-version db-version :update-version update-db-version})
>> 
>> 4. Run lein deps to grab the deps
>> 
>> 5. Attempted to create a migration, or get something going
>> 
>> $ lein create-migration first Listening for transport dt_socket
>> at address: 57528 Exception in thread "main"
>> java.lang.RuntimeException: java.lang.NoSuchMethodError: 
>> clojure.lang.KeywordLookupSite.(ILclojure/lang/Keyword;)V 
>> at clojure.lang.Util.runtimeException(Util.java:165) at
>> clojure.lang.Compiler.eval(Compiler.java:6476) at
>> clojure.lang.Compiler.eval(Compiler.java:6455) at
>> clojure.lang.Compiler.load(Compiler.java:6902) at
>> clojure.lang.RT.loadResourceScript(RT.java:357) at
>> clojure.lang.RT.loadResourceScript(RT.java:348) at
>> clojure.lang.RT.load(RT.java:427) at
>> clojure.lang.RT.load(RT.java:398) at
>> clojure.core$load$fn__4610.invoke(core.clj:5386) at
>> clojure.core$load.doInvoke(core.clj:5385) at
>> clojure.lang.RestFn.invoke(RestFn.java:408) at
>> clojure.core$load_one.invoke(core.clj:5200) at
>> clojure.core$load_lib.doInvoke(core.clj:5237) at
>> clojure.lang.RestFn.applyTo(RestFn.java:142) at
>> clojure.core$apply.invoke(core.clj:602) at
>> clojure.core$load_libs.doInvoke(core.clj:5271) at
>> clojure.lang.RestFn.applyTo(RestFn.java:137) at
>> clojure.core$apply.invoke(core.clj:602) at
>> clojure.core$require.doInvoke(core.clj:5352) at
>> clojure.lang.RestFn.invoke(RestFn.java:421) at
>> drift.generator$eval5$loading__4505__auto6.invoke(generator.clj:1)
>>
>> 
at drift.generator$eval5.invoke(generator.clj:1)
>> at clojure.lang.Compiler.eval(Compiler.java:6465) at
>> clojure.lang.Compiler.eval(Compiler.java:6455) at
>> clojure.lang.Compiler.load(Compiler.java:6902) at
>> clojure.lang.RT.loadResourceScript(RT.java:357) at
>> clojure.lang.RT.loadResourceScript(RT.java:348) at
>> clojure.lang.RT.load(RT.java:427) at
>> clojure.lang.RT.load(RT.java:398) at
>> clojure.core$load$fn__4610.invoke(core.clj:5386) at
>> clojure.core$load.doInvoke(core.clj:5385) at
>> clojure.lang.RestFn.invoke(RestFn.java:408) at
>> clojure.core$load_one.invoke(core.clj:5200) at
>> clojure.core$load_lib.doInvoke(c

Re: [ANN] Drift 1.4.0 released.

[Edmund]

Hello,

Thanks for this library, it'll really help me out.  I'm a little
stuck on getting bootstrapped, can you perhaps give me some guidance ?
 Basically I'm stuck at step 5, attempting to create my first
migration, what am I missing ?

Thanks,

 Edmund


-
Steps taken
1.  Added to :dev-dependencies in project.clj
  [drift "1.4.0"]
  [org.drift-db/drift-db-mysql "1.0.4"]

2. Created a table to hold the version number inserted 0
create table schema_migrations (
   version int not null primary key
) engine InnoDB;

3. Created src/config/migrate_config.clj
(ns config.migrate-config
  (:require [clojure.contrib.sql :as sql]))

(defonce DB (atom {:classname "com.mysql.jdbc.Driver"
   :subprotocol "mysql"
   :subname "//mysql-server:3306/bookkeeper"
   :user "user"
   :password "password"
   :auto-commit true
   :fetch-size  500}))

(defn db-version []
  (sql/with-connection DB
(sql/with-query-results res
  ["select version from schema_migrations limit 1"]
  (:version (first res)

(defn update-db-version [version]
  (sql/with-connection DB
(sql/insert-values :schema_migrations [:version] [version])))

(defn migrate-config []
  {:directory "/db/migrations"
   :current-version db-version
   :update-version update-db-version})

4. Run lein deps to grab the deps

5. Attempted to create a migration, or get something going

$ lein create-migration first
Listening for transport dt_socket at address: 57528
Exception in thread "main" java.lang.RuntimeException:
java.lang.NoSuchMethodError:
clojure.lang.KeywordLookupSite.(ILclojure/lang/Keyword;)V
at clojure.lang.Util.runtimeException(Util.java:165)
at clojure.lang.Compiler.eval(Compiler.java:6476)
at clojure.lang.Compiler.eval(Compiler.java:6455)
at clojure.lang.Compiler.load(Compiler.java:6902)
at clojure.lang.RT.loadResourceScript(RT.java:357)
at clojure.lang.RT.loadResourceScript(RT.java:348)
at clojure.lang.RT.load(RT.java:427)
at clojure.lang.RT.load(RT.java:398)
at clojure.core$load$fn__4610.invoke(core.clj:5386)
at clojure.core$load.doInvoke(core.clj:5385)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5200)
at clojure.core$load_lib.doInvoke(core.clj:5237)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_libs.doInvoke(core.clj:5271)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$require.doInvoke(core.clj:5352)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at 
drift.generator$eval5$loading__4505__auto6.invoke(generator.clj:1)
at drift.generator$eval5.invoke(generator.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6465)
at clojure.lang.Compiler.eval(Compiler.java:6455)
at clojure.lang.Compiler.load(Compiler.java:6902)
at clojure.lang.RT.loadResourceScript(RT.java:357)
at clojure.lang.RT.loadResourceScript(RT.java:348)
at clojure.lang.RT.load(RT.java:427)
at clojure.lang.RT.load(RT.java:398)
at clojure.core$load$fn__4610.invoke(core.clj:5386)
at clojure.core$load.doInvoke(core.clj:5385)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5200)
at clojure.core$load_lib.doInvoke(core.clj:5237)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_libs.doInvoke(core.clj:5271)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$require.doInvoke(core.clj:5352)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at user$eval1.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6465)
at clojure.lang.Compiler.eval(Compiler.java:6454)
at clojure.lang.Compiler.eval(Compiler.java:6431)
at clojure.core$eval.invoke(core.clj:2795)
at clojure.main$eval_opt.invoke(main.clj:296)
at clojure.main$initialize.invoke(main.clj:315)
at clojure.main$null_opt.invoke(main.clj:348)
at clojure.main$main.doInvoke(main.clj:426)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:405)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:518)
at clojure.main.main(main.java:37)
Caused by: java.lang.NoSuchMethodError:
clojure.lang.KeywordLookupSite.(ILclojure/lang/Keyw

Re: Clojure Conj extracurricular activities spreadsheet

[Edmund]

Please add me to:

 - ClojureScript
 - core.logic/miniKanren
 - Heroku Drinkup
 - Literate Programming

Thanks.

On 26/10/2011 03:25, Michael Fogus wrote:
> We built quite a large list before the internet graffiti started 
> taking over, so if you have an addition then please post it here
> and it'll be added.
> 

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

Re: Async Requests in ClojureScript

[Edmund]

Hi Base,

I have a super basic example of this on my blog at
http://boss-level.com/?p=119  It should get you over this hump.

Gimme a shout if you have problems,

Edmund

On 16/08/2011 19:08, Base wrote:
> Hi All -
> 
> I am attempting to get started in ClojureScript and am completely 
> flummoxed on getting my connectivity set up.
> 
> I have a web server running on my local machine such that
> 
> http://localhost:8080/m
> 
> yields my data correctly (just a test URL...)
> 
> I am attempting to connect using the following cljs
> 
> (ns hello.foo.dat (:require [goog.net.XhrIo :as gxhr] [goog.Uri :as
> uri] [cljs.reader :as reader]))
> 
> (defn- extract-response [message] (reader/read-string (.
> message/target (getResponseText
> 
> (defn get-data [_] (gxhr/send (goog.Uri. "http://localhost:8080/m";)
> extract-response))
> 
> However when I attempt to execute this function in the browser I get 
> 'undefined' returned. Anything you can see here that I am doing
> wrong?  This does appear to execute correctly (i.e. the function is
> called, as a hard coded return string does return correctly)
> 
> Any help is most welcomed!
> 
> Thanks,
> 
> Base
> 

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

Re: ANN: Optimized Pattern Matching Library for Clojure

[Edmund]

That's a great explanation Baishampayan, thanks !

 Edmund

On 09/08/2011 10:43, Baishampayan Ghose wrote:
>> Do you happen to have any simple descriptions/examples of where and
>> how we might use this stuff in our daily programming repertoires? I
>> for one am sure I'm not educated enough as to the value and utility
>> of pattern matching - at the moment I just think "that looks cool"
>> rather than "I'm definitely going to use that to do X and Y".
> 
> To me pattern matching is the bee's knees :) If you have a lot of 
> functions where you check the input for some certain type of value
> and then perform some action depending on the value(s), then pattern 
> matching can be very useful. It's used extensively in Erlang and 
> Haskell among others.
> 
> For example, say you have a function `decide` -
> 
> (defn decide "A very simple example using cond" [x y] (cond (= x
> :foo) (do-foo y) (= x :bar) (do-bar y) :else (do-default y)))
> 
> I expect two arguments x & y and depending on the value of `x`, I 
> would like to call the functions `do-foo`, `do-bar` or `do-default` 
> with the value of `y`.
> 
> See how the code is riddled with the conditional checks and my 
> business logic (the part I care the most about). Using 
> pattern-matching, I can write the above code a bit more succinctly 
> like this -
> 
> (defn decide "A very simple example using match" [x y] (match [x y] 
> [:foo arg] (do-foo arg) [:bar arg] (do-bar arg) [_ arg] (do-default
> arg)))
> 
> The above code is *much* clearer and conveys the exact logic that I
> am trying to implement. Internally `match` will rewrite the above to
> an optimised bit of code which uses `cond`.
> 
> If I am feeling adventurous, I can write a simple macro which will
> let me define the same function in an even more succinct manner like
> this -
> 
> (defm decide "A very simple example" ([:foo arg] (do-foo arg)) ([:bar
> arg] (do-bar arg)) ([_ arg] (do-default arg)))
> 
> A sample implementation of the `defm` macro used above could be 
> something like this (UNTESTED!) -
> 
> (defmacro defm [name & fdecl] (let [m (if (string? (first fdecl)) 
> {:doc (first fdecl)} {}) fdecl (if (string? (first fdecl)) (next
> fdecl) fdecl) argcount (count (ffirst fdecl)) args (vec (repeatedly
> argcount (partial gensym "arg__"))) body (apply concat (for [decl
> fdecl] (if (nnext decl) (cons (first decl) (list (cons `do (next
> decl decl)))] `(defn ~name ~m ~args (match ~args ~@body
> 
> It's even more awesome when you bring in complex maps, etc. into the
> picture.
> 
> I personally believe that David and Ambrose are doing some
> incredible work with match & core.logic; these two projects will
> prove be extremely useful in the future.
> 
> Regards, BG
> 

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

Re: RIncater

[Edmund Jackson]

Hey Ulises,

Sortof.  The original author is updating thing so that they work more 
cleanly.  In the interim if you want to get it to work modify the project.clj 
to look like this: https://gist.github.com/962673.  Then comes the hard bit.  
The JRI uses native libraries that upon compilation seem to hardlink in the 
directory in which the R dynamic libs are saught.  So you either have to make a 
static link R/Versions/ that points 2.10 to the Current.  Or, and this is 
better, download JRI: http://www.rforge.net/JRI/snapshot/JRI_0.5-1.tar.gz then 
compile up the dynamic libs (thus hardlinking your machine) and move them to 
the appropriate subdirectory of ./native in your clojure project and you should 
be good to go.

 Edmund


On 20 May 2011, at 22:25, Ulises wrote:

> Hi,
> 
> Is RIncanter still alive?
> 
> Cheers,
> 
> U
> 
> -- 
> 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 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

Re: Where's incanter chrono?

[Edmund Jackson]

I think the code has been under development and is now here: 
https://github.com/getwoven/clj-time as clj-time.

On 8 May 2011, at 05:53, Andreas Kostler wrote:

> Hello all,
> Has incanter.chrono disappeared?
> (use '(incanter core chrono))
> results in
> Could not locate incanter/chrono__init.class or incanter/chrono.clj on
> classpath:
>  [Thrown class java.io.FileNotFoundException]
> 
> For both incanter 1.2.3 and incanter 1.2.2
> 
> Cheers
> Andreas
> 
> -- 
> 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 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

Re: Simple things should be simple

[Edmund Jackson]

You assume the presence of a configured web server but not a text editor ?
The only constructive thing I can say is that the set of things that may be
considered simple in the clojure setup above is vastly greater than the
alternative you present.  If the cost is a 4 line 'boilerplate' (and I'm
pointedly not going to compare that to /etc/apache/conf.d) I think its a low
price.

On Thu, Sep 9, 2010 at 4:47 PM, Mike Meyer  wrote:

> On Thu, 9 Sep 2010 16:28:48 +0100
> Edmund Jackson  wrote:
>
> > Hi Mike,
> >
> > Could you perhaps present a counter-example of greater simplicity ?
>
> $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh
> #!/bin/sh
>
> echo 'Content-type: text/plain\n'
> echo Hello World
> ^D
> $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh
>
> Done. Three lines of source code. 0 lines of framework setup. 1 tool
> (sh). Pretty much the same thing works for python, perl, etc.  It's
> about as robust as can be asked for - that's the nature of
> apache. Performance is going to be mediocre at best. That's the
> trade-off for simplicity.
>
>   --
> Mike Meyer 
> http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>

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

Re: Simple things should be simple

[Edmund Jackson]

Hi Mike,

Could you perhaps present a counter-example of greater simplicity ?

Edmund

On Thu, Sep 9, 2010 at 4:03 PM, Mike Meyer <
mwm-keyword-googlegroups.620...@mired.org> wrote:

> On Thu, 9 Sep 2010 07:46:22 -0700 (PDT)
> Meikel Brandmeyer  wrote:
>
> > Hi,
> >
> > I don't know what the full definition of "deploy" is, but here is an
> > example, that should serve as a starting point: http://m.3wa.com/?p=472
>
> That's a good example of simple things not being simple.
>
> Before I've seen a single line of code, I see I need to create an
> order of magnitude more lines of boilerplate than lines of code in the
> application using a framework that makes simple things simple.
>
>--
> Mike Meyer 
> http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
> --
> 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 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

Re: Trying to write idiomatic clojure to create vector of vectors

[Edmund Jackson]

Hi,

Some time back Lau Jensen blogged something like this.  Its starts here 

http://www.bestinclass.dk/index.clj/2009/10/brians-functional-brain.html

but there are at least two follow ups.  It might spark inspiration if you've 
not yet read it.

 Edmund


On 22 Jul 2010, at 13:37, Rising_Phorce wrote:

> I'm coming from an imperative background and trying to stay away from
> "for loops" to do the task at hand.  Given a size, I want to create a
> vector of vectors to represent a game board similar to Rich's ants or
> Conway's Game of Life (no wrapping necessary for me).  A couple of
> questions.  I will need to traverse the vectors sequentially but at
> each step there will be lots of sequential back and forward tracking.
> Arrays would be the natural imperative choice, but the docs recommend
> this only for inter-op.  So are vectors the best choice?
> 
> Secondly, I figured out how to create a row (a vector of length
> 'size'):  (defn make-row [size] (vec (take size (repeat nil
> 
> but I can't figure out how to conj 'size' calls to make-row onto
> another empty vector.
> 
> I've tried 'map', but then I need a data structure of length 'size' to
> iterate
> 
> I've looked at 'doTimes', but haven't been successful in figured out
> how to make it work for 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 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

Re: Getting Clojure into the workplace, how do you do it?

[Edmund Jackson]

An exercise in declarative programming...

On 6 Jul 2010, at 17:15, Wilson MacGyver wrote:

> my story isn't a very interesting one. I simply told everyone on the team to
> learn it, because we are going to use it :)
> 
> On Tue, Jul 6, 2010 at 4:50 AM, Nick Mudge  wrote:
>> One of the things I like about Clojure is it is a way to get lisp and
>> functional programming into workaday programming work; into the many
>> places and businesses that use Java.
>> 
>> I'd be very interested to hear stories or experiences of getting
>> Clojure into the workplace and how it was done. That is, convincing
>> customers and business people and other programmers that it is okay
>> that you start doing your work in Clojure in your job. And similar
>> such experiences.
> -- 
> Omnem crede diem tibi diluxisse supremum.
> 
> -- 
> 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

  Edmund





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

Re: bioinformatics toolkit in clojure: what would that look like?

[Edmund Jackson]

Hi Jan,

Perhaps R's excellent bioconductor project could be mapped nicely into 
Incanter (Clojure's R) ? 

Edmund

On 27 Jun 2010, at 23:15, jandot wrote:

> Hi all,
> 
> I have been a ruby user for several years and have contributed to the
> bioruby toolkit for bioinformatics. Lately however I got interested in
> clojure as it's a functional language and should be very good for
> working with the huge datasets we have to handle.
> 
> Although there are bioinformatics toolkits for many OO languages
> (biojava, bioperl, biopython and bioruby), nothing similar exists for
> clojure yet. And I'd be interested to start building such toolkit
> while I learn the language. At first for my own use, but maybe
> later... who knows.
> 
> Being new to functional languages, I wonder how such a toolkit would
> be best approached. In an OO language you create classes with
> properties and methods that describe one particular entitiy in the
> field. For example: you define a DNASequence class with a "name" and
> "sequence" property, and a method to print it out in an international
> standard text format, and another method for translating the DNA
> sequence in that of the resulting protein. Much of the functionality
> of these toolkits is about retrieving a bit of information,
> manipulating it and ultimately writing it to screen/file.
> 
> As functional languages are more about verbs than nouns: how could a
> bioinformatics toolkit be idiomatically set up? Would it still be the
> Right Way (TM) to create some type of classes, a-la OO?
> 
> For more information on the OO toolkits, see www.bioperl.org, www.biojava.org,
> bioruby.org and biopython.org.
> 
> As clojure (especially combined with incanter) seems to be a very good
> candidate for future work in bioinformatics, I would very much welcome
> a little discussion on this.
> 
> Many thanks,
> jan.
> 
> -- 
> 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

  Edmund





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

Accessing final methods of superclass using :gen-class

[Edmund]

Hello,

   I'm attempting to use some java classes in clojure, where I need
the clojure to be AOT compiled.  I'm running into trouble with
accessing final methods in the superclass of genclass.  Some code:

--= Hello.java =
package com.example;
public class Hello {
public void hello() {
System.err.println("Hello, World!");
}

protected final void yo() {
System.err.println("Yo, World!");
}
}

--= HelloWorld.clj =--
(ns com.example.HelloWorld
  (:gen-class
   :extends com.example.Hello
   :methods [[go [] void]]
   :exposes-methods {yo yoSuper}))

(defn -go [this]
  (.yoSuper this))



In this case I cannot access the "protected final void yo()" in the
Hello class with the clojure code.  Now I'm not trying to override the
method myself, but is the :exposes-methods doing so under the hood ?
If so how do I get around this ?

Thanks for your help,

   Edmund

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

Re: Understanding lazy-seq

[Edmund Jackson]

Wow - thanks everybody.

On 13 Apr 2010, at 14:32, Rich Hickey wrote:

> 
> 
> On Apr 12, 7:53 pm, Stuart Halloway  wrote:
>> Hi Edmund,
>> 
>> This is a regression since last Tuesday's commit  
>> f81e612cc9ff91ddefc1d86e270cd7f018701802. Thanks for catching it!
>> 
>> Stu
>> 
>> 
>> 
>>> Dear Clojurians,
>> 
>>>I have been trying to get a proper grip on the operation of lazy-
>>> seq and hope somebody will have the time to clarify a point for me.  
>>> The references indicate that you should not hold onto the head of a  
>>> lazy sequence as it blocks the GC.  This has lead to me to believe  
>>> that a lazy sequence, even while being active 'downstream' can be  
>>> GCd 'upstream'.  Is this so ?
>> 
>>> An example:  in this post
>> 
>>> http://groups.google.com/group/clojure/browse_thread/thread/57a12f1a0...
>> 
>>> in the first version of fibo, the call (nth (fibo) 100) will  
>>> cause a seq to proceed to the millionth element.  If memory were  
>>> tight could earlier elements be GC'd before nth had reached the  
>>> end ?  My understand is that it can.  I ask because on my machine on  
>>> Clojure 1.2, (nth (fibo) 100) causes a heap overflow which I  
>>> don't understand.
>> 
>>> Thanks in advance,
>> 
>>>  Edmund
>> 
> 
> Now fixed - thanks for the report!
> 
> Rich
> 
> -- 
> 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
> 
> To unsubscribe, reply using "remove me" as the subject.

  Edmund





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

Understanding lazy-seq

[Edmund Jackson]

Dear Clojurians,

I have been trying to get a proper grip on the operation of lazy-seq 
and hope somebody will have the time to clarify a point for me.  The references 
indicate that you should not hold onto the head of a lazy sequence as it blocks 
the GC.  This has lead to me to believe that a lazy sequence, even while being 
active 'downstream' can be GCd 'upstream'.  Is this so ?

An example:  in this post

http://groups.google.com/group/clojure/browse_thread/thread/57a12f1a0dab5e1b/cb3db6e6ac94092f?#cb3db6e6ac94092f

in the first version of fibo, the call (nth (fibo) 100) will cause a seq to 
proceed to the millionth element.  If memory were tight could earlier elements 
be GC'd before nth had reached the end ?  My understand is that it can.  I ask 
because on my machine on Clojure 1.2, (nth (fibo) 100) causes a heap 
overflow which I don't understand.

Thanks in advance,

  Edmund





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

To unsubscribe, reply using "remove me" as the subject.

Re: Why I have chosen not to employ clojure

[Edmund Jackson]

I'd agree with that, I've setup Clojure on Linux, Mac and Windows and I found 
Windows the most difficult.  Granted, I virtually never use Windows, but it 
felt like I was fighting it by being at the command line, but had no choice but 
to be there.

On 22 Mar 2010, at 11:31, Luc Préfontaine wrote:

> Is my first impression right or wrong ?
> 
> Is Clojure harder to setup from Windows for beginners ?
> 
> Would an installer (.msi) help by hiding Java related details and providing 
> some basic scripts to run it ?
> 
> Luc P.
> 
> On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote:
>> 
>> On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg
>>  wrote:
>> >
>> > Every time I've started up with a clojure project I've had to spend a few
>> > hours fiddling with the environment, not that I don't do that with other
>> > languages, but it would be nice with an officially sanctioned solution for
>> > setting up a sane environment.
>> 
>> Even better, an officially sanctioned solution expressed both as
>> documentation, and as a collection of shell scripts for all the major
>> platforms.
>> 
>> (As another non-java-familiar clojure adoptee, classpaths were
>> definitely a hurdle)
>> 
>> martin
>> 
> 
> 
> -- 
> 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
>  
> To unsubscribe from this group, send email to 
> clojure+unsubscribegooglegroups.com or reply to this email with the words 
> "REMOVE ME" as the subject.

  Edmund

"Do it with love, l-o-v-e"
MJ




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

To unsubscribe from this group, send email to 
clojure+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: Name suggestions

[Edmund Jackson]

I love the reference,  but I dunno dude, the word itself sounds venereal !

On 18 Mar 2010, at 14:36, Alexandre Patry wrote:

> 
>>> On Wed, Mar 17, 2010 at 3:08 AM, mac  wrote:
>>>
>>>> After just a little more test and polish I plan on calling clj-native
>>>> 1.0. But clj-native is a *really* boring name so I want to change it
>>>> before 1.0 and I don't have very good imagination when it comes to
>>>> these things.
>>>> So I need your help.
>>>> It doesn't have to have anything to do with anything, could just be
>>>> something that sounds funny, like sasquatch, that's a funny word.
> What about cocytus, the deepest level of hell in Dante's inferno.  I guess 
> you cannot go lower level than that :)  And it reflect the pain of leaving 
> clojure to write native code.
> 
> There are also the clo-cytus or clocytus variations.
> 
> Alexandre
> 
> -- 
> 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

  Edmund

"Do it with love, l-o-v-e"
MJ




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

Re: map not working in loop

[Edmund Jackson]

I think you're calling coll as a function. Try this.

(defn pyt [coll]
 (loop [b (rest coll)]
   (map  #(* % %) b)))

Edmund

On 5 Mar 2010, at 14:13, Meikel Brandmeyer wrote:

> Hi,
> 
> On Mar 5, 3:05 pm, Glen Rubin  wrote:
> 
>> The following code does not work, when using (range 1 5) as coll
>> input:
>> 
>> (defn pyt [coll]
>>   (loop [b (rest (coll))]
>> 
>> (map  #(* % %) b)))
>> 
>> The real code was more complicated, but I refined it to its simplest
>> form while still producing the error.   (map f coll)  looks correct to
>> me??  :(
> 
> "Does not work" is quite vague. I'd say the code snippet does not
> work, because you call coll like a function, which wont work because
> it is a sequence. Try (rest coll). (Note: no parens around coll)
> 
> What is the exact error you get?
> 
> Sincerely
> Meikel
> 
> -- 
> 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

  Edmund

"Do it with love, l-o-v-e"
MJ




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

Re: Full Disclojure - I Need Topics!

[Edmund Jackson]

+1 defprotocol, deftype, reify

On 26 Jan 2010, at 00:24, Jeff Rose wrote:

> Thanks a lot for the videos you've done so far.  I watch them all.
> Here are some ideas for shows, from more Clojure centric to just
> interesting:
> 
> * defprotocol, deftype, reify, ...
> * data-flow programming
> * pattern matching
> * monads
> * performance tuning (unboxed numbers, type hints, ...?)
> * making a clojure library available to Java and other JVM languages
> * a guided tour of clojure contrib
> * OpenGL and Shaders
> * parser combinators
> * generics
> 
> -Jeff
> 
> On Jan 25, 6:34 am, Sean Devlin  wrote:
>> Hello everyone,
>> I'm having a blast making the Full Disclojure series.  It's one the
>> best projects I've had a chance to work on.
>> 
>> However, there's going to be a problem soon.  I only have a few more
>> topics left before I run out.  No more topics, no more videos.
>> 
>> This is where you come in.  I'm interested in what the community (i.e.
>> you) would like to see talked about.  It could be the core language,
>> contrib, a popular library, your-really-awesome-library-that-you-would-
>> like-to-get-exposure, or some development tool.  Bring up anything and
>> everything.  If it's interesting enough, I'll try to do an episode on
>> it.  There are no bad suggestions.
>> 
>> Thanks in advance,
>> Sean
> 
> -- 
> 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

  Edmund

"The future is here. It's just not widely distributed yet"
 -- Gibson




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

Re: Clojure Kata

[Edmund]

Here a different version, without the sequence abstraction. I realise
its idiomatically obsolete, but thought you guys might enjoy it.

(defn sift
  "Sift. Old Skool."
  [key-pred in-s]
  (reduce
   (fn [coll elem]
 (if (key-pred elem)
   (conj coll [(str elem) []])
   (conj
(pop coll)
[(first (last coll))
 (conj (last (last coll)) (str elem))])))
   []
   in-s))

On Jan 25, 10:21 am, Christophe Grand  wrote:
> Hi Patrick,
>
> On Sun, Jan 24, 2010 at 9:58 PM, CuppoJava  wrote:
> > It's an elegant puzzle. Thanks Sean!
>
> > Here's my take:
> > (defn sift [pred? s]
> >  (lazy-seq
> >    (if (seq s)
> >      (let [key (first s)
> >            [vals remaining] (split-with #(not (pred? %)) (rest s))]
> >        (cons [key vals] (sift pred? remaining))
>
> > I'm interested in what you came up with. =)
> >  -Patrick
>
> Mine looks very much like yours:
> (defn sift [pred coll]
>   (lazy-seq
>     (when-let [[x & xs] (seq (drop-while (complement pred) coll))]
>       (cons [x (take-while (complement pred) xs)] (sift pred xs)
>
> except that I discard the first items when they don't match pred,
> while you assume that the first item always match pred.
> I prefer to use when instead of if when there's no "else" expression.
>
> I also have a non-lazy solution:
> (defn sift [pred coll]
>   (letfn [(alter-top [v f & args] (conj (pop v) (apply f (peek v) args)))]
>     (reduce #(if (pred %2)
>                (conj %1 [%2 []])
>                (alter-top %1 alter-top conj %2)) [] coll)))
>
> Christophe

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

Re: Clojure Conference Poll

[Edmund]

East coast for we Europeans ?

On Jan 23, 8:53 am, Christophe Grand  wrote:
> On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen
>
>  wrote:
> > On 22 Jan 2010, at 22:15, Wilson MacGyver wrote:
>
> >> I vote let's turn this into a clojure vacation, and hold it in an
> >> exotic location.
>
> >> Otherwise, hey, Columbus Ohio is as good as any other city. :)
>
> > My vote is for Paris, France :-)
>
> +1 :-)

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

Re: Clojure/SLIME/Emacs questions

[Edmund Jackson]

and FWIW I got the whole thing going without ELPA by using the  
instructions here:

http://learnclojure.blogspot.com/2009/11/installing-clojure-on-ubuntu-910-karmic.html

but on OSX.

On 1 Jan 2010, at 11:30, Stefan Kamphausen wrote:

> FWIW I have never touched ELPA but got a setup with SLIME from CVS
> plus SBCL and Clojure.  A rudimentary description can be found at
> http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup
>
> The only part that feels tricky is compiling swank for which I needed
> a Maven setup, IIRC.
>
> Regards,
> Stefan
>
> -- 
> 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

   Edmund

"The future is here. It's just not widely distributed yet"
  -- Gibson




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

Re: newbie question

[Edmund Jackson]

Here's something based on a similar question I asked in #clojure the  
other day, based on the code Chousuke answered with (all ugliness is  
my fault).

(defn cond [f pred]
   (fn [coll acc outp]
  (if (empty? coll)
(conj outp acc)
(if (pred (first coll))
  (recur (rest coll) (vector (first coll)) (conj outp acc))
  (recur (rest coll) (f acc (first coll)) outp)

((cond conj (partial < 5)) [1 2 3 4 5 6 7 9 2 1 2 3] '[] '[])
user=> [[1 2 3 4 5] [6] [7] [9 2 1 2 3]]

Edmund

On 7 Nov 2009, at 14:17, Christophe Grand wrote:

>
> Can I play too?
>
> Non-lazy version (basically the same as Chouser's with reduce  
> instead of loop):
> (defn partition-when [pred coll]
>  (reduce #(if (pred %2)
> (conj %1 [%2])
> (conj (pop %1) (conj (peek %1) %2)))
>[[]] coll))
>
> user=> (partition-when odd? (range 1 15))
> [[] [1 2] [3 4] [5 6] [7 8] [9 10] [11 12] [13 14]]
> user=> (partition-when even? (range 1 15))
> [[1] [2 3] [4 5] [6 7] [8 9] [10 11] [12 13] [14]]
>
>
> And lazy version:
> (defn partition-when [pred coll]
>  (let [heads (partial take-while (complement pred))]
>(cons (heads coll)
>  (mapcat #(when (pred %1) [(cons %1 (heads %2))])
>coll (iterate rest (rest coll))
>
> user=> (partition-when odd? (range 1 15))
> (() (1 2) (3 4) (5 6) (7 8) (9 10) (11 12) (13 14))
> user=> (partition-when even? (range 1 15))
> ((1) (2 3) (4 5) (6 7) (8 9) (10 11) (12 13) (14))
>
> Christophe
>
> On Sat, Nov 7, 2009 at 1:47 AM, Alex Osborne  wrote:
>>
>> Alex Osborne wrote:
>>> Like Mark's but using split-with instead of split-at:
>>>
>>> (defn partition-when [pred coll]
>>>(lazy-seq
>>> (when-let [[x & xs] (seq coll)]
>>>   (let [[xs ys] (split-with (complement pred) xs)]
>>> (cons (cons x xs) (partition-when pred ys))
>>
>> Just realised this is almost the same as Warren's -- I had missed
>> reading Warren's before posting.  Thought it might be helpful if I
>> explain the differences:
>>
>> * lazy-seq on the outside of the conditional.  This means the seq is
>> fully lazy, so if you never call first/next on it, nothing is ever  
>> run.
>>
>> * As suggested by others complement instead of NOT.
>>
>> * (when (seq coll) ...) instead of (if (empty? coll) () ...).  We can
>> simplify things like this as (lazy-seq nil) => () and (seq ()) =>  
>> nil.
>>
>> * Using destructuring instead of (first coll) (next coll).  Makes  
>> it a
>> bit shorter and is quite useful if you're going to use the result of
>> (first coll) or (next coll) multiple times, but in this case it  
>> doesn't
>> really matter.
>>
>>>
>>
>
>
>
> -- 
> Professional: http://cgrand.net/ (fr)
> On Clojure: http://clj-me.cgrand.net/ (en)
>
> >

   Edmund

"The future is here. It's just not widely distributed yet"
  -- Gibson





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