Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by tlrobinson on Monday January 26, 2009 @04:37PM
(#451085)
"Lambdas are not garbage collected.
Yes. That means lambdas can be the cause of memory leaks.
As described by Charles Nutter, each lambda in Clojure is an anonymous class in Java. The problem is that classes are never garbage collected. They reside in a special place called the PermGen."
I know very little about Clojure, but that seems like a huge problem for Clojure, and other functional-ish JVM languages. Is it?
I've used Rhino (JavaScript on JVM) extensively, and I don't think it suffers from this.
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by GeoJawDguJin on Monday January 26, 2009 @10:17PM
(#451553)
Honestly, the JVM is pretty crappy right now for functional language support. A lot of stuff has to be implemented by hand in either the compiler or the program itself. Several features in Clojure take the latter track at the moment.
I advocate tracking down people from Sun and asking them in a personable, friendly tone of voice to please fix this kind of problem. On their front lawns.
Rich Hickey claims that the PermGen issue alleged in this article doesn't actually exist. A new class is created every time a (fn) is compiled, but only a new instance of that class is created each time it is invoked.
The only thing that generates a new class each time it is called is (eval), which as we all remember from reading our PG, is generally regarded as suspect when used in production code. Obviously you can see this effect at the Clojure REPL, however.
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by michaelneale on Monday January 26, 2009 @05:29PM
(#451200)
Yes the PermGen issue in general seems a major weakness of the "Sun" VM (now OpenJDK) - although its not an intractable problem - just an irritation.
It seems an out dated idea today to have a separate space/special rules for generated code versus the rest of the heap - I think other VMs like JRockit didn't do that and didn't have that issue.
Although - I think the class/classloader relationship is in the spec, so to allow easy GC of generated classes you need to have 1 to 1 with classloaders (I hear that all this is going to change anyway to reflect how people really use things).
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by Zak on Tuesday January 27, 2009 @02:07AM
(#451781)
Genetic programming generally won't appear in production code, though it might be used to generate production code. Using eval seems reasonable in the context of executing code generated by your program. I'd be interested in hearing about alternatives.
In response to this problem, Clojure now uses an ephemeral classloader. I don't know the JVM that well, but Rich Hickey says this means the anonymous classes generated by evaling fn forms can be collected.
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by michaelneale on Tuesday January 27, 2009 @07:12AM
(#452003)
if all the classes in the classloader are no longer referenced, and there are no references to the classloader itself, then they will all be GCed (but often there is a ref to the classloader that causes the PermGen issue).
Koza "invented" GP. However, parent article is really describing Evolutionary Programming, invented by Fogel in the 1960s. The difference? Ostensibly, no crossover operator in EP, only mutation.
Due to time constraints (I underestimated the time it would take to write a fast bitmap/polygon library) I only let those simulations run for ~1 hr each.
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by GeoJawDguJin on Monday January 26, 2009 @10:19PM
(#451555)
Someone should do Paul Graham, so he can write a new lisp dialect to write another program to evolve another version of Paul Graham to write a new lisp dialect to write another program to evolve another version of Paul Graham to write a new lisp dialect to write another program to evolve another version of Paul Graham to write a new lisp dialect to...
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by paulgb on Tuesday January 27, 2009 @12:28AM
(#451700)
In the informal algorithm description, it says "Create Children from the best programs by mating and mutating them". By mating, do you mean actually taking two (or more) "programs" and merging the contents? I looked over the code, but I don't know enough clojure to find any part that looked like it merged two programs.
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by nihilocrat on Monday January 26, 2009 @04:53PM
(#451109)
Make an editor which will randomly color-code each set of parentheses such that they or their background is in a set of colors which don't appear as other keywords (like function defs or strings or whatever) so as not to add confusion. You now have a way of more easily seeing every matching pair of parens without having to hover over each one. However, now you have to deal with a strange assortment of colors on your screen.
Oh wait, you can just use a gradient of colors instead of random ones, with the more-nested paren pairs having colors farther in on the gradient. Silly me.
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by riobard on Tuesday January 27, 2009 @06:50AM
(#451982)
"Oh wait, you can just use a gradient of colors instead of random ones, with the more-nested paren pairs having colors farther in on the gradient. Silly me."
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by jcl on Tuesday January 27, 2009 @10:54AM
(#452252)
"Logo is a computer programming language used for functional programming. It is an easier-to-read adaptation and dialect of the Lisp language; some have called it Lisp without the parentheses."
Re:Clojure: Genetic Mona Lisa problem in 250 beautiful lines
by ramchip on Monday January 26, 2009 @06:42PM
(#451284)
Parens let you have multiple expressions in one line, which indentation alone could not really express (except perhaps in a Haskell-like with currying, . and $ operators, etc).
For example, I don't see how (map (fn [x] (+ x 2)) (concat (take 5 my-series) etc...)) could be broken down with indentation alone without taking quite a few extra lines.
Yes. That means lambdas can be the cause of memory leaks.
As described by Charles Nutter, each lambda in Clojure is an anonymous class in Java. The problem is that classes are never garbage collected. They reside in a special place called the PermGen."
I know very little about Clojure, but that seems like a huge problem for Clojure, and other functional-ish JVM languages. Is it?
I've used Rhino (JavaScript on JVM) extensively, and I don't think it suffers from this.
The individual closures created as code executes are GC'ed like everything else.
Since eval is rather specialized, and everyone recommends it be avoided in "normal" code, this is not a major problem.
Plus, it is fixed.
- Comment from cgrand at the bottom of the article.
I advocate tracking down people from Sun and asking them in a personable, friendly tone of voice to please fix this kind of problem. On their front lawns.
http://markmail.org/message/axarlob7wwmnm2xe#query:clojure%2...
Rich Hickey claims that the PermGen issue alleged in this article doesn't actually exist. A new class is created every time a (fn) is compiled, but only a new instance of that class is created each time it is invoked.
The only thing that generates a new class each time it is called is (eval), which as we all remember from reading our PG, is generally regarded as suspect when used in production code. Obviously you can see this effect at the Clojure REPL, however.
It seems an out dated idea today to have a separate space/special rules for generated code versus the rest of the heap - I think other VMs like JRockit didn't do that and didn't have that issue.
Although - I think the class/classloader relationship is in the spec, so to allow easy GC of generated classes you need to have 1 to 1 with classloaders (I hear that all this is going to change anyway to reflect how people really use things).
In response to this problem, Clojure now uses an ephemeral classloader. I don't know the JVM that well, but Rich Hickey says this means the anonymous classes generated by evaling fn forms can be collected.
http://www.genetic-programming.com/coursemainpage.html
Koza "invented" GP. However, parent article is really describing Evolutionary Programming, invented by Fogel in the 1960s. The difference? Ostensibly, no crossover operator in EP, only mutation.
http://www.scholarpedia.org/article/Evolutionary_programming
The biggest portion of the code was the bitmap/image manipulation libraries. Excluding those, it was about the same size.
You can see my videos at: http://www.youtube.com/watch?v=S1ZPSbImvFE http://www.youtube.com/watch?v=-_VFZ_ON0A8 http://www.youtube.com/watch?v=VbyQomrJSeU
Due to time constraints (I underestimated the time it would take to write a fast bitmap/polygon library) I only let those simulations run for ~1 hr each.
Incidentally, now I want to learn clojure :).
I'm also working on genetic programming in Clojure, and with the PermGen fix in rev. 1232, it seems to be a great tool for the job.
I'm glad that got you interested in Clojure!
Has anyone thought about a Lisp dialect that uses white space, like Python, to get rid of the ()?
http://tinyurl.com/ct3xyb
http://www.dwheeler.com/readable/
Oh wait, you can just use a gradient of colors instead of random ones, with the more-nested paren pairs having colors farther in on the gradient. Silly me.
Good idea! Is it doable in VIM now? :|
http://en.wikipedia.org/wiki/Logo_programming_language
For example, I don't see how (map (fn [x] (+ x 2)) (concat (take 5 my-series) etc...)) could be broken down with indentation alone without taking quite a few extra lines.
http://en.wikipedia.org/wiki/Dylan_programming_language
Neat.
Credit and originality goes to : http://rogeralsing.com/2008/12/07/genetic-programming-evolut...
He was just using it as a demonstration of Clojure, nothing more.
Read the article before criticizing.