Re: Clojure advent calendar: call for contributions

[James Laver]

(bump)

At the minute, including myself there are five volunteers. If we don't get 
a few more, we just won't have enough material to do this, which would be a 
shame.

Come on clojure community, we can do this!

/j

On Sunday, October 9, 2016 at 2:00:41 PM UTC, James Laver wrote:
>
> Hi all,
>
> In the model of http://perladvent.org/2015/ and many other "let's look at 
> a programming shiny every day" projects, I thought I'd try to do a clojure 
> advent this year. The overall theme for this year is planned to be a 
> showcase libraries available on clojars, so every day we'll do something 
> practical/fun/astonishing/elegant with a library or two from clojars.
>
> If you're interested in contributing a day, please let me know offlist. 
> Let your imagination run wild and let's get some people wanting clojure 
> books for christmas!
>
> Cheers,
> James
>

-- 
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] permissions - role & permission based access control

[Torsten Uhlmann]

@larry I added bitmask permissions to
https://github.com/tuhlmann/permissions together with a set of unit tests
and a description in Readme. Please have a look if you like.

I don't think I will ever use it as I'm quiet content with the literal
approach. But it was an interesting exercise to separate concerns in order
to make the library more flexible and not more complex at the same time.

Kind Regards,
Torsten.


 schrieb am Do., 13. Okt. 2016 um 14:50 Uhr:

> My suggestion of a bitmask was just a response to a suggestion of prime
> factorization for encoding roles in an integer. I think using a set is just
> fine. The space requirements for a small set of keywords is negligible in
> the larger scheme of things. It also permits more readable code (always a
> good thing) with bits of code that need to interact with it.
>
>
> On Thursday, October 13, 2016 at 7:56:10 AM UTC-4, Torsten Uhlmann wrote:
>
> It might be premature optimization, or you could view it as a different
> approach, for a different usage scenario.
> I'm myself pretty content with the literal approach, we're using this in a
> fairly large application and haven't experienced any problems with regards
> of performance or amount of data attached to users so far.
>
> On the other hand I see these suggestions as a way to experiment with
> alternative approaches, which might as well teach me something...
>
> Stefan Kamphausen  schrieb am Do., 13. Okt. 2016 um
> 10:29 Uhr:
>
> Hi,
>
> Doesn't that feel like premature optimization to you, too?  Bitmasks are
> much harder to read than sets with spelled out roles and I wonder if the
> performance gain is really worth that. And it poses a limit of 64 roles.  I
> have seen several enterprise applications that had far more than 64 roles
> and/or permissions.
>
> Or am I missing something here?
>
> Just my 2ct.
>
> Kind regards,
> Stefan
>
> --
> 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: Clojure advent calendar: call for contributions

[Borkdude]

I posted this call for contributors to Reddit. Maybe there are many people 
like me there, who don't read this group regularly. 
Anyway, it seems a fun idea. Count me in. 

On Saturday, October 15, 2016 at 10:59:07 AM UTC+2, James Laver wrote:
>
> (bump)
>
> At the minute, including myself there are five volunteers. If we don't get 
> a few more, we just won't have enough material to do this, which would be a 
> shame.
>
> Come on clojure community, we can do this!
>
> /j
>
> On Sunday, October 9, 2016 at 2:00:41 PM UTC, James Laver wrote:
>>
>> Hi all,
>>
>> In the model of http://perladvent.org/2015/ and many other "let's look 
>> at a programming shiny every day" projects, I thought I'd try to do a 
>> clojure advent this year. The overall theme for this year is planned to be 
>> a showcase libraries available on clojars, so every day we'll do something 
>> practical/fun/astonishing/elegant with a library or two from clojars.
>>
>> If you're interested in contributing a day, please let me know offlist. 
>> Let your imagination run wild and let's get some people wanting clojure 
>> books for christmas!
>>
>> Cheers,
>> James
>>
>

-- 
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 advent calendar: call for contributions

[Borkdude]

I posted this call for contributors to Reddit. Maybe there are many people 
like me there, who don't read this group regularly. 

Anyway, it seems a fun idea. Count me in. 

-- 
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] clj-xchart – A charting/plotting library for Clojure

[Jean Niklas L'orange]

Hi Clojurians,

I am happy to announce clj-xchart ! 
XChart  is a lightweight charting
library for Java. clj-xchart wraps this library and tries to be a
succinct yet evident charting library for Clojure. The library can
emit the following chart types:

- Line charts
- Scatter charts
- Area charts
- Bar charts
- Histogram charts
- Pie charts
- Donut charts
- Bubble charts
- Stick charts

It also provides the following useful features:

- Easy to compare, view and make charts from a REPL
- Logarithmic axes
- Number, Date and Category X-Axis
- Export to png, gif, jpg, svg, pdf and eps
- Extensive customisation

Note that clj-xchart is a Clojure only library; if you need
interactive or animated charts in a web browser, then this library
will not help you with that. However, if you need png/jpg/svg/pdfs of
charts, then this may be a viable option.

To see a couple of example charts, along with the code required to
generate them, head over to the examples page 
.

The tutorial 
 for 
the current release should give you a good
introduction in how to use the library, and the render options page 

page has additional information about how to style the charts. The
majority of all commits and work has been related to examples and
documentation, and I hope this will make the library easy to use.

The source code is over at https://github.com/hyPiRion/clj-xchart

Suggestions and contributions are welcome!

-- Jean Niklas

-- 
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] boot-bundle, DRY for dependencies

[Borkdude]

Only a few lines of code, but it does the job:

https://github.com/borkdude/boot-bundle

This library lets you define a set of dependencies by a keyword. Details in 
the README.

I found it especially useful in a multi-project repo where we use a lot of 
the same dependencies in each project. 
It's also possible to share your personal bundle via Clojars and use it in 
your personal projects.

-- 
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: Liberator with ring-cors

[Sean Johnson]

Kenny,

Take a look at this repo: https://github.com/open-company/open-company-api

We're using Liberator with: [jumblerg/ring.middleware.cors "1.0.1"]

Works fine...

The middleware handles the CORs portion of the response:

https://github.com/open-company/open-company-api/blob/mainline/src/open_company/app.clj#L51

And then we handle the methods portion of the response with standard 
Liberator stuff:

https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/common.clj#L23
https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/common.clj#L170
https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/common.clj#L191
https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/common.clj#L197
https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/companies.clj#L123
https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/companies.clj#L129
https://github.com/open-company/open-company-api/blob/mainline/src/open_company/api/companies.clj#L140

Cheers,
Sean



On Friday, October 14, 2016 at 12:21:34 PM UTC-4, Kenny Liu wrote:
>
> Yep, I tried a non-liberator POST, and it went through perfectly. So right 
> now it seems like liberator is doing something wonky to my 
> requests/responses.
>
> On Friday, October 14, 2016 at 8:22:29 PM UTC+8, Kenny Liu wrote:
>>
>> Anyone know if this all works out of the box? Preflight OPTIONS is 200 
>> but the GET/POST fails. My attempt to get it working:
>>
>> (def app
>>   "Order must be reversed. See: 
>> http://stackoverflow.com/q/19455801/894091";
>>   (-> (bidi/make-handler v1-routes)
>>   (wrap-defaults api-defaults)
>>   (wrap-cors :access-control-allow-origin [#".*"]
>>  :access-control-allow-headers ["Host"
>> "User-Agent"
>> "Accept"
>> "Accept-Language"
>> "Accept-Encoding"
>> "Content-Type"
>> "Referer"
>> "Content-Length"
>> "Origin"
>> "Connection"
>> "Pragma"
>> "Cache-Control"]
>>  :access-control-allow-methods [:get :put :post :delete
>> ])))
>>
>> http://stackoverflow.com/q/39789487/894091
>>
>> Based on https://github.com/clojure-liberator/liberator/issues/76, I 
>> suspect it might be liberator messing with something. I'm pretty stumped.
>>
>

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

Any interest in a data-driven build tool?

[James Reeves]

I've been playing around with an idea for a new build tool that I'm
currently calling "Hop", and I was wondering if there was any interest from
the community.

I've gotten the barest minimum working here:
https://github.com/weavejester/hop

Hop uses a data-driven build file, and rather than executing tasks
directly, it builds a bash script which is then cached and executed. If the
build file remains the same, Hop uses the cached script directly.

After the cache is established, this should make Hop faster than Leiningen,
while maintaining process isolation. It also opens up the possibility of
preloading a pool of VMs to get around load times.

I'll be working on this every so often whenever I'm between projects, but
if anyone else wants to get involved, I've set up some issues for features
that should be good starting points.

- James

-- 
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: Any interest in a data-driven build tool?

[Colin Yates]

I can't offer any time unfortunately but you can certainly have a
chunk of my interest - will be fascinating to see how this pans out.

On 15 October 2016 at 15:46, James Reeves  wrote:
> I've been playing around with an idea for a new build tool that I'm
> currently calling "Hop", and I was wondering if there was any interest from
> the community.
>
> I've gotten the barest minimum working here:
> https://github.com/weavejester/hop
>
> Hop uses a data-driven build file, and rather than executing tasks directly,
> it builds a bash script which is then cached and executed. If the build file
> remains the same, Hop uses the cached script directly.
>
> After the cache is established, this should make Hop faster than Leiningen,
> while maintaining process isolation. It also opens up the possibility of
> preloading a pool of VMs to get around load times.
>
> I'll be working on this every so often whenever I'm between projects, but if
> anyone else wants to get involved, I've set up some issues for features that
> should be good starting points.
>
> - James
>
> --
> 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.

Possible ClojureScript compiler issue...

[John Szakmeister]

I've been using ClojureScript rather successfully for a year now, but
ran into an interesting issue recently.

I've discovered that js->clj isn't quite working as expected.  After
quite a bit of tearing things down and apart, I discovered it was one
of the keys in some JSON data coming back from the server that looks
like:

"Bi": 8

And the resultant error would be:

No protocol method IEncodeClojure.-js->clj defined for type
object: [object Object]

I don't know why this particular sequence caused a problem, but I
ended trying to vary things a bit just to see what happens.  If I use:

"Bi": 0

I don't see the issue.  Any non-zero value though does seem to bring
the problem about for this sequence of letters though.  Similarly, I
tried varying the two letter sequence, and discovered two others with
similar problems: Ai, and ba.  The latter brought about a different
error:

[object Object] is not ISeqable

And the pattern with the value needing to be non-zero follows.  If the
value associated with the key is 0, then I don't see a problem.

As I wasn't seeing this issue before, I backpedaled my version of the
ClojureScript compiler and eventually found that 1.9.56 didn't seem to
sufffer from the problem.  After checking out ClojureScript, and
bisecting more I found that commit
bcf60ce194e5292fbc5c4b2d89dfc5a7b886b94c is when the behavior changed
from behaving correctly to behaving badly, but I think it's a false
positive.

I then created a much smaller test case, with no other libraries
involved.  This time it's a different set of values that are broken:

* "Ta" with a non-zero value gives: [object Object] is not ISeqable

* "Ub" with a non-zero value gives: No protocol method
IEmptyableCollection.-empty defined for type object: [object Object]

* "Wb" with a non-zero value gives: No protocol method
IEncodeClojure.-js->clj defined for type object: [object Object]

If I back up to before the previously mentioned commit, I can still
cause the problem, though the letter sequences change a bit.

Also, this only appears to happen with advanced optimizations.  With
no optimizations or with whitespace optimizations, there's no issues.
So it smells like a strange interaction between the ClojureScript
runtime and the compiler.

Has anyone seen an issue like this before?  Does anyone have any ideas
what is going on?  We have these short keys in our data, and it'd be
pretty painful to make them something else (especially since the names
are meaningful to those in the know, despite them being cryptic--they
refer to bit settings on various motors).

I'd be happy to file a ticket, if that's what needs to get done too.

Thanks!

-John

PS Here's the code I used to hunt down problematic keys:

(def alphabet [\a \b \c \d \e \f \g \h \i \j \k \l \m \n \o \p \q \r \s \t \u
   \v \w \x \y \z \A \B \C \D \E \F \G \H \I \J \K \L \M \N \O \P
   \Q \R \S \T \U \V \W \X \Y \Z])

(enable-console-print!)

(defn ^:export main-page []
  (println"Starting...")
  (doseq [c1 alphabet
  c2 alphabet
  i  (range 256)]
(let [s (str "{\"" c1 c2 "\": " i "}")]
  (try
;; (prn :parse-s (js/JSON.parse s))
;; (prn :js-clj-parse (js->clj (js/JSON.parse s)))
(js->clj (js/JSON.parse s))
(catch js/Error e
  (println "didn't work" s (str e
   ))
  (println "Done!"))

Then you can observe the results from the JS console.

-- 
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] graphql-clj: An Clojure library provides GraphQL implementation

[Lei]

Hi All,

I am pleased to announce the release of graphql-clj, a library that
provides GraphQL implementation.

https://github.com/tendant/graphql-clj

For those who are not familiar with GraphQL. GraphQL is a query language
for APIs and a runtime for fulfilling those queries with your existing
data. For more details about GraphQL: http://graphql.org.

There is also a starter project for you to try graphql-clj and GraphiQL in
3 minutes.

https://github.com/tendant/graphql-clj-starter

graphql-clj is a native Clojure implementation of GraphQL specification (
http://facebook.github.io/graphql/).

Things have been implemented so far:

1. A parser using instaparse. It supports both GraphQL schema and query.

2. A schema system represent GraphQL type system.

3. A validator using clojure.spec. (Special thanks to Edward Wible)

4. An execution engine supports GraphQL query and mutation.

5. Introspection query support.

Thanks a lot to Edward Wible for his significant contribution on all parts
of this library.

This is library was made possible with contributions of:

   - Edward Wible
   - Marcin Kulik
   - Feifan Zhou
   - Oleh Palianytsia
   - David Adair
   - Yannick Scherer

This library is under active development. Any feedback is welcome,
especially github PR and issues.

Cheers,
Lei

-- 
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] graphql-clj: An Clojure library provides GraphQL implementation

[Lei]

Hi All, 

I am pleased to announce the release of graphql-clj, a library that 
provides GraphQL implementation in Clojure.

https://github.com/tendant/graphql-clj

For those who are not familiar with GraphQL. GraphQL is a query language 
for APIs and a runtime for fulfilling those queries with your existing 
data. For more details about GraphQL: http://graphql.org. 

There is also a starter project for you to try graphql-clj and GraphiQL in 
3 minutes. 

https://github.com/tendant/graphql-clj-starter

graphql-clj is a native Clojure implementation of GraphQL specification (
http://facebook.github.io/graphql/).

Things have been implemented so far:

1. A parser using instaparse. It supports both GraphQL schema and query.

2. A schema system represent GraphQL type system.

3. A validator using clojure.spec. (Special thanks to Edward Wible)

4. An execution engine supports GraphQL query and mutation.

5. Introspection query support.

Thanks a lot to Edward Wible for his significant contribution on all parts 
of this library. 

This is library was made possible with contributions of: 

   - Edward Wible
   - Marcin Kulik
   - Feifan Zhou
   - Oleh Palianytsia
   - David Adair
   - Yannick Scherer

This library is under active development. Any feedback is welcome, 
especially github PR and issues. 

Cheers,
Lei

-- 
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: Possible ClojureScript compiler issue...

[David Nolen]

This issue is somewhat to be expected if you're going to use `js->clj`.
This issue has nothing to do with ClojureScript compiler versions - you
just got lucky before. Google Closure will collapse properties, but some of
these collapsed properties are going to be used to determine protocol
membership. That's it.

I suggest just avoiding `js->clj` and using your own simple helper for
recursively converting JSON into Clojure values. Changing the (admittedly
questionable) behavior of `js->clj` will only lead to more breakage.

HTH,
David

On Sat, Oct 15, 2016 at 11:43 AM, John Szakmeister 
wrote:

> I've been using ClojureScript rather successfully for a year now, but
> ran into an interesting issue recently.
>
> I've discovered that js->clj isn't quite working as expected.  After
> quite a bit of tearing things down and apart, I discovered it was one
> of the keys in some JSON data coming back from the server that looks
> like:
>
> "Bi": 8
>
> And the resultant error would be:
>
> No protocol method IEncodeClojure.-js->clj defined for type
> object: [object Object]
>
> I don't know why this particular sequence caused a problem, but I
> ended trying to vary things a bit just to see what happens.  If I use:
>
> "Bi": 0
>
> I don't see the issue.  Any non-zero value though does seem to bring
> the problem about for this sequence of letters though.  Similarly, I
> tried varying the two letter sequence, and discovered two others with
> similar problems: Ai, and ba.  The latter brought about a different
> error:
>
> [object Object] is not ISeqable
>
> And the pattern with the value needing to be non-zero follows.  If the
> value associated with the key is 0, then I don't see a problem.
>
> As I wasn't seeing this issue before, I backpedaled my version of the
> ClojureScript compiler and eventually found that 1.9.56 didn't seem to
> sufffer from the problem.  After checking out ClojureScript, and
> bisecting more I found that commit
> bcf60ce194e5292fbc5c4b2d89dfc5a7b886b94c is when the behavior changed
> from behaving correctly to behaving badly, but I think it's a false
> positive.
>
> I then created a much smaller test case, with no other libraries
> involved.  This time it's a different set of values that are broken:
>
> * "Ta" with a non-zero value gives: [object Object] is not ISeqable
>
> * "Ub" with a non-zero value gives: No protocol method
> IEmptyableCollection.-empty defined for type object: [object Object]
>
> * "Wb" with a non-zero value gives: No protocol method
> IEncodeClojure.-js->clj defined for type object: [object Object]
>
> If I back up to before the previously mentioned commit, I can still
> cause the problem, though the letter sequences change a bit.
>
> Also, this only appears to happen with advanced optimizations.  With
> no optimizations or with whitespace optimizations, there's no issues.
> So it smells like a strange interaction between the ClojureScript
> runtime and the compiler.
>
> Has anyone seen an issue like this before?  Does anyone have any ideas
> what is going on?  We have these short keys in our data, and it'd be
> pretty painful to make them something else (especially since the names
> are meaningful to those in the know, despite them being cryptic--they
> refer to bit settings on various motors).
>
> I'd be happy to file a ticket, if that's what needs to get done too.
>
> Thanks!
>
> -John
>
> PS Here's the code I used to hunt down problematic keys:
>
> (def alphabet [\a \b \c \d \e \f \g \h \i \j \k \l \m \n \o \p \q \r \s \t
> \u
>\v \w \x \y \z \A \B \C \D \E \F \G \H \I \J \K \L \M \N \O
> \P
>\Q \R \S \T \U \V \W \X \Y \Z])
>
> (enable-console-print!)
>
> (defn ^:export main-page []
>   (println"Starting...")
>   (doseq [c1 alphabet
>   c2 alphabet
>   i  (range 256)]
> (let [s (str "{\"" c1 c2 "\": " i "}")]
>   (try
> ;; (prn :parse-s (js/JSON.parse s))
> ;; (prn :js-clj-parse (js->clj (js/JSON.parse s)))
> (js->clj (js/JSON.parse s))
> (catch js/Error e
>   (println "didn't work" s (str e
>))
>   (println "Done!"))
>
> Then you can observe the results from the JS console.
>
> --
> 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 Go

Re: Possible ClojureScript compiler issue...

[John Szakmeister]

On Sat, Oct 15, 2016 at 2:49 PM, David Nolen  wrote:
> This issue is somewhat to be expected if you're going to use `js->clj`. This
> issue has nothing to do with ClojureScript compiler versions - you just got
> lucky before. Google Closure will collapse properties, but some of these
> collapsed properties are going to be used to determine protocol membership.
> That's it.

Wow.  I did not that expect that at all.  It makes sense, but it's unfortunate.

> I suggest just avoiding `js->clj` and using your own simple helper for
> recursively converting JSON into Clojure values. Changing the (admittedly
> questionable) behavior of `js->clj` will only lead to more breakage.

I'll definitely look at alternatives.  It'd be nice if js->clj had
documentation on this shortcoming though, and perhaps pointers to
better alternatives.

Thanks for the help David!

-John

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

Java like static typing for Clojure?

[Didier]

I know a lot of people like to say how unhelpful Java like static typing 
is, and only more powerful type systems of the ML family add value, but 
I've been wondering recently if for Clojure it wouldn't make more sense to 
simply extend the type hints to enable an optional Java like static typing 
scheme.

It is my understanding that ML style static typing is incredibly difficult 
to add properly and without compromise to a dynamic language. That doing so 
limits the scope of type inference, rendering the task of adding type info 
more tedious then in ML languages themselves.

ML style static typing provide enhanced safety grantees, but seem to add 
too much complexity to Clojure to be practical. What about a Java like 
static typing scheme though?

I haven't found in practice that the safety of Clojure was an issue, as the 
REPL workflow tend to promote quite a lot of testing. So I'm not too 
worried about needing the state of the art of provable correctness for my 
programs. What has been a biggest cause of issue to me was refactoring and 
shared code base across a team. Those last two use cases are actually 
pretty well handled by Java like static type checking. Is it a powerful 
type checker, not really, but it enables most trivial type errors to be 
caught early, and it allows easier integration points for other devs to 
follow, as well as documentation for functions, better tools support and 
easier refactoring, while also enabling performance optimizations.

I have limited knowledge in typing systems, and have no idea how easy it is 
to implement them, but as a user of Clojure, I feel like I would find an 
optional Java like static typing a great addition, one that I am more 
willing to use and benefit from then Typed Clojure's more complex ML style 
type checking.

What do other think?
Can anyone with better knowledge tell me if this would be feasible or if 
adding such gradual typing system is effectively as hard as adding ML style 
type checking?

-- 
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 advent calendar: call for contributions

[Yehonathan Sharvit]

I'm in also. I'd love to present this amazing 
lib https://github.com/ztellman/automat

On Saturday, 15 October 2016 14:26:47 UTC+3, Borkdude wrote:
>
> I posted this call for contributors to Reddit. Maybe there are many people 
> like me there, who don't read this group regularly. 
>
> Anyway, it seems a fun idea. Count me in. 
>

-- 
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: Possible ClojureScript compiler issue...

[Antonin Hildebrand]

Unfortunately, this problem is not specific to `js->clj` only.

I believe in general under :advanced optimizations, any object which was 
created or modified by a code which 
was not subject of the same closure compiler optimization pass could 
exhibit similar problems when used with ClojureScript core functions like 
`satisfies?`.

That also includes working with external data (your case), and working with 
objects created/modified by adding properties by string names.

To illustrate, I created a screenshot of cljs type instance with two 
protocols, to see the internals in dev mode:
https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
In the selected text I highlighted part of generated code for `satisfies?` 
call.

ClojureScript adds/checks $cljs prefixed properties to objects. These 
internal properties get renamed by closure compiler.
So any object which happens to have one of those renamed names 
independently added as their property will potentially confuse functions 
like `satisfies?`.

Possible solutions I see:

1. use string names for clojurescript internal properties, and avoid 
clashes by using "unique-enough" prefix even in advanced mode - still not 
safe solution, but would minimize clash chances

or 

2. start tracking which objects belong to cljs land, have one 
"unique-enough" string name as a marker, clojurescript functions like 
satisfies? would check this marker before proceeding further. Still dirty, 
one could clobber cljs properties by modifying a cljs-land-object from 
unaware Javascript code. And this would probably change behaviour of some 
existing code.

or

3. use prototypal inheritance and "hide" all ClojureScript internal 
properties in a new link in the prototype chain, plain javascript objects 
would miss this link so it could be easily detected, properties would not 
clash even if they got same names. ClojureScript functions like satisfies? 
would properly
walk the chain and read properties from proper link which belongs only to 
ClojureScript. Ale we would not need any special "magic" marker - the 
Javascript type of the link in prototype would safely identify it.
I believe this would be correct solution. But I guess, this would be too 
dramatic change in ClojureScript internals and might break a lot of other 
things I currently don't understand. Also performance could get a hit.

Better ideas, anyone? :-)

ps. don't use :advanced mode when programming atomic reactors in 
ClojureScript ;-p

On Saturday, October 15, 2016 at 10:59:14 PM UTC+2, John Szakmeister wrote:
>
> On Sat, Oct 15, 2016 at 2:49 PM, David Nolen  > wrote: 
> > This issue is somewhat to be expected if you're going to use `js->clj`. 
> This 
> > issue has nothing to do with ClojureScript compiler versions - you just 
> got 
> > lucky before. Google Closure will collapse properties, but some of these 
> > collapsed properties are going to be used to determine protocol 
> membership. 
> > That's it. 
>
> Wow.  I did not that expect that at all.  It makes sense, but it's 
> unfortunate. 
>
> > I suggest just avoiding `js->clj` and using your own simple helper for 
> > recursively converting JSON into Clojure values. Changing the 
> (admittedly 
> > questionable) behavior of `js->clj` will only lead to more breakage. 
>
> I'll definitely look at alternatives.  It'd be nice if js->clj had 
> documentation on this shortcoming though, and perhaps pointers to 
> better alternatives. 
>
> Thanks for the help David! 
>
> -John 
>

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

Guidelines/Recommendations for namespaces and qualified keywords

[Josh Tilles]

I’ve got a couple questions for Alex Miller and/or the other Cognitect 
folks.

   1. *Are single-segment namespaces still “bad” when it comes to 
   registering specs under qualified keywords?*
   In the past, single-segment namespaces have been discouraged in the 
   Clojure community—both because of Java interop concerns and because of the 
   possibility of name-collision when combining projects. However, many of the 
   spec examples I’ve seen have demonstrated registering specs under keywords 
   qualified by a single-segment namespace. For example, the guide’s 
   section on multi-spec  
   defines :search/url and :error/message. Is that because 
   namespace-qualifiers of specs shouldn’t be under the same constraints as 
   namespaces used to organize code? I’m *guessing* not; it seems more 
   likely that the single-segment namespaces have been used only to keep the 
   code snippets straightforward and focused on spec, and that “real” code 
   would alias (e.g.) my-company.my-project.search as search before 
   defining a ::search/url spec.
   
   2. *When designing, how do you decide whether to use a simple keyword or 
   a qualified one?*
   There’s an interesting mix of the two in the official docs and in the 
   code for spec itself. For example: the spec rationale 
    and guide 
    both use simple keywords 
   when labeling path components, and spec reports invocation errors for 
   instrumented functions with maps that exclusively use qualified keys at the 
   “root” but simple keywords appear as values 
   

 
   and as keys in nested maps 
   

   .

Thank you for your help. I really appreciate it.

Best,
Josh

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

Java like static typing for Clojure?

[A. Levy]

Have you heard of Typed Clojure? (http://typedclojure.org)

It is an optional, gradual type system for Clojure. Does it offer enough to be 
useful or are you looking for something different?

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

Java interop: dealing with Java implementation instances vs interfaces

[hiskennyness]

Not sure if this is a Java question or Clojure question, but I think it is 
the latter.

I am trying to use the Yahoo pulsar 
library https://mvnrepository.com/artifact/com.yahoo.pulsar/pulsar-client/1.14 
from Clojure.

It is going OK in general, but a couple times now trying to replicate Java 
code such as:

Producer producer = client.createProducer(
"persistent://sample/standalone/ns1/my-topic");

..with:

  (let [prod (.createProducer client 
"persistent://sample/standalone/ns1/ktopic")]
)

...all goes well except I end up with prod bound to an instance of 
ProducerImpl.

My Java is zilch but I presume the Java code binding the impl to a var type 
Producer is why the code can then execute:

producer.send("my-message".getBytes());

...whereas I get an error about send not being defined when I do:

(.send prod "Hi Mom")

I looked around for a way to "cast" the impl to a Producer but came up 
empty.

I did find a public sendAsync on ProducerImpl and that almost worked but 
then I ran into the same impl vs interface issue with another class 
(MessageBuilder) and decided I better figure this issue out once and for 
all.

Any ideas?

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