Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2277

2014-07-30 Thread Thomas Heller
David its probably best to hold off on that release. It seems the 
closure-library HEAD version depends on a newer closure compiler version 
than the one available via maven.

At least I'm seeing some renaming issues for advanced compilation.

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


Clojure on Cloudbees versus Heroku?

2014-07-30 Thread Jonathon McKitrick
I've deployed a few apps to Heroku, but I'm always looking for new options 
with better pricing or features.

Is there any reason Cloudbees might be better for Clojure apps than 
Heroku?  If the big selling point of Cloudbees is Jenkins, I don't think 
that benefits Clojure projects, right?

-- 
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: ClojureScript 0.0-2277

2014-07-30 Thread David Nolen
Can you be more specific about the naming issues?

David

On Wednesday, July 30, 2014, Thomas Heller  wrote:

> David its probably best to hold off on that release. It seems the
> closure-library HEAD version depends on a newer closure compiler version
> than the one available via maven.
>
> At least I'm seeing some renaming issues for advanced compilation.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to clojurescr...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
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: ClojureScript 0.0-2277

2014-07-30 Thread Thomas Heller
Sorry, I would be if I could.

Trying to track it down, but debugging an optimized build is not exactly easy. 
:(

When using 2277 I have no errors, when using 2277 with the new closure lib 
release I have some "undefined" errors. That usually means some sort of 
renaming gone wrong.

Error:
Cannot read property 'apply' of undefined 

Code in question:
b.prototype[c].apply(a,k)

Haven't yet figured which code that actually is.

-- 
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: ClojureScript 0.0-2277

2014-07-30 Thread Thomas Heller
Geez, 2277 actually works just fine. 2234 doesn't work, but it actually doesn't 
work with either closure-library version. Forgot that I reverted to 2234 due to 
the keyword issue.

2277 + [org.clojure/google-closure-library "0.0-20140718-946a7d39"]

seems fine, except for that keyword issue.

Sorry about the confusion, I will shut up now until I have something solid.

-- 
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: Help Getting Sente to Work

2014-07-30 Thread Timothy Washington
Hey Peter,

Responses are inlined.


On Tue, Jul 29, 2014 at 12:51 AM, Peter Taoussanis 
wrote:

> Wrt the CSRF issue, I'll try running again without it.
>>
>
> Out of curiosity, sure - but if you've already gone to the effort of
> setting up the CSRF I'd leave it in (better to have it) :-)
>

Yep, I agree ;)


>
>
>> Now, a port changed fixed the issue for me. But before I passed in a
>> *chsk-url-fn*, I was still getting a 404, even when trying with a
>> browser (ie, using the correct port).
>>
>
> Not sure about that, may be that something in your setup is tripping up
> the default `chsk-url-fn`. Would appreciate a GitHub issue on it and I'll
> take a closer look - may be a bug.
>

Ok, new github issues is here
.


>
> That 404 went away when I included the CSRF middleware. I still had to
>> pass in a custom *chsk-url-fn*, but I could use it through the browser,
>> for example.
>>
>
> My guess is that the 404 is going away because you're passing in a custom
> `chsk-url-fn`, not because of the CSRF middleware. I.e. it's a broken chsk
> url that's causing the 404, not anything to do with the CSRF.
>

Actually, that 404 did go away when I included the CSRF middleware. And
that's weird, I'll admit, because the webserver was not running on
*ws://172.28.128.5:58269/chsk
*.

However, I was still experiencing the broken chsk channel. That's when I
included the custom *chsk-url-fn*. The tricky thing, I think, is that the
browser-repl uses a different port (i default browser-repl is 9000, ii.
austin's browser-repl port changes each session), than the running http-kit
server (8090). So when *make-channel-socket!* calls chsk-url-fn

(which is the *default-chsk-url-fn*), (encore/get-window-location)

is
returning the URL with the browser-repl's port. I'm not sure how you'd get
around that if you're using a browser-repl, vs just running in a plain
browser runtime. Seems to come down to the behaviour of (.-location
js/window)

(in
*encore/get-window-location*). Ie, in my browser-repl, invoking `*(.-location
js/window)*` gives me "http://*172.28.128.5:33283/347
*/repl/start?...", (not
http://*172.28.128.5:8090
*/...).

cljs.user> (.-location js/window)




#<
http://172.28.128.5:33283/347/repl/start?xpc=%7B%22cn%22%3A%222qJDPo7hur%22%2C%22tp%22%3Anull%2C%22osh%22%3Anull%2C%22ppu%22%3A%22http%3A%2F%2F172.28.128.5%3A8090%2Frobots.txt%22%2C%22lpu%22%3A%22http%3A%2F%2F172.28.128.5%3A33
\

283%2Frobots.txt%22%7D>




> And I'm just grokking the false `*websocket?`* allowance now. Ie, an
>> https ajax connection would give me a sente URL of 
>> "*wws://172.28.128.5:8090/chsk
>> *". Is that right? What about plain http?
>>
>
> The `chsk-url-fn` will be called with:
> 1. The path as given to the client-side `make-channel-socket!` fn (usu.
> "/chsk").
> 2. A window location map of the current page.
> 3. A bool indicating whether Sente is requesting a WebSocket (true) or
> Ajax (false) connection.
>
> From these, your fn will need to produce an URL that matches your
> server-side channel socket route.
>
> For WebSocket connections you'll want the URL to start with "ws://"
> (insecure) or "wss://" (secure).
> For Ajax connections you'll want the URL to start with "http://";
> (insecure) or "https://"; (secure).
>
> I wouldn't stress too much about that though - let's start with a GitHub
> issue since it's quite possible I can mod the default fn to cover your
> use-case automatically. Ideally you shouldn't need to fiddle with any of
> this :-)
>
> Cheers!
>
>
Nice one - thanks Peter.


Tim Washington
Interruptsoftware.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.


Redefined 'count' produces no warning

2014-07-30 Thread Meel Velliste
I had code that looked like this:

(let [{count  :count
   data   :data} (fetch-data)
  real-count (count data)])



As you can see, I was inadvertently redefining the 'count' symbol, and then 
tried to use the core 'count' function.
I thought the compiler usually warned about this sort of thing. But 
instead, it gave me a java.lang.NullPointerException with no further 
explanatory message. At least it told me the line of code where it was 
happening.

It took me a few minutes to figure out what was happening because the real 
code had a lot more details in it, so it was not immediately easy to see. 
It was a bit frustrating. I wonder if it would be possible to have the 
compiler issue a warning in cases like this? I am not necessarily saying it 
should issue a warning every time 'count' gets redefined, but if I then try 
to use it the way that the core function would be used, I would like it to 
produce a warning.

-- 
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: timbre logging, java libs

2014-07-30 Thread Brian Craft
Very useful, thanks! I was considering just dropping timbre, or extracting 
the profiling macros. The main things I use from timbre are the profiling 
macros.

I found Stuart's post about the original contrib profiling macros being a 
half-baked idea, but I'm unaware of a usable alternative. GUIs like 
visualvm are only good for spot-checking, not for logging performance vs. a 
few thousand use cases, for example, or for keeping a slow-query log. Are 
there other scriptable profiling solutions?

On Friday, July 25, 2014 1:55:49 PM UTC-7, Hugo Duncan wrote:
>
>
> craft...@gmail.com  writes: 
>
> > Is there any good way to use timbre in a project with java libs, e.g. 
> c3p0, 
> > that use java logging APIs? 
>
> You might want to look at: 
>
>   http://ptaoussanis.github.io/timbre/taoensso.timbre.tools.logging.html 
>   
> https://github.com/palletops/log-config#user-content-timbre-and-java-logging 
>
> If you set up tools.logging to use your preferred java logging 
> implementation, then timbre can log to it. 
>
> Hugo 
>

-- 
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: Redefined 'count' produces no warning

2014-07-30 Thread Andy Fingerhut
This would be an appropriate kind of check for a lint tool like Eastwood to
make, and warn about.  It currently does not do so, but I've created an
issue to remind me of the potential enhancement. [1]

It is up to the Clojure core team to decide whether they would like to make
such a change to the Clojure compiler itself.  My guess is that since this
is legal Clojure code, and sometimes people do this in their code
intentionally (i.e. use let-bound names that happen to match Var names in
clojure.core and other namespaces), they might prefer _not_ to have the
compiler issue such a warning.  Note these words: "my guess".  I have no
inside knowledge here.

Andy

[1] https://github.com/jonase/eastwood/issues/81


On Wed, Jul 30, 2014 at 9:34 AM, Meel Velliste 
wrote:

> I had code that looked like this:
>
> (let [{count  :count
>data   :data} (fetch-data)
>   real-count (count data)])
>
>
>
> As you can see, I was inadvertently redefining the 'count' symbol, and
> then tried to use the core 'count' function.
> I thought the compiler usually warned about this sort of thing. But
> instead, it gave me a java.lang.NullPointerException with no further
> explanatory message. At least it told me the line of code where it was
> happening.
>
> It took me a few minutes to figure out what was happening because the real
> code had a lot more details in it, so it was not immediately easy to see.
> It was a bit frustrating. I wonder if it would be possible to have the
> compiler issue a warning in cases like this? I am not necessarily saying it
> should issue a warning every time 'count' gets redefined, but if I then try
> to use it the way that the core function would be used, I would like it to
> produce a warning.
>
> --
> 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: Redefined 'count' produces no warning

2014-07-30 Thread Sean Corfield
FWIW we have several places where the obvious local name shadows a core 
function - so the existing behavior is both desirable (IMO) and in existing 
production usage. I would not want to see that changed :)

Eastwood seems like the correct place for this (Eastwood has continued to 
detect bugs in our code and peculiarities - that are not bugs but should be 
rewritten for clarity - so I'd heartily recommend it to everyone).

Sean

On Jul 30, 2014, at 10:32 AM, Andy Fingerhut  wrote:
> This would be an appropriate kind of check for a lint tool like Eastwood to 
> make, and warn about.  It currently does not do so, but I've created an issue 
> to remind me of the potential enhancement. [1]
> 
> It is up to the Clojure core team to decide whether they would like to make 
> such a change to the Clojure compiler itself.  My guess is that since this is 
> legal Clojure code, and sometimes people do this in their code intentionally 
> (i.e. use let-bound names that happen to match Var names in clojure.core and 
> other namespaces), they might prefer _not_ to have the compiler issue such a 
> warning.  Note these words: "my guess".  I have no inside knowledge here.
> 
> Andy
> 
> [1] https://github.com/jonase/eastwood/issues/81
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: ANN: ClojureScript 0.0-2277

2014-07-30 Thread Francis Avila
FYI, using the :psuedo-names compiler option is very handy for debugging 
advanced-compile munging issues, e.g.:

 :compiler {:optimizations :advanced
:pseudo-names true
...}



On Wednesday, July 30, 2014 10:11:17 AM UTC-5, Thomas Heller wrote:
> Geez, 2277 actually works just fine. 2234 doesn't work, but it actually 
> doesn't work with either closure-library version. Forgot that I reverted to 
> 2234 due to the keyword issue.
> 
> 
> 
> 2277 + [org.clojure/google-closure-library "0.0-20140718-946a7d39"]
> 
> 
> 
> seems fine, except for that keyword issue.
> 
> 
> 
> Sorry about the confusion, I will shut up now until I have something solid.

-- 
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] Re: ANN: ClojureScript 0.0-2277

2014-07-30 Thread David Nolen
Based on this information it sounds like the new Google Closure
artifacts are good to go. The keyword thing we'll have to address in a
subsequent release. It would be useful to know what Mobile Safari
clients you see being affected.

David

On Wed, Jul 30, 2014 at 11:11 AM, Thomas Heller  wrote:
> Geez, 2277 actually works just fine. 2234 doesn't work, but it actually 
> doesn't work with either closure-library version. Forgot that I reverted to 
> 2234 due to the keyword issue.
>
> 2277 + [org.clojure/google-closure-library "0.0-20140718-946a7d39"]
>
> seems fine, except for that keyword issue.
>
> Sorry about the confusion, I will shut up now until I have something solid.
>
> --
> Note that posts from new members are moderated - please be patient with your 
> first post.
> ---
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

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


Future termination

2014-07-30 Thread Serzh Nechyporchuk
Hello. I have a problems using code with futures. For example, if I run 
following code:

java -jar clojure-1.6.0.jar -e "(println 1)"

the process prints 1 and terminates.
But when I'm trying to run code with futures:

java -jar clojure-1.6.0.jar -e "(future 1)"

the process doesn't terminates.

This has real implication when I run some task using 

lein run -m some-ns/fun args

If code above uses futures then this process will not terminate. This is 
really frustrating.

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


Enterprise Integration Using SOAP Web Services an Clojure

2014-07-30 Thread Timur
Hi everyone,

Are there any libraries other than clj-soap for implementing SOAP 
Web-Services? 

Regards,

Timur

-- 
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: Future termination

2014-07-30 Thread Andy Fingerhut
Never is an awfully long time :-)  If you wait about 60 seconds, the
command you gave calling (future 1) does terminate, at least on Mac OS X
10.8.5 where I tested it, and I have seen the same behavior on Linux and I
think Windows.

This version terminates much more quickly:

java -jar clojure-1.6.0.jar -e "(future 1) (shutdown-agents)"

There is some discussion of this issue at the ClojureDocs page for the
function 'future', including that this issue affects pmap and
clojure.java.shell/sh, too, because are both implemented using futures:

http://clojuredocs.org/clojure_core/clojure.core/future

It also includes a link to a Clojure ticket suggesting that this behavior
change.  You can vote on it if you like (requires a Clojure JIRA account,
which you can create by clicking on the "Log In" link near the top right of
the page):

http://dev.clojure.org/jira/browse/CLJ-124

Andy



On Wed, Jul 30, 2014 at 12:33 PM, Serzh Nechyporchuk  wrote:

> Hello. I have a problems using code with futures. For example, if I run
> following code:
>
> java -jar clojure-1.6.0.jar -e "(println 1)"
>
> the process prints 1 and terminates.
> But when I'm trying to run code with futures:
>
> java -jar clojure-1.6.0.jar -e "(future 1)"
>
> the process doesn't terminates.
>
> This has real implication when I run some task using
>
> lein run -m some-ns/fun args
>
> If code above uses futures then this process will not terminate. This is
> really frustrating.
>
> --
> 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: Redefined 'count' produces no warning

2014-07-30 Thread Colin Fleming
Yeah, I do this all the time as well (in Cursive, I frequently have things
with names like 'symbol' and 'list' for example), but it does bite me when
I later refactor or copy some code around. I'm not sure what criteria I'd
want used for this warning - attempting to invoke a local binding that had
something clearly not invokable (string etc) assigned to it? It's tough
though, very rarely do you have enough type information to make those
decisions.


On 30 July 2014 19:37, Sean Corfield  wrote:

> FWIW we have several places where the obvious local name shadows a core
> function - so the existing behavior is both desirable (IMO) and in existing
> production usage. I would not want to see that changed :)
>
> Eastwood seems like the correct place for this (Eastwood has continued to
> detect bugs in our code and peculiarities - that are not bugs but should be
> rewritten for clarity - so I'd heartily recommend it to everyone).
>
> Sean
>
> On Jul 30, 2014, at 10:32 AM, Andy Fingerhut 
> wrote:
>
> This would be an appropriate kind of check for a lint tool like Eastwood
> to make, and warn about.  It currently does not do so, but I've created an
> issue to remind me of the potential enhancement. [1]
>
> It is up to the Clojure core team to decide whether they would like to
> make such a change to the Clojure compiler itself.  My guess is that since
> this is legal Clojure code, and sometimes people do this in their code
> intentionally (i.e. use let-bound names that happen to match Var names in
> clojure.core and other namespaces), they might prefer _not_ to have the
> compiler issue such a warning.  Note these words: "my guess".  I have no
> inside knowledge here.
>
> Andy
>
> [1] https://github.com/jonase/eastwood/issues/81
>
>
>

-- 
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: Redefined 'count' produces no warning

2014-07-30 Thread Andy Fingerhut
My first thought at a lint implementation was simply "warn if a let-bound
name matches any Var name in clojure.core", although granted that could
produce more false positives than you want.

The linter could be enabled by default, and experienced folks could disable
it completely.

Alternately, when I get around to implementing source code annotations to
disable individual warnings, one could mark the ones that they know are ok,
but that could get more tedious than simply disabling the check globally.

Andy


On Wed, Jul 30, 2014 at 1:17 PM, Colin Fleming 
wrote:

> Yeah, I do this all the time as well (in Cursive, I frequently have things
> with names like 'symbol' and 'list' for example), but it does bite me when
> I later refactor or copy some code around. I'm not sure what criteria I'd
> want used for this warning - attempting to invoke a local binding that had
> something clearly not invokable (string etc) assigned to it? It's tough
> though, very rarely do you have enough type information to make those
> decisions.
>
>
> On 30 July 2014 19:37, Sean Corfield  wrote:
>
>> FWIW we have several places where the obvious local name shadows a core
>> function - so the existing behavior is both desirable (IMO) and in existing
>> production usage. I would not want to see that changed :)
>>
>> Eastwood seems like the correct place for this (Eastwood has continued to
>> detect bugs in our code and peculiarities - that are not bugs but should be
>> rewritten for clarity - so I'd heartily recommend it to everyone).
>>
>> Sean
>>
>> On Jul 30, 2014, at 10:32 AM, Andy Fingerhut 
>> wrote:
>>
>> This would be an appropriate kind of check for a lint tool like Eastwood
>> to make, and warn about.  It currently does not do so, but I've created an
>> issue to remind me of the potential enhancement. [1]
>>
>> It is up to the Clojure core team to decide whether they would like to
>> make such a change to the Clojure compiler itself.  My guess is that since
>> this is legal Clojure code, and sometimes people do this in their code
>> intentionally (i.e. use let-bound names that happen to match Var names in
>> clojure.core and other namespaces), they might prefer _not_ to have the
>> compiler issue such a warning.  Note these words: "my guess".  I have no
>> inside knowledge here.
>>
>> Andy
>>
>> [1] https://github.com/jonase/eastwood/issues/81
>>
>>
>>
>  --
> 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: Redefined 'count' produces no warning

2014-07-30 Thread Sean Corfield
On Jul 30, 2014, at 1:37 PM, Andy Fingerhut  wrote:
> My first thought at a lint implementation was simply "warn if a let-bound 
> name matches any Var name in clojure.core", although granted that could 
> produce more false positives than you want.

Yeah, I'd just disable that globally for our code base.

I think Colin's suggestion is solid, if you can do it. I don't think we shadow 
a core function with a local function anywhere and such attempted calls would 
almost certainly be bugs - or at least indicate a better function name was 
needed.

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

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2277

2014-07-30 Thread Thomas Heller
I posted some User Agents in the other Thread.

https://groups.google.com/d/msg/clojurescript/diRGgGmTXPk/bbNMj3XHQ4AJ

Mozilla/5.0 (iPad; CPU OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, 
like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53
Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) 
AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 
Safari/9537.53
Mozilla/5.0 (Linux; U; Android 4.1.2; de-de; GT-N8010 Build/JZO54K) 
AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30

Got some more in the log if you need them.

HTH

On Wednesday, July 30, 2014 8:57:51 PM UTC+2, David Nolen wrote:
>
> Based on this information it sounds like the new Google Closure 
> artifacts are good to go. The keyword thing we'll have to address in a 
> subsequent release. It would be useful to know what Mobile Safari 
> clients you see being affected. 
>
> David 
>
> On Wed, Jul 30, 2014 at 11:11 AM, Thomas Heller  > wrote: 
> > Geez, 2277 actually works just fine. 2234 doesn't work, but it actually 
> doesn't work with either closure-library version. Forgot that I reverted to 
> 2234 due to the keyword issue. 
> > 
> > 2277 + [org.clojure/google-closure-library "0.0-20140718-946a7d39"] 
> > 
> > seems fine, except for that keyword issue. 
> > 
> > Sorry about the confusion, I will shut up now until I have something 
> solid. 
> > 
> > -- 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "ClojureScript" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojurescrip...@googlegroups.com . 
> > To post to this group, send email to clojur...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/clojurescript. 
>

-- 
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] Re: ANN: ClojureScript 0.0-2277

2014-07-30 Thread David Nolen
Can you please list the affected clients on this ticket
http://dev.clojure.org/jira/browse/CLJS-830, thanks!

David

On Wed, Jul 30, 2014 at 5:29 PM, Thomas Heller  wrote:
> I posted some User Agents in the other Thread.
>
> https://groups.google.com/d/msg/clojurescript/diRGgGmTXPk/bbNMj3XHQ4AJ
>
> Mozilla/5.0 (iPad; CPU OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML,
> like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53
> Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2
> (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53
> Mozilla/5.0 (Linux; U; Android 4.1.2; de-de; GT-N8010 Build/JZO54K)
> AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30
>
> Got some more in the log if you need them.
>
> HTH
>
> On Wednesday, July 30, 2014 8:57:51 PM UTC+2, David Nolen wrote:
>>
>> Based on this information it sounds like the new Google Closure
>> artifacts are good to go. The keyword thing we'll have to address in a
>> subsequent release. It would be useful to know what Mobile Safari
>> clients you see being affected.
>>
>> David
>>
>> On Wed, Jul 30, 2014 at 11:11 AM, Thomas Heller  wrote:
>> > Geez, 2277 actually works just fine. 2234 doesn't work, but it actually
>> > doesn't work with either closure-library version. Forgot that I reverted to
>> > 2234 due to the keyword issue.
>> >
>> > 2277 + [org.clojure/google-closure-library "0.0-20140718-946a7d39"]
>> >
>> > seems fine, except for that keyword issue.
>> >
>> > Sorry about the confusion, I will shut up now until I have something
>> > solid.
>> >
>> > --
>> > Note that posts from new members are moderated - please be patient with
>> > your first post.
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups "ClojureScript" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to clojurescrip...@googlegroups.com.
>> > To post to this group, send email to clojur...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/clojurescript.
>
> --
> Note that posts from new members are moderated - please be patient with your
> first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
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: Clojure on Cloudbees versus Heroku?

2014-07-30 Thread Mark Engelberg
My experience is that Cloudbees' free tier works better than Heroku's and
is somewhat easier to deploy (with cloudbees you just upload a war file
that you've built on your machine, whereas on Heroku, you are checking
files into git which are built server-side, and if the build doesn't quite
work properly on their machine but it does work on yours, it can be
difficult to track down what's going on).

I believe that Heroku's lowest cost priced tier is cheaper than Cloudbees',
but it has been a while since I've compared the two.


On Wed, Jul 30, 2014 at 4:40 AM, Jonathon McKitrick 
wrote:

> I've deployed a few apps to Heroku, but I'm always looking for new options
> with better pricing or features.
>
> Is there any reason Cloudbees might be better for Clojure apps than
> Heroku?  If the big selling point of Cloudbees is Jenkins, I don't think
> that benefits Clojure projects, right?
>
> --
> 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: Clojure on Cloudbees versus Heroku?

2014-07-30 Thread Jonathon McKitrick
Did you deploy clojure apps?

On Wednesday, July 30, 2014, Mark Engelberg 
wrote:

> My experience is that Cloudbees' free tier works better than Heroku's and
> is somewhat easier to deploy (with cloudbees you just upload a war file
> that you've built on your machine, whereas on Heroku, you are checking
> files into git which are built server-side, and if the build doesn't quite
> work properly on their machine but it does work on yours, it can be
> difficult to track down what's going on).
>
> I believe that Heroku's lowest cost priced tier is cheaper than
> Cloudbees', but it has been a while since I've compared the two.
>
>
> On Wed, Jul 30, 2014 at 4:40 AM, Jonathon McKitrick  > wrote:
>
>> I've deployed a few apps to Heroku, but I'm always looking for new
>> options with better pricing or features.
>>
>> Is there any reason Cloudbees might be better for Clojure apps than
>> Heroku?  If the big selling point of Cloudbees is Jenkins, I don't think
>> that benefits Clojure projects, right?
>>
>> --
>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/k_bOLXXCAn8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

--
Jonathon McKitrick

-- 
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: Clojure on Cloudbees versus Heroku?

2014-07-30 Thread Mark Engelberg
Yes.


On Wed, Jul 30, 2014 at 5:18 PM, Jonathon McKitrick 
wrote:

> Did you deploy clojure apps?
>
>
> On Wednesday, July 30, 2014, Mark Engelberg 
> wrote:
>
>> My experience is that Cloudbees' free tier works better than Heroku's and
>> is somewhat easier to deploy (with cloudbees you just upload a war file
>> that you've built on your machine, whereas on Heroku, you are checking
>> files into git which are built server-side, and if the build doesn't quite
>> work properly on their machine but it does work on yours, it can be
>> difficult to track down what's going on).
>>
>> I believe that Heroku's lowest cost priced tier is cheaper than
>> Cloudbees', but it has been a while since I've compared the two.
>>
>>
>> On Wed, Jul 30, 2014 at 4:40 AM, Jonathon McKitrick > > wrote:
>>
>>> I've deployed a few apps to Heroku, but I'm always looking for new
>>> options with better pricing or features.
>>>
>>> Is there any reason Cloudbees might be better for Clojure apps than
>>> Heroku?  If the big selling point of Cloudbees is Jenkins, I don't think
>>> that benefits Clojure projects, right?
>>>
>>> --
>>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/k_bOLXXCAn8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> --
> Jonathon McKitrick
>
>  --
> 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: Help Getting Sente to Work

2014-07-30 Thread Peter Taoussanis

>
> Ok, new github issues is here 
>> .
>>
>
Great, thanks - will follow up there later today! 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.