Re: Algebraic data types in clojure.contrib
On 26.02.2009, at 08:47, Jeff Valk wrote: > String representation obviously uses :type now in a very particular > way. I'm not sure where this happens though. Can anyone shed some > light on the details? print-method now dispatches on type, rather than class as it did before. There is no default implementation for print-method, so if you put something as :type that has no implementation of print- method, weird things will happen. The fix is to provide a default implementation for print-method. Try executing this: (defmethod print-method :default [o w] (print-method "failed" w)) before printing your object, and it should print "failed" without any exception. There should be a default in clojure.core, but I am not sure what it should best be. Should it print the object stripped of its metadata? Or a string indicating the problem? Or should it throw an exception? Konrad. --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On 26.02.2009, at 01:51, Rich Hickey wrote: > You raise interesting issues and I'd like to explore them further. I'm > not sure the issues you have with type-tag-or-class dispatch are all > that prohibitive. In any case, I've added a type function that returns > the :type metadata or the class if none: Thanks, that helps a lot! With a built-in universal dispatching function, most of my problems should be solved. Another useful function to have would be (defn type-instance? "Evaluates x and tests if it is an instance of the type or class t. Returns true or false" [t x] (identical? t (type x))) for type-based dispatching inside a function. > I'm not sure the mechanism you are using (actual Class types) allows > for any more overloading - Class is a single slot too, after all. True, but the number of classes is not limited. Java programmers can live with a single class hierarchy, so it can't be too bad. But Clojure's hierarchies are definitely more flexible. > A bigger problem with the mechanism you've chosen is its dependence on > some implementation details. I haven't promised, e.g. that every fn > generates a unique class type. I know, but as I said, my current implementation is just a proof of concept. It is not viable for production use for a variety of reasons. I was planning to replace it by something based on gen-class and proxy, but I will first try to get away with the new type function. Konrad. --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
2009/2/26 Konrad Hinsen > > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > You raise interesting issues and I'd like to explore them further. I'm > > not sure the issues you have with type-tag-or-class dispatch are all > > that prohibitive. In any case, I've added a type function that returns > > the :type metadata or the class if none: > > Thanks, that helps a lot! With a built-in universal dispatching > function, most of my problems should be solved. Another useful > function to have would be > > (defn type-instance? > "Evaluates x and tests if it is an instance of the type or class t. >Returns true or false" > [t x] > (identical? t (type x))) > > for type-based dispatching inside a function. or maybe generalize the existing 'instance? function to the above definition ? --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
how to get concurrent - model design question
Hi all. First. For those who remember, I posted an individual-based model in this group some time ago (eden.clj), and got some very helpful replies on where I misunderstood clojure and did things the hard way. I wanted to report that that model by now is written purely as nonblocking agents, and is happily burning cpu cycles as it simulates the evolution of our immune system :). thanks for that! Second. I am updating an older model on Chlamydia prevalence in a dynamic sexual contact network, and implemented it in clojure (http:// clojure.googlegroups.com/web/chlam-clean.clj), based on the model in this paper (http://aje.oxfordjournals.org/cgi/content/abstract/ 144/3/306). It isn't fully equivalent to the model in the paper yet (for some reason, Chlamydia keeps going extinct), but that is something I will puzzle over myself. I am however, still somewhat fuzzy on what a good way is to get the model concurrent. I tried replacing (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-host pair-host breakup-host] i world] (e i with (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-host pair-host breakup-host] i world] (send-off (agent i) e))) or (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery- host pair-host breakup-host] i world] (send-off (agent nil) (fn [_] (e i)) There doesn't seem to be any concurrency happening, and the whole thing just slows down to not doing much at all. Anyone knows what I am doing wrong?. Considering that I wrestled with this before in previous posts in this group, I offer my apologies for not getting the correct way of mixing agents and refs into my thick skull. (Luckily I have grasped agents-only models, so there is hope :), but as I need refs in this model, I'm again banging my head against the wall). --~--~-~--~~~---~--~~ 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 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: Waterfront Assertion Failure
Hi Onorio RC1-147 requires the use of Clojure's latest snapshot (can be obtained from the SVN). -Itay On Feb 26, 4:21 am, Onorio Catenacci wrote: > Hi Itay (and everyone else), > > Every time I try to run Waterfront I keep running into the same > error. On line 83 of kit.clj the assertion fails. > > Version of Clojure: Revision: 1173 > I just pulled Waterfront from the SourceForge site. (RC1-147). I > didn't see the older version so I don't know if that makes a > difference in this case or not. > Windows XP SP2 > > I have the same error with both JDK 1.6.0_03 and 1.6.0_12. > > If there's a bug tracking system for Waterfront I'll add this to the > defect tracking system. I can send along the wf.bat I'm using > (modified to my paths of course) if it makes a difference. When I > initially saw this issue Clojure was sitting in a directory name with > spaces (something like "My Documents\Desktop") so I moved it to a > directory that should be fine under 8.3 and that didn't make a > difference. > > -- > Onorio Catenacci --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On Feb 26, 2009, at 1:51, Rich Hickey wrote: > You raise interesting issues and I'd like to explore them further. I'm > not sure the issues you have with type-tag-or-class dispatch are all > that prohibitive. In any case, I've added a type function that returns > the :type metadata or the class if none: > > user=> (type #^{:type ::Fred} [1 2 3]) > :user/Fred > > user=> (type "foo") > java.lang.String > > which should help people standardize. One inconvenience I noticed with types based on meta-data tags is that the type information does not participate in equality tests. This means I have to include the type information once again in the value itself if I want to make sure that no other type's value accidentally compare as identical to mine. > If you want to multiplex multimethods for your ADT type, you can just > define a single :type ::ADT, and then sub-dispatch on e.g. :adt-type. That's not even necessary: I add a derive clause from ::adt to each of my data types and implement multimethods such as print-method for ::adt. Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Syntax-quote only as a reader macro?
I am trying to do the equivalent of a syntax-quote (converting unqualified symbols to namespace-qualified symbols) inside a macro, but it seems there is no built-in function to do this. Am I overlooking something? At the moment I am using the following function, which does a syntax- quote for a single symbol: (defn symbol-in-current-ns [s] (symbol (str *ns*) (str s))) Konrad. --~--~-~--~~~---~--~~ 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 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: Waterfront - The Clojure-based editor for Clojure
On Feb 26, 3:02 am, "Stephen C. Gilardi" wrote: > On Feb 24, 2009, at 6:47 PM, Itay Maman wrote: > > > This version is fully functional and so far I didn't encounter any > > bugs. > > I guess that over the course of the next few days, as people start > > using this version, > > a few issues may come up. I'd be glad to fix these. > > > I also took Mike's suggestion, Waterfromt's main window is now using > > a side-by-side layout. > > Hi Itay, > > Very nice work on waterfront! I gave it a try on Mac OS X. It worked > well and showcases many cool ideas. > > I had a couple of issues: > > - when building on Mac OS X with Java 6 64-bit or Java 5 32-bit, I got > errors like this one: > > [javac] Compiling 1 source file to /sq/ext/waterfront/waterfront/ > bin > [javac] /sq/ext/waterfront/lab/src/net/sourceforge/waterfront/ide/ > services/Main.java:92: method does not override a method from its > superclass > [javac] @Override > [javac] ^ > [javac] 1 error > > in every case where @Override was present in the waterfront source. In Java6 @Override can also be attached to a method that overrides an interface-declared method. So, the code is not supposed to compile w/ a Java5 compiler. As for the Java6 compiler, my guess is that your compile is configured to be Java5 complaint. So I would suggest to specify "-source 1.6" in the javac command line. Anyway, I will add it to the build.xml file. > > I was able to build successfully by commenting all of them out. > > - When using waterfront on Mac OS X, it appears that the control > characters intended to trigger menu selections (e.g. ^E) are being > intercepted before they reach the menus. In the specific case of ^E, > it is being interpreted by the text input field as "move to end of > line" which is a common meaning for it in Mac OS X. I suspect there is > a way to trigger menu items using the "command-key" on the Mac (while > still using the control key on Windows) and people using waterfront on > Mac OS X would benefit from a change to using that mechanism. Sure. > > Thanks very much for waterfront! You're very welcome. > > --Steve > > smime.p7s > 3KViewDownload --~--~-~--~~~---~--~~ 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 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: Waterfront - The Clojure-based editor for Clojure
On Feb 26, 2009, at 12:30, Itay Maman wrote: > In Java6 @Override can also be attached to a method that overrides an > interface-declared method. So, the code is not supposed to compile w/ > a Java5 compiler. As for the Java6 compiler, my guess is that your > compile is configured to be Java5 complaint. So I would suggest to > specify "-source 1.6" in the javac command line. Anyway, I will add it > to the build.xml file. Do you need Java 1.6 features? Clojure itself works fine with 1.5, and there are still machines around for which there is no 1.6 (my PPC Mac running MacOS 10.4, for example), so it would be nice if Waterfront could work with Java 1.5 as well. Konrad. --~--~-~--~~~---~--~~ 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 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: how to get concurrent - model design question
Hi Boris, > (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery- > host pair-host breakup-host] i world] > (send-off (agent nil) (fn [_] (e i)) > > There doesn't seem to be any concurrency happening, and the whole > thing just slows down to not doing much at all. This code will create potentially (count world) threads 1. Just using send instead of send-off would possibly speed things up a lot as it will limit the number of threads. Also creating a new agent every time just to provide a thread is not economical. You could instead have a small pool of agents and reuse them. Or you could take advantage of futures which have been recently added to run the task without an agent at all: (doseq [e [r s i n b] i world] (future (e i))) Also you might consider using (comp) to compose the set of e into one function, which will reduce the amount of dispatches. Lastly, why do you say you have to use refs here? It isn't obvious to me from the code - the world locations look like they could be agents - but I'm probably missing something, its quite complex :) Regards, Tim. --~--~-~--~~~---~--~~ 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 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: Syntax-quote only as a reader macro?
On Feb 26, 2009, at 12:26, Konrad Hinsen wrote: > At the moment I am using the following function, which does a syntax- > quote for a single symbol: > > (defn symbol-in-current-ns >[s] >(symbol (str *ns*) (str s))) Of course that should better be (defn qualified-symbol [s] (let [s-str (str s)] (if (.contains s-str "/") s (symbol (str *ns*) s-str so that it doesn't mess up already qualified symbols. Konrad. --~--~-~--~~~---~--~~ 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 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: Waterfront Assertion Failure
On Feb 26, 6:10 am, Itay Maman wrote: > Hi Onorio > > RC1-147 requires the use of Clojure's latest snapshot (can be obtained > from the SVN). > I figured that was probably the case but I thought you might want to know about the assertion failure in case it were some other issue. -- Onorio --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On Feb 26, 4:00 am, Konrad Hinsen wrote: > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > You raise interesting issues and I'd like to explore them further. I'm > > not sure the issues you have with type-tag-or-class dispatch are all > > that prohibitive. In any case, I've added a type function that returns > > the :type metadata or the class if none: > > Thanks, that helps a lot! With a built-in universal dispatching > function, most of my problems should be solved. Another useful > function to have would be > > (defn type-instance? >"Evaluates x and tests if it is an instance of the type or class t. > Returns true or false" >[t x] >(identical? t (type x))) > > for type-based dispatching inside a function. > I'm pretty sure you'd want that to use isa? 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 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: Algebraic data types in clojure.contrib
On Feb 26, 4:17 am, Laurent PETIT wrote: > 2009/2/26 Konrad Hinsen > > > > > > > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > > You raise interesting issues and I'd like to explore them further. I'm > > > not sure the issues you have with type-tag-or-class dispatch are all > > > that prohibitive. In any case, I've added a type function that returns > > > the :type metadata or the class if none: > > > Thanks, that helps a lot! With a built-in universal dispatching > > function, most of my problems should be solved. Another useful > > function to have would be > > > (defn type-instance? > > "Evaluates x and tests if it is an instance of the type or class t. > >Returns true or false" > > [t x] > > (identical? t (type x))) > > > for type-based dispatching inside a function. > > or maybe generalize the existing 'instance? function to the above definition > ? I'm not sure I'd want to do that. You'd still need actual class detectors. 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 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: Waterfront - The Clojure-based editor for Clojure
super slick, I love it! --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On Feb 26, 6:19 am, Konrad Hinsen wrote: > On Feb 26, 2009, at 1:51, Rich Hickey wrote: > > > You raise interesting issues and I'd like to explore them further. I'm > > not sure the issues you have with type-tag-or-class dispatch are all > > that prohibitive. In any case, I've added a type function that returns > > the :type metadata or the class if none: > > > user=> (type #^{:type ::Fred} [1 2 3]) > > :user/Fred > > > user=> (type "foo") > > java.lang.String > > > which should help people standardize. > > One inconvenience I noticed with types based on meta-data tags is > that the type information does not participate in equality tests. > This means I have to include the type information once again in the > value itself if I want to make sure that no other type's value > accidentally compare as identical to mine. > Well, you have to do something (type in value, or override equals) but I can't hardwire the relationship between type and equality, especially not as an identity compare. There is no general solution, else equals() wouldn't be overridable. Polymorphic equality is an important capability, e.g. so sets and maps with different implementations can interoperate. > > If you want to multiplex multimethods for your ADT type, you can just > > define a single :type ::ADT, and then sub-dispatch on e.g. :adt-type. > > That's not even necessary: I add a derive clause from ::adt to each > of my data types and implement multimethods such as print-method > for ::adt. > I know, just noting sub-dispatching is possible. 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 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: Is syntax quote "reader" only?
On Mon, Feb 16, 2009 at 8:31 PM, Brian Will wrote: > > I'm a bit mystified how syntax quote does what it does. I don't see > how syntax quote can quote the whole while unquoting parts without > some evaluation-time intervention. If I had to implement it myself, > I'd just punt the problem to evaluation-time by introducing a special > form 'unquote', e.g.: > > `(a b ~(c d)) > > (quote ((unquote a) 3 (unquote (c d))) > > But this isn't what Clojure does, so I'm wondering, how does syntax > quote do its business while remaining strictly a reader-time only > mechanism? Use the source, Luke. http://code.google.com/p/clojure/source/browse/trunk/src/jvm/clojure/lang/LispReader.java?r=1287#656 It looks like the reader reads the whole syntax-quoted form, and then walks it recursively looking for unquote forms. --Chouser --~--~-~--~~~---~--~~ 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 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: Waterfront Assertion Failure
On Feb 26, 2:11 pm, Onorio Catenacci wrote: > On Feb 26, 6:10 am, Itay Maman wrote: > > > Hi Onorio > > > RC1-147 requires the use of Clojure's latest snapshot (can be obtained > > from the SVN). > > I figured that was probably the case but I thought you might want to > know about the assertion failure in case it were some other issue. OK, I see your point now. -Itay > > -- > Onorio --~--~-~--~~~---~--~~ 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 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: Waterfront - The Clojure-based editor for Clojure
On Feb 26, 2:02 pm, Konrad Hinsen wrote: > On Feb 26, 2009, at 12:30, Itay Maman wrote: > > > In Java6 @Override can also be attached to a method that overrides an > > interface-declared method. So, the code is not supposed to compile w/ > > a Java5 compiler. As for the Java6 compiler, my guess is that your > > compile is configured to be Java5 complaint. So I would suggest to > > specify "-source 1.6" in the javac command line. Anyway, I will add it > > to the build.xml file. > > Do you need Java 1.6 features? Clojure itself works fine with 1.5, > and there are still machines around for which there is no 1.6 (my PPC > Mac running MacOS 10.4, for example), so it would be nice if > Waterfront could work with Java 1.5 as well. No I don't need Java6. My Eclipse is configured to be Java6-compliant so it generates these @Overrides annotations automatically. I agree with your point. I'll get rid of those. Coming to think about it, I don't even need the Java code so much. It is just a few classes which realize some low-level UI stuff which seemed to be more natural in Java than in Clojure. I do want to translate them to Clojure at some point. This will solve this issue altogether. -Itay --~--~-~--~~~---~--~~ 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 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: how to get concurrent - model design question
Thanks for the reply Timothy! I'll look into the future things :). The main reason for using refs was because I am constructing a contact network between different refs (a graph, consisting of nodes and edges.), which changes over time (all the short-term and long-term relations between hosts being started and breaking down again). If two of my refs start a steady relation together, I want a guarantee that one refers to the other in its :steady key, and the other refers to the one. So it seemed to me that both have to change simultaneously. I don't want host 1 to start initiating a steady relationship with host 2, while at the same time host 2 is starting one with host 3. I wrote an earlier version of this model with agents, but couldn't see how to guarantee bidirectional edges in a concurrent situation. On Feb 26, 12:59 pm, Timothy Pratley wrote: > Hi Boris, > > > (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery- > > host pair-host breakup-host] i world] > > (send-off (agent nil) (fn [_] (e i)) > > > There doesn't seem to be any concurrency happening, and the whole > > thing just slows down to not doing much at all. > > This code will create potentially (count world) threads 1. Just > using send instead of send-off would possibly speed things up a lot as > it will limit the number of threads. Also creating a new agent every > time just to provide a thread is not economical. You could instead > have a small pool of agents and reuse them. Or you could take > advantage of futures which have been recently added to run the task > without an agent at all: > (doseq [e [r s i n b] i world] (future (e i))) > Also you might consider using (comp) to compose the set of e into one > function, which will reduce the amount of dispatches. Lastly, why do > you say you have to use refs here? It isn't obvious to me from the > code - the world locations look like they could be agents - but I'm > probably missing something, its quite complex :) > > Regards, > Tim. --~--~-~--~~~---~--~~ 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 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: new laziness: terminology help
On Feb 25, 8:02 pm, Mark Engelberg wrote: > On Wed, Feb 25, 2009 at 6:59 AM, Stuart Halloway > > > I believe it would be simpler to leave out this footnote. In my > > perfect world, seq/ISeq/sequence are synonyms, and nillability is a > > property only of *functions*: seq and next. > > I understand why it is useful to use the noun "seq" to mean the forced > non-nil non-empty sequences that are returned by the seq function. > But I think it's going to be very confusing if you use the term seq to > mean something different than what "seq?" tests for. So I'd vote for > either Stuart's interpretation, or changing the name "seq?" to > something like "sequence?" (which I think it was at one stage of > development). I'm fine with Stuart's interpretation. People need to resist their urge to superimpose types that don't exist on the return values of functions. There is only ISeq. And some function might return one or not. 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 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: Waterfront - The Clojure-based editor for Clojure
2009/2/26 Itay Maman > > > > On Feb 26, 2:02 pm, Konrad Hinsen wrote: > > On Feb 26, 2009, at 12:30, Itay Maman wrote: > > > > > In Java6 @Override can also be attached to a method that overrides an > > > interface-declared method. So, the code is not supposed to compile w/ > > > a Java5 compiler. As for the Java6 compiler, my guess is that your > > > compile is configured to be Java5 complaint. So I would suggest to > > > specify "-source 1.6" in the javac command line. Anyway, I will add it > > > to the build.xml file. > > > > Do you need Java 1.6 features? Clojure itself works fine with 1.5, > > and there are still machines around for which there is no 1.6 (my PPC > > Mac running MacOS 10.4, for example), so it would be nice if > > Waterfront could work with Java 1.5 as well. > > No I don't need Java6. My Eclipse is configured to be Java6-compliant > so it generates What ? You used Eclipse, and still wanted to get rid of it and of clojuredev ! How sad I am ... ;-) I've taken a look at what you've done, wow ! How long did it take to realize that ? Were you working on it daily, or nightly ? Keep up the good work ! -- Laurent > > these @Overrides annotations automatically. I agree with your point. > I'll get rid of those. > > Coming to think about it, I don't even need the Java code so much. It > is just a few classes > which realize some low-level UI stuff which seemed to be more natural > in Java than in Clojure. > I do want to translate them to Clojure at some point. This will solve > this issue altogether. > > -Itay > > > > --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
2009/2/26 Rich Hickey > > > > On Feb 26, 4:17 am, Laurent PETIT wrote: > > 2009/2/26 Konrad Hinsen > > > > > > > > > > > > > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > > > > You raise interesting issues and I'd like to explore them further. > I'm > > > > not sure the issues you have with type-tag-or-class dispatch are all > > > > that prohibitive. In any case, I've added a type function that > returns > > > > the :type metadata or the class if none: > > > > > Thanks, that helps a lot! With a built-in universal dispatching > > > function, most of my problems should be solved. Another useful > > > function to have would be > > > > > (defn type-instance? > > > "Evaluates x and tests if it is an instance of the type or class t. > > >Returns true or false" > > > [t x] > > > (identical? t (type x))) > > > > > for type-based dispatching inside a function. > > > > or maybe generalize the existing 'instance? function to the above > definition > > ? > > I'm not sure I'd want to do that. You'd still need actual class > detectors. But the definition and implementation of the above 'type-instance? function works for classes, and I don't think the point of the current instance? is to check that the given class parameter is a real class or not ? It is checking the type of the instance passed to it ? Or am I missing something ? > > > 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 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: The Sequential interface (implementation question)
On Feb 26, 12:00 am, dmiller wrote: > Regarding the Sequential interface: > > There are a number of places where (x instanceof Sequential) is taken > to imply something else about x: > > (a) that casting in the form of ((IPersistentCollection)x) is okay, > or > (b) that RT.seq(x) will succeed, or > (c) that Rt.count(x) will succeed > > Note that (a) implies (b) and (c). > > In arbitrary code, these conclusions do not necessarily follow. > > Occurrences (same in both pre- and post-lazy change codebases) > > Type (a): > > APersistentVector.doEquals > APersistentVector.doEquiv > PersistentQueue.equals > PersistentQueue.equiv > RT.nth > > Type (b): > > ASeq.equals > ASeq.equiv > > Type (c): > > PersistentList.EmptyList.equals > > Sample code: PersistentQueue.equals: > > public boolean equals(Object obj){ > > if(!(obj instanceof Sequential)) > return false; > ISeq ms = ((IPersistentCollection) obj).seq(); > ... > > } > > Sample code: ASeq.equiv: > > public boolean equiv(Object obj){ > > if(!(obj instanceof Sequential || obj instanceof List)) > return false; > ISeq ms = RT.seq(obj); > ... > > The following interfaces extend Sequential: IPersistentList, > IPersistentVector, ISeq > > In core.clj, Sequential is used only in the definition of (sequential? > x). > > Why does Sequential exist at all? Why not just use > IPersistentCollection? > Are the listed interfaces the only ones intended to extend Sequential? > Is there an implicit charge to anyone extending/implementing > Sequential to guarantee (a), (b), (c)? > > Put another way, is there any meaning to being Sequential but not > IPersistentCollection? > Sequential is a marker interface. It doesn't imply the success of casts that follow it, they are independent tests. Sequential is used to help partition the collections space for equality purposes, so sequentials/sets/maps are never equal to things outside of their 'category'. Sequential unifies vectors/lists/seqs. Chouser did a great graph: http://github.com/Chouser/clojure-classes/raw/master/graph-w-legend.png 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 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: Algebraic data types in clojure.contrib
Would it make sense to make instance?/type-instance?/type .. multimethods themselves ? 2009/2/26 Konrad Hinsen > > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > You raise interesting issues and I'd like to explore them further. I'm > > not sure the issues you have with type-tag-or-class dispatch are all > > that prohibitive. In any case, I've added a type function that returns > > the :type metadata or the class if none: > > Thanks, that helps a lot! With a built-in universal dispatching > function, most of my problems should be solved. Another useful > function to have would be > > (defn type-instance? > "Evaluates x and tests if it is an instance of the type or class t. >Returns true or false" > [t x] > (identical? t (type x))) > > for type-based dispatching inside a function. > > > I'm not sure the mechanism you are using (actual Class types) allows > > for any more overloading - Class is a single slot too, after all. > > True, but the number of classes is not limited. Java programmers can > live with a single class hierarchy, so it can't be too bad. But > Clojure's hierarchies are definitely more flexible. > > > A bigger problem with the mechanism you've chosen is its dependence on > > some implementation details. I haven't promised, e.g. that every fn > > generates a unique class type. > > I know, but as I said, my current implementation is just a proof of > concept. It is not viable for production use for a variety of > reasons. I was planning to replace it by something based on gen-class > and proxy, but I will first try to get away with the new type function. > > Konrad. > > > > --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On Feb 26, 8:30 am, Laurent PETIT wrote: > 2009/2/26 Rich Hickey > > > > > > > On Feb 26, 4:17 am, Laurent PETIT wrote: > > > 2009/2/26 Konrad Hinsen > > > > > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > > > > You raise interesting issues and I'd like to explore them further. > > I'm > > > > > not sure the issues you have with type-tag-or-class dispatch are all > > > > > that prohibitive. In any case, I've added a type function that > > returns > > > > > the :type metadata or the class if none: > > > > > Thanks, that helps a lot! With a built-in universal dispatching > > > > function, most of my problems should be solved. Another useful > > > > function to have would be > > > > > (defn type-instance? > > > > "Evaluates x and tests if it is an instance of the type or class t. > > > >Returns true or false" > > > > [t x] > > > > (identical? t (type x))) > > > > > for type-based dispatching inside a function. > > > > or maybe generalize the existing 'instance? function to the above > > definition > > > ? > > > I'm not sure I'd want to do that. You'd still need actual class > > detectors. > > But the definition and implementation of the above 'type-instance? function > works for classes, and I don't think the point of the current instance? is > to check that the given class parameter is a real class or not ? It is > checking the type of the instance passed to it ? > > Or am I missing something ? > The definition above is definitely broken in using identical? I'll think about extending instance? to use type + isa? 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 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: Mini-Kanren
Hi Jim, On Feb 25, 6:38 pm, jim wrote: > I've just uploaded a file that has the Mini-Kanren logic programming > system described in "The Reasoned Schemer" implemented in idiomatic > Clojure. The file is: > > http://clojure.googlegroups.com/web/mini_kanren.clj > I'm still reading my way through it, but so far, this caught my eye: "In Scheme, passing cons one parameter encloses that parameter in a list, essentially cons'ing it to an empty list" As far as I know, no Scheme implementation does that. a cons is strictly a pair of two things, where the idiomatic usage is that the second thing is either another cons or the empty list, thus forming a proper list, versus a list terminated by a dotted pair, which is an improper list. (list x), in both Scheme and Clojure, produces a list with one item in it. Regards, -- Michel S. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
function call preconditions
Hello, While not checking types at compile time, it seems to me that a lot of clojure code still needs in the docstring some sort of "preconditions warnings". For example, that you can't pass a first argument if it cannot be callable as a function, or if it cannot succeed the (seq) test ... Couldn't it be great if such a knowledge wasn't captured in the doc string, but in something that could be more useful (optionally of course, for performance purposes) : some sort of optional precondition part of the function/macro definition. Of course, this would then be written in clojure itself. This information could then be : * added at the beginning or end of the docstring (or put in another docstring) at compilation time * added as an optional precondition check each time the function is called (activable globally via some global var that could be named *check-preconditions* for example) Indeed, I guess it's easier to fail quickly when something goes wrong, but if the argument is passed over some other function, and used later in some agent, or deeper in the code, I guess it is sometimes hard to identify where things started to go wrong (or maybe it is not such a problem with clojure ?) I feel sorry to see and place in the docstrings structured information that could be (optionally, of course) expressed in a more structured format ... What do you think about that ? Regards, -- Laurent --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
2009/2/26 Rich Hickey > > > > On Feb 26, 8:30 am, Laurent PETIT wrote: > > 2009/2/26 Rich Hickey > > > > > > > > > > > > > On Feb 26, 4:17 am, Laurent PETIT wrote: > > > > 2009/2/26 Konrad Hinsen > > > > > > > On 26.02.2009, at 01:51, Rich Hickey wrote: > > > > > > > > You raise interesting issues and I'd like to explore them > further. > > > I'm > > > > > > not sure the issues you have with type-tag-or-class dispatch are > all > > > > > > that prohibitive. In any case, I've added a type function that > > > returns > > > > > > the :type metadata or the class if none: > > > > > > > Thanks, that helps a lot! With a built-in universal dispatching > > > > > function, most of my problems should be solved. Another useful > > > > > function to have would be > > > > > > > (defn type-instance? > > > > > "Evaluates x and tests if it is an instance of the type or class > t. > > > > >Returns true or false" > > > > > [t x] > > > > > (identical? t (type x))) > > > > > > > for type-based dispatching inside a function. > > > > > > or maybe generalize the existing 'instance? function to the above > > > definition > > > > ? > > > > > I'm not sure I'd want to do that. You'd still need actual class > > > detectors. > > > > But the definition and implementation of the above 'type-instance? > function > > works for classes, and I don't think the point of the current instance? > is > > to check that the given class parameter is a real class or not ? It is > > checking the type of the instance passed to it ? > > > > Or am I missing something ? > > > > The definition above is definitely broken in using identical? > > I'll think about extending instance? to use type + isa? Yes, I agree. I hadn't realized the above definition was broken, and was speaking about its purpose that I indeed thought could be integrated in instance? without breaking instance? semantics nor existing code. -- Laurent > > > 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 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: Extensive use of let?
Very interesting ideas, everyone... thanks a lot for the input. Yeah, I recognize that each case is going to be different - I guess I was just looking for suggestions on how to manage it. Which I found... Comp and partial look particularly interesting. Thanks! -Luke On Feb 25, 5:09 pm, Kevin Downey wrote: > You should look at "->" > it lest you take (op3 (op2 (op1 input))) and write it as (-> input op1 op2 > op3) > there is also "comp" which composes functions, and partial for partial > application. > > some example comp > usage:http://github.com/hiredman/clojurebot/blob/297e266b0badf0f301a556e957... > > > > > > On Wed, Feb 25, 2009 at 12:57 PM, levand wrote: > > > Recently, in my code, I have been struggling with which of the two > > equivalent forms is, in a general sense, "better". > > > (defn my-fn1 [input] > > (let [value1 (op1 input) > > value2 (op2 input) > > value3 (op4 value1 value2)] > > (op5 value3))) > > > (defn my-fn2 [input] > > (op5 (op4 (op1 input) (op2 input > > > Now, the second is definitely cleaner and more elegant, besides being > > smaller, which is a non-trivial benefit when I have a fair amount of > > code to page through. > > > However, if I've been away from the code awhile, it's much easier to > > come back determine what the code is doing when its written the first > > way, especially when it uses descriptive names. An operation that is > > impenetrable when written in nested form can become quite simple when > > each step is broken down and labeled. > > > Clojure is my first Lisp - should I just stick with the second form > > until I learn to "see through" the nested s-expressions? > > > It's not that I'm trying to make my code more imperative - Although I > > come from a Java background, I love functional programming, and it is > > a delight to see how much I can do without side-effects. But I do miss > > the self-documentation that well-named variables can provide. > > > Any thoughts? Also, is there any performance degradation from the > > first way, or can the compiler optimize it away? > > -- > 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 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: Clojure plugin for IntelliJ IDEA published
Hello. Simplest way to run empty REPL is to create empty Clojure script and invoke new run configuration on it (marking appropriate checkbox in configuration settings). In next version we're going to integrate support for background REPL, but for now we have no, so there is no possibility to load some file or Sexpr from editor by keyboard shortcut. You should restart script or paste Sexpr to REPL console manually. So, a support for this feature is a min priority for now. As for parentheses, what kind of support do you mean? We're going to implement so-called "surround with" feature, to help simply surround selected code fragment with parentheses. for now you can use Ctrl-W shortcut to select nested forms incrementally in editor. With best regards, Ilya Sergey On Feb 26, 7:48 am, CuppoJava wrote: > Hi Ilya, > I also just started using the plugin and it's very good. Thank you for > this great plugin. > I have a few questions about how to use it though: > > How to I start a REPL without loading a script? Just a blank slate > REPL? > Is there a shortcut for Sending current sexp, or selected text to > REPL? > > May I ask what your upcoming priorities are for the project? I would > love for a basic Paredit to be supported. Parenthesis are just too > much trouble to maintain manually. > > Thanks again for the great work > -Patrick --~--~-~--~~~---~--~~ 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 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: Waterfront - The Clojure-based editor for Clojure
> > What ? You used Eclipse, and still wanted to get rid of it and of clojuredev > ! How sad I am ... ;-) :)) > > I've taken a look at what you've done, wow ! > > How long did it take to realize that ? Were you working on it daily, or > nightly ? I had a couple of weeks off at Dec. Since Jan. it is mostly night- time. > > Keep up the good work ! Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Syntax-quote only as a reader macro?
On Feb 26, 2009, at 13:04, Konrad Hinsen wrote: > Of course that should better be ... > > so that it doesn't mess up already qualified symbols. And even that is not good enough: it won't handle symbols/vars from other namespaces that are referred to. And that's where I am lost. I can't find any way to obtain the qualified symbol that an unqualified one would resolve to. There are a couple of ways to get the var it refers to (for example ns-resolve), but I don't want the var, I want the symbol, for use in a macro. I checked the compiler source code and found clojure.lang.Compiler.resolveSymbol, which does exactly what I need, but it's not public. I figured out one way to do it, but it relies on features that are perhaps not safe to rely on: I get var first, and then I get the var's namespace from its public attribute ns: (defn qualified-symbol [s] (if-let [var (resolve s)] (symbol (str (.ns var)) (str (.sym var))) s)) This seems to work fine for all cases I can imagine. But I'd love to see a cleaner way to do this. Konrad. --~--~-~--~~~---~--~~ 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 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: Mini-Kanren
I don't have a Scheme here to check it out, but doesn't (cons 1) yield '(1) or am I wrong? In either case how could it be stated more accurately/clearly? Thanks Jim On Feb 26, 7:52 am, "Michel S." wrote: > Hi Jim, > > "In Scheme, passing cons one parameter encloses that parameter in a > list, essentially cons'ing it to an empty list" > > As far as I know, no Scheme implementation does that. a cons is > strictly a pair of two things, where the idiomatic usage is that the > second thing is either another cons or the empty list, thus forming a > proper list, versus a list terminated by a dotted pair, which is an > improper list. > > (list x), in both Scheme and Clojure, produces a list with one item in > it. > > Regards, > > -- > Michel S. --~--~-~--~~~---~--~~ 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 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: Mini-Kanren
On Thu, Feb 26, 2009 at 4:03 PM, jim wrote: > > I don't have a Scheme here to check it out, but doesn't > > (cons 1) > > yield > > '(1) no. in scheme (and in all modern lisps), cons is a 2 arguments procedure. Giving it 1 is an error. Some very old lisp dialects supplied NIL in place of missing arguments. In these lisps (cons 1) was equivalent to (cons 1 nil) Cheers P. --~--~-~--~~~---~--~~ 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 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: Clojure documentation problems
On Wed, Feb 25, 2009 at 6:00 AM, David Sletten wrote: > > Whoops...it's "rational?" that was missing from the API page and > still is. The API page is programmaticly generated from the docstrings, but like the rest of the site generally reflects the latest release, not the latest svn version. --Chouser --~--~-~--~~~---~--~~ 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 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: Mini-Kanren
Looking at the code, lcons does indeed require two parms. I must've been zoned out when I wrote the comment. Thanks for catching that. On Feb 26, 9:10 am, Pierpaolo Bernardi wrote: > no. in scheme (and in all modern lisps), cons is a 2 arguments procedure. > Giving it 1 is an error. > > Some very old lisp dialects supplied NIL in place of missing arguments. In > these lisps > (cons 1) was equivalent to (cons 1 nil) > > Cheers > P. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Richer 'partial'
Hi all, I could use a version of 'partial' that would allow me to: - Partially apply a function to any of its arguments, not just the first one - 'Unapply' a partially-applied function from one of its arguments. Is any such thing already available? Thanks, Anand --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
2009/2/26 Anand Patil > > Hi all, > > I could use a version of 'partial' that would allow me to: > > - Partially apply a function to any of its arguments, not just the > first one That's already the case, haven't you made a little test ? > > - 'Unapply' a partially-applied function from one of its arguments. Not possible as far as I know. Could you please explain use cases you have in mind for such a feature ? > > > Is any such thing already available? > > Thanks, > Anand > > > --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
"partial" is a currying function. It can be provided any number of parameter(s), but it is always behaves sequentially from start to finish. That is what currying *is*. You can easily partially apply to other arguments by doing this: #(fred %1 some-arg %2 other-arg). "partial" could not easily support "unapplying" it. On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil < anand.prabhakar.pa...@gmail.com> wrote: > > Hi all, > > I could use a version of 'partial' that would allow me to: > > - Partially apply a function to any of its arguments, not just the > first one > - 'Unapply' a partially-applied function from one of its arguments. > > Is any such thing already available? > > Thanks, > Anand > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
some vs. contains? for a list
I thought for sure it would be faster to use "some" to determine whether an item was in a list rather than convert the list to a set and then use "contains?", but it turns out I was wrong. The latter approach takes about 1/3 to 1/2 the time! This is the case even when the list contains 100 items. Of course I realize that if this is a commonly needed operation for a particular collection, it's better to use a set instead of a list in the first place. (def stooges (list "Moe" "Larry" "Curly")) (time (some #(= % "Curly") stooges)) (time (contains? (set stooges) "Curly")) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
2009/2/26 Jeffrey Straszheim > "partial" is a currying function. It can be provided any number of > parameter(s), but it is always behaves sequentially from start to finish. > That is what currying *is*. > Ah, I thought currying / uncurrying what the term reserved for this operation (as I remember from Haskell) that changes the arity of functions ( transforming and untransforming a function of n parameters into a function of a tuple of n elements) ? > > You can easily partially apply to other arguments by doing this: #(fred %1 > some-arg %2 other-arg). > > "partial" could not easily support "unapplying" it. > > On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil < > anand.prabhakar.pa...@gmail.com> wrote: > >> >> Hi all, >> >> I could use a version of 'partial' that would allow me to: >> >> - Partially apply a function to any of its arguments, not just the >> first one >> - 'Unapply' a partially-applied function from one of its arguments. >> >> Is any such thing already available? >> >> Thanks, >> Anand >> >> > > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
"Adding" strings
Hey all, What is the idiomatic way to concatenate strings? Here are some things that I expected to work, but didn't (+ "foo" "bah") (conj "foo" "bah") (into "foo" "bah") For the moment I am doing (.concat "foo" "bah") But it seems wrong Thanks P --~--~-~--~~~---~--~~ 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 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: "Adding" strings
(str "foo" "bah") and if you have a collection you can (apply str coll) HTH, -- Laurent 2009/2/26 Peter Wolf > > Hey all, > > What is the idiomatic way to concatenate strings? Here are some things > that I expected to work, but didn't > >(+ "foo" "bah") >(conj "foo" "bah") >(into "foo" "bah") > > For the moment I am doing > >(.concat "foo" "bah") > > But it seems wrong > > Thanks > P > > > > > > --~--~-~--~~~---~--~~ 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 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: "Adding" strings
On Feb 26, 5:11 pm, Peter Wolf wrote: > What is the idiomatic way to concatenate strings? Here are some things > that I expected to work, but didn't > > (+ "foo" "bah") > (conj "foo" "bah") > (into "foo" "bah") > > For the moment I am doing > > (.concat "foo" "bah") (str "foo" "bah") --~--~-~--~~~---~--~~ 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 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: "Adding" strings
On Thu, Feb 26, 2009 at 11:11 AM, Peter Wolf wrote: > > Hey all, > > What is the idiomatic way to concatenate strings? Here are some things > that I expected to work, but didn't > >(+ "foo" "bah") >(conj "foo" "bah") >(into "foo" "bah") > > For the moment I am doing > >(.concat "foo" "bah") > > But it seems wrong > > Thanks > P > Try (str "foo" "bah"). --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
Thanks for the responses, guys. >> - Partially apply a function to any of its arguments, not just the >> first one >That's already the case, haven't you made a little test ? I meant I want to apply it out of sequence, sorry. > You can easily partially apply to other arguments by doing this: #(fred %1 > some-arg %2 other-arg). That makes sense, thanks, though it's not any easier to unapply than partial. I guess I could make a new 'partial-like' function that returns code to apply a function, with nil's in unapplied argument slots... ? > Not possible as far as I know. Could you please explain use cases you have > in mind for such a feature ? Sure, it's the lazy cells I've been working on. When a cell's parent changes, I don't want it to compute right away- I want it to register the fact that the parent has changed, switch to an 'unevaluated' state, and 'unapply' its childrens' update functions on itself. I won't explain how I'm doing it right now for fear of muddying the waters, but it feels overcomplicated and un-idiomatic. Thanks, Anand --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
Thanks for the responses, guys. >> - Partially apply a function to any of its arguments, not just the >> first one >That's already the case, haven't you made a little test ? I meant I want to apply it out of sequence, sorry. > You can easily partially apply to other arguments by doing this: #(fred %1 > some-arg %2 other-arg). That makes sense, thanks, though it's not any easier to unapply than partial. I guess I could make a new 'partial-like' function that returns code to apply a function, with nil's in unapplied argument slots... ? > Not possible as far as I know. Could you please explain use cases you have > in mind for such a feature ? Sure, it's the lazy cells I've been working on. When a cell's parent changes, I don't want it to compute right away- I want it to recognize the new value, but switch to an un-evaluated state. Since the cell has no value, it would be nice if its children could just un-apply their update functions on it. I won't explain how I'm doing it right now for fear of muddying the waters, but it feels overcomplicated and un-idiomatic. Thanks, Anand On Feb 26, 4:00 pm, Laurent PETIT wrote: > 2009/2/26 Jeffrey Straszheim > > > "partial" is a currying function. It can be provided any number of > > parameter(s), but it is always behaves sequentially from start to finish. > > That is what currying *is*. > > Ah, I thought currying / uncurrying what the term reserved for this > operation (as I remember from Haskell) that changes the arity of functions ( > transforming and untransforming a function of n parameters into a function > of a tuple of n elements) ? > > > > > You can easily partially apply to other arguments by doing this: #(fred %1 > > some-arg %2 other-arg). > > > "partial" could not easily support "unapplying" it. > > > On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil < > > anand.prabhakar.pa...@gmail.com> wrote: > > >> Hi all, > > >> I could use a version of 'partial' that would allow me to: > > >> - Partially apply a function to any of its arguments, not just the > >> first one > >> - 'Unapply' a partially-applied function from one of its arguments. > > >> Is any such thing already available? > > >> Thanks, > >> Anand --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
Sorry, I thought I had pushed 'stop' in time to stop the first response. On Feb 26, 4:16 pm, Anand Patil wrote: > Thanks for the responses, guys. > > >> - Partially apply a function to any of its arguments, not just the > >> first one > >That's already the case, haven't you made a little test ? > > I meant I want to apply it out of sequence, sorry. > > > You can easily partially apply to other arguments by doing this: #(fred %1 > > some-arg %2 other-arg). > > That makes sense, thanks, though it's not any easier to unapply than > partial. I guess I could make a new 'partial-like' function that > returns code to apply a function, with nil's in unapplied argument > slots... ? > > > Not possible as far as I know. Could you please explain use cases you have > > in mind for such a feature ? > > Sure, it's the lazy cells I've been working on. When a cell's parent > changes, I don't want it to compute right away- I want it to recognize > the new value, but switch to an un-evaluated state. Since the cell has > no value, it would be nice if its children could just un-apply their > update functions on it. > > I won't explain how I'm doing it right now for fear of muddying the > waters, but it feels overcomplicated and un-idiomatic. > > Thanks, > Anand > > On Feb 26, 4:00 pm, Laurent PETIT wrote: > > > 2009/2/26 Jeffrey Straszheim > > > > "partial" is a currying function. It can be provided any number of > > > parameter(s), but it is always behaves sequentially from start to finish. > > > That is what currying *is*. > > > Ah, I thought currying / uncurrying what the term reserved for this > > operation (as I remember from Haskell) that changes the arity of functions ( > > transforming and untransforming a function of n parameters into a function > > of a tuple of n elements) ? > > > > You can easily partially apply to other arguments by doing this: #(fred %1 > > > some-arg %2 other-arg). > > > > "partial" could not easily support "unapplying" it. > > > > On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil < > > > anand.prabhakar.pa...@gmail.com> wrote: > > > >> Hi all, > > > >> I could use a version of 'partial' that would allow me to: > > > >> - Partially apply a function to any of its arguments, not just the > > >> first one > > >> - 'Unapply' a partially-applied function from one of its arguments. > > > >> Is any such thing already available? > > > >> Thanks, > > >> Anand --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
On Feb 26, 9:24 am, Anand Patil wrote: > Hi all, > > I could use a version of 'partial' that would allow me to: > > - Partially apply a function to any of its arguments, not just the > first one > - 'Unapply' a partially-applied function from one of its arguments. > > Is any such thing already available? Other people have explained currying and partial application, and why it doesn't normally spply the feature you want. Normally, in a lnaguage that supplies partial application, the way to achieve the effect you want is to use combinators that change the order of arguments. A combinator is a function whose arguments are functions, and whose return value is a function; partial is a combinator. Suppose you have a function that works like this: (foo x y) ...and you want to partially apply foo, but the argument you want to apply it to is the y argument, not the x argument. You can't, because partially applying foo will apply it to the x argument. What you need is a combinator that reverses the order of foo's arguments. You want to call (swap foo) and get back a function that works exactly like foo, except that it taks arguments y x instead of x y. It turns out that this is easy to write: (defn swap [f] (fn [y x] (f x y))) swap is the combinator you need in this case. You can get the effect described above by doing (partial (swap f) y) So, to get the effect you want, figure out the transformation you would need on the argument list and write a combinator that implements it. --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
On Feb 26, 4:41 pm, mikel wrote: > Other people have explained currying and partial application, and why > it doesn't normally spply the feature you want. I'd be interested in reading about this if you know of a link. > Normally, in a lnaguage that supplies partial application, the way to > achieve the effect you want is to use combinators that change the > order of arguments. OK, that sounds like a clean functional way to do it. Thanks. Anand --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
Nice initiative! However, it the net-ssh dependency has problems: [cvh: ~]$ sudo gem install djspiewak-buildr ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem) On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak wrote: > > I'm pleased to announce preliminary (and very experimental) support > for the Clojure AOT compiler and REPL within Apache Buildr (http:// > buildr.apache.org). At present, this support is only available within > my Git fork available here: git://github.com/djspiewak/buildr.git > More specifically, Clojure support is available within the "clojure" > and "master" branches ("master" branch alone contains REPL support). > It should be possible to install this particular version of Buildr by > using the following commands, though I'm honestly not sure how up to > date GitHub's gem repository is: > > gem sources -a http://gems.github.com > sudo gem install djspiewak-buildr > > Once installed, Clojure support is activated in a project simply by > storing your .clj scripts within the src/main/clojure directory. Note > that the (ns) directive will need to match the subdirectory, otherwise > compilation will fail. By default, every script is compiled to the > target/classes directory. Namespaces are auto-detected from the > directory structure. Only updated files are re-compiled (based on > mtime of .clj file and its corresponding *__init.class). If you wish > to override the auto-detection and specify a reduced set of > namespaces, it can be done using the `compile.using` directive within > your project definition in your buildfile. Thusly: > > define 'clojure-contrib' do > compile.using :libs => ['clojure.contrib.command-line', > 'clojure.contrib.mmap'] > end > > Any scripts which are *not* pre-compiled will be copied verbatim to > the target/classes directory w.r.t. their position in the directory > structure. Note that you will need to have set CLOJURE_HOME for this > to work. > > You will have to be using the "master" branch from my git repository > in order to use the Clojure REPL through Buildr (or install via the > gem command given above). To invoke, simply run the following command > somewhere in your project hierarchy: > > buildr shell > > This will launch the Clojure REPL pointing at your project's > dependencies and the updated target/classes directory (compilation is > re-run if necessary). Additionally, if you have a valid license for > JavaRebel, you can make use of it with the REPL by setting the > REBEL_HOME environment variable. > > Note that you cannot mix Java and Clojure sources within the same > project. Aww... :( > However, this is fairly easy to overcome by splitting the > languages into separate sub-projects. Thus, your top-level project > might contain all of your Clojure sources, while the sub-project might > contain Java. There are more details regarding this process on the > Buildr project page. > > One thing to keep in mind is that Buildr was designed to serve as a > build system for more static languages (specifically: Java, Scala, > Groovy). Thus, it is pre-biased toward things like a separate > compilation phase (the REPL points to target/classes rather than src/ > main/clojure). > > Fair warning: this language support is *extremely* experimental and > probably not too reliable at this point. Also note that while it is > possible that Clojure support will be merged into the Buildr trunk in > future, it has not yet been decided one way or another (see > https://issues.apache.org/jira/browse/BUILDR-259). Use at your own > risk! > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On Feb 25, 6:51 pm, Rich Hickey wrote: > user=> (type #^{:type ::Fred} [1 2 3]) > :user/Fred This is extremely appealing, as David said, for those of us building type systems for our application data. There's one wart for my particular use: (binding [*print-dup* true] (prn-str #^{:type ::Fred} [1 2 3])) java.lang.StackOverflowError (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] Oops. Can't serialize an object with attached metadata. --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
Thanks for the insight, Konrad. I know this is a sideshow to the larger discussion on types, but it does present an unexpected usability issue. On 26 February 2009 at 02:44, Konrad Hinsen wrote: > The fix is to provide a default implementation for print-method. Try > executing this: > > (defmethod print-method :default [o w] (print-method "failed" w)) This prevents the stack overflow. But I'd prefer a more forgiving default print behavior. > There should be a default in clojure.core, but I am not > sure what it should best be. Should it print the object stripped of > its metadata? I vote for this. A default that re-dispatches on class (as you suggested, stripping the :type metadata), falls back to the previous print behavior. (defmethod print-method :default [o, #^java.io.Writer w] (if (:type (meta o)) (print-method (with-meta o (dissoc (meta o) :type)) w) (do (.write w "#<") (.write w (.getSimpleName (class o))) (.write w " ") (.write w (str o)) (.write w ">" --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
Odd. Must be a problem with RubyForge. If you try again, does it work? Daniel On Feb 26, 10:58 am, Christian Vest Hansen wrote: > Nice initiative! > > However, it the net-ssh dependency has problems: > > [cvh: ~]$ sudo gem install djspiewak-buildr > ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) > timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem) > > > > On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak wrote: > > > I'm pleased to announce preliminary (and very experimental) support > > for the Clojure AOT compiler and REPL within Apache Buildr (http:// > > buildr.apache.org). At present, this support is only available within > > my Git fork available here: git://github.com/djspiewak/buildr.git > > More specifically, Clojure support is available within the "clojure" > > and "master" branches ("master" branch alone contains REPL support). > > It should be possible to install this particular version of Buildr by > > using the following commands, though I'm honestly not sure how up to > > date GitHub's gem repository is: > > > gem sources -ahttp://gems.github.com > > sudo gem install djspiewak-buildr > > > Once installed, Clojure support is activated in a project simply by > > storing your .clj scripts within the src/main/clojure directory. Note > > that the (ns) directive will need to match the subdirectory, otherwise > > compilation will fail. By default, every script is compiled to the > > target/classes directory. Namespaces are auto-detected from the > > directory structure. Only updated files are re-compiled (based on > > mtime of .clj file and its corresponding *__init.class). If you wish > > to override the auto-detection and specify a reduced set of > > namespaces, it can be done using the `compile.using` directive within > > your project definition in your buildfile. Thusly: > > > define 'clojure-contrib' do > > compile.using :libs => ['clojure.contrib.command-line', > > 'clojure.contrib.mmap'] > > end > > > Any scripts which are *not* pre-compiled will be copied verbatim to > > the target/classes directory w.r.t. their position in the directory > > structure. Note that you will need to have set CLOJURE_HOME for this > > to work. > > > You will have to be using the "master" branch from my git repository > > in order to use the Clojure REPL through Buildr (or install via the > > gem command given above). To invoke, simply run the following command > > somewhere in your project hierarchy: > > > buildr shell > > > This will launch the Clojure REPL pointing at your project's > > dependencies and the updated target/classes directory (compilation is > > re-run if necessary). Additionally, if you have a valid license for > > JavaRebel, you can make use of it with the REPL by setting the > > REBEL_HOME environment variable. > > > Note that you cannot mix Java and Clojure sources within the same > > project. > > Aww... :( > > > > > However, this is fairly easy to overcome by splitting the > > languages into separate sub-projects. Thus, your top-level project > > might contain all of your Clojure sources, while the sub-project might > > contain Java. There are more details regarding this process on the > > Buildr project page. > > > One thing to keep in mind is that Buildr was designed to serve as a > > build system for more static languages (specifically: Java, Scala, > > Groovy). Thus, it is pre-biased toward things like a separate > > compilation phase (the REPL points to target/classes rather than src/ > > main/clojure). > > > Fair warning: this language support is *extremely* experimental and > > probably not too reliable at this point. Also note that while it is > > possible that Clojure support will be merged into the Buildr trunk in > > future, it has not yet been decided one way or another (see > >https://issues.apache.org/jira/browse/BUILDR-259). Use at your own > > risk! > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
Wow, great ! Some notes I took while reading your e-mail : (those are some pitfalls I came through while implementing clojuredev's eclipse auto-build feature) * does it support namespaces separated in several files (handling files that begin with 'in-ns, or just not trying to compile them ?) * if so, will it support the scenario of multiple files per ns, where just another file (and not the file defining the ns) is modified ? * there is also another problem : if some macros are defined in a namespace A, used in a namespace B, then if you just change the macro and recompile namespace A, I don't think code using the macros in namespace B will see the changes ? Those considerations, among other things, have made me consider just recompiling the entire project every time a resource or set of resources change, so that it is reliable, if not totally optimized (but so far, for the size of the projects, I guess it's still not a performance bottleneck). My 0,02 €, -- Laurent 2009/2/21 Daniel Spiewak > > I'm pleased to announce preliminary (and very experimental) support > for the Clojure AOT compiler and REPL within Apache Buildr (http:// > buildr.apache.org). At present, this support is only available within > my Git fork available here: git://github.com/djspiewak/buildr.git > More specifically, Clojure support is available within the "clojure" > and "master" branches ("master" branch alone contains REPL support). > It should be possible to install this particular version of Buildr by > using the following commands, though I'm honestly not sure how up to > date GitHub's gem repository is: > > gem sources -a http://gems.github.com > sudo gem install djspiewak-buildr > > Once installed, Clojure support is activated in a project simply by > storing your .clj scripts within the src/main/clojure directory. Note > that the (ns) directive will need to match the subdirectory, otherwise > compilation will fail. By default, every script is compiled to the > target/classes directory. Namespaces are auto-detected from the > directory structure. Only updated files are re-compiled (based on > mtime of .clj file and its corresponding *__init.class). If you wish > to override the auto-detection and specify a reduced set of > namespaces, it can be done using the `compile.using` directive within > your project definition in your buildfile. Thusly: > > define 'clojure-contrib' do > compile.using :libs => ['clojure.contrib.command-line', > 'clojure.contrib.mmap'] > end > > Any scripts which are *not* pre-compiled will be copied verbatim to > the target/classes directory w.r.t. their position in the directory > structure. Note that you will need to have set CLOJURE_HOME for this > to work. > > You will have to be using the "master" branch from my git repository > in order to use the Clojure REPL through Buildr (or install via the > gem command given above). To invoke, simply run the following command > somewhere in your project hierarchy: > > buildr shell > > This will launch the Clojure REPL pointing at your project's > dependencies and the updated target/classes directory (compilation is > re-run if necessary). Additionally, if you have a valid license for > JavaRebel, you can make use of it with the REPL by setting the > REBEL_HOME environment variable. > > Note that you cannot mix Java and Clojure sources within the same > project. However, this is fairly easy to overcome by splitting the > languages into separate sub-projects. Thus, your top-level project > might contain all of your Clojure sources, while the sub-project might > contain Java. There are more details regarding this process on the > Buildr project page. > > One thing to keep in mind is that Buildr was designed to serve as a > build system for more static languages (specifically: Java, Scala, > Groovy). Thus, it is pre-biased toward things like a separate > compilation phase (the REPL points to target/classes rather than src/ > main/clojure). > > Fair warning: this language support is *extremely* experimental and > probably not too reliable at this point. Also note that while it is > possible that Clojure support will be merged into the Buildr trunk in > future, it has not yet been decided one way or another (see > https://issues.apache.org/jira/browse/BUILDR-259). Use at your own > risk! > > > --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
> > Note that you cannot mix Java and Clojure sources within the same > > project. > > Aww... :( Joint-compilation is actually a hard problem normally. However, since Clojure is late-bound, I should be able to do it without too much horror. Actually, I should be able to do joint compilation with Java, Scala or Groovy (Scala and Groovy would be mutually exclusive). I just have to figure out how to trick Buildr into letting me register a compiler in this fashion. So, the feature is coming, it's just not immediately present. Daniel --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
On Feb 26, 10:58 am, Anand Patil wrote: > On Feb 26, 4:41 pm, mikel wrote: > > > Other people have explained currying and partial application, and why > > it doesn't normally spply the feature you want. > > I'd be interested in reading about this if you know of a link. What I meant was, other people have talked about it *in this thread*. :-) As in, farther up the page. :-) But you can find more about currying here: http://en.wikipedia.org/wiki/Currying > > Normally, in a lnaguage that supplies partial application, the way to > > achieve the effect you want is to use combinators that change the > > order of arguments. > > OK, that sounds like a clean functional way to do it. Thanks. This article includes some discussion of combinators, including examples of some standard ones: http://en.wikipedia.org/wiki/Combinators#Examples_of_combinators Combinators are sort of interesting in themselves; it turns out that the standard combinators S and K are Turing complete; that is, a language consisting only of S and K is sufficient to compute anything that can be computed (although such a language would be neither convenient nor efficient). That's sort of surprising. --~--~-~--~~~---~--~~ 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 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: some vs. contains? for a list
Hi Mark, The results will depend on the objects you are comparing. If you need to search through the list multiple times, converting to a set once is almost certainly going to be faster. But, if you're just doing it once, iterating will usually be much faster: user> (time (dotimes [_ 10] (contains? (set (range 100)) 10))) "Elapsed time: 7708.336 msecs" user> (time (dotimes [_ 10] (some #(= 10 %) (range 100 "Elapsed time: 291.474 msecs" user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains? s 10 "Elapsed time: 27.978 msecs" In a simple test I get similar results for strings too... what conditions were you testing under? -Jason On Feb 26, 7:53 am, Mark Volkmann wrote: > I thought for sure it would be faster to use "some" to determine > whether an item was in a list rather than convert the list to a set > and then use "contains?", but it turns out I was wrong. The latter > approach takes about 1/3 to 1/2 the time! This is the case even when > the list contains 100 items. Of course I realize that if this is a > commonly needed operation for a particular collection, it's better to > use a set instead of a list in the first place. > > (def stooges (list "Moe" "Larry" "Curly")) > (time (some #(= % "Curly") stooges)) > (time (contains? (set stooges) "Curly")) > > -- > R. Mark Volkmann > Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
> * does it support namespaces separated in several files (handling files > that begin with 'in-ns, or just not trying to compile them ?) > * if so, will it support the scenario of multiple files per ns, where just > another file (and not the file defining the ns) is modified ? I didn't even know Clojure's AOT compiler supported this. I thought that the name of the file was forced to match the name of the namespace it represents? If that is not the case, then the solution would probably be to just not compile the in-ns files, though that seems annoyingly-ugly. Right now, compilation detection is exclusively based on filenames. So if you have a file src/main/clojure/clojure/contrib/command- line.clj, then Buildr will dispatch the compilation of namespace "clojure.contrib.command-line". I thought about doing fancy parsing to checkout the ns declarations, but given Clojure's dynamic nature, I would never be able to *guarantee* any sort of accuracy in that approach. > * there is also another problem : if some macros are defined in a namespace > A, used in a namespace B, then if you just change the macro and recompile > namespace A, I don't think code using the macros in namespace B will see the > changes ? This case didn't occur to me, but you're right that it would be problematic. I should probably change the compilation to just recompile everything when any file has changed. Darn those macros... Daniel --~--~-~--~~~---~--~~ 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 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: some vs. contains? for a list
Well, I guess the second number is a bit misleading. Of course, when you're iterating the time taken will depend on the (expected) presence and position of the target in the list. Still, the order is the same even in the worst case: user> (time (dotimes [_ 10] (some #(= 100 %) (range 100 "Elapsed time: 2213.944 msecs" On Feb 26, 10:02 am, Jason Wolfe wrote: > Hi Mark, > > The results will depend on the objects you are comparing. If you need > to search through the list multiple times, converting to a set once is > almost certainly going to be faster. But, if you're just doing it > once, iterating will usually be much faster: > > user> (time (dotimes [_ 10] (contains? (set (range 100)) 10))) > "Elapsed time: 7708.336 msecs" > > user> (time (dotimes [_ 10] (some #(= 10 %) (range 100 > "Elapsed time: 291.474 msecs" > > user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains? > s 10 > "Elapsed time: 27.978 msecs" > > In a simple test I get similar results for strings too... what > conditions were you testing under? > > -Jason > > On Feb 26, 7:53 am, Mark Volkmann wrote: > > > I thought for sure it would be faster to use "some" to determine > > whether an item was in a list rather than convert the list to a set > > and then use "contains?", but it turns out I was wrong. The latter > > approach takes about 1/3 to 1/2 the time! This is the case even when > > the list contains 100 items. Of course I realize that if this is a > > commonly needed operation for a particular collection, it's better to > > use a set instead of a list in the first place. > > > (def stooges (list "Moe" "Larry" "Curly")) > > (time (some #(= % "Curly") stooges)) > > (time (contains? (set stooges) "Curly")) > > > -- > > R. Mark Volkmann > > Object Computing, Inc. > > --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
On Feb 26, 5:27 pm, mikel wrote: > On Feb 26, 10:58 am, Anand Patil > wrote: > > > On Feb 26, 4:41 pm, mikel wrote: > > > > Other people have explained currying and partial application, and why > > > it doesn't normally spply the feature you want. > > > I'd be interested in reading about this if you know of a link. > > What I meant was, other people have talked about it *in this > thread*. :-) As in, farther up the page. :-) Ha! I see. :) I was hoping for a reason why these languages don't provide more general partial application in addition to currying, but that's probably available in the Wikipedia article. > Combinators are sort of interesting in themselves; it turns out that > the standard combinators S and K are Turing complete; that is, a > language consisting only of S and K is sufficient to compute anything > that can be computed (although such a language would be neither > convenient nor efficient). That's sort of surprising. That is surprising. I go now to ponder. Anand --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Waterfront's Issue tracker is up
For those of you who encountered issues/bugs with Waterfront, you not submit reports at: http://sourceforge.net/tracker2/?func=browse&group_id=249246&atid=1126790 My intention is to get Waterfront into contrib in the near future. Till then, Waterfront will stay on sf.net. Also, thank you very much for the warm feedback and the wise comments. -Itay --~--~-~--~~~---~--~~ 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 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: Waterfront's Issue tracker is up
Should be "you can now submit..." Sorry for the typo. -Itay On Feb 26, 9:37 pm, Itay Maman wrote: > For those of you who encountered issues/bugs with Waterfront, you not > submit reports > at:http://sourceforge.net/tracker2/?func=browse&group_id=249246&atid=112... > > My intention is to get Waterfront into contrib in the near future. > Till then, Waterfront will stay on sf.net. > > Also, thank you very much for the warm feedback and the wise comments. > > -Itay --~--~-~--~~~---~--~~ 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 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: Richer 'partial'
On Feb 26, 12:34 pm, Anand Patil wrote: > On Feb 26, 5:27 pm, mikel wrote: > > > On Feb 26, 10:58 am, Anand Patil > > wrote: > > > > On Feb 26, 4:41 pm, mikel wrote: > > > > > Other people have explained currying and partial application, and why > > > > it doesn't normally spply the feature you want. > > > > I'd be interested in reading about this if you know of a link. > > > What I meant was, other people have talked about it *in this > > thread*. :-) As in, farther up the page. :-) > > Ha! I see. :) I was hoping for a reason why these languages don't > provide more general partial application in addition to currying, but > that's probably available in the Wikipedia article. I don't know that you'll find that question answered explicitly. I think the answer would be that (1) supporting that feature creates a lot of syntactic complexity (you need some notational mechanism for designating which arguments you're going to apply the function to, and anything you choose is going to be kind of messy), and (2) with combinators, you don't need it. --~--~-~--~~~---~--~~ 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 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: "Adding" strings
Thanks all. I think appending a bunch of strings is a pretty common operation. Is there any reason that str is limited to 2 arguments? It would be nice to do (str "foo" "bar" "baz") --> "foobarbaz". Is there a good reason that + can't do the right thing as with other Java and scripting languages? I think this would be popular with non-LISPers. P Laurent PETIT wrote: > (str "foo" "bah") > > and if you have a collection you can (apply str coll) > > HTH, > > -- > Laurent > > 2009/2/26 Peter Wolf mailto:opus...@gmail.com>> > > > Hey all, > > What is the idiomatic way to concatenate strings? Here are some > things > that I expected to work, but didn't > >(+ "foo" "bah") >(conj "foo" "bah") >(into "foo" "bah") > > For the moment I am doing > >(.concat "foo" "bah") > > But it seems wrong > > Thanks > P > > > > > > > > --~--~-~--~~~---~--~~ 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 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: "Adding" strings
On Feb 26, 2009, at 2:01 PM, Peter Wolf wrote: > > Thanks all. > > I think appending a bunch of strings is a pretty common operation. > > Is there any reason that str is limited to 2 arguments? It would be > nice to do (str "foo" "bar" "baz") --> "foobarbaz". It does. Try it out. =) > > > Is there a good reason that + can't do the right thing as with other > Java and scripting languages? I think this would be popular with > non-LISPers. > > > P > > > > Laurent PETIT wrote: >> (str "foo" "bah") >> >> and if you have a collection you can (apply str coll) >> >> HTH, >> >> -- >> Laurent >> >> 2009/2/26 Peter Wolf mailto:opus...@gmail.com>> >> >> >>Hey all, >> >>What is the idiomatic way to concatenate strings? Here are some >>things >>that I expected to work, but didn't >> >> (+ "foo" "bah") >> (conj "foo" "bah") >> (into "foo" "bah") >> >>For the moment I am doing >> >> (.concat "foo" "bah") >> >>But it seems wrong >> >>Thanks >>P >> >> >> >> >> >> >>> > > > > --~--~-~--~~~---~--~~ 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 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: Clojure plugin for IntelliJ IDEA published
Hello Ilya, Thanks for the workaround. I'm glad to hear you're working on a "surround with" feature. Some other parenthesis commands that I most commonly use is: 1) Delete next Sexp. 2) Splice Sexp. (Remove the parenthesis around the current sexp). 3) Move cursor to next/previous sexp. Just from a personal point of view, my most wanted features would be, in order of preference 1) Keyboard shortcuts for sending sexps to REPL. 2) Parenthesis commands 3) Working Debugger. (This would be extremely useful. But I'm making do without it for now.) Thanks -Patrick --~--~-~--~~~---~--~~ 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 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: "Adding" strings
> Is there any reason that str is limited to 2 arguments? It would be > nice to do (str "foo" "bar" "baz") --> "foobarbaz". Try it! (Hint: "With more than one arg, returns the concatenation of the str values of the args.") > Is there a good reason that + can't do the right thing as with other > Java and scripting languages? I think this would be popular with > non-LISPers. I think any desire for that disappears once you discover str, but the implementation reason against it is that it'd require arg checks for +, which you want to be fast. Look at the source for + & str -- they're both optimized for what they do. Perry --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Mathy operations on non-numerics (was "Adding" strings)
Peter Wolf writes: > Is there a good reason that + can't do the right thing as with other > Java and scripting languages? I think this would be popular with > non-LISPers. Putting a type check in + would slow down basic math, and there is a class of user who will complain loudly if basic math slows down. However, this also means that > and < also don't work on strings, which is pretty lousy. One approach that's been proposed in #clojure is to make these functions more capable by default, but then provide a fast-math library that could redefine them in terms of numerics-only. I'm a big fan of functions doing the most helpful thing by default but being able to offer better speed when you need it. Convenience vs speed is always a trade-off, but I think convenience should win in the default case. What do others think about this? -Phil --~--~-~--~~~---~--~~ 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 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: Syntax-quote only as a reader macro?
On Thu, Feb 26, 2009 at 9:36 AM, Konrad Hinsen wrote: > > I figured out one way to do it, but it relies on features that are > perhaps not safe to rely on: I get var first, and then I get the > var's namespace from its public attribute ns: > > (defn qualified-symbol > [s] > (if-let [var (resolve s)] > (symbol (str (.ns var)) (str (.sym var))) > s)) > > This seems to work fine for all cases I can imagine. But I'd love to > see a cleaner way to do this. I've got essentially the same thing for use in error-kit: (defn- qualify-sym [sym] (let [v (resolve sym)] (assert v) (apply symbol (map #(str (% ^v)) [:ns :name] Of course it depends on the var existing at the time the macro is expanded, but if that weren't true how could the macro have any idea what namespace the symbol belonged to? BTW, I'd recommend avoiding using the name of builtins like 'var' for your own locals. --Chouser --~--~-~--~~~---~--~~ 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 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: Mathy operations on non-numerics (was "Adding" strings)
On Thu, Feb 26, 2009 at 1:18 PM, Phil Hagelberg wrote: > > Peter Wolf writes: > > > Is there a good reason that + can't do the right thing as with other > > Java and scripting languages? I think this would be popular with > > non-LISPers. > > Putting a type check in + would slow down basic math, and there is a > class of user who will complain loudly if basic math slows > down. However, this also means that > and < also don't work on strings, > which is pretty lousy. > > One approach that's been proposed in #clojure is to make these functions > more capable by default, but then provide a fast-math library that could > redefine them in terms of numerics-only. I'm a big fan of functions > doing the most helpful thing by default but being able to offer better > speed when you need it. > > Convenience vs speed is always a trade-off, but I think convenience > should win in the default case. What do others think about this? > I would much rather have a fast-math library that redefined common operators for numeric types only, and had the default +, <, > be multimethods. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Preliminary Clojure Support in Buildr
> > > Note that you cannot mix Java and Clojure sources within the same > > > project. It is supported in the latest changeset. The following configurations are possible: - Just Clojure: * src/main/clojure Clojure and Scala: * src/main/clojure * src/main/scala Clojure, Scala and Java: * src/main/clojure * src/main/scala * src/main/java Clojure and Groovy: * src/main/clojure * src/main/groovy Clojure, Groovy and Java: * src/main/clojure * src/main/groovy * src/main/java Clojure and Java: * src/main/clojure * src/main/java - You'll notice that "Clojure, Scala and Groovy" is not among the possibilities. This is because the Groovy joint compiler and the Scala joint compiler both expect to be able to interleave Java dependencies within their type resolution process. They do not have support for the same functionality with each other, meaning that circular dependencies cannot be compiled between the two languages. Note that this is all predicated on a (possibly faulty) assumption about the Clojure compiler: everything must be late-bound. If Clojure's compiler needs to resolve types at compile-time, then this could potentially fail in unexpected ways. Specifically, circular dependencies between Clojure and Java/Scala/Groovy would not be possible. In such a case, you would need to somehow factor the circularity out into a separate .clj file and then exclude that file from compilation (forcing late binding). I honestly don't know if this is the compiler's behavior or not, but I thought it was worth the warning. One small change: in order to use this functionality now, you will need to include the following line at the top of your buildfile: require 'buildr/clojure' Joint compilation with Scala/Java or Groovy/Java does not necessitate an extra "require", but this first one is necessary to get the process started and ensure that Clojure's compiler becomes the dominant selection. Daniel --~--~-~--~~~---~--~~ 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 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: "Adding" strings
Doh! *engage brain BEFORE emailing* Sorry to be not thinking... Coffee now! :-P Sent via BlackBerry from T-Mobile -Original Message- From: Perry Trolard Date: Thu, 26 Feb 2009 11:13:49 To: Clojure Subject: Re: "Adding" strings > Is there any reason that str is limited to 2 arguments? It would be > nice to do (str "foo" "bar" "baz") --> "foobarbaz". Try it! (Hint: "With more than one arg, returns the concatenation of the str values of the args.") > Is there a good reason that + can't do the right thing as with other > Java and scripting languages? I think this would be popular with > non-LISPers. I think any desire for that disappears once you discover str, but the implementation reason against it is that it'd require arg checks for +, which you want to be fast. Look at the source for + & str -- they're both optimized for what they do. Perry --~--~-~--~~~---~--~~ 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 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: function call preconditions
On Feb 26, 5:55 am, Laurent PETIT wrote: > While not checking types at compile time, it seems to me that a lot of > clojure code still needs in the docstring some sort of "preconditions > warnings". Do you mean something like "Contract Programming," as in e.g., the Eiffel programming language? mfh --~--~-~--~~~---~--~~ 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 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: function call preconditions
My first thought was just : "could some information that is currently placed in the docstring be more useful is written differently, while still complying with the DRY principle (that is, the parts that are extracted from the current docstring should still be available in a useful form to the clients of your function/macro". The evident think that can be very easily formalized in the docstrings is some sort of type restriction on the arguments. A generalization of this, though, is indeed what Eiffel offers as Design By Contract. Something like that is already present (I guess) as validators on refs, atoms and agents. -- Laurent 2009/2/26 Mark H. > > On Feb 26, 5:55 am, Laurent PETIT wrote: > > While not checking types at compile time, it seems to me that a lot of > > clojure code still needs in the docstring some sort of "preconditions > > warnings". > > Do you mean something like "Contract Programming," as in e.g., the > Eiffel programming language? > > mfh > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
read file into byte[]
Is there a quick way to read a file into a java array of bytes? martin --~--~-~--~~~---~--~~ 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 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: some vs. contains? for a list
On Thu, Feb 26, 2009 at 12:02 PM, Jason Wolfe wrote: > > Hi Mark, > > The results will depend on the objects you are comparing. If you need > to search through the list multiple times, converting to a set once is > almost certainly going to be faster. But, if you're just doing it > once, iterating will usually be much faster: That makes sense, but doesn't match the results I see. See my additional detail below. > user> (time (dotimes [_ 10] (contains? (set (range 100)) 10))) > "Elapsed time: 7708.336 msecs" > > user> (time (dotimes [_ 10] (some #(= 10 %) (range 100 > "Elapsed time: 291.474 msecs" > > user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains? > s 10 > "Elapsed time: 27.978 msecs" > > In a simple test I get similar results for strings too... what > conditions were you testing under? Here's the actual code I ran to test. (def stooges (list "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "Moe" "Larry" "Curly")) (time (dotimes [_ 1000] (some #(= % "Curly") stooges))) (time (dotimes [_ 1000] (contains? (set stooges) "Curly"))) (let [s (set stooges)] (time (dotimes [_ 1000] (contains? s "Curly" I'm seeing a wide variation in results. Here are results from consecutive runs. "Elapsed time: 40.515 msecs" "Elapsed time: 121.825 msecs" "Elapsed time: 1.163 msecs" "Elapsed time: 69.026 msecs" "Elapsed time: 60.438 msecs" "Elapsed time: 1.732 msecs" So sometimes converting to a set for a single lookup (the second case) is faster, but not usually. > On Feb 26, 7:53 am, Mark Volkmann wrote: >> I thought for sure it would be faster to use "some" to determine >> whether an item was in a list rather than convert the list to a set >> and then use "contains?", but it turns out I was wrong. The latter >> approach takes about 1/3 to 1/2 the time! This is the case even when >> the list contains 100 items. Of course I realize that if this is a >> commonly needed operation for a particular collection, it's better to >> use a set instead of a list in the first place. >> >> (def stooges (list "Moe" "Larry" "Curly")) >> (time (some #(= % "Curly") stooges)) >> (time (contains? (set stooges) "Curly")) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: some vs. contains? for a list
Ah, OK, a couple of things. First, if you're running timing experiments, you probably want the times to be measured in seconds for them to be at all reliable. It seems to take up to 10 seconds of executing a bit of code before HotSpot is done optimizing it (depending on complexity of what you're running -- here, probably not so much), so usually you want to execute at least one "throw-away" run, and then do a final set of timings. Even then, if your final times aren't at least a second or so, you'll end up running afoul of intermittent GC overhead (sometimes it will happen during your run, sometimes not). At least, that's how I understand things. Second, building the set in your case will be faster since there are only 10 unique elements. AFAIK this means only 10 new "Set" object creations, compared to 100 if the elements were all unique. Cheers, Jason On Feb 26, 2009, at 12:15 PM, Mark Volkmann wrote: > > On Thu, Feb 26, 2009 at 12:02 PM, Jason Wolfe > wrote: >> >> Hi Mark, >> >> The results will depend on the objects you are comparing. If you >> need >> to search through the list multiple times, converting to a set once >> is >> almost certainly going to be faster. But, if you're just doing it >> once, iterating will usually be much faster: > > That makes sense, but doesn't match the results I see. See my > additional detail below. > >> user> (time (dotimes [_ 10] (contains? (set (range 100)) 10))) >> "Elapsed time: 7708.336 msecs" >> >> user> (time (dotimes [_ 10] (some #(= 10 %) (range 100 >> "Elapsed time: 291.474 msecs" >> >> user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains? >> s 10 >> "Elapsed time: 27.978 msecs" >> >> In a simple test I get similar results for strings too... what >> conditions were you testing under? > > Here's the actual code I ran to test. > > (def stooges (list > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" > "Moe" "Larry" "Curly")) > > (time (dotimes [_ 1000] (some #(= % "Curly") stooges))) > > (time (dotimes [_ 1000] (contains? (set stooges) "Curly"))) > > (let [s (set stooges)] > (time (dotimes [_ 1000] (contains? s "Curly" > > I'm seeing a wide variation in results. Here are results from > consecutive runs. > > "Elapsed time: 40.515 msecs" > "Elapsed time: 121.825 msecs" > "Elapsed time: 1.163 msecs" > > "Elapsed time: 69.026 msecs" > "Elapsed time: 60.438 msecs" > "Elapsed time: 1.732 msecs" > > So sometimes converting to a set for a single lookup (the second case) > is faster, but not usually. > >> On Feb 26, 7:53 am, Mark Volkmann wrote: >>> I thought for sure it would be faster to use "some" to determine >>> whether an item was in a list rather than convert the list to a set >>> and then use "contains?", but it turns out I was wrong. The latter >>> approach takes about 1/3 to 1/2 the time! This is the case even when >>> the list contains 100 items. Of course I realize that if this is a >>> commonly needed operation for a particular collection, it's better >>> to >>> use a set instead of a list in the first place. >>> >>> (def stooges (list "Moe" "Larry" "Curly")) >>> (time (some #(= % "Curly") stooges)) >>> (time (contains? (set stooges) "Curly")) > > -- > R. Mark Volkmann > Object Computing, Inc. > > > --~--~-~--~~~---~--~~ 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 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: Syntax-quote only as a reader macro?
On 26.02.2009, at 20:25, Chouser wrote: > I've got essentially the same thing for use in error-kit: > > (defn- qualify-sym [sym] > (let [v (resolve sym)] > (assert v) > (apply symbol (map #(str (% ^v)) [:ns :name] Except that you get the information from the metadata. I wonder which method is safer in the long run? > Of course it depends on the var existing at the time the macro is > expanded, but if that weren't true how could the macro have any idea > what namespace the symbol belonged to? Given that I want to replicate exactly what happens when the compiler resolves a symbol, the only problem would be a symbol referring to something else than a var. My understanding is that that shouldn't happen. > BTW, I'd recommend avoiding using the name of builtins like 'var' for > your own locals. In theory I agree, but in practice I can't remember all those builtins, most of which I never use... Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
order of the arguments for functions, think an easy way.
This is an example: (contains? (set (range 100)) 10))) (some #(= 10 %) (range 100 I would like some way to rule the order of the arguments. For example what - where. contains? what where some what where I'm sure you can think some rules to cover many cases. As I am not so young, I'm getting fond of rules to make life easier. --~--~-~--~~~---~--~~ 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 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: Algebraic data types in clojure.contrib
On 26.02.2009, at 10:00, Konrad Hinsen wrote: > I know, but as I said, my current implementation is just a proof of > concept. It is not viable for production use for a variety of > reasons. I was planning to replace it by something based on gen-class > and proxy, but I will first try to get away with the new type > function. I just committed a completely new implementation to clojure.contrib. It uses a vector with type metadata for representing algebraic data types. Overall I am rather happy with this version. It is used almost exactly like the previous one. There is probably still room for improvement, but I don't expect the interface to change significantly any more, so I'd say it's safe for adoption by adventurous Clojurians :-) Konrad. --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak wrote: > > Odd. Must be a problem with RubyForge. If you try again, does it > work? I tried again at home and got quite a bit further. Maybe it was just a hiccup at rubyforge. However, I still see some questionable things in the output, and I have yet to actually try it out (this is the first time I'm trying out buildr). Here in verbatim: rowe:~$ sudo gem install djspiewak-buildr Building native extensions. This could take a while... Successfully installed builder-2.1.2 Successfully installed net-ssh-2.0.4 Successfully installed net-sftp-2.0.1 Successfully installed rubyzip-0.9.1 Successfully installed highline-1.5.0 Successfully installed rubyforge-1.0.1 Successfully installed hoe-1.7.0 Successfully installed rjb-1.1.6 Successfully installed Antwrap-0.7.0 Successfully installed rspec-1.1.4 Successfully installed xml-simple-1.0.11 Successfully installed archive-tar-minitar-0.5.2 Successfully installed djspiewak-buildr-1.3.4 13 gems installed Installing ri documentation for builder-2.1.2... ERROR: While generating documentation for builder-2.1.2 ... MESSAGE: Unhandled special: Special: type=17, text="" ... RDOC args: --ri --op /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder -- Easy XML Building --main README --line-numbers --quiet lib CHANGES Rakefile README doc/releases/builder-1.2.4.rdoc doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc (continuing with the rest of the installation) Installing ri documentation for net-ssh-2.0.4... Installing ri documentation for net-sftp-2.0.1... Installing ri documentation for highline-1.5.0... Installing ri documentation for rubyforge-1.0.1... Installing ri documentation for hoe-1.7.0... Installing ri documentation for Antwrap-0.7.0... Installing ri documentation for rspec-1.1.4... Installing ri documentation for archive-tar-minitar-0.5.2... Installing ri documentation for djspiewak-buildr-1.3.4... File not found: lib rowe:~$ ruby --version ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin8] rowe:~$ A failure to generate the docs I can live with, but that "File not found" line looks pretty suspect. > > Daniel > > On Feb 26, 10:58 am, Christian Vest Hansen > wrote: >> Nice initiative! >> >> However, it the net-ssh dependency has problems: >> >> [cvh: ~]$ sudo gem install djspiewak-buildr >> ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) >> timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem) >> >> >> >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak wrote: >> >> > I'm pleased to announce preliminary (and very experimental) support >> > for the Clojure AOT compiler and REPL within Apache Buildr (http:// >> > buildr.apache.org). At present, this support is only available within >> > my Git fork available here: git://github.com/djspiewak/buildr.git >> > More specifically, Clojure support is available within the "clojure" >> > and "master" branches ("master" branch alone contains REPL support). >> > It should be possible to install this particular version of Buildr by >> > using the following commands, though I'm honestly not sure how up to >> > date GitHub's gem repository is: >> >> > gem sources -ahttp://gems.github.com >> > sudo gem install djspiewak-buildr >> >> > Once installed, Clojure support is activated in a project simply by >> > storing your .clj scripts within the src/main/clojure directory. Note >> > that the (ns) directive will need to match the subdirectory, otherwise >> > compilation will fail. By default, every script is compiled to the >> > target/classes directory. Namespaces are auto-detected from the >> > directory structure. Only updated files are re-compiled (based on >> > mtime of .clj file and its corresponding *__init.class). If you wish >> > to override the auto-detection and specify a reduced set of >> > namespaces, it can be done using the `compile.using` directive within >> > your project definition in your buildfile. Thusly: >> >> > define 'clojure-contrib' do >> > compile.using :libs => ['clojure.contrib.command-line', >> > 'clojure.contrib.mmap'] >> > end >> >> > Any scripts which are *not* pre-compiled will be copied verbatim to >> > the target/classes directory w.r.t. their position in the directory >> > structure. Note that you will need to have set CLOJURE_HOME for this >> > to work. >> >> > You will have to be using the "master" branch from my git repository >> > in order to use the Clojure REPL through Buildr (or install via the >> > gem command given above). To invoke, simply run the following command >> > somewhere in your project hierarchy: >> >> > buildr shell >> >> > This will launch the Clojure REPL pointing at your project's >> > dependencies and the updated target/classes directory (compilation is >> > re-run if necessary). Additionally, if you have a valid license for >> > JavaRebel, you can make use of it with the REPL by setting the >> > REBEL_HOME environment variable. >> >> > Note t
Re: order of the arguments for functions, think an easy way.
On Feb 26, 2009, at 3:57 PM, camponoblanco wrote: This is an example: (contains? (set (range 100)) 10))) (some #(= 10 %) (range 100 I would like some way to rule the order of the arguments. For example what - where. contains? what where some what where I'm sure you can think some rules to cover many cases. As I am not so young, I'm getting fond of rules to make life easier. This previous discussion may be helpful: http://groups.google.com/group/clojure/browse_frm/thread/8b2c8dc96b39ddd7?tvc=1&q=order+of+arguments --Steve smime.p7s Description: S/MIME cryptographic signature
Re: ANN: Preliminary Clojure Support in Buildr
I'm not sure what the File not found thing is all about, but you should still be ok (crazy gems). Try the following: buildr --version Daniel On Feb 26, 3:16 pm, Christian Vest Hansen wrote: > On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak wrote: > > > Odd. Must be a problem with RubyForge. If you try again, does it > > work? > > I tried again at home and got quite a bit further. Maybe it was just a > hiccup at rubyforge. > > However, I still see some questionable things in the output, and I > have yet to actually try it out (this is the first time I'm trying out > buildr). Here in verbatim: > > rowe:~$ sudo gem install djspiewak-buildr > Building native extensions. This could take a while... > Successfully installed builder-2.1.2 > Successfully installed net-ssh-2.0.4 > Successfully installed net-sftp-2.0.1 > Successfully installed rubyzip-0.9.1 > Successfully installed highline-1.5.0 > Successfully installed rubyforge-1.0.1 > Successfully installed hoe-1.7.0 > Successfully installed rjb-1.1.6 > Successfully installed Antwrap-0.7.0 > Successfully installed rspec-1.1.4 > Successfully installed xml-simple-1.0.11 > Successfully installed archive-tar-minitar-0.5.2 > Successfully installed djspiewak-buildr-1.3.4 > 13 gems installed > Installing ri documentation for builder-2.1.2... > ERROR: While generating documentation for builder-2.1.2 > ... MESSAGE: Unhandled special: Special: type=17, text="" > ... RDOC args: --ri --op > /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder -- > Easy XML Building --main README --line-numbers --quiet lib CHANGES > Rakefile README doc/releases/builder-1.2.4.rdoc > doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc > (continuing with the rest of the installation) > Installing ri documentation for net-ssh-2.0.4... > Installing ri documentation for net-sftp-2.0.1... > Installing ri documentation for highline-1.5.0... > Installing ri documentation for rubyforge-1.0.1... > Installing ri documentation for hoe-1.7.0... > Installing ri documentation for Antwrap-0.7.0... > Installing ri documentation for rspec-1.1.4... > Installing ri documentation for archive-tar-minitar-0.5.2... > Installing ri documentation for djspiewak-buildr-1.3.4... > File not found: lib > rowe:~$ ruby --version > ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin8] > rowe:~$ > > A failure to generate the docs I can live with, but that "File not > found" line looks pretty suspect. > > > > > > > Daniel > > > On Feb 26, 10:58 am, Christian Vest Hansen > > wrote: > >> Nice initiative! > > >> However, it the net-ssh dependency has problems: > > >> [cvh: ~]$ sudo gem install djspiewak-buildr > >> ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) > >> timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem) > > >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak > >> wrote: > > >> > I'm pleased to announce preliminary (and very experimental) support > >> > for the Clojure AOT compiler and REPL within Apache Buildr (http:// > >> > buildr.apache.org). At present, this support is only available within > >> > my Git fork available here: git://github.com/djspiewak/buildr.git > >> > More specifically, Clojure support is available within the "clojure" > >> > and "master" branches ("master" branch alone contains REPL support). > >> > It should be possible to install this particular version of Buildr by > >> > using the following commands, though I'm honestly not sure how up to > >> > date GitHub's gem repository is: > > >> > gem sources -ahttp://gems.github.com > >> > sudo gem install djspiewak-buildr > > >> > Once installed, Clojure support is activated in a project simply by > >> > storing your .clj scripts within the src/main/clojure directory. Note > >> > that the (ns) directive will need to match the subdirectory, otherwise > >> > compilation will fail. By default, every script is compiled to the > >> > target/classes directory. Namespaces are auto-detected from the > >> > directory structure. Only updated files are re-compiled (based on > >> > mtime of .clj file and its corresponding *__init.class). If you wish > >> > to override the auto-detection and specify a reduced set of > >> > namespaces, it can be done using the `compile.using` directive within > >> > your project definition in your buildfile. Thusly: > > >> > define 'clojure-contrib' do > >> > compile.using :libs => ['clojure.contrib.command-line', > >> > 'clojure.contrib.mmap'] > >> > end > > >> > Any scripts which are *not* pre-compiled will be copied verbatim to > >> > the target/classes directory w.r.t. their position in the directory > >> > structure. Note that you will need to have set CLOJURE_HOME for this > >> > to work. > > >> > You will have to be using the "master" branch from my git repository > >> > in order to use the Clojure REPL through Buildr (or install via the > >> > gem command given above). To invoke, simply run the following command > >> > somewhere in your pr
Re: Mathy operations on non-numerics (was "Adding" strings)
OK had my coffee, and had several thoughts... 1 -- What are Strings? How should the Clojure programmer think about them? Are they sequences, in which case all the sequence functions should work. Or are they atomic built-in types like Integers and Floats? 2 -- There is already some type checking in + to deal with Integers, Floats and infinite precision. Line 1212 of Numbers.java has the ops() method which (I think) implements this static Ops ops(Object x){ Class xc = x.getClass(); if(xc == Integer.class) return INTEGER_OPS; else if(xc == Double.class) return DOUBLE_OPS; else if(xc == Float.class) return FLOAT_OPS; else if(xc == BigInteger.class) return BIGINTEGER_OPS; else if(xc == Long.class) return BIGINTEGER_OPS; else if(xc == Ratio.class) return RATIO_OPS; else if(xc == BigDecimal.class) return BIGDECIMAL_OPS; else return INTEGER_OPS; } 3 -- Type hints can take the place of a fast-math library. The compiler could automatically call the appropriate fast math routine when given the necessary information. So my vote is that String are atomic built in objects, and at least +, < and > should work with Strings. The behavior should be just like Java, so (+ "foo" 2) --> "foo2" I don't think this will slow down math because the String case will be the last "else if" in ops() and will only happen when the args are not some sort of Number. Finally, if it doesn't already, I would expect type hints to make things faster. So, it should not be necessary to explicitly call a fast-math library. My 2 n00by cents... P Phil Hagelberg wrote: > Peter Wolf writes: > > >> Is there a good reason that + can't do the right thing as with other >> Java and scripting languages? I think this would be popular with >> non-LISPers. >> > > Putting a type check in + would slow down basic math, and there is a > class of user who will complain loudly if basic math slows > down. However, this also means that > and < also don't work on strings, > which is pretty lousy. > > One approach that's been proposed in #clojure is to make these functions > more capable by default, but then provide a fast-math library that could > redefine them in terms of numerics-only. I'm a big fan of functions > doing the most helpful thing by default but being able to offer better > speed when you need it. > > Convenience vs speed is always a trade-off, but I think convenience > should win in the default case. What do others think about this? > > -Phil > > > > > --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
rowe:~$ buildr --version /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- buildr (LoadError) from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /opt/local/lib/ruby/gems/1.8/gems/djspiewak-buildr-1.3.4/bin/buildr:18 from /opt/local/bin/buildr:19:in `load' from /opt/local/bin/buildr:19 rowe:~$ gem --version 1.3.1 rowe:~$ On Thu, Feb 26, 2009 at 10:30 PM, Daniel Spiewak wrote: > > I'm not sure what the File not found thing is all about, but you > should still be ok (crazy gems). Try the following: > > buildr --version > > Daniel > > On Feb 26, 3:16 pm, Christian Vest Hansen > wrote: >> On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak wrote: >> >> > Odd. Must be a problem with RubyForge. If you try again, does it >> > work? >> >> I tried again at home and got quite a bit further. Maybe it was just a >> hiccup at rubyforge. >> >> However, I still see some questionable things in the output, and I >> have yet to actually try it out (this is the first time I'm trying out >> buildr). Here in verbatim: >> >> rowe:~$ sudo gem install djspiewak-buildr >> Building native extensions. This could take a while... >> Successfully installed builder-2.1.2 >> Successfully installed net-ssh-2.0.4 >> Successfully installed net-sftp-2.0.1 >> Successfully installed rubyzip-0.9.1 >> Successfully installed highline-1.5.0 >> Successfully installed rubyforge-1.0.1 >> Successfully installed hoe-1.7.0 >> Successfully installed rjb-1.1.6 >> Successfully installed Antwrap-0.7.0 >> Successfully installed rspec-1.1.4 >> Successfully installed xml-simple-1.0.11 >> Successfully installed archive-tar-minitar-0.5.2 >> Successfully installed djspiewak-buildr-1.3.4 >> 13 gems installed >> Installing ri documentation for builder-2.1.2... >> ERROR: While generating documentation for builder-2.1.2 >> ... MESSAGE: Unhandled special: Special: type=17, text="" >> ... RDOC args: --ri --op >> /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder -- >> Easy XML Building --main README --line-numbers --quiet lib CHANGES >> Rakefile README doc/releases/builder-1.2.4.rdoc >> doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc >> (continuing with the rest of the installation) >> Installing ri documentation for net-ssh-2.0.4... >> Installing ri documentation for net-sftp-2.0.1... >> Installing ri documentation for highline-1.5.0... >> Installing ri documentation for rubyforge-1.0.1... >> Installing ri documentation for hoe-1.7.0... >> Installing ri documentation for Antwrap-0.7.0... >> Installing ri documentation for rspec-1.1.4... >> Installing ri documentation for archive-tar-minitar-0.5.2... >> Installing ri documentation for djspiewak-buildr-1.3.4... >> File not found: lib >> rowe:~$ ruby --version >> ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin8] >> rowe:~$ >> >> A failure to generate the docs I can live with, but that "File not >> found" line looks pretty suspect. >> >> >> >> >> >> > Daniel >> >> > On Feb 26, 10:58 am, Christian Vest Hansen >> > wrote: >> >> Nice initiative! >> >> >> However, it the net-ssh dependency has problems: >> >> >> [cvh: ~]$ sudo gem install djspiewak-buildr >> >> ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) >> >> timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem) >> >> >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak >> >> wrote: >> >> >> > I'm pleased to announce preliminary (and very experimental) support >> >> > for the Clojure AOT compiler and REPL within Apache Buildr (http:// >> >> > buildr.apache.org). At present, this support is only available within >> >> > my Git fork available here: git://github.com/djspiewak/buildr.git >> >> > More specifically, Clojure support is available within the "clojure" >> >> > and "master" branches ("master" branch alone contains REPL support). >> >> > It should be possible to install this particular version of Buildr by >> >> > using the following commands, though I'm honestly not sure how up to >> >> > date GitHub's gem repository is: >> >> >> > gem sources -ahttp://gems.github.com >> >> > sudo gem install djspiewak-buildr >> >> >> > Once installed, Clojure support is activated in a project simply by >> >> > storing your .clj scripts within the src/main/clojure directory. Note >> >> > that the (ns) directive will need to match the subdirectory, otherwise >> >> > compilation will fail. By default, every script is compiled to the >> >> > target/classes directory. Namespaces are auto-detected from the >> >> > directory structure. Only updated files are re-compiled (based on >> >> > mtime of .clj file and its corresponding *__init.class). If you wish >> >> > to override the auto-detection and specify a reduced set of >> >> > namespaces, it can be done using the `compile.using` directive within >> >> > your project definition in your buildfile. Thusly: >> >> >> > defi
Re: Mathy operations on non-numerics (was "Adding" strings)
> > So my vote is that String are atomic built in objects, and at least +, < > and > should work with Strings. The behavior should be just like Java, > so (+ "foo" 2) --> "foo2" > -1 Concatenation is not addition. I'm almost opposed to numeric operators all together. If we wrote (add 2 3), there would be no confusion at all about what (add "foo" 2) should do, because you'd be writing (conj "foo" (str 2)) If addition between a string and number is defined, what is subtraction between a string and a number? Allen --~--~-~--~~~---~--~~ 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 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: unbean
Thanks. I will definitely be using this function... keep me up to date on any changes. Bill wrote: > > It occurs to me that the "unbean" function could be very useful when > > writing tests for code that calls Java objects. > > Yes, that is exactly the use I have in mind. --~--~-~--~~~---~--~~ 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 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: how to get concurrent - model design question
Ah I see, yes that makes sense. Relationships truly are a contract in this case! --~--~-~--~~~---~--~~ 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 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: Mathy operations on non-numerics (was "Adding" strings)
Agree, I even think there *could* be some utility in having the opposite behavior (but I'm not even sure about that) : (+ "1" 2) --> 3 by + trying to cast its non numeric arguments before throwing an exception ... -- Laurent 2009/2/26 Allen Rohner > > > > > > So my vote is that String are atomic built in objects, and at least +, < > > and > should work with Strings. The behavior should be just like Java, > > so (+ "foo" 2) --> "foo2" > > > > -1 > > Concatenation is not addition. I'm almost opposed to numeric operators > all together. If we wrote (add 2 3), there would be no confusion at > all about what (add "foo" 2) should do, because you'd be writing (conj > "foo" (str 2)) > > If addition between a string and number is defined, what is > subtraction between a string and a number? > > Allen > > > > > > > --~--~-~--~~~---~--~~ 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 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: Mathy operations on non-numerics (was "Adding" strings)
Laurent PETIT writes: > > Concatenation is not addition. I'm almost opposed to numeric operators > > all together. If we wrote (add 2 3), there would be no confusion at > > all about what (add "foo" 2) should do, because you'd be writing (conj > > "foo" (str 2)) > > Agree I agree regarding concatenation as well, but I think the case for comparison of non-numerics is still pretty strong. -Phil --~--~-~--~~~---~--~~ 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 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: Mathy operations on non-numerics (was "Adding" strings)
On Feb 26, 4:56 pm, Peter Wolf wrote: > > So my vote is that String are atomic built in objects, and at least +, < > and > should work with Strings. The behavior should be just like Java, > so (+ "foo" 2) --> "foo2" I have an HP calculator. (I may get some of the details wrong here, I haven't used it lately, but this is the gist of the thing.) + adds numbers. + also concatenates lists. But wait, UNLESS the lists are lists of numbers, in which case it adds numbers componentwise. Which means you have to create a new function or operator if you actually want to be sure you are concatenating lists. It's just dumb. The point is, functions should not take on all kinds of extraneous responsibilities that are completely unrelated to their purpose. + adds numbers. str concatenates strings. BTW, I don't know if this concept of "built in object" you keep saying has any meaning in Clojure. Strings are just objects of the class String, just like in Java. --~--~-~--~~~---~--~~ 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 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: Mathy operations on non-numerics (was "Adding" strings)
> I agree regarding concatenation as well, but I think the case for > comparison of non-numerics is still pretty strong. > > -Phil Are you referring to using <, >, =, with objects that implement java.lang.Comparable? i.e. given x.compareTo(y) == -1 (< x y) => true I would find that useful. Allen --~--~-~--~~~---~--~~ 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 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: Mathy operations on non-numerics (was "Adding" strings)
If we wrote (add 2 3), there would be no confusion at > all about what (add "foo" 2) should do, because you'd be writing (conj > "foo" (str 2)) I wrote this too hastily. This could more easily be written (str "foo" 2) --Allen --~--~-~--~~~---~--~~ 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 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: Clojure plugin for IntelliJ IDEA published
I've only had a couple of minutes to work with it, but I'm already liking it. I just can't keep switching between Emacs and IDEA and IDEA is the work that pays the bills! On Thu, Feb 26, 2009 at 11:08 AM, CuppoJava wrote: > > Hello Ilya, > Thanks for the workaround. > > I'm glad to hear you're working on a "surround with" feature. Some > other parenthesis commands that I most commonly use is: > 1) Delete next Sexp. > 2) Splice Sexp. (Remove the parenthesis around the current sexp). > 3) Move cursor to next/previous sexp. > > Just from a personal point of view, my most wanted features would be, > in order of preference > 1) Keyboard shortcuts for sending sexps to REPL. > 2) Parenthesis commands > 3) Working Debugger. (This would be extremely useful. But I'm making > do without it for now.) > > Thanks > -Patrick > > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ 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 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: Preliminary Clojure Support in Buildr
Crud. I suspect this is something weird with the way that the GitHib gem server works. I'll try to repeat the problem on Ubuntu as soon as I get back to my computer. In the meantime, you could try these commands: sudo gem uninstall djspiewak-buildr sudo gem install djspiewak-buildr Daniel On Feb 26, 3:59 pm, Christian Vest Hansen wrote: > rowe:~$ buildr --version > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in > `gem_original_require': no such file to load -- buildr (LoadError) > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in > `require' > from > /opt/local/lib/ruby/gems/1.8/gems/djspiewak-buildr-1.3.4/bin/buildr:18 > from /opt/local/bin/buildr:19:in `load' > from /opt/local/bin/buildr:19 > rowe:~$ gem --version > 1.3.1 > rowe:~$ > > > > On Thu, Feb 26, 2009 at 10:30 PM, Daniel Spiewak wrote: > > > I'm not sure what the File not found thing is all about, but you > > should still be ok (crazy gems). Try the following: > > > buildr --version > > > Daniel > > > On Feb 26, 3:16 pm, Christian Vest Hansen > > wrote: > >> On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak > >> wrote: > > >> > Odd. Must be a problem with RubyForge. If you try again, does it > >> > work? > > >> I tried again at home and got quite a bit further. Maybe it was just a > >> hiccup at rubyforge. > > >> However, I still see some questionable things in the output, and I > >> have yet to actually try it out (this is the first time I'm trying out > >> buildr). Here in verbatim: > > >> rowe:~$ sudo gem install djspiewak-buildr > >> Building native extensions. This could take a while... > >> Successfully installed builder-2.1.2 > >> Successfully installed net-ssh-2.0.4 > >> Successfully installed net-sftp-2.0.1 > >> Successfully installed rubyzip-0.9.1 > >> Successfully installed highline-1.5.0 > >> Successfully installed rubyforge-1.0.1 > >> Successfully installed hoe-1.7.0 > >> Successfully installed rjb-1.1.6 > >> Successfully installed Antwrap-0.7.0 > >> Successfully installed rspec-1.1.4 > >> Successfully installed xml-simple-1.0.11 > >> Successfully installed archive-tar-minitar-0.5.2 > >> Successfully installed djspiewak-buildr-1.3.4 > >> 13 gems installed > >> Installing ri documentation for builder-2.1.2... > >> ERROR: While generating documentation for builder-2.1.2 > >> ... MESSAGE: Unhandled special: Special: type=17, text="" > >> ... RDOC args: --ri --op > >> /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder -- > >> Easy XML Building --main README --line-numbers --quiet lib CHANGES > >> Rakefile README doc/releases/builder-1.2.4.rdoc > >> doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc > >> (continuing with the rest of the installation) > >> Installing ri documentation for net-ssh-2.0.4... > >> Installing ri documentation for net-sftp-2.0.1... > >> Installing ri documentation for highline-1.5.0... > >> Installing ri documentation for rubyforge-1.0.1... > >> Installing ri documentation for hoe-1.7.0... > >> Installing ri documentation for Antwrap-0.7.0... > >> Installing ri documentation for rspec-1.1.4... > >> Installing ri documentation for archive-tar-minitar-0.5.2... > >> Installing ri documentation for djspiewak-buildr-1.3.4... > >> File not found: lib > >> rowe:~$ ruby --version > >> ruby1.8.7(2008-08-11 patchlevel 72) [i686-darwin8] > >> rowe:~$ > > >> A failure to generate the docs I can live with, but that "File not > >> found" line looks pretty suspect. > > >> > Daniel > > >> > On Feb 26, 10:58 am, Christian Vest Hansen > >> > wrote: > >> >> Nice initiative! > > >> >> However, it the net-ssh dependency has problems: > > >> >> [cvh: ~]$ sudo gem install djspiewak-buildr > >> >> ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) > >> >> timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem) > > >> >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak > >> >> wrote: > > >> >> > I'm pleased to announce preliminary (and very experimental) support > >> >> > for the Clojure AOT compiler and REPL within Apache Buildr (http:// > >> >> > buildr.apache.org). At present, this support is only available within > >> >> > my Git fork available here: git://github.com/djspiewak/buildr.git > >> >> > More specifically, Clojure support is available within the "clojure" > >> >> > and "master" branches ("master" branch alone contains REPL support). > >> >> > It should be possible to install this particular version of Buildr by > >> >> > using the following commands, though I'm honestly not sure how up to > >> >> > date GitHub's gem repository is: > > >> >> > gem sources -ahttp://gems.github.com > >> >> > sudo gem install djspiewak-buildr > > >> >> > Once installed, Clojure support is activated in a project simply by > >> >> > storing your .clj scripts within the src/main/clojure directory. Note > >> >> > that the (ns) directive will need to match the subdirectory, otherwise > >>
Please help me get rid of my mutable code.
Hi, After having used Clojure for a few months now, I'm still having lots of trouble separating my mutable code from my immutable code. My use- case is pretty typical I think, so I'm wondering what sort of structure everyone else is using. Here's my current structure. I have an engine that manages a list of sprites. The engine runs in a loop and updates all the sprites incrementally sixty times a second. When an event occurs, the engine notifies each sprite. When a sprite receives an event, it processes it, and then notifies each of it's listeners. Typical Java event listener model. Well this scheme has mutability written all over it. I'm currently representing sprites as references of immutable maps. So my code is literally littered with (dosync) instructions. How would I go about separating my mutable code from my immutable code? I think I need a completely different angle to attack the problem? Thanks a lot for the help -Patrick --~--~-~--~~~---~--~~ 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 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: read file into byte[]
On Thu, Feb 26, 2009 at 3:04 PM, Martin DeMello wrote: > > Is there a quick way to read a file into a java array of bytes? (let [fl (java.io.File. "/tmp/datafile") ary (make-array Byte/TYPE (.length fl))] (with-open [strm (java.io.FileInputStream. fl)] (.read strm ary 0 (.length fl))) ary) Hm. Or maybe java.nio? (with-open [strm (java.io.FileInputStream. "/tmp/datafile")] (let [ch (.getChannel strm) buf (java.nio.ByteBuffer/allocate (.size ch))] (.read ch buf) (.array buf))) Bleh. Anybody got something better? (with-open [strm (java.io.FileInputStream. "/tmp/datafile")] (let [ch (.getChannel strm) buf (.map ch java.nio.channels.FileChannel$MapMode/READ_ONLY 0 (.size ch)) ary (make-array Byte/TYPE (.size ch))] (.get buf ary) ary)) Seriously, what's with this API? I give up. --Chouser --~--~-~--~~~---~--~~ 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 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: read file into byte[]
On Feb 26, 3:04 pm, Martin DeMello wrote: > Is there a quick way to read a file into a java array of bytes? You want Apache Commons IO: http://commons.apache.org/io/ Specifically, http://tinyurl.com/cytspt -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---