Re: [ANN] Grenada 1.0.0-rc.2

[Francesco Bellomi]

Hi Chris,

CrossClj is similar in spirit to Hoogle, although it is more focused on 
cross-project browsing

https://crossclj.info/

However, you cannot search by type signature, being Clojure not statically 
typed ;-)

Francesco



On Wednesday, August 26, 2015 at 7:52:31 AM UTC+2, zcaudate wrote:
>
> Hey Richard,
>
> Yep, it’s exactly how you’ve described. The main emphasis is on writing 
> documentation that can be verified through tests and so if the api changes, 
> then the documentation can be fixed accordingly.
>
> The grenada project looks to be very ambitious in it’s scope and yeah, 
> it’ll be amazing to have a hoogle-like search engine for clojure.
>
> btw… is datadoc a grenada thing or a java thing?
>
> Chris
>
> Hi Chris,
>
> you can download a Datadoc JAR from 
> https://clojars.org/repo/org/clojars/rmoehn/clojure/1.7.0+003/clojure-1.7.0+003-datadoc.jar
>  
> and have a look at its contents. It's pretty bare-bones right now.
>
> Hydrox looks good! (As do your other libraries. – I hadn't had them on my 
> radar at all until now.) It appears to be a cool new tack on documentation 
> for me. A more expressive alternative to Codox, Autodoc & co. Correct me if 
> I oversimplify. What I've developed is a universal container for data about 
> Clojure code. You could store Hydrox data in it for distribution and 
> digestion by other tools. After the end of the GSoC my schedule is in a 
> state confusion, but as soon as this has abated I will have a closer look 
> at Hydrox and also include it in my comparison (
> https://github.com/clj-grenada/grenada-spec#comparison).
>
> Regarding the documentation problem (as I see it): Hydrox and Grenada 
> could be parts of the solution. Still lacking are conventions for the 
> structure of Clojure libraries and documentation, a unified approach to API 
> documentation (as opposed to people putting Codox or Autodoc on github.io 
> or private pages or nothing at all) and a dedicated search engine for 
> Clojure libraries.
>
> I would love to continue working on those things (and Grenada), but first 
> I have to wait for feedback from Alex Miller, who was my GSoC mentor, and 
> then I need to find some funding.
>
> Richard
>
> -- 
> 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 a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/TTO5AfqXXf4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: How to move an element within a vector?

[Linus Ericsson]

It is correct that vectors aren't a suitable choice for datastructures that 
need "random-access-removal". The problem is that you seem to need both 
fast index lookup and be able to access elements "after" removed elements 
quickly even when there are holes in the backing array.

There are some solutions. One is to use clojure.core/subvec, to keep the 
parts of the vector that should be kept, and concat these two sub vecs. I'm 
not sure if the removed element will be garbage collected - subvec reuses 
the structure of original vector, no copying seems to be done, so no 
"removed" element will be garbage collected until all subvecs of the 
original vector are realized as some other collection! If you are unsure 
about why (or, equally likely, prove me wrong), please refer to 
http://hypirion.com/musings/understanding-persistent-vector-pt-1 

There are also the finger-trees, which are not as wide as PersistentVector 
and are more suitable for splitting etc. Probably one could construct a 
datastructure more suitable for random access removal with that.

https://github.com/clojure/data.finger-tree

If the hotspot of your application is to quickly lookup things in vectors 
and quickly remove individual elements it feels like it exists some clever 
datastructure that, given an virtual index in the (partially shadowed) 
vector, increments the lookup index for each removed element before the 
virtual position, to compensate for the holes in the vector, but that was 
probably not really your question.

However, the problem is to find datastructures which both allow quick 
lookup and can keep track of the lookup when parts of the datastructure are 
marked as removed.

What ever you do, make sure to profile it so that you don't hunt for 
performance in vain.

/Linus

On Wednesday, August 26, 2015 at 12:12:28 AM UTC+2, Georgi Danov wrote:
>
> How about filtering? 
> BTW I don't see how it would help converting to array - what would be the 
> solution then?
>
> On Tuesday, August 25, 2015 at 7:06:30 PM UTC+2, Hussein B. wrote:
>>
>> Hi,
>>
>> For a vector like [A B C D E], how to remove an element to a specific 
>> location? For example [A D B C E] ?
>>
>> I thought about converting the vector into array but I would feel bad if 
>> I did that.
>>
>> What would be the idiomatic way to do that in Clojure?
>>
>> Thanks for help and time.
>>
>

-- 
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: Reviewers needed for new Clojure book!

[andrea crotti]

I reviewed the Python3 cookbook a while ago and would love to do the
same for a Clojure book,
thanks,
Andrea

2015-08-26 7:03 GMT+01:00 Akhil Wali :
> It's great to see so many volunteers for this project!
> Like I mentioned earlier, I have notified Packt and they shall contact
> anyone who is shortlisted as a reviewer.
>
> On Monday, August 24, 2015 at 12:16:06 PM UTC+5:30, Akhil Wali wrote:
>>
>> If anyone is interested in being a reviewer for a new book "Mastering
>> Clojure" by Packt Publishing, please let me know.
>> Reviewers will be entitled to a 6 montn subscription of PacktLib.
>>
>> Here's the list of topics covered in this title.
>>
>>
>> Working with Sequences and Types
>> Orchestrating Concurrency and Parallelism
>> Parallelization using Reducers
>> Writing Macros
>> Composing Transducers
>> Using Functors and Monads
>> Programming with Logic
>> Asynchronous Programming
>> Reactive Programming
>> Working with Tests
>> Troubleshooting and Best Practices
>>
>>
> --
> 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: ANN: Fink-Nottle 0.1.0 (async SQS + SNS client)

[Matthias Diehn Ingesman]

Hi Moe.

That looks really useful, and as far as I can tell yours is the only 
library for SNS. I'm considering using your library in a production app, 
are there any pitfalls I should be aware of?

>From quickly browsing the sources, it is not clear to me what the functions 
declared by the defissuers macro return. From your blog post on SNS I'm 
guessing it's core.async channels for single-! functions, but a comment on 
the function would be nice. :-)

Regards,
Matthias

Den mandag den 15. juni 2015 kl. 23.42.39 UTC+2 skrev Moe Aboulkheir:
>
> https://github.com/nervous-systems/fink-nottle
>
> Fink-Nottle is a non-blocking client for Amazon's SQS (queuing) and SNS 
> (push notification) services.
>
> There's a blog post here covering the SQS portion of its functionality: 
> https://nervous.io/clojure/aws/async/sqs/messaging/2015/06/15/fink-nottle-sqs/
> And one for SNS: 
> https://nervous.io/clojure/aws/async/sns/messaging/2015/06/15/fink-nottle-sns/
>
> Features:
>
> SQS:
>  - Per-queue message channels
>  - Auto-batching of writes and deletes, also via channels
>  - Message body pre-processing 
>  - Round-tripping of byte array & number attributes
>
> SNS:
>  - Channeled pagination of topic/endpoint/subscription listing
>
> Both:
>  - Natural EDN representation of AWS permission/policy documents
>  - Coverage of all API methods
>
> 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: [ANN] - New Clojure Instant Answer on DuckDuckGo

[Matthias Diehn Ingesman]

That should come in handy, thanks!

Matthias

Den onsdag den 26. august 2015 kl. 00.04.34 UTC+2 skrev Rafik NACCACHE:
>
> Hi Guys,
>
> I contributed an Instant Answer to DuckDuckGo.
>
>
> When you search for "Clojure" with a number of terms, you directly have 
> under the "software" tab all the packages matching your query from Clojars.
>
> Enjoy !
>
> Rafik
>

-- 
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: Fink-Nottle 0.1.0 (async SQS + SNS client)

[Moe Aboulkheir]

Matthias,

On Wed, Aug 26, 2015 at 9:31 AM, Matthias Diehn Ingesman
 wrote:

> That looks really useful, and as far as I can tell yours is the only library
> for SNS. I'm considering using your library in a production app, are there
> any pitfalls I should be aware of?

Nothing comes to mind - what are you planning on doing with it?  If
you're curious, there are integration tests for the underlying SNS
stuff here: 
https://github.com/nervous-systems/eulalie/blob/master/test/eulalie/test/sns.cljc

> From quickly browsing the sources, it is not clear to me what the functions
> declared by the defissuers macro return. From your blog post on SNS I'm
> guessing it's core.async channels for single-! functions, but a comment on
> the function would be nice. :-)

Yeah, the nonexistent docstrings aren't much help.  The consolation
prize is that there's documentation here:

https://github.com/nervous-systems/fink-nottle/wiki

which describes the API at a high level.   The more involved (i.e.
streaming response) functions are documented here:

https://github.com/nervous-systems/fink-nottle/wiki/sns.channeled

(Apologies if you've seen these)

Unfortunately, fink-nottle.sns is the only namespace not documented
function-by-function.  If "Pushing Messaging on EC2 ..." was the blog
post you saw, these other two also touch on SNS:

https://nervous.io/clojure/async/sns/eb/docker/2015/06/22/sns-beanstalk-chat/
https://nervous.io/clojure/clojurescript/node/aws/2015/08/09/chemtrails/

The latter lightly, but using the post 0.4.0 API.  The biggest change
from the earlier (outdated) posts is the credential-retrieval stuff,
which is described at
https://github.com/nervous-systems/eulalie/wiki/eulalie.creds

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: [ANN] - New Clojure Instant Answer on DuckDuckGo

[Chris Sims]

In a similar vein, you can use ‘!clojars’ to search on Clojars directly, e.g. 
‘!clojars cheshire’.

—Chris
> On Aug 26, 2015, at 3:11 AM, Matthias Diehn Ingesman  
> wrote:
> 
> That should come in handy, thanks!
> 
> Matthias
> 
> Den onsdag den 26. august 2015 kl. 00.04.34 UTC+2 skrev Rafik NACCACHE:
> Hi Guys,
> 
> I contributed an Instant Answer to DuckDuckGo.
> 
> 
> When you search for "Clojure" with a number of terms, you directly have under 
> the "software" tab all the packages matching your query from Clojars.
> 
> Enjoy !
> 
> Rafik
> 
> -- 
> 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: top-level lets or private globals

[Herwig Hochleitner]

I can't really speak to what's more idiomatic, but there is a slight
difference between a top-level let and ^:const ^:private.
^:const makes the compiler directly inline the form, thus it works only on
pr-dup - able values. This has gotten me by surprise some times.
This also duplicates values, that would otherwise be referenced.

OTOH, a let compiles into a static field + regular access, also it's "more
private" in the sense that you can't even get it by the (rather obscure)
@#'private-var form
​
Personally, I think there is nothing wrong with top-level lets and I like
to use them, just to keep compiler writers honest. There had been a
clojurescript bug related to this once.
Also they are more explicit about scope than the reference tree implicit in
namespace vars.

-- 
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: Fink-Nottle 0.1.0 (async SQS + SNS client)

[Matthias Diehn Ingesman]

I might have missed one or two of those pieces of documentation; will take a 
look in the morning tomorrow. 

My plans are just to use the SNS parts of fink-nottle to create and delete 
device endpoints, and subsequently publish to them. My use case is about as 
basic as it gets, I think.

-- 
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: Fink-Nottle 0.1.0 (async SQS + SNS client)

[Matthias Diehn Ingesman]

I might have missed one or two of those pieces of documentation; will take a 
look in the morning tomorrow.

My plans are just to use the SNS parts of fink-nottle to create and delete 
device endpoints, and subsequently publish to them. My use case is about as 
basic as it gets, I think.

Regards, Matthias 

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

Weird GenSyms behaviour across different quoted blocks in a macro

[Rafik NACCACHE]

Suppose I have the following macro, which generates a function that does
some repetitive generation, let's say:

(defmacro a-macro
  [m]
  `(fn [f#]
 ~(for [i# m]
`(*  (:val f#) ~i# 

Note how I start with a quoted block in which I emit the fn header, and in
which I use a gensym to capture its input, F#. I unquote to do my iterative
processing, then I quote again to emit my macro output.

If I macroexpand this:
(clojure.pprint/pprint  (macroexpand '(a-macro (1 2 3

I get :

(fn*
 ([f__11552__auto__]
  ((clojure.core/* (:val f__11551__auto__) 1)
   (clojure.core/* (:val f__11551__auto__) 2)
   (clojure.core/* (:val f__11551__auto__) 3

And I have a problem. The auto gensym for args declaration (...11522) is
different from the gensyms applying this arg in my generated function body
(...11551), so I cannot call my function.

Any Idea why is that? And Can you please help me to sort this kind of
situation?

Thank you;

Rafik

-- 
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: Weird GenSyms behaviour across different quoted blocks in a macro

[Ambrose Bonnaire-Sergeant]

You want an explicit gensym that scopes over both positions.

(defmacro a-macro
  [m]
  (let [f (gensym "f)]
`(fn [~f]
   ~(for [i# m]
  `(*  (:val ~f) ~i# )

Thanks,
Ambrose

On Wed, Aug 26, 2015 at 5:07 PM, Rafik NACCACHE 
wrote:

> Suppose I have the following macro, which generates a function that does
> some repetitive generation, let's say:
>
> (defmacro a-macro
>   [m]
>   `(fn [f#]
>  ~(for [i# m]
> `(*  (:val f#) ~i# 
>
> Note how I start with a quoted block in which I emit the fn header, and in
> which I use a gensym to capture its input, F#. I unquote to do my iterative
> processing, then I quote again to emit my macro output.
>
> If I macroexpand this:
> (clojure.pprint/pprint  (macroexpand '(a-macro (1 2 3
>
> I get :
>
> (fn*
>  ([f__11552__auto__]
>   ((clojure.core/* (:val f__11551__auto__) 1)
>(clojure.core/* (:val f__11551__auto__) 2)
>(clojure.core/* (:val f__11551__auto__) 3
>
> And I have a problem. The auto gensym for args declaration (...11522) is
> different from the gensyms applying this arg in my generated function body
> (...11551), so I cannot call my function.
>
> Any Idea why is that? And Can you please help me to sort this kind of
> situation?
>
> Thank you;
>
> Rafik
>
> --
> 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: Weird GenSyms behaviour across different quoted blocks in a macro

[Ben Wolfson]

unify-gensyms from potemkin will fix this:
https://github.com/ztellman/potemkin


On Wed, Aug 26, 2015 at 2:07 PM, Rafik NACCACHE 
wrote:

> Suppose I have the following macro, which generates a function that does
> some repetitive generation, let's say:
>
> (defmacro a-macro
>   [m]
>   `(fn [f#]
>  ~(for [i# m]
> `(*  (:val f#) ~i# 
>
> Note how I start with a quoted block in which I emit the fn header, and in
> which I use a gensym to capture its input, F#. I unquote to do my iterative
> processing, then I quote again to emit my macro output.
>
> If I macroexpand this:
> (clojure.pprint/pprint  (macroexpand '(a-macro (1 2 3
>
> I get :
>
> (fn*
>  ([f__11552__auto__]
>   ((clojure.core/* (:val f__11551__auto__) 1)
>(clojure.core/* (:val f__11551__auto__) 2)
>(clojure.core/* (:val f__11551__auto__) 3
>
> And I have a problem. The auto gensym for args declaration (...11522) is
> different from the gensyms applying this arg in my generated function body
> (...11551), so I cannot call my function.
>
> Any Idea why is that? And Can you please help me to sort this kind of
> situation?
>
> Thank you;
>
> Rafik
>
> --
> 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.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
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: Weird GenSyms behaviour across different quoted blocks in a macro

[Leon Grapenthin]

What Ambrose said and:

There is no need to use a hash for i in the for form. It is misleading 
because one thinks it will become a generated symbol as part of the 
generated form which is untrue.

On Wednesday, August 26, 2015 at 11:08:12 PM UTC+2, Rafik NACCACHE wrote:
>
> Suppose I have the following macro, which generates a function that does 
> some repetitive generation, let's say:
>
> (defmacro a-macro
>   [m]
>   `(fn [f#]
>  ~(for [i# m]
> `(*  (:val f#) ~i# 
>
> Note how I start with a quoted block in which I emit the fn header, and in 
> which I use a gensym to capture its input, F#. I unquote to do my iterative 
> processing, then I quote again to emit my macro output.
>
> If I macroexpand this:
> (clojure.pprint/pprint  (macroexpand '(a-macro (1 2 3
>
> I get :
>
> (fn*
>  ([f__11552__auto__]  
>   ((clojure.core/* (:val f__11551__auto__) 1)
>(clojure.core/* (:val f__11551__auto__) 2)
>(clojure.core/* (:val f__11551__auto__) 3
>
> And I have a problem. The auto gensym for args declaration (...11522) is 
> different from the gensyms applying this arg in my generated function body 
> (...11551), so I cannot call my function.
>
> Any Idea why is that? And Can you please help me to sort this kind of 
> situation?
>
> Thank you;
>
> Rafik
>

-- 
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: Weird GenSyms behaviour across different quoted blocks in a macro

[Timothy Baldridge]

Auto generated symbols (x# style) are only valid within a single syntax
quote form. Instead declare the symbol ahead of time, something like this:


(let [fsym (gensym "f_)]
  `(fn [~fsym]
 ~@(for [x (range 10]
 `(println ~fsym ~x

Hope this helps.

Timothy

On Wed, Aug 26, 2015 at 3:07 PM, Rafik NACCACHE 
wrote:

> Suppose I have the following macro, which generates a function that does
> some repetitive generation, let's say:
>
> (defmacro a-macro
>   [m]
>   `(fn [f#]
>  ~(for [i# m]
> `(*  (:val f#) ~i# 
>
> Note how I start with a quoted block in which I emit the fn header, and in
> which I use a gensym to capture its input, F#. I unquote to do my iterative
> processing, then I quote again to emit my macro output.
>
> If I macroexpand this:
> (clojure.pprint/pprint  (macroexpand '(a-macro (1 2 3
>
> I get :
>
> (fn*
>  ([f__11552__auto__]
>   ((clojure.core/* (:val f__11551__auto__) 1)
>(clojure.core/* (:val f__11551__auto__) 2)
>(clojure.core/* (:val f__11551__auto__) 3
>
> And I have a problem. The auto gensym for args declaration (...11522) is
> different from the gensyms applying this arg in my generated function body
> (...11551), so I cannot call my function.
>
> Any Idea why is that? And Can you please help me to sort this kind of
> situation?
>
> Thank you;
>
> Rafik
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Ratio implementation questions

[waffletower]

Would someone care to rationalize the implementation of (rationalize)?

(type (rationalize (/ 64 8)))
java.lang.Long
(type (rationalize (/ 64 7)))
clojure.lang.Ratio
(type (rationalize (/ 49 7)))
java.lang.Long
(type (rationalize (/ 49 6)))
clojure.lang.Ratio

Extraordinarily thorny to alternate type output in this manner IMO.  But I 
think a developer could cope with it if there wasn't ratio handling 
weirdness elsewhere.

Perhaps because of lack of handling for the above behavior, we have:

(rational? (/ 49 6))
true
(rational? (/ 49 7))
true

but..

fin.core> (numerator (/ 49 6))
49
(numerator (/ 49 7))
ClassCastException java.lang.Long cannot be cast to clojure.lang.Ratio 
 clojure.core/numerator (core.clj:3462)

Why doesn't (numerator) handle java.lang.Long?  Is this an oversight or is 
there a philosophy at work here?  In isolation I could understand a 
justification perhaps, but not in light of the behavior of (rationalize) 
{see above}.


-- 
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: top-level lets or private globals

[Kevin Downey]

On 8/25/15 12:06 AM, Kurt Sys wrote:
> I'm refering to a few posts in an old thread:
> https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J
> 
> What really puzzles me is that it doesn't seem to be generally
> regarded as idiomatic Clojure style to just use top-level (let)s for
> your "private" globals.
> 
>  
> So, here's the question: what's considered best practice in Clojure
> (what is idiomatic in Clojure): using private (namespace-scoped) globals
> variables or one big let over all (or at least, most) defns in a
> namespace? And why :)?
> 

I have found the access control stuff in Java to be an incredible pain.
When attempting to compose a larger system from the parts. Generally
everything is compulsively private, so if an api doesn't exactly expose
what you want, you either have to write what you want completely from
scratch, or use reflection to get a the bits you want to compose in to
what you want.

Avoid private as much as you can, and if you think you can't, ask
yourself, is this really private or is it a bit of instance state that
really shouldn't be a global def anyway.

When I make the case for making everything public generally the argument
I get back is about api evolution and how do users know what the stable
parts of the api are? I think this concern is a result of using
languages and tooling that don't do a good job of distinguishing source
code used to build an artifact and an artifact. Clojure tooling is
mostly built on top of maven, which does an excellent job of
distinguishing between the two. If you build your code using a jar out
of maven with a fixed version of 1.0.1, unless you change your
dependency you will always get the same code, so who cares what the
author decided is the stable public api and what is the private api.
Anything that you can make use of you can, and it will be the same until
you change it.

The answer to that is generally something about semantic versioning,
which due to every high profile project that uses it having at some
point a heated argument about what does and does not constitute a patch
release, who knows what you getting anyway.

-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

Ratio implementation questions

[Alex Miller]

This is logged at http://dev.clojure.org/jira/browse/CLJ-1435 - feel free to 
vote for it.

-- 
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: Ratio implementation questions

[Andy Fingerhut]

On Wed, Aug 26, 2015 at 3:26 PM, waffletower 
wrote:

> Would someone care to rationalize the implementation of (rationalize)?
>

Sorry, I don't have an answer of the form "Rich Hickey's rationale for this
behavior is X", because I don't know what X is for this behavior.  I can
point out a few things below, but you may already know them.


>
> (type (rationalize (/ 64 8)))
> java.lang.Long
> (type (rationalize (/ 64 7)))
> clojure.lang.Ratio
> (type (rationalize (/ 49 7)))
> java.lang.Long
> (type (rationalize (/ 49 6)))
> clojure.lang.Ratio
>
> Extraordinarily thorny to alternate type output in this manner IMO.  But I
> think a developer could cope with it if there wasn't ratio handling
> weirdness elsewhere.
>

Note that if you leave the calls to rationalize out of your examples above,
i.e. just do (type (/ 64 8)), etc., you get the same output.  (rationalize
x) returns x (with identical value and type) if x is of type
clojure.lang.Ratio or java.lang.Long (or any type other than Float, Double,
or BigDecimal).

If / is given arguments whose types are all integer types or type Ratio, it
returns an integer type if the answer can be represented as an integer,
otherwise it returns a Ratio.  The same is true for the arithmetic
operations + - *.  In general, arithmetic between Ratio and integer types
always puts the answer in lowest terms possible, and if the denominator
would be 1, the return value is and integer type, not type Ratio.  Thus
Clojure's clojure.lang.Ratio type is only used to represent non-integer
values.


>
> Perhaps because of lack of handling for the above behavior, we have:
>
> (rational? (/ 49 6))
> true
> (rational? (/ 49 7))
> true
>
> but..
>
> fin.core> (numerator (/ 49 6))
> 49
> (numerator (/ 49 7))
> ClassCastException java.lang.Long cannot be cast to clojure.lang.Ratio
>  clojure.core/numerator (core.clj:3462)
>
> Why doesn't (numerator) handle java.lang.Long?  Is this an oversight or is
> there a philosophy at work here?  In isolation I could understand a
> justification perhaps, but not in light of the behavior of (rationalize)
> {see above}.
>

When a decision is made on ticket
http://dev.clojure.org/jira/browse/CLJ-1435, then we will have at least an
'accept' or 'decline' answer to whether this behavior is an oversight.
Such a response might not include the philosophy at work.  If more people
vote on that ticket, it will likely lead to an accept/decline answer
sooner.  Votes alone do not necessarily affect the accept/decline decision
-- an argument that convinces Rich Hickey that the behavior is worth
changing seems to have more weight than vote count alone.  Changes to
functions in clojure.core are made pretty conservatively nowadays, and
numerator and denominator are documented to work only for values of type
Ratio.  Note that (ratio? (/ 49 7)) is false.

Andy

-- 
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: Reviewers needed for new Clojure book!

[J.-F. Rompre]

I am interested too if not too late... 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: top-level lets or private globals

[Kurt Sys]

Allright, so I'll probably stick to top-level lets... Thx!

Op woensdag 26 augustus 2015 18:44:18 UTC+2 schreef Herwig Hochleitner:
>
> I can't really speak to what's more idiomatic, but there is a slight 
> difference between a top-level let and ^:const ^:private.
> ^:const makes the compiler directly inline the form, thus it works only on 
> pr-dup - able values. This has gotten me by surprise some times.
> This also duplicates values, that would otherwise be referenced.
>
> OTOH, a let compiles into a static field + regular access, also it's "more 
> private" in the sense that you can't even get it by the (rather obscure) 
> @#'private-var form
> ​
> Personally, I think there is nothing wrong with top-level lets and I like 
> to use them, just to keep compiler writers honest. There had been a 
> clojurescript bug related to this once.
> Also they are more explicit about scope than the reference tree implicit 
> in namespace vars.
>

-- 
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: top-level lets or private globals

[Kurt Sys]

I do understand that point of view and largely agree. However, some (pretty 
small) functions or constants are private to some namespace, or rather, to 
some scope inside a namespace. I consider the public functions as the 'API 
of the namespace'. Internals shouldn't be exposed, so I can change 
internals without having to worry about public access changes. Having 
everything public would be a real pain and since internals change quite 
often, like in about 80% of the cases, I'd be torturing myself :p.

So yes, I agree to avoid global privates, but not 'private' in a general 
sense. Everything binding in a let-special form is like private to that 
let-block. But 

> ... is this really private or is it a bit of instance state that really 
> shouldn't be a global def anyway. 
>
seems to me answering my question: do not use global private defs, but use 
(top-level?) let-blocks.


Thx, qsys

Op donderdag 27 augustus 2015 01:15:14 UTC+2 schreef red...@gmail.com:
>
> I have found the access control stuff in Java to be an incredible pain. 
> When attempting to compose a larger system from the parts. Generally 
> everything is compulsively private, so if an api doesn't exactly expose 
> what you want, you either have to write what you want completely from 
> scratch, or use reflection to get a the bits you want to compose in to 
> what you want. 
>
> Avoid private as much as you can, and if you think you can't, ask 
> yourself, is this really private or is it a bit of instance state that 
> really shouldn't be a global def anyway. 
>
> When I make the case for making everything public generally the argument 
> I get back is about api evolution and how do users know what the stable 
> parts of the api are? I think this concern is a result of using 
> languages and tooling that don't do a good job of distinguishing source 
> code used to build an artifact and an artifact. Clojure tooling is 
> mostly built on top of maven, which does an excellent job of 
> distinguishing between the two. If you build your code using a jar out 
> of maven with a fixed version of 1.0.1, unless you change your 
> dependency you will always get the same code, so who cares what the 
> author decided is the stable public api and what is the private api. 
> Anything that you can make use of you can, and it will be the same until 
> you change it. 
>
> The answer to that is generally something about semantic versioning, 
> which due to every high profile project that uses it having at some 
> point a heated argument about what does and does not constitute a patch 
> release, who knows what you getting anyway. 
>
> -- 
> And what is good, Phaedrus, 
> And what is not good— 
> Need we ask anyone to tell us these things? 
>

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

Reviewers needed for new Clojure book!

[Nathan Smutz]

I'd be interested.  I've been looking for Clojure books past the introductory 
level.  It sounds like you're aiming for a good "second Clojure book."

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