Re: How do threads work in command-line REPL?

[Nathan Marz]

Yea, that code seems to explain the behavior we're seeing. I opened an
issue for this: http://dev.clojure.org/jira/browse/NREPL-80

On Tue, Feb 9, 2016 at 7:38 PM, Jony Hudson  wrote:

> Ahem.
>
> "method" -> "message"
>
>
> Jony
>
>
> On Wednesday, 10 February 2016 00:35:16 UTC, Jony Hudson wrote:
>>
>> I'm pretty fuzzy on how nREPL works, so I might be getting it wrong here
>> ... but I think it processes each method through a `future`. See:
>>
>>
>> https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L28
>>
>> All of the nREPL operations are async, AFAIK, and I think the future is
>> also relied upon to implement interruptible evaluation. See:
>>
>>
>> https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj#L243
>>
>> But I can't say I really understand that much of the eval code, so like I
>> say, I could be totally wrong here!
>>
>>
>> Jony
>>
>>
>> On Tuesday, 9 February 2016 18:19:09 UTC, Nathan Marz wrote:
>>>
>>> I was doing some work that involved the use of thread locals, and I
>>> noticed that within a REPL session (launched via 'lein repl') my thread
>>> locals would reset themselves to their initial value. I did some digging
>>> and found that the thread id keeps changing within a single REPL session,
>>> e.g.:
>>>
>>> user=> (.getId (Thread/currentThread))
>>> 65
>>> user=> (.getId (Thread/currentThread))
>>> 74
>>> user=> (.getId (Thread/currentThread))
>>> 78
>>> user=> (.getId (Thread/currentThread))
>>> 78
>>> user=> (.getId (Thread/currentThread))
>>> 78
>>> user=> (.getId (Thread/currentThread))
>>> 82
>>>
>>> I'm hoping someone who knows the internals of the REPL could shed some
>>> light onto why this is the behavior and why it was designed this way.
>>>
>>> Thanks,
>>> Nathan
>>>
>>>


-- 
Twitter: @nathanmarz
http://nathanmarz.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: Can the data in a vector have data inside it that points to the same vector? vector1=[a b c d] a=[1 2 f s vector1]

[James Reeves]

No, vectors can't be recursive. However you can use a reference of some
description, e.g.

   (let [p (promise), v [p]]
 (deliver p v)
 v))

You could also use a lazy seq.

- James

On 10 February 2016 at 04:29, Timothy Vinick  wrote:

> Here's an example:
>
>  vector1=[a b c d] a=[1 2 f s vector1]
>
> --
> 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.

Can the data in a vector have data inside it that points to the same vector? vector1=[a b c d] a=[1 2 f s vector1]

[Timothy Vinick]

Here's an example:

 vector1=[a b c d] a=[1 2 f s vector1]

-- 
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: How do threads work in command-line REPL?

[Jony Hudson]

Ahem.

"method" -> "message"


Jony

On Wednesday, 10 February 2016 00:35:16 UTC, Jony Hudson wrote:
>
> I'm pretty fuzzy on how nREPL works, so I might be getting it wrong here 
> ... but I think it processes each method through a `future`. See:
>
>
> https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L28
>
> All of the nREPL operations are async, AFAIK, and I think the future is 
> also relied upon to implement interruptible evaluation. See:
>
>
> https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj#L243
>
> But I can't say I really understand that much of the eval code, so like I 
> say, I could be totally wrong here!
>
>
> Jony
>
>
> On Tuesday, 9 February 2016 18:19:09 UTC, Nathan Marz wrote:
>>
>> I was doing some work that involved the use of thread locals, and I 
>> noticed that within a REPL session (launched via 'lein repl') my thread 
>> locals would reset themselves to their initial value. I did some digging 
>> and found that the thread id keeps changing within a single REPL session, 
>> e.g.:
>>
>> user=> (.getId (Thread/currentThread))
>> 65
>> user=> (.getId (Thread/currentThread))
>> 74
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 82
>>
>> I'm hoping someone who knows the internals of the REPL could shed some 
>> light onto why this is the behavior and why it was designed this way.
>>
>> Thanks,
>> Nathan
>>
>>

-- 
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: How do threads work in command-line REPL?

[Jony Hudson]

I'm pretty fuzzy on how nREPL works, so I might be getting it wrong here 
... but I think it processes each method through a `future`. See:

https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L28

All of the nREPL operations are async, AFAIK, and I think the future is 
also relied upon to implement interruptible evaluation. See:

https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj#L243

But I can't say I really understand that much of the eval code, so like I 
say, I could be totally wrong here!


Jony


On Tuesday, 9 February 2016 18:19:09 UTC, Nathan Marz wrote:
>
> I was doing some work that involved the use of thread locals, and I 
> noticed that within a REPL session (launched via 'lein repl') my thread 
> locals would reset themselves to their initial value. I did some digging 
> and found that the thread id keeps changing within a single REPL session, 
> e.g.:
>
> user=> (.getId (Thread/currentThread))
> 65
> user=> (.getId (Thread/currentThread))
> 74
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 82
>
> I'm hoping someone who knows the internals of the REPL could shed some 
> light onto why this is the behavior and why it was designed this way.
>
> Thanks,
> Nathan
>
>

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

[ANN] trapperkeeper 1.3.0 - with support for restarts via HUP

[Chris Price]

Today we released puppetlabs/trapperkeeper v1.3.0 to clojars.

Trapperkeeper[1] is a Clojure framework for hosting long-running
applications and services. You can think of it as a sort of "binder" for
Ring applications and other modular bits of Clojure code.

The major change in the release is support for HUP signal handling; if you
send your TK process a HUP signal, it will gracefully stop and restart all
of your TK services without needing to restart the entire JVM process.
Note that if you plan to use this feature, it's important to ensure that
your services clean up after themselves properly during a `stop`, or you
may be subject to memory leaks when the services are restarted.

Also note that this release introduces a dependency on core.async.  This is
not used in any public APIs, but I thought it was worth mentioning since it
is a significant new dependency.

This release also bumps our raynes.fs dependency to 1.4.6, as we received
some feedback from users that the older version of raynes that we were
using was causing dependency conflicts.

For more info see the CHANGELOG[2], docs[3], and associated jira
tickets[4,5]

[1] Trapperkeeper github repo: https://github.com/puppetlabs/trapperkeeper
[2] CHANGELOG:
https://github.com/puppetlabs/trapperkeeper/blob/master/CHANGELOG.md#130

[3] Trapperkeeper github wiki:
https://github.com/puppetlabs/trapperkeeper/wiki
[4] Trapperkeeper HUP support Jira ticket:
https://tickets.puppetlabs.com/browse/TK-202
[5] raynes.fs dependency upgrade ticket:
https://tickets.puppetlabs.com/browse/TK-315

-- 
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: ClojureScript ord-of-char?

[nick rothwell]

Given that one can write (int \A) in ClojureScript, what should it do? (I 
would naively expect the same effect as .charCodeAt.)

Anyway, Conditional Reader here we come.

On Tuesday, 9 February 2016 18:05:00 UTC, David Nolen wrote:
>
> .charCodeAt is the correct thing - there is no real char type in 
> ClojureScript only strings.
>
> David
>
> On Tue, Feb 9, 2016 at 1:01 PM, nick rothwell  > wrote:
>
>> Dumb question: should I be able to get the ordinal value of a character 
>> in ClojureScript via something like
>>
>> (int \A)
>>
>> ? This does exactly what I'd expect in Clojure. In ClojureScript it seems 
>> to compile to
>>
>> "A" | 0
>>
>> which evaluates to 0.
>>
>> (I'm now doing (.charCodeAt \A) which works fine.)
>>
>> [org.clojure/clojurescript "1.7.228"]
>>
>> -- 
>> 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: Scripting with Clojure / "slow" boot time

[James Elliott]

I don’t have any examples to share, I just wanted to thank you for doing 
this. It is really wonderful to see how responsive Clojure is to community 
input and concerns, and the launch of an effort like this so quickly in 
response to the survey feedback.

On Tuesday, February 9, 2016 at 12:36:43 PM UTC-6, Alex Miller wrote:
>
> I'm doing some research on slow Clojure boot time and would be interested 
> in collecting info about example use cases where it's been a problem for 
> people.
>
> http://goo.gl/forms/eSpn8M5FNB
>
> I'm not expecting to release the results in any formal way, mostly looking 
> to use it to pull out particular use cases and/or commonalities across 
> anecdotes so that we can work on boot time problems that matter the most 
> (and solutions likely to help the most). Any numbers you can provide would 
> be great.
>
> Alex
>
>
>

-- 
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] clj-refactor.el and refactor-nrepl 2.0.0 is released

[James Elliott]

Yes, that is such an intractable problem. It would be wonderful if you 
could make things work even better, but I am happy to see them getting this 
far already.

On Tuesday, February 9, 2016 at 3:31:24 AM UTC-6, benedek fazekas wrote:
>
> Thanks Colin, James. re. warning about evaluation, we are looking into 
> further improving this area, watch 
> https://github.com/clojure-emacs/refactor-nrepl/issues/134 (slightly 
> misleading title) for discussion around it.
>
> On Monday, February 8, 2016 at 6:10:22 PM UTC, James Elliott wrote:
>>
>> Thank you all! I have been watching progress on the Gitter chat and am 
>> very excited to be able to use all the great new features in this amazing 
>> package. The fact that I am now warned when the project needs to be 
>> re-evaluated, and that I can recover from issues with my protocols being 
>> redefined when I go ahead and allow that to happen by calling 
>> cider-refresh, means I can now learn and apply these tools without fear.
>>
>> On Saturday, February 6, 2016 at 5:30:39 PM UTC-6, benedek fazekas wrote:
>>>
>>> The stable release for clj-refactor.el is out together with its nrepl 
>>> middleware backend refactor-nrepl.
>>>
>>> clj-refactor.el is an Emacs package for clojure and clojure script 
>>> refactorings while refactor-nrepl is an editor agnostic nrepl middleware 
>>> backend supporting refactoring features in your editor of choice. For a 
>>> state of art demo what you can achieve with clj-refactor and Emacs see 
>>> Magnar's  parens of the dead 
>>>  series.
>>>
>>> The main areas of improvement for this release are
>>>
>>>- supporting refactorings for *cljc and clojurescript* files
>>>- *boot* support
>>>- *find usages* (and related features) supporting *macros*.
>>>- *improve discoverability* of features via hydra menus 
>>> and 
>>>the project wiki 
>>>.
>>>
>>> Apart from these there are a huge number of changes, improvements and 
>>> bugfixes, see full changelog for clj-refactor 
>>> 
>>>  and refactor-nrepl 
>>> 
>>> .
>>>
>>> This release is also compatible with the latest cider stable release. 
>>> Unfortunately tho we had to drop support for clojure 1.6 and older.
>>>
>>> As for almost all releases Lars Andersen  
>>> invested 
>>> a lot of time and energy in commits and also in support, also the original 
>>> creator of clj-refactor Magnar Sveen  helped 
>>> *create function from example* to grow brains for this release. Thanks 
>>> for both of them and all the contributors 
>>> ! 
>>> Also thanks for the maintainers and contributors of the packages we build 
>>> on, like cider, tools.nrepl, tools.analyzer, tools.namespace and others!
>>>
>>> As always any contribution and/or feedback is welcome. We are available 
>>> on gitter  and usually 
>>> hang out on clojurian slack #cider channel too.
>>>
>>> Enjoy!
>>>
>>> --
>>> Benedek Fazekas
>>>
>>

-- 
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: How do threads work in command-line REPL?

[Alex Miller]

These would be consistent with having a background thread pool where the 
ttl expired that were running your repl commands. I was able to repro in 
lein after waiting a bit.

The default clojure.main/repl doesn't do anything like that, but maybe lein 
and boot do (perhaps via nrepl or something?)


On Tuesday, February 9, 2016 at 12:55:13 PM UTC-6, Magomimmo wrote:
>
> yep..now I get the same weird result with boot too:
>
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 64
> boot.user=> (.getId (Thread/currentThread))
> 64
>
> mimmo
>
> On 09 Feb 2016, at 19:48, Nathan Marz  wrote:
>
> I should clarify that the thread id doesn't change instantly, it seems to 
> change when I've left it idle for a bit. Also on lein 2.5.2.
>
> On Tue, Feb 9, 2016 at 1:45 PM, Mimmo Cosenza  
> wrote:
>
>> I just tried with boot real:
>>
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>>
>>
>> mimmo
>>
>> On 09 Feb 2016, at 19:38, Alex Miller  wrote:
>>
>> That seems pretty weird. I can't reproduce it. I'm using lein 2.5.2. 
>>
>> On Tuesday, February 9, 2016 at 12:19:09 PM UTC-6, Nathan Marz wrote:
>>>
>>> I was doing some work that involved the use of thread locals, and I 
>>> noticed that within a REPL session (launched via 'lein repl') my thread 
>>> locals would reset themselves to their initial value. I did some digging 
>>> and found that the thread id keeps changing within a single REPL session, 
>>> e.g.:
>>>
>>> user=> (.getId (Thread/currentThread))
>>> 65
>>> user=> (.getId (Thread/currentThread))
>>> 74
>>> user=> (.getId (Thread/currentThread))
>>> 78
>>> user=> (.getId (Thread/currentThread))
>>> 78
>>> user=> (.getId (Thread/currentThread))
>>> 78
>>> user=> (.getId (Thread/currentThread))
>>> 82
>>>
>>> I'm hoping someone who knows the internals of the REPL could shed some 
>>> light onto why this is the behavior and why it was designed this way.
>>>
>>> Thanks,
>>> Nathan
>>>
>>>
>> -- 
>> 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.
>>
>>
>>
>
>
> -- 
> Twitter: @nathanmarz
> http://nathanmarz.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.
>
>
>

-- 
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: How do threads work in command-line REPL?

[Mimmo Cosenza]

yep..now I get the same weird result with boot too:

boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
64
boot.user=> (.getId (Thread/currentThread))
64

mimmo

> On 09 Feb 2016, at 19:48, Nathan Marz  wrote:
> 
> I should clarify that the thread id doesn't change instantly, it seems to 
> change when I've left it idle for a bit. Also on lein 2.5.2.
> 
> On Tue, Feb 9, 2016 at 1:45 PM, Mimmo Cosenza  > wrote:
> I just tried with boot real:
> 
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
>> boot.user=> (.getId (Thread/currentThread))
>> 34
> 
> mimmo
> 
>> On 09 Feb 2016, at 19:38, Alex Miller > > wrote:
>> 
>> That seems pretty weird. I can't reproduce it. I'm using lein 2.5.2. 
>> 
>> On Tuesday, February 9, 2016 at 12:19:09 PM UTC-6, Nathan Marz wrote:
>> I was doing some work that involved the use of thread locals, and I noticed 
>> that within a REPL session (launched via 'lein repl') my thread locals would 
>> reset themselves to their initial value. I did some digging and found that 
>> the thread id keeps changing within a single REPL session, e.g.:
>> 
>> user=> (.getId (Thread/currentThread))
>> 65
>> user=> (.getId (Thread/currentThread))
>> 74
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 82
>> 
>> I'm hoping someone who knows the internals of the REPL could shed some light 
>> onto why this is the behavior and why it was designed this way.
>> 
>> Thanks,
>> Nathan
>> 
>> 
>> -- 
>> 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 
>> .
> 
> 
> 
> 
> -- 
> Twitter: @nathanmarz
> http://nathanmarz.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 
> .

-- 
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: How do threads work in command-line REPL?

[Nathan Marz]

I should clarify that the thread id doesn't change instantly, it seems to
change when I've left it idle for a bit. Also on lein 2.5.2.

On Tue, Feb 9, 2016 at 1:45 PM, Mimmo Cosenza 
wrote:

> I just tried with boot real:
>
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
>
>
> mimmo
>
> On 09 Feb 2016, at 19:38, Alex Miller  wrote:
>
> That seems pretty weird. I can't reproduce it. I'm using lein 2.5.2.
>
> On Tuesday, February 9, 2016 at 12:19:09 PM UTC-6, Nathan Marz wrote:
>>
>> I was doing some work that involved the use of thread locals, and I
>> noticed that within a REPL session (launched via 'lein repl') my thread
>> locals would reset themselves to their initial value. I did some digging
>> and found that the thread id keeps changing within a single REPL session,
>> e.g.:
>>
>> user=> (.getId (Thread/currentThread))
>> 65
>> user=> (.getId (Thread/currentThread))
>> 74
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 78
>> user=> (.getId (Thread/currentThread))
>> 82
>>
>> I'm hoping someone who knows the internals of the REPL could shed some
>> light onto why this is the behavior and why it was designed this way.
>>
>> Thanks,
>> Nathan
>>
>>
> --
> 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.
>
>
>


-- 
Twitter: @nathanmarz
http://nathanmarz.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: How do threads work in command-line REPL?

[Mimmo Cosenza]

I just tried with boot real:

> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34

mimmo

> On 09 Feb 2016, at 19:38, Alex Miller  wrote:
> 
> That seems pretty weird. I can't reproduce it. I'm using lein 2.5.2. 
> 
> On Tuesday, February 9, 2016 at 12:19:09 PM UTC-6, Nathan Marz wrote:
> I was doing some work that involved the use of thread locals, and I noticed 
> that within a REPL session (launched via 'lein repl') my thread locals would 
> reset themselves to their initial value. I did some digging and found that 
> the thread id keeps changing within a single REPL session, e.g.:
> 
> user=> (.getId (Thread/currentThread))
> 65
> user=> (.getId (Thread/currentThread))
> 74
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 82
> 
> I'm hoping someone who knows the internals of the REPL could shed some light 
> onto why this is the behavior and why it was designed this way.
> 
> Thanks,
> Nathan
> 
> 
> -- 
> 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: How do threads work in command-line REPL?

[Alex Miller]

That seems pretty weird. I can't reproduce it. I'm using lein 2.5.2. 

On Tuesday, February 9, 2016 at 12:19:09 PM UTC-6, Nathan Marz wrote:
>
> I was doing some work that involved the use of thread locals, and I 
> noticed that within a REPL session (launched via 'lein repl') my thread 
> locals would reset themselves to their initial value. I did some digging 
> and found that the thread id keeps changing within a single REPL session, 
> e.g.:
>
> user=> (.getId (Thread/currentThread))
> 65
> user=> (.getId (Thread/currentThread))
> 74
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 78
> user=> (.getId (Thread/currentThread))
> 82
>
> I'm hoping someone who knows the internals of the REPL could shed some 
> light onto why this is the behavior and why it was designed this way.
>
> Thanks,
> Nathan
>
>

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

Scripting with Clojure / "slow" boot time

[Alex Miller]

I'm doing some research on slow Clojure boot time and would be interested 
in collecting info about example use cases where it's been a problem for 
people.

http://goo.gl/forms/eSpn8M5FNB

I'm not expecting to release the results in any formal way, mostly looking 
to use it to pull out particular use cases and/or commonalities across 
anecdotes so that we can work on boot time problems that matter the most 
(and solutions likely to help the most). Any numbers you can provide would 
be great.

Alex


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

How do threads work in command-line REPL?

[Nathan Marz]

I was doing some work that involved the use of thread locals, and I noticed
that within a REPL session (launched via 'lein repl') my thread locals
would reset themselves to their initial value. I did some digging and found
that the thread id keeps changing within a single REPL session, e.g.:

user=> (.getId (Thread/currentThread))
65
user=> (.getId (Thread/currentThread))
74
user=> (.getId (Thread/currentThread))
78
user=> (.getId (Thread/currentThread))
78
user=> (.getId (Thread/currentThread))
78
user=> (.getId (Thread/currentThread))
82

I'm hoping someone who knows the internals of the REPL could shed some
light onto why this is the behavior and why it was designed this way.

Thanks,
Nathan

-- 
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: Does Leiningen read Env Vars such as JAVA_OPTS?

[Sean Corfield]

Michael Drago wrote on Tuesday, February 9, 2016 at 6:37 AM:
Hi guys. I'm trying to figure out where the JVM gets the java parameters (such 
as -Xms and -Xmx) when starting apps via "lein run" and when using the repl. 
The only successful way I have been able to set the memory is via the 
project.clj's :jvm-opts. Can we do this with an environment variable such as 
$JAVA_OPTS? I've tried $JAVA_OPTS with no success. When the env var is set the 
JVM's memory resorts to the system default. I am trying to do this on Redhat 
(Leiningen 2.4.2 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM). Thank you!

Looks like JVM_OPTS is what you want, based on a quick look at the source code… 

https://github.com/technomancy/leiningen/blob/4383caecce94482a57a25146bdd236e89b20f75f/leiningen-core/src/leiningen/core/eval.clj#L131

And the docs seem to confirm that:

https://github.com/technomancy/leiningen/blob/792750b7a1bdf0499081c72b197df41cee5ef648/doc/TUTORIAL.md#setting-jvm-options

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


-- 
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: ClojureScript ord-of-char?

[David Nolen]

.charCodeAt is the correct thing - there is no real char type in
ClojureScript only strings.

David

On Tue, Feb 9, 2016 at 1:01 PM, nick rothwell  wrote:

> Dumb question: should I be able to get the ordinal value of a character in
> ClojureScript via something like
>
> (int \A)
>
> ? This does exactly what I'd expect in Clojure. In ClojureScript it seems
> to compile to
>
> "A" | 0
>
> which evaluates to 0.
>
> (I'm now doing (.charCodeAt \A) which works fine.)
>
> [org.clojure/clojurescript "1.7.228"]
>
> --
> 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.

ClojureScript ord-of-char?

[nick rothwell]

Dumb question: should I be able to get the ordinal value of a character in 
ClojureScript via something like

(int \A)

? This does exactly what I'd expect in Clojure. In ClojureScript it seems 
to compile to

"A" | 0

which evaluates to 0.

(I'm now doing (.charCodeAt \A) which works fine.)

[org.clojure/clojurescript "1.7.228"]

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

[ANN] scheje v 0.2.6 - now supporting clojurescript, featuring a Node.JS REPL!

[Rafik NACCACHE]

Hi Guys,

I am proud to have been able to port scheje, the little scheme on top of
clojure, using Reader conditionals, to clojurescript.

It also has two little REPLs, one for the JVM version, and one for Node.js.

Scheje makes it possible to write Lisp on the browser, with macros support
(scheme's define-syntax)

Please consider giving it a try here:
https://github.com/turbopape/scheje

Cheers!

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

Does Leiningen read Env Vars such as JAVA_OPTS?

[Michael Drago]

Hi guys. I'm trying to figure out where the JVM gets the java parameters 
(such as -Xms and -Xmx) when starting apps via "lein run" and when using 
the repl. The only successful way I have been able to set the memory is via 
the project.clj's :jvm-opts. Can we do this with an environment variable 
such as $JAVA_OPTS? I've tried $JAVA_OPTS with no success. When the env var 
is set the JVM's memory resorts to the system default. I am trying to do 
this on Redhat (Leiningen 2.4.2 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit 
Server VM). Thank you!

-- 
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: Splitting Read into 2 steps?

[Antonin Hildebrand]

Hi Terje,

I think I had a similar problem when implementing parsing for Plastic[1] 
(an experimental editor in ClojureScript).
I wanted to use tools.reader (for robustness), but I needed more 
information about tokens from it (particularly comments, new-lines and 
whitespace).

I ended up hijacking log-source*[2] hook for that. I track[3] tokens via 
log-source* and build parse-tree myself.

It is a hacky solution, but I avoided rewriting tools.reader.
Antonin

[1] https://github.com/darwin/plastic
[2] 
https://github.com/darwin/tools.reader/commit/321abf7b4242b30c94052c93cdcf5d5d92c7dc38
[3] https://github.com/darwin/plastic/blob/master/src/meld/meld/tracker.cljs

On Monday, February 8, 2016 at 8:12:10 AM UTC+1, Terje Dahl wrote:
>
>
>
> I have been studying and and implementing my own version of LispReader / 
> tool.reader - for the purpose of syntax highlighting and visual token 
> manipulation.
> My question is this:
> Why not split this into 2 steps?
>
>1. Reads the input (from PushbackReader et al) and emits a stream of 
>tokens, preserving information about location in source, and applying 
>typing to tokens, if possible.
>2. Consumes the stream from step one, descending recursively, applying 
>reader-macros, resolving symbols in name-spaces, etc.
>
> This would allow for easier configuration of each step, such as:
>
>- turning exceptions on/off (useful for syntax highlighting)
>- custom reader-macros and custom classes of reader-macros
>- static analysis of code by controlling the namespacing/context
>
> Is there any reason not to do this?
> (Other than: This is the way it has always been done. This is the way 
> lisp-readers are aways implemented.)
>
> Perhaps such a development is already underway?
>
> Finally, if I wanted to implement such a solution, would it be to do it in 
> Java or Clojure?  Why? 
>
>

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

[ANN] port of Deeplearning4j RNN example to clojure

[Joachim De Beule]

see https://github.com/joachimdb/dl4clj, all comments welcome!

Joachim

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

Utterly lost dealing with ClojureScript / Closure dependencies

[Michael Sperber]

I'm trying to properly deal with dependencies on a cljsjs package
(React, in this case).  So I have this in project.clj:


  :dependencies [[org.clojure/clojure "1.7.0"]
 [org.clojure/clojurescript "1.7.228" :scope "provided"]
 [cljsjs/react-with-addons "0.13.3-0"]] ; addons needed for 
tests only

  :cljsbuild
  
  { :builds [;; these need phantom or something like it
 {:id "test-dom"
  :source-paths ["src" "test-dom"]
  :compiler {:output-to "target/test-dom.js"
 :main reacl.test.runner
 :optimizations :none}}
...

The full glory is here, if you're interested:

https://github.com/active-group/reacl/blob/master/project.clj

Now, as soon as change :optimizations to :whitespace, I get a

goog.require("cljsjs.react")

somewhere in the output, without a corresponding require.  (FWIW, this
goes away when I elide the :main clause.)

Can anyone shed light on what's happening here, and what I'm doing
wrong?  Help would be much appreciated!

-- 
Regards,
Mike

-- 
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] clj-refactor.el and refactor-nrepl 2.0.0 is released

[benedek fazekas]

Thanks Colin, James. re. warning about evaluation, we are looking into 
further improving this area, 
watch https://github.com/clojure-emacs/refactor-nrepl/issues/134 (slightly 
misleading title) for discussion around it.

On Monday, February 8, 2016 at 6:10:22 PM UTC, James Elliott wrote:
>
> Thank you all! I have been watching progress on the Gitter chat and am 
> very excited to be able to use all the great new features in this amazing 
> package. The fact that I am now warned when the project needs to be 
> re-evaluated, and that I can recover from issues with my protocols being 
> redefined when I go ahead and allow that to happen by calling 
> cider-refresh, means I can now learn and apply these tools without fear.
>
> On Saturday, February 6, 2016 at 5:30:39 PM UTC-6, benedek fazekas wrote:
>>
>> The stable release for clj-refactor.el is out together with its nrepl 
>> middleware backend refactor-nrepl.
>>
>> clj-refactor.el is an Emacs package for clojure and clojure script 
>> refactorings while refactor-nrepl is an editor agnostic nrepl middleware 
>> backend supporting refactoring features in your editor of choice. For a 
>> state of art demo what you can achieve with clj-refactor and Emacs see 
>> Magnar's  parens of the dead 
>>  series.
>>
>> The main areas of improvement for this release are
>>
>>- supporting refactorings for *cljc and clojurescript* files
>>- *boot* support
>>- *find usages* (and related features) supporting *macros*.
>>- *improve discoverability* of features via hydra menus 
>> and the 
>>project wiki .
>>
>> Apart from these there are a huge number of changes, improvements and 
>> bugfixes, see full changelog for clj-refactor 
>> 
>>  and refactor-nrepl 
>> 
>> .
>>
>> This release is also compatible with the latest cider stable release. 
>> Unfortunately tho we had to drop support for clojure 1.6 and older.
>>
>> As for almost all releases Lars Andersen  invested 
>> a lot of time and energy in commits and also in support, also the original 
>> creator of clj-refactor Magnar Sveen  helped 
>> *create 
>> function from example* to grow brains for this release. Thanks for both 
>> of them and all the contributors 
>> ! 
>> Also thanks for the maintainers and contributors of the packages we build 
>> on, like cider, tools.nrepl, tools.analyzer, tools.namespace and others!
>>
>> As always any contribution and/or feedback is welcome. We are available 
>> on gitter  and usually 
>> hang out on clojurian slack #cider channel too.
>>
>> Enjoy!
>>
>> --
>> Benedek Fazekas
>>
>

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