Re: OAuth2

[Bastien]

Hi Plínio,

Plínio Balduino  writes:

> What are you using to authenticate with Google, Facebook, GitHub or
> Twitter?

I'm experimenting with "friend":

https://github.com/cemerick/friend
http://friend-demo.herokuapp.com/

HTH,

-- 
 Bastien

-- 
-- 
You 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] Vertigo: fast, idiomatic C-style structs

[kovas boguta]

Interesting. This seems like a pretty promising direction for the bottom of
the big-data stack.

A use case on my mind is sorting a big list of datastructures by key (or
some set of keys/paths) .

Once the data gets big, you need to do an external sort, which means tons
of serialization round trips if implemented naively. Being able to just
pluck out the values you need really helps in that case. Besides saving on
the serialization overhead, it also cuts down on memory which means you can
sort much bigger segments at a time, and complete the overall sort in fewer
passes.







On Mon, Jul 15, 2013 at 1:40 PM, Zach Tellman  wrote:

> If you (vertigo.core/wrap "a-file-name"), that will use mmap under the
> covers, so if no one's tried it, it's easy enough to start.
>
> With respect to non-fixed data layouts, that could be supported by a
> library which parses the framing information, and then layers Vertigo atop
> the actual data.  In effect, that's what Gloss [1] is going to become, so
> keep watching the skies.
>
> Zach
>
> [1] https://github.com/ztellman/gloss
>
>
> On Sun, Jul 14, 2013 at 9:16 PM, kovas boguta wrote:
>
>> This is pretty neat.
>>
>> Anyone try using this in conjunction with mmap?
>>
>> It would be nice to have some way to deal with strings & other
>> variable-length data.
>>
>> I'm also curious if its possible to make the analog of this for fressian,
>> basically to avoid unpacking objects that are not necessary for the
>> computation at hand.
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 9, 2013 at 8:56 PM, Zach Tellman  wrote:
>>
>>> Last year, I gave a talk at the Conj on my attempt to write an AI for
>>> the board game Go.  Two things I discovered is that it was hard to get
>>> predictable performance, but even once I made sure I had all the right type
>>> hints, there was still a lot of room at the bottom for performance
>>> improvements.  Towards the end [1], I mentioned a few ideas for
>>> improvements, one of which was simply using ByteBuffers rather than objects
>>> to host the data.  This would remove all the levels of indirection, giving
>>> much better cache coherency, and also allow for fast unsynchronized
>>> mutability when the situation called for it.
>>>
>>> So, ten months and several supporting libraries [2] [3] later, here it
>>> is: https://github.com/ztellman/vertigo
>>>
>>> At a high level, this library is useful whenever your datatype has a
>>> fixed layout and is used more than once.  Depending on your type, it will
>>> give you moderate to large memory savings, and if you're willing to forgo
>>> some of core library in favor of Vertigo's operators, you can get
>>> significant performance gains on batch operations.  And, in the cases where
>>> performance doesn't matter, it will behave exactly like any other Clojure
>>> data structure.
>>>
>>> I want to point out that something like this would be more or less
>>> impossible in Java; reading from an offset in a ByteBuffer without the
>>> compile-time inference and validation provided by this library would be
>>> pointlessly risky.  There's not a lot of low-level Clojure libraries, but
>>> there's an increasing amount of production usage where people are using
>>> Clojure for performance-sensitive work.  I'm looking forward to seeing what
>>> people do with Vertigo and libraries like it.
>>>
>>> Zach
>>>
>>> [1]
>>> http://www.youtube.com/watch?feature=player_detailpage&v=v5dYE0CMmHQ#t=1828s
>>> [2] https://github.com/ztellman/primitive-math
>>> [3] https://github.com/ztellman/byte-streams
>>>
>>> --
>>> --
>>> You 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/BayfuaqMzvs/unsubscribe.
>> To 

Re: core.async: exception handling

[Timothy Baldridge]

In the latest copy of core.async (taken from github master), I get this
error:

 (go
 (try
   (go (throw (Exception.)))
   (catch Exception ex
 (println "catched"

xception in thread "async-dispatch-2" java.lang.Error: java.lang.Exception
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.Exception
at
user$eval2509$fn__2510$state_machine__2342__auto2511$fn__2517$fn__2518$state_machine__2342__auto2519.invoke(NO_SOURCE_FILE:1)
at
clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:763)
at
user$eval2509$fn__2510$state_machine__2342__auto2511$fn__2517$fn__2518.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
... 2 more
#


This is exactly as expected. In your code snippet, the exception is
escaping the inner go. If you want to catch that exception, you need to put
the try/catch inside the go block.


Timothy


On Mon, Jul 15, 2013 at 10:20 PM, Alice  wrote:

> user=> (go
>  (try
>(go (throw (Exception.)))
>(catch Exception ex
>  (println "catched"
>
> IllegalArgumentException contains? not supported on type:
> clojure.lang.PersistentList  clojure.lang.RT.contains (RT.java:724)
>
>
> Why am I getting this error?
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

core.async: exception handling

[Alice]

user=> (go
 (try
   (go (throw (Exception.)))
   (catch Exception ex
 (println "catched"

IllegalArgumentException contains? not supported on type: 
clojure.lang.PersistentList  clojure.lang.RT.contains (RT.java:724)


Why am I getting this error?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: An example app using core.async and tools.namespace

[Sean Corfield]

This is a great example of both Stuart Sierra's suggested workflow
(from his talk at Clojure/West) and of using core.async to simplify
concurrent, collaborating processes! Thanks for sharing!

Sean

On Mon, Jul 15, 2013 at 11:10 AM, mybuddymichael
 wrote:
> I recently rewrote my team's IRC bot to use tools.namespace and
> core.async. You can check out the source on GitHub at
> https://github.com/mybuddymichael/pgbot.
>
> To explain briefly, the bot is basically several loops communicating
> over channels. The primary processes are two async/threads, reading
> lines from the socket and printing lines to it. A few subsystems running
> in async/go blocks can each give a few channels to the connection loops.
> The two connection threads are continuously >!-ing or alts!!-ing with
> those channels to distribute and gather messages.
>
> Even though the app is small, using channels is very nice for decoupling
> the subsystems from the connection object and its message loops. And
> using tools.namespace has been a dream for development. I can make
> changes and have a new IRC bot running with the new code in
> milliseconds. Totally dreamy stuff. My interaction with tools.namespace
> all happens through the user namespace, which is excluded from jars via
> Leiningen's profiles feature.
>
> Our bot is now running in production internally without any hiccups.
> Much thanks to Rich, Stuart, and the rest of the gang for building such
> cool libraries. And suggestions for improvements to the system or
> workflow are always welcome.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 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.
>
>



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

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

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

OAuth2

[Plínio Balduino]

Hi there

What are you using to authenticate with Google, Facebook, GitHub or Twitter?

Thanks

Plínio

-- 
-- 
You 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: --> macro proposal

[Jeremy Heiler]

On July 15, 2013 at 6:30:28 PM, Daniel Dinnyes (dinny...@gmail.com) wrote:
Hmm, good point, especially the `let` one... What is `as->`? I can't find 
anything about that.
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/as-%3E

There is one benefit over `let` though: it is more explicit. Let allows you to 
define independent bindings mixed together with multiple threads of dependent 
bindings (which can be mixed in random combinations). As the number of bindings 
increase it becomes quite messy, and hard to decipher which line depends on 
which. I have seen, even written myself (shame on me), such code. I feel that 
this is the main reason for the `core` threading macros too ("why not use let 
instead?" would still apply then). On the other hand as my simple example code 
demonstrates (off the top of my hat, cuz ya need to show da code!), in a 
functional language the parameter order shouldn't matter, and there shouldn't 
be privileged (main!?) parameter positions (Clojure is the landguage of 
multimethods after all!)
Your ->>> is a bit awkward because the symbol to the left represents the value 
of the previous expression, not the value of the following expression as is the 
case with most "bindings forms" in Clojure. Also, as-> simplifies your use case 
by only needing to identify one name that is used in all the threaded forms. 
Honestly, if I'm going to do anything more complicated that as->, I would 
rethink how I want to express my code.

Anyway, I see the reason for -> and ->> macros and indeed the first and last 
positions are special in some sense. The -> is good for navigating protocols, 
and ->> is good for functions expected/designed to be partially applied. Is 
that correct?
The threading macros operate on the forms directly, so I'm not sure what you 
mean by "partially applied" here. The big win for ->> is that the sequence 
functions in Clojure core expect the sequence to be last. This is handy for 
threading a sequence through multiple transformations.

-- 
-- 
You 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: --> macro proposal

[Daniel Dinnyes]

Hmm, good point, especially the `let` one... What is `as->`? I can't find 
anything about that.

There is one benefit over `let` though: it is more explicit. Let allows you 
to define independent bindings mixed together with multiple threads of 
dependent bindings (which can be mixed in random combinations). As the 
number of bindings increase it becomes quite messy, and hard to decipher 
which line depends on which. I have seen, even written myself (shame on 
me), such code. I feel that this is the main reason for the `core` 
threading macros too ("why not use let instead?" would still apply then). 
On the other hand as my simple example code demonstrates (off the top of my 
hat, cuz ya need to show da code!), in a functional language the parameter 
order shouldn't matter, and there shouldn't be privileged (main!?) 
parameter positions (Clojure is the landguage of multimethods after all!)

(BTW, have you noticed you can do destructuring with ->>> out of the box ;)

Anyway, I see the reason for -> and ->> macros and indeed the first and 
last positions are special in some sense. The -> is good for navigating 
protocols, and ->> is good for functions expected/designed to be partially 
applied. Is that correct?

Cheers,

Daniel

On Sunday, July 14, 2013 5:39:18 PM UTC+1, Jeremy Heiler wrote:
>
> On Sat, Jul 13, 2013 at 10:49 PM, Daniel Dinnyes 
> > 
> wrote: 
> > (->>> "test-string-with-lots-of-dashes" 
> > x (s/split x #"-") 
> > y (interleave y (range)) 
> > z (s/join #"_" z) 
> > z (s/join " * " ["I am serious" z "Not Kidding!!" z])) 
>
> Why not use as-> or a let in this situation? 
>

-- 
-- 
You 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] Vertigo: fast, idiomatic C-style structs

[Zach Tellman]

If you (vertigo.core/wrap "a-file-name"), that will use mmap under the
covers, so if no one's tried it, it's easy enough to start.

With respect to non-fixed data layouts, that could be supported by a
library which parses the framing information, and then layers Vertigo atop
the actual data.  In effect, that's what Gloss [1] is going to become, so
keep watching the skies.

Zach

[1] https://github.com/ztellman/gloss


On Sun, Jul 14, 2013 at 9:16 PM, kovas boguta wrote:

> This is pretty neat.
>
> Anyone try using this in conjunction with mmap?
>
> It would be nice to have some way to deal with strings & other
> variable-length data.
>
> I'm also curious if its possible to make the analog of this for fressian,
> basically to avoid unpacking objects that are not necessary for the
> computation at hand.
>
>
>
>
>
>
> On Tue, Jul 9, 2013 at 8:56 PM, Zach Tellman  wrote:
>
>> Last year, I gave a talk at the Conj on my attempt to write an AI for the
>> board game Go.  Two things I discovered is that it was hard to get
>> predictable performance, but even once I made sure I had all the right type
>> hints, there was still a lot of room at the bottom for performance
>> improvements.  Towards the end [1], I mentioned a few ideas for
>> improvements, one of which was simply using ByteBuffers rather than objects
>> to host the data.  This would remove all the levels of indirection, giving
>> much better cache coherency, and also allow for fast unsynchronized
>> mutability when the situation called for it.
>>
>> So, ten months and several supporting libraries [2] [3] later, here it
>> is: https://github.com/ztellman/vertigo
>>
>> At a high level, this library is useful whenever your datatype has a
>> fixed layout and is used more than once.  Depending on your type, it will
>> give you moderate to large memory savings, and if you're willing to forgo
>> some of core library in favor of Vertigo's operators, you can get
>> significant performance gains on batch operations.  And, in the cases where
>> performance doesn't matter, it will behave exactly like any other Clojure
>> data structure.
>>
>> I want to point out that something like this would be more or less
>> impossible in Java; reading from an offset in a ByteBuffer without the
>> compile-time inference and validation provided by this library would be
>> pointlessly risky.  There's not a lot of low-level Clojure libraries, but
>> there's an increasing amount of production usage where people are using
>> Clojure for performance-sensitive work.  I'm looking forward to seeing what
>> people do with Vertigo and libraries like it.
>>
>> Zach
>>
>> [1]
>> http://www.youtube.com/watch?feature=player_detailpage&v=v5dYE0CMmHQ#t=1828s
>> [2] https://github.com/ztellman/primitive-math
>> [3] https://github.com/ztellman/byte-streams
>>
>> --
>> --
>> You 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/BayfuaqMzvs/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.
>
>
>

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

An example app using core.async and tools.namespace

[mybuddymichael]

I recently rewrote my team's IRC bot to use tools.namespace and
core.async. You can check out the source on GitHub at
https://github.com/mybuddymichael/pgbot.

To explain briefly, the bot is basically several loops communicating
over channels. The primary processes are two async/threads, reading
lines from the socket and printing lines to it. A few subsystems running
in async/go blocks can each give a few channels to the connection loops.
The two connection threads are continuously >!-ing or alts!!-ing with
those channels to distribute and gather messages.

Even though the app is small, using channels is very nice for decoupling
the subsystems from the connection object and its message loops. And
using tools.namespace has been a dream for development. I can make
changes and have a new IRC bot running with the new code in
milliseconds. Totally dreamy stuff. My interaction with tools.namespace
all happens through the user namespace, which is excluded from jars via
Leiningen's profiles feature.

Our bot is now running in production internally without any hiccups.
Much thanks to Rich, Stuart, and the rest of the gang for building such
cool libraries. And suggestions for improvements to the system or
workflow are always welcome.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: test.generative and data.generators

[Reid Draper]

On Monday, July 15, 2013 9:41:03 AM UTC-5, Andreas Liljeqvist wrote:
>
> Hi, I have taken a look at simple-check.
>
> Seems promising, but I have a few reservations:
>
> I want to constrain the generation of two vectors to always have the same 
> number of elements as the other one.
> From what I can understand simple-check always uses the same max-size in a 
> property and have no current means to control the min length.
>

This is doable today, but ensuring they stay the same length as each other 
during shrinking is not yet possible. simple-check will need to support 
overriding the shrink function for this to work. That's on my TODO list. 
I'll try and add some documentation
for writing generators like this soon, but in the meantime, take a look at 
how the vector generator is implemented [1]. Your custom generator would 
just use `num-elements` twice, for each of the two vectors that need to be 
the same length.

[1] 
https://github.com/reiddraper/simple-check/blob/bbd90a76d78f5cdf25b22d9eec9fc7eedf2c8d09/src/simple_check/generators.clj#L261-L262
 

>
> Its kind of hard to inspect what values I am actually generating since the 
> generator functions return non-runnable functions.
> (without any scaffolding).
>

This is what simple-check.generators/sample is for. Check out it's 
implementation to see how the generators are called.
 

>
> Really I think that data.generators would fit nicely into simple-check.
> (I am not well-versed in the domain though...)
>

Yeah, I've been thinking about writing a little function that would lift 
data.generators generators into simple-check generators, but haven't gotten 
around to it yet. Should be pretty trivial though.
 

>
> I like the general feel of simple-check and shrinking rocks.
>

Awesome, thanks for checking it out.
 

>
>
>
>
> On Mon, Jul 15, 2013 at 2:24 PM, Chas Emerick 
> > wrote:
>
>> Shrinking is a key requirement for me as well (1000-line-long data 
>> literals that produce a failure are better than nothing, but not quite as 
>> nice as its shrunken 40-character literal that provokes the same failure). 
>>  You might be interested in simple-check, which is a "Clojure 
>> property-based testing tool inspired by QuickCheck", and so its support for 
>> shrinking is essential:
>>
>> https://github.com/reiddraper/simple-check/
>>
>> I've been using it for some weeks now with good results.
>>
>> Cheers,
>>
>> - Chas
>>
>> On Jul 15, 2013, at 7:35 AM, Andreas Liljeqvist wrote:
>>
>> So, I find that what they provide are absolutely fantastic.
>> But I don't see much action around them, are they considered maintained?
>>
>> Things on my wishlish: 
>> Shrinking of failing inputs.
>> More readable reports.
>> A couple of blogs or videos discussing them, I think that most people 
>> don't know what they are used for.
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/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 clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/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 http

Re: Matching false (== undefined, null) in ClojureScript core.match

[David Nolen]

Do you have a small failing example?


On Mon, Jul 15, 2013 at 12:08 PM, Michal Till  wrote:

> I'm trying to match a false value of map's key (foo.bar) , which in
> javascript effectively means also undefined,null etc... It seems to me
> that core.match matches the value exactly. Is there any way to do this?
>
> The other way would be to match "not true", but the docs don't give me
> any hint how to do this either.
>
>  --
> --
> You 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] Pedestal-app Tutorial has been released

[boz jennings]

Having fun going through the tutorial! Thanks for the good stuff!
,boz

On Tuesday, July 9, 2013 9:03:58 AM UTC-7, Ryan Neufeld wrote:
>
> Hey there, Clojurians/Pedestallions! 
>
> I'm pleased to announce the release of a comprehensive tutorial for 
> pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we 
> finally *dive deep* into the guts of pedestal-app and build a distributed 
> multiplayer game using pedestal-app. 
>
> Major kudos to @brentonashworth for all his hard work on the pedestal-app 
> tutorial. 
>
> Enjoy!
>
> -- Ryan Neufeld 
>
>
> -- Ryan Neufeld 
>
>

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

Matching false (== undefined, null) in ClojureScript core.match

[Michal Till]

I'm trying to match a false value of map's key (foo.bar) , which in 
javascript effectively means also undefined,null etc... It seems to me that 
core.match matches the value exactly. Is there any way to do this?

The other way would be to match "not true", but the docs don't give me any 
hint how to do this either.

-- 
-- 
You 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] Vertigo: fast, idiomatic C-style structs

[Karsten Schmidt]

Hi Zach, this looks very interesting indeed and a great next step
after Gloss. For my SimpleCL[1] project I needed something v.similar,
but went a slightly different way to represent clj data as byte
buffers and compile them from specs parsed from C (header) files[2]. I
will give Vertigo a try ASAP and see how (much better) performance is
with that... great stuff & thanks for sharing!

[1] http://hg.postspectacular/simplecl
[2] http://hg.postspectacular/structgen

Best, K.

On 15 July 2013 05:16, kovas boguta  wrote:
> This is pretty neat.
>
> Anyone try using this in conjunction with mmap?
>
> It would be nice to have some way to deal with strings & other
> variable-length data.
>
> I'm also curious if its possible to make the analog of this for fressian,
> basically to avoid unpacking objects that are not necessary for the
> computation at hand.
>
>
>
>
>
>
> On Tue, Jul 9, 2013 at 8:56 PM, Zach Tellman  wrote:
>>
>> Last year, I gave a talk at the Conj on my attempt to write an AI for the
>> board game Go.  Two things I discovered is that it was hard to get
>> predictable performance, but even once I made sure I had all the right type
>> hints, there was still a lot of room at the bottom for performance
>> improvements.  Towards the end [1], I mentioned a few ideas for
>> improvements, one of which was simply using ByteBuffers rather than objects
>> to host the data.  This would remove all the levels of indirection, giving
>> much better cache coherency, and also allow for fast unsynchronized
>> mutability when the situation called for it.
>>
>> So, ten months and several supporting libraries [2] [3] later, here it is:
>> https://github.com/ztellman/vertigo
>>
>> At a high level, this library is useful whenever your datatype has a fixed
>> layout and is used more than once.  Depending on your type, it will give you
>> moderate to large memory savings, and if you're willing to forgo some of
>> core library in favor of Vertigo's operators, you can get significant
>> performance gains on batch operations.  And, in the cases where performance
>> doesn't matter, it will behave exactly like any other Clojure data
>> structure.
>>
>> I want to point out that something like this would be more or less
>> impossible in Java; reading from an offset in a ByteBuffer without the
>> compile-time inference and validation provided by this library would be
>> pointlessly risky.  There's not a lot of low-level Clojure libraries, but
>> there's an increasing amount of production usage where people are using
>> Clojure for performance-sensitive work.  I'm looking forward to seeing what
>> people do with Vertigo and libraries like it.
>>
>> Zach
>>
>> [1]
>> http://www.youtube.com/watch?feature=player_detailpage&v=v5dYE0CMmHQ#t=1828s
>> [2] https://github.com/ztellman/primitive-math
>> [3] https://github.com/ztellman/byte-streams
>>
>> --
>> --
>> You 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.
>
>



-- 
Karsten Schmidt
http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk

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

Re: Documentation / usage --- Array vs. Vector

[vrakade]

Very helpful, thanks for the explanation Mikera!


On Thursday, July 11, 2013 6:45:35 AM UTC-5, Mikera wrote:
>
> This is a heavily overloaded naming space - especially when you consider 
> code.matrix as well, and usage of these words in mathematical / scientific 
> communities. 
>
> Data scientists generally expect a "vector" to be a 1D collection of 
> numeric values, in the same sense that a "matrix" is a 2D collection of 
> numeric values. Sometimes "array" is also used as a generalisation of this 
> to mean N-Dimensional arrays (tensors and suchlike), e.g. in NumPy.
>
> I would avoid using "array" when you mean a Clojure Persistent Vector. 
> "array" is most likely referring to the host platform array type.
>
> Whenever there is a potential for confusion, I always find it is helpful 
> to add an extra word to resolve the ambiguity, e.g.
> - 1D vector / 2D matrix / ND array - when talking about scientific / 
> mathematical arrays (typically in a core.matrix context)
> - Persistent Vector / Clojure Vector - when talking about a Clojure 
> persistent vector data structure
> - Java Vector - when talking about the old java.util.Vector (not that 
> anyone should be using it nowadays, but still it's there)
> - Java array - when talking about an Object[], double[] etc. (this seems 
> to be the convention in Clojure docstrings for aget, alength etc.)
>
> Hope that adds some clarity
>
> On Thursday, 11 July 2013 02:48:38 UTC+1, vra...@gmail.com wrote:
>>
>> I see that Lists and Vectors are similar, but have different uses and for 
>> logical reasons. My question may be more about language of datatypes in 
>> Clojure than usage.
>>
>> Is it appropriate to use the term Array and Vector interchangeably when 
>> writing documentation about Clojure/EDN for non-Clojure programmers? (1-- 
>> "Vector" can be a difficult concept to "map" in English without context, 
>> for instance: "so it's a direction as well as a value?") (2-- Map (Clojure) 
>> / Dict (Python) / Tuple (Python) / Object (JavaScript) / Hash (Ruby), 
>> there's probably no resolution there.)
>>
>> I'm hesitant to use the word Array interchangeably with Vector in 
>> technical specs since Array occurs in Clojure at least as array-map and 
>> to-array, which aren't the same as a Vector. On the other hand, "Array" 
>> would seem especially interchangeable in documentation when talking about 
>> Clojure in context of ClojureScript, but descriptive language about Clojure 
>> should probably stay consistent regardless of the hosting programming 
>> language.
>>
>>

-- 
-- 
You 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: test.generative and data.generators

[Andreas Liljeqvist]

Hi, I have taken a look at simple-check.

Seems promising, but I have a few reservations:

I want to constrain the generation of two vectors to always have the same
number of elements as the other one.
>From what I can understand simple-check always uses the same max-size in a
property and have no current means to control the min length.

Its kind of hard to inspect what values I am actually generating since the
generator functions return non-runnable functions.
(without any scaffolding).

Really I think that data.generators would fit nicely into simple-check.
(I am not well-versed in the domain though...)

I like the general feel of simple-check and shrinking rocks.




On Mon, Jul 15, 2013 at 2:24 PM, Chas Emerick  wrote:

> Shrinking is a key requirement for me as well (1000-line-long data
> literals that produce a failure are better than nothing, but not quite as
> nice as its shrunken 40-character literal that provokes the same failure).
>  You might be interested in simple-check, which is a "Clojure
> property-based testing tool inspired by QuickCheck", and so its support for
> shrinking is essential:
>
> https://github.com/reiddraper/simple-check/
>
> I've been using it for some weeks now with good results.
>
> Cheers,
>
> - Chas
>
> On Jul 15, 2013, at 7:35 AM, Andreas Liljeqvist wrote:
>
> So, I find that what they provide are absolutely fantastic.
> But I don't see much action around them, are they considered maintained?
>
> Things on my wishlish:
> Shrinking of failing inputs.
> More readable reports.
> A couple of blogs or videos discussing them, I think that most people
> don't know what they are used for.
>
> --
> --
> You 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: test.generative and data.generators

[Chas Emerick]

Shrinking is a key requirement for me as well (1000-line-long data literals 
that produce a failure are better than nothing, but not quite as nice as its 
shrunken 40-character literal that provokes the same failure).  You might be 
interested in simple-check, which is a "Clojure property-based testing tool 
inspired by QuickCheck", and so its support for shrinking is essential:

https://github.com/reiddraper/simple-check/

I've been using it for some weeks now with good results.

Cheers,

- Chas

On Jul 15, 2013, at 7:35 AM, Andreas Liljeqvist wrote:

> So, I find that what they provide are absolutely fantastic.
> But I don't see much action around them, are they considered maintained?
> 
> Things on my wishlish: 
> Shrinking of failing inputs.
> More readable reports.
> A couple of blogs or videos discussing them, I think that most people don't 
> know what they are used for.
> 
> -- 
> -- 
> You 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.

test.generative and data.generators

[Andreas Liljeqvist]

So, I find that what they provide are absolutely fantastic.
But I don't see much action around them, are they considered maintained?

Things on my wishlish:
Shrinking of failing inputs.
More readable reports.
A couple of blogs or videos discussing them, I think that most people don't
know what they are used for.

-- 
-- 
You 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: Performance Patterns

[Frantisek Sodomka]

For my own needs, I wrote a macro 'timings' - see Timing expressions and 
comparing results:
https://groups.google.com/d/msg/clojure/o8pOLc6uxQQ/bui7sJ-F5_wJ
Code and examples are here:
https://gist.github.com/fsodomka/5890711

Your examples on my machine with Clojure 1.5.1:
(report
  (let [x 2 y [0 1 2 3 4]]
(timings 1000
  (remove #{x} y)
  (remove #(= % x) y)
  (remove #(== % x) y)
  (remove #(.equals % x) y

|
:expr |   :time | :ratio | :perc |
|+---++---|
|  (remove (fn* [p1__435#] (== p1__435# x)) y)   |  28.164219 |1.0 
  |  3.84 |
| (remove (fn* [p1__436#] (.equals p1__436# x)) y) |  28.310134 |   1.01  
|  3.86 |
|   (remove (fn* [p1__434#] (= p1__434# x)) y) |  29.038815 |   
1.03  |  3.96 |
|   (remove #{x} y) | 
733.326342 |  26.04 | 100.0 |

Using set is 26 times slower than any other way and I would probably pick 
== for number comparison.

(report
  (let [a (int-array 10)]
(timings 1000
  (aset a 1 2)
  (aset-int a 1 2

|:expr | :time | :ratio | :perc |
|--+---++---|
| (aset a 1 2) | 16.062221 |1.0 |  4.47 |
| (aset-int a 1 2) | 359.22866 |  22.36 | 100.0 |

aset-int is 22x slower than aset.

I would definitely find some resource on performance useful. On the other 
side, things change and many recommendations are not valid anymore:
http://gnuvince.wordpress.com/2009/05/11/clojure-performance-tips/
- destructuring is faster ;-)
- spliting (+ 2 4 5) to (+ 2 (+ 4 5)) isn't needed
- etc.
Performance changes with versions of Clojure.

Libraries to consider:
https://github.com/hugoduncan/criterium
https://github.com/davidsantiago/perforate

Frantisek

On Sunday, July 14, 2013 10:15:04 AM UTC+2, Marc Dzaebel wrote:
>
> I'm often in need of performance comparisons/recommendations about 
> different ways to code the same usecases. E.g.
>
> (time(let [x 2 y [0 1 2 3 4]] (dotimes [_ 1000] (remove *#{x}*y 
> ;~950 ms
> (time(let [x 2 y [0 1 2 3 4]] (dotimes [_ 1000] (remove *#(= % x)*y 
> ;~150 ms
>
> (time(let [a (int-array 10)]  (dotimes [_ 1000] (*aset *a 1 
> 2;~7 ms
> (time(let [a (int-array 10)]  (dotimes [_ 1000] (*aset-int *a 1 
> 2;~430 ms
>
> I'd recommend to gather such information at a central place in a more 
> systematic way. So I wonder:
>
>- where to place such information 
> (Wiki?)
>- whether this information is of use 
>- whether you have more recommendations regarding performance or the 
>form, advices are presented
>
> *Thanks, Marc*
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+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: Performance Patterns

[Alex Fowler]

I would definitely like to have such a reference because I often work with 
performance-critical code which I mostly delegate to Java. I would like to 
see it organized in categories for easier access, with commentaries to each 
case on why is this so (for example, i would suppose that aset-int should 
be faster in your example, but this is not true). As a recommendation, you 
could probably use some libraries like https://github.com/ptaoussanis/timbre to 
produce more sophisticated tests. Also check for existing materials like 
https://www.youtube.com/watch?v=ii-ajztxALM and such..

Also, afaik, most of Clojure community seem to not be very concerned with 
performance, so not everyone will be deeply interested, but I and someone 
else would definitely be.

On Sunday, July 14, 2013 12:15:04 PM UTC+4, Marc Dzaebel wrote:
>
> I'm often in need of performance comparisons/recommendations about 
> different ways to code the same usecases. E.g.
>
> (time(let [x 2 y [0 1 2 3 4]] (dotimes [_ 1000] (remove *#{x}*y 
> ;~950 ms
> (time(let [x 2 y [0 1 2 3 4]] (dotimes [_ 1000] (remove *#(= % x)*y 
> ;~150 ms
>
> (time(let [a (int-array 10)]  (dotimes [_ 1000] (*aset *a 1 
> 2;~7 ms
> (time(let [a (int-array 10)]  (dotimes [_ 1000] (*aset-int *a 1 
> 2;~430 ms
>
> I'd recommend to gather such information at a central place in a more 
> systematic way. So I wonder:
>
>- where to place such information 
> (Wiki?)
>- whether this information is of use 
>- whether you have more recommendations regarding performance or the 
>form, advices are presented
>
> *Thanks, Marc*
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+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: Making RPCs with Shoreleave

[Alex Fowler]

Did not work.. all that is strange since I've been following the manual 
step-by-step.. looks like the shoreleave's wrapper does not even create a 
http route for itself... any other ideas?

On Friday, July 12, 2013 7:14:42 AM UTC+4, Samrat Man Singh wrote:
>
> I think you need to (use projectname.ajax) in your projectname.handler 
> page. If I remember correctly, there's also a way to specify which 
> namespace your remote function is in.
>
> On Thursday, July 11, 2013 10:42:15 PM UTC+5:45, Alex Fowler wrote:
>>
>> Hi all, this is my first experience with Shoreleave and I'm trying to use 
>> it's RPC mechanism to perform AJAX tasks. However, on a call to a remote 
>> procedure, I get this:
>>
>> `
>>
>>1. POST http://localhost:8080/_shoreleave 404 (Not Found) 
>>cljs.js:25223 
>>   1. goog.net.XhrIo.sendcljs.js:25223
>>   2. xhr__delegatecljs.js:31416 
>>   3. xhrcljs.js:31423 
>>   4. 
>> remote_callback__delegatecljs.js:32504
>>   5. remote_callbackcljs.js:32515 
>>   6. load_storecljs.js:32745 
>>   7. 
>> mk__AMPERSAND__load_store__delegatecljs.js:32755
>>   8. 
>> mk__AMPERSAND__load_storecljs.js:32763
>>   9. example_storecljs.js:33341 
>>   10. simplecljs.js:33361 
>>   11. setup_guicljs.js:33962 
>>   12. setup_allcljs.js:33982 
>>   13. startupcljs.js:41166 
>>   14. onloadapp:2 
>>   
>> XHR ERROR: Not Found 
>> `
>>
>> What is wrong and how do I fix it? I have been following this tutorial: 
>> Shoreleave 
>> Tutorial 10 - Introducing 
>> Ajax
>>  my 
>> code (relevant parts) is this:
>>
>> Project.clj:
>> `
>> (defproject projectname "0.1.0-SNAPSHOT"
>>   :description "FIXME: write description"
>>   :url "http://example.com/FIXME";
>>   :dependencies [[org.clojure/clojure "1.5.1"]
>>  [lib-noir "0.6.3"]
>>  [compojure "1.2.0-SNAPSHOT"]
>>  [ring-server "0.2.8"]
>>  [clabango "0.5"]
>>  [hiccup "1.0.3"]
>>  [com.taoensso/timbre "2.1.2"]
>>  [com.taoensso/tower "1.7.1"]
>>  [markdown-clj "0.9.26"]
>>
>>  ; -- ajax
>>  [shoreleave "0.3.0"]
>>  [shoreleave/shoreleave-remote-ring "0.3.0"]
>>  [shoreleave/shoreleave-remote "0.3.0"]
>>  
>>  ; -- cljs
>>  [com.keminglabs/singult "0.1.6"]
>>  [enfocus "1.0.1"]
>>  [jayq "2.3.0"]
>>  ]
>>   :plugins [[lein-ring "0.8.5"]
>> [lein-cljsbuild "0.3.2"]]
>>   :hooks [leiningen.cljsbuild]
>>   :cljsbuild {
>>   :builds [{
>> :jar true
>> :source-paths ["src/family/webapp"]
>> :compiler {
>>:output-to 
>> "resources/public/js/cljs.js"
>>:optimizations :whitespace
>>:externs ["externs/jquery-1.9.js"]
>>:pretty-print true}}]}
>>   :ring {:handler projectname.handler/war-handler
>>  :initprojectname.handler/init
>>  :destroy projectname.handler/destroy}
>>   :profiles
>>   {:production {:ring {:open-browser? false
>>:stacktraces?  false
>>:auto-reload?  false}}
>>:dev {:dependencies [[ring-mock "0.1.5"]
>> [ring/ring-devel "1.1.8"]]}}
>>   :min-lein-version "2.0.0")
>> `
>>
>> Handler:
>> `
>> (ns projectname.handler
>>   (:use projectname.routes.home
>> compojure.core)
>>   (:require [noir.util.middleware :as middleware]
>> [compojure.route :as route]
>> [shoreleave.middleware.rpc :refer [wrap-rpc]]))
>>
>> (def all-routes [home-routes app-routes])
>>
>> (def app (-> all-routes
>>  middleware/app-handler
>>  wrap-rpc
>>  ;;add your middlewares here
>>  ))
>>
>> (def war-handler (middleware/war-handler app))
>> ` 
>>
>> Remote procedure declaration:
>> `
>> (ns projectname.ajax
>>   (:require [shoreleave.middleware.rpc :refer [defremote]]))
>>
>> (defremote my-remote-proc [some-arg] (println "remote call ok" some-arg) 
>> some-arg)
>> `
>>
>> Client side ClojureScript code:
>> `
>> (ns projectname.webapp.model.store
>>   (:require

Re: [ANN] CHP Web Framework Documentation Update

[Bastien]

Hi Kelker,

thanks for the explanations.  I will have a closer look to get
a better understanding.  It's nice to see the diversity of the
various approaches.

All best,

-- 
 Bastien

-- 
-- 
You 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: error (init-db)

[Tassilo Horn]

jayvandal  writes:

> CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
> init-db
> in this context, compiling:(NO_SOURCE_PATH:1) 
> This is the db.clg file
> ===
> (ns jimsweb.models.db
> (:require [clojure.java.jdbc :as sql]))

According to the namespace declaration, the file should be named
src/jimsweb/models/db.clj (if you use the standard leiningen project
setup).

> (def db 
> {:subprotocol "postgresql"
> :subname "//localhost/my_website"
> :user "admin"
> :password "pass"})
>
> (defn init-db []
> (try
> (sql/with-connection
> db
> (sql/create-table
> :users
> [:id "SERIAL"]
> [:handle "varchar(100)"]
> [:pass "varchar(100)"]))
> (catch Exception ex
> (.getMessage (.getNextException ex)
>
> jimsweb.server=> (init-db)

You are in a different namespace, so you have to require or use the
namespace defining init-db first.  So either

  (use 'jimsweb.models.db)
  (init-db)

or

  (require '[jimsweb.models.db :as db])
  (db/init-db)

Bye,
Tassilo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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.