Creating clojure "stacktrace"

[Shimon Magal]

HI, I'm trying to convert a java stacktrace (generated by a clojure app) to 
a clojure stacktrace, just to use an internal util.

That means, that I go over the stacktrace and try to assemble what they 
were.

In the process, I was wondering what are all the ways of defining anonymous 
functions - I saw "fn" and "reify" appear in the stacktrace. Other 
possibilities you may know?

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Render Rails templates in Clojure?

[Erwin Kroon]

We are running Clojure and Rails in the same JVM with JRuby (with our own 
library ring.rack [1] and Zweikopf [2]). 

Depending on the templates, you can probably use only Zweikopf (so you can 
reuse gems).  Our problem was that with Rails, it is often all or nothing, 
which makes me wonder that if you see reusing only the templates as as a 
valid option, that rewriting the templates is the better option.

Cheers,
Erwin

[1] https://github.com/mpare-net/ring-rack
[2] https://github.com/ifesdjeen/zweikopf

On Friday, March 25, 2016 at 1:27:28 PM UTC+1, Igor Bondarenko wrote:
>
> Hi everyone!
>
> We're planning on moving our Rails app to Clojure and would want to keep 
> our Rails templates during the transition time. Is there a way to render 
> Rails templates in Clojure (or Java)?
>
> The reason we need this is because templates will probably change at the 
> same time as transition happens and we don't want to update them in two 
> different places/templating languages. Eventually we'll switch to Clojure 
> templating library completely, of course.
>
> Or it isn't worth the effort and we should just rewrite templates to 
> Clojure from the beginning and deal with duplication?
>
> Thanks for your thoughts.
>

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

flowchart for choosing the right Clojure parallel primitives?

[Sergey Didenko]

Hi,

Is there a flowchart for choosing the right Clojure parallel primitives?

So that you can decide when to just use reducers/fork and when to choose
core.async and etc.

For example like the flowchart for data types from Chas Emerick -
http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/

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

Re: flowchart for choosing the right Clojure parallel primitives?

[David Della Costa]

Hi Sergey, I don't have a direct answer for you but this talk at
Clojure/West 2015 by Leon Barrett went over the various options for
parallelism in Clojure, and I found it pretty educational myself:

https://www.youtube.com/watch?v=BzKjIk0vgzE&list=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a&index=2

Hope that is useful!

DD


2016-03-29 9:56 GMT-04:00 Sergey Didenko :

> Hi,
>
> Is there a flowchart for choosing the right Clojure parallel primitives?
>
> So that you can decide when to just use reducers/fork and when to choose
> core.async and etc.
>
> For example like the flowchart for data types from Chas Emerick -
> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: flowchart for choosing the right Clojure parallel primitives?

[David Della Costa]

Just realized that Leon linked to the slides in a comment on the youtube
video itself: http://leon.barrettnexus.com/clojure-west-2015/

2016-03-29 15:52 GMT-04:00 David Della Costa :

> Hi Sergey, I don't have a direct answer for you but this talk at
> Clojure/West 2015 by Leon Barrett went over the various options for
> parallelism in Clojure, and I found it pretty educational myself:
>
>
> https://www.youtube.com/watch?v=BzKjIk0vgzE&list=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a&index=2
>
> Hope that is useful!
>
> DD
>
>
> 2016-03-29 9:56 GMT-04:00 Sergey Didenko :
>
>> Hi,
>>
>> Is there a flowchart for choosing the right Clojure parallel primitives?
>>
>> So that you can decide when to just use reducers/fork and when to choose
>> core.async and etc.
>>
>> For example like the flowchart for data types from Chas Emerick -
>> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Reworking :pre condition to add an error message

[Colin Taylor]

Would there be interest in a ticket in this? Seems simple enough if (as 
above) putting the message under the :pre key is acceptable?


On Thursday, July 14, 2011 at 3:25:16 AM UTC+12, frye wrote:
>
> I do think a simple String error message is all that the user of the 
> function should provide. From there, An AssertionError can throw up 
> something along the lines of what you said - Expected… , Found… , Message. 
> That would give enough information for reporting at least in a test 
> framework. To get more precise information, like you said, that 
> AssertionError could also throw up class/file information, etc. that a 
> debugger could use. I would guard against designing these things to 
> accomodate a context outside of it's execution scope. In the ideal 
> functional world, the input and output are wholly localized. Any 
> Error/Exception thrown can be consumed or chained to give very precise 
> failure reasoning.  
>
>
> As for how that would fit into the entire exception chain, that's still 
> being thought (see here 
> ). There are 
> already a few approaches, and I think this (see here 
> ) is 
> the context of how the core team is approaching this problem. 
>
>
> Cheers 
> Tim 
>
>
> On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar  > wrote:
>
>> As I am the culprit of having introduced it with a naive example, I'd
>> better admit it may not be very useful in practical scenarios across a
>> wide variety of use cases. For example, when there is an assertion
>> error with message "`m` should be a map" 14 levels down the stack, I'd
>> really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]"
>> so that I can debug it quickly.
>>
>> Pre-conditions and Post-conditions are a valuable debugging aid, and
>> to enable that we need very precise information. Unfortunately passing
>> a string error message cannot encapsulate enough error context. A more
>> complex example can be where the correctness of input must be
>> determined collectively (in association with other args) -- in those
>> cases one can only fall back on comparing input values and raise
>> IllegalArgumentException accordingly.
>>
>> Regards,
>> Shantanu
>>
>> On Jul 11, 10:40 pm, Timothy Washington  wrote:
>> > 
>>
>
>

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

Re: Reworking :pre condition to add an error message

[Alex Miller]

(zombie thread back from the dead... :)

I think enhancements on :pre/:post are interesting.

http://dev.clojure.org/jira/browse/CLJ-1817 seems like a good place to work 
on this.


On Tuesday, March 29, 2016 at 4:02:25 PM UTC-5, Colin Taylor wrote:
>
> Would there be interest in a ticket in this? Seems simple enough if (as 
> above) putting the message under the :pre key is acceptable?
>
>
> On Thursday, July 14, 2011 at 3:25:16 AM UTC+12, frye wrote:
>>
>> I do think a simple String error message is all that the user of the 
>> function should provide. From there, An AssertionError can throw up 
>> something along the lines of what you said - Expected… , Found… , Message. 
>> That would give enough information for reporting at least in a test 
>> framework. To get more precise information, like you said, that 
>> AssertionError could also throw up class/file information, etc. that a 
>> debugger could use. I would guard against designing these things to 
>> accomodate a context outside of it's execution scope. In the ideal 
>> functional world, the input and output are wholly localized. Any 
>> Error/Exception thrown can be consumed or chained to give very precise 
>> failure reasoning.  
>>
>>
>> As for how that would fit into the entire exception chain, that's still 
>> being thought (see here 
>> ). There are 
>> already a few approaches, and I think this (see here 
>> ) is 
>> the context of how the core team is approaching this problem. 
>>
>>
>> Cheers 
>> Tim 
>>
>>
>> On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar  
>> wrote:
>>
>>> As I am the culprit of having introduced it with a naive example, I'd
>>> better admit it may not be very useful in practical scenarios across a
>>> wide variety of use cases. For example, when there is an assertion
>>> error with message "`m` should be a map" 14 levels down the stack, I'd
>>> really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]"
>>> so that I can debug it quickly.
>>>
>>> Pre-conditions and Post-conditions are a valuable debugging aid, and
>>> to enable that we need very precise information. Unfortunately passing
>>> a string error message cannot encapsulate enough error context. A more
>>> complex example can be where the correctness of input must be
>>> determined collectively (in association with other args) -- in those
>>> cases one can only fall back on comparing input values and raise
>>> IllegalArgumentException accordingly.
>>>
>>> Regards,
>>> Shantanu
>>>
>>> On Jul 11, 10:40 pm, Timothy Washington  wrote:
>>> > 
>>>
>>
>>

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

my new favorite s-expr video (seriously)

[Raoul Duke]

https://www.youtube.com/watch?v=HnZipJOan54

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

Re: Reworking :pre condition to add an error message

[Francis Avila]

A wonderful hack I read about somewhere is to just use the clojure.test/is 
macro, which I now do all the time:

(require '[clojure.test :refer [is]])
=> nil
(defn get-key [m k]
  {:pre [(is (map? m) "m is not a map!")]}
  (m k))
=> #'user/get-key
(get-key [] 0)

FAIL in clojure.lang.PersistentList$EmptyList@1 
(form-init8401797809408331100.clj:2)
m is not a map!
expected: (map? m)
  actual: (not (map? []))
AssertionError Assert failed: (is (map? m) "m is not a map!")  user/get-key 
(form-init8401797809408331100.clj:1)


This is great for repl use, but it does side-effect (the printed error) and 
doesn't return anything structured. It's suited to development-time human 
use rather than runtime or machine-use.

I see the potential for a macro which rethrows the assertion errors as 
something like ex-info exceptions (i.e. something with structured data.) 
That would fill runtime or machine-uses better (or structured logging?), 
but I'm not sure that fits with the spirit of pre/post conditions in the 
first place. After all, these do raise Java AssertionErrors, which are not 
meant to be recoverable.

On Tuesday, March 29, 2016 at 4:19:12 PM UTC-5, Alex Miller wrote:
>
> (zombie thread back from the dead... :)
>
> I think enhancements on :pre/:post are interesting.
>
> http://dev.clojure.org/jira/browse/CLJ-1817 seems like a good place to 
> work on this.
>
>
> On Tuesday, March 29, 2016 at 4:02:25 PM UTC-5, Colin Taylor wrote:
>>
>> Would there be interest in a ticket in this? Seems simple enough if (as 
>> above) putting the message under the :pre key is acceptable?
>>
>>
>> On Thursday, July 14, 2011 at 3:25:16 AM UTC+12, frye wrote:
>>>
>>> I do think a simple String error message is all that the user of the 
>>> function should provide. From there, An AssertionError can throw up 
>>> something along the lines of what you said - Expected… , Found… , Message. 
>>> That would give enough information for reporting at least in a test 
>>> framework. To get more precise information, like you said, that 
>>> AssertionError could also throw up class/file information, etc. that a 
>>> debugger could use. I would guard against designing these things to 
>>> accomodate a context outside of it's execution scope. In the ideal 
>>> functional world, the input and output are wholly localized. Any 
>>> Error/Exception thrown can be consumed or chained to give very precise 
>>> failure reasoning.  
>>>
>>>
>>> As for how that would fit into the entire exception chain, that's still 
>>> being thought (see here 
>>> ). There are 
>>> already a few approaches, and I think this (see here 
>>> ) is 
>>> the context of how the core team is approaching this problem. 
>>>
>>>
>>> Cheers 
>>> Tim 
>>>
>>>
>>> On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar  
>>> wrote:
>>>
 As I am the culprit of having introduced it with a naive example, I'd
 better admit it may not be very useful in practical scenarios across a
 wide variety of use cases. For example, when there is an assertion
 error with message "`m` should be a map" 14 levels down the stack, I'd
 really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]"
 so that I can debug it quickly.

 Pre-conditions and Post-conditions are a valuable debugging aid, and
 to enable that we need very precise information. Unfortunately passing
 a string error message cannot encapsulate enough error context. A more
 complex example can be where the correctness of input must be
 determined collectively (in association with other args) -- in those
 cases one can only fall back on comparing input values and raise
 IllegalArgumentException accordingly.

 Regards,
 Shantanu

 On Jul 11, 10:40 pm, Timothy Washington  wrote:
 > 

>>>
>>>

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

Jobs in clojure.

[Jason Basanese]

I recently have been looking for summer internships. However most of the 
companies I find either do not know what Clojure is or are certain they 
want nothing to do with it as they would much rather stick to Java or 
Javascript. Yes I know that Clojure compiles to both of those but this 
seems to be a mute point in most cases. It is a mute point because telling 
an employer you could make really great black boxes for them is not exactly 
alluring. 

Do you guys know of any companies that use Clojure? Have any suggestions on 
how to present Clojure in a more appealing manner? General suggestions on 
where to look for jobs in Clojure, such as startups vs large companies or 
job fairs vs online applications? Basically any suggestion as to how to 
find a job in the field with Clojure? 

I have grown to love the language but am failing to find a market for it. 

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

Re: Jobs in clojure.

[Kyle R. Burton]

There are at least two companies in Philadelphia that use Clojure:

* Relay Network (their engineering office is in center city Philly)
* RJ Metrics

I don't know if either is looking for interns, I think both are hiring.  I
used to be at Relay and can put you in touch with people there.  I've never
worked for RJ Metrics, but have worked with several of their people - I'd
be happy to put you in touch with them as well.

Best Regards,

Kyle

On Tue, Mar 29, 2016 at 4:25 PM, Jason Basanese 
wrote:

> I recently have been looking for summer internships. However most of the
> companies I find either do not know what Clojure is or are certain they
> want nothing to do with it as they would much rather stick to Java or
> Javascript. Yes I know that Clojure compiles to both of those but this
> seems to be a mute point in most cases. It is a mute point because telling
> an employer you could make really great black boxes for them is not exactly
> alluring.
>
> Do you guys know of any companies that use Clojure? Have any suggestions
> on how to present Clojure in a more appealing manner? General suggestions
> on where to look for jobs in Clojure, such as startups vs large companies
> or job fairs vs online applications? Basically any suggestion as to how to
> find a job in the field with Clojure?
>
> I have grown to love the language but am failing to find a market for it.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Twitter: @kyleburton
Github: https://github.com/kyleburton
Blog: http://asymmetrical-view.com/
Fun: http://snapclean.me/

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

Re: Jobs in clojure.

[Alex Miller]

You can find Clojure companies at: http://clojure.org/community/companies

There is a #jobs room on the Clojurians Slack channel that is a good place 
to ask about this too.  http://clojurians.net/

On Tuesday, March 29, 2016 at 6:25:41 PM UTC-5, Jason Basanese wrote:
>
> I recently have been looking for summer internships. However most of the 
> companies I find either do not know what Clojure is or are certain they 
> want nothing to do with it as they would much rather stick to Java or 
> Javascript. Yes I know that Clojure compiles to both of those but this 
> seems to be a mute point in most cases. It is a mute point because telling 
> an employer you could make really great black boxes for them is not exactly 
> alluring. 
>
> Do you guys know of any companies that use Clojure? Have any suggestions 
> on how to present Clojure in a more appealing manner? General suggestions 
> on where to look for jobs in Clojure, such as startups vs large companies 
> or job fairs vs online applications? Basically any suggestion as to how to 
> find a job in the field with Clojure? 
>
> I have grown to love the language but am failing to find a market for it. 
>

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

Re: Jobs in clojure.

[Jason Basanese]

Thank you Miller! That is an extensive and encouraging list I had not run 
into before.

On Tuesday, March 29, 2016 at 8:09:34 PM UTC-4, Alex Miller wrote:
>
> You can find Clojure companies at: http://clojure.org/community/companies
>
> There is a #jobs room on the Clojurians Slack channel that is a good place 
> to ask about this too.  http://clojurians.net/
> On Tuesday, March 29, 2016 at 6:25:41 PM UTC-5, Jason Basanese wrote:
>>
>> I recently have been looking for summer internships. However most of the 
>> companies I find either do not know what Clojure is or are certain they 
>> want nothing to do with it as they would much rather stick to Java or 
>> Javascript. Yes I know that Clojure compiles to both of those but this 
>> seems to be a mute point in most cases. It is a mute point because telling 
>> an employer you could make really great black boxes for them is not exactly 
>> alluring. 
>>
>> Do you guys know of any companies that use Clojure? Have any suggestions 
>> on how to present Clojure in a more appealing manner? General suggestions 
>> on where to look for jobs in Clojure, such as startups vs large companies 
>> or job fairs vs online applications? Basically any suggestion as to how to 
>> find a job in the field with Clojure? 
>>
>> I have grown to love the language but am failing to find a market for it. 
>>
>

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

Re: Jobs in clojure.

[Jason Basanese]

Kyle, I would most definitely like to be put in touch with either or both 
of these companies. Keep in mind Philadelphia is a bit far from me (Canton 
MI) and would require relocation. However compromise to achieve great 
opportunities is simply a part of life.

On Tuesday, March 29, 2016 at 8:10:10 PM UTC-4, Kyle Burton wrote:
>
> There are at least two companies in Philadelphia that use Clojure:
>
> * Relay Network (their engineering office is in center city Philly)
> * RJ Metrics
>
> I don't know if either is looking for interns, I think both are hiring.  I 
> used to be at Relay and can put you in touch with people there.  I've never 
> worked for RJ Metrics, but have worked with several of their people - I'd 
> be happy to put you in touch with them as well.
>
> Best Regards,
>
> Kyle
>
> On Tue, Mar 29, 2016 at 4:25 PM, Jason Basanese  > wrote:
>
>> I recently have been looking for summer internships. However most of the 
>> companies I find either do not know what Clojure is or are certain they 
>> want nothing to do with it as they would much rather stick to Java or 
>> Javascript. Yes I know that Clojure compiles to both of those but this 
>> seems to be a mute point in most cases. It is a mute point because telling 
>> an employer you could make really great black boxes for them is not exactly 
>> alluring. 
>>
>> Do you guys know of any companies that use Clojure? Have any suggestions 
>> on how to present Clojure in a more appealing manner? General suggestions 
>> on where to look for jobs in Clojure, such as startups vs large companies 
>> or job fairs vs online applications? Basically any suggestion as to how to 
>> find a job in the field with Clojure? 
>>
>> I have grown to love the language but am failing to find a market for it. 
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Twitter: @kyleburton
> Github: https://github.com/kyleburton
> Blog: http://asymmetrical-view.com/
> Fun: http://snapclean.me/
>

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

Nicer assert by replacing the macro

[Oliver George]

Hi All

This is a little script to producing nicer errors from asserts and pre/post 
conditions in your clojure code.  Examples below, gist includes a readme 
with some notes.  I think the pre/post conditions are the biggest win.

Can anyone tell me how to do a similar "assert patch" technique for my 
clojurescript projects while debugging.

https://gist.github.com/olivergeorge/386ff4a559197dd794c1



(let [a 111] (assert (= 1 a)))

*AssertionError Assert failed: (= 1 a) => false*
* where a is 111*
  user/eval28652 (figwheel.clj:1)



(let [heart 1 diamond 2] (assert (> heart diamond) "Hearts should trump 
diamonds"))

*AssertionError Assert failed: Hearts should trump diamonds*
*(> heart diamond) => false*
* where heart is 1*
* where diamond is 2*
  user/eval28778 (figwheel.clj:1)



(let [x 1 y 2 z (range 1000)] (assert (> x 1)))

*AssertionError Assert failed: (> x 1) => false*
* where x is 1*
  user/eval28842 (figwheel.clj:1)



(defn pos-adder [a b]
  {:pre [(pos? a) (number? b)]
   :post [(pos? %)]}
  (+ a b))
=> #'user/pos-adder

(pos-adder 1 2)
=> 3

(pos-adder -1 2)

*AssertionError Assert failed: (pos? a) => false*
* where a is -1*
  user/pos-adder (figwheel.clj:1)


(pos-adder 1 -2)

*AssertionError Assert failed: (pos? %) => false*
* where % is -1*
  user/pos-adder (figwheel.clj:1)


(pos-adder 1 "notnum")

*AssertionError Assert failed: (number? b) => false*
* where b is notnum*
  user/pos-adder (figwheel.clj:1)

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