Re: Help test the new Clojars server

I can tell by the beet-colored theme that beta.clojars.org is a wholesome replica. -- 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 b

Re: Help API

JavaHelp will work. Details here On Wednesday, December 27, 2017 at 8:17:09 AM UTC-5, Mortimer Cladwell wrote: > > I am looking for a help api for my clojure application, something that > will pop up when the user selects "Help" from t

Re: Help please: New to clojure development

Thank you, appreciate it On Feb 7, 2018 12:16 AM, "Aditya Athalye" wrote: > Welcome to Clojure, Nadeen. > > A few friends and I created "Clojure by example" for programmers not > familiar with Clojure https://github.com/inclojure-org/clojure-by-example > > This is intended as a quick-start to a

Re: Help please: New to clojure development

Welcome to Clojure, Nadeen. A few friends and I created "Clojure by example" for programmers not familiar with Clojure https://github.com/inclojure-org/clojure-by-example This is intended as a quick-start to a common way of problem-solving with Clojure. The README explains more, and should he

Re: Help please: New to clojure development

Nadeen: You are welcome to send questions here, of course. I wanted to point out another resource that many people take advantage of: The #beginners channel on Slack. https://clojurians.slack.com Sorry, I don't recall the exact button clicks necessary after you create a free account on Slack fo

Re: Help please: New to clojure development

Thanks Simon, I am using the repl and I am sorry, I should have click share to make it easier, don't know what I was thinking. Thanks everyone for your help, really appreciate it. On Feb 6, 2018 10:32 AM, "Simon Luetzelschwab" wrote: > Hi Nadeen, > > Welcome to Clojure! > > I'd recommend incorp

Re: Help please: New to clojure development

Hi Nadeen, Welcome to Clojure! I'd recommend incorporating Clojure's excellent REPL into your workflow to easily try things out with quick feedback. Here's an online version with your code snippet prepopulated - just hit the run button! https://repl.it/repls/OblongIntrepidAlabamamapturtle This

Re: Help please: New to clojure development

Thanks for the quick response James. Yes, you hit the nail on the head with me not understanding map, explanation you provided helps. I like the second option better. I have tried both options and now I am getting "illegalargumentexception, key must be an integer" When I call (state-desc3 input-fil

Re: Help please: New to clojure development

First: (#(map :st_abbrev input-file)) Is equivalent to: (map :st_abbrev input-file) Because your putting the form in an anonymous function, then immediately calling it. This is equivalent to just evaluating the form. Next, I think you're confused as to how `map` handles multiple arguments.

Re: Help with strange test output when deftest used inside a macro

Excellent, thanks! The actual macro is indeed a little more complicated, but the test assertions are limited to (is (= ...)), so replacing = with ~'= works perfectly. On Tuesday, October 10, 2017 at 3:10:37 AM UTC-6, Gary Verhaegen wrote: > > is is looking for specific patterns and, if it can't

Re: Help with strange test output when deftest used inside a macro

is is looking for specific patterns and, if it can't find a known one, defaults to assuming its argument is a random predicate and prints that. So what's happening here is the syntax quote expands (resolves) = to clojure.core/= and thus it doesn't match the pattern for = anymore. So you'd need

Re: Help with strange test output when deftest used inside a macro

The problem isn't the macro, it's your use of syntax quoting. `(= x y) gets expanded at read-time into `(clojure.core/= x y)`. Not much you can do about that. Although I'd suggest perhaps changing your code a bit to not require macros. deftest mostly just creates a defn with some extra metadata an

Re: Help ship Clojure 1.9!

Before Clojure 1.9 is shipped, I would like to reiterate the appeal from many in the community to stop the terrible, permanent mistake that is *clojure.core/any?* For those who have not seen past emails on this topic, you may view the main threads here: - https://groups.google.com/forum/#!

Re: Help ship Clojure 1.9!

I've run into a behaviour change that was actually already present in alpha20 – with the CLJ-99 patch in place, {min,max}-key now return the first argument with the minimum/maximum key, whereas previously they returned the last such argument. The new behaviour seems like the more natural one, but

Re: Help ship Clojure 1.9!

We've been using 1.9 in a small app for a while with no issues. After upgrading schema to the latest version (with the PR above) I've also successfully run our larger codebase with 1.9. On Tuesday, October 3, 2017 at 4:41:14 AM UTC-7, stuart@gmail.com wrote: > > Hi Mark, > > I think this app

Re: Help ship Clojure 1.9!

Hi Mark, I think this approach totally makes sense, and the alpha naming exists to inform this kind of decision-making. For libraries where the use of spec does not have to be user-facing, I am putting specs in separate (Clojure) namespaces, and loading them in such a way that they can coexist wi

Re: Help ship Clojure 1.9!

On Monday, October 2, 2017 at 3:16:55 PM UTC-5, Rob Nikander wrote: > > I get this when I switch from 1.8 to 1.9 beta, but maybe it's an issue > with the `core.match` library? > > WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: > clojure.tools.analyzer.utils, being rep

Re: Help ship Clojure 1.9!

I get this when I switch from 1.8 to 1.9 beta, but maybe it's an issue with the `core.match` library? WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/boolean? Rob On Thursday, September

Re: Help ship Clojure 1.9!

On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway wrote: > Hi David, > > Spec will be in alpha for a while. That is part of the point of it being a > separate library. Can you say more about what problems this is causing? > > Stu > > As a library maintainer, I am forced to upgrade and release my li

Re: Help ship Clojure 1.9!

Hello Stu, On 02/10/17 16:55, Stuart Halloway wrote: > Spec will be in alpha for a while. That is part of the point of it being > a separate library. Can you say more about what problems this is causing? I don’t have any stakes in this so it’s better if I withdraw my question. I was (still am) a

RE: Help ship Clojure 1.9!

" -- Margaret Atwood From: clojure@googlegroups.com on behalf of David Bürgin Sent: Saturday, September 30, 2017 1:52:47 AM To: clojure@googlegroups.com Subject: Re: Help ship Clojure 1.9! On 28/09/17 16:00, Stuart Halloway wrote: > Clojure 1.9 has been quite stable throughout the alpha

Re: Help ship Clojure 1.9!

Since spec is mainly a dependency of 1.9. to improve error reporting over 1.8 (correct me if I'm wrong), I'd like to point out this ticket again: https://dev.clojure.org/jira/browse/CLJ-2013 It solves what I determined the root cause of this report https://groups.google.com/d/msg/clojure/mIlKaO

Re: Help ship Clojure 1.9!

Hi David, Spec will be in alpha for a while. That is part of the point of it being a separate library. Can you say more about what problems this is causing? Stu On Sat, Sep 30, 2017 at 4:52 AM, David Bürgin wrote: > On 28/09/17 16:00, Stuart Halloway wrote: > > Clojure 1.9 has been quite stabl

Re: Help ship Clojure 1.9!

Other than spotting an issue with yada which involved upgrading aleph (https://github.com/juxt/yada/issues/199) and an issue with ClojureScript with was fixed on master I haven't encountered any problems. All our integration tests pass. Good luck with bringing Clojure 1.9.0 out the door! On Thu

Re: Help ship Clojure 1.9!

On 28/09/17 16:00, Stuart Halloway wrote: > Clojure 1.9 has been quite stable throughout the alpha period, and we > now hope to release after a very short beta. Please test your existing > programs on the latest beta (see below), and respond on this thread ASAP > if you discover anything you believ

Re: Help ship Clojure 1.9!

Yes, clojurescript makes use of a previous experimental feature of tools.reader that allowed Infinity and -Infinity to be read as Double/POSITIVE_INFINITY and Double/NEGATIVE_INFINITY, without special casing how the compiler emitted infinity literals, as clojure previously printed them as "Infi

Re: Help ship Clojure 1.9!

And to maybe answer my own question, I guess it is https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L988-L990 . On Fri, Sep 29, 2017 at 1:45 PM, Stuart Halloway wrote: > To be clear: we can certainly cut a new release of CLJS, I just want to > understand other op

Re: Help ship Clojure 1.9!

To be clear: we can certainly cut a new release of CLJS, I just want to understand other options, if any. On Fri, Sep 29, 2017 at 1:38 PM, Stuart Halloway wrote: > Hi Aleš, Mark, > > Thanks for the reports! It isn't clear to me how a change to tools.reader > can fix a problem with the core hash

Re: Help ship Clojure 1.9!

Hi Aleš, Mark, Thanks for the reports! It isn't clear to me how a change to tools.reader can fix a problem with the core hash function. Can somebody point me to the place in the Clojurescript code where this happens? Stu On Fri, Sep 29, 2017 at 11:13 AM, Aleš Roubíček wrote: > The Cljs problem

Re: Help ship Clojure 1.9!

The Cljs problem is easily solvable by referencing latest tools.reader: [org.clojure/clojurescript "1.9.908" :exclusions [org.clojure/tools.reader]] [org.clojure/tools.reader "1.1.0"] On Thursday, September 28, 2017 at 8:37:11 PM UTC+2, puzzler wrote: > > And to be clear, it doesn't only aff

Re: Help ship Clojure 1.9!

And to be clear, it doesn't only affect people who try to use ##Inf or ##NaN in their Clojurescript code. It affects all existing Clojurescript code, because running the Clojurescript compiler in a new version of Clojure causes all Clojurescript code to emit these ## characters directly into the j

Re: Help ship Clojure 1.9!

On Thu, Sep 28, 2017 at 11:02 AM, Jeaye wrote: > This has been the only issue we've run into with 1.9.0-beta1 ( ticket is > here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our back-end, > all tests are good, but we can't currently use beta1 (or alpha20) on the > front-end, since this iss

Re: Help ship Clojure 1.9!

Clojure 1.9 has been great for me so far. I think it's worth considering the problem Luke brought up regarding the REPL caught handler [1], especially since the compiler now checks macro specs. Having a slightly better knob for that might be nice, since it's an integration point. (This is not

Re: Help ship Clojure 1.9!

This has been the only issue we've run into with 1.9.0-beta1 ( ticket is here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our back-end, all tests are good, but we can't currently use beta1 (or alpha20) on the front-end, since this issue causes CLJS to choke. I'm hoping that a new version

Re: Help ship Clojure 1.9!

Thanks Beau! On Thu, Sep 28, 2017 at 1:06 PM, Beau Fabry wrote: > Identified an issue with prismatic/schema https:// > github.com/plumatic/schema/pull/399 > > On Thursday, September 28, 2017 at 9:18:52 AM UTC-7, Nathan Fisher wrote: >> >> Hi Stuart, >> >> Looks like any project using lein-cljsbu

Re: Help ship Clojure 1.9!

Identified an issue with prismatic/schema https://github.com/plumatic/schema/pull/399 On Thursday, September 28, 2017 at 9:18:52 AM UTC-7, Nathan Fisher wrote: > > Hi Stuart, > > Looks like any project using lein-cljsbuild will be affected. > > I forked and bumped the Clojure and ClojureScript ve

Re: Help ship Clojure 1.9!

Hi Stuart, Looks like any project using lein-cljsbuild will be affected. I forked and bumped the Clojure and ClojureScript version to latest and got the same error with their simple project: See Commit: https://github.com/nfisher/lein-cljsbuild/commit/5df5d3c5bb447b51a75abbbccdc72447814883a0 ST

Re: Help ship Clojure 1.9!

Hi Nathan, I suspect that is the same as https://github.com/clojure/clojurescript/commit/89914d2ead964122f99e638edda0cd96d330cb66. I don't have a sense of how many CLJS project this is going to cascade into, or what all will be needed. Anyone? Stu On Thu, Sep 28, 2017 at 10:44 AM, Nathan Fisher

Re: Help ship Clojure 1.9!

Hi Stuart, Working to create a minimal test case but upgrading from alpha19 to beta1 seems to have broken lein-cljsbuild. I get the following error: >> snip >> *SEVERE: /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js:3579: ERROR - Parse error. primary expres

Re: Help me understand what part of this code is slow, and how to make it faster?

That seems like a decent list. Also sounds like most of the Clojure Alioth contributions. :) -- 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

Re: Help me understand what part of this code is slow, and how to make it faster?

Here's my findings: Speed increase from most increase to least: * Pre-sizing the HashSet - from 4.7ms to 3.7ms * Inlining - from 4.7ms to 3.9ms * Using point. constructor instead of ->point - from 2.4ms to 2ms * Using non relfective HashSet init - from 2.36ms to 2.17ms * Using iterator instead of

Re: Help me understand what part of this code is slow, and how to make it faster?

@Marczyk, I did try your improvements, and it shaved off 2 seconds, from 4s for the nth5 to 2s for your implementation. I'm curious to try it one change at a time to see if any one of the changes was responsible for a bigger part, or if its an its of equal improvements that total up to a big sp

Re: Help me understand what part of this code is slow, and how to make it faster?

More likely, records being just as slow with Clojure 1.9.0-alpha14 probably mean that recalculating of record hashes was not a significant amount of the time your program was taking. Thanks for trying it out. Andy On Mon, Nov 21, 2016 at 5:03 PM, Didier wrote: > I tried it with the safe equals

Re: Help me understand what part of this code is slow, and how to make it faster?

> On Nov 21, 2016, at 8:03 PM, Didier wrote: > > @miner: Doesn't using the flag (set! *unchecked-math* :warn-on-boxed) gives > me unchecked math automatically? I was under the impression that +, -, /, * > etc. would all now perform in an equal way to unchecked-add, etc. If not, > what is the

Re: Help me understand what part of this code is slow, and how to make it faster?

PS. Results for the original input on my box. Going by the the timings posted above, yours is rather beefier, so this is probably faster than the current F# version. (c/quick-bench (nth-shell 2000 (point. 0 0))) Evaluation count : 6 in 6 samples of 1 calls. Execution time mean : 2.956

Re: Help me understand what part of this code is slow, and how to make it faster?

Some further optimizations for a factor of ~2.3 speed-up over nth5 as copy & pasted from upthread (6.713742 ms → 2.897630 ms) in (c/quick-bench (nth-shell 100 (point. 0 0))) (1) java.util.HashSet has a ctor that takes initial capacity of the set as an int. Passing in (* 4 (.size s1)) when const

Re: Help me understand what part of this code is slow, and how to make it faster?

I tried it with the safe equals, and it is slightly slower, but still faster then all others at 4.5ms. The non safe equals gives me 4s. Though this is now within my error margin. If ire-run quick-bench, I sometime get a mean equal for each, so I don't think the instance check adds that much ove

Re: Help me understand what part of this code is slow, and how to make it faster?

> On Nov 21, 2016, at 3:05 PM, Didier wrote: > > I experimented with this a lot, and took everyone's advice, and this is the > fastest I got, even faster then Michael Gardner's answer. > > (deftype point5 [^long i ^long j] > Object > (equals [this that] (and (= (.i this) (.i ^point5 that))

Re: Help me understand what part of this code is slow, and how to make it faster?

Not sure which version of Clojure you are using, but in all versions up to the latest 'official' release, Clojure 1.8.0, records have their hash value calculated every time they are needed, with no caching of the calculated value. The hash value is needed every time an operation is done in a Cloju

Re: Help me understand what part of this code is slow, and how to make it faster?

I experimented with this a lot, and took everyone's advice, and this is the fastest I got, even faster then Michael Gardner's answer. (deftype point5 [^long i ^long j] Object (equals [this that] (and (= (.i this) (.i ^point5 that)) (= (.j this) (.j ^point5 that

Re: Help me understand what part of this code is slow, and how to make it faster?

Below is the fastest version I tested, using ideas from the various responses in this thread. It runs in ~4s on my machine, compared with ~27s for the original version. The biggest win by far was from James Reeves' suggestion of switching to Java's mutable HashSet. I'm not sure why; I'd thought

Re: Help me understand what part of this code is slow, and how to make it faster?

In general, any benchmark code using math should be aware of boxing (old post here: http://insideclojure.org/2014/12/15/warn-on-boxed/). I would recommend doing the work to leverage primitive longs and unchecked math. Generally this makes numeric code like this about 2 orders of magnitude faste

Re: Help me understand what part of this code is slow, and how to make it faster?

On Wednesday, November 16, 2016 at 8:10:27 AM UTC-6, Jason Felice wrote: > > I'll bet the atom accesses dominate the computation. They are a part of > Clojures software transactional memory (STM) and have a cost. > Atoms don't use the STM and if used in a single-threaded context like this, th

Re: Help me understand what part of this code is slow, and how to make it faster?

I'll bet the atom accesses dominate the computation. They are a part of Clojures software transactional memory (STM) and have a cost. Something like this (untested) should be faster: (->> (iterate neighbors #{p}) (drop 1999) first) neighbors could be: (into #{} (for [[id jd] [[-1 0] [+1 0] [0

Re: Help me understand what part of this code is slow, and how to make it faster?

On 16 November 2016 at 03:39, Didier wrote: > > Currently, this takes about 30s in Clojure, while it only takes around 3s > for OCaml, Rust and F#. > > From what I see, the differences between my code and theirs are: > >- Lack of a Point struct, I'm just using a vector. >- They use a mutab

Re: Help with using spec

Hi Alex, Thanks very much for this, makes sense and has solved my issue. After a trying a few things, it appears that the ArityException was thrown because I would have needed to wrap my regex with s/spec i,e, (s/fdef my-function :args (s/cat :board (s/spec ::board))) So I think this all makes

Re: Help with using spec

I would back way up to the beginning and reconsider your ::board spec. Generally for any data where the structures are homogenous, you're probably better off using one of the collection specs like coll-of (or map-of, every, every-kv) rather than a regex, which should primarily be used when you

Re: [Help] core.async and jetty

Thanks Zach, I would love to do an unfair comparison between clojure and nodejs :) Gonna give it a spin On Tuesday, February 23, 2016 at 5:09:50 PM UTC, Zach Tellman wrote: > > For what it's worth, Aleph will handle pipelined requests in parallel: > https://github.com/ztellman/aleph. > > On Tue

Re: [Help] core.async and jetty

For what it's worth, Aleph will handle pipelined requests in parallel: https://github.com/ztellman/aleph. On Tuesday, February 23, 2016 at 4:46:23 AM UTC-8, Miguel Ping wrote: > > Thanks, thats what I eventually found out. > > On Tuesday, February 23, 2016 at 12:39:00 PM UTC, jonah wrote: >> >> H

Re: [Help] core.async and jetty

Thanks, thats what I eventually found out. On Tuesday, February 23, 2016 at 12:39:00 PM UTC, jonah wrote: > > Hi Miguel- pipelining is essentially http keep alive. A very old jetty > thread > > > http://jetty.4.x6.nabble.com/HTTP-1-1-Request-Pipelining-handling-td18682.html > >

Re: [Help] core.async and jetty

Hi Miguel- pipelining is essentially http keep alive. A very old jetty thread http://jetty.4.x6.nabble.com/HTTP-1-1-Request-Pipelining-handling-td18682.html indicates that for simplicity jetty will execute subsequent requests on the kept-alive socket serially. Jonah On Mon, Feb 22, 2016 at 3:3

Re: [Help] core.async and jetty

By the way, I can see that jetty is reusing the same HttpInput instance on the request (most probably because of pipelining) On Monday, February 22, 2016 at 8:33:37 PM UTC, Miguel Ping wrote: > > Hi guys, > > I'm trying to replicate an experiment on nodejs and http pipelining: > http://blog.yld.

Re: help with clojure

Okay, so: (defn evaltree [tree] (cons (eval tree) (rest tree))) That evaluates the tree, assuming that (rest tree) only contains numbers. (eval-tree '(+ 3 9)) However, we also want to evaluate the arguments in the same way. The arguments are a list, and when we want to do somethin

Re: help with clojure

Hey there, > Congratulations on getting this far. It took me a long time too to be able to do something this complicated. I think it's cool that you're thinking about this kind of problem. This is essentially a small recursive interpreter, which is a neat problem. How do you drop the first ele

Re: help with clojure

Ok by starting with the basic (Def a '(+ 3 9)) I have (Defn evaltree [tree] (Cons (eval tree) tree)) But I can't seem to get it to work or drop the plus from the list. I'm really struggling with this Thanks for your help -- You received this message because you are subscribed to the Goo

Re: help with clojure

So start with something like: (def a '(+ 3 9)) Then write a function where: (evaltree a) => (12 3 9) Don't worry about recursion to start with. Just get the simplest case working first. - James On 14 November 2015 at 17:46, wrote: > Sorry I'm a complete rookie at this that didn'

Re: help with clojure

Sorry I'm a complete rookie at this that didn't make a bit of sense to me. So far I have this: (def a '(* (+ 5 (* 3 7)) (- 6 8)) ) (defn evaltree [tree] (cons (eval (first (rest tree))) tree)) all i have so far which evals the first part of list but doesn't recurse through to do the rest

Re: help with clojure

When thinking about trees, I find it's often best to start with the most basic case. So in your case, begin by writing a function that deals with a single operator and two numerical arguments: (f '(* 4 9)) => (36 4 9) (f '(- 6 10)) => (-4 6 10) Next, consider the case where you have two p

Re: help on exercises of brave and feedback

> On Nov 14, 2015, at 5:10 AM, r/ Wobben wrote: > > What is the best way to find help with exercises of the brave book and > feedback on the solutions ? > This group, the irc channel or the reddit page ? All of the above :) Plus there’s a very active Slack for Clojurians. Check out http://c

Re: Help with idiomatic clojure.

Another tip when using seq then: cljs.user=> (or (seq [1 2 3]) false) (1 2 3) cljs.user=> (or (seq []) false) false cljs.user=> > On 13 Nov 2015, at 14:09, Brian wrote: > > I think I like 'seq' better than 'empty?'.I'm sure my opinions will firm > up after writing some more clojure. >

Re: Help with idiomatic clojure.

I think I like 'seq' better than 'empty?'.I'm sure my opinions will firm up after writing some more clojure. > Also, in no-errors branch you probably want to return status: 200? I picked the function where I knew there was a better way. This validation function is called from this bit code.

Re: Help with idiomatic clojure.

Doh - I obviously hadn’t had enough coffee that early in the morning :-). > On 13 Nov 2015, at 01:47, Chris Murphy wrote: > > > I think true and false should be swapped around, because seq and empty? are > opposites, seq meaning it is not empty. > > On 13/11/2015 8:08 AM, Colin Yates wrote: >

Re: Help with idiomatic clojure.

I think true and false should be swapped around, because seq and empty? are opposites, seq meaning it is not empty. On 13/11/2015 8:08 AM, Colin Yates wrote: One other minor point (if (seq some-sequence) true false) is preferred by some (I won’t say more idiomatic) than (if (empty? some-seque

Re: Help with idiomatic clojure.

The main thing to note is to not use atoms for things like this. Colin's cond-> approach is a good idea. On Thu, Nov 12, 2015 at 4:08 PM, Colin Yates wrote: > One other minor point (if (seq some-sequence) true false) is preferred by > some (I won’t say more idiomatic) than (if (empty? some-seque

Re: Help with idiomatic clojure.

One other minor point (if (seq some-sequence) true false) is preferred by some (I won’t say more idiomatic) than (if (empty? some-sequence) true false). Also, in no-errors branch you probably want to return status: 200? > On 12 Nov 2015, at 19:44, Brian wrote: > > Thanks Colin, Thanks Erik >

Re: Help with idiomatic clojure.

Thanks Colin, Thanks Erik Exactly what I was looking for. I've updated the gist with Colin's suggestion and a bit of destructuring. If this project gets any bigger I will definitely look at vlad and Prismatic Schema . BDF. On

Re: Help with idiomatic clojure.

There is also https://github.com/logaan/vlad which helps with validation. Erik. -- i farta > Den 12. nov. 2015 kl. 17.12 skrev Colin Yates : > > A nicer equivalent form would be: > > (cond-> [] > this-error? (conj “It failed with this error”) > that-error? (conj “It failed with that erro

Re: Help with idiomatic clojure.

A nicer equivalent form would be: (cond-> [] this-error? (conj “It failed with this error”) that-error? (conj “It failed with that error”)) However, purely for validation there are a few utilities out there already. Checkout the ‘Validation’ section on http://www.clojure-toolbox.com

Re: Help with decisions in threading macros

See also cond-> (Clojure core) and even condas-> (http://blog.juxt.pro/posts/condas.html) Oliy -- 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 moderat

Re: Help with decisions in threading macros

Thanks!! On Tue, Nov 3, 2015 at 7:38 PM Erik Assum wrote: > some->> > > Erik. > -- > i farta > > Den 3. nov. 2015 kl. 17.05 skrev Timur : > > Hi all, > > Often I need to make decisions in simple threading macros, for instance > consider the following code > > (->> m >:vector >(fi

Re: Help with decisions in threading macros

some->> Erik. -- i farta > Den 3. nov. 2015 kl. 17.05 skrev Timur : > > Hi all, > > Often I need to make decisions in simple threading macros, for instance > consider the following code > > (->> m >:vector >(filterv #(= (:id %) (:id m))) >(reduce #(and %1 %2))) > >

Re: Help with decisions in threading macros

Perhaps you can replace (reduce ...) with (every? true?), which works with empty collections. On Tue, Nov 3, 2015 at 6:05 PM, Timur wrote: > Hi all, > > Often I need to make decisions in simple threading macros, for instance > consider the following code > > (->> m >:vector >(fil

Re: Help with macro.

> > Yes, your solution works, but only on clojure. ClojureScript doesn't have > `resolve`. It there any portable solution? > > I'm not sure if and how you can do it in ClojureScript... have you tried: https://groups.google.com/forum/#!forum/clojurescript cheers, Gianluca -- You received this

Re: Help with macro.

On Sat, Oct 3, 2015 at 5:24 PM, gianluca torta wrote: > Hi, > > the behavior you describe is not specific to macros, but is due to the use > of aliases > > after: > (require '[foo.bar :as b]) > > this will give you false: > (= 'foo.bar/x (first '(b/x))) > > while this will give you true: > (= 'fo

Re: Help with macro.

Hi, the behavior you describe is not specific to macros, but is due to the use of aliases after: (require '[foo.bar :as b]) this will give you false: (= 'foo.bar/x (first '(b/x))) while this will give you true: (= 'foo.bar/x (first '(foo.bar/x))) one way to solve it, is comparing the resolved

Re: Help with data structure transformation

see also this page: http://clojure.org/sequences where for is listed among the seq library functions HTH Gianluca -- 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

Re: Help with data structure transformation

(for [[x y z] {:a "aa" :b "bb" :c "cc"}] [x y z]) ([:c "cc" nil] [:b "bb" nil] [:a "aa" nil]);; WTF? So her, I guess, your taking each entry in the map and destructuring them into the three vars x, y, and z. Since each map entry is a pair, the third var z will be nil. Erik. -- i farta

Re: Help with data structure transformation

x and y are destructured into the key and value of each map entry. Z is nil. The second example uses seq to convert the map into a sequence of map entries and then it destructures the seq (not the map entries themselves). The third example does destructure the map entries. (let [[a b c] [1 2]] [a

Re: Help with data structure transformation

On 06/06/2015 05:01, Sean Corfield wrote: Page 84 is where it shows that maps are a sequence of pairs. The destructuring in James's code is on vectors -- the pairs in the sequence. Hope that helps? Sean Page 84 describes the sequence abstraction in general but it's the implicit seq in for

Re: Help with data structure transformation

Page 84 is where it shows that maps are a sequence of pairs. The destructuring in James's code is on vectors -- the pairs in the sequence. Hope that helps? Sean On Fri, Jun 5, 2015 at 8:11 PM, gvim wrote: > Yes, I'm fine with the concept. Just can't remember coming across it in > the textbook

Re: Help with data structure transformation

Yes, I'm fine with the concept. Just can't remember coming across it in the textbooks but maybe I wasn't paying attention :) gvim On 06/06/2015 04:08, Sean Corfield wrote: It’s because if you treat a hash map as a sequence — as `for` does — you get a sequence of pairs (key/value — map entrie

Re: Help with data structure transformation

It’s because if you treat a hash map as a sequence — as `for` does — you get a sequence of pairs (key/value — map entries): (seq {:a 1 :b 2}) ;;=> ([:a 1] [:b 2]) Does that help? Sean > On Jun 5, 2015, at 7:41 PM, gvim wrote: > > I must re-read "Clojure Programming" (O'Reilly

Re: Help with data structure transformation

I must re-read "Clojure Programming" (O'Reilly) in that case as I don't recall the authors mentioning this kind of destructuring. gvim On 06/06/2015 03:33, Fluid Dynamics wrote: On Friday, June 5, 2015 at 10:07:05 PM UTC-4, g vim wrote: That works but I missed this possibility because I'

Re: Help with data structure transformation

On Friday, June 5, 2015 at 10:07:05 PM UTC-4, g vim wrote: > > That works but I missed this possibility because I'm still not clear how: > > (group-by :email signs) > > which produces a map of the form: > > {"a...@gmail.com " > [{:email "a...@gmail.com ", :sign "Cancer", :planet > "M

Re: Help with data structure transformation

That works but I missed this possibility because I'm still not clear how: (group-by :email signs) which produces a map of the form: {"a...@gmail.com" [{:email "a...@gmail.com", :sign "Cancer", :planet "Mars", :surname "Blogs", :first_name "Joe"} . ]} can be destructured

Re: Help with data structure transformation

Perhaps something like: (defn planet-sign-map [signs] (into {} (map (juxt :planet :sign) signs))) (defn extract-planet-signs [signs] (for [[email signs] (group-by :email signs)] {:email email, :signs (planet-sign-map signs)})) (defn find-planet-signs [emails] (extract-planet-signs (get

Re: Help with async operations

Hi Rangel, thanks! works perfectly! понедельник, 18 мая 2015 г., 4:07:53 UTC+6 пользователь Rangel Spasov написал: > > You can checkout the new pipeline stuff, I think it fits what you're > looking for nicely: > > https://gist.github.com/raspasov/7c9d8f2872d6065b2145 > > -- You received this

Re: Help with async operations

Hi Atamert, воскресенье, 17 мая 2015 г., 19:35:57 UTC+6 пользователь Atamert Ölçgen написал: > > I’m new to Clojure async operations (while have a good understanding of >> other things) and want to get a bit of advice. Atoms & agents still confuse >> me. >> >> What I’m implementing is a small R

Re: Help with async operations

You can checkout the new pipeline stuff, I think it fits what you're looking for nicely: https://gist.github.com/raspasov/7c9d8f2872d6065b2145 On Saturday, May 16, 2015 at 10:54:16 PM UTC-7, Oleg Dashevskii wrote: > > Hi, > > I’m new to Clojure async operations (while have a good understanding

Re: Help with async operations

Hi Oleg, On Sun, May 17, 2015 at 6:48 AM, Oleg Dashevskii wrote: > Hi, > > I’m new to Clojure async operations (while have a good understanding of > other things) and want to get a bit of advice. Atoms & agents still confuse > me. > > What I’m implementing is a small REST webservice with custom

  1   2   3   4   5   6   7   8   >