[ANN] New Clojure Podcast: defn

[Vijay Kiran]

Hello Everyone,

Just wanted to let you know that we started a new podcast about Clojure: 
https://defn.audio

We published our first episode and plan to release a new one every two 
weeks. It is available on iTunes 
https://itunes.apple.com/podcast/defn/id1114899563 and SoundCloud: 
https://soundcloud.com/defn-771544745

You can also get the RSS feed via 
http://feeds.soundcloud.com/users/soundcloud:users:220484243/sounds.rss

We'd appreciate if you can tune in and give us some feedback!

Thanks for listening,
Vijay & Ray

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

Re: Is java.lang.Class not a dependable map key?

[JvJ]

I think I will do something like this.  Maybe instead of converting the 
class name to a keyword, I'll just make a separate protocol IComponent or 
something, that has a component-type function that returns a constant 
keyword determined by the macro at compile time...

On Wednesday, 18 May 2016 15:50:21 UTC-7, tbc++ wrote:
>
> Well, if you store it in metadata you'll have to look it up in the 
> metadata which is a hashmap lookup. As a method on a class it's a method 
> call that returns a constant. 
>
> On Wed, May 18, 2016 at 3:12 PM, JvJ  
> wrote:
>
>> Will it be much better than type metadata, though?
>>
>> On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote:
>>>
>>> Or define components to have a member called (name-as-kw [this]) 
>>> returning a keyword version of the name of the type. 
>>>
>>> On Wed, May 18, 2016 at 1:31 PM, James Reeves  
>>> wrote:
>>>
 Why not use the name of the class as the key?

 - James

 On 18 May 2016 at 20:02, JvJ  wrote:

> I'm creating an entity-component-system architecture.  To use it, you 
> define component types, and put a bunch of components in a map to make an 
> entity.
>
> The rule for entities is that they can only have one component of any 
> given type, so I figured I would use the class to index it.  However, 
> since 
> this doesn't seem possible,
> I think I'll just make my own "defcomponent" macro which acts almost 
> like defrecord, but makes sure that the constructor associates an 
> appropriate keyword type tag
> in the metadata.
>
> Looking up the metadata is slightly slower than normal type 
> reflection, but I doubt it will make much of a difference.
>
> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>>
>> I don't think there's a general workaround, and I'm not sure I have 
>> enough context to know what you are doing specifically.
>>
>> On Wed, May 18, 2016 at 2:28 PM, JvJ  wrote:
>>
>>> I suspected as much.  It would be possible to mitigate the problem 
>>> by not using the repl, but I want the library I'm making to be built 
>>> around 
>>> a repl-oriented workflow (like every good clojure library should).
>>>
>>> Is there any way around this, or do I have to resort to :type 
>>> metadata?
>>>
>>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:

 When you reload a namespace with a record, the class for that 
 record gets recreated.  It will be functionally equivalent, but a 
 different 
 object.  I'll bet that classes hash on identity.  (Though if they 
 hashed on 
 name, you'd still have this problem.)

 On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:

> I'm encountering a very strange error in some tests.
>
> The details are a bit complex, but I'm using type-indexed maps.
>
> So, given an object o, the map would be {(type o) o}.  When I try 
> to lookup with the key (type o), I don't get the value, even though I 
> can 
> clearly see it in the map.
>
>
> I have a map instance called new-still in my tests, and I can 
> clearly see that this is its value
>
> {specs.core_test.Position {:x 0, :y 0}}
>
>
> However, when I try to compare the first key to the Position class 
> (which it should be), I get this:
>
>
> Fail in run-systems-tst
> expected: (= (first (keys new-still)) Position)
>   actual: (not (= specs.core_test.Position 
> specs.core_test.Position))
>
>
>
> How is it that the class specs.core_test.Position is not equal to 
> itself??
> Is this a bug, or just some quirk of compilation?
>
> Thanks. 
>
> -- 
> 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 unsubscribe from this group and stop receiving emails from it, 
> send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 -- 
>>> You received this message because you are subscribed to the 

Re: Is java.lang.Class not a dependable map key?

[Timothy Baldridge]

Well, if you store it in metadata you'll have to look it up in the metadata
which is a hashmap lookup. As a method on a class it's a method call that
returns a constant.

On Wed, May 18, 2016 at 3:12 PM, JvJ  wrote:

> Will it be much better than type metadata, though?
>
> On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote:
>>
>> Or define components to have a member called (name-as-kw [this])
>> returning a keyword version of the name of the type.
>>
>> On Wed, May 18, 2016 at 1:31 PM, James Reeves 
>> wrote:
>>
>>> Why not use the name of the class as the key?
>>>
>>> - James
>>>
>>> On 18 May 2016 at 20:02, JvJ  wrote:
>>>
 I'm creating an entity-component-system architecture.  To use it, you
 define component types, and put a bunch of components in a map to make an
 entity.

 The rule for entities is that they can only have one component of any
 given type, so I figured I would use the class to index it.  However, since
 this doesn't seem possible,
 I think I'll just make my own "defcomponent" macro which acts almost
 like defrecord, but makes sure that the constructor associates an
 appropriate keyword type tag
 in the metadata.

 Looking up the metadata is slightly slower than normal type reflection,
 but I doubt it will make much of a difference.

 On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>
> I don't think there's a general workaround, and I'm not sure I have
> enough context to know what you are doing specifically.
>
> On Wed, May 18, 2016 at 2:28 PM, JvJ  wrote:
>
>> I suspected as much.  It would be possible to mitigate the problem by
>> not using the repl, but I want the library I'm making to be built around 
>> a
>> repl-oriented workflow (like every good clojure library should).
>>
>> Is there any way around this, or do I have to resort to :type
>> metadata?
>>
>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>>
>>> When you reload a namespace with a record, the class for that record
>>> gets recreated.  It will be functionally equivalent, but a different
>>> object.  I'll bet that classes hash on identity.  (Though if they 
>>> hashed on
>>> name, you'd still have this problem.)
>>>
>>> On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:
>>>
 I'm encountering a very strange error in some tests.

 The details are a bit complex, but I'm using type-indexed maps.

 So, given an object o, the map would be {(type o) o}.  When I try
 to lookup with the key (type o), I don't get the value, even though I 
 can
 clearly see it in the map.


 I have a map instance called new-still in my tests, and I can
 clearly see that this is its value

 {specs.core_test.Position {:x 0, :y 0}}


 However, when I try to compare the first key to the Position class
 (which it should be), I get this:


 Fail in run-systems-tst
 expected: (= (first (keys new-still)) Position)
   actual: (not (= specs.core_test.Position
 specs.core_test.Position))



 How is it that the class specs.core_test.Position is not equal to
 itself??
 Is this a bug, or just some quirk of compilation?

 Thanks.

 --
 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 unsubscribe from this group and stop receiving emails from it,
 send an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: Is java.lang.Class not a dependable map key?

[JvJ]

Will it be much better than type metadata, though?

On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote:
>
> Or define components to have a member called (name-as-kw [this]) returning 
> a keyword version of the name of the type. 
>
> On Wed, May 18, 2016 at 1:31 PM, James Reeves  > wrote:
>
>> Why not use the name of the class as the key?
>>
>> - James
>>
>> On 18 May 2016 at 20:02, JvJ  wrote:
>>
>>> I'm creating an entity-component-system architecture.  To use it, you 
>>> define component types, and put a bunch of components in a map to make an 
>>> entity.
>>>
>>> The rule for entities is that they can only have one component of any 
>>> given type, so I figured I would use the class to index it.  However, since 
>>> this doesn't seem possible,
>>> I think I'll just make my own "defcomponent" macro which acts almost 
>>> like defrecord, but makes sure that the constructor associates an 
>>> appropriate keyword type tag
>>> in the metadata.
>>>
>>> Looking up the metadata is slightly slower than normal type reflection, 
>>> but I doubt it will make much of a difference.
>>>
>>> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:

 I don't think there's a general workaround, and I'm not sure I have 
 enough context to know what you are doing specifically.

 On Wed, May 18, 2016 at 2:28 PM, JvJ  wrote:

> I suspected as much.  It would be possible to mitigate the problem by 
> not using the repl, but I want the library I'm making to be built around 
> a 
> repl-oriented workflow (like every good clojure library should).
>
> Is there any way around this, or do I have to resort to :type metadata?
>
> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>
>> When you reload a namespace with a record, the class for that record 
>> gets recreated.  It will be functionally equivalent, but a different 
>> object.  I'll bet that classes hash on identity.  (Though if they hashed 
>> on 
>> name, you'd still have this problem.)
>>
>> On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:
>>
>>> I'm encountering a very strange error in some tests.
>>>
>>> The details are a bit complex, but I'm using type-indexed maps.
>>>
>>> So, given an object o, the map would be {(type o) o}.  When I try to 
>>> lookup with the key (type o), I don't get the value, even though I can 
>>> clearly see it in the map.
>>>
>>>
>>> I have a map instance called new-still in my tests, and I can 
>>> clearly see that this is its value
>>>
>>> {specs.core_test.Position {:x 0, :y 0}}
>>>
>>>
>>> However, when I try to compare the first key to the Position class 
>>> (which it should be), I get this:
>>>
>>>
>>> Fail in run-systems-tst
>>> expected: (= (first (keys new-still)) Position)
>>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>>
>>>
>>>
>>> How is it that the class specs.core_test.Position is not equal to 
>>> itself??
>>> Is this a bug, or just some quirk of compilation?
>>>
>>> Thanks. 
>>>
>>> -- 
>>> 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 unsubscribe from this group and stop receiving emails from it, 
>>> send an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
> 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 unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, 

Re: Is java.lang.Class not a dependable map key?

[Timothy Baldridge]

Or define components to have a member called (name-as-kw [this]) returning
a keyword version of the name of the type.

On Wed, May 18, 2016 at 1:31 PM, James Reeves  wrote:

> Why not use the name of the class as the key?
>
> - James
>
> On 18 May 2016 at 20:02, JvJ  wrote:
>
>> I'm creating an entity-component-system architecture.  To use it, you
>> define component types, and put a bunch of components in a map to make an
>> entity.
>>
>> The rule for entities is that they can only have one component of any
>> given type, so I figured I would use the class to index it.  However, since
>> this doesn't seem possible,
>> I think I'll just make my own "defcomponent" macro which acts almost like
>> defrecord, but makes sure that the constructor associates an appropriate
>> keyword type tag
>> in the metadata.
>>
>> Looking up the metadata is slightly slower than normal type reflection,
>> but I doubt it will make much of a difference.
>>
>> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>>>
>>> I don't think there's a general workaround, and I'm not sure I have
>>> enough context to know what you are doing specifically.
>>>
>>> On Wed, May 18, 2016 at 2:28 PM, JvJ  wrote:
>>>
 I suspected as much.  It would be possible to mitigate the problem by
 not using the repl, but I want the library I'm making to be built around a
 repl-oriented workflow (like every good clojure library should).

 Is there any way around this, or do I have to resort to :type metadata?

 On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>
> When you reload a namespace with a record, the class for that record
> gets recreated.  It will be functionally equivalent, but a different
> object.  I'll bet that classes hash on identity.  (Though if they hashed 
> on
> name, you'd still have this problem.)
>
> On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:
>
>> I'm encountering a very strange error in some tests.
>>
>> The details are a bit complex, but I'm using type-indexed maps.
>>
>> So, given an object o, the map would be {(type o) o}.  When I try to
>> lookup with the key (type o), I don't get the value, even though I can
>> clearly see it in the map.
>>
>>
>> I have a map instance called new-still in my tests, and I can clearly
>> see that this is its value
>>
>> {specs.core_test.Position {:x 0, :y 0}}
>>
>>
>> However, when I try to compare the first key to the Position class
>> (which it should be), I get this:
>>
>>
>> Fail in run-systems-tst
>> expected: (= (first (keys new-still)) Position)
>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>
>>
>>
>> How is it that the class specs.core_test.Position is not equal to
>> itself??
>> Is this a bug, or just some quirk of compilation?
>>
>> Thanks.
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it,
>> send an email to clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
 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 unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: Is java.lang.Class not a dependable map key?

[James Reeves]

Why not use the name of the class as the key?

- James

On 18 May 2016 at 20:02, JvJ  wrote:

> I'm creating an entity-component-system architecture.  To use it, you
> define component types, and put a bunch of components in a map to make an
> entity.
>
> The rule for entities is that they can only have one component of any
> given type, so I figured I would use the class to index it.  However, since
> this doesn't seem possible,
> I think I'll just make my own "defcomponent" macro which acts almost like
> defrecord, but makes sure that the constructor associates an appropriate
> keyword type tag
> in the metadata.
>
> Looking up the metadata is slightly slower than normal type reflection,
> but I doubt it will make much of a difference.
>
> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>>
>> I don't think there's a general workaround, and I'm not sure I have
>> enough context to know what you are doing specifically.
>>
>> On Wed, May 18, 2016 at 2:28 PM, JvJ  wrote:
>>
>>> I suspected as much.  It would be possible to mitigate the problem by
>>> not using the repl, but I want the library I'm making to be built around a
>>> repl-oriented workflow (like every good clojure library should).
>>>
>>> Is there any way around this, or do I have to resort to :type metadata?
>>>
>>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:

 When you reload a namespace with a record, the class for that record
 gets recreated.  It will be functionally equivalent, but a different
 object.  I'll bet that classes hash on identity.  (Though if they hashed on
 name, you'd still have this problem.)

 On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:

> I'm encountering a very strange error in some tests.
>
> The details are a bit complex, but I'm using type-indexed maps.
>
> So, given an object o, the map would be {(type o) o}.  When I try to
> lookup with the key (type o), I don't get the value, even though I can
> clearly see it in the map.
>
>
> I have a map instance called new-still in my tests, and I can clearly
> see that this is its value
>
> {specs.core_test.Position {:x 0, :y 0}}
>
>
> However, when I try to compare the first key to the Position class
> (which it should be), I get this:
>
>
> Fail in run-systems-tst
> expected: (= (first (keys new-still)) Position)
>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>
>
>
> How is it that the class specs.core_test.Position is not equal to
> itself??
> Is this a bug, or just some quirk of compilation?
>
> Thanks.
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 --
>>> 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 unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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.

Re: Is java.lang.Class not a dependable map key?

[JvJ]

I'm creating an entity-component-system architecture.  To use it, you 
define component types, and put a bunch of components in a map to make an 
entity.

The rule for entities is that they can only have one component of any given 
type, so I figured I would use the class to index it.  However, since this 
doesn't seem possible,
I think I'll just make my own "defcomponent" macro which acts almost like 
defrecord, but makes sure that the constructor associates an appropriate 
keyword type tag
in the metadata.

Looking up the metadata is slightly slower than normal type reflection, but 
I doubt it will make much of a difference.

On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>
> I don't think there's a general workaround, and I'm not sure I have enough 
> context to know what you are doing specifically.
>
> On Wed, May 18, 2016 at 2:28 PM, JvJ  
> wrote:
>
>> I suspected as much.  It would be possible to mitigate the problem by not 
>> using the repl, but I want the library I'm making to be built around a 
>> repl-oriented workflow (like every good clojure library should).
>>
>> Is there any way around this, or do I have to resort to :type metadata?
>>
>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>>
>>> When you reload a namespace with a record, the class for that record 
>>> gets recreated.  It will be functionally equivalent, but a different 
>>> object.  I'll bet that classes hash on identity.  (Though if they hashed on 
>>> name, you'd still have this problem.)
>>>
>>> On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:
>>>
 I'm encountering a very strange error in some tests.

 The details are a bit complex, but I'm using type-indexed maps.

 So, given an object o, the map would be {(type o) o}.  When I try to 
 lookup with the key (type o), I don't get the value, even though I can 
 clearly see it in the map.


 I have a map instance called new-still in my tests, and I can clearly 
 see that this is its value

 {specs.core_test.Position {:x 0, :y 0}}


 However, when I try to compare the first key to the Position class 
 (which it should be), I get this:


 Fail in run-systems-tst
 expected: (= (first (keys new-still)) Position)
   actual: (not (= specs.core_test.Position specs.core_test.Position))



 How is it that the class specs.core_test.Position is not equal to 
 itself??
 Is this a bug, or just some quirk of compilation?

 Thanks. 

 -- 
 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 unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Is java.lang.Class not a dependable map key?

[Jason Felice]

I don't think there's a general workaround, and I'm not sure I have enough
context to know what you are doing specifically.

On Wed, May 18, 2016 at 2:28 PM, JvJ  wrote:

> I suspected as much.  It would be possible to mitigate the problem by not
> using the repl, but I want the library I'm making to be built around a
> repl-oriented workflow (like every good clojure library should).
>
> Is there any way around this, or do I have to resort to :type metadata?
>
> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>
>> When you reload a namespace with a record, the class for that record gets
>> recreated.  It will be functionally equivalent, but a different object.
>> I'll bet that classes hash on identity.  (Though if they hashed on name,
>> you'd still have this problem.)
>>
>> On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:
>>
>>> I'm encountering a very strange error in some tests.
>>>
>>> The details are a bit complex, but I'm using type-indexed maps.
>>>
>>> So, given an object o, the map would be {(type o) o}.  When I try to
>>> lookup with the key (type o), I don't get the value, even though I can
>>> clearly see it in the map.
>>>
>>>
>>> I have a map instance called new-still in my tests, and I can clearly
>>> see that this is its value
>>>
>>> {specs.core_test.Position {:x 0, :y 0}}
>>>
>>>
>>> However, when I try to compare the first key to the Position class
>>> (which it should be), I get this:
>>>
>>>
>>> Fail in run-systems-tst
>>> expected: (= (first (keys new-still)) Position)
>>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>>
>>>
>>>
>>> How is it that the class specs.core_test.Position is not equal to
>>> itself??
>>> Is this a bug, or just some quirk of compilation?
>>>
>>> Thanks.
>>>
>>> --
>>> 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 unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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.
>

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

Re: Is java.lang.Class not a dependable map key?

[JvJ]

I suspected as much.  It would be possible to mitigate the problem by not 
using the repl, but I want the library I'm making to be built around a 
repl-oriented workflow (like every good clojure library should).

Is there any way around this, or do I have to resort to :type metadata?

On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>
> When you reload a namespace with a record, the class for that record gets 
> recreated.  It will be functionally equivalent, but a different object.  
> I'll bet that classes hash on identity.  (Though if they hashed on name, 
> you'd still have this problem.)
>
> On Wed, May 18, 2016 at 1:31 PM, JvJ  
> wrote:
>
>> I'm encountering a very strange error in some tests.
>>
>> The details are a bit complex, but I'm using type-indexed maps.
>>
>> So, given an object o, the map would be {(type o) o}.  When I try to 
>> lookup with the key (type o), I don't get the value, even though I can 
>> clearly see it in the map.
>>
>>
>> I have a map instance called new-still in my tests, and I can clearly see 
>> that this is its value
>>
>> {specs.core_test.Position {:x 0, :y 0}}
>>
>>
>> However, when I try to compare the first key to the Position class (which 
>> it should be), I get this:
>>
>>
>> Fail in run-systems-tst
>> expected: (= (first (keys new-still)) Position)
>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>
>>
>>
>> How is it that the class specs.core_test.Position is not equal to itself??
>> Is this a bug, or just some quirk of compilation?
>>
>> Thanks. 
>>
>> -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Is java.lang.Class not a dependable map key?

[Jason Felice]

When you reload a namespace with a record, the class for that record gets
recreated.  It will be functionally equivalent, but a different object.
I'll bet that classes hash on identity.  (Though if they hashed on name,
you'd still have this problem.)

On Wed, May 18, 2016 at 1:31 PM, JvJ  wrote:

> I'm encountering a very strange error in some tests.
>
> The details are a bit complex, but I'm using type-indexed maps.
>
> So, given an object o, the map would be {(type o) o}.  When I try to
> lookup with the key (type o), I don't get the value, even though I can
> clearly see it in the map.
>
>
> I have a map instance called new-still in my tests, and I can clearly see
> that this is its value
>
> {specs.core_test.Position {:x 0, :y 0}}
>
>
> However, when I try to compare the first key to the Position class (which
> it should be), I get this:
>
>
> Fail in run-systems-tst
> expected: (= (first (keys new-still)) Position)
>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>
>
>
> How is it that the class specs.core_test.Position is not equal to itself??
> Is this a bug, or just some quirk of compilation?
>
> 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
> ---
> 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.
>

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

Re: Oxford (UK) Clojure Group

[Kévin Etienne]

Hi,

Just a quick update, we haven't planned a meeting yet but I'm hoping to 
start one soon.
For the moment you can join me on http://slack.digitaloxford.com/ in the 
#clojure channel,
and I'm also on the http://clojurians.net if you are interested to keep in 
touch.

Thanks,
Kevin

On Tuesday, 15 September 2015 22:04:49 UTC+1, Kévin Etienne wrote:
>
> Hi,
>
> I've seen a previous thread 
> https://groups.google.com/forum/#!topic/clojure/dRPF8bEpjBE
> where a Clojure group in Oxford was mentioned. I don't know what happened 
> to Oxjure but
> I'm interested in running a group and meeting people around Clojure and 
> more extensively
> LISP. I've been to a Clojure in London and really enjoyed a few years ago.
>
> Let me know if you're around and if want to meet. At the moment I'm trying 
> to see if there's
> enough traction and see what we can do.
>
> Thanks,
> Kevin 
>

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