Re: Why I have chosen not to employ clojure
Tim Johnson wrote: I have evaluated clojure for the last couple of days, and it is both my own professional decision and my recommendation to the professional organizations that I belong to and report to that clojure is not ready for prime time. [snip] I agree that Tim was a bit over-reacting; it's so easy to dismiss his post as flame-bait and what not. Nevertheless, I think getting started with Clojure is certainly not painless at the moment; and it's no fault of Clojure at all. There are many people who come to Clojure from non-Java backgrounds (like me) and don't know Emacs (unlike me). Those guys face a _lot_ of problems. Using Clojure on Windows is also a bit problematic. How do we solve it? Clear, up to date instructions for new comers. I propose a website which will serve as the canonical repository for Clojure documentation. It will have great documentation starting from getting started with Clojure to examples of different library functions. We could use content from the Wikibooks project to get started, but we will need to organise and maintain the content a bit better. What do you people think? Regards, BG -- Baishampayan Ghose -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I'm happy that this guy self eliminated himself from clojure community. But experience tells me not to be so sure. His kind tends to come back and unfortunately is very persistent. If downloading couple of jar files and dropping them into the classpath is too much for him, then he is definitelly a java noob. Imagine him advising his clients never use 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Printing promises
On Mon, Mar 22, 2010 at 1:43 PM, Meikel Brandmeyer wrote: > Hi, > > On Mar 22, 7:13 am, Per Vognsen wrote: > >> As a solution, I factored the reify out into a deftype: >> >> http://gist.github.com/339834 > > A short note: you don't have to use :keyword notation in the methods. > The attributes of the type are available under their names. Good to know. Thanks! > >> Unfortunately, the Promise deftype is no longer intercepted by the >> print-method for IDerefs. I guess it has to do with the deftype >> hierarchy vs Java hierarchy. > > No. The "problem" is, that for each type there is a unique print- > method installed by deftype. You have to re-define this method and > call the method for clojure.lang.IDeref directly. (See also above > paste.) Okay, I made this change and changed the IDeref print-method so that it behaves similarly for futures and promises: http://gist.github.com/339834 However, the better way is probably to have individual print-methods for promises and futures, so the general purpose code for IDerefs doesn't have to contain these unsightly special cases. -Per > > Sincerely > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I love clojure but I think it's unnecessary it doesn't ship with a simple clj and a clj.bat script out of the box, yeah it's easy to run it with jvm, but who want to type java -server -Djava.ext.dirs=./lib:/opt/bin/lib -cp ~/.emacs.d/lisp-packages/swank-clojure jline.ConsoleRunner clojure.lang.Repl every time they need a repl? sure, command completion, but come on? It's not exactly making life simple. (I know with 1.1 it's not clojure.lang.Repl any more but still lengthy and complicated, though now I use lein so I am happy). Every time I've started up with a clojure project I've had to spend a few hours fiddling with the environment, not that I don't do that with other languages, but it would be nice with an officially sanctioned solution for setting up a sane environment. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Question about overriding print-method for deftypes
On 21 Mar 2010, at 20:34, Fogus wrote: (defmethod clojure.core/print-method ::Piece [piece writer] ???what goes here???) (defmethod clojure.core/print-method ::Piece [piece writer] (.write writer (str (:number piece) (:letter piece)) 0 2)) Extending Piece to provide a str method can replace that ugly bit in the middle. One more thing to know about print-method for deftype: The deftype macro generates a default implementation for deftype. Defining your own replaces the default version, which in most situations is just fine. However, there is a situation that requires more effort. Suppose you have a family of types for which you want to implement a common print- method. The obvious approach for any multimethod would be to declare all those types as derived from some parent (a namespace-qualified keyword will do, there is no need to have any implementation for a parent type) and have a print-method implementation for the parent. The problem is just that the type's default implementation will be used in preference to the shared one. The solution is to remove the default method using remove-method. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
[patch] Re: Sequential vs. "divide and conquer" algorithm
On Mon, Mar 22, 2010 at 5:39 AM, Michał Marczyk
wrote:
>
> Not sure if I want to draw any particular conclusion from this...
> Probably not, since I'm not yet done wondering to which degree I might
> be correct in thinking it. :-) I do want to stress once again the need
> for benchmarking with expensive tasks, though. Addition is so cheap
> that it's guaranteed not to be worth the bookkeeping cost of fancy
> work splitting solutions.
Sure. I'm testing the code with very light tasks purely for evaluating
the internal overhead of the algorithm. That's not what I'd use in a
real application.
Anyway, I wrote some vector decomposition code in Java that seems to
yield good results. Please find the source files attached. I'm not
very familiar with Clojure implementation so the code is pretty ugly,
but it works for my limited purposes.
The code provides a "partition" method for vectors, which decomposes
the vector into chunks exposing the internal structure of the
PersistentVector. Data are not copied or moved around (except for
allocating new wrapping subvectors) so the code is reasonably fast. It
does not, however, attempt to balance the tree. Currently the
"partition" method decomposes the vector down to single chunks,
perhaps it makes sense to let the user limit the depth of this process
to control the size and number of chunks.
I've tested the code with:
(defn sum_seq2 [vec]
(reduce + vec))
(defn- sum_tree_int5 [vec]
(let [s (seq vec)]
(if (vector? (first s))
(reduce + (map sum_tree_int5 vec))
(.reduce (chunk-first s) + 0
(defn sum_tree5 [vec]
(let [v (. vec (partition))]
(sum_tree_int5 v)))
(def l3 (vec (range 1 100)))
user=> (dotimes [_ 5] (time (sum_seq2 l3)))
"Elapsed time: 72.643896 msecs"
"Elapsed time: 77.785335 msecs"
"Elapsed time: 71.331996 msecs"
"Elapsed time: 70.790584 msecs"
"Elapsed time: 73.085287 msecs"
nil
user=> (dotimes [_ 5] (time (sum_tree5 l3)))
"Elapsed time: 88.355671 msecs"
"Elapsed time: 96.527659 msecs"
"Elapsed time: 96.205825 msecs"
"Elapsed time: 95.339803 msecs"
"Elapsed time: 95.249012 msecs"
nil
If you replace "map" with "pmap" the results get worse (tested on a
2-core cpu) which is not that surprising, taking into account the size
of chunks and tasks:
user=> (dotimes [_ 5] (time (sum_tree5 l3)))
"Elapsed time: 962.212255 msecs"
"Elapsed time: 956.484688 msecs"
"Elapsed time: 967.799812 msecs"
"Elapsed time: 947.298315 msecs"
"Elapsed time: 973.367556 msecs"
nil
Cheers,
Andrzej
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
diff -Nru clojure-1.1.0-orig/src/jvm/clojure/lang/PersistentVector.java clojure-1.1.0/src/jvm/clojure/lang/PersistentVector.java
--- clojure-1.1.0-orig/src/jvm/clojure/lang/PersistentVector.java 2009-12-31 09:11:38.0 +0900
+++ clojure-1.1.0/src/jvm/clojure/lang/PersistentVector.java 2010-03-22 16:43:47.0 +0900
@@ -18,8 +18,8 @@
public class PersistentVector extends APersistentVector implements IEditableCollection{
static class Node{
- final AtomicReference edit;
- final Object[] array;
+ public final AtomicReference edit;
+ public final Object[] array;
Node(AtomicReference edit, Object[] array){
this.edit = edit;
@@ -35,10 +35,10 @@
final static AtomicReference NOEDIT = new AtomicReference(null);
final static Node EMPTY_NODE = new Node(NOEDIT, new Object[32]);
-final int cnt;
-final int shift;
-final Node root;
-final Object[] tail;
+public final int cnt;
+public final int shift;
+public final Node root;
+public final Object[] tail;
public final static PersistentVector EMPTY = new PersistentVector(0, 5, EMPTY_NODE, new Object[]{});
@@ -84,7 +84,7 @@
return new TransientVector(this);
}
-final int tailoff(){
+public final int tailoff(){
if(cnt < 32)
return 0;
return ((cnt - 1) >>> 5) << 5;
@@ -209,6 +209,19 @@
return ret;
}
+public PersistentVector partition(){
+ PersistentVector tailVec = new PersistentVector(tail.length, 5, EMPTY_NODE, tail);
+ int length = tailoff();
+ if (length == 0)
+ return tailVec;
+ int rootLength = length;
+ rootLength = ((rootLength - 1) >>> shift) + 1;
+ while (rootLength > 32)
+ rootLength = ((rootLength - 1) >>> 5) + 1;
+ VectorChunk rootVec = new VectorChunk(length, rootLength, shift, root.array);
+ return PersistentVector.create(rootVec, tailVec);
+}
+
public IChunkedSeq chunkedSeq(){
if(count() == 0)
return null;
diff -Nru clojure-1.1.0-orig/src/jvm/clojure/lang/VectorChunk.java clojure-1.1.0/src/
Re: Printing promises
On 22 Mar 2010, at 07:43, Meikel Brandmeyer wrote: No. The "problem" is, that for each type there is a unique print- method installed by deftype. You have to re-define this method and call the method for clojure.lang.IDeref directly. (See also above paste.) It may be easier to do a (remove-method print-method ::Promise) right after the deftype. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: General question: Petri nets and STM in clojure
Hi Andrzej, I'm not a Petri net specialist too, but I dont see how one could simulate the view of a Clojure programmer onto STM, without simulation too the stuff programmers doesnt see: Richs under-the-hood-magic. Regards, alux Andrzej schrieb: > On Mon, Mar 22, 2010 at 4:36 AM, alux wrote: > > > > as far as I understand, Petri nets are as powerful as any concurrent > > mechanism. That means you can do all the good things Clojure does, and > > all the bad things (the other languages do :) too in Petri nets. > > I wonder if Petri nets can be applied for modeling systems based on > STM (in Clojure's flavor). I've only seen them used in common > lock-based designs (not that it means anything - I barely touched the > surface). > > Andrzej -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Maven clojure:repl
Thank you Stuart, this closes some of my thinking loops. Greetings from Europe, alux Stuart Sierra schrieb: > Maven has a default search path, but it only works for the standard > plugins distributed by Apache. > > To use the Clojure plugin (any of the clojure:* commands) the pom.xml > must contain a section like this: > > > ... > > ... > > com.theoryinpractise > clojure-maven-plugin > 1.3.2 > > ... > > > > Incanter is divided into several different modules, each with its own > pom.xml. Some of them include the Clojure plugin, some do not > (presumably they don't need it). > > Incanter's top-level pom.xml does not include the Clojure plugin, so > clojure:* goals will not work in the top-level project directory. In > some of the module directories, such as "modules/incanter-app", the > clojure:* goals should work. > > -SS > > > > On Mar 21, 3:04 pm, alux wrote: > > Hello Stuart, > > > > yes, thats not in. I'm not enough into maven to know where the plugins > > have to be specified. I had the hope that maven searches its > > repository, when I call a specific goal of the form xxx:yyy - so this > > hope was in vain? > > > > Thank you for the comment. > > > > Regards, alux > > > > Stuart Sierra schrieb: > > > > > > > > > On Mar 20, 7:56 am, alux wrote: > > > > mvn clojure:repl > > > > > > But that doesnt work. > > > > > > [ERROR] BUILD ERROR > > > > [INFO] > > > > > > > > [INFO] The plugin 'org.apache.maven.plugins:maven-clojure-plugin' does > > > > not exist > > > > > Those instructions appear to be out-of-date for Incanter's current > > > source repository. The Clojure Maven plugin is not specified as a > > > plugin by the top-level pom.xml. This may be a bug to take up with > > > the Incanter developers. > > > > > -SS -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: General question: Petri nets and STM in clojure
Indeed. Petri nets are based on the idea of synchronization via localized token passing; STM tries to create an illusion of synchronization-free serial execution which explicitly supports non-local 'spooky action at a distance' for references. Petri nets are not a very useful modeling tool here. -Per On Mon, Mar 22, 2010 at 5:45 PM, alux wrote: > Hi Andrzej, > > I'm not a Petri net specialist too, but I dont see how one could > simulate the view of a Clojure programmer onto STM, without simulation > too the stuff programmers doesnt see: Richs under-the-hood-magic. > > Regards, alux > > Andrzej schrieb: >> On Mon, Mar 22, 2010 at 4:36 AM, alux wrote: >> > >> > as far as I understand, Petri nets are as powerful as any concurrent >> > mechanism. That means you can do all the good things Clojure does, and >> > all the bad things (the other languages do :) too in Petri nets. >> >> I wonder if Petri nets can be applied for modeling systems based on >> STM (in Clojure's flavor). I've only seen them used in common >> lock-based designs (not that it means anything - I barely touched the >> surface). >> >> Andrzej > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
This is definitely flamebait. However, he has a point. Perhaps we should make it clear on the Getting Started page that deploying Java is a prerequisite to deploying Clojure, and include links to resources on how to do that for the platform you are on. It's presently unclear to anyone without a Java background. However, everyone who has responded is right that developer experience notwithstanding, any sysadmin worth his/her salt will know how to install a JVM. On Mar 21, 5:08 pm, Marek Kubica wrote: > On Sun, 21 Mar 2010 10:42:12 -0800 > > Tim Johnson wrote: > > Here's how I installed the flash player on my system. > > 1)Downloaded install_flash_player_10_linux.tar.gz > > 2)Unzipped libflashplayer.so > > 3)Copied to /usr/lib/firefox-3.5.2/plugins/ > > Here's how I installed the Clojure REPL on my system. > 1) Downloaded clojure-1.1.0.zip > 2) Unzipped clojure.jar > 3) Ran java -jar clojure.jar > > Hardly any different. > > FWIW, posting on a list and declaring immediately that one will > unsubscribe afterwards, not even reading replies is near-flamebait > quality. > > regards, > Marek -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
To add the perspective of a true newbie to this dogpile, I'm going to have to say that the OP was just plain wrong. He made a major mistake -- wanting to compile clojure for himself on a platform that's not exactly friendly to Java development in the first place (Slackware, not Linux in general) -- and promptly blamed that on the wrong tool. Are there some barriers to entry for a newbie? Hell, yes. I, for example, can't stand EMACS (insert the "great OS with crappy editor" gag here), so the EMACS-centric nature of the tools currently available is definitely a downer, as is the community assumption that anybody who'd want to use clojure is OBVIOUSLY an EMACS user. That's OK, though. On the Java side the assumption is that everybody uses Eclipse and I hate that more than I hate EMACS. This hasn't stopped me from using Java when I've needed to. Another, slightly worse, problem is that Clojure is a moving target. I have the book *Programming Clojure* and have noted already that the language is changing out from underfoot. If I'm not careful I suspect that in a years' time what I "know" about Clojure will be out of date or quite possibly even flatly wrong. This is a more serious problem than "I don't get JAR files" like the OP had, especially since there doesn't seem to be a coherent resource anywhere describing the changes -- lots of work is being put into changes but not so much is being put into *communicating* those changes. (Insert the usual round of people utterly missing the point by linking to blog X here and blog Y here and blog Z here talking about the changes.) Again I don't think this is a major problem, though. Clojure is a young language and at this early stage in its development it's inevitable that there will be large changes (as theory hits the real world). Further, anybody who's been in the industry for as long as the OP has claimed to have been knows full well that documentation *always* lags behind development. I think it telling that he's pointing to mature (and, in the case of Rebol, beyond end-of-life) products to show how documentation "should be done". It indicates to me that he's not got a lot of experience with new programming environments. TL;DR summary: this newbie thinks that yes, there are a few barriers to entry for new Clojure users but they're nowhere near as serious as the OP claims they are and are not even unusually bad for what is normal in this industry. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Clojure and JMS - Sample program
This is the follow-up code I wrote to help me understand JMS-Topic (javax.jms.Topic). Regards, John (ns jms.jms-topic (:use [jms.jms-test :only (get-initial-context get-message-text)]) (:import (javax.jms Session MessageListener))) (defn publish-term-message-to-topic [tPublisher tSession] (.publish tPublisher (.createMessage tSession))) (defn publish-message-to-topic [tPublisher tSession] (let [message (.createTextMessage tSession)] (.setText message (get-message-text)) (println (format "Publishing message - %s ..." (.getText message))) (.publish tPublisher message))) (defn publish-n-messages-to-topic [tPublisher tSession num-messages qReceiver qConnection] ;; Wait for subscribers (println "Waiting for subscribers...") (let [subscriber-available (ref false)] (.setMessageListener qReceiver (proxy [MessageListener][] (onMessage [message] (dosync (ref-set subscriber- available true) (.start qConnection) (while (false? @subscriber-available) (Thread/sleep 1000)) (.close qConnection) (println "Hoo-rah!! We have a subscriber")) (loop [n num-messages] (if (zero? n) (do (publish-term-message-to-topic tPublisher tSession) (println "*Done publishing messages to topic!*")) (recur (do (publish-message-to-topic tPublisher tSession) (dec n)) (defn process-topic-messages [tSubscriber tConnection qSender qSession] ;; Snooze a bit before we are ready to process topic messages (Thread/sleep (* 10 1000)) (println "-- Subscriber is now online --") (.send qSender (.createMessage qSession)) (let [done-processing (ref false)] (.setMessageListener tSubscriber (proxy [MessageListener][] (onMessage [message] (if (instance? javax.jms.TextMessage message) (println (format "Read message: %s" (.getText message))) (dosync (ref-set done- processing true)) (.start tConnection) (while (false? @done-processing) (Thread/sleep 1000))) (.close tConnection) (println "==Read all messages off the topic!!==")) (defn main [] (let [ctx (get-initial-context) tConFactory (.lookup ctx "TopicConnectionFactory") tConnection (.createTopicConnection tConFactory) tSession (.createTopicSession tConnection false Session/ AUTO_ACKNOWLEDGE) topic (.createTopic tSession "TestTopic") tPublisher (.createPublisher tSession topic) tSubscriber (.createSubscriber tSession topic) qConFactory (.lookup ctx "QueueConnectionFactory") qConnection (.createQueueConnection qConFactory) qSession (.createQueueSession qConnection false Session/ AUTO_ACKNOWLEDGE) queue (.createQueue qSession "controlQueue") qSender (.createSender qSession queue) qReceiver (.createReceiver qSession queue)] (.start (Thread. (fn[] (publish-n-messages-to-topic tPublisher tSession 10 qReceiver qConnection (.start (Thread. (fn[] (process-topic-messages tSubscriber tConnection qSender qSession)) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On 2010 Mar 21, at 11:52 PM, Cosmin Stejerean wrote: On Sun, Mar 21, 2010 at 10:20 PM, Luc Préfontaine > wrote: Yes we could have a complete package to run Clojure from the shell command line but how far could someone go with this to build a workable system without an IDE ? [...] Comments anyone ? I can get pretty far writing an application in Python with nothing more than good command line support and syntax highlighting in any text editor. Anything extra like completions, refactoring, etc, are just nice-to-haves. I don't see why an IDE is required for writing workable Clojure apps. +1 I use a Mac with MacPorts. Pulled down clojure and clojure-contrib ports. Only thing I had to do (and this was -not- easy to figure out), was create a .clojure file that pointed to the contrib jar. But that is how the clj wrapper in the clojure port works. I suppose I could also muck around with my class path, or do other things... There is a high Java tax on using clojure for those of us coming from non-Java languages. I'm willing to accept that I need to read the Java docs on how strings, or, whatever, work. But getting clojure itself set up? Please, do -not- make "pre-existing familiarity with an IDE" a prerequisite. There are enough learning curves as it is. -Doug P.S. I used Emacs back when Gosling was writing his version of it at CMU, before Java even existed, and now I use (g)vim. It's nice that there are other IDEs working with clojure, but not so nice to assume non-Java users are using some VisualStudio or other heavy-weight IDE. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: General question: Petri nets and STM in clojure
Hi alux, Andrej, Thanks! I'm still trying to understand how STM works in Clojure, so I would be happy if someone could tell me what's the relationship between Petri nets and the STM model. Is Petri nets analogous to the STM? If you have any good online resource, I would be very grateful if you can send some to me. Hopefully, the understanding I get can be shared with everyone. I think concurrency is quite important for today's applications, and I'm quite interested in that aspect of Clojure. Ryan On Mar 22, 11:14 am, Andrzej wrote: > On Mon, Mar 22, 2010 at 4:36 AM, alux wrote: > > > as far as I understand, Petri nets are as powerful as any concurrent > > mechanism. That means you can do all the good things Clojure does, and > > all the bad things (the other languages do :) too in Petri nets. > > I wonder if Petri nets can be applied for modeling systems based on > STM (in Clojure's flavor). I've only seen them used in common > lock-based designs (not that it means anything - I barely touched the > surface). > > Andrzej -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg wrote: > > Every time I've started up with a clojure project I've had to spend a few > hours fiddling with the environment, not that I don't do that with other > languages, but it would be nice with an officially sanctioned solution for > setting up a sane environment. Even better, an officially sanctioned solution expressed both as documentation, and as a collection of shell scripts for all the major platforms. (As another non-java-familiar clojure adoptee, classpaths were definitely a hurdle) 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Is my first impression right or wrong ? Is Clojure harder to setup from Windows for beginners ? Would an installer (.msi) help by hiding Java related details and providing some basic scripts to run it ? Luc P. On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > wrote: > > > > Every time I've started up with a clojure project I've had to spend a few > > hours fiddling with the environment, not that I don't do that with other > > languages, but it would be nice with an officially sanctioned solution for > > setting up a sane environment. > > Even better, an officially sanctioned solution expressed both as > documentation, and as a collection of shell scripts for all the major > platforms. > > (As another non-java-familiar clojure adoptee, classpaths were > definitely a hurdle) > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Haven't tried setting it up on windows, but an msi that hid the java details would be a nice plus, provided hat the abstraction never leaked (i.e. that you could do all the basic clojure operations without having to stop and edit or bypass the scripts). martin On Mon, Mar 22, 2010 at 5:01 PM, Luc Préfontaine wrote: > Is my first impression right or wrong ? > > Is Clojure harder to setup from Windows for beginners ? > > Would an installer (.msi) help by hiding Java related details and providing > some basic scripts to run it ? > > Luc P. > > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > wrote: >> >> Every time I've started up with a clojure project I've had to spend a few >> hours fiddling with the environment, not that I don't do that with other >> languages, but it would be nice with an officially sanctioned solution for >> setting up a sane environment. > > Even better, an officially sanctioned solution expressed both as > documentation, and as a collection of shell scripts for all the major > platforms. > > (As another non-java-familiar clojure adoptee, classpaths were > definitely a hurdle) > > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I use OS X and had only minor trouble getting Clojure to run the first time. But even minor trouble still has a disproportionate effect on someone's first impression. The out-of-box experience matters for everything and programming languages are no exception. Eclipse is a good example of a Java developer-oriented application with a good out-of-box experience on all platforms. Shell scripts for UNIX and installers for Windows and OS X would go a long way towards improving that for Clojure. -Per On Mon, Mar 22, 2010 at 6:31 PM, Luc Préfontaine wrote: > Is my first impression right or wrong ? > > Is Clojure harder to setup from Windows for beginners ? > > Would an installer (.msi) help by hiding Java related details and providing > some basic scripts to run it ? > > Luc P. > > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > wrote: >> >> Every time I've started up with a clojure project I've had to spend a few >> hours fiddling with the environment, not that I don't do that with other >> languages, but it would be nice with an officially sanctioned solution for >> setting up a sane environment. > > Even better, an officially sanctioned solution expressed both as > documentation, and as a collection of shell scripts for all the major > platforms. > > (As another non-java-familiar clojure adoptee, classpaths were > definitely a hurdle) > > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I'd agree with that, I've setup Clojure on Linux, Mac and Windows and I found Windows the most difficult. Granted, I virtually never use Windows, but it felt like I was fighting it by being at the command line, but had no choice but to be there. On 22 Mar 2010, at 11:31, Luc Préfontaine wrote: > Is my first impression right or wrong ? > > Is Clojure harder to setup from Windows for beginners ? > > Would an installer (.msi) help by hiding Java related details and providing > some basic scripts to run it ? > > Luc P. > > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: >> >> On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg >> wrote: >> > >> > Every time I've started up with a clojure project I've had to spend a few >> > hours fiddling with the environment, not that I don't do that with other >> > languages, but it would be nice with an officially sanctioned solution for >> > setting up a sane environment. >> >> Even better, an officially sanctioned solution expressed both as >> documentation, and as a collection of shell scripts for all the major >> platforms. >> >> (As another non-java-familiar clojure adoptee, classpaths were >> definitely a hurdle) >> >> 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. Edmund "Do it with love, l-o-v-e" MJ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Don't twist my post away from it's purpose... I am not making an IDE a pre-requisite for learning purposes. The original poster was talking about getting Clojure usable by corporations... he was not talking about academic learning. Too bad he was not aware that there are other IDEs available other than the M..ft thing. Not even looking at the documented alternatives before saying anything is unprofessional at best in this regard. You can still code 3 lines+ systems without an IDE (IDE can be as simple as VIM or this other popular text editor on MacOSX) but this approach has definitively limits. Just in case you have doubts I did a lot of these in the past before even VIM like editors became the norm. I would not revert back to these times. If some are saying they can do a lot without an IDE, fine, but that's pointless here, it seems that the main problem is the first contact with Clojure. It looks like it's rough and there's a need for some smoothness there. The main goal being to hide the Java gears as much as possible. This is the feedback I was trying to get. If .NET gears where not hidden on first contact, it would appear has bad as the JVM. With .NET, it's later in the learning process that this strikes you :)) At first it looks great (all these windows, ). I was asking for some requirements... can we start here ? a) A need for a Windows based installer b) Startup scripts to hide java machinery, probably pre-tuned to hide all these horrible Java flags c) Update mode to keep the Clojure run time up to date with whatever version you may want (1.0, 1.1, 1.2, nightly build, ...) d) a) and c) Use available public repositories to get components. e) A need for installers on other platforms ? U*X, MacOs X ? Any value there ? Starting Clojure from command line on Windows is this satisfactory for everyone ? Maybe a helper to start CMD in a folder from a context menu would be of some help ? Anything else ? Luc P. On Mon, 2010-03-22 at 00:33 -0400, Douglas Philips wrote: > On 2010 Mar 21, at 11:52 PM, Cosmin Stejerean wrote: > > On Sun, Mar 21, 2010 at 10:20 PM, Luc Préfontaine > > > > wrote: > > Yes we could have a complete package to run Clojure from the shell > > command line but how far could someone go with this > > to build a workable system without an IDE ? > > > > [...] > > > > Comments anyone ? > > > > > > I can get pretty far writing an application in Python with nothing > > more than good command line support and syntax highlighting in any > > text editor. Anything extra like completions, refactoring, etc, are > > just nice-to-haves. I don't see why an IDE is required for writing > > workable Clojure apps. > > +1 > > I use a Mac with MacPorts. Pulled down clojure and clojure-contrib > ports. > Only thing I had to do (and this was -not- easy to figure out), was > create a .clojure file that pointed > to the contrib jar. But that is how the clj wrapper in the clojure > port works. I suppose I could also > muck around with my class path, or do other things... > > There is a high Java tax on using clojure for those of us coming from > non-Java languages. > I'm willing to accept that I need to read the Java docs on how > strings, or, whatever, work. > > But getting clojure itself set up? Please, do -not- make "pre-existing > familiarity with an IDE" a prerequisite. There are enough learning > curves as it is. > > -Doug > > P.S. I used Emacs back when Gosling was writing his version of it at > CMU, before Java even existed, and now I use (g)vim. It's nice that > there are other IDEs working with clojure, but not so nice to assume > non-Java users are using some VisualStudio or other heavy-weight IDE. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
java vector canvas
A bit off topic, but I'm hoping someone here will know - is there a vector canvas available for the jvm? I mean something like tk's canvas, where you can draw vector objects that retain their own identity, and can independently respond to mouse clicks. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mon, Mar 22, 2010 at 5:13 PM, Per Vognsen wrote: > good example of a Java developer-oriented application with a good > out-of-box experience on all platforms. Shell scripts for UNIX and > installers for Windows and OS X would go a long way towards improving > that for Clojure. In my opinion, atleast in the GNU/Linux world, it should be left to distributors to do this job. On Debian for instance, one just need to do `apt-get install clojure clojure-contrib' to get clojure installed. Of course, one can provide instructions on how to build by oneself. -- Ramakrishnan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Note that I didn't propose an installer except for OS X and Windows. Only a DWIM shell script. -Per On Mon, Mar 22, 2010 at 7:04 PM, Ramakrishnan Muthukrishnan wrote: > On Mon, Mar 22, 2010 at 5:13 PM, Per Vognsen wrote: >> good example of a Java developer-oriented application with a good >> out-of-box experience on all platforms. Shell scripts for UNIX and >> installers for Windows and OS X would go a long way towards improving >> that for Clojure. > > In my opinion, atleast in the GNU/Linux world, it should be left to > distributors to do this job. On Debian for instance, one just need to > do `apt-get install clojure clojure-contrib' to get clojure installed. > > Of course, one can provide instructions on how to build by oneself. > > -- > Ramakrishnan > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: java vector canvas
On Mon, Mar 22, 2010 at 8:59 PM, Martin DeMello wrote: > A bit off topic, but I'm hoping someone here will know - is there a > vector canvas available for the jvm? I mean something like tk's > canvas, where you can draw vector objects that retain their own > identity, and can independently respond to mouse clicks. http://www.piccolo2d.org/ -Andrzej -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Setting Compiler.LOADER or USE_CONTEXT_CLASSLOADER before initialization
Hi, I'm attempting to write some Clojure code to work on the 80legs crawling service. The current code is available at http://github.com/pingles/crawly/ (note there's not much to it so far). 80legs impose some security restrictions to ensure you can't do anything too dangerous when it's running on the machines in the cluster. Part of this includes accessing the system classloader. However, accessing the class loader that loads the 'app' code is fine. I'm trying to find a way of ensuring that when the Clojure runtime kicks in the class loader can be bound to something provided from the Java adapter side (see http://github.com/pingles/crawly/blob/master/src/com/eightylegs/customer/ClojureAdapterApp.java). The line that actually raises the security exception at the moment is on Line 1498 of RT.java (clojure version 1.1.0). Thanks for any help/suggestions! Paul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure naming convention for accessors vs. local variables
On Mar 20, 2010, at 2:50 PM, cageface wrote: So will deftype/protocol be the recommended, idiomatic way to implement ADTs in Clojure 1.2? Yes. Will the current map/struct based approaches essentially be deprecated? These are two different things. deftypes will work fine with map-based code, and doing so is an important part of the design of Clojure. The intent here is definitely *not* to start building walled gardens of basic data manipulation logic. If you fund yourself writing (defprotocol Employee (get-name [emp])) you are doing it wrong. We get a lot of leverage in Clojure by having a large set of functions that can generically manipulate data via associative abstractions, and deftype types will often be associative things. Protocols are for adding additional abstractions. deftype *will* supplant defstruct (or perhaps be used to reimplement it) The doc here http://www.assembla.com/wiki/show/clojure/Datatypes suggested to me that they were more for interfacing with Java in a more efficient manner? Not at all. They are a very useful abstraction mechanism in their own right, even if you never implement an interface or expose to Java. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
On Mar 20, 2010, at 3:56 AM, Stuart Halloway wrote: The questions below refer to the gist at https://gist.github.com/336674/9ab832a86d203731c6379404d20afded79fe5f5b and to protocols in general: (1) Clojure automatically types hints the first argument when extending a protocol to an interface or class, which is great. But you cannot override this with your own type hint. Wanting to do this would be very unusual, but see the RandomAccess/List case in the example where one interface signifies the performance characteristics but a different interface has the methods you want. Should it be possible to override the type hint? No. Your wanting to do this is a hint that extending the protocol to RandomAccess is not quite right. (2) The code for chop is repeated across multiple classes. What is the idiomatic way to DRY this? Should I drop down to using raw extend with maps, or is there more mixin support to come? The idiomatic way is to write an ordinary function, e.g. chop is not primitive and can just be written in terms of the protocol. (3) The code for slice is also repeated, but only for one arity. Does that change the answer to #2? Here too, the resulting API is just a set of functions. Whether they come from protocols is irrelevant to the consumer. The slice function might end up an ordinary function defined in terms of a do-slice member of the protocol. (4) Extending to two different interfaces that a single class implements results in one class winning arbitrarily (e.g. IPersistentVector/RandomAccess). This should also be a fairly unusual case, but is there any plan for specifying precedence? Not yet. Avoid this situation (and you can here, easily) (5) It appears that the overhead for calling a protocol adds a hash lookup (find-protocol-method) over the method invocation itself. Is that the right way to summarize the performance implications? No, since the result is cached. The real every-call overhead is having to go through the var to detect changes to the protocol, vs the inline- defined case where the implementation of the interface can't change given the same instance class. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Sequential vs. "divide and conquer" algorithm
On Mar 21, 2010, at 8:29 AM, Andrzej wrote: On Sun, Mar 21, 2010 at 6:37 PM, Jarkko Oranen wrote: Rich has done some work on using the JDK7 ForkJoin Library to parallelise map and reduce over vectors, since they are already internally structured as trees. It hasn't been touched in a while, but as far as I know the code lives in the 'par' branch of the clojure repository, and works with JDK6 if you install an additional jar. Thank you. I'll keep an eye on it. You really do need to look at par, and fork/join as well. In particular, your desire for even partitioning and balancing is obviated by work stealing. If you think about it, you'll see that that would become immediately necessary as soon as you might have non- uniform cost-per-operation at the leaves, i.e. then perfect partitioning would also become non-ideal. Rich Yesterday I looked at the implementation of the PersistentVector class, trying to figure out how to exploit its internal structure to decompose the vector. I hit several issues though: 1. The trees are not balanced. So in order to split the vector roughly in half one would have to deal with the root node _and_ nodes at one level below it. 2. Node structure doesn't have a "cnt" field but PersistentVector does. When splitting the vector, length of each part would have to be calculated, which could be costly. Assuming there are no holes in the tree it might be enough to look at the depth of the tree and the number of fully occupied slices in the root node. 3. Apparently PersistentVector doesn't allow an empty tail array (for lenghts > 0). I.e. tail can have a length of 1 to 32. This would have to be changed (i.e. 0 to 31) if the partitioning is going to work fast. 4. Should partitioning stop once the vector is destructured down to a single chunk (32 values)? Destructuring vectors to single values would be more convenient to use but would only add overhead without any reduction in the access time. 5. With all this we can get subvectors with very fast access times _but_ the destructuring process itself can still trigger a lot of allocation (each subvector needs at least one new node - a root). So I'm not sure whether this would give any net performance gain, perhaps not. Andrzej -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
> I agree with Stuart that the user experience should be friendly on all > supported platforms. I also agree. The best setup experience I've had so far is using NetBeans with the Enclojure plugin. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mon 22/03/10 11:31 , "LucPréfontaine" lprefonta...@softaddicts.ca sent: > Is my first impression right or wrong ? > Is Clojure harder to setup from Windows for beginners ? > Would an installer (.msi) help by hiding Java related details and > providing some basic scripts to run it ? I think there are likely two camps: Java users seeing Clojure as a library that they can integrate with their existing projects; and non-Java users, wanting something with an installation experience something like Python. For Java users, I think a zip with a jar file in it is great, and they'll likely know what to do with it. I'd be a bit startled to find a Java library bundled in a .msi installer, it would make Clojure seem foreign and invasive. I don't think an msi would really add much at all, other than potentially making it harder to install in some environments. A zip file with working startup scripts would be enough I think? I'd like to see the documentation bundled too, so that you have a version of the documentation that corresponds to the version of clojure that you have downloaded. Perhaps the zip file could have a lib directory that the scripts pull in all jar files from, to make adding things like database drivers and contrib to the environemnt easier? Perhaps how Ant aranges its bin directory and lib folder is a good model to borrow from? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
On Mon, Mar 22, 2010 at 7:20 PM, Rich Hickey wrote: > > On Mar 20, 2010, at 3:56 AM, Stuart Halloway wrote: > >> The questions below refer to the gist at >> https://gist.github.com/336674/9ab832a86d203731c6379404d20afded79fe5f5b and >> to protocols in general: >> >> (1) Clojure automatically types hints the first argument when extending a >> protocol to an interface or class, which is great. But you cannot override >> this with your own type hint. Wanting to do this would be very unusual, but >> see the RandomAccess/List case in the example where one interface signifies >> the performance characteristics but a different interface has the methods >> you want. Should it be possible to override the type hint? > > No. Your wanting to do this is a hint that extending the protocol to > RandomAccess is not quite right. > >> >> (2) The code for chop is repeated across multiple classes. What is the >> idiomatic way to DRY this? Should I drop down to using raw extend with maps, >> or is there more mixin support to come? >> > > The idiomatic way is to write an ordinary function, e.g. chop is not > primitive and can just be written in terms of the protocol. Even if the functions can be written in terms of the core protocol, putting them in the protocol makes it possible to implement higher-performance specialized versions for some containers while supplying default implementations in terms of the core protocol functions via mixins. This is how Scala's Seq trait is designed: http://www.scala-lang.org/docu/files/api/scala/Seq.html -Per -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
> In my opinion, atleast in the GNU/Linux world, it should be left to > distributors to do this job. On Debian for instance, one just need to > do `apt-get install clojure clojure-contrib' to get clojure installed. It's equally simple on the Mac with Homebrew [1]: $ brew install clojure clojure-contrib MacPorts is probably along the same lines. Then there's also my little ClojureX [2] project, where I'd really like some more feedback by Windows users. Maybe some of the people in this thread who are dissatisfied with Clojure on Windows can give it a try? Michael [1] http://github.com/mxcl/homebrew [2] http://github.com/citizen428/ClojureX/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: java vector canvas
On Mon, Mar 22, 2010 at 7:59 AM, Martin DeMello wrote: > A bit off topic, but I'm hoping someone here will know - is there a > vector canvas available for the jvm? I mean something like tk's > canvas, where you can draw vector objects that retain their own > identity, and can independently respond to mouse clicks. > > martin Also the Batik SVG toolkit. Very good, but also maybe overkill. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Setting Compiler.LOADER or USE_CONTEXT_CLASSLOADER before initialization
On Mon, Mar 22, 2010 at 7:42 AM, Paul Ingles wrote: > > I'm trying to find a way of ensuring that when the Clojure runtime > kicks in the class loader can be bound to something provided from the > Java adapter side (see > > http://github.com/pingles/crawly/blob/master/src/com/eightylegs/customer/ClojureAdapterApp.java > ). I'd be very interested in finding a solution to this as well. I wrote a small Ant plugin for building Clojure projects that broke after 1.0 because of the change to RT.USE_CONTEXT_CLASSLOADER because of some tricky interactions with how Ant's ClassLoader loads Clojure. Unfortunately, I haven't had the time or need to look into it more than I already have, but I know some people would be interested in a solution, which I'd be happy to get in if found. It sounds like a solution here may also work for me. Thanks, - J. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Luc, Windows users should be good to go. Clojurebox, Enclojure & CCW are ready for use for any Java dev with some experience. As for the installation process, pick you poison: http://vimeo.com/tag:install_clojure Sorry to self-post, Sean On Mar 22, 7:31 am, Luc Préfontaine wrote: > Is my first impression right or wrong ? > > Is Clojure harder to setup from Windows for beginners ? > > Would an installer (.msi) help by hiding Java related details and > providing some basic scripts to run it ? > > Luc P. > > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > > wrote: > > > > Every time I've started up with a clojure project I've had to spend a few > > > hours fiddling with the environment, not that I don't do that with other > > > languages, but it would be nice with an officially sanctioned solution for > > > setting up a sane environment. > > > Even better, an officially sanctioned solution expressed both as > > documentation, and as a collection of shell scripts for all the major > > platforms. > > > (As another non-java-familiar clojure adoptee, classpaths were > > definitely a hurdle) > > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
FWIW Michael it was your ClojureX was what got me going best in the beginning, but on Mac OS X, not Windows. Getting a minimal clojure-aware editing setup was a little harder -- the emacs-setup stuff you had in an earlier version of ClojureX got me started there too, but I had to do some other stuff later to get slime working... e.g. manually copying clojure.jar and clojure-contrib.jar to my .emacs. It's kind of funny to see the range of reactions to the OP's post. This stuff really is very simple once you know how to do it, but it's not necessarily simple to people coming from different backgrounds. -Lee On Mar 22, 2010, at 9:14 AM, Michael Kohl wrote: >> In my opinion, atleast in the GNU/Linux world, it should be left to >> distributors to do this job. On Debian for instance, one just need to >> do `apt-get install clojure clojure-contrib' to get clojure installed. > > It's equally simple on the Mac with Homebrew [1]: > > $ brew install clojure clojure-contrib > > MacPorts is probably along the same lines. Then there's also my little > ClojureX [2] project, where I'd really like some more feedback by > Windows users. Maybe some of the people in this thread who are > dissatisfied with Clojure on Windows can give it a try? > > Michael > > [1] http://github.com/mxcl/homebrew > [2] http://github.com/citizen428/ClojureX/ > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: General question: Petri nets and STM in clojure
Hi Ryan, well, to describe in the terms of Petri nets how the Clojure STM is built? Thats a good topic for a thesis, but rather hard to do in news group articles. If you try to understand how to use the STM in Clojure, Petri nets probably will not help you. STM rather asks you to forget the stuff under the hood. (The best way I know to learn this is still Rich Hickeys videos.) Dont know whether thats been helpful, but I cant do more. Kind regards, alxu Ryan Teo schrieb: > Hi alux, Andrej, > Thanks! > I'm still trying to understand how STM works in Clojure, so I would > be happy if someone could tell me what's the relationship between > Petri nets and the STM model. > Is Petri nets analogous to the STM? If you have any good online > resource, I would be very grateful if you can send some to me. > Hopefully, the understanding I get can be shared with everyone. I > think concurrency is quite important for today's applications, and I'm > quite interested in that aspect of Clojure. > > Ryan > > On Mar 22, 11:14 am, Andrzej wrote: > > On Mon, Mar 22, 2010 at 4:36 AM, alux wrote: > > > > > as far as I understand, Petri nets are as powerful as any concurrent > > > mechanism. That means you can do all the good things Clojure does, and > > > all the bad things (the other languages do :) too in Petri nets. > > > > I wonder if Petri nets can be applied for modeling systems based on > > STM (in Clojure's flavor). I've only seen them used in common > > lock-based designs (not that it means anything - I barely touched the > > surface). > > > > Andrzej -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
mvn clojujure:repl - no keyboard echo
Hello, I try to get comfortable with the maven clojure plugin, but am still fighting. Precondition: I'm bound to use M$ Windows (XP currently) at my job, so I want to get stuff running there. The clojure:repl Is running now. But when I start typing, I dont see stuff. The characters I type are echoed to the shell only after I hit Enter. So thats not really a usable REPL. Anybody heard about that and has a solution? Many thanks, alux -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: java vector canvas
On Mon, Mar 22, 2010 at 6:05 PM, Andrzej wrote: > On Mon, Mar 22, 2010 at 8:59 PM, Martin DeMello > wrote: >> A bit off topic, but I'm hoping someone here will know - is there a >> vector canvas available for the jvm? I mean something like tk's >> canvas, where you can draw vector objects that retain their own >> identity, and can independently respond to mouse clicks. > > http://www.piccolo2d.org/ Thanks! That looks beautiful. Will have a go at hooking it up to clojure as soon as I get some free time. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
think about the difference between putting flash or python on a machine compared to clojure. there's more of a system-level "path" feel to those things (even though each user can have their own environment). I mean, you can add a clj script to your path and get the same effect, but that's what's different. He's not talking about someone messing around with a language ... he's talking about trying to imagine that the language is now part of the system. Again, Fantom sort of has this feel. Part of the DEFAULT instructions is to mess with your path and get things going. Check out the Fantom website. So simple and straight forward and inviting. On Sun, Mar 21, 2010 at 11:07 PM, Seth wrote: > I hate to feed trolls, but this is a solid example of passive- > aggresive behavior. Also, ignoring plausible sounding, spell-checked > diatribes is bad. > > The installation of one or two jar files from a Maven repository is > par for the JVM course. Deployment? Works on any reasonable JVM out > there. Could the install/deploy behavior be improved? Sure, but try > targeting something less ubiquitous than "ant". Slackware more modern > than Ubuntu?? > > Contrasting Clojure with Flash on Ubuntu really takes the cake. Flash > has never had a good reputation outside of Windows. Also, either the > poster is running as root (!) or has somehow forgotten a very > important su/sudo between steps 2 and 3. Either way, no sysadmin has > to be convinced. > > Wresting with pigs is bad because you get dirty and the pig likes it. > > On Mar 21, 2:42 pm, Tim Johnson wrote: > > I have evaluated clojure for the last couple of days, and it is both my > own > > professional decision and my recommendation to the professional > organizations > > that I belong to and report to that clojure is not ready for prime time. > > > > Before any of you think that I am a disgruntled newbie turned troll, know > > the following: > > > > 1)As soon as I see the copy of this email in my "clojure mailbox", I will > > unsubscribe from this mailing list, delete the clojure mailbox and I will > not > > be following up in any way. > > > > 2)In as much as clojure is a new programming language with a small but > > enthusiastic user base and a brilliant developer I confess to a certain > deja vu > > here. That would be rebol 10 years ago. Brilliantly conceived, > brilliantly > > designed by one of the best programmers on the planet. Never went > anywhere. > > I've used rebol for 10 years steadily and made a lot of money with it, > but > > there is almost 0 demand for rebol programmers out there. > > > > 3)Although I may be a noob with it comes to clojure and even more of a > noob > > when it comes to java, I have been a professional analyst and programmer > for 21 > > years and own my own company. Many seasoned programmers, analysts and > system > > adminstrators look at a new system as something to "employ". As a front > end for > > java, I do not consider clojure to be "employable". > > > > I think that clojure is brilliantly conceived and it is clear from what I > have > > read of Rich Hickey's words that his vision is right in the same channel > with > > mine, but that is not the problem. The fact that I respect the developer > and > > the product is the reason that I have taken this time to write this > email. > > > > The reason I choose NOT to employ clojure can be summed up in three > words. > > --- > > Install and deploy. > > --- > > > > I consider this to be clojure's fatal weakness. Certainly I can get > clojure up > > and running, but "selling" clojure to a sysadmin is going to be a problem > at > > this time. There was a time when PHP was NOT present on virtually all > webservers. > > PHP got it's "foot in the door" because it was very easy to deploy. > > > > Consider the two threads that I started up - one is titled "Web > programming in > > Clojure" - there's the good stuff. Generous reponse, lots of input. > > > > The other one is titled "Installation issues on slack 13.0 (ant?)". This > where > > it all falls apart. > > > > Sadly, this is like the first impression and we all know how lasting > first > > impressions are. In fact as you can see, the thread ended with no > resolution. > > I'm sorry to pick on "steve" but his response is a case study > > > > * Steve [100320 05:24]: > > > > > Reading the getting started page on the website will get you further > > > still :http://clojure.org/getting_started > > > > Sadly inadequate! Check out the comparable kawa resources and > instructions for > > a better example. > > > > > If you do need ant then a more modern distro will make your life much > > > easier (eg. apt-get install ant). > > > > Again, so inadequate. I also use ubuntu. Have for years. apt-get is a > thing > > of beauty. When it works. And bye the way, slackware is much more modern > > when it comes to up-to-date build tools. So know I not only have to > "sell" > > clojure to the sysadmins, I h
Re: clojure and clojure-contrib jars built with the 1.5 jdk
On Mar 21, 2010, at 8:50 PM, Stuart Sierra wrote: No, but you can change the configs and recompile. Clojure itself uses Ant, so "ant" on a machine with only Java 1.5 should do the trick. To install that custom JAR in your local Maven repository, download the "Maven Ant Tasks" JAR and run: ant -lib /path/to/maven-ant-tasks.jar ci-build Contrib uses Maven, so add thes lines to its pom.xml in the section: org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 Then "mvn install" to build the JARs and put them in your local repository. Why isn't this in the default build? Clojure targets 1.5, and so should contrib. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mon, Mar 22, 2010 at 1:26 AM, cej38 wrote: > I am a physicist by training and practice, this means that I am an > expert on Fortran 95. To say my exposure to Java is minimal would be > generous. And until last year when I heard about Clojure from a > friend, I thought LISP was a speech impediment. > > Setting up Clojure was a MAJOR problem for me, what with getting > path's and classpaths right. (Figuring out what a classpath is was a > challenge.) If it wasn't for the very patient help of a CS friend of > mine, I would not have figured it out. > > I think the documentation assumes that the user is comfortable with > Java. I feel like I am being asked to learn Java so that I can learn > Clojure. > Amen! I can understand why this was the initial road to get functionality going quickly, but I hope this goes away. > I am now an avid Clojure user, but there really does need to be better > descriptions of how to set Clojure up on the website. > > > On Mar 21, 4:37 pm, Quzanti wrote: > > Reading his post I got the impression he was a bit of an egocentric (a > > bit more information about himself than was relevant), those sorts > > tend to overreact. > > > > However I can imagine the whole just bung the jar file on your > > classpath thing wouldn't make much sense for a java newbie. It may > > highlight the need for some special 'getting started' documentation > > for Lisp programmers who have never used java, which I understand to > > be one target audience of clojure. > > > > > > > > > > > > > I don't understand the complaints about installing Clojure. As far as I > know > > > there's nothing required to 'install' Clojure beyond downloading the > > > clojure.jar, other than I guess having a working Java installation. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to clojure+ > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
The questions below refer to the gist at https://gist.github.com/336674/9ab832a86d203731c6379404d20afded79fe5f5b and to protocols in general: (1) Clojure automatically types hints the first argument when extending a protocol to an interface or class, which is great. But you cannot override this with your own type hint. Wanting to do this would be very unusual, but see the RandomAccess/List case in the example where one interface signifies the performance characteristics but a different interface has the methods you want. Should it be possible to override the type hint? No. Your wanting to do this is a hint that extending the protocol to RandomAccess is not quite right. Can you elaborate a little here? I can't extend to List, since I don't want all Lists, only those that are also RandomAccess. (2) The code for chop is repeated across multiple classes. What is the idiomatic way to DRY this? Should I drop down to using raw extend with maps, or is there more mixin support to come? The idiomatic way is to write an ordinary function, e.g. chop is not primitive and can just be written in terms of the protocol. I considered this, but thought it would be less discoverable. Does the caller care that chop is not primitive? I will argue no. The caller wants, given (say) a String, an easy way to ask "what things can I do with strings?" Separating protocols from non-primitive functions creates more places to look. In fact using protocols to begin with creates more places to look (right now the string functions all live in clojure.contrib.string). (3) The code for slice is also repeated, but only for one arity. Does that change the answer to #2? Here too, the resulting API is just a set of functions. Whether they come from protocols is irrelevant to the consumer. The slice function might end up an ordinary function defined in terms of a do- slice member of the protocol. (4) Extending to two different interfaces that a single class implements results in one class winning arbitrarily (e.g. IPersistentVector/RandomAccess). This should also be a fairly unusual case, but is there any plan for specifying precedence? Not yet. Avoid this situation (and you can here, easily) OK. (5) It appears that the overhead for calling a protocol adds a hash lookup (find-protocol-method) over the method invocation itself. Is that the right way to summarize the performance implications? No, since the result is cached. The real every-call overhead is having to go through the var to detect changes to the protocol, vs the inline-defined case where the implementation of the interface can't change given the same instance class. Am I saying something different? The cache requires a hash lookup, right? Stu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I have to say that while I'm sorry that we didn't snag the original poster as a Clojure user, he has actually done us a real favor. The most important customer is the pissed off customer who tells you why he is pissed off. You don't have to take everything he says to heart, but it is always worth listening to the one that got away. As someone who was a raw clojure beginner not all that long ago, a beginner with a lot of Java experience, I do think that we have a problem with the 'out of the box' experience. My first bit of evidence is the fact that the issue seems to come up fairly often. When you have a persistent customer complaint, you have to ask yourself, is the problem with the customer? In fact, before a recent intro-to-clojure talk I went ahead and built my own little 'get you going' project just to make it easier for the raw beginner: http://github.com/russolsen/dejour/downloads While dejour is just a quick and dirty thing that I put together in a few hours, I think that it captures what we need: a single zip/tar/jar file that you can download, unpack and run. No install, no git, no nothing. Just download, unpack and run a simple script. As someone else mentioned, JRuby does a really good job of this. We can at least as good as JRuby. How far can you get with just a repl and no ide? Perhaps just far enough to decide that this clojure thing is worth more time. Perhaps more: There is nothing in clojure that requires an ide any more than python or ruby or perl. It's a complicated world out there, full of very smart people with varying backgrounds. Some of them know lisp but not java. Some know java but no lisp. Some know neither but are smart nevertheless and are looking for a better language. Many of the engineers that I work with will run screaming from the room at the sight of a shell/batch script I think we want them all. We want every one of them to use clojure. Russ On Mar 22, 1:26 am, cej38 wrote: > I am a physicist by training and practice, this means that I am an > expert on Fortran 95. To say my exposure to Java is minimal would be > generous. And until last year when I heard about Clojure from a > friend, I thought LISP was a speech impediment. > > Setting up Clojure was a MAJOR problem for me, what with getting > path's and classpaths right. (Figuring out what a classpath is was a > challenge.) If it wasn't for the very patient help of a CS friend of > mine, I would not have figured it out. > > I think the documentation assumes that the user is comfortable with > Java. I feel like I am being asked to learn Java so that I can learn > Clojure. > > I am now an avid Clojure user, but there really does need to be better > descriptions of how to set Clojure up on the website. > > On Mar 21, 4:37 pm, Quzanti wrote: > > > > > Reading his post I got the impression he was a bit of an egocentric (a > > bit more information about himself than was relevant), those sorts > > tend to overreact. > > > However I can imagine the whole just bung the jar file on your > > classpath thing wouldn't make much sense for a java newbie. It may > > highlight the need for some special 'getting started' documentation > > for Lisp programmers who have never used java, which I understand to > > be one target audience of clojure. > > > > I don't understand the complaints about installing Clojure. As far as I > > > know > > > there's nothing required to 'install' Clojure beyond downloading the > > > clojure.jar, other than I guess having a working Java installation. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Sequential vs. "divide and conquer" algorithm
On Mon, Mar 22, 2010 at 9:40 PM, Rich Hickey wrote: > > You really do need to look at par, and fork/join as well. In particular, > your desire for even partitioning and balancing is obviated by work > stealing. If you think about it, you'll see that that would become > immediately necessary as soon as you might have non-uniform > cost-per-operation at the leaves, i.e. then perfect partitioning would also > become non-ideal. Thank you, Rich. Do I understand correctly that this work stealing scheme is a feature of the ForkJoin library and is not available with the pmap function? I've a trouble understanding what does the fjvtree function do. It looks like it is decomposing the vector before submitting it to the ForkJoin framework but I can't deduct how does the decomposed vector looks like, how should I use this function, etc. How does fjvtree compare against the patch I submitted today? Are they functionally equivalent as far as the vector decomposition part is concerned? -Andrzej -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
On 22 Mar 2010, at 14:12, Per Vognsen wrote: Even if the functions can be written in terms of the core protocol, putting them in the protocol makes it possible to implement higher-performance specialized versions for some containers while supplying default implementations in terms of the core protocol functions via mixins. This is how Scala's Seq trait is designed: Even though I don't like "me too" posts, I'll make an exception here because I think this is a very important point. I have an example in Clojure in my multiarray library: http://code.google.com/p/clj-multiarray/source/browse/src/multiarray/protocol.clj The function "rank" in MultiArrayProtocol is redundant in that it can always be implemented as (defn rank [x] (count (shape x))) However, for some implementations, "rank" could just return an integer field from a data structure, instead of constructing a vector for no other purpose than count the number of elements in it. That's why "rank" is a protocol 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure and clojure-contrib jars built with the 1.5 jdk
Actually, this is more complicated than I thought. The build processes will use whatever default version of Java is installed locally. Maven has config options for the Java *compiler* version to use, but that will only work for .java source files (of which there are non in contrib). The version of Java under which the Clojure compiler runs is just the local "java" executable. The solution, I suppose, is to install Java 1.5 on the build.clojure.org server and force it to be the default. -SS On Mar 22, 8:48 am, Rich Hickey wrote: > On Mar 21, 2010, at 8:50 PM, Stuart Sierra wrote: > > > > > > > No, but you can change the configs and recompile. > > > Clojure itself uses Ant, so "ant" on a machine with only Java 1.5 > > should do the trick. To install that custom JAR in your local Maven > > repository, download the "Maven Ant Tasks" JAR and run: > > ant -lib /path/to/maven-ant-tasks.jar ci-build > > > Contrib uses Maven, so add thes lines to its pom.xml in the > > section: > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > > > 1.5 > > 1.5 > > > > > > > Then "mvn install" to build the JARs and put them in your local > > repository. > > Why isn't this in the default build? Clojure targets 1.5, and so > should contrib. > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure and clojure-contrib jars built with the 1.5 jdk
By the way, Ant has the same problem: you can specify a target JDK version in the "javac" task, but not the "java" task. So the Clojure compiler runs with the default "java" executable on the local machine. -SS On Mar 22, 11:54 am, Stuart Sierra wrote: > Actually, this is more complicated than I thought. The build > processes will use whatever default version of Java is installed > locally. > > Maven has config options for the Java *compiler* version to use, but > that will only work for .java source files (of which there are non in > contrib). The version of Java under which the Clojure compiler runs > is just the local "java" executable. > > The solution, I suppose, is to install Java 1.5 on the > build.clojure.org server and force it to be the default. > > -SS > > On Mar 22, 8:48 am, Rich Hickey wrote: > > > > > On Mar 21, 2010, at 8:50 PM, Stuart Sierra wrote: > > > > No, but you can change the configs and recompile. > > > > Clojure itself uses Ant, so "ant" on a machine with only Java 1.5 > > > should do the trick. To install that custom JAR in your local Maven > > > repository, download the "Maven Ant Tasks" JAR and run: > > > ant -lib /path/to/maven-ant-tasks.jar ci-build > > > > Contrib uses Maven, so add thes lines to its pom.xml in the > > > section: > > > > > > > org.apache.maven.plugins > > > maven-compiler-plugin > > > > > > 1.5 > > > 1.5 > > > > > > > > > > Then "mvn install" to build the JARs and put them in your local > > > repository. > > > Why isn't this in the default build? Clojure targets 1.5, and so > > should contrib. > > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I looked at these videos and they are a very good starting point. Then do we have a communication problem getting these things known ? Are these videos listed on the "Getting started" page ? What about using contrib ? That would be the first "classpath" problem a newcomer would face. It looks to me that we have all the answers but not in a single spot. Luc P. On Mon, 2010-03-22 at 06:44 -0700, Sean Devlin wrote: > Luc, > Windows users should be good to go. Clojurebox, Enclojure & CCW are > ready for use for any Java dev with some experience. As for the > installation process, pick you poison: > > http://vimeo.com/tag:install_clojure > > Sorry to self-post, > Sean > > On Mar 22, 7:31 am, Luc Préfontaine > wrote: > > Is my first impression right or wrong ? > > > > Is Clojure harder to setup from Windows for beginners ? > > > > Would an installer (.msi) help by hiding Java related details and > > providing some basic scripts to run it ? > > > > Luc P. > > > > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > > > wrote: > > > > > > Every time I've started up with a clojure project I've had to spend a > > > > few > > > > hours fiddling with the environment, not that I don't do that with other > > > > languages, but it would be nice with an officially sanctioned solution > > > > for > > > > setting up a sane environment. > > > > > Even better, an officially sanctioned solution expressed both as > > > documentation, and as a collection of shell scripts for all the major > > > platforms. > > > > > (As another non-java-familiar clojure adoptee, classpaths were > > > definitely a hurdle) > > > > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
>>> lookup (find-protocol-method) over the method invocation itself. Is that the
>>> right way to summarize the performance implications?
>>
>> No, since the result is cached. The real every-call overhead is having to
>> go through the var to detect changes to the protocol, vs the inline-defined
>> case where the implementation of the interface can't change given the same
>> instance class.
>
> Am I saying something different? The cache requires a hash lookup, right?
I thought the eventual goal was to implement call-site caching in
bytecode? Inline caching isn't feasible due to the direct and indirect
cost of regenerating bytecode. But you can still do non-inline
caching! For the simplest and highest payoff case of monomorphism, it
would look something like this:
(protocol-function x ...)
=>
(let [cache# ]
(if (= (:expected-type @cache#) (type x))
((:expected-function @cache#) x ...) ;; hit
(let [actual-function ] ;; miss
(swap! cache# (constantly {:expected-type (type x),
:expected-function actual-function}))
(actual-function x ...
It occurs to me that you could even pull off this code transformation
entirely in-language with CL-style compiler macros while leaving alone
references to protocol-function in non-operator position.
-Per
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Yes, yes and yes: The videos are great, and all of the information is out there, but it was hard for me to find as I first waded in. And getting contrib to work was one of my first problems. BTW I'd also like to reinforce that although full IDEs aren't necessary to begin -- and besides they're often a matter of taste -- something *slightly* beyond a bare REPL would be a big help for beginners. In particular an editor with language-aware indenting and parentheses/bracket matching is one thing that can make a big difference (and it'd be nice if getting this didn't require too many steps). One other beginner issue that hasn't been mentioned is the fuzzy line between Clojure and Java in the documentation, which is of course one of Clojure's strengths via interop, and therefore probably always going to be a little messy. But coming from a life in which CLtL2 was all I needed for a reference (and similar things in other languages) I was initially somewhat confused when basic-seeming things weren't in the Clojure docs, and then were or weren't in the contrib docs, and then I finally realized that I have to always look at both of those and then everything that Java provides and quite reasonably hasn't been reimplemented in Clojure. I'm not saying any of those design decisions is bad (on the contrary), but the diffuseness of some of the documentation can be confusing to newcomers, especially those not coming from Java. I could imagine a sort of meta-index to all of this that would be really helpful -- but of course it would also be a lot of work. -Lee On Mar 22, 2010, at 12:13 PM, Luc Préfontaine wrote: > I looked at these videos and they are a very good starting point. > Then do we have a communication problem getting these things known ? > Are these videos listed on the "Getting started" page ? > > What about using contrib ? That would be the first "classpath" problem a > newcomer would face. > > It looks to me that we have all the answers but not in a single spot. > > Luc P. > > On Mon, 2010-03-22 at 06:44 -0700, Sean Devlin wrote: >> Luc, >> Windows users should be good to go. Clojurebox, Enclojure & CCW are >> ready for use for any Java dev with some experience. As for the >> installation process, pick you poison: >> >> >> http://vimeo.com/tag:install_clojure >> >> >> Sorry to self-post, >> Sean >> >> On Mar 22, 7:31 am, Luc Préfontaine >> wrote: >> > Is my first impression right or wrong ? >> > >> > Is Clojure harder to setup from Windows for beginners ? >> > >> > Would an installer (.msi) help by hiding Java related details and >> > providing some basic scripts to run it ? >> > >> > Luc P. >> > >> > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: >> > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg >> > > wrote: >> > >> > > > Every time I've started up with a clojure project I've had to spend a >> > > > few >> > > > hours fiddling with the environment, not that I don't do that with >> > > > other >> > > > languages, but it would be nice with an officially sanctioned solution >> > > > for >> > > > setting up a sane environment. >> > >> > > Even better, an officially sanctioned solution expressed both as >> > > documentation, and as a collection of shell scripts for all the major >> > > platforms. >> > >> > > (As another non-java-familiar clojure adoptee, classpaths were >> > > definitely a hurdle) >> > >> > > 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 > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
Hmm... maybe something like this? http://hackage.haskell.org/platform/ Or this? http://www.openoffice.org/ Sean On Mar 22, 12:39 pm, Lee Spector wrote: > Yes, yes and yes: The videos are great, and all of the information is out > there, but it was hard for me to find as I first waded in. And getting > contrib to work was one of my first problems. BTW I'd also like to reinforce > that although full IDEs aren't necessary to begin -- and besides they're > often a matter of taste -- something *slightly* beyond a bare REPL would be a > big help for beginners. In particular an editor with language-aware indenting > and parentheses/bracket matching is one thing that can make a big difference > (and it'd be nice if getting this didn't require too many steps). > > One other beginner issue that hasn't been mentioned is the fuzzy line between > Clojure and Java in the documentation, which is of course one of Clojure's > strengths via interop, and therefore probably always going to be a little > messy. But coming from a life in which CLtL2 was all I needed for a reference > (and similar things in other languages) I was initially somewhat confused > when basic-seeming things weren't in the Clojure docs, and then were or > weren't in the contrib docs, and then I finally realized that I have to > always look at both of those and then everything that Java provides and quite > reasonably hasn't been reimplemented in Clojure. I'm not saying any of those > design decisions is bad (on the contrary), but the diffuseness of some of the > documentation can be confusing to newcomers, especially those not coming from > Java. I could imagine a sort of meta-index to all of this that would be > really helpful -- but of course it would also be a lot of work. > > -Lee > > On Mar 22, 2010, at 12:13 PM, Luc Préfontaine wrote: > > > > > I looked at these videos and they are a very good starting point. > > Then do we have a communication problem getting these things known ? > > Are these videos listed on the "Getting started" page ? > > > What about using contrib ? That would be the first "classpath" problem a > > newcomer would face. > > > It looks to me that we have all the answers but not in a single spot. > > > Luc P. > > > On Mon, 2010-03-22 at 06:44 -0700, Sean Devlin wrote: > >> Luc, > >> Windows users should be good to go. Clojurebox, Enclojure & CCW are > >> ready for use for any Java dev with some experience. As for the > >> installation process, pick you poison: > > >>http://vimeo.com/tag:install_clojure > > >> Sorry to self-post, > >> Sean > > >> On Mar 22, 7:31 am, Luc Préfontaine > >> wrote: > >> > Is my first impression right or wrong ? > > >> > Is Clojure harder to setup from Windows for beginners ? > > >> > Would an installer (.msi) help by hiding Java related details and > >> > providing some basic scripts to run it ? > > >> > Luc P. > > >> > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > >> > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > >> > > wrote: > > >> > > > Every time I've started up with a clojure project I've had to spend > >> > > > a few > >> > > > hours fiddling with the environment, not that I don't do that with > >> > > > other > >> > > > languages, but it would be nice with an officially sanctioned > >> > > > solution for > >> > > > setting up a sane environment. > > >> > > Even better, an officially sanctioned solution expressed both as > >> > > documentation, and as a collection of shell scripts for all the major > >> > > platforms. > > >> > > (As another non-java-familiar clojure adoptee, classpaths were > >> > > definitely a hurdle) > > >> > > 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 > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en > > > To unsubscribe from this group, send email to > > clojure+unsubscribegooglegroups.com or reply to this email with the words > > "REMOVE ME" as the subject. > > -- > Lee Spector, Professor of Computer Science > School of Cognitive Science, Hampshire College > 893 West Street, Amherst, MA 01002-3359 > lspec...@hampshire.edu,http://hampshire.edu/lspector/ > Phone: 413-559-5352, Fax: 413-559-5438 > > Check out Genetic Programming and Evolvable > Machines:http://www.springer.com/10710-http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more optio
Re: questions on extending protocols
Before someone dings me on the race condition, imagine I had factored
those repeated @cache calls into a (let [value# @cache] ...)
expression. The other thing I'm missing is a check for whether the
protocol has been changed since the cache entry was created; this
would be done by also maintaining an :expected-protocol field and
comparing its value to protocol-function's protocol.
-Per
On Mon, Mar 22, 2010 at 11:24 PM, Per Vognsen wrote:
lookup (find-protocol-method) over the method invocation itself. Is that
the
right way to summarize the performance implications?
>>>
>>> No, since the result is cached. The real every-call overhead is having to
>>> go through the var to detect changes to the protocol, vs the inline-defined
>>> case where the implementation of the interface can't change given the same
>>> instance class.
>>
>> Am I saying something different? The cache requires a hash lookup, right?
>
> I thought the eventual goal was to implement call-site caching in
> bytecode? Inline caching isn't feasible due to the direct and indirect
> cost of regenerating bytecode. But you can still do non-inline
> caching! For the simplest and highest payoff case of monomorphism, it
> would look something like this:
>
> (protocol-function x ...)
>
> =>
>
> (let [cache# ]
> (if (= (:expected-type @cache#) (type x))
> ((:expected-function @cache#) x ...) ;; hit
> (let [actual-function hard way>] ;; miss
> (swap! cache# (constantly {:expected-type (type x),
> :expected-function actual-function}))
> (actual-function x ...
>
> It occurs to me that you could even pull off this code transformation
> entirely in-language with CL-style compiler macros while leaving alone
> references to protocol-function in non-operator position.
>
> -Per
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Nailgun, swank & lein
Hi guys, I am running Clojure on OS X Snow Leopard, 64bit, Java 1.6. I've been developing a little app using Lein, Swank and Emacs, and now I am having trouble getting Nailgun to work properly. I'm not in front of my usual PC right now so I may get a few things wrong; but here is what I know. - My error is from the ng executable & it is unable to connect to the server - "Error, connection refused" - If I run the NG jar file I can connect - If I run "lein nailgun" I can connect - If I start my JVM with Emacs' slime-clojure-project, then run the Nailgun NGServer/main function I get all the same stdout output that shows the server is running, but ng cannot connect - I can start an instance of NGServer in a new thread, see that it is running & appears to be listening, but cannot connect. It feels to me like OS X is firewalling my connection, but I've turned that off. nmap reports that port I expect NG to listen on is not open. Any thoughts? Thanks, Brad -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
clojure.contrib.json.write.print-json type coverage
Hey everyone I've come across a few situations where the print-json multi-method does not cover certain types that may be desirable to have (ex. java.math.BigDecimal and java.util.Date) It's really easy to hack your way around this, but I was just wondering if there's any demand for a change to the actual clojure.contrib.json multimethod to account for these types If you have any examples of additional types that the multi-method doesn't cover, I'd be interested to know those too. Thanks! Jieren -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
On Mar 22, 10:54 am, Stuart Halloway wrote: > >> The questions below refer to the gist > >> athttps://gist.github.com/336674/9ab832a86d203731c6379404d20afded79fe5f5b > >> and to protocols in general: > > >> (1) Clojure automatically types hints the first argument when > >> extending a protocol to an interface or class, which is great. But > >> you cannot override this with your own type hint. Wanting to do > >> this would be very unusual, but see the RandomAccess/List case in > >> the example where one interface signifies the performance > >> characteristics but a different interface has the methods you want. > >> Should it be possible to override the type hint? > > > No. Your wanting to do this is a hint that extending the protocol to > > RandomAccess is not quite right. > > Can you elaborate a little here? I can't extend to List, since I don't > want all Lists, only those that are also RandomAccess. > You can't do a good job extending this generically (e.g. (-> coll class .newInstance) is reflective and very slow, and not guaranteed to work on all types), so you should only support specific classes. > >> (2) The code for chop is repeated across multiple classes. What is > >> the idiomatic way to DRY this? Should I drop down to using raw > >> extend with maps, or is there more mixin support to come? > > > The idiomatic way is to write an ordinary function, e.g. chop is not > > primitive and can just be written in terms of the protocol. > > I considered this, but thought it would be less discoverable. > Does the > caller care that chop is not primitive? I will argue no. That last bit is what I'm saying, you should choose either a protocol fn or regular fn as appropriate, which one is an implementation detail as far as the caller is concerned. Non-protocol fns might become protocol fns (or be built on same) later on, without affecting clients at all. > The caller > wants, given (say) a String, an easy way to ask "what things can I do > with strings?" I don't see how protocols help you answer that one way or the other. There will always be an open set of non-co-located fns and protocols that might work with String. > Separating protocols from non-primitive functions > creates more places to look. > In fact using protocols to begin with > creates more places to look They are not separated, they are together, both being functions in a namespace. People will find them just as they have always found functions, in namespace documentation. > (right now the string functions all live > in clojure.contrib.string). > Not so. count, seq etc all work with strings and are not in c.c.string > >> (3) The code for slice is also repeated, but only for one arity. > >> Does that change the answer to #2? It's the same answer. Implementing a fn as a protocol fn is an implementation detail of primary interest to extenders. Consumers need only know that foo works on Bars, not how it does so. It will quite often be the case that some nice 10-function API might require the implementation of a 3-function protocol in order to extend it. A protocol is a minimal specification of an abstraction, not a totality of an API. > >> (5) It appears that the overhead for calling a protocol adds a hash > >> lookup (find-protocol-method) over the method invocation itself. Is > >> that the right way to summarize the performance implications? > > > No, since the result is cached. The real every-call overhead is > > having to go through the var to detect changes to the protocol, vs > > the inline-defined case where the implementation of the interface > > can't change given the same instance class. > > Am I saying something different? The cache requires a hash lookup, > right? Only once. There is call-site caching of protocol fns, with no per- call lookup as long as the target class remains the same. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure and clojure-contrib jars built with the 1.5 jdk
Do we really care what they are built with, or only that they target 1.5? (i.e. javac's -target option) On Mar 22, 2010, at 11:54 AM, Stuart Sierra wrote: Actually, this is more complicated than I thought. The build processes will use whatever default version of Java is installed locally. Maven has config options for the Java *compiler* version to use, but that will only work for .java source files (of which there are non in contrib). The version of Java under which the Clojure compiler runs is just the local "java" executable. The solution, I suppose, is to install Java 1.5 on the build.clojure.org server and force it to be the default. -SS On Mar 22, 8:48 am, Rich Hickey wrote: On Mar 21, 2010, at 8:50 PM, Stuart Sierra wrote: No, but you can change the configs and recompile. Clojure itself uses Ant, so "ant" on a machine with only Java 1.5 should do the trick. To install that custom JAR in your local Maven repository, download the "Maven Ant Tasks" JAR and run: ant -lib /path/to/maven-ant-tasks.jar ci-build Contrib uses Maven, so add thes lines to its pom.xml in the section: org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 Then "mvn install" to build the JARs and put them in your local repository. Why isn't this in the default build? Clojure targets 1.5, and so should contrib. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mar 22, 2010, at 12:13 PM, Luc Préfontaine wrote: I looked at these videos and they are a very good starting point. Then do we have a communication problem getting these things known ? Are these videos listed on the "Getting started" page ? They are now: http://clojure.org/getting_started Rich What about using contrib ? That would be the first "classpath" problem a newcomer would face. It looks to me that we have all the answers but not in a single spot. Luc P. On Mon, 2010-03-22 at 06:44 -0700, Sean Devlin wrote: Luc, Windows users should be good to go. Clojurebox, Enclojure & CCW are ready for use for any Java dev with some experience. As for the installation process, pick you poison: http://vimeo.com/tag:install_clojure Sorry to self-post, Sean On Mar 22, 7:31 am, Luc Préfontaine wrote: > Is my first impression right or wrong ? > > Is Clojure harder to setup from Windows for beginners ? > > Would an installer (.msi) help by hiding Java related details and > providing some basic scripts to run it ? > > Luc P. > > On Mon, 2010-03-22 at 16:48 +0530, Martin DeMello wrote: > > On Mon, Mar 22, 2010 at 2:19 PM, Joel Westerberg > > wrote: > > > > Every time I've started up with a clojure project I've had to spend a few > > > hours fiddling with the environment, not that I don't do that with other > > > languages, but it would be nice with an officially sanctioned solution for > > > setting up a sane environment. > > > Even better, an officially sanctioned solution expressed both as > > documentation, and as a collection of shell scripts for all the major > > platforms. > > > (As another non-java-familiar clojure adoptee, classpaths were > > definitely a hurdle) > > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
JColorChooser
When I try to use JColorChooser in Clojure I get the followinf error: Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: No matching method found: showDialog for class javax.swing.JColorChooser Shouldn't showDioalog be there? What and I doing wrong. Here's the code: (defn newColor [parent] (proxy [ActionListener] [] (actionPerformed [evt] (def colorChooser (new JColorChooser)) (doto colorChooser (.showDialog parent "Choose Color" bisque)) ))) Bill -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure and clojure-contrib jars built with the 1.5 jdk
I'll try this out since I'm stuck and wanted to get out of the business of building my own versions of clojure/-contrib (hence the move to maven). What do other projects do that have maven repos with similar contraints? Are there separate entries in the repo? On Mar 22, 3:53 pm, Rich Hickey wrote: > Do we really care what they are built with, or only that they target > 1.5? (i.e. javac's -target option) > > On Mar 22, 2010, at 11:54 AM, Stuart Sierra wrote: > > > > > Actually, this is more complicated than I thought. The build > > processes will use whatever default version of Java is installed > > locally. > > > Maven has config options for the Java *compiler* version to use, but > > that will only work for .java source files (of which there are non in > > contrib). The version of Java under which the Clojure compiler runs > > is just the local "java" executable. > > > The solution, I suppose, is to install Java 1.5 on the > > build.clojure.org server and force it to be the default. > > > -SS > > > On Mar 22, 8:48 am, Rich Hickey wrote: > >> On Mar 21, 2010, at 8:50 PM, Stuart Sierra wrote: > > >>> No, but you can change the configs and recompile. > > >>> Clojure itself uses Ant, so "ant" on a machine with only Java 1.5 > >>> should do the trick. To install that custom JAR in your local Maven > >>> repository, download the "Maven Ant Tasks" JAR and run: > >>> ant -lib /path/to/maven-ant-tasks.jar ci-build > > >>> Contrib uses Maven, so add thes lines to its pom.xml in the > >>> > >>> section: > > >>> > >>> org.apache.maven.plugins > >>> maven-compiler-plugin > >>> > >>> 1.5 > >>> 1.5 > >>> > >>> > > >>> Then "mvn install" to build the JARs and put them in your local > >>> repository. > > >> Why isn't this in the default build? Clojure targets 1.5, and so > >> should contrib. > > >> Rich > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en > > > To unsubscribe from this group, send email to clojure > > +unsubscribegooglegroups.com or reply to this email with the words > > "REMOVE ME" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure and clojure-contrib jars built with the 1.5 jdk
The new version of the maven-clojure-compiler plugin now supports the toolchains API to solve this ( running maven under 1.6, compiling with 1.5) but that won't help clojure itself: You can read more about this at: http://maven.apache.org/guides/mini/guide-using-toolchains.html I really need to update the README for this, and actually post a release announcement email. -- Pull me down under... On Tue, Mar 23, 2010 at 4:54 AM, Stuart Sierra wrote: > Actually, this is more complicated than I thought. The build > processes will use whatever default version of Java is installed > locally. > > Maven has config options for the Java *compiler* version to use, but > that will only work for .java source files (of which there are non in > contrib). The version of Java under which the Clojure compiler runs > is just the local "java" executable. > > The solution, I suppose, is to install Java 1.5 on the > build.clojure.org server and force it to be the default. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: JColorChooser
`showDialog` is a static method. Maybe something like below would work? (JColorChooser/showDialog parent "Choose Color" bisque) 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: JColorChooser
I think the problem is that you are try to use a static method lake an instance method. I was able to get the following to work: (import javax.swing.JColorChooser) (JColorChooser/showDialog nil "Test" java.awt.Color/BLACK) Sean On Mar 22, 4:51 pm, WoodHacker wrote: > When I try to use JColorChooser in Clojure I get the followinf error: > > Exception in thread "AWT-EventQueue-0" > java.lang.IllegalArgumentException: No matching method found: > showDialog for class javax.swing.JColorChooser > > Shouldn't showDioalog be there? What and I doing wrong. Here's the > code: > > (defn newColor [parent] > (proxy [ActionListener] [] > (actionPerformed [evt] > (def colorChooser (new JColorChooser)) > (doto colorChooser > (.showDialog parent "Choose Color" bisque)) > > > ))) > > Bill -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I'll certainly agree that it should be as easy as possible to get started in Clojure, but I really don't think that the kind of people that can't use anything without a windows installer are going to get very far with Clojure in any case. I mean, if it's too much to install java, unzip a file and run: java -cp clojure.jar clojure.main As the getting_started page suggests, what are you going to do with sexpr syntax, immutable data structures, iteration through recursion, concurrency etc? Clojure might at some point mature into the kind of language that has something to offer for people that need a lot more hand holding but clearly it's a bit of a wild west environment at the moment. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
There are a ton of people who are ready for dabbling with Clojure but aren't ready for production systems. You'd be surprised how linearly independent system administration skills and software development skills really are. They aren't quite orthogonal, but it's amazingly close. On Mar 22, 5:36 pm, cageface wrote: > I'll certainly agree that it should be as easy as possible to get > started in Clojure, but I really don't think that the kind of people > that can't use anything without a windows installer are going to get > very far with Clojure in any case. > > I mean, if it's too much to install java, unzip a file and run: > java -cp clojure.jar clojure.main > > As the getting_started page suggests, what are you going to do with > sexpr syntax, immutable data structures, iteration through recursion, > concurrency etc? Clojure might at some point mature into the kind of > language that has something to offer for people that need a lot more > hand holding but clearly it's a bit of a wild west environment at the > moment. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: mvn clojujure:repl - no keyboard echo
Really no ideas? Hm. I dont know what to do too. Reagrds, alux -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: clojure-mode-like syntax highlighting for the SLIME REPL
Phil, I've sent you a pull request with the refactoring of clojure-mode. If it looks ok to you, I was wondering if you might perhaps like a second one to include instructions to setup Clojure highlighting in swank-clojure's readme? Sincerely, Michał -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mar 22, 2:48 pm, Sean Devlin wrote: > There are a ton of people who are ready for dabbling with Clojure but > aren't ready for production systems. You'd be surprised how linearly > independent system administration skills and software development > skills really are. They aren't quite orthogonal, but it's amazingly > close. Maybe so, but if getting into Clojure is a series of struggles with unfamiliar concepts then dealing with a jar file is by far the least daunting. Naturally I'm all for making the new-user experience as pleasant and simple as possible but I'm not sure what exactly could be done at this point to make it much easier than it is. Certainly anybody that expects to be able to build it from source on an exotic Linux distro should also be prepared to roll up their own sleeves a bit. Perhaps it would be useful to at least included a ready-to-go clj shell/batch script in the default distribution? That's what Scala, Groovy and Jruby do? The only obstacle I remember from my first experiments with Clojure was getting a working clj shell script together. Had I started with Stuart's book that wouldn't have been a problem either. On the other hand, if you go to the "getting started" pages of Jruby, Groovy they're actually far more daunting (IMO) than Clojure's: http://groovy.codehaus.org/Tutorial+1+-+Getting+started http://kenai.com/projects/jruby/pages/GettingStarted -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mar 22, 1:10 am, Luc Préfontaine wrote: > An IDE becomes a necessity as the complexity of your software is > increasing. > > Now what's a complex piece of software ? > > Presently we have 12 components in production some being several > thousand lines covering three languages (Java, Ruby and Clojure). > 4 others components are in progress. Add to this that we use Spring and > a number of other frameworks for which plug ins are > available to ease the pain. > > Refactoring, code searching, configuration validation, ... are > significant features we need otherwise we would spend a lot of time > to keep things in sync, > > We started to work with Clojure in command line mode. However at a > certain moment it became clear that keeping Clojure > separate from the rest of the core was not the way to go. Today we are > mixing components from different languages/frameworks > in common Jars. Deployment is much more easier this way and using a > common IDE makes that possible. > > If the consensus is that we need to package installers to get simple > Clojure REPLs running on > Windows and Linux in a command line window then let's do it. I think > that all the infrastructure is ready (maven like repo, ...). > > Luc > > > > On Sun, 2010-03-21 at 22:52 -0500, Cosmin Stejerean wrote: > > On Sun, Mar 21, 2010 at 10:20 PM, Luc Préfontaine > > wrote: > > > Yes we could have a complete package to run Clojure from the > > shell command line but how far could someone go with this > > to build a workable system without an IDE ? > > > [...] > > > Comments anyone ? > > > I can get pretty far writing an application in Python with nothing > > more than good command line support and syntax highlighting in any > > text editor. Anything extra like completions, refactoring, etc, are > > just nice-to-haves. I don't see why an IDE is required for writing > > workable Clojure apps. > > > -- > > 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 > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en > > > To unsubscribe from this group, send email to clojure > > +unsubscribegooglegroups.com or reply to this email with the words > > "REMOVE ME" as the subject. I've noticed there have been an increasing number of solutions to running Clojure over the last year or so, which does leave a lot more to go wrong versus the default solution of just running at the command line. If someone asked me to recommend a way to get into Clojure, I'd definitely suggest just running at the command line, and editing files with notepad or whatever. There's no real substitute for learning at least the basics of the class path and how to fix things when they go wrong. This is also the absolute simplest way to go, and in my experience, only a bad Java install (frequently on Windows) can mess it up. Even running barebones like this, it's easy to copy in Jar files for gui code, add 3rd party jars etc., whilst not having a bunch of things happening in the background. Just call me Ned Ludd! Best, Jonathan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Bug: contains? doesn't work on transient maps or sets
Disturbingly, it doesn't error, it just always returns false. This is in version 1.1. Can someone check and see if this is still a problem on the latest version? Thanks, Mark -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
RE: mvn clojujure:repl - no keyboard echo
> Subject: Re: mvn clojure:repl - no keyboard echo > > Really no ideas? > Hm. > I dont know what to do too. Several ongoing threads related to bootstrap issues; if I'm tracking right you're trying to run Incanter (Clojure front-end with several java stats and graph libraries) on XP. I'm on XP as well and checked out Incanter out of curiosity, and had the same problem you're seeing. But, if I bypass Maven and run the repl directly ( bin\clj.bat from the Incanter full download) it works okay. There's an issue floating around here about jline problems under windows... seems some setups use jline to give extra terminal features to the repl, and it's apparently not configured right or something. I didn't look too hard at Incanter's setup, all that maven stuff is obtuse and annoying, hard to figure out where everything's coming from, or where it puts its pieces. And I didn't like that it wants to check the world for current versions every time it starts -- I can see that as useful, but it's time I didn't want to spend. I did notice that Incanter pulls in jline, and others have had windows-related issues with configuring that. Anyway. I guess my point is, all this stuff works, one way or another; but you need to know what you're trying to do. Getting a one-click, packaged solution to work on all systems, is still hard. Incanter, for an example, is seeming to be close to doing it with a fairly complex package, but it looks like there's still a bug its setup somewhere. Cheers, Kevin Kelley -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On Mon, Mar 22, 2010 at 7:03 PM, cageface wrote: > > On the other hand, if you go to the "getting started" pages of Jruby, > Groovy they're actually far more daunting (IMO) than Clojure's: > http://groovy.codehaus.org/Tutorial+1+-+Getting+started > http://kenai.com/projects/jruby/pages/GettingStarted The relevant bits of Groovy's page don't seem more daunting to me: > Setting up your Groovy environment > > Download the Groovy installer or binaries from the downloads page and follow > the installation > instructions. (There is currently an issue where you cannot have spaces in > the path where Groovy is > installed under windows. So, instead of accepting the default installation > path of "c:\Program > Files\Groovy" you will want to change the path to something like "c:\Groovy") One sentence and one caveat. Now, it's preceded by detailed instructions for installing Java, but those same steps are just as applicable to Clojure or any other JVM-hosted language, and having them there is probably not a bad thing. (Though I would replace them with a link - "If you don't have Java, click here and follow the instructions.") JRuby's installation is more manual, but includes examples. All three install on Ubuntu with apt-get, though the latest Clojure there is 1.0. It does come with a "clojure" shell script for starting up a REPL, though. -- Mark J. Reed -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: mvn clojujure:repl - no keyboard echo
If jline is a problem, does removing it from the pom's dependencies "solve" the problem? -- Pull me down under... On Tue, Mar 23, 2010 at 12:07 PM, Kevin wrote: > There's an issue floating around here about jline problems under windows... > seems some setups use jline to give extra terminal features to the repl, > and it's apparently not configured right or something. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
I agree with Sean on the near-orthogonality of sysadmin skills and the skills needed to get a lot of Clojure as a language. I have precious few of the former but not of the latter. And just today I had a very capable undergrad student with programming experience in a couple of languages (but not Java), starting a project for which a lisp-like language would make the most sense, say that although he saw that Clojure would be great he might just work in DrScheme since he could easily download it and have a functional IDE. This student can definitely deal with "sexpr syntax, immutable data structures, iteration through recursion, concurrency etc." I've seen him learn a new language and complete a really incredible project in it within a couple of weeks. But cageface's instructions will only get him a REPL, and not even get him contrib, the classpath details to allow him to load files, or an editor that can indent properly for the language and match parentheses. Some day he should probably learn enough about Java and sysadmin stuff to deal with this, but right now he just wants to dig into his project which doesn't have anything to do with that stuff. Someone else mentioned that maybe part of the problem is that there are several different "simple" ways to get started, and this may have been part of my own problem. I installed one of the emacs clojure modes from the "getting started" page (or maybe two?) and then later tried to install slime and I think they fought with each other, with elpa saying something was already installed and quitting. It wasn't obvious how to start over because I didn't realize that things were in my .emacs and .emacs.d (if I recall correctly). And after watching one of Lau's screencasts I realized I also had to put copies of clojure.jar and clojure-contrib.jar in my .emacs.d, but that was not obvious to me previously... -Lee On Mar 22, 2010, at 5:48 PM, Sean Devlin wrote: > There are a ton of people who are ready for dabbling with Clojure but > aren't ready for production systems. You'd be surprised how linearly > independent system administration skills and software development > skills really are. They aren't quite orthogonal, but it's amazingly > close. > > On Mar 22, 5:36 pm, cageface wrote: >> I'll certainly agree that it should be as easy as possible to get >> started in Clojure, but I really don't think that the kind of people >> that can't use anything without a windows installer are going to get >> very far with Clojure in any case. >> >> I mean, if it's too much to install java, unzip a file and run: >> java -cp clojure.jar clojure.main >> >> As the getting_started page suggests, what are you going to do with >> sexpr syntax, immutable data structures, iteration through recursion, >> concurrency etc? Clojure might at some point mature into the kind of >> language that has something to offer for people that need a lot more >> hand holding but clearly it's a bit of a wild west environment at the >> moment. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: questions on extending protocols
Very helpful, thanks! Stu On Mar 22, 10:54 am, Stuart Halloway wrote: The questions below refer to the gist athttps://gist.github.com/ 336674/9ab832a86d203731c6379404d20afded79fe5f5b and to protocols in general: (1) Clojure automatically types hints the first argument when extending a protocol to an interface or class, which is great. But you cannot override this with your own type hint. Wanting to do this would be very unusual, but see the RandomAccess/List case in the example where one interface signifies the performance characteristics but a different interface has the methods you want. Should it be possible to override the type hint? No. Your wanting to do this is a hint that extending the protocol to RandomAccess is not quite right. Can you elaborate a little here? I can't extend to List, since I don't want all Lists, only those that are also RandomAccess. You can't do a good job extending this generically (e.g. (-> coll class .newInstance) is reflective and very slow, and not guaranteed to work on all types), so you should only support specific classes. (2) The code for chop is repeated across multiple classes. What is the idiomatic way to DRY this? Should I drop down to using raw extend with maps, or is there more mixin support to come? The idiomatic way is to write an ordinary function, e.g. chop is not primitive and can just be written in terms of the protocol. I considered this, but thought it would be less discoverable. Does the caller care that chop is not primitive? I will argue no. That last bit is what I'm saying, you should choose either a protocol fn or regular fn as appropriate, which one is an implementation detail as far as the caller is concerned. Non-protocol fns might become protocol fns (or be built on same) later on, without affecting clients at all. The caller wants, given (say) a String, an easy way to ask "what things can I do with strings?" I don't see how protocols help you answer that one way or the other. There will always be an open set of non-co-located fns and protocols that might work with String. Separating protocols from non-primitive functions creates more places to look. In fact using protocols to begin with creates more places to look They are not separated, they are together, both being functions in a namespace. People will find them just as they have always found functions, in namespace documentation. (right now the string functions all live in clojure.contrib.string). Not so. count, seq etc all work with strings and are not in c.c.string (3) The code for slice is also repeated, but only for one arity. Does that change the answer to #2? It's the same answer. Implementing a fn as a protocol fn is an implementation detail of primary interest to extenders. Consumers need only know that foo works on Bars, not how it does so. It will quite often be the case that some nice 10-function API might require the implementation of a 3-function protocol in order to extend it. A protocol is a minimal specification of an abstraction, not a totality of an API. (5) It appears that the overhead for calling a protocol adds a hash lookup (find-protocol-method) over the method invocation itself. Is that the right way to summarize the performance implications? No, since the result is cached. The real every-call overhead is having to go through the var to detect changes to the protocol, vs the inline-defined case where the implementation of the interface can't change given the same instance class. Am I saying something different? The cache requires a hash lookup, right? Only once. There is call-site caching of protocol fns, with no per- call lookup as long as the target class remains the same. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Nailgun, swank & lein
I've traced my hang issue down to these lines in NGServer
synchronized(System.in) {
if (!(System.in instanceof ThreadLocalInputStream)) {
System.setIn(new ThreadLocalInputStream(in));
System.setOut(new ThreadLocalPrintStream(out));
System.setErr(new ThreadLocalPrintStream(err));
}
}
So, I'm hanging when I true to trap the streams. Not entirely
surprising, this is probably something that Swank does too. Anybody
know of a good work around here?
Brad
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Nailgun, swank & lein
Apparently starting the server with swank-clojure-project does not work, but starting it with "lein swank" and then connecting from Emacs works. Perhaps this is a problem with launching from inside Emacs. Either way, I now have something of a work around. Brad -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
