New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Clojure Engineers Needed at Factual

http://functionaljobs.com/jobs/8646-clojure-engineers-needed-at-factual



Cheers,

Sean Murphy

FunctionalJobs.com


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

Re: ANN: ClojureScript 0.0-1885 (Source maps!)

[Marco Munizaga]

I'm so happy for this, I've been subscribed to that issue on Jira for a while 
now, and here it is, alive and working! Just ran some demo code and it looks 
amazing! Thanks Sean Grove and thanks David Nolen. I'll let you know about any 
bugs I find.
On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> 
> The biggest change in this release thanks to Sean Grove - much improved 
> source maps. You can provide a :source-map option to the compiler to name the 
> source map file. Feedback on this significant enhancement welcome.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> New release version: 0.0-1885
> 
> 
> Leiningen dependency information:
> 
>     [org.clojure/clojurescript "0.0-1885"]
> 
> 
> 
> 
> Enhancements: 
> 
> * Accurate source maps!
> 
> 
> Changes:
> 
> * cljs.core/format based on goog.string/format backed out
> * set-print-fn! no longer exported
> 
> 
> 
> Fixes:
> * CLJS-588: allow upstream :foreign-libs to be used

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

[Mikera]

You might want to take a look at this library announcement (CloCoP): I 
think it may be just what you need:

https://groups.google.com/d/topic/clojure/krPr6xb5rGQ/discussion

On Friday, 13 September 2013 22:52:04 UTC+8, Mark Watson wrote:
>
> Hi, newish user here.
>
> I want to make an app that finds a simple, optimized, fantasy baseball 
> lineup.
>
> Each player has a cost associated with them, as well as the average points 
> per game they score, and position. For example: Mike Napoli, 4600, 2.9, 1B
>
> You have to choose one of each position: catcher, pitcher, 1st base, 2nd 
> base, 3rd base, and shortstop. You also have to pick three outfielders. It 
> would be easy to just pick the players with the highest points per game, 
> but you also need to stay under a specified total cost.
>
> Currently, I iterate through every possibility, and swap an atom with a 
> new lineup if the total average points is higher, while staying under the 
> total cost limit.
>
> My issues are:
>
> 1) This seems like an inelegant solution (brute force)
> 2) I don't know how to best handle the fact that I need to select three 
> outfielders from a single list, and cannot select one player more than once
>
> Any advice, suggestions would be great. Thanks!
>

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

[Mikera]

Yeah, it certainly is not quite up to giving you true dynamic language 
capabilities yet :-)

Still, it's better than nothing. The combination of being able to 
hot-update methods and set breakpoints plus all the usual debugging 
facilities makes the "working with Java from the REPL" experience much more 
pleasant overall. There's also no real downside to using this (assuming you 
have plenty of memory available to run your Clojure JVM in debug mode)

On Monday, 16 September 2013 12:09:09 UTC+8, Luc wrote:
>
> I rarely use debug mode even when we had a mix of Clojure/Java code 
> a year ago. When it happens it's because some obscure compiler error 
> made me bang my head on my desk several times :) 
>
> Never tried debug mode with java source code changes to see how far we can 
> go 
> with on the fly compilation, to me the words dynamic and Java are mutually 
> exclusive :) 
>
> If you cannot change method signatures, this usage looks quite limited. 
>
> Luc P. 
>
>
> > On c), it is worth noting that if you run the REPL in Eclipse's debug 
> mode 
> > then you can change Java source code without restarting the REPL in many 
> > cases. It will do hot code reloading of Java method bodies just fine. 
> The 
> > only thing you can't do is change method signatures, which requires a 
> full 
> > JVM restart I think. 
> > 
> > On Monday, 16 September 2013 01:13:21 UTC+8, Luc wrote: 
> > > 
> > > a) You test your code using the REPL window. In the bottom there's a 
> user 
> > > input 
> > >  area were you can run Clojure expression interactively. 
> > >  The REPL panel has a couple of buttons in the top right corner. 
> > >  You can see the last exception, interrupt processing if it loops 
> > > forever, ... 
> > > 
> > >  The console is used to look at detailed error messages from the 
> > > runtime 
> > >   like exceptions.   
> > > 
> > > b) When editing a Clojure source file, you can load it in a REPL 
> directly 
> > > by using either a shortcut ctrl->alt->s or through the 
> > > mouse-right-click -> Clojure 
> > > menu. Look at the shortcuts available. You can reload a name space 
> > > in a running REPL on the fly, redefine stuff through cursor 
> selection, 
> > > change the current name space in the REPL to the one of the source 
> > > file 
> > > edited,  
> > > 
> > > c) The time it takes to get the REPL alive can be significant 
> depending on 
> > > your 
> > > hardware. The idea is to avoid restarting it as much as possible 
> by 
> > > reloading name spaces or redefining fns, ... w/o shutting down 
> your 
> > > current REPL. Beware that in some cases it's unavoidable like when 
> > > you alter the project class path or if you are modifying java 
> source 
> > > code 
> > > part of your clojure project. The Java compilation will alter 
> static 
> > > files 
> > > not the loaded code in the JVM supporting the REPL. 
> > > 
> > > Can't help you much with the menu that vanished but if you work 
> > > within a clojure source file and not the other way around, you should 
> be 
> > > able 
> > > to run it with the above indications. 
> > > 
> > > Make sure that your project has it's Clojure nature enabled otherwise 
> none 
> > > of 
> > > the Clojure shortcuts will appear in the editor context menu. 
> > > 
> > > Luc 
> > > 
> > > 
> > > >   
> > > > 
> > > > I'm learning clojure on eclipse (counterclockwise plugin). 
> > > > 
> > > >- When I click "run" in eclipse (as I would do with Java) I get 
> not 
> > > only 
> > > >the console opened but this "REPL" window. Why is it necessary 
> and 
> > > what 
> > > >does it do? 
> > > >- When I click "run" it takes quite a few seconds to launch the 
> app. 
> > > Is 
> > > >there a way to make it faster? 
> > > >- When I need to edit the code and relaunch (run) the the app I'm 
> > > >getting this message: "The selection cannot be launched, and 
> there 
> > > are no 
> > > >recent launches". What is that and why wouldn't it let me 
> relaunch my 
> > > code? 
> > > >If I wait a while I can launch it again. 
> > > >- I was screwing around and I don't know what I did, but now "Run 
> as" 
> > > -> 
> > > >"Clojure Application" option is gone. How do I get it back? 
> > > > 
> > > > This is simple bit of code that I'm trying to run: 
> > > > 
> > > > (ns ClojureTest.core) 
> > > > (let [input (read-line)] 
> > > >   (if (= "x" input) 
> > > > (do 
> > > >   (println "Exit") 
> > > >   (System/exit 0) 
> > > > ) 
> > > > (do 
> > > >   (println input) 
> > > >   (recur) 
> > > > ) 
> > > >   )) 
> > > > 
> > > > -- 
> > > > -- 
> > > > 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 
> > > yo

Re: eclipse (counterclockwise) questions

[Softaddicts]

I rarely use debug mode even when we had a mix of Clojure/Java code
a year ago. When it happens it's because some obscure compiler error
made me bang my head on my desk several times :)

Never tried debug mode with java source code changes to see how far we can go
with on the fly compilation, to me the words dynamic and Java are mutually
exclusive :)

If you cannot change method signatures, this usage looks quite limited.

Luc P.


> On c), it is worth noting that if you run the REPL in Eclipse's debug mode 
> then you can change Java source code without restarting the REPL in many 
> cases. It will do hot code reloading of Java method bodies just fine. The 
> only thing you can't do is change method signatures, which requires a full 
> JVM restart I think.
> 
> On Monday, 16 September 2013 01:13:21 UTC+8, Luc wrote:
> >
> > a) You test your code using the REPL window. In the bottom there's a user 
> > input 
> >  area were you can run Clojure expression interactively. 
> >  The REPL panel has a couple of buttons in the top right corner. 
> >  You can see the last exception, interrupt processing if it loops 
> > forever, ... 
> >
> >  The console is used to look at detailed error messages from the 
> > runtime 
> >   like exceptions.   
> >
> > b) When editing a Clojure source file, you can load it in a REPL directly 
> > by using either a shortcut ctrl->alt->s or through the 
> > mouse-right-click -> Clojure 
> > menu. Look at the shortcuts available. You can reload a name space 
> > in a running REPL on the fly, redefine stuff through cursor selection, 
> > change the current name space in the REPL to the one of the source 
> > file 
> > edited,  
> >
> > c) The time it takes to get the REPL alive can be significant depending on 
> > your 
> > hardware. The idea is to avoid restarting it as much as possible by 
> > reloading name spaces or redefining fns, ... w/o shutting down your 
> > current REPL. Beware that in some cases it's unavoidable like when 
> > you alter the project class path or if you are modifying java source 
> > code 
> > part of your clojure project. The Java compilation will alter static 
> > files 
> > not the loaded code in the JVM supporting the REPL. 
> >
> > Can't help you much with the menu that vanished but if you work 
> > within a clojure source file and not the other way around, you should be 
> > able 
> > to run it with the above indications. 
> >
> > Make sure that your project has it's Clojure nature enabled otherwise none 
> > of 
> > the Clojure shortcuts will appear in the editor context menu. 
> >
> > Luc 
> > 
> >
> > >   
> > > 
> > > I'm learning clojure on eclipse (counterclockwise plugin). 
> > > 
> > >- When I click "run" in eclipse (as I would do with Java) I get not 
> > only 
> > >the console opened but this "REPL" window. Why is it necessary and 
> > what 
> > >does it do? 
> > >- When I click "run" it takes quite a few seconds to launch the app. 
> > Is 
> > >there a way to make it faster? 
> > >- When I need to edit the code and relaunch (run) the the app I'm 
> > >getting this message: "The selection cannot be launched, and there 
> > are no 
> > >recent launches". What is that and why wouldn't it let me relaunch my 
> > code? 
> > >If I wait a while I can launch it again. 
> > >- I was screwing around and I don't know what I did, but now "Run as" 
> > -> 
> > >"Clojure Application" option is gone. How do I get it back? 
> > > 
> > > This is simple bit of code that I'm trying to run: 
> > > 
> > > (ns ClojureTest.core) 
> > > (let [input (read-line)] 
> > >   (if (= "x" input) 
> > > (do 
> > >   (println "Exit") 
> > >   (System/exit 0) 
> > > ) 
> > > (do 
> > >   (println input) 
> > >   (recur) 
> > > ) 
> > >   )) 
> > > 
> > > -- 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > To post to this group, send email to clo...@googlegroups.com 
> > > Note that posts from new members are moderated - please be patient with 
> > your first post. 
> > > To unsubscribe from this group, send email to 
> > > clojure+u...@googlegroups.com  
> > > For more options, visit this group at 
> > > http://groups.google.com/group/clojure?hl=en 
> > > --- 
> > > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to clojure+u...@googlegroups.com . 
> > > For more options, visit https://groups.google.com/groups/opt_out. 
> > > 
> > -- 
> > 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 - pleas

Re: eclipse (counterclockwise) questions

[Mikera]

On c), it is worth noting that if you run the REPL in Eclipse's debug mode 
then you can change Java source code without restarting the REPL in many 
cases. It will do hot code reloading of Java method bodies just fine. The 
only thing you can't do is change method signatures, which requires a full 
JVM restart I think.

On Monday, 16 September 2013 01:13:21 UTC+8, Luc wrote:
>
> a) You test your code using the REPL window. In the bottom there's a user 
> input 
>  area were you can run Clojure expression interactively. 
>  The REPL panel has a couple of buttons in the top right corner. 
>  You can see the last exception, interrupt processing if it loops 
> forever, ... 
>
>  The console is used to look at detailed error messages from the 
> runtime 
>   like exceptions.   
>
> b) When editing a Clojure source file, you can load it in a REPL directly 
> by using either a shortcut ctrl->alt->s or through the 
> mouse-right-click -> Clojure 
> menu. Look at the shortcuts available. You can reload a name space 
> in a running REPL on the fly, redefine stuff through cursor selection, 
> change the current name space in the REPL to the one of the source 
> file 
> edited,  
>
> c) The time it takes to get the REPL alive can be significant depending on 
> your 
> hardware. The idea is to avoid restarting it as much as possible by 
> reloading name spaces or redefining fns, ... w/o shutting down your 
> current REPL. Beware that in some cases it's unavoidable like when 
> you alter the project class path or if you are modifying java source 
> code 
> part of your clojure project. The Java compilation will alter static 
> files 
> not the loaded code in the JVM supporting the REPL. 
>
> Can't help you much with the menu that vanished but if you work 
> within a clojure source file and not the other way around, you should be 
> able 
> to run it with the above indications. 
>
> Make sure that your project has it's Clojure nature enabled otherwise none 
> of 
> the Clojure shortcuts will appear in the editor context menu. 
>
> Luc 
> 
>
> >   
> > 
> > I'm learning clojure on eclipse (counterclockwise plugin). 
> > 
> >- When I click "run" in eclipse (as I would do with Java) I get not 
> only 
> >the console opened but this "REPL" window. Why is it necessary and 
> what 
> >does it do? 
> >- When I click "run" it takes quite a few seconds to launch the app. 
> Is 
> >there a way to make it faster? 
> >- When I need to edit the code and relaunch (run) the the app I'm 
> >getting this message: "The selection cannot be launched, and there 
> are no 
> >recent launches". What is that and why wouldn't it let me relaunch my 
> code? 
> >If I wait a while I can launch it again. 
> >- I was screwing around and I don't know what I did, but now "Run as" 
> -> 
> >"Clojure Application" option is gone. How do I get it back? 
> > 
> > This is simple bit of code that I'm trying to run: 
> > 
> > (ns ClojureTest.core) 
> > (let [input (read-line)] 
> >   (if (= "x" input) 
> > (do 
> >   (println "Exit") 
> >   (System/exit 0) 
> > ) 
> > (do 
> >   (println input) 
> >   (recur) 
> > ) 
> >   )) 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> -- 
> 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.

[ANN] manners - Yet another validation library built on using predicates properly

[Ryan McGowan]

It's my first library. I created it to assist with another project I have 
yet to release and because of some inspiration I got from reading Functional 
JavaScriptby
 
Fogus  though it is certainly not a port of his efforts 
there.  Anyway, there is a bunch more in the 
README. 
It is already published to clojars and can be included in your project by 
adding `[manners "0.1.0"]` to your dependencies.

I am very open to criticisms and improvements.

https://github.com/RyanMcG/manners

Thanks,

Ryan

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

[David Nolen]

1889 released, all changes are to make it easier to test the source map
functionality. I've blogged some basic instructions here
http://swannodette.github.io/2013/09/15/source-maps/

Feedback welcome!


On Sun, Sep 15, 2013 at 2:48 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> The biggest change in this release thanks to Sean Grove - much improved
> source maps. You can provide a :source-map option to the compiler to name
> the source map file. Feedback on this significant enhancement welcome.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-1885
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-1885"]
>
> *Enhancements: *
> * Accurate source maps!
>
> *Changes:*
> ** *cljs.core/format based on goog.string/format backed out
> * set-print-fn! no longer exported
>
> *Fixes:*
> ** *CLJS-588: allow upstream :foreign-libs to be used
>

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

[Shantanu Kumar]

Thanks for this significant release!

Will `format` make a comeback in a future release?

Shantanu

On Monday, 16 September 2013 00:18:46 UTC+5:30, David Nolen  wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> 
> The biggest change in this release thanks to Sean Grove - much improved 
> source maps. You can provide a :source-map option to the compiler to name the 
> source map file. Feedback on this significant enhancement welcome.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> New release version: 0.0-1885
> 
> 
> Leiningen dependency information:
> 
>     [org.clojure/clojurescript "0.0-1885"]
> 
> 
> 
> 
> Enhancements: 
> 
> * Accurate source maps!
> 
> 
> Changes:
> 
> * cljs.core/format based on goog.string/format backed out
> * set-print-fn! no longer exported
> 
> 
> 
> Fixes:
> * CLJS-588: allow upstream :foreign-libs to be used

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

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

The biggest change in this release thanks to Sean Grove - much improved
source maps. You can provide a :source-map option to the compiler to name
the source map file. Feedback on this significant enhancement welcome.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-1885

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1885"]

*Enhancements: *
* Accurate source maps!

*Changes:*
** *cljs.core/format based on goog.string/format backed out
* set-print-fn! no longer exported

*Fixes:*
** *CLJS-588: allow upstream :foreign-libs to be used

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

[Softaddicts]

a) You test your code using the REPL window. In the bottom there's a user input
 area were you can run Clojure expression interactively.
 The REPL panel has a couple of buttons in the top right corner.
 You can see the last exception, interrupt processing if it loops forever, 
...

 The console is used to look at detailed error messages from the runtime
  like exceptions.  

b) When editing a Clojure source file, you can load it in a REPL directly
by using either a shortcut ctrl->alt->s or through the mouse-right-click -> 
Clojure 
menu. Look at the shortcuts available. You can reload a name space
in a running REPL on the fly, redefine stuff through cursor selection, 
change the current name space in the REPL to the one of the source file
edited, 

c) The time it takes to get the REPL alive can be significant depending on your
hardware. The idea is to avoid restarting it as much as possible by
reloading name spaces or redefining fns, ... w/o shutting down your
current REPL. Beware that in some cases it's unavoidable like when
you alter the project class path or if you are modifying java source code
part of your clojure project. The Java compilation will alter static files
not the loaded code in the JVM supporting the REPL.

Can't help you much with the menu that vanished but if you work
within a clojure source file and not the other way around, you should be able
to run it with the above indications. 

Make sure that your project has it's Clojure nature enabled otherwise none of
the Clojure shortcuts will appear in the editor context menu.

Luc


>  
> 
> I'm learning clojure on eclipse (counterclockwise plugin).
> 
>- When I click "run" in eclipse (as I would do with Java) I get not only 
>the console opened but this "REPL" window. Why is it necessary and what 
>does it do?
>- When I click "run" it takes quite a few seconds to launch the app. Is 
>there a way to make it faster?
>- When I need to edit the code and relaunch (run) the the app I'm 
>getting this message: "The selection cannot be launched, and there are no 
>recent launches". What is that and why wouldn't it let me relaunch my 
> code? 
>If I wait a while I can launch it again.
>- I was screwing around and I don't know what I did, but now "Run as" -> 
>"Clojure Application" option is gone. How do I get it back?
>
> This is simple bit of code that I'm trying to run:
> 
> (ns ClojureTest.core)
> (let [input (read-line)]
>   (if (= "x" input)
> (do
>   (println "Exit")
>   (System/exit 0)
> )
> (do
>   (println input)
>   (recur)
> )
>   ))
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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: Clojure, floats, ints and OpenGL

[Mikera]

Hi Timothy,

Clearly, the "partial dynamic recompilation" feature depends on storing 
enough information to actually perform the recompile. You could store 
either the source, or some sort of transformed AST. There are many ways to 
make this kind of system work - at the REPL or otherwise (but I agree the 
main benefit would be in supporting dynamic REPL-based usage). I personally 
think the best solution would be to store raw source forms as function 
metadata, but happy to be convinced otherwise.

Incidentally, storing the source and/or AST could have various other 
beneficial uses - see e.g. this discussion from a few months 
back: https://groups.google.com/d/topic/clojure-dev/WvpqRUSH-y8/discussion 

I agree we'd want a prototype, but that's the wrong next step IMHO.

Ideally Rich (or some other "official" maintainer) should confirm that this 
is a direction we want to explore, otherwise there is little point taking 
the time to speculatively build a non-trivial prototype of functionality 
that might never be accepted. I'm certain there would be people with the 
skill, motivation and energy in the community to prototype and develop the 
feature, as long as it had official blessing (perhaps as some sort of 
Clojure 2.0 roadmap, if such a thing exists?). This sort of thing should 
probably also be coordinated with other efforts that touch upon related 
issues (core.typed, CinC, tools.analyzer etc.)

If there is genuine interest in this, I'm happy to write up a more detailed 
explanation / proposal of why it is valuable, how it might work and what 
the trade-offs would be. If it subsequently gets official approval on a 
Clojure roadmap, I'll be happy to contribute prototype work / patches (at 
least as far as my modest compiler-writing skills allow). Money where 
mouth is, and all that :-)


On Sunday, 15 September 2013 22:16:38 UTC+8, tbc++ wrote:
>
> How are you going to recompile at all, when the compiler doesn't store the 
> source code of functions after it compiles them? This is why this proposal 
> needs to have a working prototype, to prove that these ideas actually work, 
> until then proposals don't do much at all.  Personally I don't see how the 
> ideas in this proposal would work from the repl, and the repl is where most 
> people do their work.
> On Sep 14, 2013 10:55 PM, "Mikera" > 
> wrote:
>
>> On Saturday, 14 September 2013 01:04:16 UTC+8, tbc++ wrote:
>>
>>> >> This would be better, IMHO, than forever accepting semantics that 
>>> prevent idiomatic code from ever being truly fast.
>>>
>>> You're going to have a hard time convincing people to give up some of 
>>> the dynamism of Clojure just for the sake of more performance. Especially 
>>> considering that many Clojure users are perfectly okay with boxed values, 
>>> let alone need floats or other primitives.
>>>
>>
>> Let's be clear - I'm not asking anyone to give up on any dynamism. I am 
>> asking for an agreement that we want to allow high performance *options* in 
>> Clojure, so that we can at least match Scala/Java, for those use cases 
>> where people have genuine performance requirements. Some people don't care 
>> about performance enough for the distinction between float and double to 
>> matter. But others do.
>>
>> I think we (as a community) should try to support both use cases. Clojure 
>> has the potential to be *both* dynamic and fast if we design it right.
>>
>> It would be a shame if people in the community took a general stance that 
>> "performance is good enough for me, so we aren't interested in supporting 
>> further performance improvements". I'm sure that isn't what is intended, 
>> but it could appear like that to people who raise performance issues only 
>> to get challenged / told that they don't have a valid problem.
>>  
>>
>>>
>>> But what you are describing creates a whole ton of new problems, 
>>> problems I don't see a good solution for. What you are describing would 
>>> require the recompilation of entire source trees when a inner function is 
>>> modified. So now we're in the Scala/Java land of recompile after every 
>>> edit. Perhaps there's a use-case for invoke dynamic here, but now 
>>> you're talking about breaking backwards compatibility for everyone not 
>>> using Java 7+. 
>>>
>>
>> I'm not suggesting "recompile everything after edit". I'm suggesting 
>> "lazily recompile stuff that is dependent on the one thing you changed". 
>> That's a much smaller compilation unit in most cases - maybe you are 
>> recompiling 2-5 functions instead of 1. If you change something that is 
>> used everywhere in your whole app, then yes: maybe it's going to recompile 
>> 100 or so functions. But even then, I doubt it will be a significant 
>> compile time compared to Java/Scala land.
>>
>> And note that we're talking about incurring this cost only for people 
>> doing dynamic changes to existing vars. This isn't common production usage 
>> (if you are mutating production state, I would hope you are using s

Re: Clojure, floats, ints and OpenGL

[Mikera]

Hi Timothy,

Clearly, the "partial dynamic recompilation" feature depends on storing 
enough information to actually perform the recompile. You could store 
either the source, or some sort of transformed AST. There are many ways to 
make this kind of system work - at the REPL or otherwise (but I agree the 
main benefit would be in supporting dynamic REPL-based usage). I personally 
think the best solution would be to store raw source forms as function 
metadata, but happy to be convinced otherwise.

Incidentally, storing the source and/or AST could have various other 
beneficial uses - see e.g. this discussion from a few months 
back: https://groups.google.com/d/topic/clojure-dev/WvpqRUSH-y8/discussion 

I agree we'd want a prototype, but that's the wrong next step IMHO.

Ideally Rich (or some other "official" maintainer) should confirm that this 
is a direction we want to explore, otherwise there is little point taking 
the time to speculatively build a non-trivial prototype of functionality 
that might never be accepted. I'm certain there would be people with the 
skill, motivation and energy in the community to prototype and develop the 
feature, as long as it had official blessing (perhaps as some sort of 
Clojure 2.0 roadmap, if such a thing exists?). This sort of thing should 
probably also be coordinated with other efforts that touch upon related 
issues (core.typed, CinC, tools.analyzer etc.)

If there is genuine interest in this, I'm happy to write up a more detailed 
explanation / proposal of why it is valuable, how it might work and what 
the trade-offs would be. If it subsequently gets official approval on a 
Clojure roadmap, I'll be happy to contribute prototype work / patches (at 
least as far as my modest compiler-writing skills allow). Money where 
mouth is, and all that :-)


On Sunday, 15 September 2013 22:16:38 UTC+8, tbc++ wrote:
>
> How are you going to recompile at all, when the compiler doesn't store the 
> source code of functions after it compiles them? This is why this proposal 
> needs to have a working prototype, to prove that these ideas actually work, 
> until then proposals don't do much at all.  Personally I don't see how the 
> ideas in this proposal would work from the repl, and the repl is where most 
> people do their work.
> On Sep 14, 2013 10:55 PM, "Mikera" > 
> wrote:
>
>> On Saturday, 14 September 2013 01:04:16 UTC+8, tbc++ wrote:
>>
>>> >> This would be better, IMHO, than forever accepting semantics that 
>>> prevent idiomatic code from ever being truly fast.
>>>
>>> You're going to have a hard time convincing people to give up some of 
>>> the dynamism of Clojure just for the sake of more performance. Especially 
>>> considering that many Clojure users are perfectly okay with boxed values, 
>>> let alone need floats or other primitives.
>>>
>>
>> Let's be clear - I'm not asking anyone to give up on any dynamism. I am 
>> asking for an agreement that we want to allow high performance *options* in 
>> Clojure, so that we can at least match Scala/Java, for those use cases 
>> where people have genuine performance requirements. Some people don't care 
>> about performance enough for the distinction between float and double to 
>> matter. But others do.
>>
>> I think we (as a community) should try to support both use cases. Clojure 
>> has the potential to be *both* dynamic and fast if we design it right.
>>
>> It would be a shame if people in the community took a general stance that 
>> "performance is good enough for me, so we aren't interested in supporting 
>> further performance improvements". I'm sure that isn't what is intended, 
>> but it could appear like that to people who raise performance issues only 
>> to get challenged / told that they don't have a valid problem.
>>  
>>
>>>
>>> But what you are describing creates a whole ton of new problems, 
>>> problems I don't see a good solution for. What you are describing would 
>>> require the recompilation of entire source trees when a inner function is 
>>> modified. So now we're in the Scala/Java land of recompile after every 
>>> edit. Perhaps there's a use-case for invoke dynamic here, but now 
>>> you're talking about breaking backwards compatibility for everyone not 
>>> using Java 7+. 
>>>
>>
>> I'm not suggesting "recompile everything after edit". I'm suggesting 
>> "lazily recompile stuff that is dependent on the one thing you changed". 
>> That's a much smaller compilation unit in most cases - maybe you are 
>> recompiling 2-5 functions instead of 1. If you change something that is 
>> used everywhere in your whole app, then yes: maybe it's going to recompile 
>> 100 or so functions. But even then, I doubt it will be a significant 
>> compile time compared to Java/Scala land.
>>
>> And note that we're talking about incurring this cost only for people 
>> doing dynamic changes to existing vars. This isn't common production usage 
>> (if you are mutating production state, I would hope you are using s

eclipse (counterclockwise) questions

[Neverminder]

 

I'm learning clojure on eclipse (counterclockwise plugin).

   - When I click "run" in eclipse (as I would do with Java) I get not only 
   the console opened but this "REPL" window. Why is it necessary and what 
   does it do?
   - When I click "run" it takes quite a few seconds to launch the app. Is 
   there a way to make it faster?
   - When I need to edit the code and relaunch (run) the the app I'm 
   getting this message: "The selection cannot be launched, and there are no 
   recent launches". What is that and why wouldn't it let me relaunch my code? 
   If I wait a while I can launch it again.
   - I was screwing around and I don't know what I did, but now "Run as" -> 
   "Clojure Application" option is gone. How do I get it back?
   
This is simple bit of code that I'm trying to run:

(ns ClojureTest.core)
(let [input (read-line)]
  (if (= "x" input)
(do
  (println "Exit")
  (System/exit 0)
)
(do
  (println input)
  (recur)
)
  ))

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

[Angel Java Lopez]

I don't know how to play baseball, what a lineup is, etc...

But first idea to explore: genetic algorithm


On Sat, Sep 14, 2013 at 10:53 PM, Matthew Rocklin wrote:

> Perhaps a bit intense but this problem might lend itself to mixed integer
> linear programming.  MILP is a very broad formulation of optimization
> problems.  Optimal solution of MILP problems is NP-Hard but very mature
> software solutions exist.  I don't know what's out there in Clojure land
> for this but in Python the PuLP library offers idiomatic expression of MILP
> problems and connections to various open source solvers.  At the very least
> you may find their examples illuminating; MILP is a very powerful tool to
> have in your toolbox.
>
> http://pythonhosted.org/PuLP/
> http://pythonhosted.org/PuLP/CaseStudies/a_blending_problem.html
>
>
> On Friday, September 13, 2013 7:52:04 AM UTC-7, Mark Watson wrote:
>>
>> Hi, newish user here.
>>
>> I want to make an app that finds a simple, optimized, fantasy baseball
>> lineup.
>>
>> Each player has a cost associated with them, as well as the average
>> points per game they score, and position. For example: Mike
>> Napoli, 4600, 2.9, 1B
>>
>> You have to choose one of each position: catcher, pitcher, 1st base, 2nd
>> base, 3rd base, and shortstop. You also have to pick three outfielders. It
>> would be easy to just pick the players with the highest points per game,
>> but you also need to stay under a specified total cost.
>>
>> Currently, I iterate through every possibility, and swap an atom with a
>> new lineup if the total average points is higher, while staying under the
>> total cost limit.
>>
>> My issues are:
>>
>> 1) This seems like an inelegant solution (brute force)
>> 2) I don't know how to best handle the fact that I need to select three
>> outfielders from a single list, and cannot select one player more than once
>>
>> Any advice, suggestions would be great. Thanks!
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To 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: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

How are you going to recompile at all, when the compiler doesn't store the
source code of functions after it compiles them? This is why this proposal
needs to have a working prototype, to prove that these ideas actually work,
until then proposals don't do much at all.  Personally I don't see how the
ideas in this proposal would work from the repl, and the repl is where most
people do their work.
On Sep 14, 2013 10:55 PM, "Mikera"  wrote:

> On Saturday, 14 September 2013 01:04:16 UTC+8, tbc++ wrote:
>
>> >> This would be better, IMHO, than forever accepting semantics that
>> prevent idiomatic code from ever being truly fast.
>>
>> You're going to have a hard time convincing people to give up some of
>> the dynamism of Clojure just for the sake of more performance. Especially
>> considering that many Clojure users are perfectly okay with boxed values,
>> let alone need floats or other primitives.
>>
>
> Let's be clear - I'm not asking anyone to give up on any dynamism. I am
> asking for an agreement that we want to allow high performance *options* in
> Clojure, so that we can at least match Scala/Java, for those use cases
> where people have genuine performance requirements. Some people don't care
> about performance enough for the distinction between float and double to
> matter. But others do.
>
> I think we (as a community) should try to support both use cases. Clojure
> has the potential to be *both* dynamic and fast if we design it right.
>
> It would be a shame if people in the community took a general stance that
> "performance is good enough for me, so we aren't interested in supporting
> further performance improvements". I'm sure that isn't what is intended,
> but it could appear like that to people who raise performance issues only
> to get challenged / told that they don't have a valid problem.
>
>
>>
>> But what you are describing creates a whole ton of new problems, problems
>> I don't see a good solution for. What you are describing would require the
>> recompilation of entire source trees when a inner function is modified. So
>> now we're in the Scala/Java land of recompile after every edit. Perhaps
>> there's a use-case for invoke dynamic here, but now you're talking about
>> breaking backwards compatibility for everyone not using Java 7+.
>>
>
> I'm not suggesting "recompile everything after edit". I'm suggesting
> "lazily recompile stuff that is dependent on the one thing you changed".
> That's a much smaller compilation unit in most cases - maybe you are
> recompiling 2-5 functions instead of 1. If you change something that is
> used everywhere in your whole app, then yes: maybe it's going to recompile
> 100 or so functions. But even then, I doubt it will be a significant
> compile time compared to Java/Scala land.
>
> And note that we're talking about incurring this cost only for people
> doing dynamic changes to existing vars. This isn't common production usage
> (if you are mutating production state, I would hope you are using something
> with proper concurrency semantics like atoms or agents or refs to mutate
> data!). So performance probably shouldn't matter at all, apart from the
> subjective experience of compiling fast enough to be usable at the REPL.
> Which I'm pretty sure is a fairly easy target to hit.
>
> Like I said, this would be a big change, but it would be a good way to
> combine dynamism with excellent runtime performance.
>
>
>>
>> I'll be the first to admit that I'd like to rewrite the Clojure compiler
>> as a true multi-pass optimizing compiler. But that's a task I haven't
>> undertaken for two reasons 1) it's a ton of work that would take months (if
>> not years) to reach the level of performance currently offered by Clojure.
>> 2) I really don't need it. Every time I need that level of performance I
>> drop to Java, CUDA or some other high performance toolkit.
>>
>> Personally I think it would be much better for someone to come up with a
>> typed lisp that interops very cleanly with Clojure. That way you can build
>> your inner kernels using a lisp-like language, and then glue it together
>> with Clojure.
>>
>> But let me close by saying, if you really want better primitives, I'd
>> suggest writing up a proposal for how it would work, perhaps even with some
>> example using macros and genclass. Until then we don't have anything to go
>> off of, people say "I'd love to have feature X", well we all would, but all
>> the suggestions thus far won't work, so how do you plan on fixing that?
>>
>
> My pragmatic proposal for now is very simple: allow metadata to specify
> functions to be compiled in a way that invocation is compiled statically to
> an invokevirtual. You lose the dynamic var deref, but gain better runtime
> performance and the ability to use arbitrary types / primitives (which
> solves the OP's problem).
>
> This limited-scope proposal won't effect any existing dynamic usage, so
> people who like their fully mutable vars with their dynamic lookups can
> ke

Re: [ANN] modern-cljs tutorials updated

[Cedric Greevey]

On Sun, Sep 15, 2013 at 12:03 AM, Korny Sietsma  wrote:

> You know you're a lisp programmer when you feel conflicted about balancing
> parentheses around emoticons. (like this :)) (or like this :)
>
Since the emoticon is not a delimiter, however it's constructed out of more
primitive symbols, obviously the first version is the correct version. ;)

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

[Adrian Mowat]

Hi Folks

I wanted to promote a new site I have been rather hooked on for the past few 
weeks.

http://exercism.io is a crowd sourced/social coding practice site.  When you 
login, you can download an exercise and a test suite.  Once you have coded your 
best solution to the problem, you submit it back up to the site for people to 
nitpick.  You can also nitpick other people's submissions.

exercism.io is intended to be a conversation about what good code might look 
like. There's no right answer, and many good questions.

There are exercises in Clojure, Ruby, Elixir, JavaScript, Python and Haskell.

Hopefully you will find this useful too

Adrian 


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