Re: ClojureCLR 1.5.0 RC 1

[Shantanu Kumar]

On Thursday, 27 December 2012 23:15:04 UTC+5:30, dmiller wrote:
>
> ClojureCLR is caught up with all changes to ClojureJVM up to 1.5.0-RC1.
> This includes all relevant bug fixes, the reducers library, reader literal 
> improvements, new threading macros and other goodness.  See changes.md.
>
> The only change not yet implemented is the new reliance on the 
> test.generative library.  That's going to wait until there are some 
> improvements in the build and project management process.  You won't notice 
> the difference.
>
> One change specific to ClojureCLR:  building/running under Mono is now 
> supported.
>


That's fantastic! Is there a binary download link you'd like to share?

Shantanu

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

Re: ClojureCLR errors on Mono Linux

[Shantanu Kumar]

Thanks Robert, will try that shortly.

Shantanu

On Tuesday, 25 December 2012 06:29:58 UTC+5:30, RobertLJ wrote:
>
>
> Shantanu
>
> The best way to get going right now with ClojureCLR is to build it from 
> source.  The following is the process to build ClojureCLR on Linux 
> (Assuming that the mono development environment is installed).  
>
> 1. Download: 
> https://github.com/clojure/clojure-clr/archive/clojure-1.4.1.tar.gz
> 2. Untar clojure-1.4.1.tar.gz
> 3. Download the NuGet.exe commandline installer: 
> http://nuget.codeplex.com/releases . Use the link under Available 
> downloads "NuGet.exe Command Line". 
> 4. set up nuget as per these directions: 
> http://monomvc.wordpress.com/2012/03/06/nuget-on-mono/
>
> 5. From the terminal in the "lib" directory under clojure-1.4.1 use 
> "nuget" to download the dependencies like this:  
>
> A. "nuget install DynamicLanguageRuntime.Net20.Unofficial"
> B. "nuget install DynamicLanguageRuntime.Net40.Unofficial"
> C. "nuget install NUnit"
>
> 6. Copy the assemblies from 
> "lib/DynamicLanguageRuntime.Net20.Unofficial/lib/net20" to "lib/DLR/2.0"
>
> 7. Copy the assemblies from 
> "lib/DynamicLanguageRuntime.Net40.Unofficial/lib/net40" to "lib/DLR/4.0"
>
> 8. In a text editor open the "Clojure.Compile.csproj" file located in 
> "clojure-1.4.1/Clojure/Clojure.Compile".  Under the "" add 
> "mono"  to the sections so it looks like this:
>
> *-Clojure.Compile.csproj 
> Edit---*
>  mono "$(TargetPath)" clojure.core clojure.core.protocols 
> clojure.main clojure.set clojure.zip  clojure.walk clojure.stacktrace 
> clojure.template clojure.test clojure.test.tap clojure.test.junit 
> clojure.pprint clojure.clr.io clojure.repl clojure.clr.shell 
> clojure.string clojure.data clojure.reflect 
>  
> *-Clojure.Compile.csproj 
> Edit---*
>
> *-NUnit 
> Edit--*
> 9. In a text editor open the "Clojure.Tests.csproj" file located in 
> "clojure-1.4.1/Clojure/Clojure.Tests".   Change the "nunit.framework" 
> configuration from:
>
> Original Configuration
>  
>   
> ..\packages\NUnit.2.6.0.12054\lib\nunit.framework.dll
>  
>
> Change Configuration to this 
> 
>   ..\..\lib\NUnit.2.6.2\lib\nunit.framework.dll
> 
> *-NUnit 
> Edit--*
>
> 10. Finaly from the directory "clojure-clr-clojure-1.4.1/Clojure" run 
> either:
>
> MONO_IOMAP=all xbuild build.proj /target:Build /p:Configuration="Release 
> 4.0" /p:Platform="Any CPU"
>
> or
> MONO_IOMAP=all xbuild build.proj /target:Build /p:Configuration="Debug 
> 4.0" /p:Platform="Any CPU"
>
> After the build the binaries will be located in 
> "clojure-clr-clojure-1.4.1/bin/4.0\{Release || Debug}"
>
>
> I'm working on streamlining this for for ClojureCLR 1.5.0. Hope this helps.
>
> -Robert
>
>
>
> On Wednesday, December 19, 2012 5:37:10 PM UTC-5, Shantanu Kumar wrote:
>>
>> Here are the steps how to reproduce the issue on 32-bit Ubuntu 12.04:
>>
>> 1. lein new lein-clr foo
>> 2. cd foo
>> 3. # edit project.clj to download the dependencies using :clj-dep
>> 4. lein clr -v compile :all
>>
>  
>
>> 5. lein clr -v test
>>
>> It will show the exact commands being executed. Are the same Clojure 
>> binaries supposed to work on 32-bit systems?
>>
>> Shantanu
>>
>> On Wednesday, 19 December 2012 13:19:55 UTC+5:30, Shantanu Kumar wrote:
>>>
>>> Thanks David, and sorry for the insufficient bug details. I tested this 
>>> on 64-bit Ubuntu where it works fine; however, the problem shows up on 
>>> 32-bit Ubuntu.
>>>
>>> I will post the exact steps in the evening on how to replicate the issue 
>>> on 32-bit Ubuntu.
>>>
>>> Shantanu
>>>
>>> On Wednesday, 19 December 2012 02:00:53 UTC+5:30, dmiller wrote:

 Shantanu,

 I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC.  
 I installed Mono 2.10.8.
 I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0.
 Extracted.
 > mono Clojure.Main.exe  
 Runs with no problem.

 > mono Clojure.Compile.exe test.junk
 Runs with no problem.

 From the errors you report, I can only guess that some pre-1.4 DLLs are 
 being found somehow and loaded.  
 For example,  the field clojure.lang.RT.OutVar did not exist in 
 ClojureCLR 1.3.

 I do not know how else to help.

 -David
  


 On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote:
>
> This is when using ClojureCLR 1.4.0 Debug-4.0 version.
>
> Shantanu
>
> On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:
>>
>> Hi,
>>
>> I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 
>> 12.04 (they do not happen on Windows using either .NET or Mono):
>

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Sukh Singh]

Having read the posts all over again, can I say that *the JVM will remain 
the primary target/platform for Clojure, while Oracle remains good i.e. it 
doesn't get Barmy *? Isn't that unforeseeable?

On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote:
>
>
>  
> Hi, 
>
> I have noticed that this question is randomly appearing in many minds, and 
> it is frequently being asked, though there is no apparent reason on why it 
> is asked :/ or maybe people are unable to pen down the exact reasons, and 
> sad to say, even myself. 
>  
> There are reasons for which I ask this question -> 
>
>- People (Majority) tend to stick with the primary implementations 
>of certain multi-implementation software. And in the case of Clojure, the  
>JVM implementation is the primary implementation now.
>   
>- Having a primary implementation in case of BDFL lead software 
>helps as a glue in the community. For example , CPython is the primary 
>python implementation, even if there is an existance of IronPython or 
>JPython.
>
>- The doubts of many, including me, will be cleared by an abstract 
>answer... That 'many' also include the companies adopting something new, 
> in 
>this particular case, adopting clojure 
>
>  
> *QUESTION*
>  
> Rich Hickey chose JVM as the platform of choice when he invented Clojure. 
> It's 
> community developed set of tools and documentation grew around the JVM 
> (Leiningen, for example). 
>  
> From the above statements, can I say that  
>  
> *the JVM will always likely, remain the primary Clojure implementation* ? 
>
>
> Thank You.
>  
>   
>   
>   
>

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Leon Adler]

That's unforeseeable because, that represents a very long time.

Having said that, this statement deserves a resay...

*The JVM will remain the primary target/platform for Clojure, while Oracle 
remains good i.e. it doesn't get Barmy*.

What say the other people?

On Saturday, December 29, 2012 3:53:12 PM UTC+5:30, Sukh Singh wrote:
>
> Having read the posts all over again, can I say that *the JVM will remain 
> the primary target/platform for Clojure, while Oracle remains good i.e. it 
> doesn't get Barmy *? Isn't that unforeseeable?
>
> On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote:
>>
>>
>>  
>> Hi, 
>>
>> I have noticed that this question is randomly appearing in many minds, 
>> and it is frequently being asked, though there is no apparent reason on why 
>> it is asked :/ or maybe people are unable to pen down the exact reasons, 
>> and sad to say, even myself. 
>>  
>> There are reasons for which I ask this question -> 
>>
>>- People (Majority) tend to stick with the primary 
>>implementations of certain multi-implementation software. And in the case 
>>of Clojure, the  JVM implementation is the primary implementation now.
>>   
>>- Having a primary implementation in case of BDFL lead software 
>>helps as a glue in the community. For example , CPython is the primary 
>>python implementation, even if there is an existance of IronPython or 
>>JPython.
>>
>>- The doubts of many, including me, will be cleared by an 
>>abstract answer... That 'many' also include the companies adopting 
>>something new, in this particular case, adopting clojure 
>>
>>  
>> *QUESTION*
>>  
>> Rich Hickey chose JVM as the platform of choice when he invented Clojure. 
>> It's 
>> community developed set of tools and documentation grew around the JVM 
>> (Leiningen, for example). 
>>  
>> From the above statements, can I say that  
>>  
>> *the JVM will always likely, remain the primary Clojure implementation*? 
>>
>>
>> Thank You.
>>  
>>   
>>   
>>   
>>
>

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

Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Sean Chalmers]

Greetings all!

I'm just starting out in the so far wonderful world of Clojure and to help 
me get started I had a crack at one of my favourites, the FizzBuzz program. 
For anyone that isn't familiar with FizzBuzz, it is designed to count from 
1 to N and take the following actions when certain conditions are met:

   - When the remainder of i divided by 3 is 0 print "Fizz"
   - When the remainder of i divided by 5 is 0 print "Buzz"
   - When both the former are true of i print "FizzBuzz"

I crafted the following as a solution and I would really appreciate some 
more experienced Clojurians casting their eye over it and letting me know 
if what I've done is in the style and spirit of Clojure. Also this is my 
first functional language so any feedback on that would be awesome too. :)

I'm aware it's only a tnsy piece of code so not terribly indicative 
of the hilarity that might ensue on a larger project but all the same. 
Enough of my blathering here is the meaty bit:

(defn zero-remainder? [x y]
  (zero? (rem x y)))

(defn fizzy [x]
  (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)]
(if (and fizz buzz)
  (println "FizzBuzz: " x)
  (if buzz
(println "Buzz: " x)
(if fizz
  (println "Fizz: " x))

(doseq [x (range 1 25)]
  (fizzy 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

Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Michael Drogalis]

Use a cond rather than nesting ifs. Otherwise looks good.

On Saturday, December 29, 2012 7:35:38 AM UTC-5, Sean Chalmers wrote:
>
> Greetings all!
>
> I'm just starting out in the so far wonderful world of Clojure and to help 
> me get started I had a crack at one of my favourites, the FizzBuzz program. 
> For anyone that isn't familiar with FizzBuzz, it is designed to count from 
> 1 to N and take the following actions when certain conditions are met:
>
>- When the remainder of i divided by 3 is 0 print "Fizz"
>- When the remainder of i divided by 5 is 0 print "Buzz"
>- When both the former are true of i print "FizzBuzz"
>
> I crafted the following as a solution and I would really appreciate some 
> more experienced Clojurians casting their eye over it and letting me know 
> if what I've done is in the style and spirit of Clojure. Also this is my 
> first functional language so any feedback on that would be awesome too. :)
>
> I'm aware it's only a tnsy piece of code so not terribly 
> indicative of the hilarity that might ensue on a larger project but all the 
> same. Enough of my blathering here is the meaty bit:
>
> (defn zero-remainder? [x y]
>   (zero? (rem x y)))
>
> (defn fizzy [x]
>   (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)]
> (if (and fizz buzz)
>   (println "FizzBuzz: " x)
>   (if buzz
> (println "Buzz: " x)
> (if fizz
>   (println "Fizz: " x))
>
> (doseq [x (range 1 25)]
>   (fizzy 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

Clojure mug templates

[Nikita Beloglazov]

Hi

I taught small clojure class at my university this semester. At the end of 
the class I printed "clojure" mugs for my students with their names. 
Here I want to share small javascript/html page I used to generate 
templates for mugs. I hope someone find it useful. 

Page:
http://nbeloglazov.github.com/clojure-mug-template/

GitHub repo:
https://github.com/nbeloglazov/clojure-mug-template/

You can clone repo and open index.html from local copy. 

Thank you,
Nikita Beloglazov

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

Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Nikita Beloglazov]

Hi

I'd change your fizzy function so it returns a string instead of printing 
it. This way it will be pure function and more functional-like. In doseq 
you'll need (printlng (fuzzy x)) instead of 
(fuzzy x).

Nikita Beloglazov
On Saturday, December 29, 2012 3:35:38 PM UTC+3, Sean Chalmers wrote:
>
> Greetings all!
>
> I'm just starting out in the so far wonderful world of Clojure and to help 
> me get started I had a crack at one of my favourites, the FizzBuzz program. 
> For anyone that isn't familiar with FizzBuzz, it is designed to count from 
> 1 to N and take the following actions when certain conditions are met:
>
>- When the remainder of i divided by 3 is 0 print "Fizz"
>- When the remainder of i divided by 5 is 0 print "Buzz"
>- When both the former are true of i print "FizzBuzz"
>
> I crafted the following as a solution and I would really appreciate some 
> more experienced Clojurians casting their eye over it and letting me know 
> if what I've done is in the style and spirit of Clojure. Also this is my 
> first functional language so any feedback on that would be awesome too. :)
>
> I'm aware it's only a tnsy piece of code so not terribly 
> indicative of the hilarity that might ensue on a larger project but all the 
> same. Enough of my blathering here is the meaty bit:
>
> (defn zero-remainder? [x y]
>   (zero? (rem x y)))
>
> (defn fizzy [x]
>   (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)]
> (if (and fizz buzz)
>   (println "FizzBuzz: " x)
>   (if buzz
> (println "Buzz: " x)
> (if fizz
>   (println "Fizz: " x))
>
> (doseq [x (range 1 25)]
>   (fizzy 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

Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Laurent PETIT]

2012/12/29 Nikita Beloglazov 
>
> Hi
>
> I'd change your fizzy function so it returns a string instead of printing it. 
> This way it will be pure function and more functional-like. In doseq you'll 
> need (printlng (fuzzy x)) instead of
> (fuzzy x).
>
> Nikita Beloglazov
>
> On Saturday, December 29, 2012 3:35:38 PM UTC+3, Sean Chalmers wrote:
>>
>> Greetings all!
>>
>> I'm just starting out in the so far wonderful world of Clojure and to help 
>> me get started I had a crack at one of my favourites, the FizzBuzz program. 
>> For anyone that isn't familiar with FizzBuzz, it is designed to count from 1 
>> to N and take the following actions when certain conditions are met:
>>
>> When the remainder of i divided by 3 is 0 print "Fizz"
>> When the remainder of i divided by 5 is 0 print "Buzz"
>> When both the former are true of i print "FizzBuzz"
>>
>> I crafted the following as a solution and I would really appreciate some 
>> more experienced Clojurians casting their eye over it and letting me know if 
>> what I've done is in the style and spirit of Clojure. Also this is my first 
>> functional language so any feedback on that would be awesome too. :)
>>
>> I'm aware it's only a tnsy piece of code so not terribly indicative 
>> of the hilarity that might ensue on a larger project but all the same. 
>> Enough of my blathering here is the meaty bit:
>>
>> (defn zero-remainder? [x y]
>>   (zero? (rem x y)))
>>
>> (defn fizzy [x]
>>   (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)]
>> (if (and fizz buzz)
>>   (println "FizzBuzz: " x)
>>   (if buzz
>> (println "Buzz: " x)
>> (if fizz
>>   (println "Fizz: " x))


What about:

(defn fizz [x]
  (str
(when (zero-reminder? x 3) "Fizz")
(when (zero-reminder? x 5) "Buzz")
":" x))

Cheers,

-- 
Laurent

>>
>>
>> (doseq [x (range 1 25)]
>>   (fizzy 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] Dire, Erlang-style error handling

[Adam Clements]

Hey,

I really like the idea of pulling out exception handling from the function 
bodies. The try catch form has always bugged me a little bit.

One thing that worries me though. While this is fine for examples where you 
simply log the exception and move on, what if you need to do something more 
complicated with the actual data? Say for example you need to queue/trigger 
a retry, you no longer have your local bindings to work with so you'd have 
to go back to a normal try/catch (disclaimer - didn't read the paper, just 
going off the code and your comments)

Couple of thoughts on the code:

If you want to attach the error handlers to a particular function var 
(task), why not alter-meta and add the handler function there rather than 
maintaining a separate atom? Given that the deftask is pretty much 
redundant anyway, I don't really see the point in making the distinction. 
 Plus I think your current code is dropping namespaces, causing potential 
future explosions?

I'd be tempted to make a supervise function which simply takes a handler 
map and do away with the macros altogether, you can still def handlers at 
the top level if you want to re-use them, but you could also merge sets of 
handlers if you wanted, or pass in handlers which have some idea of what 
task you're supervising because they have been declared in the same lexical 
scope, e.g.

(let [currenturl "..."] 
   (supervise {ConnectionError (fn [e] (queue-retry! currenturl))
   NotFoundError   (fn [e] (log "failed:" currenturl 
(.getMessage e))}
  fetch-url currenturl :timeout 10))

or your example would look like:
(defn divider [a b]
   (/ a b))

(def div-zero-handler 
{ArithmeticException (fn [e] (println "Cannot divide by zero"))})

(def npe-handler
{NullPointerException (fn [e] (println "..."))})

(def supervised-divider (partial divider (merge div-zero-handler 
npe-handler)))

(supervised-divider 10 0)...

Which I would argue is a lot more idiomatic and flexible. I think macros 
are overkill and unnecessary complexity here, you just need a supervise 
function which takes responsibility for catching errors and lets you re-use 
handlers

Adam

On Friday, December 28, 2012 7:14:34 PM UTC, Michael Drogalis wrote:
>
> Hey folks,
>
> After watching The Language of the System and being directed to Joe 
> Armstrong's paper on error handling, I concurred that his approach is 
> fantastic. I really wanted the same thing for more rudimentary operations, 
> like file handling. So I wrote Dire 
> https://github.com/MichaelDrogalis/dire
>
> The pros are of this are that error handling code is removed from 
> application logic and it is not order complected.
> The cons are that tasks are not as strongly isolated as they are in 
> Erlang. Also, because it is so simple (16 lines),
> there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
> Ideas?)
>
> Can such a thing be useful in a non-distributed environment? Or does this 
> look like a hassle to use?
>
>
>

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

Re: Clojure mug templates

[Mayank Jain]

So nice :)
Good stuff!

On Sat, Dec 29, 2012 at 7:24 PM, Nikita Beloglazov
 wrote:
> Hi
>
> I taught small clojure class at my university this semester. At the end of
> the class I printed "clojure" mugs for my students with their names.
> Here I want to share small javascript/html page I used to generate templates
> for mugs. I hope someone find it useful.
>
> Page:
> http://nbeloglazov.github.com/clojure-mug-template/
>
> GitHub repo:
> https://github.com/nbeloglazov/clojure-mug-template/
>
> You can clone repo and open index.html from local copy.
>
> Thank you,
> Nikita Beloglazov
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
Regards,
Mayank.

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

Re: reduce-kv incompatible with subvec

[Andy Fingerhut]

I haven't taken the time to check whether that is correct or not, but the 
answer that is most likely the truth is "no one has yet had the time or 
interest to add such a thing yet".

You are welcome to create a ticket describing the problem, and attach a patch 
to it that fixes the issue, and see if it will be accepted as a change to 
Clojure.  To have a patch accepted you will need to sign a Clojure 
Contributor's Agreement first [1], and [2] describes the mechanics of creating 
patches.

[1] http://clojure.org/contributing
[2] http://dev.clojure.org/display/design/JIRA+workflow

Andy

On Dec 28, 2012, at 5:36 PM, Alan Busby wrote:

> 
> Just curious why something like the following wouldn't be part of subvector?
> 
> public Object kvreduce(IFn f, Object init){
> 
> for(int i=0;i<(end - start);i++){
> 
> init = f.invoke(init,i,v.nth(start+i));
> 
> return init;
> 
> }
> 
> 
> 
> On Fri, Dec 28, 2012 at 11:23 PM, Andy Fingerhut  
> wrote:
> I am not saying that one would *have* to give up O(1) subvec in order to 
> support other operations.
> 
> I am guessing, without having done a thorough analysis, that an O(log n) 
> subvec based on RRB Trees would make most/all operations on subvec's just 
> fall out fairly naturally, rather than having to be written as special cases.
> 
> Andy
> 
> On Dec 27, 2012, at 8:54 PM, Alan Busby wrote:
> 
>> I'm confused why we'd need to give up O(1) just to support something like 
>> reduce-kv on subvectors.
>> Isn't the implementation of subvector just a wrapper around the original 
>> vector along with a start and end value?
>> 
>> Current source here;
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java
>> 
>> I apologize if I'm missing something key here.
>> 
>> 
>> On Fri, Dec 28, 2012 at 3:18 AM, Andy Fingerhut  
>> wrote:
>> http://dev.clojure.org/jira/browse/CLJ-1082
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Andy Fingerhut]

If you don't get a flood of responses, I think it is because in this thread and 
the one linked earlier that Leon Adler started, several different people have 
explained evidence that Clojure on the JVM has had active development for five 
years, it is open source, and no one knows of any evidence that this will 
change any time in the future.  That isn't the same as saying "will remain", 
but it is the best anyone can give you that is based on evidence and reason, 
rather than some other dubious methods.

If you believe another language will give you better assurances than that about 
its future target/platform, I don't see how you came to that conclusion, unless 
it is by making up conclusions out of thin air.

Andy

On Dec 29, 2012, at 2:58 AM, Leon Adler wrote:

> That's unforeseeable because, that represents a very long time.
> 
> Having said that, this statement deserves a resay...
> 
> The JVM will remain the primary target/platform for Clojure, while Oracle 
> remains good i.e. it doesn't get Barmy.
> 
> What say the other people?
> 
> On Saturday, December 29, 2012 3:53:12 PM UTC+5:30, Sukh Singh wrote:
> Having read the posts all over again, can I say that the JVM will remain the 
> primary target/platform for Clojure, while Oracle remains good i.e. it 
> doesn't get Barmy ? Isn't that unforeseeable?
> 
> On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote:
> 
>  
> Hi, 
> 
> I have noticed that this question is randomly appearing in many minds, and it 
> is frequently being asked, though there is no apparent reason on why it is 
> asked :/ or maybe people are unable to pen down the exact reasons, and sad to 
> say, even myself. 
>  
> There are reasons for which I ask this question -> 
> People (Majority) tend to stick with the primary implementations of 
> certain multi-implementation software. And in the case of Clojure, the  JVM 
> implementation is the primary implementation now.
>   
> Having a primary implementation in case of BDFL lead software helps as a 
> glue in the community. For example , CPython is the primary python 
> implementation, even if there is an existance of IronPython or JPython.
> 
> The doubts of many, including me, will be cleared by an abstract 
> answer... That 'many' also include the companies adopting something new, in 
> this particular case, adopting clojure
>  
> QUESTION
>  
> Rich Hickey chose JVM as the platform of choice when he invented Clojure. 
> It's 
> community developed set of tools and documentation grew around the JVM 
> (Leiningen, for example). 
>  
> From the above statements, can I say that  
>  
> the JVM will always likely, remain the primary Clojure implementation ? 
> 
> 
> Thank You.
>  
>   
>   
>   
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Clojure mug templates

[John Gabriele]

On Saturday, December 29, 2012 8:54:44 AM UTC-5, Nikita Beloglazov wrote:
>
> Hi
>
> I taught small clojure class at my university this semester. At the end of 
> the class I printed "clojure" mugs for my students with their names. 
> Here I want to share small javascript/html page I used to generate 
> templates for mugs. I hope someone find it useful. 
>
> Page:
> http://nbeloglazov.github.com/clojure-mug-template/
>
> GitHub repo:
> https://github.com/nbeloglazov/clojure-mug-template/
>
>
Neat. Though, what is `slice`?

Oh, and I don't see `comp` in there!

Also, maybe replace "noir" with "lib-noir" now.

---John

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

Re: [ANN] Dire, Erlang-style error handling

[Michael Drogalis]

Thanks for the awesome feedback.

On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote:
>
> Hey,
>
> I really like the idea of pulling out exception handling from the function 
> bodies. The try catch form has always bugged me a little bit.
>
> One thing that worries me though. While this is fine for examples where 
> you simply log the exception and move on, what if you need to do something 
> more complicated with the actual data? Say for example you need to 
> queue/trigger a retry, you no longer have your local bindings to work with 
> so you'd have to go back to a normal try/catch (disclaimer - didn't read 
> the paper, just going off the code and your comments)
>

I agree. There's certainly cases where the handler will want to restart the 
task and need access to the original bindings. I'll tinker around with a 
clean way to do this. Open for suggestions. 

>
> Couple of thoughts on the code:
>
> If you want to attach the error handlers to a particular function var 
> (task), why not alter-meta and add the handler function there rather than 
> maintaining a separate atom? Given that the deftask is pretty much 
> redundant anyway, I don't really see the point in making the distinction. 
>  Plus I think your current code is dropping namespaces, causing potential 
> future explosions?
>

Correct, deftask is redundant. I wanted more language to be able to talk 
about what a task is though. This might not be necessary due to what you 
said below this. Also, can you give an example of dropping namespaces?  I 
don't think I see where this happens, but I'm sure it's present. 

>
> I'd be tempted to make a supervise function which simply takes a handler 
> map and do away with the macros altogether, you can still def handlers at 
> the top level if you want to re-use them, but you could also merge sets of 
> handlers if you wanted, or pass in handlers which have some idea of what 
> task you're supervising because they have been declared in the same lexical 
> scope, e.g.
>
> (let [currenturl "..."] 
>(supervise {ConnectionError (fn [e] (queue-retry! currenturl))
>NotFoundError   (fn [e] (log "failed:" currenturl 
> (.getMessage e))}
>   fetch-url currenturl :timeout 10))
>
> or your example would look like:
> (defn divider [a b]
>(/ a b))
>
> (def div-zero-handler 
> {ArithmeticException (fn [e] (println "Cannot divide by zero"))})
>
> (def npe-handler
> {NullPointerException (fn [e] (println "..."))})
>
> (def supervised-divider (partial divider (merge div-zero-handler 
> npe-handler)))
>
> (supervised-divider 10 0)...
>
> Which I would argue is a lot more idiomatic and flexible. I think macros 
> are overkill and unnecessary complexity here, you just need a supervise 
> function which takes responsibility for catching errors and lets you re-use 
> handlers
>
> Adam
>

Joe's paper (for reference 
http://www.erlang.org/download/armstrong_thesis_2003.pdf), in section 4.3.2 
on page 106 states that the goals are:

1. *Clean separation of issues*.
Dire achieves this by total separation of worker logic and supervisor 
logic. (IE "let it crash")

2. *Special processes only for error handling*.
Dire does not have this. Erlang processes aren't OS processes, but they are 
strongly isolated. These handlers that we set up in Dire have to be more 
resilient. I'm not sure how to do this at the moment.

3. *Workers can be run on different physical machines*.
Dire does not have this. Drawing on more knowledge from the Language of the 
System, what if we put queues between supervisors and workers? Is this 
worth it? I'm curious if you guys think it's a good idea for this 
environment.

4. *Error processing code becomes generic*.
To some degree Dire has this. The functions bound to defhandler can be 
reused.

I'm not comfortable with axing defhandler because I wanted this to feel 
like multimethods. I think it's a good idea for users of the supervise 
function to call their worker/task function and away it goes. If a new 
handler is defined, the map passed to supervise has to be modified, which 
violates the Open/Closed principle. That said, if you fork it and give your 
approach a try, I'm sure we can further this idea in some respective.

>
> On Friday, December 28, 2012 7:14:34 PM UTC, Michael Drogalis wrote:
>>
>> Hey folks,
>>
>> After watching The Language of the System and being directed to Joe 
>> Armstrong's paper on error handling, I concurred that his approach is 
>> fantastic. I really wanted the same thing for more rudimentary operations, 
>> like file handling. So I wrote Dire 
>> https://github.com/MichaelDrogalis/dire
>>
>> The pros are of this are that error handling code is removed from 
>> application logic and it is not order complected.
>> The cons are that tasks are not as strongly isolated as they are in 
>> Erlang. Also, because it is so simple (16 lines),
>> there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
>> Ideas

Re: [ANN] Dire, Erlang-style error handling

[Ben Wolfson]

On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis  wrote:
> On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote:
>> One thing that worries me though. While this is fine for examples where
>> you simply log the exception and move on, what if you need to do something
>> more complicated with the actual data? Say for example you need to
>> queue/trigger a retry, you no longer have your local bindings to work with
>> so you'd have to go back to a normal try/catch (disclaimer - didn't read the
>> paper, just going off the code and your comments)
>
>
> I agree. There's certainly cases where the handler will want to restart the
> task and need access to the original bindings. I'll tinker around with a
> clean way to do this. Open for suggestions.

Isn't this what Common Lisp's condition system allowed? (And wasn't
there a condition-like library for Clojure?)

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

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

Re: ClojureCLR 1.5.0 RC 1

[dmiller]

The executables and DLLs under the regular binary download will work just 
fine under Mono.  

On Saturday, December 29, 2012 2:06:31 AM UTC-6, Shantanu Kumar wrote:
>
>
>
> On Thursday, 27 December 2012 23:15:04 UTC+5:30, dmiller wrote:
>>
>> ClojureCLR is caught up with all changes to ClojureJVM up to 1.5.0-RC1.
>> This includes all relevant bug fixes, the reducers library, reader 
>> literal improvements, new threading macros and other goodness.  See 
>> changes.md.
>>
>> The only change not yet implemented is the new reliance on the 
>> test.generative library.  That's going to wait until there are some 
>> improvements in the build and project management process.  You won't notice 
>> the difference.
>>
>> One change specific to ClojureCLR:  building/running under Mono is now 
>> supported.
>>
>
>
> That's fantastic! Is there a binary download link you'd like to share?
>
> Shantanu
>

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

Re: Clojure mug templates

[Shantanu Kumar]

This is pretty cool, and a good idea for building screensaver on that
theme.

Shantanu

On Dec 29, 6:54 pm, Nikita Beloglazov  wrote:
> Hi
>
> I taught small clojure class at my university this semester. At the end of
> the class I printed "clojure" mugs for my students with their names.
> Here I want to share small javascript/html page I used to generate
> templates for mugs. I hope someone find it useful.
>
> Page:http://nbeloglazov.github.com/clojure-mug-template/
>
> GitHub repo:https://github.com/nbeloglazov/clojure-mug-template/
>
> You can clone repo and open index.html from local copy.
>
> Thank you,
> Nikita Beloglazov

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

Re: [ANN] Dire, Erlang-style error handling

[Michael Drogalis]

I've never seen that before, Ben. Can you link me?

Just pushed version 0.1.1 with these suggestions:

- Tasks are now simple functions, not macros
- Using metadata to keep track of handlers rather than an atom.
- Fixed namespace collision issue
- Pass original arguments of task function to error handler

Any way we can make this better?

On Saturday, December 29, 2012 1:22:30 PM UTC-5, Ben wrote:
>
> On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis 
> > 
> wrote: 
> > On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote: 
> >> One thing that worries me though. While this is fine for examples where 
> >> you simply log the exception and move on, what if you need to do 
> something 
> >> more complicated with the actual data? Say for example you need to 
> >> queue/trigger a retry, you no longer have your local bindings to work 
> with 
> >> so you'd have to go back to a normal try/catch (disclaimer - didn't 
> read the 
> >> paper, just going off the code and your comments) 
> > 
> > 
> > I agree. There's certainly cases where the handler will want to restart 
> the 
> > task and need access to the original bindings. I'll tinker around with a 
> > clean way to do this. Open for suggestions. 
>
> Isn't this what Common Lisp's condition system allowed? (And wasn't 
> there a condition-like library for Clojure?) 
>
> -- 
> Ben Wolfson 
> "Human kind has used its intelligence to vary the flavour of drinks, 
> which may be sweet, aromatic, fermented or spirit-based. ... Family 
> and social life also offer numerous other occasions to consume drinks 
> for pleasure." [Larousse, "Drink" entry] 
>

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

Re: [ANN] Dire, Erlang-style error handling

[Ben Wolfson]

On Sat, Dec 29, 2012 at 12:44 PM, Michael Drogalis  wrote:
> I've never seen that before, Ben. Can you link me?

Overview of CL conditions/restarts here:
http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

The Clojure lib was clojure.contrib.error-kit
(http://richhickey.github.com/clojure-contrib/error-kit-api.html),
which has been superseded by slingshot---but I think that slingshot
does not aim to provide conditions and restarts.

> Just pushed version 0.1.1 with these suggestions:
>
> - Tasks are now simple functions, not macros
> - Using metadata to keep track of handlers rather than an atom.
> - Fixed namespace collision issue
> - Pass original arguments of task function to error handler
>
> Any way we can make this better?
>
> On Saturday, December 29, 2012 1:22:30 PM UTC-5, Ben wrote:
>>
>> On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis 
>> wrote:
>> > On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote:
>> >> One thing that worries me though. While this is fine for examples where
>> >> you simply log the exception and move on, what if you need to do
>> >> something
>> >> more complicated with the actual data? Say for example you need to
>> >> queue/trigger a retry, you no longer have your local bindings to work
>> >> with
>> >> so you'd have to go back to a normal try/catch (disclaimer - didn't
>> >> read the
>> >> paper, just going off the code and your comments)
>> >
>> >
>> > I agree. There's certainly cases where the handler will want to restart
>> > the
>> > task and need access to the original bindings. I'll tinker around with a
>> > clean way to do this. Open for suggestions.
>>
>> Isn't this what Common Lisp's condition system allowed? (And wasn't
>> there a condition-like library for Clojure?)
>>
>> --
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks,
>> which may be sweet, aromatic, fermented or spirit-based. ... Family
>> and social life also offer numerous other occasions to consume drinks
>> for pleasure." [Larousse, "Drink" entry]
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

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

Re: Clojure mug templates

[Nikita Beloglazov]

Thank you, John. I've fixed this.

Nikita

On Sat, Dec 29, 2012 at 8:21 PM, John Gabriele  wrote:

> On Saturday, December 29, 2012 8:54:44 AM UTC-5, Nikita Beloglazov wrote:
>>
>> Hi
>>
>> I taught small clojure class at my university this semester. At the end
>> of the class I printed "clojure" mugs for my students with their names.
>> Here I want to share small javascript/html page I used to generate
>> templates for mugs. I hope someone find it useful.
>>
>> Page:
>> http://nbeloglazov.github.com/**clojure-mug-template/
>>
>> GitHub repo:
>> https://github.com/**nbeloglazov/clojure-mug-**template/
>>
>>
> Neat. Though, what is `slice`?
>
> Oh, and I don't see `comp` in there!
>
> Also, maybe replace "noir" with "lib-noir" now.
>
> ---John
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: [ANN] Dire, Erlang-style error handling

[Michael Drogalis]

The CL article is really interesting, thanks. What do you think of the idea 
of using Slingshot's try+ within Dire?

On Saturday, December 29, 2012 3:55:13 PM UTC-5, Ben wrote:
>
> On Sat, Dec 29, 2012 at 12:44 PM, Michael Drogalis 
> > 
> wrote: 
> > I've never seen that before, Ben. Can you link me? 
>
> Overview of CL conditions/restarts here: 
>
> http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
>  
>
> The Clojure lib was clojure.contrib.error-kit 
> (http://richhickey.github.com/clojure-contrib/error-kit-api.html), 
> which has been superseded by slingshot---but I think that slingshot 
> does not aim to provide conditions and restarts. 
>
> > Just pushed version 0.1.1 with these suggestions: 
> > 
> > - Tasks are now simple functions, not macros 
> > - Using metadata to keep track of handlers rather than an atom. 
> > - Fixed namespace collision issue 
> > - Pass original arguments of task function to error handler 
> > 
> > Any way we can make this better? 
> > 
> > On Saturday, December 29, 2012 1:22:30 PM UTC-5, Ben wrote: 
> >> 
> >> On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis  
>
> >> wrote: 
> >> > On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote: 
> >> >> One thing that worries me though. While this is fine for examples 
> where 
> >> >> you simply log the exception and move on, what if you need to do 
> >> >> something 
> >> >> more complicated with the actual data? Say for example you need to 
> >> >> queue/trigger a retry, you no longer have your local bindings to 
> work 
> >> >> with 
> >> >> so you'd have to go back to a normal try/catch (disclaimer - didn't 
> >> >> read the 
> >> >> paper, just going off the code and your comments) 
> >> > 
> >> > 
> >> > I agree. There's certainly cases where the handler will want to 
> restart 
> >> > the 
> >> > task and need access to the original bindings. I'll tinker around 
> with a 
> >> > clean way to do this. Open for suggestions. 
> >> 
> >> Isn't this what Common Lisp's condition system allowed? (And wasn't 
> >> there a condition-like library for Clojure?) 
> >> 
> >> -- 
> >> Ben Wolfson 
> >> "Human kind has used its intelligence to vary the flavour of drinks, 
> >> which may be sweet, aromatic, fermented or spirit-based. ... Family 
> >> and social life also offer numerous other occasions to consume drinks 
> >> for pleasure." [Larousse, "Drink" entry] 
> > 
> > -- 
> > 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 
>
>
>
> -- 
> Ben Wolfson 
> "Human kind has used its intelligence to vary the flavour of drinks, 
> which may be sweet, aromatic, fermented or spirit-based. ... Family 
> and social life also offer numerous other occasions to consume drinks 
> for pleasure." [Larousse, "Drink" entry] 
>

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

Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Sean Chalmers]

Yay! Thanks for the feedback everyone. I originally had it as a 'cond' but 
because I was using 'println' directly in my fizzy function I was getting 
on 15 for example "fizzbuzz, buzz, fizz" but changing it to more pure 
function would probably deal with that. I'll have a play with 'when' as 
well, hadn't tried that one yet. 

Thanks again and I look forward to showing off some Clojure creations in 
the wild soon.

On Saturday, 29 December 2012 22:35:38 UTC+10, Sean Chalmers wrote:
>
> Greetings all!
>
> I'm just starting out in the so far wonderful world of Clojure and to help 
> me get started I had a crack at one of my favourites, the FizzBuzz program. 
> For anyone that isn't familiar with FizzBuzz, it is designed to count from 
> 1 to N and take the following actions when certain conditions are met:
>
>- When the remainder of i divided by 3 is 0 print "Fizz"
>- When the remainder of i divided by 5 is 0 print "Buzz"
>- When both the former are true of i print "FizzBuzz"
>
> I crafted the following as a solution and I would really appreciate some 
> more experienced Clojurians casting their eye over it and letting me know 
> if what I've done is in the style and spirit of Clojure. Also this is my 
> first functional language so any feedback on that would be awesome too. :)
>
> I'm aware it's only a tnsy piece of code so not terribly 
> indicative of the hilarity that might ensue on a larger project but all the 
> same. Enough of my blathering here is the meaty bit:
>
> (defn zero-remainder? [x y]
>   (zero? (rem x y)))
>
> (defn fizzy [x]
>   (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)]
> (if (and fizz buzz)
>   (println "FizzBuzz: " x)
>   (if buzz
> (println "Buzz: " x)
> (if fizz
>   (println "Fizz: " x))
>
> (doseq [x (range 1 25)]
>   (fizzy 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

Advice on Clojure, Emacs, Lein setup on Fedora

[Sayth Renshaw]

Hi I am running F18 and wanting to setup and get goin in Clojure

Just wanted to put a summary of the things I have got so far in case I have 
missed something easy obvious that will get me going quicker.

*Fedora*
To setup on Fedora I have installed these packages(emacs already installed)
clojure-contrib.noarch clojure.noarch leiningen.noarch

*Emacs(using ELPA and Marmalade)*
Install
clojure-mode
slime
slime-repl
swank-clojure
M-x slime # to start and install dependencies.

*Lenigen -lein*
Installed via package manager, how do I use with Emacs?

*General Question*
*
*
1. Is there anything I should use in .emacs for syntax highlighting and 
clojure project support?

2. Is there a code linter/tidy for clojure and/or emacs?

*Resources*
Some resources I have found.

Leningen - https://github.com/technomancy/leiningen/blob/master/README.md
Volkman Tutorial - 
http://java.ociweb.com/mark/clojure/article.html#GettingStarted
Tutorial - 
http://pramode.net/clojure/2010/04/29/getting-started-with-clojure/
Fedora Clojure Project docs - http://fedoraproject.org/wiki/Features/Clojure
Full DisClojure - http://vimeo.com/channels/fulldisclojure
Clojure Docs - http://clojure.org/documentation
Codeschool Clojure - 
http://www.codeschool.com/code_tv/getting-started-with-clojure-part-1
Learn Clojure - http://learn-clojure.com/clojure_tutorials.html
Clojure Links (2009) - 
http://mattsears.com/articles/2009/06/06/20-clojure-links-to-get-you-up-to-speed

Is there anything I am missing or could do better to make sure I get 
running the quickest?

Thanks

Sayth
*
*

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

[ANN] Hosted findfn

[Anthony Rosequist]

I love Anthony Grimes's (et al) findfn  
library, 
but it requires some local setup (mainly the JVM security config for 
clojail), so I decided to host it on Heroku.

Features:

   - Access to findfn from any computer with no setup.
   - If your function has two arguments, tries the original and reversed 
   orderings (searching for [1 2 3] "," => "1, 2, 3" returns join, even though 
   the args are backwards).
   - For each function, includes the docstring, namespace, the version it 
   was added, and whether or not it has been deprecated.
   - Links each function to clojuredocs.org

Limitations/Issues:

   - Non-existent error handling (it just gets stuck on the "searching" 
   screen forever if any problem happens); this definitely needs to be fixed 
   soon.
   - It's slow.
   - Only searches different orderings if you have exactly two args. I 
   originally had it searching up to 5 permutations of your args, but it was 
   exceeding Heroku's 30-second timeout.
   - Doesn't support find-arg.
   - Only searches clojure.core, clojure.string, and clojure.set.
   - Not on github yet.

Let me know if you run into any issues or have any cool ideas for this.

(I emailed Anthony to make sure he was fine with me using the findfn name 
and that the attribution was good enough)

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

Clarification on setting up Clojure, Lein and Emacs on fedora

[Sayth Renshaw]

Just want to make sure I get this right. I am running F18 and am setting up 
clojure.

These would be the packages to install, correct?

clojure.noarch
clojure-contrib.noarch
leiningen.noarch 
emacs-slime.noarch

*For slime and the emacs repl*
clojure-mode, slime, slime-repl and swank-clojure 
restart M-X to install the clojure REPL.

*For lein - *better then maven, yes?
Just install the package and then use on command line. But how in Emacs?

*Emacs*
Is there anything I should be putting in my .emacs to get project and 
syntax support and the ability to send select text to a REPL?

*General Question*
Is there a code linter beautifier?

*Resources*
Lenigen - https://github.com/technomancy/leiningen/blob/master/README.md
Tutorial - http://www.learningclojure.com/
Volkmann - http://java.ociweb.com/mark/clojure/article.html#GettingStarted
Tutorial - 
http://pramode.net/clojure/2010/04/29/getting-started-with-clojure/
Fedora Clojure Docs - http://fedoraproject.org/wiki/Features/Clojure


Anything advice on the above or something obvious I have missed that will 
get me going quicker?

Thank You

Sayth








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

cljs-clj interop

[Stuart Campbell]

Hi all,

I'm toying with a way to use Clojure objects from a Rhino-based
ClojureScript environment (https://github.com/harto/rhino-bridge).

I've been able to export a Clojure function into the ClojureScript
environment without too much difficulty. Ideally, I'd like to be able to
call that function as if it were a regular ClojureScript function.

I was hoping I could do something like:

(extend-type js/Packages.clojure.lang.IFn
  IFn
  (-invoke [this] (.invoke this))
  (-invoke [this a] (.invoke this a))
  ;; etc
  )

However, this yields an error that I don't quite understand:

java.lang.UnsupportedOperationException: nth not supported on this type:
Symbol
at clojure.lang.RT.nthFrom(RT.java:846)
at clojure.lang.RT.nth(RT.java:796)
at
cljs.core$extend_type$assign_impls__7365$fn__7377$adapt_params__7380.invoke(core.clj:486)
at clojure.core$map$fn__4087.invoke(core.clj:2434)

In fact, I'm not sure this will work at all, since (type) doesn't appear to
work with non-native JS objects.

Is the extend-type method feasible?

Cheers,
Stuart

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

Re: cljs-clj interop

[David Nolen]

I think you've just formatted your code incorrectly. Did you try something
like this?

(extend-type js/Packages.clojure.lang.IFn
  IFn
  (-invoke
([this] (.invoke this))
([this a] (.invoke this a)))
  )


On Sat, Dec 29, 2012 at 8:22 PM, Stuart Campbell  wrote:

> Hi all,
>
> I'm toying with a way to use Clojure objects from a Rhino-based
> ClojureScript environment (https://github.com/harto/rhino-bridge).
>
> I've been able to export a Clojure function into the ClojureScript
> environment without too much difficulty. Ideally, I'd like to be able to
> call that function as if it were a regular ClojureScript function.
>
> I was hoping I could do something like:
>
> (extend-type js/Packages.clojure.lang.IFn
>   IFn
>   (-invoke [this] (.invoke this))
>   (-invoke [this a] (.invoke this a))
>   ;; etc
>   )
>
> However, this yields an error that I don't quite understand:
>
> java.lang.UnsupportedOperationException: nth not supported on this type:
> Symbol
> at clojure.lang.RT.nthFrom(RT.java:846)
> at clojure.lang.RT.nth(RT.java:796)
> at
> cljs.core$extend_type$assign_impls__7365$fn__7377$adapt_params__7380.invoke(core.clj:486)
> at clojure.core$map$fn__4087.invoke(core.clj:2434)
>
> In fact, I'm not sure this will work at all, since (type) doesn't appear
> to work with non-native JS objects.
>
> Is the extend-type method feasible?
>
> Cheers,
> Stuart
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Clarification on setting up Clojure, Lein and Emacs on fedora

[Moritz Ulrich]

If you have a recent (24) Emacs, use M-x package-install and install
clojure-mode and nrepl. nrepl is the successor-in-spirit of slime, as
many people consider slime as deprecated. When you have access to
leiningen 2 (strongly recommended), the whole setup simplifies to:

1) Install leiningen 2 & Emacs 24
2) In Emacs: Add Marmelade repository
3) In Emacs: M-x package-install RET nrepl RET
4) nrepl-jack-in

On Sun, Dec 30, 2012 at 12:47 AM, Sayth Renshaw  wrote:
> Just want to make sure I get this right. I am running F18 and am setting up
> clojure.
>
> These would be the packages to install, correct?
>
> clojure.noarch
> clojure-contrib.noarch
> leiningen.noarch
> emacs-slime.noarch
>
> For slime and the emacs repl
> clojure-mode, slime, slime-repl and swank-clojure
> restart M-X to install the clojure REPL.
>
> For lein - better then maven, yes?
> Just install the package and then use on command line. But how in Emacs?
>
> Emacs
> Is there anything I should be putting in my .emacs to get project and syntax
> support and the ability to send select text to a REPL?
>
> General Question
> Is there a code linter beautifier?
>
> Resources
> Lenigen - https://github.com/technomancy/leiningen/blob/master/README.md
> Tutorial - http://www.learningclojure.com/
> Volkmann - http://java.ociweb.com/mark/clojure/article.html#GettingStarted
> Tutorial -
> http://pramode.net/clojure/2010/04/29/getting-started-with-clojure/
> Fedora Clojure Docs - http://fedoraproject.org/wiki/Features/Clojure
>
>
> Anything advice on the above or something obvious I have missed that will
> get me going quicker?
>
> Thank You
>
> Sayth
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Trouble calling Dojo grid constructor from ClojureScript

[Patrick Logan]

>From what I can tell, dojo is testing an argument to see whether it has a 
method named "call". dojo seems to be assuming that if such a method 
exists, then the argument will not be a string.

Then clojurescript seems to be assigning a function named "call" to the 
String prototype. And so these two libraries conflict. 

I am unsure whether either library is completely to blame. However it seems 
fairly clear that dojo does not intend to invoke "call" on a string.

Changing dojo/on.js, line 83, to 

if(type.call && (!type instanceof String)){

does fix the problem. I'll check with the dojo folks on making a change 
along these lines unless someone can suggest a change to clojurescript.

-Patrick


On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>
> ok. I've had some time to look into this now and have figured out a few 
> things.
>
> 1. This is not due to calling the DGrid constructor from clojurescript. It 
> occurs even when I call the DGrid constructor from straight javascript 
> code. So it doesn't have to do with the clojurescript code calling the 
> constructor.
>
> 2. The error goes away if I don't require cljs.core. If cljs.core is 
> required then the grid constructor ends up calling back into some code in 
> cljs.core, which is where the error occurs. 
>
> So I'm a little further down the road but still don't know exactly why 
> doing a goog.require("cljs.core") causes cljs.core to receive events from 
> the DGrid constructor. Digging in with my javascript debugger and will 
> update this as I find out more information.
>
>
>
> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
>>
>> Hi, 
>>
>> I'm brand new to ClojureScript and have been trying to get myself 
>> familiarized with it's javascript interop capabilities by implementing 
>> the Dojo toolkit tutorials. I've successfully implemented several of 
>> the tutorials, but now I've run into something that I can't figure out 
>> and am looking for someone to point me in the right direction. 
>>
>> I am calling the DGrid(Dojo grid) constructor using the function 
>> maingrid 
>>
>> (ns couchadmin.core 
>>   (:use [jayq.util :only [clj->js]]) 
>>   (:require [clojure.browser.repl :as repl])) 
>>
>> (defn greet [dom fx] 
>>   (let [element (.byId dom "greetingcljs")] 
>> (set! (. element -innerHTML) "Hello from Dojo using 
>> ClojureScript") 
>> (.play (.slideTo fx (clj->js {:top 200 :left 200 :node 
>> element}) 
>>
>> (defn maingrid [dom grd] 
>>   (do 
>>
>> (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid") 
>> (js/alert "hello world"))) 
>>
>> (defn ^:export main [] 
>>   (comment (repl/connect "http://localhost:9000/repl";)) 
>>   (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!") 
>> greet)) 
>>   (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!") 
>> maingrid)) 
>>
>>
>> When the page is loaded the grid is constructed, but afterwards I see 
>> the following javascript exception 
>>
>> Uncaught Error: No protocol method ILookup.-lookup defined for 
>> type object: [object HTMLDivElement] 
>>
>> I'm wondering what this message is indicating. Did I call the 
>> constructor incorrectly? Is this an incompatibility with Dojo? Do I 
>> need to implement ILookup somehow? Any help would be greatly 
>> appreciated. 
>>
>> Brian 
>>
>

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

Re: Trouble calling Dojo grid constructor from ClojureScript

[David Nolen]

Yes this is known problem w/ ClojureScript that could be solved if/when we
get proper Keywords/Symbol types.

David


On Sat, Dec 29, 2012 at 8:46 PM, Patrick Logan wrote:

> From what I can tell, dojo is testing an argument to see whether it has a
> method named "call". dojo seems to be assuming that if such a method
> exists, then the argument will not be a string.
>
> Then clojurescript seems to be assigning a function named "call" to the
> String prototype. And so these two libraries conflict.
>
> I am unsure whether either library is completely to blame. However it
> seems fairly clear that dojo does not intend to invoke "call" on a string.
>
> Changing dojo/on.js, line 83, to
>
> if(type.call && (!type instanceof String)){
>
> does fix the problem. I'll check with the dojo folks on making a change
> along these lines unless someone can suggest a change to clojurescript.
>
> -Patrick
>
>
> On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>>
>> ok. I've had some time to look into this now and have figured out a few
>> things.
>>
>> 1. This is not due to calling the DGrid constructor from clojurescript.
>> It occurs even when I call the DGrid constructor from straight javascript
>> code. So it doesn't have to do with the clojurescript code calling the
>> constructor.
>>
>> 2. The error goes away if I don't require cljs.core. If cljs.core is
>> required then the grid constructor ends up calling back into some code in
>> cljs.core, which is where the error occurs.
>>
>> So I'm a little further down the road but still don't know exactly why
>> doing a goog.require("cljs.core") causes cljs.core to receive events from
>> the DGrid constructor. Digging in with my javascript debugger and will
>> update this as I find out more information.
>>
>>
>>
>> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
>>>
>>> Hi,
>>>
>>> I'm brand new to ClojureScript and have been trying to get myself
>>> familiarized with it's javascript interop capabilities by implementing
>>> the Dojo toolkit tutorials. I've successfully implemented several of
>>> the tutorials, but now I've run into something that I can't figure out
>>> and am looking for someone to point me in the right direction.
>>>
>>> I am calling the DGrid(Dojo grid) constructor using the function
>>> maingrid
>>>
>>> (ns couchadmin.core
>>>   (:use [jayq.util :only [clj->js]])
>>>   (:require [clojure.browser.repl :as repl]))
>>>
>>> (defn greet [dom fx]
>>>   (let [element (.byId dom "greetingcljs")]
>>> (set! (. element -innerHTML) "Hello from Dojo using
>>> ClojureScript")
>>> (.play (.slideTo fx (clj->js {:top 200 :left 200 :node
>>> element})
>>>
>>> (defn maingrid [dom grd]
>>>   (do
>>>
>>> (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid")
>>> (js/alert "hello world")))
>>>
>>> (defn ^:export main []
>>>   (comment (repl/connect "http://localhost:9000/repl";))
>>>   (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!")
>>> greet))
>>>   (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!")
>>> maingrid))
>>>
>>>
>>> When the page is loaded the grid is constructed, but afterwards I see
>>> the following javascript exception
>>>
>>> Uncaught Error: No protocol method ILookup.-lookup defined for
>>> type object: [object HTMLDivElement]
>>>
>>> I'm wondering what this message is indicating. Did I call the
>>> constructor incorrectly? Is this an incompatibility with Dojo? Do I
>>> need to implement ILookup somehow? Any help would be greatly
>>> appreciated.
>>>
>>> Brian
>>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Trouble calling Dojo grid constructor from ClojureScript

[Patrick Logan]

I sent a note to the dojo list, so they're aware of the situation. 
Meanwhile it's an easy enough work-around to avoid the problem.

-Patrick


On Saturday, December 29, 2012 5:51:32 PM UTC-8, David Nolen wrote:
>
> Yes this is known problem w/ ClojureScript that could be solved if/when we 
> get proper Keywords/Symbol types.
>
> David
>
>
> On Sat, Dec 29, 2012 at 8:46 PM, Patrick Logan 
> 
> > wrote:
>
>> From what I can tell, dojo is testing an argument to see whether it has a 
>> method named "call". dojo seems to be assuming that if such a method 
>> exists, then the argument will not be a string.
>>
>> Then clojurescript seems to be assigning a function named "call" to the 
>> String prototype. And so these two libraries conflict. 
>>
>> I am unsure whether either library is completely to blame. However it 
>> seems fairly clear that dojo does not intend to invoke "call" on a string.
>>
>> Changing dojo/on.js, line 83, to 
>>
>> if(type.call && (!type instanceof String)){
>>
>> does fix the problem. I'll check with the dojo folks on making a change 
>> along these lines unless someone can suggest a change to clojurescript.
>>
>> -Patrick
>>
>>
>> On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>>>
>>> ok. I've had some time to look into this now and have figured out a few 
>>> things.
>>>
>>> 1. This is not due to calling the DGrid constructor from clojurescript. 
>>> It occurs even when I call the DGrid constructor from straight javascript 
>>> code. So it doesn't have to do with the clojurescript code calling the 
>>> constructor.
>>>
>>> 2. The error goes away if I don't require cljs.core. If cljs.core is 
>>> required then the grid constructor ends up calling back into some code in 
>>> cljs.core, which is where the error occurs. 
>>>
>>> So I'm a little further down the road but still don't know exactly why 
>>> doing a goog.require("cljs.core") causes cljs.core to receive events from 
>>> the DGrid constructor. Digging in with my javascript debugger and will 
>>> update this as I find out more information.
>>>
>>>
>>>
>>> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:

 Hi, 

 I'm brand new to ClojureScript and have been trying to get myself 
 familiarized with it's javascript interop capabilities by implementing 
 the Dojo toolkit tutorials. I've successfully implemented several of 
 the tutorials, but now I've run into something that I can't figure out 
 and am looking for someone to point me in the right direction. 

 I am calling the DGrid(Dojo grid) constructor using the function 
 maingrid 

 (ns couchadmin.core 
   (:use [jayq.util :only [clj->js]]) 
   (:require [clojure.browser.repl :as repl])) 

 (defn greet [dom fx] 
   (let [element (.byId dom "greetingcljs")] 
 (set! (. element -innerHTML) "Hello from Dojo using 
 ClojureScript") 
 (.play (.slideTo fx (clj->js {:top 200 :left 200 :node 
 element}) 

 (defn maingrid [dom grd] 
   (do 

 (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid") 
 (js/alert "hello world"))) 

 (defn ^:export main [] 
   (comment (repl/connect "http://localhost:9000/repl";)) 
   (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!") 
 greet)) 
   (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!") 
 maingrid)) 


 When the page is loaded the grid is constructed, but afterwards I see 
 the following javascript exception 

 Uncaught Error: No protocol method ILookup.-lookup defined for 
 type object: [object HTMLDivElement] 

 I'm wondering what this message is indicating. Did I call the 
 constructor incorrectly? Is this an incompatibility with Dojo? Do I 
 need to implement ILookup somehow? Any help would be greatly 
 appreciated. 

 Brian 

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

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

Emacs launching 2 java processes

[Alice]

Hi,

I'm using emacs with inferior-lisp setup to use lein repl. Everything
works fine, but when I start the repl, I see two java.exe processes on
my windows task manager.

Is this normal behavior? Why two java processes not one are needed?

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

Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[John Gabriele]

On Saturday, December 29, 2012 5:15:49 PM UTC-5, Sean Chalmers wrote:
>
> ... but changing it to more pure function would probably deal with that.


Another benefit of pure functions is that they're easier to test.
 

> I'll have a play with 'when' as well, hadn't tried that one yet. 


`when` provides an implicit `do`, so I generally try to only use it when I 
want side-effects. (Other side-effecty forms include `do`, `doseq`, 
`dotimes` and `when-not`.)

---John

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

Re: Clarification on setting up Clojure, Lein and Emacs on fedora

[John Gabriele]

Sayth,

Not sure I follow everything in your post, but here are some tips:

 1. You don't need to "install" Clojure itself. Leiningen takes care of 
that for you. See 

 2. Make sure you install Emacs 24. I don't know what the Fedora 
incantations are for this.

 3. Once you've got Emacs 24 installed, add this to your ~/.emacs file:

~~~elisp
(require 'package)
(add-to-list 'package-archives
 '("marmalade" . "http://marmalade-repo.org/packages/";))
(package-initialize)
~~~

and then you can have Emacs install clojure-mode (and any other Emacs 
packages you desire) via "M-x package-install RET " (for 
example, clojure-mode).

 4. To get a Clojure repl in Emacs, my understanding is that slime is no 
longer the state of the art, and that you instead want to use nrepl.el. 
Some info regarding that at https://github.com/technomancy/clojure-mode 
(see the doc directory and wiki there too).

As far as a code beautifier, within Emacs you can select a region and then 
do "M-x indent-region" to autoindent everything you've selected.

---John

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

Re: Clarification on setting up Clojure, Lein and Emacs on fedora

[John Gabriele]

On Saturday, December 29, 2012 10:52:15 PM UTC-5, John Gabriele wrote:
>
> Sayth,
>
> Not sure I follow everything in your post, but here are some tips:
>
>  1. You don't need to "install" Clojure itself. Leiningen takes care of 
> that for you. See 
>
>
Whoops, sorry, forgot to finish typing that :) : I meant to add, "See 
https://github.com/clojuredocs/cds/blob/master/articles/tutorials/getting_started.md
 
".

---John

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

Re: Clarification on setting up Clojure, Lein and Emacs on fedora

[Phil Hagelberg]

I believe Fedora ships with Leiningen 1.7.1, which is not what you
want. It's better to install manually, see http://leiningen.org; that
way you will get 2.x. Don't install Clojure or Contrib through your OS
package manager.

The Emacs support for Clojure is documented here:
https://github.com/technomancy/clojure-mode/blob/master/doc/index.md

Please let us know if there's anything unclear that could be improved
about that documentation; it's always helpful to get a fresh
perspective when it comes to docs.

-Phil

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

Re: Emacs launching 2 java processes

[Phil Hagelberg]

On Sat, Dec 29, 2012 at 7:12 PM, Alice  wrote:
> I'm using emacs with inferior-lisp setup to use lein repl. Everything
> works fine, but when I start the repl, I see two java.exe processes on
> my windows task manager.
>
> Is this normal behavior? Why two java processes not one are needed?

This is normal. Two processes are needed because one is running
Leiningen and one is running your project. They need to be isolated so
Leiningen's own dependencies don't interfere with your project.
However, it's possible to allow Leiningen's JVM to exit before
launching your project; try `lein trampoline repl` for that. (I'm not
sure how well this works on Windows though.)

-Phil

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

Re: Clarification on setting up Clojure, Lein and Emacs on fedora

[Sayth Renshaw]

On Sunday, 30 December 2012 15:31:42 UTC+11, Phil Hagelberg wrote:
>
> I believe Fedora ships with Leiningen 1.7.1, which is not what you 
> want. It's better to install manually, see http://leiningen.org; that 
> way you will get 2.x. Don't install Clojure or Contrib through your OS 
> package manager. 
>
> The Emacs support for Clojure is documented here: 
> https://github.com/technomancy/clojure-mode/blob/master/doc/index.md 
>
> Please let us know if there's anything unclear that could be improved 
> about that documentation; it's always helpful to get a fresh 
> perspective when it comes to docs. 
>
> -Phil 
>

Thank you Phil. I have just reported that leinigen 1.7 is un-installable on 
F18 due to a mass of broken dependencies. 

> Don't install Clojure or Contrib through your OS package manager. 

Oops ok, yum remove them then as I had already installed them.

https://github.com/technomancy/clojure-mode/blob/master/doc/index.md will 
read and let you know if I find anything that could be improved.

Sayth

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Softaddicts]

If longevity is your top most concern, I have a suggestion here:

http://www.itarchitectforumblog.com/content/application_development/cobol_dead_language_rising.html

And if you do not think it's all around us:

http://itsacobolworld.blogspot.ca/?m=1

This thing has been alive and kicking since the 60s and has it seems a bright 
future.

However, do not expect to do anything significant under 15000 locs per code
units (aka namespace) or to become functional any time soon   :)))

Life is made of compromises...

Luc P.


> If you don't get a flood of responses, I think it is because in this thread 
> and the one linked earlier that Leon Adler started, several different people 
> have explained evidence that Clojure on the JVM has had active development 
> for five years, it is open source, and no one knows of any evidence that this 
> will change any time in the future.  That isn't the same as saying "will 
> remain", but it is the best anyone can give you that is based on evidence and 
> reason, rather than some other dubious methods.
> 
> If you believe another language will give you better assurances than that 
> about its future target/platform, I don't see how you came to that 
> conclusion, unless it is by making up conclusions out of thin air.
> 
> Andy
> 
> On Dec 29, 2012, at 2:58 AM, Leon Adler wrote:
> 
> > That's unforeseeable because, that represents a very long time.
> > 
> > Having said that, this statement deserves a resay...
> > 
> > The JVM will remain the primary target/platform for Clojure, while Oracle 
> > remains good i.e. it doesn't get Barmy.
> > 
> > What say the other people?
> > 
> > On Saturday, December 29, 2012 3:53:12 PM UTC+5:30, Sukh Singh wrote:
> > Having read the posts all over again, can I say that the JVM will remain 
> > the primary target/platform for Clojure, while Oracle remains good i.e. it 
> > doesn't get Barmy ? Isn't that unforeseeable?
> > 
> > On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote:
> > 
> >  
> > Hi, 
> > 
> > I have noticed that this question is randomly appearing in many minds, and 
> > it is frequently being asked, though there is no apparent reason on why it 
> > is asked :/ or maybe people are unable to pen down the exact reasons, and 
> > sad to say, even myself. 
> >  
> > There are reasons for which I ask this question -> 
> > People (Majority) tend to stick with the primary implementations of 
> > certain multi-implementation software. And in the case of Clojure, the  JVM 
> > implementation is the primary implementation now.
> >   
> > Having a primary implementation in case of BDFL lead software helps as 
> > a glue in the community. For example , CPython is the primary python 
> > implementation, even if there is an existance of IronPython or JPython.
> > 
> > The doubts of many, including me, will be cleared by an abstract 
> > answer... That 'many' also include the companies adopting something new, in 
> > this particular case, adopting clojure
> >  
> > QUESTION
> >  
> > Rich Hickey chose JVM as the platform of choice when he invented Clojure. 
> > It's 
> > community developed set of tools and documentation grew around the JVM 
> > (Leiningen, for example). 
> >  
> > From the above statements, can I say that  
> >  
> > the JVM will always likely, remain the primary Clojure implementation ? 
> > 
> > 
> > Thank You.
> >  
> >   
> >   
> >   
> > 
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Softaddicts sent by ibisMail from my ipad!

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

Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Laurent PETIT]

2012/12/30 John Gabriele :
> On Saturday, December 29, 2012 5:15:49 PM UTC-5, Sean Chalmers wrote:
>>
>> ... but changing it to more pure function would probably deal with that.
>
>
> Another benefit of pure functions is that they're easier to test.
>
>>
>> I'll have a play with 'when' as well, hadn't tried that one yet.
>
>
> `when` provides an implicit `do`, so I generally try to only use it when I
> want side-effects. (Other side-effecty forms include `do`, `doseq`,
> `dotimes` and `when-not`.)

On the other end, using when allows you to be explicit in your code
that there's no "else" clause

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

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

Strange behavior with future

[Oskar Kvist]

Hi!

I'm trying to play a sound in my application, 
using http://www.javazoom.net/javalayer/documents.html that lib. Anyway, I 
tried playing the sound in a future, so the main thread would not block 
while playing, like so: (future (-> in Player. .play)). But if I don't 
deref the future, the sound does not play. If I do deref it, the sound 
plays, but I have to wait for it, which is what I wanted to avoid. If I 
do (future (do (println "called") (-> in Player. .play))), without a deref, 
it prints "called" but does still not play the sound. If I do (future (do 
(-> in Player. .play) (println "called"))), without a deref, it neither 
prints nor plays. What could be wrong?

I'm using clojure 1.4.0 and `lein trampoline run -m ns/main` to run my 
program.

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