No transducer variant of partition?

[Mars0i]

partition-all has a transducer variant, but partition doesn't.  Just 
curious why.

The difference between the non-transducer functionalities is that, for 
example, (partition-all n coll) will return shorter-than-n stub sequences 
at the end of the main output sequence if the (count coll) isn't divisible 
by n, while partition will simply stop ignore leave the short sequences out 
of the main sequence (unless you use the four-argument syntax, in which an 
extra argument is used to construct extra sequences at the end of the main 
sequence as needed to use up the input sequence).

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

[Matt Mitchell]

My first Clojure "app" was a CLI utility that pulled data from a SQL 
database, mapped records into another form, and pushed them into a search 
engine app. It took me about 3 weeks to do that with no lisp experience at 
all, and I was super rusty on Java at that point. It was "hard", but I 
really only remember that as a very enjoyable learning experience. I don't 
think Clojure is any more difficult than language X, Y or Z really. From 
what I've seen from other developers, it's mostly a matter of getting over 
the parens/syntax (seriously). Once that's over, it's like any other 
language - it'll all click - "variables", conditionals, functions, state 
etc.. Just get started, don't hesitate. Peel back the layers one at a time 
and enjoy the learning experience. After a while, you might even find 
yourself preferring Clojure (those parens are there for a really good 
reason), and then eventually, every other language will look inferior (just 
kidding, maybe).

More to your question though - Clojure can definitely be used to build 
websites. A minimalist toolset would be (think Sinatra or Express) Ring and 
Bidi or Compojure. Throw in some common Ring middleware (static assets, 
sessions, file-type info) and you're getting somewhere. If you want 
something like Rails, I'm sure others here could recommend something.

- Matt

On Thursday, October 6, 2016 at 5:39:43 PM UTC-4, Xman wrote:
>
> It's been many years of postponing learning programming, because I 
> considered the popular languages of that time not right.
> It took me nearly 3 years to learn and build a website using another stack 
> (I wont advertise here), 
> and without having much previous knowledge in programming.  I have not 
> deployed the website yet. 
> I would like to know if Clojure is a great option to make websites ?
>
> I found out that there are new features on the web that Clojure is better 
> for, but I don't use those features in the present. 
> When I choose to learn a language I decide by myself, and after listening 
> to a video talk, it gives me reasons to think that its better.
> I want to learn the language and "frameworks" (or how to create the 
> architecture) much quicker than previous attempt.
>
> I'd like to know if its possible to do that in less than 6 months or if I 
> should stay with the framework I know ?
>

-- 
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, conform and returned value

[Alex Miller]

On Tuesday, October 11, 2016 at 1:30:18 PM UTC-5, plamen.use...@gmail.com 
wrote:
>
> Hello,
>
> I have a problem which is probably not in the spirit of clojure.spec as 
> being a library for "only" checking/generating valid values, but of 
> substantial practical value for my use case:
>
> Let say I have a function for checking if a double precision number is 
> parsable from a string (where possible performance penalties because of 
> communicating non-parsable strings through try/catch in the implementation 
> is not part of my question):
>
>
> (defn str-parsable-double? [s]
>   "Note the IMPLIED transformation from string to a double"
>   (try
> (Double/valueOf s)
> (catch NumberFormatException e
>   false)))
>
>
>
It's not detrimental here (other than this fn won't have the intended 
docstring), but this code has the docstring in the wrong place - it goes 
before the arglist, not after. 
 

> and have a spec using this function:
>
> (s/def ::str->double str-parsable-double?)
>
>
> We could actually chain checks for a single value as in:
>
> (s/def ::str->double (s/and string? str-parsable-double?))
>
>
This is a good practice. In general most specs will not generate 
automatically unless you start from a type-based predicate so this 
particular part I think is very much in line with good practices.
 

> and we could check for the conformity of a value as per:
>
> (s/conform ::str->double "3.14")
> => "3.14"
> and 
> (s/conform ::str->double "Pizza")
> => :clojure.spec/invalid
>
> Until now everything is ok, now my the questions:
>
> In my real world example I need a chain of a combination of checks and 
> transformations in the following way:
> ::check1 ::check2 ::check-and-transform3 ::check-4-on-transformed-value 
> ::check-5-on-transformed value
> or something like
> (s/def ::transforming-check (s/and string? ::str->double ::bigger-than-zero? 
> ::smaller-than-pi ... etc ...))
>
> As the result of 
> (s/conform ::str->double "3.14") is the input value as a string instead of 
> the result, 
>
>
I would need implement ::bigger-than-zero? and the rest of the checks as 
operating on strings, which would mean that I need in each check to transform 
the string into a double, which in my case is for performance reasons bad.
>
> On the other side I would be able to do the checks in a 2 step fashion, which 
> goes against my understanding of the aim of clojure.check to be able to 
> create through composition a single set of validations for a single value.
> This also doesn't solve fully the problem with the multiple parsing of the 
> first data type before the transformation: a parsing happens in the 
> ::str->double step as well in the then explicit transformation step before 
> the final checks based then on the actual double.
>
>
You can use s/conformer for this, although I will share the caution that 
use of s/conformer in your registered specs means that you are obscuring 
(and throwing away info) from the input value for your spec consumers. This 
is not inherently bad, but it is a tradeoff that should be considered when 
mixing validation and conversion. You could keep the conversion out of the 
spec and do that via a transformation or via a non-registered spec too. I 
can't say which of these is "right" for you, but you should at least think 
through these things ahead of time. A generally good practice is to also 
supply an unformer function with your conformer (here, probably just str 
would work) - this would allow you to run the spec backwards with s/unform 
and retrieve the original value.



> So - is there a way to compose checks in a single one, where some of them 
> change the underlying type of the value for subsequent validations (I may 
> miss something in the Clojure documentation, and pointers to it would be very 
> welcome)?
>
> If not - why s/conform returns the input value instead of the result value? 
> As being on the caller site of s/conform I know what I passed and I know what 
> s/conform would give me in the negative outcome of the validation.
> If s/conform while iterating/recursing through the actual spec would apply 
> the checks on returned values of previous checks instead always on the input 
> - the problem would be solved, without negatives for the calling sites (as 
> because of the previous sentence).
> This could be solved for example (not sure if I see every detail yet, but at 
> least as a pointer) in that in the clojure.spec code
>
> Spec
> (conform* [_ x] (let [ret (pred x)]
>   (if cpred?
> ret
> (if ret x ::invalid
> the value of cpred? could be passed from the calling site (or if don't miss 
> something be even per default true).
>
> In any case, I would be thankfull for any suggestions solving both proplems: 
> how to express such checks in a good way and how to avoid reparsing values 
> again and again (where the current example is for just strings to doubles, 
> but the actual 

Re: clojure.spec, conform and returned value

[plamen . usenet]

Amazing! 

Lot of thanks Josh! This solves everything. It is even written in the API 
doc, but I missed the important piece of "(possibly converted) value"...

With best regards
Plamen

On Tuesday, October 11, 2016 at 8:49:16 PM UTC+2, Josh Tilles wrote:
>
> I think you’re looking for conformer 
> ;
>  
> the spec it produces will pass along the converted value instead of the 
> original input. It could be used like:
> (defn str->double [s]
>   (try
> (Double/valueOf s)
> (catch NumberFormatException _
>   :clojure.spec/invalid)))
>
> (s/def ::transforming-check (s/and string? (s/conformer str->double) ::
> bigger-than-zero?))
>
> I hope that helps with your original problem, but I’ll defer to the more 
> experienced folks here for your questions about the spirit/aim of 
> clojure.spec.
>
> On Tuesday, October 11, 2016 at 2:30:18 PM UTC-4, plamen...@gmail.com 
> wrote:
>>
>> Hello,
>>
>> I have a problem which is probably not in the spirit of clojure.spec as 
>> being a library for "only" checking/generating valid values, but of 
>> substantial practical value for my use case:
>>
>> Let say I have a function for checking if a double precision number is 
>> parsable from a string (where possible performance penalties because of 
>> communicating non-parsable strings through try/catch in the implementation 
>> is not part of my question):
>>
>>
>> (defn str-parsable-double? [s]
>>   "Note the IMPLIED transformation from string to a double"
>>   (try
>> (Double/valueOf s)
>> (catch NumberFormatException e
>>   false)))
>>
>>
>> and have a spec using this function:
>>
>> (s/def ::str->double str-parsable-double?)
>>
>>
>> We could actually chain checks for a single value as in:
>>
>> (s/def ::str->double (s/and string? str-parsable-double?))
>>
>> and we could check for the conformity of a value as per:
>>
>> (s/conform ::str->double "3.14")
>> => "3.14"
>> and 
>> (s/conform ::str->double "Pizza")
>> => :clojure.spec/invalid
>>
>> Until now everything is ok, now my the questions:
>>
>> In my real world example I need a chain of a combination of checks and 
>> transformations in the following way:
>> ::check1 ::check2 ::check-and-transform3 ::check-4-on-transformed-value 
>> ::check-5-on-transformed value
>> or something like
>> (s/def ::transforming-check (s/and string? ::str->double ::bigger-than-zero? 
>> ::smaller-than-pi ... etc ...))
>>
>> As the result of 
>> (s/conform ::str->double "3.14") is the input value as a string instead of 
>> the result, I would need implement ::bigger-than-zero? and the rest of the 
>> checks as operating on strings, which would mean that I need in each check 
>> to transform the string into a double, which in my case is for performance 
>> reasons bad.
>>
>> On the other side I would be able to do the checks in a 2 step fashion, 
>> which goes against my understanding of the aim of clojure.check to be able 
>> to create through composition a single set of validations for a single value.
>> This also doesn't solve fully the problem with the multiple parsing of the 
>> first data type before the transformation: a parsing happens in the 
>> ::str->double step as well in the then explicit transformation step before 
>> the final checks based then on the actual double.
>>
>> So - is there a way to compose checks in a single one, where some of them 
>> change the underlying type of the value for subsequent validations (I may 
>> miss something in the Clojure documentation, and pointers to it would be 
>> very welcome)?
>>
>> If not - why s/conform returns the input value instead of the result value? 
>> As being on the caller site of s/conform I know what I passed and I know 
>> what s/conform would give me in the negative outcome of the validation.
>> If s/conform while iterating/recursing through the actual spec would apply 
>> the checks on returned values of previous checks instead always on the input 
>> - the problem would be solved, without negatives for the calling sites (as 
>> because of the previous sentence).
>> This could be solved for example (not sure if I see every detail yet, but at 
>> least as a pointer) in that in the clojure.spec code
>>
>> Spec
>> (conform* [_ x] (let [ret (pred x)]
>>   (if cpred?
>> ret
>> (if ret x ::invalid
>> the value of cpred? could be passed from the calling site (or if don't miss 
>> something be even per default true).
>>
>> In any case, I would be thankfull for any suggestions solving both proplems: 
>> how to express such checks in a good way and how to avoid reparsing values 
>> again and again (where the current example is for just strings to doubles, 
>> but the actual problem could involve any transformations on the value incl. 
>> type).
>>
>> With best regards
>> Plamen
>>
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to 

Re: clojure.spec, conform and returned value

[Josh Tilles]

I think you’re looking for conformer 
;
 
the spec it produces will pass along the converted value instead of the 
original input. It could be used like:
(defn str->double [s]
  (try
(Double/valueOf s)
(catch NumberFormatException _
  :clojure.spec/invalid)))

(s/def ::transforming-check (s/and string? (s/conformer str->double) ::
bigger-than-zero?))

I hope that helps with your original problem, but I’ll defer to the more 
experienced folks here for your questions about the spirit/aim of 
clojure.spec.

On Tuesday, October 11, 2016 at 2:30:18 PM UTC-4, plamen...@gmail.com wrote:
>
> Hello,
>
> I have a problem which is probably not in the spirit of clojure.spec as 
> being a library for "only" checking/generating valid values, but of 
> substantial practical value for my use case:
>
> Let say I have a function for checking if a double precision number is 
> parsable from a string (where possible performance penalties because of 
> communicating non-parsable strings through try/catch in the implementation 
> is not part of my question):
>
>
> (defn str-parsable-double? [s]
>   "Note the IMPLIED transformation from string to a double"
>   (try
> (Double/valueOf s)
> (catch NumberFormatException e
>   false)))
>
>
> and have a spec using this function:
>
> (s/def ::str->double str-parsable-double?)
>
>
> We could actually chain checks for a single value as in:
>
> (s/def ::str->double (s/and string? str-parsable-double?))
>
> and we could check for the conformity of a value as per:
>
> (s/conform ::str->double "3.14")
> => "3.14"
> and 
> (s/conform ::str->double "Pizza")
> => :clojure.spec/invalid
>
> Until now everything is ok, now my the questions:
>
> In my real world example I need a chain of a combination of checks and 
> transformations in the following way:
> ::check1 ::check2 ::check-and-transform3 ::check-4-on-transformed-value 
> ::check-5-on-transformed value
> or something like
> (s/def ::transforming-check (s/and string? ::str->double ::bigger-than-zero? 
> ::smaller-than-pi ... etc ...))
>
> As the result of 
> (s/conform ::str->double "3.14") is the input value as a string instead of 
> the result, I would need implement ::bigger-than-zero? and the rest of the 
> checks as operating on strings, which would mean that I need in each check to 
> transform the string into a double, which in my case is for performance 
> reasons bad.
>
> On the other side I would be able to do the checks in a 2 step fashion, which 
> goes against my understanding of the aim of clojure.check to be able to 
> create through composition a single set of validations for a single value.
> This also doesn't solve fully the problem with the multiple parsing of the 
> first data type before the transformation: a parsing happens in the 
> ::str->double step as well in the then explicit transformation step before 
> the final checks based then on the actual double.
>
> So - is there a way to compose checks in a single one, where some of them 
> change the underlying type of the value for subsequent validations (I may 
> miss something in the Clojure documentation, and pointers to it would be very 
> welcome)?
>
> If not - why s/conform returns the input value instead of the result value? 
> As being on the caller site of s/conform I know what I passed and I know what 
> s/conform would give me in the negative outcome of the validation.
> If s/conform while iterating/recursing through the actual spec would apply 
> the checks on returned values of previous checks instead always on the input 
> - the problem would be solved, without negatives for the calling sites (as 
> because of the previous sentence).
> This could be solved for example (not sure if I see every detail yet, but at 
> least as a pointer) in that in the clojure.spec code
>
> Spec
> (conform* [_ x] (let [ret (pred x)]
>   (if cpred?
> ret
> (if ret x ::invalid
> the value of cpred? could be passed from the calling site (or if don't miss 
> something be even per default true).
>
> In any case, I would be thankfull for any suggestions solving both proplems: 
> how to express such checks in a good way and how to avoid reparsing values 
> again and again (where the current example is for just strings to doubles, 
> but the actual problem could involve any transformations on the value incl. 
> type).
>
> With best regards
> Plamen
>
>
>
>
>
>

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

clojure.spec, conform and returned value

[plamen . usenet]

Hello,

I have a problem which is probably not in the spirit of clojure.spec as 
being a library for "only" checking/generating valid values, but of 
substantial practical value for my use case:

Let say I have a function for checking if a double precision number is 
parsable from a string (where possible performance penalties because of 
communicating non-parsable strings through try/catch in the implementation 
is not part of my question):


(defn str-parsable-double? [s]
  "Note the IMPLIED transformation from string to a double"
  (try
(Double/valueOf s)
(catch NumberFormatException e
  false)))


and have a spec using this function:

(s/def ::str->double str-parsable-double?)


We could actually chain checks for a single value as in:

(s/def ::str->double (s/and string? str-parsable-double?))

and we could check for the conformity of a value as per:

(s/conform ::str->double "3.14")
=> "3.14"
and 
(s/conform ::str->double "Pizza")
=> :clojure.spec/invalid

Until now everything is ok, now my the questions:

In my real world example I need a chain of a combination of checks and 
transformations in the following way:
::check1 ::check2 ::check-and-transform3 ::check-4-on-transformed-value 
::check-5-on-transformed value
or something like
(s/def ::transforming-check (s/and string? ::str->double ::bigger-than-zero? 
::smaller-than-pi ... etc ...))

As the result of 
(s/conform ::str->double "3.14") is the input value as a string instead of the 
result, I would need implement ::bigger-than-zero? and the rest of the checks 
as operating on strings, which would mean that I need in each check to 
transform the string into a double, which in my case is for performance reasons 
bad.

On the other side I would be able to do the checks in a 2 step fashion, which 
goes against my understanding of the aim of clojure.check to be able to create 
through composition a single set of validations for a single value.
This also doesn't solve fully the problem with the multiple parsing of the 
first data type before the transformation: a parsing happens in the 
::str->double step as well in the then explicit transformation step before the 
final checks based then on the actual double.

So - is there a way to compose checks in a single one, where some of them 
change the underlying type of the value for subsequent validations (I may miss 
something in the Clojure documentation, and pointers to it would be very 
welcome)?

If not - why s/conform returns the input value instead of the result value? As 
being on the caller site of s/conform I know what I passed and I know what 
s/conform would give me in the negative outcome of the validation.
If s/conform while iterating/recursing through the actual spec would apply the 
checks on returned values of previous checks instead always on the input - the 
problem would be solved, without negatives for the calling sites (as because of 
the previous sentence).
This could be solved for example (not sure if I see every detail yet, but at 
least as a pointer) in that in the clojure.spec code

Spec
(conform* [_ x] (let [ret (pred x)]
  (if cpred?
ret
(if ret x ::invalid
the value of cpred? could be passed from the calling site (or if don't miss 
something be even per default true).

In any case, I would be thankfull for any suggestions solving both proplems: 
how to express such checks in a good way and how to avoid reparsing values 
again and again (where the current example is for just strings to doubles, but 
the actual problem could involve any transformations on the value incl. type).

With best regards
Plamen





-- 
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: ThreatGRID/Cisco Looking for Clojure Developers

[Timo Sulg]

Hi, Alex!

I've few questions before i'll send my application.

Is it remote? Is there any timezone limitations? 
I saw your ad first on the "Who is hiring" tab on the Hackernews and it 
also mentioned France.

Timo
http://www.clojure.expert


On Tuesday, September 27, 2016 at 6:19:11 PM UTC+2, Alex Baranosky wrote:
>
> [ Full disclosure: I am the technical lead on this product and the hiring 
> manager in this case. Feel free to contact me with questions, and to pass 
> this around. ]
>
> Clojure Developer for Malware Analysis Product
>
> The ThreatGRID team at Cisco is looking for experienced clojure developers 
> to
> work on our large scale, malware analysis product. Our entire platform is 
> built
> on Clojure, from the the API services, around the event processing 
> subsystem,
> and down to the core.logic analysis engine.
>
> Our system runs as a distributed cluster in the cloud, and shrunk down to a
> single on-premises appliance. This keeps us focused on simple solutions, 
> clear
> abstractions between services, composition of services, functional data
> processing, and minimal state.
>
> We are analyzing 300k+ malware files a day, and will be scaling to 
> millions a
> day as we integrate more with the Cisco product line. We need experienced 
> hands
> in executing this scaling task.
>
> Our team is distributed across the U.S. and works from home with occasional
> office visits and travel -- this requires excellent written communications,
> self-confidence, trust in your co-workers, and assuming ownership of the
> problems you encounter.
>
> We work with these technologies:
>
>  * Clojure, core.logic, riemann
>  * ElasticSearch
>  * PostgreSQL
>  * Redis
>
> We are looking for experience in some of the following problem domains:
>
>  * Web Services Scaling -- Ok, but what happens if 2 million devices ask 
> that
>question?
>
>  * Cloud Deployment -- A herd of containers, a society of JVMs. Multiple 
> data
>centers.
>
>  * DevOps -- Developers and Operators working together to reduce mean-time 
> to
>discovery and remediation.
>
>  * System Monitoring and Alerting -- Kiries is Kibana, Riemann and 
> Elasticsearch
>
>  * Data Modeling -- Applied JSON epistemology in a world of hostile actors
>
>  * Micro-Services Architecture -- Towards NetFlix OSS, but in a Clojure 
> way.
>
>  * Continuous Integration/Deployment -- Keep it green, push the button to 
> deploy
>
> We offer:
>
>  * An endless supply of interesting problems, and people to solve them with
>
>  * Work in one of the fastest growing product lines in Cisco
>
>  * Competitive salary and benefits to support a stable, high-quality life
>outside of work
>
>  * Decades of collective experience with Clojure and Common Lisp
>
>  * Support in developing your skills and talents, we love to help each 
> other
>grow
>
>  * Work from home, or a Cisco office, as you please.
>  
> # CONTACT
>
> Email - jo...@threatgrid.com 
>
>

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

Re: [ANN] codox-klipse-theme 0.0.1- Clojure[script] automatically generated live documentation

[Andrea Richiardi]

On Monday, October 10, 2016 at 9:29:35 AM UTC-7, Yehonathan Sharvit wrote:
> https://github.com/viebel/codox-klipse-theme
> 
> codox is a great tool for generating API documentation from Clojure or 
> ClojureScript source code.

This is very cool stuff 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: [ANN] permissions - role & permission based access control

[Torsten Uhlmann]

Thanks for the comments!

@larry I was reminded by your comment at how I used to use bitmasks before,
like @adrian commented.
That would only get 64 states into a 64 bit Long, but was always enough. I
have no performance data on prime number sieves but I suspect that would
take longer than checking set bits of a long.

Anyway, I was thinking about your suggestion, and there might be away to
integrate such a scheme without totally warping the current implementation.

So, we would still need a definition of all existing permissions, the one
you initialize the library with at the start of your application. That
receives a map with the role keyword and a single or set of permissions.

Instead of making the role name a keyword we could also allow a number as
key. That number would then be a number by the power of 2 (if using the
bitmask approach). The value is still one or more permissions.

The user would then be added inside the :roles key a number like 5, which
would indicate the roles 1 and 4 are given.
If the library detects a number instead of a set of roles it would try to
destructure it against the global role map.

The same with the resource that asks for the permission- it could have a
permission attached or a number. That number would then map against the
roles the same way destructuring was done for the user.

I acknowledge that using the number would be limiting compared to using the
list of permission strings (because a set bit would represent one role and
not a single permission)- so it's the users obligation to create a sane set
of roles or to create basically a one-to-one relationship between a number
(a role) and a permission.

Kind Regards,
Torsten.

 schrieb am Di., 11. Okt. 2016 um 14:04 Uhr:

> If you wanted to do something more efficient, why not just use a bitmask?
> That is far more efficient than prime factorization.
>
>
> On Tuesday, October 11, 2016 at 12:06:19 AM UTC-4, larry google groups
> wrote:
>
> 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
>

Re: [ANN] permissions - role & permission based access control

[adrian . medina]

If you wanted to do something more efficient, why not just use a bitmask? 
That is far more efficient than prime factorization.

On Tuesday, October 11, 2016 at 12:06:19 AM UTC-4, larry google groups 
wrote:
>
> 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