Re: clojure, not the go to for data science
Caveats... there is a lot to explore, things are continually changing and evolving, I haven't made an exhaustive search, but here is what is quickly google-able... YMMV # Books - Eric Rochester: https://www.packtpub.com/big-data-and-business-intelligence/mastering-clojure-data-analysis and http://www.ericrochester.com/pages/announcements/clj-data-analysis/index.html - Akhil Wali: https://www.packtpub.com/big-data-and-business-intelligence/clojure-machine-learning # Youtube videos - Jony Epsilon: http://gorilla-repl.org/ - Edmund Jackson: "Clojure Data Science" https://www.youtube.com/watch?v=RVmY2lQ4DHE - Mike Anderson: "Enter the Matrix" https://www.youtube.com/watch?v=_h9TLJtjSJo and "Machine Learning Live" https://www.youtube.com/watch?v=QJ1qgCr09j8 - Aysylu Greenberg: "Loom and Graphs in Clojure" https://www.youtube.com/watch?v=wEEutxTYQQU - Cascalog: https://www.youtube.com/results?search_query=cascalog # Clojure (wrappers) - clj-vw: https://github.com/engagor/clj-vw - deeplearning4j.org e.g. [org.deeplearning4j/dl4j-spark "0.0.3.3.2.alpha1"] - core.matrix (https://github.com/mikera/core.matrix) - Raynes/Conch (shell out to the executable of your choice.) https://github.com/Raynes/conch - loom (https://github.com/aysylu/loom) - https://github.com/marcliberatore/mallet-lda - java interop I recommend settling on a particular topic/method/problem you are interested in solving and then searching specifically on that, craft a few functions, try some approaches, existing tools, etc... best, -A -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Lein repl and Cider repl
Hi guys, one question about the Repl and Cider. When I start the Repl with "lein repl", I am in the namespace "x.y", and if I do "(doc swap!)" I see the documentation showing up. If instead I start the repl with Cider, it looks like I'm in the same namespace, however "(doc swap!)" doesn't work, but if I do "(clojure.repl/doc swap!)" actually works. So I wonder what's the difference, how does running "lein repl" differ from using the cider repl? Is it possible to have the same behaviour in both? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lein repl and Cider repl
Maybe reply interns `clojure.repl/doc` in every namespace. I can tell you for a fact that in CIDER the `clojure.repl` functions are interned only in the "user" namespace. We can always change this, but it doesn't make a lot of sense. CIDER users normally never use functions like "doc" as they have much more powerful options at their disposal (e.g. `C-c C-d d` (cider-doc) or the `C-c C-d g`). On 5 April 2015 at 11:41, andrea crotti wrote: > Hi guys, one question about the Repl and Cider. > > When I start the Repl with "lein repl", I am in the namespace "x.y", > and if I do "(doc swap!)" I see the documentation showing up. > > If instead I start the repl with Cider, it looks like I'm in the same > namespace, however "(doc swap!)" doesn't work, but if I do > "(clojure.repl/doc swap!)" actually works. > > So I wonder what's the difference, how does running "lein repl" differ > from using the cider repl? > > Is it possible to have the same behaviour in both? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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: Lein repl and Cider repl
Relevant bit of code here: https://github.com/trptcolin/reply/blob/69c4c6ffe0c8903a193c1e127337832e225335b0/src/clj/reply/initialization.clj#L179 Jony On Sunday, 5 April 2015 09:47:04 UTC+1, Bozhidar Batsov wrote: > > Maybe reply interns `clojure.repl/doc` in every namespace. I can tell you > for a fact that in CIDER the `clojure.repl` functions are interned only in > the "user" namespace. We can always change this, but it doesn't make a lot > of sense. CIDER users normally never use functions like "doc" as they have > much more powerful options at their disposal (e.g. `C-c C-d d` (cider-doc) > or the `C-c C-d g`). > > On 5 April 2015 at 11:41, andrea crotti > wrote: > >> Hi guys, one question about the Repl and Cider. >> >> When I start the Repl with "lein repl", I am in the namespace "x.y", >> and if I do "(doc swap!)" I see the documentation showing up. >> >> If instead I start the repl with Cider, it looks like I'm in the same >> namespace, however "(doc swap!)" doesn't work, but if I do >> "(clojure.repl/doc swap!)" actually works. >> >> So I wonder what's the difference, how does running "lein repl" differ >> from using the cider repl? >> >> Is it possible to have the same behaviour in both? >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Lein repl and Cider repl
Ah thanks awesome, yes that's true I only have to get used to the Cider. The only thing is not also in Cider then would be "find-doc"? And in general, what would be the best way to add some extra customization to how the Cider repl works? 2015-04-05 9:46 GMT+01:00 Bozhidar Batsov : > Maybe reply interns `clojure.repl/doc` in every namespace. I can tell you > for a fact that in CIDER the `clojure.repl` functions are interned only in > the "user" namespace. We can always change this, but it doesn't make a lot > of sense. CIDER users normally never use functions like "doc" as they have > much more powerful options at their disposal (e.g. `C-c C-d d` (cider-doc) > or the `C-c C-d g`). > > On 5 April 2015 at 11:41, andrea crotti wrote: >> >> Hi guys, one question about the Repl and Cider. >> >> When I start the Repl with "lein repl", I am in the namespace "x.y", >> and if I do "(doc swap!)" I see the documentation showing up. >> >> If instead I start the repl with Cider, it looks like I'm in the same >> namespace, however "(doc swap!)" doesn't work, but if I do >> "(clojure.repl/doc swap!)" actually works. >> >> So I wonder what's the difference, how does running "lein repl" differ >> from using the cider repl? >> >> Is it possible to have the same behaviour in both? >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from 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: Lein repl and Cider repl
"find-doc" -> "cider-apropos" Go through the CIDER readme - it's full of useful tips. On 5 April 2015 at 12:45, andrea crotti wrote: > Ah thanks awesome, yes that's true I only have to get used to the Cider. > The only thing is not also in Cider then would be "find-doc"? > > And in general, what would be the best way to add some extra > customization to how the Cider repl works? > > 2015-04-05 9:46 GMT+01:00 Bozhidar Batsov : > > Maybe reply interns `clojure.repl/doc` in every namespace. I can tell you > > for a fact that in CIDER the `clojure.repl` functions are interned only > in > > the "user" namespace. We can always change this, but it doesn't make a > lot > > of sense. CIDER users normally never use functions like "doc" as they > have > > much more powerful options at their disposal (e.g. `C-c C-d d` > (cider-doc) > > or the `C-c C-d g`). > > > > On 5 April 2015 at 11:41, andrea crotti > wrote: > >> > >> Hi guys, one question about the Repl and Cider. > >> > >> When I start the Repl with "lein repl", I am in the namespace "x.y", > >> and if I do "(doc swap!)" I see the documentation showing up. > >> > >> If instead I start the repl with Cider, it looks like I'm in the same > >> namespace, however "(doc swap!)" doesn't work, but if I do > >> "(clojure.repl/doc swap!)" actually works. > >> > >> So I wonder what's the difference, how does running "lein repl" differ > >> from using the cider repl? > >> > >> Is it possible to have the same behaviour in both? > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from 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.
Datomic namespaced idents question
I have a question regarding using Datomic from Clojure, but I think it's
more of a Clojure question than a Datomic question
I understand that you must use namespaces in idents for logically distinct
types of entities. (Unless you intend them to be lumped together in the
same index.) Thus the :ids in two entities below don't conflict:
{:foo/id 1
:name "Name of a Foo"}
{:bar/id 1
:desc "Bar's don't have names, they have desc"}
So far so good.
My question is: do you expose this namespacing outside the model layer when
working in Clojure? I'm inclined to say that this namespacing is an
implementation detail of the database and so add/remove them in the model
layer. I would love to hear your opinions.
Stig
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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, not the go to for data science
Thanks, that is an awesome list of resources. On Sun, Apr 5, 2015, 4:20 AM A wrote: > Caveats... there is a lot to explore, things are continually changing and > evolving, I haven't made an exhaustive search, but here is what is quickly > google-able... YMMV > > # Books > - Eric Rochester: https://www.packtpub.com/big-data-and-business- > intelligence/mastering-clojure-data-analysis and > http://www.ericrochester.com/pages/announcements/clj-data- > analysis/index.html > - Akhil Wali: https://www.packtpub.com/big-data-and-business- > intelligence/clojure-machine-learning > > # Youtube videos > - Jony Epsilon: http://gorilla-repl.org/ > - Edmund Jackson: "Clojure Data Science" https://www.youtube.com/watch? > v=RVmY2lQ4DHE > - Mike Anderson: "Enter the Matrix" https://www.youtube.com/watch? > v=_h9TLJtjSJo and "Machine Learning Live" https://www.youtube.com/watch? > v=QJ1qgCr09j8 > - Aysylu Greenberg: "Loom and Graphs in Clojure" > https://www.youtube.com/watch?v=wEEutxTYQQU > - Cascalog: https://www.youtube.com/results?search_query=cascalog > > # Clojure (wrappers) > - clj-vw: https://github.com/engagor/clj-vw > - deeplearning4j.org e.g. [org.deeplearning4j/dl4j-spark > "0.0.3.3.2.alpha1"] > - core.matrix (https://github.com/mikera/core.matrix) > - Raynes/Conch (shell out to the executable of your choice.) > https://github.com/Raynes/conch > - loom (https://github.com/aysylu/loom) > - https://github.com/marcliberatore/mallet-lda > - java interop > > I recommend settling on a particular topic/method/problem you are > interested in solving and then searching specifically on that, craft a few > functions, try some approaches, existing tools, etc... > > best, > -A > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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.
doseq over atomic collection
Hi folks It may seem silly question but why when I doseq over a vector that is wrapped in an atom and change the vector using swap! while I am inside doseq, the doseq sets to the beginning of the vector intermittently: (def a-data (atom [15 9 8 1 4 11 7 12 13 14 5 3 16 2 10 6])) (defn switch-two-elements [the-vector] ... ) ;; swaping two elements in given vector (doseq [element @a-data] (println @a-data) (println element) (swap! a-data switch-two-elements)) [15 9 8 1 4 11 7 12 13 14 5 3 16 2 10 6] 15 [1 9 8 15 4 11 7 12 13 14 5 3 16 2 10 6] 9 [1 4 8 15 9 11 7 12 13 14 5 3 16 2 10 6] 8 [1 4 5 15 9 11 7 12 13 14 8 3 16 2 10 6] 1 ==> I expect this to be 15 I suspect the reason would be the same as the one behind not changing a collection in java while iterating over it. I appreciate any insight on this. Thanks a lot Best regards -- Software Architect & Computer Scientist -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: doseq over atomic collection
Dereferencing an atom will give you the value of the atom at the time you dereferenced it. So at the start of the doseq loop, you deref the atom and get back an immutable vector of values. It's the same as writing: (let [data @a-data] (doseq [element data] ...)) You dereference first, and then you iterate over that fixed sequence. The value of "a-data" might change, but the dereferenced "data" does not. - James On 5 April 2015 at 18:00, Shahrdad Shadab wrote: > Hi folks > > It may seem silly question but why when I doseq over a vector that is > wrapped in an atom and change the vector using swap! while I am inside > doseq, the doseq sets to the beginning of the vector intermittently: > > > (def a-data (atom [15 9 8 1 4 11 7 12 13 14 5 3 16 2 10 6])) > > (defn switch-two-elements [the-vector] ... ) ;; swaping two elements in > given vector > > (doseq [element @a-data] > (println @a-data) (println element) >(swap! a-data switch-two-elements)) > > [15 9 8 1 4 11 7 12 13 14 5 3 16 2 10 6] > 15 > > [1 9 8 15 4 11 7 12 13 14 5 3 16 2 10 6] > 9 > > [1 4 8 15 9 11 7 12 13 14 5 3 16 2 10 6] > 8 > > [1 4 5 15 9 11 7 12 13 14 8 3 16 2 10 6] > 1 ==> I expect this to be 15 > > I suspect the reason would be the same as the one behind not changing a > collection in java while iterating over it. > > I appreciate any insight on this. > > Thanks a lot > Best regards > > > > > -- > Software Architect & Computer Scientist > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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: doseq over atomic collection
Thanks a lot James. It seems I completely missed the order of let and doseq. On Sun, Apr 5, 2015 at 1:12 PM, James Reeves wrote: > Dereferencing an atom will give you the value of the atom at the time you > dereferenced it. So at the start of the doseq loop, you deref the atom and > get back an immutable vector of values. It's the same as writing: > > (let [data @a-data] > (doseq [element data] > ...)) > > You dereference first, and then you iterate over that fixed sequence. The > value of "a-data" might change, but the dereferenced "data" does not. > > - James > > On 5 April 2015 at 18:00, Shahrdad Shadab wrote: > >> Hi folks >> >> It may seem silly question but why when I doseq over a vector that is >> wrapped in an atom and change the vector using swap! while I am inside >> doseq, the doseq sets to the beginning of the vector intermittently: >> >> >> (def a-data (atom [15 9 8 1 4 11 7 12 13 14 5 3 16 2 10 6])) >> >> (defn switch-two-elements [the-vector] ... ) ;; swaping two elements in >> given vector >> >> (doseq [element @a-data] >> (println @a-data) (println element) >>(swap! a-data switch-two-elements)) >> >> [15 9 8 1 4 11 7 12 13 14 5 3 16 2 10 6] >> 15 >> >> [1 9 8 15 4 11 7 12 13 14 5 3 16 2 10 6] >> 9 >> >> [1 4 8 15 9 11 7 12 13 14 5 3 16 2 10 6] >> 8 >> >> [1 4 5 15 9 11 7 12 13 14 8 3 16 2 10 6] >> 1 ==> I expect this to be 15 >> >> I suspect the reason would be the same as the one behind not changing a >> collection in java while iterating over it. >> >> I appreciate any insight on this. >> >> Thanks a lot >> Best regards >> >> >> >> >> -- >> Software Architect & Computer Scientist >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from 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. > -- Software Architect & Computer Scientist -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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, not the go to for data science
>> Thanks, that is an awesome list of resources. kudos to the respective authors. -A -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Hello Alex, As I've understood from the dev.clojure.org page, additional features and feature combinations will become available later. Can we please get :clj/android (or :clja) still in 1.7? If so, what has to be done by me or Daniel to make it happen? Thanks! On Tuesday, March 31, 2015 at 7:50:27 PM UTC+3, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] > > Regression fixes from previous alphas (and one from 1.6): > > 1) CLJ-1544 was rolled back and will be investigated for a future release. > 2) CLJ-1637 fixed regression with vec on MapEntry > 3) CLJ-1663 fixed regression in classloader (affected Cursive) > 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) > method > 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for > literal nil arg > 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that > prevented update > > Some highlights new in alpha6: > > ## Transducer-related changes: > > The LazyTransformer introduced to create lazy transforming sequences has > been > replaced with a TransformingIterator. This was done to simplify the code > around transformations and to make certain use cases around eduction more > efficient. > > ## Faster reduce, iterator, and sequence paths > > A lot of work has been done across a set of tickets to improve the ability > of > collections to provide more efficient reduce or iterator performance, and > also to > make common sequence generators create faster sequence and reduce paths. > You > should see significant performance in many reduce-related paths (this > includes > reduce, transduce, into, and anything else built on reduce). > > Many of those changes also have beneficial sequence performance, so you > may see > some benefits even in code that does not use transducers. > > * Most uses of SeqIterator have now been replaced with iterators that > directly walk > the underlying source for improved efficiency. This includes maps, sets, > records, etc. > * repeat - now returns a faster sequence with a fast reduce path > * cycle - now returns a faster sequence with a fast reduce path > * iterate - now returns a faster sequence with a fast reduce path > * range - (did not quite make it in, but coming soon...) > * keys - iterates directly over the keys of a map, without seq or MapEntry > allocation > * vals - iterates directly over the vals of a map, without seq or MapEntry > allocation > * iterator-seq - now creates a chunked sequence when previously it was > unchunked > * vec and set - were not changed in this release but were set up in a > previous alpha > to take advantage of the reduce and iterator changes above > > ## Reader conditionals > > Reader Conditionals is a new capability to support portable code that > can run on multiple Clojure platforms with only small changes. In > particular, this feature aims to support the increasingly common case > of libraries targeting both Clojure and ClojureScript. > > Code intended to be common across multiple platforms should use a new > supported file extension: ".cljc". When requested to load a namespace, > the platform-specific file extension (.clj, .cljs) will be checked > prior to .cljc. > > A new reader form can be used to specify "reader conditional" code in > cljc files (and *only* cljc files). Each platform defines a feature > identifying the platform (:clj, :cljs, :cljr). The reader conditional > specifies code that is read conditionally based on the feature/ > > Form #? takes a list of alternating feature and expression. These are > checked like cond and the selected expression is read and returned. Other > branches are unread. If no branch is selected, the reader reads nothing > (not nil, but literally as if reading ""). An optional ":default" branch > can be used as a fallthrough. > > Reader conditional with 2 features and a default: > > #?(:clj Double/NaN >:cljsjs/NaN >:default nil) > > There is also a reader conditional splicing form. The evaluated expression > should be sequential and will be spliced into the surrounded code, similar > to unqoute-splicing. > > For example: > >[1 2 #?@(:clj [3 4] :cljs [5 6])] > > This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, > and [1 2] on any other platform. > > Additionally, the reader can now be invoked with options for the features > to use and how to interpret reader conditionals. By default, reader > conditionals > are not allowed, but that can be turned on, or a "preserve" mode can be > used to > preserve all branches (most likely useful for tooling or source > transforms). > > In the preserve mode, the reader conditional itself and any tagged literals > within the unselected branches are returned as tagged literal data. > > For more information, see: > http://dev.clojure.org/d
Re: clojure, not the go to for data science
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=rincanter.clj >> I am not sure whether this fits the design atm. though. I also >> had a look at renjin, but I think the native plugins mandate an >> RVM integration atm. >> > > You might find http://beakernotebook.com interesting, if you > haven't seen it before. It allows several languages in the same > notebook, and has a simple mechanism for sharing data between the > language environments. It's pretty green at the moment, but it has > some serious backing, so could be pretty useful once it's got a bit > more polish on it. I chatted a little with someone who was hoping > to implement a Clojure plugin for it, although I don't know how > they've gotten on since. This is really nice, thank you for pointing out! Effectively though this means you need to manually(!) convert data between all cells, which only works if serialization between the environments is a lot less work than processing the data and you don't want to call alien procedures e.g. in a loop. It also means that part of datasets need to be hold in memory in all runtimes at the same time. So I am not sure whether JSON synchronisation of state between runtimes is good in the long run, it feels fairly hacky and having that many runtimes already causes a big type-conversion matrix and probably many subtle incompatibilities. It is the most pragmatic approach though and probably the most successful for now. They are not opinionated about languages, while I would like to integrate data science tooling in Clojure, so it is easier to bring people on board, not to make language hopping the top goal, which is for mentioned performance reasons and from a Lisp/Clojure perspective a bit questionable imo (esp. since all these languages have to drop to C to get some performance). I also would like to have the environment written in Clojure (read: gorilla). I would be happy to integrate Python and R on the JVM, e.g. through Jython and RServe/renjin, which allows to share code much better down to direct method dispatch. Do you think integrating R cells in this way would be reasonable for you? Or just allowing plugins for new cell-types... (With RServe manual synchronisation with the RVM is still necessary btw., renjin would solve this, but needs more support for CRAN packages imho). > > I also have taken a paper I liked and implemented a quick version > of > >> SNE, which was fairly nice to do in Gorilla REPL: >> >> http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj >> A problem seems to be unicode support, I tried to use some math >> symbols from the notation in the paper directly, but the viewer >> seems to have a problem with it. >> > > Not sure what the problem is there - my feeling is it should just > work, on the Gorilla side. If there's a test case you can point to > (with an expected result) I can take a look at it. The problem is just that viewer.gorilla-repl.org seems to have some encoding problems with UTF-8. See the sum sigma symbol for instance: https://github.com/ghubber/cnc/blob/master/stochastic-neighbour-embedding.clj#L72 which is corrupted in the viewer. I hoped that was easy to fix. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5 HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc= =5QnK -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] ednsl-0.2.0: a super-simple DSL for building DSLs
Hi James,
Interesting library. I have a few comments on the readme.
The simple example is not so simple:
(ns my.app
(:use [ednsl]))
(defn main [& args]
(let [r (-> "config-file.edn" read-file ctx-form
(>>= emap (eithery (etuple ekey (eor (>>- esym eload-sym)
eany)
{:keys [main args]} r]
(apply main args)))
(defn real-main [& args]
;; Do something useful!
(prn args))
The calculation of r is supposed to demonstrate what this library does, but
a potential user will have no idea what any of those supposed to do.
Perhaps loosening the code and adding some comments that explain what's
going on there can help adoption.
I think main should do (apply real-main args), otherwise infinite recursion.
Codox docs are in the 'doc' directory or can be read on github. They
contain a good walkthrough.
github link here goes to your user page.
On Fri, Apr 3, 2015 at 5:43 PM, James Laver wrote:
> It’s not quite as stupid as it sounds and it’s mostly the result of
> factoring out the config handling code from oolong[1]
>
> https://github.com/jjl/ednsl/
> https://clojars.org/ednsl
>
> Happy hacking!
>
> James
>
> [1] https://github.com/jjl/oolong/
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.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: [ANN] Clojure 1.7.0-alpha6 released
The reader can be invoked programmatically with any feature set you like now. We did not plan to allow custom features for 1.7. I'm not sure what it would mean to "add" an android feature? I'll plead ignorance in not knowing how the Clojure Android stuff works or where a feature indicating Android could be set without support for custom features. Do you currently fork to support Android? > On Apr 5, 2015, at 1:44 PM, Alexander Yakushev wrote: > > Hello Alex, > > As I've understood from the dev.clojure.org page, additional features and > feature combinations will become available later. Can we please get > :clj/android (or :clja) still in 1.7? If so, what has to be done by me or > Daniel to make it happen? > > Thanks! > >> On Tuesday, March 31, 2015 at 7:50:27 PM UTC+3, Alex Miller wrote: >> Clojure 1.7.0-alpha6 is now available. >> >> Try it via >> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ >> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] >> >> Regression fixes from previous alphas (and one from 1.6): >> >> 1) CLJ-1544 was rolled back and will be investigated for a future release. >> 2) CLJ-1637 fixed regression with vec on MapEntry >> 3) CLJ-1663 fixed regression in classloader (affected Cursive) >> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) >> method >> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for >> literal nil arg >> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that >> prevented update >> >> Some highlights new in alpha6: >> >> ## Transducer-related changes: >> >> The LazyTransformer introduced to create lazy transforming sequences has >> been >> replaced with a TransformingIterator. This was done to simplify the code >> around transformations and to make certain use cases around eduction more >> efficient. >> >> ## Faster reduce, iterator, and sequence paths >> >> A lot of work has been done across a set of tickets to improve the ability of >> collections to provide more efficient reduce or iterator performance, and >> also to >> make common sequence generators create faster sequence and reduce paths. You >> should see significant performance in many reduce-related paths (this >> includes >> reduce, transduce, into, and anything else built on reduce). >> >> Many of those changes also have beneficial sequence performance, so you may >> see >> some benefits even in code that does not use transducers. >> >> * Most uses of SeqIterator have now been replaced with iterators that >> directly walk >> the underlying source for improved efficiency. This includes maps, sets, >> records, etc. >> * repeat - now returns a faster sequence with a fast reduce path >> * cycle - now returns a faster sequence with a fast reduce path >> * iterate - now returns a faster sequence with a fast reduce path >> * range - (did not quite make it in, but coming soon...) >> * keys - iterates directly over the keys of a map, without seq or MapEntry >> allocation >> * vals - iterates directly over the vals of a map, without seq or MapEntry >> allocation >> * iterator-seq - now creates a chunked sequence when previously it was >> unchunked >> * vec and set - were not changed in this release but were set up in a >> previous alpha >> to take advantage of the reduce and iterator changes above >> >> ## Reader conditionals >> >> Reader Conditionals is a new capability to support portable code that >> can run on multiple Clojure platforms with only small changes. In >> particular, this feature aims to support the increasingly common case >> of libraries targeting both Clojure and ClojureScript. >> >> Code intended to be common across multiple platforms should use a new >> supported file extension: ".cljc". When requested to load a namespace, >> the platform-specific file extension (.clj, .cljs) will be checked >> prior to .cljc. >> >> A new reader form can be used to specify "reader conditional" code in >> cljc files (and *only* cljc files). Each platform defines a feature >> identifying the platform (:clj, :cljs, :cljr). The reader conditional >> specifies code that is read conditionally based on the feature/ >> >> Form #? takes a list of alternating feature and expression. These are >> checked like cond and the selected expression is read and returned. Other >> branches are unread. If no branch is selected, the reader reads nothing >> (not nil, but literally as if reading ""). An optional ":default" branch >> can be used as a fallthrough. >> >> Reader conditional with 2 features and a default: >> >> #?(:clj Double/NaN >> :cljsjs/NaN >> :default nil) >> >> There is also a reader conditional splicing form. The evaluated expression >> should be sequential and will be spliced into the surrounded code, similar >> to unqoute-splicing. >> >> For example: >> >>[1 2 #?@(:clj [3 4] :cljs [5 6])] >> >> This form would read as [1 2 3 4] on Clojure
Re: clojure, not the go to for data science
Would be good to get that on a wiki for all so we could update and share as a resourcee. Sayth On Mon, 6 Apr 2015 at 04:47 Christian Weilbach wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >> > > >> http://viewer.gorilla-repl.org/view.html?source=github&; > user=ghubber&repo=cnc&path=rincanter.clj > >> I am not sure whether this fits the design atm. though. I also > >> had a look at renjin, but I think the native plugins mandate an > >> RVM integration atm. > >> > > > > You might find http://beakernotebook.com interesting, if you > > haven't seen it before. It allows several languages in the same > > notebook, and has a simple mechanism for sharing data between the > > language environments. It's pretty green at the moment, but it has > > some serious backing, so could be pretty useful once it's got a bit > > more polish on it. I chatted a little with someone who was hoping > > to implement a Clojure plugin for it, although I don't know how > > they've gotten on since. > > This is really nice, thank you for pointing out! Effectively though > this means you need to manually(!) convert data between all cells, > which only works if serialization between the environments is a lot > less work than processing the data and you don't want to call alien > procedures e.g. in a loop. It also means that part of datasets need to > be hold in memory in all runtimes at the same time. So I am not sure > whether JSON synchronisation of state between runtimes is good in the > long run, it feels fairly hacky and having that many runtimes already > causes a big type-conversion matrix and probably many subtle > incompatibilities. It is the most pragmatic approach though and > probably the most successful for now. > > They are not opinionated about languages, while I would like to > integrate data science tooling in Clojure, so it is easier to bring > people on board, not to make language hopping the top goal, which is > for mentioned performance reasons and from a Lisp/Clojure perspective > a bit questionable imo (esp. since all these languages have to drop to > C to get some performance). I also would like to have the environment > written in Clojure (read: gorilla). I would be happy to integrate > Python and R on the JVM, e.g. through Jython and RServe/renjin, which > allows to share code much better down to direct method dispatch. Do > you think integrating R cells in this way would be reasonable for you? > Or just allowing plugins for new cell-types... > (With RServe manual synchronisation with the RVM is still necessary > btw., renjin would solve this, but needs more support for CRAN > packages imho). > > > > > I also have taken a paper I liked and implemented a quick version > > of > > > >> SNE, which was fairly nice to do in Gorilla REPL: > >> > >> http://viewer.gorilla-repl.org/view.html?source=github&; > user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj > >> A problem seems to be unicode support, I tried to use some math > >> symbols from the notation in the paper directly, but the viewer > >> seems to have a problem with it. > >> > > > > Not sure what the problem is there - my feeling is it should just > > work, on the Gorilla side. If there's a test case you can point to > > (with an expected result) I can take a look at it. > > The problem is just that viewer.gorilla-repl.org seems to have some > encoding problems with UTF-8. See the sum sigma symbol for instance: > https://github.com/ghubber/cnc/blob/master/stochastic- > neighbour-embedding.clj#L72 > which is corrupted in the viewer. I hoped that was easy to fix. > > > Christian > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5 > HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj > eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk > hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu > tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u > vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc= > =5QnK > -END PGP SIGNATURE- > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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/vsjUlAWm64g/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 subscrib
Re: Datomic namespaced idents question
Actually, in Datomic, the namespaces don't have any special meaning for the
database itself--you can choose to use whatever namespace (or even no
namespace)! Using namespaces is a convention to help you keep track of
which attributes belong to which entities.
We don't use a separate model layer for our systems--the Datomic APIs are
actually pretty rich when it comes to manipulating the system, between the
transactions as data and the entity API.
On Sunday, April 5, 2015 at 11:32:50 AM UTC-4, Stig Brautaset wrote:
>
> I have a question regarding using Datomic from Clojure, but I think it's
> more of a Clojure question than a Datomic question
>
> I understand that you must use namespaces in idents for logically distinct
> types of entities. (Unless you intend them to be lumped together in the
> same index.) Thus the :ids in two entities below don't conflict:
>
> {:foo/id 1
> :name "Name of a Foo"}
>
> {:bar/id 1
> :desc "Bar's don't have names, they have desc"}
>
> So far so good.
>
> My question is: do you expose this namespacing outside the model layer
> when working in Clojure? I'm inclined to say that this namespacing is an
> implementation detail of the database and so add/remove them in the model
> layer. I would love to hear your opinions.
>
> Stig
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Well, I must say I'm even more ignorant in how the feature expansions are implemented. Is the feature a thing that each implementation defines separately? If so, then it will be easy to set our fork's feature as :clja, or whatever else. My request to you would then be: can you please include :clja into the "spec", in the list of available features? What I ask for is sort of semi-official confirmation that Clojure-Android has its own feature, so that we would have easier time to include Android-specific code into the libraries that will become cross-platform after 1.7 goes live. Best regards, Alex On Monday, April 6, 2015 at 12:34:04 AM UTC+3, Alex Miller wrote: > > The reader can be invoked programmatically with any feature set you like > now. We did not plan to allow custom features for 1.7. > > I'm not sure what it would mean to "add" an android feature? I'll plead > ignorance in not knowing how the Clojure > Android stuff works or where a feature indicating Android could be set > without support for custom features. Do you currently fork to support > Android? > > > > On Apr 5, 2015, at 1:44 PM, Alexander Yakushev > wrote: > > Hello Alex, > > As I've understood from the dev.clojure.org page, additional features and > feature combinations will become available later. Can we please get > :clj/android (or :clja) still in 1.7? If so, what has to be done by me or > Daniel to make it happen? > > Thanks! > > On Tuesday, March 31, 2015 at 7:50:27 PM UTC+3, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] > > Regression fixes from previous alphas (and one from 1.6): > > 1) CLJ-1544 was rolled back and will be investigated for a future release. > 2) CLJ-1637 fixed regression with vec on MapEntry > 3) CLJ-1663 fixed regression in classloader (affected Cursive) > 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) > method > 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for > literal nil arg > 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that > prevented update > > Some highlights new in alpha6: > > ## Transducer-related changes: > > The LazyTransformer introduced to create lazy transforming sequences has > been > replaced with a TransformingIterator. This was done to simplify the code > around transformations and to make certain use cases around eduction more > efficient. > > ## Faster reduce, iterator, and sequence paths > > A lot of work has been done across a set of tickets to improve the ability > of > collections to provide more efficient reduce or iterator performance, and > also to > make common sequence generators create faster sequence and reduce paths. > You > should see significant performance in many reduce-related paths (this > includes > reduce, transduce, into, and anything else built on reduce). > > Many of those changes also have beneficial sequence performance, so you > may see > some benefits even in code that does not use transducers. > > * Most uses of SeqIterator have now been replaced with iterators that > directly walk > the underlying source for improved efficiency. This includes maps, sets, > records, etc. > * repeat - now returns a faster sequence with a fast reduce path > * cycle - now returns a faster sequence with a fast reduce path > * iterate - now returns a faster sequence with a fast reduce path > * range - (did not quite make it in, but coming soon...) > * keys - iterates directly over the keys of a map, without seq or MapEntry > allocation > * vals - iterates directly over the vals of a map, without seq or MapEntry > allocation > * iterator-seq - now creates a chunked sequence when previously it was > unchunked > * vec and set - were not changed in this release but were set up in a > previous alpha > to take advantage of the reduce and iterator changes above > > ## Reader conditionals > > Reader Conditionals is a new capability to support portable code that > can run on multiple Clojure platforms with only small changes. In > particular, this feature aims to support the increasingly common case > of libraries targeting both Clojure and ClojureScript. > > Code intended to be common across multiple platforms should use a new > supported file extension: ".cljc". When requested to load a namespace, > the platform-specific file extension (.clj, .cljs) will be checked > prior to .cljc. > > A new reader form can be used to specify "reader conditional" code in > cljc files (and *only* cljc files). Each platform defines a feature > identifying the platform (:clj, :cljs, :cljr). The reader conditional > specifies code that is read conditionally based on the feature/ > > Form #? takes a list of alternating feature and expression. These are > checked like cond and the selected expression is read and returned. Other > branches ar
Re: [ANN] Clojure 1.7.0-alpha6 released
On the other hand, Clojure-Android runtime is largely similar to regular Clojure except for some small differences; so in order to use feature expressions there effectively it might make sense to wait until broader capabilities (feature combinations, feature inheritance etc.) is introduced. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Yes, each platform defines their own platform feature so it wouldn't be too hard to change the specified platform in the fork. However the key here is that the conditional occurs at read time, so you need to ensure that compilation happens with this platform if aot is involved. Maybe that's obvious. The existing code in Clojure will not fail in unknown features so you would be able to read the same code in Clojure or Android. I'll ask Rich about a preferred feature name. > On Apr 5, 2015, at 5:44 PM, Alexander Yakushev wrote: > > Well, I must say I'm even more ignorant in how the feature expansions are > implemented. Is the feature a thing that each implementation defines > separately? If so, then it will be easy to set our fork's feature as :clja, > or whatever else. My request to you would then be: can you please include > :clja into the "spec", in the list of available features? What I ask for is > sort of semi-official confirmation that Clojure-Android has its own feature, > so that we would have easier time to include Android-specific code into the > libraries that will become cross-platform after 1.7 goes live. > > Best regards, > Alex > >> On Monday, April 6, 2015 at 12:34:04 AM UTC+3, Alex Miller wrote: >> The reader can be invoked programmatically with any feature set you like >> now. We did not plan to allow custom features for 1.7. >> >> I'm not sure what it would mean to "add" an android feature? I'll plead >> ignorance in not knowing how the Clojure >> Android stuff works or where a feature indicating Android could be set >> without support for custom features. Do you currently fork to support >> Android? >> >> >> >> On Apr 5, 2015, at 1:44 PM, Alexander Yakushev wrote: >> >> Hello Alex, >> >> As I've understood from the dev.clojure.org page, additional features and >> feature combinations will become available later. Can we please get >> :clj/android (or :clja) still in 1.7? If so, what has to be done by me or >> Daniel to make it happen? >> >> Thanks! >> >> On Tuesday, March 31, 2015 at 7:50:27 PM UTC+3, Alex Miller wrote: >> Clojure 1.7.0-alpha6 is now available. >> >> Try it via >> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ >> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] >> >> Regression fixes from previous alphas (and one from 1.6): >> >> 1) CLJ-1544 was rolled back and will be investigated for a future release. >> 2) CLJ-1637 fixed regression with vec on MapEntry >> 3) CLJ-1663 fixed regression in classloader (affected Cursive) >> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) >> method >> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for >> literal nil arg >> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that >> prevented update >> >> Some highlights new in alpha6: >> >> ## Transducer-related changes: >> >> The LazyTransformer introduced to create lazy transforming sequences has >> been >> replaced with a TransformingIterator. This was done to simplify the code >> around transformations and to make certain use cases around eduction more >> efficient. >> >> ## Faster reduce, iterator, and sequence paths >> >> A lot of work has been done across a set of tickets to improve the ability of >> collections to provide more efficient reduce or iterator performance, and >> also to >> make common sequence generators create faster sequence and reduce paths. You >> should see significant performance in many reduce-related paths (this >> includes >> reduce, transduce, into, and anything else built on reduce). >> >> Many of those changes also have beneficial sequence performance, so you may >> see >> some benefits even in code that does not use transducers. >> >> * Most uses of SeqIterator have now been replaced with iterators that >> directly walk >> the underlying source for improved efficiency. This includes maps, sets, >> records, etc. >> * repeat - now returns a faster sequence with a fast reduce path >> * cycle - now returns a faster sequence with a fast reduce path >> * iterate - now returns a faster sequence with a fast reduce path >> * range - (did not quite make it in, but coming soon...) >> * keys - iterates directly over the keys of a map, without seq or MapEntry >> allocation >> * vals - iterates directly over the vals of a map, without seq or MapEntry >> allocation >> * iterator-seq - now creates a chunked sequence when previously it was >> unchunked >> * vec and set - were not changed in this release but were set up in a >> previous alpha >> to take advantage of the reduce and iterator changes above >> >> ## Reader conditionals >> >> Reader Conditionals is a new capability to support portable code that >> can run on multiple Clojure platforms with only small changes. In >> particular, this feature aims to support the increasingly common case >> of libraries targeting both Clojure and ClojureScript. >> >> Code i
Re: clojure, not the go to for data science
Please feel free to create something like http://www.clojure-toolbox.com/ for data science in Clojure, that would be great. On Sunday, April 5, 2015 at 3:33:11 PM UTC-7, Sayth Renshaw wrote: > > Would be good to get that on a wiki for all so we could update and share > as a resourcee. > > Sayth > > On Mon, 6 Apr 2015 at 04:47 Christian Weilbach > wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> >> >> >> >> http://viewer.gorilla-repl.org/view.html?source=github&; >> user=ghubber&repo=cnc&path=rincanter.clj >> >> I am not sure whether this fits the design atm. though. I also >> >> had a look at renjin, but I think the native plugins mandate an >> >> RVM integration atm. >> >> >> > >> > You might find http://beakernotebook.com interesting, if you >> > haven't seen it before. It allows several languages in the same >> > notebook, and has a simple mechanism for sharing data between the >> > language environments. It's pretty green at the moment, but it has >> > some serious backing, so could be pretty useful once it's got a bit >> > more polish on it. I chatted a little with someone who was hoping >> > to implement a Clojure plugin for it, although I don't know how >> > they've gotten on since. >> >> This is really nice, thank you for pointing out! Effectively though >> this means you need to manually(!) convert data between all cells, >> which only works if serialization between the environments is a lot >> less work than processing the data and you don't want to call alien >> procedures e.g. in a loop. It also means that part of datasets need to >> be hold in memory in all runtimes at the same time. So I am not sure >> whether JSON synchronisation of state between runtimes is good in the >> long run, it feels fairly hacky and having that many runtimes already >> causes a big type-conversion matrix and probably many subtle >> incompatibilities. It is the most pragmatic approach though and >> probably the most successful for now. >> >> They are not opinionated about languages, while I would like to >> integrate data science tooling in Clojure, so it is easier to bring >> people on board, not to make language hopping the top goal, which is >> for mentioned performance reasons and from a Lisp/Clojure perspective >> a bit questionable imo (esp. since all these languages have to drop to >> C to get some performance). I also would like to have the environment >> written in Clojure (read: gorilla). I would be happy to integrate >> Python and R on the JVM, e.g. through Jython and RServe/renjin, which >> allows to share code much better down to direct method dispatch. Do >> you think integrating R cells in this way would be reasonable for you? >> Or just allowing plugins for new cell-types... >> (With RServe manual synchronisation with the RVM is still necessary >> btw., renjin would solve this, but needs more support for CRAN >> packages imho). >> >> > >> > I also have taken a paper I liked and implemented a quick version >> > of >> > >> >> SNE, which was fairly nice to do in Gorilla REPL: >> >> >> >> http://viewer.gorilla-repl.org/view.html?source=github&; >> user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj >> >> A problem seems to be unicode support, I tried to use some math >> >> symbols from the notation in the paper directly, but the viewer >> >> seems to have a problem with it. >> >> >> > >> > Not sure what the problem is there - my feeling is it should just >> > work, on the Gorilla side. If there's a test case you can point to >> > (with an expected result) I can take a look at it. >> >> The problem is just that viewer.gorilla-repl.org seems to have some >> encoding problems with UTF-8. See the sum sigma symbol for instance: >> https://github.com/ghubber/cnc/blob/master/stochastic- >> neighbour-embedding.clj#L72 >> which is corrupted in the viewer. I hoped that was easy to fix. >> >> >> Christian >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1 >> >> iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5 >> HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj >> eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk >> hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu >> tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u >> vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc= >> =5QnK >> -END PGP SIGNATURE- >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topi
Re: [ANN] Clojure 1.7.0-alpha6 released
Awesome, thanks for the help and the clarification! On Monday, April 6, 2015 at 1:59:21 AM UTC+3, Alex Miller wrote: > > Yes, each platform defines their own platform feature so it wouldn't be > too hard to change the specified platform in the fork. However the key here > is that the conditional occurs at read time, so you need to ensure that > compilation happens with this platform if aot is involved. Maybe that's > obvious. > > The existing code in Clojure will not fail in unknown features so you > would be able to read the same code in Clojure or Android. > > I'll ask Rich about a preferred feature name. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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?
In the blog post, tcrayford gives an example of the difficulties in
wrapping a kwargs function:
(defn my-wrapper [& kwargs]
(let [options (assoc (apply hash-map kwargs) :my-default-arg 1)]
(apply (your-api-fn (flatten (into '() options))
Sure, that's convoluted (and I couldn't actually get it to work on real
code).
But isn't this a much simpler way:
(defn my-wrapper [& kwargs]
(apply your-api-fn :my-default-arg 1 kwargs))
Am I overlooking something?
On Mon, Mar 23, 2015 at 5:55 AM, tcrayford wrote:
> Hi there,
>
> I feel pretty strongly about this - I *much* prefer using APIs with
> explicit options maps. The community is pretty divided though. I wrote up
> the tradeoffs (which are well discussed here as well), as well as a list of
> libraries using each style:
> http://yellerapp.com/posts/2015-03-22-the-trouble-with-kwargs.html
>
> To me, typing two extra characters ain't a big deal, but unrolling/rolling
> up maps and not being able to manipulate options easily is a bunch of pain,
> so I always choose explicit maps wherever possible.
>
> On Tuesday, 17 March 2015 06:42:37 UTC+9, Leon Grapenthin wrote:
>>
>> Kwargs has clearly been designed for one purpose: A caller should have to
>> type less.
>>
>> A simple rule to follow is to use kw args if the exposed thing is a
>> function not expected to be used in functional composition or a certain
>> DSLish kind of macro.
>>
>> If your exposed function will be used in functional composition more
>> often than called in typed out code, with kwargs you are using the feature
>> to its opposite purpose: People have to type even more.
>>
>> For an example, if your thing is called "load-config-file!" and is used
>> in one or two places of code, use kwargs by all means. If your thing is
>> called path-for and resolves an URL for a map of parameters, kwargs is a
>> very unfortunate choice.
>>
>>
>> On Saturday, April 26, 2014 at 12:41:22 AM UTC+2, Colin Fleming wrote:
>>>
>>> Hi all,
>>>
>>> I'm working on an API at the moment, and I'm balancing whether to use
>>> inline keyword args which I would destructure in the functions, or whether
>>> to just pass an explicit params map as the last parameter. Comparison of
>>> the two options in case I'm not explaining myself well:
>>>
>>> Kwargs:
>>> (class/create-class :instancelist
>>> :description "My description"
>>> :implements (keys class-methods)
>>> :methods (calculate-my-methods))
>>>
>>> Map:
>>> (class/create-class {:instancelist
>>> :description "My description"
>>> :implements (keys class-methods)
>>> :methods (calculate-my-methods)})
>>>
>>> A lot of APIs I've seen have favoured kwargs, and it undeniably makes
>>> for some pretty code - Seesaw is the best example I've seen here, the API
>>> is a thing of beauty. However it seems to me to have some issues:
>>>
>>>1. If I want to delegate to another call from within an API function
>>>and use the same arguments, it's really awkward: (apply delegate
>>>(mapcat identity args)) or some similarly awful black juxt magic. Or
>>>of course writing out all the parameters again, but that's even worse.
>>>2. It's more difficult to make parameters optional based on some
>>>runtime criteria since the params are baked into the function call. I
>>> guess
>>>this is usually dealt with by making the calls handle nil for a
>>> particular
>>>parameter.
>>>
>>> Both of these are much easier when passing an explicit map. Any
>>> preferences here, from either writing or using APIs like this?
>>>
>>> Cheers,
>>>
>>> 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.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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
Re: Kwargs vs explicit parameter map for APIs?
Yep: that won't override the arg if the caller passes it to you as well. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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, not the go to for data science
Yesyesyesyes! Great idea! I'm on it. On Sun, Apr 5, 2015 at 4:15 PM, A wrote: > Please feel free to create something like http://www.clojure-toolbox.com/ > for data science in Clojure, that would be great. > > On Sunday, April 5, 2015 at 3:33:11 PM UTC-7, Sayth Renshaw wrote: >> >> Would be good to get that on a wiki for all so we could update and share >> as a resourcee. >> >> Sayth >> >> On Mon, 6 Apr 2015 at 04:47 Christian Weilbach >> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> >> >>> >>> >> http://viewer.gorilla-repl.org/view.html?source=github&user= >>> ghubber&repo=cnc&path=rincanter.clj >>> >> I am not sure whether this fits the design atm. though. I also >>> >> had a look at renjin, but I think the native plugins mandate an >>> >> RVM integration atm. >>> >> >>> > >>> > You might find http://beakernotebook.com interesting, if you >>> > haven't seen it before. It allows several languages in the same >>> > notebook, and has a simple mechanism for sharing data between the >>> > language environments. It's pretty green at the moment, but it has >>> > some serious backing, so could be pretty useful once it's got a bit >>> > more polish on it. I chatted a little with someone who was hoping >>> > to implement a Clojure plugin for it, although I don't know how >>> > they've gotten on since. >>> >>> This is really nice, thank you for pointing out! Effectively though >>> this means you need to manually(!) convert data between all cells, >>> which only works if serialization between the environments is a lot >>> less work than processing the data and you don't want to call alien >>> procedures e.g. in a loop. It also means that part of datasets need to >>> be hold in memory in all runtimes at the same time. So I am not sure >>> whether JSON synchronisation of state between runtimes is good in the >>> long run, it feels fairly hacky and having that many runtimes already >>> causes a big type-conversion matrix and probably many subtle >>> incompatibilities. It is the most pragmatic approach though and >>> probably the most successful for now. >>> >>> They are not opinionated about languages, while I would like to >>> integrate data science tooling in Clojure, so it is easier to bring >>> people on board, not to make language hopping the top goal, which is >>> for mentioned performance reasons and from a Lisp/Clojure perspective >>> a bit questionable imo (esp. since all these languages have to drop to >>> C to get some performance). I also would like to have the environment >>> written in Clojure (read: gorilla). I would be happy to integrate >>> Python and R on the JVM, e.g. through Jython and RServe/renjin, which >>> allows to share code much better down to direct method dispatch. Do >>> you think integrating R cells in this way would be reasonable for you? >>> Or just allowing plugins for new cell-types... >>> (With RServe manual synchronisation with the RVM is still necessary >>> btw., renjin would solve this, but needs more support for CRAN >>> packages imho). >>> >>> > >>> > I also have taken a paper I liked and implemented a quick version >>> > of >>> > >>> >> SNE, which was fairly nice to do in Gorilla REPL: >>> >> >>> >> http://viewer.gorilla-repl.org/view.html?source=github&user= >>> ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj >>> >> A problem seems to be unicode support, I tried to use some math >>> >> symbols from the notation in the paper directly, but the viewer >>> >> seems to have a problem with it. >>> >> >>> > >>> > Not sure what the problem is there - my feeling is it should just >>> > work, on the Gorilla side. If there's a test case you can point to >>> > (with an expected result) I can take a look at it. >>> >>> The problem is just that viewer.gorilla-repl.org seems to have some >>> encoding problems with UTF-8. See the sum sigma symbol for instance: >>> https://github.com/ghubber/cnc/blob/master/stochastic-neighb >>> our-embedding.clj#L72 >>> which is corrupted in the viewer. I hoped that was easy to fix. >>> >>> >>> Christian >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1 >>> >>> iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5 >>> HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj >>> eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk >>> hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu >>> tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u >>> vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc= >>> =5QnK >>> -END PGP SIGNATURE- >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://group
Re: Kwargs vs explicit parameter map for APIs?
That explains it. In the type of stuff I write, that possibility wouldn't arise: there is no calling code that I can't control, and I definitely want the ability to change my wrapper's default. In any case, I realized the reason your blog code didn't run was an error: you need to change (apply (your-api-fn ... to (apply your-api-fn ... On Sun, Apr 5, 2015 at 7:46 PM, tcrayford wrote: > Yep: that won't override the arg if the caller passes it to you as well. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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.
