Gradle: how to deal with it
Hello I use to press M-. in Emacs to jump to the definition of a function and M-, to jump back to where I came from This requires an nREPL to be working Now I'd like to explore a project using Gradle. Can I get an nREPL with Gradle ? Can Gradle export a project file so that I can use lein to have an nREPL ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: data.xml namespace aware?
test_namespace.clj just contains some unit tests for now. The final patch
will have usage examples.
With the proposal, you can define your xml namespaces on a
clojure-namespace level and refer them via keyword namespaces:
(ns thing)
(xml-default-prefix *ns* thing)
(xml-prefix *ns*
thing http://thing;)
(def e4 (xml/sexp-as-element
[::first {} [::second {}]]))
This improves on handling raw xml-prefixes in two ways:
- The full xml namespace http://thing; is known for an xml name like
::first, ::second, not just the prefix you happened to assign in code.
- You can combine xml fragments from different parts of code, without
worrying about prefix assignment. The emitter takes care of assigning xmlns
declarations.
cheers
2014-05-10 0:22 GMT+02:00 Timothy Washington twash...@gmail.com:
Thanks Herwig. I take it
test_namespace.cljhttps://github.com/bendlas/data.xml/blob/master/src/test/clojure/clojure/data/xml/test_namespace.cljis
the interesting file. Given the example in my previous message, is there
a more idiomatic way of defining namespaces with this proposal?
Thanks again
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
On Thu, May 8, 2014 at 10:54 AM, Herwig Hochleitner
hhochleit...@gmail.com wrote:
Hi,
I'm the guy working on the newer proposal, which is almost done (TM). It
seems you have found the way to emulate namespacing with the current
data.xml impl: by taking care of xmlns attributes and prefixes yourself. I
definitely want to keep compatibility with that representation. Feel free
to check out my proposal branch here https://github.com/bendlas/data.xml
cheers
2014-05-06 21:53 GMT+02:00 Timothy Washington twash...@gmail.com:
Ok, scratch that. I got it working, lol :)
Sorry for the false alarm. For future reference, this:
(def e4 (xml/sexp-as-element
[:thing:first {:xmlns:thing http://thing}
[:thing:second {}]]))
...gives you this:
user (process/print-esequel process/e4)
?xml version=1.0 encoding=UTF-8?
thing:first xmlns:thing=http://thing;
thing:second/
/thing:first
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
On Tue, May 6, 2014 at 3:45 PM, Timothy Washington
twash...@gmail.comwrote:
Got a bit further here. I want to be able to get tag namespaces without
a :root tag (that includes the namespace definition). Assume the below code
has (require '[clojure.data.xml :as xml]).
Working with attributes is fine.
(def e1 (xml/element :use {:xmlns:xlink http://testing;,
:xlink:href #whiskers,
:transform scale(-1 1) translate(-140 0)}))
Namespace prefixes is possible with tags; however, I had to add the
unwanted :root tag (that includes ns definition)
(def e2 (xml/element :root {:xmlns:thing http://thing}
(xml/element :thing:use {})))
(def e3 (xml/element :root {:xmlns:thing http://thing}
(xml/sexp-as-element
[:thing:first {}
[:thing:second {}]])))
(defn print-esequel [elem]
(println (xml/indent-str elem)))
The resulting XML is close. But we want the tag namespaces, without the
root node
user (print-esequel process/e2)
?xml version=1.0 encoding=UTF-8?
root xmlns:thing=http://thing;
thing:use/
/root
user (print-esequel process/e3)
?xml version=1.0 encoding=UTF-8?
root xmlns:thing=http://thing;
thing:first
thing:second/
/thing:first
/root
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
On Tue, May 6, 2014 at 3:24 PM, Timothy Washington
twash...@gmail.comwrote:
Hi there,
*A)* I'm just writing some SOAP XML, trying to use
data.xmlhttps://github.com/clojure/data.xml.
This SO
threadhttp://stackoverflow.com/questions/10868050/clojure-data-xml-create-key-named-xlinkhref
outlines
how to write out namespace aware XML. But the example is for a namespace
on
an attribute. I'm combing through the code now, but does anyone know how
to
set this up?
*B)* There's actually this Fuller XML
Supporthttp://dev.clojure.org/display/DXML/Fuller+XML+supportproposal
(referring to this
threadhttps://groups.google.com/forum/#!msg/clojure-dev/3_jkBrdQKgs/dUwtevWqlwkJ),
and this Namespaced
XMLhttp://dev.clojure.org/display/DXML/Namespaced+XMLproposal. But I
don't see that namespaces are fully implemented in any of
the core libs.
I only see this ArmageDOM https://github.com/pepijndevos/ArmageDOMlib,
which supports namespaces. Anything else out there that I've missed?
Thanks
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
Re: Headless server, no GUI, no idea
I was running it as displayed but, I get the same result under sudo. For sh, I can't resolve: $ su - sh -e /etc/init.d/xvfb start *su: invalid option -- 'e'* -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Headless server, no GUI, no idea
This line also fails: $ sudo sh -e /etc/init.d/xvfb start *sh: 0: Can't open /etc/init.d/xvfb* -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: What is the status of Clojure on LLVM or C?
Hi, How about to port Clojure on top of golang? To get Clojure running on LLVM some of the ideas could be maybe looked from http://julialang.org/. Mic On Thursday, March 28, 2013 6:05:03 AM UTC+10, Joe Graham wrote: Hi Group, Good afternoon I hope everyone is well. I just wanted to reach out to this group and get the current status of Clojure today on the LLVM compiler or C based implementation? Has anyone looked into a Julia implementation? Just trying to get a roadmap on the main forks before searching on every permutation of this question. Thanks so much for your help and valuable input of this group. BR_joe -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Gradle: how to deal with it
I'm in the process of writing up a procedure for the latest cider with alternative repls. Here's the relevant bits of how leiningen starts a repl: https://github.com/technomancy/leiningen/blob/master/src/leiningen/repl.clj#L116 https://github.com/technomancy/leiningen/blob/master/src/leiningen/repl.clj#L131 Don't be scared by the quoting stuff. Essentially, it has to build up a nrepl handler using the 'middlewares' defined in the project.clj (you won't have one of those). Then it passes that handler to clojure.tools.nrepl.server/start-server. That impl is here: https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L121 If you're using the latest melpa cider (0.7.0alpha), you'll have to futz with middlewares (the leiningen plugin would normally take care of this for you), I haven't yet tested this myself. On Sat, May 10, 2014 at 7:00 AM, Catonano caton...@gmail.com wrote: Hello I use to press M-. in Emacs to jump to the definition of a function and M-, to jump back to where I came from This requires an nREPL to be working Now I'd like to explore a project using Gradle. Can I get an nREPL with Gradle ? Can Gradle export a project file so that I can use lein to have an nREPL ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Nominalization
That's interesting. I haven't learned about reductions yet—I'll check it out. If you consider the following, (defn dot-product [v1 v2] (reduce + (map * v1 v2))) perhaps dot-product would be considered a noun, while since the reduce it is defined in terms of speaks of *how* instead of *what,* is better though of as a verb. I find the concept of the elimination of time interesting. The expression (reduce + (map * [1 2 3] [5 0 1])) brings to mind a tiny machine, while (dot-product [1 2 3] [5 0 1]) feels like a *thing*. But, they both are simply the thing: 8 and perhaps both could be evaluated at compile time, eliminating the time-based machine that mentally cranks away while reduce and map “run.” On Saturday, May 10, 2014 12:52:34 AM UTC-4, Gary Trakhman wrote: Never thought of it that way, I always verb the noun. Did you learn about reductions, yet? It's clear that the name corresponds to the intended output at least in that case. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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)
We can see from this discussion that several strongly opinionated visions of what documentation should be coexist. Some want literate programming whereas others want to avoid it, some want something that looks like javadoc, some just want markdown, etc. I think we can just make room for all of these views. Let's start by providing functionality for creating and viewing neutral, structured, extensible documentation content. I think both Markdown and raw strings are too weak for that; I'd rather make a more sophisticated language/data structure and then translate Markdown or docstrings or whatever into it. Then we can create more pleasant programmatic interfaces on top of it, to achieve the goals of simplicity and of the more opinionated paradigms. That's my reason for wanting to make this in Clojure data structures in the first place; as long as we have the benefits of Clojure's great programming features, we can mostly avoid having to make tradeoffs between available functionality and desired usage, and that's *good*. Let's not make anything opinionated mandatory or standard until usage has proven it. Also, I agree that we need better formalism and categorization for reasoning about technical documentation. Very good things were said in the Deep Thinkinghttps://groups.google.com/forum/?hl=fr#!searchin/clojure/deep$20thinking/clojure/YOeQVUWhUtA/f917yFk5NIoJthread on this topic. I see there are a few books in the field, I'll try to dig into these. Le mercredi 7 mai 2014 05:16:16 UTC+2, da...@axiom-developer.org a écrit : Gregg, I realize that literate programming isn't going to catch on in the Clojure community any time soon. LP shared the epiphany feature of Lisp. That is, you don't get it until the AH HA! moment, and then you wonder why anyone programs any other way. You can't get the Lisp AH HA! without writing Lisp, so many Java programmers will never get Clojure. You can't get LP without writing LP, so many programmers will never get LP. Oh well. I am trying to refocus on the goal of deep thinking the documentation problem in Clojure. My more recent posts have moved on from LP and have been focused on finding criteria to judge whether proposed solutions actually address useful goals. Parent tried to do that in his thesis. See my prior post. There are many different audiences that need Clojure documentation. Some are core maintainers who have to understand the Java code. Some are programmers who need to understand the language. Some are library maintainers who need to explain their use case. Some are people who join a company using Clojure. Some are language designers who need to understand principles like immutability, simplicity, STM, etc. There are thousands of useful programs in github. Most of them are dead because the original programmers are gone and nobody knows their use case nor how to maintain and modify them. Once the original team moves on even popular projects die. Even programs written by famous people with huge amounts of influence die. Witness Arc by Paul Graham, or Pascal which took over the world in the last century. Without Rich, wither Clojure? I really like Clojure and I want it to live. I believe that unless we focus SOME effort on making it easy to maintain, modify, use, and understand then Clojure will suffer the fate of Pascal, Arc, and that ilk. To my knowledge neither Knuth nor anybody else has ever produced a shred of evidence in support of this kind of claim. I can't speak to your knowledge but there are numerous examples. As to the cited stackoverflow claim that LP is not used in projects or teaching... Here is PROJECT example from SAGE, a python-based computer algebra system in Number Theory: Another thing I've been enjoying lately is literate programming. Amazingly it turns out to be faster to write a literate program than an ordinary program because debugging takes almost no time. -- Bill Hart, SAGE Mailing list, May 3, 2010 Here is a TEACHING example from Spring 2014: John Kitchin is a professor of Chemical Engineering at CMU. He is teaching CMU students to use literate programming and uses it in all of his courses. He recently gave a talk at PyCon http://www.youtube.com/watch?v=1-dUkyn_fZA Are you saying the core Clojure team is rewriting Clojure in *classic* litprog style? That would flabber my gast, to put it mildly. No, the core Clojure team is NOT rewriting Clojure in *classic* litprog style. I am, with the help of others. See PDF: http://daly.axiom-developer.org/clojure.pdf SRC: http://daly.axiom-developer.org/clojure.pamphlet If you follow the instructions you can type 'make' which extracts Clojure source code, compiles it, extracts and runs the test cases, and puts you into a REPL. It also re-creates the PDF. The
Re: Proposing a new Clojure documentation system (in Clojure)
Here :https://docs.google.com/spreadsheets/d/1HyS9qstgEqmdv0MtDm3xEsImnDjCYQhar1PQP3fzwMc/edit?usp=sharingI think it would help if we had a panoramic view of the existing documentation systems and what we could borrow from them. I could only think of a Google Drive spreadsheet for this, but if anyone has a better idea... :) So it would be nice if people who are knowledgeable about other doc systems could contribute to it. From what I see, that may involve Tim for Emacs, Sean for reStructured, and Daniel for docco, for example? Thanks in advance! Le 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 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 relevant concepts tend not to be obvious in the code. Since in Clojure we program with verbs, not nounshttp://steve-yegge.blogspot.fr/2006/03/execution-in-kingdom-of-nouns.html, I think *documentation is best made by example*. 4. Documentation of a Var should not be a formal description of what it is and what it does with some cryptically-named variables. *Every bit of documentation should be a micro-tutorial*. Emphasis should be put on usage, examples, tips, pitfalls, howtos. 5. There should be structure in the documentation, and it shouldn't be just :see-also links - *there should be semantics* in it. For example, some functions/macros are really meant to be nothing but shorthands for calling other functions : that kind of relationship should be explicitly documented. 6. Documentation should not be just information about each separate Var in a namespace. There should be a hierarchy to make the most useful elements of an API more obvious. Also, adding cross-vars documentation elements such as tags and topics could make it easier to navigate and understand. 7. *Documentation in the REPL is great*, it was one of the very good surprises when I started learning Clojure. However, a rich and good-looking presentation like in Javadocs would be welcome too. Of course, all of the above are just vague principles. Here is *some functionality I suggest for a start :* 1. Documentation content elements could be written in a Clojure DSL emulating some kind of docbook-like markup language. 2. On the user side, the documentation would be accessible through a generated web interface, a REPL interface, and maybe other formats like Wiki. 3. Documentation could be programmed anywhere in a project by simply referring to the relevant Vars and calling the
Re: Proposing a new Clojure documentation system (in Clojure)
If you plan on having this documentation apply to clojure.core.* you'll probably want to pull in Alex Miller or start a conversation in clojure-dev. I'd hate to see a bunch of decisions made, just to find out that Rich has a completely different view, a view that might have been nice to know before plans were finalized. Or perhaps a metadata modification system can be created? One that allows people to import clojure libs that adds new doc data to existing vars? Timothy On Sat, May 10, 2014 at 7:44 AM, Val Waeselynck val.vval...@gmail.comwrote: Here :https://docs.google.com/spreadsheets/d/1HyS9qstgEqmdv0MtDm3xEsImnDjCYQhar1PQP3fzwMc/edit?usp=sharingI think it would help if we had a panoramic view of the existing documentation systems and what we could borrow from them. I could only think of a Google Drive spreadsheet for this, but if anyone has a better idea... :) So it would be nice if people who are knowledgeable about other doc systems could contribute to it. From what I see, that may involve Tim for Emacs, Sean for reStructured, and Daniel for docco, for example? Thanks in advance! Le 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 Clojure https://github.com/weavejester/hiccup than 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 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 relevant concepts tend not to be obvious in the code. Since in Clojure we program with verbs, not nounshttp://steve-yegge.blogspot.fr/2006/03/execution-in-kingdom-of-nouns.html, I think *documentation is best made by example*. 4. Documentation of a Var should not be a formal description of what it is and what it does with some cryptically-named variables. *Every bit of documentation should be a micro-tutorial*. Emphasis should be put on usage, examples, tips, pitfalls, howtos. 5. There should be structure in the documentation, and it shouldn't be just :see-also links - *there should be semantics* in it. For example, some functions/macros are really meant to be nothing but shorthands for calling other functions : that kind of relationship should be explicitly documented. 6. Documentation should not be just information about each separate Var in a namespace. There should be a hierarchy to make the most useful elements of an API more obvious. Also, adding cross-vars documentation elements such as tags and topics could make it easier to navigate and understand. 7. *Documentation in the REPL is great*, it was one of the very good surprises when I started learning Clojure. However, a rich and good-looking presentation like in Javadocs would be welcome too.
Re: Headless server, no GUI, no idea
When you use sudo or su, I don't think you need sh (or another shell). On Sat, May 10, 2014 at 7:35 PM, stiffyrabbit jr deliverebay...@googlemail.com wrote: This line also fails: $ sudo sh -e /etc/init.d/xvfb start *sh: 0: Can't open /etc/init.d/xvfb* -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Expected inconsistency between set and map w/ ArrayList?
Thanks for the ticket pointer. I didn't find it in my initial search
because it Affects Version/s: None :-/, and I knew this behavior was new
to 1.6.
For those not up for the medium-length comment-thread read:
non-Clojure-aware Java Collections Framework interface instances are not
considered values,* and 'Rich says all bets should be off for hasheq/equiv
of non-values.' That's a bit down in the details, but I think the upshot
is that they're not currently supported as set members or hash keys.
Unfortunately they used to be supported (unintentionally, I guess) due to
Clojure following Java's lead, so I have some interop-heavy code to review
and test very carefully. Though the above seems to frame non-support as
based on principle, it seems the driver is keeping the new hasheq stuff
highly performant. I would hope a performant implementation that supported
the Collections interfaces would be accepted for some future version.
*If there is one, I'd like to read a clear definition of what values
means in Clojure. The headings on http://clojure.org/data_structures are
almost an enumeration of them, except the Collections section talks a
little about Java Collections classes, hashCode, and hasheq without making
it clear that non-Clojure collections are not values. Unfortunately the
current definition seems to admit only the Java primitives and
near-primitives (String and primitive wrappers) and clojure-aware types.
What not supported looks like via maps:
user *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}
user (hash-map [1 2] v (java.util.ArrayList. [1 2]) a)
{[1 2] a, [1 2] v}
user {[1 2] v (java.util.ArrayList. [1 2]) a}
IllegalArgumentException Duplicate key: [1 2]
clojure.lang.PersistentArrayMap.createWithCheck
(PersistentArrayMap.java:70)
user (- {} (assoc [1 2] v) (assoc (java.util.ArrayList. [1 2]) a))
{[1 2] a}
On Friday, May 9, 2014 6:34:26 PM UTC-5, Andy Fingerhut wrote:
Mike is correct. This change in behavior is due to the hashing changes in
Clojure 1.6. See the comments on ticket
http://dev.clojure.org/jira/browse/CLJ-1372 for some discussion of
whether this is considered a bug. It appears that perhaps the hash
consistency is not promised for mutable objects, only immutable ones.
Below are a couple more REPL transcripts that illustrate the change in
behavior:
user= *clojure-version*
{:major 1, :minor 5, :incremental 1, :qualifier nil}
user= (= [1 2] (java.util.ArrayList. [1 2]))
true
user= (map hash [ [1 2] (java.util.ArrayList. [1 2]) ])
(994 994)
user= (hash-map [1 2] vec (java.util.ArrayList. [1 2]) alist)
{[1 2] alist}
user= *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}
user= (= [1 2] (java.util.ArrayList. [1 2]))
true
user= (map hash [ [1 2] (java.util.ArrayList. [1 2]) ])
(156247261 994)
user= (hash-map [1 2] vec (java.util.ArrayList. [1 2]) alist)
{[1 2] alist, [1 2] vec}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Headless server, no GUI, no idea
And it doesn't work, using sudo. Can anybody break me out of this cycle? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Licensing program written in Clojure under GPL
I have written a Clojure library A which is licensed under Eclipse Public License (EPL) as usual which depends on other Clojure libraries with EPL license. In a different program B I use library A and another library G which is licensed under GPLv3. Now, the question arises which license I am allowed to use (or even must use) for program B. As far as I have read it is not possible to license B under EPL because library G is licensed under GPLv3. Leaving the only option to license program B under GPLv3 - does that sound correct to 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: Gradle: how to deal with it
You should use Clojuresque [1]. The latest version (1.7.0) can start an nrepl server for you. Since I'm a bad user (and because of various dependency-related hurdles at work), I still haven't actually started using it though. Luckily, with earlier versions it's pretty easy to define a new task that starts an nrepl server. Here's an example: https://github.com/Netflix/RxJava/blob/master/language-adaptors/rxjava-clojure/build.gradle#L55 With Cider 0.6.0, you can just M-X cider and connect. If you have the latest alpha, well, good luck getting back to 0.6.0. For ac-nrepl auto-complete you'll want to add clojure-complete [2] as a dependency as well. Good luck, Dave [1] https://bitbucket.org/clojuresque/clojuresque [2] https://clojars.org/clojure-complete On Sat, May 10, 2014 at 4:00 AM, Catonano caton...@gmail.com wrote: Hello I use to press M-. in Emacs to jump to the definition of a function and M-, to jump back to where I came from This requires an nREPL to be working Now I'd like to explore a project using Gradle. Can I get an nREPL with Gradle ? Can Gradle export a project file so that I can use lein to have an nREPL ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Proposing a new Clojure documentation system (in Clojure)
Le samedi 10 mai 2014 16:09:11 UTC+2, tbc++ a écrit : If you plan on having this documentation apply to clojure.core.* you'll probably want to pull in Alex Miller or start a conversation in clojure-dev. I'd hate to see a bunch of decisions made, just to find out that Rich has a completely different view, a view that might have been nice to know before plans were finalized. Or perhaps a metadata modification system can be created? One that allows people to import clojure libs that adds new doc data to existing vars? Actually, I was thinking of making something that is completely external to the metadata map, so as to make it nonintrusive. A bit like a test library. Timothy On Sat, May 10, 2014 at 7:44 AM, Val Waeselynck val.v...@gmail.comjavascript: wrote: Here :https://docs.google.com/spreadsheets/d/1HyS9qstgEqmdv0MtDm3xEsImnDjCYQhar1PQP3fzwMc/edit?usp=sharingI think it would help if we had a panoramic view of the existing documentation systems and what we could borrow from them. I could only think of a Google Drive spreadsheet for this, but if anyone has a better idea... :) So it would be nice if people who are knowledgeable about other doc systems could contribute to it. From what I see, that may involve Tim for Emacs, Sean for reStructured, and Daniel for docco, for example? Thanks in advance! Le 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 Clojure https://github.com/weavejester/hiccup than 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 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 relevant concepts tend not to be obvious in the code. Since in Clojure we program with verbs, not nounshttp://steve-yegge.blogspot.fr/2006/03/execution-in-kingdom-of-nouns.html, I think *documentation is best made by example*. 4. Documentation of a Var should not be a formal description of what it is and what it does with some cryptically-named variables. *Every bit of documentation should be a micro-tutorial*. Emphasis should be put on usage, examples, tips, pitfalls, howtos. 5. There should be structure in the documentation, and it shouldn't be just :see-also links - *there should be semantics* in it. For example, some functions/macros are really meant to be nothing but shorthands for calling other functions : that kind of relationship should be explicitly documented. 6. Documentation should not be just information about each separate Var in a namespace. There should be a hierarchy to make the most useful elements of an API more obvious. Also, adding cross-vars
Find source/location of anonymous function by name
Hi, Say I'm getting an ArityException Wrong number of args (2) passed to: myparser/fn--106751 exception. Unfortunately the code is quite heavy on the higher order side, so the stack trace doesn't reveal anything useful, especially since the exception is thrown by the `apply` before, so I'm not even getting line number information. And I don't really want to read a mile of traces or step through every call of `apply`. Is there a direct way to get the source location information, like the stack-trace-printer seems to do, just from the generated name of a closure like myparser/fn--106751? It's not defined as a var, so (source) doesn't work. Cheers, -- pascal -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 source/location of anonymous function by name
Have you tried naming the anonymous functions that might be culprits? (fn trace-me [..] ...) Thanks, Ambrose On Sun, May 11, 2014 at 1:33 AM, Pascal Germroth funkyco...@gmail.comwrote: Hi, Say I'm getting an ArityException Wrong number of args (2) passed to: myparser/fn--106751 exception. Unfortunately the code is quite heavy on the higher order side, so the stack trace doesn't reveal anything useful, especially since the exception is thrown by the `apply` before, so I'm not even getting line number information. And I don't really want to read a mile of traces or step through every call of `apply`. Is there a direct way to get the source location information, like the stack-trace-printer seems to do, just from the generated name of a closure like myparser/fn--106751? It's not defined as a var, so (source) doesn't work. Cheers, -- pascal -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Licensing program written in Clojure under GPL
Do you want to distribute binaries (.class files) of the program B? If not, you may license your sources in any license you want. If yes, then it will be possible only if the library G has a linking exception in its license [1], as the clojure itself is EPL so it does not matter how the library A is licensed. Without linking exception you cannot distribute the combined work from EPL and GPL sources [2] [3]. [1] http://en.wikipedia.org/wiki/GPL_linking_exception [2] https://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE [3] http://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/ Jozef On Sat, May 10, 2014 at 5:44 PM, Gunnar Völkel gunnar.voel...@googlemail.com wrote: I have written a Clojure library A which is licensed under Eclipse Public License (EPL) as usual which depends on other Clojure libraries with EPL license. In a different program B I use library A and another library G which is licensed under GPLv3. Now, the question arises which license I am allowed to use (or even must use) for program B. As far as I have read it is not possible to license B under EPL because library G is licensed under GPLv3. Leaving the only option to license program B under GPLv3 - does that sound correct to 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Rethinking Literate Programming
I think we all know this, but just to make sure the point is clear (in some of the dicussion here, it doesn't seem that it is), the alternatives are not only: (a) Source code with docstrings (or fancy formatted docstrings with links, etc.) and sparse comments, but no other explanatory text anywhere. (b) Literate programming. Of course long chunks of text are needed to explain algorithms, motivation, paths not taken, etc. Literate programming requires that those chunks be inserted into the source file, and that you have to run the source file through a filter to get rid of them. Here's how I have been working lately: Early in the process of developing a section of code, I often insert long comments to explain what I'm doing or what I intend to do, etc. Like literate code, but with comment characters in front of it. Eventually, I look at the source file and think, That long comment is cluttering up the code. I have to scroll down to often to see what's going on in the code. Then I put the long comment into a separate file, (perhaps a file that already contains some explanatory text), strip the comment characters, and maybe add some markdown or write some additional text. I leave some essential comments in the text, or put information into docstrings if it seems appropriate. The point is that these days, at least, I don't *want* a lot of text in the file that contains my source code, even though I think that explanatory documentation is *very* important, and even though I'd guess that I've written more of it per line of code than the average programmer. But that's me. Others find LP extremely beneficial, and I support that strategy for those who like it. (The desire to be able to see a lot of code at once is also one reason why C-style code formatting is undesirable in a lisp language.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 source/location of anonymous function by name
On 10 May 2014, at 18:36, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Have you tried naming the anonymous functions that might be culprits? (fn trace-me [..] ...) Yes, that turned out to be the quickest way, naming everything with a vim command: :%s/fn \[/\=fn TRACE- . line(.) . [/g Fixing the bug, and then just removing the names again: :%s/TRACE-[0-9]* //g But I'm still interested if there's a pure clojure generated-name to location solution I could just call from the REPL. Cheers, -- pascal -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Rethinking Literate Programming
I think we all know this, but just to make sure the point is clear (in some of the dicussion here, it doesn't seem that it is), the alternatives are not only: (a) Source code with docstrings (or fancy formatted docstrings with links, etc.) and sparse comments, but no other explanatory text anywhere. (b) Literate programming. Actually, lisp has a long tradition of semicolon-style comments where Chapter ;;; Section ;; Subsection ;Paragraph or inline With some Emacs hacking it would be possible to fold/unfold these comments. I worked on a Transputer editor that had fold/unfold and it was reasonably useful. I believe Emacs org-mode can also hide comments on command. Michael Fogus (The Joy of Clojure) is a better org-mode resource. John Kitchin (CMU professor) shows org-mode in his talk: http://www.youtube.com/watch?v=1-dUkyn_fZA I'm a software blacksmith and tend to create my own tools from scratch so I can't give advice on org-mode, IDEs or other store-bought solutions. :-) Of course long chunks of text are needed to explain algorithms, motivation, paths not taken, etc. Literate programming requires that those chunks be inserted into the source file, and that you have to run the source file through a filter to get rid of them. ...[snip]... The point is that these days, at least, I don't *want* a lot of text in the file that contains my source code, even though I think that explanatory documentation is *very* important, and even though I'd guess that I've written more of it per line of code than the average programmer. But that's me. Others find LP extremely beneficial, and I support that strategy for those who like it. (The desire to be able to see a lot of code at once is also one reason why C-style code formatting is undesirable in a lisp language.) I used comment-style documentation method in my youth. I created a language, called KROPS, which was the implementation language for a large expert system. It was pure lisp on a Symbolics machine so there were no other documentation tools. This limited the style of comments to the conventions mentioned above. Returning to the code many years later (which is where LP really pays off) the comments were extremely helpful but not sufficient. KROPS uses a circular, self-modifying data structure which prints as a single, solid block of code. Documenting and diagraming this structure is necessary to understand it. ASCII tools are not sufficient for the diagrams but the current tools are. The code sat in long non-comment stretches. The comments that did exist tended to follow the semicolon style mentioned above. Overall the code follows a book-like convention but used pure source code. Snippets are attached below to show the style. Things to note are * The use of #|..|# (Common Lisp has 2 comment delimiter styles) * Higher organization of the comments - an intro to check that it works - a table of contents - the use of levels of semicolon structure - the use of docstrings on functions - the use of UPPERCASE in docstrings to highlight symbol names - the use of inline semicolons Not shown are long uninterrupted stretches of code containing only the docstring/uppercase and a few inline comments. So it is possible to do some form of reasonably well documented programming that is somewhat structured, involving only some discipline on commenting style. #| ;; KROPS in common lisp ;; ;; Trivial test: ;; ;; initialize the system: ;;(PS-INITIALIZE) ;; ;; define the class TEST: ;;(LITERALIZE TEST A=) ;; ;; create one rule: ;;(P ASDF WHEN (TEST A= 1) THEN (PRINT IT WORKS)) ;; ;; create one working memory element: ;;(MAKE TEST A= 1) ;; ;; look for the rule to fire: ;;(CS) == NIL.ASDF ;; ;; run one rule: ;;(RUN) == IT WORKS ;; ; STRUCTURE OF THIS FILE: ; 1.0 PACKAGE INFORMATION ; 2.0 VERSION VARIABLE ; 3.0 CHANGE LIST ; 4.0 IMPLEMENTATION PATCHES ; 5.0 DATA STRUCTURE DOCUMENTATION ; 5.1 RETE DATA STRUCTURES ; 5.1.1 R-NODE ; 5.1.2 NODES IN THE ALPHA RETE ;5.1.2.1 R-A-PLAIN ;5.1.2.2 R-A-OR ;5.1.2.3 R-A-TRIG ;5.1.2.4 R-B-A-DISTR ; 5.1.3 NODES IN THE BETA RETE ;5.1.3.1 R-B-JOIN ;5.1.3.2 R-B-SORT (sorted memory node) ;5.1.3.3 R-B-P (PRODUCTION) NODES ; 5.1.4 OTHER DATA STRUCTURES ;5.1.4.1 R-CS (A conflict set element) ;5.1.4.2 R-B-COMMON (the vector portion of an R-B-JOIN node) ;5.1.4.3 R-B-P-C (the vector portion of an R-B-P node) ;5.1.4.4 R-B-ACC (an access vector) ; 5.1.5 MEMORIES ;5.1.5.1 R-MEM (Rplacdable memory header) ;5.1.5.2 R-MEM-ITEM (an element of R-MEM) ;5.1.5.3 R-MEM-SORT (sorted memory) ;5.1.5.4 R-UNIQUE ; 5.2 PARSER DATA STRUCTURES ; 5.2.1 INPUT SYNTAX ; 5.2.2 *RULE* ; 5.2.3 INTERNAL DATA STRUCTURES ;5.2.3.1 PREDICATE ;5.2.3.2 ORLIST ;5.2.3.3 ANDLIST ;5.2.3.4 TERM ;
Re: Expected inconsistency between set and map w/ ArrayList?
On Sat, May 10, 2014 at 7:51 AM, John Hume duelin.mark...@gmail.com wrote: Thanks for the ticket pointer. I didn't find it in my initial search because it Affects Version/s: None :-/, and I knew this behavior was new to 1.6. I changed Affects Version/s to Release 1.6 Whether that field is filled in for any particular ticket depends on the choice of the person creating the ticket, in most cases, although occasionally others will edit that field after that. Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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)
It is pretty easy to make a library that modifies doc metadata on existing vars, e.g.: https://github.com/jafingerhut/thalia The time-consuming part, which I am nowhere near completing myself, is writing the alternate documentation strings. Congrats to anyone that produces something that becomes widely used. I would suggest doing whatever suits your fancy in this area, preferably with no support required, nor roadblocks in the way of what you plan to do, from clojure.core. Don't be surprised if all your rallying efforts lead to a team of size one :-) Andy On Sat, May 10, 2014 at 7:09 AM, Timothy Baldridge tbaldri...@gmail.comwrote: If you plan on having this documentation apply to clojure.core.* you'll probably want to pull in Alex Miller or start a conversation in clojure-dev. I'd hate to see a bunch of decisions made, just to find out that Rich has a completely different view, a view that might have been nice to know before plans were finalized. Or perhaps a metadata modification system can be created? One that allows people to import clojure libs that adds new doc data to existing vars? Timothy On Sat, May 10, 2014 at 7:44 AM, Val Waeselynck val.vval...@gmail.comwrote: Here :https://docs.google.com/spreadsheets/d/1HyS9qstgEqmdv0MtDm3xEsImnDjCYQhar1PQP3fzwMc/edit?usp=sharingI think it would help if we had a panoramic view of the existing documentation systems and what we could borrow from them. I could only think of a Google Drive spreadsheet for this, but if anyone has a better idea... :) So it would be nice if people who are knowledgeable about other doc systems could contribute to it. From what I see, that may involve Tim for Emacs, Sean for reStructured, and Daniel for docco, for example? Thanks in advance! Le 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 Clojure https://github.com/weavejester/hiccup than 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 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 relevant concepts tend not to be obvious in the code. Since in Clojure we program with verbs, not nounshttp://steve-yegge.blogspot.fr/2006/03/execution-in-kingdom-of-nouns.html, I think *documentation is best made by example*. 4. Documentation of a Var should not be a formal description of what it is and what it does with some cryptically-named variables. *Every bit of documentation should be a micro-tutorial*. Emphasis should be put on usage, examples, tips, pitfalls, howtos. 5. There should be structure in the documentation, and it shouldn't be just :see-also links - *there should be semantics* in it. For example, some functions/macros
go-circuit for clojure
Hi, Since, core.async has goroutines maybe it would be possible to implement go-circuithttps://thestrangeloop.com/sessions/go-circuit-distributing-the-go-language-and-runtimefor clojure to distrubute goroutines across computer nodes? Mic -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
How to convert this list into map?
Hi,
I have this list:
(:= :language Clojure)
And I want to convert it to the following map data structure:
{:op := , :language Clojure}
I can't really think of a clear way how to do it.
Would you please help?
Thanks for help and 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.
Re: How to convert this list into map?
user= (apply hash-map (conj '(:= :language Clojure) :op))
{:op :=, :language Clojure}
On Saturday, May 10, 2014 5:56:59 PM UTC-4, Hussein B. wrote:
Hi,
I have this list:
(:= :language Clojure)
And I want to convert it to the following map data structure:
{:op := , :language Clojure}
I can't really think of a clear way how to do it.
Would you please help?
Thanks for help and 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.
Re: How to convert this list into map?
Here is how you can derive that expression:
{:op :=, :language Clojure}
is the same as
(hash-map :op := :language Clojure)
which is the same as
(apply hash-map '(:op := :language Clojure))
So, all you need is
'(:op := :language Clojure)
which can be produced by prepending :op to your original list
(conj '(:= :language Clojure) :op)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: How to convert this list into map?
That is beautiful! Thanks a lot!
On Sunday, May 11, 2014 12:33:51 AM UTC+2, Mike Fikes wrote:
Here is how you can derive that expression:
{:op :=, :language Clojure}
is the same as
(hash-map :op := :language Clojure)
which is the same as
(apply hash-map '(:op := :language Clojure))
So, all you need is
'(:op := :language Clojure)
which can be produced by prepending :op to your original list
(conj '(:= :language Clojure) :op)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: How to convert this list into map?
As a slight simplification you can take advantage of the fact that apply
handles in-line arguments as well as a seq of arguments at the end. This also
works:
user= (apply hash-map :op '(:= :language Clojure))
{:op :=, :language Clojure}
--Steve
On May 10, 2014, at 6:37 PM, Hussein B. hubaghd...@gmail.com wrote:
That is beautiful! Thanks a lot!
which can be produced by prepending :op to your original list
(conj '(:= :language Clojure) :op)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Licensing program written in Clojure under GPL
I've often wondered about this. This restriction seems to mean that any GPL Clojure library can only ever be for private use. There are a few examples out there, and this would seem to apply to LightTable as well, since it's GPL but uses a lot of EPL code. How do they get around this? With straight Clojure it's probably not such an issue since most of the libs are EPL anyway, but there are a fair number of GPL Java libs that people might want to use - I'm not sure what the norm is in the Javascript world for interop with cljs. On 11 May 2014 06:00, Jozef Wagner jozef.wag...@gmail.com wrote: Do you want to distribute binaries (.class files) of the program B? If not, you may license your sources in any license you want. If yes, then it will be possible only if the library G has a linking exception in its license [1], as the clojure itself is EPL so it does not matter how the library A is licensed. Without linking exception you cannot distribute the combined work from EPL and GPL sources [2] [3]. [1] http://en.wikipedia.org/wiki/GPL_linking_exception [2] https://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE [3] http://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/ Jozef On Sat, May 10, 2014 at 5:44 PM, Gunnar Völkel gunnar.voel...@googlemail.com wrote: I have written a Clojure library A which is licensed under Eclipse Public License (EPL) as usual which depends on other Clojure libraries with EPL license. In a different program B I use library A and another library G which is licensed under GPLv3. Now, the question arises which license I am allowed to use (or even must use) for program B. As far as I have read it is not possible to license B under EPL because library G is licensed under GPLv3. Leaving the only option to license program B under GPLv3 - does that sound correct to 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: How to convert this list into map?
That looks much better IMHO :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Monger 1.8.0 is released
Monger [1] is a Clojure MongoDB client for a more civilized age. Release notes: http://blog.clojurewerkz.org/blog/2014/05/10/monger-1-dot-8-0-is-released/ Note that the next release will be 2.0, including these breaking API changes: http://blog.clojurewerkz.org/blog/2014/04/26/major-breaking-public-api-changes-coming-in-our-projects/ 1. http://clojuremongodb.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Java API is copyright protected?
It appears that the Java API can be copyright protected. This would mean that you have to get Oracle's permission and possibly pay a fee to use it. http://www.theverge.com/2014/5/9/5699958/federal-court-overturns-google-v-oracle Tim Daly -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Java API is copyright protected?
At the risk of getting slightly off-topic here, here's a comment on Hacker News from a well-respected commenter on legal issues - he's a lawyer specialising in startup and technology law and his analysis is uniformly excellent. He argues that while the result may be unpalatable, it's by no means the stitch-up by technological ignoramuses that that article makes it sound: https://news.ycombinator.com/item?id=7722674 From an end-user point of view, I doubt this will ever be a problem. It's not in Oracle's interest to discourage people from using Java, just from implementing it in competing implementations. On 11 May 2014 12:31, d...@axiom-developer.org wrote: It appears that the Java API can be copyright protected. This would mean that you have to get Oracle's permission and possibly pay a fee to use it. http://www.theverge.com/2014/5/9/5699958/federal-court-overturns-google-v-oracle Tim Daly -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
