What is the good way of def-ing during macro expansion
Dear all, In my project, I need (in order to share constant trees in rule definitions), to define new variable during macro expansion. What I do currently: I keep all the constant definitions and the rules definitions in an atom and at the end, I call a macro at top level that define everything, in the dependency order. I don't like it very much, because it's ugly and because it forbid to create constants in a "normal" macro. Is there an idiomatic way to do that? Would the direct manipulation of namespaces in the macro be better? I mainly need it to work for compile-on-load, but if possible I would like a solution that works too for aot. Best, Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: chinese character in hiccup
> Perhaps Jetty add a charset of iso-8859-1 if there isn't one in response I think this behavior is specified in the servlet spec: "If no charset is specified, ISO-8859-1 will be used" http://download.oracle.com/docs/cd/E17802_01/products/products/servlet/2.5/docs/servlet-2_5-mr2/javax/servlet/ServletResponse.html -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN: form-dot-clj - HTML form validation and display
Form-dot-clj is library for handling the display and validation of
forms. It Supports HTML5 forms, javascript validation and plain HTML.
It should work with most methods of generating HTML.
http://github.com/alienscience/form-dot-clj
In the last 10 minutes I have also found a library called "pour" that
works in a similar way.
http://github.com/Kaali/pour
Form-dot-clj example:
(def-field username
[:maxlength 20]
[:pattern "[A-Za-z0-9]+" "Only alphanumeric characters please"])
(def-field email-address
[:email "Sorry, that style of email address is not supported"])
(def-form example
{:size 20 :required "Please fill this in"}
:username (textbox username)
:email(textbox email-address))
;; Use the following function to show the form when generating html
(show-controls example)
;; Use the following function to validate a post of this form
(on-post example params success-fn failure-fn)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: chinese character in hiccup
Then, if Ring doesn't care of the charset also, there is no one, suck as jetty, ring, compojure would take care of the charset except myself. There are many peopole come from all kinds of country or region who use ring, jetty and compojure. Let themselves set the right charset manually by wrap? I don't think that is a good idea. On 8月13日, 下午5时05分, ngocdaothanh wrote: > > Perhaps Jetty add a charset of iso-8859-1 if there isn't one in response > > I think this behavior is specified in the servlet spec: "If no charset > is specified, ISO-8859-1 will be > used"http://download.oracle.com/docs/cd/E17802_01/products/products/servle... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: chinese character in hiccup
One word, Why we would let Jetty set default charset to iso-8859-1, Why not Compojure can set the default charset to utf-8? Isn't utf8 a better choice? Is iso-8859 better than utf-8? On 8月13日, 下午5时05分, ngocdaothanh wrote: > > Perhaps Jetty add a charset of iso-8859-1 if there isn't one in response > > I think this behavior is specified in the servlet spec: "If no charset > is specified, ISO-8859-1 will be > used"http://download.oracle.com/docs/cd/E17802_01/products/products/servle... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: chinese character in hiccup
2010/8/13 limux : > Then, if Ring doesn't care of the charset also, there is no one, suck > as jetty, ring, compojure would take care of the charset except > myself. There are many peopole come from all kinds of country or > region who use ring, jetty and compojure. Let themselves set the right > charset manually by wrap? I don't think that is a good idea. Well, the charset could potentially be set to the default encoding of the JVM, but that might produce inconsistent results. If you develop of a JVM with a default encoding of X, but your production machine has a default encoding of Y, you'll run into problems. Another option is to have a default charset, such as UTF-8. I don't think Ring should have a default charset, because it's too "low level". But Compojure could be set up with a default charset. However, this won't help people who, say, use Shift-JIS. I think it would be worth adding some charset setting middleware to Ring, though, and perhaps document this behaviour. Github has new Wikis that I'd like to try out :) - James -- 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
More urgency for CinC & CLR given Oracle's lawsuit against Google?
Given Oracle's lawsuit against Google for its use of the JVM, is anyone else suddenly much more concerned about the states of Clojure in Clojure and CLR compatibility? I know the former is an important goal and also that the existence of the latter is due to heroic volunteer efforts on behalf of a small number of people. Frankly I've been sitting on the sidelines cheering the efforts on. But now I'm much more concerned about writing Clojure code that can only run as Oracle sees fit. I've got a small bit of code which needs OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of that? If it sounds like I'm stirring up FUD I apologize, it's not my intent. Oracle has its fiduciary responsibilities and the patent system is what it (sigh) is. Here's my ideal option: a production quality release of Clojure targeting the CLR before the first anniversary of SCOracle day (2010-08-12). This would have to be an organized effort since big meaty chunks like CinC are probably within scope of only a few Clojurians (i.e. not me). Just my personal opinion -- questions, comments, and corrections are welcome. Seth -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
I believe they do not sue over the JVM but over Dalvik. The OpenJDK is,I think, a bit protected frompatents by its license and the fact t has been distributed by the patents' owner. However, Clojure in Clojure and better support of other platforms would be great. On Fri, Aug 13, 2010 at 12:13 PM, Seth wrote: > Given Oracle's lawsuit against Google for its use of the JVM, is > anyone else suddenly much more concerned about the states of Clojure > in Clojure and CLR compatibility? I know the former is an important > goal and also that the existence of the latter is due to heroic > volunteer efforts on behalf of a small number of people. Frankly I've > been sitting on the sidelines cheering the efforts on. > > But now I'm much more concerned about writing Clojure code that can > only run as Oracle sees fit. I've got a small bit of code which needs > OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of > that? > > If it sounds like I'm stirring up FUD I apologize, it's not my intent. > Oracle has its fiduciary responsibilities and the patent system is > what it (sigh) is. > > Here's my ideal option: a production quality release of Clojure > targeting the CLR before the first anniversary of SCOracle day > (2010-08-12). This would have to be an organized effort since big > meaty chunks like CinC are probably within scope of only a few > Clojurians (i.e. not me). > > Just my personal opinion -- questions, comments, and corrections are > welcome. > > Seth > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: chinese character in hiccup
You are right that there should be such a middleware in Ring. On 8月13日, 下午6时40分, James Reeves wrote: > 2010/8/13 limux : > > > Then, if Ring doesn't care of the charset also, there is no one, suck > > as jetty, ring, compojure would take care of the charset except > > myself. There are many peopole come from all kinds of country or > > region who use ring, jetty and compojure. Let themselves set the right > > charset manually by wrap? I don't think that is a good idea. > > Well, the charset could potentially be set to the default encoding of > the JVM, but that might produce inconsistent results. If you develop > of a JVM with a default encoding of X, but your production machine has > a default encoding of Y, you'll run into problems. > > Another option is to have a default charset, such as UTF-8. I don't > think Ring should have a default charset, because it's too "low > level". But Compojure could be set up with a default charset. However, > this won't help people who, say, use Shift-JIS. > > I think it would be worth adding some charset setting middleware to > Ring, though, and perhaps document this behaviour. Github has new > Wikis that I'd like to try out :) > > - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
Clojure runnes manly on the JVM. Oracle ownes (or has the patents) why should anything change for clojure? As far as Dalvik goes. Why should Clojure care the lawsuit is about implementation details (as far as I understand) in the VM the basic working will be the same. Befor starting a real effort to support clojure on more VMs (not just CLR) we should finish Clojure in Clojure first. When Clojure is in Clojure as far as posible it will be mutch easier to support the CLR and others. Instead of splitting efforts know our goal should be Clojure in Clojure. On Aug 13, 1:40 pm, Nicolas Oury wrote: > I believe they do not sue over the JVM but over Dalvik. > The OpenJDK is,I think, a bit protected frompatents by its license and > the fact t has been distributed by the patents' owner. > > However, Clojure in Clojure and better support of other platforms > would be great. > > On Fri, Aug 13, 2010 at 12:13 PM, Seth wrote: > > Given Oracle's lawsuit against Google for its use of the JVM, is > > anyone else suddenly much more concerned about the states of Clojure > > in Clojure and CLR compatibility? I know the former is an important > > goal and also that the existence of the latter is due to heroic > > volunteer efforts on behalf of a small number of people. Frankly I've > > been sitting on the sidelines cheering the efforts on. > > > But now I'm much more concerned about writing Clojure code that can > > only run as Oracle sees fit. I've got a small bit of code which needs > > OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of > > that? > > > If it sounds like I'm stirring up FUD I apologize, it's not my intent. > > Oracle has its fiduciary responsibilities and the patent system is > > what it (sigh) is. > > > Here's my ideal option: a production quality release of Clojure > > targeting the CLR before the first anniversary of SCOracle day > > (2010-08-12). This would have to be an organized effort since big > > meaty chunks like CinC are probably within scope of only a few > > Clojurians (i.e. not me). > > > Just my personal opinion -- questions, comments, and corrections are > > welcome. > > > Seth > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: chinese character in hiccup
On 13 Aug 2010, at 11:40, James Reeves wrote: > I think it would be worth adding some charset setting middleware to > Ring, though, and perhaps document this behaviour. +1 -- character encoding is exactly the kind of thing one would want to set up application-wide. -Steve -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
On Aug 12, 2010, at 7:52 PM, Tim Daly wrote: I find that I'm horribly confused at this point about what a protocol "is". Can someone use some other comp. sci. terms to define this idea? I thought of them as Java interfaces with default methods but clearly I'm wrong. Coming from CL, the best analogy is that a protocol is a *named* set of generic functions that dispatch on the type of their first argument. When you define a protocol with foo/bar/baz methods you get generic functions in the protocol's namespace named foo/bar/baz. Unlike interfaces, protocols require no derivation. You can extend a protocol to a particular type by supplying a concrete map of method names to function objects (extend), *or* the code for same (extend- type), *or* by supplying definitions for the protocol methods inline in a deftype/defrecord. The latter *looks* a lot like implementing an interface, by design it is as easy to use, and might actually involve implementing an interface under the hood (but that is an implementation detail, enabled by the naming and first-arg dispatch restriction). Finally, from Java-land, you can get your type to extend a protocol by deriving from the protocol's corresponding interface. This is what seems to confuse people most, as if protocols are magic dynamic interfaces. They are not. They *sometimes* use interfaces in the implementation, but not always. At no point should one assume that because a type supports a protocol it 'isA' that protocol (or its interface). Protocols are not about inheritance and that is the key distinction vs interfaces. Hope that helps, Rich -- 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
cljr-record: what's the idiomatic way to create API to database?
Hi all, I'd like to build a clojure api to a mysql database. Have done this previously using ruby's ActiveRecord which makes this very easy. clj- record apparently provides the same kind of functionality. The clj-record README shows how to create an interface to a table (let's say "employees") with: (ns our-warehouse.employee (:require clj-record.boot)) (def db ...a clojure.contrib.sql db-spec...) (clj-record.core/init-model) As you see, the connection to the database is made within a namespace that is specific to one particular table. Is there an idiomatic way to: - create the connection first (namespace would be for *database* rather than *table*, so "our-warehouse* in the example above instead of "our-warehouse.employee") - create and initialize all the clj-record functions within that namespace? As there are a lot of tables (but the code for connecting to each very short): is it possible to do all those definitions in the same file? Or am I thinking too much using my ruby background? A small ruby example for 2 classes: ActiveRecord::Base.establish_connection( :adapter => "mysql", :host => "localhost", :username => "myuser", :password => "mypass", :database => "somedatabase" ) class Employee < ActiveRecord::Base belongs_to :company end class Company < ActiveRecord::Base has_many :employees end Any help/direction appreciated. Thanks, jan. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
On Fri, Aug 13, 2010 at 1:17 PM, Rich Hickey wrote: > not. They *sometimes* use interfaces in the implementation, but not always. > At no point should one assume that because a type supports a protocol it > 'isA' that protocol (or its interface). > That's very interesting. From a performance point of view, is there a penalty involved in being in a case where the implementation does not use interfaces? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: cljr-record: what's the idiomatic way to create API to database?
Hi, On 13 Aug., 14:51, jandot wrote: > The clj-record README shows how to create an interface to a table > (let's say "employees") with: > > (ns our-warehouse.employee > (:require clj-record.boot)) > > (def db ...a clojure.contrib.sql db-spec...) > > (clj-record.core/init-model) > > As you see, the connection to the database is made within a namespace > that is specific to one particular table. Is there an idiomatic way > to: > - create the connection first (namespace would be for *database* > rather than *table*, so "our-warehouse* in the example above instead > of "our-warehouse.employee") > - create and initialize all the clj-record functions within that > namespace? This is less a question of "idiomatic" than "interface to clj-record". clj-record to have a namespace per thing you define. If this is not what need, you may want to look at carte[1]. It also works with mysql and has a different interface, where what you need, should be easily possible. Sincerely Meikel [1]: http://github.com/brentonashworth/carte PS: > As there are a lot of tables (but the code for connecting to each very > short): is it possible to do all those definitions in the same file? It is, but you will run into trouble when you want to use require. (ns database.table1) (init-model ...) (ns database.table2) (init-model ...) All in one file. But as I said: you will run into trouble with require. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
Hi, On 13 Aug., 14:58, Nicolas Oury wrote: > That's very interesting. From a performance point of view, is there a > penalty involved in being in a case > where the implementation does not use interfaces? Using extend is slower, but more dynamic (read: mix-in via map merge vs. hard-wiring things with inline definition). Hmm... Is it possible to provide some methods inline in a defrecord, and some methods via extend? Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
On Fri, Aug 13, 2010 at 2:46 PM, Meikel Brandmeyer wrote: > Using extend is slower, but more dynamic (read: mix-in via map merge > vs. hard-wiring things with inline definition). > > Interesting... Is there a link explaining how it is implemented in the extend situation and how much slower it is? Cheers, Nicolas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
@rich What are your thoughts on the default implementation problem? On Aug 13, 2:17 pm, Rich Hickey wrote: > On Aug 12, 2010, at 7:52 PM, Tim Daly wrote: > > > I find that I'm horribly confused at this point about what a > > protocol "is". Can someone use some other comp. sci. terms to > > define this idea? I thought of them as Java interfaces with > > default methods but clearly I'm wrong. > > Coming from CL, the best analogy is that a protocol is a *named* set > of generic functions that dispatch on the type of their first > argument. When you define a protocol with foo/bar/baz methods you get > generic functions in the protocol's namespace named foo/bar/baz. > > Unlike interfaces, protocols require no derivation. You can extend a > protocol to a particular type by supplying a concrete map of method > names to function objects (extend), *or* the code for same (extend- > type), *or* by supplying definitions for the protocol methods inline > in a deftype/defrecord. The latter *looks* a lot like implementing an > interface, by design it is as easy to use, and might actually involve > implementing an interface under the hood (but that is an > implementation detail, enabled by the naming and first-arg dispatch > restriction). > > Finally, from Java-land, you can get your type to extend a protocol by > deriving from the protocol's corresponding interface. This is what > seems to confuse people most, as if protocols are magic dynamic > interfaces. They are not. They *sometimes* use interfaces in the > implementation, but not always. At no point should one assume that > because a type supports a protocol it 'isA' that protocol (or its > interface). > > Protocols are not about inheritance and that is the key distinction vs > interfaces. > > Hope that helps, > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Resource cleanup when lazy sequences are finalized
Any interest in moving this to clojure-contrib? It seems like a pretty useful facility to have for a language like clojure that relies so heavily on lazy sequences. Also, it's an easy way to implement a pretty common parallel programming pattern, two threads communicating through a buffered queue. On Aug 5, 5:59 pm, David Andrews wrote: > On Aug 3, 5:28 pm, Jeff Palmucci wrote: > > > See my library athttp://github.com/jpalmucci/clj-yield, which makes > > this trivial. > > This looks really nice, Jeff. Thanks. Exactly what I was looking > for. > > I notice that the garbage-monitor deftype yields a classname error in > IBM Java6. I renamed it to garbage_monitor and all seems copacetic. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What's a single-segment namespace and why should it be avoided?
On Aug 12, 2:09 pm, Meikel Brandmeyer wrote: > it's for technical reasons. Clojure wll then generate classes without > a package, which causes them to be put in the default package. There > are problems/restrictions/issues with classes in the default package. > I'm not a JVM expert, so someone else might provide more details. I > just go with the "JVM doesn't like it. Don't do it." You can't call anything in the default package from a regular package. But I think (ns foo) would compile into a foo package, so this wouldn't be a problem. Adam -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What's a single-segment namespace and why should it be avoided?
Thanks for responding. I'm glad to know this is about technical limitations rather than some preference for deeper namespace hierarchies. On Aug 12, 2:42 pm, Armando Blancas wrote: > The Java compiler doesn't like it; it won't import it from other > packages. The JVM won't mind. When Clojure code is the consumer, or > with use/require Clojure libs, one-segment namespaces work fine. I > keep a lot of those for test/hacks/trying things out, aot compiled and > not. > > On Aug 12, 5:09 am, Meikel Brandmeyer wrote: > > > > > Hi, > > > it's for technical reasons. Clojure wll then generate classes without > > a package, which causes them to be put in the default package. There > > are problems/restrictions/issues with classes in the default package. > > I'm not a JVM expert, so someone else might provide more details. I > > just go with the "JVM doesn't like it. Don't do it." > > > Sincerely > > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
On Aug 13, 3:38 am, Stuart Halloway wrote: > > Stu, (or anybody) I'd like to ask about a variation on this > > point. How do you handle the case where you have a general > > function that works for every type you'd like to implement a > > protocol for (thus not technically needing to be in a protocol), > > but maybe 1 or 2 of the many types have more efficient > > implementations possible? Do you just suck it up and copy and > > paste the general function around? Or is there a better way? Maybe > > the new case function? > > This might be a job for a more granular protocol. Take a look at how > granular Clojure's implementation abstractions are (even prior to > the introduction of protocols). The Java interfaces often have 0, 1, > or 2 methods. The scenario I'm thinking of is when you've already published a protocol, and now want to extend it. Instead, you could just create a new (granular) protocol, but that does seem to lead inexorably to the IFoo, IFoo2, IFoo3, situation. A more concrete example: say I've defined a protocol for AST nodes in 1.0 of a library, and later when developing 2.0 I discover it would have been a good idea to have a "pretty-print" method on nodes to show human-readable output. If the protocol had Trait-like characteristics I could add pretty-print to the protocol, with a default implementation that just prints the fields of the node, but override that with a better implementation for some of the new record types I'm including in 2.0. But I can't do that because, unless I've had the foresight to make sure clients always mix in a base set of (partial) defaults that I provide (which may be initially empty), then things break down. Sean Devlin's ideas (referenced earlier on the thread) on making it easy to mix in defaults would be great for this, but they don't really address the issue I'm looking at here. Following Stuart's suggestion, I *could* just add a protocol called "PrettyPrintable" with one method and implement it on some of the new node types, but now I can't just call "pretty-print" on any node: I need to write another function that checks if it's a PrettyPrintable first and calls something default if not. I've had to do this sort of thing many, many times in Java: one of the reasons I got excited about multimethods in Clojure is that they allow me to transparently extend the system after the fact with no such ugliness. Thanks to the superpower that is macro, I'm sure I could make a defprotocol+ and a extend+ that do this, just wanted to check that there's really no better way. Cheers, Matthew. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN: Lambdebug, A stepping debugger for the REPL
Hi, this is my attempt to enter the Clojure debugger market :) Feedbacks are welcome, and thanks to Kotka for his comment on the previous version. You can find it at http://lambdebug.github.com Adam -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What is the good way of def-ing during macro expansion
Hi Nicolas, > What I do currently: > I keep all the constant definitions and the rules definitions in an > atom and at the end, I call a macro at top level that define > everything, in the dependency order. Would you mind posting an example of this? That would definitely help me to better understand your approach. Thanks, Evan -- 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
Game development in Clojure
Hello all,
I've recently been working on a game development project in Clojure
which is now starting to bear fruit. I thought people here might be
interested, and that it would be worthwhile to share some experiences
and perspectives.
The project is a steampunk-themed strategy game, and a playable in-
development version is available here:
http://mikera.net/ironclad/
Overall, I think Clojure is a fantastic language for game development.
Some thought on what makes it really compelling:
1. Immutable data structures work surprisingly well for games. I
represent the entire game state with a big defrecord, and the main
engine loop is basically:
a) Get commands from player / AI (e.g. "Move unit from A to B")
b) Convert each command into set of atomic updates ("Remove unit
from A", "Add unit to B")
c) Apply updates sequentially to the game state
d) Trigger any feedback to player e.g. animations, sounds
2. Concurrency support has been very helpful. With immutable game
state, it has been trivial to separate the game engine from the
renderer from the AI calculations - each effectively gets to operate
on its own "snapshot" of the entire game state. This can be a big
headache in many game engines that have to mediate access to a single,
mutable game state. I can also see even greater benefits when I
finally start adding some multi-player features.
3. High level, functional programming works great for rapid, iterative
and dynamic development. Of all the languages I've used, Clojure has
probably been quickest in terms of time required to add a given new
piece of functionality. For example, the map generator code probably
only took about 30 minutes to write, pretty good for a fractal
landscape generation system!
4. The Java interoperability support is fantastic - definitely counts
as one of the "killer features" of Clojure. I've been able to reuse a
lot of Java code libraries, both my own and standard libraries such as
Swing. As an example, I have a well optimised immutable persistent 2D
grid data structure in Java (basically a very efficient, spatially
partitioned map from (int,int) to Object) that I have been able to use
pretty much seamlessly in Clojure thanks to extend-protocol and
similar.
Some interesting observations / discoveries / surprises in the
process:
1. The game worked first time on Mac and Linux, despite having been
tested exclusively on Windows. Great kudos to to both the Java
platform and the Clojure libraries!
2. Reflection is *really slow*. After getting 20-100x speedups from
eliminating reflection warnings in the AI code, I now treat any
reflection warning in code other than one-time setup code as a bug to
be fixed immediately.
Finally, here are some things I think could be great improvements to
Clojure in the future from a game developer's perspective:
1. Better support for primitive parameters / return values / unchecked
arithmetic - in performance sensitive code, these are pretty much
essential. In a few cases in the graphics and AI code, I've had to
drop back to Java to get the performance I need.
2. It would be great to reduce the amount of memory allocations. Yes,
I know memory is plentiful and GC is very cheap, but it's still not as
cheap as stack allocation and any noticeable GC pauses are not good
for the player experience in interactive games. For this reason, I
find myself using reduce and indexed loops a lot more than I guess
would normally be idiomatic, and conversely tend to avoid some of the
lazy constructs and functions that generate sequences. While Clojure
is great for a strategy game, I'd probably hesitate to use it for a
real-time 3D game.
3. I think it would be great to have better support for circular
references - perhaps a two-pass compile? The reason this is
particularly acute in game development is that different subsystems
have quite a lot of inter-dependencies. AI evaluation system needs to
understand game state/engine so it can evaluate a position. Game state/
engine needs to understand units so it can manipulate them. Units need
to understand AI evaluation system so they can decide which actions to
take.. obviously it's possible to work around all this, but it's a
major pain, adds complexity and means that you need to structure code
to manage dependencies rather than in logical modules (which would be
easier to manage and maintain!)
Would love to hear thoughts, and particularly any other experiences
people have had in using Clojure for game development!
Mike.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
> Following Stuart's suggestion, I *could* just add a protocol called > "PrettyPrintable" with one method and implement it on some of the new > node types, but now I can't just call "pretty-print" on any node: I > need to write another function that checks if it's a PrettyPrintable > first and calls something default if not. You can just extend PrettyPrintable to Object. Stu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
On Aug 13, 9:51 am, Mike Anderson wrote: > 2. It would be great to reduce the amount of memory allocations. Yes, > I know memory is plentiful and GC is very cheap, but it's still not as > cheap as stack allocation and any noticeable GC pauses are not good > for the player experience in interactive games. For this reason, I > find myself using reduce and indexed loops a lot more than I guess > would normally be idiomatic, and conversely tend to avoid some of the > lazy constructs and functions that generate sequences. While Clojure > is great for a strategy game, I'd probably hesitate to use it for a > real-time 3D game. There really is no way around this. We preallocate space for all our OpenGL vertex, as well as all the FSM for the AI engine. This is something we do even in our C++ code. We avoid creating objects whenever possible, and preallocate at init time. This is especially true in devices with smaller footprint like console/iphone/android, etc. Having said that, for prototyping OpenGL realtime 3d stuff on our desktop, clojure has been ok. > 3. I think it would be great to have better support for circular > references - perhaps a two-pass compile? The reason this is > particularly acute in game development is that different subsystems > have quite a lot of inter-dependencies. AI evaluation system needs to > understand game state/engine so it can evaluate a position. Game state/ > engine needs to understand units so it can manipulate them. Units need > to understand AI evaluation system so they can decide which actions to > take.. obviously it's possible to work around all this, but it's a > major pain, adds complexity and means that you need to structure code > to manage dependencies rather than in logical modules (which would be > easier to manage and maintain!) I'm not sure what you mean by this, can you expand on this? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
On Aug 13, 2010, at 13:13 , Seth wrote: > Given Oracle's lawsuit against Google for its use of the JVM, is > anyone else suddenly much more concerned about the states of Clojure > in Clojure and CLR compatibility? As far as I understand those things are absolutely not related, oracle isn't suing because they use the JVM but because they are not and rolling their 'own JVM' which, so claims Oracle, violates some of 'their' patents. Clojure on the other hand is simply using the JVM, as Oracle provides it, and the interfaces they provide, something they of cause will not sue over as it is a entirely different thing. Also this while 'oracle sues' panic is kind of sad :( Regards, Heinz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
On Fri, Aug 13, 2010 at 7:13 AM, Seth wrote: > Given Oracle's lawsuit against Google for its use of the JVM, is > anyone else suddenly much more concerned about the states of Clojure > in Clojure and CLR compatibility? I know the former is an important > goal and also that the existence of the latter is due to heroic > volunteer efforts on behalf of a small number of people. Frankly I've > been sitting on the sidelines cheering the efforts on. > > But now I'm much more concerned about writing Clojure code that can > only run as Oracle sees fit. I've got a small bit of code which needs > OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of > that? > > As the good book says: DON'T PANIC. IANAL, but I don't think this lawsuit has any bearing on Clojure at all. The crux of the lawsuit, as I understand it, is that Google is shipping a non-conforming Java platform with their Android- and since it's non-conforming, the guarantees Sun gave out (and Oracle is still bound by) about not requiring patent licenses for conforming platforms don't apply, so Google needs a license. What I expect to happen is a couple of months of legal maneuvering, followed by Google cutting Oracle a check with a fair number of zeros, and the whole thing going away. Worse case, the Android handset makes all have to cut checks as well. But note- what Google did that opened itself up for this lawsuit was shipping a non-conforming Java implementation. Clojure isn't shipping a Java implementation at all, conforming or not, so the whole issue is moot. Note that the CLR has all the same patent problems as the JVM- just substitute "Microsoft" for "Oracle". So switching to the CLR doesn't help (to the extent that there is a problem at all). Patents are a problem for software developers, in that you never know what patents you might be violating or who might sue you. But again, this has nothing to do with what language you implement things in. So relax. Breathe deep, pop some popcorn, and settle in to your comfy chair to watch the legal donnybrook. Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What's a single-segment namespace and why should it be avoided?
Hi, Am 12.08.2010 um 21:48 schrieb Adam Schmideg: > You can't call anything in the default package from a regular > package. But I think (ns foo) would compile into a foo package, so > this wouldn't be a problem. No. It compiles to something like foo__init.class, which lives in the default package. The function contained in the namespace will be in the package foo, though. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
I think it is all just posturing and gamesmanship, and will get settled by Google paying some sort of fee. Unless Google can buy someone with patents that Oracle is infringing then they can cross license. The only two implications I can think of are (1) Hardly helpful for people's confidence in the Java Platform, if Oracle embarks on these kind of surprise antics. May push people towards CLR. If Oracle start getting aggressive, then everyone will start worrying who they will attack next. (2) As Dalvik is based on Harmony and Harmony is techically non conforming (as they have never licensed the TCK) does this have any implications for Harmony. Although I don't use Harmony, it is nice to know its there as if Oracle un-open source Java (like they are doing with Solaris) then Harmony is my fallback option. On Aug 13, 5:29 pm, Brian Hurt wrote: > On Fri, Aug 13, 2010 at 7:13 AM, Seth wrote: > > Given Oracle's lawsuit against Google for its use of the JVM, is > > anyone else suddenly much more concerned about the states of Clojure > > in Clojure and CLR compatibility? I know the former is an important > > goal and also that the existence of the latter is due to heroic > > volunteer efforts on behalf of a small number of people. Frankly I've > > been sitting on the sidelines cheering the efforts on. > > > But now I'm much more concerned about writing Clojure code that can > > only run as Oracle sees fit. I've got a small bit of code which needs > > OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of > > that? > > As the good book says: DON'T PANIC. > > IANAL, but I don't think this lawsuit has any bearing on Clojure at all. > The crux of the lawsuit, as I understand it, is that Google is shipping a > non-conforming Java platform with their Android- and since it's > non-conforming, the guarantees Sun gave out (and Oracle is still bound by) > about not requiring patent licenses for conforming platforms don't apply, so > Google needs a license. What I expect to happen is a couple of months of > legal maneuvering, followed by Google cutting Oracle a check with a fair > number of zeros, and the whole thing going away. Worse case, the Android > handset makes all have to cut checks as well. But note- what Google did > that opened itself up for this lawsuit was shipping a non-conforming Java > implementation. Clojure isn't shipping a Java implementation at all, > conforming or not, so the whole issue is moot. > > Note that the CLR has all the same patent problems as the JVM- just > substitute "Microsoft" for "Oracle". So switching to the CLR doesn't help > (to the extent that there is a problem at all). > > Patents are a problem for software developers, in that you never know what > patents you might be violating or who might sue you. But again, this has > nothing to do with what language you implement things in. > > So relax. Breathe deep, pop some popcorn, and settle in to your comfy chair > to watch the legal donnybrook. > > Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Resource cleanup when lazy sequences are finalized
Easy enough to use via lein (thanks for uploading it to clojars BTW). I think it deserves a place in cc. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
On Aug 13, 6:51 am, Mike Anderson wrote: > Hello all, > > I've recently been working on a game development project in Clojure > which is now starting to bear fruit. I thought people here might be > interested, and that it would be worthwhile to share some experiences > and perspectives. > Looks great. Thanks for sharing your experiences. Do you plan to share the source code? Any reason you went with Swing instead of OpenGL? --Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
On Aug 13, 11:32 am, Quzanti wrote: > > The only two implications I can think o > (1) Hardly helpful for people's confidence in the Java Platform, if > Oracle embarks on these kind of surprise antics. May push people > towards CLR. If Oracle start getting aggressive, then everyone will > start worrying who they will attack next. That's the issue. Gosling has mentioned that during management meetings in the wake of the Oracle acquisition of Sun, the Oracle attorneys were salivating over JVM licensing; the issue is Oracle seeing such lawsuits as an attractive revenue stream, and what effect that will have on the Java market for the long term. In the short term, the java market is huge in the server space, and it looks promising in the mobile space. In the desktop client space it's essentially dead because Sun killed it by suing Microsoft over a noncompliant implementation. What Sun got out of that suit was a nice short-term benefit (a lot of cash from the settlement), and a major long-term loss, as Microsoft replaced their nonconformant JVM with a new VM and source language that were just different enough to be invulnerable to additional suits. Oh, and a thriving desktop client market in which Java participates not at all. The concern is that, if Oracle sees lawsuits over technical noncompliance as an attractive revenue stream, then they'll go about suing everyone with deep pockets who has any involvement with Java, with more or less the same effect that the Sun suit against Microsoft had--or at least sowing enough anxiety and confusion to have a chilling effect on the Java market, and making the JVM look less attractive as a platform. Again, in the short term it's unlikely to have much effect, because the existing Java ecology is so large and rich. The long term is more of a crapshoot, though, and the uncertainty there certainly makes it a good idea to make Clojure as able as possible to survive independent of any particular VM. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
I assumed he didn't use OpenGL because it's a 2d tile game? Using OpenGL for 2d or 2.5d (isometric) is really only a good idea if you can assume the target has hardware OpenGL acceleration. Even then you may not want to do that, due to battery concerns. On Fri, Aug 13, 2010 at 2:06 PM, Brian Carper wrote: > Do you plan to share the source code? Any reason you went with Swing > instead of OpenGL? > -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What is the good way of def-ing during macro expansion
No problem Evan, (def constants (atom ())) (defn add-constant [name x] (let [sym (gensym name)] (reset! constants (cons ([sym x]) @constants) sym )) Then when I produce code, I call add-constant and use the returned symbol. (I only use it to produce new constants, which is the annoying part. However, constants can be function) At the end I call (defmacro emit-all [] `(do ~@(reduce (fn [l [sym definition] ] (cons `(def ~sym ~definition) l) () @constants ) That's ugly and I would like to find better. Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
On Fri, Aug 13, 2010 at 2:51 PM, Mike Anderson wrote: > 2. It would be great to reduce the amount of memory allocations. Yes, > I know memory is plentiful and GC is very cheap, but it's still not as > cheap as stack allocation and any noticeable GC pauses are not good > for the player experience in interactive games. For this reason, I > find myself using reduce and indexed loops a lot more than I guess > would normally be idiomatic, and conversely tend to avoid some of the > lazy constructs and functions that generate sequences. While Clojure > is great for a strategy game, I'd probably hesitate to use it for a > real-time 3D game. > This can be made a bit better by turning Escape Analysis on? Have you tried that? The G1 collector is supposed to have lower latency. Have you tried it? http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: form-dot-clj - HTML form validation and display
Thanks for sharing, I will be trying out your lib. I am doing some web
thing.
Emeka
On Fri, Aug 13, 2010 at 10:11 AM, Saul Hazledine wrote:
> Form-dot-clj is library for handling the display and validation of
> forms. It Supports HTML5 forms, javascript validation and plain HTML.
> It should work with most methods of generating HTML.
>
> http://github.com/alienscience/form-dot-clj
>
> In the last 10 minutes I have also found a library called "pour" that
> works in a similar way.
>
> http://github.com/Kaali/pour
>
> Form-dot-clj example:
>
> (def-field username
> [:maxlength 20]
> [:pattern "[A-Za-z0-9]+" "Only alphanumeric characters please"])
>
> (def-field email-address
> [:email "Sorry, that style of email address is not supported"])
>
> (def-form example
> {:size 20 :required "Please fill this in"}
> :username (textbox username)
> :email(textbox email-address))
>
> ;; Use the following function to show the form when generating html
> (show-controls example)
>
> ;; Use the following function to validate a post of this form
> (on-post example params success-fn failure-fn)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Protocols and default method implementations
> A more concrete example: say I've defined a protocol for AST nodes in > 1.0 of a library, and later when developing 2.0 I discover it would > have been a good idea to have a "pretty-print" method on nodes to show > human-readable output. If the protocol had Trait-like characteristics > I could add pretty-print to the protocol, with a default > implementation that just prints the fields of the node, but override > that with a better implementation for some of the new record types I'm > including in 2.0. Is this because you've got Java clients coding against your interfaces? In Clojure I'd like to do something like: (doseq [node (walk-tree)] (pretty-print node)) and have it work regardless of how each node is made. I'd expect (pretty-print) to do more work if it can't just do (.pretty-print node), but client code need not be affected and the API need not be versioned in the sense IFoo, IFoo2, etc. That is, I'd think that custom Clojure libraries would be modeled after the sequence library and use protocol/types as implementation details, unless it's a "Java API" done in Clojure (which I anticipate doing myself actually). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
> This can be made a bit better by turning Escape Analysis on? Have you > tried that? > > The G1 collector is supposed to have lower latency. Have you tried it? > > http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf (GC choice/tuning is a lng story, but some select suggestions follow) First off, make sure you're at least using CMS (-XX:+UseConcMarkSweepGC) or G1 at all to begin with - the default collector is the throughput collector which will always do full GC:s of the old generation so that you are guaranteed to get pause times that scale linearly with heap size (unless you're generating *zero* non-young garbage). With CMS, you can force shorter young generation pauses by limiting the size of the young generation (usually at the cost of more GC work in total; i.e., less throughput, because the older generation is more expensive to collect). I'm not sure at all how much control over VM options you have with Java WebStart though, but in general that would be my suggestion if the young generation pauses are too long. -XX:NewSize=SIZE and -XX:MaxNewSize=SIZE should be your friend here (and -XX:+UseParNewGC though I think that is always the default on modern VM:s anyway on multi-core machines). I'm making the assumption here that the allocation pattern is not such that the concurrent mark/sweep:s are the problem. With G1, you can directly specify target pause times that G1 tends to be pretty good at maintaining in my experience. A recurring issue for me and at least some others seems to be that your application may have a workload that disallows certain memory regions to be collected within the pause time goal; this can lead to a build-up of uncollectable regions that may eventually cause a fallback to a full stop-the-world GC. The likelyhood of this happening is higher the lower the pause time goal you specify. An starter command line to play with (preferably with jdk 1.7) might be: -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=15 -XX:GCPauseIntervalMillis=20 -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
Funny you should mention this - I was about to post a question about
my own game when I saw your article. My issue is, I assume someone has
written minimax and/or alpha-beta pruning in Clojure (or a java
library that's easy to interop with). My case is slightly different in
that the turn order is not fixes - sometimes player X goes twice in a
row - but it ought to be pretty simple to plug into a standard AI
library. Does anyone know where I can find such a thing?
On Aug 13, 6:51 am, Mike Anderson
wrote:
> Hello all,
>
> I've recently been working on a game development project in Clojure
> which is now starting to bear fruit. I thought people here might be
> interested, and that it would be worthwhile to share some experiences
> and perspectives.
>
> The project is a steampunk-themed strategy game, and a playable in-
> development version is available here:
>
> http://mikera.net/ironclad/
>
> Overall, I think Clojure is a fantastic language for game development.
> Some thought on what makes it really compelling:
>
> 1. Immutable data structures work surprisingly well for games. I
> represent the entire game state with a big defrecord, and the main
> engine loop is basically:
> a) Get commands from player / AI (e.g. "Move unit from A to B")
> b) Convert each command into set of atomic updates ("Remove unit
> from A", "Add unit to B")
> c) Apply updates sequentially to the game state
> d) Trigger any feedback to player e.g. animations, sounds
>
> 2. Concurrency support has been very helpful. With immutable game
> state, it has been trivial to separate the game engine from the
> renderer from the AI calculations - each effectively gets to operate
> on its own "snapshot" of the entire game state. This can be a big
> headache in many game engines that have to mediate access to a single,
> mutable game state. I can also see even greater benefits when I
> finally start adding some multi-player features.
>
> 3. High level, functional programming works great for rapid, iterative
> and dynamic development. Of all the languages I've used, Clojure has
> probably been quickest in terms of time required to add a given new
> piece of functionality. For example, the map generator code probably
> only took about 30 minutes to write, pretty good for a fractal
> landscape generation system!
>
> 4. The Java interoperability support is fantastic - definitely counts
> as one of the "killer features" of Clojure. I've been able to reuse a
> lot of Java code libraries, both my own and standard libraries such as
> Swing. As an example, I have a well optimised immutable persistent 2D
> grid data structure in Java (basically a very efficient, spatially
> partitioned map from (int,int) to Object) that I have been able to use
> pretty much seamlessly in Clojure thanks to extend-protocol and
> similar.
>
> Some interesting observations / discoveries / surprises in the
> process:
>
> 1. The game worked first time on Mac and Linux, despite having been
> tested exclusively on Windows. Great kudos to to both the Java
> platform and the Clojure libraries!
>
> 2. Reflection is *really slow*. After getting 20-100x speedups from
> eliminating reflection warnings in the AI code, I now treat any
> reflection warning in code other than one-time setup code as a bug to
> be fixed immediately.
>
> Finally, here are some things I think could be great improvements to
> Clojure in the future from a game developer's perspective:
>
> 1. Better support for primitive parameters / return values / unchecked
> arithmetic - in performance sensitive code, these are pretty much
> essential. In a few cases in the graphics and AI code, I've had to
> drop back to Java to get the performance I need.
>
> 2. It would be great to reduce the amount of memory allocations. Yes,
> I know memory is plentiful and GC is very cheap, but it's still not as
> cheap as stack allocation and any noticeable GC pauses are not good
> for the player experience in interactive games. For this reason, I
> find myself using reduce and indexed loops a lot more than I guess
> would normally be idiomatic, and conversely tend to avoid some of the
> lazy constructs and functions that generate sequences. While Clojure
> is great for a strategy game, I'd probably hesitate to use it for a
> real-time 3D game.
>
> 3. I think it would be great to have better support for circular
> references - perhaps a two-pass compile? The reason this is
> particularly acute in game development is that different subsystems
> have quite a lot of inter-dependencies. AI evaluation system needs to
> understand game state/engine so it can evaluate a position. Game state/
> engine needs to understand units so it can manipulate them. Units need
> to understand AI evaluation system so they can decide which actions to
> take.. obviously it's possible to work around all this, but it's a
> major pain, adds complexity and means that you need to structure code
> to manage dependencies rather than in logical modul
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
CLR also infringes Oracle's patents and the only reason why Oracle is not likely to sue Microsoft is that Microsoft could do the same to Oracle. See http://jonathanischwartz.wordpress.com/2010/03/09/good-artists-copy-great-artists-steal/ Mono - the open source implementation of .NET also has uncertain legal status. I doubt it is possible to create runtime like JVM or CLR without patent problems. -- Mikhail -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
Paradigms of artificial intelligence programming: case studies in Common LISP
By Peter Norvig has a full chapter on this (ch18),
complete with code in Common LISP.
his "Artificial Intelligence: A Modern Approach" is also a good book
if you are interested in game AI. 3rd edition just came out recently
On Fri, Aug 13, 2010 at 12:33 PM, Alan wrote:
> Funny you should mention this - I was about to post a question about
> my own game when I saw your article. My issue is, I assume someone has
> written minimax and/or alpha-beta pruning in Clojure (or a java
> library that's easy to interop with). My case is slightly different in
> that the turn order is not fixes - sometimes player X goes twice in a
> row - but it ought to be pretty simple to plug into a standard AI
> library. Does anyone know where I can find such a thing?
>
> On Aug 13, 6:51 am, Mike Anderson
> wrote:
>> Hello all,
>>
>> I've recently been working on a game development project in Clojure
>> which is now starting to bear fruit. I thought people here might be
>> interested, and that it would be worthwhile to share some experiences
>> and perspectives.
>>
>> The project is a steampunk-themed strategy game, and a playable in-
>> development version is available here:
>>
>> http://mikera.net/ironclad/
>>
>> Overall, I think Clojure is a fantastic language for game development.
>> Some thought on what makes it really compelling:
>>
>> 1. Immutable data structures work surprisingly well for games. I
>> represent the entire game state with a big defrecord, and the main
>> engine loop is basically:
>> a) Get commands from player / AI (e.g. "Move unit from A to B")
>> b) Convert each command into set of atomic updates ("Remove unit
>> from A", "Add unit to B")
>> c) Apply updates sequentially to the game state
>> d) Trigger any feedback to player e.g. animations, sounds
>>
>> 2. Concurrency support has been very helpful. With immutable game
>> state, it has been trivial to separate the game engine from the
>> renderer from the AI calculations - each effectively gets to operate
>> on its own "snapshot" of the entire game state. This can be a big
>> headache in many game engines that have to mediate access to a single,
>> mutable game state. I can also see even greater benefits when I
>> finally start adding some multi-player features.
>>
>> 3. High level, functional programming works great for rapid, iterative
>> and dynamic development. Of all the languages I've used, Clojure has
>> probably been quickest in terms of time required to add a given new
>> piece of functionality. For example, the map generator code probably
>> only took about 30 minutes to write, pretty good for a fractal
>> landscape generation system!
>>
>> 4. The Java interoperability support is fantastic - definitely counts
>> as one of the "killer features" of Clojure. I've been able to reuse a
>> lot of Java code libraries, both my own and standard libraries such as
>> Swing. As an example, I have a well optimised immutable persistent 2D
>> grid data structure in Java (basically a very efficient, spatially
>> partitioned map from (int,int) to Object) that I have been able to use
>> pretty much seamlessly in Clojure thanks to extend-protocol and
>> similar.
>>
>> Some interesting observations / discoveries / surprises in the
>> process:
>>
>> 1. The game worked first time on Mac and Linux, despite having been
>> tested exclusively on Windows. Great kudos to to both the Java
>> platform and the Clojure libraries!
>>
>> 2. Reflection is *really slow*. After getting 20-100x speedups from
>> eliminating reflection warnings in the AI code, I now treat any
>> reflection warning in code other than one-time setup code as a bug to
>> be fixed immediately.
>>
>> Finally, here are some things I think could be great improvements to
>> Clojure in the future from a game developer's perspective:
>>
>> 1. Better support for primitive parameters / return values / unchecked
>> arithmetic - in performance sensitive code, these are pretty much
>> essential. In a few cases in the graphics and AI code, I've had to
>> drop back to Java to get the performance I need.
>>
>> 2. It would be great to reduce the amount of memory allocations. Yes,
>> I know memory is plentiful and GC is very cheap, but it's still not as
>> cheap as stack allocation and any noticeable GC pauses are not good
>> for the player experience in interactive games. For this reason, I
>> find myself using reduce and indexed loops a lot more than I guess
>> would normally be idiomatic, and conversely tend to avoid some of the
>> lazy constructs and functions that generate sequences. While Clojure
>> is great for a strategy game, I'd probably hesitate to use it for a
>> real-time 3D game.
>>
>> 3. I think it would be great to have better support for circular
>> references - perhaps a two-pass compile? The reason this is
>> particularly acute in game development is that different subsystems
>> have quite a lot of inter-dependenci
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
On Fri, 13 Aug 2010 23:08:40 +0400 Mikhail Kryshen wrote: > > I doubt it is possible to create runtime like JVM or CLR without patent > problems. Given that virtual machine technology "like"(1) the JVM and CLR have been around since the 70s - long before even C++ ++ -- was a gleam in Gosling's eye - I'm pretty sure it's possible to create a runtime "like" the JVM or CLR that has no insurmountable patent problems. Sure, Oracle can create problems for anyone implementing a VM by suing them, but if you started with something like either the UCSD P-Machine VM or a SmallTalk VM (Squeak, maybe?) - which Gosling cites as inspirations for the JVM (2) - such suits are clearly baseless, as the technology is obviously prior art. So it can't infringe the patent, only invalidate it. http://queue.acm.org/detail.cfm?id=1017013 -- Mike Meyer http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
Sorry all -- I think my original message went slightly awry. The announcement was a shock and quickly followed by waves of grumbling from devs I follow on Twitter. While it's easy to extrapolate the future from Oracle's past and this announcement, it's not necessarily useful or accurate to do so. I never suspected Clojure to be in any mid-term jeopardy. But it did seem like a good opportunity to stoke the CinC and CLR topics and see if there was a big change in the level of interest. Apparently not, and that's probably prudent. That said, I personally am now more interested in better CLR support for Clojure. While it's not a strength of mine, I'm sure I will find some way to contribute to that. Sorry again for any off topic churning, and here's hoping the JVM will continue to be a good place for Clojure to be for quite some time. Seth On Aug 13, 4:06 pm, Mike Meyer wrote: > On Fri, 13 Aug 2010 23:08:40 +0400 > > Mikhail Kryshen wrote: > > > I doubt it is possible to create runtime like JVM or CLR without patent > > problems. > > Given that virtual machine technology "like"(1) the JVM and CLR have > been around since the 70s - long before even C++ ++ -- was a gleam in > Gosling's eye - I'm pretty sure it's possible to create a runtime > "like" the JVM or CLR that has no insurmountable patent > problems. Sure, Oracle can create problems for anyone implementing a > VM by suing them, but if you started with something like either the > UCSD P-Machine VM or a SmallTalk VM (Squeak, maybe?) - which Gosling > cites as inspirations for the JVM (2) - such suits are clearly > baseless, as the technology is obviously prior art. So it can't > infringe the patent, only invalidate it. > > > *) This all depends on exactly what you mean by "like". Gosling and > the Java group at Sun are sharp people, I'm sure they added ideas that > were patentable, and probably even worth granting a patent to. If > "like" includes "having patented feature foo", then foo may be missing > from the VMs that are prior art, so they aren't "like" JVM or CLR. But > just having a portable VM also qualifies as "like" JVM in some sense. > > 1)http://queue.acm.org/detail.cfm?id=1017013 > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
On Aug 13, 11:09 am, Wilson MacGyver wrote: > I assumed he didn't use OpenGL because it's a 2d tile game? > Using OpenGL for 2d or 2.5d (isometric) is really only a good idea > if you can assume the target has hardware OpenGL acceleration. > > Even then you may not want to do that, due to battery concerns. > But there are some good OpenGL 2D game engines for Java, e.g. Slick[1]. There's also Penumbra[2] which nicely wraps LWJGL for Clojure. I ask this mostly because I'm making my own 2D game and somewhat torn between Java2D and OpenGL. Penumbra is pretty solid in my experience. What do you mean by "battery concerns"? --Brian [1] http://slick.cokeandcode.com/ [2] http://github.com/ztellman/penumbra -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
On Fri, Aug 13, 2010 at 4:51 PM, Brian Carper wrote: > But there are some good OpenGL 2D game engines for Java, e.g. > Slick[1]. There's also Penumbra[2] which nicely wraps LWJGL for > Clojure. I ask this mostly because I'm making my own 2D game and > somewhat torn between Java2D and OpenGL. Penumbra is pretty solid in > my experience. We don't use Penumbra. On Java, we use JOGL, and on other targets we use pure OpenGL or OpenGL ES API for both compatibility and performance reasons. We have to ensure whatever OpenGL stuff we do, will work everywhere. > > What do you mean by "battery concerns"? Laptops, Mobile devices and such. If you use OpenGL on a laptop, it will use the GPU assuming it's hardware accelerated. GPU is a big battery drain. On mobile devices such as iPhone and Android, it's even more so. Using OpenGL unnecessarily causes battery drain on your hardware. Plus, if you use OpenGL, and your target is using those Intel Extreme Graphics, where the only thing it's Extreme at, is Extremely slow. :) You end up gain nothing but lose lots. -- Omnem crede diem tibi diluxisse supremum. -- 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
Transactions in c.c.sql functions
Hi, While going through the clojure.contrib.sql sources I noticed at several places that a new transaction is started to execute the operation under. Case at hand: do-commands, do-prepared, update-or- insert-values. As far I understand, transactions belong to the user. The user should decide what to execute under which transaction. By beginning transaction inside these functions, is it assumed that the user can wrap bigger constructs under her own transactions and that the JDBC driver would support nested transactions? Cheers, Shantanu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
I'm in favor of any discussion that yields more support for Clojure on CLR. :) - David On Aug 13, 3:36 pm, Seth wrote: > Sorry all -- I think my original message went slightly awry. The > announcement was a shock and quickly followed by waves of grumbling > from devs I follow on Twitter. While it's easy to extrapolate the > future from Oracle's past and this announcement, it's not necessarily > useful or accurate to do so. I never suspected Clojure to be in any > mid-term jeopardy. But it did seem like a good opportunity to stoke > the CinC and CLR topics and see if there was a big change in the level > of interest. Apparently not, and that's probably prudent. > > That said, I personally am now more interested in better CLR support > for Clojure. While it's not a strength of mine, I'm sure I will find > some way to contribute to that. > > Sorry again for any off topic churning, and here's hoping the JVM will > continue to be a good place for Clojure to be for quite some time. > > Seth > > On Aug 13, 4:06 pm, Mike Meyer > 620...@mired.org> wrote: > > On Fri, 13 Aug 2010 23:08:40 +0400 > > > Mikhail Kryshen wrote: > > > > I doubt it is possible to create runtime like JVM or CLR without patent > > > problems. > > > Given that virtual machine technology "like"(1) the JVM and CLR have > > been around since the 70s - long before even C++ ++ -- was a gleam in > > Gosling's eye - I'm pretty sure it's possible to create a runtime > > "like" the JVM or CLR that has no insurmountable patent > > problems. Sure, Oracle can create problems for anyone implementing a > > VM by suing them, but if you started with something like either the > > UCSD P-Machine VM or a SmallTalk VM (Squeak, maybe?) - which Gosling > > cites as inspirations for the JVM (2) - such suits are clearly > > baseless, as the technology is obviously prior art. So it can't > > infringe the patent, only invalidate it. > > > > > *) This all depends on exactly what you mean by "like". Gosling and > > the Java group at Sun are sharp people, I'm sure they added ideas that > > were patentable, and probably even worth granting a patent to. If > > "like" includes "having patented feature foo", then foo may be missing > > from the VMs that are prior art, so they aren't "like" JVM or CLR. But > > just having a portable VM also qualifies as "like" JVM in some sense. > > > 1)http://queue.acm.org/detail.cfm?id=1017013 > > -- > > Mike Meyer http://www.mired.org/consulting.html > > Independent Network/Unix/Perforce consultant, email for more information. > > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
I played it, it was pretty fun.
I have UI recommendations. I couldn't tell the difference between the
enemy and my units.
I wish maybe you had some quick tips and recommended next actions so I
could get used to how the game works.
On Aug 13, 9:51 am, Mike Anderson
wrote:
> Hello all,
>
> I've recently been working on a game development project in Clojure
> which is now starting to bear fruit. I thought people here might be
> interested, and that it would be worthwhile to share some experiences
> and perspectives.
>
> The project is a steampunk-themed strategy game, and a playable in-
> development version is available here:
>
> http://mikera.net/ironclad/
>
> Overall, I think Clojure is a fantastic language for game development.
> Some thought on what makes it really compelling:
>
> 1. Immutable data structures work surprisingly well for games. I
> represent the entire game state with a big defrecord, and the main
> engine loop is basically:
> a) Get commands from player / AI (e.g. "Move unit from A to B")
> b) Convert each command into set of atomic updates ("Remove unit
> from A", "Add unit to B")
> c) Apply updates sequentially to the game state
> d) Trigger any feedback to player e.g. animations, sounds
>
> 2. Concurrency support has been very helpful. With immutable game
> state, it has been trivial to separate the game engine from the
> renderer from the AI calculations - each effectively gets to operate
> on its own "snapshot" of the entire game state. This can be a big
> headache in many game engines that have to mediate access to a single,
> mutable game state. I can also see even greater benefits when I
> finally start adding some multi-player features.
>
> 3. High level, functional programming works great for rapid, iterative
> and dynamic development. Of all the languages I've used, Clojure has
> probably been quickest in terms of time required to add a given new
> piece of functionality. For example, the map generator code probably
> only took about 30 minutes to write, pretty good for a fractal
> landscape generation system!
>
> 4. The Java interoperability support is fantastic - definitely counts
> as one of the "killer features" of Clojure. I've been able to reuse a
> lot of Java code libraries, both my own and standard libraries such as
> Swing. As an example, I have a well optimised immutable persistent 2D
> grid data structure in Java (basically a very efficient, spatially
> partitioned map from (int,int) to Object) that I have been able to use
> pretty much seamlessly in Clojure thanks to extend-protocol and
> similar.
>
> Some interesting observations / discoveries / surprises in the
> process:
>
> 1. The game worked first time on Mac and Linux, despite having been
> tested exclusively on Windows. Great kudos to to both the Java
> platform and the Clojure libraries!
>
> 2. Reflection is *really slow*. After getting 20-100x speedups from
> eliminating reflection warnings in the AI code, I now treat any
> reflection warning in code other than one-time setup code as a bug to
> be fixed immediately.
>
> Finally, here are some things I think could be great improvements to
> Clojure in the future from a game developer's perspective:
>
> 1. Better support for primitive parameters / return values / unchecked
> arithmetic - in performance sensitive code, these are pretty much
> essential. In a few cases in the graphics and AI code, I've had to
> drop back to Java to get the performance I need.
>
> 2. It would be great to reduce the amount of memory allocations. Yes,
> I know memory is plentiful and GC is very cheap, but it's still not as
> cheap as stack allocation and any noticeable GC pauses are not good
> for the player experience in interactive games. For this reason, I
> find myself using reduce and indexed loops a lot more than I guess
> would normally be idiomatic, and conversely tend to avoid some of the
> lazy constructs and functions that generate sequences. While Clojure
> is great for a strategy game, I'd probably hesitate to use it for a
> real-time 3D game.
>
> 3. I think it would be great to have better support for circular
> references - perhaps a two-pass compile? The reason this is
> particularly acute in game development is that different subsystems
> have quite a lot of inter-dependencies. AI evaluation system needs to
> understand game state/engine so it can evaluate a position. Game state/
> engine needs to understand units so it can manipulate them. Units need
> to understand AI evaluation system so they can decide which actions to
> take.. obviously it's possible to work around all this, but it's a
> major pain, adds complexity and means that you need to structure code
> to manage dependencies rather than in logical modules (which would be
> easier to manage and maintain!)
>
> Would love to hear thoughts, and particularly any other experiences
> people have had in using Clojure for game development!
>
> Mike.
--
You received this message because yo
Re: Protocols and default method implementations
so clients don't directly call the protocol functions they call print-ast which then checks to see if PrettyPrintable has been extended to the object and falls back to the default if it hasn't On Thu, Aug 12, 2010 at 6:16 PM, Matthew Phillips wrote: > On Aug 13, 3:38 am, Stuart Halloway wrote: >> > Stu, (or anybody) I'd like to ask about a variation on this >> > point. How do you handle the case where you have a general >> > function that works for every type you'd like to implement a >> > protocol for (thus not technically needing to be in a protocol), >> > but maybe 1 or 2 of the many types have more efficient >> > implementations possible? Do you just suck it up and copy and >> > paste the general function around? Or is there a better way? Maybe >> > the new case function? >> >> This might be a job for a more granular protocol. Take a look at how >> granular Clojure's implementation abstractions are (even prior to >> the introduction of protocols). The Java interfaces often have 0, 1, >> or 2 methods. > > The scenario I'm thinking of is when you've already published a > protocol, and now want to extend it. Instead, you could just create a > new (granular) protocol, but that does seem to lead inexorably to the > IFoo, IFoo2, IFoo3, situation. > > A more concrete example: say I've defined a protocol for AST nodes in > 1.0 of a library, and later when developing 2.0 I discover it would > have been a good idea to have a "pretty-print" method on nodes to show > human-readable output. If the protocol had Trait-like characteristics > I could add pretty-print to the protocol, with a default > implementation that just prints the fields of the node, but override > that with a better implementation for some of the new record types I'm > including in 2.0. > > But I can't do that because, unless I've had the foresight to make > sure clients always mix in a base set of (partial) defaults that I > provide (which may be initially empty), then things break down. Sean > Devlin's ideas (referenced earlier on the thread) on making it easy to > mix in defaults would be great for this, but they don't really address > the issue I'm looking at here. > > Following Stuart's suggestion, I *could* just add a protocol called > "PrettyPrintable" with one method and implement it on some of the new > node types, but now I can't just call "pretty-print" on any node: I > need to write another function that checks if it's a PrettyPrintable > first and calls something default if not. > > I've had to do this sort of thing many, many times in Java: one of the > reasons I got excited about multimethods in Clojure is that they allow > me to transparently extend the system after the fact with no such > ugliness. > > Thanks to the superpower that is macro, I'm sure I could make a > defprotocol+ and a extend+ that do this, just wanted to check that > there's really no better way. > > Cheers, > > Matthew. > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
Protocols not changing the caller's contract
Greetings, Suppose that I create a function that is designed to receive a map as a parameter: (defn add-ten [m] (+ 10 (:amount m))) but then later I want to make this function part of a protocol (defprotocol AddTen (add-ten [this])) but I still want it to work when someone passes a plain map to add- ten. The only thing that I can think of would be the following: (extend-protocol AddTen clojure.lang.IPersistentMap (add-ten [this] (+ 10 (:amount this It feels wrong to refer to clojure.lang.IPersistentMap as if I am relying on an implementation detail. Is there a better way to do this? I'm in the middle of writing blog post about protocols (in order to improve my own understanding of them) where I try to illustrate the point that you can code against maps then switch to protocols and records without changing the caller's contract. Thanks for your help, Brenton -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Protocols not changing the caller's contract
IPersistentMap is an interface, which are sort of the java analog of protocols, and in fact last I checked protocols generate named java interfaces, so I think you're fine On Fri, Aug 13, 2010 at 5:10 PM, Brenton wrote: > Greetings, > > Suppose that I create a function that is designed to receive a map as > a parameter: > > (defn add-ten [m] > (+ 10 (:amount m))) > > but then later I want to make this function part of a protocol > > (defprotocol AddTen > (add-ten [this])) > > but I still want it to work when someone passes a plain map to add- > ten. The only thing that I can think of would be the following: > > (extend-protocol AddTen > clojure.lang.IPersistentMap > (add-ten [this] (+ 10 (:amount this > > It feels wrong to refer to clojure.lang.IPersistentMap as if I am > relying on an implementation detail. Is there a better way to do > this? > > I'm in the middle of writing blog post about protocols (in order to > improve my own understanding of them) where I try to illustrate the > point that you can code against maps then switch to protocols and > records without changing the caller's contract. > > Thanks for your help, > Brenton > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
>> 3. I think it would be great to have better support for circular >> references - perhaps a two-pass compile? The reason this is >> particularly acute in game development is that different subsystems >> have quite a lot of inter-dependencies. AI evaluation system needs to >> understand game state/engine so it can evaluate a position. Game state/ >> engine needs to understand units so it can manipulate them. Units need >> to understand AI evaluation system so they can decide which actions to >> take.. obviously it's possible to work around all this, but it's a >> major pain, adds complexity and means that you need to structure code >> to manage dependencies rather than in logical modules (which would be >> easier to manage and maintain!) > > I'm not sure what you mean by this, can you expand on this? Though I didn't write that paragraph, I have faced the same issue. Suppose I have two functions in the same file, and one depends on the other: (defn foo [x] (+ 1 x)) (defn bar [x] (* 2 (foo x))) I can't switch their order without adding extra forward-declaration code, which is redundant: (declare foo) (defn bar [x] (* 2 (foo x))) (defn foo [x] (+ 1 x)) This example is just a minor irritation, that I need to make sure all the functions in a file are in the right order. A bigger problem is when the two functions are in different files/packages. Suppose I have files a.clj and b.clj and place some of my functions in each of those files based on some arbitrary categorization that makes intuitive sense to me. Then I realize that some of the functions in a.clj depend on some functions in b.clj, while some functions in b.clj depend on some functions in a.clj. Can I still use declare to resolve this circular dependency? Can I even "require" a.clj from b.clj when I have already "require"d b.clj from a.clj? My solution so far has been to make sure that dependencies between packages are never two-way. I deliberately choose categorizations that won't result in circular dependencies between packages. I would much prefer to just refer to whatever function I wish, from whichever function I wish, and not need to think about which packages I am allowed to depend on or in what order functions must appear in a file. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
I rarely run into this. The few times I have, I just do (def g) ;creates a var g that is unbound (defn f [] (g)) ;ok (defn g [] ;f will call this nil) as shown by Rich at http://markmail.org/message/vuzvdr4xyxx53hwr#query:+page:1+mid:tzsd3k6tvvc4ahoq+state:results On Fri, Aug 13, 2010 at 11:49 PM, Eric Lavigne wrote: > Suppose I have two functions in the same file, and one depends on the other: > > (defn foo [x] (+ 1 x)) > (defn bar [x] (* 2 (foo x))) > > I can't switch their order without adding extra forward-declaration > code, which is redundant: > > (declare foo) > (defn bar [x] (* 2 (foo x))) > (defn foo [x] (+ 1 x)) > -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
The (def g) in your example has the same effect as the (declare foo) in my example. I discussed two problems. The first problem, which you addressed, was mostly just a warm-up for discussing a related problem that is more severe. Where can I put (def g) so that two files can "require" each other? This is not a rare problem for me. Like Mike Anderson, I work around it by putting extra thought into which package-level dependencies I will allow, which sometimes necessitates creating more or fewer packages than I otherwise would have created. On Sat, Aug 14, 2010 at 12:13 AM, Wilson MacGyver wrote: > I rarely run into this. The few times I have, I just do > > (def g) ;creates a var g that is unbound > > (defn f [] > (g)) ;ok > > (defn g [] ;f will call this > nil) > > as shown by Rich at > > http://markmail.org/message/vuzvdr4xyxx53hwr#query:+page:1+mid:tzsd3k6tvvc4ahoq+state:results > > On Fri, Aug 13, 2010 at 11:49 PM, Eric Lavigne wrote: >> Suppose I have two functions in the same file, and one depends on the other: >> >> (defn foo [x] (+ 1 x)) >> (defn bar [x] (* 2 (foo x))) >> >> I can't switch their order without adding extra forward-declaration >> code, which is redundant: >> >> (declare foo) >> (defn bar [x] (* 2 (foo x))) >> (defn foo [x] (+ 1 x)) >> > > -- > Omnem crede diem tibi diluxisse supremum. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
Suppose you make a file containing a (def foo) form for every defn in every file and then load that first? Does that solve the circular reference problem? Tim Daly Eric Lavigne wrote: The (def g) in your example has the same effect as the (declare foo) in my example. I discussed two problems. The first problem, which you addressed, was mostly just a warm-up for discussing a related problem that is more severe. Where can I put (def g) so that two files can "require" each other? This is not a rare problem for me. Like Mike Anderson, I work around it by putting extra thought into which package-level dependencies I will allow, which sometimes necessitates creating more or fewer packages than I otherwise would have created. On Sat, Aug 14, 2010 at 12:13 AM, Wilson MacGyver wrote: I rarely run into this. The few times I have, I just do (def g) ;creates a var g that is unbound (defn f [] (g)) ;ok (defn g [] ;f will call this nil) as shown by Rich at http://markmail.org/message/vuzvdr4xyxx53hwr#query:+page:1+mid:tzsd3k6tvvc4ahoq+state:results On Fri, Aug 13, 2010 at 11:49 PM, Eric Lavigne wrote: Suppose I have two functions in the same file, and one depends on the other: (defn foo [x] (+ 1 x)) (defn bar [x] (* 2 (foo x))) I can't switch their order without adding extra forward-declaration code, which is redundant: (declare foo) (defn bar [x] (* 2 (foo x))) (defn foo [x] (+ 1 x)) -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Game development in Clojure
I realize that. I was pondering why I don't run into the the 2nd problem. In your code, how many files/name spaces are you creating? And how many lines of code are in each file? I'm curious how you organize your code. On Aug 14, 2010, at 12:39 AM, Eric Lavigne wrote: . > > I discussed two problems. The first problem, which you addressed, was > mostly just a warm-up for discussing a related problem that is more > severe. Where can I put (def g) so that two files can "require" each > other? > > This is not a rare problem for me. Like Mike Anderson, I work around > it by putting extra thought into which package-level dependencies I > will allow, which sometimes necessitates creating more or fewer > packages than I otherwise would have created. >> -- 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
two announcements: a new Clojure article, and a new site for beginners
** First announcement: a tutorial article on how to call Java classes from Clojure Several months ago, I asked a few questions about the use of proxy and interoperability with Java. I'm pleased to say that with the help of several members here, I was able to get past being "stuck" and finish my project. Better yet, I've written an article about the subject, and I invite you to take a look at it. It's called "Extending Java Classes Using proxy," and it contains material than I have certainly not found anywhere else on the Internet. Check it out at http://www.gettingclojure.com/articles:extending-java-classes-using-proxy If you need to call Java libraries from your Clojure programs, this article has information you need to know! ** Second announcement: GettingClojure.com, a collaborative site for Clojure beginners If you're freaking out because you've never heard of GettingClojure.com, please don't be concerned. It's not you--it's me. And I mean that literally. I created gettingclojure.com as a service to the Clojure community and to beginning Clojure programmers. I hope that it will become the one- stop shopping resource for Clojure beginners (like myself). It's actually a wiki with a set of forums attached, and it will also include short and long articles, as well as directories of links to Clojure resources elsewhere on the Internet. GettingClojure.com is *for* users, *by* users. Please help strengthen the Clojure community by participating in any of the following ways: * Visit the site (http://www.gettingclojure.com/) * Tell people about it, and point to it in your e-mails, your posts on the Clojure Google group, and your blogs. * Visit the forums (http://www.gettingclojure.com/forum:start) and add something--a question, an answer, a manifesto, whatever. * Write and post an article on something you know/are excited/are thinking about. It doesn't have to be a //magnum opus//--two good paragraphs can make an excellent article. Best of all, you get your own page to put it on, and no one can edit it but you! I'm extremely open to changing the site, so please share your ideas in the "Suggestions for This Site" section of the forum, or write me at gregg4 at-sign GettingClojure dot-sign net. I'd love to hear from you! Thanks for listening, and good hacking! Gregg Williams GettingClojure.com site manager -- 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
