Re: ANN Drip: A fast JVM launcher

[Tassilo Horn]

Omer Iqbal  writes:

Hi Omer,

> I tried the same on a ubuntu setup. Same issue as the rest I believe. :(
> time drip -cp ~/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar 
> clojure.main -e "(reduce + (range 100))"
> 4950
>
> real 0m1.065s
> user 0m1.420s
> sys 0m0.068s

Keep in mind that only subsequent invocations will be faster.  On my
system using drip 0.1.9 I get these times:

1. 2.20s user 0.09s system 96% cpu 2.374 total
2. 0.03s user 0.03s system 25% cpu 0.222 total
3. 0.03s user 0.02s system 20% cpu 0.261 total
4. 0.03s user 0.02s system 23% cpu 0.225 total

With drip 0.1.9 and leiningen 2.0.0, now the leiningen integration also
seems to work properly:

--8<---cut here---start->8---
[horn@thinkpad][0][:-)][10181](git)-[master] 
[~/Repos/clj-test] % time lein version
Leiningen 2.0.0 on Java 1.7.0_09 OpenJDK 64-Bit Server VM
lein version  3.31s user 0.17s system 95% cpu 3.631 total
[horn@thinkpad][0][:-)][10182](git)-[master] 
[~/Repos/clj-test] % time lein version
Leiningen 2.0.0 on Java 1.7.0_09 OpenJDK 64-Bit Server VM
lein version  0.05s user 0.06s system 8% cpu 1.298 total
[horn@thinkpad][0][:-)][10182](git)-[master] 
[~/Repos/clj-test] % time lein version
Leiningen 2.0.0 on Java 1.7.0_09 OpenJDK 64-Bit Server VM
lein version  0.04s user 0.03s system 5% cpu 1.370 total
[horn@thinkpad][0][:-)][10182](git)-[master] 
[~/Repos/clj-test] % time lein version
Leiningen 2.0.0 on Java 1.7.0_09 OpenJDK 64-Bit Server VM
lein version  0.04s user 0.02s system 4% cpu 1.281 total
--8<---cut here---end--->8---

And "drip ps" only shows 1 jvm process.  Before, I had one process per
lein invocation.

Great!

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

ANN: New ClojureScript Google group

[Andy Fingerhut]

You should be able to join the new group at this link:

https://groups.google.com/forum/?fromgroups#!forum/clojurescript

If you have any trouble with that link, just go to http://groups.google.com and 
search for ClojureScript.  I haven't created a Google group before, so please 
try to bear with me if we have some early difficulties with messages flowing 
smoothly.


Why a separate group for ClojureScript?

There are people who are more focused on using ClojureScript specifically, and 
less interested in Clojure on other platforms such as the JVM, CLR, etc.  The 
tools and development workflow are enough different that discussing 
ClojureScript-specific issues in its own group makes sense.  There are 
discussions appropriate for the Clojure group, e.g. bugs or performance issues 
related to JVMs or parallelism, that are not of interest to developers focused 
on ClojureScript.

There are also certainly many topics relevant to both Clojure and ClojureScript 
groups.  Many people will want to join and participate in both.  It is 
perfectly fine to post messages to the ClojureScript group that would be 
relevant on the Clojure group.  For example, "I tried this code snippet and it 
doesn't work for me", even though the code in question would work the same way 
in both Clojure/JVM and ClojureScript.

In summary:

If your question is specific to ClojureScript, it is welcome on the 
ClojureScript group.

If it is *specific* to Clojure/JVM, Clojure/CLR, etc., then it is not welcome 
on the ClojureScript group.  Please send it to the Clojure group instead.

If it is not specific to any one flavor of Clojure, but you prefer to send it 
to the ClojureScript group, go right ahead, but realize that your audience may 
be smaller than if you send it to the Clojure group.

Andy Fingerhut

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

Re: Call for volunteers to help moderate a ClojureScript Google group

[Wes Freeman]

This is great. Can you guys put [ClojureScript] in the email subject like
most google groups do? Wouldn't mind if they put [Clojure] in the clojure
emails, either.

Wes

On Thu, Jan 24, 2013 at 1:22 AM, kinleyd  wrote:

> I see a number of volunteers already; include me if you need any more.
>
> +1 to the proposal to have an independent ClojureScript group.
>
>
> On Thursday, January 24, 2013 8:42:22 AM UTC+6, solussd wrote:
>
>> I'll help!
>>
>> ---
>> Joseph Smith
>> j...@uwcreations.com
>> @solussd
>>
>>
>> On Jan 23, 2013, at 8:16 PM, Brandon Bloom  wrote:
>>
>> /me steps forward
>>
>> On Wednesday, January 23, 2013 10:53:34 AM UTC-8, Andy Fingerhut wrote:
>>>
>>> An interest was expressed by a few in having a separate ClojureScript
>>> mailing list.
>>>
>>> If it is a Google group, that requires moderating messages sent to the
>>> group, via manual approval.  I suspect early on there will be many people
>>> posting to the group for the first time that have long worked with
>>> ClojureScript, and you'll know them, and you can approve that and all
>>> future messages from them, but every time a new sender sends their first
>>> few messages to the group, a person needs to receive an email, click a
>>> link, read the message to verify it is on topic, and click a couple of
>>> buttons to approve it or reject it.
>>>
>>> Anyone interested in helping out with that?  It is easier if the load
>>> can be spread across multiple people.  If someone else approves a message,
>>> you still might get an email about a message needing approval, but the last
>>> couple of steps above are then unnecessary.
>>>
>>> Andy
>>>
>>>  --
>> --
>> 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 post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>
>

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

Re: Call for volunteers to help moderate a ClojureScript Google group

[kinleyd]

I see a number of volunteers already; include me if you need any more.

+1 to the proposal to have an independent ClojureScript group.

On Thursday, January 24, 2013 8:42:22 AM UTC+6, solussd wrote:
>
> I'll help!
>
> ---
> Joseph Smith
> j...@uwcreations.com 
> @solussd
>
>
> On Jan 23, 2013, at 8:16 PM, Brandon Bloom > 
> wrote:
>
> /me steps forward
>
> On Wednesday, January 23, 2013 10:53:34 AM UTC-8, Andy Fingerhut wrote:
>>
>> An interest was expressed by a few in having a separate ClojureScript 
>> mailing list. 
>>
>> If it is a Google group, that requires moderating messages sent to the 
>> group, via manual approval.  I suspect early on there will be many people 
>> posting to the group for the first time that have long worked with 
>> ClojureScript, and you'll know them, and you can approve that and all 
>> future messages from them, but every time a new sender sends their first 
>> few messages to the group, a person needs to receive an email, click a 
>> link, read the message to verify it is on topic, and click a couple of 
>> buttons to approve it or reject it. 
>>
>> Anyone interested in helping out with that?  It is easier if the load can 
>> be spread across multiple people.  If someone else approves a message, you 
>> still might get an email about a message needing approval, but the last 
>> couple of steps above are then unnecessary. 
>>
>> Andy 
>>
>>  -- 
> -- 
> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN Drip: A fast JVM launcher

[Omer Iqbal]

I tried the same on a ubuntu setup. Same issue as the rest I believe. :(
time drip -cp ~/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar 
clojure.main -e "(reduce + (range 100))"
4950

real 0m1.065s
user 0m1.420s
sys 0m0.068s

time java -cp ~/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar 
clojure.main -e "(reduce + (range 100))"
d4950

real 0m1.063s
user 0m1.400s
sys 0m0.160s



On Monday, September 17, 2012 2:56:43 AM UTC+8, Denis Labaye wrote:
>
> After the bug fix on ubuntu: 
>
> denis@zeus:~/.m2$ time drip -cp 
> ./repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar clojure.main -e 
> "(reduce + (range 100))"
> 4950
>
> real0m0.123s
> user0m0.032s
> sys 0m0.016s
> denis@zeus:~/.m2$ time java -cp 
> ./repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar clojure.main -e 
> "(reduce + (range 100))"
> 4950
>
> real0m0.632s
> user0m0.828s
> sys 0m0.080s
>
>
> That's very very cool !
>
> On Fri, Sep 14, 2012 at 6:59 AM, Jack Moffitt 
> > wrote:
>
>> >> I did just that, but I don't get any speedup with leiningen.  All I can
>> >> see is that after every leiningen command, "drip ps" shows one process
>> >> more.  For example:
>> >
>> > This is also happening for me. Is there some way to configure drip to
>> > ignore certain arguments?
>>
>> I added a way to specify options to ignore, which fixes the problem of
>> it launching multiple JVMs. Unfortunately, lein never works after the
>> first invocation; I'm guessing it's not happy about the trampoline
>> file disappearing and not coming back after the first invocation.
>>
>> Here's the non-working patch if anyone wants to try:
>> https://gist.github.com/3719891
>>
>> Any ideas?
>>
>> jack.
>>
>> --
>> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Help with Clojurescript + DOM Manipulation

[Evan Mezeske]

Oops, I should never type code straight into an email window, without 
REPLing it first...  X_X

I left in the "links" argument to map.  This is probably closer to what I 
meant:

(defn listen-to
  [links]
  (doseq [link links]
(.log js/console link)))

On Wednesday, January 23, 2013 8:39:51 PM UTC-8, Evan Mezeske wrote:
>
> When you want to iterate over things and perform a side-effecty action for 
> each one (logging is a side effect, as would be adding event listeners to 
> DOM nodes, changing CSS classes, etc), doseq is usually the clearest thing 
> to do:
>
> (defn listen-to
>   [links]
>   (doseq [link links]
> (.log js/console link) links))
>
> You almost never want to use map for side effects.  A good rule of thumb 
> is that if you don't use the return value from map, you probably want doseq 
> instead.
>

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

Re: Help with Clojurescript + DOM Manipulation

[Evan Mezeske]

When you want to iterate over things and perform a side-effecty action for 
each one (logging is a side effect, as would be adding event listeners to 
DOM nodes, changing CSS classes, etc), doseq is usually the clearest thing 
to do:

(defn listen-to
  [links]
  (doseq [link links]
(.log js/console link) links))

You almost never want to use map for side effects.  A good rule of thumb is 
that if you don't use the return value from map, you probably want doseq 
instead.

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

Re: Decoupling documentation from code?

[Korny Sietsma]

Thanks for that explanation - I hadn't fully looked at codeq and how it
works - I can see that it might make management of external documentation
an easier task; especially for a codebase that changes slowly.

- Korny


On 22 January 2013 18:39, Rich Morin  wrote:

> On Jan 21, 2013, at 23:15, Korny Sietsma wrote:
> > The flip side, of course, is that having documentation separate from
> > code often leads to the documentation becoming out of sync with thecode.
> >
> > What happens when someone renames or moves some code,  but doesn't also
> > move the docs?  What happens if they change the implementation?  Will
> > people remember that every code change might potentially also require a
> > change to documentation, stored somewhere else, and potentially
> versioned independently?
>
> [ Andy addressed this question, but I have my own spin on it, so... ]
>
> Keeping the docs with the code helps to handle this problem, because it
> makes it easier for a programmer to spot inconsistencies between the docs
> and the adjacent code.  However, we can't force the programmer to look at
> the docs, let alone keep them up to date.
>
> In any case, putting the docs in with the code causes the other problems
> we've discussed (eg, bulking up the code base, making changes difficult,
> getting in the way of helpful markup, internationalization issues).  So
> the real question is whether Codeq offers a way to keep the docs current.
>
> I believe that it does, in a very natural fashion.  Codeq tracks "code
> quanta" (ie, meaningful subsets of files such as classes, methods, and
> functions).  If Rich Hickey changes either the code or the comments in
> the foo function, Codeq will soon know about the changes.  It can then
> send an alert to anyone who is interested in making sure the external
> documentation for the function stays current.
>
> Given that Rich won't change any given function very often, this isn't
> likely to result in a large number of alerts, updates, etc.  I agree that
> this isn't a perfect solution, but I think it is probably quite workable.
>
> -r
>
>  --
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume r...@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> --
> 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
>



-- 
Kornelis Sietsma  korny at my surname dot com http://korny.info
"We do not quit playing because we grow old, we grow old because we quit
playing" - O.W. Holmes

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

Re: emacs - how to wean me off the family of Java IDEs

[Korny Sietsma]

On 17 January 2013 17:26, Sean Corfield  wrote:

> Error: Symbol's function definition is void: make-local-hook


bump - anyone know a workaround for this - I was interested in sr-speedbar,
especially for editing over an ssh session, but it doesn't seem to work
with emacs 24?

- Korny


-- 
Kornelis Sietsma  korny at my surname dot com http://korny.info
"We do not quit playing because we grow old, we grow old because we quit
playing" - O.W. Holmes

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

Re: Call for volunteers to help moderate a ClojureScript Google group

[Joseph Smith]

I'll help!

---
Joseph Smith
j...@uwcreations.com
@solussd


On Jan 23, 2013, at 8:16 PM, Brandon Bloom  wrote:

> /me steps forward
> 
> On Wednesday, January 23, 2013 10:53:34 AM UTC-8, Andy Fingerhut wrote:
>> 
>> An interest was expressed by a few in having a separate ClojureScript 
>> mailing list. 
>> 
>> If it is a Google group, that requires moderating messages sent to the 
>> group, via manual approval.  I suspect early on there will be many people 
>> posting to the group for the first time that have long worked with 
>> ClojureScript, and you'll know them, and you can approve that and all future 
>> messages from them, but every time a new sender sends their first few 
>> messages to the group, a person needs to receive an email, click a link, 
>> read the message to verify it is on topic, and click a couple of buttons to 
>> approve it or reject it. 
>> 
>> Anyone interested in helping out with that?  It is easier if the load can be 
>> spread across multiple people.  If someone else approves a message, you 
>> still might get an email about a message needing approval, but the last 
>> couple of steps above are then unnecessary. 
>> 
>> Andy 
>> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>  
>  

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

Re: Help with Clojurescript + DOM Manipulation

[Dave Sann]

map is lazy so your console log is never done.

use (doall ...)

Dave




On Thursday, 24 January 2013 12:38:37 UTC+11, Ari wrote:
>
> Hi,
>
> The following clojurescript code is *supposed* to identify all anchor tags 
> and print them (originally, I was trying to attach listeners and 
> callbacks); unfortunately, I can't get it to work. Confusingly, there are 
> no compilation or runtime errors. Anyone see what could be wrong? Thanks. 
>
> Note: Code uses jayq 2.0.0 & lein-cljsbuild 0.2.10
>
> --CLJS--
>
> (ns myapp.example
> (:use [jayq.core :only [$]])
> (:use-macros [jayq.macros :only [ready]]))
>
> (def links ($ :a))
>
> (defn listen-to
>   [links]
>   (map 
> (fn [link] (.log js/console link) links)))
>
> (ready (listen-to links))
>
> --HTML--
>
> 
> 
> 
> 
> 
> 
> 
> First
> Second
> Third
> 
> 
> 
>

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

Re: Call for volunteers to help moderate a ClojureScript Google group

[Brandon Bloom]

/me steps forward

On Wednesday, January 23, 2013 10:53:34 AM UTC-8, Andy Fingerhut wrote:
>
> An interest was expressed by a few in having a separate ClojureScript 
> mailing list. 
>
> If it is a Google group, that requires moderating messages sent to the 
> group, via manual approval.  I suspect early on there will be many people 
> posting to the group for the first time that have long worked with 
> ClojureScript, and you'll know them, and you can approve that and all 
> future messages from them, but every time a new sender sends their first 
> few messages to the group, a person needs to receive an email, click a 
> link, read the message to verify it is on topic, and click a couple of 
> buttons to approve it or reject it. 
>
> Anyone interested in helping out with that?  It is easier if the load can 
> be spread across multiple people.  If someone else approves a message, you 
> still might get an email about a message needing approval, but the last 
> couple of steps above are then unnecessary. 
>
> Andy 
>
>

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

[ANN] 12th modern-cljs tutorial

[Mimmo Cosenza]

Hi,
here is the 12th modern-cljs tutorial. 

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

In this short tutorial, whose title is "The highest and the deepest layers", I 
covered the HTML5 highest layer and the serve-side deepest layer of the 
progressive enhancement strategy in building web applications with 
clojurescript on the client side and clojure on the server side. 

In the next couple of tutorials I should be able to cover 

* the security issues (using friend) 
* the pure html template system for the server-side (enliven)
* the pure html template system for the client-side (enfocus)
* complete the login example using all the layers of progressive enhancement 
strategy (html, js, ajax and server-only)

Many thanks to Federico Boniardi and Francesco Agozzino for their efforts in 
following my crazy ideas about experimenting those stuff in the mean time they 
are learning the language.  

It will take me a couple of weeks of my spare time to complete the above stuff. 
Hope it will helps someone. After that I'm open to suggestion from the 
community on which topic to take care of in the next tutorials. 

My idea is to try to unify the form validation on both sides to a web 
applications, probably by pushing Federico and Francesco in starting defining a 
validation DSL by using macros which generate both client and server side 
validation code to eliminate code duplication.

My best
mimmo
 


   


 

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

Help with Clojurescript + DOM Manipulation

[Ari]

Hi,

The following clojurescript code is *supposed* to identify all anchor tags 
and print them (originally, I was trying to attach listeners and 
callbacks); unfortunately, I can't get it to work. Confusingly, there are 
no compilation or runtime errors. Anyone see what could be wrong? Thanks. 

Note: Code uses jayq 2.0.0 & lein-cljsbuild 0.2.10

--CLJS--

(ns myapp.example
(:use [jayq.core :only [$]])
(:use-macros [jayq.macros :only [ready]]))

(def links ($ :a))

(defn listen-to
  [links]
  (map 
(fn [link] (.log js/console link) links)))

(ready (listen-to links))

--HTML--








First
Second
Third




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

Call for volunteers to help moderate a ClojureScript Google group

[Edward Tsech]

Glad to help.

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

Re: Proposal: Suppressing tracebacks from clojure.core

[Andreas Liljeqvist]

I have found that I can get a bit nicer stacktraces by installing
clj-stacktrace.
Should probably do my duty and do a documentation pullrequest to nrepl.el

Thanks


On Tue, Jan 22, 2013 at 8:10 PM, David Nolen  wrote:

> Better tracebacks have been available in Clojure since 1.3:
>
> user=> (require '[clojure.repl :as r])
> user=> (r/pst *e)
>
> e* is the last exception.
>
> It's up to the tools to support it. That said allowing customized
> tracebacks for tools could be improved - but no one's ever submitted any
> serious patches along those lines to my knowledge.
>
> David
>
>
> On Sat, Jan 19, 2013 at 2:48 PM,  wrote:
>
>> Hi all
>>
>> I've been thinking about how long tracebacks get for pure Clojure errors,
>> and it would be really nice if we could hide the Java traceback from the
>> compiler when it's not relevant. When there's no Java interop, it's not
>> useful. I can't see any case where we want the tracebacks from the compiler
>> referencing clojure.core.
>>
>> I threw together a patch -- I'm sure a seasoned Java developer would find
>> a nicer way to do this.
>>
>> Here's how the tracebacks look at the moment on trunk:
>>
>> $ more dodgy-map.clj
>> (defn dodgy-map []
>>   {:1 :2 :3})
>> $ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main
>> dodgy-map.clj
>> Exception in thread "main" java.lang.RuntimeException: Map literal must
>> contain an even number of forms,
>> compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13)
>> at clojure.lang.Compiler.load(Compiler.java:7069)
>> at clojure.lang.Compiler.loadFile(Compiler.java:7019)
>> at clojure.main$load_script.invoke(main.clj:286)
>> at clojure.main$script_opt.invoke(main.clj:348)
>> at clojure.main$main$fn__6676.invoke(main.clj:432)
>> at clojure.main$main.doInvoke(main.clj:429)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.lang.Var.invoke(Var.java:415)
>> at clojure.lang.AFn.applyToHelper(AFn.java:161)
>> at clojure.lang.Var.applyTo(Var.java:532)
>> at clojure.main.main(main.java:37)
>> Caused by: java.lang.RuntimeException: Map literal must contain an even
>> number of forms
>> at clojure.lang.Util.runtimeException(Util.java:219)
>> at clojure.lang.LispReader$MapReader.invoke(LispReader.java:1090)
>> at clojure.lang.LispReader.readDelimitedList(LispReader.java:1145)
>> at clojure.lang.LispReader$ListReader.invoke(LispReader.java:979)
>> at clojure.lang.LispReader.read(LispReader.java:182)
>> at clojure.lang.Compiler.load(Compiler.java:7057)
>> ... 10 more
>>
>> If I change src/jvm/clojure/main.java to:
>>
>> public static void main(String[] args) {
>> REQUIRE.invoke(CLOJURE_MAIN);
>> try {
>> MAIN.applyTo(RT.seq(args));
>> } catch (Compiler.CompilerException e) {
>> System.out.println(e.toString());
>> }
>> }
>>
>> Then my traceback is simplified to:
>>
>> $ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main
>> dodgy-map.clj
>> java.lang.RuntimeException: Map literal must contain an even number of
>> forms, compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13)
>>
>> This also means that name errors have shorter tracebacks:
>>
>> $ more i-dont-exist.clj
>> (defn no-such-variable []
>>   i-dont-exist)
>>
>> $ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main
>> i-dont-exist.clj
>> java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in
>> this context, compiling:(/home/wilfred/src/clojure/i-dont-exist.clj:1:1)
>>
>> Of course, there's huge scope for improvement. The reference to
>> "java.lang.RuntimeException" isn't useful. It would be nice to split
>> CompilerException into more specific exception classes (SyntaxError,
>> NameError etc) so we can print different errors at the top level. This
>> simple patch also changes the exit code of the compiler, which is
>> undesirable. Finally, it'd need some new unit tests.
>>
>> Anyway, is this something that is worth opening an issue for? I'd love to
>> hear your thoughts.
>>
>> Wilfred
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
-- 
You received this message because you are subscribed to the Google

Re: Call for volunteers to help moderate a ClojureScript Google group

[Frank Siebenlist]

Happy to help - FrankS.

On Jan 23, 2013, at 10:53 AM, Andy Fingerhut  wrote:

> An interest was expressed by a few in having a separate ClojureScript mailing 
> list.
> 
> If it is a Google group, that requires moderating messages sent to the group, 
> via manual approval.  I suspect early on there will be many people posting to 
> the group for the first time that have long worked with ClojureScript, and 
> you'll know them, and you can approve that and all future messages from them, 
> but every time a new sender sends their first few messages to the group, a 
> person needs to receive an email, click a link, read the message to verify it 
> is on topic, and click a couple of buttons to approve it or reject it.
> 
> Anyone interested in helping out with that?  It is easier if the load can be 
> spread across multiple people.  If someone else approves a message, you still 
> might get an email about a message needing approval, but the last couple of 
> steps above are then unnecessary.
> 
> Andy
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> 
> 

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

Re: ANN: clj-spark - A Clojure wrapper for the Spark API

[Mark Hamstra]

I certainly understand the exploration and learning motivation -- I did 
much the same thing.  At this point, I wouldn't consider either of our 
efforts to be a complete or fully usable Clojure API for Spark, but there 
are definitely ideas worth looking at in both if anyone gets to the point 
of attempting to write a complete and robust API -- which I won't be doing 
in the immediate future.

I'm not sure that I am following you on Cascading and Spark.  Are you 
saying that you want to use the Cascading API to express workflows which 
will then be transformed into a DAG of Spark stages and run as a Spark job? 
 I don't think that I agree with that strategy.  While I can get behind 
various higher-level abstractions to express Spark jobs (which is what 
Shark is doing, after all), I don't find Cascading's API to be terribly 
elegant: When writing a Spark job in Scala, I just don't find myself think 
that it would be a whole lot easier if I could write the job in Cascading. 
 Part of that is because I'm not fluent in Cascading, but from what I have 
seen and done with it, I don't lust after Cascading.  The other problem I 
have with the Cascading-to-Spark strategy is that Cascading has been 
designed and implemented very much with Hadoop in mind, but Spark can do 
quite a bit more that Hadoop cannot.  I don't think that Cascading itself 
would be a good fit for expressing Spark jobs that can really leverage the 
advantages that Spark has over Hadoop.  None of that is meant to say that 
Cascading isn't a step forward over writing jobs using Hadoop's Java API; 
but at this point I just don't see Cascading as a step forward for writing 
Spark jobs.

Anyway, here's one of the early problems I ran into when trying to follow 
your README:

$ lein --version
Leiningen 2.0.0 on Java 1.7.0_09 OpenJDK 64-Bit Server VM
$ lein deps
$ lein compile
Compiling clj-spark.spark.functions
Compiling clj-spark.api
Compiling clj-spark.util
Compiling clj-spark.examples.query
$ lein run
2013-01-23 11:17:10,436  WARN api:1 - JavaSparkContext local Simple Job 
/home/mark/Desktop/Scala/Spark/0.6 [] {}
Exception in thread "main" java.lang.ClassCastException: 
clojure.lang.PersistentVector cannot be cast to java.lang.CharSequence
at clojure.string$split.invoke(string.clj:174)
at clj_spark.api$spark_context.doInvoke(api.clj:18)
at clojure.lang.RestFn.invoke(RestFn.java:805)
at clj_spark.examples.query$_main.doInvoke(query.clj:33)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:411)
at user$eval22.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6501)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$eval_opt.invoke(main.clj:297)
at clojure.main$initialize.invoke(main.clj:316)
at clojure.main$null_opt.invoke(main.clj:349)
at clojure.main$main.doInvoke(main.clj:427)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
zsh: exit 1 lein run

On Wednesday, January 23, 2013 7:02:43 AM UTC-8, Marc Limotte wrote:
>
> Hi Mark.
>
> This was very much exploratory work, and a lot of it was just about 
> learning the Spark paradigms.  That being said, merging for future work 
> seems appropriate, but it's not clear yet if I will be pursuing this work 
> further.  Might wind up using Shark instead [would love to use Cascading 
> over Spark as well, if it existed].
>
> I'd like to know what issue you had in getting the code/examples to work? 
>  I had a couple of people try this out from scratch on clean systems and it 
> did work for them.
>
> Serializing the functions is necessary as far as I can tell.  It would not 
> work for me without this.  As far as I can tell (this is largely 
> guesswork), the problem is that each time the anonymous function is 
> evaluated on a different JVM it gets a different class name (e.g. fn_123). 
>  There is high likelihood that the name assigned on the master is not the 
> same as the name on the task JVMs, so you wind up with a 
> ClassNotFoundException.
>
> I don't know why this would work for you.  If you have any insight on 
> this, I would love to hear it?
>
> Marc
>
> On Tue, Jan 22, 2013 at 8:09 AM, Mark Hamstra 
> > wrote:
>
>> Hmmm... a lot of duplicated work.  Sorry I didn't get my stuff in a more 
>> usable form for you, but I wasn't aware that anybody was even interested in 
>> it.  I've got some stuff that I want to rework a little, and I'm still 
>> thinking through the best way to integrate with the new reducers code in 
>> Clojure, but I haven't had the right combination of time and motivation to 
>> finish off what I started and document it.  At any rate, we should work at 
>> merging the two efforts, since I don't see any need for duplicate APIs.
>>
>> In taking a quick first 

Re: Call for volunteers to help moderate a ClojureScript Google group

[Christopher Meiklejohn]

I'd be up for it as well. 

- Chris 

-- 
Christopher Meiklejohn


On Wednesday, January 23, 2013 at 2:10 PM, Robert Pitts wrote:

> I'd be up for helping.
> 
> On Wednesday, January 23, 2013 1:53:34 PM UTC-5, Andy Fingerhut wrote:
> > An interest was expressed by a few in having a separate ClojureScript 
> > mailing list. 
> > 
> > If it is a Google group, that requires moderating messages sent to the 
> > group, via manual approval. I suspect early on there will be many people 
> > posting to the group for the first time that have long worked with 
> > ClojureScript, and you'll know them, and you can approve that and all 
> > future messages from them, but every time a new sender sends their first 
> > few messages to the group, a person needs to receive an email, click a 
> > link, read the message to verify it is on topic, and click a couple of 
> > buttons to approve it or reject it. 
> > 
> > Anyone interested in helping out with that? It is easier if the load can be 
> > spread across multiple people. If someone else approves a message, you 
> > still might get an email about a message needing approval, but the last 
> > couple of steps above are then unnecessary. 
> > 
> > Andy 
> -- 
> -- 
> 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 
> (mailto: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 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> 
> 



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

Re: Call for volunteers to help moderate a ClojureScript Google group

[Robert Pitts]

I'd be up for helping.

On Wednesday, January 23, 2013 1:53:34 PM UTC-5, Andy Fingerhut wrote:
>
> An interest was expressed by a few in having a separate ClojureScript 
> mailing list. 
>
> If it is a Google group, that requires moderating messages sent to the 
> group, via manual approval.  I suspect early on there will be many people 
> posting to the group for the first time that have long worked with 
> ClojureScript, and you'll know them, and you can approve that and all 
> future messages from them, but every time a new sender sends their first 
> few messages to the group, a person needs to receive an email, click a 
> link, read the message to verify it is on topic, and click a couple of 
> buttons to approve it or reject it. 
>
> Anyone interested in helping out with that?  It is easier if the load can 
> be spread across multiple people.  If someone else approves a message, you 
> still might get an email about a message needing approval, but the last 
> couple of steps above are then unnecessary. 
>
> Andy 
>
>

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

Re: ANN Drip: A fast JVM launcher

[Jack Moffitt]

There was a bug that prevented drip from working with preview10.
That's been fixed. Then for a while the drip JAR was distributed as
compiled by Java 7, which failed silently when run on older JVMs.
That's also been fixed now.

I've been using it successfully for the last few days now.

So if you get Lein 2.0.0 and grab the latest drip it should just work.
You can also try running it from a checkout, which also is very easy
and works (and it worked even when the Java 7 compiled ones were in
the distributed version).

jack.

On Wed, Jan 23, 2013 at 11:20 AM, Chris Altman  wrote:
> I'm getting the same behavior.  Has there been any action on this?
>
>
> On Monday, September 17, 2012 11:12:20 AM UTC-4, Gary Johnson wrote:
>>
>> I'm getting the same multiple JVM starting behavior on Arch Linux using
>> lein 2.0.0-preview10 and drip 0.1.7. Hmm...
>>
>>
>> On Monday, September 17, 2012 2:57:00 AM UTC-4, Tassilo Horn wrote:
>>>
>>> Denis Labaye  writes:
>>>
>>> >> I am still seeing a new JVM being started every drip run. I am
>>> >> testing Drip 0.1.7 with Lein 2 by running lein test 5 times in a row
>>> >> with LEIN_JAVA_CMD=drip in ~/.lein/leinrc, OS X, JDK 7.
>>> >
>>> > No multiple JVM started for me (at least in my trivial tests)
>>> >
>>> > drip 0.1.7
>>>
>>> Same versions here, but after running just "lein" thrice in a project, I
>>> still have 3 JVMs in "drip ps".  It's the same when I run another lein
>>> command, e.g., "lein jar" or "lein test".
>>>
>>> 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 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

Call for volunteers to help moderate a ClojureScript Google group

[Andy Fingerhut]

An interest was expressed by a few in having a separate ClojureScript mailing 
list.

If it is a Google group, that requires moderating messages sent to the group, 
via manual approval.  I suspect early on there will be many people posting to 
the group for the first time that have long worked with ClojureScript, and 
you'll know them, and you can approve that and all future messages from them, 
but every time a new sender sends their first few messages to the group, a 
person needs to receive an email, click a link, read the message to verify it 
is on topic, and click a couple of buttons to approve it or reject it.

Anyone interested in helping out with that?  It is easier if the load can be 
spread across multiple people.  If someone else approves a message, you still 
might get an email about a message needing approval, but the last couple of 
steps above are then unnecessary.

Andy

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

Re: ANN Drip: A fast JVM launcher

[Chris Altman]

I'm getting the same behavior.  Has there been any action on this?  

On Monday, September 17, 2012 11:12:20 AM UTC-4, Gary Johnson wrote:
>
> I'm getting the same multiple JVM starting behavior on Arch Linux using 
> lein 2.0.0-preview10 and drip 0.1.7. Hmm...
>
>
> On Monday, September 17, 2012 2:57:00 AM UTC-4, Tassilo Horn wrote:
>>
>> Denis Labaye  writes: 
>>
>> >> I am still seeing a new JVM being started every drip run. I am 
>> >> testing Drip 0.1.7 with Lein 2 by running lein test 5 times in a row 
>> >> with LEIN_JAVA_CMD=drip in ~/.lein/leinrc, OS X, JDK 7. 
>> > 
>> > No multiple JVM started for me (at least in my trivial tests) 
>> > 
>> > drip 0.1.7 
>>
>> Same versions here, but after running just "lein" thrice in a project, I 
>> still have 3 JVMs in "drip ps".  It's the same when I run another lein 
>> command, e.g., "lein jar" or "lein test". 
>>
>> 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

Re: Heroku & Boot Times

[Phil Hagelberg]

Scott Parker writes:

> Jeroen - thanks for the advice. Yeah, SNAPSHOTS in prod is a poor practice
> anyway, this gives me a good incentive to find them and kill them.

Yeah, doing any dependency resolution at process launch time is brutal
in production; apart from boot time issues it introduces variability and
counteracts the benefits of the explicit slug compilation process. You
can usually avoid this by just freezing your snapshots, but sometimes
problems can still arise transitively, so I highly recommend putting
`:offline true` into your production profile. This will prevent them
from being checked during boot even if you still have snapshots in
project.clj. I'll try to make sure this is clearer in devcenter docs.

Happy to help debug further if there are boot issues beyond simply
dependency resolution at launch; just let me know.

-Phil

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

Re: Heroku & Boot Times

[Sean Corfield]

On Wed, Jan 23, 2013 at 9:42 AM, Scott Parker  wrote:
> Static files on boot... dang. When I was first investigating our slow boot
> time I swear I checked Enlive, but another quick glance at the source
> indicates it's almost certainly a contributor. Expletive! I will start
> capturing some metrics on how much time we're spending loading HTML
> templates at init. We're not loading a godawful number of separate HTML
> files, so I'd like to avoid a bunch of delays throughout my views if
> possible.

FWIW, what I do with Enlive is to cache templates in an atom (as a map
from names to html-resource call results) so we only load each
template once - unless we force the app to reload.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: Heroku & Boot Times

[Weber, Martin S]

Obviously it helps to make sure the dependencies you are using are named with 
the exact snapshot version.
The biggest time-saver for me though is convincing lein to not do the 
dependency dance all the time. I'm surprised though to see that you are 
dependency checking at all though. Shouldn't you just create a jar and then 
call directly into that?

Fun observation about reducing lein startup times though:

So I add my deps to the project.clj; use a repo path that is inside the project 
(so it's easier to DCVS it, key :local-repo ); lein deps; run my test cases 
(lein deps sadly does not pull all potentially used dependencies, gotta 
exercise it some); then add ":offline? true" to the project.clj.

Difference on my old laptop is lein repl: ~20 secs to start with :offline? 
True; without it, it takes 45-50 seconds instead. That's a rough x 2 on a  dual 
core ht 3 Ghz w/ 3G RAM (it's still taking about factor 200 too long, but hey! 
Halved it already! On my work laptop though, the difference is 2 or 4 seconds. 
Not that big of a deal).

Regards,
-Martin

From: Jeroen van Dijk 
mailto:jeroentjevand...@gmail.com>>
Reply-To: "clojure@googlegroups.com" 
mailto:clojure@googlegroups.com>>
Date: Wed, 23 Jan 2013 12:19:06 -0500
To: "clojure@googlegroups.com" 
mailto:clojure@googlegroups.com>>
Subject: Re: Heroku & Boot Times

Hi Scott,

We had some issues as well. SNAPSHOTS are likely to be an issue because they 
are re-checked at least once a day. So if your app needs a restart this will be 
re-checked and might slow down boot time. We also had problems due to this in 
combination with failing maven mirrors. It is probably best to just not use 
SNAPSHOT versions in production.

Another thing that can have impact on boot time is the reading of static files 
on booting. We solved this by using '(def resource (delay (expensive-task ))) 
and @resource to post-pone this execution for after booting.

We also use this feature https://devcenter.heroku.com/articles/labs-preboot/ to 
minimize possible downtime between deploys (not sure if this works for restarts 
as well)

On top of that, we always have a minimum of two dynos for redundancy if one is 
down.

HTH,
Jeroen



On Wed, Jan 23, 2013 at 5:00 PM, Scott Parker 
mailto:scott.p.par...@gmail.com>> wrote:
Anyone else running a production website with Clojure in Heroku and
struggling with boot time problems? After digging through our logs
from the past month, I've noticed it's not uncommon to have a dyno
crashed for awhile because of boot time problems. It seems especially
likely when dynos are cycling once/day - I'm guessing because of
additional delays in picking up latest snapshot dependencies.

Has anyone else run into this problem and has a bright idea? I have
already verified we're using lein compile :all at deploy (by virtue of
being on lein2), running in the production profile, and I am working
on removing those snapshot dependencies. I've checked the app for
obvious bottlenecks like web/DB/IO requests during initialization with
no luck. We don't have a ton of code or dependencies right now, so I'm
a bit skeptical that we can remain on Heroku as we grow. As a last
resort, I suppose we could try a proxy bound to a Unix socket as in
https://github.com/dblock/heroku-forward but I'd rather avoid that if
possible.

If not advice specifically in the context of pleasing Heroku, advice
on troubleshooting slow app init times generally would also be
welcome. I've done some minimal code benchmarking in Clojure
previously, but never specifically towards resolving time-to-init.

Thanks,
-SP

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




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


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

Re: Heroku & Boot Times

[Scott Parker]

Jeroen - thanks for the advice. Yeah, SNAPSHOTS in prod is a poor practice
anyway, this gives me a good incentive to find them and kill them.

Static files on boot... dang. When I was first investigating our slow boot
time I swear I checked Enlive, but another quick glance at the source
indicates it's almost certainly a contributor. Expletive! I will start
capturing some metrics on how much time we're spending loading HTML
templates at init. We're not loading a godawful number of separate HTML
files, so I'd like to avoid a bunch of delays throughout my views if
possible.

Thanks a bunch Jeroen.
-SP


On Wed, Jan 23, 2013 at 11:19 AM, Jeroen van Dijk <
jeroentjevand...@gmail.com> wrote:

> Hi Scott,
>
> We had some issues as well. SNAPSHOTS are likely to be an issue because
> they are re-checked at least once a day. So if your app needs a restart
> this will be re-checked and might slow down boot time. We also had problems
> due to this in combination with failing maven mirrors. It is probably best
> to just not use SNAPSHOT versions in production.
>
> Another thing that can have impact on boot time is the reading of static
> files on booting. We solved this by using '(def resource (delay
> (expensive-task ))) and @resource to post-pone this execution for after
> booting.
>
> We also use this feature
> https://devcenter.heroku.com/articles/labs-preboot/ to minimize possible
> downtime between deploys (not sure if this works for restarts as well)
>
> On top of that, we always have a minimum of two dynos for redundancy if
> one is down.
>
> HTH,
> Jeroen
>
>
>
> On Wed, Jan 23, 2013 at 5:00 PM, Scott Parker wrote:
>
>> Anyone else running a production website with Clojure in Heroku and
>> struggling with boot time problems? After digging through our logs
>> from the past month, I've noticed it's not uncommon to have a dyno
>> crashed for awhile because of boot time problems. It seems especially
>> likely when dynos are cycling once/day - I'm guessing because of
>> additional delays in picking up latest snapshot dependencies.
>>
>> Has anyone else run into this problem and has a bright idea? I have
>> already verified we're using lein compile :all at deploy (by virtue of
>> being on lein2), running in the production profile, and I am working
>> on removing those snapshot dependencies. I've checked the app for
>> obvious bottlenecks like web/DB/IO requests during initialization with
>> no luck. We don't have a ton of code or dependencies right now, so I'm
>> a bit skeptical that we can remain on Heroku as we grow. As a last
>> resort, I suppose we could try a proxy bound to a Unix socket as in
>> https://github.com/dblock/heroku-forward but I'd rather avoid that if
>> possible.
>>
>> If not advice specifically in the context of pleasing Heroku, advice
>> on troubleshooting slow app init times generally would also be
>> welcome. I've done some minimal code benchmarking in Clojure
>> previously, but never specifically towards resolving time-to-init.
>>
>> Thanks,
>> -SP
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>
>

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

Re: Heroku & Boot Times

[Jeroen van Dijk]

Hi Scott,

We had some issues as well. SNAPSHOTS are likely to be an issue because
they are re-checked at least once a day. So if your app needs a restart
this will be re-checked and might slow down boot time. We also had problems
due to this in combination with failing maven mirrors. It is probably best
to just not use SNAPSHOT versions in production.

Another thing that can have impact on boot time is the reading of static
files on booting. We solved this by using '(def resource (delay
(expensive-task ))) and @resource to post-pone this execution for after
booting.

We also use this feature
https://devcenter.heroku.com/articles/labs-preboot/to minimize
possible downtime between deploys (not sure if this works for
restarts as well)

On top of that, we always have a minimum of two dynos for redundancy if one
is down.

HTH,
Jeroen



On Wed, Jan 23, 2013 at 5:00 PM, Scott Parker wrote:

> Anyone else running a production website with Clojure in Heroku and
> struggling with boot time problems? After digging through our logs
> from the past month, I've noticed it's not uncommon to have a dyno
> crashed for awhile because of boot time problems. It seems especially
> likely when dynos are cycling once/day - I'm guessing because of
> additional delays in picking up latest snapshot dependencies.
>
> Has anyone else run into this problem and has a bright idea? I have
> already verified we're using lein compile :all at deploy (by virtue of
> being on lein2), running in the production profile, and I am working
> on removing those snapshot dependencies. I've checked the app for
> obvious bottlenecks like web/DB/IO requests during initialization with
> no luck. We don't have a ton of code or dependencies right now, so I'm
> a bit skeptical that we can remain on Heroku as we grow. As a last
> resort, I suppose we could try a proxy bound to a Unix socket as in
> https://github.com/dblock/heroku-forward but I'd rather avoid that if
> possible.
>
> If not advice specifically in the context of pleasing Heroku, advice
> on troubleshooting slow app init times generally would also be
> welcome. I've done some minimal code benchmarking in Clojure
> previously, but never specifically towards resolving time-to-init.
>
> Thanks,
> -SP
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>
>

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

Heroku & Boot Times

[Scott Parker]

Anyone else running a production website with Clojure in Heroku and
struggling with boot time problems? After digging through our logs
from the past month, I've noticed it's not uncommon to have a dyno
crashed for awhile because of boot time problems. It seems especially
likely when dynos are cycling once/day - I'm guessing because of
additional delays in picking up latest snapshot dependencies.

Has anyone else run into this problem and has a bright idea? I have
already verified we're using lein compile :all at deploy (by virtue of
being on lein2), running in the production profile, and I am working
on removing those snapshot dependencies. I've checked the app for
obvious bottlenecks like web/DB/IO requests during initialization with
no luck. We don't have a ton of code or dependencies right now, so I'm
a bit skeptical that we can remain on Heroku as we grow. As a last
resort, I suppose we could try a proxy bound to a Unix socket as in
https://github.com/dblock/heroku-forward but I'd rather avoid that if
possible.

If not advice specifically in the context of pleasing Heroku, advice
on troubleshooting slow app init times generally would also be
welcome. I've done some minimal code benchmarking in Clojure
previously, but never specifically towards resolving time-to-init.

Thanks,
-SP

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

Re: Is there a performance hit when dynamically "require"-ing namespaces

[Sean Corfield]

On Wed, Jan 23, 2013 at 12:13 AM, Mikera  wrote:
> It requires the compilation of the namespace when it is loaded the first
> time, but that isn't particularly bad and is only a one-off cost. If you
> require the plugin twice then the second time is effectively a no-op.

I recall a thread recently that said 'require' hits the disk every
time, even if the ns is already loaded. Did that get fixed and, if so,
when?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: ANN: clj-spark - A Clojure wrapper for the Spark API

[Marc Limotte]

Hi Michael,

Thanks for the suggestion.  I intentionally avoided doing this because I do
not feel that the project is mature enough for someone to just pull in as a
dependency lib and go.  Anyone wishing to make use of it would be better
served by getting the code from github.  While it is not complete, it is
useable and I do think it is a head start for Clojure developers who are
interested in playing around or doing some proof of concept with Spark.

Marc

On Tue, Jan 22, 2013 at 6:59 AM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

> 2013/1/22 Marc Limotte 
>
>> The project is available here:
>>
>> https://github.com/TheClimateCorporation/clj-spark
>>
>
> Marc,
>
> Please add artifact/dependency information to the README. Otherwise
> beginners won't be able to
> use your project. If you need an example:
> https://github.com/clojurewerkz/elastisch#artifacts
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: ANN: clj-spark - A Clojure wrapper for the Spark API

[Marc Limotte]

Hi Mark.

This was very much exploratory work, and a lot of it was just about
learning the Spark paradigms.  That being said, merging for future work
seems appropriate, but it's not clear yet if I will be pursuing this work
further.  Might wind up using Shark instead [would love to use Cascading
over Spark as well, if it existed].

I'd like to know what issue you had in getting the code/examples to work?
 I had a couple of people try this out from scratch on clean systems and it
did work for them.

Serializing the functions is necessary as far as I can tell.  It would not
work for me without this.  As far as I can tell (this is largely
guesswork), the problem is that each time the anonymous function is
evaluated on a different JVM it gets a different class name (e.g. fn_123).
 There is high likelihood that the name assigned on the master is not the
same as the name on the task JVMs, so you wind up with a
ClassNotFoundException.

I don't know why this would work for you.  If you have any insight on this,
I would love to hear it?

Marc

On Tue, Jan 22, 2013 at 8:09 AM, Mark Hamstra  wrote:

> Hmmm... a lot of duplicated work.  Sorry I didn't get my stuff in a more
> usable form for you, but I wasn't aware that anybody was even interested in
> it.  I've got some stuff that I want to rework a little, and I'm still
> thinking through the best way to integrate with the new reducers code in
> Clojure, but I haven't had the right combination of time and motivation to
> finish off what I started and document it.  At any rate, we should work at
> merging the two efforts, since I don't see any need for duplicate APIs.
>
> In taking a quick first pass at it, I wasn't able to get your code and
> examples to work, but I'm curious what your reasoning is for
> using serializable.fn and avoiding use of
> clojure.core/fn or #().  I'm not sure that is strictly necessary.  For
> example, the following works just fine with my API:
>
> (require 'spark.api.clojure.core)
>
> (wrappers!) ; one of the pieces I want to re-work, but allows functions
> like map to work with  either Clojure collections or RDDs
>
> (set-spark-context! "local[4]" "cljspark")
>
> (def rdd (parallelize [1 2 3 4]))
>
> (def mrdd1 (map #(+ 2 %) rdd))
>
> (def result1 (collect mrdd1))
>
> (def offset1 4)
>
> (def mrdd2 (map #(+ offset %) rdd))
>
> (def result2 (collect mrdd2))
>
> (def mrdd3 (map (let [offset2 5] (+ offset %)) rdd))
>
> (def result3 (collect mrdd3))
>
>
> That will result in result1, result2, and result3 being [3 4 5 6], [5 6 7
> 8], and [6 7 8 9] respectively, without any need for serializable-fn.
>
>
> On Tuesday, January 22, 2013 6:55:53 AM UTC-8, Marc Limotte wrote:
>
>> A Clojure api for the Spark Project.  I am aware that there is another
>> clojure spark wrapper project which looks very interesting,  This project
>> has similar goals.  And also similar to that project it is not absolutely
>> complete, but it is does have some documentation and examples.  And it is
>> useable and should be easy enough to extend as needed.  This is the result
>> of about three weeks of work.  It handles many of the initial problems like
>> serializing anonymous functions, converting back and forth between Scala
>> Tuples and Clojure seqs, and converting RDDs to PairRDDs.
>>
>> The project is available here:
>>
>> https://github.com/**TheClimateCorporation/clj-**spark
>>
>> Thanks to The Climate Corporation for allowing me to release it.  At
>> Climate, we do the majority of our Big Data work with Cascalog (on top of
>> Cascading).  I was looking into Spark for some of the benefits that it
>> provides.  I suspect we will explore Shark next, and may work it in to our
>> processes for some of our more adhoc/exploratory queries.
>>
>> I think it would be interesting to see a Cascading planner on top of
>> Spark, which would enable Cascalog queries (mostly) for free.  I suspect
>> that might be a superior method of using Clojure on Spark.
>>
>> Marc Limotte
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Simple FIFO cache for memoize

[Michael Fogus]

Absolutely essential reading.

On Wed, Jan 23, 2013 at 6:02 AM, Christophe Grand  wrote:
> and kotka.de/blog/2010/03/memoize_done_right.html has some intersting
> discussion on memoization
>
>
> On Wed, Jan 23, 2013 at 9:12 AM, Baishampayan Ghose 
> wrote:
>>
>> Take a look at core.cache - https://github.com/clojure/core.cache ~BG
>>
>> On Wed, Jan 23, 2013 at 1:11 PM, Omer Iqbal  wrote:
>> > I've been reading a bit about the STM, and here's an implementation of a
>> > FIFO cache for producing a memoized version of a function. Is it correct
>> > to
>> > use the STM in this case, or are there any  drawbacks?
>> >
>> > (defn bounded-memoize
>> >   "Return a bounded memoized version of fn 'f'
>> >that caches the last 'k' computed values"
>> >   [f k]
>> >   (let [cache (ref {})
>> > values (ref clojure.lang.PersistentQueue/EMPTY)]
>> > (fn [& args]
>> >   (if-let [e (find @cache args)]
>> > (val e)
>> > (let [result (apply f args)]
>> >   (dosync
>> >(alter values conj args)
>> >(alter cache assoc args result)
>> >(if (> (count @values) k)
>> >  (let [evict (peek @values)]
>> >(alter values pop)
>> >(alter cache dissoc evict))
>> >  )
>> >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
>> >
>> >
>>
>>
>>
>> --
>> Baishampayan Ghose
>> b.ghose at 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
>>
>>
>
>
>
> --
> On Clojure http://clj-me.cgrand.net/
> Clojure Programming http://clojurebook.com
> Training, Consulting & Contracting http://lambdanext.eu/
>
> --
> --
> 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
>
>



-- 
-- http://blog.fogus.me
-- http://github.com/fogus
--

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

Re: Clojure on heroku throws exception today

[Jonathon McKitrick]

And *this* is what I love about Clojure and the Clojure community

On Tuesday, January 22, 2013 11:07:39 PM UTC-5, Phil Hagelberg wrote:
>
>
> Jonathon McKitrick writes: 
>
> > I checked out the GitHub repos for leiningen and leiningen_repl, but 
> > nothing jumps out as the cause.  I require leiningen 2.0.0, but dropping 
> > this requirement allows the repl task to load and run. 
>
> This is due to the release of Leiningen 2.0.0; the buildpack currently 
> back-ports a bugfix to the repl via an alias in a way that only works in 
> the preview. For the time being you can use `lein trampoline repl` 
> explicitly; I'll push a fix for the alias tomorrow. Thanks for bringing 
> this to my attention. 
>
> -Phil 
>

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

Re: Simple FIFO cache for memoize

[Michael Fogus]

> now I'm confused, which one is the right memoize to use?

I'm not sure exactly what you mean, but if you mean which backing
cache to use the answer depends on your needs.  The core.cache wiki
has discussion about the advantages/disadvantages of using one type or
another.  You can find the discussion under each cache's detailed
information linked on the "Using" page -->
https://github.com/clojure/core.cache/wiki/Using

> and is that true about dosync? "the nesting property of dosync: a nested
> transaction merges with the surrounding one." or did it change in the past
> almost 3 years since?

It's always been that way.
:F

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

Re: Simple FIFO cache for memoize

[AtKaaZ]

now I'm confused, which one is the right memoize to use?
and is that true about dosync? "the nesting property of dosync: a nested
transaction merges with the surrounding one." or did it change in the past
almost 3 years since?


On Wed, Jan 23, 2013 at 12:08 PM, David Powell wrote:

>
> Specifically, core.memoize uses core.cache to provide more flexible
> replacements for memoize:
> https://github.com/clojure/core.memoize
>
> --
> Dave
>
>
>
> On Wed, Jan 23, 2013 at 8:12 AM, Baishampayan Ghose wrote:
>
>> Take a look at core.cache - https://github.com/clojure/core.cache ~BG
>>
>> On Wed, Jan 23, 2013 at 1:11 PM, Omer Iqbal 
>> wrote:
>> > I've been reading a bit about the STM, and here's an implementation of a
>> > FIFO cache for producing a memoized version of a function. Is it
>> correct to
>> > use the STM in this case, or are there any  drawbacks?
>> >
>> > (defn bounded-memoize
>> >   "Return a bounded memoized version of fn 'f'
>> >that caches the last 'k' computed values"
>> >   [f k]
>> >   (let [cache (ref {})
>> > values (ref clojure.lang.PersistentQueue/EMPTY)]
>> > (fn [& args]
>> >   (if-let [e (find @cache args)]
>> > (val e)
>> > (let [result (apply f args)]
>> >   (dosync
>> >(alter values conj args)
>> >(alter cache assoc args result)
>> >(if (> (count @values) k)
>> >  (let [evict (peek @values)]
>> >(alter values pop)
>> >(alter cache dissoc evict))
>> >  )
>> >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
>> >
>> >
>>
>>
>>
>> --
>> Baishampayan Ghose
>> b.ghose at 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 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
>
>
>



-- 
I may be wrong or incomplete.
Please express any corrections / additions,
they are encouraged and appreciated.
At least one entity is bound to be transformed if you do ;)

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

Re: Simple FIFO cache for memoize

[David Powell]

Specifically, core.memoize uses core.cache to provide more flexible
replacements for memoize:
https://github.com/clojure/core.memoize

-- 
Dave



On Wed, Jan 23, 2013 at 8:12 AM, Baishampayan Ghose wrote:

> Take a look at core.cache - https://github.com/clojure/core.cache ~BG
>
> On Wed, Jan 23, 2013 at 1:11 PM, Omer Iqbal  wrote:
> > I've been reading a bit about the STM, and here's an implementation of a
> > FIFO cache for producing a memoized version of a function. Is it correct
> to
> > use the STM in this case, or are there any  drawbacks?
> >
> > (defn bounded-memoize
> >   "Return a bounded memoized version of fn 'f'
> >that caches the last 'k' computed values"
> >   [f k]
> >   (let [cache (ref {})
> > values (ref clojure.lang.PersistentQueue/EMPTY)]
> > (fn [& args]
> >   (if-let [e (find @cache args)]
> > (val e)
> > (let [result (apply f args)]
> >   (dosync
> >(alter values conj args)
> >(alter cache assoc args result)
> >(if (> (count @values) k)
> >  (let [evict (peek @values)]
> >(alter values pop)
> >(alter cache dissoc evict))
> >  )
> >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
> >
> >
>
>
>
> --
> Baishampayan Ghose
> b.ghose at 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Simple FIFO cache for memoize

[Christophe Grand]

and kotka.de/blog/2010/03/memoize_done_right.html has some intersting
discussion on memoization


On Wed, Jan 23, 2013 at 9:12 AM, Baishampayan Ghose wrote:

> Take a look at core.cache - https://github.com/clojure/core.cache ~BG
>
> On Wed, Jan 23, 2013 at 1:11 PM, Omer Iqbal  wrote:
> > I've been reading a bit about the STM, and here's an implementation of a
> > FIFO cache for producing a memoized version of a function. Is it correct
> to
> > use the STM in this case, or are there any  drawbacks?
> >
> > (defn bounded-memoize
> >   "Return a bounded memoized version of fn 'f'
> >that caches the last 'k' computed values"
> >   [f k]
> >   (let [cache (ref {})
> > values (ref clojure.lang.PersistentQueue/EMPTY)]
> > (fn [& args]
> >   (if-let [e (find @cache args)]
> > (val e)
> > (let [result (apply f args)]
> >   (dosync
> >(alter values conj args)
> >(alter cache assoc args result)
> >(if (> (count @values) k)
> >  (let [evict (peek @values)]
> >(alter values pop)
> >(alter cache dissoc evict))
> >  )
> >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
> >
> >
>
>
>
> --
> Baishampayan Ghose
> b.ghose at 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
>
>
>


-- 
On Clojure http://clj-me.cgrand.net/
Clojure Programming http://clojurebook.com
Training, Consulting & Contracting http://lambdanext.eu/

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

Re: Is there a performance hit when dynamically "require"-ing namespaces

[Mikera]

On Wednesday, 23 January 2013 03:47:56 UTC+8, Sean Bowman wrote:

> I'm trying to implement a simple system to load certain namespaces into my 
> application that are configurable at runtime, via a "plugins" text file 
> that lists the namespaces we want to load.  I have some code that loads 
> this file, then line by line calls "require" dynamically, like so:
>
> (doseq [plugin plugins]
>   (require (symbol plugin))
>
> Each "plugin" namespace attaches itself to the central event bus and 
> listens for events.  
>
> My question is:  how bad is it that I'm doing this?  Am I taking any kind 
> of major performance hit by dynamically calling "require" like this?  
>

Not really a problem. It's effectively the same as if you required the 
namespace at the start of the program in an ns declaration. 

It requires the compilation of the namespace when it is loaded the first 
time, but that isn't particularly bad and is only a one-off cost. If you 
require the plugin twice then the second time is effectively a no-op.


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

Re: Simple FIFO cache for memoize

[Baishampayan Ghose]

Take a look at core.cache - https://github.com/clojure/core.cache ~BG

On Wed, Jan 23, 2013 at 1:11 PM, Omer Iqbal  wrote:
> I've been reading a bit about the STM, and here's an implementation of a
> FIFO cache for producing a memoized version of a function. Is it correct to
> use the STM in this case, or are there any  drawbacks?
>
> (defn bounded-memoize
>   "Return a bounded memoized version of fn 'f'
>that caches the last 'k' computed values"
>   [f k]
>   (let [cache (ref {})
> values (ref clojure.lang.PersistentQueue/EMPTY)]
> (fn [& args]
>   (if-let [e (find @cache args)]
> (val e)
> (let [result (apply f args)]
>   (dosync
>(alter values conj args)
>(alter cache assoc args result)
>(if (> (count @values) k)
>  (let [evict (peek @values)]
>(alter values pop)
>(alter cache dissoc evict))
>  )
>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
>
>



-- 
Baishampayan Ghose
b.ghose at 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