Re: Architectural doubts
For now I'm hand coding a big loop with transients and a bytebuffer. It is an incredibly ugly imperative mess but, it is fast enough and so far it fits nicely into ram. It takes 2s (at this point gloss was taking upwards of 5 minutes) to decode 200MB all the way to tcp and uses 500MB of heap. This is faster than wireshark(10s) but a bit more memory hungry. Will see how it responds when decoding diameter, so far that part is stored as byte-arrays. Thank you for the pointers with datomic. Are the indexes created automatically or do I need to specify them on the schema? -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Architectural doubts
While using wireshark to analyse libpcap files (= 200 MB) I routinely
think that it would be great to preform relational queries but, wireshark
only supports search.
I thought I would decode the entire file, hold it in memory as clojure data
structures and use datomic's datalog.
Besides relational queries, a requirement is for the file to be decoded
(libpcap, ethernet-II, IP, TCP, diameter) in less then a minute(for a
200MB) and the typical queries should also be less than a minute.
I thought the frames could be represented like this:
{:frame-id 1
:timestamp java's instant-object
:src-mac string
:dest-mac string
:src-ip
:dest-ip ...
...}
{:frame-ids [1 3]
:diameter-session-id ...}
So, I started by using gloss to decode a 200MB file. Gloss is fantastic to
specify frames but, it is not meeting the time requirements. It appear the
problem has to do with the creation of a lot of objects. Even with 3G of
ram for the heap, it still crawls to a halt.
I could try to perform some experiments to determine approximate answers
but, I think it is better to talk with people with more experience in order
to avoid common pitfalls..
My questions are:
Will the JVM (with 3G) support a million hashmaps like the above?
Is Buffy able to do something like what I want?
Will datomic be able to handle this use case?
What would you suggest to solve this(e.g. don't use clojure data
structures.. but then datomic's datalog is not available to query?)?
--
You 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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
core.logic vectors vs lists
Given this: (defn nullo [l] (== '() l)) (defn all-uno [l] (conde [(nullo l) s#] [(fresh [f r] * (firsto l 1)* (resto l r) (all-uno r))])) why is it that (run* [q] (all-uno [1 q 1 q])) unifies q with 1 and (run* [q] (all-uno '(1 q 1 q))) doesn't? More generally, when using core.logic, when should we expect behavior to differ when using vectors vs proper lists? -- -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.logic vectors vs lists
Thank you for the response and for core.logic. I assumed '(a b c) was equal to (list a b c) which I now see is a wrong assumption. On Wednesday, 1 January 2014 15:57:38 UTC, Milton Silva wrote: Given this: (defn nullo [l] (== '() l)) (defn all-uno [l] (conde [(nullo l) s#] [(fresh [f r] * (firsto l 1)* (resto l r) (all-uno r))])) why is it that (run* [q] (all-uno [1 q 1 q])) unifies q with 1 and (run* [q] (all-uno '(1 q 1 q))) doesn't? More generally, when using core.logic, when should we expect behavior to differ when using vectors vs proper lists? -- -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
clojure.zip branch? and next behaviour
I was trying to write a function next-branch. I wrote somthing like: (use 'clojure.zip) (def zp (seq-zip '(+ 1 2 (+ 3 4) (+ 5 6 (defn next-branch [loc] (second (filter branch? (iterate next loc (next-branch (next-branch (next-branch zp))) this results in: NullPointerException clojure.zip/branch? (zip.clj:73) Reading the docs of next returns a distinguished loc, this seams to imply next should always return a loc even when at the end. The docs of branch? Returns true if the node at loc is a branch seam to imply any loc will do. So this would lead me to concluded that next always returns a loc and since branch? is supposed to take a loc it should work. Why doesn't next return a loc at the end? Looking at the code I know why but is it intended to be this way? If so why? -- -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: A New Core.logic Primer
This primer is a good introduction to core.logic operators. What I think is missing is a tutorial that answers these questions: What type of problems does core.logic excel at solving? How do you solve problems with core.logic? How does it enable simplicity? (Rich said in simple made easy that they can replace conditionals, so a tutorial that explores that would be interesting) On Wednesday, March 14, 2012 7:00:57 PM UTC, David Nolen wrote: Thanks to Edmund Jackson we have a new primer for core.logic: https://github.com/clojure/core.logic/wiki/A-Core.logic-Primer Feedback appreciated! David On Wednesday, March 14, 2012 7:00:57 PM UTC, David Nolen wrote: Thanks to Edmund Jackson we have a new primer for core.logic: https://github.com/clojure/core.logic/wiki/A-Core.logic-Primer Feedback appreciated! 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: Alternative structures to arrays?
http://en.wikipedia.org/wiki/Quadtree Quadtrees and octrees are very good for sparse data(2-d and 3-d respectively), but it depends on the manipulations you want to make (depending on how they are implemented some update operations can be very costly when compared to arrays). I think there isn't a library for this written in clojure but, there are a few on java. On Dec 22, 10:11 am, Simon Holgate simon.holg...@gmail.com wrote: Hi, I'm pretty new to functional languages but really love Clojure. My work typically involves multi-dimensional arrays of data. I'm an oceanographer and typically use things like sea surface height data from satellite altimetry on 1/3 degree 2D grids with maybe 800 time slices (=O(5E8 data points)). For this I use Fortran and R. I realise that I can just use Java arrays, but is this the best approach? I could implement lists of lists but I'm guessing that the performance would be worse? What other structures could I use? The arrays are typically 30% sparse (since only 70% of the planet is ocean). This means arrays are wasteful in many ways. Similar issues must apply in image processing so are there ways of handling such data in functional structures? Thanks for any advice, Simon -- You 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: problems of a newbie
On Nov 7, 9:14 am, Dennis Haupt d.haup...@googlemail.com wrote: The main thing to keep in mind is that when coming from java/scala, you'll have a hard time adjusting to clojure, and you're making it harder by trying something so inherently full of state. I understand the need to tackle problems that we like, but without a good understanding of the language you're going to have a really hard time, and that reflects in your code. what would you have done differently? Generally, I think the best approach is, to represent everything with seqs, work with them and then display them. Something close to this https://github.com/ztellman/penumbra/blob/master/test/example/game/asteroids.clj -- You 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: problems of a newbie
On Nov 7, 12:41 pm, Milton Silva milton...@gmail.com wrote: On Nov 7, 9:14 am, Dennis Haupt d.haup...@googlemail.com wrote: The main thing to keep in mind is that when coming from java/scala, you'll have a hard time adjusting to clojure, and you're making it harder by trying something so inherently full of state. I understand the need to tackle problems that we like, but without a good understanding of the language you're going to have a really hard time, and that reflects in your code. what would you have done differently? Generally, I think the best approach is, to represent everything with seqs, work with them and then display them. Something close to thishttps://github.com/ztellman/penumbra/blob/master/test/example/game/as... Maybe this last post isn't very clear. Look at your split-asteroid. that fn is either doing much more than splitting asteroids or you have the wrong representation of asteroids. I have no idea which is it because I cannot understand it(It is doing too much at a time). Now look at the split-asteroid in the resource I gave you. -- You 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: problems of a newbie
On Nov 5, 12:16 pm, Dennis Haupt d.haup...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i'm half done with my asteroids clone. i stumbled over a few problems and wanted to know how others already solved them :) i am used to less concrete programming. i ask my tools to do the actual analysis and coding for me: * where is that used? Your editor does have a search fn right? * rename that again, all editors have this. * show me all errors what do you mean? for example when I compile a file in emacs I (normally) get the line where the error is. or do you mean runtime errors? * add a parameter here not sure I understand this one. if you mean (defn [a]..) to (defn [a b] ...) how do you do that without manual intervention in any language/ editor? (just adding more args to something doesn't mean they will be properly handled... that is our job) * autocomplete this for me, i am too lazy to even remember the exact method name emacs has this(possible not out of the box) and I suspect other too. * show me a list of all methods and fields starting with an e that fit in here. i know the one i want is in that list. emacs also has this(possible not out of the box) and again I suspect other too. as elegant as clojure may be as a language, it's dragging me down to almost native text editing which i did more than 10 years ago when i wrote a game in turbo pascal. how did you solve these problem and get some tool-support? or don't you miss it because of something i am not aware of? I know IDE support isn't as good as in java but, after looking at your code, yes, there is something your not aware of and that is why clojure is giving you a hard time. The main thing to keep in mind is that when coming from java/scala, you'll have a hard time adjusting to clojure, and you're making it harder by trying something so inherently full of state. I understand the need to tackle problems that we like, but without a good understanding of the language you're going to have a really hard time, and that reflects in your code. First, understand the philosophy of clojure. look here http://tinyurl.com/5u3suzf and here http://www.infoq.com/presentations/Simple-Made-Easy If you understand that philosophy and identify with it then try to solve very small problems(preferably with little to no inherent state), and try to be as idiomatic as possible. To understand how to solve problems idiomatically, read books (e.g. joy of clojure) ask in the IRC or here on how to solve particular problems and complement this with understanding the key ideas of libraries that excel in this(e.g Ring). When you have a good understanding of the language and underling philosophy, invest some time to think about your problem and how to properly express it clojure. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOtSkdAAoJENRtux+h35aGeeQP+gJbQdNSZEdEIgjVFC/VZvRe z1Rh9Z8xVwxbuyl/kx1GMLU3jZxJKkhp0OIp7RLbDgjwFFzwBnQ0CZSeuHd9bFD/ S5Vmf6tXB4AdC3u3a7wZilEQuSuq+ARtJhMKdGIQfoXgqDYA7JwOvV8ZkpiR2T2d pKqswheRVstBqo9/xyinfuLsJMujDlF9NshoIC0n1b/L4tzddq/kgzIATcg/NJ4N I0Qd1lqGC1THU2nHtiaSR66KQE5Ciq22FN0nVoT3jW9EU/kJ9tao7L6SUTY3tcaA th8mxKLYId/NrbRmsYUTyWe6O30HAUTLLFEnImYTW2fUMdwRYeAoZGc7t5V3yJ/p dU4JN0dGA/ADbdTItykaao1DtGI2/kGe6p9VaKk3IPCVAOio9UwgOCUQylTKqy7M CWbrDcSFCQs5pTY1Sw5We9LV2VOBoTsai6vH/qE7t98mJLVf0wHvLLIBOkf/QO5a HuSyCJRpOrWQF2jbooDqAbaJAa6huxLQjMeO9Ri4sDx2gDRYsf9Fmdjp4TFWWjdZ O5HEzhUR165peQHo4RQLLf8dnlkibsdbx60n+VJ0E4iE7ID+hBOFC76bAllnAS1K Q8HqXUogMi/ZLXIAB4BA83q71IEDVcytuYAn9Ku2FQLrmWCiOD57uMhSLjtzK/8J TIuaLwipARdzsqi/piwl =MnRq -END PGP SIGNATURE- -- You 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: advantage of dynamic typing
+1 On Sep 20, 4:43 am, Sean Corfield seancorfi...@gmail.com wrote: On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Railo Technologies, Inc. --http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You 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: Thoughts on CUDA + Clojure
Why not opencl? This way you would be able to run the code in any hardware and even a hybrid approach cpu+gpu(AMD and NVIDIA), you could even think about webcl (javascript to access the gpu) which I think has some form of GC. Besides, opencl code is very similar to CUDA code. Whatever you do, this is a very interesting topic. On 8 Set, 19:43, Timothy Baldridge tbaldri...@gmail.com wrote: I've been kicking around an idea for some time, of starting a Clojure-CUDA compiler. I would like to start a discussion about this to figure out what some possible solutions are. First of all let me start a simple fact list: CUDA (for those who don't know) is NVIDIA's technology for writing general use code for modern GPUs. The current system uses a subset of C++ as it's input. The code looks like small functions/classes that are executed for each thread of the GPU. These threads can number in the thousands, and the GPU commonly executes hundreds of these at one time. So, basically we're talking of running pmap on a system will 512+ cores. CUDA 4.0 supports some very advanced C++ features. As of 4.0 CUDA supports virtual functions, and new/deleteyes...your GPU code can allocate memory on the fly (if you have a GeForce 4xx or greater). My idea is to make a subset of Clojure translatable to CUDA. So you would create input data in native memory, the the Clojure functions would be translated to CUDA C++, then to CUDA binaries where they would be executed in the CPU. A very simple approach would be to take the view that may Clojure-SQL frameworks do, and simply do a translation. In this method all CUDA Clojure functions would take only arrays and scalar values as inputs, and the functions would read data from arrays, and output them to arrays. No sequences, on-the-fly allocation, or any such thing would be allowed. On top of that, all input and output data must be of the same type, so no mixing doubles and floats, or ints and longs. All data must be resolved to staticlly defined types, and mutating the variable's type on the fly is not allowed. The more complex approach would be to use something like ClojureScript to compile core.clj to CUDA, and actually run a subset of Clojure on the GPU. In this case we would have to come up with a simple type system, and then rewrite the ClojureScript compiler to output C++ code instead of JS. In addition, some sort of simple GC (reference counting?) would have to be developed. The result would be slower than my first approach, but would be much more flexible. So in the first version we have a simple to create system, but we can't use many of the functions we are familiar with in CUDA. In the second method, we have a slower, but much more powerful system that would integrate much more tightly with existing code. Any thoughts? Besides that I'm crazy... Timothy -- You 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 for large programs
On Jul 3, 2:26 am, Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of the initial excitement around Clojure comes from the
feeling of Wow, I can do so much with so little code. But at some
point, all projects grow. I'm thinking that by now, there may be
enough people using Clojure in large projects and on large teams to
offer some good feedback about how well that works.
My Clojure codebase is somewhere around 2-3kloc and I already feel
like I'm bumping up against some frustration when it comes time to
refactor, maintain, and extend the code, all while keeping up with
ongoing changes to libraries, contrib structures, and Clojure
versions.
I want to hear war stories from those with even larger code bases than
mine. Has it proven to be a major hassle on large projects to avoid
circular dependencies in the modules? Are the lack of debugging
tools, documentation tools, and refactoring tools holding you back?
Anyone miss static typing?
One of my main gripes is that some of Clojure's built-ins return
nonsensical results (or nil), rather than errors, for certain classes
of invalid inputs. To me, one of the main benefits of functional
programming is that debugging is generally easier, in large part
because failures usually occur within close proximity of the flaw that
triggered the failure. Erlang, in particular, has really promoted the
idea of fail fast as a way to build robust systems. But Clojure's
lack of a fail-fast philosophy has burned me several times, with
hard-to-track-down bugs that were far-removed from the actual cause.
The larger my code grows, the more this annoys me, reminding me too
much of my days tracking down bugs in imperative programs.
One specific example of this is get, which returns nil whenever the
first input isn't something that supports get. For example, (get 2 2)
produces nil. This becomes especially problematic when you pass
something to get that seems like it should support get, but doesn't.
For example, (get (transient #{1}) 1) produces nil, when there's
absolutely no reason to think that (get (transient #{1} 1) would
behave any differently from ((transient #{1}) 1).
I have done 4 projects, one was with another person and ranked ~1k(a
lot of java calls). The others were done solo and ranged from ~300 to
~500 lines.
Now that I think about it, that (fail-slow/returns nil) also really
annoys me but, that normally only pops up when I have lots of side
effects chained (which make the code a lot harder to test, and it
generally leads to a lot more code being written before it's tested).
Otherwise, I iteratively build things on the repl, this coupled with
unit tests forces a bottom up approach and partially because of that
the code I write is generally a lot more maintainable than java code.
I would definitely like to hear from people with more experience to
understand if, how and why things change as the projects get larger
(in team size and code size).
--
You 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: Complement to clojure survey
Results are open(to see the graphs, go to form-show summary of responses). The contrib results aren't very meaningful but, the rest are interesting. https://spreadsheets.google.com/spreadsheet/ccc?key=0AldCQypVmS28dFFJTTZWT2lXR1N1dTJTWk5mdjZXZlEhl=en_US On Jun 30, 2:06 am, Milton Silva milton...@gmail.com wrote: At this point there are 69 responses, I think they are enough to draw some conclusions but I'll keep thesurveyopen till later today(to see if we can get around 100 responses). As soon I close it, the results will be available for everyone. On Jun 23, 9:22 pm, Milton Silva milton...@gmail.com wrote: As suggested by Chas Emerick here:http://cemerick.com/2011/06/15/the-2011-state-of-clojure-survey-is-op... I've created the followingsurvey: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFFJTTZW... -- You 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: Complement to clojure survey
try this link https://spreadsheets.google.com/spreadsheet/gform?key=0AldCQypVmS28dFFJTTZWT2lXR1N1dTJTWk5mdjZXZlEhl=en_USgridId=0#chart On Jun 30, 9:49 pm, Phil Hagelberg p...@hagelb.org wrote: Milton Silva milton...@gmail.com writes: Results are open(to see the graphs, go to form-show summary of responses). Thanks. The Form menu seems to be disabled for anonymous viewers. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Complement to clojure survey
The graphs are now in sheet 3 and 4. I could not find a way to enable users to view the summary. On Jun 30, 11:37 pm, Phil Hagelberg p...@hagelb.org wrote: Milton Silva milton...@gmail.com writes: try this link https://spreadsheets.google.com/spreadsheet/gform?key=0AldCQypVmS28dF... Still doesn't work for unauthorized users: You need permission to access this item. You are signed in as [...], but you don't have permission to access this item. You can request access from the owner or sign-in as a different user. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Complement to clojure survey
On Jun 30, 11:55 pm, Sean Corfield seancorfi...@gmail.com wrote: Thanx Milton! Interesting results on the books. I suspect it's just a bit too early in the curve for Chas's book to score more highly (I'm very impressed with the Rough Cut so far!). I know but, I also saw no reason not to include it and if we repeat this again next year it will be fun to see how it evolved. Nice to see lein leading the build tools by such a margin - I'd love to see lein endorsed as the primary recommended build tool for the community and see tutorials / introductions updated to push lein instead of the download-and-unzip-and-navigate-and-java-jar approach. Sean Secretly that was one of the reasons for me to do this(I know that without more data it's hard to push the case for a definitive tool). I would love to see the authors of these tools all working together to develop something even more polished. On Thu, Jun 30, 2011 at 3:49 PM, Milton Silva milton...@gmail.com wrote: The graphs are now in sheet 3 and 4. I could not find a way to enable users to view the summary. -- You 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: Complement to clojure survey
On Jul 1, 1:43 am, Sean Corfield seancorfi...@gmail.com wrote: On Thu, Jun 30, 2011 at 5:37 PM, Milton Silva milton...@gmail.com wrote: I wish that book also had preview chapters like joy of clojure, that would very probably earn it some more early buys. (that was what happened with me in relation to joc) You can buy it in Rough Cuts and it's already had one update since I purchased it (which kinda breaks the feedback comments since they're tied to old page numbers). Sorry, I meant that one of the things that made me buy the MEAP of JOC were the free preview chapters. -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Railo Technologies, Inc. --http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You 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: Complement to clojure survey
At this point there are 69 responses, I think they are enough to draw some conclusions but I'll keep the survey open till later today(to see if we can get around 100 responses). As soon I close it, the results will be available for everyone. On Jun 23, 9:22 pm, Milton Silva milton...@gmail.com wrote: As suggested by Chas Emerick here:http://cemerick.com/2011/06/15/the-2011-state-of-clojure-survey-is-op... I've created the followingsurvey: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFFJTTZW... -- You 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
Complement to clojure survey
As suggested by Chas Emerick here: http://cemerick.com/2011/06/15/the-2011-state-of-clojure-survey-is-open/#comments I've created the following survey: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFFJTTZWT2lXR1N1dTJTWk5mdjZXZlE6MQ -- You 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: Complement to clojure survey
done ;) btw, why do you find it useful to use more than one? or is it a necessity? On Jun 23, 9:44 pm, Aaron Bedra aaron.be...@gmail.com wrote: On 06/23/2011 04:22 PM, Milton Silva wrote: As suggested by Chas Emerick here: http://cemerick.com/2011/06/15/the-2011-state-of-clojure-survey-is-op... I've created the following survey: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFFJTTZW... Can you make the build tools a checkbox list? I use more than one :) -- You 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
