Re: hash of 0 and nil
I write again my post because the previous was bad written and I want to respect the Englis language the more as I can. With your question, I'm feeling you think each item has a different hash code. But it's wrong. You can meet collisions. An hash code is not an id, it's a way to find an element. So even if it's weird to have the same hash code for 0 and nil, this case is useful because it's shown you a case of collisions. Le jeudi 20 décembre 2012 19:04:06 UTC+1, Stathis Sideris a écrit : Hello, I noticed the following: (hash 0) 0 (hash nil) 0 Which is fair enough I suppose. It seems to have the following side-effect though: (hash [1 2 3 0]) 955327 (hash [1 2 3 nil]) 955327 Is that the intended behaviour? I suppose it's OK for two things to hash to the same value, but IMHO, it would make the hash function more useful to avoid this simple case. The implementation seems to check for nil specifically and to return 0. Thanks, Stathis -- You 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: Maps, keywords, and functions
Another common use case: leveraging the thrush operator.
(- odd-coll :foo :bar :baz)
On Friday, December 21, 2012 12:57:15 AM UTC+1, tbc++ wrote:
I use them sometimes in transversing deep maps:
(def odd-coll [{:foo {:bar {:baz 42}}}
{:foo {:bar {:baz 43}}}])
(def find-it (comp :baz :bar :foo))
(map find-it odd-coll)
; [42 43]
On Thu, Dec 20, 2012 at 4:41 PM, Dave Ray dav...@gmail.com
javascript:wrote:
You can avoid superfluous anonymous functions. For example, this:
(map #(get % :id) my-sequence)
vs this:
(map :id my-sequence)
Cheers,
Dave
On Thu, Dec 20, 2012 at 3:13 PM, Jonathon McKitrick
jmcki...@gmail.com javascript: wrote:
I thought it was pretty interesting to treat maps as functions, and even
more intrigued at treating keywords as functions as well.
What does this gain from a language design perspective, that you cannot
get
with (get map keyword) or ever (map keyword)? Why the additional
option of
(keyword map) ?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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 clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
You 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
[ANN] Process a library inspired by the core idea of Prismatic's Graph
Hi, process is another library inspired by the core idea of Prismatic's Graph. For that reason it also has a lot of goals in common with Stuart Sierra's Flow https://github.com/stuartsierra/flow library. You should read Prismatic's blog posthttp://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop.htmlabout Graph to get an idea what benefits you can leverage if you use this fine-grained, composable abstraction (FCAhttp://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html). Since Graph is not open source yet we have built the process library to split up some complex event processing into simple parts. Take a look at the library: https://github.com/doo/process Best regards Max -- You 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
Differences between data.csv and clojure-csv
Hi. I need to parse a csv data and want to know what are the main diferences beetwen these two libraries. If you have used them, please, share your experiences. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Maps, keywords, and functions
Having both options available also allows you to make NullPointerException-averse decisions as appropriate. That is, in this function: (defn foo [a-map] (a-map :foo)) I'm potentially exposed to an NPE if the given map is nil. By rewriting it: (defn foo [a-map] (:foo a-map)) I avoid this possibility, and the function returns nil even when a-map is nil. The reverse is also frequently useful. On Thursday, December 20, 2012 6:13:23 PM UTC-5, Jonathon McKitrick wrote: I thought it was pretty interesting to treat maps as functions, and even more intrigued at treating keywords as functions as well. What does this gain from a language design perspective, that you cannot get with (get map keyword) or ever (map keyword)? Why the additional option of (keyword map) ? -- You 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
Conflation and objectivity
One man's composition is another's conflation - someone on Twitter I don't necessarily agree with the opening quote, but I thought it was an interesting one :) It is not uncommon to hear/read from the Clojure commmunity that X complects a with b, hence X is bad, without giving further explanation. While I immensely acknowledge the framework of thought Rich has gave us with SME http://www.infoq.com/presentations/Simple-Made-Easy, I feel that his message wasn't 100% simple, so it can be easy to mistake it for subtly different ideas. My problem with X complects a with b is that if you don't say *why/how*are a and b complected, they could just as well be composed instead. Recall from Rich's talk that complexity and cardinality are orthogonal: neither a fn that does N things or N fns that do one thing necessarily constitute a complex/simple design. Aspects that *do* distinguish complection from composition include interleavings, dependencies, and inconsistencies (all of them mentioned in * SME*). A common theme to them is that they all contribute to blurring identity: telling one functionality from the other in a given system becomes harder. In my opinion, if we want to keep objectivity, which is part of the point of simplicity, enumerating the aspects that we deem 'complected' is not enough. So if you agree with me, please next time you take on this topic don't forget to make clear where do the complexities lie. Thanks for reading - Victor -- You 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
Looking for ideas for a hack-night to contribute back
All, We run a Clojure group out of our company's office. We want to put together a hack night where we work on something meaningful. To that end I thought I'd put that question to the wider community: what could be valuable to the community for us to work on? The group has a pretty varied amount of experience, some of us use Clojure every day, some are new to it. Regards, Kyle -- Twitter: @kyleburton Github: https://github.com/kyleburton Blog: http://asymmetrical-view.com/ Fun: http://snapclean.me/ -- You 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 to structure a Clojure day for noobs?
I used an early version of Clooj in a workshop some time ago, but got burned by some bug that rendered the REPL crazy and shredding people's code. That scared me away. Probably much better now, though. On Wednesday, 19 December 2012 20:38:05 UTC+1, Nando Breiter wrote: What about Clooj? http://dev.clojure.org/display/doc/getting+started+with+Clooj Is it too buggy, or lacking in features, to start out with? On Tue, Dec 18, 2012 at 11:27 AM, ulsa ulrik.s...@gmail.com javascript: wrote: Good point. I really would like themselves to be able to set up their own environment. I think it gives them a sense of control. However, as a fallback, it would be great with a virtual machine with everything working. I'll consider that. I believe you can get a similar level of interactivity in both IntelliJ and Eclipse, but I agree that Emacs is still the master. On Tuesday, 18 December 2012 04:31:32 UTC+1, Peter wrote: 1. install Leiningen and learn the basics 2. get everyone an editing environment, with the option of using either Emacs, IntelliJ, or Eclipse I would have people do this in advance, or provide a canned environment that has a better chance of just working. There's decent odds that these two steps will eat up a bunch of your time and leave people feeling left out when their install/editor/integration is not quite right. Personally I found the C-x-e of evaluating an s-exp in emacs to be the magic that makes clojure a bajillionty times better than any other programming language, so I'm partial to something like the emacs starter kit. But something like labrepl or eclipse+counterclockwise might be easier for people to start with. On Mon, Dec 17, 2012 at 3:26 AM, Marko Topolnik marko.t...@gmail.comwrote: I think, however, that there is a risk of a disconnect, where newcomers don't really grasp that there is a JVM running and that code is actually compiled and injected into it, and that it's for real. They are used to mickey mouse interactive tools that don't provide the real thing, and struggle to bridge the apparent gap between running code in the REPL and properly compiling and running files. There is no gap, but one needs to explain that, I think. I think this is a pivot point for everything in Clojure. The harder the mental switch, the more important to make it right away. Without understanding that, it will be very hard to maintain a clear picture of how everything fits together, especially when you start changing functions and reloading them. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en -- The king’s heart is like a stream of water directed by the Lord; He guides it wherever He pleases. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Nando Breiter *Aria Media via Rompada 40 6987 Caslano Switzerland * -- You 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 to structure a Clojure day for noobs?
I have used the isBlank example in presentations. It's not a bad starting point. Might look at how it could be used in a workshop. Thanks. On Thursday, 20 December 2012 17:16:19 UTC+1, Thomas wrote: If you need to touch on the why of Clojure I found the example in the beginning Stuart Halloways book quite a good one. the isBlank in Java and the one line blank? equivalent in Clojure. Show them the Java, talk it through with them and then highlight some of its downsides (multiple if statements, the loop, local variables, the fact that the two statements in the first if with can only be ordered in that way etc). and then show them the clojure code, talk them through that and show them what it better (even if functionally completely equivalent) about it. just a thought, Thomas -- You 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 to structure a Clojure day for noobs?
I also suspect that the IDE is important. These guys are experienced people, and I think that once they have an environment that works and they have some control over, they will have a foundation. I think they need and want to know how namespaces work, so that they can see how to modularize code. Then again, Brian's view that the REPL can be the basis for a whole book is also compelling. I must choose a path here. My hope is that, given a whole day, I can spend some time on the environment issue and still hopefully have time for both some basics and also an end-to-end example, even if it's just a tiny little web app. The plan is to give them a sense of controlling the process from the IDE, setting up a project, incrementally building it using the IDE, and then deploying it in the cloud. There are probably millions of good ways to structure such a workshop. What I'm trying to express in these posts is the lack of seeing a clear way through the features: what to start with, what to elaborate on so that they don't get too puzzled on the way to the next feature, and what to end with so that they get a sense of achievement. On Friday, 21 December 2012 03:55:46 UTC+1, Seth Chandler wrote: I would spend A LOT of time on working with the IDE be it Eclipse/Counterclockwise, IntelliJ or whatever. In my limited experience the main impediment to Clojure is not Clojure itself, which is very sensible, but in dealing with file locations, dependency management, projects, Leiningen, all of which are -- with due respect -- very difficult, particularly for people not coming from an Eclipse or similar background. Once you have the confidence that comes with understanding your IDE, you can learn Clojure by playing and by reading idiomatic code. Until then, however, Clojure development can be VERY frustrating . Maybe this will all go away once we have better IDEs (LightTable, Session) full developed, but until then don't just assume that people understand the IDE. On Saturday, December 15, 2012 4:13:21 PM UTC-6, ulsa wrote: In a couple of months, I'll have a whole day of teaching Clojure to ten of my colleagues. They are experienced Java programmers, but otherwise Clojure rookies. Any tips on how to structure such a workshop day? -- You 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 to structure a Clojure day for noobs?
This is good advice. I think you can cover a lot of ground using this
approach, which I guess you need to do when writing a book.
As I mentioned in another post, I believe I have to choose between covering
a lot of ground and building them a foundation that they can experiment on
further.
On Friday, 21 December 2012 04:14:41 UTC+1, Brian Marick wrote:
On Dec 20, 2012, at 8:55 PM, Seth Chandler chandl...@gmail.comjavascript:
wrote:
but in dealing with file locations, dependency management, projects,
Leiningen, all of which are -- with due respect -- very difficult,
particularly for people not coming from an Eclipse or similar background.
In my book, I decided to have everyone work at the repl, using only
cutting-and-pasting or `load-file`. It's a 325-page book that never talks
about namespaces or the `ns` macro.
The beginning instructions about how to do the exercises looks like this:
You can copy and paste Clojure text into
the repl. It handles multiple lines just fine.
[… a note about possible glitches when copying from a PDF]
If you want to
use a Clojure command to load a file like (for example)
`solutions/add-and-make.clj`,
use this:
{:lang=clojure}
~~
user (load-file solutions/add-and-make.clj)
~~
*Warning*: I'm used to using `load` in other languages, so I
often reflexively use it instead of `load-file`. That leads
to this
puzzling message:
{:lang=clojure}
~~
user= (load sources/without-class-class.clj)
FileNotFoundException Could not locate sources/without-class-class.
clj__init.class or sources/without-class-class.clj.clj on classpath:
clojure.lang.RT.load (RT.java:432)
~~
The clue to my mistake is the .clj.clj on the next-to-last line.
These instructions seem to work well for my readers.
Occasional consulting on programming technique
Contract programming in Ruby and Clojure
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo
--
You 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: Who's using Clojure?
How do we get ourselves to the list? We rely on Clojure heavily at http://beanstalkapp.com and we're working on rewriting even more critical pieces of our infrastructure in Clojure. I tried to edit the page, but it's locked. -- Best regards, Dima Sabanin http://twitter.com/dimasabanin -- You 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 of 0 and nil
In this case, a good question could be are 0 and nil the same?
In some languages like C or C++, NULL and 0 are the same (at least, for
x86 Intel architecture, I don't know for others). You find some old code
where you have ptr == 0 instead of ptr == NULL. And often, you have test
for pointers like if (ptr) { }.
Perhaps a study of JVM would tell what is null.
On 12/21/2012 09:10 PM, nicolas.o...@gmail.com wrote:
I think the intial post was not about the fact that collision was a
problem but about the fact that 0 and nil are frequent elements, so using
the same hash (if there is no good reason) would result in many
useless collisions.
However, there might be a good reason to have nil and 0 having the
same hash.
(nil must probably have a hash equal to '() for example)
On Fri, Dec 21, 2012 at 9:05 AM, Christian Sperandio
christian.speran...@gmail.com mailto:christian.speran...@gmail.com
wrote:
I write again my post because the previous was bad written and I
want to respect the Englis language the more as I can.
With your question, I'm feeling you think each item has a
different hash code. But it's wrong. You can meet collisions.
An hash code is not an id, it's a way to find an element.
So even if it's weird to have the same hash code for 0 and nil,
this case is useful because it's shown you a case of collisions.
Le jeudi 20 décembre 2012 19:04:06 UTC+1, Stathis Sideris a écrit :
Hello,
I noticed the following:
(hash 0)
0
(hash nil)
0
Which is fair enough I suppose. It seems to have the following
side-effect though:
(hash [1 2 3 0])
955327
(hash [1 2 3 nil])
955327
Is that the intended behaviour? I suppose it's OK for two
things to hash to the same value, but IMHO, it would make the
hash function more useful to avoid this simple case. The
implementation seems to check for nil specifically and to
return 0.
Thanks,
Stathis
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
mailto: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
mailto:clojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
Sent from an IBM Model M, 15 August 1989.
--
You 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 of 0 and nil
Yes that's exactly what I meant, sorry I think I didn't express it very well. Of course I know about hash collissions, but (maybe mistakenly) I always thought that they happened in relatively rare cases. Interestingly, '() has a hash of 1 which is the same as the hash of integer 1! On Friday, 21 December 2012 20:10:07 UTC, Nicolas Oury wrote: I think the intial post was not about the fact that collision was a problem but about the fact that 0 and nil are frequent elements, so using the same hash (if there is no good reason) would result in many useless collisions. However, there might be a good reason to have nil and 0 having the same hash. (nil must probably have a hash equal to '() for example) On Fri, Dec 21, 2012 at 9:05 AM, Christian Sperandio christian...@gmail.com javascript: wrote: I write again my post because the previous was bad written and I want to respect the Englis language the more as I can. With your question, I'm feeling you think each item has a different hash code. But it's wrong. You can meet collisions. An hash code is not an id, it's a way to find an element. So even if it's weird to have the same hash code for 0 and nil, this case is useful because it's shown you a case of collisions. Le jeudi 20 décembre 2012 19:04:06 UTC+1, Stathis Sideris a écrit : Hello, I noticed the following: (hash 0) 0 (hash nil) 0 Which is fair enough I suppose. It seems to have the following side-effect though: (hash [1 2 3 0]) 955327 (hash [1 2 3 nil]) 955327 Is that the intended behaviour? I suppose it's OK for two things to hash to the same value, but IMHO, it would make the hash function more useful to avoid this simple case. The implementation seems to check for nil specifically and to return 0. Thanks, Stathis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Sent from an IBM Model M, 15 August 1989. -- You 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: abysmal multicore performance, especially on AMD processors
Wm. Josiah Erikson wmjos...@gmail.com writes: I hope this helps people get to the bottom of things. Not to the bottom of things yet, but found some low-hanging fruit – switching the `push-state` from a struct-map to a record gives a flat ~2x speedup in all configurations I tested. So, that’s good? I have however eliminated to my satisfaction the possibility that this is something orthogonal to your system. I do see some speedup improvements when I lower the level of concurrency to the number of actual physical cores on my system, but each call to the `error-function` still takes ~10x as long to complete when run in parallel vs in serial. For a while I had some hope that atom-access in the main interpreter loop was the problem, due to causing extraneous fetches to main memory. But removing all the atoms from the system didn’t have any appreciable impact. Anyway, still poking at it. -Marshall -- You 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 of 0 and nil
The rarity about the hash code depend essentially how it is computed. On a project, the string hash codes have been the 2 first letters. On 12/21/2012 11:04 PM, Stathis Sideris wrote: Yes that's exactly what I meant, sorry I think I didn't express it very well. Of course I know about hash collissions, but (maybe mistakenly) I always thought that they happened in relatively rare cases. Interestingly, '() has a hash of 1 which is the same as the hash of integer 1! On Friday, 21 December 2012 20:10:07 UTC, Nicolas Oury wrote: I think the intial post was not about the fact that collision was a problem but about the fact that 0 and nil are frequent elements, so using the same hash (if there is no good reason) would result in many useless collisions. However, there might be a good reason to have nil and 0 having the same hash. (nil must probably have a hash equal to '() for example) On Fri, Dec 21, 2012 at 9:05 AM, Christian Sperandio christian...@gmail.com javascript: wrote: I write again my post because the previous was bad written and I want to respect the Englis language the more as I can. With your question, I'm feeling you think each item has a different hash code. But it's wrong. You can meet collisions. An hash code is not an id, it's a way to find an element. So even if it's weird to have the same hash code for 0 and nil, this case is useful because it's shown you a case of collisions. Le jeudi 20 décembre 2012 19:04:06 UTC+1, Stathis Sideris a écrit : Hello, I noticed the following: (hash 0) 0 (hash nil) 0 Which is fair enough I suppose. It seems to have the following side-effect though: (hash [1 2 3 0]) 955327 (hash [1 2 3 nil]) 955327 Is that the intended behaviour? I suppose it's OK for two things to hash to the same value, but IMHO, it would make the hash function more useful to avoid this simple case. The implementation seems to check for nil specifically and to return 0. Thanks, Stathis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en -- Sent from an IBM Model M, 15 August 1989. -- You 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 to structure a Clojure day for noobs?
On Dec 21, 2012, at 2:27 PM, ulsa wrote: I used an early version of Clooj in a workshop some time ago, but got burned by some bug that rendered the REPL crazy and shredding people's code. That scared me away. Probably much better now, though. I've taught a couple of courses using clooj and I think it's nearly optimal for some categories of noobs and some non-noobs too (like me, much of the time). For me it has an essential combination of features that I can't find together elsewhere: one-click, idiot-proof installation, native and un-mysterious GUI that doesn't require special training, REPL, bracket matching, automatic code indenting, autocompletion, doc-string access, arglist-on-space, and leiningen compatibility (but it's not integrated). There are a few things that it doesn't have that I wish that it did -- especially stuff related to debugging -- but for me the tradeoffs are worth it. However, it's true that it's not very actively maintained and that it currently has some problems. I don't think that the author has a lot of spare time for it these days. But I think that anyone can contribute and if anyone out there has the skill set and time to contribute to a project then I think this would be a worthy target... -Lee -- You 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: abysmal multicore performance, especially on AMD processors
On Dec 21, 2012, at 5:22 PM, Marshall Bockrath-Vandegrift wrote: Not to the bottom of things yet, but found some low-hanging fruit – switching the `push-state` from a struct-map to a record gives a flat ~2x speedup in all configurations I tested. So, that’s good? I really appreciate your attention to this Marshall. FWIW I used records for push-states at one point but did not observe a speedup and it required much messier code, so I reverted to struct-maps. But maybe I wasn't doing the right timings. I'm curious about how you changed to records without the messiness. I'll include below my sig the way that I had to do it... maybe you can show me what you did instead. Still, I guess the gorilla in the room, which is eating the multicore performance, hasn't yet been found. -Lee --- tl;dr: the structs vs. records thing --- Here's how I do what I need to do with struct-maps: ;; this is defined elsewhere, and I want push-states to have fields for each push-type that's defined here (def push-types '(:exec :integer :float :code :boolean :string :zip :tag :auxiliary :return :environment) ;; so I use a macro to produce the struct-map definition (defmacro define-push-state-structure [] `(defstruct push-state ~@push-types)) ;; call the macro to define the struct (define-push-state-structure) ;; and then when I want a new push-state I can just call struct-map: (defn make-push-state Returns an empty push state. [] (struct-map push-state)) In order to do the same thing with records I had to resort to this: (defn keyword-symbol [kwd] Returns the symbol obtained by removing the : from a keyword. (read-string (name kwd))) (defmacro define-push-state-record-type [] Defines the pushstate record type. The odd trick with read-string was a hack to avoid namespace qualification on the pushstate symbol. `(defrecord ~(read-string pushstate) [~@(map keyword-symbol push-types)])) (define-push-state-record-type) (defmacro make-push-state Returns an empty push state. [] `(pushstate. ~@(map (fn [_] nil) push-types))) Is there a much simpler way that I overlooked? -- You 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: abysmal multicore performance, especially on AMD processors
Lee Spector lspec...@hampshire.edu writes:
FWIW I used records for push-states at one point but did not observe a
speedup and it required much messier code, so I reverted to
struct-maps. But maybe I wasn't doing the right timings. I'm curious
about how you changed to records without the messiness. I'll include
below my sig the way that I had to do it... maybe you can show me what
you did instead.
I just double-checked, and I definitely see a 2x speedup on Josiah’s
benchmark. That may still be synthetic, of course. Here’s what I did:
(eval `(defrecord ~'PushState [~'trace ~@(map (comp symbol name)
push-types)]))
(let [empty-state (map-PushState {})]
(defn make-push-state
Returns an empty push state.
[] empty-state))
Still, I guess the gorilla in the room, which is eating the multicore
performance, hasn't yet been found.
No, not yet... I’ve become obsessed with figuring it out though, so
still slogging at it.
-Marshall
--
You 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: abysmal multicore performance, especially on AMD processors
Hi,
Am 22.12.12 00:37, schrieb Lee Spector:
;; this is defined elsewhere, and I want push-states to have fields for each
push-type that's defined here
(def push-types '(:exec :integer :float :code :boolean :string :zip
:tag :auxiliary :return :environment)
(defn keyword-symbol [kwd]
Returns the symbol obtained by removing the : from a keyword.
(read-string (name kwd)))
I'm afraid this one is still necessary, but I would use symbol instead
of read-string.
(defmacro define-push-state-record-type []
Defines the pushstate record type. The odd trick with read-string was a
hack to
avoid namespace qualification on the pushstate symbol.
`(defrecord ~(read-string pushstate) [~@(map keyword-symbol
push-types)]))
Use ~'pushstate instead of read-string.
(define-push-state-record-type)
(defmacro make-push-state
Returns an empty push state.
[]
`(pushstate. ~@(map (fn [_] nil) push-types)))
Use this:
(defn make-push-state
[]
(map-pushstate {}))
Is there a much simpler way that I overlooked?
I'm not sure it's simpler, but it's more straight-forward, I'd say.
Kind regards
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: [ANN] tools.namespace 0.2.2 and Flow 0.1.0
On Tuesday, December 18, 2012 1:02:55 AM UTC-5, Mikera wrote: Re: tools.namespace, I've found some similar functions in the bultitude library (https://github.com/Raynes/bultitude/tree/master/src/bultitude). Apparently it addresses specific needs that clojure.tools.namespace did not provide. Is one of these recommended over the other, or is there a plan to merge these so that we get the best of both? Use whichever you find most useful. Merging them would not be trivial because Bultitude is not covered by the Clojure Contributor Agreement. tools.namespace 0.2.0 was a significant rewrite with a lot of new functionality. The 0.2.1 release restored backwards-compatibility with 0.1.x versions. TNS-1 was very specific to a particular Leiningen plugin and old Clojure release. For that reason, I resisted it for several months until it became clear to me how many already-released libraries were affected. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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
