Re: why is it so annoying to run clojure code

[hiskennyness]

On Saturday, June 11, 2016 at 6:19:06 AM UTC-4, Cornelius Goh wrote:
>
> Just for curiosity. What mobile phone (Android or iOS) did you port your 
> CommonLisp libraries onto ?


I did Andoid since Cordova said it could not build for iOS on Linux, but up 
soon on my do-list is dusting off my Mac Pro and doing an iOS version.

-kt 

-- 
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: instrumenting clojure.core

[Leon Grapenthin]

Thank Alistair, but that does not really address my question. Alex 
suggested using :fn of fspec to check arity of a higher-order argument.

But I could not find a tool to check function arity. Also I doubt :fn is 
going to work since I'd expect it to be invoked /after/ the call - i. e. 
the call would fail before the arity check.

Note that in your example you can only use spec/generic testing to check 
arity because you know the argument types. You can't test a generic higher 
order fn for just arity like this because the generator won't know the 
correct types to generate.

On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:
>
> Hi Leon,
>
> I think you're looking for fspec 
> ,
>  
> unless I'm misunderstanding something. I wrote up an example 
>  that 
> might be helpful.
>
> @Ryan thanks for starting this thread, and @Alex thanks for responding. 
> It's been an interesting discussion!
>
> Cheers,
>
>
> On Monday, 13 June 2016 07:17:56 UTC+10, Leon Grapenthin wrote:
>>
>> Alex, thank you for the long and detailed response.
>>
>> The direct linking issue and Ryans last example make me wonder whether 
>> the hard rule
>>
>> "If A and B are both instrumented and if A ever calls B violating B's 
>> spec, A's spec is broken" 
>>
>> holds? If so the direct-linking issue would probably be  a non-concern 
>> since instrumentation within the standard library would not matter because 
>> one could assume that the core lib has been tested already against it's own 
>> specs. If the latter is true (I'm not quite sure) it would appear 
>> worthwhile to look for a counter-example against the former in the standard 
>> library.
>>
>> I'd highly appreciate if you could give an example for checking the arity 
>> of a passed in function since I don't see how to do that right now except 
>> for maybe using reflection?
>>
>> On Sunday, June 12, 2016 at 5:45:17 PM UTC+2, Alex Miller wrote:
>>>
>>>
>>> On Sunday, June 12, 2016 at 9:22:24 AM UTC-5, Leon Grapenthin wrote:

 That looks great already. I'm also interested in what the official 
 workflow for adding specs to core is going to be and whether contributions 
 are desired.

>>>
>>> Still much to be determined about this but I expect that specs for core 
>>> will be provided and maintained by us, because while there are a lot of 
>>> obvious specs in core, there are also a lot of far more subtle ones. Some 
>>> of the predicates added in the latest alpha5 (seqable?, and the 
>>> simple/qualified ident/keyword/symbol) will not coincidentally be useful in 
>>> these. There are also a lot of cases where there is a judgement call on how 
>>> precise to be (any likely tradeoffs with testing, performance, conciseness).
>>>
>>> Also, there is a significant difference between specs for macros and 
>>> functions in core. Macro args specs will always be checked during 
>>> macroexpansion and this is a path toward better error messages for things 
>>> like defn, ns, etc. I think it would make a lot of sense to deliver those 
>>> with core. Specs for the functions in core are things you likely want 
>>> instrumented at dev time, not at prod time, and fights a bit with direct 
>>> linking. So, one option would be a dev build of Clojure, without direct 
>>> linking and with automatic instrumentation of the functions in core. 
>>> Another would be providing the core function specs externally or optionally 
>>> alongside Clojure. We've only begun discussing how this will wind up.
>>>
>>> I don't agree with the map spec provided because I expect the args and 
>>> ret to be seqable?, not sequential?. For example, you can map over sets, 
>>> which are seqable but not sequential. This kind of subtlety is why I expect 
>>> we will provide the specs for core. Once they exist, we'll be interested in 
>>> tickets on them of course.
>>>
>>> There are also interesting :fn specs you can write on map - you could 
>>> check that if the count of the coll args is 0 that the return is ifn? (a 
>>> transducer) and that if there is at least one coll then the ret is a coll. 
>>> If the colls are all finite, the return coll will have count equal to the 
>>> minimum of the count of the arg colls. I think the transducer/coll 
>>> difference is definitely worth spec'ing and would trigger errors in cases 
>>> where some forgets the coll and accidentally gets a transducer. Is the 
>>> cardinality check worth it? Probably not.
>>>
>>> identity could have a :fn spec that checks that the input and output are 
>>> identical. That's really the only thing you care about (other than the 
>>> cardinality of the input). Is this spec really helping you though? Not 
>>> every spec pays for it's weight and this may be one that isn't worth doing.
>>>  
>>>
 The last example seems like it could be better because the user has to 
>>

Re: why is it so annoying to run clojure code

[hiskennyness]

I do not know if I have the right direction*, but qooxdoo was the 
low-hanging fruit for me because I have a ton of experience wrapping its 
so-called "Desktop" variant (Web RIAs) so... it is now pretty easy to build 
a mobile** app in CLJS/qx.Mobile***.

* I will look at ReactNative next, though my Cells library offers the same 
declarative power with the same minimum DOM manipulation. That said, React 
is pretty popular, so I will take a look.

** I started with Android, but after writing up what I have done so far I 
will dust off my Mac and give iOS a go.

*** In a few hours I will start fleshing out the read-me 
here: https://github.com/kennytilton/rube. That is just my 
dataflow/modelling library, but for now the qooxdoo wrapper Qxia is in 
there as a demo project. (I find Cells hard to motivate without a 
substantial problem to solve, and UIs are good for that.) If there is 
interest I will split off Qxia from Rube/Cells and get them up on Clojars.

-kt





On Saturday, June 11, 2016 at 9:42:21 AM UTC-4, Erlis Vidal wrote:
>
> +1
>
> Irrelevant for the current thread but I'm too really curious on how to 
> start using Clojure for mobile development. Anything that can point us on 
> the right direction? 
>
> On Sat, Jun 11, 2016 at 6:19 AM, Cornelius Goh  > wrote:
>
>> Just for curiosity. What mobile phone (Android or iOS) did you port your 
>> CommonLisp libraries onto ?
>>
>> --
>> 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: clojure.spec and the rest of clojure

[Patrick Kristiansen]

Hi

For your first question, have a look at this thread:

https://groups.google.com/forum/#!topic/clojure/d_3V9MfLZmY

- Patrick

On Monday, June 13, 2016 at 8:18:30 AM UTC+2, Philip Markgraf wrote:
>
> Rich's session on the Cognicast brought up interesting questions for me.
>
> - Is Clojure.spec being applied within clojure.core and other parts of the 
> language?
> - Has the test.check capability led to the discovery of bugs in 
> clojure.core and other parts of the language?
> - Does anyone (else) anticipate that test.check testing of clojure.core 
> and other libraries _will_ lead to bug discoveries.
>
> I am guessing that spreading clojure.spec across the historic code base is 
> a non-trivial effort. Is it something that will be receiving focus from the 
> greater team in the coming months? It does seem like a worthwhile effort.
>
> Thanks!
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What I'm missing in my Instaparse rules?

[Hussein B.]

Thanks for your help.

I tried this new grammar to match characters only:

"

TEST = OBJECT

 = <#'\\s+'>

OBJECT = CURLY_OPEN WHITESPACE* STRING WHITESPACE* (WHITESPACE* OBJECT 
WHITESPACE*)* CURLY_CLOSE

 = <'{'>

 = <'}'>

STRING = #'[a-zA-Z]'

"


(parse "{harden {James}}")


Parse error at line 1, column 3:

{harden {James}}

  ^

Expected one of:

"}" (followed by end-of-string)

"{"

#"\s+"

On Sunday, June 12, 2016 at 10:07:01 PM UTC+2, puzzler wrote:
>
> Regular expressions are treated with their ordinary Java/Clojure, greedy 
> semantics.
>
> Your regular expression for ITEM doesn't exclude whitespace or } 
> characters, so ITEM is matching "Harden }" which leaves no characters left 
> to match your grammar's right curly brace requirement.
>
> => (re-seq #"[^\"]+" "Harden }")
> ("Harden }")
>
> A solution would be to make the regex for ITEM more restrictive.
>
> On Sun, Jun 12, 2016 at 12:52 PM, Hussein B.  > wrote:
>
>> Hello,
>>
>> I'm playing around Instaparse library, starting very simple.
>>
>> For input like :
>>
>> { player }
>>
>> I created the following parser:
>>
>> (def ast
>>   (ist/parser
>> "TEST = OBJECT
>>  = <#'\\s+'>
>>  = <'{'>
>>  = <'}'>
>> ITEM = #'[^\"]+'
>> OBJECT = CURLY_OPEN WHITESPACE* ITEM WHITESPACE* CURLY_CLOSE"))
>>
>>
>> In the REPL:
>>
>> user=> (ast "{ Harden } ")
>>
>> Parse error at line 1, column 12:
>>
>> { Harden } 
>>
>>^
>>
>> Expected one of:
>>
>> "}" (followed by end-of-string)
>>
>> #"\s+"
>>
>>
>> Any ideas what I'm doing wrong?
>>
>> Thanks for help.
>>
>> -- 
>> 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: What I'm missing in my Instaparse rules?

[Mark Engelberg]

Looks like you left off a + in your regular expression for String.

On Mon, Jun 13, 2016 at 2:59 AM, Hussein B.  wrote:

> Thanks for your help.
>
> I tried this new grammar to match characters only:
>
> "
>
> TEST = OBJECT
>
>  = <#'\\s+'>
>
> OBJECT = CURLY_OPEN WHITESPACE* STRING WHITESPACE* (WHITESPACE* OBJECT
> WHITESPACE*)* CURLY_CLOSE
>
>  = <'{'>
>
>  = <'}'>
>
> STRING = #'[a-zA-Z]'
>
> "
>
>
> (parse "{harden {James}}")
>
>
> Parse error at line 1, column 3:
>
> {harden {James}}
>
>   ^
>
> Expected one of:
>
> "}" (followed by end-of-string)
>
> "{"
>
> #"\s+"
>
> On Sunday, June 12, 2016 at 10:07:01 PM UTC+2, puzzler wrote:
>>
>> Regular expressions are treated with their ordinary Java/Clojure, greedy
>> semantics.
>>
>> Your regular expression for ITEM doesn't exclude whitespace or }
>> characters, so ITEM is matching "Harden }" which leaves no characters left
>> to match your grammar's right curly brace requirement.
>>
>> => (re-seq #"[^\"]+" "Harden }")
>> ("Harden }")
>>
>> A solution would be to make the regex for ITEM more restrictive.
>>
>> On Sun, Jun 12, 2016 at 12:52 PM, Hussein B.  wrote:
>>
>>> Hello,
>>>
>>> I'm playing around Instaparse library, starting very simple.
>>>
>>> For input like :
>>>
>>> { player }
>>>
>>> I created the following parser:
>>>
>>> (def ast
>>>   (ist/parser
>>> "TEST = OBJECT
>>>  = <#'\\s+'>
>>>  = <'{'>
>>>  = <'}'>
>>> ITEM = #'[^\"]+'
>>> OBJECT = CURLY_OPEN WHITESPACE* ITEM WHITESPACE* CURLY_CLOSE"))
>>>
>>>
>>> In the REPL:
>>>
>>> user=> (ast "{ Harden } ")
>>>
>>> Parse error at line 1, column 12:
>>>
>>> { Harden }
>>>
>>>^
>>>
>>> Expected one of:
>>>
>>> "}" (followed by end-of-string)
>>>
>>> #"\s+"
>>>
>>>
>>> Any ideas what I'm doing wrong?
>>>
>>> Thanks for help.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What I'm missing in my Instaparse rules?

[Hussein B.]

Oh my ...

You saved my hair! :)

Thanks a lot for your help and time.

On Monday, June 13, 2016 at 12:03:54 PM UTC+2, puzzler wrote:
>
> Looks like you left off a + in your regular expression for String.
>
> On Mon, Jun 13, 2016 at 2:59 AM, Hussein B.  > wrote:
>
>> Thanks for your help.
>>
>> I tried this new grammar to match characters only:
>>
>> "
>>
>> TEST = OBJECT
>>
>>  = <#'\\s+'>
>>
>> OBJECT = CURLY_OPEN WHITESPACE* STRING WHITESPACE* (WHITESPACE* OBJECT 
>> WHITESPACE*)* CURLY_CLOSE
>>
>>  = <'{'>
>>
>>  = <'}'>
>>
>> STRING = #'[a-zA-Z]'
>>
>> "
>>
>>
>> (parse "{harden {James}}")
>>
>>
>> Parse error at line 1, column 3:
>>
>> {harden {James}}
>>
>>   ^
>>
>> Expected one of:
>>
>> "}" (followed by end-of-string)
>>
>> "{"
>>
>> #"\s+"
>>
>> On Sunday, June 12, 2016 at 10:07:01 PM UTC+2, puzzler wrote:
>>>
>>> Regular expressions are treated with their ordinary Java/Clojure, greedy 
>>> semantics.
>>>
>>> Your regular expression for ITEM doesn't exclude whitespace or } 
>>> characters, so ITEM is matching "Harden }" which leaves no characters left 
>>> to match your grammar's right curly brace requirement.
>>>
>>> => (re-seq #"[^\"]+" "Harden }")
>>> ("Harden }")
>>>
>>> A solution would be to make the regex for ITEM more restrictive.
>>>
>>> On Sun, Jun 12, 2016 at 12:52 PM, Hussein B.  wrote:
>>>
 Hello,

 I'm playing around Instaparse library, starting very simple.

 For input like :

 { player }

 I created the following parser:

 (def ast
   (ist/parser
 "TEST = OBJECT
  = <#'\\s+'>
  = <'{'>
  = <'}'>
 ITEM = #'[^\"]+'
 OBJECT = CURLY_OPEN WHITESPACE* ITEM WHITESPACE* CURLY_CLOSE"))


 In the REPL:

 user=> (ast "{ Harden } ")

 Parse error at line 1, column 12:

 { Harden } 

^

 Expected one of:

 "}" (followed by end-of-string)

 #"\s+"


 Any ideas what I'm doing wrong?

 Thanks for help.

 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

cljsbuild hangs with foreign-libs using letsencrypt

[Elric Erkose]

Recently I switched my local cdn from http to https with letsencrypt. I had 
to provide a trust store ( :jvm-opts ["-Djavax.net.ssl.trustStore=...) 
because java won't support letsencrypt until "JDK 8u102 is scheduled to be 
released in July 2016". After changing the protocol from "http" to "https" 
and adding the "jvm-opts" to my project.clj, lein cljsbuild auto hangs. I 
verified it fetches the foreign-libs. Also, if I change the foreign-libs 
protocol to "file" everything works. Has anyone experienced this?

-- 
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: cljsbuild hangs with foreign-libs using letsencrypt

[Daniel Compton]

AFAICT cljsbuild doesn’t do anything special with the :foreign-libs key and
passes it straight to the compiler. Can you reproduce this issue against
the bare ClojureScript compiler?

On Tue, Jun 14, 2016 at 4:58 AM Elric Erkose  wrote:

> Recently I switched my local cdn from http to https with letsencrypt. I
> had to provide a trust store ( :jvm-opts ["-Djavax.net.ssl.trustStore=...)
> because java won't support letsencrypt until "JDK 8u102 is scheduled to be
> released in July 2016". After changing the protocol from "http" to "https"
> and adding the "jvm-opts" to my project.clj, lein cljsbuild auto hangs. I
> verified it fetches the foreign-libs. Also, if I change the foreign-libs
> protocol to "file" everything works. Has anyone experienced this?
>
> --
> 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.
>
-- 
—
Daniel

-- 
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] core.async 0.2.382

[Alex Miller]

core.async 0.2.382 is now available.

Try it via:  [org.clojure/core.async "0.2.382"]

0.2.382 includes the following changes:

- Change default dispatch thread pool max size to 8.
- Add Java system property clojure.core.async.pool-size to override the 
dispatch thread pool max size
- ASYNC-152 - disable t.a.jvm's warn-on-reflection pass

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

lazy-cat's memoization obscuring runtime exceptions

[Sebastian Oberhoff]

The following lines are copied straight from tryclj.com

> (def expexp (lazy-cat [2] (map #(* % %) expexp)))
#'sandbox20298/expexp
> (take 100 expexp)
java.lang.ArithmeticException: integer overflow
> (take 100 expexp)
(2 4 16 256 65536 4294967296)

I'm wondering if this behavior is known, because I was really surprised by 
this. Couldn't this lead to some really subtle bugs downstream?

(I just went back to doublecheck and now I'm getting an unbound var for 
expexp on tryclj.com. It still behaves like this on my local machine 
though.)

-- 
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: lazy-cat's memoization obscuring runtime exceptions

[Gary Trakhman]

What's surprising about this?  Maybe you want the promoting *' variant:

> (def expexp (lazy-cat [2] (map #(*' % %) expexp)))
#'sandbox21201/expexp
> (take 100 expexp)
Execution Timed Out!

Seems like it's a big number :-)


On Mon, Jun 13, 2016 at 4:27 PM Sebastian Oberhoff <
oberhoff.sebast...@gmail.com> wrote:

> The following lines are copied straight from tryclj.com
>
> > (def expexp (lazy-cat [2] (map #(* % %) expexp)))
> #'sandbox20298/expexp
> > (take 100 expexp)
> java.lang.ArithmeticException: integer overflow
> > (take 100 expexp)
> (2 4 16 256 65536 4294967296)
>
> I'm wondering if this behavior is known, because I was really surprised by
> this. Couldn't this lead to some really subtle bugs downstream?
>
> (I just went back to doublecheck and now I'm getting an unbound var for
> expexp on tryclj.com. It still behaves like this on my local machine
> though.)
>
> --
> 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: lazy-cat's memoization obscuring runtime exceptions

[Alex Miller]

I'm not aware of a ticket on it, feel free to file one.

tryclj dumps your session periodically and you'll lose any vars you've 
defined.

On Monday, June 13, 2016 at 3:27:54 PM UTC-5, Sebastian Oberhoff wrote:
>
> The following lines are copied straight from tryclj.com
>
> > (def expexp (lazy-cat [2] (map #(* % %) expexp)))
> #'sandbox20298/expexp
> > (take 100 expexp)
> java.lang.ArithmeticException: integer overflow
> > (take 100 expexp)
> (2 4 16 256 65536 4294967296)
>
> I'm wondering if this behavior is known, because I was really surprised by 
> this. Couldn't this lead to some really subtle bugs downstream?
>
> (I just went back to doublecheck and now I'm getting an unbound var for 
> expexp on tryclj.com. It still behaves like this on my local machine 
> though.)
>

-- 
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: lazy-cat's memoization obscuring runtime exceptions

[Sebastian Oberhoff]

What's surprising is that I executed a pure function twice in succession 
and got different results. Furthermore the second execution papers over an 
exception.

-- 
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: lazy-cat's memoization obscuring runtime exceptions

[Gary Trakhman]

Ah, sorry I missed that the first time around.

There's something similar going on with lazy-seq.

user=> (defn the-seq
  #_=>   ([] (the-seq 2))
  #_=>   ([a] (cons (* a a) (lazy-seq (the-seq (* a a))

user=> (def s (the-seq))
#'user/s
user=> (take 100 s)

ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow
(Numbers.java:1501)
user=> (take 100 s)
NullPointerException   clojure.lang.Numbers.ops (Numbers.java:1013)

I think in practice, you stop passing around the seq after the first
exception, you're encouraged not to hold on to heads of seqs, so this
shouldn't get triggered.

On Mon, Jun 13, 2016 at 4:54 PM Sebastian Oberhoff <
oberhoff.sebast...@gmail.com> wrote:

> What's surprising is that I executed a pure function twice in succession
> and got different results. Furthermore the second execution papers over an
> exception.
>
> --
> 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: lazy-cat's memoization obscuring runtime exceptions

[Fluid Dynamics]

On Monday, June 13, 2016 at 4:38:47 PM UTC-4, Gary Trakhman wrote:
>
> What's surprising about this?  Maybe you want the promoting *' variant:
>
> > (def expexp (lazy-cat [2] (map #(*' % %) expexp)))
> #'sandbox21201/expexp
> > (take 100 expexp)
> Execution Timed Out!
>
> Seems like it's a big number :-)
>

Since the number of digits is near-doubling each time, the final value 
would have nearly 2^100 ~ 10^31, over a nonillion. The memory requirements 
are easier still -- the first five iterates need a 32-bit word apiece, 
after that the number needed keeps doubling, to 2^96 for the last one. 
That's going to be about an octillion bytes. If it hadn't timed out it 
would have thrown OOME ... eventually.

-- 
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] core.async 0.2.382

[Fluid Dynamics]

On Monday, June 13, 2016 at 4:14:25 PM UTC-4, Alex Miller wrote:
>
> core.async 0.2.382 is now available.
>
> Try it via:  [org.clojure/core.async "0.2.382"]
>
> 0.2.382 includes the following changes:
>
> - Change default dispatch thread pool max size to 8.
> - Add Java system property clojure.core.async.pool-size to override the 
> dispatch thread pool max size
>

Why 8, rather than, say, (.availableProcessors (Runtime/getRuntime))?

-- 
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: cljsbuild hangs with foreign-libs using letsencrypt

[Elric Erkose]

I downloaded cljs.jar, but I don't know how to specify :dependencies which 
currently reside in project.clj. The documentation seems to only address 
compiler options. The build failed because it couldn't locate dependencies.

On Monday, June 13, 2016 at 12:46:32 PM UTC-7, Daniel Compton wrote:
>
> AFAICT cljsbuild doesn’t do anything special with the :foreign-libs key 
> and passes it straight to the compiler. Can you reproduce this issue 
> against the bare ClojureScript compiler?
> Daniel
>

-- 
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] mustache.clojure 0.3.0

[Bill Robertson]

Hello, 


I've released 0.3.0 of mustache.clojure. It's a Clojure adapter for 
mustache.java, which performs well and has good adherence to the mustache 
spec (with the exception of whitespace).


Version 0.3.0 adds mustache spec compliance equal to mustache.java.


https://github.com/billrobertson42/mustache.clojure




Thanks! 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: instrumenting clojure.core

[Alistair Roche]

Oh, I see what you mean now, Leon. Apologies for not reading more closely!
Yours is a much more interesting puzzle.

Here's an attempt I made
, groping
towards it using reflection, but I couldn't even get that to work. Would be
curious to see what the solution is there, and even more so (like you) to
see if it can be done without reflection.

On 13 June 2016 at 17:21, Leon Grapenthin  wrote:

> Thank Alistair, but that does not really address my question. Alex
> suggested using :fn of fspec to check arity of a higher-order argument.
>
> But I could not find a tool to check function arity. Also I doubt :fn is
> going to work since I'd expect it to be invoked /after/ the call - i. e.
> the call would fail before the arity check.
>
> Note that in your example you can only use spec/generic testing to check
> arity because you know the argument types. You can't test a generic higher
> order fn for just arity like this because the generator won't know the
> correct types to generate.
>
>
> On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:
>>
>> Hi Leon,
>>
>> I think you're looking for fspec
>> ,
>> unless I'm misunderstanding something. I wrote up an example
>>  that
>> might be helpful.
>>
>> @Ryan thanks for starting this thread, and @Alex thanks for responding.
>> It's been an interesting discussion!
>>
>> Cheers,
>>
>>
>> On Monday, 13 June 2016 07:17:56 UTC+10, Leon Grapenthin wrote:
>>>
>>> Alex, thank you for the long and detailed response.
>>>
>>> The direct linking issue and Ryans last example make me wonder whether
>>> the hard rule
>>>
>>> "If A and B are both instrumented and if A ever calls B violating B's
>>> spec, A's spec is broken"
>>>
>>> holds? If so the direct-linking issue would probably be  a non-concern
>>> since instrumentation within the standard library would not matter because
>>> one could assume that the core lib has been tested already against it's own
>>> specs. If the latter is true (I'm not quite sure) it would appear
>>> worthwhile to look for a counter-example against the former in the standard
>>> library.
>>>
>>> I'd highly appreciate if you could give an example for checking the
>>> arity of a passed in function since I don't see how to do that right now
>>> except for maybe using reflection?
>>>
>>> On Sunday, June 12, 2016 at 5:45:17 PM UTC+2, Alex Miller wrote:


 On Sunday, June 12, 2016 at 9:22:24 AM UTC-5, Leon Grapenthin wrote:
>
> That looks great already. I'm also interested in what the official
> workflow for adding specs to core is going to be and whether contributions
> are desired.
>

 Still much to be determined about this but I expect that specs for core
 will be provided and maintained by us, because while there are a lot of
 obvious specs in core, there are also a lot of far more subtle ones. Some
 of the predicates added in the latest alpha5 (seqable?, and the
 simple/qualified ident/keyword/symbol) will not coincidentally be useful in
 these. There are also a lot of cases where there is a judgement call on how
 precise to be (any likely tradeoffs with testing, performance, 
 conciseness).

 Also, there is a significant difference between specs for macros and
 functions in core. Macro args specs will always be checked during
 macroexpansion and this is a path toward better error messages for things
 like defn, ns, etc. I think it would make a lot of sense to deliver those
 with core. Specs for the functions in core are things you likely want
 instrumented at dev time, not at prod time, and fights a bit with direct
 linking. So, one option would be a dev build of Clojure, without direct
 linking and with automatic instrumentation of the functions in core.
 Another would be providing the core function specs externally or optionally
 alongside Clojure. We've only begun discussing how this will wind up.

 I don't agree with the map spec provided because I expect the args and
 ret to be seqable?, not sequential?. For example, you can map over sets,
 which are seqable but not sequential. This kind of subtlety is why I expect
 we will provide the specs for core. Once they exist, we'll be interested in
 tickets on them of course.

 There are also interesting :fn specs you can write on map - you could
 check that if the count of the coll args is 0 that the return is ifn? (a
 transducer) and that if there is at least one coll then the ret is a coll.
 If the colls are all finite, the return coll will have count equal to the
 minimum of the count of the arg colls. I think the transducer/coll
 difference is definitely worth spec'ing and would trigger errors in cases
 w

Re: [ANN] Clojure 1.9.0-alpha5

[Jason Wolfe]

The warning should be fixed in schema 1.1.2.

-Jason

On Monday, June 13, 2016 at 10:46:09 AM UTC+8, Josh Tilles wrote:
>
> On Sunday, June 12, 2016 at 10:29:56 PM UTC-4, Alan Thompson wrote:
>>
>> I would have expected the namespaces to avoid this kind of conflict. Why 
>> don't they?
>>
>
> Because the conflict was only introduced five days ago, with this commit 
> .
>  
> Up until that point, the maintainers of Schema had no reason to include 
> Inst in schema.core’s exclusions 
> 
> .
> I’d guess that they’d welcome a pull request that silences the 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.

[ANN] cljsee 0.1.0

[Alex Engelberg]

https://github.com/aengelberg/cljsee

Cljsee is a Leiningen plugin that applies the idea of cljx to the new cljc 
reader conditional format. In other words, as a build step, it parses .cljc 
files and outputs .clj and/or .cljs files with only the relevant code. The 
purpose of this library is to enable library maintainers to write cljc 
code, and expressively target multiple platforms from a single file, but 
maintain compatibility with Clojure 1.6 and below in which reader 
conditionals are not supported.

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

CUFP 2016 Call For Tutorials

[roman]

Hi all,

The Commercial Users of Functional Programming (CUFP) 2016 has its Call for 
Tutorials open for submission. 

CUFP 2016 is being held in the historic city of Nara, Japan. The conference 
is devoted to showcase the state of the art of Functional Programming on 
industrial settings.  This conference is co-located with the International 
Conference of Functional Programming (ICFP).

We're looking for tutors that would like to host workshops on on the 
following themes:

- Introductions to functional programming languages. In the past we have 
had sessions of Clojure, Erlang, F#, F*, Haskell, ML, OCaml, Scala, Scheme 
and others.

- Advanced programming languages, concepts and applications (e.g. Lens, 
Liquid-Haskell, Agda, Idris, etc.)

- Applying functional programming in particular areas, including Web, 
high-performance computing, finance.

- Tools and techniques supporting state of the art functional programming. 
In the past we have had tutorials on QuickCheck, Elm and others.

- Theory. Type theory, category theory, abstract algebra, ongoing or new 
research, and anything useful or interesting to functional programmers.

If you'd like to submit a proposal, just fill this form 
http://goo.gl/forms/qoyK9qYPZhiDPSzO2.

More info can be found at http://cufp.org/2016/call-for-tutorials.html

Regards,

Roman Gonzalez.

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