Re: two announcements: a new Clojure article, and a new site for beginners
I see, I am reading that "Extending Java Classes using proxy" article. 2010/8/15 Michael Gardner : > On Aug 14, 2010, at 12:58 AM, Gregg Williams wrote: > >> ** Second announcement: GettingClojure.com, a collaborative site for >> Clojure beginners > > gettingclojure.com currently redirects to www.wikidot.com. > > www.gettingclojure.com is fine, though. > > -- > 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
grep for defn and write out def forms to a file? Btsai wrote: Continuing this train of thought... 1. The "declare" macro may be handy for declaring multiple names at once. 2. Maybe one could use the functions in clojure.repl or clojure- contrib.ns-utils to write something that automatically forward declares everything needed? On Aug 13, 10:49 pm, Tim Daly wrote: 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:tzsd3k... 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: two announcements: a new Clojure article, and a new site for beginners
On Aug 14, 2010, at 12:58 AM, Gregg Williams wrote: > ** Second announcement: GettingClojure.com, a collaborative site for > Clojure beginners gettingclojure.com currently redirects to www.wikidot.com. www.gettingclojure.com is fine, though. -- 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: Transactions in c.c.sql functions
On Aug 13, 11:23 pm, Shantanu Kumar wrote: > > 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? I'm unsure of why clojure.contrib.sql does start transactions without documenting them but it is a lot smarter than it first appears. My understanding is that JDBC relies on the underlying database to support nested transactions. However, clojure.contrib.sql supports nested transactions on all databases by keeping a count of the level of nesting and only executing a database transaction at the outer level. http://github.com/richhickey/clojure-contrib/blob/6a0483d9e216ca00fc648a4b3673996b76a2785a/src/main/clojure/clojure/contrib/sql/internal.clj#L144 I don't know if this is an ideal thing to do but my own modest, not mission critical, use of it has not run into any problems. Saul -- 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: two announcements: a new Clojure article, and a new site for beginners
Great working, thanks! I will participate actively. On 8月14日, 下午1时58分, Gregg Williams wrote: > ** 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-p... > > 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
Re: ANN: Emacs auto-complete plugin for slime users
Excellent. Seems to work quite well. On Sat, Aug 14, 2010 at 6:19 AM, Steve Purcell wrote: > Hi all, > > A while ago I hooked Slime's completion and documentation features into the > popular Emacs auto-completion framework "auto-complete" ( > http://www.emacswiki.org/emacs/AutoComplete). > > Since it may be of interest to others, I've released the completion plugin > on github: http://github.com/purcell/ac-slime > > Here's a screenshot of the plugin in action in a clojure-mode buffer, > showing the (very handy) pop-up documentation: > > > > > > > -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 > -- 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
One example is a contract programming job I did recently, writing software for identifying radioactive isotopes based on measurements of their emission spectra. In the end I had 7 Clojure source files (not including tests). I will show them in such an order that each file depends only on previous files. math (11 definitions, 80 lines) matching (5 definitions, 54 lines) units (2 definitions, 15 lines) io (7 definitions, 74 lines) physics (4 definitions, 28 lines) metrics (7 definitions, 174 lines) main (1 definition, 35 lines) I originally wanted to include the contents of the units file in the physics file, but then there would be a circular dependency between physics and io. The io code needs to interpret half-life values in files that provide information about isotopes, and those half-life values are meaningless if you don't know the relationship between seconds, hours, and years. Physics code needs access to io code quite frequently because, for example, you can't determine what portion of photons will penetrate a 1/4" thick iron plate without reading iron's transmission coefficients as a function of photon energy from a file. It's not a big deal to have a units package, but I don't typically create a new category for just two definitions that already fit well in one of the existing categories. Also, there were two functions in the physics package that I moved to the math package so that functions in the io package could depend on them. These functions were responsible for sorting emission lines by energy and filtering out emission lines that would not be included in the analysis because their energies are often associated with false positives. These operations need to be performed on every isotope that is read from the application's isotope library, and the easiest way to arrange that is to call them from the function that reads the isotope library. Again, not a big deal, but I would not ordinarily include code in the math package that can only operate on emission data - that belongs in physics. On Sat, Aug 14, 2010 at 1:37 AM, Wilson MacGyver wrote: > 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 -- 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
Matthew Phillips writes: > ;; A node has a data attachment and (possibly) children > (defprotocol Node > (data [n]) > (children [n])) > > (deftype SimpleNode [d] > Node > (data [n] d) > (children [n] [])) > > ;; In version 2, I add want to add pretty-printing > > (defprotocol PrettyPrintableNode > (pretty-print [n])) > > ;; Make anything potentially pretty-print'able > (extend-type Object > PrettyPrintableNode > (pretty-print [n] (str "A node: " (data n I'm confused by the mixture of formality and looseness here. When you extend this way, binding this `pretty-print' implementation to arguments of type Object, you're implicitly requiring that argument "n" satisfies the protocol Node -- because you call the `data' function on it. But if the function `data' would work on any kind of Object, then so too would any call to `pretty-print', right? Should the call to `data' within the `pretty-print' definition above require some mention of protocol Node? In other words, what's the difference between using `extend-type' here on Object and just writing , | (defn pretty-print | [n] | (str "A node: " (data n))) ` My experiments in the REPL don't show any difference in behavior. Being able to define a normal `pretty-print' function above differs from the generic function system in Common Lisp. There, if one has defined a generic function with `defgeneric', and one later tries to define a normal function with the same name, the normal function replaces the generic function, and the compiler may emit a warning. Working the other way, though, one may not define a generic function -- using `defgeneric' or `defmethod' -- if the function name is already bound to a normal function, macro, or special operator. Is there supposed to be a difference between the normal function `pretty-print' I wrote above and the function defined in the `extend-type' form quoted above? -- Steven E. Harris -- 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
how doesn't it work? the approach of writing your library using regular functions while protocols provide a simple pluggable lower bound that users can implement. and when users do implement the simple protocols they suddenly get all the advanced features of the library functions, like if you implement ISeq, suddenly all of clojure's sequence functions work on your data. On Fri, Aug 13, 2010 at 9:40 PM, Matthew Phillips wrote: > On Aug 14, 9:07 am, Kevin Downey wrote: >> 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 > > Sure, but I'm talking about publishing protocols that clients > implement, not an API that might make use of protocols internally. If > the clients implement *and* call methods via protocols, then that kind > of approach doesn't really work. > > -- > 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: Protocols and default method implementations
On Sat, Aug 14, 2010 at 5:32 AM, Matthew Phillips wrote: > > One idea that I tried was to use extend-type on a protocol, say to > extend any Node to be a PrettyPrintableNode. Obviously this didn't > work, and I'm not sure it actually makes semantic sense, but it's > interesting that was my intuitive action. > I played with that kind of things a bit and come up with a - very alpha - library some time ago. I called it type classes because it does a part of what Haskell's type classes do. You can define a rule: Node => PrettyPrintableNode (implementation of PrettyPrintableNode using Node) And it extends Object with a default implementatiuon of protocol PrettyPrintable, that just takes the object it is called on, looks at its type, and try to apply the rules it can apply to it (You could have a rule NodeV2-25 => PrettyFormatable and another PrettyFormatable, ... => PrettyPrintable). If it finds a non-cyclic path to construct a PrettyPrintable instance, it extend the types with the right protocols implementation, and recalls the function. I planned to improve on it, but it seems there were a really low interest for this kind of thing on the list when I posted. I wouldn't recommand to use it in this state, but if you want to have a look at the code: https://nicolasoury.repositoryhosting.com/trac/nicolasoury_type-classes 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: Protocols and default method implementations
> Adding to Object works, but doesn't feel right: as libraries grow, > they'll start bloating out the method sets on the global Object type. No, you have this backwards. The protocol is not on Object, Object is on the protocol. Protocols live in namespaces. You can have 10,000 different protocols extended to Object with no bloat problems. You can have multiple methods with the same names but different semantics, and use any or all of them as you see fit. This is a major benefit of decoupling polymorphism from inheritance. There is no bloat, and no sacred place (on Object) where you compete for names. 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: More urgency for CinC & CLR given Oracle's lawsuit against Google?
* Mikhail Kryshen: > 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. Microsoft rescued Sun a couple of years ago with a cash injection (similar to what they did with Apple), and the companies reached some agreement on patents back then. Those contracts probably remain in force despite the acquisition. However, it is unclear to what extent such agreements cover downstream users of such technology. The best defense seems to be not to become too successful. -- 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 14, 3:22 am, Armando Blancas wrote: > > 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)) No, I'm just trying to work this all out based on my experiences with using Java interfaces in library design. Although I guess Java interop will be important for me since I have a lot of existing Java to support, -- 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
Continuing this train of thought... 1. The "declare" macro may be handy for declaring multiple names at once. 2. Maybe one could use the functions in clojure.repl or clojure- contrib.ns-utils to write something that automatically forward declares everything needed? On Aug 13, 10:49 pm, Tim Daly wrote: > 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:tzsd3k... > > >> 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: Protocols and default method implementations
On Aug 14, 9:07 am, Kevin Downey wrote: > 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 Sure, but I'm talking about publishing protocols that clients implement, not an API that might make use of protocols internally. If the clients implement *and* call methods via protocols, then that kind of approach doesn't really work. -- 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 14, 12:34 am, Stuart Halloway wrote: > > 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. Just to thrash this out in my own head I've developed the scenario below as a hypothetical (and obviously trivial) graph node library evolves through several versions. I've used extend-type on Object to retro-actively provide default implementations for older clients. Adding to Object works, but doesn't feel right: as libraries grow, they'll start bloating out the method sets on the global Object type. One idea that I tried was to use extend-type on a protocol, say to extend any Node to be a PrettyPrintableNode. Obviously this didn't work, and I'm not sure it actually makes semantic sense, but it's interesting that was my intuitive action. Example below, interested in any thoughts. Matthew. --- ;; A node has a data attachment and (possibly) children (defprotocol Node (data [n]) (children [n])) (deftype SimpleNode [d] Node (data [n] d) (children [n] [])) ;; In version 2, I add want to add pretty-printing (defprotocol PrettyPrintableNode (pretty-print [n])) ;; Make anything potentially pretty-print'able (extend-type Object PrettyPrintableNode (pretty-print [n] (str "A node: " (data n ;; Later, in version 3, I decide nodes also need a tag (defprotocol TaggedNode (tag [n])) ;; Default to node's data if no tag (extend-type Object TaggedNode (tag [n] (data n))) ;; A new type of node that has a settable tag (deftype SuperNode [d t] Node (data [n] d) (children [n] []) PrettyPrintableNode (pretty-print [n] (str "Node: tag " (tag n) ", data: " (data n))) TaggedNode (tag [n] t)) --- Examples of use > (def n (SimpleNode. "Matt")) > (def n2 (SuperNode. "Matt" "a tag")) > (tag n) "Matt" > (tag n2) "a tag" > (pretty-print n2) "Node: tag a tag, data: Matt" > (pretty-print n) "A node: Matt" -- 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: Emacs auto-complete plugin for slime users
Hi all, A while ago I hooked Slime's completion and documentation features into the popular Emacs auto-completion framework "auto-complete" (http://www.emacswiki.org/emacs/AutoComplete). Since it may be of interest to others, I've released the completion plugin on github: http://github.com/purcell/ac-slime Here's a screenshot of the plugin in action in a clojure-mode buffer, showing the (very handy) pop-up documentation: -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: Game development in Clojure
I have a similar problem with deftype/defecord If I need to mutually defined types... (declare new-a) (deftype B ... (new-a)...)) (deftype A) (defn new-a [] (A.)) On Sat, Aug 14, 2010 at 8:21 AM, Mark Engelberg wrote: > On Fri, Aug 13, 2010 at 9:39 PM, Eric Lavigne wrote: >> 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. > > Me three. I find it to be a *lot* of work to avoid circular dependencies. > > -- > 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
On Fri, Aug 13, 2010 at 9:39 PM, Eric Lavigne wrote: > 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. Me three. I find it to be a *lot* of work to avoid circular dependencies. -- 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
