Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Mark Engelberg]

The template example shows a notation for doing something special on the
last iteration of a loop, but it doesn't look like this syntax can handle
nested loops.  Is there any mechanism for nested loops?

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

Releasing Caribou today: Open Source Clojure Web Ecosystem

[Joel Holdbrooks]

This exactly the sort of project I've been hoping for to get others to take a 
serious look at using Clojure. While its unfortunate some developers will not 
look at a language until it has a comfortable entry point, it's a real barrier 
for  adoption. Caribou looks like it has the potential to speak to these 
developers with familiar workflow tools. I look forward to sharing this with 
others whom I've tried to convince in the past.

By the way the documentation is great. You guys nailed it! Bonus points for 
having a philosophy! :-)

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

Comments on first function

[jskdlfj999]

Hi everyone,

I'm new to Clojure, and after a lot of reading I wrote a couple of 
functions.
They are working and doing what they are supposed to, but I was wondering 
if the way I wrote the functions was optimal and if I made any conceptual 
errors which advanced programmers avoid.
Basically: Are they what they call the "clojure" way?

(defn download-source [url]
  (let [stream (java.io.BufferedReader. (java.io.InputStreamReader. (.. 
(java.net.URL. url) openStream)))]
(loop [b (.readLine stream), acc ""]
  (if (= b nil) acc
(recur (.readLine stream) (str acc b))

(println (download-source "http://google.com";))

This function for example downloads the source of a webpage and returns it 
as a string.
Could this have been written in a better way?
I want to get a feeling of what is considered good practice/design in 
clojure.

Nice Regards

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

Using xlisp assoc-lists in clojure

[hpw014]

Hello,

As a newbie coming from a autolisp/newLISP background I have a question 
about using xlisp assoc-lists in clojure.

I have huge databases form autolisp (from an autocad enviroment) in the 
form of nested assoc-lists.

Can I stay with that format and read them from clojure?

The first would be to emulate 'setq' 
This could be done with 'def' (with a single pair of symbol/expression)
(By the way: Can a multiform of def be done like (defm symbol1 expression1 
symboln expressionn) by a macro)

The scond is the use of assoc-lists in clojure:

Is it wise to use them in clojure for huge data-lists?
How can I access them like I do in autolisp with it's 'assoc'.
Finding the sublist by its first member.
I do not see a equivalent command for lists in clojure.
clojures assoc command is completly different.
Can it be done with a macro?


Regards

Hans-Peter

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[David Simmons]

Ryan

thanks for the great reply. I'll have to play a bit more to really get my 
head around this. I'd too would love to see a simple blog example not using 
the Admin interface to try and show how and where you'd define your models.

many thanks.

Dave

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

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Clojure Engineers Needed! at Factual

http://functionaljobs.com/jobs/8657-clojure-engineers-needed-at-factual



Cheers,

Sean Murphy

FunctionalJobs.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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Yesql 0.2.1 - Clojure & SQL queries rethought.

[Jeremy Heiler]

On Mon, Nov 11, 2013 at 6:10 AM, Kris Jenkins wrote:

> https://github.com/krisajenkins/yesql
>
> Yesql is a simple library for blending SQL & Clojure together, cleanly.
> Here's how it works ,
> and how to use it .
>

Very cool. Do you have any thoughts on a caching strategy?

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

Re: Question on Sequences

[Jeremy Heiler]

On Sat, Nov 16, 2013 at 9:00 PM, Cedric Greevey  wrote:

> This efficiency is why built-in functions to map, filter, etc. vectors to
> vectors aren't provided
>


Well, there is mapv and filterv.

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

Re: Question on Sequences

[Leif]

Hi, Alexandru.

If you just need more performance on vectors only, there are the core 
functions mapv, filterv, and subvec (O(1), which can be used to implement 
takev and dropv).  Also, looking at the source of mapv and filterv is 
instructive, because they use transients internally; you might do that in 
your solution to get a bit more speed.

If you really need a generic solution where most clj.core functions are 
performant on your custom data structures, I don't have suggestions, but 
you can refer to what the experts do:

https://github.com/clojure/data.priority-map
https://github.com/ztellman?tab=repositories (potemkin, clj-tuple, 
immutable-bitset, et al)

Hope that helps,
Leif

On Saturday, November 16, 2013 7:01:14 PM UTC-5, Alexandru Nedelcu wrote:
>
> Hi, 
>
> I'm trying to understand the design of Clojure's collections and one 
> thing that I find odd is the return of functions operating on sequences. 
> Like for instance a call such as this will return a lazy-seq and not a 
> vector: 
>
> (drop 2 [1 2 3 4]) 
>
> The reason why I find it odd is that data-structures have different 
> characteristics and one may want to use a vector because it supports 
> efficient indexing and appending to the end. 
>
> Of course, dropping 2 elements like above from a vector is probably 
> going to have O(n) complexity and thus returning something lazy is more 
> appropriate. And while there are some operations, like "conj", "pop" and 
> "peek" that preserve the type, functions such as map and filter also 
> return lazy-seq. And I worry that the property of the collection you 
> start with is lost, given that this returns a "cons": 
>
>  (conj (filter even? [1 2 3 4 5]) 6) 
>
> So lets say that I want to write a generic function that preserves the 
> type of that collection. Is something like this idiomatic? 
>
>  (defn only-evens [coll] 
>(into (empty coll) (filter even? coll))) 
>
> Thanks, 
>
> -- 
> Alexandru Nedelcu 
> www.bionicspirit.com 
>
> PGP Public Key: 
> https://bionicspirit.com/key.aexpk 
>
>

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

Re: maintainability, DSLs, declarative APIs, etc.

[Alexey Verkhovsky]

On Friday, 15 November 2013 13:12:29 UTC-7, Jay Fields wrote:
>
> Better to have the ability when you desire it, than not to have it - 
> if you're willing to put up with other people (ab)using that power at 
> times. 
>

+1, with one caveat. 

If you have a rule of thumb like "introduce an abstraction when you have 
repeated yourself three times",  the bar for introducing meta-programming 
abstractions should be set much higher than three.

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

[Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time

[Alexey Verkhovsky]

Hello, all,

I'm a Clojure noob (half way through Stu Halloway's book), who's just 
joined this group today. Sorry about my first post being a recruitment 
spam. Seeing that there aren't that many yet, I hope nobody minds. For the 
right kind of people (talented, pragmatic and not averse to full-time 
pairing), this is a great gig.

I'm hoping to contribute to this community in some more meaningful ways in 
the near future :)


Please reply to me off list. A link to your Github profile counts for much 
more than a stellar resume. Doesn't have to be in Clojure.

--Alex Verkhovsky


--


Outpace Systems, Inc is hiring!


   - 
   
   Polyglot lifestyle ~ currently Clojure,Ruby, CoffeeScript
   - 
   
   100% pairing using remote tools
   - 
   
   Very competitive pay
   - 
   
   Work from anywhere in the US
   - 
   
   Very agile - fast, flexible teams with world class business architects 
   and programmers
   

We are an early stage SW product company doing its first client engagement. 
The company was founded in February, and has been profitable since early 
May. The domain is enterprise software, but with a few twists that we think 
are real game-changers. We are only hiring master programmers and very 
strong journeymen. We pay extremely competitively, work in cool 
technologies, and have already hired a great team that we are looking to 
expand.

We are committed to a polyglot lifestyle and an emphasis on truly fast 
flexible teams. The only guiding principles on the developer side are near 
100% pair programming, strong focus on testing, and continuous integration. 
We are currently using primarily Clojure, Ruby, and CoffeeScript - but we 
hire strong programmers no matter what language they are currently fluent 
in.

Geographically, we are only hiring in the US time zones for the time being 
- it's just too hard to pair across a lot of  time zones. Our primary 
working environment is a Macbook pro, two thunderbolt monitors on your 
desktop at home using screensharing to do remote pairing. 

We are minimizing travel and relocation so that we can hire the best people 
anywhere on the continent. If we have the necessity and opportunity to 
travel, we let people decide for themselves whether they want to be 
involved. If you don’t want to travel at all, we still want to talk to you. 

The company is on track to make $6 million in revenue this year, with 
expectations of over $15 million next year, and we need the best 
programmers we can get to make that happen. Two of the founders are ex 
McKinsey & Company, including an ex senior partner who started doing Agile 
in 1992 (winning the ComputerWorld Best Business application of IT award) 
with an approach called "Do it fix it rapid prototyping".

Let us know if you are interested!

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

Re: Friend roles stored in a database table

[Dave Della Costa]

Heh--I know exactly what you mean, had the exact same kind of experience
myself many times.  In any case, glad you got it working!

(2013/11/18 4:42), wm.mark@gmail.com wrote:
> Sometimes you can't see the wood for the trees I guess, I have it
> working with this trivial change:
> 
> (defn credential-fn [username]
>   (update-in (read-user username) [:roles] read-string))
> 
> Still learning the basics...
> 
> On Sunday, 17 November 2013 17:04:27 UTC, wm.ma...@gmail.com wrote:
> 
> Presumably when I read my user record from the database I need to
> "de-stringify" the roles from the database column to an actual set
> for the ":roles" rather than a string, so how do I do that for a
> string like this?
> 
>  #{:my-app-ns/admin :my-app-ns/some-other-role} 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: [ANN] overload-middleware 0.1.1

[Rob Day]

On 16/11/13 21:22, Craig wrote:
Very interesting. I have a similar requirement, but not in serving web 
requests. I haven't looked under the covers of your module, but wonder 
if it could be decoupled from web/ring?


Craig


I've just pushed 0.2.0-SNAPSHOT to Clojars and Github. This adds 
overload-middleware.middleware/create-overload-wrapper, which takes two 
arguments - a function that can be applied to a request to generate an 
"overloaded" response (to account for protocols that need to copy some 
request info back into the response, unlike HTTP), and a function that 
can be applied to a response to determine whether it is indicating 
overload (which can just be "(constantly false)" if your application 
doesn't do this). It returns a function which behaves like the existing 
wrap-overload.


As an example, the new definition of wrap-overload is:

(def wrap-overload (create-overload-wrapper
(constantly {:status 503 :body "Overloaded"})
#(= 503 (:status %

Does this sound like it fits your use-case?

Best,
Rob

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] overload-middleware 0.1.1

[Robert Day]

On 17/11/13 14:24, James Reeves wrote:
I've added this library to clojure-toolbox.com 
. I can see this library being very useful 
for certain systems.


Thanks! I hadn't heard of the Clojure Toolbox before, but there's a lot 
of interesting things in there that I now want to check out.


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to store the results in a vector ?

[James Reeves]

Try using ??- and ??<-. These will output to a vector.

(??<- [?category] ((select-fields info-tap ["?category"]) ?category))


- James


On 17 November 2013 21:05, sindhu hosamane  wrote:

> Hello friends ,
>
> (?<- (stdout)[?category]((select-fields info-tap ["?category"]) ?category)
> )
>
> Above is my Cascalog query which produces result like :
>
>
> Warning
>
> Start inhibit
>
> Stop
>
> Inhibit
>
> Warning
>
> Halt
>
>
> how to store the above result in a vector ?
>
> my way is
>
>
> (let [x (?<- (stdout)[?category]((select-fields info-tap ["?category"])
>  ?category
>
>   ))])
>
>
> is this correct ? but it does not seem working.Or how to store the above
> result ?
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Ryan Spangler]

The migrations are run one time to set up the models (or anything else), 
they don't represent the current state of the models.  In general, we use 
either the Admin to edit models, in which case we export the schema as edn 
to migrate between different environments, or we use the built in 
migrations and leave the admin models alone.  But there is no reason you 
couldn't use both.  

If you are looking for something to represent the current state of the 
model schema, you want the export API, which renders your current schema as 
an edn file which can be applied to any database universally.  

In general, there is always a potential disconnect between the schema and 
the code in any system.  If you have model descriptors, nothing guarantees 
your schema conforms to that.  You have to run migrations that line up with 
your model descriptions.  In Caribou, the database contains the model 
descriptions, and the system just reads those descriptions from the db to 
construct the models that the rest of the code is using.  So in a way, the 
Caribou models always reflect the state of the db, and don't depend on code 
to describe something that may not be in sync with what is in the db in the 
first place.  

It is different from any system I have seen though, so I understand your 
confusion!  Part of our challenge is providing a way to explain this 
clearly and to mitigate any issues that could arise from this approach.  

On Sunday, November 17, 2013 2:02:07 PM UTC-8, puzzler wrote:
>
> On Sun, Nov 17, 2013 at 1:58 PM, Ryan Spangler 
> 
> > wrote:
>
>> There are many advantages to this, including being able to generate the 
>> admin and api automatically, (as well as letting our frontend guys add 
>> properties they need in a model without pestering the backend guys to make 
>> schema updates!).  If manipulating schemas through the admin makes you 
>> nervous, you can always write migrations for your model changes: 
>> http://caribou.github.io/caribou/docs/migrations.html
>>
>
> I'm a little confused about this.  If you write some code to set up 
> models, and then you make changes to the admin interface, isn't your code 
> out-of-sync with the underlying reality? 
>  

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

Re: Functions using locks are slowed even when locks are never taken

[Andy Fingerhut]

I have just created a ticket linking to this discussion, with a copy of one
of Michal's earlier messages in the thread as a description of what might
be the problem.

I would not say that this is the same as movement on this issue.  Movement
in the form that would lead to a change in the Clojure compiler will
require one or more volunteers to carefully diagnose the root cause of the
problem, develop one or more patches, respond to comments from screeners
and/or Rich Hickey, etc.  If people want to raise more attention to this
issue, one way to do it is to vote on the ticket in JIRA.  If you do not
already have an account, you can create one here:

http://dev.clojure.org/jira/secure/Signup!default.jspa

Andy


On Sun, Nov 17, 2013 at 10:14 AM, Michael Blume wrote:

> Sorry to be a bother, but any movement on this? This looks like a real
> performance bug and I don't yet have the internals knowledge to chase it
> down myself.
>
>
> On Sun, Nov 3, 2013 at 12:10 PM, Michał Marczyk 
> wrote:
>
>> Well, that is interesting.
>>
>> The difference between the compiled versions of
>>
>> (defn foo [x]
>>   (if (> x 0)
>> (inc x)
>> (locking o
>>   (dec x
>>
>> and
>>
>> (defn bar [x]
>>   (if (> x 0)
>> (inc x)
>> (let [res (locking o
>> (dec x))]
>>   res)))
>>
>> is quite significant. foo gets compiled to a single class, with
>> invocations handled by a single invoke method; bar gets compiled to a
>> class for bar + an extra class for an inner function which handles the
>> (locking o (dec x)) part -- probably very similar to the output for
>> the version with the hand-coded locking-part (although I haven't
>> really looked at that yet). The inner function is a closure, so
>> calling it involves an allocation of a closure object; its ctor
>> receives the closed-over locals as arguments and stores them in two
>> fields (lockee and x). Then they get loaded from the fields in the
>> body of the closure's invoke method etc.
>>
>> I guess I'll have to play around with Java equivalents too...
>>
>> Cheers,
>> Michał
>>
>>
>> On 3 November 2013 20:46, Michael Blume  wrote:
>> > I mean, I'm probably being naive, but this suggests that one could write
>> >
>> > (defmacro locking' [& forms]
>> >   `(let [res# (locking ~@forms)] res#))
>> >
>> > and use locking' in place of locking for improved performance. Is this
>> > wrong? If it's right, does that suggest the macro in clojure.core
>> should be
>> > changed?
>> >
>> >
>> > On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume 
>> wrote:
>> >>
>> >> Huh, interesting.
>> >>
>> >> I have:
>> >>
>> >> (defn foo' [x]
>> >>   (if (> x 0)
>> >> (inc x)
>> >> (let [res (locking o (dec x))] res)))
>> >>
>> >> (defn foo'' [x]
>> >>   (if (> x 0)
>> >> (inc x)
>> >> (locking o
>> >>   (dec x
>> >>
>> >> foo' is fast, but foo'' is slow. So something about wrapping the
>> locking
>> >> clause in a let makes it fast. Still no idea why.
>> >>
>> >> On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote:
>> >>>
>> >>> You have a typo in foo -- monitor-exit's argument is 0 (zero) rather
>> >>> than o (the sentinel object).
>> >>>
>> >>> Besides that, in foo both monitor-enter and monitor-exit get their
>> >>> arguments from a Var. Rewriting to use locking, which first puts the
>> >>> object whose monitor will be used in a local (that is, (let [lockee o]
>> >>> ...), where ... performs the locking using the newly introduced
>> >>> local), gives timings identical to those of bar and baz:
>> >>>
>> >>> (defn foo' [x]
>> >>>   (if (> x 0)
>> >>> (inc x)
>> >>> (let [res (locking o (dec x))] res)))
>> >>>
>> >>> So this is one reason not to use monitor-enter and monitor-exit
>> >>> directly. Another reason is that locking guarantees that the monitor
>> >>> will be released (by using try / finally, and of course by preventing
>> >>> situations where the matching monitor-enter & monitor-exit operate on
>> >>> different objects).
>> >>>
>> >>> In fact, both monitor-enter and monitor-exit carry docstrings which
>> >>> explicitly say that they should not be used in user code and point to
>> >>> locking as the user-facing equivalent to Java's synchronized.
>> >>>
>> >>> Cheers,
>> >>> Michał
>> >>>
>> >>>
>> >>> On 1 November 2013 19:34, Michael Blume  wrote:
>> >>> > https://github.com/MichaelBlume/perf-test
>> >>> >
>> >>> > (ns perf-test
>> >>> >   (:use (criterium core))
>> >>> >   (:gen-class))
>> >>> >
>> >>> > (def o (Object.))
>> >>> >
>> >>> > (defn foo [x]
>> >>> >   (if (> x 0)
>> >>> > (inc x)
>> >>> > (do
>> >>> >   (monitor-enter o)
>> >>> >   (let [res (dec x)]
>> >>> > (monitor-exit 0)
>> >>> > res
>> >>> >
>> >>> > (defn bar [x]
>> >>> >   (if (> x 0)
>> >>> > (inc x)
>> >>> > (dec x)))
>> >>> >
>> >>> > (defn locking-part [x l]
>> >>> >   (monitor-enter l)
>> >>> >   (let [res (dec x)]
>> >>> > (monitor-exit l)
>> >>> > res))
>> >>> >
>> >>> > (defn

Re: Functions using locks are slowed even when locks are never taken

[Andy Fingerhut]

Sorry, I neglected to include a link to the ticket:

http://dev.clojure.org/jira/browse/CLJ-1296


On Sun, Nov 17, 2013 at 2:11 PM, Andy Fingerhut wrote:

> I have just created a ticket linking to this discussion, with a copy of
> one of Michal's earlier messages in the thread as a description of what
> might be the problem.
>
> I would not say that this is the same as movement on this issue.  Movement
> in the form that would lead to a change in the Clojure compiler will
> require one or more volunteers to carefully diagnose the root cause of the
> problem, develop one or more patches, respond to comments from screeners
> and/or Rich Hickey, etc.  If people want to raise more attention to this
> issue, one way to do it is to vote on the ticket in JIRA.  If you do not
> already have an account, you can create one here:
>
> http://dev.clojure.org/jira/secure/Signup!default.jspa
>
> Andy
>
>
> On Sun, Nov 17, 2013 at 10:14 AM, Michael Blume wrote:
>
>> Sorry to be a bother, but any movement on this? This looks like a real
>> performance bug and I don't yet have the internals knowledge to chase it
>> down myself.
>>
>>
>> On Sun, Nov 3, 2013 at 12:10 PM, Michał Marczyk > > wrote:
>>
>>> Well, that is interesting.
>>>
>>> The difference between the compiled versions of
>>>
>>> (defn foo [x]
>>>   (if (> x 0)
>>> (inc x)
>>> (locking o
>>>   (dec x
>>>
>>> and
>>>
>>> (defn bar [x]
>>>   (if (> x 0)
>>> (inc x)
>>> (let [res (locking o
>>> (dec x))]
>>>   res)))
>>>
>>> is quite significant. foo gets compiled to a single class, with
>>> invocations handled by a single invoke method; bar gets compiled to a
>>> class for bar + an extra class for an inner function which handles the
>>> (locking o (dec x)) part -- probably very similar to the output for
>>> the version with the hand-coded locking-part (although I haven't
>>> really looked at that yet). The inner function is a closure, so
>>> calling it involves an allocation of a closure object; its ctor
>>> receives the closed-over locals as arguments and stores them in two
>>> fields (lockee and x). Then they get loaded from the fields in the
>>> body of the closure's invoke method etc.
>>>
>>> I guess I'll have to play around with Java equivalents too...
>>>
>>> Cheers,
>>> Michał
>>>
>>>
>>> On 3 November 2013 20:46, Michael Blume  wrote:
>>> > I mean, I'm probably being naive, but this suggests that one could
>>> write
>>> >
>>> > (defmacro locking' [& forms]
>>> >   `(let [res# (locking ~@forms)] res#))
>>> >
>>> > and use locking' in place of locking for improved performance. Is this
>>> > wrong? If it's right, does that suggest the macro in clojure.core
>>> should be
>>> > changed?
>>> >
>>> >
>>> > On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume 
>>> wrote:
>>> >>
>>> >> Huh, interesting.
>>> >>
>>> >> I have:
>>> >>
>>> >> (defn foo' [x]
>>> >>   (if (> x 0)
>>> >> (inc x)
>>> >> (let [res (locking o (dec x))] res)))
>>> >>
>>> >> (defn foo'' [x]
>>> >>   (if (> x 0)
>>> >> (inc x)
>>> >> (locking o
>>> >>   (dec x
>>> >>
>>> >> foo' is fast, but foo'' is slow. So something about wrapping the
>>> locking
>>> >> clause in a let makes it fast. Still no idea why.
>>> >>
>>> >> On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote:
>>> >>>
>>> >>> You have a typo in foo -- monitor-exit's argument is 0 (zero) rather
>>> >>> than o (the sentinel object).
>>> >>>
>>> >>> Besides that, in foo both monitor-enter and monitor-exit get their
>>> >>> arguments from a Var. Rewriting to use locking, which first puts the
>>> >>> object whose monitor will be used in a local (that is, (let [lockee
>>> o]
>>> >>> ...), where ... performs the locking using the newly introduced
>>> >>> local), gives timings identical to those of bar and baz:
>>> >>>
>>> >>> (defn foo' [x]
>>> >>>   (if (> x 0)
>>> >>> (inc x)
>>> >>> (let [res (locking o (dec x))] res)))
>>> >>>
>>> >>> So this is one reason not to use monitor-enter and monitor-exit
>>> >>> directly. Another reason is that locking guarantees that the monitor
>>> >>> will be released (by using try / finally, and of course by preventing
>>> >>> situations where the matching monitor-enter & monitor-exit operate on
>>> >>> different objects).
>>> >>>
>>> >>> In fact, both monitor-enter and monitor-exit carry docstrings which
>>> >>> explicitly say that they should not be used in user code and point to
>>> >>> locking as the user-facing equivalent to Java's synchronized.
>>> >>>
>>> >>> Cheers,
>>> >>> Michał
>>> >>>
>>> >>>
>>> >>> On 1 November 2013 19:34, Michael Blume  wrote:
>>> >>> > https://github.com/MichaelBlume/perf-test
>>> >>> >
>>> >>> > (ns perf-test
>>> >>> >   (:use (criterium core))
>>> >>> >   (:gen-class))
>>> >>> >
>>> >>> > (def o (Object.))
>>> >>> >
>>> >>> > (defn foo [x]
>>> >>> >   (if (> x 0)
>>> >>> > (inc x)
>>> >>> > (do
>>> >>> >   (monitor-enter o)
>>> >>> >   (let [res (dec x)]
>>> >>> > 

Re: Do web apps need Clojure?

[Marcus Blankenship]

Thanks, Jerrod.  Great way to frame the question!

On Nov 16, 2013, at 4:34 PM, Jarrod Swart  wrote:

> I think the more interesting question is: do web developers need Clojure?  If 
> performance were the sole concern then everyone would still code web apps in 
> C or assembler.  There is great power in abstraction.  I like this talk by 
> Uncle Bob: http://skillsmatter.com/podcast/agile-testing/bobs-last-language  
> If you don't have time to watch it I will summarize: every time we get a more 
> powerful programming environment (for developers) we reduce our programming 
> options (in the language).  
> C --> Java == no pointers
> Java --> Clojure == no immutability, etc.
> Every major advancement for developers has largely involved reducing our 
> options and choices.  Take away register manipulation, take away pointers, 
> take away variables, and so on.  I highly recommend the talk by Uncle Bob.
> 
> So I highly encourage you to investigate the benefits that Clojure provide to 
> the developer, over the benefits provided to the machine.
> 
> Good luck in your search!
> 
> Jarrod
> 
> On Wednesday, November 13, 2013 5:38:49 PM UTC-5, Marcus Blankenship wrote:
> Hi Folks,
> 
> We’re a Python / Django shop, and some folks are getting excited about using 
> Clojure for building web apps.  Certainly there are numerous open-source 
> options to assist us (Pedastal, Ring, Compojure, Caribou, etc), but I think 
> it begs a larger question: as a rule, do web applications need the power that 
> Clojure brings to the table?
> 
> Other folks on my team are telling me that solutions built with Python / 
> Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
> we have built, and that Clojure offers nothing new to this problem space.  
> 
> So, here’s the question: How are you are actually using Clojure, and why did 
> you choose to use it, particularly in the “web application” space?  
> 
> Thanks,
> Marcus
> 
> 
> 
> marcus blankenship
> \\\ Partner, Problem Solver, Linear Thinker
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Ryan Spangler]

Mark, 

Luminus is great, it is at its heart a lein template that gathers together 
a number of useful Clojure web libraries and stitches them into a whole. 
 It provides a good starting point with many options without preventing you 
from adapting it in any way you see fit.  Caribou is more of an integrated 
framework that is built in layers from the data model up to 
routing/controllers, template rendering, image resizing, to the automatic 
Admin and HTTP API generation.  It is like Django in that it comes with an 
Admin out of the box that can be customized as necessary.  

That said, we worked hard to ensure that it does not trap you into any 
workflow.  You can use any library you want, and in the end it is just 
Clojure so you really have as much flexibility as you need.  We even know 
someone who has a project that doesn't use a db!  So in this way it is like 
Luminus:  a good starting point that you can adapt as you see fit.  

On Sunday, November 17, 2013 1:09:02 PM UTC-8, puzzler wrote:
>
> I'm reading through the documentation right now.  Looks interesting -- 
> reminds me a lot of Django.
>
> Could someone give a brief compare/contrast with Luminous?
>
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Mark Engelberg]

On Sun, Nov 17, 2013 at 1:58 PM, Ryan Spangler wrote:

> There are many advantages to this, including being able to generate the
> admin and api automatically, (as well as letting our frontend guys add
> properties they need in a model without pestering the backend guys to make
> schema updates!).  If manipulating schemas through the admin makes you
> nervous, you can always write migrations for your model changes:
> http://caribou.github.io/caribou/docs/migrations.html
>

I'm a little confused about this.  If you write some code to set up models,
and then you make changes to the admin interface, isn't your code
out-of-sync with the underlying reality?

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Ryan Spangler]

Justin:  I believe he is asking for a repo of an example Caribou site that 
does something useful (like a blog that posts comments or something).  

David:  That is right, you don't have model files which describe your 
model.  Instead, there is a Model model (with a collection of instances of 
a Field model) which is just data in the db like any other model. 
 Manipulating Model data, either through the admin or programmatically, 
modifies the schema in the background, meaning basically that there is a 
table for each Model and (roughly) a column for each Field (though there 
are more complex fields, like assets or collections, that have multiple 
fields or refer to other tables behind the scenes).  

There are many advantages to this, including being able to generate the 
admin and api automatically, (as well as letting our frontend guys add 
properties they need in a model without pestering the backend guys to make 
schema updates!).  If manipulating schemas through the admin makes you 
nervous, you can always write migrations for your model 
changes: http://caribou.github.io/caribou/docs/migrations.html

Also you can export your Models (or any data for that matter) using the 
content export/import API.  This means you can build your models using the 
admin and h2, export the schema as edn, and import it into a Postgres db. 
 Then you have a file which represents your Models that you can check into 
version control or modify directly etc.  I realize now I haven't written 
docs for this process (I'll fix that shortly), but it is in the 
caribou-core repo under src/caribou/io.clj

Part of why Caribou is alpha is that we want to make sure the automatic 
schema modification process is bulletproof, as well as solve the various 
issues that arise in migrating schemas between environments and dbs in the 
cleanest and most seamless way possible.  We have a lot of ideas and 
already things are working pretty well, but are also open to all 
suggestions on that.

The automatic schema migrations are one of the most powerful parts of 
Caribou, but also take some careful thought to ensure they are not also 
getting in the way or potentially messing things up.  In practice, we don't 
have any issues and the ability to modify the schema transparently has been 
a huge boon to the development process on teams with multiple people.  

As for field validation, that is a great idea.  Currently nothing is in 
place for ranges of numbers, but I am once again open to any suggestions. 
 I will add it to the list!

 

On Sunday, November 17, 2013 1:03:43 PM UTC-8, David Simmons wrote:
>
> Hi Ryan
>
> Congratulations on the release of Caribou. I've got a couple of questions.
>
> 1. If I create a model via the Admin UI, am I right in thinking that this 
> does not actually create a clj file containing the details of the model 
> which I could edit later via a text editor? 
> 2. Do you the concept of model validations so that a field must be numeric 
> and between 10 and 50?
>
> many thanks for you help.
>
> Dave
>

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

How to store the results in a vector ?

[sindhu hosamane]

Hello friends ,

(?<- (stdout)[?category]((select-fields info-tap ["?category"]) ?category))

Above is my Cascalog query which produces result like :


Warning

Start inhibit 

Stop

Inhibit 

Warning

Halt


how to store the above result in a vector ?

my way is 


(let [x (?<- (stdout)[?category]((select-fields info-tap ["?category"])
 ?category

  ))])


is this correct ? but it does not seem working.Or how to store the above 
result ? 




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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Mark Engelberg]

I'm reading through the documentation right now.  Looks interesting --
reminds me a lot of Django.

Could someone give a brief compare/contrast with Luminous?

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[David Simmons]

Hi Ryan

Congratulations on the release of Caribou. I've got a couple of questions.

1. If I create a model via the Admin UI, am I right in thinking that this 
does not actually create a clj file containing the details of the model 
which I could edit later via a text editor? 
2. Do you the concept of model validations so that a field must be numeric 
and between 10 and 50?

many thanks for you help.

Dave

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Justin Smith]

I don't know if this is what Ronen is asking for, but I have had requests 
that we serve an instance with the admin open somewhere, so people can try 
out the whole app without installing it and getting it running locally.

On Sunday, November 17, 2013 11:49:50 AM UTC-8, Ryan Spangler wrote:
>
> Ronen,
>
> No sample app yet!  The screencast goes through building an app from 
> scratch, but a larger example is a great idea.  We'll get something 
> together here in the coming weeks (we have many projects using Caribou, 
> just means pulling something abstract out of one of them).  
>
> On Saturday, November 16, 2013 6:36:50 AM UTC-8, Ronen Cohen wrote:
>>
>> This look great! Is there a sample app anywhere?
>>
>> On Wednesday, November 13, 2013 1:52:10 AM UTC+2, Ryan Spangler wrote:
>>>
>>> Hello Clojure,
>>>
>>> Excited to announce today the release of Caribou!  
>>> http://let-caribou.in/
>>>
>>> We have been building web sites and web applications with it for over 
>>> two years now and improving it every day.  Currently we have four people 
>>> working on it and another ten using it to build things, so it is getting a 
>>> lot of real world testing.
>>>
>>> It has been designed as a collection of independent libraries that could 
>>> each be useful on their own, but which come together as a meaningful whole.
>>>
>>> We have been spending the last couple months getting it ready for a full 
>>> open source release, and I am happy to say it is finally ready.  Funded and 
>>> supported by Instrument in Portland, OR:  http://weareinstrument.com/ We 
>>> have four projects using it in production, and several more about to be 
>>> launched (as well as over a dozen internal things).
>>>
>>> Documentation is here:  
>>> http://caribou.github.io/caribou/docs/outline.html
>>>
>>> Source is here:  http://github.com/caribou/caribou (use this for 
>>> issues, you don't actually need the source as it is installed through a 
>>> lein template).
>>>
>>> Some of the independently useful libraries Caribou is built on are:
>>>
>>> * Polaris -- Routing with data (not macros) and reverse routing! :  
>>> https://github.com/caribou/polaris
>>> * Lichen -- Image resizing to and from s3 or on disk: 
>>> https://github.com/caribou/lichen
>>> * Schmetterling -- Debugging Clojure processes from the browser:  
>>> https://github.com/prismofeverything/schmetterling
>>> * Antlers -- Useful extensions to mustache templating (helpers and 
>>> blocks, among other things):  https://github.com/caribou/antlers
>>> * Groundhog -- Replay http requests: 
>>> https://github.com/noisesmith/groundhog
>>>
>>> And many others.
>>>
>>> Basically this is an Alpha release, and I am announcing it here first in 
>>> order to get as much feedback from the community as possible.  We have made 
>>> it as useful as we can for our purposes and recognize that for it to 
>>> improve from here, we really need as many people using it and building 
>>> things with it as possible.  The documentation also needs to be put through 
>>> its paces:  we need to see how well people are able to use it who know 
>>> nothing about it, based only on the existing docs.
>>>
>>> All feedback welcome!  
>>>
>>> Thanks for reading!  I hope you find it useful.
>>>
>>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Ryan Spangler]

Ronen,

No sample app yet!  The screencast goes through building an app from 
scratch, but a larger example is a great idea.  We'll get something 
together here in the coming weeks (we have many projects using Caribou, 
just means pulling something abstract out of one of them).  

On Saturday, November 16, 2013 6:36:50 AM UTC-8, Ronen Cohen wrote:
>
> This look great! Is there a sample app anywhere?
>
> On Wednesday, November 13, 2013 1:52:10 AM UTC+2, Ryan Spangler wrote:
>>
>> Hello Clojure,
>>
>> Excited to announce today the release of Caribou!  http://let-caribou.in/
>>
>> We have been building web sites and web applications with it for over two 
>> years now and improving it every day.  Currently we have four people 
>> working on it and another ten using it to build things, so it is getting a 
>> lot of real world testing.
>>
>> It has been designed as a collection of independent libraries that could 
>> each be useful on their own, but which come together as a meaningful whole.
>>
>> We have been spending the last couple months getting it ready for a full 
>> open source release, and I am happy to say it is finally ready.  Funded and 
>> supported by Instrument in Portland, OR:  http://weareinstrument.com/ We 
>> have four projects using it in production, and several more about to be 
>> launched (as well as over a dozen internal things).
>>
>> Documentation is here:  
>> http://caribou.github.io/caribou/docs/outline.html
>>
>> Source is here:  http://github.com/caribou/caribou (use this for issues, 
>> you don't actually need the source as it is installed through a lein 
>> template).
>>
>> Some of the independently useful libraries Caribou is built on are:
>>
>> * Polaris -- Routing with data (not macros) and reverse routing! :  
>> https://github.com/caribou/polaris
>> * Lichen -- Image resizing to and from s3 or on disk: 
>> https://github.com/caribou/lichen
>> * Schmetterling -- Debugging Clojure processes from the browser:  
>> https://github.com/prismofeverything/schmetterling
>> * Antlers -- Useful extensions to mustache templating (helpers and 
>> blocks, among other things):  https://github.com/caribou/antlers
>> * Groundhog -- Replay http requests: 
>> https://github.com/noisesmith/groundhog
>>
>> And many others.
>>
>> Basically this is an Alpha release, and I am announcing it here first in 
>> order to get as much feedback from the community as possible.  We have made 
>> it as useful as we can for our purposes and recognize that for it to 
>> improve from here, we really need as many people using it and building 
>> things with it as possible.  The documentation also needs to be put through 
>> its paces:  we need to see how well people are able to use it who know 
>> nothing about it, based only on the existing docs.
>>
>> All feedback welcome!  
>>
>> Thanks for reading!  I hope you find it useful.
>>
>

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

Re: Friend roles stored in a database table

[wm . mark . lee]

Sometimes you can't see the wood for the trees I guess, I have it working 
with this trivial change:

(defn credential-fn [username]
  (update-in (read-user username) [:roles] read-string))

Still learning the basics...

On Sunday, 17 November 2013 17:04:27 UTC, wm.ma...@gmail.com wrote:
>
> Presumably when I read my user record from the database I need to 
> "de-stringify" the roles from the database column to an actual set for the 
> ":roles" rather than a string, so how do I do that for a string like this?
>
>  #{:my-app-ns/admin :my-app-ns/some-other-role} 
>

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

Re: Functions using locks are slowed even when locks are never taken

[Michael Blume]

Sorry to be a bother, but any movement on this? This looks like a real
performance bug and I don't yet have the internals knowledge to chase it
down myself.


On Sun, Nov 3, 2013 at 12:10 PM, Michał Marczyk wrote:

> Well, that is interesting.
>
> The difference between the compiled versions of
>
> (defn foo [x]
>   (if (> x 0)
> (inc x)
> (locking o
>   (dec x
>
> and
>
> (defn bar [x]
>   (if (> x 0)
> (inc x)
> (let [res (locking o
> (dec x))]
>   res)))
>
> is quite significant. foo gets compiled to a single class, with
> invocations handled by a single invoke method; bar gets compiled to a
> class for bar + an extra class for an inner function which handles the
> (locking o (dec x)) part -- probably very similar to the output for
> the version with the hand-coded locking-part (although I haven't
> really looked at that yet). The inner function is a closure, so
> calling it involves an allocation of a closure object; its ctor
> receives the closed-over locals as arguments and stores them in two
> fields (lockee and x). Then they get loaded from the fields in the
> body of the closure's invoke method etc.
>
> I guess I'll have to play around with Java equivalents too...
>
> Cheers,
> Michał
>
>
> On 3 November 2013 20:46, Michael Blume  wrote:
> > I mean, I'm probably being naive, but this suggests that one could write
> >
> > (defmacro locking' [& forms]
> >   `(let [res# (locking ~@forms)] res#))
> >
> > and use locking' in place of locking for improved performance. Is this
> > wrong? If it's right, does that suggest the macro in clojure.core should
> be
> > changed?
> >
> >
> > On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume 
> wrote:
> >>
> >> Huh, interesting.
> >>
> >> I have:
> >>
> >> (defn foo' [x]
> >>   (if (> x 0)
> >> (inc x)
> >> (let [res (locking o (dec x))] res)))
> >>
> >> (defn foo'' [x]
> >>   (if (> x 0)
> >> (inc x)
> >> (locking o
> >>   (dec x
> >>
> >> foo' is fast, but foo'' is slow. So something about wrapping the locking
> >> clause in a let makes it fast. Still no idea why.
> >>
> >> On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote:
> >>>
> >>> You have a typo in foo -- monitor-exit's argument is 0 (zero) rather
> >>> than o (the sentinel object).
> >>>
> >>> Besides that, in foo both monitor-enter and monitor-exit get their
> >>> arguments from a Var. Rewriting to use locking, which first puts the
> >>> object whose monitor will be used in a local (that is, (let [lockee o]
> >>> ...), where ... performs the locking using the newly introduced
> >>> local), gives timings identical to those of bar and baz:
> >>>
> >>> (defn foo' [x]
> >>>   (if (> x 0)
> >>> (inc x)
> >>> (let [res (locking o (dec x))] res)))
> >>>
> >>> So this is one reason not to use monitor-enter and monitor-exit
> >>> directly. Another reason is that locking guarantees that the monitor
> >>> will be released (by using try / finally, and of course by preventing
> >>> situations where the matching monitor-enter & monitor-exit operate on
> >>> different objects).
> >>>
> >>> In fact, both monitor-enter and monitor-exit carry docstrings which
> >>> explicitly say that they should not be used in user code and point to
> >>> locking as the user-facing equivalent to Java's synchronized.
> >>>
> >>> Cheers,
> >>> Michał
> >>>
> >>>
> >>> On 1 November 2013 19:34, Michael Blume  wrote:
> >>> > https://github.com/MichaelBlume/perf-test
> >>> >
> >>> > (ns perf-test
> >>> >   (:use (criterium core))
> >>> >   (:gen-class))
> >>> >
> >>> > (def o (Object.))
> >>> >
> >>> > (defn foo [x]
> >>> >   (if (> x 0)
> >>> > (inc x)
> >>> > (do
> >>> >   (monitor-enter o)
> >>> >   (let [res (dec x)]
> >>> > (monitor-exit 0)
> >>> > res
> >>> >
> >>> > (defn bar [x]
> >>> >   (if (> x 0)
> >>> > (inc x)
> >>> > (dec x)))
> >>> >
> >>> > (defn locking-part [x l]
> >>> >   (monitor-enter l)
> >>> >   (let [res (dec x)]
> >>> > (monitor-exit l)
> >>> > res))
> >>> >
> >>> > (defn baz [x]
> >>> >   (if (> x 0)
> >>> > (inc x)
> >>> > (locking-part x o)))
> >>> >
> >>> > (defn -main []
> >>> >   (println "benching foo")
> >>> >   (bench (foo 5) :verbose)
> >>> >   (println "benching bar")
> >>> >   (bench (bar 5) :verbose)
> >>> >   (println "benching baz")
> >>> >   (bench (baz 5) :verbose)
> >>> >   (println "done benching"))
> >>> >
> >>> >
> >>> >
> >>> > I'm only ever calling these functions with positive values, so the
> >>> > monitor-enter branch should never be entered. Nevertheless, the
> >>> > performance
> >>> > of foo is much worse than bar or baz.
> >>> >
> >>> > The best guess I've got is that the fact that lock-taking is involved
> >>> > somehow changes how the function is compiled, somehow making the
> >>> > function
> >>> > slower. If the practical upshot is that I shouldn't write functions
> >>> > that
> >>> > only sometimes lock -- that the locking part of a fun

Re: Clojure Users Group - Denmark

[Anders Konring Olesen]

On Fri, Nov 15, 2013 at 2:28 PM, Krukow  wrote:

> On Thursday, November 14, 2013 11:40:08 PM UTC+1, Jacob Mortensen wrote:
>>
>> I do clojure+clojurescript hobby programming at home. I live in
>> copenhagen. It seems there is a clojure user group here in copenhagen, but
>> I havent been able to locate it.
>>
>
> Well. That sounds good.

I currently live in Aarhus, but of course it is nice to hear that there is
something going on i Copenhagen as well.


> We've started to write some of the concurrent infrastructure in Xamarin
> Test Cloud in Clojure.
>
> I know YouSee is using Clojure in at least one project.
>
> - Karl
>

Are you a member of the Xamarin Team? Are you working in the Aarhus area?

>  --
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/QQc1X529gRo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Anders Konring Olesen
+4524638864

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

Re: Friend roles stored in a database table

[wm . mark . lee]

Hello, some inline-comments...

On Sunday, 17 November 2013 11:25:38 UTC, David Della Costa wrote:

As far as actually storing the roles in the database, they are simply a 
> stringified set of namespace-qualified keywords, like so: 
>
> #{:my-app-ns/user} 
> #{:my-app-ns/admin :my-app-ns/some-other-role} 


This was the piece I was missing.

I hope this helps, definitely let me know if I didn't answer one of your 
> questions. 
>

It definitely helps.

I think the last part of my problem is a language problem rather than 
anything else due to my lack of Clojure experience...

Presumably when I read my user record from the database I need to 
"de-stringify" the roles from the database column to an actual set for the 
":roles" rather than a string, so how do I do that for a string like this?

 #{:my-app-ns/admin :my-app-ns/some-other-role} 
 

> And I'm very happy to hear the tutorial helped you get going, by the way! 
>

It really was the most useful information I found on this subject, 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/groups/opt_out.

Re: [ANN] overload-middleware 0.1.1

[Bob Hutchison]

Hi Rob,

Nice! Thanks for releasing this. I’m not sure when I’ll use this but I can 
pretty much guarantee that I will give it a go sooner or later. I’ve written a 
few of these in the past, it’s good to see someone make a library out of it.

BTW, things like AngularJS and EmberJS should/could know about 503 errors and 
what they mean. There’s actually a project, that I’ve *not* used (yet), 
https://github.com/kkolstad/angular-servicestack that will re-try on a 503 
after a random delay. Here’s the line from their source code (it’s 
coffeescript):

sleepTime = Math.min (Math.random() * (Math.pow(4, response.collisionCount() - 
1) * 100)), serviceStackRestConfig.maxDelayBetweenRetries

Cheers,
Bob

On Nov 16, 2013, at 1:21 PM, Rob Day  wrote:

> Hi all,
> 
> I've just published the first working version of a Ring middleware that some 
> of you might find useful. It's designed for web apps where, if you're 
> overloaded, it's better to serve some requests quickly and fail the others 
> than to try and serve all the requests   and do it slowly. (My background 
> is in telecoms, where that's often the best approach.)
> 
> Specifically, you specify a target latency that you want 90% of requests to 
> try and meet, and it applies the algorithm from 
> http://www.eecs.harvard.edu/%7Emdw/papers/control-usits03.pdf to try and keep 
> your latency below that threshold. The exact parameters of the algorithm are 
> tunable, and different URLs or groups of URLs can have different targets and 
> parameters.
> 
> It still needs a bit of tidying - docstrings, cleaning up some of the Midje 
> tests, and so on - but it works and I think the documentation is usable, so 
> I'm announcing it now.
> 
> Github (w/ docs): https://github.com/rkday/overload-middleware
> Clojars: https://clojars.org/overload-middleware
> 
> Let me know if you have any feedback!
> Rob

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

Re: [ANN] overload-middleware 0.1.1

[James Reeves]

On 17 November 2013 13:04, Clinton Dreisbach  wrote:

> People, you are not going to win a fight with a Level 65 Troll Wizard.
> Back away slowly.
>
> Rob, this is a cool library: thanks for writing it.
>

Point taken.

I've added this library to clojure-toolbox.com. I can see this library
being very useful for certain systems.

- James

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

Re: [ANN] overload-middleware 0.1.1

[Cedric Greevey]

On Sun, Nov 17, 2013 at 8:22 AM, Christian Romney  wrote:

> Maybe you should re-read this whole thread. Clinton is just pointing out
> how impolite it is, particularly as the first response to an ANN post, to
> poopoo all over someone else's work,
>

Please provide a citation to back up your claim that I did anything of the
kind.

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

Re: [ANN] overload-middleware 0.1.1

[Luc Prefontaine]

No, no, I can assure you, it's not an 
insult, you are well beyond.

:))) --> toward the edge of
the universe

Luc P


> Is that intended as some sort of an insult aimed at me? I'm just pointing
> out that "the web" != "everything that might conceivably be done with the
> HTTP protocol". "The web" is that thing you browse with Firefox, more or
> less by definition (even if sometimes tools like curl and wget are used as
> shortcuts when downloading files or scraping data off some site, and
> testing tools used to find dead links, and the like -- the web is that
> HTTP-served stuff whose *primary* interface is intended to be a web
> browser). So, for example, although the Gnutella file-sharing software uses
> HTTP under the hood for file transfers, it's not "the web".
> 
> 
> On Sun, Nov 17, 2013 at 8:04 AM, Clinton Dreisbach 
> wrote:
> 
> > People, you are not going to win a fight with a Level 65 Troll Wizard.
> > Back away slowly.
> >
> > Rob, this is a cool library: thanks for writing it.
> >
> > -- Clinton Dreisbach
> >
> >
> > On Sun, Nov 17, 2013 at 7:53 AM, Cedric Greevey wrote:
> >
> >> So, when people here are talking about the web, they might not be talking
> >> about the web. Erm, okay, I guess ...
> >>
> >>
> >> On Sun, Nov 17, 2013 at 7:11 AM, James Reeves wrote:
> >>
> >>> On 17 November 2013 05:25, Cedric Greevey  wrote:
> >>>
>  On Sat, Nov 16, 2013 at 9:35 PM, James Reeves 
>  wrote:
> 
> > On 17 November 2013 01:52, Cedric Greevey  wrote:
> >
> >> The distribution will be narrow and peak at around 1 second, though,
> >> which may not be what you want. Of course, the OP has since indicated 
> >> that
> >> he meant non-web uses of HTTP rather than serving web sites...
> >>
> >
> > Web services are generally considered to be part of the web, hence the
> > term "*web* service" :)
> >
> 
>   Well, which is it? Either it's the web, and the user will probably
>  promptly hit reload if faced with a 503 error at what should be a working
>  URL, or else it's not the web, and lies outside the scope of my original
>  remark.
> 
> >>>
> >>> You're going to be very confused if you keep believing that the web only
> >>> refers to the visible parts you can access through a browser!
> >>>
> >>> When people talk about web apps, they're not necessarily talking about
> >>> websites. You just need to use your common sense to discern what they 
> >>> mean.
> >>> If someone suggests something that might seem undesirable for a 
> >>> user-facing
> >>> website to have, maybe they're talking about a machine-readable web 
> >>> service
> >>> instead.
> >>>
> >>> - James
> >>>
> >>> --
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Clojure" group.
> >>> To post to this group, send email to clojure@googlegroups.com
> >>> Note that posts from new members are moderated - please be patient with
> >>> your first post.
> >>> To unsubscribe from this group, send email to
> >>> clojure+unsubscr...@googlegroups.com
> >>> For more options, visit this group at
> >>> http://groups.google.com/group/clojure?hl=en
> >>> ---
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Clojure" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> >>> an email to clojure+unsubscr...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>
> >>
> >>  --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >
> >  --
> > --
> > 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.

Re: [ANN] overload-middleware 0.1.1

[Christian Romney]

Maybe you should re-read this whole thread. Clinton is just pointing out how 
impolite it is, particularly as the first response to an ANN post, to poopoo 
all over someone else's work, shared freely and graciously with the rest of the 
community, simply because *you* can't see a use for it. Clearly at least one 
person finds it useful, and someone cared enough about the topic to write a 
paper on it. A perfectly viable and more polite alternative would have been to 
simply ignore the 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] overload-middleware 0.1.1

[Cedric Greevey]

Is that intended as some sort of an insult aimed at me? I'm just pointing
out that "the web" != "everything that might conceivably be done with the
HTTP protocol". "The web" is that thing you browse with Firefox, more or
less by definition (even if sometimes tools like curl and wget are used as
shortcuts when downloading files or scraping data off some site, and
testing tools used to find dead links, and the like -- the web is that
HTTP-served stuff whose *primary* interface is intended to be a web
browser). So, for example, although the Gnutella file-sharing software uses
HTTP under the hood for file transfers, it's not "the web".


On Sun, Nov 17, 2013 at 8:04 AM, Clinton Dreisbach wrote:

> People, you are not going to win a fight with a Level 65 Troll Wizard.
> Back away slowly.
>
> Rob, this is a cool library: thanks for writing it.
>
> -- Clinton Dreisbach
>
>
> On Sun, Nov 17, 2013 at 7:53 AM, Cedric Greevey wrote:
>
>> So, when people here are talking about the web, they might not be talking
>> about the web. Erm, okay, I guess ...
>>
>>
>> On Sun, Nov 17, 2013 at 7:11 AM, James Reeves wrote:
>>
>>> On 17 November 2013 05:25, Cedric Greevey  wrote:
>>>
 On Sat, Nov 16, 2013 at 9:35 PM, James Reeves wrote:

> On 17 November 2013 01:52, Cedric Greevey  wrote:
>
>> The distribution will be narrow and peak at around 1 second, though,
>> which may not be what you want. Of course, the OP has since indicated 
>> that
>> he meant non-web uses of HTTP rather than serving web sites...
>>
>
> Web services are generally considered to be part of the web, hence the
> term "*web* service" :)
>

  Well, which is it? Either it's the web, and the user will probably
 promptly hit reload if faced with a 503 error at what should be a working
 URL, or else it's not the web, and lies outside the scope of my original
 remark.

>>>
>>> You're going to be very confused if you keep believing that the web only
>>> refers to the visible parts you can access through a browser!
>>>
>>> When people talk about web apps, they're not necessarily talking about
>>> websites. You just need to use your common sense to discern what they mean.
>>> If someone suggests something that might seem undesirable for a user-facing
>>> website to have, maybe they're talking about a machine-readable web service
>>> instead.
>>>
>>> - James
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@google

Re: [ANN] overload-middleware 0.1.1

[Clinton Dreisbach]

People, you are not going to win a fight with a Level 65 Troll Wizard. Back
away slowly.

Rob, this is a cool library: thanks for writing it.

-- Clinton Dreisbach


On Sun, Nov 17, 2013 at 7:53 AM, Cedric Greevey  wrote:

> So, when people here are talking about the web, they might not be talking
> about the web. Erm, okay, I guess ...
>
>
> On Sun, Nov 17, 2013 at 7:11 AM, James Reeves wrote:
>
>> On 17 November 2013 05:25, Cedric Greevey  wrote:
>>
>>> On Sat, Nov 16, 2013 at 9:35 PM, James Reeves wrote:
>>>
 On 17 November 2013 01:52, Cedric Greevey  wrote:

> The distribution will be narrow and peak at around 1 second, though,
> which may not be what you want. Of course, the OP has since indicated that
> he meant non-web uses of HTTP rather than serving web sites...
>

 Web services are generally considered to be part of the web, hence the
 term "*web* service" :)

>>>
>>>  Well, which is it? Either it's the web, and the user will probably
>>> promptly hit reload if faced with a 503 error at what should be a working
>>> URL, or else it's not the web, and lies outside the scope of my original
>>> remark.
>>>
>>
>> You're going to be very confused if you keep believing that the web only
>> refers to the visible parts you can access through a browser!
>>
>> When people talk about web apps, they're not necessarily talking about
>> websites. You just need to use your common sense to discern what they mean.
>> If someone suggests something that might seem undesirable for a user-facing
>> website to have, maybe they're talking about a machine-readable web service
>> instead.
>>
>> - James
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] overload-middleware 0.1.1

[Cedric Greevey]

So, when people here are talking about the web, they might not be talking
about the web. Erm, okay, I guess ...


On Sun, Nov 17, 2013 at 7:11 AM, James Reeves  wrote:

> On 17 November 2013 05:25, Cedric Greevey  wrote:
>
>> On Sat, Nov 16, 2013 at 9:35 PM, James Reeves wrote:
>>
>>> On 17 November 2013 01:52, Cedric Greevey  wrote:
>>>
 The distribution will be narrow and peak at around 1 second, though,
 which may not be what you want. Of course, the OP has since indicated that
 he meant non-web uses of HTTP rather than serving web sites...

>>>
>>> Web services are generally considered to be part of the web, hence the
>>> term "*web* service" :)
>>>
>>
>>  Well, which is it? Either it's the web, and the user will probably
>> promptly hit reload if faced with a 503 error at what should be a working
>> URL, or else it's not the web, and lies outside the scope of my original
>> remark.
>>
>
> You're going to be very confused if you keep believing that the web only
> refers to the visible parts you can access through a browser!
>
> When people talk about web apps, they're not necessarily talking about
> websites. You just need to use your common sense to discern what they mean.
> If someone suggests something that might seem undesirable for a user-facing
> website to have, maybe they're talking about a machine-readable web service
> instead.
>
> - James
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] overload-middleware 0.1.1

[James Reeves]

On 17 November 2013 05:25, Cedric Greevey  wrote:

> On Sat, Nov 16, 2013 at 9:35 PM, James Reeves wrote:
>
>> On 17 November 2013 01:52, Cedric Greevey  wrote:
>>
>>> The distribution will be narrow and peak at around 1 second, though,
>>> which may not be what you want. Of course, the OP has since indicated that
>>> he meant non-web uses of HTTP rather than serving web sites...
>>>
>>
>> Web services are generally considered to be part of the web, hence the
>> term "*web* service" :)
>>
>
>  Well, which is it? Either it's the web, and the user will probably
> promptly hit reload if faced with a 503 error at what should be a working
> URL, or else it's not the web, and lies outside the scope of my original
> remark.
>

You're going to be very confused if you keep believing that the web only
refers to the visible parts you can access through a browser!

When people talk about web apps, they're not necessarily talking about
websites. You just need to use your common sense to discern what they mean.
If someone suggests something that might seem undesirable for a user-facing
website to have, maybe they're talking about a machine-readable web service
instead.

- James

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

Re: Friend roles stored in a database table

[Dave Della Costa]

Sounds like you've got some of this working smoothly already, so
apologies in advance if any of this is redundant.

Regarding database roles, the way I have it working in one of my simpler
apps with the default interactive form workflow is to set the
credential-fn in the workflow configuration to something like this:

(defn verify-credentials
  [creds]
  (let [valid-user (creds/bcrypt-credential-fn users/get-user-creds creds)]
;; other app-specific logic ...
valid-user)) ; finally, returns the valid-user

My get-user-creds function is what queries the database and returns the
user info, including roles, formatted for use in friend's identity map.
 In this case the roles are simply a column in the db, but of course
this can be anything as long as you end up with something that looks the
same as the map described in the friend docs (a little further down from
here: https://github.com/cemerick/friend#httpfriend-demoherokuappcom).

The password is checked using bcrypt-credential-fn (obviously you can
substitute this with a different function if you so desire) which
returns either nil or the user-record with the password stripped out.

https://github.com/cemerick/friend/blob/master/src/cemerick/friend/credentials.clj#L20

It then is returned to the interactive-form workflow, which loads it up
into friend's identity map to be stored in the session and used for
role-based authorization checks from that point forward.

https://github.com/cemerick/friend/blob/master/src/cemerick/friend/workflows.clj#L80

As far as actually storing the roles in the database, they are simply a
stringified set of namespace-qualified keywords, like so:

#{:my-app-ns/user}
#{:my-app-ns/admin :my-app-ns/some-other-role}

etc.

I hope this helps, definitely let me know if I didn't answer one of your
questions.

And I'm very happy to hear the tutorial helped you get going, by the way!

DD


(2013/11/17 18:50), wm.mark@gmail.com wrote:
> Hello,
> 
> As a long-time Java web developer, I've now been doing clojure for a few
> days so there's a lot I don't get yet, but I do have an end-to-end
> working Compojure web application with a UI, JSON web services, and
> working form-based authentication using Friend - originally using the
> in-memory users 'database' from the demos.
> 
> So what I am doing now is trying to get user name and password
> validation going against a database table.
> 
> I actually managed to get this integrated and working as a Friend
> credential-fn.
> 
> The state my application in right now is that username and password
> combinations are properly validated against my database table. So I can
> authenticate, or not, correctly.
> 
> The only piece that is not yet working is to get role authorisations
> working according to the roles in my database table.
> 
> I just can't see how I'm supposed to map one or more namespaced roles to
> either a "roles" column value, or a roles join table in the database. 
> 
> The examples for Friend show roles like "::admin", "::user", and I use
> similar roles from more than one namespace - so what should I persist in
> the database to load those roles via my credential-fn, and how should I
> populate the :roles property from the result-set?
> 
> I feel like I'm really close to getting this fully working, but I've hit
> a road-block so any pointers would be greatly appreciated.
> 
> Regards,
> 
> -M.
> 
> PS
> 
> This tutorial was very helpful, so thanks to @ddellacosta
> 
> [1] https://github.com/ddellacosta/friend-interactive-form-tutorial
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: [ANN] overload-middleware 0.1.1

[Bruce Adams]

Even for a web site used exclusively by people, "fail fast" when
overloaded can be good. You would rather give an error (one hopes a
"gee, so sorry, we having some trouble right now" page) to some users
rather than be extremely slow for many users.



What do I do when I get a slow web page? I hit reload (and I am not
alone). This further overloads the system and doesn't even cancel the
earlier requests (from the servers point of view). A "fail fast"
response didn't cost the server very much. With luck, the load will be
lower a few seconds later when the user hits reload.



On Sun, Nov 17, 2013, at 12:25 AM, Cedric Greevey wrote:

On Sat, Nov 16, 2013 at 9:35 PM, James Reeves
<[1]ja...@booleanknot.com> wrote:

On 17 November 2013 01:52, Cedric Greevey <[2]cgree...@gmail.com>
wrote:

The distribution will be narrow and peak at around 1 second, though,
which may not be what you want. Of course, the OP has since indicated
that he meant non-web uses of HTTP rather than serving web sites...


Web services are generally considered to be part of the web, hence the
term "web service" :)


Well, which is it? Either it's the web, and the user will probably
promptly hit reload if faced with a 503 error at what should be a
working URL, or else it's not the web, and lies outside the scope of my
original remark.

References

1. mailto:ja...@booleanknot.com
2. mailto:cgree...@gmail.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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.

[Andrey Antukh]

Hi Zach!

It is not based on any concrete version (is not a fork). Casually, it
has similarities with java.jdbc 0.2.x because uses same name for some
functions
(in my opinion 0.2 version has better api than 0.3). Additionally I have
copied some useful functions like parsing dbspec to URI or a map of
protocol->cases
and the rest are written from scratch.

Furthermore, a new version of java.jdbc (0.3.x), introduces a lot of
complexity to code in comparison to 0.2 and base it on the new version
would be a mistake.
In any case, as I said previously, clj.jdbc is not based in any concrete
version of java.jdbc.

You can read more about it on faq section of clj.jdbc
http://cljjdbc.readthedocs.org/en/latest/faq.html#why-one-other-jdbc-wrapper
that
explains a main differences
with a current version of java.jdbc (0.3)

In respect to jdk7, personally I don't know if clj.jdbc works with jdk6
because I only working with jdk7. But, any compatibility fixes for jdk6 are
welcome!



2013/11/17 Zach Oakes 

> Andrey, this looks interesting. It seems to be based on a really old
> version of clojure.java.jdbc, though. Is there a reason for this? Since it
> is a fork, it seems like it would be best to base it on a recent version,
> to aid those who may want to try switching to it. Also, does it require JDK
> 7 to compile?
>
>
> On Saturday, November 16, 2013 6:48:03 AM UTC-5, Andrey Antukh wrote:
>
>> Hi!
>>
>> I have some frustration with current official jdbc wrapper for clojure
>> and I have worked in one alternative mainly because of:
>>
>> - Lack of documentation.
>> - Philosophical differences of how things should be done.
>>
>> Documentation page: http://cljjdbc.readthedocs.org/en/latest/
>> Github: https://github.com/niwibe/clj.jdbc
>>
>> Any feedback always welcome.
>>
>> Andrey
>>
>> --
>> Andrey Antukh - Андрей Антух - 
>>
>> http://www.niwi.be/about.html
>> http://www.kaleidos.net/A5694F/
>>
>> "Linux is for people who hate Windows, BSD is for people who love UNIX"
>> "Social Engineer -> Because there is no patch for human stupidity"
>>
>


-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

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

Friend roles stored in a database table

[wm . mark . lee]

Hello,

As a long-time Java web developer, I've now been doing clojure for a few 
days so there's a lot I don't get yet, but I do have an end-to-end working 
Compojure web application with a UI, JSON web services, and working 
form-based authentication using Friend - originally using the in-memory 
users 'database' from the demos.

So what I am doing now is trying to get user name and password validation 
going against a database table.

I actually managed to get this integrated and working as a Friend 
credential-fn.

The state my application in right now is that username and password 
combinations are properly validated against my database table. So I can 
authenticate, or not, correctly.

The only piece that is not yet working is to get role authorisations 
working according to the roles in my database table.

I just can't see how I'm supposed to map one or more namespaced roles to 
either a "roles" column value, or a roles join table in the database. 

The examples for Friend show roles like "::admin", "::user", and I use 
similar roles from more than one namespace - so what should I persist in 
the database to load those roles via my credential-fn, and how should I 
populate the :roles property from the result-set?

I feel like I'm really close to getting this fully working, but I've hit a 
road-block so any pointers would be greatly appreciated.

Regards,

-M.

PS

This tutorial was very helpful, so thanks to @ddellacosta

[1] https://github.com/ddellacosta/friend-interactive-form-tutorial

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