Re: Source Code for Stuart Halloway's ETL Talk

[Cecil Westerhof]

2017-03-11 4:00 GMT+01:00 Alex Miller :

> Sorry, I don't have any control over the page - that's the publisher.
>

​I hope they read this list. ;-)
​

​I have a busy weekend. I'll give them a heads-up after the weekend.

-- 
Cecil Westerhof

-- 
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: Source Code for Stuart Halloway's ETL Talk

[Alex Miller]

Sorry, I don't have any control over the page - that's the publisher.

-- 
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: Source Code for Stuart Halloway's ETL Talk

[Cecil Westerhof]

2017-03-10 23:27 GMT+01:00 Alex Miller :

> Hey, the page just appeared today actually... it's alive!
>
> https://pragprog.com/book/shcloj3/programming-clojure
>

​I have default JavaScript disabled. Luckily for pragprog.com I only need
to activate one domain. (There are sites that want you to activate a lot
more. Those I do not use anymore.)
But it directs you to the page ‘no_js’, so a refresh after activating
JavaScript does not work. Personally I find this a design flaw.
If you really want another page, you could include the link to the original
page.

-- 
Cecil Westerhof

-- 
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: Private member variables for deftype

[Alex Miller]

No.

On Friday, March 10, 2017 at 5:14:09 PM UTC-6, Tianxiang Xiong wrote:
>
> Is there a way of giving a type defined with `deftype` internal member 
> variables? E.g. not passed explicitly in the constructor.
>
> With `reify`, we can use a closure 
> :
>
> (let [ctx (atom nil)
>   kv-store (atom nil)]
>   (reify Processor
> ;; ...
> (init [this context]
>   (reset! ctx context)
>   (reset! kv-store (.getStateStore context "Counts")))
> ;; ...
> ))
>
> It's not clear how this can be done with `deftype`, however.
>

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

Private member variables for deftype

['Tianxiang Xiong' via Clojure]

Is there a way of giving a type defined with `deftype` internal member 
variables? E.g. not passed explicitly in the constructor.

With `reify`, we can use a closure 
:

(let [ctx (atom nil)
  kv-store (atom nil)]
  (reify Processor
;; ...
(init [this context]
  (reset! ctx context)
  (reset! kv-store (.getStateStore context "Counts")))
;; ...
))

It's not clear how this can be done with `deftype`, however.

-- 
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: Source Code for Stuart Halloway's ETL Talk

[Alex Miller]

Hey, the page just appeared today actually... it's alive!

https://pragprog.com/book/shcloj3/programming-clojure


On Friday, March 10, 2017 at 4:25:39 PM UTC-6, Alex Miller wrote:
>
> It's coming along nicely, should be out in beta this summer I think, 
> including a brand new chapter on spec!
>
> On Friday, March 10, 2017 at 11:17:58 AM UTC-6, Shaun Parker wrote:
>>
>> Thanks for the update Alex. I can't wait to read the third edition of 
>> Programming Clojure!
>>
>> On Thursday, March 9, 2017 at 7:05:52 PM UTC-7, Alex Miller wrote:
>>>
>>> He has not yet released it but he is still planning to do so.
>>
>>

-- 
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: Source Code for Stuart Halloway's ETL Talk

[Alex Miller]

It's coming along nicely, should be out in beta this summer I think, 
including a brand new chapter on spec!

On Friday, March 10, 2017 at 11:17:58 AM UTC-6, Shaun Parker wrote:
>
> Thanks for the update Alex. I can't wait to read the third edition of 
> Programming Clojure!
>
> On Thursday, March 9, 2017 at 7:05:52 PM UTC-7, Alex Miller wrote:
>>
>> He has not yet released it but he is still planning to do so.
>
>

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

(JOBS) Quartet is looking for a Core Platform Engineer & Platform Engineering Manager

[lherzig via Clojure]

Quartet is a mission-driven technology company transforming the way mental 
healthcare is delivered. We partner with insurers and physicians to make 
mental healthcare more accessible and integrated into primary care. Our 
platform relies on advanced analytics, proven treatment programs, and easy 
to use technology to improve outcomes and total cost of care. We are a team 
of engineers, data scientists, and clinicians, finding solutions for a 
broken healthcare system. Venture-backed by the very best healthcare and 
technology investors, including GV (formerly Google Ventures), Quartet is 
using this investment to further build its team and expand into 5+ new 
markets in 2017.

We are looking to hire a Core Platform Engineer 
 and a 
Platform 
Engineering Manager 
. 
Located in NYC. We currently use Clojure and Scala for our backend 
services. 

If interested, please click the link(s) above to apply. For more 
information, please visit our website .

-- 
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: Vars as global thread-locals?

[Didier]

Absolutly, Clojure embraces its host platform. Always feel free to use the Java 
features when they work best for your use case. 

But just to clarify, Java's ThreadLocal is an implementation of dynamic 
scoping. The scope is determined not by the source code, but by the runtime 
circumstances, in this case, the running Thread. While it's not the classic 
kind of dynamic scoping, it is still dynamic and not lexical. 

It differs from Clojure's dynamic scope in that, Clojure's scope is determined 
by the runtime stack plus the current thread.

Clojure relies on ThreadLocal for the per-thread scoping implementation, and it 
uses its own implementation for the runtime stack based scoping.

This means that if you want to re-enter a thread after having executed in its 
context before, and still have access to its previously bound ThreadLocal, you 
can only do it with a ThreadLocal. With Clojure's dynamic Vars, I don't think 
this is possible, since Clojure restores the previous binding when you exit 
from the thread. Now, be careful with this, I've seen lots of bugs in Java due 
to people not realizing that the binding is permanently attached to the thread, 
unless explicitly unbound, especially with the use of thread pools.

So I'd consider Clojure dynamic Vars safer to use in most cases, and still 
would recommend you use them instead of ThreadLocal most of the time. Unless 
what you want to do is attach state to the thread, dynamic Vars will probably 
be better and easier.

Just my 2 cents.

-- 
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: Source Code for Stuart Halloway's ETL Talk

[Shaun Parker]

Thanks for the update Alex. I can't wait to read the third edition of 
Programming Clojure!

On Thursday, March 9, 2017 at 7:05:52 PM UTC-7, Alex Miller wrote:
>
> He has not yet released it but he is still planning to do so.

-- 
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: Leiningen, AOT compilation, and classloaders

[Mike Rodriguez]

I haven't been able to get to the bottom of this as of yet.  Primarily the 
problem is I need to investigate how `lein trampoline` works compared to 
without it, from an implementation perspective.

I'll note that `lein test` does do a :reload option to `require` when 
running tests.  Typically forced reloads of namespaces doesn't mix well 
with AOT compilation, due to classloader issues like you are reporting here.
However, I'm still missing key parts to understanding this.  I want to look 
a bit closer at it, but just responding here in case these thoughts are 
meaningful to anyone else that is looking at it.

On Wednesday, March 8, 2017 at 12:07:31 AM UTC-5, Tianxiang Xiong wrote:
>
> I recently ran into an issue with AOT compilation that I'd like to 
> understand better. A minimal working example (MWE) can be found here 
> . 
>
> Basically, using `:aot :all` in `project.clj` with `lein trampoline test` 
> results in different classloaders for class `Foo`.  
>
> Classloader for lein_trampoline_aot.core.Foo:  
> #object[clojure.lang.DynamicClassLoader 
> 0x4982cc36 clojure.lang.DynamicClassLoader@4982cc36]
> Classloader for (->Foo):  #object[sun.misc.Launcher$AppClassLoader 
> 0x55f96302 sun.misc.Launcher$AppClassLoader@55f96302]
>
> While the same classloaders are used with `lein test`:
>
> Class loader for lein_trampoline_aot.core.Foo:  
> #object[sun.misc.Launcher$AppClassLoader 
> 0x55f96302 sun.misc.Launcher$AppClassLoader@55f96302]
> Classloader for (->Foo):  #object[sun.misc.Launcher$AppClassLoader 
> 0x55f96302 sun.misc.Launcher$AppClassLoader@55f96302]
>
> When is one classloader used instead of another, and why do `lein 
> trampoline test` and `lein test` behave differently with `:aot :all`?
>

-- 
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: Navigators and lenses

[Jason Felice]

I'm very curious why most lens libraries don't just use fns with arity 1
and 2.

(I'm going to guess that Specter doesn't because it wants more
introspection into the lenses for optimization purposes.)

On Thu, Mar 9, 2017 at 4:25 PM, Mark Engelberg 
wrote:

> On Mar 9, 2017 9:52 AM, "Brandon Bloom"  wrote:
> >>
> >
> > Since you're responding to me specifically, I'd like to be clear that I
> never made that claim. I only said we need more experimentation. This is a
> sufficiently big enough area of ideas to warrant exploration of competing
> approaches.
>
> My comment wasn't intended as directed specifically at you.  Your list of
> references was interesting and useful.  Thanks for posting them.
>
> --
> 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.