Re: ANN: ClojureScript release 0.0-1513

[Shantanu Kumar]

> It was a regression to reify caused by 
> CLJS-369,http://dev.clojure.org/jira/browse/CLJS-405
>
> It's fixed in master. If you can confirm this works for you too that would
> be great.

Yes, it works for me. Thanks!

Shantanu

-- 
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: tutorials or screencasts on debuggers in clojure?

[Roberto Mannai]

There is a ticket in CDS:
https://github.com/clojuredocs/cds/issues/27#issuecomment-9583049

On Wednesday, October 24, 2012, Warren Lynn wrote:

> +1. I just got the basic ritz-nrepl set up in the hope to try out the
> debugger. But I don't even know where to start. How to set a breakpoint,
> for example? I could not find it anywhere on the web or from Emacs
> "apropos". I figured it must be so obvious to others and I must be so
> stupid... Thanks for bringing up this topic.
>
>
>  --
> 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 '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  'clojure%2bunsubscr...@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

[ANN] congomongo 0.2.2 and 0.3.1 released

[Sean Corfield]

Today has been a busy day in the world of CongoMongo with four(!) releases...

The 0.2.x branch is now in maintenance, supporting Clojure 1.2.x.
Release 0.3.0 onward only support Clojure 1.3.0 and later.

Only 0.2.1 and 0.3.0 were planned. MongoDB then announced a critical
bug fix in the Java driver (2.9.2 to replace 2.9.1 and 2.9.0) so there
were rather hurried 0.2.2 and 0.3.1 releases to incorporate that
critical fix:

Version 0.3.1 - October 23rd, 2012

* Update Java driver to 2.9.2 for CRITICAL update (#98)

Version 0.3.0 - October 23rd, 2012

* DROP SUPPORT FOR CLOJURE 1.2.1 AND EARLIER!
* Update clojure.data.json to 0.2.0 (#97)
* Update clojure.core.incubator to 0.1.2

Version 0.2.2 - October 23rd, 2012 - last release to support Clojure 1.2.x!

* Update Java driver to 2.9.2 for CRITICAL update (#98)

Version 0.2.1 - October 23rd, 2012

* Support insertion of sets (#94, #95)
* Declare MongoDB service for Travis CI (#96)

The change to clojure.data.json 0.2.0 in 0.3.0 was the catalyst for
dropping support for Clojure 1.2.x since it is only compatible with
Clojure 1.3.0 and later. The CongoMongo 0.2.x branch will continue to
get maintenance fixes for Clojure 1.2.x users but master (0.3.0 and
later) will continue to get new features.
-- 
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: Spyscope, a trace/println-oriented debugging tool for Clojure

[Mads Olsen]

Super! Very pragmatic, short, practical.
I suggest removing fib or putting it in test. Also suggest renaming ast.

-- 
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: Some Friend documentation and regarding documentation in general

[David Della Costa]

Patrik, Pierre, have you folks checked out the mock app that Chas
created in the test directory?  It's not going to give you everything
you're looking for but make it can help.  There is an implementation
of the OpenID workflow in there, including a credential-fn example:

https://github.com/cemerick/friend/blob/master/test/test_friend/mock_app.clj

This may also help, regarding credential functions:

https://github.com/cemerick/friend/blob/master/test/test_friend/credentials.clj

I also highly recommend looking at the bcrypt-credential-fn in the
credentials.clj lib, in the src of the project itself:

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

This is the default credentials function used in the mock app above,
so it should help illustrate some of the concepts.  I've spent a lot
of time poring over the code too, so feel free to ping me with
questions too, I may be able to help.

> IMHO the doc is really lacking and I have to say I was expecting more
> guidance in the code itself.

Yes, it's still hard to wrap your head around the docs.  Friend
scratches an itch I have, and I think it's going to be rather
important if people are trying to web apps quickly in Clojure, so I'm
going to keep working on it and see how much I can clean things up and
make concepts more clear.  And I know Chas is interested in this as
well, from his past comments.  Any help and pull requests are welcome.
;-)

I'm working on some updates to everything I've been working on, I'll
post updates to the list shortly (later this week probably, maybe even
today).

DD

2012/10/24 Pierre R :
> Thanks David for the extra doc.
>
> I have had a try with OpenID. Everything works kind of expected.
>
> I had a question about "302 redirection prior to authentication" that I
> posted on github.
>
> Another question is how to link the concept of roles with the openid
> credentials.
>
> IMHO the doc is really lacking and I have to say I was expecting more
> guidance in the code itself.
>
> I guess a lot of stuff obvious to an experienced clojure developers are
> still dark magic to me.
>
> In particular it is rather difficult to understand how to write a
> crendential-fn and this link won't help you ;-)
> https://github.com/cemerick/friend/blob/master/docs/credentials.md
>
> For "OpenId" I have blindly used the identity function without much
> understanding ...
>
> I am using Friend to scratch a little auth server. Not sure it is the best
> fit for that purpose. I will see.
>
> I hope Friend is going to be reviewed by an extended community of people
> much more qualified than myself to talk about such matter.
>
> Still docs could be improved and I believe helps could come from pull
> requests to suggest the addition of code comments there and there.
>
> If I dig far enough in the code, I would be pleased to help.
>
> Thanks for the hard work.
>
> Cheers,
>
> Le mardi 23 octobre 2012 17:50:25 UTC+2, Patrik Sundberg a écrit :
>>
>> These are great tutorials. Thanks for publishing.
>>
>> Right now I'm looking for something similar using the OpenID workflow. I
>> see it's there but how I use to for example create a "sign in with google"
>> setup is less clear to me.
>>
>> Has anyone got a good OpenID example out there somewhere?
>>
>> On Saturday, October 6, 2012 4:50:05 PM UTC+1, David Della Costa wrote:
>>>
>>> Hi folks,
>>>
>>> I've been pretty slack in communicating via the mailing list, but I
>>> realized today that there is a lot of important dialogue going on here
>>> so I have to make more of an effort to take part--I want to be a part of
>>> this community!
>>>
>>> In any case, I've been using Friend a lot lately, since I come from
>>> Ruby-on-Rails-land, and it addresses a lot of the pain points that
>>> Devise does for me.
>>>
>>> But (as has been mentioned in other threads quite recently),
>>> documentation is definitely the Clojure community's week point: it's
>>> inconsistent, formatted inconsistently (Ring and Compojure, for example,
>>> are wonderful exceptions), and updated erratically.  When it's good,
>>> it's great; but when it's not, it puts me off from using a library.  For
>>> example, I stayed away from Enlive for months before I realized what a
>>> useful library it is--so I re-wrote the README to suit my tastes
>>> (https://github.com/ddellacosta/enlive).
>>>
>>> I think Chas Emerick writes much better docs than much of what
>>> accompanies most Clojure libraries, but he's quite an advanced Clojure
>>> developer, and he's moving very fast--so as a newbie, I had difficulty
>>> even with his relatively good docs for Friend.  And I suspect you'll be
>>> getting more and more folks from the web development world in the next
>>> few years like me.  So it will be good to have things from the
>>> perspective of someone not just trying to grok the libraries that exist,
>>> but also trying to understand how Clojure works, and how the eco-system
>>> fits together.
>>>
>>> I've written some material o

Re: tutorials or screencasts on debuggers in clojure?

[Warren Lynn]

+1. I just got the basic ritz-nrepl set up in the hope to try out the 
debugger. But I don't even know where to start. How to set a breakpoint, 
for example? I could not find it anywhere on the web or from Emacs 
"apropos". I figured it must be so obvious to others and I must be so 
stupid... Thanks for bringing up this topic.


-- 
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: ClojureScript release 0.0-1513

[David Nolen]

On Mon, Oct 22, 2012 at 3:20 PM, Shantanu Kumar wrote:

>
>
> On Oct 23, 12:11 am, David Nolen  wrote:
> > On Mon, Oct 22, 2012 at 3:08 PM, Shantanu Kumar <
> kumar.shant...@gmail.com>wrote:
> >
> > > 19afb31a52504293ba2182c584b1867917316662
> >
> > Do you have top level lets in your code?
> >
> > (let [foo ...]
> >(defn bar ...))
>
> I have top-level let in a macro file, which is never referenced via
> any of the tests:
>
> https://github.com/kumarshantanu/basil/blob/master/src/basil/core_macro.clj
>
>
> However, I was suspecting the error to be happening in group.clj:
>
> https://github.com/kumarshantanu/basil/blob/master/src/basil/group.clj#L40
>
> because, I noticed that all error instances are due to the same cause:
>
> TypeError: 'undefined' is not an object (evaluating 'self__.f_obtain__
> $1.call')
>
> Shantanu
>

It was a regression to reify caused by CLJS-369,
http://dev.clojure.org/jira/browse/CLJS-405

It's fixed in master. If you can confirm this works for you too that would
be great.

David

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

Re: CLJS: println stopped working (r1514) ?

[David Nolen]

On Tue, Oct 23, 2012 at 6:47 PM, Frank Siebenlist <
frank.siebenl...@gmail.com> wrote:

> Thanks Paul.
>
> Just wanted a confirmation first that this printing from the browser repl
> doesn't work before opening a new issue.
> (too many versions and uncommitted changes on my mac - it's a pain trying
> to create a clean slate - may require a lein&m2 hard-reboot… a simple
> confirmation would avoid that.)
>
> -FS.


It would be helpful if you could use the lein checkouts feature and did a
git bisect to figure out which commit broke browser REPL.

David

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

Re: CLJS: println stopped working (r1514) ?

[Frank Siebenlist]

Yes - automated testing of cljs in the browser would definitely be Grand with a 
capital G.

Not sure exactly what it would take, but it may be helpful to use this 
cljs-info.repl/cljs->repl function as it allows you to send cljs-forms for eval 
to the browser and get the result back from your clj environment: write test 
functions in clj to test cljs-forms in the browser. How to set it all up that 
it works in an automated way… is still unclear to me.

-FrankS.


On Oct 23, 2012, at 3:37 PM, David Nolen  wrote:

> A related ticket - http://dev.clojure.org/jira/browse/CLJS-404 if someone is 
> interested.
> 
> Would be grand if we could automate testing the browser REPL to avoid 
> regressions like this.
> 
> David
> 
> On Tue, Oct 23, 2012 at 5:51 PM, Paul deGrandis  
> wrote:
> Frank,
> 
> Do you have an open issue for this?  if not, please do so and attach all the 
> information you can.
> I can start digging in on this.
> 
> Paul
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: CLJS: println stopped working (r1514) ?

[Frank Siebenlist]

Thanks Paul.

Just wanted a confirmation first that this printing from the browser repl 
doesn't work before opening a new issue.
(too many versions and uncommitted changes on my mac - it's a pain trying to 
create a clean slate - may require a lein&m2 hard-reboot… a simple confirmation 
would avoid that.)

-FS.


On Oct 23, 2012, at 2:51 PM, Paul deGrandis  wrote:

> Frank,
> 
> Do you have an open issue for this?  if not, please do so and attach all the 
> information you can.
> I can start digging in on this.
> 
> Paul
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: CLJS: println stopped working (r1514) ?

[David Nolen]

A related ticket - http://dev.clojure.org/jira/browse/CLJS-404 if someone
is interested.

Would be grand if we could automate testing the browser REPL to avoid
regressions like this.

David

On Tue, Oct 23, 2012 at 5:51 PM, Paul deGrandis wrote:

> Frank,
>
> Do you have an open issue for this?  if not, please do so and attach all
> the information you can.
> I can start digging in on this.
>
> Paul
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

tutorials or screencasts on debuggers in clojure?

[James Hess]

Hi,
Are there any recent tutorials or screencasts on the debuggers in 
clojure's ecosystem today (e.g. ritz for emacs, or CCW)?  If not then I 
think having a debugger tutorial on clojure-docs or similar would fill a 
massive void.


-Jimbo

--
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: when to be lazy

[Jonathan Fischer Friberg]

No, that's unfortunate. :(

Jonathan

On Wed, Oct 24, 2012 at 12:27 AM, Brian Craft  wrote:

> hipster presentation is not so great in archive: can't really see what
> he's doing.
>
>
> On Tuesday, October 23, 2012 1:55:08 PM UTC-7, Jonathan Fischer Friberg
> wrote:
>
>> Just found this: http://www.infoq.com/**presentations/Laziness-Good-**
>> Bad-Ugly 
>>
>> Jonathan
>>
>> On Tue, Oct 23, 2012 at 10:09 PM, Brian Craft  wrote:
>>
>>> Thanks for all the responses! This is great.
>>>
>>> b.c.
>>>
>>> On Tuesday, October 23, 2012 12:51:11 PM UTC-7, Sean Corfield wrote:
>>>
 On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft 
 wrote:
 > Is a lazy seq mostly about algorithmic clarity, and avoiding
 unnecessary
 > computation? So far I haven't run into any cases where I wouldn't
 realize
 > the entire sequence, and it's always faster to do it up-front.

 Here's a real world example or two from World Singles (where I work):

 Search engine results

 We use a search engine that returns "pages" of results. We provide the
 criteria, page number and page size, and get back that "page" of
 results from the overall result set. We have a process that looks thru
 search results and discards matches a member has already seen recently
 and various other filters. It would be messy to have to write all of
 that paging logic into the filtering logic so we have a
 lazy-search-results function that hides the paging and turns the
 result set into a flat, lazy sequence. That's the only place that has
 to deal with paging complexity. The rest of the algorithm is much,
 much simpler since it can now operate on a plain ol' Clojure sequence
 of search results. Huge win for simplicity.

 Emailing matches to members daily

 We have millions of members. We have a process that scours the
 database for members who haven't had an email from us recently, which
 then looks for different types of matches for them (related to the
 process above). After each period of 24 hours, the process restarts
 from the beginning. We use a lazy sequence around fetching suitable
 members from the database that automatically gets a sentinel inserted
 24 hours after we started that period's search. As above, the process
 now simply just processes a sequence until it hits the sentinel (it's
 actually interleaving about fifty sequences and having the sentinel
 dynamically inserted in each sequence makes the code simpler than just
 hitting the 'end' of a sequence - we tried that first). The number of
 members processed in 24 hours depends on how many matches we find, how
 far thru each result set we have to look to find matches and so on.
 Lazy sequences make this much simpler (and much less memory intensive
 since we don't have to hold the entire sequence in memory in order to
 process it).

 Updating the search engine

 We also have a process that watches the database for member profile
 changes and transforms profile data into XML and posts it to the
 search engine, to keep results fresh. Again, a lazy sequence is used
 to allow us to continually process the 'sequence' of changes from the
 database and handle 'millions' of profiles in a (relatively) fixed
 amount of memory.

 So, yes, we are constantly processes sequences that either wouldn't
 fit in memory fully realized or are actually infinite. Is the
 processing slower than the procedural equivalent of loops and tests?
 Quite probably. Is the memory usage better than realizing entire
 chunks of sequences? Oh yes, and not having to worry about tuning all
 that is a big simplification. Is the code simpler than the procedural
 equivalent? Hell, yeah!

 Hope that helps?
 --
 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 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, 

Re: when to be lazy

[Brian Craft]

hipster presentation is not so great in archive: can't really see what he's 
doing.

On Tuesday, October 23, 2012 1:55:08 PM UTC-7, Jonathan Fischer Friberg 
wrote:
>
> Just found this: http://www.infoq.com/presentations/Laziness-Good-Bad-Ugly
>
> Jonathan
>
> On Tue, Oct 23, 2012 at 10:09 PM, Brian Craft 
> > wrote:
>
>> Thanks for all the responses! This is great.
>>
>> b.c.
>>
>> On Tuesday, October 23, 2012 12:51:11 PM UTC-7, Sean Corfield wrote:
>>
>>> On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft  
>>> wrote: 
>>> > Is a lazy seq mostly about algorithmic clarity, and avoiding 
>>> unnecessary 
>>> > computation? So far I haven't run into any cases where I wouldn't 
>>> realize 
>>> > the entire sequence, and it's always faster to do it up-front. 
>>>
>>> Here's a real world example or two from World Singles (where I work): 
>>>
>>> Search engine results 
>>>
>>> We use a search engine that returns "pages" of results. We provide the 
>>> criteria, page number and page size, and get back that "page" of 
>>> results from the overall result set. We have a process that looks thru 
>>> search results and discards matches a member has already seen recently 
>>> and various other filters. It would be messy to have to write all of 
>>> that paging logic into the filtering logic so we have a 
>>> lazy-search-results function that hides the paging and turns the 
>>> result set into a flat, lazy sequence. That's the only place that has 
>>> to deal with paging complexity. The rest of the algorithm is much, 
>>> much simpler since it can now operate on a plain ol' Clojure sequence 
>>> of search results. Huge win for simplicity. 
>>>
>>> Emailing matches to members daily 
>>>
>>> We have millions of members. We have a process that scours the 
>>> database for members who haven't had an email from us recently, which 
>>> then looks for different types of matches for them (related to the 
>>> process above). After each period of 24 hours, the process restarts 
>>> from the beginning. We use a lazy sequence around fetching suitable 
>>> members from the database that automatically gets a sentinel inserted 
>>> 24 hours after we started that period's search. As above, the process 
>>> now simply just processes a sequence until it hits the sentinel (it's 
>>> actually interleaving about fifty sequences and having the sentinel 
>>> dynamically inserted in each sequence makes the code simpler than just 
>>> hitting the 'end' of a sequence - we tried that first). The number of 
>>> members processed in 24 hours depends on how many matches we find, how 
>>> far thru each result set we have to look to find matches and so on. 
>>> Lazy sequences make this much simpler (and much less memory intensive 
>>> since we don't have to hold the entire sequence in memory in order to 
>>> process it). 
>>>
>>> Updating the search engine 
>>>
>>> We also have a process that watches the database for member profile 
>>> changes and transforms profile data into XML and posts it to the 
>>> search engine, to keep results fresh. Again, a lazy sequence is used 
>>> to allow us to continually process the 'sequence' of changes from the 
>>> database and handle 'millions' of profiles in a (relatively) fixed 
>>> amount of memory. 
>>>
>>> So, yes, we are constantly processes sequences that either wouldn't 
>>> fit in memory fully realized or are actually infinite. Is the 
>>> processing slower than the procedural equivalent of loops and tests? 
>>> Quite probably. Is the memory usage better than realizing entire 
>>> chunks of sequences? Oh yes, and not having to worry about tuning all 
>>> that is a big simplification. Is the code simpler than the procedural 
>>> equivalent? Hell, yeah! 
>>>
>>> Hope that helps? 
>>> -- 
>>> 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 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: Midje popularity?

[Brian Marick]

I merged your pull request, and I'm now getting up to speed with nrepl, 
leiningen 2, etc. 

Do you want to be a committer to midje-mode? I'll have to get dnaumov to set 
you up, since it's his repo.

-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile
Writing /Functional Programming for the Object-Oriented Programmer/: 
https://leanpub.com/fp-oo


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

Re: CLJS: println stopped working (r1514) ?

[Paul deGrandis]

Frank,

Do you have an open issue for this?  if not, please do so and attach all 
the information you can.
I can start digging in on this.

Paul

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

Re: when to be lazy

[Jonathan Fischer Friberg]

Just found this: http://www.infoq.com/presentations/Laziness-Good-Bad-Ugly

Jonathan

On Tue, Oct 23, 2012 at 10:09 PM, Brian Craft  wrote:

> Thanks for all the responses! This is great.
>
> b.c.
>
> On Tuesday, October 23, 2012 12:51:11 PM UTC-7, Sean Corfield wrote:
>
>> On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft 
>> wrote:
>> > Is a lazy seq mostly about algorithmic clarity, and avoiding
>> unnecessary
>> > computation? So far I haven't run into any cases where I wouldn't
>> realize
>> > the entire sequence, and it's always faster to do it up-front.
>>
>> Here's a real world example or two from World Singles (where I work):
>>
>> Search engine results
>>
>> We use a search engine that returns "pages" of results. We provide the
>> criteria, page number and page size, and get back that "page" of
>> results from the overall result set. We have a process that looks thru
>> search results and discards matches a member has already seen recently
>> and various other filters. It would be messy to have to write all of
>> that paging logic into the filtering logic so we have a
>> lazy-search-results function that hides the paging and turns the
>> result set into a flat, lazy sequence. That's the only place that has
>> to deal with paging complexity. The rest of the algorithm is much,
>> much simpler since it can now operate on a plain ol' Clojure sequence
>> of search results. Huge win for simplicity.
>>
>> Emailing matches to members daily
>>
>> We have millions of members. We have a process that scours the
>> database for members who haven't had an email from us recently, which
>> then looks for different types of matches for them (related to the
>> process above). After each period of 24 hours, the process restarts
>> from the beginning. We use a lazy sequence around fetching suitable
>> members from the database that automatically gets a sentinel inserted
>> 24 hours after we started that period's search. As above, the process
>> now simply just processes a sequence until it hits the sentinel (it's
>> actually interleaving about fifty sequences and having the sentinel
>> dynamically inserted in each sequence makes the code simpler than just
>> hitting the 'end' of a sequence - we tried that first). The number of
>> members processed in 24 hours depends on how many matches we find, how
>> far thru each result set we have to look to find matches and so on.
>> Lazy sequences make this much simpler (and much less memory intensive
>> since we don't have to hold the entire sequence in memory in order to
>> process it).
>>
>> Updating the search engine
>>
>> We also have a process that watches the database for member profile
>> changes and transforms profile data into XML and posts it to the
>> search engine, to keep results fresh. Again, a lazy sequence is used
>> to allow us to continually process the 'sequence' of changes from the
>> database and handle 'millions' of profiles in a (relatively) fixed
>> amount of memory.
>>
>> So, yes, we are constantly processes sequences that either wouldn't
>> fit in memory fully realized or are actually infinite. Is the
>> processing slower than the procedural equivalent of loops and tests?
>> Quite probably. Is the memory usage better than realizing entire
>> chunks of sequences? Oh yes, and not having to worry about tuning all
>> that is a big simplification. Is the code simpler than the procedural
>> equivalent? Hell, yeah!
>>
>> Hope that helps?
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: CLJS: println stopped working (r1514) ?

[David Nolen]

On Tue, Oct 23, 2012 at 4:33 PM, Frank Siebenlist <
frank.siebenl...@gmail.com> wrote:

> Sorry - browser-repl- any browser.


Ah. This is possible given some of the changes around printing. Help
welcome on this one, a bit busy this week.

David

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

Re: CLJS: println stopped working (r1514) ?

[Frank Siebenlist]

Sorry - browser-repl- any browser.

On Oct 23, 2012, at 1:25 PM, David Nolen  wrote:

> On Tue, Oct 23, 2012 at 4:18 PM, Frank Siebenlist 
>  wrote:
> Bump.
> 
> Could someone please confirm that printing from the repl doesn't work anymore?
> 
> Thanks, Frank.
> 
> In what REPL? Works fine for me using the Rhino one via script/repljs
> 
> David 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: CLJS: println stopped working (r1514) ?

[David Nolen]

On Tue, Oct 23, 2012 at 4:18 PM, Frank Siebenlist <
frank.siebenl...@gmail.com> wrote:

> Bump.
>
> Could someone please confirm that printing from the repl doesn't work
> anymore?
>
> Thanks, Frank.


In what REPL? Works fine for me using the Rhino one via script/repljs

David

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

Re: CLJS: println stopped working (r1514) ?

[Frank Siebenlist]

Bump.

Could someone please confirm that printing from the repl doesn't work anymore?

Thanks, Frank.



On Oct 19, 2012, at 8:18 PM, Frank Siebenlist  
wrote:

> When I eval in the cljs-repl:
> 
>(set! *print-fn* clojure.browser.repl/repl-print)
> 
> all works again.
> 
> Seems that the "(defmethod handle-post :ready [_ conn _] …)" in 
> cljs.repl.browser doesn't assign the *print-fn* in the cljs-repl (?).
> 
> Not sure if anything changed there (?).
> 
> -FS.
> 
> 
> On Oct 19, 2012, at 7:56 PM, Frank Siebenlist  
> wrote:
> 
>> Not sure if its my cljs-config somehow (working off head r1514), but println 
>> doesn't seem to be working anymore:
>> 
>> ClojureScript:cljs.user> (println "JAJA")
>> "Error evaluating:" (println "JAJA") :as 
>> "cljs.core.println.call(null,\"JAJA\");\n"
>> #
>> _STAR_print_fn_STAR_@http://10.0.1.18:9000/js/main-debug.js:1821
>> string_print@http://10.0.1.18:9000/js/main-debug.js:18711
>> pr_with_opts@http://10.0.1.18:9000/js/main-debug.js:18984
>> println__delegate@http://10.0.1.18:9000/js/main-debug.js:19098
>> println@http://10.0.1.18:9000/js/main-debug.js:19102
>> 
>> 
>> eval code
>> eval@[native code]
>> @http://10.0.1.18:9000/js/main-debug.js:29720
>> evaluate_javascript@http://10.0.1.18:9000/js/main-debug.js:29719
>> @http://10.0.1.18:9000/js/main-debug.js:29799
>> deliver@http://10.0.1.18:9000/js/main-debug.js:25554
>> deliver_@http://10.0.1.18:9000/js/main-debug.js:26665
>> messageReceived_@http://10.0.1.18:9000/js/main-debug.js:26258
>> handleEvent@http://10.0.1.18:9000/js/main-debug.js:21161
>> fireListener@http://10.0.1.18:9000/js/main-debug.js:21661
>> handleBrowserEvent_@http://10.0.1.18:9000/js/main-debug.js:21726
>> f@http://10.0.1.18:9000/js/main-debug.js:21265
>> [native code]
>> nil
>> ClojureScript:cljs.user> 
>> 
>> 
>> Is it just me or…
>> 
>> -FrankS.
> 

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

Re: when to be lazy

[Brian Craft]

Thanks for all the responses! This is great.

b.c.

On Tuesday, October 23, 2012 12:51:11 PM UTC-7, Sean Corfield wrote:
>
> On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft 
> > 
> wrote: 
> > Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary 
> > computation? So far I haven't run into any cases where I wouldn't 
> realize 
> > the entire sequence, and it's always faster to do it up-front. 
>
> Here's a real world example or two from World Singles (where I work): 
>
> Search engine results 
>
> We use a search engine that returns "pages" of results. We provide the 
> criteria, page number and page size, and get back that "page" of 
> results from the overall result set. We have a process that looks thru 
> search results and discards matches a member has already seen recently 
> and various other filters. It would be messy to have to write all of 
> that paging logic into the filtering logic so we have a 
> lazy-search-results function that hides the paging and turns the 
> result set into a flat, lazy sequence. That's the only place that has 
> to deal with paging complexity. The rest of the algorithm is much, 
> much simpler since it can now operate on a plain ol' Clojure sequence 
> of search results. Huge win for simplicity. 
>
> Emailing matches to members daily 
>
> We have millions of members. We have a process that scours the 
> database for members who haven't had an email from us recently, which 
> then looks for different types of matches for them (related to the 
> process above). After each period of 24 hours, the process restarts 
> from the beginning. We use a lazy sequence around fetching suitable 
> members from the database that automatically gets a sentinel inserted 
> 24 hours after we started that period's search. As above, the process 
> now simply just processes a sequence until it hits the sentinel (it's 
> actually interleaving about fifty sequences and having the sentinel 
> dynamically inserted in each sequence makes the code simpler than just 
> hitting the 'end' of a sequence - we tried that first). The number of 
> members processed in 24 hours depends on how many matches we find, how 
> far thru each result set we have to look to find matches and so on. 
> Lazy sequences make this much simpler (and much less memory intensive 
> since we don't have to hold the entire sequence in memory in order to 
> process it). 
>
> Updating the search engine 
>
> We also have a process that watches the database for member profile 
> changes and transforms profile data into XML and posts it to the 
> search engine, to keep results fresh. Again, a lazy sequence is used 
> to allow us to continually process the 'sequence' of changes from the 
> database and handle 'millions' of profiles in a (relatively) fixed 
> amount of memory. 
>
> So, yes, we are constantly processes sequences that either wouldn't 
> fit in memory fully realized or are actually infinite. Is the 
> processing slower than the procedural equivalent of loops and tests? 
> Quite probably. Is the memory usage better than realizing entire 
> chunks of sequences? Oh yes, and not having to worry about tuning all 
> that is a big simplification. Is the code simpler than the procedural 
> equivalent? Hell, yeah! 
>
> Hope that helps? 
> -- 
> 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: immutable objects in js

[Philip Potter]

If you're interested, I did an introduction to clojure's persistent data
structures at the london Clojure user group earlier this year:

http://skillsmatter.com/podcast/home/persistent-data-structures-in-clojure

There have also been talks worth watching on the subject by Chris Houser,
Daniel Spiewak, and Phil Bagwell, all at one clojure/conj or another.

Phil
On Oct 23, 2012 8:49 PM, "Raoul Duke"  wrote:

> On Tue, Oct 23, 2012 at 12:47 PM, Philip Potter
>  wrote:
> > Clojure's persistent data structures use sharing under the hood. Ergo,
> so do
> > clojurescript's.
>
> keen! thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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: when to be lazy

[Sean Corfield]

On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft  wrote:
> Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
> computation? So far I haven't run into any cases where I wouldn't realize
> the entire sequence, and it's always faster to do it up-front.

Here's a real world example or two from World Singles (where I work):

Search engine results

We use a search engine that returns "pages" of results. We provide the
criteria, page number and page size, and get back that "page" of
results from the overall result set. We have a process that looks thru
search results and discards matches a member has already seen recently
and various other filters. It would be messy to have to write all of
that paging logic into the filtering logic so we have a
lazy-search-results function that hides the paging and turns the
result set into a flat, lazy sequence. That's the only place that has
to deal with paging complexity. The rest of the algorithm is much,
much simpler since it can now operate on a plain ol' Clojure sequence
of search results. Huge win for simplicity.

Emailing matches to members daily

We have millions of members. We have a process that scours the
database for members who haven't had an email from us recently, which
then looks for different types of matches for them (related to the
process above). After each period of 24 hours, the process restarts
from the beginning. We use a lazy sequence around fetching suitable
members from the database that automatically gets a sentinel inserted
24 hours after we started that period's search. As above, the process
now simply just processes a sequence until it hits the sentinel (it's
actually interleaving about fifty sequences and having the sentinel
dynamically inserted in each sequence makes the code simpler than just
hitting the 'end' of a sequence - we tried that first). The number of
members processed in 24 hours depends on how many matches we find, how
far thru each result set we have to look to find matches and so on.
Lazy sequences make this much simpler (and much less memory intensive
since we don't have to hold the entire sequence in memory in order to
process it).

Updating the search engine

We also have a process that watches the database for member profile
changes and transforms profile data into XML and posts it to the
search engine, to keep results fresh. Again, a lazy sequence is used
to allow us to continually process the 'sequence' of changes from the
database and handle 'millions' of profiles in a (relatively) fixed
amount of memory.

So, yes, we are constantly processes sequences that either wouldn't
fit in memory fully realized or are actually infinite. Is the
processing slower than the procedural equivalent of loops and tests?
Quite probably. Is the memory usage better than realizing entire
chunks of sequences? Oh yes, and not having to worry about tuning all
that is a big simplification. Is the code simpler than the procedural
equivalent? Hell, yeah!

Hope that helps?
-- 
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: immutable objects in js

[Raoul Duke]

On Tue, Oct 23, 2012 at 12:47 PM, Philip Potter
 wrote:
> Clojure's persistent data structures use sharing under the hood. Ergo, so do
> clojurescript's.

keen! thanks.

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

Re: immutable objects in js

[Philip Potter]

Clojure's persistent data structures use sharing under the hood. Ergo, so
do clojurescript's.

Phil
On Oct 23, 2012 8:23 PM, "Raoul Duke"  wrote:

> On Tue, Oct 23, 2012 at 12:19 PM, David Nolen 
> wrote:
> > On Tue, Oct 23, 2012 at 3:17 PM, Brian Craft 
> wrote:
> >> Does clojurescript have to do full copies on collection types to keep
> them
> >> immutable? Or is there some nice way to efficiently do immutable
> objects in
> >> js?
> > ClojureScript now implements all of Clojure's persistent data structures.
>
> hm, uh, that doesn't seem to answer the question, as i read it. :-)
> you /could have/ implemented them via slow expensive full copies, or
> you could implement them with sharing under the covers. i assume you
> mean the latter is true, but it isn't totally clear just from that
> sentence.
>
> --
> 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: when to be lazy

[Brian Hurt]

Sorry- I didn't mean for my post to come off sounding like the only reason
to use lazy eval is to skip computation.  It's just *one* of the many
reasons.

On Tue, Oct 23, 2012 at 3:08 PM, Kurman Karabukaev  wrote:

> Hi Brian,
>
> Laziness (and first class functions) can help with code modularity, I
> would suggest reading paper by John Hughes on the topic:
> www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
>
> Kurman
>
> On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft wrote:
>
>> I don't yet understand how laziness helps. Can anyone point me to a
>> reference? I have vague memory that one of the videos addresses this (I
>> remember something about "these are not iterators"), but I'm having trouble
>> finding it now.
>>
>> I'm finding that lazy seqs are too slow for everything, so I expect I'm
>> using them incorrectly. Many of the core functions return seqs, and I
>> invariably end up wrapping them with (vec ...) to get any kind of
>> reasonable performance. Is that what I should be doing?
>>
>> Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
>> computation? So far I haven't run into any cases where I wouldn't realize
>> the entire sequence, and it's always faster to do it up-front.
>>
>>  --
>> 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: when to be lazy

[Kurman Karabukaev]

Hi Brian,

Laziness (and first class functions) can help with code modularity, I would
suggest reading paper by John Hughes on the topic:
www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf

Kurman

On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft  wrote:

> I don't yet understand how laziness helps. Can anyone point me to a
> reference? I have vague memory that one of the videos addresses this (I
> remember something about "these are not iterators"), but I'm having trouble
> finding it now.
>
> I'm finding that lazy seqs are too slow for everything, so I expect I'm
> using them incorrectly. Many of the core functions return seqs, and I
> invariably end up wrapping them with (vec ...) to get any kind of
> reasonable performance. Is that what I should be doing?
>
> Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
> computation? So far I haven't run into any cases where I wouldn't realize
> the entire sequence, and it's always faster to do it up-front.
>
>  --
> 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: Some Friend documentation and regarding documentation in general

[Pierre R]

Thanks David for the extra doc.

I have had a try with OpenID. Everything works kind of expected.

I had a question about "302 redirection prior to authentication" that I 
posted on github.

Another question is how to link the concept of roles with the openid 
credentials.

IMHO the doc is really lacking and I have to say I was expecting more 
guidance in the code itself.

I guess a lot of stuff obvious to an experienced clojure developers are 
still dark magic to me.

In particular it is rather difficult to understand how to write a 
crendential-fn and this link won't help you ;-)
https://github.com/cemerick/friend/blob/master/docs/credentials.md

For "OpenId" I have blindly used the identity function without much 
understanding ...

I am using Friend to scratch a little auth server. Not sure it is the best 
fit for that purpose. I will see.

I hope Friend is going to be reviewed by an extended community of people 
much more qualified than myself to talk about such matter.

Still docs could be improved and I believe helps could come from pull 
requests to suggest the addition of code comments there and there. 

If I dig far enough in the code, I would be pleased to help.

Thanks for the hard work.

Cheers,

Le mardi 23 octobre 2012 17:50:25 UTC+2, Patrik Sundberg a écrit :
>
> These are great tutorials. Thanks for publishing.
>
> Right now I'm looking for something similar using the OpenID workflow. I 
> see it's there but how I use to for example create a "sign in with google" 
> setup is less clear to me.
>
> Has anyone got a good OpenID example out there somewhere?
>
> On Saturday, October 6, 2012 4:50:05 PM UTC+1, David Della Costa wrote:
>>
>> Hi folks, 
>>
>> I've been pretty slack in communicating via the mailing list, but I 
>> realized today that there is a lot of important dialogue going on here 
>> so I have to make more of an effort to take part--I want to be a part of 
>> this community! 
>>
>> In any case, I've been using Friend a lot lately, since I come from 
>> Ruby-on-Rails-land, and it addresses a lot of the pain points that 
>> Devise does for me. 
>>
>> But (as has been mentioned in other threads quite recently), 
>> documentation is definitely the Clojure community's week point: it's 
>> inconsistent, formatted inconsistently (Ring and Compojure, for example, 
>> are wonderful exceptions), and updated erratically.  When it's good, 
>> it's great; but when it's not, it puts me off from using a library.  For 
>> example, I stayed away from Enlive for months before I realized what a 
>> useful library it is--so I re-wrote the README to suit my tastes 
>> (https://github.com/ddellacosta/enlive). 
>>
>> I think Chas Emerick writes much better docs than much of what 
>> accompanies most Clojure libraries, but he's quite an advanced Clojure 
>> developer, and he's moving very fast--so as a newbie, I had difficulty 
>> even with his relatively good docs for Friend.  And I suspect you'll be 
>> getting more and more folks from the web development world in the next 
>> few years like me.  So it will be good to have things from the 
>> perspective of someone not just trying to grok the libraries that exist, 
>> but also trying to understand how Clojure works, and how the eco-system 
>> fits together. 
>>
>> I've written some material on how to use Friend, including some OAuth2 
>> resources.  I'd appreciate any feedback you can give, I'm pretty new to 
>> Clojure (and Lisp in general). 
>>
>> In any case: 
>>
>> https://github.com/ddellacosta/friend-interactive-form-tutorial 
>> https://github.com/ddellacosta/friend-oauth2-examples 
>> https://github.com/ddellacosta/friend-oauth2 
>>
>> I have a bunch of other Clojure-related stuff on my github account too, 
>> feedback is most welcome! 
>>
>> Cheers, 
>> DD 
>>
>

-- 
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: immutable objects in js

[Raoul Duke]

On Tue, Oct 23, 2012 at 12:19 PM, David Nolen  wrote:
> On Tue, Oct 23, 2012 at 3:17 PM, Brian Craft  wrote:
>> Does clojurescript have to do full copies on collection types to keep them
>> immutable? Or is there some nice way to efficiently do immutable objects in
>> js?
> ClojureScript now implements all of Clojure's persistent data structures.

hm, uh, that doesn't seem to answer the question, as i read it. :-)
you /could have/ implemented them via slow expensive full copies, or
you could implement them with sharing under the covers. i assume you
mean the latter is true, but it isn't totally clear just from that
sentence.

-- 
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: immutable objects in js

[David Nolen]

On Tue, Oct 23, 2012 at 3:17 PM, Brian Craft  wrote:

> Does clojurescript have to do full copies on collection types to keep them
> immutable? Or is there some nice way to efficiently do immutable objects in
> js?


ClojureScript now implements all of Clojure's persistent data structures.

David

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

immutable objects in js

[Brian Craft]

Does clojurescript have to do full copies on collection types to keep them 
immutable? Or is there some nice way to efficiently do immutable objects in 
js?

-- 
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: when to be lazy

[Jonathan Fischer Friberg]

Example:

You want to find an element with a certain property in a list.
In a imperative language you can do:

function ...
   for( ... loop over list)
  if( ... current element has the property ...)
 return the element

But in clojure we can do:
(first (filter has-the-property? the-list))

If 'filter' was not lazy, the performance would be absolutely terrible.
With laziness however, it is only necessary to evaluate until we reach an
element that has the property (that is, the same as in the imperative way).

A simple runnable example would be:

(first (filter #(> % 5) (range)))
;=> 6

Where (range) is of course an infinite list, so this would not even be
possible without laziness.

The point is that laziness basically makes it possible to use the functions
that operates on seq,
without really caring about how much we are evaluating.

The above example might seem like a nifty little example, that doesn't
reflect the real world.
I think it does. In fact, I think the advantages you get from laziness is
much greater than
this example shows. I often have functions where I do several
map/filter/"that stuff" on a
list, then send it to the next function(s) that also does something along
those lines.
So on and so on.

---

"Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
computation?"
Basically, yes, I think so. You could rephrase it as
"making algorithmic clarity possible, by avoiding unnecessary computation.".

"So far I haven't run into any cases where I wouldn't realize the entire
sequence, and it's always faster to do it up-front."
I think the cases where I have to realize the entire thing are much more
common than not. However, when they do
crop up, it's absolutely necessary to have laziness.
Is it always faster to do it "up-front"? Maybe. The question is: do we
really need the extra performance.
In almost all cases, I would say "not really".
The only time that I have actually needed the extra performance was in some
euler problem(s).
Otherwise, the performance have not been noticeable.

Jonathan


On Tue, Oct 23, 2012 at 8:38 PM, Brian Craft  wrote:

> I don't yet understand how laziness helps. Can anyone point me to a
> reference? I have vague memory that one of the videos addresses this (I
> remember something about "these are not iterators"), but I'm having trouble
> finding it now.
>
> I'm finding that lazy seqs are too slow for everything, so I expect I'm
> using them incorrectly. Many of the core functions return seqs, and I
> invariably end up wrapping them with (vec ...) to get any kind of
> reasonable performance. Is that what I should be doing?
>
> Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
> computation? So far I haven't run into any cases where I wouldn't realize
> the entire sequence, and it's always faster to do it up-front.
>
>  --
> 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: when to be lazy

[Brian Hurt]

On Tue, Oct 23, 2012 at 2:58 PM, Jim - FooBar(); wrote:

> On 23/10/12 19:57, Brian Hurt wrote:
>
>> Unless you don't need to do it at all.
>>
>
> nce... ;-)
>
>
I was actually serious.  One of the advantages of lazy eval is that it lets
you delay deciding whether or not to do a computation until you actually
need the result- if there is a decent chance you won't, then it's a win.
So it lets you play games like:
(let [ lst (map expensive_function (range 10)) ]
; Note, lst is lazily evaluated, the above expression is O(1) cost!
...
   ; Later- nah, I've changed my mind, I only need the first 10 elements
   (take 10 lst)

Note that we haven't paid the cost of evaluating all billion calls to
expensive_function, we've only paid the cost of doing it 10 times- skipping
the remaining 999,999,990 calls.

Brian



>
> Jim
>
> --
> 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+unsubscribe@**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: when to be lazy

[Jim - FooBar();]

On 23/10/12 19:57, Brian Hurt wrote:

Unless you don't need to do it at all.


nce... ;-)

Jim

--
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: when to be lazy

[Brian Hurt]

On Tue, Oct 23, 2012 at 2:49 PM, Jim - FooBar(); wrote:

> On 23/10/12 19:38, Brian Craft wrote:
>
>> it's always faster to do it up-front.
>>
>
> it will always always be faster do it upfront...no way around that!
>

Unless you don't need to do it at all.

Brian

-- 
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: when to be lazy

[Jim - FooBar();]

On 23/10/12 19:38, Brian Craft wrote:

it's always faster to do it up-front.


it will always always be faster do it upfront...no way around that!

Clojure offers both worlds...be lazy when designing  APIs or dealing 
with big-data that don't fit to memory and be greedy when you want petal 
to the metal perf. Most of the precious fns in core now have a reducer 
brother. No assumptions or promises about the underlying collection are 
made with reducers...just poor the reducer into a vector and you're 
golden... :-)


hope that helps...

Jim

--
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: when to be lazy

[Raoul Duke]

On Tue, Oct 23, 2012 at 11:38 AM, Brian Craft  wrote:
> I don't yet understand how laziness helps. Can anyone point me to a
> reference?

all of haskell? ;-)

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

when to be lazy

[Brian Craft]

I don't yet understand how laziness helps. Can anyone point me to a 
reference? I have vague memory that one of the videos addresses this (I 
remember something about "these are not iterators"), but I'm having trouble 
finding it now.

I'm finding that lazy seqs are too slow for everything, so I expect I'm 
using them incorrectly. Many of the core functions return seqs, and I 
invariably end up wrapping them with (vec ...) to get any kind of 
reasonable performance. Is that what I should be doing?

Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary 
computation? So far I haven't run into any cases where I wouldn't realize 
the entire sequence, and it's always faster to do it up-front.

-- 
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: Some Friend documentation and regarding documentation in general

[Patrik Sundberg]

These are great tutorials. Thanks for publishing.

Right now I'm looking for something similar using the OpenID workflow. I 
see it's there but how I use to for example create a "sign in with google" 
setup is less clear to me.

Has anyone got a good OpenID example out there somewhere?

On Saturday, October 6, 2012 4:50:05 PM UTC+1, David Della Costa wrote:
>
> Hi folks, 
>
> I've been pretty slack in communicating via the mailing list, but I 
> realized today that there is a lot of important dialogue going on here 
> so I have to make more of an effort to take part--I want to be a part of 
> this community! 
>
> In any case, I've been using Friend a lot lately, since I come from 
> Ruby-on-Rails-land, and it addresses a lot of the pain points that 
> Devise does for me. 
>
> But (as has been mentioned in other threads quite recently), 
> documentation is definitely the Clojure community's week point: it's 
> inconsistent, formatted inconsistently (Ring and Compojure, for example, 
> are wonderful exceptions), and updated erratically.  When it's good, 
> it's great; but when it's not, it puts me off from using a library.  For 
> example, I stayed away from Enlive for months before I realized what a 
> useful library it is--so I re-wrote the README to suit my tastes 
> (https://github.com/ddellacosta/enlive). 
>
> I think Chas Emerick writes much better docs than much of what 
> accompanies most Clojure libraries, but he's quite an advanced Clojure 
> developer, and he's moving very fast--so as a newbie, I had difficulty 
> even with his relatively good docs for Friend.  And I suspect you'll be 
> getting more and more folks from the web development world in the next 
> few years like me.  So it will be good to have things from the 
> perspective of someone not just trying to grok the libraries that exist, 
> but also trying to understand how Clojure works, and how the eco-system 
> fits together. 
>
> I've written some material on how to use Friend, including some OAuth2 
> resources.  I'd appreciate any feedback you can give, I'm pretty new to 
> Clojure (and Lisp in general). 
>
> In any case: 
>
> https://github.com/ddellacosta/friend-interactive-form-tutorial 
> https://github.com/ddellacosta/friend-oauth2-examples 
> https://github.com/ddellacosta/friend-oauth2 
>
> I have a bunch of other Clojure-related stuff on my github account too, 
> feedback is most welcome! 
>
> Cheers, 
> DD 
>

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

nREPL 0.2.0-RC1 released

[Chas Emerick]

I released [org.clojure/tools.nrepl "0.2.0-RC1"] last night.  This includes a 
couple of key fixes since the 0.2.0-beta9 release, which you can peruse here if 
you're so inclined:

http://dev.clojure.org/jira/browse/NREPL/fixforversion/10153
http://dev.clojure.org/jira/browse/NREPL/fixforversion/10154

With any luck, the same codebase will become 0.2.0 final.  The remaining work 
is all in the area of documentation, which I'll be sawing away at this week.

Cheers,

- Chas

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

Re: Meta data access

[Mamun]

Hi Carlo,

Thanks. Now it is fine.

Regards,
Mamun

On Tuesday, October 23, 2012 5:24:41 AM UTC+2, Carlo wrote:
>
> Hey Mamun, 
>
> Your problem is that your ^{:test true} metadata isn't being applied 
> to your functions, as you might expect, but rather to the var that is 
> pointing to the function. You can see this in the following (#' is a 
> shorthand to get the var rather than the thing it contains). 
>
> user=> (meta f1) 
> nil 
> user=> (meta #'f1) 
> {:arglists ([]), :ns #, :test true, :name f1, :line 1, 
> :source "(clojure.core/defn ^{:test true} f1 [] (println \"Call f1 
> fn\"))\n", :file "NO_SOURCE_PATH"} 
>
> You can solve this in two ways: 
>
> 1) Have `f*` contain a list of symbols, then use `resolve` [1] to get 
> the vars. Then the definition of `f*` becomes `(def f* (list 'f1 
> 'f2))` 
>
> 2) Have `f*` contain a list of vars 
>
> Once you have the vars then you can use `(-> form meta :test)` to 
> access the value for the :test metadata. 
>
> Due to the way vars are implemented, calling `(form)` when `form` is a 
> var will actually call the function that `form` is pointing to, so the 
> earlier function call should continue to work. 
>
> I hope that helps! 
>
> Carlo 
>
> [1]: 
> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/resolve 
>
> On Tue, Oct 23, 2012 at 1:30 AM, Mamun > 
> wrote: 
> > Hi All, 
> > 
> > I've a application with following structure. Now I would like to access 
> meta 
> > data of f1 and f2 within process function. 
> > 
> > (defn ^{:test true} f1 [] 
> > (println "call f1 fn")) 
> > 
> > (defn ^{:test false} f2 [] 
> > (println "call f2 fn")) 
> > 
> > (def f* (list f1 f2)) 
> > 
> > (defn process [form] 
> >   (do 
> > //Would like to access meta data of form 
> > (println (str "-->" form 
> > 
> > (map #(process %1) f*) 
> > 
> > Does any one have any idea? 
> > 
> > 
> > Regards, 
> > Mamun 
> > 
> > -- 
> > 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: Zürich Clojure User Group

[Nando]

Thomas,

Can you be more specific about the room, if it is already known?

On Mon, Oct 22, 2012 at 8:00 PM, Thomas G. Kristensen <
thomas.g.kristen...@gmail.com> wrote:

> Hi Nando,
>
> The first meeting will be Monday 12 of November at 7 PM (more information
> at http://www.meetup.com/zh-clj-Zurich-Clojure-User-Group/events/87505462/).
> It will be held at ETH, but we are looking for new rooms, since our contact
> there is changing to a new firm.
>
> It will be in English - many people around here seem to be expats, and my
> German isn't good enough to perform technical discussions!
>
> Well met,
>
> Thomas
>
>
> On Monday, October 22, 2012 6:50:50 PM UTC+2, Nando Breiter wrote:
>
>> Thomas,
>>
>> Have you organized location and time yet? Or is the meetup to be online?
>> Will it be in German, Swiss-German, English?
>>
>> --
>> Nando Breiter
>>
>> *Aria Media
>> via Rompada 40
>> 6987 Caslano
>> Switzerland*
>>
>> On Mon, Oct 22, 2012 at 10:37 AM, Thomas G. Kristensen <
>> thomas.g@gmail.com**> wrote:
>>
>>> Hi all,
>>>
>>> I'm happy to announce the Zürich Clojure User Group!
>>>
>>> http://www.meetup.com/zh-clj-**Zurich-Clojure-User-Group/
>>>
>>> Our first meetup will be Monday the 12th of November, and we're very
>>> excited about seeing as many Clojurians from Switzerland (and the
>>> surrounding countries) as possible.
>>>
>>> I have tried to add the group to http://dev.clojure.org/**
>>> display/community/Clojure+**User+Groups--
>>>  but I have been unable to gain editing rights to the page. If anybody
>>> are able to help me in that, please get in touch.
>>>
>>> Well met!
>>>
>>> Thomas
>>>
>>> --
>>> 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
>



-- 
Nando Breiter

*Aria Media
via Rompada 40
6987 Caslano
Switzerland
*

-- 
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: LispIndent, jEdit plugin that indents lisp code

[Jonathan Fischer Friberg]

>
> BTW, I created the beginnings of a CDS "development tools" guide
> https://github.com/clojuredocs/cd
> s/blob/master/articles/ecosystem/development_tools.mdand
>  added some notes in there re. jEdit + LispIndent.
>

Nice!
Hopefully this will make it easier for new users to get started.
(unless they drown in the amount of editors/IDEs you can choose from :) )

Today I updated the LispIndent indenting so that it reads one line at a
time,
instead of "strings of length one" at a time.
This makes it possible to remove characters such as \( and comments.
It is big change however, it requires testing. :)

Jonathan

-- 
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: after a few days, my app dies -- how should I diagnose?

[Hubert Iwaniuk]

Not sure if that is a case but could your run your software in some long 
running shell like tmux or screen.
You redirected all standard file descriptors, so it should not be a 
problem, but it is worth a try.


HTH,
Hubert.

AtKaaZ wrote:
You could save the std out and err to some .log and can inspect it 
later, I'd expect you'd see some exceptions if any were thrown.

who-is-logged-in-1.0.1-standalone.jar 4 stdouterr.log &

On Tue, Oct 23, 2012 at 12:12 AM, Michael Klishin 
mailto:michael.s.klis...@gmail.com>> wrote:


2012/10/23 larry google groups mailto:lawrencecloj...@gmail.com>>

If memory is not the problem, what other problems should I
look for? 



Unhandled exceptions, although in the case of a Web app, Jetty and
similar should cover last
resort exception handling that will prevent main JVM thread from
terminating.

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




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


--
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: Understanding clojure.core.cache TTL cache

[Hussein B.]

Just to push to the limit.

Lets say we saved/serializer the cache to a secondary storage (file or 
ZooKeeper).
What happen when the cache is restored? 
I mean TTL is still honored? expired data while been sleeping will be 
evicted upon an operation is performed after deserialization?

Thanks a lot!

On Tuesday, October 23, 2012 1:42:28 AM UTC+3, Sean Corfield wrote:
>
> On Mon, Oct 22, 2012 at 3:30 PM, Hussein B. > 
> wrote: 
> > So we need to call evict explicitly if we want to remove an entry? no 
> > automatic deletion after expiring? 
>
> The cache is immutable. 
>
> When you call hit / miss, you get a new instance of the cache with the 
> expired entries removed, and the hit entry updated (if appropriate) or 
> the miss entry added. 
>
> That new instance needs to be stored somewhere (or passed to future 
> code execution). 
>
> Entries will be automatically deleted after expiring in any new 
> instance of the cache - returned by hit / miss. 
>
> You can see that here: 
>
> user=> (swap! c3 hit-or-miss :a 1) 
> {:a 1} 
> user=> (swap! c3 hit-or-miss :b 2) 
> {:a 1, :b 2} 
> user=> (swap! c3 hit-or-miss :c 3) 
> {:c 3, :b 2} 
> user=> (swap! c3 hit-or-miss :d 4) 
> {:c 3, :d 4} 
> user=> (swap! c3 hit-or-miss :e 5) 
> {:c 3, :d 4, :e 5} 
>
> We add :a, then :b. By the time we add :c, :a has expired (and been 
> removed). By the time we add :d, :b has expired (and been removed). 
> Then we add :e before any more expiries. If I wait awhile and add a 
> new value for :a... 
>
> user=> (swap! c3 hit-or-miss :a 6) 
> {:a 6} 
>
> ...you'll see :c, :d and :e have expired. 
> -- 
> 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: UTF-8 behavior ClojureScript (vs. Clojure)

[Dave Sann]

I notice this is fixed on clojurescript master. 

thanks guys. 

I can now delete my special edition clojure :)

On Saturday, 20 October 2012 11:55:23 UTC+11, Chas Emerick wrote:
>
> I've filed a CLJS issue for this, and attached a patch: 
>
> http://dev.clojure.org/jira/browse/CLJS-400 
>
> Thanks for keeping on this, Dave. :-) 
>
> - Chas 
>
> On Oct 19, 6:18 pm, Dave Sann  wrote: 
> > Chas, If your patch works without issue - this is probably better 
> because 
> > it will then work with existing versions of Clojure - clojurescript is 
> > changing faster and people a probably upgrading faster. 
> > 
> > I don't think it does any harm for Clojure to be able to read these 
> chars 
> > but fixing the interchange the the real issue (for me). 
> > 
> > Stu closed 1025 already. 
> > 
> > Dave 
>

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