Re: How to use Clojure core specs in my own library with regards to the EPL license?
Ya, I will just license the modifications to the specs under EPL. I do feel though specs are a weird grey area. For example, EPL 2.0 says: > Modified Works shall not include works that contain only declarations, > interfaces, types, classes, structures, or files of the Program solely in > each case in order to link to, bind by name, or subclass the Program or > Modified Works thereof. And EPL 1 allows a contributor to relicense under EPL 2. It doesn't list specs explicitly, because it's clearly designed for Java, but I feel it begs the question: If I implement a function of some spec, and then a spec for it. And someone implement a function of similar spec, and a spec for it. Now the specs could be seen as derivative. It can get tricky. Anyways. That's just thoughts. For my project it don't matter. Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/e2164409-8415-428f-b010-072a629dfd8b%40googlegroups.com.
Re: Strange behavior with clojure.java.io/copy
A bit awkward to clutter a standard library with too much speculative forgiveness of other software's potential failure to follow a spec. Where would it end? Anyway, the best improvement here would help with all InputStream consumers, not just io/copy. If you suffer from a faulty InputStream that returns zero when it simply does not feel like blocking, couldn't you either fix it or wrap it in a "TolerateZeroBytesReadByRetryingInputStream" that blocks until it gets something other than zero? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/84da2491-2a3c-4b0c-9406-49f63ed6caf4%40googlegroups.com.
Re: gen-class/AOT considered harmful (in libraries)???
Clojure does not guarantee binary compatibility between versions, but almost always happens to be compatible. Yet, it's best not to distribute your Clojure libs as compiled classes, much better to do so as source. For a gen-class though, it works like Java. Java guarantees backward compatibility of classes, as far as I know. So you should be good as long as you make sure that none of the Clojure code gets AOTed and included in the jar by accident as you compiled the gen-class. Like keep your gen-class in their own namespace with only the -xyx fns in it. And have those instantly delegate to a call to another namespace. Or what I do is I AOT, but then when I package the Jar, I only include the gen-class .class file in it. I hand pick it for inclusion in the Jar, and don't include any of the other .class files. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/67955ff9-c70a-44e9-b9be-081056fc10c7%40googlegroups.com.
Re: gen-class/AOT considered harmful (in libraries)???
On Saturday, August 31, 2019 at 5:39:18 AM UTC-4, Didier wrote: > > with only the -xyx fns in it. And have those instantly delegate to a call > to another namespace. > The gen-class :impl-ns option is useful here. It achieves the delegation without spreading AOT to the implementing namespace. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/c5da2374-ff83-4378-be6a-45f4354674f1%40googlegroups.com.
Re: gen-class/AOT considered harmful (in libraries)???
I'm not sure if it is harmful. On Thursday, August 22, 2019 at 9:59:44 AM UTC-7, Jim foo.bar wrote: > > Hi folks, > > This is a genuine question that has tripped me quite a few times, so I'd > appreciate some closure - pun intended ;) > > Suppose you are developing a library *foo*. In the absence of AOT, you > don't need to include Clojure as an actual dependency (perhaps as a :dev > one so that you can work away), because the caller/user of your library is > expected to provide the Clojure version he/she wants (ignoring features > introduced in some particular release and such). All good so far... > > Now suppose said library uses a `:gen-class` ns (because it needs to > register a service through java-SPI and `proxy` won't cut it), and that you > 've managed to restrain AOT only to that specific ns (through runtime > `requiring-resolve` calls). Does that automatically make that library only > compatible with whatever Clojure version you compiled it with (which would > mean that Clojure now needs to be a proper dependency for things to work)? > > > Many thanks in advance... > > Kind regards, > > Dimitris > > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/e63ff68c-cf60-457e-893d-fb05aa3e660d%40googlegroups.com.
