Re: Using Clojure for public facing system in a bank - code security scanning - any luck?

[Aaron Bedra]

Penetration testing is something performed on an application, but a source code 
review of the language is certainly an interesting idea. My company does these 
all the time. I ran this by my folks and there was certainly interest. If we 
could publish the results and create a healthy discussion my company would be 
happy to participate and do this at a fixed and heavily discounted price.

In terms of socket repl it is and will always be a security anti-pattern. But 
that should be understood and considered as a trade-off for the ability to 
access a running program. There could be recommendations made, but I don’t see 
a lot of value in pointing out what we already know to be a poor idea from a 
security perspective. I think that conversation should shift towards 
compensating controls around the environment to make sure limitations on repl 
access are present and auditable.

> On Apr 13, 2018, at 12:51 PM, Didier  wrote:
> 
> I'd love an independent penetration and security audit of the Clojure 
> codebase. Especially around the socket repl in a localhost restricted way and 
> making sure its not exploitable.
> 
> I wonder how much it costs, and if Clojurist together could have one funded.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Using Clojure for public facing system in a bank - code security scanning - any luck?

[Aaron Bedra]

t. 
> This is in itself useful and an extension of what we anyway do - but customer 
> wise it is obviously not really 'objective'. A way to make it more strongly 
> objective would be to use a third party - that may however be costly.
> Similarly we are wondering to what extent we could expand the work we do in 
> terms of ethical hacking / penetration testing - perhaps we could raise the 
> bar there in terms of automation.
> You might want to talk to Aaron Bedra about some of this - he does security 
> consulting and is deeply knowledgeable about Clojure systems as well (and 
> spurred a lot of changes in the Clojure web frameworks to default to better 
> security).
> 
>  
> 
> Thanks a gain for your time.
> 
> -- 
> 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://groups.google.com/group/clojure?hl=en>
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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

Re: [ANN] ring-auth middleware for protecting sessions

[Aaron Bedra]

On 05/18/2014 09:25 AM, James Reeves wrote:
 I don't want to seem like I'm badgering you. You have a lot of sound
 ideas. But I don't think we should be trying to work around insecure
 designs; we should be making it easier for people to design things
 securely.

 In terms of /specific/ things wrong that I've yet to mention: the
 middleware you have won't work for all session stores; only session
 stores that create a new session if a key is not found. Ideally
 session stores should reject session IDs that don't exist, rather than
 construct new ones.

 - James

After reading this thread I would like to make a couple of quick points.
I think that ring-auth is a step in the right direction and has the
right end goals in mind. To cut past the tension a bit I think that what
James is trying to say is let's try to make this less confusing and
work within the constraints of the current system. This really isn't a
bad idea. In fact, it is usually the way to succeed as an add-on to a
library. I understand all of the original points made by Brendan and
agree with almost all of them. That being said, I would encourage a
little more work here to try and blend just a bit more. I am happy to
take this off list and start a more productive discussion on how with a
smaller group if there's interest.

- Aaron




 On 18 May 2014 14:06, Brendan Younger brendan.youn...@gmail.com
 mailto:brendan.youn...@gmail.com wrote:



 On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote:

 On 18 May 2014 00:09, Brendan Younger brendan...@gmail.com
 wrote:

 For anyone else following along at home, I'll just
 re-iterate the benefits of using ring-auth versus trying
 to write your routes /just right/ to avoid the myriad
 security issues listed at OWASP.

 - If you initiate a session with a user over HTTP and
 later on that user logs in over HTTPS but you don't change
 the session id in the cookie, then everyone at the coffee
 shop has access to the authenticated session.  Ring-auth
 protects you from this.


 This is true, but I don't think we should be aiming to protect
 people from doing the wrong thing, so much as stop them from
 doing it in the first place.

 You seem to be aiming this middleware at people concerned
 about security, but not so concerned as to follow best
 practice. I'm a little baffled by this use-case.


 On the contrary, I'm protecting the user from oversights or bugs
 in the webapp.  Saying that there would be no security issues if
 only everyone wrote perfect software is a tautology.
  

  

 - If you use a CSRF middleware, but at any time leak the
 session id cookie over HTTP, then your CSRF protection is
 broken.  Ring-auth protects you from this.


 CSRF protection doesn't matter if your session is compromised.
 CSRF is a mechanism for sending a HTTP POST with the user's
 session ID. If you already have the session ID, there's very
 few reasons why you'd bother with CSRF.

 - If you ever send your CSRF token over HTTP, then the
 entire coffee shop can entice the user to Click here
 now! and send money to their off-shore account.
  Ring-auth helps you avoid sending the CSRF token in the
 clear.


 Hm? How? There doesn't appear to be anything in your code that
 looks for the CSRF token embedded in the response body.


 Because the :csrf-token is only present in the :auth-session, you
 can be sure that if your code has access to the :csrf-token, then
 it's communicating over HTTPS with the user.  I could not use
 ring-anti-forgery here because there is no provision to place the
 token in anything except :session.
   

 - If you get a request over HTTP which should have gone
 over HTTPS and respond with an error, but don't
 immediately delete the session, then everyone at the
 coffee shop has seen the authenticated session id
 (assuming you forgot to set Secure).  Ring-auth protects
 you from this.


 Again, I don't understand the use-case for this. Setting the
 secure flag on the session cookie is the clearly the better
 option. I'm having trouble seeing how you'd present this in
 your project's README.
  

 - If a user closes their browser on a public computer but
 forgets to sign off, the next user can go back to the
 site, and hopefully the browser has cached the cookie
 giving them access to the first user's account.  Ring-auth
 will help prevent this as soon as the Cache-Control
 header is set.


 A session idle-timeout isn't necessarily a bad 

Re: [ANN] ring-auth middleware for protecting sessions

[Aaron Bedra]

On 05/18/2014 09:25 AM, James Reeves wrote:
 I don't want to seem like I'm badgering you. You have a lot of sound
 ideas. But I don't think we should be trying to work around insecure
 designs; we should be making it easier for people to design things
 securely.

 In terms of /specific/ things wrong that I've yet to mention: the
 middleware you have won't work for all session stores; only session
 stores that create a new session if a key is not found. Ideally
 session stores should reject session IDs that don't exist, rather than
 construct new ones.

 - James

After reading this thread I would like to make a couple of quick points.
I think that ring-auth is a step in the right direction and has the
right end goals in mind. To cut past the tension a bit I think that what
James is trying to say is let's try to make this less confusing and
work within the constraints of the current system. This really isn't a
bad idea. In fact, it is usually the way to succeed as an add-on to a
library. I understand all of the original points made by Brendan and
agree with almost all of them. That being said, I would encourage a
little more work here to try and blend just a bit more. I am happy to
take this off list and start a more productive discussion on how with a
smaller group if there's interest.

- Aaron




 On 18 May 2014 14:06, Brendan Younger brendan.youn...@gmail.com
 mailto:brendan.youn...@gmail.com wrote:



 On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote:

 On 18 May 2014 00:09, Brendan Younger brendan...@gmail.com
 wrote:

 For anyone else following along at home, I'll just
 re-iterate the benefits of using ring-auth versus trying
 to write your routes /just right/ to avoid the myriad
 security issues listed at OWASP.

 - If you initiate a session with a user over HTTP and
 later on that user logs in over HTTPS but you don't change
 the session id in the cookie, then everyone at the coffee
 shop has access to the authenticated session.  Ring-auth
 protects you from this.


 This is true, but I don't think we should be aiming to protect
 people from doing the wrong thing, so much as stop them from
 doing it in the first place.

 You seem to be aiming this middleware at people concerned
 about security, but not so concerned as to follow best
 practice. I'm a little baffled by this use-case.


 On the contrary, I'm protecting the user from oversights or bugs
 in the webapp.  Saying that there would be no security issues if
 only everyone wrote perfect software is a tautology.
  

  

 - If you use a CSRF middleware, but at any time leak the
 session id cookie over HTTP, then your CSRF protection is
 broken.  Ring-auth protects you from this.


 CSRF protection doesn't matter if your session is compromised.
 CSRF is a mechanism for sending a HTTP POST with the user's
 session ID. If you already have the session ID, there's very
 few reasons why you'd bother with CSRF.

 - If you ever send your CSRF token over HTTP, then the
 entire coffee shop can entice the user to Click here
 now! and send money to their off-shore account.
  Ring-auth helps you avoid sending the CSRF token in the
 clear.


 Hm? How? There doesn't appear to be anything in your code that
 looks for the CSRF token embedded in the response body.


 Because the :csrf-token is only present in the :auth-session, you
 can be sure that if your code has access to the :csrf-token, then
 it's communicating over HTTPS with the user.  I could not use
 ring-anti-forgery here because there is no provision to place the
 token in anything except :session.
   

 - If you get a request over HTTP which should have gone
 over HTTPS and respond with an error, but don't
 immediately delete the session, then everyone at the
 coffee shop has seen the authenticated session id
 (assuming you forgot to set Secure).  Ring-auth protects
 you from this.


 Again, I don't understand the use-case for this. Setting the
 secure flag on the session cookie is the clearly the better
 option. I'm having trouble seeing how you'd present this in
 your project's README.
  

 - If a user closes their browser on a public computer but
 forgets to sign off, the next user can go back to the
 site, and hopefully the browser has cached the cookie
 giving them access to the first user's account.  Ring-auth
 will help prevent this as soon as the Cache-Control
 header is set.


 A session idle-timeout isn't necessarily a bad 

Re: Clojure 1.5 RC 14

[Aaron Bedra]

I tried it on 3 machines with the following results

Late '11 iMac running OS X 10.8.2: Failed with PermGen error
Mid '12 Macbook Air running OS X 10.8.2: Success
VM Running Arch Linux: Success

So I can't say it is easily reproducible. I'll see if I can find what is 
tripping things up on the iMac today.

-Aaron

On Feb 10, 2013, at 8:36 AM, Stuart Halloway stuart.hallo...@gmail.com wrote:

 Aaron:
 
 Were you simply running the test suite via the build?  On what hardware and 
 OS?
 
 Stu
 
 
 On Sat, Feb 9, 2013 at 9:16 PM, Aaron Bedra aaron.be...@gmail.com wrote:
 Yeah, I know what would fix it, but I would like to make sure the right 
 defaults are in place for folks who pull it down.
 
 -Aaron
 
 On Feb 9, 2013, at 4:29 PM, AtKaaZ atk...@gmail.com wrote:
 
 maybe jvm arg would help
 -XX:MaxPermSize=256m
 
 
 
 On Sat, Feb 9, 2013 at 11:17 PM, Aaron Bedra aaron.be...@gmail.com wrote:
 I just pulled it down locally and got the dreaded PermGen…
 
  [java] java.lang.OutOfMemoryError: PermGen space
  [java]  at 
 clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
  [java]  at clojure.lang.AFn.applyToHelper(AFn.java:161)
  [java]  at clojure.lang.AFn.applyTo(AFn.java:151)
  [java]  at clojure.core$apply.invoke(core.clj:617)
  [java]  at 
 clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
  [java]  at 
 clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
  [java]  at 
 clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
  [java]  at 
 clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
  [java]  at 
 clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
  [java]  at clojure.lang.AFn.call(AFn.java:18)
  [java]  at 
 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
  [java]  at java.util.concurrent.FutureTask.run(FutureTask.java:138)
  [java]  at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  [java]  at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  [java]  at java.lang.Thread.run(Thread.java:680)
  [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see ex-data 
 {:printed [#inst 2034-04-17T21:03:17.620-00:00 #inst 
 1979-04-19T20:14:07.477-00:00 #inst 1996-06-20T05:47:52.868-00:00 #inst 
 1995-08-15T20:51:41.920-00:00 #inst 2029-05-17T14:34:37.906-00:00 #inst 
 1987-06-05T21:05:23.305-00:00 #inst 1994-06-29T16:17:24.459-00:00 #inst 
 2035-12-03T09:39:44.754-00:00 #inst 2040-01-31T09:47:29.774-00:00 #inst 
 1973-06-09T04:53:42.029-00:00 #inst 1996-12-23T17:26:25.607-00:00 #inst 
 2022-07-01T16:33:57.846-00:00 #inst 1998-10-01T00:21:09.895-00:00 #inst 
 1973-01-11T17:43:58.457-00:00 #inst 1988-11-03T22:46:53.468-00:00 #inst 
 1982-01-31T11:34:19.796-00:00 #inst 2011-11-11T10:59:23.168-00:00 #inst 
 1973-06-07T12:37:22.285-00:00 #inst 1977-12-15T03:32:20.215-00:00 #inst 
 2047-10-15T13:51:28.327-00:00 #inst 2007-12-16T05:50:59.539-00:00 #inst 
 1980-05-01T01:58:13.802-00:00 #inst 1980-01-30T04:31:20.418-00:00 #inst 
 2044-09-16T14:38:34.919-00:00 #inst 1980-08-05T18:06:50.589-00:00 #inst 
 1978-12-31T11:40:11.800-00:00 #inst 2015-05-08T15:03:27.594-00:00 #inst 
 1975-06-28T17:24:08.855-00:00 #inst 1975-06-09T07:22:42.892-00:00 #inst 
 2026-03-20T07:01:01.296-00:00 #inst 2053-02-02T01:33:45.525-00:00 #inst 
 2002-04-11T18:43:38.347-00:00 #inst 1992-12-10T13:33:55.048-00:00 #inst 
 2015-04-16T20:53:45.670-00:00 #inst 2013-12-23T20:16:07.506-00:00 #inst 
 1978-09-02T09:42:03.175-00:00 #inst 1980-06-29T00:54:55.361-00:00 #inst 
 2061-11-04T22:40:32.484-00:00 #inst 2190-06-05T04:42:38.638-00:00 #inst 
 2038-03-19T09:05:50.002-00:00 #inst 2033-08-08T13:48:51.747-00:00 #inst 
 2077-11-18T06:09:19.557-00:00 #inst 1997-02-07T14:02:27.410-00:00 #inst 
 1988-08-20T07:11:32.623-00:00 #inst 1981-12-06T05:48:21.787-00:00 #inst 
 1980-08-15T09:40:38.877-00:00 #inst 2022-01-19T16:23:06.638-00:00 #inst 
 1994-09-09T17:35:55.052-00:00 #inst 1989-09-14T07:24:38.880-00:00 #inst 
 2050-03-30T21:22:42.054-00:00 #inst 2071-10-09T20:37:08.430-00:00 #inst 
 2083-04-19T10:25:43.108-00:00 #inst 1978-09-09T18:28:22.366-00:00 #inst 
 1979-11-03T08:18:42.779-00:00 #inst 1975-10-24T00:59:58.497-00:00 #inst 
 1974-10-10T14:40:29.360-00:00 #inst 1999-07-14T07:47:47.220-00:00 #inst 
 2215-11-23T00:36:40.748-00:00 #inst 2077-02-14T19:40:22.712-00:00 #inst 
 1985-03-14T12:30:49.064-00:00 #inst 2021-08-26T20:51:15.030-00:00 #inst 
 2013-04-22T10:48:12.278-00:00 #inst 2019-08-31T17:31:05.195-00:00 #inst 
 1975-04-21T22:13:33.370-00:00 #inst 1984-09-10T23:30:15.313-00:00 #inst 
 2053-11-10T05:36:02.093-00:00 #inst 1974-01-05T15:17:02.286-00:00 #inst 
 2058-09-18T08:11:45.895-00:00 #inst 1987-10-26T13:15:29.968-00:00 #inst 
 2001-10-01T08:12:45.877-00:00 #inst 2003-05-29T15:17:24.449-00:00 #inst 
 1981-02-07T01:20:10.665-00:00 #inst 1972

Re: Clojure 1.5 RC 14

[Aaron Bedra]

I just pulled it down locally and got the dreaded PermGen…

 [java] java.lang.OutOfMemoryError: PermGen space
 [java] at 
clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
 [java] at clojure.lang.AFn.applyToHelper(AFn.java:161)
 [java] at clojure.lang.AFn.applyTo(AFn.java:151)
 [java] at clojure.core$apply.invoke(core.clj:617)
 [java] at 
clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
 [java] at 
clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
 [java] at 
clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
 [java] at 
clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
 [java] at 
clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
 [java] at clojure.lang.AFn.call(AFn.java:18)
 [java] at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 [java] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 [java] at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 [java] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 [java] at java.lang.Thread.run(Thread.java:680)
 [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see ex-data 
{:printed [#inst 2034-04-17T21:03:17.620-00:00 #inst 
1979-04-19T20:14:07.477-00:00 #inst 1996-06-20T05:47:52.868-00:00 #inst 
1995-08-15T20:51:41.920-00:00 #inst 2029-05-17T14:34:37.906-00:00 #inst 
1987-06-05T21:05:23.305-00:00 #inst 1994-06-29T16:17:24.459-00:00 #inst 
2035-12-03T09:39:44.754-00:00 #inst 2040-01-31T09:47:29.774-00:00 #inst 
1973-06-09T04:53:42.029-00:00 #inst 1996-12-23T17:26:25.607-00:00 #inst 
2022-07-01T16:33:57.846-00:00 #inst 1998-10-01T00:21:09.895-00:00 #inst 
1973-01-11T17:43:58.457-00:00 #inst 1988-11-03T22:46:53.468-00:00 #inst 
1982-01-31T11:34:19.796-00:00 #inst 2011-11-11T10:59:23.168-00:00 #inst 
1973-06-07T12:37:22.285-00:00 #inst 1977-12-15T03:32:20.215-00:00 #inst 
2047-10-15T13:51:28.327-00:00 #inst 2007-12-16T05:50:59.539-00:00 #inst 
1980-05-01T01:58:13.802-00:00 #inst 1980-01-30T04:31:20.418-00:00 #inst 
2044-09-16T14:38:34.919-00:00 #inst 1980-08-05T18:06:50.589-00:00 #inst 
1978-12-31T11:40:11.800-00:00 #inst 2015-05-08T15:03:27.594-00:00 #inst 
1975-06-28T17:24:08.855-00:00 #inst 1975-06-09T07:22:42.892-00:00 #inst 
2026-03-20T07:01:01.296-00:00 #inst 2053-02-02T01:33:45.525-00:00 #inst 
2002-04-11T18:43:38.347-00:00 #inst 1992-12-10T13:33:55.048-00:00 #inst 
2015-04-16T20:53:45.670-00:00 #inst 2013-12-23T20:16:07.506-00:00 #inst 
1978-09-02T09:42:03.175-00:00 #inst 1980-06-29T00:54:55.361-00:00 #inst 
2061-11-04T22:40:32.484-00:00 #inst 2190-06-05T04:42:38.638-00:00 #inst 
2038-03-19T09:05:50.002-00:00 #inst 2033-08-08T13:48:51.747-00:00 #inst 
2077-11-18T06:09:19.557-00:00 #inst 1997-02-07T14:02:27.410-00:00 #inst 
1988-08-20T07:11:32.623-00:00 #inst 1981-12-06T05:48:21.787-00:00 #inst 
1980-08-15T09:40:38.877-00:00 #inst 2022-01-19T16:23:06.638-00:00 #inst 
1994-09-09T17:35:55.052-00:00 #inst 1989-09-14T07:24:38.880-00:00 #inst 
2050-03-30T21:22:42.054-00:00 #inst 2071-10-09T20:37:08.430-00:00 #inst 
2083-04-19T10:25:43.108-00:00 #inst 1978-09-09T18:28:22.366-00:00 #inst 
1979-11-03T08:18:42.779-00:00 #inst 1975-10-24T00:59:58.497-00:00 #inst 
1974-10-10T14:40:29.360-00:00 #inst 1999-07-14T07:47:47.220-00:00 #inst 
2215-11-23T00:36:40.748-00:00 #inst 2077-02-14T19:40:22.712-00:00 #inst 
1985-03-14T12:30:49.064-00:00 #inst 2021-08-26T20:51:15.030-00:00 #inst 
2013-04-22T10:48:12.278-00:00 #inst 2019-08-31T17:31:05.195-00:00 #inst 
1975-04-21T22:13:33.370-00:00 #inst 1984-09-10T23:30:15.313-00:00 #inst 
2053-11-10T05:36:02.093-00:00 #inst 1974-01-05T15:17:02.286-00:00 #inst 
2058-09-18T08:11:45.895-00:00 #inst 1987-10-26T13:15:29.968-00:00 #inst 
2001-10-01T08:12:45.877-00:00 #inst 2003-05-29T15:17:24.449-00:00 #inst 
1981-02-07T01:20:10.665-00:00 #inst 1972-02-20T03:11:10.395-00:00 #inst 
1971-05-15T02:20:31.099-00:00 #inst 1998-07-14T19:05:58.450-00:00 #inst 
2003-11-20T14:15:43.535-00:00 #inst 2032-11-06T18:16:34.702-00:00 #inst 
1974-09-12T12:12:41.530-00:00 #inst 1971-01-16T05:00:36.536-00:00 #inst 
1997-04-22T20:01:48.046-00:00 #inst 1980-02-10T15:10:37.905-00:00 #inst 
1978-05-09T10:52:42.400-00:00 #inst 1991-03-04T00:27:15.926-00:00 #inst 
1993-12-10T20:33:14.714-00:00 #inst 2045-04-04T10:42:38.474-00:00 #inst 
1972-05-30T18:17:49.692-00:00 #inst 1986-03-14T02:42:42.374-00:00 #inst 
2096-01-05T11:11:23.974-00:00 #inst 1997-12-03T18:50:28.444-00:00 #inst 
2009-05-12T23:48:54.862-00:00 #inst 2026-02-16T11:51:39.884-00:00 #inst 
1978-07-24T14:57:30.134-00:00 #inst 2003-08-21T22:16:56.540-00:00 #inst 
2000-04-06T12:22:12.441-00:00 #inst 2002-11-24T01:28:22.121-00:00 #inst 
1994-03-25T13:59:33.563-00:00 #inst 2071-07-24T05:23:57.700-00:00 #inst 

Re: Clojure 1.5 RC 14

[Aaron Bedra]

Yeah, I know what would fix it, but I would like to make sure the right 
defaults are in place for folks who pull it down.

-Aaron

On Feb 9, 2013, at 4:29 PM, AtKaaZ atk...@gmail.com wrote:

 maybe jvm arg would help
 -XX:MaxPermSize=256m
 
 
 
 On Sat, Feb 9, 2013 at 11:17 PM, Aaron Bedra aaron.be...@gmail.com wrote:
 I just pulled it down locally and got the dreaded PermGen…
 
  [java] java.lang.OutOfMemoryError: PermGen space
  [java]   at 
 clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
  [java]   at clojure.lang.AFn.applyToHelper(AFn.java:161)
  [java]   at clojure.lang.AFn.applyTo(AFn.java:151)
  [java]   at clojure.core$apply.invoke(core.clj:617)
  [java]   at 
 clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
  [java]   at 
 clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
  [java]   at 
 clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
  [java]   at 
 clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
  [java]   at 
 clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
  [java]   at clojure.lang.AFn.call(AFn.java:18)
  [java]   at 
 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
  [java]   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
  [java]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  [java]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  [java]   at java.lang.Thread.run(Thread.java:680)
  [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see ex-data 
 {:printed [#inst 2034-04-17T21:03:17.620-00:00 #inst 
 1979-04-19T20:14:07.477-00:00 #inst 1996-06-20T05:47:52.868-00:00 #inst 
 1995-08-15T20:51:41.920-00:00 #inst 2029-05-17T14:34:37.906-00:00 #inst 
 1987-06-05T21:05:23.305-00:00 #inst 1994-06-29T16:17:24.459-00:00 #inst 
 2035-12-03T09:39:44.754-00:00 #inst 2040-01-31T09:47:29.774-00:00 #inst 
 1973-06-09T04:53:42.029-00:00 #inst 1996-12-23T17:26:25.607-00:00 #inst 
 2022-07-01T16:33:57.846-00:00 #inst 1998-10-01T00:21:09.895-00:00 #inst 
 1973-01-11T17:43:58.457-00:00 #inst 1988-11-03T22:46:53.468-00:00 #inst 
 1982-01-31T11:34:19.796-00:00 #inst 2011-11-11T10:59:23.168-00:00 #inst 
 1973-06-07T12:37:22.285-00:00 #inst 1977-12-15T03:32:20.215-00:00 #inst 
 2047-10-15T13:51:28.327-00:00 #inst 2007-12-16T05:50:59.539-00:00 #inst 
 1980-05-01T01:58:13.802-00:00 #inst 1980-01-30T04:31:20.418-00:00 #inst 
 2044-09-16T14:38:34.919-00:00 #inst 1980-08-05T18:06:50.589-00:00 #inst 
 1978-12-31T11:40:11.800-00:00 #inst 2015-05-08T15:03:27.594-00:00 #inst 
 1975-06-28T17:24:08.855-00:00 #inst 1975-06-09T07:22:42.892-00:00 #inst 
 2026-03-20T07:01:01.296-00:00 #inst 2053-02-02T01:33:45.525-00:00 #inst 
 2002-04-11T18:43:38.347-00:00 #inst 1992-12-10T13:33:55.048-00:00 #inst 
 2015-04-16T20:53:45.670-00:00 #inst 2013-12-23T20:16:07.506-00:00 #inst 
 1978-09-02T09:42:03.175-00:00 #inst 1980-06-29T00:54:55.361-00:00 #inst 
 2061-11-04T22:40:32.484-00:00 #inst 2190-06-05T04:42:38.638-00:00 #inst 
 2038-03-19T09:05:50.002-00:00 #inst 2033-08-08T13:48:51.747-00:00 #inst 
 2077-11-18T06:09:19.557-00:00 #inst 1997-02-07T14:02:27.410-00:00 #inst 
 1988-08-20T07:11:32.623-00:00 #inst 1981-12-06T05:48:21.787-00:00 #inst 
 1980-08-15T09:40:38.877-00:00 #inst 2022-01-19T16:23:06.638-00:00 #inst 
 1994-09-09T17:35:55.052-00:00 #inst 1989-09-14T07:24:38.880-00:00 #inst 
 2050-03-30T21:22:42.054-00:00 #inst 2071-10-09T20:37:08.430-00:00 #inst 
 2083-04-19T10:25:43.108-00:00 #inst 1978-09-09T18:28:22.366-00:00 #inst 
 1979-11-03T08:18:42.779-00:00 #inst 1975-10-24T00:59:58.497-00:00 #inst 
 1974-10-10T14:40:29.360-00:00 #inst 1999-07-14T07:47:47.220-00:00 #inst 
 2215-11-23T00:36:40.748-00:00 #inst 2077-02-14T19:40:22.712-00:00 #inst 
 1985-03-14T12:30:49.064-00:00 #inst 2021-08-26T20:51:15.030-00:00 #inst 
 2013-04-22T10:48:12.278-00:00 #inst 2019-08-31T17:31:05.195-00:00 #inst 
 1975-04-21T22:13:33.370-00:00 #inst 1984-09-10T23:30:15.313-00:00 #inst 
 2053-11-10T05:36:02.093-00:00 #inst 1974-01-05T15:17:02.286-00:00 #inst 
 2058-09-18T08:11:45.895-00:00 #inst 1987-10-26T13:15:29.968-00:00 #inst 
 2001-10-01T08:12:45.877-00:00 #inst 2003-05-29T15:17:24.449-00:00 #inst 
 1981-02-07T01:20:10.665-00:00 #inst 1972-02-20T03:11:10.395-00:00 #inst 
 1971-05-15T02:20:31.099-00:00 #inst 1998-07-14T19:05:58.450-00:00 #inst 
 2003-11-20T14:15:43.535-00:00 #inst 2032-11-06T18:16:34.702-00:00 #inst 
 1974-09-12T12:12:41.530-00:00 #inst 1971-01-16T05:00:36.536-00:00 #inst 
 1997-04-22T20:01:48.046-00:00 #inst 1980-02-10T15:10:37.905-00:00 #inst 
 1978-05-09T10:52:42.400-00:00 #inst 1991-03-04T00:27:15.926-00:00 #inst 
 1993-12-10T20:33:14.714-00:00 #inst 2045-04-04T10:42:38.474-00:00 #inst 
 1972-05-30T18:17:49.692-00:00 #inst 1986-03-14T02:42:42.374-00:00 #inst 
 2096-01-05T11

[ANN] data.zip 0.1.1

[Aaron Bedra]

Hi everyone, 

Thanks to a patch from Justin Kramer, data.zip now works properly with the 
updates to data.xml. 

dependency
groupIdorg.clojure/groupId
artifactIddata.zip/artifactId
version0.1.1/version
/dependency

or

[org.clojure/data.zip 0.1.1]

Cheers,

Aaron

-- 
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] Accession, A Clojure library for Redis

[Aaron Bedra]

I put together a Redis library that focuses on the newer unified protocol
for communicating with Redis.  I am still playing a bit with the API and
there are still a few things left to do, but the library is fully usable.
 You can check the source out at

http://github.com/abedra/accession

and the docs at

http://abedra.github.com/accession

The library has been pushed to clojars, so in Leiningen speak

[accession 0.0.1]

Cheers,

Aaron

-- 
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: update to clojure.tools.cli

[Aaron Bedra]

It's strange that it hasn't made it to central yet. This is normally a few
hours on the high end and it's been over 12 now.  I double checked that the
release hit sonatype

https://oss.sonatype.org/content/repositories/public/org/clojure/tools.cli/0.2.0/

We might need to summon the all mighty Stuart Sierra to see if he knows
what could have happened.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Tue, Nov 1, 2011 at 1:59 PM, gaz jones gareth.e.jo...@gmail.com wrote:

 Hi,

 I have made some changes to tools.cli to fix an annoying bug arround
 boolean flags and the inability to collect 'trailing arguments'.
 Whilst gathering opinions on these changes, a few other suggestions
 were made such as removing all magic functions and System/exit calls.
 The update is therefore going to break the existing API which you
 obviously need to be aware of if you are currently using 0.1.0 and
 intend to upgrade to 0.2.0.

 The release has been cut, but the last time I checked it still hadn't
 hit maven central, so this is slightly advanced notice. To see details
 of the new api please see: https://github.com/clojure/tools.cli.

 There are a few things worth mentioning... support for grouped options
 has been removed, and the result of the call to cli is now a vector of
 [options, trailing arguments, usage banner] (originally it was just a
 hash of options). Automatic help is also no longer provided, an
 example of how to roll your own is at the bottom of the aforementioned
 page.

 a brief example of the differences (see the site for full details though):

 0.1.0:

 (cli [-p 8080 -v --foo bar some-filename]
 (optional [-p --port The port] #(Integer. %))
 (optional [-f --foo Some foos])
 (optional [-v --[no-]verbose Be chatty])

 = {:port 8080, :foo bar, :verbose true}

 0.2.0:

 (cli [-p 8080 --foo bar -v some-filename]
 [-p --port The port :parse-fn  #(Integer. %)]
 [-f --foo Some foos]
 [-v --[no-]verbose Be chatty :default false])

 = [{:port 8080, :foo bar, :verbose true}, [some-filename], *the
 usage banner*]

 Apologies for anyone upset by the timing / notification of the changes
 -- I will give greater advanced notice in future if there are any more
 breaking changes (hopefully there wont be :D)

 --
 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: Please try the alphas and betas!

[Aaron Bedra]

I'm with Phil on this one. The alphas and betas are synced to maven
central. You don't need any additional repositories in your project file.
They are announced on the list when they are cut and always have a brief
list of changes since the last release.  They are easy to find if you
follow this list.  You can also just look in maven central to find the
latest.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Mon, Oct 31, 2011 at 8:11 PM, Phil Hagelberg p...@hagelb.org wrote:

 On Mon, Oct 31, 2011 at 4:57 PM, JMatt jm...@jmatt.org wrote:
  Everyone that I know who writes clojure professionally or on a daily
 basis
  uses lein to start. The simplest way to expose far more people to alphas
 and
  betas is to add the sonatype repo to the default-repos function in lein:
 
 https://github.com/technomancy/leiningen/blob/1.x/src/leiningen/core.clj#L128
  Is there a reason that lein shouldn't / doesn't support the new repos?

 Adding snapshot repositories to the default repo list incurs an
 additional cost for checking every single snapshot dependency you add.
 I would rather have folks call out explicit usage of snapshots.
 Leiningen 2.0 will probably even remove Clojars snapshots by default.

 -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


-- 
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: Idiomatic record construction in 1.3

[Aaron Bedra]

On 10/26/2011 05:50 AM, Chas Emerick wrote:

Certainly are in ours: http://shop.oreilly.com/product/0636920013754.do

I'm sure they're mentioned in Programming Clojure 2ed as well.

Yes, they will be in Programming Clojure 2ed

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: clojure.string no namespace error

[Aaron Bedra]

Here's an example from the REPL that should get you going:

user = (require '[clojure.string :as str])
nil
user= (str/split-lines foo\nbar\r\nbaz\n)
[foo bar baz]

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 10/18/2011 05:52 AM, Omer Kudat wrote:

Hi all,

I've started to teach myself clojure recently, so apologies for a
potentially stupid question.

I'm using clojure-1.3.0.jar, downloaded very recently. I would like to
use clojure.string/split-lines, but I cannot access the namespace.

I've tried:
(import 'clojure.string)
(import 'string)
and
(:require [clojure.string :as str]))

The last one is from the documentation in the string.clj file embedded
in the jar. They all throw either a java.lang.ClassNotFoundException:
clojure.string or a java.lang.Exception: No namespace:
clojure.string.

Calling (all-ns) gives me a list of namespaces which does not include
string, and (find-ns) doesn't find clojure.string either.

Not sure what I'm doing wrong. Any pieces of wisdom?
Omer



--
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: Who will be at QCon SF?

[Aaron Bedra]

I will be there and am giving a talk in the functional web track

http://qconsf.com/sf2011/presentation/One+%28%29+to+Rule+them+All

See you on the coast.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 09/27/2011 06:28 PM, Demetrius Nunes wrote:

Hi guys,

I'd love to meet with fellow clojurians at QCon SF. How many of you 
will be there?


cheers!
Demetrius

--
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: clojure.contrib.base64

[Aaron Bedra]

This actually introduces an opportunity for a much larger set of utilities.

clojure.data.crypto

base64 is part of this idea anyways, and putting it in place along with
nice wrappers around the messy java crypto bits I think could provide a
significant win.  I have had to do this several times now and it would
be great to have in the future. The thing that always pushed me away was
relying on sun.misc when all of the jdks don't have it. 

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 10/06/2011 08:07 AM, Stuart Halloway wrote:
 I use Base64 encoding a lot and the slow implementation is hurting a
 lot. It's slower than Sun misc encoder/decoder
 and that one is very very slow. I was using Sun's implementation a bit
 and it took 80 seconds to encode a 56 MB file.
 Then I found this: http://migbase64.sourceforge.net/
 It loaded from a disk drive and encoded the same file in 0.3 seconds!
 Would it be possible to have Clojure contrib use an implementation
 like this and thus enable all Clojure developers to have lightning
 fast Base64 encoding/decoding? I know having everything implemented in
 clojure is a big thing around here but in case of Base64 encoding and
 regular expressions I think the language would benefit greatly by
 having implementations which are orders of magnitude faster than
 default implementations in java. Did I say regular expressions?
 http://www.tusker.org/regex/regex_benchmark.html
 Like Rich Hickey said: why should we reinvent file streams and sockets
 in each language?
 I think the same principle applies to Base64 and regular expressions,
 especially when in Clojure we have an opportunity to replace standard
 java implementations with ones that are orders of magnitude faster.
 What are your views on this?
 I too would like a fast base64. There are a few different things we could do:

 1. Vet the best Java one and link it from contrib.base64 (and possibly 
 deprecate the contrib as well).

 2. Approve a base64 lib for inclusion by reference in contribs.

 3. Write a fast clojure one (possibly a direct port of the project you link, 
 if it is the best).

 I have several Clojure projects that ship with no binary dependencies. This 
 is a maintenance virtue, which is why I think #3 is important. 

 If somebody writes a good one I will fast track getting it into contrib.

 Stu



-- 
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: how to use record as a value

[Aaron Bedra]

Assuming you want to do things with the record later, why not just
create it in the let binding

(let [foo (-car 1982 Mercedes)]
  ...)

or

(let [foo (car. 1982 Mercedes)]
  ...)

or even

(let [foo (map-car {:year 1982 :manufacturer Mercedes})]
  ...)

or if you must

(let [foo #user.car{:year 1982 :manufacturer Mercedes}]
  ...)

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 10/06/2011 01:27 PM, Razvan Rotaru wrote:
 Hi,

 I want to instantiate a record, but having the record type as value at
 runtime.

 Example:
 (defrecord car [year manufacturere])
 (defrecord bike [year manufacturere])
 (defrecord boat [year manufacturer])

 I want to do (new stuff 1982 Mercedes), but having the record type
 kept in the variable stuff. Something like:

 (let [stuff car]
   (new stuff 1982 Mercedes))

 (let [stuff bike]
   (new stuff 1990 Harley Davidson))

 Obviously new does not work. I'm gratefull for suggestions of how to
 do it best.

 Thanks,
 Razvan


-- 
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] Clojure 1.3 RC0

[Aaron Bedra]

And the supporting ticket in JIRA

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

On 09/14/2011 12:05 PM, Sean Corfield wrote:
 On Wed, Sep 14, 2011 at 8:45 AM, Paul Stadig p...@stadig.name wrote:
 This compiles fine in 1.2.1, but fails in 1.3.0-RC0
 Intentional removal:

 https://github.com/clojure/clojure/blob/master/changes.txt

 1.3 Disallow recur across try

-- 
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: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Aaron Bedra]

I have used jsvc in the past and found it to be a great tool. It allows you to 
configure which user the application runs as, and does proper detaching. It 
allows you to configure output streams and pid files to your liking. I have 
written some simple init scripts as well to make it very unix service like.  
All in all, I like it a lot more than lein daemon. Lein is a development and 
packaging tool. I wouldn't want it to be a dependency of my production systems.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Sep 7, 2011, at 10:41 AM, Bronsa brobro...@gmail.com wrote:

 the lein-daemon plugin seems to do that
 
 Il giorno 07/set/2011 16.27, Marko Kocić marko.ko...@gmail.com ha scritto:
  While we are at this topic, how do you run Clojure deamons. Do you have 
  some 
  scripts to set it up how?
  Is there a simple way to daemonize lein project?
  
  Regards,
  Marko
  
  -- 
  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: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Aaron Bedra]

On 09/07/2011 02:53 PM, Marko Kocić wrote:

Thanks for the tip about jsvc. I'll give it a try. Do you have some script 
examples to share, since having Linux service is exactly what I need?

Thanks,
Marko

I'll try and put together a few things including the code that 
implements the interface to get hooked up to jsvc.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: get keys from defrecord

[Aaron Bedra]

user= (defrecord MyRecord [a b c])
user.MyRecord
user= (def rec (user.MyRecord. one two three))
#'user/rec
user= (keys rec)
(:a :b :c)


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 08/29/2011 12:54 PM, Razvan Rotaru wrote:

Hi,

Assuming I have:

(defrecord myrecord [:a :b :c])

is there a way to get the list of keys from the record definition?

Thanks,
Razvan



--
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: JVM 7 support (invokedynamic)

[Aaron Bedra]

The version of ASM that is bundled in Clojure is very old.  This will
likely cause problems.  You are correct in looking to ASM 4 since it has
started supported the JSR-292 stuff and other Java 7 changes.  I am
planning on doing an extraction, update, and re-packaging of ASM in
Clojure as soon as Programming Clojure hits the printers.  This most
likely won't get started until October though because of conferences.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 08/29/2011 05:53 PM, Tal Liron wrote:
 Progress... is slow.

 I encouraged other people to try, so the least I can do now is to
 point you at some of the serious challenges.

 Right now I have what I think is a nice semi-generic mechanism for
 invokedynamic. It's called the Linker: it handles finding the target
 method handle, bootstrapping, and what I call restrapping, which is
 what happens when you guard it with an ILinkable (another new
 interface) and it fallbacks when a SwitchPoint is invalidated. There
 some various MethodHandle composing to make sure caller and target are
 both happy. I hope the Linker will make is easier to add
 invokedynamic in Clojure, and possibly in other projects.

 My real challenge is not there, however, but with adapting Clojure to
 JVM 7 more generally. invokedynamic requires V1.7 classes, and for
 V1.7 the stack frame map that was optional in V1.6 is now a
 requirement. This is overall a very good idea for moving the JVM
 forward (these maps are a huge help for HotSpot), but I have no doubt
 that it will create serious pain for any project that generates JVM
 bytecode and until JVM 7 now could afford to be sloppier with stack
 frames. The V1.7 verifier will simply not let you load classes that
 don't have perfectly aligned maps.

 ASM has very nice support for doing the stack frame arithmetic for
 you, but this is still being worked on in ASM 4 (trunk), and is not
 working in Clojure. I'm getting VerifyErrors specifically having to do
 with the mapping of try-catch blocks, and am working on debugging this
 via close look at CheckClassAdapter dumps. It's about as much fun as
 filling in tax forms. :/

 (I've added support for two new defines, -Dclojure.jvm7=true and
 -Dclojure.invokedynamic=true, so each can be turned on separately. To
 be clear, my problems right now are in -Dclojure.jvm7=true and
 -Dclojure.invokedynamic=false.)

 I've already patched one tiny part of ASM commons in order to add
 support for invokedynamic, and my work on debugging this may result in
 a more major patch to ASM. Assuming I do manage a fix. :/

 So, what can I say? It's the cutting edge, baby. In for a penny, in
 for a pound.

 -Tal
 -- 
 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: Peculiar transients behaviour

[Aaron Bedra]

Adding the additional zero did trigger the issue for me.  I have bumped 
the ticket into Release.Next.  Thanks for the clarification.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 08/25/2011 01:21 PM, Alan Malloy wrote:

Update: just built master, and issue still exists. If you want to be
sure you get it, just add another zero to the input range. I'll
mention that in the ticket as well.

On Aug 25, 10:14 am, Alan Malloya...@malloys.org  wrote:

I did, of course. I searched for transient, and didn't find any
describing this issue. And looking at the issue you link to, I still
don't see how it's related: it's a patch specifically for vectors, and
this code doesn't touch vectors; and it involves changes to a
transient leaking back into the original persistent, while this code
is about getting the wrong persistent object back after some changes.

I don't have a lot of experience with building clojure, but I'll try
compiling latest master and trying it out. In the meantime, did you
try this code more than once? Because it includes randomness,
sometimes it works without problems.

On Aug 25, 6:03 am, Aaron Bedraaaron.be...@gmail.com  wrote:








Please search through previous messages/tickets before posting new
issues.  This issue has been fixed as of commit da412909d36551a526ed and
will be included in the -beta2 release.  It was originally ticketed here:
http://dev.clojure.org/jira/browse/CLJ-816
(let [m (into {} (for [x (range 10)] [(rand) (rand)]))]
(println (count (distinct (map hash (keys m)
((juxt count identity) (persistent!
(reduce dissoc! (transient m) (keys m)
10
[0 {}]
Cheers,
Aaron Bedra
--
Clojure/corehttp://clojure.com
On 08/24/2011 04:32 AM, Alan Malloy wrote:

On Aug 24, 12:27 am, Alan Malloya...@malloys.orgwrote:

On Aug 23, 11:38 pm, Ken Wessonkwess...@gmail.comwrote:

What does zipmap do if the key seq contains duplications?

That was my instinct too, but (a) a few thousand numbers won't collide
very often at all given the problem space, and (b) some experimenting
indicates that the key-seq is always 100k elements large - no
duplicates.
HOWEVER, I did find the problem: the keys themselves don't collide,
but their hashes do. The number of elements that get messed up is
related to the number of hash collisions, but I still don't quite
understand how they interact.
Here's a modified code snippet that demonstrates the issue:
user(let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
  (println (count (distinct (map hash (keys m)
  ((juxt count identity) (persistent!
  (reduce dissoc! (transient m) (keys m)
10 ;; no collisions
[0 {}] ;; map is empty at the end
user(let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
  (println (count (distinct (map hash (keys m)
  ((juxt count identity) (persistent!
  (reduce dissoc! (transient m) (keys m)
6 ;; four collisions
[8 {0.30426231137219917 0.8531183785687654, 0.8893047006425385
0.4788315896128895, 0.47854633997540674 0.45133768991797785,
0.5265638224227486 0.7724779126227945}] ;; a four-element map that
reports its count as eight!!!
That last comment seems to indicate a very serious error somewhere:
not only is the transient map broken, but it creates a broken
persistent object. I'll file a JIRA issue for this, and see if I can
find out any more about the cause.
FWIW, I'm using 1.2.1 for the above output.

Ticket is athttp://dev.clojure.org/jira/browse/CLJ-829


--
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: JVM 7 support (invokedynamic)

[Aaron Bedra]

That's correct.  That is why Clojure/core hasn't prioritized this work.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 08/25/2011 08:37 AM, Meikel Brandmeyer (kotarak) wrote:

Hi,

Disclaimer: I have no clue whatsoever about the low-level JVM stuff.

I remember Rich saying in one of his talks/interviews, that 
invokedynamic is not very interesting for Clojure and that Clojure 
won't really benefit from it. I'm far from understanding these things. 
So details on what's improved would be very interesting, I guess.


Sincerely
Meikel

--
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: Peculiar transients behaviour

[Aaron Bedra]

Please search through previous messages/tickets before posting new 
issues.  This issue has been fixed as of commit da412909d36551a526ed and 
will be included in the -beta2 release.  It was originally ticketed here:


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

(let [m (into {} (for [x (range 10)] [(rand) (rand)]))]
(println (count (distinct (map hash (keys m)
((juxt count identity) (persistent!
(reduce dissoc! (transient m) (keys m)
10
[0 {}]

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 08/24/2011 04:32 AM, Alan Malloy wrote:

On Aug 24, 12:27 am, Alan Malloya...@malloys.org  wrote:

On Aug 23, 11:38 pm, Ken Wessonkwess...@gmail.com  wrote:


What does zipmap do if the key seq contains duplications?

That was my instinct too, but (a) a few thousand numbers won't collide
very often at all given the problem space, and (b) some experimenting
indicates that the key-seq is always 100k elements large - no
duplicates.

HOWEVER, I did find the problem: the keys themselves don't collide,
but their hashes do. The number of elements that get messed up is
related to the number of hash collisions, but I still don't quite
understand how they interact.

Here's a modified code snippet that demonstrates the issue:

user  (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
 (println (count (distinct (map hash (keys m)
 ((juxt count identity) (persistent!
 (reduce dissoc! (transient m) (keys m)
10 ;; no collisions
[0 {}] ;; map is empty at the end

user  (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
 (println (count (distinct (map hash (keys m)
 ((juxt count identity) (persistent!
 (reduce dissoc! (transient m) (keys m)
6 ;; four collisions
[8 {0.30426231137219917 0.8531183785687654, 0.8893047006425385
0.4788315896128895, 0.47854633997540674 0.45133768991797785,
0.5265638224227486 0.7724779126227945}] ;; a four-element map that
reports its count as eight!!!

That last comment seems to indicate a very serious error somewhere:
not only is the transient map broken, but it creates a broken
persistent object. I'll file a JIRA issue for this, and see if I can
find out any more about the cause.

FWIW, I'm using 1.2.1 for the above output.

Ticket is at http://dev.clojure.org/jira/browse/CLJ-829



--
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: JSON library for clojure 1.3

[Aaron Bedra]

Perhaps we can put these in core.incubator for now so they have a place 
to live in the 1.3 world.  The function for this library is the staging 
of things that are destined for core itself, so it might not be a bad idea.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 08/07/2011 10:19 AM, Stuart Sierra wrote:

Hi Arthur,

I think thos would make a reasonable addition. If you'll make a JIRA 
ticket in the backlog, I'll see if I can push it forward. Ultimately, 
it will be Rich's decision, of course.


Thanks,
-Stuart Sierra
clojure.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: Clojure 1.3 Beta 1

[Aaron Bedra]

It does, thanks for the explanation.  Stuart Halloway and I took a look 
at this yesterday and have started on a solution. I will create a ticket 
in JIRA to track it. The basic idea is that BigInts that are small 
enough to store their value in the Long portion of the BigInt will not 
do the extra work if the end result doesn't spill over into BigInt 
territory. We tested some simple addition stuff last night and found it 
to be much faster.


Thanks for your help.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 07/30/2011 09:10 PM, Mark Engelberg wrote:

On Fri, Jul 29, 2011 at 10:09 AM, abedraaaron.be...@gmail.com  wrote:

Can you provide a couple of concrete examples for this?  I will make
the ticket in JIRA and start working on it, but I am spread thin on
quite a few things at the moment and these examples will help a lot.

Cheers,

Aaron Bedra

Sure, let me elaborate on what I mean with a short but somewhat
contrived example.

Consider the following definition of factorial:
(defn fact [n]
   (loop [n n result 1]
 (if (zero? n) result
 (recur (dec n) (* result n)

factorial overflows as soon as you get to (fact 21).  Now, let's say
you don't know exactly at what point factorial overflows.  So to be on
the safe side, the recommended procedure is to pass a bigint to the
factorial function and rely on contagion to make this work, i.e.:
(fact 21N)

The problem is that (fact 21N) in 1.3 is slower than (fact 21) in 1.2.
  We're paying a big performance by relying on contagion.

Here's why:
In Clojure 1.2, the first 20 multiplications are done with longs, and
only when it overflows then the last multiplication is done with
bigints.
In Clojure 1.3, all the multiplications are done with bigints which are slow.

When this issue was first raised back when Rich floated the idea of
primitive ops with bigint contagion, he created the stub class saying
that eventually the plan would be to come up with a better version of
bigint than Java's BigInteger class in the sense that it would reduce
and compute with longs (and maybe ints) when in that range.

Now, factorial is contrived because overflow happens fairly early in
the process, yet the difference is still measurable.  For many of the
statistics I compute in my work project, a substantial number of the
computations happen within the long range, but sometimes they
overflow.  1.3 kills performance for me if I try to leverage
contagion; I must convert everything to the overflow ' operators.

I was thinking about this recently because I was rewriting my
clojure.contrib.math to support 1.3.  One of the things I had to think
about was how the expt function should behave.  It would be most
compatible with 1.3's outlook if
(expt primitive-long primitive-long) returned a primitive-long or
generated an overflow error.  But to implement expt in this way, I
also have to think about the fact that for many cases, exponentiation
will overflow.  So what should users do?  One option is I could also
provide a expt' function.  But I ruled this out because then I get
caught up in a proliferation of two versions (regular and ') of nearly
every math function.  It might be feasible to provide a single version
of expt that supports primitive math and then allow users to use
contagion (e.g., (expt 2N 100)), but this contagion will hurt
performance.  So the only viable option I see is to implement expt
with boxed numbers and the *' operator, maintaining the same
performance profile as 1.2, but missing out on the possibility of
making the primitive math people happy.

Does this explanation 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: Java 7 is out!

[Aaron Bedra]

On 07/28/2011 11:54 AM, Daniel Gagnon wrote:

So, what does it means for Clojure?

Faster execution? Some new interesting stuff in the standard Java library?

And I remember there was something about forkjoin that would be good 
for Clojure, what about that?

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


The short answer here is that the new platform features in Java 7 will 
not get any attention for quite some time.  There is a lot of 
stabilization and maturity that has to happen here before we jump into 
implementation.  There is also the story of the backports.  Since 
Clojure still targets 1.5, this is walking the line of a non-starter.  
This can eventually change, but the benefit that we would see versus the 
impact to the language doesn't make sense right now.


That being said, given other benefits like the new garbage collector and 
more hotspot optimizations, it is very likely that Clojure sees 
performance improvements without doing anything.  We will be taking the 
time to make sure that Clojure runs on Java 7 and address issues that 
come up, but the invoke dynamic and method handle stuff is not in the 
immediate pipeline.  Neither is adding the Java language bits like 
Diamond, try-with-resources, or the rest of them into the Java parts of 
Clojure.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: clojure.contrib.profile crashes

[Aaron Bedra]

The first thing I do when experiencing something strange like this is to 
remove anything possible.  In this case, try taking Leiningen out of the 
picture and just running it directly.  I am thinking that Colin is 
correct in his assessment that this is related to the bug that has 
already been filed.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 07/24/2011 11:40 PM, Sunil S Nandihalli wrote:

Hi Aaron Bedra,
 Thanks for your quick response. Sorry I could not get back to you 
with the information you asked for sooner..


 I am using

user *clojure-version*
{:major 1, :minor 2, :incremental 1, :qualifier }

My project.clj is as follows...

(defproject bitvector 1.0.0-SNAPSHOT
  :description FIXME: write description
  :dependencies [[org.clojure/clojure 1.2.1]
 [org.clojure/clojure-contrib 1.2.0]
 [clj-iterate 0.95-SNAPSHOT]]
  :dev-dependencies [[swank-clojure 1.4.0-SNAPSHOT]
 [clojure-source 1.2.1]]
  :main bitvector.core)

do you have any idea why I am getting this out of range thing when I 
use clojure.contrib.profile?


Thanks again,
Sunil.

On Fri, Jul 22, 2011 at 4:51 AM, Aaron Bedra aaron.be...@gmail.com 
mailto:aaron.be...@gmail.com wrote:


What version of Clojure are you running?

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 07/21/2011 06:12 PM, Sunil S Nandihalli wrote:

The reason I am not posting the code is because I am not able to
reproduce this on a simple case. I was just hoping some of you
may have some insight with out the code..
Thanks,
Sunil.

On Fri, Jul 22, 2011 at 3:29 AM, Sunil S Nandihalli
sunil.nandiha...@gmail.com mailto:sunil.nandiha...@gmail.com
wrote:

Hello everybody,
 I have used the profiler successfully in the past. But some
how it is repeatedly crashing with the following stack trace.

Value out of range for int: 17069635385
  [Thrown class java.lang.IllegalArgumentException]
Restarts:
 0: [QUIT] Quit to the SLIME top level
Backtrace:
  0: clojure.lang.RT.intCast(RT.java:950)
  1: clojure.lang.RT.intCast(RT.java:922)
  2:
clojure.contrib.profile$summarize$fn__3252.invoke(profile.clj:88)

  3: clojure.core$r.invoke(core.clj:799)
  4: clojure.contrib.profile$summarize.invoke(profile.clj:85)
  5: bitvector.core$eval4530.invoke(NO_SOURCE_FILE:1)
  6: clojure.lang.Compiler.eval(Compiler.java:5424)
  7: clojure.lang.Compiler.eval(Compiler.java:5391)
  8: clojure.core$eval.invoke(core.clj:2382)
  9: swank.core$eval650$fn__651.invoke(core.clj:409)
 10: clojure.lang.MultiFn.invoke(MultiFn.java:163)
.
.
.
.

Before I bother you all with actual code which might get
messy, does anybody have any suggestion as to why this is
happening..?
Thanks,
Sunil.


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



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Alright, fess up, who's unhappy with clojurescript?

[Aaron Bedra]

First:

* I respect your opinions. I am glad that you have taken the time to 
start exploring ClojureScript


Second:

* Dude, stop trolling. This is the second time you have started a thread 
with a baiting subject line and no clear end goal. Your opinions are 
yours, and I have no problems with that, however, this offers no 
constructive feedback. If you would like to write your own Clojure on 
JavaScript, that would be a great way to learn and get exactly what you 
want out of it.  I encourage you to look at the ClojureScript source 
code for ideas while you are doing your implementation.


* If you want to start discussions like this, please do so elsewhere.  
If you have something in particular you want to discuss about Clojure or 
ClojureScript, then this is the place.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 07/24/2011 08:19 AM, James Keats wrote:

Alright, to be honest, I'm disappointed.

First of all, congrats and good job to all involved in putting it out.
On the plus side, it's a good way to use the Google Closure javascript
platform.

On the minus, imho, that's what's wrong with it.

Google Closure is too Java. It's not idiomatic JavaScript. I find it
disappointing that rather than porting from a functional language like
Clojure straight to another functional language like Javascript, the
google closure with its ugly Java-isms is right there obnoxiously in
the middle.

Then, there's the elephant in the room, and that elephant is Jquery. I
believe any targetting-javascript tool that misses out on jquery-first-
and-foremost is missing out on the realities of javascript in 2011.
Jquery is huge in its community and plugins, and it has tons of books
and tutorials. In much the same way that you can have lots of libs on
the JVM, there are lots of plugins for jquery. So much so that the
latest edition of Javascript: the Definitive Guide includes a chapter
on it; quoted:

Because the jQuery library has become so widely used, web developers
should be fa-
miliar with it: even if you don’t use it in your own code, you are
likely to encounter it
in code written by others.

Then, the Google Closure compiler is a moot point. Everyone by now
already has a copy of jquery from the Google CDN and linking to it in
your code will not download it any further after your first visit to a
website that does so. In any case, it's already small and fast.

Then there's rhino/jvm. I would much rather an in-browser focus.

I'm tempted to fork clojurescript and redo it in javascript perhaps
so that seamless interop with jquery would be the main priority.

Discuss?





--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Leiningen on OpenBSD

[Aaron Bedra]

It appears that the ports tree does offer a sun jdk now that you can 
build, but it is 1.7.  If you are running 4.9 and are using the jdk from 
the ports tree, this could also be the source of your problem.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 07/23/2011 09:57 PM, Aaron Bedra wrote:

The java that you cobble together for openbsd is really a mess. Unless they 
have a working version of the standard jdk, I wouldn't bother. I love and 
support the openbsd project, but I stay away from any kind of java on openbsd.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On Jul 23, 2011, at 10:24 AM, Scott Scitesrailca...@gmail.com  wrote:


While walking through the Clojure/Heroku/Database tutorial the Leiningen REPL 
fails to display a prompt.  When I control-c out, the final output before 
closing shows a connection being made and the prompt.  If I change out of the 
project directory and lein repl I get the connection and the prompt as I would 
expect.

Is there a solution to this problem?  How might I debug the issue?  Should I 
file a bug with the Leiningen project?

Thank you.

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



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Leiningen on OpenBSD

[Aaron Bedra]

The java that you cobble together for openbsd is really a mess. Unless they 
have a working version of the standard jdk, I wouldn't bother. I love and 
support the openbsd project, but I stay away from any kind of java on openbsd.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On Jul 23, 2011, at 10:24 AM, Scott Scites railca...@gmail.com wrote:

 While walking through the Clojure/Heroku/Database tutorial the Leiningen REPL 
 fails to display a prompt.  When I control-c out, the final output before 
 closing shows a connection being made and the prompt.  If I change out of the 
 project directory and lein repl I get the connection and the prompt as I 
 would expect.
 
 Is there a solution to this problem?  How might I debug the issue?  Should I 
 file a bug with the Leiningen project?
 
 Thank you.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To 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.contrib.profile crashes

[Aaron Bedra]

What version of Clojure are you running?

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 07/21/2011 06:12 PM, Sunil S Nandihalli wrote:
The reason I am not posting the code is because I am not able to 
reproduce this on a simple case. I was just hoping some of you may 
have some insight with out the code..

Thanks,
Sunil.

On Fri, Jul 22, 2011 at 3:29 AM, Sunil S Nandihalli 
sunil.nandiha...@gmail.com mailto:sunil.nandiha...@gmail.com wrote:


Hello everybody,
 I have used the profiler successfully in the past. But some how
it is repeatedly crashing with the following stack trace.

Value out of range for int: 17069635385
  [Thrown class java.lang.IllegalArgumentException]
Restarts:
 0: [QUIT] Quit to the SLIME top level
Backtrace:
  0: clojure.lang.RT.intCast(RT.java:950)
  1: clojure.lang.RT.intCast(RT.java:922)
  2:
clojure.contrib.profile$summarize$fn__3252.invoke(profile.clj:88)
  3: clojure.core$r.invoke(core.clj:799)
  4: clojure.contrib.profile$summarize.invoke(profile.clj:85)
  5: bitvector.core$eval4530.invoke(NO_SOURCE_FILE:1)
  6: clojure.lang.Compiler.eval(Compiler.java:5424)
  7: clojure.lang.Compiler.eval(Compiler.java:5391)
  8: clojure.core$eval.invoke(core.clj:2382)
  9: swank.core$eval650$fn__651.invoke(core.clj:409)
 10: clojure.lang.MultiFn.invoke(MultiFn.java:163)
.
.
.
.

Before I bother you all with actual code which might get messy,
does anybody have any suggestion as to why this is happening..?
Thanks,
Sunil.


--
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: Fixing Java Apache Class error

[Aaron Bedra]

Not to derail this too much, but what do you need from clj-http?

On 07/20/2011 09:35 AM, octopusgrabbus wrote:

Same problem. I'm starting Clojure like this, and have rebuilt clj-
http with cake deps

exec java -cp  /usr/share/java/jline.jar:/usr/share/java/clojure.jar:/
usr/share/java/clojure-contrib.jar:/usr/share/java/commons-
logging-1.1.1.jar:/home/cnorton/git_build/clj-http/clj-
http-0.1.3.jar$extra_classpath clojure.main $@

On Jul 20, 9:31 am, Islon Schererislonsche...@gmail.com  wrote:

It seems like you didn't put the apache HTTP client jars in your path. Are
you using leiningen? If so you only need to run lein deps and it will
download the dependencies.


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

tools.logging 0.2.0 released

[Aaron Bedra]

Alex Taggart has been busy with upgrades to tools.logging recently and a 
few people have asked for a new release.  I cut 0.2.0 last night and it 
is in Central now and available for use.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: jdbc and postgresql type problem

[Aaron Bedra]

Silly question, but which version of java.jdbc are you using?  Up until 
0.0.3 I had no end of troubles with psql because of the batchExecute issue.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 07/11/2011 02:48 AM, Brian Carper wrote:

On Jul 10, 4:52 pm, Wilfredyowilf...@gmail.com  wrote:

I'm at a bit of a loss. UPDATE comments SET approved='1' WHERE id =
'1' works fine in psql. approved is a boolean field, so is this an
issue with the SQL library producing incorrect SQL?

I think this is an oddity with the JDBC driver for PostgreSQL.  The
driver doesn't seem to like doing automatic typecasting.  Try this:

(sql/update-values :comments
[id = cast(? as integer) id]
;; alternatively id = ?::integer
{:approved true})

Or you could (Integer/parseInt id) to do the cast before you pass it
as parameter, though in either case you should validate your id before
casting, if you want to avoid dying on poorly-formed input.


--
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: I cannot scroll up down REPL in konsole

[Aaron Bedra]

I haven't had any issues in gnome-terminal, xterm, or iterm2.  I suggest
trying another terminal to see if it's a problem with konsole or your setup.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Wed, Jul 6, 2011 at 9:21 PM, Antonio Recio amdx6...@gmail.com wrote:

 In the default terminal of KDE linux, konsole, when I am using REPL I
 cannot scroll up down. When I get a long message I can only read the last
 lines. Is there any way to scroll up down the REPL in konsole (or other
 linux terminal)? (I think it is possible in emacs or vim, but I am
 interested in konsole.)

 --
 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: Please stand firm against Steve Yegge's yes language push

[Aaron Bedra]

Although I agree with the ideas here that have already been stated by 
Rich, I am concerned about this message.  There is no reason to stand 
against somebody.  Steve is welcome to his own opinions and is an 
incredibly smart guy.  He should be respected as a peer.  His opinions 
happen to be different from Clojure's core values, and that is ok.  
Steve will either choose to use Clojure or go another path, and that is 
alright.


The way for Clojure to grow is by embracing it's core values and showing 
the world that careful choices do lead to the right outcome.  Let's not 
turn this into us against Steve.  There's nothing productive there.  
Focus your energy instead on writing great Clojure code and sharing it 
with everyone else.  Get people excited about Clojure who want something 
more powerful, and show them what is truly possible.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 07/01/2011 03:59 PM, James Keats wrote:

Hi all. I've been looking at Clojure for the past month, having had a
previous look at it a couple of years ago and then moved on to other
things only to return to it now.

Over the past decade I have looked at many languages and many ways of
doing things. People may say this language or that language is
general purpose, but the fact remains that languages have their
niches in which they excel and beyond which it'd be foolish to
venture.

Clojure should not attempt be a mass success language or worry about
its Tiobe index ranking.

Clojure, the way I see it, is most suitable for the advanced
independent developer. It is a language in the image of its creator,
Rich Hickey. It's not a language for the factory hen. It won't become
the next Java. Java already fills that niche, and despite what some
may say, I don't see it going away anytime soon.

I don't feel Clojure needs to grow - in terms of size of language.
In fact it would worry me enormously if Clojure's path is to grow in
size. It is fundamentally unsuited for that. If anything I wish for it
to shrink even further and further.

A Rich Hickey's quote comes to mind:
• (paraphrased) Most Clojure programmers go through an arc.  First
they think “eww, Java” and try to hide all the Java.  Then they think
“ooh, Java” and realize that Clojure is a powerful way to write Java
code
and As I've said in my talks, most Clojure users go from eww, Java
libs to ooh, Java libs, leveraging the fact there there is already
a lib for almost anything they need to do. And using the lib is
completely transparent, idiomatic and wrapper free. - Google verbatim
for sources.

Whereas when Steve Yegge writes: which means that everyone (including
me!) who is porting Java code to Clojure (which, by golly, is a good
way to get a lot of people using Clojure) is stuck having to rework
the code semantically rather than just doing the simplest possible
straight port.  The more they have to do this, the more you're going
to shake users off the tree. all I could think on reading this is
horror, horror, oh God, horror!!!; he really doesn't get it. First,
he shouldn't be porting Java code to clojure, Second, Clojure IS
fundamentally different from Java, and third, such said users who
don't want to touch Java should not touch Clojure.

Clojure shouldn't worry about growing; java already has innumerable
libs. Clojure, imho, should continue its - what I would dub -
middleware begone! path, in which it'd provide an end-to-end, down-
to-the-metal comprehensible system that an individual developer can
get his head round and know exactly what's happening with his code and
its environment here and everywhere.

I could write more, but I have to run. Regards.
J.



--
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: Please stand firm against Steve Yegge's yes language push

[Aaron Bedra]

And we certainly will.  And, as I stated in my previous email, we will 
do so with actions.  My point is simply that I would rather not spend 
energy even talking about this, but rather demonstrating that we stand 
by our decisions by continuing on in the fashion Rich started, and many 
after have followed.  I don't see how arguing about the merits of one 
person or another helps in any situation, or their technical influence 
or credibility.  I would rather just put all that behind us.


As you asked, Clojure/core will continue in the fashion that it always 
has.  We welcome all ideas and opinions, though we will always think 
carefully about which ones are accepted into the Clojure language.  You 
can rest easy knowing that the effort you put into building up your 
Clojure knowledge will not go to waste :)


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 07/02/2011 03:59 PM, James Keats wrote:


On Jul 2, 6:41 pm, Stefan Kamphausenska2...@googlemail.com  wrote:

FWIW,

However, as Aaron pointed out, I'd rather a more tolerant, pleasant
community.

Kind regards,

A month ago I asked a question here that barely a minute after
clicking send realized was utterly dumb. It reminds of an anecdote
about an (MIT?) professor who'd insist on whomever asks him a question
to explain in some detail what they understand and what they don't
understand, and oftentimes when people do so come to an Oh! moment
of sudden understanding before he'd even answered just out of
formulating the problem.

That utterly dumb question got many tolerant, pleasant answers. :-)

I would draw a thick line between the community's response to someone
who'd ask an utterly dumb question - I don't me specifically, but any
newcomer - and someone who'd insist upon the creator of a carefully
considered and crafted solution and its community to change their
culture outright. If I, and people like me who are willing to put
their nose to the grindstone, read the books and watch the videos
umpteen times over till they get it through and through, to become
invested in clojure and its future, then we need a firm reassurance
that ludicrous demands like those are firmly resisted, and believe
it's imperative to implore clojure core to do so.

Kind regards, :-)
J



--
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: Current state of clojure-contrib?

[Aaron Bedra]

You can find your answers at

http://dev.clojure.org/display/design/Contrib+Library+Names

As to where things are going or have ended up.  The most used libs are 
logging and jdbc, so an project.clj file that used these would look like


[org.clojure/java.jdbc 0.0.2]
[org.clojure/tools.logging 0.1.2]

Cheers,

Aaron
--
Clojure/core
http://clojure.com

On 07/01/2011 07:27 AM, Mark Derricutt wrote:

Hey all,

Whats the current state of clojure-contrib for 1.3?  I remember seeing 
a wiki post or something awhile ago with new package layouts/maven 
settings etc but can't seem to find it now ;(


Mark


--
Great artists are extremely selfish and arrogant things — Steven 
Wilson, Porcupine Tree

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



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: ClassCastException on 'clojure.data.json/print-json'

[Aaron Bedra]

The process for getting code into Clojure's official libraries is the 
same as it is for the language.  We work with patches submitted to JIRA 
(http://dev.clojure.org/jira) rather than github pull requests.  It 
allows us to track things a little bit easier.  We also require that all 
contributors sign the Clojure contributor agreement (referred to as the 
CA).  I did a quick check and didn't see your name on the list.  Please 
forgive me if I didn't search properly and you are already on there.


For this issue in particular, it will probably be easiest to just let 
Stuart fix things up quickly.  If you are interested in contributing in 
the future I encourage you to get your CA in and sign up for an account 
on JIRA.  Make sure not to send your CA certified or require a signature 
as it will most likely bounce back to you.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 06/30/2011 10:09 AM, Timothy Washington wrote:
I already made a quick fix and put in a github pull request. You can 
do whichever is easier.



Tim Washington
twash...@gmail.com mailto:twash...@gmail.com
416.843.9060



On Thu, Jun 30, 2011 at 8:52 AM, Stuart Sierra 
the.stuart.sie...@gmail.com mailto:the.stuart.sie...@gmail.com wrote:


clojure.core/*out* is usually a PrintWriter, but its docstring
only specifies that it's a Writer. So it's a bug for data.json to
assume PrintWriter.  I'll fix it.

-Stuart Sierra
clojure.com http://clojure.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
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%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 


--
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 1.3 Beta 1

[Aaron Bedra]

It's already on the list in the ticket 
http://dev.clojure.org/jira/browse/CLJ-815


On 06/24/2011 11:31 PM, Alan Malloy wrote:

What about juxt? Can we get rid of the Alpha - name subject to
change in the docstring there?

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Clojure 1.3 Beta 1

[Aaron Bedra]

Also see the original design page on the wiki for where things ended up.

http://dev.clojure.org/display/design/Contrib+Library+Names

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 06/24/2011 04:53 PM, Stuart Sierra wrote:
The monolithic clojure-contrib project is not being actively 
maintained. It does not currently build on Clojure 1.3 beta. All new 
development is happening in new contrib libraries under 
http://github.com/clojure


Most of the libraries from old clojure-contrib have been released as 
new contrib libraries.  The first release of each new contrib 
library should be source-compatible with the old version; the only 
change should be the name of the namespace.  All the new contrib 
libraries should be source-compatible with both Clojure 1.2 and 1.3, 
unless they require features only available in 1.3.


A list of new contrib libraries with reference to the old 
namespaces is at 
http://dev.clojure.org/display/design/Contrib+Library+Names


So, if you are currently using Clojure 1.2, your upgrade path might 
look something like this:


 1. Find the new contrib library you need
 2. Add a dependency on the new library
 3. Replace the clojure.contrib.* namespace with the new equivalent
 4. Test your app, fix problems
 5. Repeat steps 1-4 for each contrib library you use
 6. Remove the dependency on old clojure-contrib
 7. Replace your dependency on Clojure 1.2 with 1.3-beta1
 8. Test your app, fix problems
 9. Profit!

I realize this may seem confusing. But it is intended to make things 
easier in the long run. We do believe this is the best way to 
encourage more development of contributed libraries, which had stalled 
under the old clojure-contrib repository because it was getting too 
big to manage. It also means you can include just the libraries you 
need for your app, instead of one big JAR.


There is currently no plan for a Clojure 1.3-compatible release of 
old clojure-contrib. However, if people with commit access to old 
clojure-contrib have time to fix all the little things that prevent it 
from building under 1.3, I will consider publishing one last release.


As always, I will be here to help and answer questions where I can. 
Thanks, everyone!


-Stuart Sierra
clojure.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: Clojure 1.3 Beta 1

[Aaron Bedra]

Everything is now beta.  deftype/defrecord have had some changes 
recently, but they are ready to rock.  I will update the docstrings today.


Aaron

On 06/24/2011 09:29 AM, smf...@googlemail.com wrote:

Just a quick question (before I forget): Is deftype/defrecord still
alpha? Or is the Alpha - subject to change note in the docstrings
just an oversight?

Thanks,
-F.M.

On 23 Jun., 20:43, Chris Redingerch...@clojure.com  wrote:

Clojure 1.3 Beta 1 is now available at

http://clojure.org/downloads

All of you that were waiting for the official beta, now's your chance to
start using it! We look forward to your feedback.

Here are the list of changes:

  0 Changes from 1.3 Alpha 7 to 1.3 Beta 1
  1 Changes from 1.3 Alpha 7 to 1.3 Alpha 8
  2 Changes from 1.3 Alpha 6 to 1.3 Alpha 7
  3 Changes from 1.3 Alpha 5 to 1.3 Alpha 6
  4 Changes from 1.3 Alpha 4 to 1.3 Alpha 5
  5 Changes from 1.3 Alpha 3 to 1.3 Alpha 4
  6 Changes from 1.3 Alpha 2 to 1.3 Alpha 3
  7 Changes from 1.3 Alpha 1 to 1.3 Alpha 2
  8 Changes from 1.2 to 1.3 Alpha 1
  9 About Alpha Releases

Issue Tracking:http://dev.clojure.org/jira

= 0 Changes from 1.3 Alpha 8 to 1.3 Beta 1 (06/21/2011)

   * Fix weak hold-unto-head problem in partition-by (CLJ-769)
   * Protocol's method cache falls back to using a map when shift-mask
 table won't work (CLJ-801)

= 1 Changes from 1.3 Alpha 7 to 1.3 Alpha 8 (05/27/2011)

   * improvements to print/read for defrecords/deftypes
 (CLJ-800, CLJ-794)
   * numeric fixes (CLJ-795, CLJ-802)
   * fix compiler handling of recur mismatch (CLJ-671)
   * improved method resolution (CLJ-789)
   * allow record fields that collide with method names

= 2 Changes from 1.3 Alpha 6 to 1.3 Alpha 7 (05/13/2011)

   * print/read syntax for defrecords (CLJ-374)
   * several primitive math improvements:
 (CLJ-184, CLJ-784, CLJ-690, CLJ-782)
   * case now handles hash collisions (CLJ-426)

= 3 Changes from 1.3 Alpha 5 to 1.3 Alpha 6 (03/11/2011)

   * improved startup time
   * several holding onto head fixes (CLJ-708)
   * internal keyword map uses weak refs
   * fix perf on some numeric overloads (CLJ-380)
   * detect and report cyclic load dependencies (CLJ-8)

= 4 Changes from 1.3 Alpha 4 to 1.3 Alpha 5 (01/14/2011)

   * pprint respects *print-length*
   * into-array now coerces numeric types
   * Java's line.separator property for newline
   * compilation and deployment via Maven

= 5 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 (12/12/2010)

   * normalized unchecked-* fn names
   * added *unchecked-math* support
   * fixes to binding conveyance (and *agent*)

= 6 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 (11/05/2010)

   * fixed filter performance issue introduced in 1.3A2
   * with-redefs macro (useful for stubbing)
   * print-table

= 7 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 (10/10/2010)

   * code path for using vars is now *much* faster for the common case,
 and you must explicitly ask for :dynamic bindability
   * new: clojure.reflect/reflect
http://dev.clojure.org/display/design/Reflection+API
   * new: clojure.data/diff

= 8 Changes from 1.2 to 1.3 Alpha 1 (09/23/2010)

   * enhanced primitive support
 (http://dev.clojure.org/display/doc/Enhanced+Primitive+Support)
   * better exception reporting
   * ancillary namespaces no longer auto-load on startup:
 clojure.set, clojure.xml, clojure.zip

= 9 About Alpha Releases

1.3 is the first release of Clojure that will include a series of
alpha builds. We are adding these builds to support maven and
leiningen users, who want a specific artifact that they can target (as
opposed to building from master or moving-target snapshots).

If you are the kind of person who used to track master by building
from source, but no longer do so because you are using maven or
leiningen, alpha releases are for you.

--
Christopher Redinger
Clojure/corehttp://clojure.com



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Clojure 1.3 Beta 1

[Aaron Bedra]

On 06/24/2011 09:29 AM, smf...@googlemail.com wrote:

Just a quick question (before I forget): Is deftype/defrecord still
alpha? Or is the Alpha - subject to change note in the docstrings
just an oversight?

Thanks,
-F.M.
I just created a housekeeping ticket around all of the alpha markings.  
See http://dev.clojure.org/jira/browse/CLJ-815 for details.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Complement to clojure survey

[Aaron Bedra]

On 06/23/2011 04:22 PM, Milton Silva wrote:

As suggested by  Chas Emerick here:
http://cemerick.com/2011/06/15/the-2011-state-of-clojure-survey-is-open/#comments

I've created the following survey:

https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFFJTTZWT2lXR1N1dTJTWk5mdjZXZlE6MQ


Can you make the build tools a checkbox list? I use more than one :)


--
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: Complement to clojure survey

[Aaron Bedra]

I start with Leiningen because it is simple.  I end up on Maven when 
Leiningen can't provide what I need.  This list includes but is not 
limited to:


* Projects that have multiple local project dependencies, all in the 
build chain
* Projects that have native (JNI) code that need to be built and are a 
dependency of the project
* Projects where Leiningen just happens to fall down for some 
unexplained reason


Please don't read this as Leiningen sucks.  I love Leiningen and it IS 
my default.  There are just some things that crop up every now and again 
and since I am too lazy to fix them myself, I suffer the consequences 
(Maven).


Cheers,

Aaron

On 06/23/2011 05:06 PM, Milton Silva wrote:

done ;) btw, why do you find it useful to use more than one? or is it
a necessity?

On Jun 23, 9:44 pm, Aaron Bedraaaron.be...@gmail.com  wrote:

On 06/23/2011 04:22 PM, Milton Silva wrote:  As suggested by  Chas Emerick 
here:

http://cemerick.com/2011/06/15/the-2011-state-of-clojure-survey-is-op...
I've created the following survey:
https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFFJTTZW...

Can you make the build tools a checkbox list? I use more than one :)


--
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: Complement to clojure survey

[Aaron Bedra]

On 06/23/2011 05:56 PM, Phil Hagelberg wrote:

Aaron Bedraaaron.be...@gmail.com  writes:


I start with Leiningen because it is simple.  I end up on Maven when
Leiningen can't provide what I need.  This list includes but is not
limited to:

* Projects that have multiple local project dependencies, all in the
build chain

Have you looked into checkout dependencies? I'd be interested in hearing
more about this particular use case if it's something that checkout deps
don't address.

I haven't looked at that quite yet.

* Projects that have native (JNI) code that need to be built and are a
dependency of the project

Hah; I have been looking for people to test the new native deps support
in Leiningen for weeks. Where have you been? =)
My native deps problem is the one that I replied to on the list when you 
asked for help.  It is not just including a native dep, but actually 
building it.

* Projects where Leiningen just happens to fall down for some
unexplained reason

It would be great to see bug reports for these cases if it's not too
much trouble.

Yes, we need to start sending stuff in.  The only problem is recreating 
the bug in a way where we can share the code.  It is often times some 
strange repl issue that doesn't exist until we are multiple layers deep 
in a project.  There haven't really been too many random lein bugs in 
quite a while though.  Most of them had to do with repl but we don't use 
that anymore.


I'll try to be more diligent with submitting reports :)

Aaron

--
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: Complement to clojure survey

[Aaron Bedra]

On 06/23/2011 11:25 PM, Phil Hagelberg wrote:

Aaron Bedraaaron.be...@gmail.com  writes:


Hah; I have been looking for people to test the new native deps support
in Leiningen for weeks. Where have you been? =)

My native deps problem is the one that I replied to on the list when
you asked for help.  It is not just including a native dep, but
actually building it.

Oh, I see; yes that's different. I'm interested in discussing that once
Leiningen 1.6 is released. I'd love to get some requirements as there
are very few open source projects that actually use native code and I
have never been in that position myself.

-Phil

I'm happy to run down the scenario that we've had and help put something 
together


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Dependencies with native components

[Aaron Bedra]

The main thing that we have run into is leiningen's inability to build a 
native dependency.  We have a few projects where we had to build some 
wrappers and those have to be built and installed with a shell script 
before running leiningen.  Is that in the pipeline?

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 05/29/2011 11:25 PM, Phil Hagelberg wrote:

I started a thread on the Leiningen mailing list about improving
support for dependencies with native components, but I realized I
should have put it on the main Clojure list instead for a wider
audience: 
http://groups.google.com/group/leiningen/browse_thread/thread/11e225cdea343176

If you maintain or use a library that includes native code then please
take a look at the proposal; your input is welcome.

-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: We need a better way to handle errors.

[Aaron Bedra]

Have you signed a CA yet? If so, you can sign up for a confluence account
and start a wiki page around this.  This way the appropriate discussions and
review can take place and then possibly a JIRA ticket/patch to fix things
up.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Sat, May 21, 2011 at 12:42 AM, Ken Wesson kwess...@gmail.com wrote:

 = (try (doall (map (partial / 36) [4 9 3 2 0])) (catch
 ArithmeticException _ boo!))
 #CompilerException java.lang.RuntimeException:
 java.lang.ArithmeticException: Divide by zero (NO_SOURCE_FILE:0)

 The problem with trying to catch exceptions thrown from inside lazy
 sequence generators is that they all get wrapped in RuntimeException.

 Catching that works:

 = (try (doall (map (partial / 36) [4 9 3 2 0])) (catch
 RuntimeException _ boo!))
 boo!

 but doesn't allow catch-dispatch on exception type.

 You can get the final cause of an exception with this:

 (defn get-cause [t]
  (loop [t t]
(if-let [c (.getCause t)]
  (recur c)
  t)))

  You could make a catch-last macro.

 (defmacro catch-last [ catches]
  `(catch Throwable t#
 (let [cause# (get-cause t#)]
   (try (throw cause#)
 ~@catches

 seems like it should work, and macroexpands properly, but fails oddly:

 = (try (doall (map (partial / 36) [4 9 3 2 0])) (catch-last
 ArithmeticException _ boo!))
 #CompilerException java.lang.Exception: Unable to resolve symbol:
 catch in this context (NO_SOURCE_FILE:1)

 If you ask me, that's a compiler bug right there; it should expand to
 (try (doall ...) (catch (let ...))) which is legal Clojure and a legal
 try-catch form in particular.

 This, instead, works:

 (defmacro try-2 [ body]
  (let [[try-part catches] (split-with #(not= (first %) 'catch) body)
[catches finally] (split-with #(not= (first %) 'finally) catches)]
`(try
   ~@try-part
   (catch Throwable t#
 (let [cause# (get-cause t#)]
   (try (throw cause#)
 ~@catches)))
   ~@finally)))

 = (try-2 (doall (map (partial / 36) [4 9 3 2 0])) (catch
 ArithmeticException _ boo!))
 boo!

 However, if you call a Java API that wraps exceptions, you might want
 to catch the Java layer exception and not its own cause. That is, you
 could have

 Exception in thread Thread-1989 java.lang.RuntimeException: blah blah
at stack trace here
 Caused by com.foo.FooFrameworkLoadResourceException: blah blah
at stack trace here
 Caused by org.xml.sax.SAXException: blah blah
at stack trace here

 and you probably don't care that the framework encountered some
 malformed XML on the web, but that it failed to load a resource.
 Ordinary try will catch the RuntimeExcepion and try-2 will catch the
 SAXException; neither will catch the
 FooFrameworkLoadResourceException.

 The simplest thing Clojure could do to alleviate this type of
 difficulty is to not wrap in generic RuntimeExceptions. Instead,
 derive ClojureRuntimeException from it and use that, and we can
 redefine get-cause as follows:

 (defn get-cause [t]
  (loop [t t]
(if (instance? ClojureRuntimeException t)
  (recur (.getCause t))
  t)))

 and then try-2 will behave as desired for cases like this.

 But then there's so much more that could be done, such as allowing
 error handlers to be called as soon as various conditions arise that
 can perform restarts. The options would generally be to a) propagate
 the exception, b) retry, c) throw an Error, and d) return some other
 value as the value of the expression whose evaluation aborted. So if
 we set up to propagate, the behavior would be the same as now. On the
 other hand if we set up to restart, we might use a handler like:
 (syntax speculative)

 (handler ArithmeticException _ Double/NaN)

 in case we'd rather have NaNs propagate through failed math, for example,
 or

 (handler IOException _ nil)

 if we want some I/O read operation to return nil on failure. How about

 (handler OutOfMemoryError _ (reset! cache {}) (retry))

 with the proviso that retry reruns the failed expression as if retry
 were a zero-argument function containing it as its body and any
 unhandled exceptions thrown out of a handler are propagated. This
 allows propagation either via (handler FooException e (throw e)) or by
 not having a handler registered for FooException. Multiple retries
 would require try...catch inside the handler.

 The default in REPL sessions could even be to pop up a message box via
 Swing and prompt the user what to do, not unlike the errors one gets
 developing in typical Common Lisp environments:



 ! Error   x _ #

 FooException in foo-function

  (x) Propagate the exception
  ( ) Retry
  ( ) Throw Error
  ( ) Evaluate to this value: [nil]

  (Copy stack trace to clipboard)  (OK)



 where the field for the third option is of course passed through
 read-string or maybe even eval and throw Error would be omitted if
 the exception

Re: Joy of Clojure errata: Chapter 5

[Aaron Bedra]

On 05/17/2011 09:21 PM, Ken Wesson wrote:

On Tue, May 17, 2011 at 5:57 PM, pmbauerpaul.michael.ba...@gmail.com  wrote:

Manning's forum would be a better home for errata than the Clojure mailing
list.
http://www.manning-sandbox.com/forum.jspa?forumID=624

Sorry; I don't really care for web forums much. I think mailing lists
and Usenet are much to be preferred.

Please do use Manning's forum for this.  It will help the authors and 
the publisher track the errata in the proper way and reduce the traffic 
on this list.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

New contrib releases

[Aaron Bedra]

Hello all,

I just pushed out two new releases.

* [org.clojure/tools.macro 0.1.0]
** Includes all the bits from c.c.macro-utils and name-with-attributes 
from c.c.def. Thanks to Konrad who did the initial leg work for this

* [org.clojure/core.incubator 0.1.0]
** Includes the bits from c.c.core and defmacro- from c.c.def

They have been released to sonatype and should hit central within a 
couple of hours


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: ANN: Slamhound (for reconstructing ns forms)

[Aaron Bedra]

I love you Phil.

On 04/25/2011 09:05 PM, Phil Hagelberg wrote:

So I just threw together a little tool to help with ns forms. I find
often they accumulate a bunch of cruft over time where you no longer
need a given :use or :require form. And sometimes you don't feel like
finding exactly where on the classpath a given class is. Or maybe
you're too lazy to type it; whatever. Slamhound helps with that.

(ns my.namespace
   some doc string)

(defn -main [  args]
   (pprint args)
   (io/copy (ByteArrayInputStream. (.getBytes hello))
(first args)))

Look at that; all bare, missing all kinds of necessary stuff.
Disgraceful. Release the hound!

$ lein slamhound src/my/namespace.clj

(ns my.namespace
   I have a doc string.
   (:use [clojure.pprint :only [pprint]])
   (:require [clojure.java.io :as io])
   (:import (java.io ByteArrayInputStream)))

Tada! (also featuring Emacs integration: M-x slamhound)

Enjoy: https://github.com/technomancy/slamhound

-Phil




--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

New contrib releases

[Aaron Bedra]

Hi everyone,

I have moved and released some c.c libraries into their new homes.

* c.c.def and c.c.classpath are now combined under 
clojure.java.classpath and version 0.1.0 is available on maven central
* c.c.find-namespaces is now clojure.tools.namespaces.  I released 
version 0.1.0 just a few minutes ago, so it will be a few hours before 
it hits maven central.


You can view the build status of these projects at http://build.clojure.org

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: ANN: Clojure Atlas (preview!)

[Aaron Bedra]

I would pay $20 per project for this easily.  You did some great work 
(from the looks of it anyways) and you should get the financial reward 
from it.  This isn't a charity, it's a service, and I would treat it as 
such.  Keep up the awesome!


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 04/19/2011 01:10 PM, rob levy wrote:
This seems great.  The $20 bothers me, not because I don't want to pay 
it, I would gladly donate this meager amount for such a useful 
resource.  There's just something in poor taste about not making this 
open to everyone.  And there's an implicit camaraderie and good will 
that developer communities have come to expect that makes this paywall 
seem weird and unwelcoming.  If you framed this as a donation, with 
access not contingent on donation, it would be perfectly fine-- and 
people might actually use it.


On Tue, Apr 19, 2011 at 12:45 PM, Paul deGrandis 
paul.degran...@gmail.com mailto:paul.degran...@gmail.com wrote:


This is a great piece visualization for Clojure and very much how I
think about the language as I'm working with it (based on the pictures
and descriptions).  This is a nice niche piece of documentation for
the community, power users, and newly emerging Clojure shops.

Is your freemium model limiting namespaces/content. functionality, or
both?

Paul


On Apr 19, 9:27 am, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com mailto:abonnaireserge...@gmail.com
wrote:
 Oh wow, this looks exciting! Subbed.

 Ambrose

 On Wed, Apr 20, 2011 at 12:19 AM, Chas Emerick
cemer...@snowtide.com mailto:cemer...@snowtide.comwrote:







  Today, I’m opening up a “preview” site for Clojure Atlas [1],
a new side
  project of mine that I’m particularly excited about.

  Clojure Atlas is an experiment in visualizing a programming
language and
  its standard library.  I’ve long been frustrated with the
limitations of
  text in programming, and this is my attempt to do something
about it.  From
  the site:

  While Clojure Atlas has a number of *raisons d’être*, it
fundamentally
  exists because I’ve consistently thought that typical
programming language
  and API references – being, in general, walls of text and
alphabetized links
  – are really poor at conveying the most important information:
not the
  minutiae of function signatures and class hierarchies, but the
stuff that’s
  “between the lines”, the context and interrelationships
between such things
  that too often are only discovered and internalized by bumping
into them in
  the course of programming. This is especially true if we’re
learning a
  language and its libraries (really, a never-ending process
given the march
  of progress), and what’s standing in our way is not, for
example, being able
  to easily access the documentation or signature for a
particular known
  function, but *discovering* the mere existence of a
previously-unknown
  function that is perfect for our needs at a given moment.

  This is just a preview – all sizzle and no steak, as it were.
 I’m working
  away at the ontology that drives the visualization and user
experience, but
  I want to get some more early (quiet) feedback from a few
folks to make sure
  I’m not committing egregious sins in various ways before
throwing open the
  doors to the world.

  In the meantime, if you’re really interested, follow
@ClojureAtlas [2],
  and/or sign up for email updates [3] on the site.
  - Chas

  [1]http://clojureatlas.com
  [2]http://twitter.com/ClojureAtlas
  [3]http://clojureatlas.com/subscribe

  P.S. This is a ML repost of my announcement @
 http://cemerick.com/2011/04/19/clojure-atlas-preview/

  --
  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%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
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%2bunsubscr...@googlegroups.com
For more options

Re: ANN: Clojure Atlas (preview!)

[Aaron Bedra]

Also, when I mean per project, I mean that in the sense that I am 
working with different customers who would find it valuable and pay for 
the access for them :)


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 04/19/2011 01:23 PM, Aaron Bedra wrote:
I would pay $20 per project for this easily.  You did some great work 
(from the looks of it anyways) and you should get the financial reward 
from it.  This isn't a charity, it's a service, and I would treat it 
as such.  Keep up the awesome!


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Enclojure REPL problems

[Aaron Bedra]

On 04/13/2011 08:45 AM, Chas Emerick wrote:

On Apr 13, 2011, at 1:08 AM, Ken Wesson wrote:


Since these issues have been raised on the Enclojure Google Group by
various people repeatedly over the last couple of years, to no effect,
it seems that they need to be raised elsewhere to actually get the
attention they deserve.

Someone fix this in Enclojure 1.5 please! At least one of bug 1 and
bug 2c, and preferably all of them.

Entirely rhetorical question: if you've posted messages to the group dedicated 
to the project in question, what makes you think posting to a general-interest 
list will have the effect you desire?  One might as well hope to affect change 
in Clojure by posting to a generalized JVM language list.

Anyways…anybody can be that someone, given sufficient interest and 
motivation…even you.

- Chas

Agreed.  If these things are bothering you to a large degree you can 
make those fixes and submit them back to the project.  I imagine they 
would be a very welcome addition


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Enclojure REPL problems

[Aaron Bedra]

On 04/13/2011 08:56 AM, Ken Wesson wrote:

On Wed, Apr 13, 2011 at 8:45 AM, Chas Emerickcemer...@snowtide.com  wrote:

On Apr 13, 2011, at 1:08 AM, Ken Wesson wrote:


Since these issues have been raised on the Enclojure Google Group by
various people repeatedly over the last couple of years, to no effect,
it seems that they need to be raised elsewhere to actually get the
attention they deserve.

Someone fix this in Enclojure 1.5 please! At least one of bug 1 and
bug 2c, and preferably all of them.

Entirely rhetorical question: if you've posted messages to the group dedicated 
to the project in question, what makes you think posting to a general-interest 
list will have the effect you desire?

I haven't, actually. I only noted that others have, and that the data
indicated that doing so was ineffective. Hence why I haven't bothered.


  One might as well hope to affect change in Clojure by posting to a 
generalized JVM language list.

If the Clojure list was nearly dead, getting only 2 or 3 posts a
month, and inquiries and reports posted here tended to sink without a
ripple, one would obviously have to go elsewhere.


Anyways…anybody can be that someone, given sufficient interest and 
motivation…even you.

Not really. I don't know beans about Enclojure's internals. It would
take me a lot longer to read and study and fully understand the source
code, figure out what the problem is, and fix it than it should take
any of Enclojure's existing developers to figure out what the problem
is and fix it.

It all depends on what the current developers time and interests are 
like.  You may get the fix faster if you do it yourself.  Despite your 
admitted lack of knowledge around the IDE internals, I think you are 
more than capable when it comes to solving these kind of problems.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: labrepl incanter IntelliJ Ubuntu 64-bit X11 error

[Aaron Bedra]

I use Ubuntu 10.10 64 Desktop edition for all of my development.  I 
install the oracle jdk 6.  All of my dotfiles and emacs configurations 
are on github at http://github.com/abedra/shell-shocked.  You can dig 
through them to see if you are missing anything, but I have never had 
this issue before.  I install a handful of extras, but I can't think of 
anything that would cause/fix the issue you are reporting.  Have you 
looked on the Ubuntu forums for general Java development with the same 
errors? Are you doing anything with your configuration that might be 
causing this?


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 04/13/2011 09:00 PM, peterg wrote:

Hi All,

I rebuild a brand-spanking Ubuntu 10.10 system and tried IntelliJ and
labrepl. Also tried all three JDKs (openjdk sun-java-6, andf the
IntelliJ built-in) none of these worked with incanter graphics.

As I reported before the graphics work fine from the command-line.

*I seriously believe there is a missing step in published
configuration instructions, or that a development environment being
used elsewhere on the same machine by other people testing provides a
magic fix.

IMHO the NetBeans and Eclipse configs were also flaky or heavyweight.
I started trying EMACS but learning curve is high for entry.

Cheers,
--PG

On Apr 11, 4:44 pm, peterg..  wrote:

OK that's nice and clear. Thanks for your help

--PG

On Apr 11, 1:31 pm, Aaron Bedraaaron.be...@gmail.com  wrote:









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

Re: labrepl incanter IntelliJ Ubuntu 64-bit X11 error

[Aaron Bedra]

I'm on Ubuntu 10.10 64.  I use it as my daily development environment.  
I just installed IntelliJ community edition 10 and checked out labrepl.  
I used the maven browser and selected the clojure:repl task and 
everything worked successfully.  You can still try out Clojure though 
labrepl using any of the other editor options until you get your 
IntelliJ issues sorted out.


On 04/10/2011 10:49 PM, peterg wrote:

The Ubuntu configuration is very plain - not used for anything else.
X11 is part of the standard distribution.

I would really like to try out Clojure through this tutorial...

--PG


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Contrib.Logging enhancements: set-log-level!, spy for lazy sequences

[Aaron Bedra]

Just a reminder that logging has moved to it's own repository in the 
clojure space.  It can be found at


http://github.com/clojure/tools.logging

and is where all future development of the library should exist.  If you 
would like to submit patches for logging, please do so against the new 
project instead of contrib.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 04/10/2011 10:48 PM, Paul Legato wrote:

Hi,

I'd like to suggest two enhancements to clojure-contrib.logging:

1) There should be an easy way to set the current log level threshold
(DEBUG, WARN, etc.) I've written two set-log-level! functions which do
this, at http://www.paullegato.com/blog/setting-clojure-log-level/ .

I'm not sure why some Clojure instances return a
org.apache.commons.logging.impl.Jdk14Logger and others a
java.util.logging.LogManager$RootLogger from (impl-get-log ).
Perhaps there's a better / more universal way to write the log level
setting function than this?

2) The logging/spy macro doesn't print lazy sequences to the log;
instead, it prints something like clojure.lang.LazySeq@8592. Since
the user has explicitly requested that the sequence's value be logged,
it makes sense to me to run the sequence and log the result. I've
implemented this at 
http://www.paullegato.com/blog/lazy-spy-clojure-logging-lazy-sequences/.
Again, I'm not sure if this is the best way to go about it.
Suggestions or improvements would be greatly appreciated.

Best,
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: How to profile my app?

[Aaron Bedra]

YourKit

http://www.yourkit.com/

It's a great tool.  It comes with a free trial, but IMHO it's worth 
every penny for the paid version.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com



On 04/04/2011 07:31 PM, Base wrote:

Hi Group!

I am hoping to get a little help figuring out how to profile my app.

I have been working on this for a while and appear to have a
bottleneck somewhere.

I could attempt to manually step through the app step by step, but I
am looking to see if there is a better solution.

How to you all profile your app to look to find the performance
bottlenecks?

Any help is most appreciated and would definitely be a good learning
experience for us newbies.

Thanks!

Base




--
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: What the hell is going on with the Clojure cheat sheet?

[Aaron Bedra]

On 04/05/2011 09:55 AM, Ken Wesson wrote:

I keep a tab parked at the Clojure cheat sheet, and just now I clicked
a link there. When I hit back, instead of the browser displaying the
cheat sheet again, as it should have, it displayed a big block of ads
and other cruft with no cheat sheet in sight!

The cheat sheet web page has apparently been defaced!

It was not defaced, the domain expired.  It is being (or has been 
already) renewed.  As soon as the dns changes propagate back out it will 
come back again.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: What the hell is going on with the Clojure cheat sheet?

[Aaron Bedra]

On 04/05/2011 12:53 PM, Baishampayan Ghose wrote:

On Tue, Apr 5, 2011 at 10:17 PM, Ken Wessonkwess...@gmail.com  wrote:

And why would it come up as a page full of ads (mostly pretty scammy
looking ads, like fake Windows messageboxes and such) instead of a
Host Unknown error?!

Because the registrar for clojure.org chose to resolve lapsed domain
names to a page that it thinks could make it some money instead of
failing. If you look closely (assuming you can still get the page),
you're liable to find a buy this domain link somewhere on it.

That's pretty evil. Their behavior makes Clojure look unprofessional,
or even hacked, and is confusing to users trying to reach the page.
It's like going to your local mall and finding a big, neon-encrusted
casino or something in its stead, rather than either the mall or a
vacant lot.

Most domain registrars do that. What fix do you suggest to make
Clojure look more professional?

Regards,
BG

I think we have moved past the relevant portion of this conversation.  
There was a mistake, it was corrected.  We apologize for any 
inconvenience this has caused.  Since there is an answer to this thread 
let's put it to rest and move on with more important matters.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: http://build.clojure.org/releases - no alpha5 alpha6.. ?

[Aaron Bedra]

On 03/24/2011 11:13 AM, Jules wrote:

Aha !

OK - so maven is pulling alpha5/6 in from somewhere, but not from the 
repo that I expected - and unfortunately, I am not finding 
clojure.contrib.logging for these releases - maybe contrib is not 
being released to the same repo ? or maybe it has changed its name ? 
I'll have to investigate.
Logging has been pulled into the new contrib style under the project 
tools.logging.  Take a look at the following leiningen example:


(defproject example 1.0.0-SNAPSHOT
  :description FIXME: write
  :dependencies [[org.clojure/clojure 1.3.0-alpha6]
   [org.clojure/tools.logging 0.1.2]])

This is the same library that was in contrib, and it will be the place 
for further development.



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Tracking Clojure 1.3/2.0 progress

[Aaron Bedra]

On 03/09/2011 02:18 PM, Fogus wrote:

Hi all,

I've put together a Jira dashboard to display a distillation of the
current progress toward the 1.3/2.0 release.  I believe that anyone
can view it, so pass the link far and wide.

http://dev.clojure.org/jira/secure/Dashboard.jspa?selectPageId=10014

There is additional information displayed if you log in.

Enjoy.
:f


Very nice!

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Release.Next Version Number

[Aaron Bedra]

 I come from the Ruby world, and Ruby isn't even a 2.0, so my perspective is
 definitely colored.


It seems to me like (most) of the things you are talking about are not core
language specific things.  In particular for package management Ruby uses
Rubygems which is a separate project, and just recently Bundler for
dependency management.  To me these things have no impact on the language
and shouldn't keep the language from moving forward in a version numbering
sense. I do agree that they should mature though.


 Three problems with the REPL:

 1. The standard way Clojure tells me to get a REPL is using the java
 command. This makes Clojure not feel like a first-class language.


Agreed, there is a ticket for this in JIRA.



 2. Once I do get a REPL, either through the java or lein or cljr commands,
 it has no indentation or Jline support. It feels messy.


From what I have seen most people aren't using the bare REPL or lein repl,
but the experience could be better.



 3. I use Vim, so Emacs/Slime isn't really something I want to do. (And I
 don't want to have to use a specific editor in order to use the language of
 my choice.)


Sorry if you are already aware of this, but there is a vim plugin for slime
that I have heard good things about.




   - better discovery for existing, well-tested libraries.


Well tested is completely a matter of opinion and is another one of those
things that doesn't seem like a reason to hold back a 2.0.


 As I say, I really enjoy coding in Clojure, but the process surrounding
 coding is not always very polished. I see too much Java and not quite enough
 integration to think of it as a 2.0 yet, though I do think we can get
 there.


I can completely understand what you mean after coming from the Ruby world
where there has been a ton of effort spent on making the development
experience better.  I think we can take a lot away from what Ruby has done.
 Two of the Clojure/core team members (Stuart Halloway and me) also came
from Ruby and spent quite a bit of time helping make it better while we were
there.

I do want to make sure that the things we think about when calling a release
2.0 factor more into what has changed since the last release.  This would be
both how much has changed, and how many breaking changes have occurred.  I
don't want to dismiss what you have brought up though because I think they
are all really important for the adoption of the language going forward.

Cheers.

Aaron
--
Clojure/core
http://clojure.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

Re: Is there an on-going running service

[Aaron Bedra]

Although a while loop does work here, it's just a hack to get the 
desired behavior.  Have you considered using a scheduled thread pool as 
your controller?


For example:

(def ^{:private true} pool (atom nil))
(def ^{:private true} num-threads 3)

(defn- thread-pool []
  (swap! pool (fn [p] (or p (ScheduledThreadPoolExecutor. num-threads)

(defn schedule-periodic
  Schedules function f to run every 'delay' milliseconds after an
  initial delay of 'initial-delay'.
  [f initial-delay delay]
  (.scheduleWithFixedDelay (thread-pool)
   (protect-from-exceptions f)
   initial-delay delay TimeUnit/MILLISECONDS))


(defn run-always []
  (schedule-periodic dosomething 0 60))

This is a simple example that lacks general robustness around error 
handling, but provides a clean way to continuously run things.  You can 
also provide a clean shutdown a la:


(defn shutdown
  Terminates all periodic tasks.
  []
  (swap! pool (fn [p] (when p (.shutdown p)

Hope this helps,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 02/21/2011 06:35 PM, Brent Millare wrote:

Seems to work for me. Are you putting something valid in (do
something)?

Also if you want to watch files in a directory, there is JNotify,
which might be useful to you.

On Feb 21, 5:19 pm, clj123ariela2...@gmail.com  wrote:

Hello,

I'm looking for an on-going service that runs and processes files in a
certain location. This function should be contiously running.

The function that I've used, it always running and when files are
place it does something with it.

(defn run-always []
 (while true (dosomething)))

However, it throws an exception:
Expression failed: (run-always)

I'm not sure why it's throwing it, and is there a better way to handle
this kind of service?

Thanks.



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Suspected REPL bug; behavior in empty namespace differs from what's documented

[Aaron Bedra]

Agreed.  I get the same behavior as Stuart.  If you suspect a bug like 
this please verify it against the most basic form of the REPL by 
starting clojure directly and trying your solution.


On 01/22/2011 01:32 PM, Stuart Sierra wrote:
I think it's a bug in Enclojure's REPL. The examples work for me in 
Clojure 1.2.0 and 1.3.0-master at the command line.

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Creating standalone executable

[Aaron Bedra]

You should take a look at

http://data-sorcery.org/2010/06/12/incanter-executables/

which is a great place to start.

On 01/22/2011 02:51 PM, Miki wrote:

Greetings,

What is the best option to create a stand alone executable from 
Clojure project (something like py2exe).

(I want to bundle the JRE in the application).

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Why no def- ?

[Aaron Bedra]

On 01/21/2011 12:51 AM, Ken Wesson wrote:

On Fri, Jan 21, 2011 at 12:40 AM, Alex Baranosky
alexander.barano...@gmail.com  wrote:

I've wanted to have private defs.  For defn, I just us defn-.  But there is
no def-

So I just use:

(defmacro def- [name  decls]
 (list* `def (with-meta name (assoc (meta name) :private true)) decls))

There's a (defvar- ...) in clojure.contrib. Why there's nothing like
this in core remains a mystery to me. :)


You can also do

(def foo {:private true} (...))

which is just the basic functionality in core.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Why no def- ?

[Aaron Bedra]

On 01/21/2011 09:22 AM, Laurent PETIT wrote:
2011/1/21 Aaron Bedra aaron.be...@gmail.com 
mailto:aaron.be...@gmail.com


On 01/21/2011 12:51 AM, Ken Wesson wrote:

On Fri, Jan 21, 2011 at 12:40 AM, Alex Baranosky
alexander.barano...@gmail.com
mailto:alexander.barano...@gmail.com  wrote:

I've wanted to have private defs.  For defn, I just us
defn-.  But there is
no def-

So I just use:

(defmacro def- [name  decls]
(list* `def (with-meta name (assoc (meta name)
:private true)) decls))

There's a (defvar- ...) in clojure.contrib. Why there's
nothing like
this in core remains a mystery to me. :)

You can also do

(def foo {:private true} (...))


With def, it will be :
user= (def ^{:private true} foo ba)
#'user/foo
user= (meta (var foo))
{:ns #Namespace user, :name foo, :file NO_SOURCE_PATH, :line 4, 
:private true}

user=

It's with defn that you can use a map at a certain position:
user= (defn foo {:private true} [] bar)
#'user/foo
user= (meta (var foo))
{:ns #Namespace user, :name foo, :file NO_SOURCE_PATH, :line 7, 
:arglists ([]), :private true}

user=


Doh!  I'm full of typos this week.  Do a combination of what I meant and 
what Laurent said and you'll be in a good place.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: just an observation about doseq...

[Aaron Bedra]

On 01/20/2011 07:53 AM, John Szakmeister wrote:

On Thu, Jan 20, 2011 at 5:38 AM, Baishampayan Ghoseb.gh...@gmail.com  wrote:

when we give an empty vector of seq-exprs to doseq it returns the value of
the last s-expression.. but returns nil when the
vector-of-seq-exprs is not empty.. may be this is the expected behaviour ..
but the documentation states otherwise ..

Yeah, that looks like a bug (either in the documentation or the code):
   (doseq [] 1) =  1

doseq works just like do when the seq-exprs part is empty. This is
certainly not a bug in the code, but I believe the documentation can
be improved.

Relevant portion of the code:
https://github.com/clojure/clojure/blob/b578c69d7480f621841ebcafdfa98e33fcb765f6/src/clj/clojure/core.clj#L2395

Yep, I took a look at that before responding.  I'm just not sure what
the fix should be: make (doseq) return nil as advertised, or update
the documentation.  I tend towards the former, although the latter is
fine too. :-)  Either way, something should be fixed. :-)

I folks believe it's a documentation problem, I'm happy to whip up a
patch for that.

-John

Please create a ticket in JIRA for this.  If you have a patch and have 
signed the CA then all is good there.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: just an observation about doseq...

[Aaron Bedra]

On 01/21/2011 10:31 AM, Baishampayan Ghose wrote:

Please create a ticket in JIRA for this.  If you have a patch and have
signed the CA then all is good there.

Done. http://dev.clojure.org/jira/browse/CLJ-722

My CA is on file.

Regards,
BG


Thanks!

--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Getting started with Counterclockwise

[Aaron Bedra]

You have been asked kindly to change your tone.


Are you implying a threat?

The next part of your post seemed to descend into name-calling, more
threats, and other unconstructive material, so I did not bother to
read further.

Have a good day.


Nobody is implying any threats.  They are simply asking you to be a 
little bit more considerate when you are asking/replying to questions.  
Before sending a reply just read over it quickly and ask yourself if I 
were on the receiving end of this email would it offend me?.  CCW is 
free and open source software that people have put a lot of effort 
into.  Questions and improvements are a great way to grow and nurture 
projects, but the tone here has gotten a little out of hand.  If all 
questions have been answered let's move on and keep the good discussions 
rolling.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.comcl


--
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: Getting started with Counterclockwise

[Aaron Bedra]

Yep, just fixed that :)

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On 01/20/2011 09:36 AM, Laurent PETIT wrote:

Seriously, Aaron, there's a typo in your signature.

Take care ;)

--
Laurent
--
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: Getting started with Counterclockwise

[Aaron Bedra]

On 01/20/2011 10:15 AM, Ken Wesson wrote:

On Thu, Jan 20, 2011 at 9:31 AM, Luc Prefontaine
lprefonta...@softaddicts.ca  wrote:

Chasing a fly with a news paper has more value than spending time
with you for any purpose.

...


Oups, need to flush that junk folder again... crap appeared in it
again.

And some people are claiming that *I* am being trollish, churlish, or
unreasonable.

Go figure.

Agreed.  Comments like this are unnecessary.  Let's let this thread die 
and move on.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Ah-hah! Clojure is a Lisp

[Aaron Bedra]

On 12/20/10 1:39 PM, Ken Wesson wrote:

On Mon, Dec 20, 2010 at 1:26 PM, Meikel Brandmeyerm...@kotka.de  wrote:

Hi,

if you prefer text over talk:

http://clojure.googlegroups.com/web/AreWeThereYet.pdf

*giggle*

It figures.

I ask for text instead of video so, naturally, I get a PDF link.

*falls over laughing*
You have asked others not to reply to you in the same tone you are 
taking here.  This was a sincere effort to help.  Please show a little 
bit more respect.


Aaron
--
Clojure/core
http://clojure.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

Re: Ah-hah! Clojure is a Lisp

[Aaron Bedra]

On 12/20/10 1:47 PM, Ken Wesson wrote:

On Mon, Dec 20, 2010 at 1:42 PM, Aaron Bedraaaron.be...@gmail.com  wrote:

On 12/20/10 1:39 PM, Ken Wesson wrote:

On Mon, Dec 20, 2010 at 1:26 PM, Meikel Brandmeyerm...@kotka.dewrote:

Hi,

if you prefer text over talk:

http://clojure.googlegroups.com/web/AreWeThereYet.pdf

*giggle*

It figures.

I ask for text instead of video so, naturally, I get a PDF link.

*falls over laughing*

You have asked others not to reply to you in the same tone you are taking
here.  This was a sincere effort to help.  Please show a little bit more
respect.

I'm sorry, but it's just hilarious the lengths some people apparently
go to to avoid plain text/html that you don't need a special browser
plugin and a multimegabyte download to view. All those video links and
then, when someone finally points to a textual summary for one of
them, it's a pdf! It's tragicomic. :)
If you think it is funny that's absolutely your opinion to keep.  It has 
no place or constructive worth on this mailing list.  Please keep this 
kind of response off the list.


Aaron

--
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: could clojure be androids joker card

[Aaron Bedra]

There are several forces at play here that work against clojure on 
android being a huge force.  The size of hello world in clojure is 
currently 4.21MB.  This is roughly 4 for clojure and .21 for the app. 
This is compared to the same app in java at .2MB.  Bring in c.c and you 
have a whole lot more.  With the separated c.c builds it gets better, 
but that's still a lot.


Moving on to more important matters is the performance issues.  The 
dalvik vm is not very efficient when it comes to GC or reflection.  The 
functional programming nature generates much more garbage than your 
standard java app which causes some performance issues.  This hits the 
hardest at boot time in an android application.  AOT compilation helps 
here but not in all cases.  The idea of having a REPL on the phone is 
nice and can be done, but it is quite slow.  I'm sure there are ways to 
make it a bit faster (2.2 has JIT support for example) but it will most 
likely be severely limited for some time.   I have been playing with 
several different ways to improve Clojure's performance on android and 
have made some improvements, but am a ways off from releasing anything.


This is in no way meant to steer you away from trying out Clojure on 
android, but I would suggest learning the platforms ins and outs, and 
then move in to trying out Clojure on it.  If you have specific 
questions please feel free to ask and I will do my best to answer them 
for you.


Cheers,

Aaron


hi clojure-commmunity,

when learning 2 new things at a time, one is always
temped to combine them and have some unrealistic
fantasies.

i am just reading through the meap of ???
so it's not a surprise, that i think about a
combination of clojure and android.

according to other discussions in the mailinglist,
clojure on android is possible and someone has also
managed to run the combination. i also noticed, that
android-support is mentioned in the clojure 'roadmap'
at jira.

in particular i though of, how clojure could help android
to overcome its java-dependency on the long run ...
-  clojure in clojure -  clojure on base of the android
system-level-abstractions.

also leveraging the power of FP for embedded systems
programming seams like something that could pay back.

what do you think ? could clojure be androids joker card ?
and vice versa ? ;-)

have a successful day


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

[Aaron Bedra]

 Try the following instead (just modified your attached source)

(ns guestbook.core
 (:use compojure.core)
 (:require [compojure.route :as route])
 (:require [ring.adapter.jetty :as jetty])

(defroutes dispatcher
  (GET / [] h1Hello, world/h1)
  (route/not-found bRequested resource not found/b))

(defn -main [ args]
  (jetty/run-jetty dispatcher {:port 8080}))

You don't need the gen class or the servlet stuff.  Also note that there 
is a compojure google group that you can join to ask more specific 
compojure based questions on.  If you want to see more examples I have 
some on github at http://github.com/abedra/clojure-web.


Cheers,

Aaron


On 9/12/10 8:53 PM, Bahman Movaqar wrote:

  Hi list,

I'm trying to get a simple hello world Compojure application
running.   I attach both the clj file and maven pom.xml (using
NetBeans+Enclojure).  When I run (guestbook.core/-main), I get a blank
page in browser, no matter the URL.  What am I missing?

BTW, by blank I really mean blank.  If I view the page source in
Firefox, it's empty.

TIA,



--
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: [Weekend Chat] A secretly Clojure web framework?

[Aaron Bedra]

 On 9/3/10 11:45 PM, HB wrote:

Hey,
Since Relevance is heavily investing in Clojure, do you think they are
working on a Clojure web framework?
Personally, I wish.
We aren't currently working on creating a new web framework, but I am 
working to make the web development experience a little better by 
helping out where I can.  I have spent my time working with compojure 
and very recently with sandbar.  There's a fair amount of work to be 
done in this area, but there are some great people who have already 
dedicated time to it.


Cheers,

Aaron

--
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: Typical usage of Compojure

[Aaron Bedra]

 On 9/4/10 11:44 AM, HB wrote:

Hey,
If Compojure is micro web framework like Sinatra, does this means it
is not suitable for large web applications?
(since Sinatra isn't suitable for large applications, it is mainly
used for very small applications and particularly to create some kind
of an API).
Thanks for help and time.

This is a pretty unfair assessment of things.  I have used both sinatra 
and compojure on fairly large scale applications without issue.  It 
really comes down to how well you can design the whole system and how 
well the application code is written.  Like Stuart said it really is 
about finding out what pieces are missing.  I would be ok with using 
compojure on a larger project as long as it helped me get the job done 
efficiently.


Aaron

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

Clojure/core Team Update 1

[Aaron Bedra]

Clojure/core Team Update 1
Monday, July 26, 2010

Welcome to the first Clojure/core team update. In these updates you
will find:

* Announcements of upcoming events
* Project updates: summaries of recent work on Clojure and related
  projects that we support
* New developments: other new things we are working on, that haven't
  quite reached the status of supported project

==
Announcements

Friday, July 30, 2010 is Move your app to Clojure 1.2 day. The
Clojure/core team will be hanging out in the #clojure channel on IRC
and monitoring the mailing list in real time to help you out with any
migration issues.

Rich Hickey and Stuart Halloway are teaching Clojure at the Pragmatic
Studio. Next venue is September 13-15 in Reston VA. Previous studios
have sold out, so register early:http://pragmaticstudio.com/clojure.

==
Project Updates

Clojure (http://clojure.org)
* went to 1.2 beta 1 on July 14 (http://bit.ly/bIZD8v)
* set your keywords free! Keyword and dynamic classes now use soft
  references (http://bit.ly/bo5BHO)

Clojure-Contrib (http://clojure.org)
* marked deprecations throughout contrib. There are a lot of them!
* documented deprecation policy: mark deprecated for one point
  release (e.g. 1.2), then option to remove in future releases. If you
  are living on snapshots you will need to remove dependencies on
  deprecated contrib functions after 1.2 goes final.

Incanter (http: incanter.org)
* added mean and variance functions for colls, sets, maps
* set-theme fix and example
* added auto-correlation function

Labrepl (http://github.com/relevance/labrepl)
* Continuing to support onramping people across a wide variety of
  operating systems and IDEs.
* Please check the closed issues list before posting an issue:
  http://github.com/relevance/labrepl/issues/closed.

==
New Developments

Lazytest is a BDD/test-driven framework.
* added typed assertions
  http://stuartsierra.com/2010/07/19/typed-assertions
* Getting closer to a release. The underlying architecture of types and
  protocols is approaching stability. Still need significant work on
  reporting.  If you have a burning interest in how test reports will
  look in the console, now is the time to make suggestions to
  @stuartsierra.

Cljr (http://github.com/liebke/cljr) is a Clojure REPL and package
manager. Unlike project-oriented tools, Cljr's sweet spot is an
easy-to-install REPL backed by a global package management system.
* several classpath-related tweaks and fixes
* fixes to windows installation

Happy Clojuring!

Aaron Bedra
Clojure/core Team
http://clojure.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

Re: -- macro proposal

[Aaron Bedra]

On 07/06/2010 04:16 PM, Greg wrote:

Have you checked for those?
 

No, sorry, I think that's a rather unreasonable request. I'm not going to spend 
hours sifting through the core and contrib just to jerk out examples for you.

I'd rather use logic and reason to make my case.
   
I don't think that this was intended to be unreasonable.  I believe the 
motivation here is to help everyone understand the basis for your idea 
with a concrete example.  No one would want you to spend hours sifting 
through code to prove a point.  I would just start with a few reasonable 
places and see if you can code up a quick example.  I believe that this 
is a fair request.  I would very much like to see some specific examples 
as it would help solidify your ideas.


Cheers,

Aaron


- Greg

On Jul 6, 2010, at 4:14 PM, Mike Meyer wrote:

   

On Tue, 6 Jul 2010 14:09:18 -0400
Gregg...@kinostudios.com  wrote:
 

On Jul 6, 2010, at 2:01 PM, Stuart Halloway wrote:
   

(3) I haven't seen a lot of examples where something like --  solves real 
problems in code.
 

I haven't coded long enough in Clojure to provide you with any examples, but it 
seems like hoping that the functions you're going to use are going to have the 
correct parameter order is silly. Why hope when you can guarantee it won't 
matter?

Anyways, you haven't seen a lot of examples simply because people don't have a --  to 
use. Thus they're are forced to work around it, for example by replacing calls to -  or 
-  with the corresponding standard calls (postfix/prefix? don't remember what that 
style is called).

If it existed, you would see it being used.
   

If that's true, then it should be easy to find places in either
clojure.contrib or the parts of clojure.core that are written in
clojure that could make use of it.

Have you checked for those?

 mike
--
Mike Meyerm...@mired.orghttp://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O  ascii ribbon campaign - stop html mail - www.asciiribbon.org

--
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: labrepl isn't a project in netbeans 6.8 - (Ubuntu 10.04)

[Aaron Bedra]

Jared,

There was another post about issues with netbeans.  I am looking into why
this is happening.  On another note, labrepl uses clojure 1.2, but that is
all handled via leiningen.

Cheers,

Aaron

On Thu, Jun 17, 2010 at 11:10 PM, Jared tri...@gmail.com wrote:

 I was following the instructions to get labrepl up and running and hit
 a snag. Netbeans does not recognize Samples/Clojure/Relevance
 LabReplProject as a project. After creating it it does not appear in
 the Projects window. So I go to File - Open Project and click on
 RelevanceLabRepl and hit Open Project. Instead of opening the project
 it displays the subfolders. Also, when RelevanceLabRepl is selected it
 does not display a name for Project Name:, and the box Open as Main
 Project is grayed out.

 I do have a normal clojure project that I can open. I am using clojure
 1.0 if that matters.

 --
 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.comclojure%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

Re: Clojure, emacs, slime, swank tutorial for Ubuntu

[Aaron Bedra]

rlwrap seems to be a much better solution.  I do use emacs as my daily
driver, but it's nice to have a backup on the command line.  I wrote a
getting started article for Ubuntu a while back if you want to check it out.

http://aaronbedra.com/2008/8/17/adventures-in-clojure-getting-started

I made it with Hardy Heron as the focus.  I have yet to see if it all
works on Intrepid Ibex.

Aaron

solkis wrote:
 I haven't tried configuring the REPL scripts to use rlwrap. I'm mostly
 learning within emacs where it may be a moot point anyway (not sure.)
 I know in emacs I use Alt-p get get past forms. I'm definitely open to
 modifying this config tutorial to use rlwrap if it's more stable when
 needed (like directly in a shell-based REPL.) I not sure in what
 situations that JLine is iffy as you mentioned. Can you give any quick
 suggestions on what sections I would need to modify to switch in
 rlwrap? As you can see I'm using the scripts as closely as possible
 from clojure-extra so that the tutorial stays basic.

 Thanks for the feedback,

 -Tim

 On Oct 10, 5:09 pm, James Reeves [EMAIL PROTECTED] wrote:
   
 On Oct 10, 10:22 pm, solkis [EMAIL PROTECTED] wrote:

 
 I just created a basic clojure, emacs, slime, swank configuration
 tutorial for Ubuntu users
   
 I notice your tutorial uses JLine, which I've found to be rather iffy
 under Linux. Have you tried the REPL with rlwrap? Or haven't you had
 any problems with JLine?

 - James
 
 

   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---