This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (8)
- # beginners (78)
- # boot (20)
- # cider (81)
- # clara (53)
- # cljdoc (10)
- # cljsjs (3)
- # clojure (55)
- # clojure-boston (1)
- # clojure-dev (25)
- # clojure-nl (3)
- # clojure-uk (65)
- # clojurescript (65)
- # core-async (1)
- # cursive (41)
- # data-science (4)
- # datomic (16)
- # editors (74)
- # emacs (17)
- # events (1)
- # figwheel (3)
- # hyperfiddle (39)
- # immutant (16)
- # jobs-discuss (62)
- # juxt (2)
- # keechma (2)
- # leiningen (6)
- # mount (7)
- # nrepl (1)
- # off-topic (30)
- # onyx (14)
- # protorepl (2)
- # re-frame (4)
- # reagent (15)
- # reitit (19)
- # shadow-cljs (102)
- # sim-testing (1)
- # spacemacs (44)
- # specter (15)
- # tools-deps (50)
- # vim (2)
What's your overall opinion on Grimoire (` https://www.conj.io/ `) ? I wasn't aware that it existed, and the CIDER integration is tempting
Traditionally I've resorted to
Take a look at https://cljdoc.xyz/
FWIW cljdoc doesn’t have examples (yet) so if you’re looking for examples you might be better off sticking to http://conj.io or http://clojuredocs.org for now.
As the Grimoire maintainer, clojuredocs is "a bit more popular" by 10-20x if I recall the last traffic numbers I saw from zkim. Clojuredocs and Grimoire are both mostly finished projects - Grimoire's initial value add was some handwritten "docstrings++" and examples pulled from clojuredocs and formatted for consistency. The intervening four years haven't really done it any favors although Clojure being absurdly stable there hasn't been much bit rot either. I'm excited to see what @martinklepsch comes back with in cljdoc, and I'm currently working on http://github.com/arrdem/stacks which may wind up being the basis for a Grimoire++ one of these days. But Grimoire isn't going anywhere.
Priceless input @arrdem, thank you!
Best wishes for
stacks and also I may give a shot to Grimoire (this morning I opened https://github.com/clojure-grimoire/grimoire/issues/267 which would be killer feature IMO)
Wonder if it'd be worth inserting the newlines at display time in order to avoid the comparison problem. Would be easier if automated, of course, but if human-chosen, maybe could store & apply the diffs instead of the altered version? Dunno, just brainstorming.
License question: I have assembled a clojure lib based on a fork of clojure I've found on github. I have kept only the parts I was interested in (rather than the whole language fork) and I'm wondering what to put in the license headers of the files. The fork: • is licensed under the EPL 1.0 • has several original files with the EPL license header containing "© name of the creators of the fork" • contains modified versions of two files (RT.java and LockingTransaction.java) from Clojure's source code with the original license header (© Rich Hickey) intact but no mention of the fork contributors I have: • copied the original files from the fork and made some modifications on a few of them to adapt the contributed features to my needs: I was thinking about just keeping the license headers as is with the names of the creators of the fork. Do I have to add my name somewhere? Because I don't care personally. • copied RT.java from the fork that was basically a copy/paste of the original RT.java with new methods added at the end. I've kept only the new methods not present in the original clojure code and renamed it TC.java (cosmetics), and I also added a new method myself: same as above, I was thinking about adding the license header with the names of the creators of the fork because it is a new file but content contributed by them, plus a new method from me. • subclassed LockingTransaction.java from Clojure's source code rather than keeping the modified copy from the fork, but I have "ported" the modifications made in the fork into this subclass: here I don't know what to do since the copy from the fork contained the © Rich Hickey header but the new file I have created contains a subclass with code from the fork. So basically only a tiny portion of the code is mine, most of it is just copy/pasted. I don't want to take credit for things I didn't do, I also don't care about being credited for my small contribution, most importantly I don't want previous contributors to have problems or be blamed for bugs or anything else introduced by my contributions. I just want to put this in a small library ouside of my project, also I don't want to consult a lawyer. #help
If you want to publish the source, you could do so on GitHub, link to the projects from which you got the originals you started from, put it all under EPL 1.0 (I think, unless I missed some mention you made of original code licensed otherwise), and make a README that contains pretty much what you said above.
That would be easier indeed.
If most of the code shares commit history with one other project on Github, you could even use Github to fork that project, then commit your changes on top of the latest version at the time you forked. The commit history of your project would make clear what changes you made, vs. came from original authors.
@jgh I don't think so, it was created in an academic context and the modifications are made to be more "practical" for certain use cases. Also the main project is a complete clojure fork, and I was interested in a library version.
@arnaud_bos you can just read the EPL license for what you have to do:
When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. Contributors may not remove or alter any copyright notices contained within the Program. Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution.
so it must be EPL 1.0 and include the EPL 1.0 license, you must not remove or alter copyright notices, and you must identify yourself as the originator of any contributions
For the files I have modified, no problem. But I have created new files containing mostly code I did not write myself. Then I guess I have not "removed or altered any copyright notices contained within the Program" (or did I?). I don't think it makes me the "originator" of these contributions.
I feel the same way when I'm trying to make a printer print something 🤯
I'll just fork the repo on github and 1) remove everything I don't want to keep, 2) rename the file from there without touching the copyright notices and 3) make the changes I want. I guess it'll work.
I don't know the legal requirements of EPL in that case, if any, but at least out of politeness, and/or documentation of where the code came from, comments in those files giving pointers to the origin of the code would be good to have.
If a single file contains code from multiple other projects (all EPL 1.0, say), then multiple comments listing each of those original sources seems appropriate.
Thanks a lot
If nothing else, such comments can help someone new to the code figure out where it came from, and track down the original, e.g. in case bugs were fixed in the original but not your copy, and they want to copy those fixes from the original to the copy. Note that "someone new to the code" could effectively be you after not looking at the code for 2 years.
Very good point. Now that I have something working and fresh in memory I will redo it from the fork step by step and add comments along the way.
1:40 am coding is the best
After 2 am you begin to fall, like the Ballmer peak.