Re: core.logic: Help with insertion sort

[Tassilo Horn]

Nicolás Berger  writes:

Hi Nicolás,

>> I've simplified the code a bit so that I don't need the `cconso` >
>> relation.
>
> That's great. It's easier to understand this way. To simplify a tiny
> bit more, the `nf` lvar can also be removed: it's unified with `f`, so
> f can be used instead of nf in `(conso nf nr nl)`

Ah, right.

>> Ok, and now the backwards case:
>> ...
>> ...
>> Well, that loops forever.
>
> I found the cause of non-termination. Before the long explanation, you
> might want to open my full working version from
> https://gist.github.com/nberger/6b0ad2a68c52a6005c6a
>
> When `l` is not ground (the backwards case), there's no constraint
> that prevents it from being any arbitrary long list, so isorto and
> inserto are indefinitely tried recursively looking for solutions based
> on those lists. Arbitrary long `l`s generate arbitrary long `acc`s.

Yeah, I've guessed that, too.

> I tried avoiding this issue by adding a `(permuteo l sl)` in the
> 2-arity version of isorto, which one would say it's a relation that
> must hold between l and sl, but it yielded a similar result.

Hehe, and that was also what I've tried to somehow put the information
that both lists must be equally long in there.  But I guess that would
have degraded the algorithm to a naive sort, i.e., filtering the sorted
permutations from all permutations instead of building a sorted list by
adding values at the right positions.

> I finally made it work by adding a (non-relational) goal that fails
> when acc is going to be longer than sl:
>
> (project [sl acc]
>   (if (and (not (lvar? sl))
>(= (count acc) (count sl)))
> fail ; acc is already long as sl, let's stop here
> s#))
>
> We have to first check that sl is ground (not an lvar) so we can take
> its count.

Oh, that's great.

>> Too bad that lazy sequences aren't printed in a readable way.
>
> I used this slightly different version of trace-lvar which calls
> pr-str to help with this:
>
> (defn trace-lvar [a lvar]
>   `(println (format "%5s = %s" (str '~lvar) (pr-str (-reify ~a ~lvar)
>
> A 3-arity version of trace-lvar that takes a transformation fn to
> apply to the reified value might be handy.

Thanks!

>>  And why are the sorted lists sl of isorto and nl of inserto always
>> (the same?)  fresh variable _0?  I had expected that during the
>> recursion, more information should be added so that their value
>> builds up like
>>
>>   sl = (1 2 . some-lvar)
>>
>> where some-lvar will eventually during the next recursion be fixed to
>> the list (3).
>
> In the forward case, sl has to always be the same fresh variable
> because it's our "output" lvar that will get unified with acc when l
> gets to be empty. That also explains that in the end, nl and sl are
> unified to the same var. See this:
>
> (inserto f acc nacc) ; nacc will be nl in inserto
> (isorto r nacc sl) ; nacc will be acc in isorto, and it will be unified with 
> sl

Ok, I see.

> Before closing, a minor thing:
>
> - I had to replace the conda in inserto with conde, because when l is
> not ground (so x is also not ground) we want to try both branches.

Yes, conde is the right thing of course.  I just put a conda there to
see if this changes anything wrt termination.

> That's what I found. Hope it helps :)

It does!  I'm really happy that I haven't been too far off the right
solution.  And I think the approach is good: specify the problem fully
relational, and if it won't terminate, add some non-relational
constraints that cut the divering paths.

Bye,
Tassilo

-- 
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: range no longer returns a LazySeq; how to check whether realized?

[Mars0i]

On Sunday, August 2, 2015 at 4:05:02 PM UTC-5, Matching Socks wrote:
>
> By the way, -- When is it useful to know whether a lazy sequence has been 
> realized?
>

I don't know what people do with it in production code, but one reason you 
might want to know would be that you have a lazy sequence that produces 
side-effects when realized.  You might want to know whether the 
side-effects have already happened. 

-- 
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: Complete lack of helpful compilation errors with :gen-class

[Mars0i]

I don't have anything helpful to say, but:  I've often gotten a useful 
stacktrace from compile-time errors using 'lein compile' with :gen-class.  
Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
I think that whatever's happening is not just an issue with compilation of 
gen-class.  Maybe an issue involving libraries?  This page 

 
is consistent with that hypothesis.

-- 
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: Using a dynamic var for my database connection for implicit connections+transactions

[James Gatannah]

On Thursday, July 30, 2015 at 7:44:31 PM UTC-5, J. Pablo Fernández wrote:
>
> Hello Clojurians,
>
> I found passing around the database connection to each function that uses 
> it very error prone when you are using transactions as passing the wrong 
> one could mean a query runs outside the transaction when in the source code 
> it is inside the with-db-transaction function.
>

I'll go ahead and make the point that it's error-prone for different 
reasons.

Pretty much by definition, that database connection is a system boundary. 
It's all about something that's *way* more complex than random global state 
changes inside your program. This is a thing that interacts with the 
outside world, with all the nastiness that implies.

Everything that everyone else has already written about this approach is 
true, but I don't think they've gone far enough.

Even if you pass that database connection around as a parameter everywhere, 
you're talking about throwing away a huge part of the benefit of using a 
functional language.

Isolate your side-effects.

Think of a castle. You have a moat surrounding it, and a few gates that you 
use to allow your peasants to enter/exit. This particular gate opens up to 
a swamp full of alligators.

Your approach amounts to letting the gators wander around loose.

Passing the connection around to each function in the call chain is like 
tying a ribbon around the gator's neck and hoping you can use that as a 
leash.

You can use either approach to great effect. If you're really, really good. 
And so is everyone else on your team (you did mention a 200 KLOC project).

One of the main benefits to functional programming is that admitting you 
aren't really, really good is incredibly liberating. I don't have the 
time/energy to dedicate to trying to maintain this sort of code. (Yes, I 
spent lots of time recently thinking about how java was designed for very 
average programmers, but it really takes much better programmers than a 
functional language to actually write correct programs). Even if I were 
that good...I'd rather be focused on the problems that make my customers 
happy.

I'm going to appeal to authority here for the right 
answer: http://prog21.dadgum.com/23.html (in my defense, it's a great 
blog). Have your web response handler (which is another system 
boundary...this one is next to an active volcano populated by 
fire-breathing dragons) build up a list of all the nasty side-effects that 
will eventually have to happen.

Don't just isolate your side-effects. Quarantine those suckers as if each 
and every one means you're dealing with the most diabolical hacker you can 
imagine.

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Jason Lewis]

IntelliJ CE (the free version) has served me well for Java and (playing
with) Cursive for Clojure. I can't speak to Python.

For Clojure nothing beats emacs + CIDER, and emacs is a fine choice for
Python. I generally stick to IntelliJ for Java, but I do know a few people
who use emacs for Java and then do a run through an IDE for static analysis
and automated refactoring as a second step.

FWIW, I think it's worth learning the tradeoffs between editors and IDEs; I
wish I'd learned the difference earlier on. Maybe Python/emacs ->
Java/IntelliJ -> Clojure/emacs? Learning emacs and IntelliJ might be a bit
of cognitive overhead, but (insert some old saw about a good craftsmen
knowing his tools).

I can't imagine using Atom for Java, and using it for Clojure seems like a
terrible idea; no inline eval, no integrated REPL, no
jump-to-fn-definition, no jump-to-docstring... I used it briefly when I was
still doing Ruby, it was acceptable on the days when the latest update
didn't cause it to crash every 15 minutes.



On Sun, Aug 2, 2015 at 8:51 PM Mark Engelberg 
wrote:

> Intellij might be your best option for a unified development platform for
> Java, Clojure, and Python.  It won't be free though.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Mikera]

If you want a free / open source alternative, then Eclipse also offers a 
great environment for developing Java, Clojure and Python.

The Counterclockwise plugin for Eclipse is great - certainly has provided 
everything I want in a Clojure dev environment (integrated REPL, paredit 
mode, good syntax highlighting, integrated docstrings, auto-complete etc.)

On Monday, 3 August 2015 08:51:17 UTC+8, puzzler wrote:
>
> Intellij might be your best option for a unified development platform for 
> Java, Clojure, and Python.  It won't be free though.
>
>
>

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

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Mark Engelberg]

Intellij might be your best option for a unified development platform for
Java, Clojure, and Python.  It won't be free though.

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

Re: core.async: implementing pi.go

[Mark Engelberg]

I agree that there's value to making math expressions look like the way
they are written in actual math -- it is much easier to tell at a glance
that you've entered the correct formula.  I think your maya library is a
nice contribution.  (I think Incanter has a similar macro, but it is nice
to have it in a lightweight standalone library.
https://github.com/joyofclojure/unfix is another one, I haven't figured out
exactly how they all compare.  It's not obvious to me from your
documentation -- does maya automatically handle operator precedence?).

My point is mainly that people who read and write Clojure are used to using
infix notation, so for that particular audience, it should be no big deal
to read the infix math unless the expression is particularly complex.
Specifically, I don't think that reordering math with -> gains you any
readability.  But I'm all for judicious use of infix DSLs.



On Sun, Aug 2, 2015 at 5:59 AM, Divyansh Prakash <
divyanshprakas...@gmail.com> wrote:

> Makes sense.
> By the way - I've refactored my code
>  to
> not use a go block inside 'term', and made it much more readable (IMO) than
> before using my maya library .
> I'm telling you this because I'm not a big fan of writing mathematical
> expressions as s-exps but you seem all for it.
> I had written the macros defined in maya quite a long time ago, but you
> just inspired me to push it to clojars, so thanks for that! :)
>
> - Divyansh
>
> --
> 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] Initial release of Glow, a tiny library for syntax highlighting Clojure source code

[Reid McKenzie]

On the contrary, I would argue that there is some interesting stuff
like locals highlighting that existing highlighting solutions don't or
can't offer. However as you say pygments fulfills my requirements.

Reid

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


0x0A85EC53.asc
Description: application/pgp-keys

Re: [ClojureScript] ClojureScript Self-hosting Demo

[Marc Fawzi]

Some basic and potentially naive questions:

I realize you need a bunch of things loaded in the browser to convert CLJS code 
to JS and eval it. I'm wondering about the below:

1. Does this means that i can run CLJS in the browser without the Google 
Closure library or is the compiler dependent on that? 

2. Is it possible now to load CLJS libraries into JS projects with similar ease 
to loading JS libraries/modules?



Sent from my iPhone

> On Jul 31, 2015, at 11:08 AM, David Nolen  wrote:
> 
> Some more words & demos here 
> http://swannodette.github.io/2015/07/29/clojurescript-17/
> 
> Cheers,
> David
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

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

Complete lack of helpful compilation errors with :gen-class

[James Elliott]

I don't know if this is an issue with the compiler in general, with 
Leiningen more specifically, or something I am doing wrong in trying to use 
them, but I have wasted many hours over the last couple weeks while working 
on afterglow-max  due 
to the fact that when I am compiling a Clojure source file which extends a 
Java class, any little mistake I make while coding gives me the following 
opaque output when I try to compile, rather than the helpful message 
telling me where the problem occurred that I am used to:

lein -U uberjar

Compiling afterglow.max.core

Compiling afterglow.max.Cue

Compiling afterglow.max.Eval

Compiling afterglow.max.init

Compiling afterglow.max.Metro


Exception: java.lang.UnsatisfiedLinkError thrown from the 
UncaughtExceptionHandler in thread "main"

Compilation failed: Subprocess failed

Uberjar aborting because jar failed: Compilation failed: Subprocess failed

Error encountered performing task 'uberjar' with profile(s): 
'base,system,user,provided,dev,update'

Uberjar aborting because jar failed: Compilation failed: Subprocess failed

Trying to just do a lein compile seems to silently do nothing at all when 
it is in this state. In this case it was because I had called a function 
which was not defined until later in the file. Normally super easy to 
figure out from the compiler error messages, of course!

So I end up having to tediously try commenting out sections of my code 
until I can get it compiling again and then narrow down the problem. I had 
developed a style of making a tiny addition then rebuilding the uberjar to 
avoid this problem (and this is made worse by the fact that the compilation 
process creates futures at some point, due to one of the libraries 
involved, so compilation delays for an extra sixty seconds each time, 
waiting for Clojure's agent thread pool to shut itself down! I can't 
believe that *still* does not use daemon threads)... But this time I was 
writing the final object, which was very similar to others I had already 
written, and forged through until the end until trying to compile, then had 
to spend hours figuring out my simple stupid error.

Has anyone else seen a problem like this? Don't get me wrong, I still think 
Clojure is the best thing going, but it could be better without this 
problem. Is there anything I can do to avoid it, beyond what I already was?

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

Having done some more research, I see Atom 1.0 is still very new 
which likely accounts for the a paucity of replies, an no Youtubes
on the topic (that I could find).

Anyway, it's not a set in stone requirement -- in the virtual school 
of my dreams [1] -- that every course should use the same IDE, just 
it's nice when that's an option.

I'm using IntelliJ with the Cursive plug-in for Clojure currently, having
tried LightTable before (for which I did find a demo with Clojure).

The old Mac OSX I'm running on my Mac Air won't even boot Atom, 
so I've got a ways to go exploring that particular configuration. [2]

I'll be on the lookout for demo Youtubes.  It's a little inconvenient 
searching on Atom + Clojure given the "atom" concept is core to
Clojure as a part of the language. :-D

Kirby

[1]  
http://controlroom.blogspot.com/2015/08/asynchronous-learning-engine-ale.html

[2]  Atom 1.0 requires Mac OSX 10.8 or above, but will run in Ubuntu (so 
that's 
a VM option).

-- 
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: range no longer returns a LazySeq; how to check whether realized?

[Matching Socks]

By the way, -- When is it useful to know whether a lazy sequence has been 
realized?

-- 
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: range no longer returns a LazySeq; how to check whether realized?

[Fluid Dynamics]

On Sunday, August 2, 2015 at 2:40:55 PM UTC-4, Alex Miller wrote:
>
> realized? throws when passed something that's not IPending. Lazy seqs (but 
> not all seqs) implement IPending, thus the vast majority of realized? users 
> already have an if check prior to making the call. Any code of that form 
> continues to work. I think it would be a better idea if realized? did this 
> for you (which is the ticket above).
>
> This was discussed at length prior to release and the decision was to 
> leave the new range in its current state.
>

I'd say it's a defect for it to not, at the very least, not-throw when 
passed any seq (and then it should return true for any non-lazy one).

-- 
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: range no longer returns a LazySeq; how to check whether realized?

[Alex Miller]

realized? throws when passed something that's not IPending. Lazy seqs (but not 
all seqs) implement IPending, thus the vast majority of realized? users already 
have an if check prior to making the call. Any code of that form continues to 
work. I think it would be a better idea if realized? did this for you (which is 
the ticket above).

This was discussed at length prior to release and the decision was to leave the 
new range in its current state.

-- 
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: range no longer returns a LazySeq; how to check whether realized?

[Fluid Dynamics]

On Friday, July 31, 2015 at 9:04:45 AM UTC-4, Alex Miller wrote:
>
> We're focusing on defects right now for 1.8 but eventually we'll roll back 
> around to enhancements too.
>
> On Fri, Jul 31, 2015 at 5:04 AM, Marc O'Morain  > wrote:
>
>> This caught us out at Circle when preparing the code-base for Clojure 1.7 
>> – which reminds me of http://dev.clojure.org/jira/browse/CLJ-1752 
>>
>
I am pretty sure that formerly working code throwing a ClassCastException 
*is* a defect. 

-- 
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: core.async: implementing pi.go

[Divyansh Prakash]

Makes sense.
By the way - I've refactored my code 
 to not 
use a go block inside 'term', and made it much more readable (IMO) than 
before using my maya library .
I'm telling you this because I'm not a big fan of writing mathematical 
expressions as s-exps but you seem all for it.
I had written the macros defined in maya quite a long time ago, but you 
just inspired me to push it to clojars, so thanks for that! :)

- Divyansh

-- 
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: core.async: implementing pi.go

[Mark Engelberg]

On Sun, Aug 2, 2015 at 4:38 AM, Divyansh Prakash <
divyanshprakas...@gmail.com> wrote:

> I have one more question, though: how does one work in ClojureScript
> without 
>

This use case is a little weird because the 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: core.async: implementing pi.go

[Divyansh Prakash]

Hey, puzzler!
Thanks for the detailed response. Just changing (chan) to (chan n) actually 
worked!
 
I get your displeasure with how 'term' is implemented. 
That's not how I generally code. I'm very new to core.async and was aiming 
for a direct translation of the Go code.

I do get a little carried away with -> at times, though.

Also - though optimization wasn't a priority, thanks for taking out the 
time to show alternate approaches along with their use cases. 
I haven't tried reducers yet, so that was new.

I have one more question, though: how does one work in ClojureScript 
without 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: core.async: implementing pi.go

[Mark Engelberg]

Clojure's async is built around the opinion that you, the programmer,
should be required to think about what sort of buffer you want to have on
your channel, and think about what should happen if that buffer overflows.

Your code spins off 5000 little go blocks that are each trying to write to
a channel of size 1.  This effectively forces Clojure to buffer up all
those blocking puts.  Clojure provides a fairly limited buffer (size 1024)
for the blocked puts so that you can't easily circumvent its opinionated
policy that *you* should be supplying the right size buffer with the
appropriate policy.

So, short answer: change your (chan) to something like (chan 1) and
your code works fine.

But that's probably not what you're looking for.  We really don't want to
have to size the buffer based on the input to the pi function.  We want to
be able to deal with arbitrarily large inputs with some reasonably smallish
buffer.  Because this is a toy problem, it glosses over something that
would be critical for us to think about in a real application: Which runs
faster, the "term" computation or the additions in the accumulator?  The
answer to that question leads to two a couple different solutions.

Before I show some possible solutions, I should mention that I'm not a big
fan of the way you wrote the "term" function.  I would argue that it is
much cleaner to write it as a pure function (something you can test).
Don't inject notions of channels into a pure arithmetic computation.  Also,
you've made the math unnecessarily convoluted with your overuse of ->.
Embrace infix math.  If you think the -1^k expression is awkward, you could
do something like this:

(defn term [k]
  (/ (if (even? k) 4 -4)
 (inc (* 2 k

There, a nice clean pure function that makes it clear that -1^k is just a
"trick" for putting the correct sign on the expression.  You can change 2
to 2.0 if you want to return a double rather than a rational number from
this function (or use this version and just coerce to the double in the
consumer, depending on the behavior you want).

Or, if you want to use pow:
(defn term [k]
  (/ (* 4 (Math/pow -1 k))
 (inc (* 2 k

Or, you can leverage the fact that multiplying by 1 or -1 is the same as
dividing and eliminate the multiplication:
(defn term [k]
  (/ 4 (Math/pow -1 k)
 (inc (* 2 k

Any of these would be preferable to the -> version which is harder to read.

Now, back to the key question.

Case 1: term is fast, addition is slow
In this case, we really just need one thread to generate all the term
expressions, and we simply want to let the producer get ahead of the
consumer by some bounded amount.  So something like this would work:

(defn pi [n]
  (let [ch (to-chan (map term (range (inc n]
(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] Initial release of Glow, a tiny library for syntax highlighting Clojure source code

[W. David Jarvis]

I thought about it early on but considered that a space that's largely
already addressed by highlight.js et al. If there's another use case you
had in mind for it that highlight et al. don't satisfy I'd be happy to look
into it :)

On Sun, Aug 2, 2015 at 7:55 AM, Reid McKenzie  wrote:

> Very nice! Have you put any effort into an HTML output target?
>
> Reid
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ntz-YPxwryA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

venanti.us
203.918.2328


-- 
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] Clojure 1.8.0-alpha3

[Dragan Djuric]

Is there any introduction/example/short intro on direct linking?

On Thursday, July 30, 2015 at 12:51:18 AM UTC+2, Alex Miller wrote:
>
> Clojure 1.8.0-alpha3 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha3
> - Leiningen: [org.clojure/clojure "1.8.0-alpha3"]
>
> Tuples have been disabled after further analysis of performance impacts.
>
> This alpha has initial support for direct linking which you can enable 
> with -Dclojure.compiler.direct-linking=true
>
> Direct linking allows functions compiled with direct linking on to make 
> direct static method calls to most other functions, instead of going 
> through the var and the Fn object. This can enable further optimization by 
> the jit, at a cost in dynamism. In particular, directly-linked calls will 
> not see redefinitions.
>
> In alpha3, clojure.core is compiled with direct linking by default and 
> therefore other namespaces cannot redefine core fns and have those 
> redefinitions seen by core code.
>
> Functions declared as dynamic will never be linked to directly.
>
> As with all alphas, this represents ongoing work-in-progress that is 
> subject to change.
>

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

core.async: implementing pi.go

[Divyansh Prakash]

I came across pi.go  in the examples for 
go-lang.
I've been trying to replicate it with core.async, and this is what I have 
till now:

(defn term [ch k]
>   (go (>! ch (-> 4.0 
>   (* (Math/pow -1 k))
>   (/ (-> k (* 2) (+ 1)))
>
 

> (defn pi [n]
>   (let [ch (chan)
> f  (atom 0)]
> (dotimes [k (inc n)]
>   (term ch k))
> (dotimes [k (inc n)]
>   (swap! f + ( @f))
>
 

> (defn -main []
>   (pi 5000))


This is more or less a direct translation and pretty ugly. Also, it throws 
an interminable stacktrace.
What would be the right way to do this?

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