Re: slow raw io
> I put a self-contained test up here:
> http://gist.github.com/452095
>
> To run it copy this to slurptest.clj and run these commands
> java clojure.main slurptest.clj makewords 100 (100 seems good for
> macs, 300 for linux)
>
> java -Xmx3G -Xms3G clojure.main slurptest.clj slurp|
> slurp2
>
> Trying either slurp or slurp2. I see big timing differences on both
> macs and linux machines but it would be interesting to see if other
> people do too.
Looking at core's slurp, the problem is that it reads one character at
a time from the reader. The underlying reader being buffered or not,
reading one character at a time is not good for performance. The
attached patch brings it back down do the speed of slurp2 (How do I
actually create a ticket on assembla? I couldn't find a way to do
that; just browse individual tickets. I can't change tickets either;
perhaps editing is not publicly allowed?).
Anyways, some performance for FreeBSD 8/x86-64 with:
openjdk6: 15 seconds slurp, 3.0 seconds slurp2
openjdk7 (fastdebug): 14.5 seconds slurp, 2.0 seconds slurp2
And slurp2 as a function of buffer size (single run each):
1: 17.8 seconds
128: 2.92 seconds
1024: 2.88 seconds
4096: 3.12 seconds
--
/ Peter Schuller
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=endiff --git a/src/clj/clojure/core.clj b/src/clj/clojure/core.clj
index fdfd37a..fdc 100644
--- a/src/clj/clojure/core.clj
+++ b/src/clj/clojure/core.clj
@@ -5356,14 +5356,15 @@
{:added "1.0"}
([f & opts]
(let [opts (normalize-slurp-opts opts)
- sb (StringBuilder.)]
+ sb (StringBuilder.)
+ buffer (char-array 4096)]
(with-open [#^java.io.Reader r (apply jio/reader f opts)]
- (loop [c (.read r)]
+ (loop [c (.read r buffer)]
(if (neg? c)
(str sb)
(do
- (.append sb (char c))
- (recur (.read r)
+ (.append sb buffer 0 c)
+ (recur (.read r buffer)
(defn spit
"Opposite of slurp. Opens f with writer, writes content, then
Re: slow raw io
And reading the thread history I realize the problem was already identified (sorry), however: > Has anyone else had a chance to try this? I'm surprised to see manual > buffering behaving so much better than the BufferedReader > implementation but it does seem to make quite a difference. Not really that surprising looking at the implementation. Each call to read(), in addition to the obvious buffer arithmetic etc, results in: * A lock being acquired. * ensureOpen() being called, which checks whether the stream was already closed. One might argue about whether streams should be thread-safe or not, but in any case I think it is good default behavior to always strive to do I/O chunk-wise, regardless of whether the expectation is that the underlying stream is fast (for some definition of fast). -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: New Primitive data types (equal branch) - impact on optimized code.
On Jun 24, 2010, at 23:17 , David Nolen wrote: > Don't have time to dive into this right now, but all I can say is now you are > starting to have an idea what the "other side" looks like. The kind of hoop > jumping you have to do get within 3x of Scala is absurd. Yes to see what the "other side" looks like was one of the goals, and it is abselutly insane I agree, so to be mean, adding a few (long) or +' in there won't make it much worst :P but that isn't the point I wanted to see how far one can go. > This style of coding is largely unnecessary with the latest equals branch. > However in order to be competitive you're going to have to be a bit more > clever with your combination of deftype/record, protocols, statics: > > * Data locality, solved by fields with deftype/record (also allows to define > a bunch of method/fns that have access to the field type to avoid cast) > * primitive return solved by static > * macro inlining is unnecessary with static I took the aproach that was most likely to succeed to be fast and I figured the lower you go the faster you get, I am not entirely sure but I think that some using records and types instead of arrays would be slower then this implementation but I'll gladly be proven wrong :P. On Jun 25, 2010, at 4:50 , Mark Engelberg wrote: > When exactly did people start expecting Clojure to be as fast as Java > and/or Scala? Don't get me wrong I neither expect nor demand clojure to be as Fast as Java/Scala, this was or is a scientific experiment to see how fast it can be, scala is just a nice measuring pole especially since Rich mentioed that this changes in the equal branch bring us a bit closer to the point where people don't claim clojure to be that much slower. > I'm glad someone is starting to tackle these benchmarks. I think it's > especially interesting to see how fast the code can be when written > idiomatically, so I hope we'll see more of these results as well. > Once you start using mutable arrays and type hinting every single > variable, why aren't you just using Java? Because Java us ugly as hell, it's worst then the most horrible clojure code you could possibly write :P. (my 2 cents) also it would defeat the idea behind this test. The ideomatic (at least in my eyes) clojure code is also included in the tests but it is slower in a magnitude that it makes it un-benchmarkable for longer runs. On the other hand the ideomatic code nearly reads as the problem description, which is wonderful and I think in most cases I'd say 'screw speed and make it nice' ... actualy I saied that before :P ... but you get the point I think. Regards, heinz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure script in the classpath : + Servlet Container Question
Yes, you can load Clojure code from Java and invoke it however you like:
RT.var("clojure.core",
"require").invoke(Symbol.intern("your.namespace.here"));
And now you can use your clojure fns:
Var myfn = RT.var("your.namespace.here", "myfn");
myfun.invoke(arg1, arg2, etc);
I'd like to have a more pleasant Java/host API for loading code (that
first line is a doozy if you don't know what's going on), but it works.
Deploying a clojure app into a servlet container doesn't require any
special maneuvers -- yes, gen-class a single servlet. Map it to the
root you want in your web.xml (just to '/' if it's an all-Clojure
webapp), and you're done. The code in your gen-class'ed namespace
takes over from there, and you're in Clojure land from there on out.
Autowiring probably won't work with proxied classes, although I've
never tried it. Should work fine with gen-class'ed classes, as well
as deftype and defrecord classes.
- Chas
On Jun 19, 2010, at 2:23 PM, Todd wrote:
Is it possible to load up .clj files from the classpath of an
arbitrary java app? For example, could you proxy HttpServlet and run
your servlet as a .clj from within a servlet container? If not, and
you have to gen-class the servlet, could the servlet bootstrap the
clojure environment and proceed to load additional .clj files off
the classpath?
Essentially, I'm trying to figure out the easiest path to
incorporate clojure code into an existing java+tomcat environment
(although I think this is interesting in many other cases, too.)
Along this note, someone asked a question awhile back about
integrating spring with clojure. Is it possible to autowire either
proxy or gen-class clojure classes? If so, does anyone have any
experience with this scenario?
-Todd
On 6/19/10 10:39 AM, Paul Moore wrote:
On 19 June 2010 17:22, Chas Emerick wrote:
If you're just looking to run a script that happens to be on the
classpath,
you can do so by prepending an '@' character to the classpath-
relative path
to the script.
So, if a directory foo is on your classpath, and a clojure file
you'd like
to run is at foo/bar/script.clj, then you can run it with:
java -cp clojure.main @/bar/script.clj
FWIW, this is noted in the documentation for clojure here:
http://clojure.org/repl_and_main
Nice! Thanks.
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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: code review request: clojure.java.io
Sorry I'm so late to this particular discussion :-/ Why was to-byte-array left behind? It is a bit of an oddball function, insofar as it doesn't fit into IOFactory or Coercions, but seems to me like a natural cousin to copy. - Chas On May 11, 2010, at 12:16 PM, Stuart Halloway wrote: Assembla Ticket #311 [1] calls for the promotion of clojure.contrib.io into clojure (as clojure.java.io). I have attached a patch, and am requesting comments and code review from the community. Reasons you want to take time from your day to read this code: (1) It's important. This isn't just a copy/paste from contrib, there are several design changes (documented in the ticket). (2) It's interesting, demonstrating use of Clojure 1.2 protocols. (3) If you are new to Clojure, it isn't that scary. It's "just I/ O". :-) Thanks! Stu [1] https://www.assembla.com/spaces/clojure/tickets/311-clojure-java-io-namespace -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Hash-map destructuring
On Jun 16, 2010, at 9:21 PM, Michael Gardner wrote:
On Jun 16, 2010, at 7:07 PM, ataggart wrote:
There's a disconnect between the function definition and the
datastructures used by the caller.
Either fix the data structure:
(def args [:bar 2 :baz [:quux]])
then use apply
Or change the function definition to take a map:
(defn foo [x {:keys [bar baz]}]
...)
That's a pretty flippant answer. I have run into this same issue;
it's not always desirable to have your function take a map, and if
you get the data structure from elsewhere (say loaded from a config
file), then you have to resort to either re-building the arg list
manually or doing (apply concat ...).
Regarding Brian's original question: as far as I know, there is no
built-in version of apply that works with keyword args contained in
a map. But note that you can eliminate the call to seq, since (apply
concat args) works the same as (apply concat (seq args)).
This is fairly simple:
user=> (defn foo [& {:as args}] [args])
#'user/foo
user=> (def m {:a 5 :b 6})
#'user/m
user=> (apply foo (-> m seq flatten))
[{:a 5, :b 6}]
I'm not sure if it could be made easier, short of changing apply
(which I wouldn't think is reasonable).
- Chas
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Commercially-supported, polished Clojure development environment
Sorry, for some reason I thought that the raw data was linked off the 'analytics' page as well -- and then I didn't notice your and Antony's messages looking for that raw data. :-( I've updated the form with a link to the raw data added: http://spreadsheets.google.com/viewform?formkey=dHVEYUg3V3dMZjc0VDdNUFhWMGJ2bmc6MQ - Chas On Jun 14, 2010, at 7:55 AM, Laurent PETIT wrote: Hi Chas, I'm interested in being able to consult the detail of the answers (not just the summary view), 'cause I guess there could be interesting stuff in the "free form" parts of it (and the summary page just presents a few of these answers). 2010/6/9 Chas Emerick : Following the results from the State of Clojure survey, and some follow-up comments from some in #clojure indicating that they, too, would like to see a commercially-supported Clojure development environment (adjectives included "badass", "no-compromise", and the like, just to give you the flavor), I went ahead and started yet another Google Docs form (I guess I might be looking for nails to drive with this new hammer I've found ;-)): Petition / Market Research: For the development of a commercially- supported, polished Clojure development environment http://spreadsheets.google.com/viewform?formkey=dHVEYUg3V3dMZjc0VDdNUFhWMGJ2bmc6MQ If you're at all interested in the topic of Clojure development environments, and you'd potentially be interested in paying real money for one that presumably improved upon your current environment by some remarkable amount, take a look at the survey, the accompanying wiki page, and add yourself to the waiting list, as it were. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: New Primitive data types (equal branch) - impact on optimized code.
Have you tried manual copying of the perm array (as in the scala version)? It is probably not much better or worse, but it would be nice to have the same algorithm than scala, for comparaison purpose. On Fri, Jun 25, 2010 at 10:10 AM, Heinz N. Gies wrote: > > On Jun 24, 2010, at 23:17 , David Nolen wrote: > > > Don't have time to dive into this right now, but all I can say is now you > are starting to have an idea what the "other side" looks like. The kind of > hoop jumping you have to do get within 3x of Scala is absurd. > Yes to see what the "other side" looks like was one of the goals, and it is > abselutly insane I agree, so to be mean, adding a few (long) or +' in there > won't make it much worst :P but that isn't the point I wanted to see how far > one can go. > > > This style of coding is largely unnecessary with the latest equals > branch. However in order to be competitive you're going to have to be a bit > more clever with your combination of deftype/record, protocols, statics: > > > > * Data locality, solved by fields with deftype/record (also allows to > define a bunch of method/fns that have access to the field type to avoid > cast) > > * primitive return solved by static > > * macro inlining is unnecessary with static > > I took the aproach that was most likely to succeed to be fast and I figured > the lower you go the faster you get, I am not entirely sure but I think that > some using records and types instead of arrays would be slower then this > implementation but I'll gladly be proven wrong :P. > > > On Jun 25, 2010, at 4:50 , Mark Engelberg wrote: > > > When exactly did people start expecting Clojure to be as fast as Java > > and/or Scala? > Don't get me wrong I neither expect nor demand clojure to be as Fast as > Java/Scala, this was or is a scientific experiment to see how fast it can > be, scala is just a nice measuring pole especially since Rich mentioed that > this changes in the equal branch bring us a bit closer to the point where > people don't claim clojure to be that much slower. > > > I'm glad someone is starting to tackle these benchmarks. I think it's > > especially interesting to see how fast the code can be when written > > idiomatically, so I hope we'll see more of these results as well. > > Once you start using mutable arrays and type hinting every single > > variable, why aren't you just using Java? > Because Java us ugly as hell, it's worst then the most horrible clojure > code you could possibly write :P. (my 2 cents) also it would defeat the idea > behind this test. The ideomatic (at least in my eyes) clojure code is also > included in the tests but it is slower in a magnitude that it makes it > un-benchmarkable for longer runs. On the other hand the ideomatic code > nearly reads as the problem description, which is wonderful and I think in > most cases I'd say 'screw speed and make it nice' ... actualy I saied that > before :P ... but you get the point I think. > > Regards, > heinz > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: New Primitive data types (equal branch) - impact on optimized code.
On Fri, Jun 25, 2010 at 8:20 AM, Mark Engelberg wrote: > When exactly did people start expecting Clojure to be as fast as Java > and/or Scala? > > I seem to recall in one of the original Clojure videos, Rich talked > about the relationship between Clojure and Java. There's a long > history of C programmers dropping down to assembly, Python programmers > dropping down to C, and so on. He explained that Java was Clojure's > "assembly". You use Clojure to write the logic that is too complex to > code compactly in Java. You write Java to code the low-level bits you > can't do in Clojure. I've actually been thinking of learning scala to have something to "drop down to" when clojure isn't fast enough. Anyone have experience with this? 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
Re: New Primitive data types (equal branch) - impact on optimized code.
On Jun 25, 2010, at 12:19 , Nicolas Oury wrote: > Have you tried manual copying of the perm array (as in the scala version)? > It is probably not much better or worse, but it would be nice to have the > same algorithm than scala, for comparaison purpose. Yes the original version did that, the impact of change was minimal but in the end I found it cleaner to use the low level system funciton. Regards, Heniz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Futures Docs and Functionality
Hi Daniel, On Wed, Jun 23, 2010 at 1:15 PM, Daniel Werner < daniel.d.wer...@googlemail.com> wrote: > > Judging from previous discussions on this list, I get the feeling that > relying too much on the Java implementation details underlying the > public Clojure APIs is discouraged. This certainly makes sense > considering that apparently one of the future plans (no pun intended) > is to give the CLR and JavaScript ports of the language more focus. > > I don't know much about the CLR version of Clojure but can understand that. My goal was just trying eliminate the need look at the source code to know about the timeout feature of the Futures. Having the below function solves that problem. > IMHO this seems like a useful improvement. Maybe your proposal would > draw more attention if you backed it up with a patch -- even a > preliminary one? :-) > > What I was thinking for a future-await function was: (defn- convert-time-unit [unit] (case unit :nanoseconds (java.util.concurrent.TimeUnit/NANOSECONDS) :microseconds (java.util.concurrent.TimeUnit/MICROSECONDS) :milliseconds (java.util.concurrent.TimeUnit/MILLISECONDS) :seconds (java.util.concurrent.TimeUnit/SECONDS) :minutes (java.util.concurrent.TimeUnit/MINUTES) :hours (java.util.concurrent.TimeUnit/HOURS) :days (java.util.concurrent.TimeUnit/DAYS) (throw (IllegalArgumentException. (str unit " is not a valid unit of time") (defn future-await "Returns the value of the future just like a deref. If the future has not completed by timeout, nil is returned" ([^java.util.concurrent.Future f timeout-in-millis] (future-await f timeout-in-millis :milliseconds)) ([^java.util.concurrent.Future f timeout unit] (try (->> unit convert-time-unit (.get f timeout)) (catch java.util.concurrent.TimeoutException e nil It's usage is below (def fut (future (Thread/sleep 100) "done")) (future-await fut 1000) ;throws exception (future-await fut 2 :seconds) ;throws exception (def fut2 (future (Thread/sleep 1) "done")) (future-await fut2 2 :minutes) ; => "done" -Ryan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
On Wed, Jun 23, 2010 at 5:23 PM, James Reeves wrote: > Hello there! > > Chas Emerick's recent "State of Clojure" survey [http://bit.ly/dtdAwb] > indicated that a significant proportion of Clojure users are beginning > to use Clojure for web development. A recent Hacker News posting > [http://bit.ly/91Bu5J] seems to corroborate these results, with > several Clojure-based web applications already out in the wild. > > As one of the main developers of Ring and Compojure, I'd be very > interested to hear more about how people are using Clojure to build > web apps. To this end, I have a few questions I'd like to quiz Clojure > web developers about: > > 1. Have you written, or are you writing, a web application that uses > Clojure? What does it do? I considered it but I needed comet support and didn't want to roll my own when my practical clojure experience was limited. I think that clojure would be an excellent platform for what I was planning on doing but it lacked the comet support I needed so I'm implementing in Seaside for Gemstone's Smalltalk. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Question about "every?"
So the validation takes place after "alter messages conj msg" in the add-message function? On Jun 24, 4:48 pm, Meikel Brandmeyer wrote: > Hi, > > alter calls conj on [] (which is kept as a vector) since it is the > initial content of the messages ref. So the content of messages is a > seqable thing and not a single message. > > Sincerely > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
> 1. Have you written, or are you writing, a web application that uses > Clojure? What does it do? I've written a few small web apps. > 2. Which libraries or frameworks are you using? Which versions? ring and compojure > 3. What made you choose Clojure to develop web applications in? What > are the strengths of Clojure web development? Im inexperienced enough to not know better :D I've been coding seriously for about 2 and a half years, most of that using different lisps(i got to scheme really early in my endeavor for programming knowledge), im sold on the whole functional programming and lisp thing. I didn't have to unlearn too much to figure it out, just a bit of python. So, since clojure is my favorite language *at the moment*, its natural to try and write stuff in it, and web development seems as good as any place to start. > 4. What do you think are the current weaknesses of web development in > Clojure? What could be improved? Im not very experienced in web development to say for sure. I've written a blog in django, and thats all my web experience. So my first problem was figuring out how to write web apps in general. I think clojure is a lousy first web language at the moment. Rings docs kind of assume you already know what you are doing. I had to figure everything out for myself, i read all the source so i can figure it out, and i still have trouble with it. I'd say that ring/compojure could use a comprehensive tutorial with lots of examples and tips. > 5. Anything else you want to comment on? I love hiccup, ever since i first saw a web app written in a lisp using s-expressions to generate html, i've been in love with the idea. Also as someone already pointed out in the "State of Clojure" survey, Rich really does have awesome hair :D -- You 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
How does contains? work?
Hello, Explain me this, please: user=> (def x (cons 'a nil)) #'user/x user=> x (a) user=> (contains? x 'a) false user=> And, what is Clojure analogue of Lisp "member" function. Thanks in advance. -- You 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
Duplicate key bug in hash-maps
I tried Clojure via Githhub today.
Anyone notice this bug that hadn't existed in Version 1.1
user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
Tim
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
Duplicate key prevention is a feature added in commit
c733148ba0fb3ff7bbab133f5375422972e62d08.
Stu
> I tried Clojure via Githhub today.
>
> Anyone notice this bug that hadn't existed in Version 1.1
>
> user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
>
> Tim
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How does contains? work?
Hi,
(some '#{a} x) or (some #(= 'a %) x) in case 'a can be false or nil.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: code review request: clojure.java.io
No one spoke up for it. > Sorry I'm so late to this particular discussion :-/ > > Why was to-byte-array left behind? It is a bit of an oddball function, > insofar as it doesn't fit into IOFactory or Coercions, but seems to me like a > natural cousin to copy. > > - Chas > > On May 11, 2010, at 12:16 PM, Stuart Halloway wrote: > >> Assembla Ticket #311 [1] calls for the promotion of clojure.contrib.io into >> clojure (as clojure.java.io). I have attached a patch, and am requesting >> comments and code review from the community. >> >> Reasons you want to take time from your day to read this code: >> >> (1) It's important. This isn't just a copy/paste from contrib, there are >> several design changes (documented in the ticket). >> >> (2) It's interesting, demonstrating use of Clojure 1.2 protocols. >> >> (3) If you are new to Clojure, it isn't that scary. It's "just I/O". :-) >> >> Thanks! >> Stu >> >> [1] >> https://www.assembla.com/spaces/clojure/tickets/311-clojure-java-io-namespace >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Question about "every?"
Hi, On Jun 25, 8:12 am, michele wrote: > So the validation takes place after "alter messages conj msg" in the > add-message function? Well. "in between". It takes place after the conj, but "before" the alter. The value is taken from the ref and modified by the function you provide. In this case the conj. The new value is then fed to the validator and on success put back into the ref. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How does contains? work?
BTW: Searching the group archives for contains? will bring up a lot of information on this topic. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: slow raw io
Hi Peter, You are on the contributors list, so I just need to know your account name on Assembla to activate your ability to add tickets, patches, etc. Let me know your account name (which needs to be some permutation of your real name, not a nick). Thanks, Stu >> I put a self-contained test up here: >> http://gist.github.com/452095 >> >> To run it copy this to slurptest.clj and run these commands >> java clojure.main slurptest.clj makewords 100 (100 seems good for >> macs, 300 for linux) >> >> java -Xmx3G -Xms3G clojure.main slurptest.clj slurp| >> slurp2 >> >> Trying either slurp or slurp2. I see big timing differences on both >> macs and linux machines but it would be interesting to see if other >> people do too. > > Looking at core's slurp, the problem is that it reads one character at > a time from the reader. The underlying reader being buffered or not, > reading one character at a time is not good for performance. The > attached patch brings it back down do the speed of slurp2 (How do I > actually create a ticket on assembla? I couldn't find a way to do > that; just browse individual tickets. I can't change tickets either; > perhaps editing is not publicly allowed?). > > Anyways, some performance for FreeBSD 8/x86-64 with: > > openjdk6: 15 seconds slurp, 3.0 seconds slurp2 > openjdk7 (fastdebug): 14.5 seconds slurp, 2.0 seconds slurp2 > > And slurp2 as a function of buffer size (single run each): > > 1: 17.8 seconds > 128: 2.92 seconds > 1024: 2.88 seconds > 4096: 3.12 seconds > > -- > / Peter Schuller > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How does contains? work?
> Explain me this, please: > > user=> (def x (cons 'a nil)) > #'user/x > user=> x > (a) > user=> (contains? x 'a) > false > user=> contains? checks whether the collection contains the *key*, not the value. So for example the list [:a :b] contains keys 0 and 1, but not 2 or :a: user=> (contains? [:a :b] 0) true user=> (contains? [:a :b] 1) true user=> (contains? [:a :b] 2) false user=> (contains? [:a :b] :a) false That said, it was not obvious from (doc contains?) to me what the semantics were for operating on lists. Checking PersistentList, it seems contains() always returns false - which makes sense if you consider that lists are not functions of indexes (while vectors and java arrays are). -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: slow raw io
> You are on the contributors list, so I just need to know your account name on > Assembla to activate your ability to add tickets, patches, etc. Let me know > your account name (which needs to be some permutation of your real name, not > a nick). When I read up before submitting the contributor agreement I did see the preference for real name derived account names, but I went with my usual 'scode' anyway since I normally use the same name *everywhere* and I didn't get the impression it was a strict requirement. I can register another account (no problem), but what implications are there on the fact that I wrote 'scode' on the contributor agreement I mail:ed Rich? -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: slow raw io
> I can register another account (no problem), but what implications are > there on the fact that I wrote 'scode' on the contributor agreement I > mail:ed Rich? I just registered "peterschuller". -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: New Primitive data types (equal branch) - impact on optimized code.
could you also give more info of the jvm/flags you use. Especially I see you are on a mac where last time I checked the default was the client HotSpot. On Fri, Jun 25, 2010 at 12:18 PM, Heinz N. Gies wrote: > > On Jun 25, 2010, at 12:19 , Nicolas Oury wrote: > > > Have you tried manual copying of the perm array (as in the scala > version)? > > It is probably not much better or worse, but it would be nice to have the > same algorithm than scala, for comparaison purpose. > Yes the original version did that, the impact of change was minimal but in > the end I found it cleaner to use the low level system funciton. > > Regards, > Heniz > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
Regarding deployment leiningen-war might prove useful http://github.com/alienscience/leiningen-war. On Jun 24, 7:17 pm, Brenton wrote: > 1. Have you written, or are you writing, a web application that uses > Clojure? What does it do? > > I am an independent contractor and do a lot of corporate intranet web > applications. All of my clients support Java. Each year I write a few > new applications and spend a lot of time maintaining old Java > applications. The first new application that I wrote this year was > pure Clojure. It was a very simple application for collecting ideas > from employees. It was great to be able to use Lisp and yet integrate > and deploy into a Java environment. The application was deployed to > WebSphere as a war file, connects to an SQL Server database and uses > the company's LDAP Java libraries. I plan to use Clojure for all new > projects. > > I also work for a research group with a bunch of statisticians > building web based tools based on the work that they do. Usually > taking some nasty spreadsheet that someone has created and turning it > into a web application. Clojure (functional programming) with Incanter > will be a perfect fit for this type of project. > > 2. Which libraries or frameworks are you using? Which versions? > > [org.clojure/clojure "1.1.0"] > [org.clojure/clojure-contrib "1.1.0"] > [compojure "0.4.0-RC3"] > [hiccup "0.2.3"] > [sandbar "0.2.4"] > [enlive "1.0.0-SNAPSHOT"] > [carte "0.1.0"] > [inflections "0.3"] > > I am also working on Sandbar and Carte. Sandbar provides middleware to > allow one to work with the session as if it were a global map with put > and get functions. It also provides middleware for authentication and > authorization. Carte is non-object oriented relational mapping. Both > are very new. > > 3. What made you choose Clojure to develop web applications in? What > are the strengths of Clojure web development? > > 1. Functional programming is a better fit than OO for web > applications. > 2. Lisp is as DRY as you can get. Every other environment that I have > worked in, you get to some point where you can no longer create > abstractions and have to resort to design patterns, code generation or > non-primary language configuration. I don't see this ever happening > with Clojure. > 3. It is just Java. Easy deployment into any Java container. Clients > get a Java app and there is much rejoicing. > 4. Mutable objects as a default are bad, even for web applications. > 5. Interactive REPL development. > 6. Ring and Compojure are exactly what I want as the foundation for my > web applications: simple, small and extensible. Middleware is > wonderful. > > 4. What do you think are the current weaknesses of web development in > Clojure? What could be improved? > > Packaging and deployment seem to be the big problem at this point. I > have a lot experience with Java web applications so it is not that > difficult for me to create a war for deployment but I can see that > someone without a Java background would be completely confused by > this. I would love to see a tool that can package my app into a war > including a REPL server. > > It would also be nice to have easily accessible, thorough, > documentation for Ring and Compojure with example code that goes > beyond the most simple cases. The community is young and so there is a > lack of shared knowledge about best practices when developing larger > applications. > > One of the things that I like about Clojure web development (the > flexibility) also causes some concern. In my opinion, the best thing > about Rails is that any developer who knows Rails can go to any Rails > project and know where everything is. The conventions of Rails have > also contributed greatly to Rails' ability to grow and innovate. I > don't know what the solution is, just wanted to bring this up. > > 5. Anything else you want to comment on? > > Many thanks to Mark and James for all of your work on Ring and > Compojure. Without these two libraries there wouldn't be much Clojure > web development going on. Also, thanks for keeping it simple and not > trying to do too much. > > On Jun 23, 2:23 pm, James Reeves wrote: > > > > > Hello there! > > > Chas Emerick's recent "State of Clojure" survey [http://bit.ly/dtdAwb] > > indicated that a significant proportion of Clojure users are beginning > > to use Clojure for web development. A recent Hacker News posting > > [http://bit.ly/91Bu5J] seems to corroborate these results, with > > several Clojure-based web applications already out in the wild. > > > As one of the main developers of Ring and Compojure, I'd be very > > interested to hear more about how people are using Clojure to build > > web apps. To this end, I have a few questions I'd like to quiz Clojure > > web developers about: > > > 1. Have you written, or are you writing, a web application that uses > > Clojure? What does it do? > > > 2. Which libraries or frameworks are you using? Which versions? > > > 3. What made you c
Re: Duplicate key bug in hash-maps
On 25 June 2010 12:27, Tim Robinson wrote:
> I tried Clojure via Githhub today.
>
> Anyone notice this bug that hadn't existed in Version 1.1
>
> user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
You're trying to put duplicate values into a set.
Did you mean this instead?
user=> (def x {:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}})
#'user/x
user=> (:item1 x)
{:a "A", :b "B"}
user=> (:item2 x)
{:a "A", :b "B"}
user=>
--
Michael Wood
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
On Fri, 25 Jun 2010 15:36:31 +0200
Michael Wood wrote:
> On 25 June 2010 12:27, Tim Robinson wrote:
> > I tried Clojure via Githhub today.
> >
> > Anyone notice this bug that hadn't existed in Version 1.1
> >
> > user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> > java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
>
> You're trying to put duplicate values into a set.
So? Most places, putting a value that's already in a set into the set
is a nop. Even in clojure that exhibits the above behavior:
user=> #{:a :a}
java.lang.IllegalArgumentException: Duplicate key: :a
user=> (set [:a :a])
#{:a}
user=> (conj #{:a} :a)
#{:a}
user=>
Apparently, duplicate keys in sets are only disallowed in set
literals. Arguably, that must be a mistake on the users part, but
it sure seems to clash with the behavior of sets elsewhere.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
> > > Apparently, duplicate keys in sets are only disallowed in set > literals. Arguably, that must be a mistake on the users part, but > it sure seems to clash with the behavior of sets elsewhere. > > Why would you ever want to write a duplicate in a set literal? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
Duplicate keys in maps/sets are disallowed in literals and factory functions,
where data is generally literal & inline and therefore likely represents coder
error:
; all disallowed
#{:a :a}
{:a 1 :a 2}
(hash-map :a 1 :a 2)
(hash-set :a :a)
They are allowed in other contexts, where the data could come from anywhere:
; dumb, but these forms not generally called with a literal
(set [:a :a])
(into #{} [:a :a])
I find this behavior consistent and easy to explain, but I was involved in the
design conversation so maybe I have participant blindness. :-)
Stu
> On Fri, 25 Jun 2010 15:36:31 +0200
> Michael Wood wrote:
>
>> On 25 June 2010 12:27, Tim Robinson wrote:
>>> I tried Clojure via Githhub today.
>>>
>>> Anyone notice this bug that hadn't existed in Version 1.1
>>>
>>> user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
>>> java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
>>
>> You're trying to put duplicate values into a set.
>
> So? Most places, putting a value that's already in a set into the set
> is a nop. Even in clojure that exhibits the above behavior:
>
> user=> #{:a :a}
> java.lang.IllegalArgumentException: Duplicate key: :a
> user=> (set [:a :a])
> #{:a}
> user=> (conj #{:a} :a)
> #{:a}
> user=>
>
> Apparently, duplicate keys in sets are only disallowed in set
> literals. Arguably, that must be a mistake on the users part, but
> it sure seems to clash with the behavior of sets elsewhere.
>
> --
> Mike Meyerhttp://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
Were not using Clojure yet for our Web based GUIs. The main reason being that we jumped on Rails last year. Most of our needs are to display/edit database data and the ActiveScaffold plugin allows us to write a controller in 20 lines. We do not need to write forms, it's all done through partial renderings provided by the plugin. We just provide layouts and customize CSS stuf. We will give a closer look to Compojure this year and see if can achieve the same code ratio somehow. Luc P Sent from my iPod On 2010-06-24, at 12:27, Daniel Gagnon wrote: I don't use Clojure for web development and I thought sharing why could be useful too. For web development, my favourite tool is Django. It comes as a fullstack framework which means I have everything I need out of the box. Templates, caching, ORM, a kick-ass autogenerated admin section, cross-domain request forgery protection etc. and the documentation is really top notch. I'd rather have Clojure than Python but all the goodness that Django provides is such a time saver that I feel I'd lose too much time with Clojure. If I had a full-stack, well-documented clojure framework, I'd jump to that. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: slow raw io
Thanks Stuart & Peter for following up on this. Now I can get back to plowing through this mountain of ldiff data with Clojure! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
On Fri, 25 Jun 2010 10:31:57 -0400
Stuart Halloway wrote:
> Duplicate keys in maps/sets are disallowed in literals and factory functions,
> where data is generally literal & inline and therefore likely represents
> coder error:
>
> ; all disallowed
> #{:a :a}
> {:a 1 :a 2}
> (hash-map :a 1 :a 2)
> (hash-set :a :a)
Maps I can see being an error - you lose data in the process.
However, since you can plug variables of unknown provenance into
either the constructor or the literal, that's liable to create a nasty
surprise for someone at some point.
user=> (def a :a)
#'user/b
user=> (def b :a)
#'user/b
user=> (hash-set a b)
java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:6)
user=> #{a b}
java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:0)
user=>
> They are allowed in other contexts, where the data could come from anywhere:
It could come from anywhere in the two "forbidden" contexts as well.
> ; dumb, but these forms not generally called with a literal
> (set [:a :a])
> (into #{} [:a :a])
>
> I find this behavior consistent and easy to explain, but I was involved in
> the design conversation so maybe I have participant blindness. :-)
My initial reaction was "that's a bit odd, but probably a good idea."
However, given that I can use variables inside the literal and
constructor, I'm leaning the other way.
Or is (set [a b c]) idiomatic usage in this case, and (hash-set a b c)
or #{a b c} to be avoided?
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
I think there are two important considerations in favor of how it works now:
(1) The "common case" presumptions (which admittedly may need to be learned).
(2) The need for both flavors. If there wasn't a flavor that rejected duplicate
keys, somebody would surely ask for it.
Add to these considerations the names of the functions already in play, and you
get the implementation you see.
> On Fri, 25 Jun 2010 10:31:57 -0400
> Stuart Halloway wrote:
>
>> Duplicate keys in maps/sets are disallowed in literals and factory
>> functions, where data is generally literal & inline and therefore likely
>> represents coder error:
>>
>> ; all disallowed
>> #{:a :a}
>> {:a 1 :a 2}
>> (hash-map :a 1 :a 2)
>> (hash-set :a :a)
>
> Maps I can see being an error - you lose data in the process.
>
> However, since you can plug variables of unknown provenance into
> either the constructor or the literal, that's liable to create a nasty
> surprise for someone at some point.
>
> user=> (def a :a)
> #'user/b
> user=> (def b :a)
> #'user/b
> user=> (hash-set a b)
> java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:6)
> user=> #{a b}
> java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:0)
> user=>
>
>
>> They are allowed in other contexts, where the data could come from anywhere:
>
> It could come from anywhere in the two "forbidden" contexts as well.
>
>> ; dumb, but these forms not generally called with a literal
>> (set [:a :a])
>> (into #{} [:a :a])
>>
>> I find this behavior consistent and easy to explain, but I was involved in
>> the design conversation so maybe I have participant blindness. :-)
>
> My initial reaction was "that's a bit odd, but probably a good idea."
> However, given that I can use variables inside the literal and
> constructor, I'm leaning the other way.
>
> Or is (set [a b c]) idiomatic usage in this case, and (hash-set a b c)
> or #{a b c} to be avoided?
>
>--
> Mike Meyerhttp://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Duplicate key bug in hash-maps
On Fri, 25 Jun 2010 11:37:32 -0400 Stuart Halloway wrote: > (2) The need for both flavors. If there wasn't a flavor that rejected > duplicate keys, somebody would surely ask for it. I guess it makes as much sense as anything, given that you don't want to get into -unique or some such. But it does leave me wondering where the duplicate-rejecting version of into is :-). http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Hash-map destructuring
On Jun 25, 2:57 am, Chas Emerick wrote:
> This is fairly simple:
>
> user=> (defn foo [& {:as args}] [args])
> #'user/foo
> user=> (def m {:a 5 :b 6})
> #'user/m
> user=> (apply foo (-> m seq flatten))
> [{:a 5, :b 6}]
>
> I'm not sure if it could be made easier, short of changing apply
> (which I wouldn't think is reasonable).
>
> - Chas
That was what I tried first, but it doesn't work. It flattens too
much. Note that I have a vector as one of the map values in my
example.
--Brian
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Hash-map destructuring
On Wed, Jun 16, 2010 at 7:00 PM, Brian Carper wrote:
> Given:
>
> (defn foo [x & {:as args}] [x args])
> (foo 1 :bar 2 :baz [:quux])
> => [1 {:bar 2, :baz [:quux]}]
>
> If I have those rest-arguments already in a map, what's the most
> elegant way to call foo with them?
>
> (def args {:bar 2 :baz [:quux]})
> (foo 1 ?)
>
> I feel like I may be missing some simple way of doing it. I find
> myself needing to do this pretty often, for example any time I have a
> chain of functions calling each other that all take keyword arguments
> on the end.
>
I would do it like this, a la Python:
(defn foo [a b & {:keys [c d]}]
(println a b c d))
(defn ** [m]
(apply concat (vec m)))
(apply foo 1 2 (** {:c 3 :d 4}))
(apply apply [foo 1 2 (** {:c 3 :d 4})])
The problem with your apply* is that it's macro so it can't be used as an
fn.
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
Re: State of Clojure web development
> On 2010-06-24, at 12:27, Daniel Gagnon wrote: > > I don't use Clojure for web development and I thought sharing why could be > useful too. > > For web development, my favourite tool is Django. It comes as a fullstack > framework which means I have everything I need out of the box. Templates, > caching, ORM, a kick-ass autogenerated admin section, cross-domain request > forgery protection etc. and the documentation is really top notch. > I'd rather have Clojure than Python but all the goodness that Django > provides is such a time saver that I feel I'd lose too much time with > Clojure. > If I had a full-stack, well-documented clojure framework, I'd jump to that. Ditto. Django's admin tool is something I haven't seen elsewhere, and it saves me gobs of time. I can't imagine switching to a framework that doesn't have that. But hypothetically, if Clojure did have something like that, I'd consider switching. Another factor to me is the reality of webhosting. There are a number of webhosting services (e.g., webfaction) that make it super-easy to get Django, turbogears, cherrypy, rails, etc. up and running with one-click installers and very detailed tutorials. On the other hand, Java-based servers usually require much more knowledge to deploy, and usually require more memory than the cheapest plans offer. I'd probably be unlikely to switch to Clojure for webhosting without detailed instructions on how to deploy on a well-known, inexpensive hosting service (like webfaction). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How does contains? work?
My sense from reading Rich's writing on the subject is that 'contains? was named with the use of sets in mind. There is also a pairing logic involved whereby if 'contains? returns true, the the value returned by 'get is valid (this covers cases in maps where the value actually is nil). As Meikel indicated, this is a well-worn path of discussion and isn't going to change. On Jun 25, 5:15 am, Peter Schuller wrote: > > Explain me this, please: > > > user=> (def x (cons 'a nil)) > > #'user/x > > user=> x > > (a) > > user=> (contains? x 'a) > > false > > user=> > > contains? checks whether the collection contains the *key*, not the > value. So for example the list [:a :b] contains keys 0 and 1, but not > 2 or :a: > > user=> (contains? [:a :b] 0) > true > user=> (contains? [:a :b] 1) > true > user=> (contains? [:a :b] 2) > false > user=> (contains? [:a :b] :a) > false > > That said, it was not obvious from (doc contains?) to me what the > semantics were for operating on lists. Checking PersistentList, it > seems contains() always returns false - which makes sense if you > consider that lists are not functions of indexes (while vectors and > java arrays are). > > -- > / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Futures Docs and Functionality
On 25 June 2010 05:27, Ryan Senior wrote: > (future-await fut2 2 :minutes) ; => "done" Your implementation points into the right direction (again, IMHO). I'd like to offer two suggestions: 1. Leave out the three-arg version of future-await. The time unit conversion seems somewhat superfluous, with little gain for the lines of code added. Rich argued against writing thin wrappers around Java stuff as well. And personally, I'd probably only ever use the two-arg version with an integer in milliseconds, since that's what most methods/functions are using anyway. (If you know of use cases for and trust the system clock to act on milliseconds correctly, you could also make the integer represent nanoseconds instead.) 2. Returning nil to represent timeout is dangerous here -- the future may have completed correctly and returned nil! It should be perfectly okay and idiomatic here to let the TimeoutException escape, as long as you document this behaviour. What do others think? -- Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
Enhanced primitive support - redux
equiv, the revenge of num The latest revision of primitive support is in the equiv branch. It takes the approach of num, with no auto-promotion, and bigint contagion, and adds several things to better support contagion. I think contagion is the best way to continue to support polymorphic numeric code, something I consider important. Contagion has several issues. First and foremost, it means that it it will be possible for 42 and 42N to be produced in the course of normal operations, so strict type-specific equality is not a good match. The equiv branch brings back equivalence-based =, with a slightly tighter notion of =, supporting only similar categories of numbers, so (= 42 42.0) => false, but (= 42 42N) => true. == is still available. The second problem is the use of numbers (and collections of numbers) as keys in hash maps and members of hash sets. We already had an issue here, as there wasn't completely uniform boxing, and there will always be the possibility of numbers from the outside. The equal branch tried to use consistent boxing and type-specific =, but it was still open to mismatch with numbers from outside. The equiv branch extends = to keys and set members when used from Clojure, i.e. Clojure get and contains will use = logic, while the Java get and containsKey will use .equals(). I.e. we will still satisfy the semantics of Java when used through the Java APIs, but nothing said the Clojure API must match those semantics. When combined with the new BigInt class (see below), this will allow you to look up (and find!) the integer 42 with either 42 or 42N. The equiv branch also has a new BigInt type. This is strictly necessary for this scheme, as Java's BigIntegers and Longs can produce different hashCodes for the same values. In addition to matching hashCode support, the BigInt class opens the door to better performance when used with numbers long-or-smaller. These performance enhancements have not yet been made. More details have been added to the top here: https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support Code is here: http://github.com/richhickey/clojure/commits/equiv Feedback welcome, Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
This looks excellent. I'd like to re-raise a question I had a few days ago: Will this ultimately come to affect floats, too? In particular: 1) If there is going to be BigInt contagion, why not BigDecimal contagion? user=> (* 4 5) 20 user=> (* 4 5N) 20N but user=> (* 4.0 5.0) 20.0 user=> (* 4.0 5.0M) ;no contagion 20.0 user=> (* 4.0M 5.0M) 20.00M user=> (* 4.0 5.001M) ;not even when it's needed 20.0 user=> (* 4.0M 5.001M) 20.0040M 2) Will the same reasoning that produced BigInt give us a BigDec with a better hashCode() than that of BigDecimal? user=> (hash 4343434343) 48467046 user=> (hash (BigInteger. "4343434343")) ;not very nice 48467078 user=> (hash 4343434343N) ;nice as of equiv branch 48467046 but user=> (hash 4343.4343) 1861754824 user=> (hash 4343.4343M) ;not very nice 1346464637 user=> (defn -hashCode [this] (let [dv (.doubleValue this)] (if (== this dv) (.hashCode dv) (.hashCode this #'user/-hashCode user=> (hash 4343.4343) 1861754824 user=> (-hashCode 4343.4343M) ;nicer 1861754824 Garth On Fri, Jun 25, 2010 at 3:04 PM, Rich Hickey wrote: > equiv, the revenge of num > > The latest revision of primitive support is in the equiv branch. It takes > the approach of num, with no auto-promotion, and bigint contagion, and adds > several things to better support contagion. I think contagion is the best > way to continue to support polymorphic numeric code, something I consider > important. > > Contagion has several issues. First and foremost, it means that it it will > be possible for 42 and 42N to be produced in the course of normal > operations, so strict type-specific equality is not a good match. The equiv > branch brings back equivalence-based =, with a slightly tighter notion of =, > supporting only similar categories of numbers, so (= 42 42.0) => false, but > (= 42 42N) => true. == is still available. > > The second problem is the use of numbers (and collections of numbers) as > keys in hash maps and members of hash sets. We already had an issue here, as > there wasn't completely uniform boxing, and there will always be the > possibility of numbers from the outside. The equal branch tried to use > consistent boxing and type-specific =, but it was still open to mismatch > with numbers from outside. The equiv branch extends = to keys and set > members when used from Clojure, i.e. Clojure get and contains will use = > logic, while the Java get and containsKey will use .equals(). I.e. we will > still satisfy the semantics of Java when used through the Java APIs, but > nothing said the Clojure API must match those semantics. When combined with > the new BigInt class (see below), this will allow you to look up (and find!) > the integer 42 with either 42 or 42N. > > The equiv branch also has a new BigInt type. This is strictly necessary for > this scheme, as Java's BigIntegers and Longs can produce different hashCodes > for the same values. In addition to matching hashCode support, the BigInt > class opens the door to better performance when used with numbers > long-or-smaller. These performance enhancements have not yet been made. > > More details have been added to the top here: > > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support > > Code is here: > > http://github.com/richhickey/clojure/commits/equiv > > > Feedback welcome, > > 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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
Amazingly good ideas. Will try it tomorrow. On Fri, Jun 25, 2010 at 8:04 PM, Rich Hickey wrote: > equiv, the revenge of num > > The latest revision of primitive support is in the equiv branch. It takes > the approach of num, with no auto-promotion, and bigint contagion, and adds > several things to better support contagion. I think contagion is the best > way to continue to support polymorphic numeric code, something I consider > important. > > Contagion has several issues. First and foremost, it means that it it will > be possible for 42 and 42N to be produced in the course of normal > operations, so strict type-specific equality is not a good match. The equiv > branch brings back equivalence-based =, with a slightly tighter notion of =, > supporting only similar categories of numbers, so (= 42 42.0) => false, but > (= 42 42N) => true. == is still available. > > The second problem is the use of numbers (and collections of numbers) as > keys in hash maps and members of hash sets. We already had an issue here, as > there wasn't completely uniform boxing, and there will always be the > possibility of numbers from the outside. The equal branch tried to use > consistent boxing and type-specific =, but it was still open to mismatch > with numbers from outside. The equiv branch extends = to keys and set > members when used from Clojure, i.e. Clojure get and contains will use = > logic, while the Java get and containsKey will use .equals(). I.e. we will > still satisfy the semantics of Java when used through the Java APIs, but > nothing said the Clojure API must match those semantics. When combined with > the new BigInt class (see below), this will allow you to look up (and find!) > the integer 42 with either 42 or 42N. > > The equiv branch also has a new BigInt type. This is strictly necessary for > this scheme, as Java's BigIntegers and Longs can produce different hashCodes > for the same values. In addition to matching hashCode support, the BigInt > class opens the door to better performance when used with numbers > long-or-smaller. These performance enhancements have not yet been made. > > More details have been added to the top here: > > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support > > Code is here: > > http://github.com/richhickey/clojure/commits/equiv > > > Feedback welcome, > > 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
Following up, point (2) in my previous message would be helpful only if = were changed so that it looked at the stripTrailingZeros() value of BigDecimals. I would advocate this in any case, because the following behavior appears silly to me (is it useful to anyone?): user=> (== 434343.00M 434343.0M) ;BigDecimal works this way, apparently false user=> (= 434343.00M 434343.0M) ;odd, however false user=> (= 434343.00M 434343.0) false user=> (== 434343.00M 434343.0) ;even odder, in my opinion, given the above true user=> (= (.stripTrailingZeros 434343.00M) (.stripTrailingZeros 434343.0M)) ;shouldn't = default to this? true Garth On Fri, Jun 25, 2010 at 4:18 PM, Garth Sheldon-Coulson wrote: > This looks excellent. > > I'd like to re-raise a question I had a few days ago: Will this ultimately > come to affect floats, too? > > In particular: > > 1) If there is going to be BigInt contagion, why not BigDecimal contagion? > > user=> (* 4 5) > 20 > user=> (* 4 5N) > 20N > > but > > user=> (* 4.0 5.0) > 20.0 > user=> (* 4.0 5.0M) ;no contagion > 20.0 > user=> (* 4.0M 5.0M) > 20.00M > user=> (* 4.0 5.001M) ;not even when it's needed > 20.0 > user=> (* 4.0M 5.001M) > 20.0040M > > 2) Will the same reasoning that produced BigInt give us a BigDec with a > better hashCode() than that of BigDecimal? > > user=> (hash 4343434343) > 48467046 > user=> (hash (BigInteger. "4343434343")) ;not very nice > 48467078 > user=> (hash 4343434343N) ;nice as of equiv branch > 48467046 > > but > > user=> (hash 4343.4343) > 1861754824 > user=> (hash 4343.4343M) ;not very nice > 1346464637 > > user=> (defn -hashCode [this] > (let [dv (.doubleValue this)] > (if (== this dv) > (.hashCode dv) > (.hashCode this > #'user/-hashCode > > user=> (hash 4343.4343) > 1861754824 > user=> (-hashCode 4343.4343M) ;nicer > 1861754824 > > Garth > > > > On Fri, Jun 25, 2010 at 3:04 PM, Rich Hickey wrote: > >> equiv, the revenge of num >> >> The latest revision of primitive support is in the equiv branch. It takes >> the approach of num, with no auto-promotion, and bigint contagion, and adds >> several things to better support contagion. I think contagion is the best >> way to continue to support polymorphic numeric code, something I consider >> important. >> >> Contagion has several issues. First and foremost, it means that it it will >> be possible for 42 and 42N to be produced in the course of normal >> operations, so strict type-specific equality is not a good match. The equiv >> branch brings back equivalence-based =, with a slightly tighter notion of =, >> supporting only similar categories of numbers, so (= 42 42.0) => false, but >> (= 42 42N) => true. == is still available. >> >> The second problem is the use of numbers (and collections of numbers) as >> keys in hash maps and members of hash sets. We already had an issue here, as >> there wasn't completely uniform boxing, and there will always be the >> possibility of numbers from the outside. The equal branch tried to use >> consistent boxing and type-specific =, but it was still open to mismatch >> with numbers from outside. The equiv branch extends = to keys and set >> members when used from Clojure, i.e. Clojure get and contains will use = >> logic, while the Java get and containsKey will use .equals(). I.e. we will >> still satisfy the semantics of Java when used through the Java APIs, but >> nothing said the Clojure API must match those semantics. When combined with >> the new BigInt class (see below), this will allow you to look up (and find!) >> the integer 42 with either 42 or 42N. >> >> The equiv branch also has a new BigInt type. This is strictly necessary >> for this scheme, as Java's BigIntegers and Longs can produce different >> hashCodes for the same values. In addition to matching hashCode support, the >> BigInt class opens the door to better performance when used with numbers >> long-or-smaller. These performance enhancements have not yet been made. >> >> More details have been added to the top here: >> >> >> https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support >> >> Code is here: >> >> http://github.com/richhickey/clojure/commits/equiv >> >> >> Feedback welcome, >> >> 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 >> > > -- You 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 thi
Re: Enhanced primitive support - redux
floats and doubles are "inexact" numbers and ratios, ints, longs, bigints, and bigdecimals are "exact" numbers. The expected behavior is that inexact things contaminate exact things, because now the result is inexact. This is what Clojure does. On Fri, Jun 25, 2010 at 1:18 PM, Garth Sheldon-Coulson wrote: > 1) If there is going to be BigInt contagion, why not BigDecimal contagion? doubles contaminate bigdecimals, not the other way around. That's how it should be. > 2) Will the same reasoning that produced BigInt give us a BigDec with a > better hashCode() than that of BigDecimal? You don't want the hashCode of bigdecimal to match the corresponding double. They aren't equal, so they shouldn't have the same hashcode. They aren't equal because one is exact and one is inexact. Now, one interesting question is whether the hashCode of 40.0M should match the hashCode for 40N, because they are two exact numbers that represent the same value. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
A couple points of clarification: On Fri, Jun 25, 2010 at 1:35 PM, Mark Engelberg wrote: > You don't want the hashCode of bigdecimal to match the corresponding > double. They aren't equal, so they shouldn't have the same hashcode. > They aren't equal because one is exact and one is inexact. I should have said "they shouldn't be equal" based on Rich Hickey's explanation that from now on (= 1 1.0) will return false. I think by this logic (= 1.0M 1.0) should also be false. I have no idea what the current branch actually does though -- haven't tried it yet. > > Now, one interesting question is whether the hashCode of 40.0M should > match the hashCode for 40N, because they are two exact numbers that > represent the same value. > The more I think about it, the more I think that big decimals are sort of their own universe and we really wouldn't want the hashCodes of an integral bigdecimal to match the integer hashcode. I mean, if 40.0M and 40.00M are considered different by Java, it seems fruitless to try to unify these with their integer counterparts. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
I'd first like to thank everyone who has replied so far. Your feedback has been invaluable. I'm going to try and address some of the issues people have raised. If I've missed any big ones, feel free to shout louder :) @Joost Could you send me an email with the i18n patches you had to make to Compojure/Ring? @Chas I think we probably need a high-level way of exposing a type as a HTTP resource. I haven't thought about this much, but it's certainly a hole that isn't quite filled by currently available libraries. @Chas, @Brian, @Brenton Deployment is also an issue. Perhaps we need a Leiningen plugin that would automatically generate an AOTed HttpServlet, given a :handler key in defproject that designates the main handler function. Another option is to bypass the whole idea of Java servlet containers and devise some lightweight Clojure solution. I guess some people will like that idea, whilst others will shudder at the idea of reinventing a well-used wheel. @Hugo I agree that a standard authentication and authorization library would be good. With OpenID, OpenAuth, etc. authentication is becoming quite complex, and login pages are becoming quite uniform. It would be nice to have some middleware that would automatically provide this sort of thing. Named routes may be something I could integrate into Compojure. I'd have to think of a good way of doing it. @Adrian One thing Ring and Compojure are lacking are some good benchmarks. I'll have to see about making some, unless anyone wants to volunteer? @Jimmy, @Chas, @Sean Websockets/Comet is something that has been mentioned to me a few times. Websockets are a separate protocol to HTTP, and Comet is essentially a separate protocol, even if it uses HTTP as a transport layer. So in the past, my opinion is that normal HTTP should be handled by Ring, and Websockets/Comet should be handled by something different. However, it occurs to me that whilst Websockets and Comet are arguably not HTTP, they do start out with a normal-looking HTTP request. I wonder if Ring could accept this initial request, but instead of returning a standard response map, it returns a message-handling function. I'll think about this, then bring it up on the Ring group for further discussion. @Wilson, @Daniel, @Mark E Clojure web development is shaping up to be made up of many small, interchangeable parts. On the whole, I think this is a good thing. I don't like the idea of monolithic web frameworks, continually reinventing the same wheels (routes, templates, ORM). My goal for Clojure web development is near total interoperability. But at the same time, it's good to be able to pick something up that integrates all these small parts together. I think eventually we'll see larger frameworks emerging for Clojure that just tie a bunch of low-level libraries together. But I think we're a little way off that goal. @Wilson, @Brenton, @j-g-faustus, @Brian, @pavelludiq I've also started writing a Clojure Web Development book. One of the problems of having lots of small libraries is that its hard to get an overview of how one should proceed. The Clojure Web Development book is an effort to take the reader through the Clojure web development ecosystem, starting with Ring, but also later covering Compojure, Hiccup, Enlive, Moustache, Sandbar and others. I envision this as being similar to the Git community book [http://book.git-scm.com/]. I've started a Google document for it, which you can view here: https://docs.google.com/Doc?docid=0AQqGP1CDN0uIZGhmZjJmcGZfMjNjNHIycGZu&hl=en At the time of writing, it's in a ***very*** rough state. If anyone wants to help me out, I'll send them a read-write link they can use to contribute. When the book is more complete, I'll divide it up into web pages and put it in a GitHub repository. @Mark S Logging is something I've been very interested in at various points in the past, usually when an application goes wrong in production and I have to figure out what went wrong! I think we need to discard the notion that logs should be timestamped strings outputted to a file. Instead, I think they should be hash-maps we send to a logging server, which then stores them in a database. You could then visit the database and say "Show me all exceptions that occurred for user X". You could then select the field you wanted and say "Show me all log messages that occurred within the context of the same request as this exception". This is something that would have saved me a lot of pain in the past. You've gotten me thinking of writing something like this, perhaps using MongoDB or Redis to store the documents, and Compojure to write a nice web interface for searching/configuring. @Martin I've been thinking on and off about how to bind data to a set of routes. I'll let you know if I come up with anything, and suggestions are always welcome. I think Allen's "Turtles all the way down" post in the Compojure group is thinking along the right lines. @Howard Exception reporting cou
Re: Enhanced primitive support - redux
> I should have said "they shouldn't be equal" based on Rich Hickey's > explanation that from now on (= 1 1.0) will return false. I think by > this logic (= 1.0M 1.0) should also be false. I have no idea what the > current branch actually does though -- haven't tried it yet. > > Ah, yeah, fair enough. I would merely like to have floating point hash codes that match floating point equality. In other words, if we were to stick with the status quo where (= 0.3 0.3M) => true and (= 3/10 0.3) => true, then it would be nice to get BigDec hash codes that match Double hash codes. But you're right that Rich's message suggests we're moving to a world where (= 0.3 0.3M) => false. I hadn't realized the (good) consequences for floating point equality. In that world, you're right about hash codes. I also see what you mean about contagion. Personally, I think (= 3 3M) => true and (= 3/10 0.3M) => true would be nice to have, given that (= 3 3N) => true. Both are currently false in equiv. I also think (= 3.0M 3.00M) => true would be nice. As Rich said, there's no particular reason to have Clojure = work exactly like Java .equals(). I think all it would take is a call to .stripTrailingZeros() on each = comparison of a BigDecimal. Garth -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
Hi James, Great idea for a survey! I'm using Clojure to bootstrap a startup, broadly in the Healthcare domain. The system we're building comprises a number of components all implemented in Clojure, one of which is a centralised web server. The reason we chose Clojure was because it runs on the JVM, and we can interact easily with lots of legacy systems (Java has the best API's for interacting with the legacy systems we need). This coupled equally with Clojure's strong DSL capabilities, and homoiconic syntax (beyond just macros) are a key motivator for us. I doubt the things we're doing would be achievable in Scala, Groovy or JRuby in the time frames we need... Because Clojure seems naturally suited to our domain problem. Anyway, the point is that we're using Clojure for non-web reasons, but have been pleasantly surprised by the web story as it stands... Though right now (on the web) our needs are pretty basic. On the web side, we're using Ring and Moustache. We were using Compojure, but migrated to Moustache as I suspected Compojure was giving us problems with Clojure 1.2 (which we need for incanter). Anyway, the problem turned out to be unrelated to Compojure but the work involved in migrating between Compojure and Moustache was only about 30 minutes! So in this regard I think the component oriented approach to web development is working, as you really can swap components in and out quickly and easily... Something that I think would be far harder in Ruby (even with Sinatra). I'm on the fence in the Moustache vs Compojure debate. Both seem very good. I like how Moustache is more Clojure like. But then I also like how Compojure is more 'HTTP' like, i.e. it is more apparant that Compojure is routing HTTP requests than with moustache... but I think moustache is more flexible. That said I have two issues with moustache: 1) There are too many equivalent syntactic forms. This can be confusing, and I think I'd prefer the different syntaxes to have different semantics. 2) Moustache seems to silently swallow errors... However I haven't debugged this yet to firmly blame moustache, as it could well be my code. Anyway we're not firmly in Moustache camp and might later switch back to Compojure if it's beneficial. The web-app UI itself is written in Java as GWT application, that is compiled into HTML CSS & Javascript, however we write the GWT-RPC servlets in Clojure, and AOT compile them for wiring into jetty. This combination works quite well, as we get a blindingly fast UX, whilst retaining interactive development of both the ajax client and server side... whilst not worrying too much about cross browser issues. This said, I'm not completely sold on GWT yet, and we might consider switching to something else if it proves more capable or productive. We use Moustache (and before it Compojure) for routing API style requests rather than those from the webapp. The most complex part of our web-application is really the jetty wiring. Unfortunately because we want to mix both servlets (AOT compiled GWT RPCServlets) and ring handlers, we can't use the ring jetty wrapper. This could be simple if ring provided a means of converting a servlet into a handler (it already does the other way). This is the feature I'd most like to see in ring. We could of course wire the thing together in a web.xml, but IMHO that's more pain than wiring it in Jetty. Besides, having a REPL direct into the server is really handy, when you need to interogate things. Anyway, I'm *way* more productive in Clojure after a year and a half than I ever was in Ruby (approx 3-4 years) and Java (more than I care to count). I love how pragmatic the language is, and how you can solve a complex problem in 5 lines of expressive code... Not to mention interactive development, and paredit which makes life coding way more fun than even Ruby was. Oh, and also Clojure is fast!! Love it! ... Oh and did I mention how great incanter is?! :-) Anyway, thanks again for your devotion to the Clojure community! R. On 23 June 2010 22:23, James Reeves wrote: > Hello there! > > Chas Emerick's recent "State of Clojure" survey [http://bit.ly/dtdAwb] > indicated that a significant proportion of Clojure users are beginning > to use Clojure for web development. A recent Hacker News posting > [http://bit.ly/91Bu5J] seems to corroborate these results, with > several Clojure-based web applications already out in the wild. > > As one of the main developers of Ring and Compojure, I'd be very > interested to hear more about how people are using Clojure to build > web apps. To this end, I have a few questions I'd like to quiz Clojure > web developers about: > > 1. Have you written, or are you writing, a web application that uses > Clojure? What does it do? > > 2. Which libraries or frameworks are you using? Which versions? > > 3. What made you choose Clojure to develop web applications in? What > are the strengths of Clojure web development? > > 4. What do
reading from the slime repl
Hi everyone- I am running an emacs slime repl via "lein swank". I want to do some simple data input/output by writing a program that runs in the repl. However, when I try to execute "(read)" through the slime repl it gives a "stream closed" error. This operation works fine if done through "lein repl". Is this a limitation of swank? Or is there something I'm doing wrong? I couldn't find anything on the interwebs that discusses this issue. Thanks for any pointers! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
On Fri, Jun 25, 2010 at 2:39 PM, Garth Sheldon-Coulson wrote: > Personally, I think (= 3 3M) => true and (= 3/10 0.3M) => true would be nice > to have, given that (= 3 3N) => true. Both are currently false in equiv. I > also think (= 3.0M 3.00M) => true would be nice. As Rich said, there's no > particular reason to have Clojure = work exactly like Java .equals(). I > think all it would take is a call to .stripTrailingZeros() on each = > comparison of a BigDecimal. Yeah, if it's technically feasible, this definitely makes the most mathematical sense. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
I'll reiterate a question I asked a while back, but was never answered: Are the bit-bashing operators (bit-*) going to get the same treatment as the arithmetic operators? I would expect that many of the fields that benefit if the latter to be fast would also benefit from the former being fast, and I know that fast algorithms in combinatorics and crypto tend to make use of them. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: State of Clojure web development
> @Mark S > Logging is something I've been very interested in at various points in > the past, usually when an application goes wrong in production and I > have to figure out what went wrong! > > I think we need to discard the notion that logs should be timestamped I still like timestamps even with per-user logging. Since each user has its ownfile -mm-dd/userid the timestamp per line only needs to contain HH:MM:SS. Each day a new directory/file is created as needed. So log files don't grow toolarge. Another thread removes dirs/files older than 30 days. > strings outputted to a file. Instead, I think they should be hash-maps > we send to a logging server, which then stores them in a database. I prefer files. Using a DB prevents me from using existing powerful tools to search and query the logs: vim and emacs. The nice thing about per-user logging files is that they don't get that big. They are quick to load/search/analyze. > You could then visit the database and say "Show me all exceptions that > occurred for user X". You could then select the field you wanted and > say "Show me all log messages that occurred within the context of the > same request as this exception". This is something that would have > saved me a lot of pain in the past. Wrt context: per-user logging data is written serially so it's easy to figure out the context/progression of events that lead up to the exception. You know where one request starts and ends. FYI: we use the STM to queue up requests in a map and flush each user's loggingdata to disk every few seconds. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
On Sat, Jun 26, 2010 at 4:04 AM, Rich Hickey wrote: > equiv, the revenge of num Has it already been decided that some sort of this new numeric tower will find its way into Clojure? Personally, I think this change will open a can of worms and make programming in Clojure more difficult and error prone. I don't think there is a nice and clean solution to the numeric problem (Clojure is not the first language tackling it) but there are two possibilities that could produce an acceptable trade off: - using boxed math everywhere and optimizing performance by storing preallocated Integers in a cache, - using both boxed and primitive math but keeping the boundary between them as explicit as possible (different operators, no automatic conversion etc.). Existing operators should default to boxed math (for runtime safety and compatibility). 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
Re: Clojure / Common Lisp Question
> > Rich Hickey's insightful videos have caused me to stop > writing loops whenever possible. For me this is the same > level of "thinking-change" that happened when I moved to > using "Structured Programming" rather than GOTO (in Fortran). > Rich needs to write a paper called > "Loops considered harmful" > That is a great thing, I like that about both Common Lisp and Clojure. Compare with Perl or even Python; you can use map/grep, list comprehensions etc some of the time but not all of the time. I Lisp it's always possible to that in a neat way I think. I know there is a loop macro in CL, which I'm sure can cause many people to just write in some other language's idiom instead of the native one. > Common lisp, however, gives me precise machine-level to > massive function semantics, e.g. (car ...) is a machine > pointer and (integrate ...) is a huge function but I can > freely mix them in (integrate (car ...)). I don't feel the > same "one-ness" in Clojure/Java. > > Yes it is awesome. SBCL has a good enough compile that someone could write a fast OS kernel in it I think. And then we could actually read it and know what it's doing later on, and not have weird buffer overflows. ;) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure / Common Lisp Question
> > It can (but its startup is slow, currently). May I ask you why you > wouldn't want to use it? > > One reason is that from what little I know about ABCL it seems more straightforward working with Java libraries in Clojure, but also there is a huge amount of enthusiasm and energy going into Clojure, whereas with ABCL the developer is more on their own, with less eyes on the code, smaller community of users, etc. That and I enjoy lots of other things about Clojure, and want to use it, so playing with two JVM Lisps seems a little redundant and it becomes an either/or proposition for me. But I think I would use it if there was something written common lisp thing that I wanted to integrate into some other JVM-based thing, why not? I haven't had that experience but it seems like it could happen. > The nudging of paradigm/idiom makes many things easier in Common > Lisp. > > That depends on a lot of things and it's very personal. Common Lisp is > not automatically easier than Clojure for everyone. > > I agree with you on this actually, I was kind of playing devil's advocate to try to think of arguments for both sides... > I use Common Lisp because that's the Lisp I know. I'm interested in > Clojure because it has put some nice ideas on the table, but currently > I see no reason to use it outside heavily parallelism-oriented > applications, especially given that ABCL is there and it offers a nice > combination of CL with Java libraries. OTOH, I think that for the > average Java developer Clojure is probably friendlier. > > Concurrency is not very developed at all in Common Lisp, which could be a major point against it going forward, but I'm sure people will remedy that, as Lisp is always a good laboratory for adding new things to the language as libraries etc. Of course in the case of Clojure the interesting new ideas didn't come from CL, though many good old ideas did. CL people should probably study and consider Clojure's innovations in this case. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Futures Docs and Functionality
Hi,
Am 25.06.2010 um 20:48 schrieb Daniel Werner:
> On 25 June 2010 05:27, Ryan Senior wrote:
>> (future-await fut2 2 :minutes) ; => "done"
>
> What do others think?
I agree – in particular for point 2.
For point 1: I think "2 :minutes" is not very clojure-like. It sound more like
Ruby: 2.minutes. A more clojure-like approach would be to an use optional
keyword argument.
(defn future-await
[fut & {:keys [timeout]}]
)
(future-await zukunft)
(future-await zukunft :timeout time-out-in-ms)
Or of course the simple two-arg-version.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Enhanced primitive support - redux
On Sat, Jun 26, 2010 at 05:58, Andrzej wrote: > On Sat, Jun 26, 2010 at 4:04 AM, Rich Hickey wrote: >> equiv, the revenge of num > > Has it already been decided that some sort of this new numeric tower > will find its way into Clojure? > > Personally, I think this change will open a can of worms and make > programming in Clojure more difficult and error prone. > > I don't think there is a nice and clean solution to the numeric > problem (Clojure is not the first language tackling it) but there are > two possibilities that could produce an acceptable trade off: > - using boxed math everywhere and optimizing performance by storing > preallocated Integers in a cache, This was suggested on the previous thread on this topic as well, but I don't think it was pointed out that *Java already does this*. See the inner class IntegerCache at line 608: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/3956cdee6712/src/share/classes/java/lang/Integer.java And for Long as well (line 543): http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/3956cdee6712/src/share/classes/java/lang/Long.java > - using both boxed and primitive math but keeping the boundary between > them as explicit as possible (different operators, no automatic > conversion etc.). Existing operators should default to boxed math (for > runtime safety and compatibility). > > 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 -- You 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
