Re: hash of 0 and nil

[Christian Sperandio]

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

[Marko Topolnik]

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  >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
>> > 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.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=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.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=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

[Max Weber]

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  library. You should read
Prismatic's blog
postabout
Graph to get an idea what benefits you can leverage if you use this
fine-grained, composable abstraction
(FCA).
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

[Giuliani Sanches]

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

[travis vachon]

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

[vemv]

>
> "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 , 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

[Kyle R. Burton]

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?

[ulsa]

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 
> > 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 wrote:
>>>

 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=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.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=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?

[ulsa]

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?

[ulsa]

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?

[ulsa]

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 > 
> 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?

[Dima Sabanin]

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

[Christian Sperandio]

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 
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

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




--
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

[Stathis Sideris]

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 > 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
>> 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=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

[Marshall Bockrath-Vandegrift]

"Wm. Josiah Erikson"  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

[Christian Sperandio]

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
> 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

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=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?

[Lee Spector]

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

[Lee Spector]

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

[Marshall Bockrath-Vandegrift]

Lee Spector  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

[Meikel Brandmeyer]

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

[Stuart Sierra]

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