Re: s/valid? does not tell me if the data is valid as supplied
On Thursday, February 22, 2018 at 12:58:00 AM UTC+1, Sean Corfield wrote: > > Looking around I see lots of cases where people do use conformers for > coercion. > > > > That doesn’t make them right > Oh, I agree, I'm just being realistic. The cat is out of the bag. I just googled for 's/conformer' and found an entire library of conformers that do various data conversions. > At a first glance it seems very natural, and warnings not to do it are not > easily found. > > > > Every single time coercion comes up anywhere in the context of spec, > someone says “don’t do that”, and they’ve been saying it since the earliest > alpha versions of spec. You would be correct to point out that nothing in > the spec overview or spec guide on clojure.org carries this caution, > however (and I think it’s a reasonable “ask” for the guide to be updated to > include such a caution). > > > > My recommendation is to have a strictly non-coercive spec for the target > data “type” / shape you want, and to have a second spec that combines the > coercion you want with that spec. That way you have a way to tell if your > uncoerced data conforms to the spec, as well as a way to do coercion in > s/conform. They are – and should be – two separate specs and two separate > operations. They represent different layers of abstraction inside your > application (so “of course” they should be two separate specs, one built on > top of the other). > Also agree. I think coercion and conformance verification are two separate concepts and should not be conflated. I like the idea with two specs, as this lets me get some reuse. > Given that the overview and the guide don’t even mention s/conformer, I’m > not sure where that recommendation should live. Alex, any thoughts on this, > since you seem to be the one most often making the recommendation? > As a spec user, I would expect to learn about this from the spec guide. Also, I still believe that in the short term a function that validates a spec without calling conformers would be useful. best regards, --Jan -- 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: s/valid? does not tell me if the data is valid as supplied
On Tuesday, February 20, 2018 at 4:53:33 PM UTC+1, Alex Miller wrote: > > This is exactly why we recommend that you not use conformers for coercion. > Conformers were added primarily as a tool for building custom composite > spec types (for example, we used it to build keys* from keys). > I am afraid that ship has sailed. Looking around I see lots of cases where people do use conformers for coercion. At a first glance it seems very natural, and warnings not to do it are not easily found. > This is a common need though and I would be happier if spec did more to > help you solve it in a way that minimized repetition and maximized the use > of existing specs. I'm still thinking through what that would mean exactly. > It's challenging right now to plug externally without rebuilding a > significant part of spec, so that's obviously not ideal. > > Ideally, you would be able to say the things that are important here: > > - the spec of the incoming data (strings or whatever - JSON sourced is the > major use case) > - the spec of the data I desire > - the coercion functions that can move from one to the other (there are > probably a small number of these that are widely reused) > - some way to coerce+validate or coerce+conform > > Building coercion into a single spec itself instead leads to the problem > of not being able to know what the source data actually was, and that's > really at odds with the spec philosophy and the notion of bidirectional > conforming. > I'm glad you see the need, highlighting it was largely the point of my post. As for these requirements, I agree, although I'm not sure about the need to know about the source. Regardless of larger future plans, I think my original suggestion still stands: it would be nice to have a function that would tell me if the data is valid as supplied. And another minor point: when I call a validation function (as part of contract checking), I do not necessarily expect to deal with all kinds of exceptions that coercion functions might throw. --J. -- 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.
s/valid? does not tell me if the data is valid as supplied
I've been using spec for a while now, in a reasonably large code base (>30k lines of Clojure and ClojureScript) and there is an issue that bit me several times. I use conformers for coercing data that is *almost* what I need, usually when reading from JSON (RethinkDB). Common conformers are keyword and set. And it works really well, except for one problem: there is no way to know if data has been conformed or not. Calling s/valid? will tell me if the data is valid *if it has been conformed*. But what if it hasn't? Can I use the data? Is it "valid" according to the spec I wrote? This is a very real problem: I've spent considerable time chasing bugs where there was a code path which did not call s/conform. The data passed all validations done with valid? and the bug manifested itself far down the road, where something expected a keyword instead of a string, or a set instead of a vector. Here is a specific minimal example demonstrating what I'm talking about: (ns spectest (:require [clojure.spec.alpha :as s])) (s/def ::test-spec (s/and (s/conformer keyword) keyword?)) (s/conform ::test-spec "a") ;; :a (s/valid? ::test-spec "a") ;; true I expected the last valid? to return false, because my code does not expect a string, it expects a keyword, according to the spec. I might be missing something, but I would much rather see valid? tell me if the data is valid for use (as supplied) and have a separate valid-when-conformed? which tells me if the data is, well, valid when conformed. It seems to me that the current valid? that does two things is confusing and not very useful for contracts. At the very least I'd really like to see a function that tells me if the data is valid *as supplied*, as this is the function that I'd want to use when enforcing contracts everywhere in my code. Alternatively, I could stop using conformers altogether, and write explicit data conversion functions. That might not be a bad idea, but it seems other people started using conformers, too, so eventually I'll hit the same problem again. --J. -- 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: An Annotation within an Annotation
Hello, I have forgetten an error that 'lein compile' gives. java.lang.IllegalArgumentException: Metadata can only be applied to IMetas, compiling:(rhsm/cockpit/tests/register_tests.clj:88:35) Exception in thread "main" java.lang.IllegalArgumentException: Metadata can only be applied to IMetas, compiling:(rhsm/cockpit/tests/register_tests.clj:88:35) Have a good day, Jan Stavel -- 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.
An Annotation within an Annotation
Hello everybody, I am trying to annotate a method in clojure where annotation type is made up of nested annotations. Example of similar java code: https://github.com/jstavel/rhsm-qe/blob/polarion-annotations/src/rhsm/cli/tests/ContentTests.java#L66 I want to do the same in clojure. This is my attempt to do that: https://github.com/jstavel/rhsm-qe/blob/polarion-annotations/src/rhsm/cockpit/tests/register_tests.clj#L87 A definition of the TestType interface: https://github.com/RedHatQE/polarize/blob/master/src/main/java/com/github/redhatqe/polarize/metadata/TestType.java#L11 Any hint welcome. Have a good day, Jan Stavel -- 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.
Parsing and querying binary .fit files in Clojure
As an active cyclist, I always wanted to do power-data analysis in my favourite language, so I finally put together this little tool: https://github.com/janherich/fit-to-edn. I hope it will be useful for someone else as well, what it does & how to use it is pretty well documented in the readme <https://github.com/janherich/fit-to-edn/blob/master/README.md>(and of course code as well). There are still many things I want to implement there, for example another weighted average algorithm (x-power used by golden-cheetah and strava), filtering input .fit files by date and date ranges and also virtual elevation profile for accurate Cda estimations by Robert Chung's method <http://anonymous.coward.free.fr/wattage/cda/indirect-cda.pdf>. If you have any suggestions or ideas for improvement, just write me here, or open a PR. Cheers Jan -- 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] data.avl 0.0.13 – fast sorted collections with O(log n) slices and nth
Very awesome :D!
Cheers, Jan
> On 09 Dec 2015, at 10:39, Michał Marczyk <michal.marc...@gmail.com> wrote:
>
> Hi,
>
> I am pleased to announce the 0.0.13 release of data.avl, a Clojure
> Contrib library providing highly performant drop-in replacements for
> Clojure(Script)'s built-in sorted maps and sets with the following
> headline features:
>
> 0. performance often superior to the built-ins (owing to the smaller
> height of AVL trees), see end of this email for some benchmarks
>
> 1. logarithmic-time slicing and splits:
>
> (avl/split-key 3 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1 2} 3 #{4 5 6}]
>
> (avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1} #{2 3 4 5}]
>
> (avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 2 < 5)
> ;= #{2 3 4}
>
> All returned collections are independent from the originals for GC
> purposes (no holding on to out-of-range keys present in the
> original collections), all operations run in O(log n) time in
> asymptotic terms, and actually fast in real-world terms.
>
> 2. logarithmic-time access by rank and rank queries:
>
> (nth (avl/sorted-set 0 1 2) 1)
> ;= 1
>
> (avl/rank-of (avl/sorted-map-by > 0 0 1 1 2 2) 0)
> ;= 2
>
> 3. nearest-neighbour lookups:
>
> (avl/nearest (avl/sorted-set 0 1 2) < 1)
> ;= 0
>
> The complete clojure.core sorted collections API is also supported, as
> is the transient API. See the README for more detailed examples and
> feature descriptions.
>
> Fixed in this release:
>
> 1. IMeta and IFn implementations now use correct method names in the
> ClojureScript version.
>
> 2. sorted-map/sorted-map-by now throw exceptions if no value is
> provided for the final key (in other words, if an odd number of
> arguments is passed in) – patch by Andy Fingerhut, thanks!
>
> Changed in this release:
>
> 1. Seqs over data.avl maps now use node objects themselves as map
> entries. This is in line with the behaviour of Clojure's built-in
> sorted maps. Previously seqs over data.avl maps used
> freshly-allocated map entry objects; this had the benefit of not
> holding on to subtrees in some scenarios, however not without some
> performance and GC pressure cost to regular traversals. Note that
> the new behaviour allows the user to rewrap key/value pairs as map
> entries if they so choose in a separate map step.
>
> 2. Because of 1., AVL nodes now implement vector and map entry
> interfaces.
>
> Cheers,
> Michał
>
>
> ;;; A handful of benchmarks
>
> ; CIDER 0.9.1 (Java 1.8.0_45-internal, Clojure 1.8.0-RC2, nREPL 0.2.10)
>
> user> (def ks (range 1))
> #'user/ks
> user> (def ksks (doall (interleave ks ks)))
> #'user/ksks
> user> (def m1 (apply sorted-map ksks))
> #'user/m1
> user> (def m2 (apply avl/sorted-map ksks))
> #'user/m2
> user> (.tree m1)
> [4095 4095]
> user> (.getTree m2)
> [4095 4095]
> user> (let []
> (prn :>>>>>>>>> 0)
> (c/quick-bench (get m1 0))
> (c/quick-bench (get m2 0))
> (prn :>>>>>>>>> 4095)
> (c/quick-bench (get m1 4095))
> (c/quick-bench (get m2 4095))
> (prn :>>>>>>>>> )
> (c/quick-bench (get m1 ))
> (c/quick-bench (get m2 )))
> :>>>>>>>>> 0
> WARNING: Final GC required 9.525315094951035 % of runtime
> WARNING: Final GC required 88.3127760569387 % of runtime
> Evaluation count : 2280474 in 6 samples of 380079 calls.
> Execution time mean : 262.138936 ns
> Execution time std-deviation : 56.938518 ns
>Execution time lower quantile : 237.779848 ns ( 2.5%)
>Execution time upper quantile : 360.756510 ns (97.5%)
>Overhead used : 20.503990 ns
>
> Found 1 outliers in 6 samples (16.6667 %)
> low-severe 1 (16.6667 %)
> Variance from outliers : 64.2134 % Variance is severely inflated by outliers
> WARNING: Final GC required 78.56747149813818 % of runtime
> Evaluation count : 2280498 in 6 samples of 380083 calls.
> Execution time mean : 261.626921 ns
> Execution time std-deviation : 42.454179 ns
>Execution time lower quantile : 241.444705 ns ( 2.5%)
>Execution time upper quantile : 335.120524 ns (97.5%)
>Overhead used : 20.503990 ns
>
> Found 1 outliers in 6 samples (16.6667 %)
> low-severe 1 (16.6667 %)
> Variance from outliers : 47.5275 % Variance is moderately inflated by
> outliers
> :&
Re: Awesome Clojure Engineer Opportunity
Hey Rameen, Cool, I didn’t know that Apple was using Clojure internally. Cheers, Jan > On 12 Oct 2015, at 22:00, Rameen Fattahi <rameenfatt...@gmail.com> wrote: > > Hi Everyone, > > My name is Rameen and I'm looking for a passionate Clojure engineer for a > very confidential project at one of the biggest companies in the world > (cannot name it here for privacy reasons). > > This is a full time role on our Applied Machine Learning team. If you're > interested, please send me your resume and I'd be happy to chat with you. > > Thanks a lot, > Rameen Fattahi, Technical Recruiter > > > -- > 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 > <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 > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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: rand-nth on empty collections
Throwing an exception is probably the right thing to do if it's supposed to closely model the behavior of `nth`, but it wonder if it's the most usefull behavior in practice. I would guess that it introduces `not-empty` checks everywhere, instead of only for the cases where you want to be shure that the nil returned is actually an element of the collection. cheers Jan > On 30 Sep 2015, at 20:18, Mark Engelberg <mark.engelb...@gmail.com> wrote: > >> On Wed, Sep 30, 2015 at 12:14 PM, Mark Engelberg <mark.engelb...@gmail.com> >> wrote: >> I also think it makes perfect sense for rand-nth to throw an error on an >> empty collection. That's because the first step is it needs to generate a >> random number between 0 and the length of the collection (0), which is >> impossible. So it should throw an error. Note that it is the *random >> generation of the index*, not the nth that conceptually is throwing the >> error. > > To be clear, when I say that nth "conceptually is throwing the error", I just > mean that's how I rationalize Clojure's behavior. That's not really what's > going on. (rand-int 0) returns 0 (which it probably shouldn't, given that > the input is meant to be an exclusive upper bound). So in fact, the error is > thrown by clojure.lang.RT.nthFrom, which is surprising. > > > -- > 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.
Clojure Jobs Available
We're a stealth startup in the fintech space building consumer-scale, fully distributed systems in Clojure along with cutting edge data storage and transaction technologies. We're Clojure all the way to the edge. We have teams in Seattle, Sydney, and Costa Rica and are looking to hire senior engineers with Clojure/Lisp experience. Many of our engineers come from a CL background and we also have senior engineers who have recently switched to functional programming and LISP. If you're looking for an excellent team and awesome product to work on, then here at SecureOne™ is the best place to be. We care about solid engineering, reliable and resilient systems, low latency distributed processing, streaming analytics, high scalability, and extreme performance… and we're doing all of them. If you're interested, please deliver a resume to jobs at SecureOne.com and Jan Drake (http://www.linkedin.com/in/janman) will get back to you. We hope to hear from you. Jan Drake VP of Engineering Operations SecureOne Corporation -- 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: Is this the good way to write get-percentage
I really don't think that calculating percentages warrants a DSL. (I'm not even sure if percent warrants a function ;} ) `(round (percent ...)) (round-up (percent ...)) (round-down (percent ...))` Seems far more readable to me than having a function that does many things at once, be it higher order, keyword configured or pre `comp`ed. Cheers Jan -- 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: Architectural doubts
Why not stream frames directly into the datomic db as they fall out of gloss?
This should be faster at query time anyhow due to indexes,
and let's datomic handle the memory management.
cheers Jan
On 31 Jan 2015, at 11:39, Milton Silva milton...@gmail.com wrote:
While using wireshark to analyse libpcap files (= 200 MB) I routinely think
that it would be great to preform relational queries but, wireshark only
supports search.
I thought I would decode the entire file, hold it in memory as clojure data
structures and use datomic's datalog.
Besides relational queries, a requirement is for the file to be decoded
(libpcap, ethernet-II, IP, TCP, diameter) in less then a minute(for a 200MB)
and the typical queries should also be less than a minute.
I thought the frames could be represented like this:
{:frame-id 1
:timestamp java's instant-object
:src-mac string
:dest-mac string
:src-ip
:dest-ip ...
...}
{:frame-ids [1 3]
:diameter-session-id ...}
So, I started by using gloss to decode a 200MB file. Gloss is fantastic to
specify frames but, it is not meeting the time requirements. It appear the
problem has to do with the creation of a lot of objects. Even with 3G of ram
for the heap, it still crawls to a halt.
I could try to perform some experiments to determine approximate answers but,
I think it is better to talk with people with more experience in order to
avoid common pitfalls..
My questions are:
Will the JVM (with 3G) support a million hashmaps like the above?
Is Buffy able to do something like what I want?
Will datomic be able to handle this use case?
What would you suggest to solve this(e.g. don't use clojure data structures..
but then datomic's datalog is not available to query?)?
--
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: When to use metadata
Solussd is absolutely correct, but maybe even more simplistic (or easier to
grasp) explanation would be to use metadata if you don't want the
additional (meta)data to change the equality semantics of the map, for
example:
(def test-desc1 {:number-of-threads 10})
(def test-desc2 ^{:integration true} {:number-of-threads 10})
(def test-desc3 {:number-of-threads 10 :integration true})
(= test-desc1 test-desc2) ;; returns true
(= test-desc1 test-desc2 test-desc3) ;; returns false, because while the
first two vars reference equal values, the third one doesn't
Dňa štvrtok, 29. januára 2015 16:10:34 UTC+1 Jonathon McKitrick napísal(-a):
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
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: if-not implementation
Even with inlining the code is rather silly ;) [x] (if x false true) so you'd get, (if (if test false true) then else) Which relies a bit too much on the JVM's JIT for my taste :D I've always wondered what the reason for the original implementation is. Keep closer to the implementation of not, so that no incompatibilities arise should not become a protocol one day? Cheers Jan On 22 Jan 2015, at 01:32, Mikera mike.r.anderson...@gmail.com wrote: Interesting - there seems to be a very slight performance advantage to your version on my machine (consistently about 25% faster for if-nots in a tight loop). I think the problem is actually with not - which isn't getting inlined currently. If I patch not so that it is inlined, the difference disappears. Worth a quick patch maybe? On Thursday, 22 January 2015 03:51:37 UTC+8, Leon Grapenthin wrote: I am surprised to find the two branch implementation of if-not as follows: ([test then else] `(if (not ~test) ~then ~else)) What I expected was: ([test then else] `(if ~test ~else ~then)) -- 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: DSL in RTL (Right to Left) languages.
I would wrap everything in a tree walking macro that first reverses all lists and then starts evaluating other macros. I'd love to see an Arabic clojure file btw :D But non English source always makes me shudder a bit, one of the great things about programming is that everybody speaks English ;) cheers Jan On 14 Jan 2015, at 05:52, clojure.u...@gmail.com wrote: Hi I need to write a dsl in Arabic which is a RTL. I am not sure how to get started with such a dsl in clojure. Any pointers with be really appreciated. 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. -- 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: Author a Book on Clojure - Packt Publishing
Just my 50 cent. I was asked to do a technical review on a Clojure podcasts by packtpub once. The storyboard they send me consisted of a word file containing a huge table with text and source code. Why would anybody send a technical reviewer source code in a word document, yet alone in a table column that has a width of 50 characters which causes it to line-wrap everywhere?! It feels to me that this publisher is just a book mill that goes for quantity and not quality. I couldn't make it thought a single book I bought from them because reading them felt like a waste of time. Of course things might have changed by now and your mileage may vary. I'm just thinking that if somebody takes the time of writing a book on Clojure, it should at least be worthwhile. All the best, Jan On 20 Dec 2014, at 09:07, Tushar Gupta tos...@gmail.com wrote: I am Tushar Gupta, an Acquisition Editor at Packt Publishing. We specialise in publishing books, eBooks, video tutorials and articles for IT developers, administrators and users. We are currently planning to develop a book on Clojure Data structures and Algorithms. We are looking for an expert to author this book and share their knowledge and skills with our readers. For more information you can mail me on tush...@packtpub.com. Looking forward to have some legit responses. :) -- Regards, Tushar Gupta Acquisition Editor Packt Publishing www.packtpub.com http://www.packtpub.com/ Skype: packt.tusharg x-msg://4/tush...@packtpub.com%3C -- 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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] stateful-check 0.1.0 - test stateful systems with test.check
Hi Carlo, Thanks for sharing! I see that generative testing of statful computations is a popular topic in the Clojure world these days; I think we've started working on our libraries nearly the same day :) https://github.com/jstepien/states All the best, Jan -- 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: If code is data why do we use text editors?
Yeah this would be awesome, but sadly representing Clojure code as data is as hard as representing Java. All the reader macros make it a nightmare, and the closest thing you'll get is tools.analyzer AST nodes. Session is certainly a step in the right direction, and I wish more people would embrace it, but it works on text as well. Same pretty much goes for codeq, if that is not dead. One could define a Clojure subset that is valid EDN though, which would make everything from serialisable functions to a nano-pass compiler a lot easier. This has to be the first step imho. Cheers Jan On 14 Nov 2014, at 17:09, atucker agjf.tuc...@gmail.com wrote: re As I understand it, Session https://github.com/kovasb/session and codeq https://github.com/Datomic/codeq are tools that somehow keep your code in a database instead of plain text. On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote: Hi, here is an idea that has been in my mind for a while. I wonder what you think about it. In Clojure code is data, right? But when we program we manipulate flat text files, not the data directly. Imagine your source code where a data structure (in memory). And programming is done by manipulating this data structure. No text editor and text files involved. Your editor directly manipulates the source data and later saves it on disk (maybe as a text file). These are the benefits I can think of: - It enables you to use any Clojure function to manipulate your source „code“. Giving you hole new opportunities for refactoring.This functions can be provides as library. - Really nice auto complete. - Visual programming. Source code can be represented in many different ways (not just text) . The easiest example I can think of is color. It can be represented as text of course (#23FF02) but that’s a quite bad interface for humans. Why not display the actual color and provide a color picker? Or what about music notes? Or Math formulars? Or what about a tree view to move and rename functions like files? This could all be implemented in a way that every library can ship there own „views“. I think this „views“ are basically macros that are not limited to text. - You don’t have to worry that you text files are in the same state as your JVM (when developing interactive). You only work on your sourcedata and it gets loaded into the JVM automatically. - Answer questions about your source code. What is the most called function? Who depends on this namespace? Where is this function used? What is the biggest function? Thinks like that become easy. Again you can ship this queries as a library. The drawback is you can’t simply program using any text editor. You need a special tool. But we have that anyway (syntax highlighting, paredit etc.). Nobody programs using a bare text editor. Maybe this idea is not new? What do you 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: better way to group consecutive numbers in a vector?
I think what you want is `partition-between` as implemented by amalloys useful lib (https://github.com/amalloy/useful/blob/develop/src/flatland/useful/seq.clj#L224 https://github.com/amalloy/useful/blob/develop/src/flatland/useful/seq.clj#L224). `(partition-between (fn [x y] (not= (inc x) y)) coll)` Why this isn’t in the standard library is beyond me tbh, as `partition-by` is a special case for `partition-between`. `(def partition-by (partial partition-between not=))` Maybe adding it to clojure.core should be considered? Also I’d be intrigued to know the rationale behind `partition-by`. Cheers, Jan On 07 Nov 2014, at 18:56, Alex Hammel ahamme...@gmail.com wrote: Here's my take on the 'add delimiters and split' approach. Bonus `congeal function, which chunks collections on any condition you like: (defn- insert-gaps [coll pred gap-symbol] (reduce (fn [acc x] (if (pred (peek acc) x) (conj acc x) (conj acc gap-symbol x))) [(first coll)] (rest coll))) (defn split-coll [coll delimiter] (- coll (partition-by (partial = delimiter)) (remove (partial = (list delimiter) (defn congeal [pred coll] (let [gap-symbol (gensym)] (- coll (insert-gaps pred gap-symbol) (split-coll gap-symbol (defn consecutive? [p q] (= (inc p) q)) (println (congeal consecutive? [1 3 4 5 7 9 10 11 12])) #= ((1) (3 4 5) (7) (9 10 11 12)) (println (congeal [1 2 3 1 2 3 1 2 3])) #= ((1 2 3) (1 2 3) (1 2 3)) (println (congeal not= [:foo :foo :bar :bar :foo :bar])) #= ((:foo) (:foo :bar) (:bar :foo :bar)) On Fri, Nov 7, 2014 at 4:09 AM, Paweł Rozynek pro...@gmail.com mailto:pro...@gmail.com wrote: (def data '(1 3 4 5 7 9 10 11 12)) (map #(map last %) (partition-by #(apply - %) (map-indexed vector data))) = ((1) (3 4 5) (7) (9 10 11 12)) regards PR -- 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: Question about test.check, and knossos
Hi Andy, Lately I've been exploring the world introduced to me by watching the John Hughes' quickcheck video from clojure west. Awesome stuff! Eventually I found the testing for fun and profit[1] paper which left me wanting to test my apps using a model based system like the paper describes. It looks like test-check-knossos[2] takes a stab at applying knossos[3] to this problem. However the examples in that repo don't capture the the aspect of using state to generate test commands to be executed against the system. It's just a random stream of :take/:reset operations whereas the registry example in the paper seems to require that the function which generates the sequence of test commands has access to the state of the system under test at the start of each command. So is there a missing clojure library here? Is anybody working on something that allows this style of model testing? If not, would it make sense for someone writing one to leverage knossos in any way? Cheers, Andy [1]: http://people.inf.elte.hu/center/fulltext.pdf [2]: https://github.com/philandstuff/test-check-knossos [3]: https://github.com/aphyr/knossos I've begun to work on such a tool not long ago. Thomas Arts, who gave a talk at our local FP user group meetup [mλ], inspired me to try out the approach you're describing in Clojure. After some experiments I got the library to a state where it could generate test cases for java.util.HashSet. I looked for prior art in the area of concurrency and detection of race conditions. That's when I discovered Philip Potter's Knossos-based approach [pp]. I find it very interesting but I haven't yet had time to try it out. It'd be great to have it integrated, though. I demonstrated the tentative API in [gist], where some simple properties of HashSet and Clojure vector are checked. The gist also shows how an exemplary failure looks, including shrinking. I'll try to get the implementation to a reasonable state and push it to GitHub soon. Feedback is very welcome! Cheers, Jan Stępień [mλ]: http://www.meetup.com/Munich-Lambda/events/202278902/ [pp]: http://vimeo.com/100976693 [gist]: https://gist.github.com/jstepien/6153312613db1589f1ec -- 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: Schrodinger's cat in clojure?
Transducers build up transformation steps, with new generic operations like single arg `map` and `filter`, and then apply these transformations to a collection using an evaluation function. This function decides if operations are done lazily, eagerly, or on a channel. Note that while this makes the place where laziness occurs more obvious, it is not really new. You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. While `mapv` or `filterv` are not. On 11 Oct 2014, at 00:28, Mars0i marsh...@logical.net wrote: On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote: Maybe an ideal world would be one in which there was a global setting to turn laziness on and off. When you want it, have it, and know your risks. After looking at the source for some of the lazy functions, I've come to suspect that such a feature would be completely nontrivial. Oh, wait, Rich Hickey's blog post about transducers says: But transducers can also be used for: a la carte laziness ... collection/iteration/laziness-free transforming reductions Not certain what this means. Haven't fully grokked reducers. -- 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: Schrodinger's cat in clojure?
I feel that there are some misconceptions here, Clojure is not a language that has lazy evaluation, but is instead completely eager. Macros are the closest thing that come to laziness, but they are still different. However, Clojure has a data structure, that also serves as an abstraction layer, that implements laziness, called a sequence or seq. Therefor turning of laziness makes no real sense. You could say disable the laziness of seqs, but that doesn't really make sense either. It's like disabling the FIFO nature of a queue or a channel. If you don't want the properties of a seq, then use another data structure, like a vector. On 11 Oct 2014, at 18:14, Mars0i marsh...@logical.net wrote: Thanks Jan-Paul. That's helpful. I wonder whether, if all lazy functions were rewritten in terms of transducers, it would then be easy to turn laziness on and off. (I am not suggesting that this should be done. No doubt it would entail a lot of work, and performance tradeoffs. I'm quite happy with Clojure as it is, despite anything negative I might say about impacts of laziness in some circumstances.) On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote: Transducers build up transformation steps, with new generic operations like single arg `map` and `filter`, and then apply these transformations to a collection using an evaluation function. This function decides if operations are done lazily, eagerly, or on a channel. Note that while this makes the place where laziness occurs more obvious, it is not really new. You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. While `mapv` or `filterv` are not. On 11 Oct 2014, at 00:28, Mars0i mars...@logical.net wrote: On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote: Maybe an ideal world would be one in which there was a global setting to turn laziness on and off. When you want it, have it, and know your risks. After looking at the source for some of the lazy functions, I've come to suspect that such a feature would be completely nontrivial. Oh, wait, Rich Hickey's blog post about transducers says: But transducers can also be used for: a la carte laziness ... collection/iteration/laziness-free transforming reductions Not certain what this means. Haven't fully grokked reducers. -- 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 the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, 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. -- 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: Schrodinger's cat in clojure?
Yes you are right, currently a lot of stuff is seq only. I think that reducers provide a lot of eager operations, but not everything. So yeah, transducers are exactly what you are looking for. If you call `sequence` with the transducer you get laziness, if you call `into` with a collection and a transducer, you get eagerness :). No decision about the evaluation strategy has to be made up until that point, and afaik transducers implement most classical seq constructs. On 11 Oct 2014, at 21:09, Mars0i marsh...@logical.net wrote: I don't think I have any misconceptions. I probably haven't expressed myself clearly. Clojure has many very useful functions that return lazy sequences. Analogous functions in other languages perform what are exactly the same operations, except for the fact that what's returned is not a lazy sequence, but instead is a different kind of sequential structure. For example, Common Lisp'smapcar is very much like Clojure's map, but mapcar returns a (non-lazy) singly-linked list. As you point out, there are also functions in Clojure that return sequential structures that are not lazy. Moreover, it's easy to convert a lazy sequence into a non-lazy sequence through use of, for example, doall or vec. However, writing code in Clojure that only used non-lazy sequences would be unnatural and verbose, as Lee points out. No one would bother doing that. Part of what's great about Clojure is the convenience of its set of sequence operations. If you're not using those, you're not getting full benefit from Clojure. So as a practical matter, one must deal with laziness in Clojure. However, almost the same language could be constructed without any laziness, just by replacing lazy functions such as map with non-lazy analogues. In that case, you could do all of the same things in those situations that don't require laziness. (You couldn't use lazy infinite sequences, and you'd have to worry about keeping large data structures in memory, etc. But in many situations, those features aren't needed.) That's what I mean by turning off laziness: Replacing every function that returns a lazy sequence with its closest non-lazy analogue. On Saturday, October 11, 2014 12:01:34 PM UTC-5, Jan-Paul Bultmann wrote: I feel that there are some misconceptions here, Clojure is not a language that has lazy evaluation, but is instead completely eager. Macros are the closest thing that come to laziness, but they are still different. However, Clojure has a data structure, that also serves as an abstraction layer, that implements laziness, called a sequence or seq. Therefor turning of laziness makes no real sense. You could say disable the laziness of seqs, but that doesn't really make sense either. It's like disabling the FIFO nature of a queue or a channel. If you don't want the properties of a seq, then use another data structure, like a vector. On 11 Oct 2014, at 18:14, Mars0i mars...@logical.net wrote: Thanks Jan-Paul. That's helpful. I wonder whether, if all lazy functions were rewritten in terms of transducers, it would then be easy to turn laziness on and off. (I am not suggesting that this should be done. No doubt it would entail a lot of work, and performance tradeoffs. I'm quite happy with Clojure as it is, despite anything negative I might say about impacts of laziness in some circumstances.) On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote: Transducers build up transformation steps, with new generic operations like single arg `map` and `filter`, and then apply these transformations to a collection using an evaluation function. This function decides if operations are done lazily, eagerly, or on a channel. Note that while this makes the place where laziness occurs more obvious, it is not really new. You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. While `mapv` or `filterv` are not. On 11 Oct 2014, at 00:28, Mars0i mars...@logical.net wrote: On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote: Maybe an ideal world would be one in which there was a global setting to turn laziness on and off. When you want it, have it, and know your risks. After looking at the source for some of the lazy functions, I've come to suspect that such a feature would be completely nontrivial. Oh, wait, Rich Hickey's blog post about transducers says: But transducers can also be used for: a la carte laziness ... collection/iteration/laziness-free transforming reductions Not certain what this means. Haven't fully grokked reducers. -- 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
Seeking Large Companies That Employ Clojure
Greetings, You can learn a bit about me here http://www.linkedin.com/in/janman. I am looking to connect with engineering teams and managers of those teams that are using Clojure in enterprise and/or web scale scenarios to discuss various topics important to users of Clojure at scale, in production, etc. If you are one, please contact me directly; if you know of one, please make me an introduction. Onward in the great Clojure Adventure! Regards, Jan -- 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: `as-` does not work with `recur`.
Ah thanks, I did a JIRA search for `as-` before but nothing had popped up. On 05 Oct 2014, at 03:06, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: This issue has been reported May be you should upvote this.. http://dev.clojure.org/jira/browse/CLJ-1418 On Sun, Oct 5, 2014 at 4:56 AM, Leon Grapenthin grapenthinl...@gmail.com wrote: Thought: (defmacro as- [expr name forms] `(let [~name ~expr ~@(interleave (repeat name) (butlast forms))] ~(last forms))) On Sunday, October 5, 2014 1:02:50 AM UTC+2, Jan-Paul Bultmann wrote: Hey, I just noticed that while recur can be the last statement in most threading macros, it can't be used within an `as-` macro. user= (macroexpand '(- x (recur))) (recur x) user= (macroexpand '(as- x % (recur %))) (let* [% x % (recur %)] %) This means that a recur within a `as-` will cause a CompilerException, because it is not at the tail position. Thoughts? Cheers, Jan-Paul -- 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. -- 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.
`as-` does not work with `recur`.
Hey, I just noticed that while recur can be the last statement in most threading macros, it can't be used within an `as-` macro. user= (macroexpand '(- x (recur))) (recur x) user= (macroexpand '(as- x % (recur %))) (let* [% x % (recur %)] %) This means that a recur within a `as-` will cause a CompilerException, because it is not at the tail position. Thoughts? Cheers, Jan-Paul -- 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: Is Clojure a language for growth?
If a company wants to be able to hire staff and get them up to speed, as well as have options for bringing in contractors and outsourcing some work, is Clojure a good choice? My friend works in a project which is being rewritten from Rails to Clojure (due to usual scaling problems with Rails). They don't have hiring problems. However, they are not looking for Clojure devs but devs who want to learn Clojure - and they don't have any problems with that. Usually, each new developer is able to code in Clojure after one month. Of course, every new team member has to read a book or two after hours and requires some mentoring from other members in a team. We've had trouble finding Clojure devs, and others have complained of how hard it is to learn Clojure and read the code from open source projects, especially for those with backgrounds in languages like C++. Clojure is as hard to learn as any other language. People who complain about strange grammar (those bloody brackets) or a few new concepts in the language won't be a good buy for a fast-growing company. I'm really looking for arguments that will help me persuade my boss that the risk of starting our next project in Clojure is one worth taking. I had the same problem with Scala a few years ago. Persuade you boss to start with very small project. Make it awesome, show it to your team and remember - you 'll have only one chance. If you fail - they won't allow you to use Clojure again :) -- 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: complex numbers in clojure
I agree that Clojure could really use an imaginary number type. The best place to start with this might be `clojure.math.numeric-tower` because it already provides a `MathFunctions` protocol that defines a square root operation. Cheers Jan On 15 Aug 2014, at 19:54, Maik Schünemann maikschuenem...@gmail.com wrote: Hi, On Fri, Aug 15, 2014 at 7:00 PM, Reid McKenzie rmckenzi...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The best way to build a complex arithmetic package is probably to work atop `clojure.algo.generic`. I've done a pair of libraries (https://github.com/arrdem/imprecise, https://github.com/arrdem/meajure) based around extending algo.generic with custom datatypes and they've both worked out well I'll look at these. Building complex arithmetic atop algo.generic wouldn't bring the desired unification, because for example core.matrix doesn't use algo.generic ... Clojure in general seems pretty loath to package traditional numerics facilities... note that we don't even have a built in square root operator and the common practice is to use java.lang.Math through interop so I wouldn't go holding your breath over adding irrational numbers to the language core. Also clojure.contrib is abandoned and deprecated in favor of real community maintained standalone libraries. The most likely place for an irrational type is probably either a user library like both of the above or possibly algo.generic itself. Yeah, I meant 'as a contrib library' when I wrote clojure.contrib. Sorry for the confusion. As for the other part, let me elaborate a bit: As it is true that clojure doesn't have much numeric functions in core (like the square root example), it doesn't eschew numeric /types/ like BigInt and Rationals, and you obviously can't pass to java.lang.Math via interop already. Take rationals as example. I really like them and use them often in my clojure code because they give you exact arithmetic basically for free because they are part of the core language and you can use them anywhere (in pure clojure). They even have a convenient literal syntax (but that is not that inportant). We had a discussion a while ago on the clojure-numerics mailing list on how we could open core.matrix for arbitrary scalar types, like complex numbers or symbolic expressions. I'll link this here as it could be of interest: https://groups.google.com/forum/#!topic/numerical-clojure/Ze7lNjXJeQc/discussion I think a reason that held the discussion back was missing standard types to experiment with. I don't argue that clojure should provide complex types as part of clojure.core and can understand the reasons not to (while I think it would be the same reason as including rationals in clojure.core) but as a clojure contrib library that other clojure math libraries build ontop of (including core.matrix and algo.generic). The tricky part would then be figuring out how to nicely interop with the other clojure types without incuring too much overhead to be used in serious scientific computing (I think algo.generic uses multimethods for dispatch, which is definitly too slow in highly stressed inner loops of heavy matrix manipulations for example). greetings Maik Reid On 08/15/2014 10:24 AM, Maik Schünemann wrote: Hi, is there a recommended way to do complex arithmetic in clojure ? I am interested to see clojure going forward for scientific computing purposes. There is already considerable effort going on with core.matrix, incanter, expresso etc. But something thad is oddly lacking is support for complex numbers. For some areas, this is a show stopper and it is very basic stuff in other languages and systems: - common-lisp, python etc all have a standard complex type as part of the language/standard library - see language support here http://en.wikipedia.org/wiki/Complex_data_type In Java, there are multiple incompatible complex number classes and I don't want that incompatibilities in clojure libraries that provide complex number manipulation. In my opinion we should strive as a community for a standard complex number datatype, that is agreed on by clojure libraries, and plays nicely with clojures other numeric types. Ideally, this would be provided as part of clojure.contrib or even clojure itself - like rationals are! -- 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
Re: Idiomatic clojure on building a sequence
Hi Colin, Have a look at the 'as-' macro, its very helpful in some cases, as: (- [] (conj some-element) (as- some-seq (if some-condition? (conj some-seq some-element) some-seq) (if some-other-condition? (conj some-seq some-other-element) some-seq)) (take some-number-of-elements)) Dňa streda, 21. mája 2014 18:23:06 UTC+2 Colin Yates napísal(-a): I often find myself doing the following: (let [some-seq [] some_seq (if some-condition? (conj some-seq some-element) some-seq) some_seq (if some-other-condition? (conj some-seq some-other-element) some-seq) some_seq etc.]) In other words building up a sequence which contains the results of predicated elements. Building up a where clause in SQL for example. I experimented with the - and - but that didn't help and just looked messier. How do you handle this pretty common use case? 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: Comparing classes in case statement
From official clojure documentation: The test-constants are not evaluated. They must be compile-time literals Dňa štvrtok, 27. februára 2014 14:03:04 UTC+1 Markus Bader napísal(-a): Hello, if I am not too dumb, it seems that comparing for classes does not work in case statements, like: = (class '(1 2 3)) clojure.lang.PersistentList = (case (class '(1 2 3)) clojure.lang.PersistentList :amazing :so-sad) :so-sad I do not need a workaround - that is already done - and using the List is just for providing a simple example. It originally occurred while comparing Java classes. I am just interested if this behavior is intended or a bug. Cheers! -- 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/groups/opt_out.
Re: Comparing Regular Expression pattens for equality?
Clojure re-uses java.util.regex.Pattern objects. This object doesn't override equals method, so object references are always compared. But you can easily get pattern string from compiled pattern and then compare just them: user= (= (.pattern #test) (.pattern #test)) true Dňa streda, 26. februára 2014 12:55:17 UTC+1 Thomas napísal(-a): Hi Everyone, I am creating some regular expressions programmatically with re-pattern. In order to avoid creating the same regex pattern again I want to check if it already exists. But comparing regex pattern doesn't seem to be work: user= (= #test #test) false user= (identical? #test #test) false Not surprised that identical? doesn't work to be honest, but = should have worked IMHO Is there a way to do this? TIA Thomas -- 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/groups/opt_out.
Re: Latest web framework for clojure
It depends also on your requirements. For example if you want your app to work in many deployment scenarios (standalone Jetty or Tomcat, J2EE web containers...) and you may have to use servlet 3.0 API asynchronous features, nothing beats pedestal currently. The concept of interceptors is little harder to grok then simple ring handlers (which are reused to the greatest possible extent anyway), but they really make sense and truly decomplect execution order, unlike traditional ring wrapping handlers. The routing systems is also more transparent (data based) then Compojure macro routing and the url generation facility is nice. Sometimes i hear people say that pedestal is unclojurish and complex, but i think they just don't get the difference between complex and easy. Overall, i think that pedestal represents core clojure philosophy better then any other clojure server side framework. Dňa streda, 26. februára 2014 2:13:30 UTC+1 Aravindh S napísal(-a): Hi All, I have been reading clojure for sometime now. I am at a point where I want to learn a web framework. I see many options available for clojure where few are built upon others. So if I am to learn one, which framework does the community recommend? Thanks Aravindh.S -- 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/groups/opt_out.
Shutting down core.async executors threadpool
Hi Folks, I developed an pedestal application which uses core.async for real-time server push. Everything works fine, except little problem when i run the application as the Servlet in Tomcat (7.0.52). The problem is, that if i shutdown the tomcat instance with shutdown script (default bin/shutdown.sh), it won't quit. I can see with VisualVM that it is because of the core.async executors threadpool used to dispatch go blocks which is not properly teared down. Any ideas how to solve this ? Cheers Jan -- 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/groups/opt_out.
Re: Shutting down core.async executors threadpool
Thank you much for the hint Jozef, you pointed mi in the right direction. As you wrote, all core.async thread are daemon threads, but i was using another clojure library (pedestal) which uses executors threadpool for SSE heartbeat functionality, and this was indeed the problem. I already submitted an pull request to library maintainers: https://github.com/pedestal/pedestal/pull/250 Dňa pondelok, 24. februára 2014 19:18:42 UTC+1 Jozef Wagner napísal(-a): All threads in default core.async threadpool should be daemon, so they should not block when JVM is about to exit. Maybe it is a tomcat issue. On Mon, Feb 24, 2014 at 7:06 PM, Jan Herich jan.h...@gmail.comjavascript: wrote: Hi Folks, I developed an pedestal application which uses core.async for real-time server push. Everything works fine, except little problem when i run the application as the Servlet in Tomcat (7.0.52). The problem is, that if i shutdown the tomcat instance with shutdown script (default bin/shutdown.sh), it won't quit. I can see with VisualVM that it is because of the core.async executors threadpool used to dispatch go blocks which is not properly teared down. Any ideas how to solve this ? Cheers Jan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: (series of swap! on atom) == single swap!
I'm afraid your understanding of atom swap! operations is not quite correct - update function must (or should) be pure as well. See the documentationhttp://clojuredocs.org/clojure_core/clojure.core/swap!for swap!, update function could be potentially called multiple times if there are more threads of execution updating one atomic reference - there is simple compare and sethttp://clojuredocs.org/clojure_core/clojure.core/compare-and-set!mechanism involved, which compares the old value of the atom (input for the update function) and sets the atom to new value (return value from the update function) only value of the atom reference was not changed in between, if yes the compare and set is retried until ti succeeds. Dňa nedeľa, 16. februára 2014 23:35:24 UTC+1 t x napísal(-a): I believe that's the STM approach, which has the advanrtage of: * can synchronize across multiple pieces of data but has the disadvantage of: * work must be pure since it can be retried * possibly less efficient due to possibility of retrying In the example I posted above, I only need to: * modify a single atom and the approach I presented above: * can be impure, since it is guaranteed to only run once * is guaranteed to succeed (without retrys) On Sun, Feb 16, 2014 at 2:25 PM, Ramesh ramesh1...@gmail.comjavascript: wrote: You can use a ref instead of an atom. And use dosync with multiple alter, so everything is safely inside a transaction. On Feb 16, 2014 2:04 PM, t x txre...@gmail.com javascript: wrote: Hi John, Your solution is perfectly valid and optimal for the problem I described above. Unfortunately, I forgot to mention an additional constraint: sometimes I do: (let [ foo (:some-selector @data-atom) ] (swap! data-atom update-in [:other-selector] ... )) which the - doesn't quite work on, but my ugly hack above does resolve. The problem being -- I want to update one part of the atom, but it depends on another part of the atom. I ended up with the following hack: (defn tswap! [atm func] (swap! atm (fn [old] (let [natm (atom old)] (func natm) @natm On Sat, Feb 15, 2014 at 4:09 PM, John D. Hume duelin@gmail.comjavascript: wrote: On Sat, Feb 15, 2014 at 6:04 PM, t x txre...@gmail.com javascript: wrote: (defn what-I-want [] (with-atom some-atom assoc-in ... assoc-in ... update-in ...)) I often do something like this and don't find it too ugly: (swap! my-atom #(- % (assoc-in [:k] v) (update-in [:k2] inc) ,,,)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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
Re: (series of swap! on atom) == single swap!
Hi t x, I think, that lock-free approach an it's semantics is more in line with other Clojure reference types such as refs. It also encourages you to only use pure functions for state transitions, among other things, such as significant performance benefits in comparison with lock based approaches, see for example this articlehttp://mechanical-sympathy.blogspot.sk/2013/08/lock-based-vs-lock-free-concurrent.html . If you really want to update some reference with function which will also perform impure actions such as file I/O, consider using agents http://clojure.org/agents and sendhttp://clojure.github.io/clojure/clojure.core-api.html#clojure.core/sendor send-offhttp://clojure.github.io/clojure/clojure.core-api.html#clojure.core/send-off(the latter in case of I/O blocking actions), functions given to send and send-off are guaranteed to run only once. Dňa pondelok, 17. februára 2014 2:36:59 UTC+1 t x napísal(-a): Hi Jan, You're right. I'm wrong. I'm grateful you pointed this out -- this would have otherwise been impossible to debug. === To everyone: Why can swap! be retried? This confuses me -- to implement swap!, why can't we * have a lock * ensure that only one swap! is in session at any given time * have the given swap! complete before running the next swap! Thanks! On Sun, Feb 16, 2014 at 3:51 PM, Jan Herich jan.h...@gmail.comjavascript: wrote: I'm afraid your understanding of atom swap! operations is not quite correct - update function must (or should) be pure as well. See the documentation for swap!, update function could be potentially called multiple times if there are more threads of execution updating one atomic reference - there is simple compare and set mechanism involved, which compares the old value of the atom (input for the update function) and sets the atom to new value (return value from the update function) only value of the atom reference was not changed in between, if yes the compare and set is retried until ti succeeds. Dňa nedeľa, 16. februára 2014 23:35:24 UTC+1 t x napísal(-a): I believe that's the STM approach, which has the advanrtage of: * can synchronize across multiple pieces of data but has the disadvantage of: * work must be pure since it can be retried * possibly less efficient due to possibility of retrying In the example I posted above, I only need to: * modify a single atom and the approach I presented above: * can be impure, since it is guaranteed to only run once * is guaranteed to succeed (without retrys) On Sun, Feb 16, 2014 at 2:25 PM, Ramesh ramesh1...@gmail.com wrote: You can use a ref instead of an atom. And use dosync with multiple alter, so everything is safely inside a transaction. On Feb 16, 2014 2:04 PM, t x txre...@gmail.com wrote: Hi John, Your solution is perfectly valid and optimal for the problem I described above. Unfortunately, I forgot to mention an additional constraint: sometimes I do: (let [ foo (:some-selector @data-atom) ] (swap! data-atom update-in [:other-selector] ... )) which the - doesn't quite work on, but my ugly hack above does resolve. The problem being -- I want to update one part of the atom, but it depends on another part of the atom. I ended up with the following hack: (defn tswap! [atm func] (swap! atm (fn [old] (let [natm (atom old)] (func natm) @natm On Sat, Feb 15, 2014 at 4:09 PM, John D. Hume duelin@gmail.com wrote: On Sat, Feb 15, 2014 at 6:04 PM, t x txre...@gmail.com wrote: (defn what-I-want [] (with-atom some-atom assoc-in ... assoc-in ... update-in ...)) I often do something like this and don't find it too ugly: (swap! my-atom #(- % (assoc-in [:k] v) (update-in [:k2] inc) ,,,)) -- 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 the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out
Re: Example in Joy of Clojure, 2nd edition (MEAP)
Hello Eric, You can rewrite this functionality with key# and r# instead of ~'key and ~'r and it would work just as well, it's only not necessary to use unique symbols here, because you are not using them in the function body anyway, so there is no danger of accidental var capture. To be honest, i would rather use underscore symbols (written as ~'_ inside macro definition) to indicate that i won't use any of the first two parameters in the function body. Dňa sobota, 15. februára 2014 9:32:48 UTC+1 Eric napísal(-a): Hi, I'm reading the second edition of Joy of Clojure (the MEAP), and there is an example that I don't quite get, and I was hoping someone here could help me. It's in chapter 8, talking about macros. There is an example of a macro called def-watched, which prints a message each time the root binding of a var changes: (defmacro def-watched [name value] `(do (def ~name ~@value) (add-watch (var ~name) :re-bind (fn [~'key ~'r old# new#] (println old# - new#) I understand almost everything, but I don't see why we have to use ~'keyand ~'r rather than simply key# and r#. As I understand it, the first option ( ~'var-name) would be useful to capture an external var inside the macro, but I don't see the point of doing it here, especially since ~'key is defined in the parameter list, so that it would anyway hide any external var. Could someone please help me understand this? Thank you in advance, Eric -- 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/groups/opt_out.
Re: Handy clojure function to transform prepared statement queries
The problem with libraries you mentioned is that those are fully featured
DSLs for embedding SQL queries
as clojure macros/function calls in your program.
However, i like the philosophy of Yesql
libraryhttps://github.com/krisajenkins/yesql,
which leverages clojure/java.jdbc library but encourages you
to keep SQL queries in .sql files for many different reasons (all stated in
README.md https://github.com/krisajenkins/yesql/blob/master/README.md of
this library).
There is a whole class of real-world environments, where this approach is
preferable to full-power DSLs.
My problem is, that i'm forced to abadon Yesql approach whenever my query
has IN () clause within and
i have to write the query as a String in clojure program (or use some DSLs,
but that's what i'm trying to avoid).
If there would be some hook to attach in my proposed behavior to either
clojure/java.jdbc or Yesql, i would
be able to continue writing all of my queries as plain .sql files.
Of course you can argue that whenever someone needs to do this, it's the
right time to start using DSLs,
i'm not sure on this, that's why i want to discuss this topic.
Dňa pondelok, 10. februára 2014 0:16:01 UTC+1 Sean Corfield napísal(-a):
As maintainer of java.jdbc I'd say this is a more appropriate feature
for a DSL library like SQLingvo or HoneySQL (which may already support
something like this - I haven't checked).
Sean
On Sun, Feb 9, 2014 at 12:40 PM, Jan Herich jan.h...@gmail.comjavascript:
wrote:
Hello folks,
In the last days, i was working with clojure/java.jdbc and yesql
libraries
(which are both great piece of work),
the experience was overall very positive, but one thing bothered me,
that i
was unable to use plain prepared
statements (and sadly, yesql) when working with IN clauses and
collection
values as arguments for prepared
statements. So i created following helper function to help with
generating
correct prepared statements:
(ns db-util
(:require [clojure.string :as str]))
(def ^:private placeholders-for (comp (partial str/join ,) #(repeat %
'?)
count))
(defn in-statement
Takes a prepared SQL statement and variable number of arguments,
which
may be
also collection values. Replace all occurences of IN (?) with spliced
out
values
such as IN (?,?,?) where number of placeholder characters is the same
as
count
of elements in corresponding argument which is assumed to be a
collection.
In case that collection argument has only one element, IN (?) is
transformed
into more effective = ? form. Placeholders in query which don't
corresponds to
collection arguments are unnafected. Returns vector, with first item
of
the
vector as transformed prepared SQL statement and rest as spliced out
arguments.
[statement args]
(let [in-placeholders-positions (- (re-seq #\?|IN \(\?\)
statement)
(map vector (iterate inc 0))
(filter #(= (second %) IN (?)))
(map first)
(set))
in-placeholders-args (- args
(map vector (iterate inc 0))
(filter #(contains?
in-placeholders-positions (first %)))
(map second))
expanded-statement (reduce (fn [acc arg]
(str/replace-first acc #IN \(\?\)
(if ( (count
arg)
1)
(str IN (
(placeholders-for arg) ))
= ?)))
statement in-placeholders-args)
unspliced-args (- args
(map #(if (coll? %) (seq %) %))
(flatten))]
(into [] (cons expanded-statement unspliced-args
;; following holds true
(= (in-statement id = ? AND user_id IN (?) AND msg_id IN (?) 1 #{2 3
4}
#{5})
[id = ? AND user_id IN (?,?,?) AND msg_id = ? 1 2 3 4 5])
Now my question is, do you think that something in this flavor would be
good
addition to clojure/java.jdbc
or yesql libraries (the latter one is probably more appropriate for
inclusion) ? If so, i will try to refine and
generalize my solution, think about how to integrate it and then issue
an
pull request.
Cheers Jan
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
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
Re: Handy clojure function to transform prepared statement queries
Thank you for your explanation Kris, i will test this functionality in Yesql. Dňa pondelok, 10. februára 2014 14:40:18 UTC+1 Kris Jenkins napísal(-a): Actually, Yesql already supports this, albeit unofficially. Here's an example, but please read the caveat at the end before you use it... Define an IN-query with one parameter: -- name: find-by-age SELECT * FROM person WHERE age IN (:age) Call it, supplying a vector for age: (find-by-age db-spec [18 21 35]) The query will get expanded to [SELECT * FROM person WHERE age IN (?,?,?) 18 21 35] ...for the underlying jdbc call, and behave as you hope. So what's the caveat? I haven't tested it sufficientlyhttps://github.com/krisajenkins/yesql/blob/master/test/yesql/named_parameters_test.clj#L54-56. And until I do, I'm not going to document it, or make it official. But it's there in v0.3.0, so if you want to field-test it, do let me know your experiences. :-) (And, FWIW, I completely agree with Sean. This kind of thing definitely belongs in a layer above clojure.java.jdbc.) On Monday, 10 February 2014 10:41:55 UTC, Jan Herich wrote: The problem with libraries you mentioned is that those are fully featured DSLs for embedding SQL queries as clojure macros/function calls in your program. However, i like the philosophy of Yesql libraryhttps://github.com/krisajenkins/yesql, which leverages clojure/java.jdbc library but encourages you to keep SQL queries in .sql files for many different reasons (all stated in README.mdhttps://github.com/krisajenkins/yesql/blob/master/README.mdof this library). There is a whole class of real-world environments, where this approach is preferable to full-power DSLs. My problem is, that i'm forced to abadon Yesql approach whenever my query has IN () clause within and i have to write the query as a String in clojure program (or use some DSLs, but that's what i'm trying to avoid). If there would be some hook to attach in my proposed behavior to either clojure/java.jdbc or Yesql, i would be able to continue writing all of my queries as plain .sql files. Of course you can argue that whenever someone needs to do this, it's the right time to start using DSLs, i'm not sure on this, that's why i want to discuss this topic. Dňa pondelok, 10. februára 2014 0:16:01 UTC+1 Sean Corfield napísal(-a): As maintainer of java.jdbc I'd say this is a more appropriate feature for a DSL library like SQLingvo or HoneySQL (which may already support something like this - I haven't checked). Sean On Sun, Feb 9, 2014 at 12:40 PM, Jan Herich jan.h...@gmail.com wrote: Hello folks, In the last days, i was working with clojure/java.jdbc and yesql libraries (which are both great piece of work), the experience was overall very positive, but one thing bothered me, that i was unable to use plain prepared statements (and sadly, yesql) when working with IN clauses and collection values as arguments for prepared statements. So i created following helper function to help with generating correct prepared statements: (ns db-util (:require [clojure.string :as str])) (def ^:private placeholders-for (comp (partial str/join ,) #(repeat % '?) count)) (defn in-statement Takes a prepared SQL statement and variable number of arguments, which may be also collection values. Replace all occurences of IN (?) with spliced out values such as IN (?,?,?) where number of placeholder characters is the same as count of elements in corresponding argument which is assumed to be a collection. In case that collection argument has only one element, IN (?) is transformed into more effective = ? form. Placeholders in query which don't corresponds to collection arguments are unnafected. Returns vector, with first item of the vector as transformed prepared SQL statement and rest as spliced out arguments. [statement args] (let [in-placeholders-positions (- (re-seq #\?|IN \(\?\) statement) (map vector (iterate inc 0)) (filter #(= (second %) IN (?))) (map first) (set)) in-placeholders-args (- args (map vector (iterate inc 0)) (filter #(contains? in-placeholders-positions (first %))) (map second)) expanded-statement (reduce (fn [acc arg] (str/replace-first acc #IN \(\?\) (if ( (count arg) 1) (str IN ( (placeholders-for arg
Handy clojure function to transform prepared statement queries
Hello folks,
In the last days, i was working with clojure/java.jdbc and yesql libraries
(which are both great piece of work),
the experience was overall very positive, but one thing bothered me, that i
was unable to use plain prepared
statements (and sadly, yesql) when working with IN clauses and collection
values as arguments for prepared
statements. So i created following helper function to help with generating
correct prepared statements:
(ns db-util
(:require [clojure.string :as str]))
(def ^:private placeholders-for (comp (partial str/join ,) #(repeat % '?)
count))
(defn in-statement
Takes a prepared SQL statement and variable number of arguments, which may be
also collection values. Replace all occurences of IN (?) with spliced out
values
such as IN (?,?,?) where number of placeholder characters is the same as
count
of elements in corresponding argument which is assumed to be a collection.
In case that collection argument has only one element, IN (?) is transformed
into more effective = ? form. Placeholders in query which don't corresponds
to
collection arguments are unnafected. Returns vector, with first item of the
vector as transformed prepared SQL statement and rest as spliced out
arguments.
[statement args]
(let [in-placeholders-positions (- (re-seq #\?|IN \(\?\) statement)
(map vector (iterate inc 0))
(filter #(= (second %) IN (?)))
(map first)
(set))
in-placeholders-args (- args
(map vector (iterate inc 0))
(filter #(contains? in-placeholders-positions
(first %)))
(map second))
expanded-statement (reduce (fn [acc arg]
(str/replace-first acc #IN \(\?\)
(if ( (count arg) 1)
(str IN (
(placeholders-for arg) ))
= ?)))
statement in-placeholders-args)
unspliced-args (- args
(map #(if (coll? %) (seq %) %))
(flatten))]
(into [] (cons expanded-statement unspliced-args
;; following holds true
(= (in-statement id = ? AND user_id IN (?) AND msg_id IN (?) 1 #{2 3 4} #{5})
[id = ? AND user_id IN (?,?,?) AND msg_id = ? 1 2 3 4 5])
Now my question is, do you think that something in this flavor would be good
addition to clojure/java.jdbc
or yesql libraries (the latter one is probably more appropriate for inclusion)
? If so, i will try to refine and
generalize my solution, think about how to integrate it and then issue an pull
request.
Cheers Jan
--
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/groups/opt_out.
Re: Idiomatic way to construct potentially time bound target channel in core.async
Ok, so i'm thinking about such one-shot detachable input pipe channels... (ns async-util.input-pipe (:require [clojure.core.async.impl.protocols :as impl] [clojure.core.async :refer [! close! go-loop]])) (defprotocol InputPipe (detach* [p])) (defn input-pipe Creates and return input pipe of supplied channel with attached input channel. [ch ch-i] (let [i (atom ch-i) p (reify impl/Channel (close! [_] (impl/close! ch)) (closed? [_] (impl/closed? ch)) impl/ReadPort (take! [_ fn1] (impl/take! ch fn1)) impl/WritePort (put! [_ val fn1] (impl/put! ch val fn1)) InputPipe (detach* [_] (if (impl/closed? ch) false (do (reset! i nil) true] (go-loop [val (! @i)] (if-let [i-c @i] (if (nil? val) (close! p) (recur (! i-c))) (reset! i nil))) p)) (defn detach-input Detaches input from input-pipe channel, returns false if input-pipe channel is closed, true otherwise [p] (detach* p)) Dňa piatok, 31. januára 2014 19:18:37 UTC+1 Jan Herich napísal(-a): Hello Folks, I need to construct core.async channel with following semantics: 1. When the channel is created, timeout is attached to channel 2. After timeout passes out, channel is closed 3. It's possible to detach timeout from the channel before it passes out Now i implemented it with something like this: (defn create-cancel-channel [channel-to-notify timeout-ms] (let [cancel-channel (async/chan) timeout-channel (async/timeout timeout-ms)] (async/go (let [[_ c] (async/alts! [cancel-channel timeout-channel])] (when (= c timeout-channel) (async/close! cancel-channel) (async/close! channel-to-notify cancel-channel)) ;; transport channel (def transport-channel (async/chan)) ;; cancel-channel (def cancel-channel (create-cancel-channel transport-channel 2000)) ;; to cancel the transport channel timeout, just close the cancel-channel (async/close! cancel-channel) But i'm rather unsatisfied with this solution because it seems little bit clunky and what's worse, i need to explicitly keep track of those cancel channels. Obviously core.async pipe would greatly simplify this, but it seems, that there's no way to disconnect piped channels. Maybe mult/tap/untap, even if i won't use broadcasting semantic of those constructs. Any other ideas ? -- 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/groups/opt_out.
Re: Idiomatic way to construct potentially time bound target channel in core.async
If anyone is interested, that's roughly what i'm currently thinking about... (ns async-util.input-pipe (:require [clojure.core.async.impl.protocols :as impl] [clojure.core.async :refer [! close! go-loop]])) (defprotocol InputPipe (attach* [p ch]) (detach* [p])) (defn input-pipe Creates and return input pipe of supplied channel. [ch] (let [i (atom nil) p (reify impl/Channel (close! [_] (impl/close! ch)) (closed? [_] (impl/closed? ch)) impl/ReadPort (take! [_ fn1] (impl/take! ch fn1)) impl/WritePort (put! [_ val fn1] (impl/put! ch val fn1)) InputPipe (attach* [_ ch-i] (if (impl/closed? ch) false (do (reset! i ch-i) true))) (detach* [_] (if (impl/closed? ch) false (do (reset! i nil) true] (go-loop [] (when-let [i-v @i] (let [val (! i-v)] (if (nil? val) (close! p) (recur) p)) (defn attach-input Attaches channel to input-pipe channel, returns false if input-pipe channel is closed, true otherwise. [p ch] (attach* p ch)) (defn detach-input Detaches input from input-pipe channel, returns false if input-pipe channel is closed, true otherwise (detach* p)) Dňa piatok, 31. januára 2014 19:18:37 UTC+1 Jan Herich napísal(-a): Hello Folks, I need to construct core.async channel with following semantics: 1. When the channel is created, timeout is attached to channel 2. After timeout passes out, channel is closed 3. It's possible to detach timeout from the channel before it passes out Now i implemented it with something like this: (defn create-cancel-channel [channel-to-notify timeout-ms] (let [cancel-channel (async/chan) timeout-channel (async/timeout timeout-ms)] (async/go (let [[_ c] (async/alts! [cancel-channel timeout-channel])] (when (= c timeout-channel) (async/close! cancel-channel) (async/close! channel-to-notify cancel-channel)) ;; transport channel (def transport-channel (async/chan)) ;; cancel-channel (def cancel-channel (create-cancel-channel transport-channel 2000)) ;; to cancel the transport channel timeout, just close the cancel-channel (async/close! cancel-channel) But i'm rather unsatisfied with this solution because it seems little bit clunky and what's worse, i need to explicitly keep track of those cancel channels. Obviously core.async pipe would greatly simplify this, but it seems, that there's no way to disconnect piped channels. Maybe mult/tap/untap, even if i won't use broadcasting semantic of those constructs. Any other ideas ? -- 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/groups/opt_out.
Idiomatic way to construct potentially time bound target channel in core.async
Hello Folks, I need to construct core.async channel with following semantics: 1. When the channel is created, timeout is attached to channel 2. After timeout passes out, channel is closed 3. It's possible to detach timeout from the channel before it passes out Now i implemented it with something like this: (defn create-cancel-channel [channel-to-notify timeout-ms] (let [cancel-channel (async/chan) timeout-channel (async/timeout timeout-ms)] (async/go (let [[_ c] (async/alts! [cancel-channel timeout-channel])] (when (= c timeout-channel) (async/close! cancel-channel) (async/close! channel-to-notify cancel-channel)) ;; transport channel (def transport-channel (async/chan)) ;; cancel-channel (def cancel-channel (create-cancel-channel transport-channel 2000)) ;; to cancel the transport channel timeout, just close the cancel-channel (async/close! cancel-channel) But i'm rather unsatisfied with this solution because it seems little bit clunky and what's worse, i need to explicitly keep track of those cancel channels. Obviously core.async pipe would greatly simplify this, but it seems, that there's no way to disconnect piped channels. Maybe mult/tap/untap, even if i won't use broadcasting semantic of those constructs. Any other ideas ? -- 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/groups/opt_out.
Re: side-effect only function with map-like syntax (again)
How about doseq http://clojuredocs.org/clojure_core/clojure.core/doseq ? Dňa utorok, 28. januára 2014 5:28:04 UTC+1 Mars0i napísal(-a): Back in 2007 ( https://groups.google.com/forum/#!searchin/clojure/mapc/clojure/x0PDu_D6mP0/3A7CZe-ZDWAJ), Henk Boom raised the possibility of including in Clojure a function with syntax like map, but semantics more like Common Lisp's mapc (or Scheme's for-each, I believe). It works just like Clojure map, but applies the function to items in a sequence (sequences) only for side-effects. A sequence of results isn't generated, so there's no need for laziness. There was discussion, and at one point Rich Hickey seemed to say that he had added this kind of function, under the name 'scan'. It looks like scan was subsequently renamed to 'dorun' (http://clojure.org/old_news), but dorun doesn't do what mapc does. As far as I can tell, there is no such function at present in Clojure. Is that correct? There are other ways to get the same functionality, and it's easy to define a simple version of mapc (or whatever it should be called). However, I like the map syntax, even for side-effects, and don't want to reinvent the wheel. Even for small sequences, in which producing a sequence as output isn't costly, using mapc tells readers of your code that you're iterating over the list solely for side-effects. (defn mapc [f coll] (doseq [x coll] (f x))) For example, creating a mutable vector using core.matrix: = (def a (zero-vector :ndarray 5)) #'popco.core.popco/a = a #NDArray [0.0 0.0 0.0 0.0 0.0] = (mapc #(mset! a % -1) [0 2 4]) nil = a #NDArray [-1 0.0 -1 0.0 -1] -- -- 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/groups/opt_out.
Re: Read file contents as map
And if you are not sure about that, just use edn-only reader: (require '[clojure.tools.reader.edn :as edn]) (edn/read-string (slurp file)) Dňa nedeľa, 26. januára 2014 17:12:32 UTC+1 mynomoto napísal(-a): If you are sure that the file doesn't contain malicious code you can use: (read-string (slurp file)) On Sunday, January 26, 2014 11:24:30 AM UTC-2, Paul Smith wrote: Hi, I have a config file that contains a Clojure map. If I slurp that file it obviously returns a string. Is it possible to return that read file as a map (its original data structure) and not a string? Thanks Paul -- -- 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/groups/opt_out.
Re: core.async count in a channel
Hello Paul, Why not just adjust the number of workers based on actual workload instead of monitoring the source channel for average depth ? Have a look at this codehttps://github.com/halgari/clojure-conj-2013-core.async-examples/blob/master/src/clojure_conj_talk/core.clj#L254-287from clojure-conj presentation about core.async, it's just a simple thread-pool service, where you can specify source-channel, maximal number of threads (workers), function to be performed by each worker and timeout. Timeout means, for how long each thread will be waiting if there is no data on input before it will shut-down. The service starts with minimal amount of threads able to handle the workload and then progressively scales up to max specified number of threads if there are no free threads able to take items from the source channel. Maybe i misunderstood your description of the problem, but for me, it seems like a perfect fit. Jan Dňa utorok, 21. januára 2014 17:56:56 UTC+1 Paul Viola napísal(-a): I think this is all well and good for a particular use of channel. So perhaps I am misusing channels?? To repeat: in one case I have workers pulling from a channel of *real work*. For various reasons this channel might get filled rather deeply. In this case I would want to add additional workers or get a bigger machine. I was wondering if monitoring the channel for things like average depth (or 99 percentile) would give me the information I needed. I could of course just skip the channel business, and use a java queue is a fine proposal. But since the producers of this work are truly asynchronous (attached to the real world) I thought it best to keep the channel methodology. On Tue, Jan 21, 2014 at 5:11 AM, Aaron France aaron.l...@gmail.comjavascript: wrote: On 21/01/14 14:09, Moritz Ulrich wrote: On Tue, Jan 21, 2014 at 9:43 AM, Aaron France aaron.l...@gmail.comjavascript: wrote: Since channels yield nil when they are devoid of items, surely this is enough to know when the channel is empty? That's not correct. Take-Operations block on empty channels. They yield nil when they're closed. You could add a timeout to the take operation to see if no item arrived in a specific time. Much appreciated for the clarification. It's the same in Go. I can imagine this pattern (take on a possibly closed channel being useful) being useful but I'm not convinced knowing the count of channel is a safe thing to know/care about. My $0.02, perhaps Clojure does this differently. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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/zD2jl-bIFXI/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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/groups/opt_out.
Servlet adapter for ring handlers with support for asynchronous processing
Hi Folks, Is someone aware of servlet adapter (other then pedestal-service) for ring based handlers with support for asynchronous processing as specified in Servlet 3.0+ api ? Given that ring core was already refactored to support such solutions (middleware had been split into wrapping and request modifying functions) it should be not so hard to combine it with core.async go macros to assemble handler chain which supporting async processing and write an adapter to connect it with Servler 3.0+ API - HttpServletRequest.startAsync(), AsyncContext.complete() and so on... If you assembled something similar yourself, or you now about such project (even in development, immature, alpha), please let me know, thank you very much. Jan -- -- 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/groups/opt_out.
Re: Servlet adapter for ring handlers with support for asynchronous processing
Hello Shantanu, Thank you for this hint, i will definitely look at your lein-servlet project. In the meantime, i'm taking inspiration from prototype of pedestal core.async based interceptor chainhttps://github.com/pedestal/pedestal-service-channels/blob/master/src/channels/core.clj, looks very interesting. Jan Dňa sobota, 18. januára 2014 20:32:19 UTC+1 Shantanu Kumar napísal(-a): Hi Jan, This not directly related, but i thought it might be useful in some way. In case you do the java interop stuff on your own to implement the servlet 3.0 methods, you might want to use lein-servlet to run the servlet using Jetty 9 maybe. https://github.com/kumarshantanu/lein-servlet Shantanu On Saturday, 18 January 2014 16:01:02 UTC+5:30, Jan Herich wrote: Hi Folks, Is someone aware of servlet adapter (other then pedestal-service) for ring based handlers with support for asynchronous processing as specified in Servlet 3.0+ api ? Given that ring core was already refactored to support such solutions (middleware had been split into wrapping and request modifying functions) it should be not so hard to combine it with core.async go macros to assemble handler chain which supporting async processing and write an adapter to connect it with Servler 3.0+ API - HttpServletRequest.startAsync(), AsyncContext.complete() and so on... If you assembled something similar yourself, or you now about such project (even in development, immature, alpha), please let me know, thank you very much. Jan -- -- 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/groups/opt_out.
Re: Grouping and nested keys in a hash
Another way of doing that:
(def data {:b--name B, :a--id 1, :b--id 2, :a--name A})
(defn transform [data delimiter]
(reduce (fn [acc [k v]]
(let [[f-k s-k] (- k (name) (str/split delimiter))]
(assoc-in acc [(keyword f-k) (keyword s-k)] v))) {} s))
(transform data #--) ;; {:a {:name A, :id 1}, :b {:id 2, :name B}}
Dňa štvrtok, 16. januára 2014 14:46:46 UTC+1 James Conroy-Finn napísal(-a):
Hello all,
I've found myself stuck trying to move matching keys in a hash into a
nested hash.
For example,:
{:a--id 1 :a--name A :b--id 2 :b--name B} ;= {:a {:id 1 :name A} :b
{:id 2 :name B}}
I've tried `clojure.walk`, I've tried building the args to `assoc-in`, and
using `apply`. I honestly feel like I'm missing something really obvious,
like something with group-by.
Any tips would be greatly appreciated. I'll keep hammering away.
--
--
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/groups/opt_out.
Re: Grouping and nested keys in a hash
My solution would work only for fixed 2 level deep maps, but it would be
not so hard to modify it that it will be much more generic :)
Dňa štvrtok, 16. januára 2014 14:46:46 UTC+1 James napísal(-a):
Hello all,
I've found myself stuck trying to move matching keys in a hash into a
nested hash.
For example,:
{:a--id 1 :a--name A :b--id 2 :b--name B} ;= {:a {:id 1 :name A} :b
{:id 2 :name B}}
I've tried `clojure.walk`, I've tried building the args to `assoc-in`, and
using `apply`. I honestly feel like I'm missing something really obvious,
like something with group-by.
Any tips would be greatly appreciated. I'll keep hammering away.
--
--
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/groups/opt_out.
Re: Grouping and nested keys in a hash
Here we go, more generic solution:
(defn transform [data delimiter]
(reduce (fn [acc [k v]]
(let [key-strs (- k (name) (str/split delimiter))]
(assoc-in acc (mapv keyword key-strs) v))) {} s))
Dňa štvrtok, 16. januára 2014 14:46:46 UTC+1 James napísal(-a):
Hello all,
I've found myself stuck trying to move matching keys in a hash into a
nested hash.
For example,:
{:a--id 1 :a--name A :b--id 2 :b--name B} ;= {:a {:id 1 :name A} :b
{:id 2 :name B}}
I've tried `clojure.walk`, I've tried building the args to `assoc-in`, and
using `apply`. I honestly feel like I'm missing something really obvious,
like something with group-by.
Any tips would be greatly appreciated. I'll keep hammering away.
--
--
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/groups/opt_out.
Re: Grouping and nested keys in a hash
Oh, yes, my mistake, it should be data instead of s
Dňa štvrtok, 16. januára 2014 15:56:18 UTC+1 James napísal(-a):
Thank you for sharing.
I think the final `s` needs to be `data`, right?
On 16 Jan 2014, at 14:53, Jan Herich jan.h...@gmail.com javascript:
wrote:
Here we go, more generic solution:
(defn transform [data delimiter]
(reduce (fn [acc [k v]]
(let [key-strs (- k (name) (str/split delimiter))]
(assoc-in acc (mapv keyword key-strs) v))) {} s))
Dňa štvrtok, 16. januára 2014 14:46:46 UTC+1 James napísal(-a):
Hello all,
I've found myself stuck trying to move matching keys in a hash into a
nested hash.
For example,:
{:a--id 1 :a--name A :b--id 2 :b--name B} ;= {:a {:id 1 :name A}
:b {:id 2 :name B}}
I've tried `clojure.walk`, I've tried building the args to `assoc-in`,
and using `apply`. I honestly feel like I'm missing something really
obvious, like something with group-by.
Any tips would be greatly appreciated. I'll keep hammering away.
--
--
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 javascript:
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 javascript:
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/vvs5uAWYrBE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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/groups/opt_out.
Re: Grouping and nested keys in a hash
I have been using Clojure for something more then 2 years, something more
then 1 year intensive...
But i think those feelings of frustration are absolutely OK, when i started
with Clojure for the very first
time, i was so frustrated (years of OOP mind-bending...) that i gave up for
some time and only later
i collected my courage and approached Clojure again. Determination and
patience is very important.
Dňa štvrtok, 16. januára 2014 15:54:47 UTC+1 James napísal(-a):
Wow, I feel like a clumsy fool bashing parens together.
Have you been using Clojure for a long time Jan? I ask because I often
don't know where to begin when approaching a problem with Clojure, and it
can be quite frustrating.
On Thursday, January 16, 2014 2:45:48 PM UTC, Jan Herich wrote:
Another way of doing that:
(def data {:b--name B, :a--id 1, :b--id 2, :a--name A})
(defn transform [data delimiter]
(reduce (fn [acc [k v]]
(let [[f-k s-k] (- k (name) (str/split delimiter))]
(assoc-in acc [(keyword f-k) (keyword s-k)] v))) {} s))
(transform data #--) ;; {:a {:name A, :id 1}, :b {:id 2, :name B}}
Dňa štvrtok, 16. januára 2014 14:46:46 UTC+1 James Conroy-Finn
napísal(-a):
Hello all,
I've found myself stuck trying to move matching keys in a hash into a
nested hash.
For example,:
{:a--id 1 :a--name A :b--id 2 :b--name B} ;= {:a {:id 1 :name A}
:b {:id 2 :name B}}
I've tried `clojure.walk`, I've tried building the args to `assoc-in`,
and using `apply`. I honestly feel like I'm missing something really
obvious, like something with group-by.
Any tips would be greatly appreciated. I'll keep hammering away.
--
--
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/groups/opt_out.
Re: [ANN] incise 0.1.0 - An extensible static site generator
Hello Ryan, Thank you for the project, i was always missing a good static site generator written in clojure ! You took some interesting design decisions with extensibility. I'm currently working on the similar project https://github.com/janherich/gutenberg, even if my design is very different, because my needs are different - i want to have templates in pure html and be able to declaratively specify specific areas, because of that my project is based on enlive html library. Dňa utorok, 14. januára 2014 8:35:33 UTC+1 Ryan McGowan napísal(-a): Hi all! After consuming quite a bit of my spare time for the past several months, I have finally released version 0.1.0 https://clojars.org/incise of incise. It is a static site generator written in Clojure (of course). I like it quite a bit and I think others might benefit from it too. I am very open to contributions, suggestions or criticisms (just open an issue)https://github.com/RyanMcG/incise/issues . Necessary links: - https://clojars.org/incise - http://www.ryanmcg.com/incise/ - README generated into website using itself (it's called being meta). - https://github.com/RyanMcG/incise - https://github.com/RyanMcG/lein-incise - Yes there is a plugin - http://www.ryanmcg.com/2014/1/13/static-website-generation-with-incise/ - Very short post about it. Basically points to the README and makes the disclaimer that it's not a big deal. - https://github.com/RyanMcG/incise-example-project - super simple example project - http://www.ryanmcg.com/incise-example-project/ - and its generated output Thanks, Ryan McGowan -- -- 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/groups/opt_out.
Re: A question about lazy seq with io
As Mauricio already mentioned, map is not meant to be used for side-effects, if you want to need to evaluate a sequence for side-effects, use doseq http://clojuredocs.org/clojure_core/clojure.core/doseq instead. Regarding your first question about explicit loop-recur, i think it's reasonable way to write the functionality you want to achieve, even if the for macro is maybe little more idiomatic and shorter/more concise, here is the comparison: (def url-sequence (map #(str http://www.mysite.com/list.php?pageID=; %) (range))) (def download (loop [urls url-sequence lst []] (let [u (first urls) r (rest urls) resp (client/get u) next (re-find #(s?)title=\next page\Next gt;gt; (:body resp)) segments ((html2data (:body resp)) :segment) data (map segment2data segments)] (if next (recur r (conj lst data)) (conj lst data) (def download (- (for [url url-sequence :let [body (:body (client/get url)) next-pages (re-find #(s?)title=\next page\Next gt;gt; body)] :while next-pages] (map segment2data (- body (html2data) :segment (into [])) Also note that i didn't use local binding named next, but instead i named it next-pages, because next local name could lead to surprise if you forget that you aliased something to next and try to use clojure core next function :) Dňa pondelok, 13. januára 2014 15:49:50 UTC+1 Kashyap CK napísal(-a): Hi, I've been dabbling with Clojure for a bit and I am really loving it!!! I am trying to write a clojure program to download a bunch of URLs and I was wondering what is the right way to do it - My current implementation is as follows (def url-sequence (map #(str http://www.mysite.com/list.php?pageID=; %) (range))) (def download (loop [urls url-sequence lst []] (let [ u (first urls) r (rest urls) resp (client/get u) next (re-find #(s?)title=\next page\Next gt;gt; (:body resp)) segments ((html2data (:body resp)) :segment) data (map segment2data segments) ] (if next (recur r (conj lst data)) (conj lst data) I was wondering if I could replace the loop thingy with a map - that is when I experimented with a simple piece of code and found something that was not intuitive. I'd really appreciate it if someone could tell me what's going on when I do the following - user (defn xx [] (map println [1 2 3 4 5 6])) #'user/xx user (take 2 (xx)) (1 2 3 4 5 6 nil nil) user Regards, Kashyap -- -- 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/groups/opt_out.
Re: Adding query customization to Ring-based REST APIs
Hello Alexander, I did some work in this area some time ago, and the result was service-hub library https://github.com/ITEdge/service-hub - created to simplify basic CRUD services. It's designed to allow more then one type of data-store, currently it supports SQL databases (i use my own fork of korma here), simple in-memory data-stores and datomic. I built it around a set of handler protocols which define what basic and more advanced data-store implementations can do, you can see those herehttps://github.com/ITEdge/service-hub/blob/master/core/src/itedge/service_hub/core/handlers.clj . Furthermore, the library tries to also simplify validations, authorizations and wrapping those ready-to-be-exposed-to-outer-world services behind another set of services protocols, see herehttps://github.com/ITEdge/service-hub/blob/master/core/src/itedge/service_hub/core/services.clj . You can then simply use library web layer to automatically expose those instances over web via ring compojure libraries. Regarding translating requests maps to data-structures for data-store implementations, see for example korma util namespacehttps://github.com/ITEdge/service-hub/blob/master/persistence-korma/src/itedge/service_hub/persistence_korma/util.clj or datomic util namespacehttps://github.com/ITEdge/service-hub/blob/master/persistence-datomic/src/itedge/service_hub/persistence_datomic/util.clj . There are also some examples of such CRUD based web-services in project service-hub-examples https://github.com/ITEdge/service-hub-examples. I hope it will help you, or at least provides some clues Dňa pondelok, 13. januára 2014 3:25:40 UTC+1 Alexandr Kurilin napísal(-a): I'm investigating adding query options to my Ring app's GET requests for the more boring CRUD routes. I'd like to allow the caller to specify a set of SQL-level query customizations such as sorting, paging, counting, distinct ons, limits, some basic constraints etc. across all of my resources, ideally in such a way that I only have to write this once and it will magically just work across the board. First of all, there's the hard question of elegantly designing the API itself and how a caller will be able to specify query details. I have some experience with how Parse.com does this with their JSON requests (they pretty much allow you to specify the whole query in there), but I've heard Stack Overflow's and Elastic Search's APIs mentioned as good examples as well. Any other ones you'd recommend? Second, there's the whole business of translating those maps into requests. As far as I can tell, Korma is the right fit here, but I might be also missing out on another good SQL-generation library that I should know of, something I might integrate directly with clojure.jdbc. This doesn't sound like an unsolved problem. Folks, I could use words of wisdom on the subject. Have you done this kind of work on your APIs before? What did you use for reference? Anything clojure-specific I could leverage here to make it as elegant and concise as possible? Cheers! -- -- 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/groups/opt_out.
Re: HttpKit, Enlive (html retrieval and parsing)
I don't recommend using java's built in HTTP retrieval (by passing
java.net.URL object to enlive html-resource function).
Not only is it significantly slower then using clj-http (which uses
apache-http client under the hood), but it's also unreliable
when issuing more parallel requests.
Current enlive library supports plug-able parsers, the default one is
TagSoup, but you can switch it very easily for example
for JSoup by setting *parser* dynamic var.
You can have a look at one of my little projects where i used enlive for
html scraping
herehttps://github.com/janherich/lazada-quest/blob/master/src/lazada_quest/scrapper.clj
,
in this case, i used clj-http as
http client:
(ns lazada-quest.scrapper
(:require [clojure.string :as string]
[clj-http.client :as client]
[net.cgrand.enlive-html :as html]))
(defn fetch-url
Given some url string, fetch html content of the resource served under url
adress and return
it in the form of enlive nodes
[url]
(html/html-resource (:body (client/get url {:as :stream}
It would be straightforward to replace use of clj-http with http-kit
synchronous api, or asynchronous api with some changes
Dňa nedeľa, 12. januára 2014 0:24:48 UTC+1 Dave Tenny napísal(-a):
I'm just playing around with tool kits to retrieve and parse html from web
pages and files that I already have on disk (such as JDK API documentation).
Based on too little time, it looks like [http-kit 2.1.16] will retrieve
but not parse html, and [enlive 1.1.5] will retrieve AND parse html.
Or is there a whole built-in parse capability I'm missing in http-kiit?
Also, http-kit doesn't seem to want to retrieve content from a file:///
url, whereas enlive is happy with both local and remote content.
I'm just messing around, I wanted to have some REPL javadoc logic that
didn't fire up a browser or use the swing app (whose fonts are unreadable
for me, and half a day spent trying to change it was not fruitful).
Any tips or suggestions? Just don't want to make sure I'm missing obvious
things.
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/groups/opt_out.
Re: Sorting Nested Vectors and filter out some
Hello Jeff, This https://gist.github.com/janherich/8255881#file-gistfile1-clj should do the trick, at least it worked with data set you provided :) Dňa sobota, 4. januára 2014 11:31:07 UTC+1 Jeff Angle napísal(-a): Hi...I get my nested vector from a database, then map a function that formats it and computes the deviation, actual data looks like below..so I don't have any keys within the the vector, ..would like to sort by index 5 in in each vector descending and if index 5 is N/A (not e.g a percentage)remove it from the list [[151819 ANTI HUMAN GLOBULIN SERUM 5ML 6.0 0 0 N/A N/A] [151090 ANTI SERUM A 10ML 6.0 0 0 N/A N/A] [151094 ANTI SERUM AB 10ML 6.0 0 0 N/A N/A] [151092 ANTI SERUM B 10ML 6.0 0 0 N/A N/A] [151095 ANTI SERUM D 10ML 6.0 0 0 N/A N/A] [151825 BLOOD GLUCOSE GLUCOMETER-CONTOUR 0 0 0 N/A N/A] [151829 BLOOD GLUCOSE STRIPS(50 STRIPS)-CONTOUR 12.0 360.0 0 3000.00 % N/A] [151828 BLOOD GLUCOSE STRIPS(50 STRIPS)-SURESTEP 0 360.0 0 N/A N/A]] Thanks again On Friday, January 3, 2014 9:33:42 PM UTC+3, john walker wrote: You can do something like this. https://gist.github.com/johnwalker/8243534 On Friday, January 3, 2014 12:37:07 PM UTC-5, Jeff Angle wrote: Hi guys! this has made me pull quite a load of hair new to clojure.. have a nested vector say [[salt 0 0 %deviation 00] [sugar 5 10 %deviation 5$10] [milk 1 2 %deviation 12 ] [bread] ...] where % deviation is the actual figure of evaluting the deviation between e.g 5 and 10 for sugar, I want to sort using % deviation and also filter out those with deviations of 0. Please help, will revenge when I master functional programing with clojure -- -- 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/groups/opt_out.
Re: Parallel http requests
Maybe it's not exactly what you need, but i did similar thing once - i needed to scrape many linked html resources to extract tree data structure, each request/parse operation took considerable time - around 2 seconds - i was using clj-http/enlive combo (which is actualy Apache HttpClient/ TagSoup under the hood). Therefore i needed to parallelize this operations as much as possible and clojure pmap function provides exactly that (with futures and threads under the hood). Many times i stumbled upon people complaining that use of the pmap actually sloves down rather then speeds the code, but this is because the coordination overhead for managing threads is substantional, so it's probably not useful for tasks where the actual mapping function runs very fast, but in my case, the speedup in comparison to normal map function was massive - here is the codehttps://github.com/janherich/lazada-quest/blob/master/src/lazada_quest/scrapper.clji'm talking about. Dňa utorok, 31. decembra 2013 9:46:53 UTC+1 chinmoy debnath napísal(-a): I am a newbie in clojure. I need to send multiple http requests in parallel and need to have a call back when response for each request come back. What will be the idiomatic way of doing it in clojure? Thanks in advacne -- -- 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/groups/opt_out.
Re: Akka-like framework in Clojure ?
Hi Eric, Maybe pulsar https://github.com/puniverse/pulsar is what you are looking for, but i recommend you to also discover the other way of doing concurrency in clojure instead of the actor model - have a look at CSPhttp://en.wikipedia.org/wiki/Communicating_sequential_processes and its clojure implementation the the form of the core library called core.async Dňa piatok, 27. decembra 2013 9:54:16 UTC+1 Eric Le Goff napísal(-a): Hi, After a long background with imperative languages such as Java, I recently spent some time learning functionnal programming, starting with Scala. I had the opporrtunity to build a demo project based on the Akka framework. Now I am starting learning Clojure, and would be curious to know if there was some clojure based framework available which could implement rather similar features to Akka. In particular, I would be interested in an implementation of the Actor Model [1] Thanks. Eric [1] http://en.wikipedia.org/wiki/Actor_model -- -- 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/groups/opt_out.
Re: [ANN] Component: dependency injection and state management
This is simple brilliant... The approach proposed and the component framework implementing it finally solves the issue with the necessary evil (start/stop interactions with statefull components in any bigger Clojure app) by cleverly taking only the best ideas (like using inferred dependency graph to automatically start/stop components in the correct order) from Java DI frameworks like Spring, which i have a lot of experience with. Thank you very much for this work. Dňa štvrtok, 21. novembra 2013 3:01:19 UTC+1 Stuart Sierra napísal(-a): This is a small library/framework I've been working on for a few months. https://github.com/stuartsierra/component I use this to manage runtime state in combination with my reloaded workflow using tools.namespace.[1] I've started using this on some personal and professional projects and it seems to be working fairly well. [1]: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded -- -- 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/groups/opt_out.
[ANN] Service-hub - Library for building service-oriented applications
https://github.com/ITEdge/service-hub Service-hub is a modular library for building service-oriented applications with fine grained authentication, authorization and validation rules. The library is centered around idea of handlers as light-weight abstractions to CRUD interactions and services as something exposed to the outer world, which is authenticated, authorized and validated - one service could be composed of many handlers if needed. The core library containing abstractions of handlers, services, authorizators, validators and convertors along with some util namespaces and simple in-memory implementation is packaged in the sub-project core: https://github.com/ITEdge/service-hub/tree/master/core When you need to implement sql-handlers, Service-hub provides the sub-project persistence-korma, which depends on library korma-enhanced 0.3.1: https://github.com/ITEdge/service-hub/tree/master/persistence-korma For datomic-handlers, just use the sub-project persistence-datomic: https://github.com/ITEdge/service-hub/tree/master/persistence-datomic And finally to expose your service-oriented application through http, use sub-project http-ring, which depends on ring and compojure libraries: https://github.com/ITEdge/service-hub/tree/master/http-ring I also created some simple examples showing how to use service-hub: https://github.com/ITEdge/service-hub-examples Note that i designed and implemented the library a while ago (even if it was constantly upgraded and most dependencies are not obsolete), when i needed a tool to prototype and create relatively simple data exposing services in the most declarative and easy way possible, so it's probably not the best tool to build services requiring the data to be persisted with complicated transaction strategies, or to implement asynchronous communication in the effective fashion out of the box, libraries like pedestal-service are much better at those kind of tasks. I still think it could be useful to people, so i decided to announce it. Feedback welcomed, Jan -- -- 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/groups/opt_out.
Re: Clojure in production
Hi Plínio, at gateprotect, we use clojure in our firewall product for model representation and doing all the hard/logic work. Some stats: ~ 370 namespaces ~ 25000 sloc A great part of that is written in our model DSL. Cheers, Jan http://www.gateprotect.com We are hiring! http://www.gateprotect.com/en-GB/company/jobs.html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Himilsbach 0.1.0 is released
Dear Clojurians, I'm very happy to announce Himilsbach 0.1.0. Get it from Clojars: [himilsbach 0.1.0] Himilsbach is a tiny actor library for intra-process messaging inspired by Erlang. The main highlight of this release is a considerable performance improvement achieved by adoption of a new message queueing mechanism. The benchmark based on a graph of 1000 actors sending messages to each other shows a nearly fourfold improvement since version 0.0.1. The new version is capable of sending 1M messages per second on an Intel Core i7 quad-core processor. The API has not been changed since version 0.0.1. Differences are summed up at https://github.com/jstepien/himilsbach/compare/0.0.1...0.1.0 Documentation generated using Marginalia is available at http://jstepien.github.io/himilsbach/ Your feedback, pull requests and bug reports are very much appreciated! All the best, -- Jan Stępień -- -- 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/groups/opt_out.
Re: [ANN] Himilsbach 0.0.1 is released
W dniu poniedziałek, 6 maja 2013 05:12:37 UTC+2 użytkownik Ben Mabey napisał: On Sun May 5 18:31:59 2013, Mikera wrote: On Tuesday, 30 April 2013 04:12:14 UTC+8, Jan Stępień wrote: Dear Clojurians, I'm very happy to announce Himilsbach 0.0.1. Himilsbach is a tiny actor library for intra-process messaging inspired by Erlang. Find it at https://github.com/jstepien/himilsbach Your feedback is very much appreciated! Nice - been looking for some Erlang-style features in Clojure for a while. How does this compare with Pulsar? - https://github.com/puniverse/pulsar Looking at the source of Himilsbach it seems to be using java (OS) threads where as Pulsar allows for light weight threads and regular JVM threads. Thanks for pointing me to Pulsar; I find it very interesting. From what I've learned reading Pulsar's announcement blog post, Himilsbach differs from Pulsar in a number of ways. Himilsbach is a very simple library focusing solely on concurrent message passing. Unlike Pulsar, Himilsbach doesn't offer abstractions over IO, fibers, nor channels inspired by Go. Local actor's state is also absent in Himilsbach, since users of the library can easily add it themselves using refs or agents. Minimalism of the offered API has been one of my goals. Pulsar seems to be a more faithful adaptation of Erlangs approach. Both Himilsbach and Pulsar cover the basic principles of message passing and linking processes, but, for example, only the latter supports selective receive. There's nothing preventing this feature being implemented in Himilsbach though and I think it would be a good addition to the API. As noted by Ben, actors in Himilsbach are run in futures, and consequently they are executed in regular JVM threads. This results in worse performance in case of workload with many context switches. I did some benchmarks using OpenJDK 1.7.0-u21-b12. I ported the full graph benchmark from Himilsbach to Pulsar. I ran it for 1k actors exchanging 1M messages in total. Results for 75 executions are following. Time measurements are given in ms. PulsarHimilsbach Mean 551 1151 Median526 1041 St. dev. 144 399 To make the comparison fair I implemented the ring benchmark discussed in Pulsar's announcement blog post using Himilsbach's actors. Again, I ran it for 1k actors exchanging 1M messages in total. Results for 75 executions indicate that Pulsar excels in this benchmark. PulsarHimilsbach Mean 722 12311 Median714 12312 St. dev. 57333 Tests were run against commits e3c208e in case of Pulsar and b2b44e1 in case of Himilsbach. I've attached code of two adapted benchmarks. Finally, Himilsbach currently works on JVM 6/7/8. As I've learned from Ron Pressler, the Pulsar's author, his library requires JVM 7 due to dependence on the Fork/Join framework. JVM 8 support is on Pulsar's to-do list. I'm adding Ron Pressler to CC in case he'd like to clarify something or comment on this comparison. All the best, -- Jan Stępień -- -- 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/groups/opt_out. graph_old.clj Description: Binary data ring.clj Description: Binary data
[ANN] Himilsbach 0.0.1 is released
Dear Clojurians, I'm very happy to announce Himilsbach 0.0.1. Himilsbach is a tiny actor library for intra-process messaging inspired by Erlang. Find it at https://github.com/jstepien/himilsbach Your feedback is very much appreciated! All the best, -- Jan Stępień -- -- 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/groups/opt_out.
Re: Are futures garbage-collected?
Thanks to everyone for the helpful replies. I've been using futures in this manner for a long time now and they work fine, but I wanted to make sure this is the specified behavior. --J. -- 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
Are futures garbage-collected?
If I create a future but do not hold on to it anywhere and never dereference it, is the thread guaranteed to run until successful completion? In other words, if I create futures entirely for side effects, should I worry about them getting terminated and GCd? I looked for an answer but could not find anything relevant. Any hints appreciated. thanks, --J. -- 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
Re: Migration to 1.3 for mortals
On Sep 13, 1:44 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: Since the new, separated contrib libraries are supposed to be compatible with Clojure 1.2, you could perhaps also start migrating one lib at a time at your leisure. This might even enable you to contribute to a migration document. Yes, this is what I am hoping people will do. Move to the new libraries first, then switch over to Clojure 1.3. That is exactly our plan, except we probably won't start immediately, as the word leisure in the paragraph above doesn't quite apply to our current situation :-) thanks, --J. -- 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
Re: Migration to 1.3 for mortals
On Sep 10, 9:31 pm, Sean Corfield seancorfi...@gmail.com wrote: On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter jrych...@gmail.com wrote: If you use Clojure to build an application that you subsequently launch and maintain, it is pretty much a given that you use contrib. Lots of it, in fact. I think that depends on when you started building stuff with Clojure. I get the impression quite a bit of old contrib grew up to provide functionality not in Clojure's core and I see quite a few pieces of old contrib that are explicitly deprecated because functions moved to Clojure 1.2 (c.c.string, for example, mostly moved to clojure.string long before Clojure 1.3 got under way). I suspect that folks who started with Clojure long ago and are relying heavily on old contrib, are probably relying on those old deprecated namespaces and functions and have simply avoided updating their code to use the newer, supported namespaces. I think the break in contrib coming with 1.3 will be good for the Clojure ecosystem overall because it will force a lot of folks to clean up their code :) Just to clarify, I am not against change, quite the opposite — I'd much rather see a quickly evolving Clojure ecosystem than one mired in legacy code. I will gladly rework my code regularly so that it works with newer releases. I'd just like to see the process somewhat documented. I think I've said all there was to be said in this discussion, so I'll shut up now and wait for better documentation or a migration guide. In the meantime, we'll stick to Clojure 1.2 together with our patched-up monolithic contrib. thanks, --J. -- 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
Re: Migration to 1.3 for mortals
On Sep 9, 8:04 pm, Sean Corfield seancorfi...@gmail.com wrote: On Fri, Sep 9, 2011 at 1:09 AM, Jan Rychter jrych...@gmail.com wrote: [...] I think issues like that are fundamentally important if Clojure is to be adopted for production work. I agree - which is why I'm pushing on clojure-dev for some serious attention to be paid to the contrib migration issue. Thanks for the explanations. I'll summarize: clojure-contrib is being reorganized. There is no clear migration path for applications that use the monolithic 1.2 contrib. Not all of 1.2 contrib code made its way into new modules yet. There is no migration guide for existing applications. Unless clojure 1.3 can be used with 1.2 monolithic contrib, I'd strongly suggest that the release of clojure 1.3 should wait until the contrib situation is resolved. I'd much rather see an announcement of production-ready Clojure 1.3 than an announcement of very cool core code that can't really be used in production systems. Much as it sounds boring, it's the libraries that define the applicability and usability of a programming language. --J. -- 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
Re: Migration to 1.3 for mortals
On Sep 10, 5:20 pm, Steve Purcell st...@sanityinc.com wrote: David Nolen dnolen.li...@gmail.com writes: Waiting for contrib authors to sort out their libraries seems unrelated as to whether 1.3 should or should not be released. That's like delaying Python 3 because libraries don't support it yet. It still wouldn't be released. Except that Python 3 comes bundled with many more libraries than Clojure. I think the issue is that Clojure started off in the Python mold as Batteries Included in the form of a coordinated Core + Contrib, and has since transitioned to Some Batteries Included, jettisoning much of Contrib to fend for itself. I respect the wisdom of those who've made the decision to decouple Core and Contrib, so I'm not about to question that decision, but I guess I'm not alone in having viewed Contrib + Core as Clojure up to this point. If you use Clojure to build an application that you subsequently launch and maintain, it is pretty much a given that you use contrib. Lots of it, in fact. This might be different for people who hack on Clojure itself, write libraries, or work on small (and fun) projects. There is a disconnect that is very risky -- witness Common Lisp, where for many years people would hack on nothing but language implementations and library situation was abysmal. It's gotten much better in recent years, but still isn't anywhere near languages like Python or Ruby. My worry is that the decoupling of core Clojure from contrib will result in contrib authors not caring too much about sorting out the current situation. Also, I think much of the fanfare of the 1.3 release will be shadowed by the contrib situation. And perhaps most importantly, I worry that I won't be able to take advantage of Clojure 1.3 in any of my applications anytime soon. I think contrib modularization should either be carried all the way in time for 1.3, or stopped altogether (meaning I could continue to use the same old monolithic contrib code with Clojure 1.3). --J. -- 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
Re: Migration to 1.3 for mortals
On Sep 8, 10:36 pm, Armando Blancas armando_blan...@yahoo.com wrote: There's this page:http://dev.clojure.org/display/doc/Clojure+Contrib Here's the main page for the new repos:https://github.com/clojure Problem is, none of those pages help with my problem: how do I go from a list of 1.2 clojure-contrib modules to a list of dependencies in the new contrib. Plus the resources above are incomplete. Take an example -- even in the relatively simple case of clojure.contrib.combinatorics: note that it is NOT listed on http://dev.clojure.org/display/doc/Clojure+Contrib, and if I follow the github repos I'll end up in https://github.com/clojure/math.combinatorics which tells me nothing about what I should add to project.clj (what is the latest released version, for instance). I have to say that from the point of view of application developers the current state of contrib likely means I won't be migrating to 1.3 anytime soon. What's worse, I'll be left in a situation where there are bugs in 1.2 contrib which only get fixed in the 1.3 version, which I won't be able to use. I already have one such bug that I reported (and provided a fix) for clojure.contrib.json. It never made it into any contrib release, which means we have to use a locally-modified version. I think issues like that are fundamentally important if Clojure is to be adopted for production work. --J. -- 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
Migration to 1.3 for mortals
How do we mere mortals (that develop and maintain large apps) migrate to 1.3? I thought I'd be able to at least estimate the effort involved for our application in about an hour today, but failed. In spite of searching, looking through various repos, reading the wiki and in general googling around I was unable to find a migration path for the clojure.contrib code we currently use. As a first step I thought I'd fix project.clj so that it correctly points to newer clojure.contrib library or modules. A quick grep through our code shows we depend on: clojure.contrib.combinatorics clojure.contrib.command-line clojure.contrib.core clojure.contrib.def clojure.contrib.except clojure.contrib.io clojure.contrib.java-utils clojure.contrib.json clojure.contrib.logging clojure.contrib.map-utils clojure.contrib.mmap clojure.contrib.seq clojure.contrib.seq-utils clojure.contrib.str-utils clojure.contrib.str-utils2 clojure.contrib.string clojure.contrib.trace clojure.contrib.zip-filter clojure.contrib.zip-filter.xml How do I go from this list to a list of new project.clj lines? After an hour of poking and probing I only got to: [org.clojure/data.json 0.1.1] [org.clojure/tools.cli 0.1.0] [org.clojure/tools.logging 0.2.0] I got some version numbers from github repo READMEs, some from manually listing directories under https://oss.sonatype.org/content/groups/public/org/clojure/ There must surely be a better way — any hints would be very much appreciated. Also, a suggestion for documentation maintainers: please think about people who have code based on 1.2 and haven't followed Clojure closely for the past 2 years or so — we lack a lot of context information that might be obvious to you. As an example, I managed to list lots of clojure.contrib modules before realizing that this particular modularization is obsolete and has already been abandoned in one of the alphas. thanks, --J. -- 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
Re: Indexing a nested sequence
Hello,
I'm trying to find an elegant way of indexing a two-dimensional sequence
with the coordinates as keys.
If you know width and height you can generate the pattern of coordinates instead
of calculating it:
(map vector (for [y (range height) x (range width)] y)
(cycle (range width)))
= ([0 0] [0 1] [0 2] [1 0] [1 1] [1 2]) ; for height 2, width 3
or if you don't like 'for':
(map vector (mapcat #(repeat width %) (range height))
(cycle (range width)))
now combine with a one-dimensional input string:
(zipmap (map vector (for [y (range height) x (range width)] y)
(cycle (range width)))
#I##O#)
= {[1 2] \#, [1 1] \O, [1 0] \#, [0 2] \#, [0 1] \I, [0 0] \#}
HTH,
Jan
--
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
Re: group tag for clojure newsgroup
Rich Hickey richhic...@gmail.com writes: On Mar 4, 2:56 am, TimDaly d...@axiom-developer.org wrote: For the other groups that I subscribe to, the email subjects are always prefixed with the group name, e.g. Re: [sage-devel] This is the mail subject This makes it possible to reliably group the emails into folders. Is it possible to do the same for Clojure and Clojure-dev? It is possible for me to put a [Clojure] prefix on the emails. Does anyone have any objections to that? It pollutes the Subject line for no good reason, anyone can filter based on headers anyway. This is useful only for people who don't filter their mail and drop everything into one huge inbox. --J. -- 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
Re: variation of time macro
Shawn Hoover shawn.hoo...@gmail.com writes: I see usages of the time macro that wrap the expression of interest in a call to dotimes. Is there any interest in an overload of time that takes an additional parameter for a number of iterations, evaluates the expression that many times, and prints the average time in the report? Usage: user (time 10 (* 21 2)) Elapsed time: 0.201 msecs, Average: 0.0201 msecs 42 user I think this is a bad idea, read this article for reasons why http://www.ibm.com/developerworks/java/library/j-benchmark1.html -- jan -- 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
Re: Code improvement: incrementing a meta val
samppi rbysam...@gmail.com writes: Is there a more elegant way to phrase this? (defn- inc-index Increments the :index val in the givens state's metadata. [state] (vary-meta state assoc :index (inc (:index ^state This is slightly cleaner (defn- inc-index Increments the :index val in the givens state's metadata. [state] (vary-meta state update-in [:index] inc)) -- jan -- 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
Re: newbie question
Warren Wood warrenthomasw...@yahoo.com writes: Thought of this, which I like better. Again, I'm surprised if conjunction is not already a standard function, but I can't find it. I'm still a bit tempted to call it AND for readabilty of code. (I spent some time studying combinatory logic back in the day. (I even had a Curry Fellowship at Penn State where Haskell Curry used to work.) Can't remember what combinator letter my dual function is.) (defn dual [x] (fn [f] (f x))) (defn conjunction [ preds] (fn [x] (every? (dual x) preds))) (filter (conjunction even? (partial = 16) (partial = 9)) (range 1 20)) for cases like this you can also leverage reader macros (filter #(and (even? %) (= 16 %) (= 9 %)) (range 1 20)) -- jan -- 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
Re: Topological sort
Nick Day nicke...@gmail.com writes:
I've been trying to implement a topological sort and have been
struggling a bit. I have a map of symbol vs collection of symbols
like:
{a [b c], b [c], c [nil]}
which can be read as 'a' depends on 'b' and 'c', 'b' depends on 'c'
and 'c' doesn't depend on anything. I've been trying to write
something that returns a collection of the dependencies in order (c,
b, a) but so far I've only been able to do it using a ref to store
intermediate output of the sorting. I was wondering if anyone has
already done something similar?
clojure.contrib.graph/dependency-list might be close enough for you
(use 'clojure.contrib.graph)
(dependency-list {:nodes [:a :b :c]
:neighbors {:a [:b :c]
:b [:c]}})
=[#{:c} #{:b} #{:a}]
--
jan
--
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
Re: Code formatter
John Harrop jharrop...@gmail.com writes: The following, which I relinquish into the public domain and certify is original to me, takes a string and reformats it as Clojure code, returning a string. It behaves similarly to the Enclojure reformatter, but: 1. Outside string literals and comments, it will take care of all spacing. 2. Comments get one space before and one after the ; before the comment text. If the comment text originally started with a space none is inserted after the ;. 3. If two comments are on successive lines and the second can be aligned with the first by inserting additional spaces before the ;, the comments are aligned in this manner; exception to item 2. it doesn't handle these comments gracefully (format-code ;;; header comment (defn test-comments [] ;; whole line comment :thing)) -- jan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Baffled by NPE
Brian Hurt bhur...@gmail.com writes: Of course, you don't have tail call optimization in Clojure (dang jvm). So this is probably better: (defn for-each [f items] (loop [ curr items ] (if (empty? curr) nil (do (f (first curr)) (recur (rest curr)) When you only have a single branch in `if' it is more conventional to use `when', or in this case `when-not'. And defn sets up a recur point so there's no need for the explicit loop either. (defn for-each [f items] (when-not (empty? items) (f (first items)) (recur f (rest items -- jan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Printing to *out* in another thread
Gorsal s...@tewebs.com writes: How am i supposed to print to the output from another thread? I want, for example, (future (println HI)) to print hi. It doesn't. If you are using slime the default behaviour will be to print HI to the *inferior-lisp* buffer. You can redirect output to the repl with M-x slime-redirect-inferior-output or place this line in your .emacs file (add-hook 'slime-connected-hook 'slime-redirect-inferior-output) -- jan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure/EPL and the GPL
Tassilo Horn tass...@member.fsf.org writes: [...] BTW: What's the reason that Clojure is licensed under the EPL and the contrib stuff under CPL? Since clojure is not really eclipse-related, I don't see a good rationale. IMHO, the Lesser GPL would be a much better fit. Then you can use clojure also in commercial apps (I guess that was the rationale behind EPL), but still you can use it in projects with any other free-software license, may it be EPL, GPL or whatever... The GPL and LGPL are very restrictive licenses. While most people only focus on the source code availability issue, the real show-stopper for most commercial usage is the anti-patent clause that exists in both the GPL and LGPL. This clause is a potential landmine, even though little attention is paid to it. It exists in the same form in both the GPL and LGPL. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: replace-subtree for zippers?
Meikel Brandmeyer m...@kotka.de writes: Hi, On Aug 21, 12:05 pm, Jan Rychter j...@rychter.com wrote: It isn't what I want. But that's because I misspecified what I actually wanted. I didn't think about the problem enough. I need something more akin to a splice function: (splice tree1 index tree2) (splice '(1 2 (3 4 5) 6) 4 '(7 8 (9 10))) should produce = '(1 2 (3 7 8 (9 10) 6)) (defn zip-splice [loc node new-node] (loop [loc loc] (cond (zip/end? loc) (throw (Exception. Node not found)) (= (zip/node loc) node) (let [childs (zip/children new-node) loc(reduce #(zip/insert-left %1 %2) loc childs)] (zip/remove loc)) :else (recur (zip/next loc) user= (def z (zip/vector-zip [1 2 [3 4 5] 6])) #'user/z user= (def s (zip/vector-zip [7 8 [9 10]])) #'user/s user= (zip/root (zip-splice z 4 s)) [1 2 [3 7 8 [9 10] 5] 6] Be aware of the '=' there. This you might want to replace with some smarter function to check for the identity of a node. I stumpled over that in this thread: http://groups.google.com/group/clojure/browse_thread/thread/bfd6539ec367a95b I'm not really a tree expert. So if you have solved this problem, please let me know. I'm still interested in this. Thanks -- this is good stuff. I appreciate the help. I meant the index as a numeric index into the tree (depth-first traversal), unrelated to the actual tree contents -- I used natural numbers in the tree only as an example. My real trees contain mostly symbols. So your function isn't applicable to my stuff. In the meantime, I came up with this (nothing like a piece of paper and some thinking to work things out): (defn zip-splice [zipped-tree index loc2] (let [splice-site (goto-node zipped-tree index)] (zip/root (zip/replace (zip/up splice-site) (concat (zip/lefts splice-site) (list (zip/node loc2)) (zip/rights loc2)) where goto-node is defined as: (defn goto-node [zipped-code n] (loop [counter 0 loc (zip/next zipped-code)] (if (or (= counter n) (zip/end? loc)) loc (recur (inc counter) (zip/next loc) This seems to do exactly what I wanted. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: replace-subtree for zippers?
Stefan van der Meer stefanvanderm...@gmail.com writes: On Aug 21, 12:05 pm, Jan Rychter j...@rychter.com wrote: think crossover in genetic programming (this is actually what I need this for). I've written a genetic programming framework in Clojure, it might be of interest if you're looking for some inspiration: http://bitbucket.org/svdm/clojuregp/src/ I didn't know about this -- thanks, I will definitely check it out. Though I experimented with using zippers initially, I ended up not using them for the fundamental tree operations like the one discussed here. I found zippers to be quite a bit slower than more low level approaches for traversing trees, which becomes significant in typical GP experiments where things like subtree replacement are used a large number of times. Interesting. I don't see why zippers would be much slower than other approaches, unless manipulating metadata in Clojure is excessively slow. In my case, I don't much care, because my program spends most of the time in fitness evaluations. Actual code manipulation takes only a small percentage of the time and isn't worth worrying about (so far). [...] So that's one way of doing it. Not the prettiest, but it does what I need it to. I'm not sure it does exactly what you want though, because: user (tree-replace 3 '(7 8 (9 10)) '(1 2 (3 4 5) 6)) (1 2 (3 (7 8 (9 10)) 5) 6) Compared to: should produce = '(1 2 (3 7 8 (9 10) 6)) I'm kind of wondering why you want the replacement subtree (tree2 if you will) to be spliced flat into the original tree like that. It seems to me that such an operation would not actually do a subtree replacement in the typical genetic programming sense. Flat splicing-in makes sense, because my GP is a stack-based one (a concatenative language, inspired by PushGP and Forth). Programs are really flat sequences of instructions and constants. Trees arise only because I want the language to have loops and function/code generation facilities. A subtree is a piece of code that gets pushed onto the code stack, to be executed later. For simple tasks, flat sequences of instructions would be enough and indeed this is the primary mechanism. Here are three examples that hopefully illustrate the concept: (1 2 int+) = 3 (2 (1 int+) exec) = 3 (2 (1 int+) 3 dotimes) = 5 As you can see, I really do want the crossover operator to splice code flat into the original tree. Adding a subtree has an entirely different meaning. You might want to look at stack-based GP. I think it is much more flexible than code trees. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: clojure success story ... hopefully :-)
bradford cross bradford.n.cr...@gmail.com writes: Hi Chad, yep, that was me. We do hope to open source some stuff soon. First will probably be our wrappers for cascading/hadoop and s3. Those would be of great interest to many of us. Please do. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: replace-subtree for zippers?
Meikel Brandmeyer m...@kotka.de writes: A transcript: ; Create trees... user= (def t1 [1 [[2 3] 4]]) #'user/t1 user= (def t2 [[[:a :b] :c] :d]) #'user/t2 ; Create zippers and navigate to subtrees... user= (def zt1 (- (zip/vector-zip t1) zip/down zip/right)) #'user/zt1 user= (zip/node zt1) [[2 3] 4] user= (def zt2 (- (zip/vector-zip t2) zip/down)) #'user/zt2 user= (zip/node zt2) [[:a :b] :c] ; Replace the subtree from first zipper with subtree from second zipper... user= (def zt1 (zip/replace zt1 (zip/node zt2))) #'user/zt1 user= (zip/root zt1) [1 [[:a :b] :c]] Isn't that what you want? It isn't what I want. But that's because I misspecified what I actually wanted. I didn't think about the problem enough. I need something more akin to a splice function: (splice tree1 index tree2) (splice '(1 2 (3 4 5) 6) 4 '(7 8 (9 10))) should produce = '(1 2 (3 7 8 (9 10) 6)) think crossover in genetic programming (this is actually what I need this for). --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
replace-subtree for zippers?
Has anyone written a replace-subtree for zippers? I need to replace an entire subtree with another one (from another zipped structure) and found out that zip/replace won't help me there. Writing my own has proven remarkably difficult, or perhaps I'm missing something obvious. Any help appreciated. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Idiom for array slicing
Mark Triggs mark.h.tri...@gmail.com writes: Is there an idiom for what I'm doing below, or does a function already exist? (let [vowels (slice abcdefghijklmnopqrstuvwxyz 0 4 8 14 20)] vowels) = (\a \e \i \o \u) Here's how I would do it: (defn extract [coll keys] (map #(get coll %) keys)) or (defn slice [coll keys] (remove nil? (map #(get coll %) keys))) -- jan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Idiom for array slicing
(defn slice [coll keys] (remove nil? (map #(get coll %) keys))) this doesn't handle nils, here is a better definition (defn slice [coll keys] (let [not-found (Object.)] (remove #(identical? % not-found) (map #(get coll % not-found) keys -- jan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ANN: Clojuratica -- A seamless interface to Mathematica for fast numerics and more
Garth Sheldon-Coulson g...@mit.edu writes: I would like to announce *Clojuratica http://clojuratica.weebly.com/,* a high-performance, seamless Clojure interface to Wolfram Mathematicahttp://clojuratica.weebly.com/#mathematica. Wow! This is exactly what I needed. I've been looking for interfaces to Mathematica back when I was still using Common Lisp. Recently I do most of my coding in Clojure and I'd eventually cook up something similar to what you did, only with much less functionality. I've even been looking at documentation for J/Link recently. Thank you, this interface will be very useful. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: sizeof in Clojure
On Jul 21, 5:51 am, Jan Rychter j...@rychter.com wrote: Is there a way to get the size of a data structure in Clojure? I've been wondering how much more space-efficient vectors are than lists, but I don't know how to measure it. Stuart Sierra the.stuart.sie...@gmail.com writes: Short answer: no, because Java has no sizeof operator. You can use Java profiling tools to examine the memory usage of your app if needed. Since all of clojure's data structures are persistent (reusable), they won't necessarily meet your expectations for memory usage based on the standard definitions of vector/list/etc. A clojure vector is *not* just an array. A clojure list is *not* just a linked list. The names refer to the performance characteristics (vectors allow random access, lists allow linear access) rather than the implementation. In fact, most of Clojure's data structures are variants of trees, and they are quite efficient. If you are concerned about memory usage, I recommend you write a prototype of your app using Clojure's built-in structures first. If that uses too much memory, try refactoring your code to use Java arrays or some other Java data structure optimized for your use case. I should have described the problem better. In my case, I'm not considering using native Java data structures. I have stacks implemented on top of Clojure vectors and Clojure lists. I do not care that much about random access, but I do care about O(1) count operation (which both lists and vectors support). I measured the performance in a real-life scenario and it is nearly identical for vectors and lists (lists are actually slightly faster). What I would like to know is given the same amount of data, which structure will be more memory-efficient? I realize this is not an obvious thing to measure, and I did look at the article that describes a solution for Java (http://www.javaworld.com/javaworld/javaqa/2003-12/02-qa-1226-sizeof.html). I've been wondering if something similar has been implemented for Clojure data structures. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Risks of (over-)using destructuring?
Laurent PETIT laurent.pe...@gmail.com writes:
2009/7/24 pcda...@gmail.com pcda...@gmail.com
On Jul 23, 10:15 pm, Richard Newman holyg...@gmail.com wrote:
Coming from an OO background which puts a strong focus on data
encapsulation,
this makes me a little nervous.
The same problem exists with OO.
Not to the same extent, unless you expose all the internals of your
classes (including fields) as public.
Java tries hard to hide the detail, yes, but it's still possible to use
reflection.
So it's just (as you stated) a fact of making it easy or difficult.
But you should consider that everything you cannot find in the (doc) of
functions is not public API.
While I agree with what you say, I have a couple of problems with
relying on doc strings to document private fields. Firstly, I don't
write docs while prototyping. Secondly, docs aren't visible when
browsing code.
I've been using the convention of naming private fields with a
trailing hyphen: {:foo public :bar- private}
Here's a patch that adds syntax highlighting for this to clojure-mode.
diff --git a/clojure-mode.el b/clojure-mode.el
index 2d82ab6..7f1c28f 100644
--- a/clojure-mode.el
+++ b/clojure-mode.el
@@ -374,6 +374,8 @@ elements of a def* forms.
\\(\\sw+\\)? )
(1 font-lock-keyword-face)
(2 font-lock-function-name-face nil t))
+ ;; Private keywords :foo-
+ (\\:\\sw+-\\ 0 font-lock-constant-face)
;; Constant values.
(\\:\\sw+\\ 0 font-lock-builtin-face)
;; Meta type annotation #^Type
--
jan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
sizeof in Clojure
Is there a way to get the size of a data structure in Clojure? I've been wondering how much more space-efficient vectors are than lists, but I don't know how to measure it. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: turn a seq into a list
Jarkko Oranen chous...@gmail.com writes: On Jul 15, 1:54 pm, Jan Rychter j...@rychter.com wrote: I've been looking for a function that would take a seq and create a list (a real clojure.lang.PersistentList), but haven't found one. The closest I got was: (apply list my-seq) Essentially, I'm looking for something similar to (vec) that returns lists. --J. Why would you want to do this? Seqs are nearly identical to lists (The only difference I can think being that lists are Counted, while seqs are not). If it's about forcing strictness, You can use 'doall. I rely heavily on count being O(1). I have stacks implemented on top of lists and if those lists turn into seqs, the performance impact is huge. However, if you really do need a PersistentList, then (apply list the- seq) is what you need. The vec function is a shortcut for (apply vector the-seq), provided in the standard library because vectorising a seq is rather common. Based on my (admittedly limited) experiments with a profiler, apply seems to be a rather heavyweight tool. And vec doesn't seem to be a shortcut for apply, it seems it creates the structure directly: (defn vec Creates a new vector containing the contents of coll. ([coll] (. clojure.lang.LazilyPersistentVector (createOwning (to-array coll) --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure vectors
Thanks to everyone who replied in this thread. I am impressed by the signal-to-noise ration on this list and by the quality of replies. I will try to reply to everyone in a single post, trying to summarize. On Jul 13, 11:15 am, Jan Rychter j...@rychter.com wrote: I've been trying to implement stacks using vectors in Clojure. In case you wonder why, it's because I need stacks with a fast item count operation. Rob rob.nikan...@gmail.com writes: If that's the only reason, you don't have to use vectors. The following page says that 'count' for lists is O(1) Indeed -- I missed that, and my experiments seemed to indicate that calling (count) really slows things down. It turns out it was because my lists were turning into seqs behind my back. Mark Engelberg mark.engelb...@gmail.com writes: Using conj and pop on vectors for stack operations should work just fine. Don't use subvec though; nested subvecs will really start to slow things down. I went ahead and implemented my stacks using both lists and vectors, then did some careful benchmarking. It turns out there is no discernible performance difference. I am not sure what you mean about subvecs, though -- I currently use them for dropn and rot operations, and I don't know how to avoid using them: (defmacro stack-dropn [stack n] `(let [stack# ~stack] (subvec stack# 0 (- (stack-count ~stack#) ~n (defmacro stack-rot [stack] `(let [stack# ~stack] (if ( (stack-count stack#) 1) (apply conj (vector (peek stack#)) (subvec stack# 0 (dec (count stack# stack#))) (incidentally, if anyone can suggest a better rot implementation, I would be very grateful -- rot rotates the stack, putting the last element of the vector first) So, to summarize -- my real performance problem is that my lists were becoming lazy seqs without me knowing. It turns out you REALLY REALLY have to know the difference between a list and a seq. And, since performance of lists and vectors in my case is identical, I don't know which one to choose now for my stacks? --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
turn a seq into a list
I've been looking for a function that would take a seq and create a list (a real clojure.lang.PersistentList), but haven't found one. The closest I got was: (apply list my-seq) Essentially, I'm looking for something similar to (vec) that returns lists. --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Clojure vectors
I've been trying to implement stacks using vectors in Clojure. In case you wonder why, it's because I need stacks with a fast item count operation. While experimenting I discovered some vector properties which were unexpected. conj adds at the end of the vector as expected: user (conj [1 2 3] 4) [1 2 3 4] However, after reading Programming Clojure (page 114) I expected to be able to use sequence functions, such as drop-last, without my vectors changing representation. It seems this is not the case, as after calling drop-last (or indeed any of the seq functions) conj no longer adds at the end: user (conj (drop-last 1 [1 2 3]) 4) (4 1 2) I don't know if it also has performance implications (does it turn my vector into a list?). So it turns out that pretty much the only operations I can use on my vectors are subvec and pop: user (conj (subvec [1 2 3] 0 2) 4) [1 2 4] user (conj (pop [1 2 3]) 4) [1 2 4] user I didn't expect this to happen. Most tutorials (and Stuart Halloway's book) emphasize the generality of the sequence functions, only mentioning that subvec is faster for vectors. I think the fact that they also change subsequent behavior of conj is fundamental and should be printed in bold type. Am I missing something here? And while we're on the subject -- any hints for implementing a stack with a fast item count? (apart from a list with a separate counter) --J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Support for disabling forms (reader macro similar to CL's #-(and))
Following up on my own post: Jan Rychter j...@rychter.com writes: Rich Hickey richhic...@gmail.com writes: On Jan 26, 11:15 am, Cosmin Stejerean cstejer...@gmail.com wrote: On Mon, Jan 26, 2009 at 6:34 AM, Rich Hickey richhic...@gmail.com wrote: On Jan 25, 4:10 pm, Laurent PETIT laurent.pe...@gmail.com wrote: #- makes sense (CL didn't always make things the wrong way :-) And indeed, #; *could* break a lot of already existing editors for a while Yes, the issues are: #; is bad for editors #- would be incompatible with CL's #-, and couldn't be upgraded to compatibility without breakage. I'm not sure the latter is a big deal, as #-test ... in CL is just an alternative for #+(not test) ... Is ## an option? How about #_ ? I would prefer #-, but if you think you might want to have a reader conditional system similar to CL in the future, #_ is fine as well. Actually, any character is better than plucking out multi-line forms and commenting them out :-) --J. Any chance this could get implemented, Rich? I really miss that functionality when developing with Clojure. --J. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
