Best style for clojure.spec and namespaced keywords?

[David Goldfarb]

I'm starting to dive into clojure.spec, which is a strong motivation for me 
to finally appreciate and use namespaced keywords -- an aspect of Clojure 
that I've ignored until now.

I don't have a good sense of style re how to namespace keywords, especially 
in standalone projects. I'm inclined to either create a separate namespace 
for each abstraction (approximately corresponding to each class in an OOP 
view of my data) or to jam all my keywords into one namespace 
(corresponding to the fact that I own all of them).  Neither approach feels 
completely right; the first seems much cleaner, but can quickly become very 
verbose.

Can anyone point me to some tasteful code or style guide that discusses the 
interplay of spec and namespaced keywords?
The existing examples seem to be a bit ad hoc. For example, 
http://clojure.org/guides/spec shows:

> (s/def ::date inst?) (s/def ::suit #{:club :diamond :heart :spade})

Which implies defining dates, a generally useful concept, in a local 
namespace along with parts of a card game.
I hope/assume this is just temporary, and clojure.core will soon evolve 
specs for types like dates, right?

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

Re: Neanderhal 0.8.0 released - includes Windows build

[Sungjin Chun]

It seems that matrix inversion routine is not in the current version of 
neanderthal or I cannot find what it is.
However, some interesting routines like axpy (I've no experience on 
BLAS/LAPACK) are fresh (positively) to me :-)

Thank you.

On Monday, October 10, 2016 at 2:10:27 PM UTC+9, Dragan Djuric wrote:
>
> Thank you for reporting broken links. They are fixed now. Anyway, it was 
> broken only on the news release page, everything worked ok from anywhere 
> else on the web site. Regarding the tutorials and docs, just follow the 
> main page or the links in the menu.
>
> On Monday, October 10, 2016 at 1:55:32 AM UTC+2, Sungjin Chun wrote:
>>
>> Hi, 
>>
>> First, thank you for your great library.
>> Second, the tutorial link 
>> http://neanderthal.uncomplicate.org/articles/news/articles/getting_started.html
>>  
>> in the release
>> page is missing.
>> Third, I'd tried to test some simple linear algebra code of my own such 
>> as inverting matrix, however, I cannot figure
>> out how to do this with neanderthal. Are there any docs on this simple 
>> subjects?
>>
>> On Monday, October 10, 2016 at 1:40:19 AM UTC+9, Dragan Djuric wrote:
>>>
>>> Windows users should not feel left out from high-performance computing 
>>> experience in Clojure. Neanderthal now comes ready for Linux, OS X, AND 
>>> Windows, on all CPUs and AMD, Nvidia, and Intel GPUs!
>>>
>>> Greatest thanks go to Dejan Dosic (https://github.com/ddosic), who 
>>> wrestled Windows peculiarities and found how to install GNU toolchain 
>>> properly to make ATLAS build smooth on Windows.
>>>
>>> http://neanderthal.uncomplicate.org/articles/news/release-0.8.0.html
>>>
>>

-- 
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: Neanderhal 0.8.0 released - includes Windows build

[Dragan Djuric]

You're right - matrix inversion is on the TODO list. However, in most cases 
when you think you need matrix inverse (which is very computationally 
expensive), you actually need some factorization (which is computationally 
expensive, but less than the whole inversion). Factorizations are, though, 
also on the TODO. Basically, now BLAS 1, 2, and 3 is implemented, while 
LAPACK is on the list of things I'll add next.

On Monday, October 10, 2016 at 11:44:12 AM UTC+2, Sungjin Chun wrote:
>
> It seems that matrix inversion routine is not in the current version of 
> neanderthal or I cannot find what it is.
> However, some interesting routines like axpy (I've no experience on 
> BLAS/LAPACK) are fresh (positively) to me :-)
>
> Thank you.
>
> On Monday, October 10, 2016 at 2:10:27 PM UTC+9, Dragan Djuric wrote:
>>
>> Thank you for reporting broken links. They are fixed now. Anyway, it was 
>> broken only on the news release page, everything worked ok from anywhere 
>> else on the web site. Regarding the tutorials and docs, just follow the 
>> main page or the links in the menu.
>>
>> On Monday, October 10, 2016 at 1:55:32 AM UTC+2, Sungjin Chun wrote:
>>>
>>> Hi, 
>>>
>>> First, thank you for your great library.
>>> Second, the tutorial link 
>>> http://neanderthal.uncomplicate.org/articles/news/articles/getting_started.html
>>>  
>>> in the release
>>> page is missing.
>>> Third, I'd tried to test some simple linear algebra code of my own such 
>>> as inverting matrix, however, I cannot figure
>>> out how to do this with neanderthal. Are there any docs on this simple 
>>> subjects?
>>>
>>> On Monday, October 10, 2016 at 1:40:19 AM UTC+9, Dragan Djuric wrote:

 Windows users should not feel left out from high-performance computing 
 experience in Clojure. Neanderthal now comes ready for Linux, OS X, AND 
 Windows, on all CPUs and AMD, Nvidia, and Intel GPUs!

 Greatest thanks go to Dejan Dosic (https://github.com/ddosic), who 
 wrestled Windows peculiarities and found how to install GNU toolchain 
 properly to make ATLAS build smooth on Windows.

 http://neanderthal.uncomplicate.org/articles/news/release-0.8.0.html

>>>

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

Just quick review - "idiomaticy" check (Selection sort)

[Rastko Soskic]

Hi,
I thought perhaps asking on IRC instead here - but chose here anyway :)

I am doing just some exercises in scope of various algorithms, data 
structures etc.
Currently, in scope is *selection sort*.

I came up of this implementation in Clojure (original examples are in 
Python and Ruby where
indices are directly manipulated and arrays tumbled over etc which is of 
course not encouraged in Clojure)

(defn- smallest [xs]
   "Searches for smallest element and returns it's value and position"
  (reduce #(let [[e im ci] %]
(if (<= %2 e)
  [%2 ci (inc ci)]
  [e im (inc ci)])) [(first xs) 0 0] xs))

(defn selection-sort [s]
  "Selection sort itself :)"
  (loop [xs s acc []]
(if (seq xs)
  (let [[x i] (smallest xs)]
(recur (concat (take i xs) (drop (inc i) xs)) (conj acc x))) ; <--
  acc)))


I don't need optimized implementation or anything :) 
It should be, well, selection sort with all it's flaws :)

I am just looking for advice if it could be made more Clojure-way?
I am specially interested in better way for processing input which shrinks 
after each step.
I was thinking of using *iterate *equipped with appropriate iteration 
function 
but that would be kinda of ugly once input is exhausted...

Thanks in advance and apologizes to those who might find this kind of 
question in this group annoying.

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

[Torsten Uhlmann]

I'd like to announce the first preview of "permissions"- a small library to 
handle role and permission based access control in web applications.

Github: https://github.com/tuhlmann/permissions
Clojars: https://clojars.org/agynamix/permissions

Permissions is heavily inspired and modeled after Apache Shiro's 
WildcardPermission: http://shiro.apache.org/permissions.html.

In a nutshell, you can define permissions based on a 

- domain: "users", "company", "admin", whatever the main areas of your 
application might be, 
- actions: "read", "edit", "delete", "upload" or however you like to name 
them,
- entities: "abcd1234", to limit access only to a resource with this 
specific ID

And you have the wildcard. You can grant access to all domains, all 
actions, all entities by applying the wildcard in the appropriate field.

Examples:

"*" would grant access to everything (internally this would be represented 
as "*:*:*", a wildcard for each
"users:*" would grant the user that holds the permission to everything that 
asks for a "users" permission
"users:read" would grant the user read access
"users:write:abcd1234" would grant write access to that specific resource

Roles:

The library also holds an implementation for roles and an easy to use API 
to check if a given user holds a permission or does not.

Roles are really just a container for a set of permissions. In order for 
the library to know which roles exist it has to be initialized with a map 
of roles.
The key is the name of the role, the value is a set of permissions. Such a 
definition could look like:

(def roles {:user/admin "user/*"
:user/all   #{"user/read" "user/write"}
:admin/all  "*"
:company/super #{"company/read" "company/write" "company/edit" 
"company/delete"}
}


In order to let the library check if a user "has-permission?" or 
"lacks-permission?" it expects a key ":roles" and/ or a key ":permissions" 
(you can override that default) inside the user map.

(def user {:roles #{:user/all :company/super}
   :permissions #{"library/read" "company/gibberish"}
   ... lots of other keys
   }


It would take the roles, flatten them to a list of permissions (through 
that mapping you initialized it with, remember?) and add the individual 
permissions to them.
It would then check if the permission required by the resource the user is 
trying to access is covered by one of the permissions of the user. How you 
handle granted or denied access is totally up to you.

I have used this role based access management in a number of different 
Scala projects (https://github.com/liftmodules/mapperauth, 
https://github.com/eltimn/lift-mongoauth) and found it quiet versatile. 
I'm using it now in a ClojureScript project and thought that might actually 
be a good candidate for a standalone library. Now here it is.

If you're interested in it please have a look at the tests and the code- 
I'm sure there is much room for improvement and interesting ideas I haven't 
thought about.
One thing that especially bugs me is the need to initialize the map of 
existing roles prior to using the library. If you come up with a better way 
I'm eager to hear it.

Please keep in mind that the code is merely a preview at the moment. 
Changes to the API should comes as no surprise.

Thanks,
Torsten.

-- 
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: Just quick review - "idiomaticy" check (Selection sort)

[Moe Aboulkheir]

Here's an example w/ iterate & a simpler 'smallest':

(defn- smallest [xs]
  (->> xs (map-indexed vector) (sort-by second) first))

(defn selection-sort [s]
  (->> (iterate
(fn [[acc xs]]
  (let [[i x] (smallest xs)
[l r] (split-at i xs)]
[(conj acc x) (concat l (rest r))]))
[[] s])
   (drop-while (comp not-empty second))
   ffirst))

I don't think using iterate is a huge win.

Take care,
Moe

-- 
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: Just quick review - "idiomaticy" check (Selection sort)

[Rastko Soskic]

Yeah you are right, it is simpler, I just wanted to avoid usage of any 
sort* function, I've probably gone too far :)
*split-at* is cool reminder :) totally forgot about it :)

Thanks!

On Monday, October 10, 2016 at 3:33:16 PM UTC+2, Moe Aboulkheir wrote:
>
> Here's an example w/ iterate & a simpler 'smallest':
>
> (defn- smallest [xs]
>   (->> xs (map-indexed vector) (sort-by second) first))
>
> (defn selection-sort [s]
>   (->> (iterate
> (fn [[acc xs]]
>   (let [[i x] (smallest xs)
> [l r] (split-at i xs)]
> [(conj acc x) (concat l (rest r))]))
> [[] s])
>(drop-while (comp not-empty second))
>ffirst))
>
> I don't think using iterate is a huge win.
>
> Take care,
> Moe
>

-- 
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] codox-klipse-theme 0.0.1- Clojure[script] automatically generated live documentation

[Yehonathan Sharvit]

https://github.com/viebel/codox-klipse-theme

codox  is a great tool for generating
API documentation from Clojure or ClojureScript source code.

With the klipse theme for codox, you can make your codox documentation live
and interactive powered by the KLIPSE plugin
.

In addition to words that describe your functions, now you can add interactive
code examples. It will be much easier for your users to understand how to
use your functions.

https://github.com/viebel/codox-klipse-theme

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

[JOB] Mastodon C looking for Clojure and Devops

[Bruce Durling]

Hi!

My company, Mastodon C is looking for people who like clojure and devops.

The details on the job are here:

http://www.mastodonc.com/hiring/2016/09/23/delivery-manager.html

We're based in London, but happy to work with remote people in the UK.

cheers,
Bruce
CTO Mastodon C

-- 
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: Just quick review - "idiomaticy" check (Selection sort)

[Steve Miner]

> On Oct 10, 2016, at 6:50 AM, Rastko Soskic  wrote:
> 
> I am specially interested in better way for processing input which shrinks 
> after each step.

Vectors have some nice properties if your action is mostly at the end.  The 
peek and pop functions are useful for “shrinking” a vector.  Also, you can 
assoc into a vector, which is sometimes simpler to use than list manipulations. 
 By the way, reduce-kv works with vectors so that’s a good way to find the 
smallest element and its index.

I’m cheating a bit by filling the “hole” of the selected item with the last 
element so I can pop the input vector without losing anything.

Caveat: not a recommended way to sort, only lightly tested.

(defn selsort [coll]
  (loop [v (vec coll) sv []]
(if (seq v)
  (let [pi (dec (count v))
px (peek v)
[i0 x0] (reduce-kv (fn [r i x] (if (< x (peek r)) [i x] r))
  [pi px]
  (pop v))]
(recur (pop (assoc v i0 px)) (conj sv x0)))
  sv)))



-- 
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 + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[pat . killean]

FWIW I removed the CSP from atom and now have figwheel running inside atom 
and its awesome

On Friday, October 7, 2016 at 8:25:18 PM UTC-4, Ray King wrote:
>
> Thanks for all the direct and public replies so far, we take great 
> reassurance from them.
>
> Recapping the constraints:
>
> We have an existing Java library, which is a collection of algorithms 
> (Statistical inferencing stuff), architecturally they are stateless. Pass 
> in a Map, and it returns a Map.  There is a coordination layer which we 
> have moved to Clojure, this just a Map/Reduce & transform router. For 
> example, we would run a simulation a few alternative models concurrently. 
> The Clojure code distributed work maps to threads and instances in 
> different memory spaces and consolidated all the results as pour back in 
> asynchronously. It handles failures and continuation etc.  This part works 
> fine. The difference of reimplementing this layer in Clojure is night and 
> day, forget Java and Scala for this, the rewrite was painless and scaling 
> options we have given ourselves are fantastic.
>
> We still have Java dependencies, there in is the rub.
>
> We want to move as much as this stuff client side as possible, 
> Clojurescript and only leave the bounds of the customer's machine for 
> certain operations where we need to offload these work maps to cloud bound 
> processors.
>
> In the perfect world, we would have an electron app with render processes 
> handling the GUI elements and the primary process doing some light 
> processing and distribution and coordination of the work maps. In fact, we 
> have prototyped this, and it appears viable.
>
> In the short term, we have running a JVM based server on the client 
> machine as that is what host the algorithm library.
>
> (By the way, this library will eventually be reimplemented in Clojure 
> script, but as there is a need to for precision & correctness we currently 
> have a test suit that 3x larger than the code base and we still trying to 
> get our heads around the float points in JS)
>
> The above is what motivated the question.
>
> 1. Cljs and Electron, Tick no problems.
>
> 2. Packaging up a web socket server in electron for deployment and later 
> version updating? Has it been done, Clues thoughts, etc.?
>
> 3. Developer workflow, (Productivity). 
> 
> a. Currently, we have the library, Java code, and Clojure layer in one 
> code base and repository. Using Lein, and Cursive to hack on it. Which by 
> itself is fine.
>
> b. Bring 'Cljs' & electron into play, using ATOM with 'Dirac' and 
> 'Cljs-oops' with 'Boot' starting becoming a lot more ergonomic and lighter 
> then Intellij, Cursive and Lein.
>
> We would like to unite these two worlds into one repository and one tool 
> chain. From that one environment, we should be able to work on the GUI 
> layer, live reload, inspect and tango on. (ATOM, Dirac and Boot). Then move 
> without friction and context changes to hacking some Clojure, running some 
> unit test and now specs with 1.9.0-alpha. Then back again, to the front.
>
> The fact is all the above (Clj, Cljs, Electron and Java can work together, 
> and deliver good results). But we have yet to find a unified tooling chain. 
> Being an IDE/Editor, 'repl', build and dependency management. That handles 
> the architectural options that 'Clj' and 'Cljs' is enabling.
>
> Yes, 'lein' abstracts us from mistakes of past 'Maven' but it is not the 
> promised landed. I want to write code executable testable code to manage my 
> project, to extract what I need from the code base, compile and package 
> into immutable file sets. 
>
> Darken by two decades of Java, Maven and dependence management yet not 
> brave enough to ride the grunt while gulping down bower packages which are 
> made by copy and paste mystery meats. I am thankful for the Google Closure 
> Complier that tree shakes out some of the JS crap that always seems to find 
> its way into JS apps. I am hoping that 'boot; will become the tool that 
> bridges 'Clj' and 'Cljs'.
>
> Please share your thoughts and wash apart any ignorance I have in this 
> area.  Indeed, if you have a directory structure and tooling around a 
> unifying a 'Clj', 'Java', 'Cljs' and 'JS' project, please share.
>
> Thanks again for the suggestions, I hope this post elaborate more upon 
> what I mean when I say developer workflow, productivity and ergonomics.
>
>
> On Friday, October 7, 2016 at 6:13:30 AM UTC+11, Daniel Compton wrote:
>>
>> Hi Ray
>>
>> We have a ClojureScript + Electron + Re-Frame application that we run. 
>> Those three work together quite nicely. I’m not totally clear what it would 
>> look like for Clojure + Boot + ProtoRepl to co-exist with the first three? 
>> Can you explain what you’re envisioning some more?
>>
>> On Wed, Oct 5, 2016 at 11:41 PM Mathias De Wachter  
>> wrote:
>>
>>> Hi Ray,
>>>
>>> I'm in a pretty much identical situation, except that I'm using re-frame 
>>> for the gui that connects to the 

Re: Just quick review - "idiomaticy" check (Selection sort)

[Mark Engelberg]

Doesn't seem fair to use a sort algorithm in the implementation of
selection sort.  Besides, sort is an n*logn operation, so you don't want to
(first (sort-by second ...)) anyway.  Instead, choose (apply min-key second
...).  Only catch is you need to make sure you don't pass an empty list, or
it will throw an error rather than returning nil like the sort-by version.

selection-sort isn't going to be performant in an immutable data structure,
but it might be interesting to compare performance using
clojure.core.rrb-vector for faster removal of the minimum value.

On Mon, Oct 10, 2016 at 6:33 AM, Moe Aboulkheir  wrote:

> Here's an example w/ iterate & a simpler 'smallest':
>
> (defn- smallest [xs]
>   (->> xs (map-indexed vector) (sort-by second) first))
>
>

-- 
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: [?] cljs-devtools vs. dirac DevTools

[Antonin Hildebrand]

Hi,

I'm the author of both tools.

cljs-devtools is essential and you should start with it if you are 
developing under Chrome. It presents ClojureScript data structures when you 
print them via console.log. cljs-devtools must be configured as a library 
included in your project/app.

Dirac is a fork of Chrome DevTools with ClojureScript-specific features 
added. You use it instead of internal DevTools in Chrome. 
It is more advanced tool and requires some non-trivial setup. It is the 
next evolutionary step when you master your ClojureScript development 
environment.
There are many nice-to-have features (as listed on the homepage) but the 
distinguished one is to be able to REPL cljs code in the context of a 
paused breakpoint. 
This is obviously very advanced feature you would use debugging complex 
code once in 10 years, but I'm not aware of any other tool allowing this.
I would not recommend it to beginners, as they don't usually need that 
power.

Both tools are complementary. Dirac expects cljs-devtools as a soft 
dependency. It does not make much sense to use Dirac REPL without having 
cljs-devtools presenting cljs data structures in a friendly way.

good luck!
Antonin


On Monday, October 10, 2016 at 6:04:36 AM UTC+2, Philos Kim wrote:
>
> Could anyone explain the difference between cljs-devtools and dirac 
> DevTools?
>
> And which one to use when?
>
> https://github.com/binaryage/cljs-devtools
>
> https://github.com/binaryage/dirac
>
> Many thanks in advance.
>
>

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

[larry google groups]

A minor pet peeve of mine, but is it possible to attach prime numbers to 
the roles, and to then decipher the roles from the factors of the total? 
Using strings or keywords for permissions often strikes me as inefficient. 
Assuming:

create -- 2

read -- 3

update  -- 5

delete -- 7

bulk-erase -- 11

delete-others -- 13

So given a permissions value of 330, we can factor 330 and find 2, 3, 5 and 
11. And it seems more efficient (though less readable) to carry around 
"330" rather than [:create :read :update :bulk-erase]

I would very much like to see a small library that does this for me, rather 
than always writing this code for myself. 









On Monday, October 10, 2016 at 6:51:14 AM UTC-4, Torsten Uhlmann wrote:
>
> I'd like to announce the first preview of "permissions"- a small library 
> to handle role and permission based access control in web applications.
>
> Github: https://github.com/tuhlmann/permissions
> Clojars: https://clojars.org/agynamix/permissions
>
> Permissions is heavily inspired and modeled after Apache Shiro's 
> WildcardPermission: http://shiro.apache.org/permissions.html.
>
> In a nutshell, you can define permissions based on a 
>
> - domain: "users", "company", "admin", whatever the main areas of your 
> application might be, 
> - actions: "read", "edit", "delete", "upload" or however you like to name 
> them,
> - entities: "abcd1234", to limit access only to a resource with this 
> specific ID
>
> And you have the wildcard. You can grant access to all domains, all 
> actions, all entities by applying the wildcard in the appropriate field.
>
> Examples:
>
> "*" would grant access to everything (internally this would be represented 
> as "*:*:*", a wildcard for each
> "users:*" would grant the user that holds the permission to everything 
> that asks for a "users" permission
> "users:read" would grant the user read access
> "users:write:abcd1234" would grant write access to that specific resource
>
> Roles:
>
> The library also holds an implementation for roles and an easy to use API 
> to check if a given user holds a permission or does not.
>
> Roles are really just a container for a set of permissions. In order for 
> the library to know which roles exist it has to be initialized with a map 
> of roles.
> The key is the name of the role, the value is a set of permissions. Such a 
> definition could look like:
>
> (def roles {:user/admin "user/*"
> :user/all   #{"user/read" "user/write"}
> :admin/all  "*"
> :company/super #{"company/read" "company/write" "company/edit" 
> "company/delete"}
> }
>
>
> In order to let the library check if a user "has-permission?" or 
> "lacks-permission?" it expects a key ":roles" and/ or a key ":permissions" 
> (you can override that default) inside the user map.
>
> (def user {:roles #{:user/all :company/super}
>:permissions #{"library/read" "company/gibberish"}
>... lots of other keys
>}
>
>
> It would take the roles, flatten them to a list of permissions (through 
> that mapping you initialized it with, remember?) and add the individual 
> permissions to them.
> It would then check if the permission required by the resource the user is 
> trying to access is covered by one of the permissions of the user. How you 
> handle granted or denied access is totally up to you.
>
> I have used this role based access management in a number of different 
> Scala projects (https://github.com/liftmodules/mapperauth, 
> https://github.com/eltimn/lift-mongoauth) and found it quiet versatile. 
> I'm using it now in a ClojureScript project and thought that might 
> actually be a good candidate for a standalone library. Now here it is.
>
> If you're interested in it please have a look at the tests and the code- 
> I'm sure there is much room for improvement and interesting ideas I haven't 
> thought about.
> One thing that especially bugs me is the need to initialize the map of 
> existing roles prior to using the library. If you come up with a better way 
> I'm eager to hear it.
>
> Please keep in mind that the code is merely a preview at the moment. 
> Changes to the API should comes as no surprise.
>
> Thanks,
> Torsten.
>
>

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