Re: [ANN] The Kiln, an Evaulation Strategy for Insanely Complex Functions

[Jeffrey Straszheim]

Looks awesome.

I think we're going the same direction. Myself, I wanted clays to be 
first-class items that can live in Clojure namespaces, and give you all of 
that. The downside is this: if I particular clay is wrong for some 
particular evaluation, you're stuck. The clay is the clay is the clay.

There are a couple ways around this. For testing, with-redefs has its 
normal purpose. You can also use a function unsafe-set-clay!! to force a 
clay's value. But that's heavy handed. More usefully, clays can be built 
lexically, as in

 (let [a-clay (clay :value (... stuff ...) :name something)]
  ... stuff ...)

And passed around

(fire kiln clay-with-args a-lexical-clay)

(defclay clay-with-args
   :args [some-clay]
   :value (blah (?? some-clay)))

This would let you build a computational graph on an as-needed basis.

But still, those are clumsy tools: fine for a few edge cases, but if needed 
often you'd want something built for the task. For your use case, it sounds 
like your approach is better. For the specific applications that led to my 
thinking, the entities were pretty well-defined and their computation 
well-known. Making them top-level named objects seems the right way to go.





On Thursday, May 10, 2012 11:11:15 AM UTC-4, mlimotte wrote:
>
> Hi Jeff,
>
> What do you think about a Map interface for this?
>
> I recently implemented something similar in a project of mine, which I 
> called an 'evaluating-map'.  It's not a Web project, but the pattern is a 
> general one.  In my case, a DSL for specifying a job to run.  I want the 
> DSL writer to have access to a lot of data/logic which can come from a lot 
> of different sources (a "big ball of mud" to use your term).
>
> Like you, the mud-ball could contain values or functions.  These functions 
> can have references to other values in the "ball of mud".  I expanded this 
> to include interpolated strings (e.g. "foo is ${foo}") and collections of 
> values/Strings/functions which are handled recursively.  My code doesn't do 
> anything to manage state, although users are encouraged to provide memoized 
> functions and a helper is provided to assist with this.
>
> Here's an example comparable to your example from the Kiln project.
>
> (def m 
>   {:request "foo"
>:uri #(build-uri (:request %))   ; an anonymous function works, or
>:path (lfn [uri] (.getPath uri)) ; use lfn, a helper that returns a fn
>:dispatch 
>  (lfn [path] (condp = path 
>"/remove-user" :remove-user
>"/add-user" :add-user
>"/view-user" :view-user))
>:action! action  ; assuming action is defn'ed elsewhere
>... and so on ... })
>
> lfn is the helper that I mentioned-- it pulls it's args as keys from the 
> "ball-of-mud" and returns a memoized fn of those args.
>
> Eventually, you fire it.  Like Kiln, the concept is that you have a bunch 
> of code that sets it up and then at some point you mix in a few seed values 
> and kick it off.  My fire function does a bunch of other stuff, but the 
> relevant part boils down to (-> m (assoc :request req) evaluating-map), 
> which is used like this:
>
> (let [k (-> m (assoc :request req) evaluating-map)
>   result (try 
>(:action! k)
>(render-template (:template k) ...other kiln data...)
>... catch)]
>   ; because it's a Map, you can do things like
>   (log/debug (select-keys k [:uri :path]))
>   result)
>
> I didn't write support for glazes and cleanup.  I think glazes could be 
> done ring-style.  Cleanup requires some extra thought.  Those are nice 
> features of Kiln.
>
> I think Kiln gives you more control over the execution and state, making 
> things like cleanup easy.  What I like about the Map interface, aside from 
> the convenience of being able to use standard collection functions (merge, 
> select-keys, dissoc, etc) is that you can construct the map from many 
> different sources.  I.e. you can merge maps which are constructed 
> dynamically at different points in your flow.  This was important for my 
> use-case, since DSL users are writing code that my core code knows nothing 
> about.  Using the example above, a subsequent user could replace the :uri 
> fn:
>
> (merge m {:uri (lfn [request] (some-other-build-fn request))}) 
>
> This new function would then be the input for the :path function.
>
> My code for this abstraction isn't isolated, but you can see it in context 
> of another project 
> here
> .
>
> Anyway, I like the project and thanks for sharing it.
>
> Marc 
>
>
>

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

Re: The Kiln, an Evaulation Strategy for Insanely Complex Functions

[Jeffrey Straszheim]

Well, I’m not sure what you mean. It does nothing specific with the “data 
types” as such, so I would say, no, that isn’t it.


On Monday, May 7, 2012 10:59:22 AM UTC-4, cperkins wrote:
>
> I like it.  Kiln looks like it is automatically composing the request 
> handler based mostly on a description of data types (*) provided and 
> needed.  Is that correct, more or less? 
>
> It looks very useful.  Using Common Lisp (not Clojure yet) I end up 
> using a lot of macros when handling HTTP requests to handle 
> boilerplate minutiae but that strategy doesn't always work cleanly 
> because most of the requests are the almost the same but slightly 
> different. So either I write macros with arguments to configure the 
> output of the macro or end up making multiple macros, or resort to 
> inserting boilerplate by hand. 
>

-- 
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: The Kiln, an Evaulation Strategy for Insanely Complex Functions

[Jeffrey Straszheim]

On Tuesday, May 8, 2012 11:18:42 AM UTC-4, Andrew wrote:
>
> Cool... Do you use kilns at Akamai, and to what extent?
>
> Another question: you set up coals and clays and eventually kilns are 
> fired. When you're setting up the coals and clays in code, you're telling 
> the system about dependencies. Are these dependencies laid out explicitly 
> enough to be always unambiguous-in-execution? 
>
> (I'm comparing this to an architecture in the object-oriented world where 
> we ditched static singletons since static things in Java are initialized at 
> load time and we had no control over the sequence. In our architecture, we 
> had explicit metadata lists for depends-upon and provides-interface and 
> everything was registered with a master collection which would construct a 
> valid sequence for set-up and tear-down according to those metadata lists. 
> So the ambiguity was eliminated with the use of those lists. And the issue 
> of passing around more and more arguments was addressed since now you pass 
> around the single master collection. And each context could have its own 
> master collection... etc.)
>
> What were the other ways of managing complexity that you considered and 
> why did you decide that kilns would fit your needs better?
>
>
I cannot be very specific on what is happening at my work. But I will say 
the Kiln *resulted* from my experience here.

The dependency graph is implicit in your clay arrangement. However, I do no 
static analysis of the graph. If you create a cycle, it will fail at 
runtime. The stack trace should be adequate to see what went wrong.

It was a tradeoff. To make dependency analysis automatic would require the 
call graph be explicit at compile time. I decided that the ability to pass 
around coals/clays as first class objects, and to evaluate them or not as 
needed, was more important. Also, they obey all the normal Clojure rules on 
namespacing and lexical scope. To detect cycles and such would require 
global knowledge of all namespaces plus control-flow analysis. That would 
be a very different kind of library.

However, in practice I expect it to work well. Since clays name *conceptual 
values*, their dependencies should easily map into particular categories. 
That is, a developer may say, “This is part of the dispatch system, so I 
cannot count on data from the search result system, as that cannot fire 
until I have resolved dispatch.”

>From what you say, I am guessing your Java system was able to do entirely 
static analysis of the call graph.

 

-- 
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: The Kiln, an Evaulation Strategy for Insanely Complex Functions

[Jeffrey Straszheim]

I detail what I mean about "insanely complex" here:

http://github.com/straszheimjeffrey/The-Kiln/wiki/Why

And I would reject any description of the Kiln as "imperative", as such.
It does allow for side effects, but that is a matter of design and taste.
You could use it without side effects.

Ultimately, it is a dataflow model, albeit one where each cell
is only be computed once. This makes it the opposite of a
"cells-alike" library, where you want to model statefull cells
changing. The Kiln is for when your cells do not change, at
least over the lifetime of a particular kiln.

During a webapp request, the `current-user` is a fixed value, as
is `request-uri` and `response-main-body`, etc. . I find that managing
the dataflow between this stuff is an endless headache.

And no, it is not a FSM. FSM's model things that change. Kilns
model things that do not (over the lifetime of a single kiln).


On Sunday, May 6, 2012 5:52:04 PM UTC-4, Paul deGrandis wrote:
>
> Can you give a better example of insanely complex functions? 
>
> I actually think that FP is ideal at modeling, representing, and 
> managing data-flow, stream-based, or request/response data. 
> Kiln seems to encourage a sort of imperative style to these 
> operations, where associative data (like hashmaps) would normally be 
> used. 
> What advantages and tradeoffs does Kiln offer?  What problems does it 
> solve for you where you've deployed it? 
> Is Kiln's goal to create a uniform interface to a finite state machine 
> -esque concept? 
>
> Thanks! 
> Paul 
>
>
>
> On May 6, 2:08 pm, Jeffrey Straszheim  wrote: 
> > The Kiln is an evaluation strategy for insanely complex functions. It 
> was 
> > designed based on two things: my experience with managing several large, 
> > complex, ever-changing web applications in Clojure, and my experience in 
> > dataflow approaches to modelling. 
> > 
> > I have released version 1.0.0 on Clojars. Also, there is quite a bit of 
> > documentation and explanation on the project Github page, including a 
> full 
> > sample application presented in a somewhat “literate” style. 
> > 
> > Please take a look. 
> > 
> > http://github.com/straszheimjeffrey/The-Kiln

-- 
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] Exploding Fish: A URI Library for Clojure

[Jeffrey Straszheim]

But why "Exploding Fish", Walter?

Why? Why?

Poor fish.

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

[ANN] The Kiln, an Evaulation Strategy for Insanely Complex Functions

[Jeffrey Straszheim]

The Kiln is an evaluation strategy for insanely complex functions. It was 
designed based on two things: my experience with managing several large, 
complex, ever-changing web applications in Clojure, and my experience in 
dataflow approaches to modelling.

I have released version 1.0.0 on Clojars. Also, there is quite a bit of 
documentation and explanation on the project Github page, including a full 
sample application presented in a somewhat “literate” style.

Please take a look.

http://github.com/straszheimjeffrey/The-Kiln


-- 
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: prn/read and infinities

[Jeffrey Straszheim]

I'm thinking this should be handled at the reader level, not the evaluator.
 Since doubles are normally "understood" at read time, reading these values
as symbols and expecting the evaluator to get them right could lead to
unexpected behavior.

On Tue, Oct 20, 2009 at 11:57 AM, Rich Hickey  wrote:

>
>
> On Oct 20, 2009, at 11:15 AM, Brian Hurt wrote:
>
> >
> >
> >
> > I'll have to think about how best to handle this, but would appreciate
> > an issue in Assembla to track it.
> >
> >
> >
> > Sorry for the delay in responding.  I don't seem to have permission
> > to add new tickets to the Clojure Assembla page.
> >
>
> Anyone can file a support ticket:
>
> http://www.assembla.com/spaces/clojure/support/tickets
>
> 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
-~--~~~~--~~--~--~---

Re: Redirecting Output

[Jeffrey Straszheim]

Speaking of which, NIO is certainly a subset of Java that would benefit from
a nice Clojure wrapper.  Not that I'm volunteering or anything.

On Tue, Oct 20, 2009 at 3:06 AM, Alex Osborne  wrote:

>
> John Harrop wrote:
> > On Tue, Oct 20, 2009 at 12:07 AM, Alex Osborne  > > wrote:
> >
> > Gorsal wrote:
> >  > However, this raises the CPU to about 50 percent. This is due to
> the
> >  > infinite recursion, I'm assuming?
> >
> > Yes, it's because you're tight looping, checking to see if data is
> > available as fast as possible.  A quick and dirty hack would be to
> put
> > in a sleep to slow it down a bit.
> >
> >
> > A blocking operation and Java's Thread.interrupt() method would be
> cleaner.
>
> Yes, that's why I suggested NIO.  Apparently you can't interrupt an (old
> IO) read though:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4514257
>
> >
>

--~--~-~--~~~---~--~~
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: Slime and stuff

[Jeffrey Straszheim]

Thanks!

On Tue, Oct 20, 2009 at 4:01 AM, Giancarlo Angulo wrote:

>
> http://paulbarry.com/articles/2008/07/02/getting-started-with-clojure-and-aquamacs
>
>
>
> =
> ANGOL
> =
> -|-^...@^_^, =|+^_^X++~_~,@-
>
> "The only thing worse than a hopeless romantic is a hopeful one"
>
> Magbasa bago Mamuna. Mag-isip bago mambatikos
>
> Without Truth there is no Justice,
> Without Justice, there is Tyranny
>
> Semper fi
>
> Proof of Desire is Pursuit
>
> www.onthe8spot.com
> igan.l...@gmail.com
> 09173822367
>
>
> On Tue, Oct 20, 2009 at 2:30 AM, Jeffrey Straszheim <
> straszheimjeff...@gmail.com> wrote:
>
>> So, I just upgraded my machine to a Macbook Pro, and am reinstalling
>> everything.
>> I'm thinking about using Slime with Aquamacs.  Does anyone have a link to
>> a tutorial getting Slime up and running w/ Aquamacs?
>>
>>
>>
>
> >
>

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

Slime and stuff

[Jeffrey Straszheim]

So, I just upgraded my machine to a Macbook Pro, and am reinstalling
everything.
I'm thinking about using Slime with Aquamacs.  Does anyone have a link to a
tutorial getting Slime up and running w/ Aquamacs?

--~--~-~--~~~---~--~~
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: Got a Clojure user group?

[Jeffrey Straszheim]

I'd love to meet some other Clojure folks.  Is anyone else in Florida?

On Sun, Apr 12, 2009 at 9:22 AM, atreyu  wrote:

>
> A group for share bookmarks (and comments) about clojure and
> functional programming:
> http://groups.diigo.com/groups/clojure_dev
>
> thanks for clojure! it rocks!
>
> On Apr 9, 9:00 pm, Rich Hickey  wrote:
> > Got a Clojure user group, meetup etc?
> >
> > Reply to this message and let me know, I'll add them to the Clojure
> > site.
> >
> > Please supply a primary URL for getting info for your group.
> >
> > Thanks!
> >
> > 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
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: Java 6 dependency in clojure-contrib ok?

[Jeffrey Straszheim]

Yes to 5!  I'm on a Mac and don't feel like dealing w/ upgrading to 6.

On Thu, Apr 9, 2009 at 9:03 AM, Francesco Bellomi <
francesco.bell...@gmail.com> wrote:

>
> Looks like an interesting idea for me; it would also allow for
> automated dependency analysis for a given target jvm.
>
> btw, I'd also prefer to have 1.5 compatibility
>
> Francesco
>
> On Apr 9, 2:24 am, Howard Lewis Ship  wrote:
> > Looks like we need a macro:
> >
> > (for-jvm 1.5 ()
> >  1.6 ())
> >
>
> >
>

--~--~-~--~~~---~--~~
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
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: Bloggin' 'bout Dataflow

[Jeffrey Straszheim]

Yes!  I did forget to provide a link.

http://jstraszheim.livejournal.com/

On Apr 4, 1:23 pm, Jeffrey Straszheim 
wrote:
> I've started a series of blog posts about the use and implementation of my
> "Cells like" Dataflow library that currently lives in contrib.  I'd love to
> get some traffic to it.  Even more, since I'm looking for a job now, I
> wouldn't mind some links to it so maybe it will show up when potential
> employers google me.
> 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
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
-~--~~~~--~~--~--~---

Bloggin' 'bout Dataflow

[Jeffrey Straszheim]

I've started a series of blog posts about the use and implementation of my
"Cells like" Dataflow library that currently lives in contrib.  I'd love to
get some traffic to it.  Even more, since I'm looking for a job now, I
wouldn't mind some links to it so maybe it will show up when potential
employers google me.
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
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 + Terracotta Update

[Jeffrey Straszheim]

You're doing amazing work!  I look forward to the result.

On Thu, Apr 2, 2009 at 5:37 PM, Paul Stadig  wrote:

> I've been speaking with the Terracotta engineers, so here is an update on a
> couple of the issues:
>
> 1) array.clone(). It turns out this is a bug in Terracotta. They have
> acknowledged it, and will be working to resolve it. However, they mentioned
> (as I have found else where on the interweb[1][2]) that arraycopy is
> slightly faster than array.clone(), though nothing to write home about, so
> it may be worth rolling that change back into Clojure, or at least it won't
> hurt.
>
> 2) AtomicReference. They seem to think that adding support for AR in
> Terracotta is low hanging fruit for someone who wants to write a patch, and
> somehow they roped me into doing it. ;)
>
> 3) Boolean.TRUE != Boolean.TRUE across VMs. This also is a bug that they
> are working to resolve.
>
> So it looks like three of the biggest issues I had to work around in
> getting Clojure to work with Terracotta, will be resolved on the Terracotta
> side. This means that the Terracotta Integration Module that I wrote[3] will
> pretty much boil down to a configuration file.
>
> I think the only other *serious* issue is the problem with *in*, *out*, and
> *err*. Either they need to be made into "special" vars, or derefed
> specially, because their root values cannot be put into the TC cluster.
>
> That's all folks!
>
>
> Paul
>
> [1]
> http://groups.google.com/group/comp.lang.java.programmer/msg/f63fdf8da28004f0
> [2] http://www.javapractices.com/topic/TopicAction.do?Id=3
> [3] http://github.com/pjstadig/tim-clojure-1.0-snapshot/tree/master
>
>
> On Mon, Mar 30, 2009 at 7:38 PM, Rich Hickey  wrote:
>
>>
>>
>>
>> On Mar 30, 5:12 pm, Paul Stadig  wrote:
>> > I have gotten to the point in my Clojure + Terracotta experiment, where
>> I
>> > believe all of the features of Clojure are functional (Refs, Atoms,
>> > transactions, etc.). I do not have a way to extensively test the Clojure
>> > functionality, but I have run the clojure.contrib.test-clojure test
>> suites
>> > successfully, as well as some simple tests on my machine.
>> >
>> > There are still some open issues (though not necessarily deal killers),
>> and
>> > given the limited extent to which I have tested this, I would not
>> consider
>> > this production quality in the least. I would welcome help from the
>> Clojure
>> > community in testing this integration module. I'm sure there are
>> unexplored
>> > corners.
>> >
>> > Being that several of the changes are relatively trivial, they could be
>> > easily integrated back into the Clojure core. I have detailed as best as
>> > possible the changes I had to make to Clojure in this report: Clojure +
>> > Terracotta Integration Report
>> > (http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv)<
>> http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv>It
>> > is very possible that I have misunderstood things, so if there is a
>> > better way to accomplish any of the solutions, then let me know.
>> >
>> > I would welcome any comments, feedback, etc.
>> >
>>
>> Thanks for the detailed report! I'll look through it soon.
>>
>> 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
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: Questions about Clojure and Common Lisp

[Jeffrey Straszheim]

I can't give you any numbers on #2, but I have used both languages and there
is no comparison.  Groovy is freakishly slow.  Clojure is relatively zippy.

On Wed, Apr 1, 2009 at 11:41 AM, Chanwoo Yoo  wrote:

>
> Hello. Yesterday, I talked with a representative of a publisher about
> a translation of Lisp books. There are books about Ruby, Lua, Erlang,
> and Groovy in South Korea, but there is no book about Lisp except
> SICP. So he is considering printing the first Lisp book in South
> Korea. We talked about 'Programming Clojure', 'ANSI Common Lisp', and
> 'Practical Common Lisp'. I told him that I slightly prefered
> 'Programming Clojure' to others because of Clojure's support for
> concurrency and java interoperability. I said that the strong points
> of Clojure would make programmers of main stream languages have
> interests in Lisp. And he asked me questions like follows.
>
> 1. Has Clojure become stable?
> He is afraid that the publishing of 'Programming Clojure' would be
> meaningless if Clojure take significant changes after the publishing.
> We know it will change. But the degree is the matter.
>
> 2. Could I get any benchmarking data about the performance of Clojure
> and Java?
> I read that Clojure can generate code as fast as Java in 'Programming
> Clojure'. But he worries whether Clojure is slow like Groovy. Could I
> get data about performance comparisons between Clojure and Java on
> several algorithms?
>
> 3. Clojure can use Java libraries. Common Lisp can use C/C++
> libraries. Is it possible to say Clojure has strong points to Common
> Lisp in the power of libraries?
>
> All these questions are not easy to answer for me. I think I should
> give him the object information. So I hope that I get opinions from
> the community.
>
> >
>

--~--~-~--~~~---~--~~
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
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: detecting retries

[Jeffrey Straszheim]

The last I looked it would need to be added at the Java level.

On Fri, Mar 20, 2009 at 5:32 PM, Mark Volkmann wrote:

>
> On Fri, Mar 20, 2009 at 4:02 PM, Jeffrey Straszheim
>  wrote:
> > +1
> > I think two simple atomic integers would do the trick:
> >  1. Number of transactions entered
> >  2. Number completed, or exited through exception.
> > The amount 1 exceeds 2 is your retry rate.
>
> Right. I could implement this myself in every transaction, but I'm
> looking for tools that do this or something provided with Clojure ...
> this is if such a thing exists.
>
> > On Fri, Mar 20, 2009 at 4:38 PM, Mark Volkmann <
> r.mark.volkm...@gmail.com>
> > wrote:
> >>
> >> It seems that an important part of optimizing the performance of a
> >> Clojure application may be to attempt to minimize the number of
> >> retries that are performed in transactions. What are good ways to
> >> detect and count retries other than explicitly adding code inside
> >> dosync calls to count them?
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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
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: detecting retries

[Jeffrey Straszheim]

+1
I think two simple atomic integers would do the trick:

 1. Number of transactions entered

 2. Number completed, or exited through exception.

The amount 1 exceeds 2 is your retry rate.

On Fri, Mar 20, 2009 at 4:38 PM, Mark Volkmann wrote:

>
> It seems that an important part of optimizing the performance of a
> Clojure application may be to attempt to minimize the number of
> retries that are performed in transactions. What are good ways to
> detect and count retries other than explicitly adding code inside
> dosync calls to count them?
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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
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: Producing HTML

[Jeffrey Straszheim]

Awesome! Thanks.

On Tue, Mar 17, 2009 at 8:08 AM, Timothy Pratley
wrote:

>
> I can highly recommend clojure.contrib.prxml
>
> James Reeves gave a really good example in the 2nd last post of this
> thread:
>
> http://groups.google.com/group/clojure/browse_thread/thread/f35d01a859329409
>
> I've used it to output html to a file and found it very convenient:
> http://clojure.googlegroups.com/web/categories.clj
>
>
> On Mar 18, 12:01 am, Jeffrey Straszheim 
> wrote:
> > Is there a good standalone library to create HTML from Clojure,
> preferably
> > something like the CL-WHO?  This will be for a standalone application,
> not
> > an application server.  I just need to generate some populated HTML and
> put
> > it in to a file.  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
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 STM and deadlocks

[Jeffrey Straszheim]

The code isn't too hard to follow, 'cept the barging stuff gets a bit
tricky.  A nice 10,000 foot overview would be nice, however.

On Tue, Mar 17, 2009 at 8:04 AM, Mark Volkmann wrote:

>
> Is there a summary somewhere of the steps Clojure STM takes to avoid
> deadlocks? I'm just trying to understand the basics of what, if
> anything, it does to avoid them.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

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

Producing HTML

[Jeffrey Straszheim]

Is there a good standalone library to create HTML from Clojure, preferably
something like the CL-WHO?  This will be for a standalone application, not
an application server.  I just need to generate some populated HTML and put
it in to a file.  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
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 Web Framework, what I want to add

[Jeffrey Straszheim]

I hadn't heard of Grizzly before.  Thanks for the pointer (er..., reference,
or whatever we're calling them these days).

On Tue, Mar 17, 2009 at 5:31 AM, Hubert Iwaniuk  wrote:

> Hi Jeffrey,
> I was recently thinking of adding support for
> https://grizzly.dev.java.net/ in
> http://github.com/weavejester/compojure/tree/master.
> Just need some time to get my head around compojure.
>
> Cheers,
> Hubert.
>
>
>
> On Tue, Mar 17, 2009 at 12:52 AM, Jeffrey Straszheim <
> straszheimjeff...@gmail.com> wrote:
>
>> I'd love to see something built around very-high scalability, using NIO
>> and thread pools and such.
>>
>>
>> On Mon, Mar 16, 2009 at 7:40 PM, Sean  wrote:
>>
>>>
>>> I'm not sure if some of the design inputs make sense, specifically
>>> Spring and Hibernate.
>>>
>>> Point 1 - I've found the strength of Spring to be making up for the
>>> weaknesses of Java.  Once you have first class functions, macros, and
>>> multi-methods (to name a few), Spring doesn't bring much to the table
>>> any more.  Add in a few Unix utilities like cron and others, you
>>> remove the rest of the features.
>>>
>>> Point 2 - As for Hibernate, ORM doesn't make much sense with a
>>> functional language either.  The SQL library in clojure-contrib lets
>>> you load a map, and you can create way more interesting queries with
>>> clojure than hibernate.  S-expressions are that powerful.
>>>
>>> Point 3 - I'd follow Rails example and use strong defaults, and resort
>>> to XML only when necessary.
>>>
>>> Point 4 - Sounds good.
>>>
>>> Point 5 - Have you looked into compojure?  It does a really good job
>>> of turning s-expressions into HTML.
>>>
>>> Point 5 (the second one) - See compojure again.
>>>
>>> Point 6 & 7 - This is where a lot of work is to be done.  I'm not sure
>>> how to respond right now.  I'll think about it.
>>>
>>> Point 8 - This is why clojure is awesome.  I'll leave this as an
>>> exercise to the user :)
>>>
>>> Point 9 - Yeah, this would be a great feature.
>>>
>>> That's my thoughts.
>>>
>>> On Mar 16, 7:17 pm, BerlinBrown  wrote:
>>> > After many years (decade) of web development, here are the things that
>>> > I want in a framework, mostly based in clojure:
>>> >
>>> > What do you think and what you add.  This is ambitious and just a
>>> > "ideas" of what I would add.  What would you want from your ideal
>>> > framework?
>>> >
>>> > 1. Based on Spring Framework for middleware:
>>> > Reason: there are years and years and years of development spent on
>>> > spring and there are many things done right.  If I were integrating
>>> > with any other third party libraries, I would use spring.  Spring is
>>> > added to my framework.
>>> >
>>> > 2. Based on Hibernate for ORM mapping:
>>> > Reason: the defacto standard for ORM mapping with Java.  And also used
>>> > by NHibernate.  There is a lot of support for most popular databases.
>>> >
>>> > 3. Clojure/Lisp based configuration AND default XML configurations.
>>> > This has become the standard way to configure a J2EE web application
>>> > including spring and hibernate.  But I would like a lisp oriented
>>> > configuration.
>>> >
>>> > 4. Easy mapping to URLs.  I like python's approach for URL mapping
>>> >
>>> > 5. Clojure based, framework based server pages AND JSPs.  I have
>>> > always hated some aspects of JSP and ASPs, etc, etc.  They are just
>>> > too complicated.  I would want to use Clojure code within the
>>> > framework oriented server page and other predefined tags.
>>> >
>>> > 5. Lift like reusable server pages.  Lift has an interesting approach
>>> > for resuing the same page.  E.g. you have an if-else statement within
>>> > the page.
>>> >
>>> > If request == GET
>>> > ...render this
>>> > if request == POST
>>> >  ...render this.
>>> > if URL == 'abc.html'
>>> >  .. render this.
>>> >
>>> > I want to embed this in my framework.  You only touch one page, but
>>> > you get different outputs depending on the request method or URL, etc,
>>> > etc.
>>>

Re: I got to use Clojure at work today !!!

[Jeffrey Straszheim]

Just using the REPL to test some Java code interactively.

On Mon, Mar 16, 2009 at 9:44 PM, Vincent Foley  wrote:

>
> Personal project at work, or part of something bigger?
>
> On Mar 16, 9:27 pm, Jeffrey Straszheim 
> wrote:
> > Only to do a tiny little test w/ not-deployed code.  But still: I am a
> > professional Clojure developer now :)
> > (Please don't kill my dream.)
> >
>

--~--~-~--~~~---~--~~
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
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: Question about profiling

[Jeffrey Straszheim]

Are they both Java 6?  I know it fixed a lot of performance issue over 5.

On Mon, Mar 16, 2009 at 9:22 PM, Vincent Foley  wrote:

>
> I found that the problem is caused by the version of Sun's JVM on
> Ubunty Hardy Heron.  On my Ibex machine at home, the first two lines
> (Object.wait and ReferenceQueue.remove) are not even there and the
> costliest method if AtomicInteger.get.
>
> Vincent.
> >
>

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

I got to use Clojure at work today !!!

[Jeffrey Straszheim]

Only to do a tiny little test w/ not-deployed code.  But still: I am a
professional Clojure developer now :)
(Please don't kill my dream.)

--~--~-~--~~~---~--~~
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
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 Web Framework, what I want to add

[Jeffrey Straszheim]

I'd love to see something built around very-high scalability, using NIO and
thread pools and such.

On Mon, Mar 16, 2009 at 7:40 PM, Sean  wrote:

>
> I'm not sure if some of the design inputs make sense, specifically
> Spring and Hibernate.
>
> Point 1 - I've found the strength of Spring to be making up for the
> weaknesses of Java.  Once you have first class functions, macros, and
> multi-methods (to name a few), Spring doesn't bring much to the table
> any more.  Add in a few Unix utilities like cron and others, you
> remove the rest of the features.
>
> Point 2 - As for Hibernate, ORM doesn't make much sense with a
> functional language either.  The SQL library in clojure-contrib lets
> you load a map, and you can create way more interesting queries with
> clojure than hibernate.  S-expressions are that powerful.
>
> Point 3 - I'd follow Rails example and use strong defaults, and resort
> to XML only when necessary.
>
> Point 4 - Sounds good.
>
> Point 5 - Have you looked into compojure?  It does a really good job
> of turning s-expressions into HTML.
>
> Point 5 (the second one) - See compojure again.
>
> Point 6 & 7 - This is where a lot of work is to be done.  I'm not sure
> how to respond right now.  I'll think about it.
>
> Point 8 - This is why clojure is awesome.  I'll leave this as an
> exercise to the user :)
>
> Point 9 - Yeah, this would be a great feature.
>
> That's my thoughts.
>
> On Mar 16, 7:17 pm, BerlinBrown  wrote:
> > After many years (decade) of web development, here are the things that
> > I want in a framework, mostly based in clojure:
> >
> > What do you think and what you add.  This is ambitious and just a
> > "ideas" of what I would add.  What would you want from your ideal
> > framework?
> >
> > 1. Based on Spring Framework for middleware:
> > Reason: there are years and years and years of development spent on
> > spring and there are many things done right.  If I were integrating
> > with any other third party libraries, I would use spring.  Spring is
> > added to my framework.
> >
> > 2. Based on Hibernate for ORM mapping:
> > Reason: the defacto standard for ORM mapping with Java.  And also used
> > by NHibernate.  There is a lot of support for most popular databases.
> >
> > 3. Clojure/Lisp based configuration AND default XML configurations.
> > This has become the standard way to configure a J2EE web application
> > including spring and hibernate.  But I would like a lisp oriented
> > configuration.
> >
> > 4. Easy mapping to URLs.  I like python's approach for URL mapping
> >
> > 5. Clojure based, framework based server pages AND JSPs.  I have
> > always hated some aspects of JSP and ASPs, etc, etc.  They are just
> > too complicated.  I would want to use Clojure code within the
> > framework oriented server page and other predefined tags.
> >
> > 5. Lift like reusable server pages.  Lift has an interesting approach
> > for resuing the same page.  E.g. you have an if-else statement within
> > the page.
> >
> > If request == GET
> > ...render this
> > if request == POST
> >  ...render this.
> > if URL == 'abc.html'
> >  .. render this.
> >
> > I want to embed this in my framework.  You only touch one page, but
> > you get different outputs depending on the request method or URL, etc,
> > etc.
> >
> > 6. Use of Clojure syntactic sugar -- TO BE DETERMINED.   There is the
> > ability to use powerful Clojure constructs  with this framework but I
> > haven't figured out how yet.
> >
> > 7. Better integration of CSS, Javascript, HTML.   A lot of a web
> > application still resides with the client side.   I have yet to see an
> > web framework that addresses client development (besides GWT).   Maybe
> > something as simple as server page tags for CSS?  Javascript?
> >
> > 8.  Additional third party libraries:
> >
> > Lucene, iText, jFreeChart, optional Terracotta integration
> > 
> >
> > Other optional/additional thoughts.
> >
> > 9. Clear separation between back-end and front-end layers
> >
>

--~--~-~--~~~---~--~~
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
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: Symbols evaluated at compile time?

[Jeffrey Straszheim]

I agree.  It doesn't matter what order the compiler reads the definitions: I
can scroll up and type.
It does effect humans reading the code, however.  Often when looking at
unfamiliar Clojure code, I find myself scrolling to the bottom first.

On Mon, Mar 16, 2009 at 1:58 PM, Meikel Brandmeyer  wrote:

> Hi,
>
> Am 16.03.2009 um 18:36 schrieb Elena:
>
>  IMHO, this is a no-no for interactive development. I understand that
>> it helps avoiding undefined symbols, but such code integrity checks
>> could be delayed to a final compilation stage. Having them earlier
>> forces you to develop code in a bottom-up way.
>>
>
> I don't think so. I start with a function. *hackhackhack*
> Then I realise, that some part should be extracted into
> a helper function, eg. to share code with third function.
>
> Then it is matter of convention of the local project, whether
> this helper function is place in front or after the other functions
> combined with a declare.
>
> I use a top-down approach all the time and it works
> pretty well in Clojure.
>
> 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
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: errors?

[Jeffrey Straszheim]

Don't be discouraged.  At work I use Eclipse with all sorts of mature tools
(this is Java).  It is, more or less, pretty easy to use.  At home I use
Aquamacs with a simple clojure-mode.el.  I can produce lines of code many
times faster and easier with the later.  No doubt a big part reflects the
superiority of Clojure, but I insist the Emacs environment also contributes.
 It will take a little longer to ramp up to being productive, but if your
experience is like mine, you'll find the overall experience is better.
On Sat, Mar 14, 2009 at 7:54 PM, Raoul Duke  wrote:

>
> > Try frequently doing:
>
> all of this sounds like it would be great if i understood enough of it
> all to make some patches to the source code -- it strikes me as rather
> newbie-unfriendly the way it currently all works. $0.02.
>
> sincerely.
>
> >
>

--~--~-~--~~~---~--~~
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
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: design patterns for event driven applications

[Jeffrey Straszheim]

Maybe I'll put together a Parsec.  I seem to remember it supported a cut
operator?  That would be fun.

On Sat, Mar 14, 2009 at 2:10 PM, Meikel Brandmeyer  wrote:

> Hi,
>
> Am 14.03.2009 um 18:42 schrieb Jeffrey Straszheim:
>
>  Hasn't someone been working on a Clojure vesion of Parsec?
>>
>
> I started a port of Parsec, but it is not in a usable state.
> But there are alternatives like, eg. http://github.com/joshua-choi/fnparse
>
> 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
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: design patterns for event driven applications

[Jeffrey Straszheim]

Hasn't someone been working on a Clojure vesion of Parsec?

On Sat, Mar 14, 2009 at 4:31 AM, Christophe Grand wrote:

>
> Anatoly Yakovenko a écrit :
> > basically i am dealing with a 3rd party library, (interactive brokers
> > tws api), that takes an interface with lots of different methods that
> > it calls when an event occurs.  like received market data, received
> > order, etc...  It provides another interface that basically generates
> > these events.
> >
> > Some of the events are statefull, like i canceled an order, i get a
> > response that the order cancel was received, and then i get a
> > confirmation that the order was canceled.
> >
> > If i was implementing this in haskell, (i am at the moment, but
> > writing the bindings is a pain in the arse), i would pump all the
> > events into a Chan, essentially a lazy evaluated sequence used to get
> > stuff from IO, and write a parser on top of that.
>
> This first part is rather easy to port to Clojure, use a BlockingQueue
> to buffer events received by the callback interface:
>  (def #^java.util.concurrent.BlockingQueue q
> (java.util.concurrent.LinkedBlockingQueue.))
> and in your consumer thread, turn it into a sequence:
>  (def s (repeatedly #(.take q))) ; (EOS handling is left as an exercise)
>
> For the parser part, I'm afraid there's no such thing right now. Maybe
> can you build upon Konrad's monads library?
>
> HTH Christophe
>
>
> --
> Professional: http://cgrand.net/ (fr)
> On Clojure: http://clj-me.blogspot.com/ (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
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: errors?

[Jeffrey Straszheim]

Try frequently doing:
(use :reload 'fully.qualified.name.of.my.file)

When you are interactively adding code to the REPL (by typing or through
Slime or whatever) it doesn't know the line number.  If you reload the file
containing the offending code, it will.

I usually have a comment block like this on the bottom of modules I'm
working on:

(comment
  (use :reload 'this.current.file)
  (use 'clojure.contrib.stacktrace) (e)
  (use 'clojure.contrib.trace)
)

That way I can pop down there, reload the file, ensure that stacktrace is
loaded, and run the (e) command (to show the exception) without any effort.

On Sat, Mar 14, 2009 at 2:42 AM, Mark Engelberg wrote:

>
> But how do you get rid of the (NO_SOURCE_FILE:0) messages for every
> single error?  I'd really like to know the line number of the function
> that threw the error.
>
> >
>

--~--~-~--~~~---~--~~
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
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: "08" and "09" are invalid numbers, but "01" through "07" are fine?

[Jeffrey Straszheim]

In Java, numbers prefixed with a "0" are treated as octal.  It should not
surprise us, then, that 08 and 09 blow up.

On Thu, Mar 12, 2009 at 4:08 PM, levand  wrote:

>
> Seems like there's a bug here. All the digits less than 8 work. If
> leading zeros aren't allowed, at least the behavior ought to be
> consistent.
>
> (def n 01)
> #'user/n
>
> ...
>
> (def n 07)
> #'user/n
>
> BUT
>
> (def n 08)
> clojure.lang.LispReader$ReaderException:
> java.lang.NumberFormatException: Invalid number: 08
>
> (def n 09)
> clojure.lang.LispReader$ReaderException:
> java.lang.NumberFormatException: Invalid number: 09
>
> Same thing with additional leading zeros...
>
> (def n 007)
> #'user/n
>
> (def n 008)
> clojure.lang.LispReader$ReaderException:
> java.lang.NumberFormatException: Invalid number: 008
>
> >
>

--~--~-~--~~~---~--~~
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
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: A pretty printer for Clojure

[Jeffrey Straszheim]

Awesome!  I expect I'll be trying it out tonight.
Oh, and I hope this goes into contrib -- it'll keep my classpath shorter.

On Thu, Mar 12, 2009 at 2:05 AM, Tom Faulhaber wrote:

>
> I have now "released" the first version of my pretty printer as part
> of my cl-format library. It is released under the EPL.
>
> The pretty printer has two functions that you probably care about:
>
> (pprint obj) will pretty print the given object, and
> (pp) at the REPL will pretty print the last result output, i.e. the
> value in *1.
>
> The pretty printer currently supports two modes: simple and code.
> Simple mode prints structure in a standard way that's good for data.
> Code mode understands lots of Clojure forms (defn, binding vectors,
> condp, etc.) and attempts to print them in an idiomatic way.
>
> Cl-format is on github at http://github.com/tomfaulhaber/cl-format.
> There is a Readme there with instructions, examples, limitations and
> futures. I won't even try to put examples here, because google groups
> wreaks havoc on formatting.
>
> The simplest way to get some pretty printing happiness:
> 1) Download the jar:
> http://github.com/tomfaulhaber/cl-format/raw/master/release/cl-format.jar
> 2) Put it in your classpath.
> 3) Fire up your REPL
> 4) (use 'com.infolace.format)
> 5) Use pprint and pp as described above.
>
> This is definitely a first release and there are sure to be bugs. And
> I know there are things missing. So let me know if you're having
> problems and I'll try to get things fixed up ASAP.
>
> Enjoy!
>
> Tom
> >
>

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

Another cells library

[Jeffrey Straszheim]

I've put together another cells-like library.  Mine differs from the others
in that it uses ref's and transactions, allowing global integrity checks,
rollbacks, and other features that the agent based cells systems do not
have.

It can be found at:

  http://github.com/straszheimjeffrey/dataflow/tree/master

Comments and criticisms are welcome.

--~--~-~--~~~---~--~~
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
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: Enjoying test-is

[Jeffrey Straszheim]

Me too!

I'm writing tests right now.

On Wed, Mar 11, 2009 at 6:11 PM, Stuart Sierra
wrote:

>
> On Mar 11, 2:45 am, mikel  wrote:
> > I just wanted to say thanks to Stuart Sierra for test-is.
> On Mar 11, 9:15 am, stephaner  wrote:
> > I use test-is too, this is a very usefull test framework.
>
> You're both very welcome!
> -Stuart Sierra
>
> >
>

--~--~-~--~~~---~--~~
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
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: Request: Can clojure.contrib.walk provide a reduce type operation?

[Jeffrey Straszheim]

Yeah, I figured something like that out, but it was non-obvious.

It might be nice helper function sometime down the road.

On Wed, Mar 11, 2009 at 3:49 PM, Kevin Downey  wrote:

>
> if your walk pushes the items into a Queue, you can just reduce across the
> Queue
>
> On Wed, Mar 11, 2009 at 9:24 AM, Jeffrey Straszheim
>  wrote:
> > Currently the clojure.contrib.walk code provides a nice way to perform a
> > depth first map operation on trees.  However, I need to fold across a
> tree.
> > It would be nice if walk provided this.
> >
> > >
> >
>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> >
>

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

Request: Can clojure.contrib.walk provide a reduce type operation?

[Jeffrey Straszheim]

Currently the clojure.contrib.walk code provides a nice way to perform a
depth first map operation on trees.  However, I need to fold across a tree.
It would be nice if walk provided this.

--~--~-~--~~~---~--~~
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
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: design patterns for event driven applications

[Jeffrey Straszheim]

It is impossible to give a simple answer.  You need to be more specific
about the needs of your application.  Will it need to be concurrent, for
instance?

On Tue, Mar 10, 2009 at 7:49 PM, Anatoly Yakovenko wrote:

>
> I just starting playing around with clojure, and i know nothing of
> java beyond the syntax.  I am trying to implement an interface that
> gets called by some 3rd party application whenver an event occurs.  If
> i was doing this in haskell I would serialize the events in a channel
> and write a parser to parse the events, thus avoiding ugly state
> transition code.
>
> How does one handle this in clojure?
>
> >
>

--~--~-~--~~~---~--~~
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
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: Debugging support for clojure?

[Jeffrey Straszheim]

Probably.  The Java BigInteger classes are not particularly fast, and do not
seem to be a priority to Sun.  Therefore Clojure is not competitive on large
integer algorithms.

On Wed, Mar 11, 2009 at 2:21 AM, Tassilo Horn wrote:

>
> Phil Hagelberg  writes:
>
> Hi Phil,
>
> >> If not, is there better way than inserting gazillions of printlns to
> >> check why and where a function doesn't do the right thing?
> >
> > Most definitely! Break your functions up into smaller pieces, then
> > write tests for them using test-is.  If your functions are hard to
> > test, it's probably because they need to be broken out differently.
>
> Yeah, might be.  To get started with clojure I tried to translate the
> Miller-Rabin pseudo prime algorithm from wikipedia.  Basically it seems
> to work correctly, but the preformance is really bad for numbers above a
> certain limit.
>
> Investigated it a bit more (doing the algorithm step by step in the
> repl) and now I know what's the culprit:  The `expt' function from the
> math contrib library is dead slow.
>
> For number theory you often need things like
>
>(mod (expt n exp) m)
>
> where the exponent may be very huge.  Is that something which cannot be
> done faster in Clojure because of the Java Integer/BigInteger stuff?
> That would be a shame!  I just fell in love with clojure cause the code
> looks that concise and right!
>
> Bye,
> Tassilo
>
> >
>

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

add-watch to refs

[Jeffrey Straszheim]

When you add a watch to a ref (as opposed to an agent), when is it called?
After transaction commit, I assume, but can someone confirm that.  The docs
for add-agent mention that the watch function might be called from various
threads.  If used from a dosync, can it be called from a different thread
from the one which executed the transaction?

Thanks in advance.

--~--~-~--~~~---~--~~
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
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: What is Clojure NOT good for?

[Jeffrey Straszheim]

Well, there is no real replacement for raw intelligence, but I hope we'll
all agree that attitude and curiosity are also critical.

On Mon, Mar 9, 2009 at 7:33 PM, Phil Hagelberg  wrote:

>
> bOR_  writes:
>
> > I'm not from the software engineers field, but how difficult is it for
> > some non-lisp, but java-savvy software writer to pick up a 600-line
> > clojure program and learn to understand it?
>
> I suspect it has more to do with people thinking they can't do it than
> any actual lack of ability to comprehend. Many people are intimidated by
> new ideas and think to themselves, "I'm a Java programmer. I shouldn't
> have to learn a new language." Other people would see it as an
> opportunity rather than a burden, even if they are otherwise both
> equally capable programmers, the second person will be able to pull it
> off. But unfortunately this kind of person is much rarer.
>
> > I mean, everyone in this forum managed to learn clojure to some degree
> > without too much trouble.. including me.
>
> Membership to this group is _very_ self-selecting; you can't expect
> things that are true here to be true across the board.
>
> -Phil
>
> >
>

--~--~-~--~~~---~--~~
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
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: filter-split

[Jeffrey Straszheim]

There is separate in seq_utils in contrib.

On Sat, Mar 7, 2009 at 11:29 PM, David Sletten  wrote:

>
> I'm reading the Sequences chapter of Programming Clojure, and Stu
> points out that split-with combines the semantics of take-while and
> drop-while. But is there a function that does something similar with
> "filter"? Namely, rather than simply filtering the elements of a
> collection that satisfy a predicate I also want to capture those that
> don't. Something like this:
> (defn filter-split [pred coll]
>   (loop [trues '() falses '() coll coll]
> (cond (empty? coll)
>   (vector (reverse trues) (reverse falses))
>   (pred (first coll))
>   (recur (cons (first coll) trues) falses (rest coll))
>   :else
>   (recur trues (cons (first coll) falses) (rest coll)
>
> (filter-split #{\a\e\i\o\u} "is this not pung?") => [(\i \i \o \u)
> (\s \space \t \h \s \space \n \t \space \p \n \g \?)]
> (filter-split even? (range 10)) => [(0 2 4 6 8) (1 3 5 7 9)]
>
> Aloha,
> David Sletten
>
> >
>

--~--~-~--~~~---~--~~
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
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: Datalog update

[Jeffrey Straszheim]

I've added some Datalog material to the wiki:

http://code.google.com/p/clojure-contrib/wiki/DatalogOverview

On Wed, Feb 18, 2009 at 4:55 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:

> Makes sense.  That would work.  It certainly looks cleaner.
>
>
> On Wed, Feb 18, 2009 at 4:51 PM, Rich Hickey  wrote:
>
>>
>>
>>
>> On Feb 18, 4:32 pm, Jeffrey Straszheim 
>> wrote:
>> > Easy enough to do.  The only drawback is I'd probably want to force it
>> into
>> > a hash during the query.  For large datasets (say 100,000 records) this
>> > might get expensive.
>> >
>>
>> What I envisioned was that while this was the logical db, 'inserting'
>> any tuple would also add it to internal indexes, including of course a
>> default index on relname. You'd declare which other keys to index, and
>> how (sorted/hashed) when creating the db.
>>
>> Rich
>>
>> > On Wed, Feb 18, 2009 at 4:13 PM, Rich Hickey 
>> wrote:
>> >
>> > > On Feb 18, 3:51 pm, Jeffrey Straszheim 
>> > > wrote:
>> > > > Yes.  I've been thinking about a database layer that would support
>> > > indexing,
>> > > > constraints, and so on.  One step at a time.
>> >
>> > > Maybe I wasn't clear, I'm talking about the foundational layer.
>> > > Instead of:
>> >
>> > > (def data {
>> > >  :table-1 #{ { :x 34 :y 33 } { :x 33 :y :fred } { :x "k" :y \u } }
>> > >  :table-2 #{ { :a "fred" :b "mary" } { :a "sally" :b "joan" } }
>> > > })
>> >
>> > > I'm recommending:
>> >
>> > > (def data
>> > > #{{:rel :table-1 :x 34 :y 33 }
>> > >   {:rel :table-1 :x 33 :y :fred }
>> > >   {:rel :table-1 :x "k" :y \u }
>> > >   {:rel :table-2 :a "fred" :b "mary"}
>> > >   {:rel :table-2 :a "sally" :b "joan" }})
>> >
>> > > i.e. making relation and rule names non-special.
>> >
>> > > Rich
>> >
>> > > > (logic-rule (:fred :x ?x :y ?y) - (:sally :x ?x :z ?z) ("becky" :y
>> ?y)
>> > > >(not! :janet :qqq ?z) (if < ?x
>> ?y))
>> >
>> > > > Translated into positional notation (assuming the columns are named
>> in
>> > > the
>> > > > obvious way):
>> >
>> > > >   fred(X,Y) :- sally(X,Z), becky(Y), ~Janet(Z), when X> >
>> > > > The "<" symbol can be any Clojure callable.  Its return value will
>> be
>> > > > interpreted as a boolean.
>> >
>> > > > So, you'd get every X,Z from the relation sally, cross product with
>> every
>> > > Y
>> > > > from becky, remove each tuple that has a Z in janet, and also remove
>> any
>> > > > tuple where X> relation
>> > > > fred.
>> >
>> > > > On Wed, Feb 18, 2009 at 3:23 PM, Rich Hickey 
>> > > wrote:
>> >
>> > > > > On Feb 9, 8:46 am, Jeffrey Straszheim <
>> straszheimjeff...@gmail.com>
>> > > > > wrote:
>> > > > > > No, but I'm really learning as I go here.  I'll look into it.
>> >
>> > > > > > On Mon, Feb 9, 2009 at 7:58 AM, Rich Hickey <
>> richhic...@gmail.com>
>> > > > > wrote:
>> >
>> > > > > > > Looks like you're moving apace!
>> >
>> > > > > > > Have you considered query/subquery optimization instead of
>> magic
>> > > sets?
>> >
>> > > > > > > Rich
>> >
>> > > > > > > On Feb 8, 7:51 pm, Jeffrey Straszheim <
>> straszheimjeff...@gmail.com
>> >
>> > > > > > > wrote:
>> > > > > > > > By the way, if anyone on this list has experience
>> implementing
>> > > > > bottom-up
>> > > > > > > > optimizations for logic programs, particularly from the
>> magic set
>> > > > > family,
>> > > > > > > > and is willing to assist, please contact me.
>> >
>> > > > > > > > On Sun, Feb 8, 2009 at 7:47 PM, Jeffrey Straszheim <
>> >
>> > > > > 

Re: hash-map based on identity

[Jeffrey Straszheim]

java.util.IdentityHashMap

On Sat, Mar 7, 2009 at 1:49 AM, Mark Engelberg wrote:

>
> Is there a variation of hash-map which supports comparison of keys
> using identical? rather than = ?  Ditto with sets.
>
> >
>

--~--~-~--~~~---~--~~
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
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: pmap slower than map when reducing

[Jeffrey Straszheim]

Cool!

On Fri, Mar 6, 2009 at 5:35 PM, Dimiter malkia Stanev wrote:

>
> Thanks! Realized that a bit too late (Looked into the pmap source
> code, but that's about it).
>
> I've split my job decision roughly 1000 x 1000 - now I'm getting 8
> times speedup, on 8 core machine:
>
>  (reduce +
>(pmap
> (fn [_]
>   (reduce +
>   (map (fn [_]
>  (+ (pnpoly np xp yp  0.5   0.5)
> (pnpoly np xp yp  0.5   1.5)
> (pnpoly np xp yp -0.5   1.5)
> (pnpoly np xp yp  0.75  2.25)
> (pnpoly np xp yp  0.0   2.01)
> (pnpoly np xp yp -0.5   2.5)
> (pnpoly np xp yp -1.0  -0.5)
> (pnpoly np xp yp -1.5   0.5)
> (pnpoly np xp yp -2.25 -1.0)
> (pnpoly np xp yp  0.5  -0.25)
> (pnpoly np xp yp  0.5  -1.25)
> (pnpoly np xp yp -0.5  -2.5)))
>    (range 0 1000
> (range 0 1000)))
>
> Clojure is reasonable :)
>
> Jeffrey Straszheim wrote:
> > It is pretty common to get a slowdown when moving from map to pmap.  It
> just
> > means that the thread scheduling overhead is greater than the gain from
> > parallelizing the code.  The behavior might be very different w/ larger
> data
> > sets, or w/ more CPU's.  It is often best to leave parallelism as an
> option
> > to the client of your library.
> > Are you using the latest build?  pmap now uses Java futures and they run
> in
> > a cached thread pool.  If so, try running the algorithm a few times and
> see
> > if it speeds up as the thread pool winds up.
> >
> > On Fri, Mar 6, 2009 at 1:31 PM, Dimiter malkia Stanev  >wrote:
> >
> > >
> > > Hi guys, anyone has an insight into the problem I'm running into?
> > >
> > > On Mar 4, 2:27 am, "Dimiter \"malkia\" Stanev" 
> > > wrote:
> > > > Hi guys,
> > > >
> > > > In the example below, if map is replaced with pmap, it goes twice
> > > > slower on my MBP (2 CPUs).
> > > >
> > > > I believe it's probably the (reduce + ...) causing it, but I can't
> > > > explain it.
> > > >
> > > > Version with map:
> > > > user> (time (pnpolytest))
> > > > "Elapsed time: 3903.533 msecs"
> > > > 600
> > > >
> > > > Version with pmap:
> > > > user> (time (pnpolytest))
> > > > "Elapsed time: 7995.565 msecs"
> > > >
> > > > What I'm doing wrong here?
> > > >
> > > > (defn- pnpoly [npol #^floats xp #^floats yp x y]
> > > >   (let [npol (int npol)
> > > > x (float x)
> > > > y (float y)]
> > > > (loop [r (int 0)
> > > >i (int 0)
> > > >xi (aget xp (dec npol))
> > > >yi (aget yp (dec npol))]
> > > >   (if (< i npol)
> > > > (let [xj xi xi (aget xp i)
> > > >   yj yi yi (aget yp i)]
> > > >   (if (or (= (> yi y) (> yj y))
> > > >   (>= x (+ xi (/ (* (- xj xi)
> > > > (- y  yi))
> > > >  (- yj yi)
> > > > (recur (bit-not r) (inc i) xi yi)
> > > > (recur  r  (inc i) xi yi)))
> > > > (- r)
> > > >
> > > > (defn pnpolytest []
> > > >   (let [xp
> > > > (float-array
> > > >  [+0.0 +1.0 +1.0 +0.0 +0.0
> > > >   +1.0 -0.5 -1.0 -1.0 -2.0
> > > >   -2.5 -2.0 -1.5 -0.5 +1.0
> > > >   +1.0 +0.0 -0.5 -1.0 -0.5])
> > > > yp
> > > > (float-array
> > > >  [+0.0 +0.0 +1.0 +1.0 +2.0
> > > >   +3.0 +2.0 +3.0  0.0 -0.5
> > > >   -1.0 -1.5 -2.0 -2.0 -1.5
> > > >   -1.0 -0.5 -1.0 -1.0 -0.5])
> > > > npol 20]
> > > > (reduce +
> > > > ;; Replace the nex map with pmap,
> > > > ;; and things slow down
> > > >

Re: pmap slower than map when reducing

[Jeffrey Straszheim]

It is pretty common to get a slowdown when moving from map to pmap.  It just
means that the thread scheduling overhead is greater than the gain from
parallelizing the code.  The behavior might be very different w/ larger data
sets, or w/ more CPU's.  It is often best to leave parallelism as an option
to the client of your library.
Are you using the latest build?  pmap now uses Java futures and they run in
a cached thread pool.  If so, try running the algorithm a few times and see
if it speeds up as the thread pool winds up.

On Fri, Mar 6, 2009 at 1:31 PM, Dimiter malkia Stanev wrote:

>
> Hi guys, anyone has an insight into the problem I'm running into?
>
> On Mar 4, 2:27 am, "Dimiter \"malkia\" Stanev" 
> wrote:
> > Hi guys,
> >
> > In the example below, if map is replaced with pmap, it goes twice
> > slower on my MBP (2 CPUs).
> >
> > I believe it's probably the (reduce + ...) causing it, but I can't
> > explain it.
> >
> > Version with map:
> > user> (time (pnpolytest))
> > "Elapsed time: 3903.533 msecs"
> > 600
> >
> > Version with pmap:
> > user> (time (pnpolytest))
> > "Elapsed time: 7995.565 msecs"
> >
> > What I'm doing wrong here?
> >
> > (defn- pnpoly [npol #^floats xp #^floats yp x y]
> >   (let [npol (int npol)
> > x (float x)
> > y (float y)]
> > (loop [r (int 0)
> >i (int 0)
> >xi (aget xp (dec npol))
> >yi (aget yp (dec npol))]
> >   (if (< i npol)
> > (let [xj xi xi (aget xp i)
> >   yj yi yi (aget yp i)]
> >   (if (or (= (> yi y) (> yj y))
> >   (>= x (+ xi (/ (* (- xj xi)
> > (- y  yi))
> >  (- yj yi)
> > (recur (bit-not r) (inc i) xi yi)
> > (recur  r  (inc i) xi yi)))
> > (- r)
> >
> > (defn pnpolytest []
> >   (let [xp
> > (float-array
> >  [+0.0 +1.0 +1.0 +0.0 +0.0
> >   +1.0 -0.5 -1.0 -1.0 -2.0
> >   -2.5 -2.0 -1.5 -0.5 +1.0
> >   +1.0 +0.0 -0.5 -1.0 -0.5])
> > yp
> > (float-array
> >  [+0.0 +0.0 +1.0 +1.0 +2.0
> >   +3.0 +2.0 +3.0  0.0 -0.5
> >   -1.0 -1.5 -2.0 -2.0 -1.5
> >   -1.0 -0.5 -1.0 -1.0 -0.5])
> > npol 20]
> > (reduce +
> > ;; Replace the nex map with pmap,
> > ;; and things slow down
> > (map (fn [_]
> >(+ (pnpoly npol xp yp  0.5   0.5)
> >   (pnpoly npol xp yp  0.5   1.5)
> >   (pnpoly npol xp yp -0.5   1.5)
> >   (pnpoly npol xp yp  0.75  2.25)
> >   (pnpoly npol xp yp  0.0   2.01)
> >   (pnpoly npol xp yp -0.5   2.5)
> >   (pnpoly npol xp yp -1.0  -0.5)
> >   (pnpoly npol xp yp -1.5   0.5)
> >   (pnpoly npol xp yp -2.25 -1.0)
> >   (pnpoly npol xp yp  0.5  -0.25)
> >   (pnpoly npol xp yp  0.5  -1.25)
> >   (pnpoly npol xp yp -0.5  -2.5)))
> >  (range 0 100)
> >
> > Thanks,
> > Dimiter "malkia" Stanev
> >
>

--~--~-~--~~~---~--~~
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
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: What is Clojure NOT good for?

[Jeffrey Straszheim]

If these theories are correct (and I believe they are) then this is
an opportunity to beat the crap out these guys in head-to-head competition.
 The Rails guys seem to have successfully broken into industry by being
better (relatively compared to Java/VB/C#).  We can do the same thing if we
don't wait for others to do it instead.
(I know this sounds like a PG essay, but it is true.)

On Fri, Mar 6, 2009 at 11:07 AM,  wrote:

>
> I agree about "consultants" (these days it's not anymore an synonym for
> expert) and the state of the market but...
>
> If you write a new software product and
> you are concerned with deadlines and speed in general, Java is not
> the way to go anymore considering the pile of code you need to do
> anything significant these days. More code = more people = inefficiencies.
>
> I know some business where HR and IT managers come back with this mantra
> that they can find Java and .Net coders, anything else is too risky or
> too scarce on the market.
> It reminds the time when you could not get fired when buying IBM
> mainframes.
>
> Many HR departments do not understand anything about
> software development in general and the profile of individuals needed.
> They go for the "standard" available bodies with a single fit all projects
> skill set and their batteries of psychological tests.
> That explains a lot why productivity is low on most projects.
>
> The landscape will change when HR changes (and managers)...
> seeking intelligence and initiative instead of a single static fit.
> (looks like StarTrek quest...)
>
> The day they will understand that software development is not
> a Taylor assembly line (less the efficiency), the situation will improve.
>
> You cannot get more from people that what you are asking for...
>
> I am not generally optimistic about the state of things in the software
> industry but we need to bring in tools that are more accessible to the
> masses. Clojure is one if you compared it to CL...
>
> Luc
>
> >
> > The biggest barrier to using Clojure in an "enterprise" environment is
> > that enterprise projects are typically built and maintained by 100s of
> > replaceable code-monkeys and consultants, all of which understand Java
> > and almost none of which understand Lisp of any kind, let alone
> > Clojure.
> >
> > To be honest, even if I could get away with it, I wouldn't want to
> > inflict hell on the next person who has to fix something in my Clojure
> > code. Even if they're a good developer, they are very unlikely to care
> > about Clojure or functional programming. I heard of one guy in our
> > company who wrote some web services in Scala on the grounds that they
> > were one-off services that wouldn't need to be modified - until they
> > were, and everyone was roundly cursing him for it. They were small
> > enough that it turned out to be easier to redo them in Java rather
> > than to learn Scala and understand his code.
> >
> > Like it or not, enterprise development = Java or .NET until the
> > language landscape has some radical changes.
> >
>
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: Missing function?

[Jeffrey Straszheim]

Which raises the question when will there be another release?  The current
one is getting pretty wildly outdated.  Also, I think a corresponding
release of contrib would be a good idea.
People "just trying out" Clojure are unlikely to want to mess with the
nightly builds, but all the libraries are built against that.  I think it is
time for a refresh.

On Fri, Mar 6, 2009 at 10:52 AM, Chouser  wrote:

>
> On Fri, Mar 6, 2009 at 10:42 AM, hotcore  wrote:
> >
> > in the API specs on http://clojure.org/api#toc247 I see the function
> > frest.
> > However, when I build Clojure (Checked out revision 1326 from
> > Googlecode) this function seems to be missing.
>
> The website generally documents the latest release, not the latest SVN
> HEAD (with a few exceptions).
>
> You're probably looking for 'fnext':
>
> user=> (doc fnext)
> -
> clojure.core/fnext
> ([x])
>  Same as (first (next x))
> nil
>
> --Chouser
>
> >
>

--~--~-~--~~~---~--~~
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
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: Chrono date library

[Jeffrey Straszheim]

I took a brief glance at Joda.  It appears they already use immutable
objects to a large degree.  It looks like *exactly* the sort of library we
can just use out of the box, unwrapped.

On Thu, Mar 5, 2009 at 6:49 PM, Phil Hagelberg  wrote:

>
> Cosmin Stejerean  writes:
>
> > I like the API so far, although I'll probably have to wait for
> > timezone support before I can start using this.
>
> Would love some suggestions on what you'd expect the API to look like
> for this. Failing test cases would be even better. I haven't given it
> much thought yet.
>
> > If anyone else is interested here is a link to github
> > for chrono.clj (syntax highlighting). For some reason I couldn't
> > locate test-chrono.clj in the repo.
>
> The convention in contrib is to keep tests in
> src/clojure/contrib/test_contrib/chrono.clj, but I didn't want to attach
> two "chrono.clj" files, so I renamed it. Here's the link:
>
>
> http://github.com/technomancy/clojure-contrib/blob/de4afee3dbfef2ed7f095ce1e7c2b7ea98e13e71/src/clojure/contrib/test_contrib/chrono.clj
>
> -Phil
>
> >
>

--~--~-~--~~~---~--~~
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
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 creates lots of classloaders

[Jeffrey Straszheim]

I dies with a MaxPermGen exception.
On Wed, Mar 4, 2009 at 3:27 PM, Chas Emerick  wrote:

>
> That's a good point.  Does such usage cause some failure, or is it a
> performance issue?  I would think that prior generations' code
> (classes + classloader(s)) would get GC'd as necessary -- or is the
> number of created classloaders so significant as to hit some serious
> limitation?
>
> - Chas
>
> On Mar 4, 2009, at 3:16 PM, Jeffrey Straszheim wrote:
>
> > Many people consider the use of eval in "normal" code to be bad
> > style.  However, there are times when it is justified, such as
> > genetic programming or dynamic code loading.  In these cases Clojure
> > falls down without the classloader trick.
>
> >
>

--~--~-~--~~~---~--~~
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
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 creates lots of classloaders

[Jeffrey Straszheim]

Many people consider the use of eval in "normal" code to be bad style.
 However, there are times when it is justified, such as genetic programming
or dynamic code loading.  In these cases Clojure falls down without the
classloader trick.

On Wed, Mar 4, 2009 at 3:03 PM, Chas Emerick  wrote:

>
> Hendrik,
>
> I came across this issue with JNI libs some years ago, and also comes
> up in the context of most app servers, which use a multitude of
> classloaders to enable hot code reloading and such.  The general
> solution is to move your JNI lib into your boot classpath; in my
> experience with Tomcat and Weblogic years ago, doing this caused the
> boot classloader to link the JNI lib, making it available from all
> child classloaders.  See #3 here:
> http://www.bostic.com/docs/bdb_current/ref/java/faq.html
>
> Creating a new classloader is really important to enable proper GC'ing
> of any dynamically-generated classes later on, as others have said.
> This also only happens when one loads code, which will generally only
> happen at or near app startup outside of a development environment, so
> performance isn't really a concern IMO.
>
> - Chas
>
> On Mar 4, 2009, at 10:21 AM, Hendrik wrote:
>
> >
> > Hi,
> >
> > I got a question: Clojure seems to create poopillions of
> > DynamicClassLoader instances. Why does it do that? Could I try
> > patching it so that it creates less of them? I need this cause I ran
> > into trouble working with JNI.
> >
> > I looked at the Clojure source rev 1323. I'm no expert, this is my
> > first look at the sources, but the following struck me as hack-ish:
> > (from Compiler.java, shortened slightly)
> >
> > public static Object eval(Object form) throws Exception{
> >if(true)//!LOADER.isBound())
> >makeClassLoader();
> >
> > To me, that looks like for evaluating _every form_, a new classloader
> > gets created. Isn't that a bit much? Also, it looks "temporary" that
> > the if() has its condition commented out and replaced with
> > true ... :-/ So Clojure's behavior seems to have been different at
> > some point in the past.
> >
> > Thanks a bunch for your opinions.
> >
> > Cheers
> > Hendrik
> >
> >
> >
> > Details:
> >
> > I'm asking because I was loading a native library through JNI. The
> > rule here (apparently) is that you can load a library through only one
> > classloader, not the same library through several loaders.
> >
> > For example, this program fails:
> >
> > (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> > java.so")
> > (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> > java.so")
> >
> > I feel that the program should work. Apparently Clojure creates new
> > classloaders between line 1 and 2. An equivalent Java program does
> > work (the first System.load() loads the library, the second sees the
> > library is already loaded and does nothing).
> >
> > This is the exact error message:
> >
> > $ cat t3.clj
> > (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> > java.so")
> > (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> > java.so")
> > (println "42")
> >
> > $ java -jar /home/hk/clojure-svn-2/clojure.jar t3.clj
> > java.lang.UnsatisfiedLinkError: Native Library /home/hk/inotify-
> > java-0.1/build/native/libinotify-java.so already loaded in another
> > classloader (t3.clj:0)
> >at clojure.lang.Compiler.eval(Compiler.java:4533)
> >at clojure.lang.Compiler.load(Compiler.java:4846)
> >at clojure.lang.Compiler.loadFile(Compiler.java:4813)
> >at clojure.main$load_script__5685.invoke(main.clj:206)
> >at clojure.main$script_opt__5716.invoke(main.clj:258)
> >at clojure.main$main__5740$fn__5742.invoke(main.clj:333)
> >at clojure.main$main__5740.doInvoke(main.clj:328)
> >at clojure.lang.RestFn.invoke(RestFn.java:413)
> >at clojure.lang.Var.invoke(Var.java:346)
> >at clojure.lang.AFn.applyToHelper(AFn.java:173)
> >at clojure.lang.Var.applyTo(Var.java:463)
> >at clojure.main.main(main.java:39)
> > Caused by: java.lang.UnsatisfiedLinkError: Native Library /home/hk/
> > inotify-java-0.1/build/native/libinotify-java.so already loaded in
> > another classloader
> >at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1743)
> >at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674)
> >at java.lang.Runtime.load0(Runtime.java:770)
> >at java.lang.System.load(System.java:1005)
> >at user$eval__4.invoke(t3.clj:2)
> >at clojure.lang.Compiler.eval(Compiler.java:4522)
> >... 11 more
> >
> > $
> >
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://grou

Re: Clojure creates lots of classloaders

[Jeffrey Straszheim]

This was to fix a bug where new code (generated by (eval ...)) would never
get garbage collected and crashed some programs that used eval heavily.  The
JVM has a limitation that it will never GC a loaded class, but can GC a
collection of classes referenced by a single classloader.

On Wed, Mar 4, 2009 at 10:21 AM, Hendrik  wrote:

>
> Hi,
>
> I got a question: Clojure seems to create poopillions of
> DynamicClassLoader instances. Why does it do that? Could I try
> patching it so that it creates less of them? I need this cause I ran
> into trouble working with JNI.
>
> I looked at the Clojure source rev 1323. I'm no expert, this is my
> first look at the sources, but the following struck me as hack-ish:
> (from Compiler.java, shortened slightly)
>
> public static Object eval(Object form) throws Exception{
>if(true)//!LOADER.isBound())
>makeClassLoader();
>
> To me, that looks like for evaluating _every form_, a new classloader
> gets created. Isn't that a bit much? Also, it looks "temporary" that
> the if() has its condition commented out and replaced with
> true ... :-/ So Clojure's behavior seems to have been different at
> some point in the past.
>
> Thanks a bunch for your opinions.
>
> Cheers
> Hendrik
>
>
>
> Details:
>
> I'm asking because I was loading a native library through JNI. The
> rule here (apparently) is that you can load a library through only one
> classloader, not the same library through several loaders.
>
> For example, this program fails:
>
> (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> java.so")
> (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> java.so")
>
> I feel that the program should work. Apparently Clojure creates new
> classloaders between line 1 and 2. An equivalent Java program does
> work (the first System.load() loads the library, the second sees the
> library is already loaded and does nothing).
>
> This is the exact error message:
>
> $ cat t3.clj
> (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> java.so")
> (System/load "/home/hk/inotify-java-0.1/build/native/libinotify-
> java.so")
> (println "42")
>
> $ java -jar /home/hk/clojure-svn-2/clojure.jar t3.clj
> java.lang.UnsatisfiedLinkError: Native Library /home/hk/inotify-
> java-0.1/build/native/libinotify-java.so already loaded in another
> classloader (t3.clj:0)
>at clojure.lang.Compiler.eval(Compiler.java:4533)
>at clojure.lang.Compiler.load(Compiler.java:4846)
>at clojure.lang.Compiler.loadFile(Compiler.java:4813)
>at clojure.main$load_script__5685.invoke(main.clj:206)
>at clojure.main$script_opt__5716.invoke(main.clj:258)
>at clojure.main$main__5740$fn__5742.invoke(main.clj:333)
>at clojure.main$main__5740.doInvoke(main.clj:328)
>at clojure.lang.RestFn.invoke(RestFn.java:413)
>at clojure.lang.Var.invoke(Var.java:346)
>at clojure.lang.AFn.applyToHelper(AFn.java:173)
>at clojure.lang.Var.applyTo(Var.java:463)
>at clojure.main.main(main.java:39)
> Caused by: java.lang.UnsatisfiedLinkError: Native Library /home/hk/
> inotify-java-0.1/build/native/libinotify-java.so already loaded in
> another classloader
>at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1743)
>at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674)
>at java.lang.Runtime.load0(Runtime.java:770)
>at java.lang.System.load(System.java:1005)
>at user$eval__4.invoke(t3.clj:2)
>at clojure.lang.Compiler.eval(Compiler.java:4522)
>... 11 more
>
> $
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: warning on mutation

[Jeffrey Straszheim]

Not exactly, but there is the IO! macro (see core.clj) that you can use to
mark your side effect generating code.

On Wed, Mar 4, 2009 at 10:49 AM, Joshua Fox  wrote:

> Can Clojure generate warnings when a function has side effects,
> particularly in transactions and other places where one should avoid them?
> Perhaps just a warning on access to any objects other than those of
>  Clojure types and "pre-approved" immutable Java types (String, Number,
> etc.)?
> Joshua
>
> >
>

--~--~-~--~~~---~--~~
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
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: So what do we want for a Cells-alike ?

[Jeffrey Straszheim]

I don't think I gain anything here, however, over just updating the graph in
a dosync block, except I add a bunch of asynchronicity that I then have to
block to avoid.  With agents it also becomes more difficult to do static
analysis on the graph.

On Tue, Mar 3, 2009 at 11:12 AM, Anand Patil <
anand.prabhakar.pa...@gmail.com> wrote:

>
> On Mar 3, 3:38 pm, Jeffrey Straszheim 
> wrote:
> > I'm pretty sure I don't want an agent based model.  I want clear
> > transactional semantics.  However, there is no reason both should not
> > exist.
>
> I think you can get solid transactions with lazy agents, since an
> update corresponds to a single step/data pulse/whatever. Pseudocode:
>
> (dosync
>Attach a watcher to all the cells, that when requested blocks
> until they've computed a new value
>Change the values of the base cells
>Send an update message to all the cells, which will cause them all
> to update exactly once
>Wait on the watcher)
>
> Since agents are integrated with the STM, my understanding is that the
> new data update will get written in all at once. Is that good enough
> for your purpose?
>
> As Raffael pointed out, the laziness doesn't get you recording of
> previous values... but that wouldn't be inordinately challenging to
> add in.
>
> Anand
> >
>

--~--~-~--~~~---~--~~
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
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: So what do we want for a Cells-alike ?

[Jeffrey Straszheim]

I'm pretty sure I don't want an agent based model.  I want clear
transactional semantics.  However, there is no reason both should not
exist.


On Mar 3, 9:11 am, Anand Patil 
wrote:
> On Mar 3, 1:04 pm, Rich Hickey  wrote:
>
> > I think it is important to embrace asynchrony and concurrency as
> > Clojure does. Any Cells-for-Clojure that presumes the world is a
> > single synchronous chain of events would be a misfit. The whole notion
> > of a 'current step' is suspect.
>
> I'd appreciate it if my asynchronous lazy cells got a look, as I've
> given them a few revisions now. They're 
> athttp://github.com/onyin/lazy-agent/tree.
> They don't have any global counter, but the diamond pattern is no
> problem for them. As noted in an earlier thread, my def-cell macro is
> not as nice as it could be, but it wouldn't be hard for someone who is
> good at macros to write a quick wrapper.
>
> The readme:
>
> Implements two types of agent-based 'cells' for Clojure: lazy agents
> and oblivious agents. These complement the auto-agents available in
> Clojure Contrib. Both allow for concurrent cell updates with
> respectably efficient scheduling and avoid unnecessarily repeating
> cell updates.
>
> If you deref a lazy cell, you'll see a map: {:value xxx :status
> yyy}. :status may be :needs-update, :updating, :up-to-date
> or :oblivious. If a cell is up-to-date or oblivious, :value gives the
> value of the cell.
>
> When a lazy agent's ancestor changes, its value changes to {:value
> nil :status :needs-update} but it does not compute its new value until
> it receives a message instructing it to do so. To send the update
> message to a group of agents, do (update a b c d e). To send the
> update message and wait for the values, do (evaluate a b c d e).
>
> Oblivious agents are even lazier than lazy agents. When an oblivious
> agent is up-to-date, its status is :oblivious. If an ancestor
> subsequently changes, the oblivious agent will not do anything. It
> needs to receive a 'force-need-update' message to change state to
> {:value nil :status :needs-update}, but then it starts watching its
> parents for changes like a lazy agent until it computes.
>
> Anand
--~--~-~--~~~---~--~~
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
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: So what do we want for a Cells-alike ?

[Jeffrey Straszheim]

I've actually been looking at Rete.  However, for my present purposes
I want something that just does computation dependency graphs.  Rete
is way heavier than I'm currently thinking.

On Mar 3, 8:12 am, Rich Hickey  wrote:
> On Mar 2, 10:41 pm, Jeffrey Straszheim 
> wrote:
>
>
>
> > There are a lot of "toy" cells implementations for Clojure, but as far as I
> > can tell none of them are really full-production ready libraries like K.
> > Tilton's.  I'm planning on starting a GUI based project and something cell's
> > like would be very helpful.  I may end up building it myself, and am
> > wondering what the community thinks is the best direction.
>
> > I have some thoughts of my own.
>
> > First off, Clojure is not Common Lisp (to say the least), so I don't think
> > we necessarily need to create as stateful a library as the original Cells.
> > I've used Cells-like architectures before in GUI apps (although not as a
> > separate abstract library), and don't really think it is the best way.
>
> > I'm thinking of a more static, "rules engine-ey" approach, with a small set
> > of input data, a dataflow mechanism over some rules, with dependency
> > management, parallelism (when requested), and support for fixed-point
> > recursion. However, since I'd like whatever I come up with to be reused by
> > the community, I'm intererested in everyone's input.
>
> Rete?
>
> There's Drools, an interface to which might be a lot of fun. When last
> I looked into it, it seemed needlessly painful due to Drools'
> inability to treat maps as facts (they wanted JavaBeans). I'm not sure
> if that is still the case.
>
> Rich
>
> 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
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: So what do we want for a Cells-alike ?

[Jeffrey Straszheim]

I've actually been looking at Rete.  However, for my present purposes
I want something that just does computation dependency graphs.  Rete
is way heavier than I'm currently thinking.

On Mar 3, 8:12 am, Rich Hickey  wrote:
> On Mar 2, 10:41 pm, Jeffrey Straszheim 
> wrote:
>
>
>
> > There are a lot of "toy" cells implementations for Clojure, but as far as I
> > can tell none of them are really full-production ready libraries like K.
> > Tilton's.  I'm planning on starting a GUI based project and something cell's
> > like would be very helpful.  I may end up building it myself, and am
> > wondering what the community thinks is the best direction.
>
> > I have some thoughts of my own.
>
> > First off, Clojure is not Common Lisp (to say the least), so I don't think
> > we necessarily need to create as stateful a library as the original Cells.
> > I've used Cells-like architectures before in GUI apps (although not as a
> > separate abstract library), and don't really think it is the best way.
>
> > I'm thinking of a more static, "rules engine-ey" approach, with a small set
> > of input data, a dataflow mechanism over some rules, with dependency
> > management, parallelism (when requested), and support for fixed-point
> > recursion. However, since I'd like whatever I come up with to be reused by
> > the community, I'm intererested in everyone's input.
>
> Rete?
>
> There's Drools, an interface to which might be a lot of fun. When last
> I looked into it, it seemed needlessly painful due to Drools'
> inability to treat maps as facts (they wanted JavaBeans). I'm not sure
> if that is still the case.
>
> Rich
>
> 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
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: So what do we want for a Cells-alike ?

[Jeffrey Straszheim]

Access to the previous value is an interesting idea.  I'm thinking of
putting together a lib where all updates are collection into
transactions (which would run *inside* of Clojure transactions, but
would have their own semantics also).  Something like this:

(update-model
   (update x 3)
   (update y (+ (val y) 7)))

Where update-model is a macro that makes sure everything gets
recomputed before commit.  It would be pretty straightforward to keep
the previous value around.

On Mar 3, 10:22 am, Raffael Cavallaro 
wrote:
> On Mar 3, 8:04 am, Rich Hickey  wrote:
>
> >  If B and C depend on A in such
> > a way that their values must be coordinated in order to be valid and
> > consistent, then maybe they shouldn't independently depend on A,
> > instead a transaction should fire on changes to A, which in turn
> > updates B and C. Then any downstream consumers of B and C could never
> > see inconsistent values, all without a notion of 'current step'.
>
> Certainly you can and should hide the notion of current step for
> *most* purposes. Using transactions is certainly a good way to do it;
> but you must expose it in some way or you won't be able to express the
> full range of dataflow models.
>
> Typically:
>
> ;; pseudocode
>
> (defmodel my-model
>(a :independent)
>(b (fn [a] (+ (* a 12) 3)))
>(c (fn [a] (+ a 7)))
>(d (fn [c b] (* c d 3.2
>
> Here the step is implicit, as each reference to another cell in the
> functions above really means "the value of that cell at the *same*
> step/time/data pulse."  However:
>
> 1.  failing to deal with this issue in the *implementation* of a
> dataflow
> library leads to the wrong semantics; the absence of this notion or
> any other means of dealing with it, (such as a transaction as you
> suggest)
> commonly leads to bugs in cells-alikes, including at least one clojure
> implementation.
>
> 2. there are certain types of models where one needs to be able to
> refer to previous pulses/steps. These include reflexive update
> functions, (where the value of a cell depends on its own value at some
> previous step/time/pulse), and time lags. With these types of
> dependencies, there must be some way to explicitly refer to step or
> pulse:
>
> ;pseudocode with time lag
>
> ((defmodel my-model
>(a :independent)
>(b (fn [a] (previous a 3))) ;; i.e., how many steps back
>(c (fn [a] (+ a 7)))
>(d (fn [c d] (* c d 3.2
>
> You can certainly hide the most common case (i.e., everything is at
> the same
> step/pulse), but it has to be there internally or the semantics will
> be
> wrong, and it has to be exposed in some way or you won't be able to
> express many interesting types of models in a simple, direct way.
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

So what do we want for a Cells-alike ?

[Jeffrey Straszheim]

There are a lot of "toy" cells implementations for Clojure, but as far as I
can tell none of them are really full-production ready libraries like K.
Tilton's.  I'm planning on starting a GUI based project and something cell's
like would be very helpful.  I may end up building it myself, and am
wondering what the community thinks is the best direction.

I have some thoughts of my own.

First off, Clojure is not Common Lisp (to say the least), so I don't think
we necessarily need to create as stateful a library as the original Cells.
I've used Cells-like architectures before in GUI apps (although not as a
separate abstract library), and don't really think it is the best way.

I'm thinking of a more static, "rules engine-ey" approach, with a small set
of input data, a dataflow mechanism over some rules, with dependency
management, parallelism (when requested), and support for fixed-point
recursion. However, since I'd like whatever I come up with to be reused by
the community, I'm intererested in everyone's input.

--~--~-~--~~~---~--~~
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
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: The Application Context Pattern

[Jeffrey Straszheim]

I've seen the term "skyhook" used to describe a very similar system.  In any
event, it looks cool.

On Fri, Feb 27, 2009 at 5:24 AM, linh  wrote:

>
> thanks, this will be very useful for me
>
> On 27 Feb, 09:05, Itay Maman  wrote:
> > Some of the reaction for Waterfront was related to the Application
> > Context Pattern (ACP) - The pattern that allows most of Waterfront's
> > code to be purely functional. I'll try to explain the basics in this
> > post. Let me start with the motivation: the reason why FP is at odds
> > with GUI code.
> >
> > (Pure) Functional code has no side effects, which implies immutability
> > of state. There are no fields nor global variables that can be
> > assigned to. Thus, one function can affect the computation carried out
> > by another function only by the passing of parameters. Most GUI
> > systems are built around the notion of event handlers which are
> > invoked by a message processing loop. There is no chain of calls from
> > one event handler to another.
> > In particular, if handler "A" computed some new value it cannot pass
> > it on to handler "B" because the system will call "B" only after "A"
> > returns. That's the predicament.
> >
> > ACP overcomes this by capturing the applications current state in an
> > immutable map. All event handlers receive a single parameter which is
> > the "current" context and compute the "new" context. A typical handler
> > (henceforth: "context processing function") will carry out these
> > activities: (a) Examine the current context; (b) Perform some GUI
> > operations (setSize, setText, etc.); (c) Compute a new context based
> > on the current context and on information obtained from the GUI
> > (getText, etc.). The caller (henceforth: "dispatcher") takes the
> > returned context and will use it as the new current context, the next
> > time a context processing function is invoked.
> >
> > This means that when you register event handler with a Swing widget
> > the handler needs to to call the ACP dispatcher passing it a context
> > processing function.
> >
> > The net effect of this approach is that only the dispatcher has to
> > deal with mutable state. The context processors are functional: they
> > merely compute the new state from the current.
> >
> > application-context-pattern.clj (http://groups.google.com/group/
> > clojure/web/application-context-pattern.clj) shows a concrete example.
> > It's about 140 LOC (ripped off from the real Waterfront codebase)
> > structured as follows:
> >   Lines 1..40: General-purpose helpers.
> >   Lines 40..90: The ACP infrastructure
> >   Lines 90..140: A quick sample, built around ACP.
> >
> > The sample program opens a JFrame with two buttons: Input and Output.
> > A click on the input button will pop-up an input dialog box. A click
> > on the output button will pop-up a message box showing the last value
> > entered into the input box. There's also a JLabel showing the length
> > of the input, but let's ignore it for the moment.
> >
> > The entry point into the ACP world is the bootstrap function. It takes
> > two parameters: a context processing function and an initial context.
> > In the example, this is carried out at the bottom of the run-it
> > function:
> >
> >   (defn run-it []
> > (let [build-ui (fn [ctx]
> >   (let [f (javax.swing.JFrame. "Frame")
> > b-in (javax.swing.JButton. "Input")
> > b-out (javax.swing.JButton. "Output")]
> >
> > (.addActionListener b-in (new-action-listener (fn [event]
> >   ((ctx :dispatch) get-input
> >
> > (.addActionListener b-out (new-action-listener (fn [event]
> >   ((ctx :dispatch) show-output
> >
> > (.setLayout f (java.awt.FlowLayout.))
> > (doseq [x [b-in b-out]]
> >   (.add f x) )
> >
> > (doto f
> >   (.setSize 500 300)
> >   (.setDefaultCloseOperation javax.swing.JFrame/
> > DISPOSE_ON_CLOSE)
> >   (.setVisible true))
> >
> > (assoc ctx :frame f) ))]
> >
> > (invoke-later #(bootstrap build-ui {})) ))
> >
> > invoke-later is a utility function that is mapped to SwingUtilities/
> > invokeLater.
> >
> > Let's drill down into the build-ui function: It takes the current
> > context (ctx parameter). Then it creates the frame and the buttons. It
> > uses new-action-listener (another utility) to register an action
> > listener with the buttons. The first listener looks like this:
> >   ((ctx :dispatch) get-input
> >
> > It uses (ctx :dispatch) to obtain the dispatcher from which ctx was
> > obtained, and evaluates it passing get-input as the context processing
> > function. The call to bootstrap initialized this dispatcher and added
> > the :dispatch mapping to the initial context.
> >
> > get-input looks like this:
> >   (defn- get-input [ctx]
> > (let [reply (javax.swing.JOptionPane/showInputDialog nil "Type in
> > something")]
> >   (assoc ctx :user-input reply) ))
> >
> > It pops-up an in

Re: Richer 'partial'

[Jeffrey Straszheim]

"partial" is a currying function.  It can be provided any number of
parameter(s), but it is always behaves sequentially from start to finish.
 That is what currying *is*.

You can easily partially apply to other arguments by doing this: #(fred %1
some-arg %2 other-arg).

"partial" could not easily support "unapplying" it.

On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil <
anand.prabhakar.pa...@gmail.com> wrote:

>
> Hi all,
>
> I could use a version of 'partial' that would allow me to:
>
> - Partially apply a function to any of its arguments, not just the
> first one
> - 'Unapply' a partially-applied function from one of its arguments.
>
> Is any such thing already available?
>
> Thanks,
> Anand
> >
>

--~--~-~--~~~---~--~~
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
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: error-kit and threads

[Jeffrey Straszheim]

Awesome!  Thanks.

And I can't think of a better way.  This is ultimately the same problem
found in this sort of code:

(let [something-we-need-to-close (open whatever)]
   (try (something-lazy something-we-need-to-close)
 (finally (close something-we-need-to-close

This was discussed recently on another thread, but I forget which.

On Wed, Feb 25, 2009 at 9:26 PM, Chouser  wrote:

>
> On Wed, Feb 25, 2009 at 12:32 PM, Chouser  wrote:
> > On Wed, Feb 25, 2009 at 9:05 AM, Jeffrey Straszheim
> >  wrote:
> >> Does the stuff in error kit work across thread boundaries.  I'm
> thinking,
> >> for instance, if you run a computation using pmap, the individual
> >> computations are run inside of Java futures, which will propagate
> exceptions
> >> back to the caller when the caller gets the value.  So, pmap should work
> >> fairly transparently with regard to Java exception semantics.  That is
> nice.
> >
> > That's a very interesting scenario, thanks for bringing it up.
> >
> >> Can the same be said for the error-kit stuff?
> >
> > Currently, no.  The problem is that though future propagates
> > exceptions on the way out, it does not propagate dynamic binding
> > context on the way in, which is what error-kit needs to do what it
> > does.  Also, error-kit uses some thread-local data to pass information
> > up the stack past frames that don't know about it.
>
> I've got a solution or at least a sort of work-around for this.  As of
> svn 530, error-kit provides a 'rebind-fn' function  You can pass it a
> function definition and it will stuff the dynamic context needed by
> error-kit (via lexicals) into the given fn and re-dynamically-bind
> them there.  This along with some other adjustments to how error-kit
> communicates with itself across stack frames allows for this:
>
>  (with-handler
>(doall
>  (pmap (rebind-fn
>  #(if (< % 5)
> %
> (raise *error* "foo")))
>(range 10)))
>(handle *error* [msg]
>  (str "caught " msg)))
>
> That returns "caught foo".
>
> The two key pieces there are the 'doall' and 'rebind-fn'.
>
> Leaving out both the 'doall' and 'rebind-fn' would mean that pmap may
> not raise the error until after leaving the dynamic scope of the
> with-handler.  The 'raise' would not see the with-handler, and throw a
> normal Java Exception, producing the same results as you'd get from
> using try/catch in a similar way:
>
>  java.lang.Exception: foo
>
> Including the 'doall' but leaving out 'rebind-fn' would still prevent
> 'raise' from seeing that its inside a with-handler, and so would still
> throw a normal Java Exception, which the with-handler would decline to
> catch:
>
>  java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.Exception: foo (NO_SOURCE_FILE:0)
>
> Leaving out the 'doall' but including 'rebind-fn' produces the
> strangest result.  The 'rebind-fn' would allow 'raise' to see the
> with-handler context, but which would no longer be in place when the
> 'raise' actually executes.  This allows error-kit's internal exception
> object to sneak out into the light of day:
>
>  Error Kit Control Exception: default, {:args ("caught foo"), :hfunc
> #, :blockid
> G__1899, :htag clojure.contrib.error-kit/*error*, :rfunc
> #}
>
> Scary, right?  So don't do that.
>
> If you correctly use 'rebind-fn' in contexts that are forced while
> still within the appropriate with-handler context, you can use the
> full power of error-kit, including continue, continue-with,
> bind-continue, etc:
>
>  (defn whine []
>(raise *error* "whine"))
>
>  (with-handler
>(doall
>  (pmap (rebind-fn
>  #(with-handler
> (if (< % 5) % (whine))
> (bind-continue insert [x] x)))
>(range 10)))
>(handle *error* [msg]
>  (continue insert (str "caught " msg
>
> If anyone is still reading and has a better idea for how to get
> try/catch and dynamic binding contexts to stay in sync, I'm all ears.
>
> --Chouser
>
> >
>

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

Multimethods in other namespaces

[Jeffrey Straszheim]

If in namespace one I define
   (defmulti fred dispatch-fred)

and have imported that ns into another, can I just do

(defmethod fred ::val [x] ),

or do I need to scope the method name?

--~--~-~--~~~---~--~~
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
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: Algebraic data types in clojure.contrib

[Jeffrey Straszheim]

Is there any reason they cannot be implemented as structs with some sort of
type tag?

On Wed, Feb 25, 2009 at 10:26 AM, Konrad Hinsen
wrote:

>
> I have just added a new library to clojure.contrib. It provides a
> proof-of-concept implementation of algebraic data types. An example
> for what you can do with it:
>
> (deftype tree
>   empty-tree
>   (leaf value)
>   (node left-tree right-tree))
>
> (def a-tree (node (leaf :a)
>  (node (leaf :b)
>(leaf :c
>
> (defn depth
>   [#^tree t]
>   (match t
> empty-tree  0
> (leaf n)1
> (node l r)  (inc (max (depth l) (depth r)
>
> (depth empty-tree)
> (depth a-tree)
>
>
> For more examples, see clojure.contrib.types.examples.
>
> The reason why I call this a proof-of-concept implementation is that
> it has a major drawback that seriously limits its applicability:
> equality tests on objects created from these types are done by
> identity, not by value equality, which makes them practically
> useless. This is due to the fact that the objects are actually
> implemented as closures. Another drawback, following as well from the
> implementation as closures, is that the objects cannot have any meta-
> data attached.
>
> Closures are the simplest way to create a new Java class in Clojure,
> but they have the disadvantage of equality-by-identity. I have an
> idea for a better implementation, based on gen-class and proxy, but
> before embarking on this I'd like to see some feedback on the current
> implementation. Is this something you would like to use?
>
> Konrad.
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: dorun and map

[Jeffrey Straszheim]

I really like the "close it as the last item in the sequence" trick.  Sadly,
I don't see how it can be made exception safe.

On Wed, Feb 25, 2009 at 9:02 AM, Stuart Sierra
wrote:

>
> On Feb 25, 8:29 am, Meikel Brandmeyer  wrote:
> > That's interesting. I almost never use doall or dorun together with
> > map. I found that most side-effects don't give interesting result
> > values.
>
> I often find I need to do this when the mapping function depends on a
> dynamic context, like an open stream or an SQL connection. I'm not
> using side effects in this case, but I have to make sure that the
> sequence is completely realized before leaving the scope in which it
> was created. This issue has been mentioned before, but there doesn't
> seem to be a good general-purpose solution.
>
> -Stuart Sierra
> >
>

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

error-kit and threads

[Jeffrey Straszheim]

Does the stuff in error kit work across thread boundaries.  I'm thinking,
for instance, if you run a computation using pmap, the individual
computations are run inside of Java futures, which will propagate exceptions
back to the caller when the caller gets the value.  So, pmap should work
fairly transparently with regard to Java exception semantics.  That is nice.
Can the same be said for the error-kit stuff?

--~--~-~--~~~---~--~~
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
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: Waterfront - The Clojure-based editor for Clojure

[Jeffrey Straszheim]

Count me interested also.

On Wed, Feb 25, 2009 at 7:49 AM, Itay Maman  wrote:

>
>
>
> On Feb 25, 11:48 am, linh  wrote:
> > where can i read about "application context" pattern?
> It is something I had occasionally used in the past. As I started
> working on Waterfront, I realized it is well suited for GUI apps in
> a functional language. I am not sure where you can find information
> about
> it, it is just something that was sitting there in my head.
>
> Anyway, I plan to write a more detailed description of this pattern
> as it addresses a concrete need of Clojure developers. Hope to get
> to that within the next few days.
>
> -Itay
>
>
> > i this the idiomatic way to write GUI in functional languages?
> > i'm writing a small swing based app in clojure, and i have problems
> > wirting the gui, because the gui code tends to be very imperative and
> > messy.
> >
> > On 24 Feb, 15:04, Itay Maman  wrote:
> >
> > > I've been silently following Clojure (and this group) for several
> > > months now.Somewhere around December I started working on a Clojure
> > > editor/REPL written in Clojure. This effort evolved into the
> > > Waterfront project which is now available on sourceforge (http://
> > > sourceforge.net/project/showfiles.php?group_id=249246).
> >
> > > Waterfront's Highlights:
> >
> > > * CTRL+E: Eval current selection, or the whole file if the selection
> > > is empty
> > > * Edit -> Eval as you type: When turned on (default) periodically
> > > evaluates your code. Boosts productivity as many errors are detected
> > > on the spot.
> > > * Eval-ed code can inspect/mutate Waterfront by accessing the *app*
> > > variable. For instance, if you eval this expression,
> > > ((*app* :change) :font-name "Arial"), you will choose "Arial" as the
> > > UI font.
> > > * Eval-ed code can inspect the currently edited Clojure program. For
> > > instance, if you eval this expression, ((*app* :visit) #(when (= (str
> > > (first %1)) "cons") (println %1))), the output window will show all
> > > calls, made by your code, to the cons function.
> > > * Syntax and Evaluation errors are displayed on: (1) The Problems
> > > window; (2) The line-number panel, as red markers.
> > > * Source -> Generate -> Proxy: Generates a proxy for the given list of
> > > super-types, with stub implementations for all abstract methods.
> > > * F1: Shows the doc (as per Clojure's (doc x) function) of the
> > > identifier under the caret.
> > > * Source -> Reflect: Shows the synopsis of a Java class when the caret
> > > stands on a class symbol (e.g.: java.awt.Color).
> > > * CTRL+Space: Token-based auto completion.
> > > * Full parenthesis matching.
> > > * An extensible plugin architecture.
> > > * Other goodies such as undo/redo, toggle comment, recently opened
> > > files, indent/unindent, Tab is *always* two spaces, ...
> >
> > > In order to get started, you need to
> > >   (1) Download the waterfront zip file from:
> http://sourceforge.net/project/showfiles.php?group_id=249246.
> > >   (2) Unpack it into a local directory.
> > >   (3) Edit wf.bat: fix the path to clojure.jar according to its
> > > location on your machine.
> >
> > > Personally, this effort was quite interesting. Writing GUI
> > > applications in a functional language is sometimes a challenging task
> > > (at least if you want your Clojure code not to be a transliteration of
> > > Java code…).  I used a pattern the "application context" pattern: an
> > > immutable map describing the application's current state that is
> > > passed around. This made it possible for most of Waterfront's code to
> > > be purely functional. Consequently, plugins can accomplish a lot with
> > > just a handful of lines. Many plugins span about 60 lines of code.
> > > Vast majority of them are less than 200 LOC. The main module, ui.clj,
> > > that implements the underlying engine is also less than 200 LOC. I
> > > think this is a very good indication to Clojure's power.
> >
> > > Hope you'll find it useful. I'd be happy if anyone would like to join
> > > and contribute to Waterfront. Your feedback, either on-line or
> > > offline, will be highly appreciated.
> >
> > > --
> > > Itay Mamanhttp://javadots.blogspot.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
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: Flatten a list

[Jeffrey Straszheim]

I always end up doing (filter identity '(:fred :mary nil :sue))
(remove nil? ...) is actually more clear.  I'll try to remember that.

On Tue, Feb 24, 2009 at 10:42 PM, Timothy Pratley
wrote:

>
> user=> (remove nil? '(:a nil nil :b :a))
> (:a :b :a)
>
> On Feb 25, 2:38 pm, Sean  wrote:
> > I've got the following list
> >
> > (:a nil nil :b :a)
> >
> > I want to call a "nil-killer" function, and get the following list
> >
> > (:a :b :a)
> >
> > How do I go about this?  Could someone post a quick example?
> >
>

--~--~-~--~~~---~--~~
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
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: pretty printing code

[Jeffrey Straszheim]

I look forward to it.  A good pretty-printer would be very helpful in my
current work.

On Tue, Feb 24, 2009 at 11:54 AM, Tom Faulhaber wrote:

>
> I'm just a few days away from having announcing the first release of
> my pretty printer (the pretty printer itself is working now, I'm just
> gearing up the defs for different code structures and organizing the
> packaging.
>
> It's all in the pprint branch of cl-format on github if you want to
> take a look.
>
> This has taken longer than I had hoped because my day job has been off
> the hook since new year's, but progress continues slowly but
> surely :-).
>
> On Feb 23, 1:52 pm, Mark Volkmann  wrote:
> > I recall several people discussing creation of pretty printers for
> > Clojure code on this mailing list. Are any of them in a usable state?
> > I'm looking for one that can be invoked on a file from a terminal
> > window, not one that is part of an editor/IDE plugin.
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
>

--~--~-~--~~~---~--~~
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
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 troubles with new lazy-seq hotness (OutOfMemory)

[Jeffrey Straszheim]

Glad I could help.

On Tue, Feb 24, 2009 at 1:07 AM, bsmith.occs  wrote:

>
>
>
> On Feb 23, 11:46 pm, Jeffrey Straszheim 
> wrote:
> > Have you figured this out yet?
> >
> > On Mon, Feb 23, 2009 at 4:58 PM, Jeffrey Straszheim <
> >
> > straszheimjeff...@gmail.com> wrote:
> > > The identifier "fibl" is holding on to the head of the sequence.
>
> Yes, this works:
>
> (defn fibl []
>   ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1))
>
> ;; (count (str (last (take 10
> (fibl)
> ;; --> 20899
>
> by making fibl a function, the head of the sequence is no longer
> hanging off some global variable, never to be garbage collected.
>
> I think I now understand why it's holding on to the head. lazy-seq
> evaluates its body only once and then caches the result, which would
> be a cons with a number in the car and a lazy-seq in the cdr, which in
> turn... tada! full heap! macroexpand-1 gave me the clue I needed:
>
> => (macroexpand-1 '(lazy-seq (cons a (h b (+ a
> b)
>
> (new clojure.lang.LazySeq (fn* [] (cons a (h b (+ a b)
>
> Thanks for the pointer in the right direction!
>
> // ben
> >
>

--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Jeffrey Straszheim]

I did make one important update.  The nodes no longer need to be integers.
You can build a graph of nodes and adjacency lists without the pain of
mapping to indexes.  Also, the "adjacency lists" can be a provided map, or
any function from node->neighbors.

(The fact that Clojure maps are functions of their keys is amazing.  Why
haven't other languages figured that out?)

On Mon, Feb 23, 2009 at 9:50 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:

> It would be easy to convert from your form to adjacency lists, so if you
> want it write a converter :)  I think we should keep the algorithms
> *basically* efficient.  I don't see that as premature optimization at all.
>
>
> On Mon, Feb 23, 2009 at 9:37 PM, Eric  wrote:
>
>>
>>
>>
>> On Feb 23, 6:38 pm, Jeffrey Straszheim 
>> wrote:
>> > Well, right now I'm just handling directed graphs, and basically
>> treating
>> > nodes as integer indexes, with a simple formula from index to adjacency
>> list
>> > of nodes.
>> >
>>
>> I would actually like to see an implementation that more closely
>> resembles the mathematical representation of graphs:
>>
>> A graph is , where V is a set of vertices and E is a set of
>> edges .
>>
>> It's really easy to do with maps and sets:
>>
>> {:V #{1 2 3 4 5} :E #{{:a 1 :b 2} . . . .
>>
>> It is less efficient than yours, but let's not optimize too soon.
>> >>
>>
>

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

Where to put fixed-point?

[Jeffrey Straszheim]

For my graph code in contrib, I've created a function fixed-point.  It is, I
believe, generally useful.  However, it is not properly a "graph" function
per se, and might belong elsewhere in the library.

Does anyone have a better suggestion of a file in contrib to put a
fixed-point function?

--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Jeffrey Straszheim]

It would be easy to convert from your form to adjacency lists, so if you
want it write a converter :)  I think we should keep the algorithms
*basically* efficient.  I don't see that as premature optimization at all.

On Mon, Feb 23, 2009 at 9:37 PM, Eric  wrote:

>
>
>
> On Feb 23, 6:38 pm, Jeffrey Straszheim 
> wrote:
> > Well, right now I'm just handling directed graphs, and basically treating
> > nodes as integer indexes, with a simple formula from index to adjacency
> list
> > of nodes.
> >
>
> I would actually like to see an implementation that more closely
> resembles the mathematical representation of graphs:
>
> A graph is , where V is a set of vertices and E is a set of
> edges .
>
> It's really easy to do with maps and sets:
>
> {:V #{1 2 3 4 5} :E #{{:a 1 :b 2} . . . .
>
> It is less efficient than yours, but let's not optimize too soon.
> >
>

--~--~-~--~~~---~--~~
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
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: challenge: best fibo implementation under the new laziness?

[Jeffrey Straszheim]

The speed of the JVM's big ints, and therefore Clojure's, doesn't seem to be
competitive.

On Mon, Feb 23, 2009 at 5:46 PM, Raffael Cavallaro <
raffaelcavall...@gmail.com> wrote:

>
>
>
> On Feb 23, 2:51 pm, "Stephen C. Gilardi"  wrote:
>
> > The fibs implementation in clojure.contrib.lazy-seqs is not a function
> > that returns fib(n) given n.
>
> > I think defining a fib(n) function somewhere in contrib or core that
> > operates as efficiently as we can manage would be a good idea.
>
> There was a thread on comp.lang.lisp a while ago where a number of
> people went back and forth trying to come up withe the fastest fib(n)
> algorithm (again, *not* returning a sequence, but just the nth fib
> given n). Here is the winner of that informal competition translated
> to clojure:
>
> (defn fib
>  ([n]
> (fib n 1))
>  ([n b]
> (if (zero? b)  ;calculate lucas numbers
>   (cond
>(zero? n) 2
>(= n 1) 1
>:otherwise
>(if (even? n)
>  (let [ k (/ n 2)
> l (fib k 0)]
>(+ (* l l) (if (even? k) -2 2)))
>  (let [ k (- n 1)
> l (fib k 0)
> f (fib k 1)]
>(/ (+ (* 5 f) l) 2
>   (cond;calculate fibonacci numbers
>(zero? n) 0
>(= n 1) 1
>:otherwise
>(if (even? n)
>  (let [ k (/ n 2)
> l (fib k 0)
> f (fib k 1)]
>(* f l))
>  (let [ k (- n 1)
> l (fib k 0)
> f (fib k 1)]
>(/ (+ f l) 2)))
>
> btw, the relatively naive algorithm:
>
> (defn fib-naive [n]
>  (first (nth (iterate (fn [[a b]] [b (+ a b)]) [0 1]) n)))
>
> takes over 85 seconds, or more than 40 times as long as the lucas
> number based algorithm at top to compute the one millionth fibonacci
> number. The simple loop version:
>
> (defn fib-naive2 [n]
>  (loop [a 0 b 1 counter 0]
>(if (= counter n) a
>(recur b (+ a b) (inc counter)
>
> fares exactly the same as one might expect.
>
>
> for comparison, here are some timings under different lisps on the
> same machine. All timings are after several runs to warm up caches
> and, in the case of clojure, hotspot optimizations.
>
> Time to calculate the one millionth fibonacci number using the lucas
> number based algorithm at top:
>
> clojure: 2 seconds
> ccl: 0.5 seconds
> lispworks: 1.7 seconds
> mzscheme: 0.15 seconds
> sbcl: 0.8 seconds
> larceny: 13 seconds
> ecl: 0.04 seconds
>
> as you can see, clojure is competitive with other lisps/schemes,
> faster than some, slower than others. this is really just a benchmark
> of the bignum package used by the lisp implementation. I think ecl
> uses GMP which is quite fast.
>
> btw, I tried adding type annotations to the clojure version but it
> didn't seem to make much difference.
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Jeffrey Straszheim]

Well, right now I'm just handling directed graphs, and basically treating
nodes as integer indexes, with a simple formula from index to adjacency list
of nodes.

I'm not opposed to a more elaborate implementation.  Patch welcome :)

On Mon, Feb 23, 2009 at 7:33 PM, Jeff Rose  wrote:

>
> Jeffrey Straszheim wrote:
> > As part of my Datalog work I'm putting together some directed graph
> > algorithms, mostly things like finding strongly connected components,
> > and building dependency stratifications (think topological sort but with
> > the results groups in tiers of non-interdependent nodes).  Anyhow, I'm
> > thinking this stuff will be usefull outside of Datalog, and am wondering
> > if I should just add it to contrib as a stand-alone library?
>
> That would be great.  Especially if the algorithms can operate over some
> kind of generalized interface, so the algorithms can run over different
> graph implementations.  I'm writing a semi-structured storage library on
> top of the neo4j graph database, and it would be great if I could
> analyze properties like connectedness, degree distribution, etc.  I'm
> writing a graph query engine too, so it would also be cool if it could
> run over the in-memory graphs from your library.
>
> -Jeff
>
> >
>

--~--~-~--~~~---~--~~
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
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 troubles with new lazy-seq hotness (OutOfMemory)

[Jeffrey Straszheim]

Have you figured this out yet?

On Mon, Feb 23, 2009 at 4:58 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:

> The identifier "fibl" is holding on to the head of the sequence.
>
>
> On Mon, Feb 23, 2009 at 4:04 PM, bsmith.occs wrote:
>
>>
>> ;;
>> -
>> ;; using clojure.jar from source r1301
>> ;;
>> ;; I'm new to clojure and working  from B7.0 of Programming Clojure.
>> ;; This version still uses lazy-cons.  Nevertheless I'm trying to grok
>> lazy-seq
>> ;; as described here: http://clojure.org/lazy
>> ;;
>> ;; It seems I've not understood it because I'm getting
>> OutOfMemoryError
>> ;; below and this surprises me
>>
>>
>> ;; bog-standard iterative fib.
>> ;; This works as expected
>>
>> (defn fibi [n]
>>  (loop [a 0, b 1, i n]
>>(if (<= i 0) a
>>(recur b (+ a b) (dec i)
>>
>> ;; (count (str (fibi 10)))
>> ;; --> 20899
>>
>>
>> ;; my attempt to define a lazy fib sequence.
>> ;; working? not so much.
>>
>> (def fibl
>> ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1))
>>
>> ;; (count (str (last (take 10 fibl
>> ;; --> java.lang.OutOfMemoryError: Java heap space
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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
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 troubles with new lazy-seq hotness (OutOfMemory)

[Jeffrey Straszheim]

The identifier "fibl" is holding on to the head of the sequence.

On Mon, Feb 23, 2009 at 4:04 PM, bsmith.occs  wrote:

>
> ;;
> -
> ;; using clojure.jar from source r1301
> ;;
> ;; I'm new to clojure and working  from B7.0 of Programming Clojure.
> ;; This version still uses lazy-cons.  Nevertheless I'm trying to grok
> lazy-seq
> ;; as described here: http://clojure.org/lazy
> ;;
> ;; It seems I've not understood it because I'm getting
> OutOfMemoryError
> ;; below and this surprises me
>
>
> ;; bog-standard iterative fib.
> ;; This works as expected
>
> (defn fibi [n]
>  (loop [a 0, b 1, i n]
>(if (<= i 0) a
>(recur b (+ a b) (dec i)
>
> ;; (count (str (fibi 10)))
> ;; --> 20899
>
>
> ;; my attempt to define a lazy fib sequence.
> ;; working? not so much.
>
> (def fibl
> ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1))
>
> ;; (count (str (last (take 10 fibl
> ;; --> java.lang.OutOfMemoryError: Java heap space
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Jeffrey Straszheim]

I don't remember that post, but my work also deals with cycles, and a
strongly connected component algorithm will be one of my first submissions.

On Mon, Feb 23, 2009 at 10:52 AM, cliffc  wrote:

>
> As a compiler writer I do a lot of graph-work, but nearly all of it
> has cycles.
> There was a thread earlier about defining cyclic graphs in Clojure.
> Can someone point me to it?
>
> Thanks,
> Cliff
>
>
> On Feb 22, 7:55 am, Rich Hickey  wrote:
> > On Feb 22, 2009, at 10:11 AM, Jeffrey Straszheim wrote:
> >
> > > Just as a point of fact, I don't plan to make a complete *every
> > > algorithm you can think of* package, just the ones I need.  However,
> > > it would be easy to add others submitted by the community.  I could
> > > be a gathering place of graph algorithms.
> >
> > Sounds good to me - thanks!
> >
> > Rich
> >
> > > On Sun, Feb 22, 2009 at 7:31 AM, Francesco Bellomi <
> francesco.bell...@gmail.com
> > > > wrote:
> >
> > > +1
> >
> > > Francesco
> >
> > > On Feb 22, 2:59 am, Jeffrey Straszheim 
> > > wrote:
> > > > As part of my Datalog work I'm putting together some directed graph
> > > > algorithms, mostly things like finding strongly connected
> > > components, and
> > > > building dependency stratifications (think topological sort but
> > > with the
> > > > results groups in tiers of non-interdependent nodes).  Anyhow, I'm
> > > thinking
> > > > this stuff will be usefull outside of Datalog, and am wondering if
> > > I should
> > > > just add it to contrib as a stand-alone library?
> >
>

--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Jeffrey Straszheim]

Just as a point of fact, I don't plan to make a complete *every algorithm
you can think of* package, just the ones I need.  However, it would be easy
to add others submitted by the community.  I could be a gathering place of
graph algorithms.

On Sun, Feb 22, 2009 at 7:31 AM, Francesco Bellomi <
francesco.bell...@gmail.com> wrote:

>
> +1
>
> Francesco
>
> On Feb 22, 2:59 am, Jeffrey Straszheim 
> wrote:
> > As part of my Datalog work I'm putting together some directed graph
> > algorithms, mostly things like finding strongly connected components, and
> > building dependency stratifications (think topological sort but with the
> > results groups in tiers of non-interdependent nodes).  Anyhow, I'm
> thinking
> > this stuff will be usefull outside of Datalog, and am wondering if I
> should
> > just add it to contrib as a stand-alone library?
> >
>

--~--~-~--~~~---~--~~
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
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: Issue 52 looks solved

[Jeffrey Straszheim]

Does zero arguments return #{} ?

Has intersection changed?

On Sun, Feb 22, 2009 at 5:16 AM, Frantisek Sodomka wrote:

>
> Hello! Just a quick note:
> Issue 52: Make set/union accept any number of arguments
> http://code.google.com/p/clojure/issues/detail?id=52
>
> seems to be solved already by:
>
> SVN 1276
> http://code.google.com/p/clojure/source/detail?r=1276
> added multi-arg clojure.set/union/difference/intersection, patch from
> jawolfe
>
> Frantisek
> >
>

--~--~-~--~~~---~--~~
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
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: arguments to dissoc and select-keys

[Jeffrey Straszheim]

On Sat, Feb 21, 2009 at 8:49 PM, David Nolen  wrote:

>
> Ah the power of Clojure ;) The fact that (almost?) anything can be a key is
> a pretty liberating thing.
>

It is truly an amazing ability.

--~--~-~--~~~---~--~~
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
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: dependencies + observers + java interop: how to?

[Jeffrey Straszheim]

I have a "toy" version of Datalog working now here:

  http://code.google.com/p/clojure-datalog/

By "toy" I mean it works but is incredibly slow and wasteful.  I would not
use it in a production system.

"Real" Datalog is coming, but I'm now doing research regarding the correct
approach.

Note, that Datalog is really a query engine, not a computation engine.  It
is most definitely not Prolog.  It you need computation I suggest you look
at one of the versions of the "Cells" approach that are out there.  There is
a simple one in Contrib.

On Sat, Feb 21, 2009 at 7:12 PM, Timothy Pratley
wrote:

>
> Hi Max,
>
> Clojure has watchers on IRefs which can do most of what you are
> describing.
> auto-agent by SS in contrib allows you to define formula which are
> automatically updated (inspired by cells - search for cells on lib
> page and group). This gives a simple rule system, leaving just the the
> GUI interaction - which is simple also! Your specific example is not
> far from
>
> http://github.com/timothypratley/strive/blob/c430759c4a46f1a37c272d7448975b6bc24951b0/src/clj/cells.clj
> however in your case you would want to use an auto-agent to calculate
> the dependency. Also you want your GUI updating back to the formulas,
> again someone has done this for textboxes:
> http://bitbucket.org/ksojat/neman/src/tip/src/net/ksojat/neman/cells.clj
>
> So I think you can achieve a lightweight solution quite easily using
> these parts.
>
> However if you are interested in more complete 'rules' systems then I
> suggest searching for Datalog on this group. JS is implementing
> Datalog logic querying and has already made great progress. hoeck
> wrote a wrapper for IRIS reasoner with macro support (DSL style) which
> allows you to write and query rules.
>
>
> Regards,
> Tim.
>
>
> On Feb 20, 9:04 pm, max3000  wrote:
> > Hi,
> >
> > I'm new to clojure and lisp in general. I'm trying semi-porting a real
> > world application but at this time I lack patterns to reason about
> > clojure solutions to problems. I thought I'd ask the community about
> > one such problem I'm facing.
> >
> > To give a simple example for the following discussion, suppose we have
> > the following:
> > - A "temperature" fact that is updated by some external connection to
> > a thermometer.
> > - A "heater on" fact that depends on the temperature. If the
> > temperature is, say, < 20 degrees true otherwise false.
> >
> > - Requirements -
> > We want to have a collection of "facts", all mutable (i.e. they will
> > change over time).
> > Each fact is displayed in a GUI. So, there must be a callback
> > functionality for when the fact changes (observer pattern, GUI being
> > the observer).
> > Some facts are "standalone" while others are based on other facts. In
> > effect, these other facts are observers of the standalone facts (or of
> > other dependent facts).
> > Any component (GUI included) can change any fact anytime. When this
> > happens, all dependent facts must be recalculated and all observers
> > called.
> >
> > I implemented this in Java like so:
> > - Fact class implements observer pattern (w/ PropertyChangeSupport)
> > - GUI linked to all facts through addObserver
> > - Rules based engine (drools) to update facts when they change (uses
> > addPropertyChnageListener/removePropertyChangeListener implemented by
> > facts). Whenever a fact change Drools refire rules (Drools handles
> > dependencies).
> >
> > Drools is great but is rather heavy for my needs. My rules/
> > dependencies are really not that complicated. Besides, I would much
> > rather have them as a series of clojure functions.
> >
> > ***
> > At this point, I'm a bit lost trying to match these requirements to a
> > clojure design. I suppose:
> >
> > - The facts must be referenced by some unique ID, probably a keyword.
> > - The Fact class should be ported to a structmap + related functions.
> > - Fact should include a function to set it. (If the set doesn't change
> > anything, no callbacks are called).
> > - Fact should include a collection containing callback functions.
> > Anyone can hence "register" their callback. BUT: how to handle
> > unregistrations? Is this a simple matter of passing the same function
> > that was used to register?
> > - The dependencies are really not part of the facts themselves. I
> > should handle them as a series of clojure functions (or should I?).
> > E.g.:
> >
> > (defn rule1 [] (set-fact :heater-on (> (get-fact :temperature) 20)))
> >
> > - But should I also register dependencies myself? E.g:
> >
> > (add-fact-observer :temperature rule1)
> >
> > - Is there a way to make this automatic given that my rule (rule1)
> > already contained this information?
> >
> > - And what about the GUI (in Java)? Basically, each GUI element knows
> > what fact it is bound to, so the GUI code itself drives the
> > addObserver's. So, I would need to expose an interface in clojure.
> >
> > (proxy someJavaInterface observer fact-in-java
> >   (fn [] (add-fact-observ

Directed Graphs for Contrib

[Jeffrey Straszheim]

As part of my Datalog work I'm putting together some directed graph
algorithms, mostly things like finding strongly connected components, and
building dependency stratifications (think topological sort but with the
results groups in tiers of non-interdependent nodes).  Anyhow, I'm thinking
this stuff will be usefull outside of Datalog, and am wondering if I should
just add it to contrib as a stand-alone library?

--~--~-~--~~~---~--~~
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
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: Calling method in Java that mutates passed argument

[Jeffrey Straszheim]

The Clojure collections are immutable, which is their entire reason for
existing.  However, there is nothing stopping you from creating a plain old
Java collection in Clojure.
(let [list (ArrayList. '("Fred" "mary" "sue")]
  (do
(java.util.Collections/sort list)
list))

Should work.

On Fri, Feb 20, 2009 at 1:59 PM, Steffen Glückselig wrote:

>
> I was trying to use Clojure to verify the behavior some method in
> Java.
>
> Namely I wanted to quickly check whether Collections.sort does the
> sorting I need.
>
> So I came up with:
>
> (let [list '("1" "KB" "K6" "2" "EÜ" "EZ" "ES")]
>  (do
>(java.util.Collections/sort list)
>list))
>
> But since Collections/sort mutates the list in place I cannot get a
> result.
>
> Is there a way in Clojure to get at the result of operations like
> these?
>
>
>
> Steffen
>
> >
>

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

[Jeffrey Straszheim]

I haven't read _The Reasoned Schemer_, but I have read the logic programming
sections of SICP and Norvig .. as well as some non-lispy texts.  I *suspect*
TRS's material is at a similar weight.  What I'm trying to do now goes quite
a bit beyond those implementations.  Plus, they are all use a top-down w/
unification approach.  For Datalog I'm using a bottom up, set oriented,
fixed-point based approach, which guarantees termination, but turns out to
be very hard to optimize.

On Fri, Feb 20, 2009 at 1:47 PM, jim  wrote:

>
> There's a logic programming module in the files section.  It
> implements the system found in "The Reasoned Schemer".
>
> On Feb 18, 2:59 pm, Jeffrey Straszheim 
> wrote:
> > Did you cover logic programming?  Any bottom up logic query techniques?
> > (My motives are probably transparent.)
> >
> > On Wed, Feb 18, 2009 at 2:34 PM, Joshua  wrote:
> >
> > > I am currently in a masters level Compiler class. We have a final
> > > project for the class and I was wondering if there would be any
> > > defects/enhancements that I could do in Clojure. I have about 5 years
> > > of professional Java experience with dabbling with some other
> > > languages. (not an expert, but pretty good). The amount of work for
> > > the project should be about 20-40 hours (I have a month).
> >
> > > Please let me know of any suggestions.
> >
> > > Joshua
> >
>

--~--~-~--~~~---~--~~
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
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: Anyone tried to create a dynamic TableModel (or ListModel)?

[Jeffrey Straszheim]

You could also hide the vector inside your list model code, and require
modification through an api.  This would let you know what updates to send
to the Swing object without having to walk the list.

On Fri, Feb 20, 2009 at 11:11 AM, Rowdy Rednose wrote:

>
> Thanks pmf and Jeffrey,
>
> so I guess the idea is to have the TableModel hold on to the
> (dereferenced) vector and when the agent fires, the model would
> dereference the ref again and compare that value with the old one. It
> would then have to do a diff on those 2.
>
> That is one of the unelegant ideas I had - unelegant, because I have
> to iterate through both collections and do a (much more complicated
> than the "map =") diff on potentially large vectors, just because 1
> entry has been added. At the time we add that entry, we know what we
> are doing, so if we could keep that information instead of losing it
> and having to diff 2 complete collections later... But I don't have an
> idea on how to do this in Clojure.
>
> On Feb 20, 11:15 pm, Jeffrey Straszheim 
> wrote:
> > It would be pretty easy to wrap an agent (as pmf suggests) to notify your
> > model class if a Vector changes.  You could then do something like
> >  (map = old_vec new_vec)
> >
> > And then look for false results in the array and send a notification to
> > Swing.
> >
> > On Fri, Feb 20, 2009 at 5:40 AM, Rowdy Rednose  >wrote:
> >
> >
> >
> > > All the clojure swing examples I've seen so far use JTables in a
> > > static way, i.e. the data is not programmatically modified once the
> > > table got created.
> >
> > > Has anyone actually tried to implement a TableModel that is backed by
> > > a clojure Vector/Map and fires events to TableModelListeners when the
> > > underlying data changes?
> >
> > > I've got a few ideas on how to implement this, but none of them seems
> > > to be very elegant (which is why I am interested in clojure in the
> > > first place).
> >
> > > For those of you who don't know the events that a TableModel fires,
> > > they are:
> >
> > > * Table has changed ( => redraw the whole thing)
> > > * Rows x through y have changed (=> redraw only those)
> > > * Rows x through y have been inserted
> > > * Rows x through y have been deleted
> >
> > > (Full details:
> > >http://java.sun.com/javase/6/docs/api/javax/swing/event/TableModelEve.
> ..
> > > )
> >
> > > Any elegant ideas or examples on how to do this when the underlying
> > > data structure is (a ref to) one of clojure's (immutable) collections,
> > > so that a change to that structure will fire the appropriate event?
> >
>

--~--~-~--~~~---~--~~
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
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 did nil go?

[Jeffrey Straszheim]

There have been some major changes in the last week or so.  See
http://clojure.org/lazy for a brief overview.
Also: http://blog.n01se.net/?p=39

On Fri, Feb 20, 2009 at 10:31 AM, Rock  wrote:

>
> After watching Rich's video presentations and reading Stuart's fine
> book, I was absolutely convinced that if you take the *rest* of an
> empty list, what you've got left is nil.
>
> Instead, with the recent svn version of Clojure, I'm getting the empty
> list (actually sequence of course) again:
>
> user=> (rest ())
> ()
>
> or
>
> user=> (rest [])
> ()
>
>
> What gives?
>
> Rock
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: General Question Clojure(Lisp) Idiom, cross cutting? What is the terminology

[Jeffrey Straszheim]

The OO folks call this an "internal iterator" or "visitor".  However, I'd
recommend against adopting their point of view.

On Fri, Feb 20, 2009 at 10:12 AM, BerlinBrown wrote:

>
> This is a general termingology question.  What is this idiom, called
> where you pass a function as an argument to another function and then
> use that function with in a loop.  I thought it reminded me of that
> aspect oriented programming?  cross cutting of concerns?
>
> For example, I do that a lot, where I loop through a file and then
> want to call a function on one particular line string.
>
> (defn my-func [line no]
>  ...
>  ...
>
> ---
>
> (defun something
>(loop [srch-res? (. lm find) line-no 0]
>  (when srch-res?
>   
>(my-func (. lm group) line-no)
>  ***
>
>(recur (. lm find) (+ line-no 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
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: compiling a GUI app and also: interference of Java's built-in architechture

[Jeffrey Straszheim]

If your CLJ files are in the classpath, and you include clojure.jar, then
your good.

On Fri, Feb 20, 2009 at 9:30 AM, rob  wrote:

>
> What do you mean when you say there is no need to compile your program
> to distribute it?  Doesn't that require end users to set up a clojure
> environment?  And how would you deploy a web-based application without
> compiling it?
>
> On Feb 19, 6:51 pm, Kevin Albrecht  wrote:
> > I can vouch for using SWT with Clojure.  There is also no need to
> > compile you application to distribute it.  I posted a little example
> > program on my blog here:
> >
> > http://kevinoncode.blogspot.com/2009/01/creating-clojure-gui-applicat...
> >
> > --
> > Kevin Albrechthttp://www.kevinalbrecht.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
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: doc suggestion for future function

[Jeffrey Straszheim]

As far as I can tell, futures are *not* agents, but wrap the
java.util.concurrent.Future class.  However, they do run in the same thread
pool that the agents use, so your point still stands.


On Fri, Feb 20, 2009 at 9:09 AM, Mark Volkmann wrote:

>
> The doc string for the future function should probably mention that it
> uses an Agent so shutdown-agents should be called at the end of
> applications that use it.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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
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: Anyone tried to create a dynamic TableModel (or ListModel)?

[Jeffrey Straszheim]

It would be pretty easy to wrap an agent (as pmf suggests) to notify your
model class if a Vector changes.  You could then do something like
 (map = old_vec new_vec)

And then look for false results in the array and send a notification to
Swing.

On Fri, Feb 20, 2009 at 5:40 AM, Rowdy Rednose wrote:

>
> All the clojure swing examples I've seen so far use JTables in a
> static way, i.e. the data is not programmatically modified once the
> table got created.
>
> Has anyone actually tried to implement a TableModel that is backed by
> a clojure Vector/Map and fires events to TableModelListeners when the
> underlying data changes?
>
> I've got a few ideas on how to implement this, but none of them seems
> to be very elegant (which is why I am interested in clojure in the
> first place).
>
> For those of you who don't know the events that a TableModel fires,
> they are:
>
> * Table has changed ( => redraw the whole thing)
> * Rows x through y have changed (=> redraw only those)
> * Rows x through y have been inserted
> * Rows x through y have been deleted
>
> (Full details:
> http://java.sun.com/javase/6/docs/api/javax/swing/event/TableModelEvent.html
> )
>
> Any elegant ideas or examples on how to do this when the underlying
> data structure is (a ref to) one of clojure's (immutable) collections,
> so that a change to that structure will fire the appropriate event?
>
> >
>

--~--~-~--~~~---~--~~
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
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: how to learn clojure ?

[Jeffrey Straszheim]

The Common Lisp and Scheme books suggested are great, of course,
particularly _On Lisp_.  However, I think learning CL or Scheme is an
awfully roundabout way to learn Clojure.

I think we should really be pushing the Pragmatic book.  It is good and gets
the user to Clojure in a straight line.

On Wed, Feb 18, 2009 at 6:11 PM, Timothy Pratley
wrote:

>
> If you want to dive straight into Clojure I hope this might help:
> http://en.wikibooks.org/wiki/Clojure_Programming/By_Example
>
> >
>

--~--~-~--~~~---~--~~
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
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.contrib: name changes in monads

[Jeffrey Straszheim]

I like that.  It makes it clear what is a monad, and what is not.

On Wed, Feb 18, 2009 at 3:24 AM, Konrad Hinsen wrote:

>
> The latest Clojure version broke many of my code by introducing the
> function sequence whose name collided with my sequence monad. So I
> decided that since now is the time for breaking changes, I should
> solve that kind of problem thoroughly. I just renamed all monads in
> clojure.contrib.monads and clojure.contrib.probabilities, the names
> now have a -m suffix: sequence-m, maybe-m, etc.
>
> Konrad.
>
> >
>

--~--~-~--~~~---~--~~
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
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: Datalog update

[Jeffrey Straszheim]

Makes sense.  That would work.  It certainly looks cleaner.

On Wed, Feb 18, 2009 at 4:51 PM, Rich Hickey  wrote:

>
>
>
> On Feb 18, 4:32 pm, Jeffrey Straszheim 
> wrote:
> > Easy enough to do.  The only drawback is I'd probably want to force it
> into
> > a hash during the query.  For large datasets (say 100,000 records) this
> > might get expensive.
> >
>
> What I envisioned was that while this was the logical db, 'inserting'
> any tuple would also add it to internal indexes, including of course a
> default index on relname. You'd declare which other keys to index, and
> how (sorted/hashed) when creating the db.
>
> Rich
>
> > On Wed, Feb 18, 2009 at 4:13 PM, Rich Hickey 
> wrote:
> >
> > > On Feb 18, 3:51 pm, Jeffrey Straszheim 
> > > wrote:
> > > > Yes.  I've been thinking about a database layer that would support
> > > indexing,
> > > > constraints, and so on.  One step at a time.
> >
> > > Maybe I wasn't clear, I'm talking about the foundational layer.
> > > Instead of:
> >
> > > (def data {
> > >  :table-1 #{ { :x 34 :y 33 } { :x 33 :y :fred } { :x "k" :y \u } }
> > >  :table-2 #{ { :a "fred" :b "mary" } { :a "sally" :b "joan" } }
> > > })
> >
> > > I'm recommending:
> >
> > > (def data
> > > #{{:rel :table-1 :x 34 :y 33 }
> > >   {:rel :table-1 :x 33 :y :fred }
> > >   {:rel :table-1 :x "k" :y \u }
> > >   {:rel :table-2 :a "fred" :b "mary"}
> > >   {:rel :table-2 :a "sally" :b "joan" }})
> >
> > > i.e. making relation and rule names non-special.
> >
> > > Rich
> >
> > > > (logic-rule (:fred :x ?x :y ?y) - (:sally :x ?x :z ?z) ("becky" :y
> ?y)
> > > >(not! :janet :qqq ?z) (if < ?x
> ?y))
> >
> > > > Translated into positional notation (assuming the columns are named
> in
> > > the
> > > > obvious way):
> >
> > > >   fred(X,Y) :- sally(X,Z), becky(Y), ~Janet(Z), when X >
> > > > The "<" symbol can be any Clojure callable.  Its return value will be
> > > > interpreted as a boolean.
> >
> > > > So, you'd get every X,Z from the relation sally, cross product with
> every
> > > Y
> > > > from becky, remove each tuple that has a Z in janet, and also remove
> any
> > > > tuple where X relation
> > > > fred.
> >
> > > > On Wed, Feb 18, 2009 at 3:23 PM, Rich Hickey 
> > > wrote:
> >
> > > > > On Feb 9, 8:46 am, Jeffrey Straszheim  >
> > > > > wrote:
> > > > > > No, but I'm really learning as I go here.  I'll look into it.
> >
> > > > > > On Mon, Feb 9, 2009 at 7:58 AM, Rich Hickey <
> richhic...@gmail.com>
> > > > > wrote:
> >
> > > > > > > Looks like you're moving apace!
> >
> > > > > > > Have you considered query/subquery optimization instead of
> magic
> > > sets?
> >
> > > > > > > Rich
> >
> > > > > > > On Feb 8, 7:51 pm, Jeffrey Straszheim <
> straszheimjeff...@gmail.com
> >
> > > > > > > wrote:
> > > > > > > > By the way, if anyone on this list has experience
> implementing
> > > > > bottom-up
> > > > > > > > optimizations for logic programs, particularly from the magic
> set
> > > > > family,
> > > > > > > > and is willing to assist, please contact me.
> >
> > > > > > > > On Sun, Feb 8, 2009 at 7:47 PM, Jeffrey Straszheim <
> >
> > > > > > > > straszheimjeff...@gmail.com> wrote:
> >
> > > > > > > > > Stratified negation is working and in trunk.
> >
> > > > > > > > > I have some cool ideas of a simple, but powerful, way to
> > > implement
> > > > > > > > > evaluable predicates.  They'll likely make it in by
> midweek.
> >
> > > > > > > > > The the hard part (magic sets) begins.
> >
> > > > > > > > > On Feb 8, 11:43 am, Jeffrey Straszheim <
> > > > > straszheimjeff...@gmail.com>
> > > > > > > > > wro

Re: Datalog update

[Jeffrey Straszheim]

Easy enough to do.  The only drawback is I'd probably want to force it into
a hash during the query.  For large datasets (say 100,000 records) this
might get expensive.

On Wed, Feb 18, 2009 at 4:13 PM, Rich Hickey  wrote:

>
>
>
> On Feb 18, 3:51 pm, Jeffrey Straszheim 
> wrote:
> > Yes.  I've been thinking about a database layer that would support
> indexing,
> > constraints, and so on.  One step at a time.
>
> Maybe I wasn't clear, I'm talking about the foundational layer.
> Instead of:
>
> (def data {
>  :table-1 #{ { :x 34 :y 33 } { :x 33 :y :fred } { :x "k" :y \u } }
>  :table-2 #{ { :a "fred" :b "mary" } { :a "sally" :b "joan" } }
> })
>
> I'm recommending:
>
> (def data
> #{{:rel :table-1 :x 34 :y 33 }
>   {:rel :table-1 :x 33 :y :fred }
>   {:rel :table-1 :x "k" :y \u }
>   {:rel :table-2 :a "fred" :b "mary"}
>   {:rel :table-2 :a "sally" :b "joan" }})
>
> i.e. making relation and rule names non-special.
>
> Rich
>
> > (logic-rule (:fred :x ?x :y ?y) - (:sally :x ?x :z ?z) ("becky" :y ?y)
> >(not! :janet :qqq ?z) (if < ?x ?y))
> >
> > Translated into positional notation (assuming the columns are named in
> the
> > obvious way):
> >
> >   fred(X,Y) :- sally(X,Z), becky(Y), ~Janet(Z), when X >
> > The "<" symbol can be any Clojure callable.  Its return value will be
> > interpreted as a boolean.
> >
> > So, you'd get every X,Z from the relation sally, cross product with every
> Y
> > from becky, remove each tuple that has a Z in janet, and also remove any
> > tuple where X > fred.
> >
> > On Wed, Feb 18, 2009 at 3:23 PM, Rich Hickey 
> wrote:
> >
> > > On Feb 9, 8:46 am, Jeffrey Straszheim 
> > > wrote:
> > > > No, but I'm really learning as I go here.  I'll look into it.
> >
> > > > On Mon, Feb 9, 2009 at 7:58 AM, Rich Hickey 
> > > wrote:
> >
> > > > > Looks like you're moving apace!
> >
> > > > > Have you considered query/subquery optimization instead of magic
> sets?
> >
> > > > > Rich
> >
> > > > > On Feb 8, 7:51 pm, Jeffrey Straszheim  >
> > > > > wrote:
> > > > > > By the way, if anyone on this list has experience implementing
> > > bottom-up
> > > > > > optimizations for logic programs, particularly from the magic set
> > > family,
> > > > > > and is willing to assist, please contact me.
> >
> > > > > > On Sun, Feb 8, 2009 at 7:47 PM, Jeffrey Straszheim <
> >
> > > > > > straszheimjeff...@gmail.com> wrote:
> >
> > > > > > > Stratified negation is working and in trunk.
> >
> > > > > > > I have some cool ideas of a simple, but powerful, way to
> implement
> > > > > > > evaluable predicates.  They'll likely make it in by midweek.
> >
> > > > > > > The the hard part (magic sets) begins.
> >
> > > > > > > On Feb 8, 11:43 am, Jeffrey Straszheim <
> > > straszheimjeff...@gmail.com>
> > > > > > > wrote:
> > > > > > > > I now have recursive queries working.  My next 3 milestones
> are
> > > > > > > stratified
> > > > > > > > negation, evaluable predicates, and then some version of
> magic
> > > sets
> > > > > > > > optimization.  But now, as long as your queries are
> non-negated
> > > it is
> > > > > > > > working.
> >
> > > > > > > >http://code.google.com/p/clojure-datalog/
> >
> > > I got a chance to look at your docs:
> >
> > >http://code.google.com/p/clojure-datalog/wiki/BasicSyntax
> >
> > > I think your choice of using maps (we don't call them hashes in
> > > Clojure as they might not be hash tables) is right on the money for
> > > Clojure, especially set-of-maps-is-relation, just like clojure.set.
> >
> > > Two thoughts:
> >
> > > I wonder though if the map of rel-names to rels isn't a wart though.
> > > It's a pet peeve of mine that relation names don't end up in the db
> > > like any other attribute. Yes, they'll need to be indexed, but
> > > eventually you'll want to support indexing on any desired attributes
> > > as well. Putting relation names in the db gives you a uniform meta-
> > > query capability. I haven't thought this all the way through, but you
> > > might want to think about it.
> >
> > > I didn't know how to interpret this:
> >
> > > (logic-rule (:fred :x ?x :y ?y) - (:sally :x ?x :z ?z) ("becky" :y ?y)
> > >(not! :janet :qqq ?z) (if < ?x ?
> > > y))
> >
> > > Overall, it looks very promising!
> >
> > > If you weren't aware of it:
> >
> > > Foundations of Databases: The Logical Level
> > > Serge Abiteboul, Richard Hull, Victor Vianu
> >
> > >http://www.amazon.com/gp/product/0201537710
> >
> > > has good coverage of Datalog, including QSQ.
> >
> > > 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
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: Contributing

[Jeffrey Straszheim]

Did you cover logic programming?  Any bottom up logic query techniques?
(My motives are probably transparent.)

On Wed, Feb 18, 2009 at 2:34 PM, Joshua  wrote:

>
> I am currently in a masters level Compiler class. We have a final
> project for the class and I was wondering if there would be any
> defects/enhancements that I could do in Clojure. I have about 5 years
> of professional Java experience with dabbling with some other
> languages. (not an expert, but pretty good). The amount of work for
> the project should be about 20-40 hours (I have a month).
>
> Please let me know of any suggestions.
>
> Joshua
>
> >
>

--~--~-~--~~~---~--~~
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
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: Datalog update

[Jeffrey Straszheim]

Yes.  I've been thinking about a database layer that would support indexing,
constraints, and so on.  One step at a time.
(logic-rule (:fred :x ?x :y ?y) - (:sally :x ?x :z ?z) ("becky" :y ?y)
   (not! :janet :qqq ?z) (if < ?x ?y))

Translated into positional notation (assuming the columns are named in the
obvious way):

  fred(X,Y) :- sally(X,Z), becky(Y), ~Janet(Z), when X wrote:

>
>
>
> On Feb 9, 8:46 am, Jeffrey Straszheim 
> wrote:
> > No, but I'm really learning as I go here.  I'll look into it.
> >
> > On Mon, Feb 9, 2009 at 7:58 AM, Rich Hickey 
> wrote:
> >
> > > Looks like you're moving apace!
> >
> > > Have you considered query/subquery optimization instead of magic sets?
> >
> > > Rich
> >
> > > On Feb 8, 7:51 pm, Jeffrey Straszheim 
> > > wrote:
> > > > By the way, if anyone on this list has experience implementing
> bottom-up
> > > > optimizations for logic programs, particularly from the magic set
> family,
> > > > and is willing to assist, please contact me.
> >
> > > > On Sun, Feb 8, 2009 at 7:47 PM, Jeffrey Straszheim <
> >
> > > > straszheimjeff...@gmail.com> wrote:
> >
> > > > > Stratified negation is working and in trunk.
> >
> > > > > I have some cool ideas of a simple, but powerful, way to implement
> > > > > evaluable predicates.  They'll likely make it in by midweek.
> >
> > > > > The the hard part (magic sets) begins.
> >
> > > > > On Feb 8, 11:43 am, Jeffrey Straszheim <
> straszheimjeff...@gmail.com>
> > > > > wrote:
> > > > > > I now have recursive queries working.  My next 3 milestones are
> > > > > stratified
> > > > > > negation, evaluable predicates, and then some version of magic
> sets
> > > > > > optimization.  But now, as long as your queries are non-negated
> it is
> > > > > > working.
> >
> > > > > >http://code.google.com/p/clojure-datalog/
>
> I got a chance to look at your docs:
>
> http://code.google.com/p/clojure-datalog/wiki/BasicSyntax
>
> I think your choice of using maps (we don't call them hashes in
> Clojure as they might not be hash tables) is right on the money for
> Clojure, especially set-of-maps-is-relation, just like clojure.set.
>
> Two thoughts:
>
> I wonder though if the map of rel-names to rels isn't a wart though.
> It's a pet peeve of mine that relation names don't end up in the db
> like any other attribute. Yes, they'll need to be indexed, but
> eventually you'll want to support indexing on any desired attributes
> as well. Putting relation names in the db gives you a uniform meta-
> query capability. I haven't thought this all the way through, but you
> might want to think about it.
>
> I didn't know how to interpret this:
>
> (logic-rule (:fred :x ?x :y ?y) - (:sally :x ?x :z ?z) ("becky" :y ?y)
>(not! :janet :qqq ?z) (if < ?x ?
> y))
>
>
> Overall, it looks very promising!
>
> If you weren't aware of it:
>
> Foundations of Databases: The Logical Level
> Serge Abiteboul, Richard Hull, Victor Vianu
>
> http://www.amazon.com/gp/product/0201537710
>
> has good coverage of Datalog, including QSQ.
>
> 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
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: Performance of (fn [] ...)?

[Jeffrey Straszheim]

Creating a small object like that is cheap on the JVM.  There are much
better places to put optimization effort.

On Wed, Feb 18, 2009 at 1:07 PM, Michel Salim wrote:

>
>
>
> On Feb 18, 3:17 am, Laurent PETIT  wrote:
> > Hello,
> >
> > 2009/2/18 CuppoJava 
> >
> >
> >
> > > Hi,
> > > I've noticed that I'm creating a lot of maps of functions, and I'm
> > > wondering if there's a performance penalty for this.
> >
> > > ie.
> > > (defn create_fn []
> > >  (fn [] (println "hi")))
> >
> > If you use AOT compilation, you'll see that this code will add 2 new
> classes
> > to the namespace it is declared in : one class for create_fn itself, and
> one
> > anonymous class for (fn [] (println "hi"))
> >
> > > ((create_fn))   <--- Does this "create" a new function every-time it's
> > > called? Or is the function code cached somewhere? How much of a
> > > performance penalty does this incur?
> >
> > Each call to create_fn will create a new instance (object) of the
> anonymous
> > class for (fn [] (println "hi"))
> >
> Is this something that will eventually be optimized? This anonymous
> function does not capture any variable, and therefore can just be
> instantiated once.
>
> Regards,
>
> --
> Michel S.
> >
>

--~--~-~--~~~---~--~~
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
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: Questions about a Clojure Datalog

[Jeffrey Straszheim]

I see nothing in his code or documentation for handling negation or
stratification.  Also, it appears to be a top down evaluator, and I don't
see any fixed-point or other recursion handling.  I *suspect* this does not
guarantee termination over arbitrary safe rules.  It is not real Datalog.

On Wed, Feb 18, 2009 at 12:42 PM, Telman Yusupov  wrote:

>
> Could this be of any help for your development? There is now a version
> of Datalog for PLT Scheme:
>
> Software:
>
> http://planet.plt-scheme.org/display.ss?package=datalog.plt&owner=jaymccarthy
>
> Documentation:
>
> http://planet.plt-scheme.org/package-source/jaymccarthy/datalog.plt/1/0/planet-docs/datalog/index.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
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: Questions about a Clojure Datalog

[Jeffrey Straszheim]

It is worth looking at.

On Wed, Feb 18, 2009 at 12:42 PM, Telman Yusupov  wrote:

>
> Could this be of any help for your development? There is now a version
> of Datalog for PLT Scheme:
>
> Software:
>
> http://planet.plt-scheme.org/display.ss?package=datalog.plt&owner=jaymccarthy
>
> Documentation:
>
> http://planet.plt-scheme.org/package-source/jaymccarthy/datalog.plt/1/0/planet-docs/datalog/index.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
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
-~--~~~~--~~--~--~---