Re: Status of Generic Functions (a la lisp)

[Mark Engelberg]

The word "fast" is relative, of course.  I've been happily using Clojure's
multimethods for a long time.  They are certainly fast enough for a wide
range of uses.

I've seen a couple instances where people used a couple levels of protocols
(e.g., one function dispatching on the type of the first argument in turn
calling something that dispatches on the second argument) in order to get
some additional speed with multiple dispatch on type, but I haven't found
the need to do that myself.

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

Re: Status of Generic Functions (a la lisp)

[Alex Baranosky]

Razvan, are you asking about dispatch on multiple types...  protocols only
give fast dispatch on their first arg's type.

Currently you can either get fast dispatch on the type of the first arg, or
you get slower dispatch on anything w/ multimethods.

On Sat, Aug 3, 2013 at 11:48 PM, Robert Levy  wrote:

> But isn't that the whole point of protocols, polymorphic dispatch that is
> fast?
>
>
> On Sat, Aug 3, 2013 at 11:45 PM, Răzvan Rotaru wrote:
>
>> The keyword here is speed. Multimethods are not fast. They don't use the
>> JVM for dispatch (as far as I know). Protocols are fast. That's the reason
>> for their existence. I want to find out whether there's some effort
>> invested in making fast multiple dispatch in Clojure (and how else can it
>> be but based on Java types?).
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Status of Generic Functions (a la lisp)

[Robert Levy]

But isn't that the whole point of protocols, polymorphic dispatch that is
fast?


On Sat, Aug 3, 2013 at 11:45 PM, Răzvan Rotaru wrote:

> The keyword here is speed. Multimethods are not fast. They don't use the
> JVM for dispatch (as far as I know). Protocols are fast. That's the reason
> for their existence. I want to find out whether there's some effort
> invested in making fast multiple dispatch in Clojure (and how else can it
> be but based on Java types?).
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Status of Generic Functions (a la lisp)

[Răzvan Rotaru]

The keyword here is speed. Multimethods are not fast. They don't use the 
JVM for dispatch (as far as I know). Protocols are fast. That's the reason 
for their existence. I want to find out whether there's some effort 
invested in making fast multiple dispatch in Clojure (and how else can it 
be but based on Java types?). 

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

[ANN] core.typed 0.1.19 - core.async support

[Ambrose Bonnaire-Sergeant]

Hi,

This should be exciting news for some, and perhaps the last reason
to use Go for others ;)

core.typed now includes support for core.async.

- typed core.async
examples
.
- companion 
namespace

There's been some guessing about the types, I need feedback concerning
their correctness and utility!

Some other interesting things happened in this release. For the fully story
see the 
changelog
.

Enjoy!
Ambrose

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

Re: Can we please deprecate the :use directive ?

[Ye He]

What I mean is don't use it when you use :use.

Regards,
Ye He

On Sun, Aug 4, 2013 at 12:52 PM, Takahiro Hozumi 
wrote:

> Hi Ye,
>> or at least *Do Not Use *those standard names*.*
> The following guide suggests the opposite.
> http://dev.clojure.org/display/community/Library+Coding+Standards
>> Use good names, and don't be afraid to collide with names in other 
> namespaces. That's what the flexible namespace support is there for.
> Takahiro
> On Sunday, August 4, 2013 11:25:34 AM UTC+9, Ye He wrote:
>>
>> Yesterday, I spent hours trying to figure out why some code didn't work. 
>> The code is like so:
>> (defn replace-symbol-in-ast-node [old new ast]
>>   (tree-replace (symbol old) (symbol new) ast))
>>
>> I use tree-replace directly like this:
>> (ast/tree-replace (symbol 'a) (symbol 'c) (ast/sexp->parsley '(+ a b)))
>>
>> I thought the result would the the same but I was wrong. After hours of 
>> thinking, I finally figured it out.
>> Guess what? The 'symbol' function in the first code snippet is not the 
>> standard 'symbol'. It actually is:
>> (defn symbol [sym]
>>   (make-node :atom (core/vector (name sym
>>
>> It's defined in another library. But I stupidly thought it was the 
>> standard 'symbol'.
>> Part of this was my fault, I guess. I shouldn't have taken it for granted 
>> and guessed its meaning. But who know? 
>> In my opinion if we use less :use, it would easier for others to read our 
>> code and less likely to misunderstand the meaning, or at least *Do Not 
>> Use *those standard names*.*
>>
>>
>> On Wednesday, July 24, 2013 1:50:50 AM UTC+10, Greg wrote:
>>>
>>> I think I read somewhere that :use is no longer encouraged, but I could 
>>> be mistaken. 
>>>
>>> From what I've read, it seems like most people agree that Clojure has too 
>>> many ways of including/importing/referencing/requiring/using things: 
>>>
>>>
>>> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>>>  
>>>
>>> The above gives a very nice explanation of all the various difference, 
>>> but it also acknowledges their complexity. 
>>>
>>> Since :use uses :require, and since :require can do everything that :use 
>>> can, can we simplify Clojure programming a bit for newcomers by deprecating 
>>> the use of :use? The situation in ClojureScript is even worse because it 
>>> adds :require-macros on top of all the other ways of including files. 
>>>
>>> Ideally, it would be awesome if there was just a single directive for 
>>> everything, but perhaps there's some complicated low-level reason why 
>>> that's not possible. :-\ 
>>>
>>> Thoughts? 
>>>
>>> Thanks, 
>>> Greg 
>>>
>>> P.S. If this has already been brought up you have my sincere apologies. 
>>>
>>> -- 
>>> Please do not email me anything that you are not comfortable also sharing 
>>> with the NSA. 
>>>
>>>
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/i2VzAlT6oqM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: Can we please deprecate the :use directive ?

[Softaddicts]

You did not get a warning that "symbol" was overriding the core symbol fn ?

Luc P.

> Yesterday, I spent hours trying to figure out why some code didn't work. 
> The code is like so:
> (defn replace-symbol-in-ast-node [old new ast]
>   (tree-replace (symbol old) (symbol new) ast))
> 
> I use tree-replace directly like this:
> (ast/tree-replace (symbol 'a) (symbol 'c) (ast/sexp->parsley '(+ a b)))
> 
> I thought the result would the the same but I was wrong. After hours of 
> thinking, I finally figured it out.
> Guess what? The 'symbol' function in the first code snippet is not the 
> standard 'symbol'. It actually is:
> (defn symbol [sym]
>   (make-node :atom (core/vector (name sym
> 
> It's defined in another library. But I stupidly thought it was the standard 
> 'symbol'.
> Part of this was my fault, I guess. I shouldn't have taken it for granted 
> and guessed its meaning. But who know? 
> In my opinion if we use less :use, it would easier for others to read our 
> code and less likely to misunderstand the meaning, or at least *Do Not Use 
> *those 
> standard names*.*
> 
> 
> On Wednesday, July 24, 2013 1:50:50 AM UTC+10, Greg wrote:
> >
> > I think I read somewhere that :use is no longer encouraged, but I could be 
> > mistaken. 
> >
> > From what I've read, it seems like most people agree that Clojure has too 
> > many ways of including/importing/referencing/requiring/using things: 
> >
> >
> > http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
> >  
> >
> > The above gives a very nice explanation of all the various difference, but 
> > it also acknowledges their complexity. 
> >
> > Since :use uses :require, and since :require can do everything that :use 
> > can, can we simplify Clojure programming a bit for newcomers by deprecating 
> > the use of :use? The situation in ClojureScript is even worse because it 
> > adds :require-macros on top of all the other ways of including files. 
> >
> > Ideally, it would be awesome if there was just a single directive for 
> > everything, but perhaps there's some complicated low-level reason why 
> > that's not possible. :-\ 
> >
> > Thoughts? 
> >
> > Thanks, 
> > Greg 
> >
> > P.S. If this has already been brought up you have my sincere apologies. 
> >
> > -- 
> > Please do not email me anything that you are not comfortable also sharing 
> > with the NSA. 
> >
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Takahiro Hozumi]

Hi Ye,

> or at least *Do Not Use *those standard names*.*

The following guide suggests the opposite.

http://dev.clojure.org/display/community/Library+Coding+Standards
> Use good names, and don't be afraid to collide with names in other 
namespaces. That's what the flexible namespace support is there for.

Takahiro

On Sunday, August 4, 2013 11:25:34 AM UTC+9, Ye He wrote:
>
> Yesterday, I spent hours trying to figure out why some code didn't work. 
> The code is like so:
> (defn replace-symbol-in-ast-node [old new ast]
>   (tree-replace (symbol old) (symbol new) ast))
>
> I use tree-replace directly like this:
> (ast/tree-replace (symbol 'a) (symbol 'c) (ast/sexp->parsley '(+ a b)))
>
> I thought the result would the the same but I was wrong. After hours of 
> thinking, I finally figured it out.
> Guess what? The 'symbol' function in the first code snippet is not the 
> standard 'symbol'. It actually is:
> (defn symbol [sym]
>   (make-node :atom (core/vector (name sym
>
> It's defined in another library. But I stupidly thought it was the 
> standard 'symbol'.
> Part of this was my fault, I guess. I shouldn't have taken it for granted 
> and guessed its meaning. But who know? 
> In my opinion if we use less :use, it would easier for others to read our 
> code and less likely to misunderstand the meaning, or at least *Do Not 
> Use *those standard names*.*
>
>
> On Wednesday, July 24, 2013 1:50:50 AM UTC+10, Greg wrote:
>>
>> I think I read somewhere that :use is no longer encouraged, but I could 
>> be mistaken. 
>>
>> From what I've read, it seems like most people agree that Clojure has too 
>> many ways of including/importing/referencing/requiring/using things: 
>>
>>
>> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>>  
>>
>> The above gives a very nice explanation of all the various difference, 
>> but it also acknowledges their complexity. 
>>
>> Since :use uses :require, and since :require can do everything that :use 
>> can, can we simplify Clojure programming a bit for newcomers by deprecating 
>> the use of :use? The situation in ClojureScript is even worse because it 
>> adds :require-macros on top of all the other ways of including files. 
>>
>> Ideally, it would be awesome if there was just a single directive for 
>> everything, but perhaps there's some complicated low-level reason why 
>> that's not possible. :-\ 
>>
>> Thoughts? 
>>
>> Thanks, 
>> Greg 
>>
>> P.S. If this has already been brought up you have my sincere apologies. 
>>
>> -- 
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA. 
>>
>>

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

Re: Can we please deprecate the :use directive ?

[Ye He]

Yesterday, I spent hours trying to figure out why some code didn't work. 
The code is like so:
(defn replace-symbol-in-ast-node [old new ast]
  (tree-replace (symbol old) (symbol new) ast))

I use tree-replace directly like this:
(ast/tree-replace (symbol 'a) (symbol 'c) (ast/sexp->parsley '(+ a b)))

I thought the result would the the same but I was wrong. After hours of 
thinking, I finally figured it out.
Guess what? The 'symbol' function in the first code snippet is not the 
standard 'symbol'. It actually is:
(defn symbol [sym]
  (make-node :atom (core/vector (name sym

It's defined in another library. But I stupidly thought it was the standard 
'symbol'.
Part of this was my fault, I guess. I shouldn't have taken it for granted 
and guessed its meaning. But who know? 
In my opinion if we use less :use, it would easier for others to read our 
code and less likely to misunderstand the meaning, or at least *Do Not Use 
*those 
standard names*.*


On Wednesday, July 24, 2013 1:50:50 AM UTC+10, Greg wrote:
>
> I think I read somewhere that :use is no longer encouraged, but I could be 
> mistaken. 
>
> From what I've read, it seems like most people agree that Clojure has too 
> many ways of including/importing/referencing/requiring/using things: 
>
>
> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>  
>
> The above gives a very nice explanation of all the various difference, but 
> it also acknowledges their complexity. 
>
> Since :use uses :require, and since :require can do everything that :use 
> can, can we simplify Clojure programming a bit for newcomers by deprecating 
> the use of :use? The situation in ClojureScript is even worse because it 
> adds :require-macros on top of all the other ways of including files. 
>
> Ideally, it would be awesome if there was just a single directive for 
> everything, but perhaps there's some complicated low-level reason why 
> that's not possible. :-\ 
>
> Thoughts? 
>
> Thanks, 
> Greg 
>
> P.S. If this has already been brought up you have my sincere apologies. 
>
> -- 
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA. 
>
>

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

Re: Hiring Clojure Programmer(s)

[Quinn Finney]

It doesn't matter to us, it's a job for one project that can be worked on 
from anywhere. However, we are located in Orange County, California. (The 
number is from Seattle, but that is just my personal cell)

On Friday, August 2, 2013 9:47:21 AM UTC-7, Quinn Finney wrote:
>
> Hello all,
>
> My company is looking to hire a Clojure programmer to help assess and 
> finish our product, a server architecture system for Java instances. The 
> product involves receiving input from a web control panel and making 
> changes based on that. To our knowledge, the product is currently 85% 
> complete. This will be a payed position. Please email me at 
> quinn.fin...@gmail.com or call me at (206) 660 5366 for more information 
> if you are interested. 
>

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

Re: Hiring Clojure Programmer(s)

[Asim Jalis]

The area code suggests Seattle, WA.

On Aug 2, 2013, at 2:14 PM, Marcus Blankenship  wrote:

> Unless that doesn't matter…
> 
> 
> On Aug 2, 2013, at 12:27 PM, Andrew Stine  wrote:
> 
>> Might help if you said what part of the world you're in.
>> 
>> On Friday, August 2, 2013 12:47:21 PM UTC-4, Quinn Finney wrote:
>>> 
>>> Hello all,
>>> 
>>> My company is looking to hire a Clojure programmer to help assess and 
>>> finish our product, a server architecture system for Java instances. The 
>>> product involves receiving input from a web control panel and making 
>>> changes based on that. To our knowledge, the product is currently 85% 
>>> complete. This will be a payed position. Please email me at 
>>> quinn@gmail.com or call me at (206) 660 5366 for more information if 
>>> you are interested. 
>> 
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> MARCUS BLANKENSHIP
> \\\ Owner, Problem Solver, Thinker
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

Re: core.async: faulty rebinding of loop-bindings in go blocks

[Kemar]

It appears to be working, awesome!
Thanks!

Cheers,
Kevin

Am Samstag, 3. August 2013 21:05:57 UTC+2 schrieb Ghadi Shayban:
>
> Fixed -- should make it to maven within an hour.
>

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

trying out overtone, leipzip, chris-ford's functional composition code

[Geoffrey Knauth]

I'm fairly new to Clojure.  At LambdaJam I saw Chris Ford give a great demo 
of functional composition [music].  I want to show my 16-yo the same code 
working, since he's really doing well with Racket (and Gregor Kiczales' 
MOOC via UBC) and loving it, and he loves music and music composition too.

Chris Ford posted his code here:
https://github.com/ctford/functional-composition/tree/LambdaJam-2013

My directory structure looks like this:
  ~/test/github/lj2013/chris-ford/
functional-composition/
...
functional-composition/src/jazz/standards/in_the_mood.clj
...
leipzig/
overtone/
whelmed/

I've installed Clojure and Leiningen.  I'm in Emacs and have clojure-mode 
and nrepl.  I'm trying to figure out how to get things going.  I typed M-x 
nrepl-jack-in in Emacs and got a REPL.  I'm sure my classpath is not set up 
right; I'm not sure how to do that.  I think .clj files need to be 
compiled.  I'm not sure how to make that happen.

How should I organize these files to get things to work?

There is an Emacs-Live setup for Overtone+Emacs but when I tried that it 
completely moved my ~/.emacs aside and I'm not sure that's what I want, 
since I use Emacs for many many things that are not in Emacs-Live's setup.

Geoff

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

Re: core.async: faulty rebinding of loop-bindings in go blocks

[Ghadi Shayban]

Fixed -- should make it to maven within an hour.

On Thursday, August 1, 2013 12:47:16 PM UTC-4, Ghadi Shayban wrote:
>
> It's a nasty bug, seems like a local symbol scope issue.  I will take a 
> look at it.  Thanks for the report.
>
> On Thursday, August 1, 2013 6:05:59 AM UTC-4, Kemar wrote:
>>
>> There seems to be an issue with the rebinding of loop-bindings using 
>> loop/recur in go blocks,
>> specifically when you are just changing the order of the original 
>> bindings in a recur call.
>>
>> Take this snippet for example:
>>
>>
>> (require '[clojure.core.async :refer [go timeout]])
>>> (go (loop [a :black, b :white]  
>>>   (println a b)
>>>   (>>   (recur b a)))
>>>
>>
>> Instead of repeatedly printing
>>
>> :black :white
>>> :white :black
>>> :black :white 
>>> :white :black
>>> (...)
>>>
>>
>>  it actually prints
>>
>> :black :white
>>> :white :white
>>> :white :white
>>> :white :white
>>> (...)
>>>
>>  
>> Note however, that 
>>  
>>
>>> (require '[clojure.core.async :refer [go timeout]])
>>> (go (loop [a :black, b :white]  
>>>   (println a b)
>>>   (>>   (recur (identity b) (identity a
>>>
>>
>> works correctly.
>>
>> Any ideas as to what's causing this?
>>
>>
>> Cheers,
>> Kevin
>>
>>

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

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

Thanks for the complements! I just released 0.0.2, which should make 
Run/Build faster and more reliable. It also fixes shortcuts on OS X so they 
use command instead of control.

On Saturday, August 3, 2013 8:07:31 AM UTC-4, Manuel Paccagnella wrote:
>
> Wow, it looks very promising. I'd also like add a +1 for smart indent and 
> paredit. 
>
> Kudos to you Zach!
>
> Manuel
>
> Il giorno venerdì 2 agosto 2013 15:03:03 UTC+2, Zach Oakes ha scritto:
>>
>> I’ve been working on a simple IDE for the past few months. It started as 
>> an attempt to add Leiningen integration to Clooj, but eventually I decided 
>> to start a new project from scratch. It is very alpha-quality, so please be 
>> gentle:
>>
>> http://nightcode.info/
>>
>> Here’s what it has:
>>
>> -Written in Clojure (the UI is written with seesaw)
>>
>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>>
>> -Built-in templates for several common types of Clojure and Java projects
>>
>> -Always-on REPL in the corner to try Clojure commands
>>
>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>>
>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>>
>> -Cool looking dark theme, because that’s trendy these days
>>
>> Here’s what it’s missing:
>>
>> -Fast build times (it launches Leiningen in a separate process, which is 
>> slw...I plan on fixing this and would love any help)
>>
>> -Important editing features (code completion, text replace, etc)
>>
>> -Quick switching between recent files
>>
>> -Jump to definition, built-in documentation
>>
>> -Integration between editor and REPL (eval form or entire file)
>>
>> -Integration with git
>> -Many other things -- please give me your thoughts!
>>
>

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

Re: Status of Generic Functions (a la lisp)

[Robert Levy]

Oh wait nm, misread completely. The solution exists and it's called
protocols.


On Sat, Aug 3, 2013 at 11:37 AM, Robert Levy  wrote:

> Sounds like he wants predicate dispatch? That was an early motivation for
> core.logic and as far as I know it's in the works.
>
>
> On Sat, Aug 3, 2013 at 4:22 AM, Răzvan Rotaru wrote:
>
>> Hi,
>>
>> I'm looking for fast lisp style generic functions in clojure. In other
>> words: multimethods that dispatch on the java type.
>> A search on the web revealed little, since protocols and multimethods
>> always show up. I have also seen some old discussion in this group on the
>> topic, but I couldn't figure out whether there is a usable implementation
>> out there. So I'm posting my question on this group.
>>
>> 1/ Is there generic function implementation out there that I can use?
>> 2/ Are there plans to include them in future versions of clojure?
>> 3/ And lastly, could this be implemented as a sequence of single dispatch
>> (using the available single dispatch, which is fast)?
>>
>> Thanks,
>> Răzvan
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>

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

Re: Status of Generic Functions (a la lisp)

[Robert Levy]

Sounds like he wants predicate dispatch? That was an early motivation for
core.logic and as far as I know it's in the works.


On Sat, Aug 3, 2013 at 4:22 AM, Răzvan Rotaru wrote:

> Hi,
>
> I'm looking for fast lisp style generic functions in clojure. In other
> words: multimethods that dispatch on the java type.
> A search on the web revealed little, since protocols and multimethods
> always show up. I have also seen some old discussion in this group on the
> topic, but I couldn't figure out whether there is a usable implementation
> out there. So I'm posting my question on this group.
>
> 1/ Is there generic function implementation out there that I can use?
> 2/ Are there plans to include them in future versions of clojure?
> 3/ And lastly, could this be implemented as a sequence of single dispatch
> (using the available single dispatch, which is fast)?
>
> Thanks,
> Răzvan
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: should contains? throw an exception on sorted maps?

[Bronsa]

Ops, I didn't see Andy already replied, sorry for the unnecessary mail.


On Sat, Aug 3, 2013 at 7:10 PM, Nicola Mometto  wrote:

>
> http://dev.clojure.org/jira/browse/CLJ-1242
>
> Jay Fields writes:
>
> > This: (contains? (sorted-map 1 2 3 4) :a)
> > Results in this: ClassCastException java.lang.Long cannot be cast to
> > clojure.lang.Keyword  clojure.lang.Keyword.compareTo (Keyword.java:102)
> >
> > --
>

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

Re: should contains? throw an exception on sorted maps?

[Nicola Mometto]

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

Jay Fields writes:

> This: (contains? (sorted-map 1 2 3 4) :a)
> Results in this: ClassCastException java.lang.Long cannot be cast to
> clojure.lang.Keyword  clojure.lang.Keyword.compareTo (Keyword.java:102)
>
> --

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

Re: should contains? throw an exception on sorted maps?

[Andy Fingerhut]

It throws because it calls the compare function on the value you are
checking and one or more values in the ordered set, and compare throws when
called with 2 values that are of different enough types.


https://github.com/jafingerhut/thalia/blob/master/doc/project-docs/clojure.core-1.5.1/clojure.core/compare.md

Nicola Mometto recently created ticket
http://dev.clojure.org/jira/browse/CLJ-1242 and wrote a patch for it that
would catch such exceptions in some cases, perhaps for contains? calls,
too, and cause them to return false instead of throwing.  It hasn't been
Vetted, so it remains to be seen what the Clojure developers answer to your
"should" question is.

Andy


On Sat, Aug 3, 2013 at 6:47 AM, Jay Fields  wrote:

> This: (contains? (sorted-map 1 2 3 4) :a)
> Results in this: ClassCastException java.lang.Long cannot be cast to
> clojure.lang.Keyword  clojure.lang.Keyword.compareTo (Keyword.java:102)
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Status of Generic Functions (a la lisp)

[Softaddicts]

I can't understand why multi methods or protocols do not
satisfy your needs. Care to shed some light on your needs ?

Luc P.


> Hi,
> > I'm looking for fast lisp style generic functions in clojure. In other 
> words: multimethods that dispatch on the java type.
> A search on the web revealed little, since protocols and multimethods > 
> always show up. I have also seen some old discussion in this group on the > 
> topic, but I couldn't figure out whether there is a usable implementation > 
> out there. So I'm posting my question on this group.
> > 1/ Is there generic function implementation out there that I can use? > 2/ 
> > Are there plans to include them in future versions of clojure? > 3/ And 
> > lastly, could this be implemented as a sequence of single dispatch > (using 
> > the available single dispatch, which is fast)?
> > Thanks,
> Răzvan
> > -- > -- > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- > You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> > > --
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Status of Generic Functions (a la lisp)

[Mark Engelberg]

What's wrong with the built-in multimethods?

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

Re: futures - The Joy Of Clojure book question

[Ryan Moore]

Thanks guys. I had a feeling that it wasn't doing the calculation twice the 
way it was coded in the book.

Ryan

On Tuesday, July 23, 2013 11:23:21 AM UTC-4, Lars Nilsson wrote:
>
> On Tue, Jul 23, 2013 at 11:12 AM, Baishampayan Ghose 
> > 
> wrote: 
> > It's definitely got to do with the code, the right way to test it out 
> > will be to wrap the form in a function and then calling it twice. Like 
> > so - 
> > 
> > (time 
> >   (let [x (fn [] (Thread/sleep 2000) 
> >(+ 1 1))] 
> >  [(x) (x)])) 
> > ;=> "Elapsed time: 4002.0 msecs" 
> > ;=> [2 2] 
> > 
> > Hope that helps. 
> > 
> > Regards, 
> > BG 
> > 
> > 
> > On Tue, Jul 23, 2013 at 8:34 PM, Ryan Moore 
> > > 
> wrote: 
> >> There is an example in the book The Joy of Clojure on p.262 that uses 
> >> futures that I evaluated in the REPL. 
> >> 
> >> user> (time 
> >>(let [x (future (do (Thread/sleep 2000) 
> >>   (+ 1 1)))] 
> >> [@x @x])) 
> >> "Elapsed time: 2000.809 msecs" 
> >> [2 2] 
> >> 
> >> I figured that taking out the future would cause the execution to take 
> twice 
> >> as long, however, when I try this: 
> >> 
> >> user> (time 
> >>(let [x (do (Thread/sleep 2000) 
> >>   (+ 1 1))] 
> >> [x x])) 
> >> "Elapsed time: 2000.512 msecs" 
> >> [2 2] 
> >> 
> >> as you see it takes about the same amount of time. Does this have 
> something 
> >> to do with the REPL evaluating things or maybe the newer version of 
> Clojure 
> >> handles things differently from the Joy of Clojure book? 
>
> Can also show the difference using two different vars 
>
>   (time (let [x (future (do (Thread/sleep 2000) (+ 1 1))) 
>   y (future (do (Thread/sleep 3000) (+ 2 2)))] 
>   [@x @y])) 
>
> "Elapsed time: 3003.802 msecs" 
> [2 4] 
>
>   (time (let [x (do (Thread/sleep 2000) (+ 1 1)) 
>   y (do (Thread/sleep 3000) (+ 2 2))] 
>   [x y])) 
>
> "Elapsed time: 5003.049 msecs" 
> [2 4] 
>
> Basically, [x x] doesn't do the evaluation, it happens in the let once 
> for x. For [@x @x] the thread is kicked off once to do the 
> computation, and the first @x waits for the result (if not already 
> available) while the second @x uses the cached value. 
>
> In my modified version, the second case the two Thread/sleep happens 
> in sequence, while in the first they take place in parallel thanks to 
> the futures. 
>
> Lars Nilsson 
>

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

Re: the snake game with core.async and swing

[Chris Ford]

Cool!

If you want to make the Swing stuff more idiomatic, you could take a look
at Seesaw .


On 2 August 2013 17:11,  wrote:

> Below is a little (stupid) snake game I wrote using core.async and swing.
> It uses channels for timer, keyboard input and repaint to make everything
> nice and sequential.
> Thought it could be a nice example of the power of core.async.
>
> I'm not an experienced clojure/lisp developer so I'd be happy if someone
> could give me some feedback on the code.
> Is it clojure idiomatic?
> Am I using core.async properly?
> etc.
>
> Thanks
> --anders
>
>
> (ns my-test
>   (use [midje.sweet])
>   (require [clojure.core.async :as async :refer :all])
>   (import [javax.swing JFrame JButton JPanel SwingUtilities])
>   (import [java.awt Color Dimension])
>   (import [java.awt.event ActionListener WindowAdapter KeyListener]))
>
>
> (defn map-chan [f in]
>   (let [c (chan)]
> (go (loop []
>   (when-let [v (f ( (>! c v))
>   (recur)))
> c))
>
> (defn start-timer! []
>   (let [c (chan)]
> (go (while true (! c :go)))
> c))
>
> (defn closing-channel [frame]
>   (let [c (chan)]
> (.addWindowListener frame
> (proxy [WindowAdapter] []
>   (windowClosing [e] (put! c e
> c))
>
> (defn array-of [coordinates index]
>   (int-array (map #(nth % index) coordinates)))
>
> (defn points-of [coordinates]
>   [(array-of coordinates 0) (array-of coordinates 1)])
>
> (defn draw-poly-line [canvas coordinates]
>   (SwingUtilities/invokeLater
>(fn []
>  (let [[x-points y-points] (points-of coordinates)
>g (.getGraphics canvas)
>prev-color (.getColor g)]
>   (.setColor g Color/BLACK)
>   (.drawPolyline g x-points y-points (count coordinates))
>   (.setColor g prev-color)
>
> (def step 5)
> (defmulti calc-new-pos (fn[xy prev-pos dir] [xy dir]))
> (defmethod calc-new-pos [:x :right][xy prev-pos dir] (+ prev-pos step))
> (defmethod calc-new-pos [:x :left][xy prev-pos dir] (- prev-pos step))
> (defmethod calc-new-pos [:y :down][xy prev-pos dir] (+ prev-pos step))
> (defmethod calc-new-pos [:y :up][xy prev-pos dir] (- prev-pos step))
> (defmethod calc-new-pos :default [xy prev-pos dir] prev-pos)
>
> (defn calc-snake [dir snake-obj counter]
>   (let [[l-x l-y] (last snake-obj)
> old-snake (if (= (mod counter 2) 0) snake-obj (rest snake-obj))]
> (conj (vec old-snake) [(calc-new-pos :x l-x dir) (calc-new-pos :y l-y
> dir)])))
>
> (facts "snake positions"
>(fact "snake moves and grows"
>  (calc-snake :right [[1 2]] 2) => [[1 2] [6 2]]
>  (calc-snake :right [[2 2]] 4) => [[2 2] [7 2]])
>(facts "snake moves"
>   (calc-snake :right [[1 2]] 1) => [[6 2]]
>   (calc-snake :down [[1 2]] 1) => [[1 7]]
>   (calc-snake :left [[10 2]] 1) => [[5 2]]
>   (calc-snake :up [[10 7]] 1) => [[10 2]]
>   ))
>
> (def key-to-dir-map {37 :left, 38 :up, 39 :right, 40 :down})
>
> (defn key-channel [obj]
>   (let [c (chan)]
> (.addKeyListener obj
>  (reify KeyListener
>(keyTyped [_ e] )
>(keyPressed [_ e] )
>(keyReleased [_ e]
>  (put! c e
> c))
>
> (defn create-canvas [paint-channel]
>   (proxy [JButton] []
>  (getPreferredSize [] (Dimension. 300 300))
>  (paintComponent [g]
>(go
>  (proxy-super paintComponent g)
>  (>! paint-channel :repaint)
>
> (defmulti inside-window? (fn [dir canvas pos] dir))
> (defmethod inside-window? :left [dir canvas [x _]] (>= x (.getX canvas)))
> (defmethod inside-window? :right [dir canvas [x _]] (<= x (+ (.getX
> canvas) (.getWidth canvas
> (defmethod inside-window? :up [dir canvas [_ y]] (>= y (.getY canvas)))
> (defmethod inside-window? :down [dir canvas [_ y]] (<= y (+ (.getY canvas)
> (.getHeight canvas
>
>
>
> (def initial-snake (vec  (map (fn [x] [x 10])  (take 20 (iterate (partial
> + step) 0)
>
>
> (defn game-rules-ok? [snake dir canvas]
>   (and
>(apply distinct? snake)
>(inside-window? dir canvas (last snake
>
> (facts "game rules"
>(let [canvas (JButton.)]
>  (.setBounds canvas 0 0 10 10)
>  (facts "inside window"
> (game-rules-ok? [[0 0]] :right canvas) => truthy
> (game-rules-ok? [[11 0]] :right canvas) => falsey
> (game-rules-ok? [[11 0]] :left canvas) => truthy
> (game-rules-ok? [[11 0]] :up canvas) => truthy
> (game-rules-ok? [[11 0]] :down canvas) => truthy
> (game-rules-ok? [[11 11]] :down canvas) => falsey)
>  (facts "snake eating itself"
>   (game-rules-ok? [[0 0] [0 0]] :right canvas) => falsey
>   (game-rules-ok?

should contains? throw an exception on sorted maps?

[Jay Fields]

This: (contains? (sorted-map 1 2 3 4) :a)
Results in this: ClassCastException java.lang.Long cannot be cast to
clojure.lang.Keyword  clojure.lang.Keyword.compareTo (Keyword.java:102)

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

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Manuel Paccagnella]

Wow, it looks very promising. I'd also like add a +1 for smart indent and 
paredit. 

Kudos to you Zach!

Manuel

Il giorno venerdì 2 agosto 2013 15:03:03 UTC+2, Zach Oakes ha scritto:
>
> I’ve been working on a simple IDE for the past few months. It started as 
> an attempt to add Leiningen integration to Clooj, but eventually I decided 
> to start a new project from scratch. It is very alpha-quality, so please be 
> gentle:
>
> http://nightcode.info/
>
> Here’s what it has:
>
> -Written in Clojure (the UI is written with seesaw)
>
> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>
> -Built-in templates for several common types of Clojure and Java projects
>
> -Always-on REPL in the corner to try Clojure commands
>
> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>
> -ClojureScript integration (includes the lein-cljsbuild plugin)
>
> -Cool looking dark theme, because that’s trendy these days
>
> Here’s what it’s missing:
>
> -Fast build times (it launches Leiningen in a separate process, which is 
> slw...I plan on fixing this and would love any help)
>
> -Important editing features (code completion, text replace, etc)
>
> -Quick switching between recent files
>
> -Jump to definition, built-in documentation
>
> -Integration between editor and REPL (eval form or entire file)
>
> -Integration with git
> -Many other things -- please give me your thoughts!
>

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

Status of Generic Functions (a la lisp)

[Răzvan Rotaru]

Hi,

I'm looking for fast lisp style generic functions in clojure. In other 
words: multimethods that dispatch on the java type.
A search on the web revealed little, since protocols and multimethods 
always show up. I have also seen some old discussion in this group on the 
topic, but I couldn't figure out whether there is a usable implementation 
out there. So I'm posting my question on this group.

1/ Is there generic function implementation out there that I can use? 
2/ Are there plans to include them in future versions of clojure? 
3/ And lastly, could this be implemented as a sequence of single dispatch 
(using the available single dispatch, which is fast)?

Thanks,
Răzvan

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