Re: symbolic protocols

[kovas boguta]

Letting interprete also consume functions as well as protocols would
let it bottom out into actual clojure code that actually implements
some logic.

Though it would also be handy so have some kind of (escape [bindings]
body) clause to allow binding to normal code to temporary names for
the sake of implementing logic but without risk of conflict with the
symbolic code.


On Tue, Jan 8, 2013 at 2:29 AM, kovas boguta  wrote:
> Maybe the use cases would be more clearer if I fleshed out the
> interprete operation.
>
> The typical case would be
>
> (interprete expression [protocol1 protocol2 protocol3 ...])
>
> interprete would limit its operation the protocols specified;
> everything else would be inert.
>
> To implement compiler passes, you would do
>
> (-> expression
> (interprete protocols-for-phase-1)
> (interprete protocols-for-phase-2)
> ...)
>
> and out would come the final expression.
>
>
> On Tue, Jan 8, 2013 at 2:15 AM, kovas boguta  wrote:
>> Close.
>>
>> The defmulti would be closer to
>>
>>  (defmulti mm first)
>>
>> because we need to dig into the list to get the first symbol.
>>
>> But there need to be a way to recurse as well, if you want to
>> interprete the whole expression. That part is hard to capture in the
>> multimethod.
>>
>> (interprete '(foo (bar 1)))
>>
>> whether you start at foo and go down or at bar and go up could be a
>> property of the symbolic system, itself determined by protocols.
>>
>>
>>
>> On Tue, Jan 8, 2013 at 2:05 AM, Ambrose Bonnaire-Sergeant
>>  wrote:
>>> Semantically, are you thinking along the lines of a multimethod that
>>> dispatches on identity?
>>>
>>> (defmulti mm identity)
>>>
>>> (defmethod mm 'bar
>>>   ...)
>>>
>>> (defmethod mm 'foo
>>>   ...)
>>>
>>> Thanks,
>>> Ambrose
>>>
>>> On Tue, Jan 8, 2013 at 2:56 PM, kovas boguta  wrote:

 This is a pretty embryonic idea, but I'm wondering if anyone has
 thought the same, or seen relevant examples/literature.

 The idea is: What if we could attach protocols to symbols themselves?

 so (foo '(bar 1))

 would have its behavior defined by a protocol implemented on the symbol
 bar.

 This could be a way to create symbolic systems in clojure.

 Besides being of theoretical interest, symbolic systems can be a
 composable way to achieve metaprogramming.

 We could instruct that any expression should be first interpreted
 symbolically with a tag like #symbolic

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

-- 
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: Unit testing

[Meikel Brandmeyer (kotarak)]

Hi,

Am Dienstag, 8. Januar 2013 08:50:05 UTC+1 schrieb Eric MacAdie:
>
> Is there a common unit testing framework for Clojure? I did some googling, 
> put all the results were a couple of years old. 
>
>
clojure.test ships with clojure proper. And midje is also very popular.

Kind regards
Meikel
 

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

Re: Unit testing

[keeds]

Expectations is a good framework.

https://github.com/jaycfields/expectations

On Tuesday, January 8, 2013 7:50:05 AM UTC, Eric MacAdie wrote:
>
> Is there a common unit testing framework for Clojure? I did some googling, 
> put all the results were a couple of years old. 
>
> - Eric MacAdie
>
>

-- 
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: Unit testing

[Alex Baranosky]

There's also Midje: https://github.com/marick/Midje

On Tue, Jan 8, 2013 at 12:54 AM, keeds  wrote:

> Expectations is a good framework.
>
> https://github.com/jaycfields/expectations
>
>
> On Tuesday, January 8, 2013 7:50:05 AM UTC, Eric MacAdie wrote:
>>
>> Is there a common unit testing framework for Clojure? I did some
>> googling, put all the results were a couple of years old.
>>
>> - Eric MacAdie
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Convincing employer to go for Clojure

[Marko Topolnik]

> 2. What are good examples of complex domains that have been tackled with 
> Clojure web apps and API layers?
>

At my company we have built an entire B2B platform that drives the exchange 
of business documents for my country's largest company. Our first 
production version was on Clojure 0.9 and has been rock-solid from that day 
on. My previous experience with anything else JVM-based has been fraught 
with many more reliability and performance issues (various application 
containers, for example). The smaller codebase means less bugs, and bugs of 
coarser granularity. They are more visible in running code, more obvious to 
locate in the source code, fixed soon never to return.

As a different example, we have also built several JFace/SWT WebStart 
applications, with similar success. In this case the ease of building DSLs 
in Clojure has made a great mark: we have beautifully succint descriptions 
of window layouts, together with action handlers. Hacking together a GUI 
library has been a great pleasure for me.
 

> 3. What major road blocks have teams discovered at the edges of Clojure 
> (keeping in mind that perhaps several of these problems could be solved 
> using native Java calls)?
>

Nothing major; as you already point out, at rare occasions one needs some 
Java code. Mind that it is not for performance, but in some complicated 
interop scenarios. Writing top-performant code in Clojure is mostly 
possible, but often harder than in Java, especially if you want to port a 
performant Java solution to Clojure.
 

> What other tips do you have for convincing an employer that Clojure makes 
> good business sense? (Of course I've already told them about 
> domain-tailored abstractions, containing complexity, the ease of data 
> manipulation with a functional language, etc.)
>

My favorite is hot-patching production code by just using vi to edit it at 
the server. My workflow:

   1. read the server logs;
   2. if not enough data, introduce focused logging statements to server 
   code;
   3. reproduce the problem and fix it locally;
   4. make the necessary edit right at the server.

In most cases I am able to deploy an emergency bugfix within one hour, 
while the employees whose business depends on this take a coffee break. My 
client *loves* this. On the other hand, since Day One the client has 
experienced perhaps a dozen of such bugs. After that, the code has just 
been running completely unattended for months.

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

Feature Expressions

[Irakli Gozalishvili]

Hi Folks, 

I wanted to comment on "Feature Expressions" feature page, but it looks like 
special privileges are required, so I thought I'd post my questions / feedback 
here. 

I've being working on client side JS for a while and I'm well aware of hazards 
associated with platform specific code  branching. Although solution that in my 
experience worked best, was move to more granular a codebase, isolating 
platform specific code from a common one. 

I think this would be a great direction for clojure / clojurescript ? As a 
matter of fact it would be tremendous help for newcomers like myself to have a 
baseline libraries abstracting platform differences that would not assume 
specific backgrounds in Java or JS. 

Please don't take this a wrong way, but I do believe most problems are not 
caused by inability to switch between platform
specific code, but rather by a lack of baseline that would allow writing a 
common code. 
Here are few examples:

Otherwise perfectly portable clojure compatible clojurescript code won't work 
because in clojurescript one needs to extend
default type while in clojure it's Object instead. I don't know actual reason 
here but have a feeling that common thing could
be created that would work for both.
https://github.com/Gozala/eventual-cljs/blob/master/src/core.cljs#L26

Another interesting case is try special form which clearly does not fits JS 
since catching
exceptions by a classname does not really make much sense there. 
http://clojure.org/special_forms#try

Also as far as I can tell in order to throw an exception one need to either 
access
js/Error or one of Exception classes on Java.

I do believe identifying & fixing such cases, so that non platform specific 
code could be written without accessing
platform specific constructs would solve most of the issues without introducing 
further complexity. In fact it would
make platform more accessible for others.

Another thing I wanted to point out was racket's submodules which may be 
another interesting option to consider:
http://blog.racket-lang.org/2012/06/submodules.html


P.S: My apologies, if some of my comments are incorrect it could be that I'm 
still missing important parts of the puzzle.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

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

Re: Convincing employer to go for Clojure

[Colin Yates]

I would ask "what problem would Clojure solve that the current technology X 
doesn't"?  There are no invalid answers to this, but it is important to 
understand *why* you want to move to Clojure.

Perfectly valid answers might be:

 - our domain is best solved with functional programming and we want to 
stay on the JVM
 - problem X is best solved using macros
 - I am bored with writing Java
 - our apps are trivial and there is far too high a signal to noise ratio 
when using hibernate, spring etc.
 - our domain involves highly concurrent mutation of state and needs to 
scale vertically 

I would also identify the risks as well.

Ultimately you need to be able to articulate why, both to yourself and your 
bosses.  Just to throw the cat into the pidgeons I went through this very 
same process and concluded that Scala was a better choice for me - I just 
can't give up that strong typing/API boundary contract enforcement and I 
just couldn't make the leap to functional programming fast enough 
principles.  I have to say for me, OO was working fine as well but that is 
another story :).

In my experience, any change of technology *and paradigm* will cost more 
than you expect, so if you do make the leap cover your back and make it 
explicit, which will ultimately involve justifying it.

Col

P.S.  I still thing Clojure is absolutely fantastic, and I am still craving 
to try it Clojure, but I need to take a longer path than my usual install 
it, build things and then learn about it :).  Is there a "Functional 
programming with Clojure" coursera course?

On Monday, 7 January 2013 23:02:37 UTC, David Jacobs wrote:
>
> Hey guys,
>
> As someone who's written Clojure for a couple of years now, I would love 
> to convince my new company to build our platform using Clojure from the 
> start. Clojure is certainly a possibility for our small team, but a few 
> questions will have to be answered before I can convince everyone that 
> Clojure is worth using:
>
> 1. Would it be harder to hire if we built our apps with Clojure? More 
> specifically: Hiring for people who know about or already love Clojure/FP 
> is certainly a nice filter for talent, but is it too stringent of a filter? 
> What percentage of the Clojure community wants to code Clojure 
> professionally but isn't right now? Do we have metrics on that?
>
> 2. What are good examples of complex domains that have been tackled with 
> Clojure web apps and API layers?
>
> 3. What major road blocks have teams discovered at the edges of Clojure 
> (keeping in mind that perhaps several of these problems could be solved 
> using native Java calls)?
>
> What other tips do you have for convincing an employer that Clojure makes 
> good business sense? (Of course I've already told them about 
> domain-tailored abstractions, containing complexity, the ease of data 
> manipulation with a functional language, etc.)
>
> Best,
> David
>

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

Re: Feature Expressions

[Dave Sann]

there have been a number of previous discussions FYI.

This was one I could find:

https://groups.google.com/d/topic/clojure/LQcBEph-3Bg/discussion



On Tuesday, 8 January 2013 22:24:26 UTC+11, Irakli Gozalishvili wrote:
>
> Hi Folks, 
>
> I wanted to comment on "Feature Expressions" feature page, but it looks 
> like special privileges are required, so I thought I'd post my questions / 
> feedback here. 
>
> I've being working on client side JS for a while and I'm well aware of 
> hazards associated with platform specific code  branching. Although 
> solution that in my experience worked best, was move to more granular a 
> codebase, isolating platform specific code from a common one. 
>
> I think this would be a great direction for clojure / clojurescript ? As a 
> matter of fact it would be tremendous help for newcomers like myself to 
> have a baseline libraries abstracting platform differences that would not 
> assume specific backgrounds in Java or JS. 
>
> Please don't take this a wrong way, but I do believe most problems are not 
> caused by inability to switch between platform
> specific code, but rather by a lack of baseline that would allow writing a 
> common code. 
> Here are few examples:
>
> Otherwise perfectly portable clojure compatible clojurescript code won't 
> work because in clojurescript one needs to extend
> default type while in clojure it's Object instead. I don't know actual 
> reason here but have a feeling that common thing could
> be created that would work for both.
> https://github.com/Gozala/eventual-cljs/blob/master/src/core.cljs#L26
>
> Another interesting case is try special form which clearly does not fits 
> JS since catching
> exceptions by a classname does not really make much sense there. 
> http://clojure.org/special_forms#try
>
> Also as far as I can tell in order to throw an exception one need to 
> either access
> js/Error or one of Exception classes on Java.
>
> I do believe identifying & fixing such cases, so that non 
> platform specific code could be written without accessing
> platform specific constructs would solve most of the issues without 
> introducing further complexity. In fact it would
> make platform more accessible for others.
>
> Another thing I wanted to point out was racket's submodules which may be 
> another interesting option to consider:
> http://blog.racket-lang.org/2012/06/submodules.html
>
>
> P.S: My apologies, if some of my comments are incorrect it could be that 
> I'm still missing important parts of the puzzle.
>
> Regards
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
>
>

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

Re: core.logic: datomic unification

[David Nolen]

The dispatching mechanism was more trouble than it was worth but we did
lose some flexibility. Do you really need to unify Sequential or is
unifying with a concrete type like PersistentVector work well enough for
your use case?

David


On Tue, Jan 8, 2013 at 2:01 AM, Austin Haas  wrote:

>
> The datomic unification code in core.logic has bit-rotted. It depends on
> IUnifyWithSequential, which was removed in this commit:
> https://github.com/clojure/core.logic/commit/bbc4e820128d5a0745ce3d79cd3bbd9401a1bf55
>
> I'm trying to understand how to update the code, but I don't get how
> dispatching works following the above commit. It appears that each
> implementation of IUnifyTerms must dispatch on the second argument, and I
> don't see how to get clojure.lang.Sequential to dispatch on a datom unless
> I override the implementation of clojure.lang.Sequential unify-terms here:
> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1581
>
> I must be missing something. Any pointers would be appreciated.
>
> -austin
>
> --
> Austin Haas
> Pet Tomato, Inc.
> http://pettomato.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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

nREPL 0.2.0-RC2

[Chas Emerick]

I released [org.clojure/tools.nrepl "0.2.0-RC2"] last night.  Thanks to Tim 
Pope for raising a couple of issues he encountered through the course of his 
integrating nREPL into foreplay last month.

This will be 0.2.0 final later this week, barring any jarring new bug reports.

Also note that nREPL documentation has been significantly refreshed since RC1:

* More comprehensive, updated README detailing usage, architecture, etc: 
https://github.com/clojure/tools.nrepl/blob/master/README.md

* Central listing of known nREPL middleware and transports: 
https://github.com/clojure/tools.nrepl/wiki/Extensions

Cheers,

- Chas

-- 
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: Convincing employer to go for Clojure

[Colin Yates]

(please ignore the atrocious speling mistax in my previous post - not 
enough sleep)

On Tuesday, 8 January 2013 12:05:11 UTC, Colin Yates wrote:
>
> I would ask "what problem would Clojure solve that the current technology 
> X doesn't"?  There are no invalid answers to this, but it is important to 
> understand *why* you want to move to Clojure.
>
> Perfectly valid answers might be:
>
>  - our domain is best solved with functional programming and we want to 
> stay on the JVM
>  - problem X is best solved using macros
>  - I am bored with writing Java
>  - our apps are trivial and there is far too high a signal to noise ratio 
> when using hibernate, spring etc.
>  - our domain involves highly concurrent mutation of state and needs to 
> scale vertically 
>
> I would also identify the risks as well.
>
> Ultimately you need to be able to articulate why, both to yourself and 
> your bosses.  Just to throw the cat into the pidgeons I went through this 
> very same process and concluded that Scala was a better choice for me - I 
> just can't give up that strong typing/API boundary contract enforcement and 
> I just couldn't make the leap to functional programming fast enough 
> principles.  I have to say for me, OO was working fine as well but that is 
> another story :).
>
> In my experience, any change of technology *and paradigm* will cost more 
> than you expect, so if you do make the leap cover your back and make it 
> explicit, which will ultimately involve justifying it.
>
> Col
>
> P.S.  I still thing Clojure is absolutely fantastic, and I am still 
> craving to try it Clojure, but I need to take a longer path than my usual 
> install it, build things and then learn about it :).  Is there a 
> "Functional programming with Clojure" coursera course?
>
> On Monday, 7 January 2013 23:02:37 UTC, David Jacobs wrote:
>>
>> Hey guys,
>>
>> As someone who's written Clojure for a couple of years now, I would love 
>> to convince my new company to build our platform using Clojure from the 
>> start. Clojure is certainly a possibility for our small team, but a few 
>> questions will have to be answered before I can convince everyone that 
>> Clojure is worth using:
>>
>> 1. Would it be harder to hire if we built our apps with Clojure? More 
>> specifically: Hiring for people who know about or already love Clojure/FP 
>> is certainly a nice filter for talent, but is it too stringent of a filter? 
>> What percentage of the Clojure community wants to code Clojure 
>> professionally but isn't right now? Do we have metrics on that?
>>
>> 2. What are good examples of complex domains that have been tackled with 
>> Clojure web apps and API layers?
>>
>> 3. What major road blocks have teams discovered at the edges of Clojure 
>> (keeping in mind that perhaps several of these problems could be solved 
>> using native Java calls)?
>>
>> What other tips do you have for convincing an employer that Clojure makes 
>> good business sense? (Of course I've already told them about 
>> domain-tailored abstractions, containing complexity, the ease of data 
>> manipulation with a functional language, etc.)
>>
>> Best,
>> David
>>
>

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

Re: Clojure Conj Videos

[Lynn Grogan]

Alright, the first 2012 video is up on Youtube: 
http://www.youtube.com/watch?v=Mfsnlbd-4xQ. Chris Ford on Functional 
Composition. 
Expect 1-2 more videos every day. 

Cheers! Lynn



On Sunday, January 6, 2013 5:26:33 AM UTC-5, kinleyd wrote:
>
> You are right Alex. I got it mixed up since I've been waiting for both the 
> Strange Loop and the Clojure Conj talks on InfoQ.
>
> On Sunday, January 6, 2013 7:29:15 AM UTC+6, Alex Miller wrote:
>>
>> Barski hasn't spoken at Strange Loop, perhaps you mean his talk at the 
>> conj?
>>
>> On Friday, January 4, 2013 3:30:55 AM UTC-6, kinleyd wrote:
>>>
>>> Thanks for taking the trouble Alex - that was pretty comprehensive. I've 
>>> seen Rathore's and Nolen's (both excellent), skipped Stokke's (but only 
>>> because Catnip didn't interest me) and was looking forward to Barski (but 
>>> don't see him on the horizon though his talk was delivered a while back). I 
>>> will now go through the others that you have listed. 
>>>
>>> On Friday, January 4, 2013 9:45:06 AM UTC+6, Alex Miller wrote:

 The full Strange Loop video schedule is here: 
 https://thestrangeloop.com/news/strange-loop-2012-video-schedule

 Re Clojure talks, 

 Already released related in some way to Clojure and ClojureScript:
 - Nathan Marz on big data - 
 http://www.infoq.com/presentations/Complexity-Big-Data
 - Jim Weirich on Y Combinator - 
 http://www.infoq.com/presentations/Y-Combinator
 - Chris Granger on Light Table - 
 http://www.infoq.com/presentations/Learn-Tools
 - David Nolen on ClojureScript - 
 http://www.infoq.com/presentations/ClojureScript-Optimizations
 - Amit Rathore on Clojure+Datomic+Storm - 
 http://www.infoq.com/presentations/Zolodeck
 - Bodil Stokke on Catnip IDE and ClojureScript - 
 http://www.infoq.com/presentations/Catnip

 Still to be released:
 - Jason Wolfe's talk on the Prismatic Graph library is coming out week 
 of Jan 28th
 - Kevin Lynagh's talk on his ClojureScript visualization lib is week of 
 Feb 11th
 - Rich Hickey's talk is scheduled for week of Mar 18th but same one has 
 already been released on InfoQ so not sure if they'll re-release it
 - Stuart Sierra's talk on functional design patterns is week of Apr 1st

 Sorry if I missed any.

 Alex

 On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote:
>
> I've been waiting forever for the recent Strange Loop Clojure talks to 
> be made available as well. So far I've only seen two, Amit Rathore's 
> "Clojure + Datomic + Stomr = Zolodeck" and David Nolen's "ClojureScript - 
> Better semantics at low, low prices" on InfoQ. Any one have any idea when 
> the others will be made available? 
>
> On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote:
>>
>> Let the party begin :-)
>>
>> On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote:
>>>
>>> Confreaks is just completing the final edits on the videos and we 
>>> should be releasing them soon (in a week or so?). 
>>> Of course, it will probably be a staggered release just to drive 
>>> everyone crazy ;) 
>>>
>>> Lynn Grogan
>>> Relevance
>>>
>>> On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote:

 On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt  
 wrote: 
 > 
 > +1 - I'm sure I've even seen any BLOGS on this years Conj let 
 alone videos. 

 http://corfield.org/blog/post.cfm/clojure-conj-2012 
 -- 
 Sean A Corfield -- (904) 302-SEAN 
 An Architect's View -- http://corfield.org/ 
 World Singles, LLC. -- http://worldsingles.com/ 

 "Perfection is the enemy of the good." 
 -- Gustave Flaubert, French realist novelist (1821-1880) 

>>>

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

Re: Clojure Conj Videos

[Paul deGrandis]

Thanks for the update Lynn!

Paul

On Tuesday, January 8, 2013 7:06:32 AM UTC-8, Lynn Grogan wrote:
>
> Alright, the first 2012 video is up on Youtube: 
> http://www.youtube.com/watch?v=Mfsnlbd-4xQ. Chris Ford on Functional 
> Composition. 
> Expect 1-2 more videos every day. 
>
> Cheers! Lynn
>
>
>
> On Sunday, January 6, 2013 5:26:33 AM UTC-5, kinleyd wrote:
>>
>> You are right Alex. I got it mixed up since I've been waiting for both 
>> the Strange Loop and the Clojure Conj talks on InfoQ.
>>
>> On Sunday, January 6, 2013 7:29:15 AM UTC+6, Alex Miller wrote:
>>>
>>> Barski hasn't spoken at Strange Loop, perhaps you mean his talk at the 
>>> conj?
>>>
>>> On Friday, January 4, 2013 3:30:55 AM UTC-6, kinleyd wrote:

 Thanks for taking the trouble Alex - that was pretty comprehensive. 
 I've seen Rathore's and Nolen's (both excellent), skipped Stokke's (but 
 only because Catnip didn't interest me) and was looking forward to Barski 
 (but don't see him on the horizon though his talk was delivered a while 
 back). I will now go through the others that you have listed. 

 On Friday, January 4, 2013 9:45:06 AM UTC+6, Alex Miller wrote:
>
> The full Strange Loop video schedule is here: 
> https://thestrangeloop.com/news/strange-loop-2012-video-schedule
>
> Re Clojure talks, 
>
> Already released related in some way to Clojure and ClojureScript:
> - Nathan Marz on big data - 
> http://www.infoq.com/presentations/Complexity-Big-Data
> - Jim Weirich on Y Combinator - 
> http://www.infoq.com/presentations/Y-Combinator
> - Chris Granger on Light Table - 
> http://www.infoq.com/presentations/Learn-Tools
> - David Nolen on ClojureScript - 
> http://www.infoq.com/presentations/ClojureScript-Optimizations
> - Amit Rathore on Clojure+Datomic+Storm - 
> http://www.infoq.com/presentations/Zolodeck
> - Bodil Stokke on Catnip IDE and ClojureScript - 
> http://www.infoq.com/presentations/Catnip
>
> Still to be released:
> - Jason Wolfe's talk on the Prismatic Graph library is coming out week 
> of Jan 28th
> - Kevin Lynagh's talk on his ClojureScript visualization lib is week 
> of Feb 11th
> - Rich Hickey's talk is scheduled for week of Mar 18th but same one 
> has already been released on InfoQ so not sure if they'll re-release it
> - Stuart Sierra's talk on functional design patterns is week of Apr 1st
>
> Sorry if I missed any.
>
> Alex
>
> On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote:
>>
>> I've been waiting forever for the recent Strange Loop Clojure talks 
>> to be made available as well. So far I've only seen two, Amit Rathore's 
>> "Clojure + Datomic + Stomr = Zolodeck" and David Nolen's "ClojureScript 
>> - 
>> Better semantics at low, low prices" on InfoQ. Any one have any idea 
>> when 
>> the others will be made available? 
>>
>> On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote:
>>>
>>> Let the party begin :-)
>>>
>>> On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote:

 Confreaks is just completing the final edits on the videos and we 
 should be releasing them soon (in a week or so?). 
 Of course, it will probably be a staggered release just to drive 
 everyone crazy ;) 

 Lynn Grogan
 Relevance

 On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote:
>
> On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt  
> wrote: 
> > 
> > +1 - I'm sure I've even seen any BLOGS on this years Conj let 
> alone videos. 
>
> http://corfield.org/blog/post.cfm/clojure-conj-2012 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>


-- 
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: Client-Server comunication with shoreleave

[Francesco Agozzino]

Hi Paul,
I'd like to thank You for you precious help.
We managed to use your library and we are going to publish the tutorial in 
the modern-cljs series: https://github.com/magomimmo/modern-cljs .

Cheers,
Francesco

Il giorno lunedì 7 gennaio 2013 18:39:41 UTC+1, Paul deGrandis ha scritto:
>
> Hi Francesco,
>
> Robert Stuttafird's example might help you out: 
> https://github.com/robert-stuttaford/demo-enfocus-pubsub-remote
>
> You may also want to use the remote macros on the client side, they might 
> clean up the code for you a bit.
>
> (ns CLJS-NS
>  (:require-macros [shoreleave.client.remotes.macros :as srm]))
>
> (defn ^:export perform-login [email 
> password-str] 
>   
>
>   (let [valid-password (some-validation 
> password-str] 
>
>
> (srm/rpc (login {:email email
>  :password 
> valid-password})  
>  
>
>  
> [login-response]  
>   
>
>  (js/alert login-response
>
> On the server, I assume you're using Compojure and Ring.
> You'll need to define a remote called, login (it has to match the remote 
> name on the client side).
>
> (defremote login [credentials-map] ...)
>
> And make sure you hook up the RPC middleware on the server-side.  Full 
> instructions can be found here:
> https://github.com/shoreleave/shoreleave-remote-ring
>
>  - - - 
>
> Semi-related - I'm in the middle of a substantial upgrade to all of the 
> Shoreleave pieces (for Shoreleave 0.3), so stay tuned.
>
> Cheers,
> Paul
>
>

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

Re: Clojure Conj Videos

[Marco Munizaga]

This is perfect! I've been waiting forever to show this off to the world. 
Thanks!

On Tuesday, January 8, 2013 10:06:32 AM UTC-5, Lynn Grogan wrote:
>
> Alright, the first 2012 video is up on Youtube: 
> http://www.youtube.com/watch?v=Mfsnlbd-4xQ. Chris Ford on Functional 
> Composition. 
> Expect 1-2 more videos every day. 
>
> Cheers! Lynn
>
>
>
> On Sunday, January 6, 2013 5:26:33 AM UTC-5, kinleyd wrote:
>>
>> You are right Alex. I got it mixed up since I've been waiting for both 
>> the Strange Loop and the Clojure Conj talks on InfoQ.
>>
>> On Sunday, January 6, 2013 7:29:15 AM UTC+6, Alex Miller wrote:
>>>
>>> Barski hasn't spoken at Strange Loop, perhaps you mean his talk at the 
>>> conj?
>>>
>>> On Friday, January 4, 2013 3:30:55 AM UTC-6, kinleyd wrote:

 Thanks for taking the trouble Alex - that was pretty comprehensive. 
 I've seen Rathore's and Nolen's (both excellent), skipped Stokke's (but 
 only because Catnip didn't interest me) and was looking forward to Barski 
 (but don't see him on the horizon though his talk was delivered a while 
 back). I will now go through the others that you have listed. 

 On Friday, January 4, 2013 9:45:06 AM UTC+6, Alex Miller wrote:
>
> The full Strange Loop video schedule is here: 
> https://thestrangeloop.com/news/strange-loop-2012-video-schedule
>
> Re Clojure talks, 
>
> Already released related in some way to Clojure and ClojureScript:
> - Nathan Marz on big data - 
> http://www.infoq.com/presentations/Complexity-Big-Data
> - Jim Weirich on Y Combinator - 
> http://www.infoq.com/presentations/Y-Combinator
> - Chris Granger on Light Table - 
> http://www.infoq.com/presentations/Learn-Tools
> - David Nolen on ClojureScript - 
> http://www.infoq.com/presentations/ClojureScript-Optimizations
> - Amit Rathore on Clojure+Datomic+Storm - 
> http://www.infoq.com/presentations/Zolodeck
> - Bodil Stokke on Catnip IDE and ClojureScript - 
> http://www.infoq.com/presentations/Catnip
>
> Still to be released:
> - Jason Wolfe's talk on the Prismatic Graph library is coming out week 
> of Jan 28th
> - Kevin Lynagh's talk on his ClojureScript visualization lib is week 
> of Feb 11th
> - Rich Hickey's talk is scheduled for week of Mar 18th but same one 
> has already been released on InfoQ so not sure if they'll re-release it
> - Stuart Sierra's talk on functional design patterns is week of Apr 1st
>
> Sorry if I missed any.
>
> Alex
>
> On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote:
>>
>> I've been waiting forever for the recent Strange Loop Clojure talks 
>> to be made available as well. So far I've only seen two, Amit Rathore's 
>> "Clojure + Datomic + Stomr = Zolodeck" and David Nolen's "ClojureScript 
>> - 
>> Better semantics at low, low prices" on InfoQ. Any one have any idea 
>> when 
>> the others will be made available? 
>>
>> On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote:
>>>
>>> Let the party begin :-)
>>>
>>> On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote:

 Confreaks is just completing the final edits on the videos and we 
 should be releasing them soon (in a week or so?). 
 Of course, it will probably be a staggered release just to drive 
 everyone crazy ;) 

 Lynn Grogan
 Relevance

 On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote:
>
> On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt  
> wrote: 
> > 
> > +1 - I'm sure I've even seen any BLOGS on this years Conj let 
> alone videos. 
>
> http://corfield.org/blog/post.cfm/clojure-conj-2012 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>


-- 
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: Convincing employer to go for Clojure

[Softaddicts]

Many businesses are short term driven. The paradigm change so called "cost" 
is a good way to spread fud. However, it may be hard to analyze this
solely on specific language features versus what benefits you may get.

Here, we had a mixed Java/JRuby/Clojure code base since we went in production
in Jan. 2009. Next February we will be 100% Clojure minus a couple of Rails API.

This a code reduction from 270k sloc (excuding JRuby) to around 15k sloc in 
Clojure.
Basta OO ! Welcome the age of FP.

The maintenance as eased up a lot, we can apply live patches (this is a critical
system and must be up 24/7) and dig into live processes as needed to maintain
uptime.

Monitoring and scalability in production have also greatly benefited from a 
small footprint nucleus. 

We are also doing things that cannot be done in Java at all.
Most of our processing is driven by data... data here means a
combo of persistent structures and behaviors as closures embedded in it.
It is aligned with our business domain, no framework in the middle to 
fog our understanding of it.

It beats XML by a few hundred light years. We redesigned the entire system 
according
to this principle. The data is our contract. No wrappers needed.

This system is a polyglot system that allows alien systems to communicate.
Extensions are done by modifying data, not code. A traditional approach would
require a huge number of maintainers not withstanding the change analysis to
support other systems.

If you do switch to Clojure and want many of the potential benefits, you need a 
mind
shift in your design approach. There are possibly much more innovative 
approaches
in designing a solution for your business problem than what you will find in
other more traditional languages.

If you do not thing out of the box, you may not reap all the possible benefits 
or
understand which ones you may get in the longterm.

Short term thinking will not help much here.

Luc P.

> (please ignore the atrocious speling mistax in my previous post - not 
> enough sleep)
> 
> On Tuesday, 8 January 2013 12:05:11 UTC, Colin Yates wrote:
> >
> > I would ask "what problem would Clojure solve that the current technology 
> > X doesn't"?  There are no invalid answers to this, but it is important to 
> > understand *why* you want to move to Clojure.
> >
> > Perfectly valid answers might be:
> >
> >  - our domain is best solved with functional programming and we want to 
> > stay on the JVM
> >  - problem X is best solved using macros
> >  - I am bored with writing Java
> >  - our apps are trivial and there is far too high a signal to noise ratio 
> > when using hibernate, spring etc.
> >  - our domain involves highly concurrent mutation of state and needs to 
> > scale vertically 
> >
> > I would also identify the risks as well.
> >
> > Ultimately you need to be able to articulate why, both to yourself and 
> > your bosses.  Just to throw the cat into the pidgeons I went through this 
> > very same process and concluded that Scala was a better choice for me - I 
> > just can't give up that strong typing/API boundary contract enforcement and 
> > I just couldn't make the leap to functional programming fast enough 
> > principles.  I have to say for me, OO was working fine as well but that is 
> > another story :).
> >
> > In my experience, any change of technology *and paradigm* will cost more 
> > than you expect, so if you do make the leap cover your back and make it 
> > explicit, which will ultimately involve justifying it.
> >
> > Col
> >
> > P.S.  I still thing Clojure is absolutely fantastic, and I am still 
> > craving to try it Clojure, but I need to take a longer path than my usual 
> > install it, build things and then learn about it :).  Is there a 
> > "Functional programming with Clojure" coursera course?
> >
> > On Monday, 7 January 2013 23:02:37 UTC, David Jacobs wrote:
> >>
> >> Hey guys,
> >>
> >> As someone who's written Clojure for a couple of years now, I would love 
> >> to convince my new company to build our platform using Clojure from the 
> >> start. Clojure is certainly a possibility for our small team, but a few 
> >> questions will have to be answered before I can convince everyone that 
> >> Clojure is worth using:
> >>
> >> 1. Would it be harder to hire if we built our apps with Clojure? More 
> >> specifically: Hiring for people who know about or already love Clojure/FP 
> >> is certainly a nice filter for talent, but is it too stringent of a 
> >> filter? 
> >> What percentage of the Clojure community wants to code Clojure 
> >> professionally but isn't right now? Do we have metrics on that?
> >>
> >> 2. What are good examples of complex domains that have been tackled with 
> >> Clojure web apps and API layers?
> >>
> >> 3. What major road blocks have teams discovered at the edges of Clojure 
> >> (keeping in mind that perhaps several of these problems could be solved 
> >> using native Java calls)?
> >>
> >> What other tips do you have for convincing an

Re: core.logic: datomic unification

[Austin Haas]

Ok, thanks, I'll try to get it to work with PersistentVector. 

I just started looking at core.logic's internals, and I'm still fairly new to 
Clojure, so everything is a little fuzzy. I took Sequential for granted, since 
that is referenced in the existing code.

Thanks for the help.

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Tue Jan 08 07:28 , David Nolen wrote:
> The dispatching mechanism was more trouble than it was worth but we did
> lose some flexibility. Do you really need to unify Sequential or is
> unifying with a concrete type like PersistentVector work well enough for
> your use case?
> 
> David
> 
> 
> On Tue, Jan 8, 2013 at 2:01 AM, Austin Haas  wrote:
> 
> >
> > The datomic unification code in core.logic has bit-rotted. It depends on
> > IUnifyWithSequential, which was removed in this commit:
> > https://github.com/clojure/core.logic/commit/bbc4e820128d5a0745ce3d79cd3bbd9401a1bf55
> >
> > I'm trying to understand how to update the code, but I don't get how
> > dispatching works following the above commit. It appears that each
> > implementation of IUnifyTerms must dispatch on the second argument, and I
> > don't see how to get clojure.lang.Sequential to dispatch on a datom unless
> > I override the implementation of clojure.lang.Sequential unify-terms here:
> > https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1581
> >
> > I must be missing something. Any pointers would be appreciated.
> >
> > -austin
> >
> > --
> > Austin Haas
> > Pet Tomato, Inc.
> > http://pettomato.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> >
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Clojure Conj Videos

[Andrew Cristina]

Thanks, by the way, for setting up Clojure TV on youtube.  The experience 
is much nicer than the old location (was it blip?  I don't even remember 
now).

On Tuesday, January 8, 2013 7:06:32 AM UTC-8, Lynn Grogan wrote:
>
> Alright, the first 2012 video is up on Youtube: 
> http://www.youtube.com/watch?v=Mfsnlbd-4xQ. Chris Ford on Functional 
> Composition. 
> Expect 1-2 more videos every day. 
>
> Cheers! Lynn
>
>
>
> On Sunday, January 6, 2013 5:26:33 AM UTC-5, kinleyd wrote:
>>
>> You are right Alex. I got it mixed up since I've been waiting for both 
>> the Strange Loop and the Clojure Conj talks on InfoQ.
>>
>> On Sunday, January 6, 2013 7:29:15 AM UTC+6, Alex Miller wrote:
>>>
>>> Barski hasn't spoken at Strange Loop, perhaps you mean his talk at the 
>>> conj?
>>>
>>> On Friday, January 4, 2013 3:30:55 AM UTC-6, kinleyd wrote:

 Thanks for taking the trouble Alex - that was pretty comprehensive. 
 I've seen Rathore's and Nolen's (both excellent), skipped Stokke's (but 
 only because Catnip didn't interest me) and was looking forward to Barski 
 (but don't see him on the horizon though his talk was delivered a while 
 back). I will now go through the others that you have listed. 

 On Friday, January 4, 2013 9:45:06 AM UTC+6, Alex Miller wrote:
>
> The full Strange Loop video schedule is here: 
> https://thestrangeloop.com/news/strange-loop-2012-video-schedule
>
> Re Clojure talks, 
>
> Already released related in some way to Clojure and ClojureScript:
> - Nathan Marz on big data - 
> http://www.infoq.com/presentations/Complexity-Big-Data
> - Jim Weirich on Y Combinator - 
> http://www.infoq.com/presentations/Y-Combinator
> - Chris Granger on Light Table - 
> http://www.infoq.com/presentations/Learn-Tools
> - David Nolen on ClojureScript - 
> http://www.infoq.com/presentations/ClojureScript-Optimizations
> - Amit Rathore on Clojure+Datomic+Storm - 
> http://www.infoq.com/presentations/Zolodeck
> - Bodil Stokke on Catnip IDE and ClojureScript - 
> http://www.infoq.com/presentations/Catnip
>
> Still to be released:
> - Jason Wolfe's talk on the Prismatic Graph library is coming out week 
> of Jan 28th
> - Kevin Lynagh's talk on his ClojureScript visualization lib is week 
> of Feb 11th
> - Rich Hickey's talk is scheduled for week of Mar 18th but same one 
> has already been released on InfoQ so not sure if they'll re-release it
> - Stuart Sierra's talk on functional design patterns is week of Apr 1st
>
> Sorry if I missed any.
>
> Alex
>
> On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote:
>>
>> I've been waiting forever for the recent Strange Loop Clojure talks 
>> to be made available as well. So far I've only seen two, Amit Rathore's 
>> "Clojure + Datomic + Stomr = Zolodeck" and David Nolen's "ClojureScript 
>> - 
>> Better semantics at low, low prices" on InfoQ. Any one have any idea 
>> when 
>> the others will be made available? 
>>
>> On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote:
>>>
>>> Let the party begin :-)
>>>
>>> On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote:

 Confreaks is just completing the final edits on the videos and we 
 should be releasing them soon (in a week or so?). 
 Of course, it will probably be a staggered release just to drive 
 everyone crazy ;) 

 Lynn Grogan
 Relevance

 On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote:
>
> On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt  
> wrote: 
> > 
> > +1 - I'm sure I've even seen any BLOGS on this years Conj let 
> alone videos. 
>
> http://corfield.org/blog/post.cfm/clojure-conj-2012 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>


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

clojure for the java noob(while experienced functional programmers)?

[bob zhang]

Hi List,
* * I am interested in learning clojure these days(mainly for the JVM),  I 
am a long-term functional programmer(one of the maintainers of the ocaml 
compiler, designing my language Fan (a variant of ocaml which has the 
similar macro mechanism as clojure), quite familiar with common lisp).
  So, for me, the main challenge is to know jvm better to understand 
clojure. Is there any book for professional functional programmers while no 
java background? or should I still learn java to understand clojure better?
  Thanks

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

Re: Convincing employer to go for Clojure

[David Jacobs]

Thanks for all of the feedback and suggestions, everyone. To clear one 
thing up, I'm working at an early-stage SF startup, so the alternatives are 
along the lines of Ruby/Python/Node, not Java. That said, I think these 
arguments are great -- I'll definitely share them with team.

Cheers,
David

On Monday, January 7, 2013 3:02:37 PM UTC-8, David Jacobs wrote:
>
> Hey guys,
>
> As someone who's written Clojure for a couple of years now, I would love 
> to convince my new company to build our platform using Clojure from the 
> start. Clojure is certainly a possibility for our small team, but a few 
> questions will have to be answered before I can convince everyone that 
> Clojure is worth using:
>
> 1. Would it be harder to hire if we built our apps with Clojure? More 
> specifically: Hiring for people who know about or already love Clojure/FP 
> is certainly a nice filter for talent, but is it too stringent of a filter? 
> What percentage of the Clojure community wants to code Clojure 
> professionally but isn't right now? Do we have metrics on that?
>
> 2. What are good examples of complex domains that have been tackled with 
> Clojure web apps and API layers?
>
> 3. What major road blocks have teams discovered at the edges of Clojure 
> (keeping in mind that perhaps several of these problems could be solved 
> using native Java calls)?
>
> What other tips do you have for convincing an employer that Clojure makes 
> good business sense? (Of course I've already told them about 
> domain-tailored abstractions, containing complexity, the ease of data 
> manipulation with a functional language, etc.)
>
> Best,
> David
>

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

[ANN] Typed Clojure 0.1.6, New Documentation Wiki

[Ambrose Bonnaire-Sergeant]

Hi,

Typed Clojure 0.1.6 fixes some bugs, but perhaps more excitingly there is a
new wiki
for user documentation, screencasts and other goodies.

https://github.com/frenchy64/typed-clojure
https://github.com/frenchy64/typed-clojure/wiki

Check the README for the changes.

Enjoy!
Ambrose

-- 
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: Convincing employer to go for Clojure

[David Jacobs]

With the* team, that is. (Couldn't let that stay uncorrected heh. I hear 
ya, Colin, re: sleep.)

On Tuesday, January 8, 2013 10:35:07 AM UTC-8, David Jacobs wrote:
>
> Thanks for all of the feedback and suggestions, everyone. To clear one 
> thing up, I'm working at an early-stage SF startup, so the alternatives are 
> along the lines of Ruby/Python/Node, not Java. That said, I think these 
> arguments are great -- I'll definitely share them with team.
>
> Cheers,
> David
>
> On Monday, January 7, 2013 3:02:37 PM UTC-8, David Jacobs wrote:
>>
>> Hey guys,
>>
>> As someone who's written Clojure for a couple of years now, I would love 
>> to convince my new company to build our platform using Clojure from the 
>> start. Clojure is certainly a possibility for our small team, but a few 
>> questions will have to be answered before I can convince everyone that 
>> Clojure is worth using:
>>
>> 1. Would it be harder to hire if we built our apps with Clojure? More 
>> specifically: Hiring for people who know about or already love Clojure/FP 
>> is certainly a nice filter for talent, but is it too stringent of a filter? 
>> What percentage of the Clojure community wants to code Clojure 
>> professionally but isn't right now? Do we have metrics on that?
>>
>> 2. What are good examples of complex domains that have been tackled with 
>> Clojure web apps and API layers?
>>
>> 3. What major road blocks have teams discovered at the edges of Clojure 
>> (keeping in mind that perhaps several of these problems could be solved 
>> using native Java calls)?
>>
>> What other tips do you have for convincing an employer that Clojure makes 
>> good business sense? (Of course I've already told them about 
>> domain-tailored abstractions, containing complexity, the ease of data 
>> manipulation with a functional language, etc.)
>>
>> Best,
>> David
>>
>

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

CLJS: Issue with requiring "goog.storage.mechanism.HTML5LocalStorage" (?)

[Frank Siebenlist]

Not sure what to make of this issue.

Tried to compile/run shoreleave.browser.storage.localstorage module,
but it gave me the following js-console error:

ERROR - required "goog.storage.mechanism.HTML5LocalStorage" namespace never 
provided
goog.require('goog.storage.mechanism.HTML5LocalStorage')

Then I tried to require "goog.storage.mechanism.HTML5LocalStorage" in my 
user.cljs,
and I get the same error… guess I cannot blame shoreleave now ;-).

I can see the goog.require("goog.storage.mechanism.HTML5LocalStorage"); 
statement in main-debug.js,
but no "provide"'ing code. Puzzling...

Cleaned-up the dev environment, started from scratch… still the same.

Could someone please confirm that it's not just me…?

Is there something special about this 
"goog.storage.mechanism.HTML5LocalStorage"?

Is it a bug somewhere?

Thanks, FrankS.

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

Re: clojure for the java noob(while experienced functional programmers)?

[Marko Topolnik]

On Tuesday, January 8, 2013 6:52:58 PM UTC+1, bob zhang wrote:

> Hi List,
> * * I am interested in learning clojure these days(mainly for the JVM), 
>  I am a long-term functional programmer(one of the maintainers of the ocaml 
> compiler, designing my language Fan (a variant of ocaml which has the 
> similar macro mechanism as clojure), quite familiar with common lisp).
>   So, for me, the main challenge is to know jvm better to understand 
> clojure. Is there any book for professional functional programmers while no 
> java background? or should I still learn java to understand clojure better?
>   Thanks
>

Java is very much present in Clojure so knowing it definitely contributes 
to knowing Clojure. You should probably inform yourself on at least these 
topics:

   - the sandbox that is the JVM;
   - the semantics of most Java language features: 
  - exception handling mechanism;
  - class/instance members; 
  - dynamic dispatch, method inheritance and overriding;
  - what exactly are interfaces;
  - primitive types and arrays;
  - concurrency model (threads);
   - important parts of the standard library:
  - java.lang.Object;
  - java.lang.String;
  - Collections Framework;
  - Reflection API;
  - java.util.concurrent package;
  - java.io package.
   
I'm afraid I don't know any resources intended for experienced FP 
developers starting with Java. Something aimed at C/C++ developers might be 
googlable, though.

-- 
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: core.logic: datomic unification

[David Nolen]

I've updated the experimental core.logic Datomic support so that you can
unify PersistentVector and Datoms again. In a real system I'd probably
recommend providing your own tuple type that does not implement Sequential
for doing unification with Datoms.

David


On Tue, Jan 8, 2013 at 11:55 AM, Austin Haas  wrote:

>
> Ok, thanks, I'll try to get it to work with PersistentVector.
>
> I just started looking at core.logic's internals, and I'm still fairly new
> to Clojure, so everything is a little fuzzy. I took Sequential for granted,
> since that is referenced in the existing code.
>
> Thanks for the help.
>
> -austin
>
> --
> Austin Haas
> Pet Tomato, Inc.
> http://pettomato.com
>
> On Tue Jan 08 07:28 , David Nolen wrote:
> > The dispatching mechanism was more trouble than it was worth but we did
> > lose some flexibility. Do you really need to unify Sequential or is
> > unifying with a concrete type like PersistentVector work well enough for
> > your use case?
> >
> > David
> >
> >
> > On Tue, Jan 8, 2013 at 2:01 AM, Austin Haas 
> wrote:
> >
> > >
> > > The datomic unification code in core.logic has bit-rotted. It depends
> on
> > > IUnifyWithSequential, which was removed in this commit:
> > >
> https://github.com/clojure/core.logic/commit/bbc4e820128d5a0745ce3d79cd3bbd9401a1bf55
> > >
> > > I'm trying to understand how to update the code, but I don't get how
> > > dispatching works following the above commit. It appears that each
> > > implementation of IUnifyTerms must dispatch on the second argument,
> and I
> > > don't see how to get clojure.lang.Sequential to dispatch on a datom
> unless
> > > I override the implementation of clojure.lang.Sequential unify-terms
> here:
> > >
> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1581
> > >
> > > I must be missing something. Any pointers would be appreciated.
> > >
> > > -austin
> > >
> > > --
> > > Austin Haas
> > > Pet Tomato, Inc.
> > > http://pettomato.com
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/clojure?hl=en
> > >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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: Unit testing

[Sean Corfield]

On Mon, Jan 7, 2013 at 11:50 PM, Eric MacAdie  wrote:
> Is there a common unit testing framework for Clojure? I did some googling,
> put all the results were a couple of years old.

As others have noted separately, Clojure has clojure.test built-in
which is fairly straightforward assertion-based:

(deftest
  (is (= :expected (actual-expression

At World Singles we use that for our WebDriver-based tests, but we use
Jay Fields' Expectations which has the benefit of simpler behavioral
assertions but runs all tests at JVM shutdown (which is generally
great, but doesn't work well with browser session testing):

(expect :expected (actual-expression))
;; or
(give (actual-expression)
  (expect
first :a
second :b))

I've just started looking at Midje for another project and might
update our WebDriver tests to use that instead of clojure.test since
Midje provides a very (very!) rich vocabulary for writing tests. A
simple test would be:

(fact (actual-expression) => :expected)

Both Expectations and Midje have plugins for Leiningen that will watch
your source / tests for changes and automatically run your test suite.
Both of them also have modes for Emacs that provide a very slick
workflow there.

I like Expectations for its clean, simple approach. I'm growing to
like Midje for its sophistication.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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] 9th episode of modern-cljs on dom manipulation

[Mimmo Cosenza]

Hello everyone,
I just published the 9th tutorial of modern-cljs series. It addresses DOM 
manipulation using both domina and hiccups libraries

here is the link

https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-09.md


Hope it helps in your clojurescript programming.

Mimmo


-- 
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: core.logic: datomic unification

[Austin Haas]

Thanks! I had just finished making similar changes. It was a good exercise and 
I'm glad to be able to compare code.

A couple of questions:

1. Why is there no case for unifying a Datom with another Datom?

2. Why aren't multimethods used for dispatching to the appropriate unification 
implementation?

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Tue Jan 08 14:30 , David Nolen wrote:
> I've updated the experimental core.logic Datomic support so that you can
> unify PersistentVector and Datoms again. In a real system I'd probably
> recommend providing your own tuple type that does not implement Sequential
> for doing unification with Datoms.
> 
> David
> 
> 
> On Tue, Jan 8, 2013 at 11:55 AM, Austin Haas  wrote:
> 
> >
> > Ok, thanks, I'll try to get it to work with PersistentVector.
> >
> > I just started looking at core.logic's internals, and I'm still fairly new
> > to Clojure, so everything is a little fuzzy. I took Sequential for granted,
> > since that is referenced in the existing code.
> >
> > Thanks for the help.
> >
> > -austin
> >
> > --
> > Austin Haas
> > Pet Tomato, Inc.
> > http://pettomato.com
> >
> > On Tue Jan 08 07:28 , David Nolen wrote:
> > > The dispatching mechanism was more trouble than it was worth but we did
> > > lose some flexibility. Do you really need to unify Sequential or is
> > > unifying with a concrete type like PersistentVector work well enough for
> > > your use case?
> > >
> > > David
> > >
> > >
> > > On Tue, Jan 8, 2013 at 2:01 AM, Austin Haas 
> > wrote:
> > >
> > > >
> > > > The datomic unification code in core.logic has bit-rotted. It depends
> > on
> > > > IUnifyWithSequential, which was removed in this commit:
> > > >
> > https://github.com/clojure/core.logic/commit/bbc4e820128d5a0745ce3d79cd3bbd9401a1bf55
> > > >
> > > > I'm trying to understand how to update the code, but I don't get how
> > > > dispatching works following the above commit. It appears that each
> > > > implementation of IUnifyTerms must dispatch on the second argument,
> > and I
> > > > don't see how to get clojure.lang.Sequential to dispatch on a datom
> > unless
> > > > I override the implementation of clojure.lang.Sequential unify-terms
> > here:
> > > >
> > https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1581
> > > >
> > > > I must be missing something. Any pointers would be appreciated.
> > > >
> > > > -austin
> > > >
> > > > --
> > > > Austin Haas
> > > > Pet Tomato, Inc.
> > > > http://pettomato.com
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Clojure" group.
> > > > To post to this group, send email to clojure@googlegroups.com
> > > > Note that posts from new members are moderated - please be patient with
> > > > your first post.
> > > > To unsubscribe from this group, send email to
> > > > clojure+unsubscr...@googlegroups.com
> > > > For more options, visit this group at
> > > > http://groups.google.com/group/clojure?hl=en
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/clojure?hl=en
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> >
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: CLJS: Issue with requiring "goog.storage.mechanism.HTML5LocalStorage" (?)

[Paul deGrandis]

Hi Frank,

Two situations cause this error:
 - Sometimes paths to the third-party jar get "jangled" up.
 - Names/paths will sometimes change slightly between the dev releases and 
the final official releases of the Goog jar. (This is happening a lot with 
HTML5 stuff)

In both cases you just have to unpack the jar and grep around to find out 
where things went.  The online Google Closure Lib docs can also help as 
well.

- - - -
Shoreleave is going through a serious upgrade (0.3), which should be done 
in a week or so - at which time I'll have this all sorted out.

Thanks for checking out the project!  Sorry master is a little unstable at 
this point.

Cheers,
Paul

On Tuesday, January 8, 2013 10:58:53 AM UTC-8, FrankS wrote:
>
> Not sure what to make of this issue. 
>
> Tried to compile/run shoreleave.browser.storage.localstorage module, 
> but it gave me the following js-console error: 
>
> ERROR - required "goog.storage.mechanism.HTML5LocalStorage" namespace 
> never provided 
> goog.require('goog.storage.mechanism.HTML5LocalStorage') 
>
> Then I tried to require "goog.storage.mechanism.HTML5LocalStorage" in my 
> user.cljs, 
> and I get the same error… guess I cannot blame shoreleave now ;-). 
>
> I can see the goog.require("goog.storage.mechanism.HTML5LocalStorage"); 
> statement in main-debug.js, 
> but no "provide"'ing code. Puzzling... 
>
> Cleaned-up the dev environment, started from scratch… still the same. 
>
> Could someone please confirm that it's not just me…? 
>
> Is there something special about this 
> "goog.storage.mechanism.HTML5LocalStorage"? 
>
> Is it a bug somewhere? 
>
> Thanks, FrankS. 
>
>

-- 
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: core.logic: datomic unification

[David Nolen]

On Tue, Jan 8, 2013 at 3:29 PM, Austin Haas  wrote:

>
> Thanks! I had just finished making similar changes. It was a good exercise
> and I'm glad to be able to compare code.
>
> A couple of questions:
>
> 1. Why is there no case for unifying a Datom with another Datom?
>

Oversight. I added Datomic support more as a guide then anything serious.
It's up to the community to take it further. Patches welcome!


> 2. Why aren't multimethods used for dispatching to the appropriate
> unification implementation?
>
> -austin
>

Speed.

David

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

Re: CLJS: Issue with requiring "goog.storage.mechanism.HTML5LocalStorage" (?)

[Frank Siebenlist]

Thanks Paul for the "hints" - can't wait for your finished upgrade…

-FrankS.



On Jan 8, 2013, at 12:57 PM, Paul deGrandis  wrote:

> Hi Frank,
> 
> Two situations cause this error:
>  - Sometimes paths to the third-party jar get "jangled" up.
>  - Names/paths will sometimes change slightly between the dev releases and 
> the final official releases of the Goog jar. (This is happening a lot with 
> HTML5 stuff)
> 
> In both cases you just have to unpack the jar and grep around to find out 
> where things went.  The online Google Closure Lib docs can also help as well.
> 
> - - - -
> Shoreleave is going through a serious upgrade (0.3), which should be done in 
> a week or so - at which time I'll have this all sorted out.
> 
> Thanks for checking out the project!  Sorry master is a little unstable at 
> this point.
> 
> Cheers,
> Paul
> 
> On Tuesday, January 8, 2013 10:58:53 AM UTC-8, FrankS wrote:
> Not sure what to make of this issue. 
> 
> Tried to compile/run shoreleave.browser.storage.localstorage module, 
> but it gave me the following js-console error: 
> 
> ERROR - required "goog.storage.mechanism.HTML5LocalStorage" namespace never 
> provided 
> goog.require('goog.storage.mechanism.HTML5LocalStorage') 
> 
> Then I tried to require "goog.storage.mechanism.HTML5LocalStorage" in my 
> user.cljs, 
> and I get the same error… guess I cannot blame shoreleave now ;-). 
> 
> I can see the goog.require("goog.storage.mechanism.HTML5LocalStorage"); 
> statement in main-debug.js, 
> but no "provide"'ing code. Puzzling... 
> 
> Cleaned-up the dev environment, started from scratch… still the same. 
> 
> Could someone please confirm that it's not just me…? 
> 
> Is there something special about this 
> "goog.storage.mechanism.HTML5LocalStorage"? 
> 
> Is it a bug somewhere? 
> 
> Thanks, FrankS. 
> 

-- 
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: Unit testing

[Tony Pitluga]

If you are coming from Ruby, there is speclj which has an RSpec feel.

https://github.com/slagyr/speclj


On Tue, Jan 8, 2013 at 1:57 PM, Sean Corfield wrote:

> On Mon, Jan 7, 2013 at 11:50 PM, Eric MacAdie  wrote:
> > Is there a common unit testing framework for Clojure? I did some
> googling,
> > put all the results were a couple of years old.
>
> As others have noted separately, Clojure has clojure.test built-in
> which is fairly straightforward assertion-based:
>
> (deftest
>   (is (= :expected (actual-expression
>
> At World Singles we use that for our WebDriver-based tests, but we use
> Jay Fields' Expectations which has the benefit of simpler behavioral
> assertions but runs all tests at JVM shutdown (which is generally
> great, but doesn't work well with browser session testing):
>
> (expect :expected (actual-expression))
> ;; or
> (give (actual-expression)
>   (expect
> first :a
> second :b))
>
> I've just started looking at Midje for another project and might
> update our WebDriver tests to use that instead of clojure.test since
> Midje provides a very (very!) rich vocabulary for writing tests. A
> simple test would be:
>
> (fact (actual-expression) => :expected)
>
> Both Expectations and Midje have plugins for Leiningen that will watch
> your source / tests for changes and automatically run your test suite.
> Both of them also have modes for Emacs that provide a very slick
> workflow there.
>
> I like Expectations for its clean, simple approach. I'm growing to
> like Midje for its sophistication.
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: CLJS: Issue with requiring "goog.storage.mechanism.HTML5LocalStorage" (?)

[Frank Siebenlist]

A dependency on domina 1.0.0 pulled in a goog-jar-*.jar file which didn't work 
well with the google-closure-library-*.jar.

Seems that goog-jar was providing similar access to the goog.* modules as the 
google-closure-library, 
but was hopelessly outdated… no html5 goog-files in goog-jar but they are 
present in the google-closure-library.

Removing the domina dependency made the goog-jar file go away, and all goog 
requires and provides are happily resolved.

Ough… talking about dependency hell...

-FrankS.


On Jan 8, 2013, at 1:17 PM, Frank Siebenlist  wrote:

> Thanks Paul for the "hints" - can't wait for your finished upgrade…
> 
> -FrankS.
> 
> 
> 
> On Jan 8, 2013, at 12:57 PM, Paul deGrandis  wrote:
> 
>> Hi Frank,
>> 
>> Two situations cause this error:
>> - Sometimes paths to the third-party jar get "jangled" up.
>> - Names/paths will sometimes change slightly between the dev releases and 
>> the final official releases of the Goog jar. (This is happening a lot with 
>> HTML5 stuff)
>> 
>> In both cases you just have to unpack the jar and grep around to find out 
>> where things went.  The online Google Closure Lib docs can also help as well.
>> 
>> - - - -
>> Shoreleave is going through a serious upgrade (0.3), which should be done in 
>> a week or so - at which time I'll have this all sorted out.
>> 
>> Thanks for checking out the project!  Sorry master is a little unstable at 
>> this point.
>> 
>> Cheers,
>> Paul
>> 
>> On Tuesday, January 8, 2013 10:58:53 AM UTC-8, FrankS wrote:
>> Not sure what to make of this issue. 
>> 
>> Tried to compile/run shoreleave.browser.storage.localstorage module, 
>> but it gave me the following js-console error: 
>> 
>> ERROR - required "goog.storage.mechanism.HTML5LocalStorage" namespace never 
>> provided 
>> goog.require('goog.storage.mechanism.HTML5LocalStorage') 
>> 
>> Then I tried to require "goog.storage.mechanism.HTML5LocalStorage" in my 
>> user.cljs, 
>> and I get the same error… guess I cannot blame shoreleave now ;-). 
>> 
>> I can see the goog.require("goog.storage.mechanism.HTML5LocalStorage"); 
>> statement in main-debug.js, 
>> but no "provide"'ing code. Puzzling... 
>> 
>> Cleaned-up the dev environment, started from scratch… still the same. 
>> 
>> Could someone please confirm that it's not just me…? 
>> 
>> Is there something special about this 
>> "goog.storage.mechanism.HTML5LocalStorage"? 
>> 
>> Is it a bug somewhere? 
>> 
>> Thanks, FrankS. 
>> 
> 

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

What's the current status of Clojure-in-Clojure?

[Thor]

I think this would be a fun project to contribute to, but a few searches 
haven't led me to where the development is taking place. Is it just part of 
the main Clojure github project?

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

deploying clojure/compojure web apps

[Josh Kamau]

Hi There ;

I am new to clojure. My question is: Whats the common practice when it
comes to deploying webapps built on compojure? running via lein ring server
or creating a war file ?  I would also like to know which is the best way
to put load configuration files  i.e using properties file... or using a
reader to load .clj file with a hashmap def?

Kind regards.
Josh

-- 
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] Persistent disjoint-set forests for Clojure

[Jordan Lewis]

Hi all,

I couldn't find any implementations of union-find[1] for Clojure, so I 
wrote one. It's a persistent rendition of the disjoint-set forest 
implementation by Tarjan, including the union-by-rank and path compression 
optimizations. It acts like a native Clojure collection, as well as 
supporting the union and get-canonical operations given by the union-find 
algorithm.

It's available with usage instructions on GitHub (
https://github.com/jordanlewis/data.union-find) and Clojars (
https://clojars.org/org.jordanlewis/data.union-find).

Why is this useful? Briefly, union-find allows you to keep track of a 
universe of elements organized into a number of disjoint sets. It 
efficiently supports the operations of adding new elements as singleton 
sets to the universe, "modifying" the universe by unioning two sets 
together, and determining which set contains a particular element within 
the universe.

Feedback is greatly appreciated!

Cheers,
Jordan Lewis

[1]: http://en.wikipedia.org/wiki/Disjoint-set_data_structure

-- 
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: symbolic protocols

[Brandon Bloom]

>
> The defmulti would be closer to 
>
>  (defmulti mm first) 
>
> because we need to dig into the list to get the first symbol. 
>

I don't think that there is anything stopping you from creating such a code 
walker now. Maybe you should built a proof of concept to demonstrate some 
use cases concretely? 
 

> But there need to be a way to recurse as well, if you want to 
> interprete the whole expression. That part is hard to capture in the 
> multimethod. 
>

Look for a paper titled "Expansion-Passing Style: A General Macro 
Mechanism" for ideas on how to handle recursion and expansion dispatch.

-- 
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: What's the current status of Clojure-in-Clojure?

[Brandon Bloom]

ClojureScript has the best chance of forming a base of Clojure-in-Clojure. 
I believe David Nolen would consider any patches that help decouple us from 
JavaScript.

On Tuesday, January 8, 2013 3:44:16 PM UTC-8, Thor wrote:
>
> I think this would be a fun project to contribute to, but a few searches 
> haven't led me to where the development is taking place. Is it just part of 
> the main Clojure github project?

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

Please help this newbie out!

[Jacob Goodson]

(let [frame (doto (JFrame.)
(.setSize 100 100))
  height (.getHeight a)
  width (.getWidth a)
  image (.createImage a b c)] 
  image)

Why does this return nil?

Thank you!

-- 
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: Please help this newbie out!

[juan.facorro]

I think the code you posted might not be the working code since a, b and c 
don't seem to exist in it. :P

Check out the docs for the createImage(int, 
int) method:

*Returns:**an off-screen drawable image, which can be used for double 
buffering. The return value may be null if the component is not 
displayable. This will always happen ifGraphicsEnvironment.isHeadless()
 returns true.*

It seems you have to make the JFrame visible in order to get an image when 
using that method. 

The following should work:

*(let [frame (doto (JFrame.)*
*  (.setSize 100 100)*
*  (.setVisible true))*
*  height (.getHeight frame)*
*  width (.getWidth frame)*
*  image (.createImage frame height width)] *
*  image)*

Cheers,

Juan

On Tuesday, January 8, 2013 11:38:35 PM UTC-3, Jacob Goodson wrote:
>
> (let [frame (doto (JFrame.)
> (.setSize 100 100))
>   height (.getHeight a)
>   width (.getWidth a)
>   image (.createImage a b c)] 
>   image)
>
> Why does this return nil?
>
> Thank you!
>

-- 
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: Please help this newbie out!

[Jacob Goodson]

Whoops! I changed the code to be more readable, those were my previous 
values...argh!  

I read the documentation over and over and never noticed that...sigh. 
 Thank you for the response.

On Tuesday, January 8, 2013 9:57:13 PM UTC-5, juan.facorro wrote:
>
> I think the code you posted might not be the working code since a, b and c 
> don't seem to exist in it. :P
>
> Check out the docs for the createImage(int, 
> int)method:
>
> *Returns:**an off-screen drawable image, which can be used for double 
> buffering. The return value may be null if the component is not 
> displayable. This will always happen ifGraphicsEnvironment.isHeadless()
>  returns true.*
>
> It seems you have to make the JFrame visible in order to get an image when 
> using that method. 
>
> The following should work:
>
> *(let [frame (doto (JFrame.)*
> *  (.setSize 100 100)*
> *  (.setVisible true))*
> *  height (.getHeight frame)*
> *  width (.getWidth frame)*
> *  image (.createImage frame height width)] *
> *  image)*
>
> Cheers,
>
> Juan
>
> On Tuesday, January 8, 2013 11:38:35 PM UTC-3, Jacob Goodson wrote:
>>
>> (let [frame (doto (JFrame.)
>> (.setSize 100 100))
>>   height (.getHeight a)
>>   width (.getWidth a)
>>   image (.createImage a b c)] 
>>   image)
>>
>> Why does this return nil?
>>
>> Thank you!
>>
>

-- 
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: Convincing employer to go for Clojure

[Peter Mancini]

Our company was recently formed in stages. The first stage did a lot of 
research and decided we needed strong NLP tools and felt that the right 
direction to go with the NLP was Python. I had spent 7 years doing NLP and 
advised them on that aspect and had spent a lot of time doing NLP in 
Python. I also despise Java. OK maybe too harsh but I still dislike it. So 
the new crew was hired for the web development and product development and 
while they all had Python experience at least one of them I can fairly call 
an expert in Clojure. He suggested it.

There are some great NLP libraries in Java. NLP is at it's heart about 
map/reduce and very compartmentalized linear algebra. In looking at Clojure 
I decided while it might be hard for me to program in, I could do work in 
Java as I learned Clojure and we could make progress. As it turns out I was 
right - learning clojure is a pain in the butt if all you've ever done are 
Algol based languages (PL/1, Pascal, C, C++, Java, C#, Python for me). What 
closed the loop for me was Clojure Koans. They are the best thing I've ever 
encountered in learning a language. Once you get what they are doing to get 
you to learn, enlightenment follows quickly.

Our whole team voted in the positive for Clojure and Clojurescript. We've 
had no problem working with the Stanford CoreNLP library, D3, datomic, 
storm and all the other great stuff out there. It has been a really great 6 
1/2 months and I am looking forward to our first delivery this month and a 
future delivery for our really big project.

The company name is Cicayda and we are located in Nashville, TN where there 
is a growing band of functional programmers of all types.

-- 
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: "core.matrix" proposal

[Brandon Bloom]

There's a bunch of useful operations that games & animation systems perform 
frequently that are less common in other uses of linear algebra. For 
example: linear and spline interpolations.

The DirectXMath library is worth 
studying: 
http://msdn.microsoft.com/en-us/library/windows/desktop/hh437833(v=vs.85).aspx
Similarly, the XNA math 
libraries: 
http://msdn.microsoft.com/en-us/library/bb196942(v=xnagamestudio.35).aspx

On Sunday, January 6, 2013 11:13:04 PM UTC-8, Mikera wrote:
>
> Yep, the idea is to be flexible enough to support many different 
> implementations.
>
> The pure Clojure version should be very easy to use and flexible since it 
> uses regular Clojure persistent vectors. The trade-off is of less 
> performance compared to the Java/native implementations.
>
> As an added bonus, writing a pure Clojure version is useful for testing / 
> validating the design of the API before we extend it to more complex 
> implementations.
>
> On Sunday, 6 January 2013 12:54:08 UTC+8, Rob Lachlan wrote:
>>
>> I really like this idea -- I think there's a need for a dedicated matrix 
>> computation library in clojure.  I really like the idea of having matrix 
>> operations implemented in clojure (I think that you have this in 
>> persistent_vector.clj) but also being able to call on java libraries.
>>
>>
>> On Saturday, January 5, 2013 2:00:23 AM UTC-8, Mikera wrote:
>>>
>>> Hello all,
>>>
>>> I've been experimenting with a common API / abstraction for matrix and 
>>> vector maths in Clojure:
>>>
>>>   https://github.com/mikera/matrix-api
>>>
>>> The idea is:
>>>  - Provide a clear, consistent API for matrix and vector operations
>>>  - Support multiple different underlying implementations (e.g. native 
>>> code via JBLAS vs pure Java like vectorz-clj)
>>>  - Provide a base which other libraries that need to consume matrices 
>>> can build upon (e.g. Incanter)
>>>  - Offer good performance while still presenting a reasonably flexible 
>>> high level API
>>>
>>> I think this could be very useful for the Clojure community, especially 
>>> given the interest in big data, simulations, machine learning, 3D graphics 
>>> etc. If it goes well and there is enough interest, I guess that this could 
>>> form the basis for a future "core.matrix" library.
>>>
>>> Comments / ideas / patches welcome.
>>>
>>>   Mike.
>>>
>>

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