ANN: Ribol 0.1.5 - Conditional Restart Library for Clojure

[zcaudate]

Check out the Tutorial and Examples here:

https://github.com/zcaudate/ribol
ribol

ribol is a conditional restart library for clojure inspired by errorkit, 
having a more readable syntax, and designed with the base 
clojure.lang.ExceptionInfo type in mind.
Installation:

In project.clj, add to dependencies:

 [im.chit/ribol "0.1.5"]

Provides
   
   - Issue (exception) handling using maps for data as opposed to typed 
   classes
   - Passing data along with exceptions
   - Tight integration with ex-info and ex-data
   - Five different issue handlers - catch, continue, choose, escalate and 
   default

Comparison with other Libraries

There are two other conditional restart libraries for clojure - errorkit
 and swell

   - 
   
   errorkit provided the guiding architecture for ribol. However, ribol 
   updates errorkit with more options for controlling exceptions, uses 
   ex-info which is part of core and has an updated and more understandable 
   syntax.
   - 
   
   swell was written specifically to work with the slingshot try+/catch+ 
packages 
   and I thought that the two together carried too much baggage. ribol has 
   no such 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Leiningen 2.3.0 released

[Alex Ott]

Also fails on Linux

ott@mercury:.../Debug\>lein
upgrade
8:34 0
Downloading Leiningen to
/home/ott/.lein/self-installs/leiningen-2.3.0-standalone.jar now...
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed
  0 00 00 0  0  0 --:--:-- --:--:--
--:--:-- 0
curl: (22) The requested URL returned error: 403
/home/ott/bin/lein: line 63: download_failed_message: command not found
ott@mercury:./Debug\>wget
https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.0-standalone.jar
8:35 1
--2013-08-09 08:35:29--
https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.0-standalone.jar
Resolving leiningen.s3.amazonaws.com (leiningen.s3.amazonaws.com)...
205.251.242.192
Connecting to leiningen.s3.amazonaws.com
(leiningen.s3.amazonaws.com)|205.251.242.192|:443...
connected.
HTTP request sent, awaiting response... 403 Forbidden
2013-08-09 08:35:30 ERROR 403: Forbidden.



On Fri, Aug 9, 2013 at 7:21 AM, Sean Corfield wrote:

> I'm still getting the 403 forbidden error. Mac and Windows.
>
> On Thu, Aug 8, 2013 at 10:06 PM, Phil Hagelberg  wrote:
> > On Thursday, August 8, 2013 8:52:47 PM UTC-7, Frank Hale wrote:
> >> Looks like I was way too fast. Upgrading just worked for me. Thank you!
> >
> >
> > I got the ACL wrong on the initial upload but fixed it a few minutes
> after
> > the email went out.
> >
> > -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 unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

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

sending errors to the ui - web development using luminus

[Abraham]

Dear 
How to send validate the input and then send all errors at a time .?
I am using luminus , the doc shows send one error at a time.
Thanks in advance
A

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

Re: [ANN] Leiningen 2.3.0 released

[Sean Corfield]

I'm still getting the 403 forbidden error. Mac and Windows.

On Thu, Aug 8, 2013 at 10:06 PM, Phil Hagelberg  wrote:
> On Thursday, August 8, 2013 8:52:47 PM UTC-7, Frank Hale wrote:
>> Looks like I was way too fast. Upgrading just worked for me. Thank you!
>
>
> I got the ACL wrong on the initial upload but fixed it a few minutes after
> the email went out.
>
> -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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



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

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

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

Re: [ANN] Leiningen 2.3.0 released

[Phil Hagelberg]

On Thursday, August 8, 2013 8:52:47 PM UTC-7, Frank Hale wrote:
> Looks like I was way too fast. Upgrading just worked for me. Thank you!
>
>   
I got the ACL wrong on the initial upload but fixed it a few minutes after 
the email went out.

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

Re: [ANN] Leiningen 2.3.0 released

[Sean Corfield]

It failed for me on Mac OS X 10.8.4 - this has also been a problem on
Windows for me (which doesn't have curl / wget anyway). Can we please
get the Leiningen JAR posted somewhere that is not prone to this sort
of SSL problem?

(! 536)-> lein upgrade
The script at /Developer/workspace/worldsingles/build/bin/lein2 will
be upgraded to the latest stable version.
Do you want to continue [Y/n]? y

Upgrading...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   126  100   1260 0261  0 --:--:-- --:--:-- --:--:--   336
100 11353  100 113530 0  11459  0 --:--:-- --:--:-- --:--:--  101k

Manual self-install is deprecated; it will run automatically when necessary.
Downloading Leiningen to
/Users/sean/.lein/self-installs/leiningen-2.3.0-standalone.jar now...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 403
Failed to download
https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.0-standalone.jar
It's possible your HTTP client's certificate store does not have the
correct certificate authority needed. This is often caused by an
out-of-date version of libssl. Either upgrade it or set HTTP_CLIENT
to turn off certificate checks:
  export HTTP_CLIENT="wget --no-check-certificate -O" # or
  export HTTP_CLIENT="curl --insecure -f -L -o"
It's also possible that you're behind a firewall haven't yet
set HTTP_PROXY and HTTPS_PROXY.

Thu Aug 08 21:10:48
(sean)-(jobs:0)-(/Developer/workspace/worldsingles)
(! 537)-> HTTP_CLIENT="curl --insecure -f -L -o" lein upgrade
Downloading Leiningen to
/Users/sean/.lein/self-installs/leiningen-2.3.0-standalone.jar now...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 403
/usr/bin/lein: line 63: download_failed_message: command not found

Thu Aug 08 21:11:19
(sean)-(jobs:0)-(/Developer/workspace/worldsingles)

On Thu, Aug 8, 2013 at 8:28 PM, Phil Hagelberg  wrote:
>
> Hello everyone.
>
> I'm happy to announce the release of Leiningen version 2.3.0. This
> version contains mostly minor fixes, but some highlights include faster
> test runs when using selectors (by skipping fixtures), better support
> for detecting ambiguous version resolutions via :pedantic, and fixes to
> better isolate different profiles in different :target-paths.
>
> * Add `:eval-in :pprint` for debugging. (Phil Hagelberg)
> * Support cleaning extra dirs with `:clean-targets`. (Yoshinori Kohyama)
> * Test-selectors skip fixtures too, not just running tests. (Gary Fredericks)
> * Place licenses and readmes into jars. (Phil Hagelberg)
> * Include LICENSE as separate file in templates. (Wolodja Wentland)
> * Allow aborting on ambiguous version resolution with `:pedantic`. (Nelson 
> Morris, Phil Hagelberg)
> * Scope `:compile-path` and `:native-path` under profile-specific target dir. 
> (Phil Hagelberg)
> * Fix bug where uberjar filename would include provided profile. (Phil 
> Hagelberg)
> * Deprecate explicit `self-install` command. (Phil Hagelberg)
> * Fix bugs around long lines in jar manifests. (Leon Barrett)
> * Support nested checkout dependencies. (Phil Hagelberg)
> * Fix bugs around `:filespecs`. (Jean Niklas L'orange)
>
> As usual, you can get the latest version by running `lein upgrade`.
>
> Thanks to all the contributors who helped make this happen.
>
> happy hacking,
> Phil



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

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

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

Re: [ANN] Leiningen 2.3.0 released

[Mark Engelberg]

I'm getting the same error.

On Thu, Aug 8, 2013 at 8:47 PM, Frank Hale  wrote:

> Upgrading failed for me.
>
> C:\Users\majyk\Desktop>lein upgrade
> The script at C:\Users\majyk\Desktop\local\lein.bat will be upgraded to
> the late
> st version in series 2.3.0-SNAPSHOT.
> Do you want to continue (Y/N)?Y
> Downloading latest Leiningen batch script...
> 1 file(s) moved.
>
> Upgrading...
> Downloading Leiningen now...
> Exception calling "DownloadFile" with "2" argument(s): "The remote server
> returned an error: (403) Forbidden."
> At line:1 char:17
> + & {param($a,$f) (new-object System.Net.WebClient).DownloadFile($a, $f)}
> "https:/ ...
> + ~~
> + CategoryInfo  : NotSpecified: (:) [],
> MethodInvocationException
> + FullyQualifiedErrorId : WebException
>
> The system cannot find the file specified.
> 1 file(s) moved.
> C:\Users\majyk\Desktop>
>
> I tried to manually download the jar file by using the following URL
>
> https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.0-standalone.jar
>
> And I got:
>
> This XML file does not appear to have any style information associated
> with it. The document tree is shown below.
>
> 
> AccessDenied
> Access Denied
> 5FA0428EC6828177
> 
> GArXYH0mU0svBmqdNQ16npOOFQUz3FDEL6wQ0ew7zfSl/cpCo1kEbrn1gzawBes4
> 
> 
>
>
> On Thu, Aug 8, 2013 at 11:28 PM, Phil Hagelberg  wrote:
>
>>
>> Hello everyone.
>>
>> I'm happy to announce the release of Leiningen version 2.3.0. This
>> version contains mostly minor fixes, but some highlights include faster
>> test runs when using selectors (by skipping fixtures), better support
>> for detecting ambiguous version resolutions via :pedantic, and fixes to
>> better isolate different profiles in different :target-paths.
>>
>> * Add `:eval-in :pprint` for debugging. (Phil Hagelberg)
>> * Support cleaning extra dirs with `:clean-targets`. (Yoshinori Kohyama)
>> * Test-selectors skip fixtures too, not just running tests. (Gary
>> Fredericks)
>> * Place licenses and readmes into jars. (Phil Hagelberg)
>> * Include LICENSE as separate file in templates. (Wolodja Wentland)
>> * Allow aborting on ambiguous version resolution with `:pedantic`.
>> (Nelson Morris, Phil Hagelberg)
>> * Scope `:compile-path` and `:native-path` under profile-specific target
>> dir. (Phil Hagelberg)
>> * Fix bug where uberjar filename would include provided profile. (Phil
>> Hagelberg)
>> * Deprecate explicit `self-install` command. (Phil Hagelberg)
>> * Fix bugs around long lines in jar manifests. (Leon Barrett)
>> * Support nested checkout dependencies. (Phil Hagelberg)
>> * Fix bugs around `:filespecs`. (Jean Niklas L'orange)
>>
>> As usual, you can get the latest version by running `lein upgrade`.
>>
>> Thanks to all the contributors who helped make this happen.
>>
>> happy hacking,
>> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] Leiningen 2.3.0 released

[Frank Hale]

Looks like I was way too fast. Upgrading just worked for me. Thank you!


On Thu, Aug 8, 2013 at 11:47 PM, Frank Hale  wrote:

> Upgrading failed for me.
>
> C:\Users\majyk\Desktop>lein upgrade
> The script at C:\Users\majyk\Desktop\local\lein.bat will be upgraded to
> the late
> st version in series 2.3.0-SNAPSHOT.
> Do you want to continue (Y/N)?Y
> Downloading latest Leiningen batch script...
> 1 file(s) moved.
>
> Upgrading...
> Downloading Leiningen now...
> Exception calling "DownloadFile" with "2" argument(s): "The remote server
> returned an error: (403) Forbidden."
> At line:1 char:17
> + & {param($a,$f) (new-object System.Net.WebClient).DownloadFile($a, $f)}
> "https:/ ...
> + ~~
> + CategoryInfo  : NotSpecified: (:) [],
> MethodInvocationException
> + FullyQualifiedErrorId : WebException
>
> The system cannot find the file specified.
> 1 file(s) moved.
> C:\Users\majyk\Desktop>
>
> I tried to manually download the jar file by using the following URL
>
> https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.0-standalone.jar
>
> And I got:
>
> This XML file does not appear to have any style information associated
> with it. The document tree is shown below.
>
> 
> AccessDenied
> Access Denied
> 5FA0428EC6828177
> 
> GArXYH0mU0svBmqdNQ16npOOFQUz3FDEL6wQ0ew7zfSl/cpCo1kEbrn1gzawBes4
> 
> 
>
>
> On Thu, Aug 8, 2013 at 11:28 PM, Phil Hagelberg  wrote:
>
>>
>> Hello everyone.
>>
>> I'm happy to announce the release of Leiningen version 2.3.0. This
>> version contains mostly minor fixes, but some highlights include faster
>> test runs when using selectors (by skipping fixtures), better support
>> for detecting ambiguous version resolutions via :pedantic, and fixes to
>> better isolate different profiles in different :target-paths.
>>
>> * Add `:eval-in :pprint` for debugging. (Phil Hagelberg)
>> * Support cleaning extra dirs with `:clean-targets`. (Yoshinori Kohyama)
>> * Test-selectors skip fixtures too, not just running tests. (Gary
>> Fredericks)
>> * Place licenses and readmes into jars. (Phil Hagelberg)
>> * Include LICENSE as separate file in templates. (Wolodja Wentland)
>> * Allow aborting on ambiguous version resolution with `:pedantic`.
>> (Nelson Morris, Phil Hagelberg)
>> * Scope `:compile-path` and `:native-path` under profile-specific target
>> dir. (Phil Hagelberg)
>> * Fix bug where uberjar filename would include provided profile. (Phil
>> Hagelberg)
>> * Deprecate explicit `self-install` command. (Phil Hagelberg)
>> * Fix bugs around long lines in jar manifests. (Leon Barrett)
>> * Support nested checkout dependencies. (Phil Hagelberg)
>> * Fix bugs around `:filespecs`. (Jean Niklas L'orange)
>>
>> As usual, you can get the latest version by running `lein upgrade`.
>>
>> Thanks to all the contributors who helped make this happen.
>>
>> happy hacking,
>> 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Leiningen 2.3.0 released

[Frank Hale]

Upgrading failed for me.

C:\Users\majyk\Desktop>lein upgrade
The script at C:\Users\majyk\Desktop\local\lein.bat will be upgraded to the
late
st version in series 2.3.0-SNAPSHOT.
Do you want to continue (Y/N)?Y
Downloading latest Leiningen batch script...
1 file(s) moved.

Upgrading...
Downloading Leiningen now...
Exception calling "DownloadFile" with "2" argument(s): "The remote server
returned an error: (403) Forbidden."
At line:1 char:17
+ & {param($a,$f) (new-object System.Net.WebClient).DownloadFile($a, $f)}
"https:/ ...
+ ~~
+ CategoryInfo  : NotSpecified: (:) [],
MethodInvocationException
+ FullyQualifiedErrorId : WebException

The system cannot find the file specified.
1 file(s) moved.
C:\Users\majyk\Desktop>

I tried to manually download the jar file by using the following URL

https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.0-standalone.jar

And I got:

This XML file does not appear to have any style information associated with
it. The document tree is shown below.


AccessDenied
Access Denied
5FA0428EC6828177

GArXYH0mU0svBmqdNQ16npOOFQUz3FDEL6wQ0ew7zfSl/cpCo1kEbrn1gzawBes4




On Thu, Aug 8, 2013 at 11:28 PM, Phil Hagelberg  wrote:

>
> Hello everyone.
>
> I'm happy to announce the release of Leiningen version 2.3.0. This
> version contains mostly minor fixes, but some highlights include faster
> test runs when using selectors (by skipping fixtures), better support
> for detecting ambiguous version resolutions via :pedantic, and fixes to
> better isolate different profiles in different :target-paths.
>
> * Add `:eval-in :pprint` for debugging. (Phil Hagelberg)
> * Support cleaning extra dirs with `:clean-targets`. (Yoshinori Kohyama)
> * Test-selectors skip fixtures too, not just running tests. (Gary
> Fredericks)
> * Place licenses and readmes into jars. (Phil Hagelberg)
> * Include LICENSE as separate file in templates. (Wolodja Wentland)
> * Allow aborting on ambiguous version resolution with `:pedantic`. (Nelson
> Morris, Phil Hagelberg)
> * Scope `:compile-path` and `:native-path` under profile-specific target
> dir. (Phil Hagelberg)
> * Fix bug where uberjar filename would include provided profile. (Phil
> Hagelberg)
> * Deprecate explicit `self-install` command. (Phil Hagelberg)
> * Fix bugs around long lines in jar manifests. (Leon Barrett)
> * Support nested checkout dependencies. (Phil Hagelberg)
> * Fix bugs around `:filespecs`. (Jean Niklas L'orange)
>
> As usual, you can get the latest version by running `lein upgrade`.
>
> Thanks to all the contributors who helped make this happen.
>
> happy hacking,
> 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Leiningen 2.3.0 released

[Phil Hagelberg]

Hello everyone.

I'm happy to announce the release of Leiningen version 2.3.0. This
version contains mostly minor fixes, but some highlights include faster
test runs when using selectors (by skipping fixtures), better support
for detecting ambiguous version resolutions via :pedantic, and fixes to
better isolate different profiles in different :target-paths.

* Add `:eval-in :pprint` for debugging. (Phil Hagelberg)
* Support cleaning extra dirs with `:clean-targets`. (Yoshinori Kohyama)
* Test-selectors skip fixtures too, not just running tests. (Gary Fredericks)
* Place licenses and readmes into jars. (Phil Hagelberg)
* Include LICENSE as separate file in templates. (Wolodja Wentland)
* Allow aborting on ambiguous version resolution with `:pedantic`. (Nelson 
Morris, Phil Hagelberg)
* Scope `:compile-path` and `:native-path` under profile-specific target dir. 
(Phil Hagelberg)
* Fix bug where uberjar filename would include provided profile. (Phil 
Hagelberg)
* Deprecate explicit `self-install` command. (Phil Hagelberg)
* Fix bugs around long lines in jar manifests. (Leon Barrett)
* Support nested checkout dependencies. (Phil Hagelberg)
* Fix bugs around `:filespecs`. (Jean Niklas L'orange)

As usual, you can get the latest version by running `lein upgrade`.

Thanks to all the contributors who helped make this happen.

happy hacking,
Phil


pgpYLmUsGH4v3.pgp
Description: PGP signature

Re: Clojure cheatsheets with several flavors of tooltips

[Alex Miller]

I updated the cheatsheet on clojure.org to the latest version (no 
tooltips). I don't have enough access to add the additional assets that 
would make that possible.

Alex

On Thursday, August 8, 2013 2:13:24 PM UTC-4, Andy Fingerhut wrote:
>
> It is relatively easy (with help from the right person with permission to 
> update clojure.org/cheatsheet) to update the non-tooltip version of the 
> cheatsheet there.
>
> When last they checked for me some months ago, it was less easy to enable 
> the tooltip version of the cheatsheet at clojure.org/cheatsheet.
>
> On the plus side, the link to the other versions of the cheatsheet is now 
> at the top of the page rather than the bottom, so it should be easier for 
> people to find.
>
> Andy
>
>
> On Thu, Aug 8, 2013 at 1:46 AM, Jakub Holy 
> > wrote:
>
>> Hi Andy, 
>>
>> This cheatsheet of yours is wonderful! 
>>
>> Are there any chances of getting it to clojure.org/cheatsheet? It is a 
>> shame that the cheatsheet at clojure.org is only for Clj 1.4 and doesn't 
>> have the beautiful tooltips.
>>
>> Thank you, Jakub
>>
>>
>> On Monday, April 23, 2012 8:35:12 PM UTC+2, Andy Fingerhut wrote:
>>>
>>> The tooltip version of the Clojure/Java cheatsheet is not published at 
>>> [1] just yet, but hopefully we can figure out how to make that happen in a 
>>> while:
>>>
>>> [1] http://clojure.org/cheatsheet
>>>
>>> There is an updated link at the bottom of that page called "Download 
>>> other versions" that leads to [2]:
>>>
>>> [2] http://jafingerhut.github.com
>>>
>>> Page [2] has links to 5 different variations of the cheatsheet, and I 
>>> plan for it to be the long term home for where I publish cheatsheets (in 
>>> addition to [1]).  They differ only in whether they have tooltips, how the 
>>> tooltip is implemented, and whether the tooltip includes a 1-line summary 
>>> of what ClojureDocs.org contained at a recent snapshot time.  It does not 
>>> query ClojureDocs.org every time it displays a tooltip.  That would slow 
>>> down the tooltip display, and likely be too much load on ClojureDocs.org.
>>>
>>> There are also links on that page to the Github repository containing 
>>> the source that generated the cheatsheets, and to the PDF versions.
>>>
>>> Note: It is free and quick to create an account on ClojureDocs.org, and 
>>> you don't even need to create an account if you have an OpenID account on 
>>> Google, Yahoo, or myOpenId.  Just click "log in" in the upper right corner 
>>> of [3], and you can edit examples and see alsos, too.  Don't be dismayed 
>>> thinking that you must write special markup to create examples.  In most 
>>> cases, all it takes is copying and pasting a REPL session, with some 
>>> editing to add comments if it helps understanding what is going on.  The 
>>> color highlighting is automatically added by the web server.
>>>
>>> [3] http://clojuredocs.org
>>>
>>> Andy
>>>
>>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

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

Re: Story

[Gary Johnson]

> I'm concerned that the ability to freely order comments and code will not 
> interact well with Clojure's namespaces.  With Clojure's namespaces, you 
> can have things with the same name in two different namespaces.  Functions 
> local to a namespace are referred to in one way, whereas you need some sort 
> of prefix to refer to one in a different namespace.  These prefixes are 
> often aliases, and the aliases may vary from one context to another, for 
> example, in one namespace I may refer to clojure.string as `str` and in 
> another namespace I may refer to it as `string`.
>
 
 

How do you deal with this "lack of context" when you present your code in a 
> way that is completely unrelated to the namespace organization of your 
> files?
>
>
Well, my experience thus far has led me down two different roads here.

Sometimes, I follow the path you came to on your own, which is to use one 
section or chapter per namespace. Within that section/chapter I can 
reorganize my code into whatever order lends itself to the clearest 
explanation. Because I use org-babel, it can export each namespace section 
to its own file during the tangling process. It's straightforward to run 
the program through the REPL or leiningen at that point.

The other approach that I have tried a few times now is to simply throw out 
the whole namespace construct entirely. After all, namespaces in functional 
programming mostly serve as simply a tool for collecting together functions 
and global vars that work together to accomplish some shared goal. If I am 
working on a literate program, it seems very natural for me to simply use 
sections/chapters to organize my functions by their purpose. The namespace 
then just becomes an unnecessary build construct. That is, I just tell 
org-babel to tangle the entire codebase to a single .clj file. Simple.
 

> Actually it isn't really a change in workflow but a change in mindset.
>> Literate programming is not documentation, they are different ideas.
>>
>
> Here's why I called it a change in workflow -- please correct me if I'm 
> mistaken:
>
> Every time the subject of literate programming comes up, I ask one simple 
> question:  When you get a stacktrace, is the file/line number information 
> correct?  A year or two back when I asked this, you elaborated that for 
> you, this was mostly a non-issue.  You said you developed your code by 
> sending over one tiny code block at a time to the REPL, rather than sending 
> a whole file over, and you never used any debugging facilities.  I consider 
> that a change in workflow.
>

I'm in the same boat with Tim. I try to test my functions one at a time 
through the REPL if possible. Whenever I have to make several modifications 
to different parts of the program at once, then I'll just re-evaluate the 
file and resume testing it one piece at a time. It is true that the 
stacktraces don't tend to get the file/line numbers right, but since 
Clojure stacktraces are good at naming the function where the error 
occured, I rarely find that to be an issue that C-s or C-r 
(isearch-forward/backward) can't solve in an instant.
 

>  
>
>>
>> For Clojure specific efforts see
>> http://daly.axiom-developer.org/clojure.pdf (PDF)
>> http://daly.axiom-developer.org/clojure.pamphlet (source)
>>
>
> This is a great example of using literate programming to document a 
> program that is complete and stable.  Have you successfully used literate 
> programming in a program that is rapidly evolving?
>
>
I have developed a rather large fire simulation toolkit using the LP model, 
and it was...interesting. Prior to that, I had only created shortish 
programs that were mostly just helping me to get my feet wet with the 
concepts and workflows of literate programming. When I worked on the fire 
program though, I ran into several new hurdles and successes.

The benefit of LP was (not surprisingly) that my design errors really 
jumped right out at me when I tried to explain them in English. Previously, 
I had started hacking together this program in the usual non-LP way, but I 
started to get stuck in some of the messy statistical details. I backed up 
and started over using LP, and my code's organization really came together 
beautifully in a matter of a couple of days of hacking.

The downside unfortunately was that I had never written a literate program 
at that scale before, and lacking Tim's 42 years of experience, I wasted a 
lot of time just trying to figure out basic code organization things like 
the ones you are asking in this thread: How do I deal with these namespace 
imports? What is the best way to organize toplevel chunk references? Should 
they be sequential or hierarchical? Can org-babel support multiple code 
blocks with the same name in the same way that Tim's tangle.lisp program 
does? (Hint: the answer is no) Why does tangling work with 
swank-clojure+SLIME but not with NREPL? (I had to patch that) How do I get 
org-mode to communicate with the Clojur

Re: IDE feature

[Sean Corfield]

On Thu, Aug 8, 2013 at 7:03 PM, Stanislav Sedov  wrote:
> One should definitely try it to see if it works for him, but saying it is a 
> panacea
> for balancing parens/braces is a bit for stretch as other tools solve this 
> problem
> as well.

It's important to draw the distinction between "parentheses matching"
(in terms of highlighting matching parens), "auto-closing parentheses"
(inserting ')' when you type '(' etc), and "structural editing". The
former two are provided by most editors (nearly all, these days I
suspect). The advocates of paredit are really talking about the latter
feature, of which the former two are minor sub-features that are
almost "just" an implementation detail.

Structural editing - being able to move / expand / contract /
reorganize entire s-expressions with simple keystrokes is where the
additional productivity comes from. Assuming you can get past paredit
not allowing you to type ill-formed code, of course :)
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: IDE feature

[Stanislav Sedov]

On Aug 8, 2013, at 5:44 AM, Lee Spector  wrote:

> Agreed. But good brace/paren *matching* (highlighting the mate and/or 
> unmatched brackets) solves this problem without all the downsides (IMHO) of 
> paredit.

I too had a similar experience.  Often when writing code I don't even produce 
it in
the LISP form but more like a freehand drawing, and then, if the idea turned out
to be valid, correct the syntax and put in the parenthesis.  Paren matching 
helps
me to do it without any effort by showing which parens are complimentary and,
more importantly, without getting in the way.

Having said that, paredit can be a great tool depending on your editing habits.
One should definitely try it to see if it works for him, but saying it is a 
panacea
for balancing parens/braces is a bit for stretch as other tools solve this 
problem
as well.

--
ST4096-RIPE

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

Re: IDE feature

[Norman Richards]

On Thu, Aug 8, 2013 at 7:20 PM, Sean Corfield wrote:

> Yes, paredit is a bit of a pain to get used to at first, but it really
>  does remove a whole slew of issues around parentheses in code, and it
> really does make you a lot more productive, especially once you learn
> the structural editing commands (I am surprised at how many times I
> use paredit-convolute-sexpr to help reorganize code - I'm almost at
> the point of binding it to a key sequence!).


It's almost like magic, when it fits the situation.  I've been toying with
the idea of starting a project to create a refactoring-like layer on top of
paredit to give more of these types of operations - and hopefully with
clearer names that convolute-sexpr...  Is anyone else interested in working
on refactoring tool?

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

Re: Story

[Tim Daly]

> I'm concerned that the ability to freely order comments and code will not
> interact well with Clojure's namespaces.

Hmmm. If raw code is confusing because namespaces are not apparent
perhaps it would help to surround the code with some natural language
that explains the specific namespace used. :-)

Seriously though, if you are trying to communicate from one human to
another and you're aware that 'str' and 'string' both refer to 
'clojure.string' but it might be ambiguous in the function under
discussion, wouldn't you consider mentioning this? 

> What this means is that Clojure code is pretty much unreadable unless you
> know the context it occurs in, specifically, you need to which namespace it
> is, know the symbols that were defined above it in the file, and know the
> aliases of all the namespaces referred to from this namespace.

If you're using namespaces so heavily perhaps it would make sense to
have a chapter/section early in the document to explain the structure
and use of namespaces. 

> If you freely bounce around from namespace to namespace in the description
> of your Clojure code, it's going to be very confusing.  This suggests to me
> that a well-organized literate program in Clojure would tend to document
> one namespace at a time.  Within a namespace, Clojure lets you move
> code

See? Already the notion of explaining code to the reader has led to
the notion of "a well-organized literate program". Writing good,
readable literature is a challenge but, hey, we're professionals.

> How do you deal with this "lack of context" when you present your code in a
> way that is completely unrelated to the namespace organization of your
> files?

Well I deal with it by using unique names rather than namespaces so 
I have never encountered the issue. The whole notion of namespaces
feels like an attempt by Java programmers to import the com.foo...
filenaming snafu into lisp. In the common lisp world I rarely 
ever see more than one package (namespace) so I guess I just haven't
seen this as an issue. Styles vary.

If you're using namespaces I presume you're also exporting an API.
Logically that implies that the namespace and its functions would live
in a separate chapter I suppose.

Tim Daly





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

Re: Story

[u1204]

> As far as I can tell, neither your script nor org-babel mode address the
> third prong of literate programming as defined by Knuth, specifically, the
> extensive cross-indexing, letting you know not only where functions are
> defined, but also where defined functions are used.  Why do you not
> consider this to be as essential as, say, the ability to reorder your code?

I do this with a latex macro. I have a "calls" macro that reads:

\calls{thisfn}{theFunctionCalled}

which creates 

  thisfn   77
 calls theFunctionCalled   42

  theFunctionCalled42
 called by thisfn  77

in the index. I use the hyperref latex package so each of these
becomes a hyperlink into the book. I have considered writing an
emacs function to generate the lines but it takes so little work
that I can't be bothered. I cons up an emacs keystroke macro,
point at the function called, and it adds the \calls line at
the head of the function. Point, C-x e, and it's done.

The index is really useful when reading or refactoring because I 
can find all of the callers of a function by just looking at the
back of the book.

I probably should add the \calls macro to the clojure pamphlet.

Tim


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

Re: IDE feature

[Sean Corfield]

On Thu, Aug 8, 2013 at 5:00 PM, Mark Engelberg  wrote:
> Getting back to the point of the original post, one of the nice features of
> DrRacket is that when you type `]`, it automatically puts either ']' or ')'

Having used DrRacket quite a bit lately, I do not find its handling of
parens to be particularly good. Regardless of whether I set it to
auto-close each opening paren or not, I constantly find myself with a
missing paren or an extra paren, or an incorrect mix of closing ))]))]
somewhere. It's not a problem I ever have in Emacs working on Clojure
- with paredit.

> this is like closing off a thought.  Paren matching is currently more
> arduous in Clojure, because you really do have to pay attention to which
> kind of delimiter you're closing off and type the right one, so I would love

Well, that's why folks advocate paredit - that problem simply goes away.

Yes, paredit is a bit of a pain to get used to at first, but it really
does remove a whole slew of issues around parentheses in code, and it
really does make you a lot more productive, especially once you learn
the structural editing commands (I am surprised at how many times I
use paredit-convolute-sexpr to help reorganize code - I'm almost at
the point of binding it to a key sequence!).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: Story

[u1204]

> Again. I'm with you on this one, Tim. Fear not. You aren't the only crazy 
> Clojure programmer putting the LP bug in people's ears. I must say, your 
> work on creating a literate version of the Clojure source was really 
> amazing. Any plans for maintaining it in the future as new Clojure releases 
> keep rolling out?

I forked the version that you see in the pamphlet so I could have a
single version. Assuming I manage to reverse-engineer the various
clever bits I would like to bring it up to date. Rich is easily able
to come up with new ideas faster than I can document the prior ones.

Tim

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

Re: IDE feature

[Mark Engelberg]

On Thu, Aug 8, 2013 at 4:50 PM, Norman Richards wrote:

> I do stand by comment.  You are free to disagree.   It's so painful to
> watch people (experienced LISPers and newbies alike) manually balancing
> parenthesis and spending inordinate amounts of time to do the simplest
> tasks like pulling an expression up into a let or wrapping/unwrapping
> blocks.  I've never once seen someone programming Clojure without paredit
> and thought to myself "wow - that guy/gal really has this down".  The scope
> of this statement is limited by the sadly small number of great Clojure
> coders I've had the pleasure of watching work.  I would truly love to see
> some counter examples.
>

Getting back to the point of the original post, one of the nice features of
DrRacket is that when you type `]`, it automatically puts either ']' or ')'
depending on which delimiter is required.  In Clojure, you could extend
this to `}`.  When you have this feature, there's nothing arduous about
matching parens.  You just hit `]` repeatedly to close off the section that
is now complete.  I really like the analogy put forth earlier in this
thread that this is like closing off a thought.  Paren matching is
currently more arduous in Clojure, because you really do have to pay
attention to which kind of delimiter you're closing off and type the right
one, so I would love to see this convenience feature implemented in one of
the Clojure environments.

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

Re: IDE feature

[Norman Richards]

On Thu, Aug 8, 2013 at 7:44 AM, Lee Spector  wrote:

>
> I was referring to Norman Richard's comment, which is what set me off:
> "Structural editing, like paredit, is really the only sane way to do
> Clojure code.  I honestly thing anyone who manually balances parenthesis or
> edits Clojure functions in a way that doesn't preserve the structural
> integrity of your expressions is just doing it wrong.  (not just doing it
> poorly - but doing it wrong)".
>

I do stand by comment.  You are free to disagree.   It's so painful to
watch people (experienced LISPers and newbies alike) manually balancing
parenthesis and spending inordinate amounts of time to do the simplest
tasks like pulling an expression up into a let or wrapping/unwrapping
blocks.  I've never once seen someone programming Clojure without paredit
and thought to myself "wow - that guy/gal really has this down".  The scope
of this statement is limited by the sadly small number of great Clojure
coders I've had the pleasure of watching work.  I would truly love to see
some counter examples.

If doing it by hand works for you, more power to you.  I think you are
doing it wrong, but my personal opinions thankfully don't really affect
much of the world outside my head.

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

Re: Story

[Mark Engelberg]

I started the post primarily to see if anyone else was using story, and if
anyone knew the status of that application, and this has turned more into a
discussion about literate programming.  That's okay though.  I'm very
interested in literate programming, and am always looking for a viable
toolset for incorporating it into my programming.  With that in mind, I'd
like to ask some followup questions about the toolchain(s) proposed by Tim
and the others:

On Wed, Aug 7, 2013 at 5:36 PM, Tim Daly  wrote:

> The ability to freely order comments and code is actually vital to the
> idea of literate programming. The key idea is writing to communicate
> ideas to another person. This almost certainly involves reordering
> and restructuring code.


I'm concerned that the ability to freely order comments and code will not
interact well with Clojure's namespaces.  With Clojure's namespaces, you
can have things with the same name in two different namespaces.  Functions
local to a namespace are referred to in one way, whereas you need some sort
of prefix to refer to one in a different namespace.  These prefixes are
often aliases, and the aliases may vary from one context to another, for
example, in one namespace I may refer to clojure.string as `str` and in
another namespace I may refer to it as `string`.

What this means is that Clojure code is pretty much unreadable unless you
know the context it occurs in, specifically, you need to which namespace it
is, know the symbols that were defined above it in the file, and know the
aliases of all the namespaces referred to from this namespace.

If you freely bounce around from namespace to namespace in the description
of your Clojure code, it's going to be very confusing.  This suggests to me
that a well-organized literate program in Clojure would tend to document
one namespace at a time.  Within a namespace, Clojure lets you move code
around using `declare` in order to achieve a better narrative flow.  So as
long as you have a tool that lets you specify the ordering of namespaces,
and then captures the top-to-bottom narrative flow within the namespace, I
think you'll get a nice, comprehensible literate program.  Anything more
jumbled than that seems likely to be too hard to follow, due to Clojure's
use of namespaces.

How do you deal with this "lack of context" when you present your code in a
way that is completely unrelated to the namespace organization of your
files?

Actually it isn't really a change in workflow but a change in mindset.
> Literate programming is not documentation, they are different ideas.
>

Here's why I called it a change in workflow -- please correct me if I'm
mistaken:

Every time the subject of literate programming comes up, I ask one simple
question:  When you get a stacktrace, is the file/line number information
correct?  A year or two back when I asked this, you elaborated that for
you, this was mostly a non-issue.  You said you developed your code by
sending over one tiny code block at a time to the REPL, rather than sending
a whole file over, and you never used any debugging facilities.  I consider
that a change in workflow.


>
> For Clojure specific efforts see
> http://daly.axiom-developer.org/clojure.pdf (PDF)
> http://daly.axiom-developer.org/clojure.pamphlet (source)
>

This is a great example of using literate programming to document a program
that is complete and stable.  Have you successfully used literate
programming in a program that is rapidly evolving?

Is it true that there's nothing like org-babel for environments other than
emacs?

To me, the most compelling reason to stick with tools that use regular
Clojure files and regular Clojure comments, especially for open source
projects, is that it allows for collaboration between people using
different Clojure platforms and tools, whereas locking things into a file
that can be only be processed by emacs or a unix shell script would limit
the pool of contributors.

One thing I do like about org-babel code is that it makes it easy to create
"live" examples in the docs that actually recompute when the code changes.

As far as I can tell, neither your script nor org-babel mode address the
third prong of literate programming as defined by Knuth, specifically, the
extensive cross-indexing, letting you know not only where functions are
defined, but also where defined functions are used.  Why do you not
consider this to be as essential as, say, the ability to reorder your code?

--Mark

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

Re: Making Music with Clojure: Meta-eX

[John D. Hume]

Great demonstration. I'd love to have the camera video side-by-side w/
screencast video (and large enough to read your code as you play).


On Thu, Aug 8, 2013 at 9:16 AM, Sam Aaron  wrote:

> Hey everyone,
>
> I just thought I'd give you a heads up of what I'm currently doing with
> Clojure and Overtone within the music space. I gave a talk at a music tech
> conference in London a good few months ago and they just put the video
> online:
>
> https://www.youtube.com/watch?v=zJqH5bNcIN0
>
> It's a pretty good description of the kinds of things we do (as Meta-eX)
> and a demonstration of the power of Clojure for making and manipulating
> music live in front of an audience. We also put a different spin on the
> notion of performance testing of our software ;-)
>
> The great thing about this video for me is that I can clearly see the huge
> improvements we've made since then. Clojure is such a joy to hack with and
> I feel wonderfully productive with it. Our system is a massively concurrent
> beast handling and coordinating many different streams of information
> (nREPL comms, MIDI devices, monomes, OSC messages, etc.) in addition to
> coordinating the synthesis engine with the GLSL shaders. Such fun stuff!
>
> For more info, check us out here: http://meta-ex.com
>
> Finally, for anyone in the London/Cambridge area - you might want to come
> to Wysing Arts Festival to see us play:
> http://www.wysingartscentre.org/whats_on/annual_music_festival
>
> Sam
>
> ---
> http://sam.aaron.name
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
http://elhumidor.blogspot.com/

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

Re: Debugging a custom reader literal for a sorted-set

[Jozef Wagner]

It may be a bug somewhere in a Compiler. I've lost track at 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6624

after debugging this:

user> (def x `(quote ~(list 1 (clojure.lang.PersistentTreeMap/create (seq 
[1 2 3 4])
#'user/x
user> x
(quote (1 #sorted-map (1 2 3 4)))
user> (.eval (clojure.lang.Compiler/analyze 
clojure.lang.Compiler$C/EXPRESSION x))
(1 #sorted-map (1 2 3 4))
user> (eval x)
(1 {1 2, 3 4})

JW

On Thursday, August 8, 2013 10:14:57 PM UTC+2, David James wrote:
>
> I'd really appreciate if others could take a look. I wonder if it may 
> be a Clojure reader bug. 
>
> On Thu, Aug 8, 2013 at 3:55 PM, Jozef Wagner 
> > 
> wrote: 
> > It seems there is something else in data reader which causes this 
> change. 
> > 
> > user=> (class '#foo/sm (1 2 3 4)) 
> > clojure.lang.PersistentArrayMap 
> > user=> (class (read-string "#foo/sm (1 2 3 4)")) 
> > clojure.lang.PersistentTreeMap 
> > 
> > It's quite puzzling. In both cases the evaluation does not take place, 
> but 
> > still the transition to PersistentArrayMap occurs. 
> > 
> > JW 
> > 
> > On Thursday, August 8, 2013 9:49:24 PM UTC+2, David James wrote: 
> >> 
> >> That's a good point about: 
> >> user=> eval (to-sorted-map '(1 2 3 4))) 
> >> {1 2, 3 4} 
> >> 
> >> But this should work, right? 
> >> user=> (assoc #sorted-map (:a 1 :b 2) :c 3) 
> >> {:c 3, :a 1, :b 2} ; incorrect 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

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

Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata

[Jonathan Fischer Friberg]

I'd suggest avoiding macros until you absolutely know that you need them.
Usually they aren't necessary.


Problem with this is that you don't really know when you need them unless
you know what they do.

On Thu, Aug 8, 2013 at 9:58 PM, Jace Bennett  wrote:

> Thanks, Mike.
>
> I guess my simple example is too simple. Out of the hypothetical, have you
> used techniques like this?
>
> I have this nagging feeling that there is a more direct and idiomatic way
> to glean this sort of information from my code. I mean, that's why we use
> AST's, right? So we can process them? I shouldn't need a data structure
> like the endpoint map in the first place. I just don't know how to
> capitalize on this rather abstract and vague notion.
>
> How do folks usually go about it when they have a desire to query the
> running system about its shape and structure?
>
>
>
> On Thu, Aug 8, 2013 at 2:36 AM, Mikera wrote:
>
>> I'd suggest avoiding macros until you absolutely know that you need them.
>> Usually they aren't necessary.
>>
>> Prefer writing pure functions (without side effects) - these are easier
>> to reason about, easier to test, simpler to write correctly and easier to
>> plug together / compose via higher order functions.
>>
>> For example, in your endpoint example I would probably just use three
>> functions:
>> - a pure "add endpoint metadata to an endpoint map" function
>> - an impure "update endpoints" function that updates endpoints using an
>> endpoint map
>> - a function that calls both of the above to declare and launch a new
>> endpoint
>>
>> There might be a few other helper functions as well but hopefully you get
>> the idea.
>>
>>
>> On Thursday, 8 August 2013 03:19:15 UTC+1, Jace Bennett wrote:
>>>
>>> Thanks to the community for a wondrous programming environment. I
>>> discovered SICP last year, and fell in love with the idea of lisp. But I've
>>> come to a point where I think I need practice on moderately sized projects
>>> before more reading will help.
>>>
>>> When starting on almost any moderately scoped effort, I quickly run into
>>> a class of problems which I think may be a fit for macros, but I want to
>>> understand what is the idiomatic way to approach them in clojure.
>>>
>>> Most of my professional experience is in .NET, and that is probably
>>> coloring my thought patterns a bit. In that context, I often use reflection
>>> scans and type metadata to configure infrastructural bits and dry things
>>> up. Instead of having to explicitly register components in the more dynamic
>>> areas of my app, I use conventions to select components to register from
>>> the metadata I have about my code.
>>>
>>> I can imagine using macros in clojure to accumulate metadata about my
>>> declarations so that I can query them at runtime. For example, maybe a
>>> "defendpoint" macro that sets up a handler AND adds it to the routing table
>>> (or more directly an "endpoint map" which I then use to make routing
>>> decisions among other things).
>>>
>>> Admittedly, something about the sound of the phrase "it's just data"
>>> tells me I'm sniffin up the wrong tree here. But I don't know how to turn
>>> that nagging feeling into working code.
>>>
>>> Is this a reasonable use of the macro? What about doing the registration
>>> at macro-expansion time vs emitting runtime code to do it? How should one
>>> approach the problems space otherwise?
>>>
>>>  Thanks 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
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Story

[Gary Johnson]

Again. I'm with you on this one, Tim. Fear not. You aren't the only crazy 
Clojure programmer putting the LP bug in people's ears. I must say, your 
work on creating a literate version of the Clojure source was really 
amazing. Any plans for maintaining it in the future as new Clojure releases 
keep rolling out?

  ~Gary

On Thursday, August 8, 2013 12:00:26 PM UTC-4, da...@axiom-developer.org 
wrote:
>
> >   I'm with you 100% on the mind-blowing greatness of literate 
> >   programming, 
>
> Actually, it's not the technology of literate programming I'm on about. 
>
> Rich Hickey comes up with marvelous and insightful ideas and reduces 
> them to practice, like his work on reasonable big-O data structures 
> or his work on software transactional memory. Or his work on ... 
>
> Yet if you look at the code you see nothing. 
>
> Which means that the next set of people who get to slice-and-dice 
> the code after Rich will miss some of the insight and get it wrong. 
> I've seen it happen in many places. The apprentice is rarely as good 
> as the master. Not to cast stones at the rest of the Clojure group, 
> I'm just using hasty-generalization, my favorite form of reasoning, 
> from my experience. 
>
> I find that literate programming is the only way to capture the 
> insight and keep it where it belongs, adjacent and intermixed with 
> the code, but written for humans-to-human communication. Clojure 
> is heavy with great ideas and they need to be communicated intact. 
>
> Tim Daly 
>
>
>

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

Re: Debugging a custom reader literal for a sorted-set

[David James]

I'd really appreciate if others could take a look. I wonder if it may
be a Clojure reader bug.

On Thu, Aug 8, 2013 at 3:55 PM, Jozef Wagner  wrote:
> It seems there is something else in data reader which causes this change.
>
> user=> (class '#foo/sm (1 2 3 4))
> clojure.lang.PersistentArrayMap
> user=> (class (read-string "#foo/sm (1 2 3 4)"))
> clojure.lang.PersistentTreeMap
>
> It's quite puzzling. In both cases the evaluation does not take place, but
> still the transition to PersistentArrayMap occurs.
>
> JW
>
> On Thursday, August 8, 2013 9:49:24 PM UTC+2, David James wrote:
>>
>> That's a good point about:
>> user=> eval (to-sorted-map '(1 2 3 4)))
>> {1 2, 3 4}
>>
>> But this should work, right?
>> user=> (assoc #sorted-map (:a 1 :b 2) :c 3)
>> {:c 3, :a 1, :b 2} ; incorrect
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata

[Jace Bennett]

Thanks, Mike.

I guess my simple example is too simple. Out of the hypothetical, have you
used techniques like this?

I have this nagging feeling that there is a more direct and idiomatic way
to glean this sort of information from my code. I mean, that's why we use
AST's, right? So we can process them? I shouldn't need a data structure
like the endpoint map in the first place. I just don't know how to
capitalize on this rather abstract and vague notion.

How do folks usually go about it when they have a desire to query the
running system about its shape and structure?



On Thu, Aug 8, 2013 at 2:36 AM, Mikera  wrote:

> I'd suggest avoiding macros until you absolutely know that you need them.
> Usually they aren't necessary.
>
> Prefer writing pure functions (without side effects) - these are easier to
> reason about, easier to test, simpler to write correctly and easier to plug
> together / compose via higher order functions.
>
> For example, in your endpoint example I would probably just use three
> functions:
> - a pure "add endpoint metadata to an endpoint map" function
> - an impure "update endpoints" function that updates endpoints using an
> endpoint map
> - a function that calls both of the above to declare and launch a new
> endpoint
>
> There might be a few other helper functions as well but hopefully you get
> the idea.
>
>
> On Thursday, 8 August 2013 03:19:15 UTC+1, Jace Bennett wrote:
>>
>> Thanks to the community for a wondrous programming environment. I
>> discovered SICP last year, and fell in love with the idea of lisp. But I've
>> come to a point where I think I need practice on moderately sized projects
>> before more reading will help.
>>
>> When starting on almost any moderately scoped effort, I quickly run into
>> a class of problems which I think may be a fit for macros, but I want to
>> understand what is the idiomatic way to approach them in clojure.
>>
>> Most of my professional experience is in .NET, and that is probably
>> coloring my thought patterns a bit. In that context, I often use reflection
>> scans and type metadata to configure infrastructural bits and dry things
>> up. Instead of having to explicitly register components in the more dynamic
>> areas of my app, I use conventions to select components to register from
>> the metadata I have about my code.
>>
>> I can imagine using macros in clojure to accumulate metadata about my
>> declarations so that I can query them at runtime. For example, maybe a
>> "defendpoint" macro that sets up a handler AND adds it to the routing table
>> (or more directly an "endpoint map" which I then use to make routing
>> decisions among other things).
>>
>> Admittedly, something about the sound of the phrase "it's just data"
>> tells me I'm sniffin up the wrong tree here. But I don't know how to turn
>> that nagging feeling into working code.
>>
>> Is this a reasonable use of the macro? What about doing the registration
>> at macro-expansion time vs emitting runtime code to do it? How should one
>> approach the problems space otherwise?
>>
>> Thanks 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Debugging a custom reader literal for a sorted-set

[Jozef Wagner]

It seems there is something else in data reader which causes this change.

user=> (class '#foo/sm (1 2 3 4))
clojure.lang.PersistentArrayMap
user=> (class (read-string "#foo/sm (1 2 3 4)"))
clojure.lang.PersistentTreeMap

It's quite puzzling. In both cases the evaluation does not take place, but 
still the transition to PersistentArrayMap occurs.

JW

On Thursday, August 8, 2013 9:49:24 PM UTC+2, David James wrote:
>
> That's a good point about: 
> user=> eval (to-sorted-map '(1 2 3 4))) 
> {1 2, 3 4} 
>
> But this should work, right? 
> user=> (assoc #sorted-map (:a 1 :b 2) :c 3) 
> {:c 3, :a 1, :b 2} ; incorrect 
>

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

Re: Debugging a custom reader literal for a sorted-set

[David James]

That's a good point about:
user=> eval (to-sorted-map '(1 2 3 4)))
{1 2, 3 4}

But this should work, right?
user=> (assoc #sorted-map (:a 1 :b 2) :c 3)
{:c 3, :a 1, :b 2} ; incorrect

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

Re: Debugging a custom reader literal for a sorted-set

[Jozef Wagner]

The problem is the evaluation. PersistentTreeMap evaluates to the 
PersistentArrayMap (or PersistentHashMap).

user=> (class (to-sorted-map '(1 2 3 4)))
clojure.lang.PersistentTreeMap
user=> (class #sorted-map (1 2 3 4))
clojure.lang.PersistentArrayMap
user=> (class #sorted-map (1 2 3 4 5 6 7 8 9 0 11 12 13 14 15 16 17 18 19 
20))
clojure.lang.PersistentHashMap
user=> (read-string "#sorted-map (1 2 3 4)")
#sorted-map (1 2 3 4)
user=> #sorted-map (1 2 3 4)
{1 2, 3 4}
user=> (to-sorted-map '(1 2 3 4))
#sorted-map (1 2 3 4)
user=> (eval (to-sorted-map '(1 2 3 4)))
{1 2, 3 4}

JW

On Thursday, August 8, 2013 7:29:16 PM UTC+2, David James wrote:
>
> I am having trouble with an implementation of a custom reader literal 
> called #sorted-set. 
>
> Please see my short code first: 
> https://github.com/xpe/sorted-map-literal 
>
> Why does this work correctly: 
> (to-sorted-map '(1 2 3 4)) 
> #sorted-map (1 2 3 4) ; correct 
>
> While this does not? 
> #sorted-map (1 2 3 4) 
> {1 2, 3 4} ; incorrect 
>
> Thanks, 
> David 
>
> P.S. BTW, I understand that I should not release non-namespaced reader 
> literals; this is just a self-contained experiment. 
>

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

Re: Clojure cheatsheets with several flavors of tooltips

[Andy Fingerhut]

It is relatively easy (with help from the right person with permission to
update clojure.org/cheatsheet) to update the non-tooltip version of the
cheatsheet there.

When last they checked for me some months ago, it was less easy to enable
the tooltip version of the cheatsheet at clojure.org/cheatsheet.

On the plus side, the link to the other versions of the cheatsheet is now
at the top of the page rather than the bottom, so it should be easier for
people to find.

Andy


On Thu, Aug 8, 2013 at 1:46 AM, Jakub Holy  wrote:

> Hi Andy,
>
> This cheatsheet of yours is wonderful!
>
> Are there any chances of getting it to clojure.org/cheatsheet? It is a
> shame that the cheatsheet at clojure.org is only for Clj 1.4 and doesn't
> have the beautiful tooltips.
>
> Thank you, Jakub
>
>
> On Monday, April 23, 2012 8:35:12 PM UTC+2, Andy Fingerhut wrote:
>>
>> The tooltip version of the Clojure/Java cheatsheet is not published at
>> [1] just yet, but hopefully we can figure out how to make that happen in a
>> while:
>>
>> [1] http://clojure.org/cheatsheet
>>
>> There is an updated link at the bottom of that page called "Download
>> other versions" that leads to [2]:
>>
>> [2] http://jafingerhut.github.com
>>
>> Page [2] has links to 5 different variations of the cheatsheet, and I
>> plan for it to be the long term home for where I publish cheatsheets (in
>> addition to [1]).  They differ only in whether they have tooltips, how the
>> tooltip is implemented, and whether the tooltip includes a 1-line summary
>> of what ClojureDocs.org contained at a recent snapshot time.  It does not
>> query ClojureDocs.org every time it displays a tooltip.  That would slow
>> down the tooltip display, and likely be too much load on ClojureDocs.org.
>>
>> There are also links on that page to the Github repository containing the
>> source that generated the cheatsheets, and to the PDF versions.
>>
>> Note: It is free and quick to create an account on ClojureDocs.org, and
>> you don't even need to create an account if you have an OpenID account on
>> Google, Yahoo, or myOpenId.  Just click "log in" in the upper right corner
>> of [3], and you can edit examples and see alsos, too.  Don't be dismayed
>> thinking that you must write special markup to create examples.  In most
>> cases, all it takes is copying and pasting a REPL session, with some
>> editing to add comments if it helps understanding what is going on.  The
>> color highlighting is automatically added by the web server.
>>
>> [3] http://clojuredocs.org
>>
>> Andy
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Debugging a custom reader literal for a sorted-set

[David James]

I am having trouble with an implementation of a custom reader literal
called #sorted-set.

Please see my short code first:
https://github.com/xpe/sorted-map-literal

Why does this work correctly:
(to-sorted-map '(1 2 3 4))
#sorted-map (1 2 3 4) ; correct

While this does not?
#sorted-map (1 2 3 4)
{1 2, 3 4} ; incorrect

Thanks,
David

P.S. BTW, I understand that I should not release non-namespaced reader
literals; this is just a self-contained experiment.

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

Re: Function as key of a map

[Peter Juhl Christiansen]

Here is a somewhat simplified example:

Lets say you decide to model positions as {:x 12 :y 10}  {:x 23 :y 34} 
...And then you want to describe what is present at each of these positions

Then this can simply be done using a map

{ {:x 12 :y 10}  "A house", 
  {:x 23 :y 34} "Other house"}

This may not sound useful but once you wrap you head around it, situations 
where this simplifies things pop up often enough.

/PJC 

On Wednesday, August 7, 2013 6:28:00 PM UTC+2, Abraham wrote:
>
>  this is in reference to the followng article 
>
>
>
>
> http://blog.safaribooksonline.com/2013/08/06/two-simple-clojure-tricks-with-values/
>
> wherin it says any value ( function , vector , other data structure of 
> clj) can be used as key for a hashed map. 
>
> can anybody enlighten how is it useful if function or any other data 
> struc. is used as key?
>
> Thnks
> A
>
>

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

Re: Clojure cheatsheets with several flavors of tooltips

[Jakub Holy]

Hi Andy, 

This cheatsheet of yours is wonderful! 

Are there any chances of getting it to clojure.org/cheatsheet? It is a 
shame that the cheatsheet at clojure.org is only for Clj 1.4 and doesn't 
have the beautiful tooltips.

Thank you, Jakub

On Monday, April 23, 2012 8:35:12 PM UTC+2, Andy Fingerhut wrote:
>
> The tooltip version of the Clojure/Java cheatsheet is not published at [1] 
> just yet, but hopefully we can figure out how to make that happen in a 
> while:
>
> [1] http://clojure.org/cheatsheet
>
> There is an updated link at the bottom of that page called "Download other 
> versions" that leads to [2]:
>
> [2] http://jafingerhut.github.com
>
> Page [2] has links to 5 different variations of the cheatsheet, and I plan 
> for it to be the long term home for where I publish cheatsheets (in 
> addition to [1]).  They differ only in whether they have tooltips, how the 
> tooltip is implemented, and whether the tooltip includes a 1-line summary 
> of what ClojureDocs.org contained at a recent snapshot time.  It does not 
> query ClojureDocs.org every time it displays a tooltip.  That would slow 
> down the tooltip display, and likely be too much load on ClojureDocs.org.
>
> There are also links on that page to the Github repository containing the 
> source that generated the cheatsheets, and to the PDF versions.
>
> Note: It is free and quick to create an account on ClojureDocs.org, and 
> you don't even need to create an account if you have an OpenID account on 
> Google, Yahoo, or myOpenId.  Just click "log in" in the upper right corner 
> of [3], and you can edit examples and see alsos, too.  Don't be dismayed 
> thinking that you must write special markup to create examples.  In most 
> cases, all it takes is copying and pasting a REPL session, with some 
> editing to add comments if it helps understanding what is going on.  The 
> color highlighting is automatically added by the web server.
>
> [3] http://clojuredocs.org
>
> Andy
>
>

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

Re: Confused by var eval behaviour

[Jamie Brandon]

The Fn case works because print-dup is defined on fns:

user=> (binding [*print-dup* true] (println (fn [] nil)))
#=(user$eval2502$fn__2503. )
nil
user=> (read-string "#=(user$eval2502$fn__2503. )")
#

I still can't figure out why Compiler.emitValue is used though. Am I
right in thinking that clojure.core/eval is not calling the function
that the compiler uses, but instead serializing everything and pushing
it through the same pathway as compiling text files?

On 8 August 2013 16:43, Christophe Grand  wrote:
> Right now I ca't figure why the fn case is working but the anonyous Var is
> failing because the vars are specially handled:
>
> else if(value instanceof Var)
> {
> Var var = (Var) value;
> gen.push(var.ns.name.toString());
> gen.push(var.sym.toString());
> gen.invokeStatic(RT_TYPE, Method.getMethod("clojure.lang.Var
> var(String,String)"));
> }
>
> Christophe
>
>
>
> On Thu, Aug 8, 2013 at 4:44 PM, Jamie Brandon 
> wrote:
>>
>> What if it isn't inside a constant?
>>
>> user=> (eval `(fn [] ~#'x))
>> #
>>
>> user=> (with-local-vars [x nil] (eval `(fn [] ~x)))
>> CompilerException java.lang.NullPointerException,
>> compiling:(NO_SOURCE_PATH:1:1)
>>
>> How about functions? These are unreadable but they still eval
>> correctly inside  constants.
>>
>> user=> (letfn [(x [] nil)] (eval x))
>> #
>>
>> user=> (letfn [(x [] nil)] (eval [x]))
>> [#]
>>
>> user=> (read-string "#")
>> RuntimeException Unreadable form  clojure.lang.Util.runtimeException
>> (Util.java:219)
>>
>> user=> (defn x [] nil)
>> #'user/x
>>
>> user=> (eval x)
>> #
>>
>> user=> (eval [x])
>> [#]
>>
>> user=> (read-string "#> user$eval1381$x__1382@e3b7c27>")
>> RuntimeException Unreadable form  clojure.lang.Util.runtimeException
>> (Util.java:219)
>>
>> On 8 August 2013 14:58, Christophe Grand  wrote:
>> > The error is caused by the fact that eval sees the var as a constant (or
>> > part of) and tries to serialize the constant.
>> > # is unreadable while #'user/x is that explains teh
>> > difference in behaviour.
>> >
>> >
>> > On Thu, Aug 8, 2013 at 3:40 PM, Jamie Brandon
>> > 
>> > wrote:
>> >>
>> >> This has me stumped:
>> >>
>> >> user=> (with-local-vars [x nil] (eval x))
>> >> #
>> >> user=> (with-local-vars [x nil] (eval [x]))
>> >> CompilerException java.lang.NullPointerException,
>> >> compiling:(NO_SOURCE_PATH:1:1)
>> >>
>> >> By comparison:
>> >>
>> >> user=> (def x nil)
>> >> #'user/x
>> >> user=> (eval #'x)
>> >> #'user/x
>> >> user=> (eval [#'x])
>> >> [#'user/x]
>> >>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to clojure@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to clojure+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > On Clojure http://clj-me.cgrand.net/
>> > Clojure Programming http://clojurebook.com
>> > Training, Consulting & Contracting http://lambdanext.eu/
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send 

Re: IDE feature

[Paul L. Snyder]

On Thu, 08 Aug 2013, Sam Aaron wrote:

> Haha, I come back to this list after a good few months of not being able
> to keep up with the volume to find a rant about paredit - priceless!
> 
> Seriously though, these things are all personal and as such clearly get
> people's backs up. So for what it's worth, let me throw my thoughts in...

I'm very much of the "can't we all just get along?" school, too.

One of my biggest resistance-points to paredit was that I hated the idea of
the editor producing syntactically correct structures even though the
partially written logic behind them was incomplete and broken. Unclosed
parentheses were a visible marker of unfinished thoughts, and having them
automatically closed was like chopping down signposts I was relying on.

The switch from this mindset wasn't easy, and didn't happen until I'd been
editing paredit-only for a good while. It still makes me nervous.  One
result is that I actively try to write shorter functions (which is good
practice, anyway). I also more frequently put mental state that might be
lost into FIXME comments or logging statements, so there is a visual (and,
better, searchable) reminder of incompleteness if I switch contexts.

A second stumbling-block was paredit's occasional tendency just to get
something wrong and make it obnoxiously hard to fix. Being unable to
delete a bad parenthesis or switch the nesting level of a square bracket is
utterly rage-inducing. My early experiences with this were quite
aggravating. Who would want to use a mode that breaks the backspace key?

The realization that I could manually fix problems by killing/cutting the
bad bits (C-SPACE at one end, positioning the cursor at the other, then C-w
to kill the region) and, if necessary, yanking/pasting them to an
appropriate location (C-y) meant that I could jump outside of paredit's
straightjacket when the annoyance factor started rising, without losing 
ground by disabling it completely. I'd long before rebound C-q to something
else so I never relied on the ability to C-q  to force an
insertion, but that option is there, too.

> I wouldn't go so far as to say that not using paredit (or an equivalent)
> is "the wrong way" (although I probably would in the pub after a couple
> of pints). However, it *definitely* feels to me that using an editor that
> doesn't support paredit feels broken - and I always wind up writing
> broken code with missing parenthesis because my mind is used to not
> worrying about them. Also, moving forms around manually is pretty
> dreadful and syntax-error prone - paredit massively improves this.

I'd probably agree with you over those beers to the extent that trying to go
non-paredit is deeply suboptimal if you're live-coding!

There's a deeper issue that gets back to Lee's comment about thinking of
code as text. If that is the mental model one is using, paredit's approach
is almost offensive.  That's the way I felt for quite a while, and I am
deeply sympathetic to this perspective.

When paredit finally started clicking with me, I realized that I was
thinking about programming as "editing and manipulating S-expressions"
rather than as "editing text". I now find that this jump to a higher level
of abstraction has reduced a certain level of friction between the code 
in my brain and the code that needs to appear on the screen.

Tools are important, and the match between tools and mental models is
critical. One of the marvelous things about Emacs is how easily you
can adapt the tool to fit the shape of your mind (even though with paredit
you might have to meet it halfway).

What actually let me get paredit embedded into my work habits
was that I changed my approach to keybindings. Rather than blithely
learning and accepting the defaults, I began to optimize my entire
environment.

The best enabler for this was binding Hyper to the Caps Lock key.

This has been absolutely brilliant. Hyper is a green field.  You don't
interfere with any existing bindings, and you can still rely on the normal
keystroke documentation for any packages you might have installed.  So, for
example, I could never recall how barfage and slurpage were supposed to
work but using

  H-M-n paredit-backward-slurp-sexp
  H-M-m paredit-backward-barf-sexp
  H-M-, paredit-forward-barf-sexp
  H-M-. paredit-forward-slurp-sexp

feels completely natural. I also bind commonly used keys like delimiters to
the Hyper plane, such as H-l for '(', H-; for ')'.

> The analogy I think about is touch typing. People might also make a claim
> that programmers that don't touch type are doing it "the wrong way". I
> personally definitely find that touch typing improves my ability to
> program as it frees my mind from having to worry about my finger
> placement and looking at the keyboard. Also, I can do an awful lot with
> key combos which all serves to improve my bandwidth of communication to
> the computer. However, this isn't an experience you can explain to
> someone - you have to be a touch typer t

Re: Story

[Tim Daly]

>   I'm with you 100% on the mind-blowing greatness of literate
>   programming, 

Actually, it's not the technology of literate programming I'm on about.

Rich Hickey comes up with marvelous and insightful ideas and reduces
them to practice, like his work on reasonable big-O data structures
or his work on software transactional memory. Or his work on ...

Yet if you look at the code you see nothing. 

Which means that the next set of people who get to slice-and-dice
the code after Rich will miss some of the insight and get it wrong.
I've seen it happen in many places. The apprentice is rarely as good
as the master. Not to cast stones at the rest of the Clojure group,
I'm just using hasty-generalization, my favorite form of reasoning,
from my experience.

I find that literate programming is the only way to capture the 
insight and keep it where it belongs, adjacent and intermixed with
the code, but written for humans-to-human communication. Clojure 
is heavy with great ideas and they need to be communicated intact.

Tim Daly


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

Re: Confused by var eval behaviour

[Christophe Grand]

Right now I ca't figure why the fn case is working but the anonyous Var is
failing because the vars are specially handled:

else if(value instanceof Var)
{
Var var = (Var) value;
gen.push(var.ns.name.toString());
gen.push(var.sym.toString());
gen.invokeStatic(RT_TYPE, Method.getMethod("clojure.lang.Var
var(String,String)"));
}

Christophe


On Thu, Aug 8, 2013 at 4:44 PM, Jamie Brandon
wrote:

> What if it isn't inside a constant?
>
> user=> (eval `(fn [] ~#'x))
> #
>
> user=> (with-local-vars [x nil] (eval `(fn [] ~x)))
> CompilerException java.lang.NullPointerException,
> compiling:(NO_SOURCE_PATH:1:1)
>
> How about functions? These are unreadable but they still eval
> correctly inside  constants.
>
> user=> (letfn [(x [] nil)] (eval x))
> #
>
> user=> (letfn [(x [] nil)] (eval [x]))
> [#]
>
> user=> (read-string "#")
> RuntimeException Unreadable form  clojure.lang.Util.runtimeException
> (Util.java:219)
>
> user=> (defn x [] nil)
> #'user/x
>
> user=> (eval x)
> #
>
> user=> (eval [x])
> [#]
>
> user=> (read-string "# >")
> RuntimeException Unreadable form  clojure.lang.Util.runtimeException
> (Util.java:219)
>
> On 8 August 2013 14:58, Christophe Grand  wrote:
> > The error is caused by the fact that eval sees the var as a constant (or
> > part of) and tries to serialize the constant.
> > # is unreadable while #'user/x is that explains teh
> > difference in behaviour.
> >
> >
> > On Thu, Aug 8, 2013 at 3:40 PM, Jamie Brandon <
> ja...@scattered-thoughts.net>
> > wrote:
> >>
> >> This has me stumped:
> >>
> >> user=> (with-local-vars [x nil] (eval x))
> >> #
> >> user=> (with-local-vars [x nil] (eval [x]))
> >> CompilerException java.lang.NullPointerException,
> >> compiling:(NO_SOURCE_PATH:1:1)
> >>
> >> By comparison:
> >>
> >> user=> (def x nil)
> >> #'user/x
> >> user=> (eval #'x)
> >> #'user/x
> >> user=> (eval [#'x])
> >> [#'user/x]
> >>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >
> >
> >
> > --
> > On Clojure http://clj-me.cgrand.net/
> > Clojure Programming http://clojurebook.com
> > Training, Consulting & Contracting http://lambdanext.eu/
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



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

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

Re: IDE feature

[Sam Aaron]

On 8 Aug 2013, at 16:29, Tim Daly  wrote:

>> Find me a person who fluently used paredit that stopped and reverted back to 
>> manual parenthesis manipulation.
> 
> /me raises my hand.
> 
> Structural editing was useful in LispVM (on IBM mainframes) where the
> display was 12 lines by 40 characters. It might also be useful for the
> iPad lisping app. If your IDE uses 80% of your display for buttons,
> lines, and icons I can see where it would be useful, since most of the
> text area is gone.
> 
> However, I've been programming in lisp for 42 years on everything from
> punched cards to mega-displays. I find that keeping structure and
> counting parens is like finishing a thought. It just happens.  I don't
> remember the last time I had a paren-balance bug. I've spent the last 13
> years rewriting and refactoring Axiom which is 1.2 million lines of lisp
> code so I have a fair sized sample as a test case.
> 
> I find that programming occurs "in my head" and that the computer is
> only useful for recording the results. For me, smart editing and IDEs
> get in my way, like a helpful newbie in a metal shop.
> 
> Then again I don't use IDEs. If it works for you, go for it.

Super interesting - thanks for sharing this. 

The fact that this list contains such a broad range of such interesting people 
is a real asset to the Clojure community.

Sam

---
http://sam.aaron.name

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

Re: Story

[Tim Daly]

Re: org-mode. 

I stand corrected. Some days my religious zeal overwhelms my fingers.
Thanks for setting the record straight.

Tim

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

Re: IDE feature

[Tim Daly]

> Find me a person who fluently used paredit that stopped and reverted back to 
> manual parenthesis manipulation.

/me raises my hand.

Structural editing was useful in LispVM (on IBM mainframes) where the
display was 12 lines by 40 characters. It might also be useful for the
iPad lisping app. If your IDE uses 80% of your display for buttons,
lines, and icons I can see where it would be useful, since most of the
text area is gone.

However, I've been programming in lisp for 42 years on everything from
punched cards to mega-displays. I find that keeping structure and
counting parens is like finishing a thought. It just happens.  I don't
remember the last time I had a paren-balance bug. I've spent the last 13
years rewriting and refactoring Axiom which is 1.2 million lines of lisp
code so I have a fair sized sample as a test case.

I find that programming occurs "in my head" and that the computer is
only useful for recording the results. For me, smart editing and IDEs
get in my way, like a helpful newbie in a metal shop.

Then again I don't use IDEs. If it works for you, go for it.

Tim


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

[ANN] progressbar: easy progress bars in clojure

[Travis Vachon]

progressbar transparently wraps any "map"-able object to print
feedback to standard out as items in the seq are processed:


user> (require '[progressbar.core :refer [progressbar]])
user> (doall (map identity (progressbar (range 10) :print-every 2)))
[) # this is animated from [) to [) using \r
(0 1 2 3 4 5 6 7 8 9)


It is designed to make getting feedback about a long running seq-based
computation trivial. More information, and the source, here:

http://eng.copious.com/blog/2013/08/05/progressbar/
https://github.com/travis/progressbar

Enjoy!

Travis

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

Java Web Start (JWS), Clojure, and a security issue

[Terje Dahl]

I struggled for many working days a while back trying to get my 
Clojure-and-JavaFX app to run as JWS. 
The app ran fine when launched as a stand-alone (from the jar).  And code 
signing and JNLP were supposedly done state-of-the-art.  But I kept getting 
a security exception à la "accessing a restricted/private member"...
I gave up.

But yesterday I recompiled and deployed an already existing application.
Now I suddenly got the same error.  But I figured out what the cause was:
I had upgraded the apps Clojure library from 1.4.0 to 1.5.1
As soon as I switched back to 1.4.0, the problem disappeared!  :-D

Any thoughts on what new "magic under the hood" is employed in 1.5 that was 
not pressent in 1.4, and which the JWS security sandbox does not accept 
even when code is signed and "all-permissions" is accepted and works in 
other parts of the code?

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

Re: Confused by var eval behaviour

[Jamie Brandon]

This actually seems to work for deftypes too:

user=> (deftype Foo [])
user.Foo
user=> (eval (Foo.))
#
user=> (eval [(Foo.)])
[#]

But not for arbitrary objects:

user=> (eval (java.io.StringReader. "foo"))
#

user=> (eval [(java.io.StringReader. "foo")])
CompilerException java.lang.RuntimeException: Can't embed object in
code, maybe print-dup not defined: java.io.StringReader@7504a5ce,
compiling:(NO_SOURCE_PATH:1:1)


So I guess Fn and Var have print-dup methods defined. I still don't
understand why print-dup is used at all though.

On 8 August 2013 15:44, Jamie Brandon  wrote:
> What if it isn't inside a constant?
>
> user=> (eval `(fn [] ~#'x))
> #
>
> user=> (with-local-vars [x nil] (eval `(fn [] ~x)))
> CompilerException java.lang.NullPointerException, 
> compiling:(NO_SOURCE_PATH:1:1)
>
> How about functions? These are unreadable but they still eval
> correctly inside  constants.
>
> user=> (letfn [(x [] nil)] (eval x))
> #
>
> user=> (letfn [(x [] nil)] (eval [x]))
> [#]
>
> user=> (read-string "#")
> RuntimeException Unreadable form  clojure.lang.Util.runtimeException
> (Util.java:219)
>
> user=> (defn x [] nil)
> #'user/x
>
> user=> (eval x)
> #
>
> user=> (eval [x])
> [#]
>
> user=> (read-string "#")
> RuntimeException Unreadable form  clojure.lang.Util.runtimeException
> (Util.java:219)
>
> On 8 August 2013 14:58, Christophe Grand  wrote:
>> The error is caused by the fact that eval sees the var as a constant (or
>> part of) and tries to serialize the constant.
>> # is unreadable while #'user/x is that explains teh
>> difference in behaviour.
>>
>>
>> On Thu, Aug 8, 2013 at 3:40 PM, Jamie Brandon 
>> wrote:
>>>
>>> This has me stumped:
>>>
>>> user=> (with-local-vars [x nil] (eval x))
>>> #
>>> user=> (with-local-vars [x nil] (eval [x]))
>>> CompilerException java.lang.NullPointerException,
>>> compiling:(NO_SOURCE_PATH:1:1)
>>>
>>> By comparison:
>>>
>>> user=> (def x nil)
>>> #'user/x
>>> user=> (eval #'x)
>>> #'user/x
>>> user=> (eval [#'x])
>>> [#'user/x]
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>>
>> --
>> On Clojure http://clj-me.cgrand.net/
>> Clojure Programming http://clojurebook.com
>> Training, Consulting & Contracting http://lambdanext.eu/
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: butlast with reducers

[Jozef Wagner]

Wow, thank you very much! A perfect solution.

At the end, wouldn't be good if the reducers would implement alongside 
CollReduce also a Seqable interface, so that reducers could be used as a 
drop in replacement for today's sequence functions (map, filter, ...)? 
CollReduce implements 'eager' computations (when calling reduce and fold) 
while the Seqable would implement a lazy ones (when calling seq).

Functions working with seqs (e.g. first, rest) always call seq before 
working with the collection, so this would be transparent for them. It may 
be a breaking change and complects things a bit though...

JW

On Thursday, August 8, 2013 3:34:31 PM UTC+2, Christophe Grand wrote:
>
> ArrayDeque based versions:
>
> (defn drop-last [n coll]
>   (reducer coll
> (fn [f1]
>   (let [buffer (java.util.ArrayDeque. (int n))]
> (fn self
>   ([] (f1))
>   ([ret x]
> (.add buffer x)
> (if (<= (count buffer) n)
>   ret
>   (f1 ret (.pop buffer)
>
> (defn take-last [n coll]
>   (reify clojure.core.protocols.CollReduce
> (coll-reduce [this f1]
>   (clojure.core.protocols/coll-reduce this f1 (f1)))
> (coll-reduce [_ f1 init]
>   (clojure.core.protocols/coll-reduce
> (doto (clojure.core.protocols/coll-reduce 
>   coll
>   (fn [^java.util.Deque q x]
> (.add q x)
> (when (> (count q) n)
>   (.pop q))
> q) (java.util.ArrayDeque. (int n))) prn)
> f1 init
>
>
>
> On Thu, Aug 8, 2013 at 3:16 PM, Christophe Grand 
> 
> > wrote:
>
>> You need to use a buffer to defer calls to the reduced function
>>
>> (defn drop-last [n coll]
>>   (reducer coll
>> (fn [f1]
>>   (let [buffer 
>> (atom clojure.lang.PersistentQueue/EMPTY)]
>> (fn self
>>   ([] (f1))
>>   ([ret x]
>> (let [b (swap! buffer conj x)]
>>   (if (<= (count @buffer) n)
>> ret
>> (do 
>>   (swap! buffer pop)
>>   (f1 ret (peek b)))
>>
>> An array or a ring buffer should be used instead of  the atom and 
>> persistent queue combo to reduce allocation.
>>
>> take-last is harder because you can't know when the reduction is over 
>> when using #'reducer, so you have to implement CollReduce yourself:
>>
>> (defn take-last [n coll]
>>   (reify clojure.core.protocols.CollReduce
>> (coll-reduce [this f1]
>>   (clojure.core.protocols/coll-reduce this f1 (f1)))
>> (coll-reduce [_ f1 init]
>>   (clojure.core.protocols/coll-reduce
>> (clojure.core.protocols/coll-reduce 
>>   coll
>>   (fn [q x]
>> (let [q (conj q x)]
>>   (if (<= (count q) n)
>> q
>> (pop q clojure.lang.PersistentQueue/EMPTY)
>> f1 init
>>
>> again, use of a mutable array/buffer would be preferable. 
>>
>> hth,
>>
>> Christophe
>>
>> On Thu, Aug 8, 2013 at 1:00 PM, Jozef Wagner 
>> 
>> > wrote:
>>
>>> Is it possible to implement efficient butlast (and drop-last, take-last) 
>>> with reducers? The only solution I can think of needs additional reduce to 
>>> compute count, which may often be undesirable. 
>>>
>>> Or is it OK to say that reducers are not designed for such cases?
>>>
>>> JW
>>>
>>> -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>
>>
>> -- 
>> On Clojure http://clj-me.cgrand.net/
>> Clojure Programming http://clojurebook.com
>> Training, Consulting & Contracting http://lambdanext.eu/ 
>>  
>
>
>
> -- 
> On Clojure http://clj-me.cgrand.net/
> Clojure Programming http://clojurebook.com
> Training, Consulting & Contracting http://lambdanext.eu/ 
>  

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

Re: Confused by var eval behaviour

[Jamie Brandon]

What if it isn't inside a constant?

user=> (eval `(fn [] ~#'x))
#

user=> (with-local-vars [x nil] (eval `(fn [] ~x)))
CompilerException java.lang.NullPointerException, compiling:(NO_SOURCE_PATH:1:1)

How about functions? These are unreadable but they still eval
correctly inside  constants.

user=> (letfn [(x [] nil)] (eval x))
#

user=> (letfn [(x [] nil)] (eval [x]))
[#]

user=> (read-string "#")
RuntimeException Unreadable form  clojure.lang.Util.runtimeException
(Util.java:219)

user=> (defn x [] nil)
#'user/x

user=> (eval x)
#

user=> (eval [x])
[#]

user=> (read-string "#")
RuntimeException Unreadable form  clojure.lang.Util.runtimeException
(Util.java:219)

On 8 August 2013 14:58, Christophe Grand  wrote:
> The error is caused by the fact that eval sees the var as a constant (or
> part of) and tries to serialize the constant.
> # is unreadable while #'user/x is that explains teh
> difference in behaviour.
>
>
> On Thu, Aug 8, 2013 at 3:40 PM, Jamie Brandon 
> wrote:
>>
>> This has me stumped:
>>
>> user=> (with-local-vars [x nil] (eval x))
>> #
>> user=> (with-local-vars [x nil] (eval [x]))
>> CompilerException java.lang.NullPointerException,
>> compiling:(NO_SOURCE_PATH:1:1)
>>
>> By comparison:
>>
>> user=> (def x nil)
>> #'user/x
>> user=> (eval #'x)
>> #'user/x
>> user=> (eval [#'x])
>> [#'user/x]
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
>
> --
> On Clojure http://clj-me.cgrand.net/
> Clojure Programming http://clojurebook.com
> Training, Consulting & Contracting http://lambdanext.eu/
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: core.async: loop bindings can't see prior brindings

[Kemar]

I've posted a bug report:
http://dev.clojure.org/jira/browse/ASYNC-17

Am Donnerstag, 8. August 2013 16:04:15 UTC+2 schrieb tbc++:
>
> Yep, this is bug, please submit a bug report through JIRA, and I'll try to 
> get it fixed ASAP. 
>
> Timothy
>
>
> On Thu, Aug 8, 2013 at 9:22 AM, David Nolen 
> > wrote:
>
>> You can report issues here: http://dev.clojure.org/jira/browse/ASYNC
>>
>>
>>
>> On Thu, Aug 8, 2013 at 7:02 AM, Kemar >wrote:
>>
>>> Hi there,
>>>
>>> it seems that loop bindings cant's see prior bindings made in
>>> the same loop when the loop is in a go block:
>>>
>>> (require '[clojure.core.async :refer [go]])
 (go (loop [x 41 y (inc x)] (println y)))

>>>
>>> Rather than printing 42, it either complains that x can't be
>>> resolved in that context (in Clojure), or that x ist an undeclared
>>> Var (in ClojureScript).
>>>
>>> Cheers,
>>> Kevin
>>>
>>>
>>> P.S.: is there a better place to post bug reports for core.async?
>>>
>>> -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Re: Story

[Gary Johnson]

Tim,

  I'm with you 100% on the mind-blowing greatness of literate programming, 
but I do have to correct you on org-babel. It is actually a very nicely 
done LP development system. You write your content as you would a book or 
article, using sections and subsections, paragraphs, ordered and unordered 
lists, tables, embedded images, links, and so on. Code is placed within 
specially delimited blocks that specify the source language (thus 
triggering the appropriate emacs mode for syntax highlighting) as well as 
special rules for code and output export. Obviously, code blocks can (and 
should be) out of order in the Org document so as to enable clear 
exposition. When you are ready to test out the finished product, org-babel 
provides built in tangle and weave commands.

  I used your homebrew solution on axiom-developer.org a few years ago when 
I was first getting my feet wet with literate programming. However, 
org-babel provides several unique advantage IMHO over 
make+tangle.lisp+latex:

  1. Org markup is much simpler and more visually recognizable than LaTeX 
although anything you can do with LaTeX, you can do in Org mode. This is 
because you can export an Org file to LaTeX and Org markup syntax allows 
for inline LaTeX code blocks if you want to do anything that is not already 
supported by the standard markup. 

  2. Org mode can export my Literate Program to many, many different 
formats with a simple keystroke. These include (but are not limited to) 
HTML, LaTeX, ASCII, and LibreOffice ODF. Thus my woven program can be 
distributed as a PDF file, Word Document, or webpage.

  3. Org mode supports multiple programming languages within a single file. 
This allows me to chain together in the same document (and thus in the same 
exposition) a shell script written in Bash, a Python script for generating 
a graph, and a Clojure program for running a webserver. When I trigger the 
tangle procedure, each language's code is written out to its own file(s) 
and run through the correct interpreter or compiler. Amazingly, code blocks 
in different languages can even be annotated such that they pass values 
between one another like functions in a Lisp environment.

  4. Org supports Live Code Evaluation. By simply placing my cursor (the 
point in Emacs jargon) within any code block in my Literate Program and 
pressing C-c C-c, Emacs will trigger an external shell for that language, 
recursively expand any code block references included within the selected 
code block (i.e., a local tangling procedure), send the expanded code to 
the external shell (be it an interpreter or compiler), evalutate the 
result, and pretty print this result into my LP file in an annotated RESULT 
block directly after the code block that I evaluated. If I tweak the code 
and reevaluate it, the RESULT block's contents are updated in place. This 
provides an in-document multi-language REPL-like experience. Note, of 
course, that the contents of these RESULT blocks may then be optionally 
woven into my formatted output, which is particularly useful in explaining 
the behavior of code with examples or in automatically generating tables or 
figures for illustrative purposes.

There are many more features that Org mode supports that would take...well, 
the entire Org mode manual to explain. However, these LP features are 
really quite useful, and I do genuinely think more people interested in LP 
should give them a try.

For more information, please check out the Babel section of the Org Mode 
manual:

  http://orgmode.org/worg/org-contrib/babel/intro.html

I also HIGHLY recommend the 2012 journal article published on Org Mode's 
Babel features in the Journal of Statistical Software:

*A Multi-Language Computing Environment for Literate Programming and 
Reproducible Research*
  by Eric Schulte, Dan Davison, Thomas Dye, Carsten Dominik

  http://www.jstatsoft.org/v46/i03


  As you like to say, Tim...

  Get Literate!
~Gary


On Wednesday, August 7, 2013 8:36:51 PM UTC-4, da...@axiom-developer.org 
wrote:
>
> > Recently, I discovered the "story" literate programming tool for 
> Clojure, 
> > which I prefer to marginalia: 
> > https://github.com/jedahu/story 
> > 
> > ... (snip) ... 
> > 
> > I had never heard of "story", but ran across a mention of it while 
> looking 
> > through the issues on marginalia's github site, so I decided to give it 
> a 
> > try.  It's similar to marginalia, in that it's not true literate 
> > programming -- it doesn't let you freely order your comments and code 
> > irrespective of how they appear in the final files, but is a tool for 
> > extracting long comments written in markdown in order to weave some sort 
> of 
> > narrative explanation of why the code is written the way it is. 
>
> The ability to freely order comments and code is actually vital to the 
> idea of literate programming. The key idea is writing to communicate 
> ideas to another person. This almost certainly involves reordering 
> a

Making Music with Clojure: Meta-eX

[Sam Aaron]

Hey everyone,

I just thought I'd give you a heads up of what I'm currently doing with Clojure 
and Overtone within the music space. I gave a talk at a music tech conference 
in London a good few months ago and they just put the video online:

https://www.youtube.com/watch?v=zJqH5bNcIN0

It's a pretty good description of the kinds of things we do (as Meta-eX) and a 
demonstration of the power of Clojure for making and manipulating music live in 
front of an audience. We also put a different spin on the notion of performance 
testing of our software ;-)

The great thing about this video for me is that I can clearly see the huge 
improvements we've made since then. Clojure is such a joy to hack with and I 
feel wonderfully productive with it. Our system is a massively concurrent beast 
handling and coordinating many different streams of information (nREPL comms, 
MIDI devices, monomes, OSC messages, etc.) in addition to coordinating the 
synthesis engine with the GLSL shaders. Such fun stuff!

For more info, check us out here: http://meta-ex.com

Finally, for anyone in the London/Cambridge area - you might want to come to 
Wysing Arts Festival to see us play: 
http://www.wysingartscentre.org/whats_on/annual_music_festival

Sam

---
http://sam.aaron.name

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

Re: IDE feature

[Sam Aaron]

Haha, I come back to this list after a good few months of not being able to 
keep up with the volume to find a rant about paredit - priceless!

Seriously though, these things are all personal and as such clearly get 
people's backs up. So for what it's worth, let me throw my thoughts in...

I wouldn't go so far as to say that not using paredit (or an equivalent) is 
"the wrong way" (although I probably would in the pub after a couple of pints). 
However, it *definitely* feels to me that using an editor that doesn't support 
paredit feels broken - and I always wind up writing broken code with missing 
parenthesis because my mind is used to not worrying about them. Also, moving 
forms around manually is pretty dreadful and syntax-error prone - paredit 
massively improves this.

The analogy I think about is touch typing. People might also make a claim that 
programmers that don't touch type are doing it "the wrong way". I personally 
definitely find that touch typing improves my ability to program as it frees my 
mind from having to worry about my finger placement and looking at the 
keyboard. Also, I can do an awful lot with key combos which all serves to 
improve my bandwidth of communication to the computer. However, this isn't an 
experience you can explain to someone - you have to be a touch typer to 
appreciate these benefits. Similarly, you have to be fluent with paredit to 
appreciate the benefits. With both, you have to go through a pretty dreadful 
learning curve where your productivity is reduced.

Here's a challenge:
Find me a person who touch typed fluently that stopped and reverted back to 
single finger typing.
Find me a person who fluently used paredit that stopped and reverted back to 
manual parenthesis manipulation.

Sam

---
http://sam.aaron.name


On 8 Aug 2013, at 14:09, Stefan Kamphausen  wrote:

> Just for the record:
> 
> I've been coding in Lisp for close to 30 years 
> 
> 
> make that 20 years in my case and I agree with Lee. 
> 
> Can't live without C-M-q, TAB, M-left/right, C-M-SPC but paredit is 
> interfering too much for /my/ taste.
> 
> stefan
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

Re: core.async: loop bindings can't see prior brindings

[Timothy Baldridge]

Yep, this is bug, please submit a bug report through JIRA, and I'll try to
get it fixed ASAP.

Timothy


On Thu, Aug 8, 2013 at 9:22 AM, David Nolen  wrote:

> You can report issues here: http://dev.clojure.org/jira/browse/ASYNC
>
>
>
> On Thu, Aug 8, 2013 at 7:02 AM, Kemar  wrote:
>
>> Hi there,
>>
>> it seems that loop bindings cant's see prior bindings made in
>> the same loop when the loop is in a go block:
>>
>> (require '[clojure.core.async :refer [go]])
>>> (go (loop [x 41 y (inc x)] (println y)))
>>>
>>
>> Rather than printing 42, it either complains that x can't be
>> resolved in that context (in Clojure), or that x ist an undeclared
>> Var (in ClojureScript).
>>
>> Cheers,
>> Kevin
>>
>>
>> P.S.: is there a better place to post bug reports for core.async?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

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

Re: Confused by var eval behaviour

[Christophe Grand]

The error is caused by the fact that eval sees the var as a constant (or
part of) and tries to serialize the constant.
# is unreadable while #'user/x is that explains teh
difference in behaviour.


On Thu, Aug 8, 2013 at 3:40 PM, Jamie Brandon
wrote:

> This has me stumped:
>
> user=> (with-local-vars [x nil] (eval x))
> #
> user=> (with-local-vars [x nil] (eval [x]))
> CompilerException java.lang.NullPointerException,
> compiling:(NO_SOURCE_PATH:1:1)
>
> By comparison:
>
> user=> (def x nil)
> #'user/x
> user=> (eval #'x)
> #'user/x
> user=> (eval [#'x])
> [#'user/x]
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


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

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

Confused by var eval behaviour

[Jamie Brandon]

This has me stumped:

user=> (with-local-vars [x nil] (eval x))
#
user=> (with-local-vars [x nil] (eval [x]))
CompilerException java.lang.NullPointerException, compiling:(NO_SOURCE_PATH:1:1)

By comparison:

user=> (def x nil)
#'user/x
user=> (eval #'x)
#'user/x
user=> (eval [#'x])
[#'user/x]

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

Re: butlast with reducers

[Christophe Grand]

ArrayDeque based versions:

(defn drop-last [n coll]
  (reducer coll
(fn [f1]
  (let [buffer (java.util.ArrayDeque. (int n))]
(fn self
  ([] (f1))
  ([ret x]
(.add buffer x)
(if (<= (count buffer) n)
  ret
  (f1 ret (.pop buffer)

(defn take-last [n coll]
  (reify clojure.core.protocols.CollReduce
(coll-reduce [this f1]
  (clojure.core.protocols/coll-reduce this f1 (f1)))
(coll-reduce [_ f1 init]
  (clojure.core.protocols/coll-reduce
(doto (clojure.core.protocols/coll-reduce
  coll
  (fn [^java.util.Deque q x]
(.add q x)
(when (> (count q) n)
  (.pop q))
q) (java.util.ArrayDeque. (int n))) prn)
f1 init



On Thu, Aug 8, 2013 at 3:16 PM, Christophe Grand wrote:

> You need to use a buffer to defer calls to the reduced function
>
> (defn drop-last [n coll]
>   (reducer coll
> (fn [f1]
>   (let [buffer
> (atom clojure.lang.PersistentQueue/EMPTY)]
> (fn self
>   ([] (f1))
>   ([ret x]
> (let [b (swap! buffer conj x)]
>   (if (<= (count @buffer) n)
> ret
> (do
>   (swap! buffer pop)
>   (f1 ret (peek b)))
>
> An array or a ring buffer should be used instead of  the atom and
> persistent queue combo to reduce allocation.
>
> take-last is harder because you can't know when the reduction is over when
> using #'reducer, so you have to implement CollReduce yourself:
>
> (defn take-last [n coll]
>   (reify clojure.core.protocols.CollReduce
> (coll-reduce [this f1]
>   (clojure.core.protocols/coll-reduce this f1 (f1)))
> (coll-reduce [_ f1 init]
>   (clojure.core.protocols/coll-reduce
> (clojure.core.protocols/coll-reduce
>   coll
>   (fn [q x]
> (let [q (conj q x)]
>   (if (<= (count q) n)
> q
> (pop q clojure.lang.PersistentQueue/EMPTY)
> f1 init
>
> again, use of a mutable array/buffer would be preferable.
>
> hth,
>
> Christophe
>
> On Thu, Aug 8, 2013 at 1:00 PM, Jozef Wagner wrote:
>
>> Is it possible to implement efficient butlast (and drop-last, take-last)
>> with reducers? The only solution I can think of needs additional reduce to
>> compute count, which may often be undesirable.
>>
>> Or is it OK to say that reducers are not designed for such cases?
>>
>> JW
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> On Clojure http://clj-me.cgrand.net/
> Clojure Programming http://clojurebook.com
> Training, Consulting & Contracting http://lambdanext.eu/
>



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

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

Re: core.async: loop bindings can't see prior brindings

[David Nolen]

You can report issues here: http://dev.clojure.org/jira/browse/ASYNC


On Thu, Aug 8, 2013 at 7:02 AM, Kemar  wrote:

> Hi there,
>
> it seems that loop bindings cant's see prior bindings made in
> the same loop when the loop is in a go block:
>
> (require '[clojure.core.async :refer [go]])
>> (go (loop [x 41 y (inc x)] (println y)))
>>
>
> Rather than printing 42, it either complains that x can't be
> resolved in that context (in Clojure), or that x ist an undeclared
> Var (in ClojureScript).
>
> Cheers,
> Kevin
>
>
> P.S.: is there a better place to post bug reports for core.async?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: butlast with reducers

[Christophe Grand]

You need to use a buffer to defer calls to the reduced function

(defn drop-last [n coll]
  (reducer coll
(fn [f1]
  (let [buffer
(atom clojure.lang.PersistentQueue/EMPTY)]
(fn self
  ([] (f1))
  ([ret x]
(let [b (swap! buffer conj x)]
  (if (<= (count @buffer) n)
ret
(do
  (swap! buffer pop)
  (f1 ret (peek b)))

An array or a ring buffer should be used instead of  the atom and
persistent queue combo to reduce allocation.

take-last is harder because you can't know when the reduction is over when
using #'reducer, so you have to implement CollReduce yourself:

(defn take-last [n coll]
  (reify clojure.core.protocols.CollReduce
(coll-reduce [this f1]
  (clojure.core.protocols/coll-reduce this f1 (f1)))
(coll-reduce [_ f1 init]
  (clojure.core.protocols/coll-reduce
(clojure.core.protocols/coll-reduce
  coll
  (fn [q x]
(let [q (conj q x)]
  (if (<= (count q) n)
q
(pop q clojure.lang.PersistentQueue/EMPTY)
f1 init

again, use of a mutable array/buffer would be preferable.

hth,

Christophe

On Thu, Aug 8, 2013 at 1:00 PM, Jozef Wagner  wrote:

> Is it possible to implement efficient butlast (and drop-last, take-last)
> with reducers? The only solution I can think of needs additional reduce to
> compute count, which may often be undesirable.
>
> Or is it OK to say that reducers are not designed for such cases?
>
> JW
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

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

Re: IDE feature

[Stefan Kamphausen]

Just for the record:

I've been coding in Lisp for close to 30 years 
>
>
make that 20 years in my case and I agree with Lee. 

Can't live without C-M-q, TAB, M-left/right, C-M-SPC but paredit is 
interfering too much for /my/ taste.

stefan

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

Re: IDE feature

[Lee Spector]

On Aug 8, 2013, at 8:15 AM, Phillip Lord wrote:
>> 
>> I'm happy to drop this after this message too. I just couldn't let such an
>> unnecessarily insulting email stand without a response
> 
> I think he was trying to support you actually. He's saying "it doesn't
> work for you, which means it's the wrong tool!"

I was referring to Norman Richard's comment, which is what set me off: 
"Structural editing, like paredit, is really the only sane way to do Clojure 
code.  I honestly thing anyone who manually balances parenthesis or edits 
Clojure functions in a way that doesn't preserve the structural integrity of 
your expressions is just doing it wrong.  (not just doing it poorly - but doing 
it wrong)".


>> And one other part of my dislike comes from my work teaching new programmers,
>> who have enough to learn and overcome without having to rethink the concept 
>> of
>> editing before turning (a b (c d)) into (a (b c d)), which they could do
>> effortlessly in a normal editor.
> 
> I can see this as a problem, although, there again new programmers are
> likely to have problems getting parens balanced. I've never taught lisp
> to new programmers, but given the difficult those I have taught Java
> have with brace/paren matching, I guess it's a problem. 

Agreed. But good brace/paren *matching* (highlighting the mate and/or unmatched 
brackets) solves this problem without all the downsides (IMHO) of paredit.

 -Lee

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

Re: IDE feature

[Neale Swinnerton]

> I can see this as a problem, although, there again new programmers are
> likely to have problems getting parens balanced. I've never taught lisp
> to new programmers, but given the difficult those I have taught Java
> have with brace/paren matching, I guess it's a problem.
>
> It's always hard to know when to bring in tools, especially the ones
> that are really useful, but have a learning curve.
>

Smart Parens[1] looks interesting/useful. Seems like a less oppressive
paredit without losing too many features and gaining others. This might be
easier for beginners.

[1] https://github.com/Fuco1/smartparens/wiki

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

Re: IDE feature

[Phillip Lord]

Lee Spector  writes:

> On Aug 8, 2013, at 3:34 AM, Robert Stuttaford wrote:
>
>> Lee has a valid point. Lee's point is: let me decide. Put paredit in, but 
>> let me turn it off if I want. 
>> 
>> I agree that paredit is the only sane way for me and for anyone who doesn't
>> have Lee's muscle memory to overcome. But for Lee, paredit is 'doing it
>> wrong', because he doesn't enjoy it and he's unproductive that way. And that
>> trumps any particular language, tool, paradigm, what-have-you.
>> 
>> I mean, there are some people who are perfectly productive and happy in C++.
>> If that's possible, then anything is :-)
>
> I'm happy to drop this after this message too. I just couldn't let such an
> unnecessarily insulting email stand without a response


I think he was trying to support you actually. He's saying "it doesn't
work for you, which means it's the wrong tool!"

> And one other part of my dislike comes from my work teaching new programmers,
> who have enough to learn and overcome without having to rethink the concept of
> editing before turning (a b (c d)) into (a (b c d)), which they could do
> effortlessly in a normal editor.

I can see this as a problem, although, there again new programmers are
likely to have problems getting parens balanced. I've never taught lisp
to new programmers, but given the difficult those I have taught Java
have with brace/paren matching, I guess it's a problem. 

It's always hard to know when to bring in tools, especially the ones
that are really useful, but have a learning curve.

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

Re: IDE feature

[Lee Spector]

On Aug 8, 2013, at 3:34 AM, Robert Stuttaford wrote:

> Lee has a valid point. Lee's point is: let me decide. Put paredit in, but let 
> me turn it off if I want. 
> 
> I agree that paredit is the only sane way for me and for anyone who doesn't 
> have Lee's muscle memory to overcome. But for Lee, paredit is 'doing it 
> wrong', because he doesn't enjoy it and he's unproductive that way. And that 
> trumps any particular language, tool, paradigm, what-have-you.
> 
> I mean, there are some people who are perfectly productive and happy in C++. 
> If that's possible, then anything is :-)

I'm happy to drop this after this message too. I just couldn't let such an 
unnecessarily insulting email stand without a response, and BTW I also don't 
know where the alleged data about majorities/minorities is coming from (not 
that such data would even mean that the minority are "doing it wrong"). 

Before I do, though, I'd like to clarify: my dislike of paredit isn't just 
about muscle memory, although that's part of it. The biggest issue is that when 
I write code it is very often not structurally sound while I'm composing it, 
and that's intentional and important. Yes, it has to be structurally sound when 
I evaluate it, but along the way I often jump around non-linearly and add weird 
things when I think about them as I have new ideas, or copy chunks of code with 
unbalanced parentheses from someplace else because I know I need *something* 
related but I'm not yet sure how the pieces should fit into the new structure 
yet. Sort of like I'm composing this email (and like I compose most text), 
which had ungrammatical stuff at first but which I've rearranged and patched up 
(I hope :-) as I've proceeded. For me, paredit is like a straightjacket that 
prevents me from writing code in this free-form way, which is an important part 
of the way I work. 

And one other part of my dislike comes from my work teaching new programmers, 
who have enough to learn and overcome without having to rethink the concept of 
editing before turning (a b (c d)) into (a (b c d)), which they could do 
effortlessly in a normal editor.

Okay. I'm done.

  -Lee

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

core.async: loop bindings can't see prior brindings

[Kemar]

Hi there,

it seems that loop bindings cant's see prior bindings made in
the same loop when the loop is in a go block:

(require '[clojure.core.async :refer [go]])
> (go (loop [x 41 y (inc x)] (println y)))
>

Rather than printing 42, it either complains that x can't be
resolved in that context (in Clojure), or that x ist an undeclared
Var (in ClojureScript).

Cheers,
Kevin


P.S.: is there a better place to post bug reports for core.async?

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

butlast with reducers

[Jozef Wagner]

Is it possible to implement efficient butlast (and drop-last, take-last) 
with reducers? The only solution I can think of needs additional reduce to 
compute count, which may often be undesirable. 

Or is it OK to say that reducers are not designed for such cases?

JW

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

Re: IDE feature

[Phillip Lord]

Tassilo Horn  writes:
>> Writing great code would be a much better use of our time than calling
>> other people insane.
>
> I've never called anybody insane.  I just wanted to transport that
> paredit and other tools need some time to get used to, but then the
> investment might be worth it.


I didn't discover paredit till I started clojure, having spent many
years writing emacs-lisp. For me, it was like learning to touch type
many years ago; hard at first, but paid benefits within a week.

I think part of the problem is that the commands that I used most
frequently are classifed under "Barfage and Slurpage" -- names that are
so ridiculous that it took me a week to find out what they do.

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

Re: IDE feature

[Meikel Brandmeyer (kotarak)]

Hi,

Am Donnerstag, 8. August 2013 10:45:34 UTC+2 schrieb Tassilo Horn:
>
>
> I've never called anybody insane.  I just wanted to transport that 
> paredit and other tools need some time to get used to, but then the 
> investment might be worth it. 
>
>
I meant the overall discussion. Not you in person. From somewhere down the 
thread:

Structural editing, like paredit, is really the only sane way to do Clojure 
code.
 
So not using it is insane. I don't agree together with Lee and Mark. YMMV.

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

Re: IDE feature

[Tassilo Horn]

"Meikel Brandmeyer (kotarak)"  writes:

>> now I don't know how people can edit Lisp without it. 
>>
> Quite simple: You type an (, you type some more code, you type ). Easy
> as that.

Writing is easy.  IMO, paredit (or structural editing in general) shines
when refactoring code.

> Can we stop this arrogant "smug paredit weenie" discussion now?

Yes.

> Writing great code would be a much better use of our time than calling
> other people insane.

I've never called anybody insane.  I just wanted to transport that
paredit and other tools need some time to get used to, but then the
investment might be worth it.

Bye,
Tassilo

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

Re: IDE feature

[Meikel Brandmeyer (kotarak)]

Hi,

Am Donnerstag, 8. August 2013 10:05:28 UTC+2 schrieb Tassilo Horn:
>
> now I don't know how people can edit Lisp without it. 
>
>
Quite simple: You type an (, you type some more code, you type ). Easy as 
that.

Can we stop this arrogant "smug paredit weenie" discussion now? Writing 
great code would be a much better use of our time than calling other people 
insane.

Meikel
(who kept hundreds of vim users happy around the globe for more than four 
years with VimClojure (ranked 2nd after emacs in Chas' surveys) - without 
using paredit)

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

Re: IDE feature

[Tassilo Horn]

Mark Engelberg  writes:

> I've tried paredit several times and dislike it.  I found that while
> editing the code, I spent a lot of mental energy trying to figure out
> how to edit the code within the constraints of the
> structure-preserving transformation key combos, which took away from
> my ability to concentrate on the problem at hand.

That statement is also true for people new to emacs or even more vi.
But after the key bindings mave made it into your muscle memory, there
are probably no other editors that can be used that effectively for text
editing as those two.  When I started using paredit, I also found it
awkward at first, but I kept on using it, and now I don't know how
people can edit Lisp without it.

Bye,
Tassilo

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

Re: IDE feature

[Mark Engelberg]

I've tried paredit several times and dislike it.  I found that while
editing the code, I spent a lot of mental energy trying to figure out how
to edit the code within the constraints of the structure-preserving
transformation key combos, which took away from my ability to concentrate
on the problem at hand.  I know plenty of others who feel the same way.  So
maybe the paredit folks are just a "vocal minority".  Do you have any
evidence for your claim that paredit is preferred by the vast majority of
people who have tried it?

On Thu, Aug 8, 2013 at 12:20 AM, Steven Degutis  wrote:

> The vast majority of people who have tried paredit prefer using it, your
> reaction is very rare. So this is as far from "YMMV" as you can get.
>
>

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

Re: IDE feature

[Robert Stuttaford]

Lee has a valid point. Lee's point is: let me decide. Put paredit in, but 
let me turn it off if I want. 

I agree that paredit is the only sane way for me and for anyone who doesn't 
have Lee's muscle memory to overcome. But for Lee, paredit is 'doing it 
wrong', because he doesn't enjoy it and he's unproductive that way. And 
that trumps any particular language, tool, paradigm, what-have-you.

I mean, there are some people who are perfectly productive and happy in 
C++. If that's possible, then anything is :-)

On Thursday, August 8, 2013 4:58:32 AM UTC+2, Lee wrote:
>
>
> On Aug 7, 2013, at 2:06 PM, Norman Richards wrote: 
> > Structural editing, like paredit, is really the only sane way to do 
> Clojure code.  I honestly thing anyone who manually balances parenthesis or 
> edits Clojure functions in a way that doesn't preserve the structural 
> integrity of your expressions is just doing it wrong.  (not just doing it 
> poorly - but doing it wrong) 
>
> What a spectacularly annoying thing to say. 
>
> I've been coding in Lisp for close to 30 years and teaching Lisp off and 
> on for about 20. I have used paredit many times over these decades but I 
> dislike it intensely, both for my own coding and for my teaching. I have my 
> reasons for this, which I could explain, but I have no interest in 
> discouraging you or anyone else who finds it useful from using it. But I 
> don't want to use it, and I don't see where you get off saying that I'm 
> "doing it wrong" on account of this. 
>
> > So, of course, my advice to the original poster is to just jump in and 
> learn paredit.  It will probably seem awkward at first, but if you invest 
> the effort (and it honestly doesn't take that much) to learn a better way 
> to edit expressions, you'll be so much better off. 
>
> Your mileage may vary! 
>
> > In fact, I've sold several people on Clojure just by showing them how 
> paredit makes it significantly easier to lisp-style expressions than to 
> edit C-style languages with their irregular syntax.  I would jumped on lisp 
> years ago if I had realized how easy it was to edit instead of remembering 
> those painful university lisp assignments where I spent all my time 
> balancing parenthesis and being afraid to make simple structural changes 
> for fear of getting my code all messed up. 
>
> In my own experience bracket-matching and auto-reindentation are indeed 
> essential, and they make balancing parentheses and seeing the structure of 
> the code almost effortless. I would personally have a hard time coding in 
> any environment without these tools. But Paredit takes things further by 
> interfering with the typing/cutting/pasting/sketching/brainstorming 
> skills/habits that I've developed over my whole life and which I use in 
> every other text-based application and environment, preventing me from 
> treating programs as text -- which is how I sometimes really want to think 
> of them, especially when I'm playing with ideas and sketching out code 
> roughly. 
>
> Your mileage may vary! But that doesn't mean that either of us is doing it 
> wrong. 
>
>  -Lee 
>
>
> -- 
> Lee Spector, Professor of Computer Science 
> Cognitive Science, Hampshire College 
> 893 West Street, Amherst, MA 01002-3359 
> lspe...@hampshire.edu , http://hampshire.edu/lspector/ 
> Phone: 413-559-5352, Fax: 413-559-5438 
>
>

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

Re: IDE feature

[Steven Degutis]

The vast majority of people who have tried paredit prefer using it, your
reaction is very rare. So this is as far from "YMMV" as you can get.


On Wed, Aug 7, 2013 at 9:58 PM, Lee Spector  wrote:

>
> On Aug 7, 2013, at 2:06 PM, Norman Richards wrote:
> > Structural editing, like paredit, is really the only sane way to do
> Clojure code.  I honestly thing anyone who manually balances parenthesis or
> edits Clojure functions in a way that doesn't preserve the structural
> integrity of your expressions is just doing it wrong.  (not just doing it
> poorly - but doing it wrong)
>
> What a spectacularly annoying thing to say.
>
> I've been coding in Lisp for close to 30 years and teaching Lisp off and
> on for about 20. I have used paredit many times over these decades but I
> dislike it intensely, both for my own coding and for my teaching. I have my
> reasons for this, which I could explain, but I have no interest in
> discouraging you or anyone else who finds it useful from using it. But I
> don't want to use it, and I don't see where you get off saying that I'm
> "doing it wrong" on account of this.
>
> > So, of course, my advice to the original poster is to just jump in and
> learn paredit.  It will probably seem awkward at first, but if you invest
> the effort (and it honestly doesn't take that much) to learn a better way
> to edit expressions, you'll be so much better off.
>
> Your mileage may vary!
>
> > In fact, I've sold several people on Clojure just by showing them how
> paredit makes it significantly easier to lisp-style expressions than to
> edit C-style languages with their irregular syntax.  I would jumped on lisp
> years ago if I had realized how easy it was to edit instead of remembering
> those painful university lisp assignments where I spent all my time
> balancing parenthesis and being afraid to make simple structural changes
> for fear of getting my code all messed up.
>
> In my own experience bracket-matching and auto-reindentation are indeed
> essential, and they make balancing parentheses and seeing the structure of
> the code almost effortless. I would personally have a hard time coding in
> any environment without these tools. But Paredit takes things further by
> interfering with the typing/cutting/pasting/sketching/brainstorming
> skills/habits that I've developed over my whole life and which I use in
> every other text-based application and environment, preventing me from
> treating programs as text -- which is how I sometimes really want to think
> of them, especially when I'm playing with ideas and sketching out code
> roughly.
>
> Your mileage may vary! But that doesn't mean that either of us is doing it
> wrong.
>
>  -Lee
>
>
> --
> Lee Spector, Professor of Computer Science
> Cognitive Science, Hampshire College
> 893 West Street, Amherst, MA 01002-3359
> lspec...@hampshire.edu, http://hampshire.edu/lspector/
> Phone: 413-559-5352, Fax: 413-559-5438
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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