find the last and the nth item without using last or nth
Hello, IM busy with 4Clojure and I have now two challenges which I think can be solved the same way. On a list I first have to find the last item of a list without using last and after that I have to do the same for a nth item and im not allowed to use nth. Now I can convert the list to a vector and use the vector things but I think this is cheating at some way. Could a recurvice way or a loop do the trick. And how do I then take the right value. Should I use first then or is there a better way. I also read about doseq but then I have to find out how to print only the item I want. Anyone who can give a hint without spoiling the answer. Roelof -- 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: find the last and the nth item without using last or nth
Your intuition that this can be done through recursion or a loop is correct (the latter being a more specialised version of the former). When dealing with recursion, it often helps to consider the base case, i.e. where the recursion stops. Typically this is when you get to zero or one elements. You may wish to consider the following questions: 1. How do you find the last element of a seq with exactly one element? 2. How do you find out whether a seq has one element, or more than one element? 3. How do you find out the last element if a seq with exactly two elements? 4. How do you find out the last element of a seq that may have one *or* two elements? - James On 30 April 2014 07:08, Roelof Wobben rwob...@hotmail.com wrote: Hello, IM busy with 4Clojure and I have now two challenges which I think can be solved the same way. On a list I first have to find the last item of a list without using last and after that I have to do the same for a nth item and im not allowed to use nth. Now I can convert the list to a vector and use the vector things but I think this is cheating at some way. Could a recurvice way or a loop do the trick. And how do I then take the right value. Should I use first then or is there a better way. I also read about doseq but then I have to find out how to print only the item I want. Anyone who can give a hint without spoiling the answer. Roelof -- 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: find the last and the nth item without using last or nth
Roelof Wobben rwob...@hotmail.com writes: Could a recurvice way or a loop do the trick. Yes. And how do I then take the right value. For nth, you need a counter that you can increment in each recursion step. For last, you return the first element of the list whose rest is the empty list. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: find the last and the nth item without using last or nth
Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves: Your intuition that this can be done through recursion or a loop is correct (the latter being a more specialised version of the former). When dealing with recursion, it often helps to consider the base case, i.e. where the recursion stops. Typically this is when you get to zero or one elements. You may wish to consider the following questions: 1. How do you find the last element of a seq with exactly one element? the last and the first element are the same 2. How do you find out whether a seq has one element, or more than one element? Look at the length of the seq 3. How do you find out the last element if a seq with exactly two elements? take the first element away and you have a seq of one element . 4. How do you find out the last element of a seq that may have one *or* two elements? Look at the length. If it has one element , see question 1 if it has 2 elements, see question 3. - James On 30 April 2014 07:08, Roelof Wobben rwo...@hotmail.com javascript:wrote: Hello, IM busy with 4Clojure and I have now two challenges which I think can be solved the same way. On a list I first have to find the last item of a list without using last and after that I have to do the same for a nth item and im not allowed to use nth. Now I can convert the list to a vector and use the vector things but I think this is cheating at some way. Could a recurvice way or a loop do the trick. And how do I then take the right value. Should I use first then or is there a better way. I also read about doseq but then I have to find out how to print only the item I want. Anyone who can give a hint without spoiling the answer. Roelof -- 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/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: find the last and the nth item without using last or nth
Op woensdag 30 april 2014 08:22:07 UTC+2 schreef Tassilo Horn: Roelof Wobben rwo...@hotmail.com javascript: writes: Could a recurvice way or a loop do the trick. Yes. And how do I then take the right value. For nth, you need a counter that you can increment in each recursion step. For last, you return the first element of the list whose rest is the empty list. Bye, Tassilo Thanks, and if I use cons (item, list) then item is the value I want. I only have to print it. Roelof -- 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: Proposing a new Clojure documentation system (in Clojure)
Imagine you're reading through some documentation and you notice a problem. Maybe a typo, or something out of date, or something that's confusing that you could explain better. In one scenario there's a git clone link in the sidebar to a repository that contains a bunch of markdown files. In another scenario there's an HTML rendering generated from a literate programming project where the prose is intermixed with the code and requires a specific version of org-mode and the knowledge of how to untangle something in order to render it. This is a focus on the technology which I'm reluctant to do, mostly because I have strong opinions about it. I will say from experience that any technology that separates code from explanation will fail. If we focus on what information we require and what structure has to be placed on that information so it can be understood THEN we can ask about the technologies and what they support. Can I ask, quite seriously and not intending any sarcasm, what you mean by detracts from what's important? For me, what's important is to communicate ideas, designs, and details from one developer to another so that others can maintain, modify, and extend what exists. I've already held forth on what I think that implies so I won't bore you with it. Consider Clojure's primary data structure implementation. It is basically an immutable, log32, red-black tree. For some people that is more than sufficient, especially if they have been working in the code base for years. For others, especially as a developer new to the project, there is a lot to know. Without this information it is very difficult to contribute. A new developer needs an introduction to the IDEA of immutable data structures with a reference to Okasaki's thesis which is online at http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf (a bibliography). A new developer needs to know that the DESIGN of Clojure relies on these immutable data structures so they don't introduce any quick and efficient hacks that violate the design. (a Clojure overview) A new developer needs to know WHAT a red-black tree is, WHY it was chosen, and HOW Clojure maps user-visible data structures to them. (the chapter on this particular data structure) A new developer needs to know the IMPLICATIONS of the choice of log32 since it defines the efficiency. (the design constraints section and the algorithmic analysis section) A new developer needs to know HOW to update a log32 immutable red-black tree. (a pseudocode explanation with pictures) A new developer needs to know HOW the log32 red-black tree is implemented. It is not immediately obvious how the 5-bit chunks are mapped into a 32 bit word. If the task was to re-implement it on a 64 bit word they'd have to know the details to understand the code. (the actual code with explanations of the variables) If the new developer's task is to modify the code for a 64 bit architecture they would need a way to find the code (the table of contents) and places where this information is mentioned (an index). All of the places where it is written need to be properly updated. Even if we focus strictly on what a new developer needs to know we end up with something that smells a lot like a book. From the above we see the need for 1) a bibliography 2) a Clojure overview 3) a chapter focus on this data structure 4) sections on design constraints and algorithmic analysis 5) a section of pseudocode with pictures 6) a section with code and details of the actual implementation 7) a table of contents 8) an index And that's only a few dozen lines of the Clojure source code. Now we know what information we require and what structure has to be placed on that information so it can be understood, managed, and kept up to date with the code. NOW let's talk about technologies that support these requirements. We can examine the ideas for possible technologies to properly organize the above information. Do inline comments in source code files work? Does a Javadoc kind of technology work? Does a wiki on an external website work? Do separate markdown files in the directory tree work? Do we create videos to explain code? Do any of these technologies integrate with the normal edit-compile-test code developement cycle? Does changing the code generate an immediate expectation to update the associated words? I would claim that only a technology that is fully integrated into the developer's main line, day-to-day work cycle will ensure that the associated information up to date. Checking in code ought to require a review of the associated information to ensure that it is up to date; essentially the role of an editor-in-chief whose job it is to maintain high quality, READABLE, natural language. Our standard needs to be that anyone can read the words and KNOW that the code is correct, complete, efficent, and well integrated with the rest of the design. This isn't really a technology problem. We have
Re: find the last and the nth item without using last or nth
Op woensdag 30 april 2014 08:50:22 UTC+2 schreef Roelof Wobben: Op woensdag 30 april 2014 08:22:07 UTC+2 schreef Tassilo Horn: Roelof Wobben rwo...@hotmail.com writes: Could a recurvice way or a loop do the trick. Yes. And how do I then take the right value. For nth, you need a counter that you can increment in each recursion step. For last, you return the first element of the list whose rest is the empty list. Bye, Tassilo Thanks, and if I use cons (item, list) then item is the value I want. I only have to print it. Roelof If I look at the documentations I think I have to use doseq for running and cons for finding and a if then to stop at the right place. Am I at the right track. -- 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: Kwargs vs explicit parameter map for APIs?
After posting this last week I decided to go down the explicit map route,
and I'm already really glad I did. Amongst other things, it has allowed me
to have two similar calls easily share their common options and merge in
the differences. I'm generally a fan of maintaining fairly minimal APIs, I
don't think I'll be duplicating functions, I don't really see a need - two
extra braces are just not that much noise for me. I'd rather use Alex's
last example with the optional map arg than have my-function and
my-function-from-map everywhere.
On 30 April 2014 17:55, James Reeves ja...@booleanknot.com wrote:
On 30 April 2014 06:07, Alex Baranosky alexander.barano...@gmail.comwrote:
I especially dislike that my non-kwarg fns no-longer can elegantly accept
no options. Let me illustrate:
(defn foo [ {:keys [a b]}]
[a b])
(foo :a 1 :b 2)
(foo)
You could write:
(defn foo [ [{:keys [a b]}]]
[a b])
(foo {:a 1 :b 2})
(foo)
- James
--
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: find the last and the nth item without using last or nth
On 30 April 2014 07:49, Roelof Wobben rwob...@hotmail.com wrote: Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves: 1. How do you find the last element of a seq with exactly one element? the last and the first element are the same Right. So to formalise it: (defn last* [coll] (first coll)) I'm using last* as the name so that it doesn't conflict with the function last in clojure.core. 2. How do you find out whether a seq has one element, or more than one element? Look at the length of the seq Unlike vectors, seqs are simple structures and don't know their own length. You can count seqs, but this involves iterating through every element in turn. If all you want to do is find out whether there is more than one element, there's a much simpler and more efficient way. 3. How do you find out the last element if a seq with exactly two elements? take the first element away and you have a seq of one element . So in other words: (defn last* [coll] (first (rest coll))) 4. How do you find out the last element of a seq that may have one *or* two elements? Look at the length. If it has one element , see question 1 if it has 2 elements, see question 3. In code, this would be: (defn last* [coll] (if (more-than-one-element? coll) (first (rest coll)) (first coll))) The more-than-one-element? to be replaced with the answer to question 2, of course. Can you think of a way of making this function recursive to work with any number of elements? - James -- 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: Kwargs vs explicit parameter map for APIs?
Thanks James, that's a useful version to experiment with :)
On Wed, Apr 30, 2014 at 12:04 AM, Colin Fleming colin.mailingl...@gmail.com
wrote:
After posting this last week I decided to go down the explicit map route,
and I'm already really glad I did. Amongst other things, it has allowed me
to have two similar calls easily share their common options and merge in
the differences. I'm generally a fan of maintaining fairly minimal APIs, I
don't think I'll be duplicating functions, I don't really see a need - two
extra braces are just not that much noise for me. I'd rather use Alex's
last example with the optional map arg than have my-function and
my-function-from-map everywhere.
On 30 April 2014 17:55, James Reeves ja...@booleanknot.com wrote:
On 30 April 2014 06:07, Alex Baranosky alexander.barano...@gmail.comwrote:
I especially dislike that my non-kwarg fns no-longer can elegantly
accept no options. Let me illustrate:
(defn foo [ {:keys [a b]}]
[a b])
(foo :a 1 :b 2)
(foo)
You could write:
(defn foo [ [{:keys [a b]}]]
[a b])
(foo {:a 1 :b 2})
(foo)
- James
--
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.
Observing the same non-dynamic var in two different states
I thought that once defined clojure vars are immutable and retain their values. However, I accidentally bumped into a situation where I observe the same var in two different states. Here's how to reproduce: lein new app vartest Add the following files to the test folder: - (ns vartest.test-data) (def uuid (java.util.UUID/randomUUID)) - (ns vartest.core-test (:require [clojure.test :refer :all] [vartest.test-data :as td])) (def my-uuid td/uuid) (deftest a-test (testing accessing same var twice (is (= my-uuid td/uuid Now run the tests: C:\temp\vartestlein test :all lein test vartest.core-test lein test :only vartest.core-test/a-test FAIL in (a-test) (core_test.clj:9) accessing same var twice expected: (= my-uuid td/uuid) actual: (not (= #uuid 030d2fe8-407b-4d67-a505-261bc3650729 #uuid f8405611-e2da-4dd2-973b-508831 27ef6a)) lein test vartest.test-data Ran 1 tests containing 1 assertions. 1 failures, 0 errors. Tests failed. However, if I run lein test :only vartest.core-test/a-test then the very same test passes. What's going on here? Environment: Clojure 1.5.1 and 1.6.0, Leiningen 2.3.4, Java 1.7.0_51 64-Bit, Windows 7 64-bit ::Antti:: -- 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: Observing the same non-dynamic var in two different states
When a namespace is reloaded any vars defined in it are re-evaluated. In your case it would seem that some quirk of the Leiningen test architecture is leading to vartest.test-data being loaded twice. In general namespaces should be robust when it comes to being reloaded. Clojure provides a macro, defonce, for variables you only want defined once across reloads. Using defonce in your test-data namespace should solve your problem. - James On 30 April 2014 07:29, Antti Karanta antti.kara...@gmail.com wrote: I thought that once defined clojure vars are immutable and retain their values. However, I accidentally bumped into a situation where I observe the same var in two different states. Here's how to reproduce: lein new app vartest Add the following files to the test folder: - (ns vartest.test-data) (def uuid (java.util.UUID/randomUUID)) - (ns vartest.core-test (:require [clojure.test :refer :all] [vartest.test-data :as td])) (def my-uuid td/uuid) (deftest a-test (testing accessing same var twice (is (= my-uuid td/uuid Now run the tests: C:\temp\vartestlein test :all lein test vartest.core-test lein test :only vartest.core-test/a-test FAIL in (a-test) (core_test.clj:9) accessing same var twice expected: (= my-uuid td/uuid) actual: (not (= #uuid 030d2fe8-407b-4d67-a505-261bc3650729 #uuid f8405611-e2da-4dd2-973b-508831 27ef6a)) lein test vartest.test-data Ran 1 tests containing 1 assertions. 1 failures, 0 errors. Tests failed. However, if I run lein test :only vartest.core-test/a-test then the very same test passes. What's going on here? Environment: Clojure 1.5.1 and 1.6.0, Leiningen 2.3.4, Java 1.7.0_51 64-Bit, Windows 7 64-bit ::Antti:: -- 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: find the last and the nth item without using last or nth
Roelof Wobben rwob...@hotmail.com writes: For nth, you need a counter that you can increment in each recursion step. For last, you return the first element of the list whose rest is the empty list. Thanks, and if I use cons (item, list) then item is the value I want. I only have to print it. I think you should return it, not just print it. If I look at the documentations I think I have to use doseq for running and cons for finding and a if then to stop at the right place. No. doseq doesn't allow you to stop after you've found the right item, and cons constructs a new list given an item and another list. You want either an explicit recursion or `loop`/`recur` for running through the list, and in each step you want to use `first` and `rest` to split the list into its head item and its tail. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Kwargs vs explicit parameter map for APIs?
my two cents: The extra readability to users when using keyword args also comes from the fact that a function's options are explicit in its signature. So during development, instead of having to look them up in the docs or in the code, my emacs mini-buffer simply shows them to me. Although I do agree with all the good reasons against keywords arguments, to me this is still the decisive reason to prefer them... Joachim Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves: On 30 April 2014 03:54, Sean Corfield se...@corfield.org javascript:wrote: I still think the keyword argument approach is far more readable to _users_ -- 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: find the last and the nth item without using last or nth
Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves: On 30 April 2014 07:49, Roelof Wobben rwo...@hotmail.com javascript:wrote: Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves: 1. How do you find the last element of a seq with exactly one element? the last and the first element are the same Right. So to formalise it: (defn last* [coll] (first coll)) I'm using last* as the name so that it doesn't conflict with the function last in clojure.core. 2. How do you find out whether a seq has one element, or more than one element? Look at the length of the seq Unlike vectors, seqs are simple structures and don't know their own length. You can count seqs, but this involves iterating through every element in turn. If all you want to do is find out whether there is more than one element, there's a much simpler and more efficient way. Yep, if there is only 1 item is a list (rest coll) is nil. In code, this would be: (defn last* [coll] (if (more-than-one-element? coll) (first (rest coll)) (first coll))) The more-than-one-element? to be replaced with the answer to question 2, of course. Can you think of a way of making this function recursive to work with any number of elements? I think I can but I have to try some things but untested it looks like this (defn last* [coll] (if (nil? (rest coll) (first coll))) (last* (rest coll)) Now I wonder how I can make it work if I want to find lets say the 5th value of a array of any number of elements Then rest is never nil. So at first glance if I do not know the length it cannnot be done recursive. I have to do it in a for loop. - James -- 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: find the last and the nth item without using last or nth
Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves: On 30 April 2014 07:49, Roelof Wobben rwo...@hotmail.com javascript:wrote: Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves: 1. How do you find the last element of a seq with exactly one element? the last and the first element are the same Right. So to formalise it: (defn last* [coll] (first coll)) I'm using last* as the name so that it doesn't conflict with the function last in clojure.core. 2. How do you find out whether a seq has one element, or more than one element? Look at the length of the seq Unlike vectors, seqs are simple structures and don't know their own length. You can count seqs, but this involves iterating through every element in turn. If all you want to do is find out whether there is more than one element, there's a much simpler and more efficient way Yes , with only 1 item (res col) is nill. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure for web project? Talk me into it!
Yes, one would hope so. Then again, they've been using Pedestal-App for their projects as well... :-) Anyway, pedestal seems the way to go. After all, I could also see myself replacing it with the latest and greatest routing library without much hassle, should it once be deprecated. On Tuesday, April 29, 2014 5:35:25 PM UTC+2, Mike Haney wrote: Pedestal was developed by Cognitect and I would assume they use it on many of their consulting projects. Since future support appears be a major concern for you (rightly so), Pedestal probably fulfills that requirement better than anything else out there right now. Even if you don't need all the features it offers, it's worth considering building your server-side stack around it for that reason alone. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure for web project? Talk me into it!
Hoplon looks really interesting. It’s just that I don’t want to build a single page application, so it’s kind of moot to consider it, I guess. I was planning to have a lot of server rendered pages in the app, not least to make the content accessible for search engine bots. For the dynamic UI parts I will definitely use React.js or some of the clojure “bindings” for it (Om, Reagent?). We'll see. Guys, thank you all for your comments! On Tuesday, April 29, 2014 6:40:41 PM UTC+2, Daniel Jomphe wrote: Not to make it more complicated for you, but have you looked at Hoplon too? http://hoplon.io/ I was *very* impressed by the author's presentations, the later of which is https://www.youtube.com/watch?v=wVXjExRiFy0 And podcast about it: http://thinkrelevance.com/blog/2014/03/18/alan-dipert-cognicast-episode-052 It's optimized around single-page web apps. I'm not saying that's what I'd necessarily use for your product; you may want to use all of it, or parts of it (it's modular) along something else. If this kind of approach isn't what you'd use on your front-end, make sure you look at Om, Reagent and Quiescent for that. And obviously, I'm forgetting a few other batteries-included frameworks I've seen (because there are a few, apart from Caribou). On Tuesday, April 29, 2014 4:22:58 AM UTC-4, Bernhard Mäder wrote: Hey guys, I need your help in choosing a web stack for a medium sized website project, which is going to take the better half of my time for the next year. I really want to use clojure, because of various reasons, but have never done web development with it before. Frankly, it’s quite hard to feel confident about such a decision, as there are so many libraries to choose from, many of which seem to be abandoned or with very little (public) momentum. These are the notable features I need on the server side: - Internationalization of content, with multilingual URLs - Authentication through username / password and through xing (oauth) and linkedin (oath2). - Image and PDF upload - A small (and pretty basic) CMS - Beautiful reports renderings - A basic admin backend First, I was thinking along the compojure/hiccup/friend stack. I like it for the simplicity, the flexibility and the abundance of documentation on the web. Unfortunately, I see myself reinventing the wheel a few times with this approach… Then there is caribou. I like that it’s very well documented and that it’s already being used in production. It appears to be the most feature complete solution for the time being. It handles images, has backend scaffolding and i18n. OTOH, authentication isn’t really built-in (other than basic auth, if I got that right) and, it’s very new, so adoption seems to be still low. Also, it is developed in-house, so there’s the risk of abandonment, too. Finally, I took a look at pedestal (services). I like its overall design and I especially welcome the URL generator, which is going to be a boon in larger projects. But all in all, it seems to be little more than a (powerful) routing engine (again, maybe I’m missing something) and lacks internationalization as well as authentication (although I read that the snapshot version of friend will work with it). Also, it is developed in-house and not declared production-ready yet. I don’t feel very comfortable with either choice and would appreciate the thoughts of seasoned clojure web devs on that topic. Please talk me into it! I don’t want to end up with scala and play… :-) Thanks for your thought! Bernhard -- 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: Kwargs vs explicit parameter map for APIs?
But that's only true for the variables which are explicitly destructured in the function definition, which in my experience many are not - they're often later picked out of an :as args argument, perhaps dependent on a combination of the parameters which are explicitly destructured. Seesaw never does this, for example. I think it's dangerous to rely on this rather than the documentation since it's often an incomplete view of what the function requires. Cheers, Colin On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.com wrote: my two cents: The extra readability to users when using keyword args also comes from the fact that a function's options are explicit in its signature. So during development, instead of having to look them up in the docs or in the code, my emacs mini-buffer simply shows them to me. Although I do agree with all the good reasons against keywords arguments, to me this is still the decisive reason to prefer them... Joachim Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves: On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote: I still think the keyword argument approach is far more readable to _users_ -- 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: Kwargs vs explicit parameter map for APIs?
And thinking about it (after pressing send, of course), you'd get the same benefit from destructuring an explicit map in the function parameter anyway, wouldn't you? On 30 April 2014 22:11, Colin Fleming colin.mailingl...@gmail.com wrote: But that's only true for the variables which are explicitly destructured in the function definition, which in my experience many are not - they're often later picked out of an :as args argument, perhaps dependent on a combination of the parameters which are explicitly destructured. Seesaw never does this, for example. I think it's dangerous to rely on this rather than the documentation since it's often an incomplete view of what the function requires. Cheers, Colin On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.comwrote: my two cents: The extra readability to users when using keyword args also comes from the fact that a function's options are explicit in its signature. So during development, instead of having to look them up in the docs or in the code, my emacs mini-buffer simply shows them to me. Although I do agree with all the good reasons against keywords arguments, to me this is still the decisive reason to prefer them... Joachim Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves: On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote: I still think the keyword argument approach is far more readable to _users_ -- 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: find the last and the nth item without using last or nth
On 30 April 2014 10:41, Roelof Wobben rwob...@hotmail.com wrote: Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves: Unlike vectors, seqs are simple structures and don't know their own length. You can count seqs, but this involves iterating through every element in turn. If all you want to do is find out whether there is more than one element, there's a much simpler and more efficient way. Yep, if there is only 1 item is a list (rest coll) is nil. Almost. Clojure distinguishes between nil and the empty list. The function you want is next: (rest [1]) = () (next [1]) = nil Why the distinction between next and rest? It has to do with laziness, and if you're interested I can go into more detail. Otherwise just remember that rest returns an empty list, and next returns nil. Can you think of a way of making this function recursive to work with any number of elements? I think I can but I have to try some things but untested it looks like this (defn last* [coll] (if (nil? (rest coll) (first coll))) (last* (rest coll)) That's pretty much right. You just need to use (nil? (next coll)) or (empty? (rest coll)) (defn last* [coll] (if (nil? (next coll)) (first coll) (last* (next coll You can also write it with loop/recur: (defn last* [coll] (loop [coll coll] (if (nil? (next coll)) (first coll) (recur (next coll See how the recursive step is replaced with recur? This is more efficient because we're not filling the stack up as we would with recursion. You can also write the above as: (defn last* [coll] (if (nil? (next coll)) (first coll) (recur (next coll If a recur is used without an outer loop, the whole function acts as an implicit loop. There's one more optimisation you can perform, and that's to take advantage of nil being a falsey value. (defn last* [coll] (if (next coll) (recur (next coll)) (first coll))) If (next coll) isn't nil, it recurs. If it is, then the if statement fails and the first item of the collection is returned. The above code is actually how it's defined in clojure.core. Now I wonder how I can make it work if I want to find lets say the 5th value of a array of any number of elements Then rest is never nil. So at first glance if I do not know the length it cannnot be done recursive. I have to do it in a for loop. You need a counter. Take a look at the version of last* that has a loop/recur: (defn last* [coll] (loop [coll coll] (if (nil? (next coll)) (first coll) (recur (next coll Consider how you might add a counter to the loop. You'll want to increment the counter, then stop when it reaches the desired number. - James -- 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: Hosting Providers
Hi Richard Sorry for the delay. We'll check that out! Having said that, my inclination would be to avoid the compile step if we can and just run on top of the leiningen project (e.e. analogous to ruby apps). Putting Engine Yard aside, it raises an interesting question so I am wondering what other people on this list do. Do you compile your code or just run from the sources as you would in development? Many Thanks Adrian On Thu, Apr 24, 2014 at 2:51 PM, Richard Watson rwat...@engineyard.comwrote: Hi Adrian, You don't have far to look ... Engine Yard now supports Java, and by extension, Clojure. If you can package up your Clojure app into a WAR file (using Leiningen's 'lein ring uberwar', for example) you can deploy it onto a Jetty or Tomcat server in an Engine Yard Java environment. This is a post I published recently on the Engine Yard blog describing the components of a basic Clojure Web app and how to deploy onto Engine Yard. https://blog.engineyard.com/2014/clojure-web-app-engine-yard I'm Richard, Product Manager for Java at Engine Yard. Please, drop me a line if you're interested in trying your Clojure code on Engine Yard, or just go ahead and try it out at http://ui.engineyard.com . We're offering a $100 credit to try out the Java platform and give us feedback. Richard. On Friday, April 18, 2014 11:36:05 AM UTC+1, Adrian Mowat wrote: Hi Everyone, I am currently looking at hosting providers for Clojure for my company. We are using Engine Yard for our Ruby applications and we looking for something comparable in terms of providing an easy path to getting started and easy ongoing maintenance (they allow you to apply OS patches with zero downtime by simply clicking a button for example). We also need 24/7 support for server issues. I was wondering if anyone here could share any experiences and/or recommendations? Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/rdV-idmmGh0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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: find the last and the nth item without using last or nth
Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves: On 30 April 2014 10:41, Roelof Wobben rwo...@hotmail.com javascript:wrote: Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves: Unlike vectors, seqs are simple structures and don't know their own length. You can count seqs, but this involves iterating through every element in turn. If all you want to do is find out whether there is more than one element, there's a much simpler and more efficient way. Yep, if there is only 1 item is a list (rest coll) is nil. Almost. Clojure distinguishes between nil and the empty list. The function you want is next: (rest [1]) = () (next [1]) = nil Why the distinction between next and rest? It has to do with laziness, and if you're interested I can go into more detail. Otherwise just remember that rest returns an empty list, and next returns nil. (defn last* [coll] (loop [coll coll] (if (nil? (next coll)) (first coll) (recur (next coll Consider how you might add a counter to the loop. You'll want to increment the counter, then stop when it reaches the desired number. So without checking it so out of my head I would do this (defn last* [coll, number] (loop [coll coll] (if == counter number)) (first coll) (recur (next coll) (+counter 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/d/optout.
Re: find the last and the nth item without using last or nth
On 30 April 2014 11:41, Roelof Wobben rwob...@hotmail.com wrote: Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves: Consider how you might add a counter to the loop. You'll want to increment the counter, then stop when it reaches the desired number. So without checking it so out of my head I would do this (defn last* [coll, number] (loop [coll coll] (if == counter number)) (first coll) (recur (next coll) (+counter 1 )) Essentially yes. You need to initiate the counter to zero, and you still need a condition to make sure you don't go past the end of the seq (in case n is more than the length of the list), but you've basically got it. - James -- 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: Proposing a new Clojure documentation system (in Clojure)
Phil Hagelberg p...@hagelb.org writes: On Saturday, April 26, 2014 9:21:26 PM UTC-7, Mars0i wrote: I like the general idea of the Valentin's proposal, but I don't understand every bit of it. It sounds complicated. Personally, I'd rather see something that's relatively simple, and good enough, than something that's perfect but unwieldy. If it's too difficult, people won't use it, or they'll waste time, or feel that the Clojure community expects them to spend too much time on something that detracts from what's important. Double-inc[1] on this. Clojure needs people who care about documentation far more than it needs another documentation system. Don't try to apply a technical solution to a social problem. Consider this argument, of the same form. What the JVM needs is people who care about writing good code far more than it needs another JVM hosted language. Don't try and apply a technical solution to a social problem. Following this logic, we can just dump Clojure and use Java; in fact, if we do this, we will achieve a better documentation system than we have at the moment, because javadoc is better than Clojure's system. Of course, technical solutions don't solve all problems, and authoring documentation is difficult to start off with; but Clojure's current system -- an unstructured string -- is not a good tool. Compare Emacs doc Compare these two strings: Returns a new seq where x is the first element and seq is the rest. Create a new cons, give it CAR and CDR as components, and return it. In the latter, we can distinguish CAR and CDR as parameters. In the former, cannot. We could look at arglist :arglists '([x seq]) which tells us. However, we have a new seq and seq is the rest -- one refering to the formal parameter and the other refering to the clojure abstraction. And neither refering to clojure.core/seq which we might otherwise want to hyperlink to. We could change it to this Returns a new object implementing the ISeq interface, where the formal parameter x is the first element and the formal parameter seq is the rest. which avoids the ambiguity, but this is long winded. We need some structure, or at least conventions in Clojure documentation. The lack of this is the technical problem. That we have many potential technical solutions is social problem, not that we have any. Phil -- 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: Sliding Windows
On 30/04/14 04:25, Paulo Suzart wrote: If anyone knows any other sliding window impl please share. Riemann seems to have one: http://riemann.io/howto.html#group-events-in-time -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
testing clojure.core/group-by with clojure.test.check
Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. 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: Clojure Office Hours
This is getting to the point where it seems to make sense as a wiki page like http://dev.clojure.org/display/community/Clojure+User+Groups Maybe http://dev.clojure.org/display/community/Clojure+Office+Hours ? On Tue, Apr 29, 2014 at 5:53 PM, Lynn Grogan l...@thinkrelevance.com wrote: This is awesome, thank you Leif! I just set up an office hours account to help anyone who might be interested in organizing a Clojure tech conference or event, Meetup, etc. I chose some random office times, so ping me if you have a special timing request outside of the listed hours. https://lynn.youcanbook.me/ Cheers! Lynn Grogan (Cognitect, Events Manager) On Monday, April 28, 2014 5:31:04 AM UTC-5, Ulises wrote: Thanks for the pointer Jakob. I've updated the form accordingly. Cheers, On 28 April 2014 10:56, Jakub Holy jakub...@iterate.no wrote: I too have booked a session with Ulises and am excited about it :-) @Ulises It would be nice if the timezone of the session was mentioned on the booking page (your [BST] 9-10am is mine [CEST] 10-11, I believe). 2014-04-28 11:09 GMT+02:00 Rudi Engelbrecht rudi.eng...@gmail.com: Hi Ulises Just finished our session - wow! I have learned a lot by watching how you approach solving the problem I suggested. Looking forward to our next session and thanks a lot for sharing your knowledge. Kind regards Rudi Engelbrecht On 18/04/2014, at 7:41 PM, Ulises ulises@gmail.com wrote: Yikes! Got my first booking for Monday. That was quick! one thing I forgot to mention is that I have no preferred way to do this. I personally have emacs+cider set up, but I'm happy to work with your own set up. In the past I've used ScreenHero (not available for Linux unfortunately) for screen sharing, as well as Google hangouts. Once you've booked an appointment with me please email me privately to arrange the pairing set up so that I can be ready for you :) Cheers On 18 April 2014 10:35, Ulises ulises@gmail.com wrote: Inspired by Leif's offer, I've decided to offer Clojure office hours as well. I'm based in the UK so I reckon the times will be more amenable to those in Europe (not sure the times will be good for those in Asia unfortunately.) Sadly the offer is limited to 1h a day, but hopefully it'll still be useful. You can book me at https://ucb.youcanbook.me/ Cheers! On 18 April 2014 03:03, Leif leif.p...@gmail.com wrote: @Miguel: There are somewhat subtle arrows on the sides for navigation. Thursday, April 24 is still open. I will give a slot to you if you want one, just email me if the 24th is full when you check again. @all: But yes, this round of office hours is almost over. I will be in transit for at least a couple weeks in the beginning of May, but I will probably book some more hours when I become stationary again. It will probably be more like 4 or 5 hours a week, though, not 8. @all: Several poor souls from Europe are going to stay up until 2 a.m. for this, and people further east are probably just silent because the time difference is so large; So, I definitely think some European / African / Asian / Australian clojure devs' office hours would be popular. It's fun, and you might find some people to hire, if that's your thing! --Leif On Thursday, April 17, 2014 10:43:50 AM UTC-4, Miguel Ping wrote: Hey, the schedule's full! :\ On Wednesday, April 16, 2014 2:57:49 AM UTC+1, Marcus Blankenship wrote: Leif, thanks for the great session today. Not only did I get a jump start on my next 4Clojure problems, but I learned some emacs as well! Very enjoyable, and I look forward to next week’s session. THANK YOU! All, if you’re trying to get a jumpstart on Clojure, I highly recommend Leif’s office hours. -Marcus On Apr 15, 2014, at 6:50 PM, Leif leif.p...@gmail.com wrote: @Jakub: Thanks for your kind words. I'm definitely no industry hero, but I hope Clojure devs of all levels start having more pair programming fun. @Tim: Clojurescript UI programming being way out of my comfort zone, I learned quite a lot from you yesterday. So thank you. @Everyone: To clarify / reiterate: You do not need a plan, a project, or a specific problem. If you want to work through Project Euler, 4clojure, clojure-koans, the ClojureBridge materials, some other clojure tutorial, or just play it by ear, I am happy to try it out. --Leif On Tuesday, April 15, 2014 8:00:17 AM UTC-4, frye wrote: I just came from an office hours session, yesterday with Leif. This is good stuff guys, and a great way to learn and meet with other developers. Highly recommended. Thanks Leif Tim Washington Interruptsoftware.com On Tue, Apr 15, 2014 at 5:12 AM, Jakub Holy jakub...@iterate.no wrote: Hi Leif, This is a great activity, thank you for contributing to the community this way! Do not be surprise and discouraged by the fact that the interest seems low. I have a similar
Re: Sliding Windows
We've had lots of luck with Narrator: https://github.com/ztellman/narrator It's got loads of powerful features, including realtime batch mode, integration with core.async and lamina, windows, functions, and recursive analyses. On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote: Hi Guys, I was looking for a very simple stream processing lib. We have some in clojure (lamina, meltdown, esper, eep). The simplest one was clojure werkz eep, but they don't provide sliding windows. I ender up writing this: http://paulosuzart.github.io/blog/2014/04/27/sliding-window-events-with-clojure/ And publishing this very small implementation using meltdown. https://github.com/paulosuzart/sw . It is enough for a very simple use case I have to deal. If anyone knows any other sliding window impl please share. Regards -- Paulo Suzart @paulosuzart -- 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.
Datascript and React.js for a Clojure web app
Hi all, I've released a Clojure web application. It includes a front-end using DataScript and React.js in ClojureScript. More details here: http://thegeez.net/2014/04/30/datascript_clojure_web_app.html The code is on github: https://github.com/thegeez/clj-crud Demo on heroku: http://clj-crud.herokuapp.com/ Best regards, Gijs -- 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: Proposing a new Clojure documentation system (in Clojure)
Tim, I am in full support of the approach to documentation that you describe, for individuals and organizations that feel that it best supports their needs. It's a good approach. I don't favor requiring an entire programming community to follow it. That's too much of an imposition. I do like the idea of more minimal norms for a community. Docstrings are a good start, but I can see the benefits of slightly more systematic norms or tools for (e.g.) docstrings, or references to more information. I think that it's a matter of degree. Minimal norms shouldn't require too much of programmers. It should be pretty obvious to any experienced programmer that such a norm will be worth following, and it should be easy to follow it. Maybe there should also be norms for more elaborate kinds of documentation for those organizations that want more elaborate kinds--that way, there will be some uniformity among such organizations. That might be the best of both worlds: An adequate minimal norm for documentation, with easy-to-use tool support, plus norms and tool support for extensions to the minimal norm. On Wednesday, April 30, 2014 2:09:04 AM UTC-5, da...@axiom-developer.org wrote: Imagine you're reading through some documentation and you notice a problem. Maybe a typo, or something out of date, or something that's confusing that you could explain better. In one scenario there's a git clone link in the sidebar to a repository that contains a bunch of markdown files. In another scenario there's an HTML rendering generated from a literate programming project where the prose is intermixed with the code and requires a specific version of org-mode and the knowledge of how to untangle something in order to render it. This is a focus on the technology which I'm reluctant to do, mostly because I have strong opinions about it. I will say from experience that any technology that separates code from explanation will fail. If we focus on what information we require and what structure has to be placed on that information so it can be understood THEN we can ask about the technologies and what they support. Can I ask, quite seriously and not intending any sarcasm, what you mean by detracts from what's important? For me, what's important is to communicate ideas, designs, and details from one developer to another so that others can maintain, modify, and extend what exists. I've already held forth on what I think that implies so I won't bore you with it. Consider Clojure's primary data structure implementation. It is basically an immutable, log32, red-black tree. For some people that is more than sufficient, especially if they have been working in the code base for years. For others, especially as a developer new to the project, there is a lot to know. Without this information it is very difficult to contribute. A new developer needs an introduction to the IDEA of immutable data structures with a reference to Okasaki's thesis which is online at http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf (a bibliography). A new developer needs to know that the DESIGN of Clojure relies on these immutable data structures so they don't introduce any quick and efficient hacks that violate the design. (a Clojure overview) A new developer needs to know WHAT a red-black tree is, WHY it was chosen, and HOW Clojure maps user-visible data structures to them. (the chapter on this particular data structure) A new developer needs to know the IMPLICATIONS of the choice of log32 since it defines the efficiency. (the design constraints section and the algorithmic analysis section) A new developer needs to know HOW to update a log32 immutable red-black tree. (a pseudocode explanation with pictures) A new developer needs to know HOW the log32 red-black tree is implemented. It is not immediately obvious how the 5-bit chunks are mapped into a 32 bit word. If the task was to re-implement it on a 64 bit word they'd have to know the details to understand the code. (the actual code with explanations of the variables) If the new developer's task is to modify the code for a 64 bit architecture they would need a way to find the code (the table of contents) and places where this information is mentioned (an index). All of the places where it is written need to be properly updated. Even if we focus strictly on what a new developer needs to know we end up with something that smells a lot like a book. From the above we see the need for 1) a bibliography 2) a Clojure overview 3) a chapter focus on this data structure 4) sections on design constraints and algorithmic analysis 5) a section of pseudocode with pictures 6) a section with code and details of the actual implementation 7) a table of contents 8) an index And that's only a few dozen lines of the Clojure source code. Now we
Re: Kwargs vs explicit parameter map for APIs?
We used kwargs for options extensively in Immutant 1.x, and we're moving to explicit maps for Immutant 2.x, for the reasons cited above. It's not obvious to me why the bad release-sharks example on the coding standards page [1] is bad. Why should the optional config be the least variance argument? I had to look up laudable, btw. It's one of those good words that sounds bad. :) [1] http://dev.clojure.org/display/community/Library+Coding+Standards On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming colin.mailingl...@gmail.comwrote: And thinking about it (after pressing send, of course), you'd get the same benefit from destructuring an explicit map in the function parameter anyway, wouldn't you? On 30 April 2014 22:11, Colin Fleming colin.mailingl...@gmail.com wrote: But that's only true for the variables which are explicitly destructured in the function definition, which in my experience many are not - they're often later picked out of an :as args argument, perhaps dependent on a combination of the parameters which are explicitly destructured. Seesaw never does this, for example. I think it's dangerous to rely on this rather than the documentation since it's often an incomplete view of what the function requires. Cheers, Colin On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.comwrote: my two cents: The extra readability to users when using keyword args also comes from the fact that a function's options are explicit in its signature. So during development, instead of having to look them up in the docs or in the code, my emacs mini-buffer simply shows them to me. Although I do agree with all the good reasons against keywords arguments, to me this is still the decisive reason to prefer them... Joachim Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves: On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote: I still think the keyword argument approach is far more readable to _users_ -- 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.
Re: Sliding Windows
Ow, exactly what I was looking for. Thanks a lot On 30 Apr 2014 10:26, dgrnbrg dsg123456...@gmail.com wrote: We've had lots of luck with Narrator: https://github.com/ztellman/narrator It's got loads of powerful features, including realtime batch mode, integration with core.async and lamina, windows, functions, and recursive analyses. On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote: Hi Guys, I was looking for a very simple stream processing lib. We have some in clojure (lamina, meltdown, esper, eep). The simplest one was clojure werkz eep, but they don't provide sliding windows. I ender up writing this: http://paulosuzart. github.io/blog/2014/04/27/sliding-window-events-with-clojure/ And publishing this very small implementation using meltdown. https://github.com/paulosuzart/sw . It is enough for a very simple use case I have to deal. If anyone knows any other sliding window impl please share. Regards -- Paulo Suzart @paulosuzart -- 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: Kwargs vs explicit parameter map for APIs?
Maybe they want config in the least variance argument so it can be partial'ed? On Wed, Apr 30, 2014 at 10:03 AM, Jim Crossley j...@crossleys.org wrote: We used kwargs for options extensively in Immutant 1.x, and we're moving to explicit maps for Immutant 2.x, for the reasons cited above. It's not obvious to me why the bad release-sharks example on the coding standards page [1] is bad. Why should the optional config be the least variance argument? I had to look up laudable, btw. It's one of those good words that sounds bad. :) [1] http://dev.clojure.org/display/community/Library+Coding+Standards On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming colin.mailingl...@gmail.com wrote: And thinking about it (after pressing send, of course), you'd get the same benefit from destructuring an explicit map in the function parameter anyway, wouldn't you? On 30 April 2014 22:11, Colin Fleming colin.mailingl...@gmail.comwrote: But that's only true for the variables which are explicitly destructured in the function definition, which in my experience many are not - they're often later picked out of an :as args argument, perhaps dependent on a combination of the parameters which are explicitly destructured. Seesaw never does this, for example. I think it's dangerous to rely on this rather than the documentation since it's often an incomplete view of what the function requires. Cheers, Colin On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.comwrote: my two cents: The extra readability to users when using keyword args also comes from the fact that a function's options are explicit in its signature. So during development, instead of having to look them up in the docs or in the code, my emacs mini-buffer simply shows them to me. Although I do agree with all the good reasons against keywords arguments, to me this is still the decisive reason to prefer them... Joachim Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves: On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote: I still think the keyword argument approach is far more readable to _users_ -- 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. -- 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.
Do not understand the - macro here
On 4 clojure there it this exercise: (= (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) 5) if I understand it right this is happen reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ] Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2] Sort this and you get [ 1 2 3 4 5] This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [ 1 2 3 4 5] what does the (__)) 5) does exactly. When I change the 5 to another number the outcome is not changed. And where does clojure put the first [ 1 2 3 4 5 ] in the second form ? Roelof -- 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: Proposing a new Clojure documentation system (in Clojure)
Valentin, et al, I'm a little late to the thread here, but I'm the author of lein-sphinx which you mentioned in your (well thought out) post so I thought I'd weigh in here. I agree with a lot of what you wrote in your proposal, and for many projects (not all of them, but many) there is an important role for documentation that is separate from code. Maybe there needs to be a chapter length explanation of system X that your library is intending to interact with system X before the code (and docstrings) even make any sense to someone new to the codebase. You're going to put all that content in the code in doc strings? No. Maybe you put it in Markdown and let GitHub render it, but even with GH's proprietary extensions of MD, it's limited when compared to something like Sphinx and reStructured Text. So that's where something like lein-sphinx comes in, and I built that simply as a necessary evil. I'm not a big Python guy, or a fan of reStructured Text or Sphinx, but I felt there was nothing equivalent for building up real substantial docs in Clojure. I have some specific thoughts on your proposal are below: I've been thinking for a while that the Clojure community could benefit a lot from a more sophisticated and ergonomic documentation system. I would have said usable, but I love your choice of ergonomic here to describe software. I think usability is a bit of an overused word that's lost some of its power. I'm going to steal this and start using ergonomic. Thanks! I have seen some existing plugins like lein-sphinx, but I think it would be really good to have documentation that would be written in Clojure, for the following reasons : - we're all very fond of Clojure data structures and their syntax. (I don't know about you, but I find that even HTML looks better in Clojurehttps://github.com/weavejester/hiccupthan in HTML). Plus, Clojure programmers already know how to edit them. hmmm... I like that we could use Clojure syntax to describe Clojure syntax and Clojure data structures. I'm not so sure I'm so fond of Clojure syntax that I want to use it for sentences. And I don't think HTML looks better in Clojure, there's a lot of really nasty HTML out there. Nasty HTML looks nasty in Clojure too, and nice HTML looks better in HTML than in Clojure. - (better reason) The facts that Vars are first-class citizens and that symbols can be referred explicitly with hardly any ceremony (macros) are a exceptional opportunity to make smart and highly-structured documentation very easily. mmk. - if it's in Clojure, Clojure programmers can seamlessly build *ad hoc*documentation functionality on top of it to suit their own particular needs. I like this reason. I haven't found anything of the like yet, and if it exists, I would be grateful if someone would redirect me to it. It doesn't exist unless someone has built it internally and is keeping it for themselves (not likely). Fergal's suggestion of lein-midje-doc is probably the closest. Here are *my thoughts on this :* 1. Clojure doc-strings, although they are quite handy as reminders and for doc-indexation, are *too raw a content*. Even when they are done right, they tend to be cumbersome, and it's too bad to have such concise code drown in the middle of so much documentation. What's more, I believe that when programmers program a function (or anything), they tend to think more about the implementation than the (uninformed) usage, so they have little incentive to make it right. I think doc strings are necessary, but not sufficient. I think there *is*a role for documentation in the code, otherwise you end up duplicating documentation in the separate docs and docstrings, or in comments, so a Clojure documentation framework/solution probably out to be able to make use of doc strings by pulling out their content. It ought to also pull out things like :pre and :post. It ought to use the code to make writing the docs as easy and boilerplate free as possible. But again, when you need a lot of docs, tutorials, etc. putting that stuff directly in the code is a mess. 1. Building on 1. having a system where documentation and programs live in separate files, in the same way as tests, would enforce a healthy separation of concerns. Importantly, it would make life much easier on the Version Control perspective. Yes. And just how tests refer back to the code they are testing. I think docs need to be able to refer back to the vars/atoms/functions/doc strings etc. of the code they are documenting. 1. Documentation should probably be made differently than what people have got accustomed to by classical languages. Because you seldom find types, and because IMHO Clojure programs are formed more by factoring out recurring mechanisms in code than from implementing intellectual abstractions, the
require and jtransforms
I would like to try the JTransforms Java FFT library from Clojure: https://sites.google.com/site/piotrwendykier/software/jtransforms I created a new folder went to that folder in a console and typed lein try net.sourceforge.jtransforms/jtransforms 2.4.0 lein try retrieved some jars and poms from central, presumably jtransforms and its dependencies and started a REPL. Having got this far I can't seem to figure out how to require jtransforms in the REPL. I have tried (require '[x :as trans]) for various values of x such as net.sourceforge.jtransforms/jtransforms and net.sourceforge.jtransforms.jtransforms, jtransforms.jtransforms and the REPL keeps saying FileNotFoundException Could not locate jtranforms__init.class or jtransforms.clj on classpath: clojure.lang.RT.load (RT.java:443) I think I must be misunderstanding how to download libraries and their dependencies or how to require them when they have been downloaded. Can anybody shed some light on this for me? Thanks, Alan -- 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: Do not understand the - macro here
You have to replace the underscore with a function. The value of (= (_ [1 2 3 4 5]) 5) must be true. So the value of (_ [1 2 3 4 5]) must be 5. So the function you are looking for will have to return the last element of the array. On Wednesday, April 30, 2014 5:28:26 PM UTC+2, Roelof Wobben wrote: On 4 clojure there it this exercise: (= (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) 5) if I understand it right this is happen reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ] Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2] Sort this and you get [ 1 2 3 4 5] This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [ 1 2 3 4 5] what does the (__)) 5) does exactly. When I change the 5 to another number the outcome is not changed. And where does clojure put the first [ 1 2 3 4 5 ] in the second form ? Roelof -- 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: Example of using ANTLR from Clojure?
Thank you very much. This definitely helps. -Kranthi On Sat, Apr 26, 2014 at 9:17 PM, Armando Blancas abm221...@gmail.comwrote: I haven't touched this project in a while, but it might be useful. https://github.com/blancas/tinypost This file has the relevant interop code: src/main/clojure/blancas/tinypost/scan.clj On Saturday, April 26, 2014 3:04:50 AM UTC-7, Kranthi Rajoli wrote: Hi Paul, Do you mind outlining the method you used? I am exactly looking for the same. My Java skills are pathetic too. Thanks, Kras On Wednesday, September 9, 2009 4:17:07 AM UTC+5:30, Paul Henning wrote: Thanks for the information. Once I bit the bullet and learned a bit of Java, it was actually pretty easy to call ANTLR from clojure, after getting all the package naming figured out. Paul On Sep 6, 6:22 am, Laurent PETIT laurent.pe...@gmail.com wrote: 2009/9/5 Mike Hinchey hinche...@gmail.com I don't know anything about it, but counterclockwise uses antlr. http://groups.google.com/group/clojuredev-devel/browse_ thread/thread/... That's true. To be more precise, we have a clojure lexer which is extensively used in Counterclockwise clojure source editor for syntax coloration. There is also the lexer part but it was developed a long time ago (so may not be still accurate), and is not used yet (so maybe the way the AST is constructed is nood in the good shape for most purpose). But to come back to your concern of using antlr from clojure : no, Counterclockwise is not yet written in clojure (just the client/server part for communicating with running projects instances) and so you wil not be able to find examples for that, sorry :-( -- Laurent -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/vdUGQRwDYWo/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kranthi Rajoli -- 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: Do not understand the - macro here
It looks like a quiz. Which function should stand in place of underscores to give 5 in result? On Wed, Apr 30, 2014 at 7:28 PM, Roelof Wobben rwob...@hotmail.com wrote: On 4 clojure there it this exercise: (= (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) 5) if I understand it right this is happen reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ] Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2] Sort this and you get [ 1 2 3 4 5] This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [ 1 2 3 4 5] what does the (__)) 5) does exactly. When I change the 5 to another number the outcome is not changed. And where does clojure put the first [ 1 2 3 4 5 ] in the second form ? Roelof -- 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: require and jtransforms
Java libraries are handled differently to native Clojure libraries. You can either enter the full class with packages, such as: (java.util.UUID/randomUUID) Or you can use import to access the class without the package: (import 'java.util.UUID) (UUID/randomUUID) To check you have access to the java library, try entering the following class name at the REPL: edu.emory.mathcs.jtransforms.fft.DoubleFFT_1D If the library is loaded, this should return a class object, rather than erroring. - James On 30 April 2014 16:40, Alan Forrester alanmichaelforres...@googlemail.comwrote: I would like to try the JTransforms Java FFT library from Clojure: https://sites.google.com/site/piotrwendykier/software/jtransforms I created a new folder went to that folder in a console and typed lein try net.sourceforge.jtransforms/jtransforms 2.4.0 lein try retrieved some jars and poms from central, presumably jtransforms and its dependencies and started a REPL. Having got this far I can't seem to figure out how to require jtransforms in the REPL. I have tried (require '[x :as trans]) for various values of x such as net.sourceforge.jtransforms/jtransforms and net.sourceforge.jtransforms.jtransforms, jtransforms.jtransforms and the REPL keeps saying FileNotFoundException Could not locate jtranforms__init.class or jtransforms.clj on classpath: clojure.lang.RT.load (RT.java:443) I think I must be misunderstanding how to download libraries and their dependencies or how to require them when they have been downloaded. Can anybody shed some light on this for me? Thanks, Alan -- 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: require and jtransforms
Hi, Alan. 'require' is only for clojure libs. For Java packages, use 'import': user= (import '[edu.emory.mathcs.jtransforms.fft DoubleFFT_1D]) edu.emory.mathcs.jtransforms.fft.DoubleFFT_1D user= (def da (double-array (range 0 10 0.01))) #'user/da user= (def fft (DoubleFFT_1D. (count da))) #'user/fft user= (.realForward fft da) ;; operates in-place Reflection warning, /tmp/form-init1030205091778006036.clj:1:9 - call to realForward can't be resolved. user= (first da) 5004.9934 Also, as you may already be aware, the Maven coordinates and the Java package names are not necessarily the same or even similar. --Leif On Wednesday, April 30, 2014 11:40:31 AM UTC-4, Alan Forrester wrote: I would like to try the JTransforms Java FFT library from Clojure: https://sites.google.com/site/piotrwendykier/software/jtransforms I created a new folder went to that folder in a console and typed lein try net.sourceforge.jtransforms/jtransforms 2.4.0 lein try retrieved some jars and poms from central, presumably jtransforms and its dependencies and started a REPL. Having got this far I can't seem to figure out how to require jtransforms in the REPL. I have tried (require '[x :as trans]) for various values of x such as net.sourceforge.jtransforms/jtransforms and net.sourceforge.jtransforms.jtransforms, jtransforms.jtransforms and the REPL keeps saying FileNotFoundException Could not locate jtranforms__init.class or jtransforms.clj on classpath: clojure.lang.RT.load (RT.java:443) I think I must be misunderstanding how to download libraries and their dependencies or how to require them when they have been downloaded. Can anybody shed some light on this for me? Thanks, Alan -- 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: Do not understand the - macro here
These two forms are equivalent: (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) The - macro turns the second form into the first. You can see this by running macroexpand-all: (require '[clojure.walk :refer [macroexpand-all]]) (macroexpand-all '(- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))) This should produce: (__ (sort (rest (reverse [2 5 4 1 3 6] - James On 30 April 2014 16:28, Roelof Wobben rwob...@hotmail.com wrote: On 4 clojure there it this exercise: (= (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) 5) if I understand it right this is happen reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ] Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2] Sort this and you get [ 1 2 3 4 5] This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [ 1 2 3 4 5] what does the (__)) 5) does exactly. When I change the 5 to another number the outcome is not changed. And where does clojure put the first [ 1 2 3 4 5 ] in the second form ? Roelof -- 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: Do not understand the - macro here
Op woensdag 30 april 2014 18:46:36 UTC+2 schreef James Reeves: These two forms are equivalent: (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) The - macro turns the second form into the first. You can see this by running macroexpand-all: (require '[clojure.walk :refer [macroexpand-all]]) (macroexpand-all '(- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))) This should produce: (__ (sort (rest (reverse [2 5 4 1 3 6] - James That what I expected. what is the benefit of this if the first forms already gives the right answer. The only thing I still do not see is what the 5) is doing here. It looks to me of writing something very difficult where it could be done very easy with just the first form. Roelof -- 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: Do not understand the - macro here
Op woensdag 30 april 2014 19:12:24 UTC+2 schreef James Reeves: The 5 is just the last part of the equality statement. This might be easier to see by adding in a let: (let [x (__ (sort (rest (reverse [2 5 4 1 3 6] y (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))] (= x y 5)) - James Sorry I still do not see it If I understand it right it will be like this (let [x (__ [ 1 2 3 4 5] y (- [ 1 2 3 4 5] (= [1 2 3 4 5] [ 1 2 3 4 5] 5)) it still looks very wierd to me Roelof -- 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: Do not understand the - macro here
The 5 is just the last part of the equality statement. This might be easier to see by adding in a let: (let [x (__ (sort (rest (reverse [2 5 4 1 3 6] y (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))] (= x y 5)) - James On 30 April 2014 18:09, Roelof Wobben rwob...@hotmail.com wrote: Op woensdag 30 april 2014 18:46:36 UTC+2 schreef James Reeves: These two forms are equivalent: (__ (sort (rest (reverse [2 5 4 1 3 6] (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__)) The - macro turns the second form into the first. You can see this by running macroexpand-all: (require '[clojure.walk :refer [macroexpand-all]]) (macroexpand-all '(- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))) This should produce: (__ (sort (rest (reverse [2 5 4 1 3 6] - James That what I expected. what is the benefit of this if the first forms already gives the right answer. The only thing I still do not see is what the 5) is doing here. It looks to me of writing something very difficult where it could be done very easy with just the first form. Roelof -- 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: Do not understand the - macro here
The __ needs to be replaced with a function. So essentially it boils down to: (= (__ [1 2 3 4 5]) 5) What function when called with [1 2 3 4 5] returns 5? - James On 30 April 2014 18:18, Roelof Wobben rwob...@hotmail.com wrote: Op woensdag 30 april 2014 19:12:24 UTC+2 schreef James Reeves: The 5 is just the last part of the equality statement. This might be easier to see by adding in a let: (let [x (__ (sort (rest (reverse [2 5 4 1 3 6] y (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))] (= x y 5)) - James Sorry I still do not see it If I understand it right it will be like this (let [x (__ [ 1 2 3 4 5] y (- [ 1 2 3 4 5] (= [1 2 3 4 5] [ 1 2 3 4 5] 5)) it still looks very wierd to me Roelof -- 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: Do not understand the - macro here
Op woensdag 30 april 2014 19:46:41 UTC+2 schreef James Reeves: The __ needs to be replaced with a function. So essentially it boils down to: (= (__ [1 2 3 4 5]) 5) What function when called with [1 2 3 4 5] returns 5? - James Thats a easy one . That is last. But what I try to find out and do not understand is how it boils down to that question. Why make a difficult thing if you could also write down the question that you have asked. Roelof On 30 April 2014 18:18, Roelof Wobben rwo...@hotmail.com javascript:wrote: Op woensdag 30 april 2014 19:12:24 UTC+2 schreef James Reeves: The 5 is just the last part of the equality statement. This might be easier to see by adding in a let: (let [x (__ (sort (rest (reverse [2 5 4 1 3 6] y (- [2 5 4 1 3 6] (reverse) (rest) (sort) (__))] (= x y 5)) - James Sorry I still do not see it If I understand it right it will be like this (let [x (__ [ 1 2 3 4 5] y (- [ 1 2 3 4 5] (= [1 2 3 4 5] [ 1 2 3 4 5] 5)) it still looks very wierd to me Roelof -- 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: Proposing a new Clojure documentation system (in Clojure)
On Tue, Apr 29, 2014 at 7:44 PM, Phil Hagelberg p...@hagelb.org wrote: On Saturday, April 26, 2014 9:21:26 PM UTC-7, Mars0i wrote: I like the general idea of the Valentin's proposal, but I don't understand every bit of it. It sounds complicated. Personally, I'd rather see something that's relatively simple, and good enough, than something that's perfect but unwieldy. If it's too difficult, people won't use it, or they'll waste time, or feel that the Clojure community expects them to spend too much time on something that detracts from what's important. Double-inc[1] on this. Clojure needs people who care about documentation far more than it needs another documentation system. Don't try to apply a technical solution to a social problem. Double-dog dinc. Having followed this thread I hazard a few reminders of the obvious. Code *is* documentation. Programmers don't like to write documentation - it's hard enough to write good code, and then you want me to translate my code into clear simple concise English? (Are you nuts? Learn to read code!) Writing good documentation and writing good code are distinct skills that are very rarely found in a single person. Good documentation is expensive. Good means good enough. Less obvious: there are at least two distinct notions of documentation in play. One is the code: self-documenting documentation. The other is arguably meta-documentation: English (usually) prose *about* the code - which means, about the self-documenting documentation. Controversial: literate programming is a bad, bad, bad idea. There is a reason it has never caught on. Ever try to hack Tex? Did Knuth's literate code help? Maybe; but people routinely tackle systems that are just as complex without the added burden of tangle and weave, etc. Many years ago I had to do maintenance work on a banking system written entirely in S/370 assembler. It was a pain, but it was doable. Literate programming would have made it far worse, in my opinion. Would it be easier to hack TeX if it had been written without the lit prog cruft? In my view the answer is (probably) yes. (Note that, until relatively recently, (XeTeX and LuaTex) there was almost no work that built on TeX to make new stuff - which is what Knuth had hoped for.) But the more critical point is that TeX was (mostly) a one-man show. Literate programming fine for that, but is utterly, irredeemably, terminally unsuitable for the sorts of projects that work in the open source world - lots of different people, scratching lots of different itches, with lots of different opinions about the Way the World Ought To Work. I can see no reason to think that literate code is in any way immune to the problems that inevitably afflict any successful software project - bitrot, feature creep, over-engineering, under-specification, gradual divergence between descriptions of the system and what it actually does, pressure to just make the damn thing work (as opposed to doing it right), etc. etc. etc. My heart sinks whenever I see a project that looks good but is implemented in literate programming. If I really like it and want to bang on it, the first thing I will do is terminate the literate stuff with extreme prejudice - give me the code, please, and the minimal amount of local commenting. I'll read the literate docs, but will never code the stuff. The one thing that I think would be genuinely useful and developer friendly with respect to Clojure is a means of making type signatures explicit. Clojure may be dynamically typed, but everything has an intended type, and I would like to see it. I'm thinking of something along the way Haskell and other languages express type sigs. The paradigmatic example is factorial (or fibonacci). So given a factorial function fact I want to be able to write something like (type-sig fact) and get something like Int - Int. -Gregg -- 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: Kwargs vs explicit parameter map for APIs?
Granted, but the word bad seems harsh without any explanation, especially if the common usage is to pass an empty map. On Wed, Apr 30, 2014 at 11:18 AM, Alex Robbins alexander.j.robb...@gmail.com wrote: Maybe they want config in the least variance argument so it can be partial'ed? On Wed, Apr 30, 2014 at 10:03 AM, Jim Crossley j...@crossleys.org wrote: We used kwargs for options extensively in Immutant 1.x, and we're moving to explicit maps for Immutant 2.x, for the reasons cited above. It's not obvious to me why the bad release-sharks example on the coding standards page [1] is bad. Why should the optional config be the least variance argument? I had to look up laudable, btw. It's one of those good words that sounds bad. :) [1] http://dev.clojure.org/display/community/Library+Coding+Standards On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming colin.mailingl...@gmail.com wrote: And thinking about it (after pressing send, of course), you'd get the same benefit from destructuring an explicit map in the function parameter anyway, wouldn't you? On 30 April 2014 22:11, Colin Fleming colin.mailingl...@gmail.comwrote: But that's only true for the variables which are explicitly destructured in the function definition, which in my experience many are not - they're often later picked out of an :as args argument, perhaps dependent on a combination of the parameters which are explicitly destructured. Seesaw never does this, for example. I think it's dangerous to rely on this rather than the documentation since it's often an incomplete view of what the function requires. Cheers, Colin On 30 April 2014 21:03, Joachim De Beule joachim.de.be...@gmail.comwrote: my two cents: The extra readability to users when using keyword args also comes from the fact that a function's options are explicit in its signature. So during development, instead of having to look them up in the docs or in the code, my emacs mini-buffer simply shows them to me. Although I do agree with all the good reasons against keywords arguments, to me this is still the decisive reason to prefer them... Joachim Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves: On 30 April 2014 03:54, Sean Corfield se...@corfield.org wrote: I still think the keyword argument approach is far more readable to _users_ -- 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. -- 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
Re: Proposing a new Clojure documentation system (in Clojure)
On Wednesday, 30 April 2014 19:03:24 UTC+1, Gregg Reynolds wrote: The one thing that I think would be genuinely useful and developer friendly with respect to Clojure is a means of making type signatures explicit. Clojure may be dynamically typed, but everything has an intended type, and I would like to see it. I'm thinking of something along the way Haskell and other languages express type sigs. The paradigmatic example is factorial (or fibonacci). So given a factorial function fact I want to be able to write something like (type-sig fact) and get something like Int - Int. (I think someone might have mentioned it above, but it doesn't hurt to repeat) you might like schema https://github.com/Prismatic/schema/ . Jony -- 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.
browser repl for clojurescript with counterclockwise
Hi, Is it possible to have a browser based repl for clojurescript with counterclockwise? I tried to set up one as described on the clojurescript site, but my impression was that ccw is not able to send forms for evaluation. Cheers, Razvan -- 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.
[ANN] packthread 0.1.0
packthread
Threading macros for working with globs of state.
https://github.com/maitria/packthread/blob/master/README.md#whyWhy?
Many descriptions about state in Clojure fit into the following form:
State is hard to reason about, and so we use pure functions in Clojure. But
then we have a problem, we need to pass around *all*the application's
state. And that's just too hard, and it's basically just like having all
the global variables anyway, and you've coupled every function in the
system to this big ball of mud. So we need to separate it out and
encapsulate and therefore we've invented $library which does *x*, where *x* ∈
{*OO programming*, *global mutable state*, *...*}.
Packthread is different.
Packthread is for threading state through programs in a simple, composable
way. It does not compromise the ability to be functionally pure or reason
about one's program. It's pretty similar to the - and - macros, with a
helper macro named in for creating different *projections* of the state to
manipulate with different functions.
https://github.com/maitria/packthread/blob/master/README.md#+
Threads value through forms in much the same way as -, except for special
handling of the following forms:
https://github.com/maitria/packthread/blob/master/README.md#if-if-not-if-let-when-when-not-when-letif,
if-not, if-let, when, when-not, when-let:
The value is threaded through the then and else clauses independently,
leaving the test conditions alone. If an else clause is missing, it is will
be supplied as though the value had been threaded through identity in that
case.
For example,
(+ 42 (if true inc)) ;= 43(+ 42 (if false inc)) ;= 42
In when, when-not, and when-let forms, the value is threaded through each
form in the body, not just the last.
https://github.com/maitria/packthread/blob/master/README.md#condcond
The test clauses are left untouched and the value is threaded through the
expr clauses of each condition. If no :else condition was supplied, + pretends
as though it has been (identity), and threads the value through that.
For example,
(+ 42
(cond
(= 1 2)
inc)) ;= 42
(+ 42
(cond
(= 1 1)
dec)) ;= 41
https://github.com/maitria/packthread/blob/master/README.md#dodo
The current expr is threaded through the body forms of the do.
https://github.com/maitria/packthread/blob/master/README.md#inin
Threads the inner expressions through a projection of value.
projector is a function which takes two arguments: a value and a function.
It should apply the function to a *projection* of the value, take the
function's result, and reassemble from that result a value which can be
used again in the outer context.
For example,
(+ 42
(in (fn [v f]
(* 2 (f (/ v 2
inc)) ;= 42.5
This can be thought of as 'lifting' the body expressions into the 'world
where things are twice as large'.
As a special case, if projector is a keyword, in assumes that value is a
map and that sub-key are threaded through the inner expressions.
For example,
(+ {:hello 42}
(in :hello
(+ 5))) ;= {:hello 47}
This macro can only be used inside + or +.
https://github.com/maitria/packthread/blob/master/README.md#-1+
Threads expressions like -, except with the handling of the special forms
above.
https://github.com/maitria/packthread/blob/master/README.md#installing
Installing
Leiningen http://github.com/technomancy/leiningen/ dependency information:
[com.maitria/packthread 0.1.0]
https://github.com/maitria/packthread/blob/master/README.md#usageUsage
(require '[packthread.core :refer :all])
(+ 42
(if true
inc)) ;= 43
See
core_test.cljhttps://github.com/maitria/packthread/blob/master/test/packthread/core_test.clj
for
examples of usage.
https://github.com/maitria/packthread/blob/master/README.md#licenseLicense
Copyright 2014 Maitria
You have permission to use this in any way you like (modify it, sell it,
republish it), provided you agree to all the following conditions:
- you don't mislead anyone about it
- you don't interfere with our ability to use it
- you release us from any claims of liability if it causes problems for
you
--
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: testing clojure.core/group-by with clojure.test.check
The only hard parts about property based testing are the properties and the generators. ;) On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. those seem good so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? You don't seem to be leveraging the possibilities of the grouping function. If you create a grouping function that maps many random values into a small number of groups, then everything may get easier. Some candidate functions: first character of the keyword, length of the keyword, etc. Or working backwards is often useful with a generator - generate the grouping values first, then use the inverse of the grouping function to generate data that maps to that group and populate the input with that. as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. 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: testing clojure.core/group-by with clojure.test.check
As an aside to the discussion at hand, what papers/books/online articles are good to read to learn about how to come up with good properties and generators? On Wed, Apr 30, 2014 at 3:36 PM, Alex Miller a...@puredanger.com wrote: The only hard parts about property based testing are the properties and the generators. ;) On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. those seem good so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? You don't seem to be leveraging the possibilities of the grouping function. If you create a grouping function that maps many random values into a small number of groups, then everything may get easier. Some candidate functions: first character of the keyword, length of the keyword, etc. Or working backwards is often useful with a generator - generate the grouping values first, then use the inverse of the grouping function to generate data that maps to that group and populate the input with that. as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. 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.
Managing State Changes, using Component
Hi all,
I'm having a weird state problem with
Componenthttps://github.com/stuartsierra/component.
Let's say I have a system component, like in fig.1. Starting / stopping and
loading state is fine.
However, let's say I have 2 other components (:updater , :reader) that use
component :a. This is the problem that occurs.
1. When *:updater*, modifies an atom in *:a*, that change appears in
path [*:core :a*], not path [*:updater :a*] or [*:a*].
2. Because of the abouve, when *:reader* goes to it's local path [
*:reader :a*] to read that change, it doesn't see those modifications.
3. Using this scheme, *:a* is duplicated 4 times, in the system map.
However, the modifications only appear in path [*:core :a*]. Thus
:reader is unable to access it (it's local [*:a*] is unchanged).
(def system-components [:a :updater :reader])
(defrecord Core [env] component/Lifecycle
(start [this] ...)
(stop [this] ...))
(defn component-core [env]
(component/system-map
:a (component/using
(ca/component-a env)
{})
:updater (component/using
(cs/component-updater env)
{:a :a})
:reader(component/using
(cs/component-reader env)
{:a :a})
:core (component/using
(map-Foobar {:env env})
{:a :a
:updater :updater
:reader :reader })))
*fig.1 *
I was hoping to use Component to manage all internal application state. But
maybe it's not designed for this use case (state changes between
components). I imagine that immutability is preventing all those duplicates
from seeing the modifications. However, in this case I do need an update to
:a in one component, to be accessed by another component.
Any suggestions on patterns here? I'm also looking at
component/update-systemhttps://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj#L116.
But again, I don't have access to the core *system* var, from within my
components.
Any insights appreciated
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Sliding Windows
Humm. Actually narretor flushes all messages. Still not what I'm looking for somethiing like this: http://docs.oracle.com/cd/E13157_01/wlevs/docs30/epl_guide/overview.html(see the images). Thanks anyway On 30 April 2014 12:15, Paulo Suzart paulosuz...@gmail.com wrote: Ow, exactly what I was looking for. Thanks a lot On 30 Apr 2014 10:26, dgrnbrg dsg123456...@gmail.com wrote: We've had lots of luck with Narrator: https://github.com/ztellman/narrator It's got loads of powerful features, including realtime batch mode, integration with core.async and lamina, windows, functions, and recursive analyses. On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote: Hi Guys, I was looking for a very simple stream processing lib. We have some in clojure (lamina, meltdown, esper, eep). The simplest one was clojure werkz eep, but they don't provide sliding windows. I ender up writing this: http://paulosuzart. github.io/blog/2014/04/27/sliding-window-events-with-clojure/ And publishing this very small implementation using meltdown. https://github.com/paulosuzart/sw . It is enough for a very simple use case I have to deal. If anyone knows any other sliding window impl please share. Regards -- Paulo Suzart @paulosuzart -- 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. -- Paulo Suzart @paulosuzart -- 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: Proposing a new Clojure documentation system (in Clojure)
On Apr 30, 2014, at 11:03 AM, Gregg Reynolds d...@mobileink.com wrote: Controversial: literate programming is a bad, bad, bad idea. There is a reason it has never caught on. I was going to stay out of this discussion but... I agree with Gregg here. All that prose just gets in the way and inhibits the largest portion of software development: maintenance. Sure, it's great in theory to have all that documentation right there when you're first learning a code base, but then it just gets in the way - and you're still not guaranteed that any maintenance that is done will keep the (extensive) documentation up to date. Most programmers just don't work well with prose - neither at reading it nor writing it. I think Clojure's docstrings are a great compromise: something built into the language for each file (namespace) and each var and function. I wish docstrings could be added to some other constructs (defmethod, in particular, but also the pure Java definterface / defrecord / deftype stuff). Short, clear docstrings and well-structured code with well-named symbols short provide enough information for maintenance. Rationale, concepts and extensive examples belong outside the code for that first use scenario, IMO. The one thing that I think would be genuinely useful and developer friendly with respect to Clojure is a means of making type signatures explicit. Clojure may be dynamically typed, but everything has an intended type, and I would like to see it. I'm thinking of something along the way Haskell and other languages express type sigs. The paradigmatic example is factorial (or fibonacci). So given a factorial function fact I want to be able to write something like (type-sig fact) and get something like Int - Int. Having used core.typed at work, I'll posit that type inference on most Clojure code won't actually tell you a lot. The inferred types would be pretty general. Even when adding annotations (for core.typed's analysis), it's sometimes surprisingly hard to crank down the type signatures and still get everything to type check: you often need either much more general types than you might wish for or you end up with complex union types, partly due to nil-punning and Clojure's view of truthy / falsey. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Proposing a new Clojure documentation system (in Clojure)
On Apr 29, 2014, at 9:42 PM, Atamert Ölçgen mu...@muhuk.com wrote: Since I don't use emacs, I would probably have found the former easier. I don't think Emacs has anything to do with this, even tho' Phil used the example of org-mode etc. I agree that if working on the code - and keeping the copious documentation in sync - requires anything more than a simple text editor, it's going to create obstacles to the workflow. For a project that has its auxiliary documentation on a Github wiki, you don't even need to git clone edit the repo: you can simply click Edit Page. That's about a low a barrier to entry as there can be and we still don't see enough contribution to documentation. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Kwargs vs explicit parameter map for APIs?
On Apr 30, 2014, at 8:03 AM, Jim Crossley j...@crossleys.org wrote: It's not obvious to me why the bad release-sharks example on the coding standards page [1] is bad. Why should the optional config be the least variance argument? I had to look up laudable, btw. It's one of those good words that sounds bad. :) [1] http://dev.clojure.org/display/community/Library+Coding+Standards Well, that's a very recent change. Stuart Halloway's version has been the standard for years. Reid made those changes only a few days ago - and I saw no discussion of the proposed changes so I'd like to hear from Cognitect's folks about this: is it a change of heart by Clojure/core or are they unaware of the change? Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Kwargs vs explicit parameter map for APIs?
I think they're unaware of the change, as it resulted from a recent
conversation on IRC that same day, where sentiment indicated that kwargs
are generally more trouble than they're worth and there's still confusion
around it.
What started it: the example of keys-destructuring on a list in a let
binding, very odd to explain.
(let [{:keys [a b c]} '(:a 1 :b 2 :c 3)]
[a b c])
[1 2 3]
On Wed, Apr 30, 2014 at 5:53 PM, Sean Corfield s...@corfield.org wrote:
On Apr 30, 2014, at 8:03 AM, Jim Crossley j...@crossleys.org wrote:
It's not obvious to me why the bad release-sharks example on the coding
standards page [1] is bad. Why should the optional config be the least
variance argument?
I had to look up laudable, btw. It's one of those good words that sounds
bad. :)
[1] http://dev.clojure.org/display/community/Library+Coding+Standards
Well, that's a very recent change. Stuart Halloway's version has been the
standard for years. Reid made those changes only a few days ago - and I saw
no discussion of the proposed changes so I'd like to hear from Cognitect's
folks about this: is it a change of heart by Clojure/core or are they
unaware of the change?
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
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: Sliding Windows
Since you already like clojurewerkz EEP, why not just add a time-sliding window to it? --Leif On Wednesday, April 30, 2014 5:13:42 PM UTC-4, Paulo Suzart wrote: Humm. Actually narretor flushes all messages. Still not what I'm looking for somethiing like this: http://docs.oracle.com/cd/E13157_01/wlevs/docs30/epl_guide/overview.html(see the images). Thanks anyway On 30 April 2014 12:15, Paulo Suzart paulo...@gmail.com javascript:wrote: Ow, exactly what I was looking for. Thanks a lot On 30 Apr 2014 10:26, dgrnbrg dsg123...@gmail.com javascript: wrote: We've had lots of luck with Narrator: https://github.com/ztellman/narrator It's got loads of powerful features, including realtime batch mode, integration with core.async and lamina, windows, functions, and recursive analyses. On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote: Hi Guys, I was looking for a very simple stream processing lib. We have some in clojure (lamina, meltdown, esper, eep). The simplest one was clojure werkz eep, but they don't provide sliding windows. I ender up writing this: http://paulosuzart. github.io/blog/2014/04/27/sliding-window-events-with-clojure/ And publishing this very small implementation using meltdown. https://github.com/paulosuzart/sw . It is enough for a very simple use case I have to deal. If anyone knows any other sliding window impl please share. Regards -- Paulo Suzart @paulosuzart -- 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/d/optout. -- Paulo Suzart @paulosuzart -- 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: testing clojure.core/group-by with clojure.test.check
Some good links here: https://github.com/clojure/test.check But related communities like QuickCheck, ScalaCheck, etc are probably good places to look. Someone should start making something great for test.check on the wiki: https://github.com/clojure/test.check Hint hint hint! On Wednesday, April 30, 2014 3:10:34 PM UTC-5, Tim Visher wrote: As an aside to the discussion at hand, what papers/books/online articles are good to read to learn about how to come up with good properties and generators? On Wed, Apr 30, 2014 at 3:36 PM, Alex Miller al...@puredanger.comjavascript: wrote: The only hard parts about property based testing are the properties and the generators. ;) On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. those seem good so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? You don't seem to be leveraging the possibilities of the grouping function. If you create a grouping function that maps many random values into a small number of groups, then everything may get easier. Some candidate functions: first character of the keyword, length of the keyword, etc. Or working backwards is often useful with a generator - generate the grouping values first, then use the inverse of the grouping function to generate data that maps to that group and populate the input with that. as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- 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/d/optout. -- You received this message because you are subscribed to the
Re: Proposing a new Clojure documentation system (in Clojure)
Sorry I have been late to react to all this, since I'm the one who started it all. First, *as a side note* : I have nothing against docstrings. I acknowledge their benefits, I think we should keep using them and I enjoy them every day like all of you. My point was just that they were not enough for all documentation, I probably wasn't very clear on that. Stop shooting :) @Fergal : thanks for such a great tour. It seems I have a lot of catching up to do before I have a keen understanding of the currently existing options. Nevertheless, I'll try to make a relevant contribution to the discussion. Given some of the answers, I'd like as a precaution emphasize the fact that I'm not trying to sell you a documentation system nor impose a dogma. My intent in proposing these approximative features was that, through some refining, some proposing and some discarding, the discussion will converge to a precise idea of what we want for documentation and how we should do it. As for what Gregg and Sean objected - that Clojure code is self-sufficient as documenting itself - I have to simply disagree. I do not want to have a theoretical discussion on this, because I think it's pointless; it is an empirical observation to me that foreign Clojure code tends to be difficult to understand. I have felt that pain, many times and despite all my stubbornness, which is why I finally posted here. I I'm the only one, please tell me. I think it is very important to raise the awareness of all Clojure programmers, especially library authors, that there is a significant asymmetry of information here : namely, it's easier than ever to go from intent to code, and much harder to go the way back. I see it at work when I edit my own code too : the programs seem to organize themselves naturally as I write them, sometimes in such a mechanical way that I have difficulties finding names for the abstractions I program, and I do get a crystal-clear understanding of them; but I'm quite sure that it would be very obscure to me if I had not witnessed the process. Try to make a Ring middleware or a monad self-explanatory with just code and a schema. Undoubtedly, library authors will feel this duty of documentation like a hinderance. I believe this is a necessary tradeoff to make. Besides, if you're code changes so fast that documentation quickly becomes obsolete, isn't that a sign that your API isn't ready to be exported? Anyway, I think speculating about the necessity of such a documentation system is not the best thing to do - I suggest we give it a try, and then everyone can decide for themselves if it's useful. After all, it's in Clojure, so this should not take too long, right ? ;) samedi 26 avril 2014 18:39:04 UTC+2, Val Waeselynck a écrit : Hello to all, *Short version :* I think Clojure needs a documentation system in Clojure, I would like to know if some efforts exist in that direction, and I am willing to create it / contribute to it. *Long version :* I've been thinking for a while that the Clojure community could benefit a lot from a more sophisticated and ergonomic documentation system. I have seen some existing plugins like lein-sphinx, but I think it would be really good to have documentation that would be written in Clojure, for the following reasons : - we're all very fond of Clojure data structures and their syntax. (I don't know about you, but I find that even HTML looks better in Clojurehttps://github.com/weavejester/hiccupthan in HTML). Plus, Clojure programmers already know how to edit them. - (better reason) The facts that Vars are first-class citizens and that symbols can be referred explicitly with hardly any ceremony (macros) are a exceptional opportunity to make smart and highly-structured documentation very easily. - if it's in Clojure, Clojure programmers can seamlessly build *ad hoc*documentation functionality on top of it to suit their own particular needs. I haven't found anything of the like yet, and if it exists, I would be grateful if someone would redirect me to it. Here are *my thoughts on this :* 1. Clojure doc-strings, although they are quite handy as reminders and for doc-indexation, are *too raw a content*. Even when they are done right, they tend to be cumbersome, and it's too bad to have such concise code drown in the middle of so much documentation. What's more, I believe that when programmers program a function (or anything), they tend to think more about the implementation than the (uninformed) usage, so they have little incentive to make it right. 2. Building on 1. having a system where documentation and programs live in separate files, in the same way as tests, would enforce a healthy separation of concerns. Importantly, it would make life much easier on the Version Control perspective. 3. Documentation should probably be
Re: testing clojure.core/group-by with clojure.test.check
One approach you can use is write the generators in such a way that they generate the final answer group-by should return, then you write code which does the inverse to group by and then you check the group by answer is equal to the originally generated solution. On Wednesday, April 30, 2014 11:38:19 PM UTC+12, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. 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: Clojure for web project? Talk me into it!
Wasn't Pedestal-app placed on hiatus? What is the current status of that? On Tuesday, April 29, 2014 10:35:25 AM UTC-5, Mike Haney wrote: Pedestal was developed by Cognitect and I would assume they use it on many of their consulting projects. Since future support appears be a major concern for you (rightly so), Pedestal probably fulfills that requirement better than anything else out there right now. Even if you don't need all the features it offers, it's worth considering building your server-side stack around it for that reason alone. -- 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: Kwargs vs explicit parameter map for APIs?
Here's the thing I can't stand about keyword args:
Let's start off with a simple function that looks for keys x and y, and if
either is missing,
replaces the value with 1 or 2 respectively.
(defn f [ {:keys [x y] :or {x 1 y 2}}]
[x y])
= (f :x 10)
[10 2]
So far, so good.
Now, let's do an extremely simple test of composability. Let's define a
function g that destructures the keyword args, and if a certain keyword
:call-f is set, then we're just going to turn around and call f, passing
all the keyword args along to f.
(defn g [ {call-f :call-f :as m}]
(when call-f
(apply f m)))
= (g :call-f true :x 10)
[1 2]
What? Oh right, you can't apply the function f to the map m. This doesn't
work. If we want to apply f, we somehow need to apply it to a sequence
of alternating keys and values, not a map.
Take 2:
(defn g [ {:keys [call-f x y] :as m}]
(when call-f
(f :x x :y y)))
OK, so this time we try to workaround things by explicitly calling out the
names of all the keywords we want to capture and pass along. It's ugly,
and doesn't seem to scale well to situations where you have an unknown but
at first glance, it seems to work:
= (g :call-f true :x 80 :y 20)
[80 20]
Or does it?
= (g :call-f true :x 10)
[10 nil]
What is going on here? Why is the answer coming out that :y is nil, when
function f explicitly uses :or to have :y default to 2?
The answer is that :or doesn't do what you think it does. The word or
implies that it substitutes the default value of :y any time the
destructured :y is nil or false. But that's not how it really works. It
doesn't destructure and then test against nil; instead the :or map only
kicks in when :y is actually missing as a key of the map.
This means that in g, when we actively destructured :y, it got set to a
nil, and then that got passed along to f. f's :or map didn't kick in
because :y was set to nil, not absent.
This is awful. You can't pass through keyword arguments to other functions
without explicitly destructuring them, and if you destructure them and pass
them along explicitly, nil values aren't picked up as absent values, so the
:or default maps don't work properly.
To put it simply, keyword args are bad news for composability.
It's a shame, and I'd love to see this improved (rather than just having
the community give up on keyword arguments).
--
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] nginx-clojure v0.2.0 -- Let MySQL JDBC Driver Apache HttpClient Fly With Epoll/Kqueue on Nginx
Thank you. It's my honour that nginx-clojure will being used possibly. As you said, coroutine based Java socket implementation can simplify asynchronous event model. We just write synchronous style code about java socket API and get the non-blocking and event driven executing on nginx. On Tuesday, April 29, 2014 10:20:53 PM UTC+8, Rick Richardson wrote: This is excellent! I definitely think there is a lot of opportunity for fusion between Clojure and Nginx. Clojure's model already supports the cooperating threads model that can simplify Nginx's complex event model, as you have demonstrated. Work has already been done that proves this idea can result in productivity and scale gains (nginx + Lua) It can also greatly simplify architectures by cutting out load-balancers making less to patch for security/stability issues. I look forward to using this on my upcoming web projects. On Friday, April 25, 2014 11:51:41 PM UTC-4, Xfeep Zhang wrote: nginx-clojure v0.2.0 includes new features: 1. non-blocking socket based on coroutine and compatible with largely existing java library such as apache http client, mysql jdbc drivers 2. asynchronous callback API of socket for some advanced usage 3. run initialization clojure code when nginx worker starting 4. provide a build-in tool to make setting of coroutine based socket easier 5. support Linux 32bit x86 now 6. publish [binary release compiled with lastes stable nginx 1.6.0]( https://sourceforge.net/projects/nginx-clojure/files/) about Linux x64, Linux i586, Win32 MacOS X. If the http service should do some slow I/O operations such as access external http service, database, etc. nginx worker will be blocked by those operations and the new user request even static file request will be blocked. It really sucks！ Before v0.2.0 the only choice is using thread pool but now we have three choice Now: 1. Coroutine based Socket -- Let MySQL JDBC Driver Apache HttpClient Fly With Epoll/Kqueue on Nginx - Java Socket API Compatible and work well with largely existing java library such as apache http client, mysql jdbc drivers etc. - non-blocking, cheap, fast and let one java main thread be able to handle thousands of connections. - Your old code **_need not be changed_** and those plain and old java socket based code such as Apache Http Client, MySQL mysql jdbc drivers etc. will be on the fly with epoll/kqueue on Linux/BSD! - You must do some steps to get the right class waving configuration file and set it in the nginx conf file. 2. Asynchronous Socket - More details here: https://github.com/nginx-clojure/nginx-clojure 3. Thread Pool - More details here : https://github.com/nginx-clojure/nginx-clojure More details please visit nginx-clojure github site : https://github.com/nginx-clojure/nginx-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/d/optout.
Re: Clojure for web project? Talk me into it!
Pedestal-app is pretty much dead, but pedestal (service) is alive and well, and that is what I was talking about. I know some people were upset when pedestal-app was put on hiatus, but I look at it a different way. Libraries like react (and its clojurescript counterparts) are changing the way people think about client-side development, and that's starting to look like the next big evolutionary step in ui's. Pedestal app was very new when this firestorm hit, with very little adoption, so I think Cognitect made a prudent choice to suspend it rather than encourage people to continue down a path that could end up in obsolescence. Sure, they could have pressed on and made incremental changes as the technology coalesced, but why go down that path when it was still early enough to scrap the library without affecting many users? Pedestal-service is a different story. It's been around longer and from what I've seen Cognitect hasn't wavered at all in their support for it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Kwargs vs explicit parameter map for APIs?
Unless I'm missing something subtle, all of your points would hold if you
removed the in your argument vector to turn your kwargs into an explicit
map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
I'm not sure the :or logic would be any less troublesome.
On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
Here's the thing I can't stand about keyword args:
Let's start off with a simple function that looks for keys x and y, and if
either is missing,
replaces the value with 1 or 2 respectively.
(defn f [ {:keys [x y] :or {x 1 y 2}}]
[x y])
= (f :x 10)
[10 2]
So far, so good.
Now, let's do an extremely simple test of composability. Let's define a
function g that destructures the keyword args, and if a certain keyword
:call-f is set, then we're just going to turn around and call f, passing
all the keyword args along to f.
(defn g [ {call-f :call-f :as m}]
(when call-f
(apply f m)))
= (g :call-f true :x 10)
[1 2]
What? Oh right, you can't apply the function f to the map m. This
doesn't work. If we want to apply f, we somehow need to apply it to a
sequence of alternating keys and values, not a map.
Take 2:
(defn g [ {:keys [call-f x y] :as m}]
(when call-f
(f :x x :y y)))
OK, so this time we try to workaround things by explicitly calling out the
names of all the keywords we want to capture and pass along. It's ugly,
and doesn't seem to scale well to situations where you have an unknown but
at first glance, it seems to work:
= (g :call-f true :x 80 :y 20)
[80 20]
Or does it?
= (g :call-f true :x 10)
[10 nil]
What is going on here? Why is the answer coming out that :y is nil, when
function f explicitly uses :or to have :y default to 2?
The answer is that :or doesn't do what you think it does. The word or
implies that it substitutes the default value of :y any time the
destructured :y is nil or false. But that's not how it really works. It
doesn't destructure and then test against nil; instead the :or map only
kicks in when :y is actually missing as a key of the map.
This means that in g, when we actively destructured :y, it got set to a
nil, and then that got passed along to f. f's :or map didn't kick in
because :y was set to nil, not absent.
This is awful. You can't pass through keyword arguments to other
functions without explicitly destructuring them, and if you destructure
them and pass them along explicitly, nil values aren't picked up as absent
values, so the :or default maps don't work properly.
To put it simply, keyword args are bad news for composability.
It's a shame, and I'd love to see this improved (rather than just having
the community give up on keyword arguments).
--
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: Kwargs vs explicit parameter map for APIs?
I think it would because in that case you'd just pass your arg map straight
through rather than having to reconstruct it. So if you weren't passed :y
in g (in Mark's example), g wouldn't pass it on to f. By forcing the
reconstruction of the map from explicit args, you're forced to use the
value (incorrectly) destructured in g. Mark could work around it in his
example by using (apply f (mapcat identity m)) in g, but it's far from
intuitive.
On 1 May 2014 15:04, Jim Crossley j...@crossleys.org wrote:
Unless I'm missing something subtle, all of your points would hold if you
removed the in your argument vector to turn your kwargs into an explicit
map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
I'm not sure the :or logic would be any less troublesome.
On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg
mark.engelb...@gmail.comwrote:
Here's the thing I can't stand about keyword args:
Let's start off with a simple function that looks for keys x and y, and
if either is missing,
replaces the value with 1 or 2 respectively.
(defn f [ {:keys [x y] :or {x 1 y 2}}]
[x y])
= (f :x 10)
[10 2]
So far, so good.
Now, let's do an extremely simple test of composability. Let's define a
function g that destructures the keyword args, and if a certain keyword
:call-f is set, then we're just going to turn around and call f, passing
all the keyword args along to f.
(defn g [ {call-f :call-f :as m}]
(when call-f
(apply f m)))
= (g :call-f true :x 10)
[1 2]
What? Oh right, you can't apply the function f to the map m. This
doesn't work. If we want to apply f, we somehow need to apply it to a
sequence of alternating keys and values, not a map.
Take 2:
(defn g [ {:keys [call-f x y] :as m}]
(when call-f
(f :x x :y y)))
OK, so this time we try to workaround things by explicitly calling out
the names of all the keywords we want to capture and pass along. It's
ugly, and doesn't seem to scale well to situations where you have an
unknown but at first glance, it seems to work:
= (g :call-f true :x 80 :y 20)
[80 20]
Or does it?
= (g :call-f true :x 10)
[10 nil]
What is going on here? Why is the answer coming out that :y is nil, when
function f explicitly uses :or to have :y default to 2?
The answer is that :or doesn't do what you think it does. The word or
implies that it substitutes the default value of :y any time the
destructured :y is nil or false. But that's not how it really works. It
doesn't destructure and then test against nil; instead the :or map only
kicks in when :y is actually missing as a key of the map.
This means that in g, when we actively destructured :y, it got set to a
nil, and then that got passed along to f. f's :or map didn't kick in
because :y was set to nil, not absent.
This is awful. You can't pass through keyword arguments to other
functions without explicitly destructuring them, and if you destructure
them and pass them along explicitly, nil values aren't picked up as absent
values, so the :or default maps don't work properly.
To put it simply, keyword args are bad news for composability.
It's a shame, and I'd love to see this improved (rather than just having
the community give up on keyword arguments).
--
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
Parameter order for APIs
Hi everyone, After the very interesting keyword argument debate, I have another question about API design. Specifically I'm interested in suggestions about parameter order. The new API guidelines, which have changed very recently to favour maps over keyword args, also changed to include a suggestion that the keyword map be the first argument, since it's the least variance argument. I've been using some fairly simple rules to order my parameters, basically 1) functions that operate on collections should have the collection last to interoperate with -, and 2) functions operating on a main object should accept that first, to interoperate with -. #2 is generally pretty intuitive since it's the same as Java interop and protocol calls, but there's still a fair amount of ambiguity with just these rules unless all your functions have one or two arguments. I'm interested in opinions about the variance ordering, since I assume this is to facilitate use of partial and the like. I never really use partial myself so I don't have a good feeling for how this ordering should work - any comments or opinions? Thanks, Colin -- 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: Datascript and React.js for a Clojure web app
Wow Thank you so much for this - I played with the demo on Heroku - and this is a great starter skeleton for someone like myself who wants to build a web app. Please keep up the good work and I like your roadmap tasks in your todo list - they are all relevant and useful for someone like myself. Kind regards Rudi On 30/04/2014, at 11:32 PM, Gijs S. gijsstuur...@gmail.com wrote: Hi all, I've released a Clojure web application. It includes a front-end using DataScript and React.js in ClojureScript. More details here: http://thegeez.net/2014/04/30/datascript_clojure_web_app.html The code is on github: https://github.com/thegeez/clj-crud Demo on heroku: http://clj-crud.herokuapp.com/ Best regards, Gijs -- 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.
Pedestal on Google App Engine (GAE)
Hi,I watched @rkneufeld 's webcast on pedestal recently and it was really nice.I was wondering how I could go about deploying a pedestal based app on GAE. I'd appreciate any pointers very much.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/d/optout.
Re: Parameter order for APIs
Hi, Colin. I don't use 'partial' that much either, since anonymous functions are so easy to create. A fn also has the advantage (to my mind) of making it clear what arity the old and new fns have. 'Partial' turns a multi-arity fn into another multi-arity fn, which I personally think is very hard to translate when reading code, even if you're familiar with the original fn. I don't have any parameter order rules, either. I just use the argument order of whichever clojure.core fn reminds me most of the fn I'm writing (This is like a reduction, I'll put the collection at the end; This adds an element, I'll put the collection at the beginning.). --Leif On Wednesday, April 30, 2014 11:22:55 PM UTC-4, Colin Fleming wrote: Hi everyone, After the very interesting keyword argument debate, I have another question about API design. Specifically I'm interested in suggestions about parameter order. The new API guidelines, which have changed very recently to favour maps over keyword args, also changed to include a suggestion that the keyword map be the first argument, since it's the least variance argument. I've been using some fairly simple rules to order my parameters, basically 1) functions that operate on collections should have the collection last to interoperate with -, and 2) functions operating on a main object should accept that first, to interoperate with -. #2 is generally pretty intuitive since it's the same as Java interop and protocol calls, but there's still a fair amount of ambiguity with just these rules unless all your functions have one or two arguments. I'm interested in opinions about the variance ordering, since I assume this is to facilitate use of partial and the like. I never really use partial myself so I don't have a good feeling for how this ordering should work - any comments or opinions? Thanks, Colin -- 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: Kwargs vs explicit parameter map for APIs?
Oh, right. (f m) instead of (apply f [m]). Duh.
On Wed, Apr 30, 2014 at 11:15 PM, Colin Fleming colin.mailingl...@gmail.com
wrote:
I think it would because in that case you'd just pass your arg map
straight through rather than having to reconstruct it. So if you weren't
passed :y in g (in Mark's example), g wouldn't pass it on to f. By forcing
the reconstruction of the map from explicit args, you're forced to use the
value (incorrectly) destructured in g. Mark could work around it in his
example by using (apply f (mapcat identity m)) in g, but it's far from
intuitive.
On 1 May 2014 15:04, Jim Crossley j...@crossleys.org wrote:
Unless I'm missing something subtle, all of your points would hold if you
removed the in your argument vector to turn your kwargs into an explicit
map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
I'm not sure the :or logic would be any less troublesome.
On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
Here's the thing I can't stand about keyword args:
Let's start off with a simple function that looks for keys x and y, and
if either is missing,
replaces the value with 1 or 2 respectively.
(defn f [ {:keys [x y] :or {x 1 y 2}}]
[x y])
= (f :x 10)
[10 2]
So far, so good.
Now, let's do an extremely simple test of composability. Let's define a
function g that destructures the keyword args, and if a certain keyword
:call-f is set, then we're just going to turn around and call f, passing
all the keyword args along to f.
(defn g [ {call-f :call-f :as m}]
(when call-f
(apply f m)))
= (g :call-f true :x 10)
[1 2]
What? Oh right, you can't apply the function f to the map m. This
doesn't work. If we want to apply f, we somehow need to apply it to a
sequence of alternating keys and values, not a map.
Take 2:
(defn g [ {:keys [call-f x y] :as m}]
(when call-f
(f :x x :y y)))
OK, so this time we try to workaround things by explicitly calling out
the names of all the keywords we want to capture and pass along. It's
ugly, and doesn't seem to scale well to situations where you have an
unknown but at first glance, it seems to work:
= (g :call-f true :x 80 :y 20)
[80 20]
Or does it?
= (g :call-f true :x 10)
[10 nil]
What is going on here? Why is the answer coming out that :y is nil,
when function f explicitly uses :or to have :y default to 2?
The answer is that :or doesn't do what you think it does. The word or
implies that it substitutes the default value of :y any time the
destructured :y is nil or false. But that's not how it really works. It
doesn't destructure and then test against nil; instead the :or map only
kicks in when :y is actually missing as a key of the map.
This means that in g, when we actively destructured :y, it got set to a
nil, and then that got passed along to f. f's :or map didn't kick in
because :y was set to nil, not absent.
This is awful. You can't pass through keyword arguments to other
functions without explicitly destructuring them, and if you destructure
them and pass them along explicitly, nil values aren't picked up as absent
values, so the :or default maps don't work properly.
To put it simply, keyword args are bad news for composability.
It's a shame, and I'd love to see this improved (rather than just having
the community give up on keyword arguments).
--
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
clojure code to java
I've been programming a bit in Clojure, and in my opinion it's like making Java programs without typing long Java because of it running on the JVM. However, I wanna be able to convert my Clojure code to Java code. I know Leiningen can do that, but I am really clueless at this point, and I don't know what other programs out there will convert Clojure to Java .class file. Does anyone have any tips? -- 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.
difference in behavior for :let modifiers in for vs. doseq
Hello everyone, In Clojure 1.6: user (doseq [:let [a 1] b '(1 2 3)] (println a b)) 1 1 1 2 1 3 nil user (for [:let [a 1] b '(1 2 3)] (println a b)) IllegalStateException Can't pop empty vector clojure.lang.PersistentVector.pop (PersistentVector.java:381) user Is this expected behavior? a bug? Something I missed in the documentation? -- 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: difference in behavior for :let modifiers in for vs. doseq
At least a few people consider it a bug, and two of them created a ticket, the first of which was declined as not a bug. That is some evidence that it is considered not a bug: http://dev.clojure.org/jira/browse/CLJ-1316 http://dev.clojure.org/jira/browse/CLJ-207 Andy On Wed, Apr 30, 2014 at 9:39 PM, Yuri Niyazov yuri.niya...@gmail.comwrote: Hello everyone, In Clojure 1.6: user (doseq [:let [a 1] b '(1 2 3)] (println a b)) 1 1 1 2 1 3 nil user (for [:let [a 1] b '(1 2 3)] (println a b)) IllegalStateException Can't pop empty vector clojure.lang.PersistentVector.pop (PersistentVector.java:381) user Is this expected behavior? a bug? Something I missed in the documentation? -- 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: clojure code to java
Leiningen can convert Clojure source code to Java .class files (compiled Java byte code, not Java source code), with the help of the Clojure compiler. I don't know of a way Leiningen can convert that to Java source code, unless there is some feature of Leiningen I haven't learned about yet, or some plugin that does that. There are several programs out there, some open source, some commercial, that can decompile Java byte code files into Java source code, of varying quality. I have used a trial version of the AndroChef Java Decompiler 1.0 a few times in the past, and found its results better than one other open source Java decompiler I tried (I don't remember what that was called right now). http://www.neshkov.com/ac_decompiler.html Andy On Wed, Apr 30, 2014 at 7:05 PM, Julio Berina juliober...@gmail.com wrote: I've been programming a bit in Clojure, and in my opinion it's like making Java programs without typing long Java because of it running on the JVM. However, I wanna be able to convert my Clojure code to Java code. I know Leiningen can do that, but I am really clueless at this point, and I don't know what other programs out there will convert Clojure to Java .class file. Does anyone have any tips? -- 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: clojure code to java
You could also check https://github.com/galdolber/clojure-objc, which uses a modified Clojure compiler to output Java source instead of bytecode. It's been subsequently modified to work with ObjC, I'm not sure whether that affects its ability to execute the program as Java or not. On 1 May 2014 16:56, Andy Fingerhut andy.finger...@gmail.com wrote: Leiningen can convert Clojure source code to Java .class files (compiled Java byte code, not Java source code), with the help of the Clojure compiler. I don't know of a way Leiningen can convert that to Java source code, unless there is some feature of Leiningen I haven't learned about yet, or some plugin that does that. There are several programs out there, some open source, some commercial, that can decompile Java byte code files into Java source code, of varying quality. I have used a trial version of the AndroChef Java Decompiler 1.0 a few times in the past, and found its results better than one other open source Java decompiler I tried (I don't remember what that was called right now). http://www.neshkov.com/ac_decompiler.html Andy On Wed, Apr 30, 2014 at 7:05 PM, Julio Berina juliober...@gmail.comwrote: I've been programming a bit in Clojure, and in my opinion it's like making Java programs without typing long Java because of it running on the JVM. However, I wanna be able to convert my Clojure code to Java code. I know Leiningen can do that, but I am really clueless at this point, and I don't know what other programs out there will convert Clojure to Java .class file. Does anyone have any tips? -- 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.
