how many men have we killed in our life..we're not europeans
On Sat, Jul 10, 2010 at 6:47 PM, <clojure+nore...@googlegroups.com> wrote: > Today's Topic Summary > > Group: http://groups.google.com/group/clojure/topics > > bigint discrepency [1 Update] > CCW zombie error markers [1 Update] > Proposal: Digest [1 Update] > Idiomatic Clojure namespace names [5 Updates] > Congomongo question - how to update all records? [1 Update] > ClojureDocs.org [4 Updates] > Redcar and Clojure [1 Update] > Databases for a Concurrent World [4 Updates] > Recent builds have failed on http://build.clojure.org [1 Update] > Clojure and Backtraces [1 Update] > > Topic: bigint discrepency > > ".Bill Smith" <william.m.sm...@gmail.com> Jul 10 03:55PM -0700 ^ > > I ran across this while editing http://clojure-examples.appspot.com: > > user=> (bigint 1) > 1 > user=> (bigint 1.5) > 1 > user=> (bigint "1") > 1 > user=> (bigint "1.5") > java.lang.NumberFormatException: For input string: > "1.5" (NO_SOURCE_FILE:0) > > Since 1.5 coerces to 1, shouldn't "1.5" also coerce to 1? > > user=> *clojure-version* > {:interim true, :major 1, :minor 2, :incremental 0, :qualifier > "master"} > > Bill Smith > Austin, Texas > > > > Topic: CCW zombie error markers > > Lee Spector <lspec...@hampshire.edu> Jul 10 06:02PM -0400 ^ > > I'm using Eclipse/Counterclockwise and on a couple of occasions have had > errors (e.g. once with a java.lang.IllegalArgumentException) that produce an > error marker (a red circle with a white "x" in the left margin) that won't > go away when the error is fixed, or even when closing/reopening the document > or quitting/restarting Eclipse. > > Is there some simple way to clear these that I'm missing? I'm new to Eclipse > but have tried to find this in the documentation or via web searches... but > to no avail, and I have the feeling that I must be missing something > obvious. > > Actually I did find one way to remove these things, but it's a weird pain: > > quit > delete > <workspace>/.metadata/.plugins/org.eclipse.core.resources/.projects/<projectname>/.markers > relaunch > clean > run > (see > http://wiki.objectstyle.org/confluence/display/WOL/Sticky+WOD+error+markers+will+not+go+away) > > This seems like a workaround for a rare, pathological situation, but I've > gotten into this situation twice in two days with CCW, so I'm guessing that > I'm either missing the simpler, normal way to clear these things or maybe > the CCW/Clojure is creating a pathological situation more than other Eclipse > configurations (but more likely the former). > > Any pointers would be appreciated. > > -- > Lee Spector, Professor of Computer Science > School of Cognitive Science, Hampshire College > 893 West Street, Amherst, MA 01002-3359 > lspec...@hampshire.edu, http://hampshire.edu/lspector/ > Phone: 413-559-5352, Fax: 413-559-5438 > > Check out Genetic Programming and Evolvable Machines: > http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ > > > > Topic: Proposal: Digest > > David Soria Parra <d...@php.net> Jul 10 09:22PM ^ > > Hi, > > I want to propose a wrapper around MessageDigest to provide a simple way > to generate digests. > > The following proposal includes a multimethods digest, which operates either > on strings or on arrays of bytes. > > I think digests are usuall used with strings. To expose the byte array api > from java's message digest class I used multimethods. Other multimethods > do not exists, as I think it doesn't make much sense to define digest > on something like integers or sequences. > > The function digest-to-str returns a typical string representation. > > The available algorithms correspond to the algorithms that are available > using MessageDigest. > > The code can be found here: > http://github.com/dsp/clojure-contrib/commit/77c9f7dbe071d90bf6cb385db4859e76d5e8ff19 > > A typical example would be: > (digest-to-str (digest "hello world" :algorithm "SHA-1")) > > I'm open for suggestions, as I'm new to clojure and the API might not > be perfectly suited for clojure. > > - David > > > > Topic: Idiomatic Clojure namespace names > > Martin DeMello <martindeme...@gmail.com> Jul 10 07:44PM +0530 ^ > >> clj.mired.proclog >> clj.weavejester.compojure >> clj.acme-corp.dynamite > > +1 > > martin > > > > Martin DeMello <martindeme...@gmail.com> Jul 10 07:46PM +0530 ^ > > On Sat, Jul 10, 2010 at 2:56 PM, Mike Meyer >>>clj.weavejester.compojure >>>clj.acme-corp.dynamite > >> Why should I prefer clj.mired, shared with gods knows who over org.mired, >> shared with nobody? > > You wouldn't; someone without his own domain, or who didn't want to > tie his project namespace to his domain, might. > > martin > > > > Mikhail Kryshen <mikh...@kryshen.net> Jul 10 11:10AM -0700 ^ > >> the project, authors, etc., should be associated with the Jar file if >> anything, but not splatted on the top of every piece of code that uses >> a library. > > Also it is possible to have a library implementing single API in parts > in different languages or a library could be rewritten in a different > language while retaining API compatibility. > >> The issue of changing domain names when using the domain as package >> name is much worse than only the maintainer having to do a multi-file >> search and replace. > > I wonder if Oracle is going to rename all sun.* and com.sun.* packages > in JVM. > > Also I don't see why one have to rename packages at all. Package name > following the java conventions does not have to correspond to the > registered domain owned by the project maintainer. > > From the Java Code Conventions > (http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html): > > "The prefix of a unique package name is always written in > all-lowercase ASCII letters and should be one of the top-level > domain names, currently com, edu, gov, mil, net, org, or one of > the English two-letter codes identifying countries as specified > in ISO Standard 3166, 1981. > > Subsequent components of the package name vary according to an > organization's own internal naming conventions. Such conventions > might specify that certain directory name components be division, > department, project, machine, or login names." > >> the information containing components (right most) of package names >> you have to have a really wide package manager panel or deal with side >> scrolling. Every time I'm back in Java these things annoy me. > > This is more an IDE GUI usability issue. > > -- > Mikhail > > > > Phil Hagelberg <p...@hagelb.org> Jul 10 01:28PM -0700 ^ > >> to the wild and crazy, totally uncensored and unmonitored clojars.org, >> which is working out great in tandem with lein. Clojars wasn't a >> failed experiment, it's the future. > > Right, I think we have a consensus of sorts here: if you are worried > for some reason about naming collisions, then by all means use the > verbose reverse domain name. The rest of us will all use the > uncluttered way. > > -Phil > > > > Mike Meyer <mwm-keyword-googlegroups.620...@mired.org> Jul 10 04:40PM -0400 > ^ > > On Sat, 10 Jul 2010 03:42:16 -0700 (PDT) >> Nothing about what I said precludes interoperability with Java. In >> fact I specifically chose to use the two part namespace because it >> allows for AOT compilation, and thus access from other JVM languages. > > No, it just ignores the increased possibility of collisions once you > include the Java and other JVM language. > >> languages, NOW, so yes it is plausible and realistic. I just don't >> see myself or many other people use Clojure libraries from outside >> Clojure yet, which is why I stated it the way that I did. > > The problem doesn't just occur for people calling clojure libraries > from outside clojure. Hell, if it were, I wouldn't care - I don't plan > on ever doing that. The problem occurs for people calling libraries > from other languages in Clojure, which happens all the time. > >> >> completely.useless.names.for.libraries.that.google.will.find.before.you.finish.typing.the.package.name, >> yet there are plenty of proofs by existence that this kind of scheme >> is not necessary to have a successful language or library community. > > If people would quit repeating arguments that have already been shown > to be wrong, there would be no reason to repeat the refutations. Yes, > there are plenty of proofs by existence that a near free-for-all can > be successful. So what? There are also plenty of proofs that a near > free-for-all can cause name collisions and pain as well - even in > successful languages. In fact, the more successful they are, the more > likely that becomes. > > If all you want is a successful language, feel free to ignore any data > that doesn't agree with what you're saying. If you want the > environment to be the best it can be, then you examine both sets of > cases, figure out what's different about them, and try and make sure > clojure has the properties of the first set and not the second. Then > you figure out how clojure is different from the successful cases, and > try and figure out how to compensate. I've been doing that and > proposing alternatives to both the free-for-all and the DNS names all > along. > >> prepare for it. This is the kind of enterprisey Java think that >> results in everything requiring copious amounts of configuration >> rather than just working the simple way by default. > > No, but it sure as hell seems like the whole world is writing Java > already, and clojure shares that name space. That's what we have to > deal with. > >> the project, authors, etc., should be associated with the Jar file if >> anything, but not splatted on the top of every piece of code that uses >> a library. > > Another one of those oft-repeated wrong arguments. That ain't > meta-data, it's just a name, with no meaning whatsoever. The point of > using the language name as the first part of the namespace isn't to > identify what language the program is written in, it's to pick out > part of an existing namespace convention that isn't likely to be used > by anyone else. It could just as well be pybwher. > >> dynamic code where a simple search and replace might not do it. >> Renaming packages is really annoying, and another of many reasons not >> to include domains in package names. > > No, it's a reason not to rename the package just because the project > and/or author changed domains. Thinking you have to do that is one of > those false arguments people keep on making. The Java spec *says* the > domain in a java class name doesn't have any meaning, they're just > piggy-backing on an existing centralized registry. Any software, > organization or person that imputes a real-world meaning from a > classes full name is making a mistake. > >> the information containing components (right most) of package names >> you have to have a really wide package manager panel or deal with side >> scrolling. Every time I'm back in Java these things annoy me. > > True, that sucks. An IDE actually helps, because you can scroll away > the meaningless columns. See > http://www.mired.org/home/mwm/papers/simple-clojure.html for my take > on how to deal with them in a CLI (look for "namespaces" on the page). > >> to the wild and crazy, totally uncensored and unmonitored clojars.org, >> which is working out great in tandem with lein. Clojars wasn't a >> failed experiment, it's the future. > > Won't be the first time I've been on the losing and right side of a > technical argument at the same time. On the other hand, if Clojars > turns into a central registry of names - that's one the thing the > languages without collision problems have that those with them don't > have. I think it's got to much java infrastruture crap in it - doesn't > seem like there's a way to just download a jar from it. > > <mike > -- > Mike Meyer <m...@mired.org> 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 > > > > Topic: Congomongo question - how to update all records? > > Mark Engelberg <mark.engelb...@gmail.com> Jul 10 01:17PM -0700 ^ > > Let's say I have a table called :table, and a column called :col, and > I want to go through all the records in the table and set the :col > value to 0. I had been doing it like this: > (defn update-db! [] > (doseq [entry (fetch :table)] > (update! :table entry (assoc entry :col 0)))) > > but the other day I noticed that this was mysteriously skipping over > certain records, and not everything was getting updated. So I > switched to this: > > (defn update-db! [] > (doseq [entry (doall (fetch :table))] > (update! :table entry (assoc entry :col 0)))) > > which worked just fine. I speculate that somehow the update process > screws with whatever iteration process that fetch uses to deliver the > records lazily. However, now my update process is limited by the > number of records I can hold in memory. > > So, is there some sort of recipe for updating all records without > first loading them all into memory? > > > > Topic: ClojureDocs.org > > James Reeves <jree...@weavejester.com> Jul 10 01:45PM +0100 ^ > >> Quick thought: You probably don't want to include private vars. > > Seconded. It's a little confusing seeing private vars and macros in > the API docs! > > Other than that, this looks excellent. I'm signing up as I write this. > > - James > > > > Stuart Halloway <stuart.hallo...@gmail.com> Jul 10 10:06AM -0400 ^ > > Very cool. Let me start by saying thanks to everyone who has been involved > in the various threads on improving documentation, especially those who, > like Zack, have taken substantial action. > > Here are a bunch of ideas, in no particular order: > > (1) Ease of contribution is huge, and http://clojuredocs.org looks good on > this front. Stick to it. > > (2) +1 on hiding private APIs. We use private APIs carefully and > deliberately in Clojure, and I would hate to facilitate people writing code > that will break later. > > (3) +1 on making it very easy to see which version of an API you are looking > at. This should be both at the top level (some way to say "show me 1.1") and > on a per-var basis, reading the :added metadata. > > (4) Provenance matters. Clojure itself is very careful to have people sign a > CA before contributing code. The bar may be somewhat different for a > documentation site, but it still needs to be carefully considered. > > (5) Continuity matters. We have already had some pain with useful resources > popping up on the web and then having the maintainer go AWOL with no > succession plan. There are several steps any documentation site should take > to address this: (a) open sourcing everything (b) including multiple > committers and admins on the site itself and (c) providing an easy API to > suck the data out. > > (6) Because docstrings are designed for consumption at a REPL, they may in > some cases presume a fixed font. Worth considering for display on the site. > > (7) Quality matters. There are multiple possible ways to make sure that the > cream rises: letting people up and downvote, making it easy for "editors" to > track new submissions, etc. > > Thanks again! > > Stu > > > > > James Reeves <jree...@weavejester.com> Jul 10 06:36PM +0100 ^ > >> (6) Because docstrings are designed for consumption at a REPL, they may in >> some cases presume a fixed font. Worth considering for display on the site. > > What about giving function documentation the same "wiki" behaviour > that the examples have? Start off with the docstrings as the initial > values, but allow people to update them. The web allows longer and > better formatted documentation than a standard Clojure docstring > (which needs to fit in a terminal). > > - James > > > > "Luc Préfontaine" <lprefonta...@softaddicts.ca> Jul 10 02:58PM -0400 ^ > > Zack if you need help with this Rail > app let us now. We can give you a > hand, the wish list keeps growing :))) > > Luc P. > > > Sent from my iPod > > > > > Topic: Redcar and Clojure > > Dave Byrne <david.r.by...@gmail.com> Jul 10 09:01AM -0700 ^ > > Does anyone use Redcar editor with Clojure? I am thinking about > writing a Clojure REPL plugin, but wanted to make sure no one else has > already done this. Would anyone find this useful, or is there no need > for it with the plethora of other options (emacs/slime/swank, > counterclockwise, etc.)? > > > > Topic: Databases for a Concurrent World > > David Nolen <dnolen.li...@gmail.com> Jul 10 11:59AM -0400 ^ > >> between making one connection per request vs. pipelining many request >> over an already established connection... > >> Toni. > > > One big problem with the PostgreSQL and MySQL numbers is that they don't use > pooling. I found a simple example of adding that to the PostgreSQL code and > done so, though I'm still hunting for a MySQL example :P > > As far as CouchDB I'm using Richard Newman's nice clj-apache-http library > which is a wrapper around Apache HTTP Client. It reuses connections by > default. However Iooking into this some more, the connections might still be > the bottleneck - I'm looking into using multithreaded client connection > manager. Will be interesting to see what numbers come up after that. > > If the whole premise of the blog post turns out to be flawed at least we > have a page documenting the basics of how to use Clojure with several dbs ;) > > David > > > > Toni Batchelli <tbatche...@gmail.com> Jul 10 09:46AM -0700 ^ > > I think what you're doing is great. I understand you're using ab for > these tests, right? What are the actual settings that you are using? > > Also, I'd like to mention that what these tests are showing is the > behavior of the server under constant load (constant frequency in the > arrival times of the requests, and constant load attached to each > request). This is not what happens in reality though, and servers that > do well under a constant distribution of requests might not do that > well (at all) under a Pareto distribution of both arrival times and > load (a real load that a server gets is very similar to a Pareto > http://en.wikipedia.org/wiki/Pareto_distribution). Under a Pareto load > a well crafted event-based server that has bounds on the number of > threads used (and maybe other resources) might significantly > outperform a 1-thread-per-request server. Unfortunately, I don't think > ab can test these scenarios. > > I built a tool sometime ago while working at UCSB that would do > exactly this. I will look into whether I can dig it out and opensource > it. > > Toni. > > > > -- > Antoni Batchelli > - twitter: @tbatchelli , @disclojure > --- email: tbatche...@gmail.com > ----- web: tbatchelli.org , disclojure.org > > > > Allen Johnson <akjohnso...@gmail.com> Jul 10 12:55PM -0400 ^ > > To test with pooled DB connections I thought I'd mention Apache Commons > dbcp. Its a generic connection pool library that could be used for any jdbc > connection. > > I'd post a example clojure usage but I'm afk atm. The lib's BasicDataSource > is probably all you'd need. > > Depends on Commons pool. Just place both jars on the classpath. > > http://commons.apache.org/dbcp/ > > Allen > > On Jul 10, 2010 12:47 PM, "Toni Batchelli" <tbatche...@gmail.com> wrote: > I think what you're doing is great. I understand you're using ab for > these tests, right? What are the actual settings that you are using? > > Also, I'd like to mention that what these tests are showing is the > behavior of the server under constant load (constant frequency in the > arrival times of the requests, and constant load attached to each > request). This is not what happens in reality though, and servers that > do well under a constant distribution of requests might not do that > well (at all) under a Pareto distribution of both arrival times and > load (a real load that a server gets is very similar to a Pareto > http://en.wikipedia.org/wiki/Pareto_distribution). Under a Pareto load > a well crafted event-based server that has bounds on the number of > threads used (and maybe other resources) might significantly > outperform a 1-thread-per-request server. Unfortunately, I don't think > ab can test these scenarios. > > I built a tool sometime ago while working at UCSB that would do > exactly this. I will look into whether I can dig it out and opensource > it. > > Toni. > > > >> On Fri, Jul 9, 2010... > -- > Antoni Batchelli > - twitter: @tbatchelli , @disclojure > --- email: tbatche...@gmail.com > ----- web: tbatchelli.org , disclojure.org > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To p... > > > > Allen Johnson <akjohnso...@gmail.com> Jul 10 02:10PM -0400 ^ > > Here are my examples for mysql and postgres using commons-dbcp. They > are exactly the same except for the connection info. Might want to > play around with the initial,min,max size properties. > > [MySQL] > http://gist.github.com/470901 > > [PostgreSQL] > http://gist.github.com/470904 > > Just download and include the following jars in the classpath: > > http://commons.apache.org/dbcp/downloads.html > http://commons.apache.org/pool/downloads.html > > Allen > > > > > Topic: Recent builds have failed on http://build.clojure.org > > Stuart Halloway <stuart.hallo...@gmail.com> Jul 10 07:31AM -0400 ^ > > You are looking at the wrong build box. The master branch is at > http://github.com/clojure/clojure, now that GitHub offers organization > support. > > The current build.clojure.org is about to be replaced. We have a new build > box that we should be pointing the DNS to, hopefully this weekend. > > Stu > > > > > Topic: Clojure and Backtraces > > Stuart Halloway <stuart.hallo...@gmail.com> Jul 09 02:14PM -0400 ^ > > Proposal and patch welcome! > > > > > -- > You 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
