Re: What's up with IMeta?

2017-11-02 Thread Didier 
Okay, I can see how I can maybe infer some of that by piecing together the code 
base, but if there was a book, or a reference somewhere describing more the 
implementation of Clojure itself I'd be interested to read it, if there is one 
out there. I'd understand if there's not, I know Clojure has no formal semantic 
spec.

Also, I guess I'm still confused about that bit:

> That said, metadata and its relationship to an object is immutable - an 
> object with different metadata is a different object. One consequence of this 
> is that applying metadata to a lazy sequence will realize the head of the 
> sequence so that both objects can share the same sequence.

-- 
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: What's up with IMeta?

2017-11-02 Thread James Reeves 
On 3 November 2017 at 02:31, Didier  wrote:

> Wow, thanks. Is that all tribal knowledge? Or is there some documentation
> around the Clojure interfaces and their semantics somewhere I could read?
> Maybe even a Clojure book recommendation that covers this?
>

Each of the internal methods corresponds to an public function:

  IMeta.meta => clojure.core/meta
  IObj.withMeta  => clojure.core/with-meta
  IRef.alterMeta => clojure.core/alter-meta!
  IRef.resetMeta => clojure.core/reset-meta!

So in the case of the metadata interfaces, it's pretty straightforward to
figure out what they do by reading the API docs.


> So if I understand correctly, withMeta will return a new object which is
> not equal to the old. So two immutable objects implementing IObj which
> differ only in meta are not equal. But this is a convention, in that if I
> implement IMeta myself, I should also override equals so that it returns
> false when meta differs correct?
>

Metadata doesn't affect equality (see the docs on metadata
), so even though the object
*identity* will differ when you use with-meta, they will be considered to
be equal:

  user=> (def m1 {:a 1})
  #'user/m1
  user=> (def m2 (with-meta m1 {:x 2}))
  #'user/m2
  user=> (= m1 m2)
  true
  user=> (identical? m1 m2)
  false

-- 
James Reeves
booleanknot.com

-- 
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: What's up with IMeta?

2017-11-02 Thread Didier 
Wow, thanks. Is that all tribal knowledge? Or is there some documentation 
around the Clojure interfaces and their semantics somewhere I could read? Maybe 
even a Clojure book recommendation that covers this?

So if I understand correctly, withMeta will return a new object which is not 
equal to the old. So two immutable objects implementing IObj which differ only 
in meta are not equal. But this is a convention, in that if I implement IMeta 
myself, I should also override equals so that it returns false when meta 
differs correct?

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

New Clojure Job Board

2017-11-02 Thread Ertuğrul Çetin 
Hi Everyone,

I've created a new Clojure Job Board 
 on Clojurecademy. I hope it's 
going to be useful for both companies and Clojure developers!

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.

Re: [ANN] Clojure 1.9.0-beta4

2017-11-02 Thread Peter Hull 
On Thursday, 2 November 2017 19:46:35 UTC, Alex Miller wrote:
>
> I think this is an issue with Leiningen with Java 1.9 (re things in 
> dynapath and the changes in classloader details in Java 1.9), and not 
> Clojure itself. 
>
> Yes this was leiningen issue #2331 now fixed:
https://github.com/technomancy/leiningen/issues/2331

-- 
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: [ANN] Clojure 1.9.0-beta4

2017-11-02 Thread Alex Miller 
I think this is an issue with Leiningen with Java 1.9 (re things in
dynapath and the changes in classloader details in Java 1.9), and not
Clojure itself.

On Thu, Nov 2, 2017 at 2:31 PM, Andy Fingerhut 
wrote:

> Alan, I get similar messages when starting 'lein repl' with this
> combination of versions:
> + Leiningen version 2.8.0, Clojure 1.8.0, Java 9.0.1 (note - No Clojure
> 1.9.0 involved)
>
> Changing only the Leiningen to version 2.8.1 and there is no such error
> message.
>
> Andy
>
> On Thu, Nov 2, 2017 at 11:29 AM, Alan Thompson  wrote:
>
>> Hi.  1.9.0-beta4 works great for the Tupelo library on java 1.8, but I
>> get the following warnings using Java 9.0.1:
>>
>> ​WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by dynapath.defaults$eval380$fn__381
>> to method java.net.URLClassLoader.addURL(java.net.URL)
>> WARNING: Please consider reporting this to the maintainers of
>> dynapath.defaults$eval380$fn__381
>> WARNING: Use --illegal-access=warn to enable warnings of further illegal
>> reflective access operations
>> WARNING: All illegal access operations will be denied in a future release
>>
>> lein test tst.tupelo._bootstrap
>>
>> ---
>>Clojure 1.9.0-beta4Java 9.0.1
>> ---
>>
>>
>> Is Clojure 1.9 intended to be compatible with Java 9?
>>
>> Alan
>>
>

-- 
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: [ANN] Clojure 1.9.0-beta4

2017-11-02 Thread Andy Fingerhut 
Alan, I get similar messages when starting 'lein repl' with this
combination of versions:
+ Leiningen version 2.8.0, Clojure 1.8.0, Java 9.0.1 (note - No Clojure
1.9.0 involved)

Changing only the Leiningen to version 2.8.1 and there is no such error
message.

Andy

On Thu, Nov 2, 2017 at 11:29 AM, Alan Thompson  wrote:

> Hi.  1.9.0-beta4 works great for the Tupelo library on java 1.8, but I get
> the following warnings using Java 9.0.1:
>
> ​WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by dynapath.defaults$eval380$fn__381
> to method java.net.URLClassLoader.addURL(java.net.URL)
> WARNING: Please consider reporting this to the maintainers of
> dynapath.defaults$eval380$fn__381
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
>
> lein test tst.tupelo._bootstrap
>
> ---
>Clojure 1.9.0-beta4Java 9.0.1
> ---
>
>
> Is Clojure 1.9 intended to be compatible with Java 9?
>
> Alan
>
>
>
>
> On Wed, Nov 1, 2017 at 6:26 PM, Didier  wrote:
>
>> FWIW, bigdec? seemed to fit better, given bigdec as a coercion and
>>> BigDecimal as the underlying type – decimal? always seemed like the anomaly.
>>>
>>
>> Thought so too, but since there's no small decimal, or any other decimal,
>> its survivable. Though it does get a bit confusing, especially since int?
>> exclude bigint, for which you have to use integer?, which gets very
>> confusing if that includes or not biginteger.
>>
>> My conclusion is, its already all a bit of a mess, so maybe the broken
>> window principle applies here (even though that principle is actually to
>> say broken windows are not a good reason to break more of them, but...).
>>
>> On Wednesday, 1 November 2017 08:21:50 UTC-7, Sean Corfield wrote:
>>>
>>> Aside from needing to change bigdec? to decimal? in four places in our
>>> code, testing with Beta 4 has not shown any problems so we’ll probably go
>>> to production with it early next week.
>>>
>>>
>>>
>>> FWIW, bigdec? seemed to fit better, given bigdec as a coercion and
>>> BigDecimal as the underlying type – decimal? always seemed like the anomaly.
>>>
>>>
>>>
>>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>>
>>>
>>> --
>>> *From:* clo...@googlegroups.com  on behalf of
>>> Alex Miller 
>>> *Sent:* Tuesday, October 31, 2017 7:24:04 AM
>>> *To:* Clojure
>>> *Subject:* [ANN] Clojure 1.9.0-beta4
>>>
>>> Clojure 1.9.0-beta4 is now available.
>>>
>>> Try it via
>>>
>>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure
>>> /1.9.0-beta4
>>> - Leiningen: [org.clojure/clojure "1.9.0-beta4"]
>>>
>>> 1.9.0-beta4 includes the following changes since 1.9.0-beta3:
>>>
>>> - CLJ-2259  - Remove
>>> unnecessary bigdec? predicate added in 1.9
>>> - Bumped spec.alpha dependency to 0.1.143
>>>
>>> We would appreciate anything you can do to try out this release. We do
>>> not plan to make any further changes prior to 1.9.0 release unless
>>> regressions are found.
>>>
>>> --
>>> 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.co

Re: [ANN] Clojure 1.9.0-beta4

2017-11-02 Thread Alan Thompson 
Hi.  1.9.0-beta4 works great for the Tupelo library on java 1.8, but I get
the following warnings using Java 9.0.1:

​WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by dynapath.defaults$eval380$fn__381 to
method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of
dynapath.defaults$eval380$fn__381
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release

lein test tst.tupelo._bootstrap

---
   Clojure 1.9.0-beta4Java 9.0.1
---


Is Clojure 1.9 intended to be compatible with Java 9?

Alan




On Wed, Nov 1, 2017 at 6:26 PM, Didier  wrote:

> FWIW, bigdec? seemed to fit better, given bigdec as a coercion and
>> BigDecimal as the underlying type – decimal? always seemed like the anomaly.
>>
>
> Thought so too, but since there's no small decimal, or any other decimal,
> its survivable. Though it does get a bit confusing, especially since int?
> exclude bigint, for which you have to use integer?, which gets very
> confusing if that includes or not biginteger.
>
> My conclusion is, its already all a bit of a mess, so maybe the broken
> window principle applies here (even though that principle is actually to
> say broken windows are not a good reason to break more of them, but...).
>
> On Wednesday, 1 November 2017 08:21:50 UTC-7, Sean Corfield wrote:
>>
>> Aside from needing to change bigdec? to decimal? in four places in our
>> code, testing with Beta 4 has not shown any problems so we’ll probably go
>> to production with it early next week.
>>
>>
>>
>> FWIW, bigdec? seemed to fit better, given bigdec as a coercion and
>> BigDecimal as the underlying type – decimal? always seemed like the anomaly.
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>> --
>> *From:* clo...@googlegroups.com  on behalf of
>> Alex Miller 
>> *Sent:* Tuesday, October 31, 2017 7:24:04 AM
>> *To:* Clojure
>> *Subject:* [ANN] Clojure 1.9.0-beta4
>>
>> Clojure 1.9.0-beta4 is now available.
>>
>> Try it via
>>
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure
>> /1.9.0-beta4
>> - Leiningen: [org.clojure/clojure "1.9.0-beta4"]
>>
>> 1.9.0-beta4 includes the following changes since 1.9.0-beta3:
>>
>> - CLJ-2259  - Remove
>> unnecessary bigdec? predicate added in 1.9
>> - Bumped spec.alpha dependency to 0.1.143
>>
>> We would appreciate anything you can do to try out this release. We do
>> not plan to make any further changes prior to 1.9.0 release unless
>> regressions are found.
>>
>> --
>> 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...@googlegro

Re: We present: DevTools for re-frame!

2017-11-02 Thread Daniel Neal 
Nice! 

This looks really useful - and beautiful too!

Figuring out what is going on in (and optimising performance of) a complex 
UI 
can get really difficult so it's great to see things like this that can 
help.

Thanks for your work :)

On Thursday, October 26, 2017 at 4:31:53 PM UTC+1, Saskia Lindner wrote:
>
> Hi everyone!
>
> This summer, we worked on a devtool for re-frame, called re-frame trace. 
> Daniel Compton who had initially started the project supported us 
> throughout the course of the summer along with a bunch of people from the 
> Clojure community. Thanks so much to all of you!
>
> Our intention was to improve the developer experience by presenting the 
> application data in a clear and browsable way. Information about events, 
> subscriptions and renderings are being displayed while interacting with the 
> application and it is possible to inspect the current app-state. 
>
>
> Go try it out: https://github.com/Day8/re-frame-trace
>
> If you want to get an impression of how it works, Matt Huebert has set up 
> a sample application showing the tool in use: 
> https://mhuebert.github.io/shadow-re-frame/ (forked version of re-frame 
> trace)
>
> And if you're interested in more information, read our blog post here: 
> http://www.daiyi.co/dev-diary/
>
>
> We would love to get your feedback. Find us as daiyi and saskia on 
> Clojurians Slack (https://clojurians.slack.com/) via direct message or in 
> the #re-frame channel. 
>
>
> Cheers, 
>
> Chris & Saskia
>

-- 
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: Curious About Interfaces In IFn.java

2017-11-02 Thread Alex Miller 
Yes, primitive ^long and ^double hints can result in calling and returning 
primitives in function invocation to avoid boxing. Otherwise, pretty much 
everything is typed as Object from the JVM's perspective.

On Thursday, November 2, 2017 at 6:11:29 AM UTC-5, Nick Mudge wrote:
>
> I noticed the interface definitions in IFn.java that start out like this:
>
> static public interface L{long invokePrim();}
> static public interface D{double invokePrim();}
> static public interface OL{long invokePrim(Object arg0);}
> static public interface OD{double invokePrim(Object arg0);}
>
> Obviously these are about handing primitive arguments and return values. I 
> am curious what/why they are used. Are these used for performance reasons 
> with primitive values?
>

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

Curious About Interfaces In IFn.java

2017-11-02 Thread Nick Mudge 
I noticed the interface definitions in IFn.java that start out like this:

static public interface L{long invokePrim();}
static public interface D{double invokePrim();}
static public interface OL{long invokePrim(Object arg0);}
static public interface OD{double invokePrim(Object arg0);}

Obviously these are about handing primitive arguments and return values. I 
am curious what/why they are used. Are these used for performance reasons 
with primitive values?

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