Re: New developments in beginner-friendly editing/repl environments?

[Phillip Lord]

Have you asked the developer to provide an option?

>From my experience is that parinfer is weird for the first 5 mins. Then
it gets less confusing than trying to work out why the indentation is
wrong. In paren mode, it does allow adding and removing brackets also.

Phil

"'Lee' via Clojure"  writes:

> Alas, current Nightcode forces use of parinfer, unless something has 
> changed very recently.
>
> Previous versions of Nightcode met all of my requirements and I used them 
> for teaching, and liked it quite a lot.
>
> But parinfer is a problem. One of my requirements is that the editor acts 
> mostly like a normal text editor, aside from bracket matching and 
> user-triggered re-indentation. Auto-insertion of closing brackets is okay 
> too, if they can be erased. My students know how to type and to cut and 
> paste text, and I want them to be able to rely on those skills working as 
> they expect them to work as they learn to program. I've seen parinfer 
> confuse and frustrate some of my students, and it also happens to clash 
> badly with my own ways of editing code.
>
>  -Lee
>
>
> On Monday, August 27, 2018 at 4:36:33 PM UTC-4, Erik Assum wrote:
>>
>> Have you had a look at Nightcode?
>> https://sekao.net/nightcode/
>>
>> Erik. 
>> -- 
>> i farta
>>
>> 27. aug. 2018 kl. 22:00 skrev Nando Breiter > >:
>>
>> Lee,
>>
>> Perhaps https://atom.io/packages/atom-beautify will do what you want. 
>>
>> With Parinfer disabled, I can select and shift-tab all code to the left 
>> margin, removing all indentation. Then when I run Atom Beautify on the 
>> file, all indentation is restored. 
>>
>>
>>
>> Aria Media Sagl
>> +41 (0)76 303 4477 cell
>> skype: ariamedia
>>
>> On Mon, Aug 27, 2018 at 9:18 PM, 'Lee' via Clojure <
>> clo...@googlegroups.com > wrote:
>>
>>>
>>> Ah -- thank you! 
>>>
>>> Now I can re-indent in Cursive, although it doesn't do the right thing 
>>> after defn, etc. What do Cursive users do to get standard indentation?
>>>
>>> Playing a bit more I see some other with basic editing, even in 
>>> "Structural Off" mode. Like if you type "(defn foo" and hit return, then 
>>> foo changes into some strange autocompleted symbol. Shift-return avoids 
>>> this, but the idea is to let people use their pre-existing typing skills. 
>>> It also won't let you delete to the left of the indentation point (it jumps 
>>> you up to the previous line), etc. I'm not sure how problematic these 
>>> issues would be.
>>>
>>>
>>>
>>> On Monday, August 27, 2018 at 3:01:37 PM UTC-4, ri...@chartbeat.com 
>>> wrote:

 It’s under one of the code or refactor menus, you can auto-format or 
 auto-indent.

 On Aug 27, 2018, at 11:30 AM, 'Lee' via Clojure  
 wrote:


 Probably true that my requirements are a bigger challenge for 
 multi-language IDEs. I thought Eclipse/Counterclockwise did a reasonable 
 job of it back when that was an active project, but it was a bit rough 
 too, 
 since there was a lot of incidental and distracting complexity in dealing 
 with Eclipse in general.

 I did see the "off" setting for parinfer/paredit in Cursive, but it's 
 not really "off" in the sense of behaving like a normal text editor, and I 
 don't see re-indentation anywhere. FWIW since this is for teaching I'm not 
 really interested in customization, just reasonable behavior out of the 
 box.


 On Monday, August 27, 2018 at 11:21:47 AM UTC-4, Rick Mangi wrote:
>
> Yeah, I actually just create projects with lein. If you right click on 
> a project.clj you can just fire up a repl via lein and it works really 
> well. There's 3 choices for parenthesis, there's again a little button on 
> the bottom right to switch between parinfer/paredit and off. You can 
> customize all of the code reformatting and you can even alias things like 
> defnp and other macros to evaluate correctly. 
>
> That said, a tool that supports dozens of languages isn't going to do 
> any of them particularly easily :)
>
>
>
> On Mon, Aug 27, 2018 at 11:18 AM 'Lee' via Clojure <
> clo...@googlegroups.com> wrote:
>
>> Thanks Rick. 
>>
>> Just tried Cursive again but it still seems to fail pretty badly on 
>> newbie setup and usability, which is what has hung me up in the past. 
>>
>> tldr: A half hour or so after a fresh install and going through the 
>> Getting Started instructions I still don't have a REPL (confused about 
>> Run 
>> Configurations and what I'm seeing doesn't match the website pics), and 
>> although I can edit code in an existing project with drag and drop 
>> (can't 
>> yet create a project with a core.clj), even the "Structural Off" editing 
>> mode behaves oddly and doesn't appear to support structure-aware 
>> re-indentation (again, unless I'm missing it). And the indentation that 
>> it 
>> prefers after a newline appears to be 

Re: Developing in Clojure with Emacs: Mastering the Keyboard

[Phillip Lord]

which-key is a fantastic package. The Emacs out-of-the-box experience is
getting better, but slowly; this sort of functionality really needs to
be in core, automatically active.

Phil

Chris Shellenbarger <chris.shellenbar...@gmail.com> writes:

> I found them useful for getting the repl to run - after following these 
> instructions I was able to run 'cider-jack-in' and get to a repl that 
> worked the same was as the one I had been using in Cursive.
>
> They also pointed me to a couple of suggested packages to install, in which 
> whichkey was one. 
>
> However, with a running REPL, I had no idea what to do - I was consulting 
> cheat sheets for things I knew I wanted to do, but did not have a clear way 
> to discover all the options available to me.  That's when I turned to the 
> CftBT book and his configuration because at least I could see what a 
> Clojure Developer was using.   Installing whichkey and whatever package 
> allows the search for functions was incredibly helpful (which inspired the 
> original post).
>
> What I feel is missing from a lot of the Clojure world is documentation on 
> how the real professional Clojure developers are working from a day to day 
> perspective.  This includes any that work in Emacs/CIDER - how are they 
> working more productively than we can in Cursive or another IDE?  With the 
> tools I mention in my post, I can see how you can get started down that 
> path.
>
> As far as the CIDER docs go, I think a huge way to increase their utility 
> would be to provide an example Emacs configuration so that people can just 
> download it and get up and running within a context that can be discussed 
> in the documentation.  I'm sure people have these configurations running - 
> you can use the ones that I put up as well.
>
>
> On Sunday, March 4, 2018 at 7:13:37 AM UTC-6, Bozhidar Batsov wrote:
>>
>> Btw, didn't you find the instructions in the official manual useful (
>> http://cider.readthedocs.io/en/latest/installation/ and 
>> http://cider.readthedocs.io/en/latest/up_and_running/). Admitted they are 
>> not great, but they do cover a lot of ground and are reasonably up-to-date. 
>>
>> On 3 March 2018 at 23:11, Chris Shellenbarger <ch...@cloudrepo.io 
>> > wrote:
>>
>>> I spent the last week learning and using Emacs and CIDER for Clojure 
>>> Development.
>>>
>>> I've started to write up a lot of the lessons I've learned from doing so 
>>> in the hopes that it will help some other people who attempt something 
>>> similar.
>>>
>>> Anyway, if you're interested in getting started with Emacs and CIDER, 
>>> you'll have to learn about how to use the keyboard so I wrote a couple of 
>>> key lessons in a Medium post:  Developing in Clojure with Emacs: 
>>> Mastering the Keyboard 
>>> <https://medium.com/@chris.shellenbarger/developing-in-clojure-with-emacs-mastering-the-keyboard-6cb9bef7f760>
>>> .
>>>
>>> My environment was Emacs 24.5.1 with CIDER 0.16.0 on Linux Mint 18.3.
>>>
>>> I used the Clojure for the Brave and True <https://www.braveclojure.co> 
>>> book 
>>> for a basic intro into Emacs <https://www.braveclojure.com/basic-emacs/> 
>>> and 
>>> used the provided emacs configuration files as a starting point.  However, 
>>> these only worked with CIDER 0.8.0 and were about four years old.  I made 
>>> some modifications of the files to work with CIDER 0.16.0 and put them up 
>>> for anyone to use on my BitBucket Repository 
>>> <https://bitbucket.org/64BitChris/linux-emacs-configuration>.
>>>
>>> I have a lot more to share about my Emacs experience, but I found that 
>>> there was so much that I had to split it into multiple posts.   
>>>
>>> Hope it helps someone out there!
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to clo

Re: Clarification on how Clojure libraries can be included in other software

[Phillip Lord]

My reading of this is slightly different. As far as I can tell, it is
possible to use Clojure within GPL libraries or applications, as Clojure
would fall under the definition of "System Library" implementing the
"Standard Interface". It's the same clause in GPL which allows, for
example, GPL applications running under Windows. For a more equivalent
answer, you can write a GPL application in Common Lisp, and run it on a
proprietary CL implementation.

But, what falls into a "system library" and what does not is less
clear. If you use other clojure libraries, EPL and GPL incompatibilty
hits. Yes, you could re-write GPL to allow additional options (in fact
the LGPL does this). But, it would be hard, and no one is likely to
trust a bespoke license used only by you, just because it's unsual.

As usual, this is just my own take, and you need to consult a lawyer if
you want legal advice.

Phil


Jeronimo Pellegrini  writes:
> I have a question about the the license used for Clojure libraries.
>
> As far as I understand, a library released under the EPL can be
> included in any software, including proprietary, so long as the
> library itself is not modified -- is that correct?
>
> So, this also means that the EPL would also allow for me to use those
> libraries in software that I release under one of the GPL licences,
> right? I know that the *GPL* itself wouldn't allow for that, but I
> suppose that if the EPL does allow for this, then I can write an
> exception paragraph allowing the use of the EPL libraries and add it
> to the GPL.
>
> I'd like to know if my interpretation is correct, and also if there is 
> already code
> being licensed like that.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure core documentation

[Phillip Lord]

Alex Miller <a...@puredanger.com> writes:

> On Monday, September 25, 2017 at 11:42:12 AM UTC-5, Phillip Lord wrote:
>> Clojure's doc strings, though, contain knowledge that is not 
>> clear. Consider, this documentation: 
>>
>> Returns a new seq where x is the first element and seq is the rest. 
>>
>> x is the name of a parameter. So is the the second occurence of seq, but 
>> not the first. Neither first, nor rest refer to the functions in 
>> clojure.core, although both probably should do. 
>>
>
> You didn't mention it but this is the docstring for cons. You also stripped 
> half the context (the arglist):
>
> -
> clojure.core/cons
> ([x seq])
>   Returns a new seq where x is the first element and seq is
> the rest.
>
> To me, first and rest here are clearly referring to the English meaning, 
> not the functions, but also intentionally echoes the actual function names 
> which can be used to extract x and seq. I think that's all good.

Yes, I agree with first and rest. But you are inferring this. A tool
will not.

> You can go further with echoing the first/rest stuff by using a spec
> with a :fn too:



>
> -
> clojure.core/cons
> ([x seq])
>   Returns a new seq where x is the first element and seq is
> the rest.
> Spec
>   args: (cat :x any? :seq seqable?)
>   ret: seq?
>   fn: (fn [{:keys [args ret]}] (and (= (:x args) (first ret)) (= (sequence 
> (:seq args)) (rest ret
>
> I think this is way better in specifying the args and ret and actually 
> includes a very precise description of how the args and return value relate 
> to first and ret.


Yep. Precise, but not very readable.



>> Compare this to the documentation for "apply" from Andy Fingerhuts 
>> thalia. 
>>
>
> It seems weird to me to give the docstring from cons above and then from 
> Andy's apply below as a comparison.


Thalia is nice but, alas, not comprehensive.


> I do think it would be useful if the docstring for apply said that args had 
> to be seqable. Of course, if apply had a spec, you'd have that:
>
> user=> (s/fdef clojure.core/apply :args (s/cat :f ifn? :prepend (s/* any?) 
> :args seqable?))
> clojure.core/apply
> user=> (doc apply)
> -
> clojure.core/apply
> ([f args] [f x args] [f x y args] [f x y z args] [f a b c d & args])
>   Applies fn f to the argument list formed by prepending intervening 
> arguments to args.
> Spec
>   args: (cat :f ifn? :prepend (* any?) :args seqable?)
>   ret: any?
>
> Some slight alterations in the :arglists, :doc, and spec names could align 
> these even better.

Indeed, this would be a nice addition.



> Examples: 
>> ```clojure\nuser=> (apply + [1 2])   ; same as (+ 1 2) 3 
>>user=> (apply + 1 2 [3 4 5 6])   ; same as (+ 1 2 3 4 5 6) 
>>
>
> I think one example in this docstring would actually say a lot. I don't 
> like the formatting here (why the clojure? why the user prompt? why the 
> dangling 3?).

The formatting is mine -- I converted the newline chars from the
string. The 3 is my mistaken transcription.


>> It would be possible to go even further than this; consider the runnable 
>> doc strings of rust -- the examples are also tests. Emacs' dash.el does 
>> the same thing. 
>>
>
> Cool idea. As I showed above, we're 95% of the way there already, but with 
> *automatically generated examples*. Although hand-picked ones would 
> undoubtedly serve as better examples, but you could actually inject custom 
> arg generators to even handle that.

As you say, hand-picked ones would be better -- documentation is not the
same thing as a test. Rather, it is good to be able to test the
documentation.

Why not ensure that the right thing (hand-picked examples) are
supported first? Automatically generated examples can come later.

Still, it is good to know that these things are being actively worked
on. The documentation has been static for a long time, and improvements
would be gratefully recieved.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure core documentation

[Phillip Lord]

If the docstring were more structured (either using conventions within
the docstring, or additional metadata elements on the var), then this
would not be a problem. First line for tooltip, main doc for hover-over,
examples on request, that kind of thing.

Phil

Beau Fabry <imf...@gmail.com> writes:

> As a docstring I don't find this superior. Docstrings (for me) are usually
> viewed as quick little pop-up boxes in my editor. The existing clojure 
> docstring for `apply` gives me the information I need much faster and 
> with less screen real estate. YMMV.
>
>
> On Monday, September 25, 2017 at 9:42:12 AM UTC-7, Phillip Lord wrote:
>>
>>
>>
>> Clojure's doc strings, though, contain knowledge that is not 
>> clear. Consider, this documentation: 
>>
>> Returns a new seq where x is the first element and seq is the rest. 
>>
>> x is the name of a parameter. So is the the second occurence of seq, but 
>> not the first. Neither first, nor rest refer to the functions in 
>> clojure.core, although both probably should do. 
>>
>> Compare this to the documentation for "apply" from Andy Fingerhuts 
>> thalia. 
>>
>> `f` is a function and the last argument `args` is a sequence.  Calls 
>> `f` with the elements of `args` as its arguments.  If more arguments 
>> `x`, `y`, etc.  are specified, they are added to the beginning of 
>> `args` to form the complete argument list with which `f` is called. 
>>
>> Examples: 
>> ```clojure\nuser=> (apply + [1 2])   ; same as (+ 1 2) 3 
>>user=> (apply + 1 2 [3 4 5 6])   ; same as (+ 1 2 3 4 5 6) 
>>
>> Which is essentially superior in every way. The existence of neither 
>> specs nor clojure.org don't really change this. 
>>
>> It would be possible to go even further than this; consider the runnable 
>> doc strings of rust -- the examples are also tests. Emacs' dash.el does 
>> the same thing. 
>>
>> Still, it's been this way since I first started using clojure (1.3/1.4) 
>> so I suspect that it's not going to change. 
>>
>> Phil 
>>
>>
>>
>> Stuart Halloway <stuart@gmail.com > writes: 
>>
>> > Clojure has great data, and great metadata. Documentation strings are 
>> *not* 
>> > great data, they are strings. 
>> > 
>> > If you want to provide more structured support than docstrings to help 
>> > someone use Clojure, look at specs for inspiration. They are made of 
>> data, 
>> > and they live in a registry separate from Clojure's var system. This 
>> kind 
>> > of decoupling supports composition and tooling without requiring any 
>> > addition or change to Clojure. 
>> > 
>> > I would also echo Matching Socks: Having more and better guides at 
>> > clojure.org would be great. The contribution process is described at 
>> > 
>> https://github.com/clojure/clojure-site/blob/master/content/community/contributing_site.adoc
>> > . 
>> > 
>> > Regards, 
>> > Stu 
>> > 
>> > On Mon, Sep 11, 2017 at 5:23 AM, Matching Socks <phill...@gmail.com 
>> > 
>> > wrote: 
>> > 
>> >> I am not convinced I would have found the API docs on reducers or 
>> zippers 
>> >> more informative if all references had been tidily markdown'ed. 
>> >> 
>> >> The new clojure.org welcomes contributions of topical overviews. 
>>  That's 
>> >> helpful. 
>> >> 
>> >> But, to interpret docstrings, nothing helps like perspective.  The 
>> thing 
>> >> about perspective is that there could be so many.  I like "Clojure 
>> >> Programming" by Emerick, Carper & Grand. 
>>

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Biology, Medicine, ComputingEmail: phillip.l...@newcastle.ac.uk
School of Computing,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 5.012 Urban Sciences Building, skype: russet_apples
Newcastle University,   twitter: phillord
NE4 5TG

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure core documentation

[Phillip Lord]

Clojure's doc strings, though, contain knowledge that is not
clear. Consider, this documentation:

Returns a new seq where x is the first element and seq is the rest.

x is the name of a parameter. So is the the second occurence of seq, but
not the first. Neither first, nor rest refer to the functions in
clojure.core, although both probably should do.

Compare this to the documentation for "apply" from Andy Fingerhuts
thalia.

`f` is a function and the last argument `args` is a sequence.  Calls
`f` with the elements of `args` as its arguments.  If more arguments
`x`, `y`, etc.  are specified, they are added to the beginning of
`args` to form the complete argument list with which `f` is called.

Examples:
```clojure\nuser=> (apply + [1 2])   ; same as (+ 1 2) 3
   user=> (apply + 1 2 [3 4 5 6])   ; same as (+ 1 2 3 4 5 6)

Which is essentially superior in every way. The existence of neither
specs nor clojure.org don't really change this.

It would be possible to go even further than this; consider the runnable
doc strings of rust -- the examples are also tests. Emacs' dash.el does
the same thing.

Still, it's been this way since I first started using clojure (1.3/1.4)
so I suspect that it's not going to change.

Phil



Stuart Halloway  writes:

> Clojure has great data, and great metadata. Documentation strings are *not*
> great data, they are strings.
>
> If you want to provide more structured support than docstrings to help
> someone use Clojure, look at specs for inspiration. They are made of data,
> and they live in a registry separate from Clojure's var system. This kind
> of decoupling supports composition and tooling without requiring any
> addition or change to Clojure.
>
> I would also echo Matching Socks: Having more and better guides at
> clojure.org would be great. The contribution process is described at
> https://github.com/clojure/clojure-site/blob/master/content/community/contributing_site.adoc
> .
>
> Regards,
> Stu
>
> On Mon, Sep 11, 2017 at 5:23 AM, Matching Socks 
> wrote:
>
>> I am not convinced I would have found the API docs on reducers or zippers
>> more informative if all references had been tidily markdown'ed.
>>
>> The new clojure.org welcomes contributions of topical overviews.  That's
>> helpful.
>>
>> But, to interpret docstrings, nothing helps like perspective.  The thing
>> about perspective is that there could be so many.  I like "Clojure
>> Programming" by Emerick, Carper & Grand.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clojure.java.jdbc 0.7.0 Beta 2

[Phillip Lord]

Yep, appears that you are right. I ended with this:

(doseq
  [[k v] (ns-map ns)
   :when (= (find-ns 'clojure.core) (:ns (meta v)))]
(ns-unmap ns k))

which is pretty ugly.

Justin Smith  writes:

> refer-clojure doesn't ever remove mappings, it only adds them
>
> The reason a refer-clojure clause in your ns form can prevent bindings is
> because your refer-clojure clause (which is likely more qualified than the
> default) overrides the args that ns would otherwise provide to
> refer-clojure.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clojure.java.jdbc 0.7.0 Beta 2

[Phillip Lord]

Apologies, didn't mean to follow that thread!

Phillip Lord <phillip.l...@newcastle.ac.uk> writes:

> I am confused about how to exclude clojure.core from a namespace already
> exists. That is, I have not just created the namespace, but it's been
> given to me by a tool.
>
> Consider, for example:
>
>
>
>
> lein repl
> nREPL server started on port 41054 on host 127.0.0.1 - nrepl://127.0.0.1:41054
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.8.0
> OpenJDK 64-Bit Server VM 1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11
>
> user=> (refer-clojure :only [])
> nil
> user=> (defn some[])
> WARNING: some already refers to: #'clojure.core/some in namespace:
> user, being replaced by: #'user/some
> #'user/some
> user=> 
>
>
> Now, why do I get this warning? Surely some is not being replaced at
> all, since the refer-clojure form should have removed some
> clojure.core/some from the current namespace.
>
> Phil

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Biology, Medicine, ComputingEmail: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clojure.java.jdbc 0.7.0 Beta 2

[Phillip Lord]

I am confused about how to exclude clojure.core from a namespace already
exists. That is, I have not just created the namespace, but it's been
given to me by a tool.

Consider, for example:




lein repl
nREPL server started on port 41054 on host 127.0.0.1 - nrepl://127.0.0.1:41054
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.8.0
OpenJDK 64-Bit Server VM 1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11

user=> (refer-clojure :only [])
nil
user=> (defn some[])
WARNING: some already refers to: #'clojure.core/some in namespace: user, being 
replaced by: #'user/some
#'user/some
user=> 


Now, why do I get this warning? Surely some is not being replaced at
all, since the refer-clojure form should have removed some
clojure.core/some from the current namespace.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrating nREPL out of Clojure Contrib

[Phillip Lord]

Alex Miller  writes:

> On Tuesday, July 18, 2017 at 1:03:09 PM UTC-5, Chas Emerick wrote:
>> (Parenthetically, it strikes me as very strange for a project to have a 
>> copyright assignment to an individual that hasn't lodged any commits, at 
>> least insofar as the project gone "solo". It's interesting that I don't 
>> have that intuition if the assignee is an org like Apache or whatever, a 
>> discrepancy that I'll have to think on.) 
>>
>
> Afaik, this is not at all strange and is (legally) the exact same thing. 

Not really. The Apache foundation is a discrete legal entity, with a
declared constitution and legal obligations. Rich is a person; he could
sell the software to anyone. He could die, and then the ownership would
pass to someone.

*Who* owns the copyright is important in a copyright assignment
process. You are putting your trust in that person or organisation, and
whoever that person or organisation passes ownership to.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Primitive Operator

[Phillip Lord]

Yes, but it doesn't supoort ints for all the operators, as far as I can
tell.

You are right, though, perhaps I should look at this also.

Phil

Max Penet <m...@qbits.cc> writes:

> This seems quite similar to https://github.com/ztellman/primitive-math. Did 
> you know about it?
>
> On Monday, July 3, 2017 at 11:44:40 AM UTC+2, Phillip Lord wrote:
>>
>>
>>
>> This is the first alpha release of my new library! Comments welcome. 
>>
>> Clojure has an extensive system for dealing with numbers, including 
>> error on overflow, or auto-promotion, defaulting to long and double data 
>> types. 
>>
>> This is all well and good, but irritating if you need to implement an 
>> algorithm which depends on ints overflowing for instance. While, clojure 
>> provides functions for operating over ints, the names tend to be long 
>> and wieldy, such as clojure.core/unchecked-int-add. Clojure is also 
>> rather inconsistent; for example, the bit-shifting operators in Java are 
>> not accessible in Clojure over ints. 
>>
>> This library provides accessible, easily named float and int functions 
>> for Clojure. Where possible, functions with the same name as the 
>> operators are provided as well as names (<< and left-shift). Three Java 
>> operators are not valid symbols in clojure (~, % and ^), so just have 
>> names. Short reader literals are also provided to simplify the creation 
>> of ints and float. 
>>
>> (require '[primititve.operator.integer :as i]) 
>>
>> (i/+ 10 10) 
>> => 20 
>>
>> (type (i/+ 10 10)) 
>> => java.lang.Integer 
>>
>> (i/add 10 10) 
>> => 20 
>>
>> (i/not 10) 
>> => -11 
>>
>> (i/+ #p/i 10 #p/i 10) 
>> => 20 
>>
>>
>> https://github.com/phillord/primitive-operator 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Primitive Operator

[Phillip Lord]

Nicola Mometto  writes:

> Hi Phillip,
>
> I've had a very quick look at the code and I've spotted a few issues,
> here's my feedback:
>
> 1- all your functions will cause input args and return value to be
> boxed. There's a few ways to avoid it, none of which are particularly
> pretty. If your library is not worried about performance but just
> about behaviour then this is not a problem, if it is, I can guide you
> through ways to avoid boxing (primitive type hinting of ints and
> floats is unfortunately not an option).

I'd be happy to get that information. Performance is not really my
concern here, rather it is ensuring that I can replicate int/float based
algorithms in Clojure.

Having said that, all things being equal, performance is better than not.


> 2- defining a var called &, while technically valid, is not a good
> idea. syntax-quote will not resolve vars named & to avoid collision
> with the & rest syntax in destructuring, so I'd consider using a
> different name

Ah, yes. Clojure really sucks up all those handy punctuation characters.


> 3- clojure/core encourages libraries to provide "sufficiently uniquely
> named data literals", p/i and p/f to me while convenient don't seem
> unique enough to be safely included in a library. This one could be
> detabatable

Yeah, I was worried about that. If they are longer, though, it defeats
the point.

#primitive/int 10
(int 10)

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Primitive Operator

[Phillip Lord]

Nicola Mometto  writes:

> Hi Phillip,
>
> I've had a very quick look at the code and I've spotted a few issues,
> here's my feedback:
>
> 1- all your functions will cause input args and return value to be
> boxed. There's a few ways to avoid it, none of which are particularly
> pretty. If your library is not worried about performance but just
> about behaviour then this is not a problem, if it is, I can guide you
> through ways to avoid boxing (primitive type hinting of ints and
> floats is unfortunately not an option).

I'd be happy to get that information. Performance is not really my
concern here, rather it is ensuring that I can replicate int/float based
algorithms in Clojure.

Having said that, all things being equal, performance is better than not.


> 2- defining a var called &, while technically valid, is not a good
> idea. syntax-quote will not resolve vars named & to avoid collision
> with the & rest syntax in destructuring, so I'd consider using a
> different name

Ah, yes. Clojure really sucks up all those handy punctuation characters.


> 3- clojure/core encourages libraries to provide "sufficiently uniquely
> named data literals", p/i and p/f to me while convenient don't seem
> unique enough to be safely included in a library. This one could be
> detabatable

Yeah, I was worried about that. If they are longer, though, it defeats
the point.

#primitive/int 10
(int 10)

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Primitive Operator

[Phillip Lord]

This is the first alpha release of my new library! Comments welcome.

Clojure has an extensive system for dealing with numbers, including
error on overflow, or auto-promotion, defaulting to long and double data
types.

This is all well and good, but irritating if you need to implement an
algorithm which depends on ints overflowing for instance. While, clojure
provides functions for operating over ints, the names tend to be long
and wieldy, such as clojure.core/unchecked-int-add. Clojure is also
rather inconsistent; for example, the bit-shifting operators in Java are
not accessible in Clojure over ints.

This library provides accessible, easily named float and int functions
for Clojure. Where possible, functions with the same name as the
operators are provided as well as names (<< and left-shift). Three Java
operators are not valid symbols in clojure (~, % and ^), so just have
names. Short reader literals are also provided to simplify the creation
of ints and float.

(require '[primititve.operator.integer :as i])

(i/+ 10 10)
=> 20

(type (i/+ 10 10))
=> java.lang.Integer

(i/add 10 10)
=> 20

(i/not 10)
=> -11

(i/+ #p/i 10 #p/i 10)
=> 20


https://github.com/phillord/primitive-operator

-- 
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.

Scripting with a pre-prepared environment

[Phillip Lord]

I am trying to build a clojure environment which can run pre-prepared
scripts, using functions from my own library. I've been trying out boot
and it's nice. I can do things like so:


#!/usr/bin/env boot

(set-env! :dependencies '[[uk.org.russet/tawny-owl "2.0.0-SNAPSHOT"]])

(use 'tawny.owl)

(defontology o)
(defclass C)

(save-ontology "ontology-and-class.omn")


For simple uses, this is fine, but it has quite a lot of boilerplate at
the beginning. So, I'd like to replace this.

I thought about having a script like so:

boot --file init.clj --file $*

where "init.clj" would contain my additinal material, but unfortunately,
boot doesn't accept multiple "--file" options.

What I really want to do is to produce an executable like boot but with
my additional functionality added in. Am I missing something obvious
here?

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Numbers/math in Clojure

[Phillip Lord]

Alex Miller  writes:

> On Sunday, June 25, 2017 at 1:55:42 AM UTC-5, henrik42 wrote:
>>> Oh, I thought because there is the float-function floats are supported. 
>> Clojure could use "0.2f" to print/read floats and still use double "0.2" as 
>> the default (but float's "Infinity" may be challenging ;-)
>>
>
> Rich decided long ago that Clojure would only support primitive longs and 
> primitive doubles (for reading, function invocation, function return, etc). 
> Primitive floats, ints, shorts are supported only for the purposes of Java 
> interop (invoking Java methods primarily) and to some limited degree in 
> tight loop/recur loops.


It appears though, that Clojure doesn't provide access to all of the
operators in Java, over all data types. It would probably be nice to add
these all, systematically, for interop if nothing else.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why transducers are not (yet) fundamental?

[Phillip Lord]

 writes:

> I'm doing a little research for a talk and asking clojurists around. The 
> thesis I'm supporting is that transducers should completely replace 
> "normal" (non-reducing based) sequential processing. People have different 
> reactions to this, usually going from "what's wrong with threading macros" 
> to "I only use them for performances" to "they are less readable". I think 
> it's mostly habit.
>
> Personally, I can't find any good reason not to ditch Clojure <1.7 
> sequential processing and use transducers exclusively. It took me a couple 
> of years to kill my habit but hey, they came late. If 1.0 shipped with 
> transducers and 1.7 introduced thread macros to create data pipelines, 
> people would probably go now: "why should I use a macro instead of comp", 
> "they are slow", "they don't compose easily" etc.
>
> What do you think? Am I missing something?


Well, inertia is probably the biggest reason, combined with the
documentation. When you have a FAQ which is "what are good use cases for
transducers", surely this is an issue.

I've never used one yet, except by accident when I forget an argument to
a function that previously would have crashed.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Let and For Doesn't Execute - Where Is My Misunderstanding?

[Phillip Lord]

They are lazy -- change "for" to "doseq"


From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Kevin 
Kleinfelter [kleinfelter.gro...@gmail.com]
Sent: 17 May 2017 19:14
To: Clojure
Subject: Let and For Doesn't Execute - Where Is My Misunderstanding?

I'm stumped by the behavior of the following code fragment.  Can someone help 
me understand what's happening?

This code:
  (println "Holding:" (:class holding))
  (let [t (:class holding)]
  (for [x t] (println "here" x))
  (for [x t] (println "there" x

Produces this output:
holding: {:fundname Mutual Fund 1, :value 123.45, :class [{:class sell-me, 
:percent 100}]}
class: [{:class sell-me, :percent 100}]
Holding: [{:class sell-me, :percent 100}]
there {:class sell-me, :percent 100}

Why doesn't the 'for' with "here" print anything?

I tried wrapping the fors with a do, but the output was the same:
  (println "class:" (:class holding))
  (let [t (:class holding)]
(do
(for [x t] (println "here" x))
(for [x t] (println "there" x)

Thanks!

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: How to Create Clojure `defn` Functions automatically?

[Phillip Lord]

I don't think that they are the same, unfortunately. In the `def` form the 
symbol is unquoted as so
much be known at the time that the form is compiled. In the second case, the 
symbol is quoted and so can also be
a variable. Hence, it cannot be guaranteed to be known at compile time.

The practical upshot of this, is that, with the `def` form, you can use the `x` 
in later in the same macro expansion. 
While with the intern you cannot, because the compiler doesn't know that `x` 
has been defined.

Phil



From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Timothy 
Baldridge [tbaldri...@gmail.com]
Sent: 14 May 2017 00:04
To: clojure@googlegroups.com
Subject: Re: How to Create Clojure `defn` Functions automatically?

Okay, so I've read these SO articles about 4 times now, and I finally think I'm 
starting to understand what the `intern` solution is doing. I would recommend 
this then can we simply state that:

`(def x 42)`

is equal to

`(intern 'x 42)`

Except the first is a compiler special form (and hence requires a compiler 
and/or macro system) while the other is a function (and requires a namespace 
system). That will probably save people a ton of reading. Like I said, I 
program Clojure a lot, and it took me about 60 minutes of reading and thinking 
about this code before I finally figured out what the problem and the solution 
and the solution being presented.


On Sat, May 13, 2017 at 4:49 PM, Alan Thompson 
> wrote:
I was just trying to answer a question posed by someone else, so I can't give 
details about the original motivation. I thought it was a good example of the 
capabilities of `intern` that I hadn't seen before, which could be useful in a 
dynamic case where one wanted to generate functions on the fly w/o using macros.

A previous answer the OP was referred 
to
 was incomplete for the new question and I was trying to fill in the missing 
parts.



On Sat, May 13, 2017 at 3:40 PM, Timothy Baldridge 
> wrote:
Sorry, but this use of intern is a pointless. What does intern give you that a 
let over a defn doesn't?

On Sat, May 13, 2017 at 4:37 PM, Alan Thompson 
> wrote:
If anyone is interested, I cleaned up the question to (hopefully) make it 
clearer, as well as adding the macro-calling-a-macro solution.

While some may consider it esoteric, I thought it was a good example of the 
power `intern` can provide, as well as a good way to avoid macros and stick to 
pure functions.

Here is the re-worked version:  
http://stackoverflow.com/questions/43958471/how-to-create-clojure-defn-functions-automatically-without-macros/

Alan

On Thu, May 11, 2017 at 10:15 AM, Alan Thompson 
> wrote:
Actually someone else wrote the original CLJS question (1):  
http://stackoverflow.com/questions/43897632/mapped-calls-to-clojurescript-macro

It was marked as a duplicate of this question (2):  
http://stackoverflow.com/questions/43897632/mapped-calls-to-clojurescript-macro 
   This one also had an answer using `intern` to avoid the need for a macro.

I didn't think question (1) was an exact duplicate of (2), and I wanted to work 
out the details of solving (1) using `intern` instead of macros (it seemed like 
a good goal at the time...).  I tried to simplify question (1) w/o the CLJS 
callback stuff, and may have oversimplified.

Since question was closed as being a "duplicate" (in error, I think), I 
couldn't answer there and posed the Q style answer separately at (3):  
http://stackoverflow.com/questions/43904628/how-to-create-clojure-defn-functions-automatically

The main goal I had here was simply finding a good way to avoid macros when 
auto-generating functions, and to generalize/document the technique described 
in (2) using `intern`.

Alan

P.S.  Regarding (3), Joel Spolsky, creator of StackOverflow, has often 
encouraged people to post both a question and its answer on the site:  
https://stackoverflow.blog/2011/07/01/its-ok-to-ask-and-answer-your-own-questions
  In fact, they even have a special button for this purpose.



On Thu, May 11, 2017 at 9:39 AM, Timothy Baldridge 
> wrote:
I assume this is a real problem you are encountering since you wrote the 
original Stack Overflow questions. As Dragan mentioned, this example doesn't 
warrant such a complex solution, maps and keywords *are* function, so all you 
really need is `foo` as a getter. Or even if they weren't functions you still 
have `(partial get foo)`.

On Thu, May 11, 2017 at 10:27 AM, Alan Thompson 
> wrote:
Since the original question was in CLJS, which has neither `intern` nor `eval`, 
does that mean the macro 

Re: Following type annotations across call sites to eliminate reflection?

[Phillip Lord]

I macro'd this out (macro's with type-hints are surprisingly tricky).

So, you end with this

(with-types [val [String Double Boolean]]
(C/met val)

Which calls C/met with the right thing without reflection (unless you
count "instance?").

The code is in tawny-owl.

https://github.com/phillord/tawny-owl/blob/master/src/tawny/util.clj

Phil

lvh <_...@lvh.io> writes:

> Hi Reid,
>
>
>> On May 21, 2016, at 11:44 PM, Reid McKenzie <m...@arrdem.com> wrote:
>> 
>> You should be able to do this:
>> 
>> (defn f [a ^bytes b ^bytes c]
>>(if (instance? ByteBuffer a)
>>  (.f binding ^ByteBuffer a b c)
>>  (.f binding ^bytes a b c)))
>> 
>> 
>> You have a bimorphic function and yes there isn't a way to express that with 
>> Clojure's calling convention and consequent hinting support. So 1) yes, 2) 
>> no but no promises there, 3) see above.
>
> Thanks! That confirms my suspicions. Unfortunately, I was hoping to solve this
> statically. Since some of these call sites are really only useful internally,
> I’ll deal with the multi-var version, because my library’s the only one to pay
> that cost.
>
>
> thanks!
> lvh
>
>> I don't have a Clojure instance handy, but this should compile to
>> 1) load the a argument
>> 2) check instanceof against the class ByteBuffer
>> 3) branch to the appropriate instance invoke
>> 4) load b, c, a, from the arguments (as Objects), checkcasting appropriately
>> to get typed as hinted values on the stack
>> 5) invoke (fully type qualified, no reflection).
>> 
>> On Saturday, May 21, 2016 at 4:57:43 PM UTC-5, lvh ‌ wrote:
>> Hi, 
>> 
>> 
>> 
>> I’m working on caesium[1], Clojure bindings for libsodium using jnr-ffi. Up
>> until recently, I was able to stick to byte arrays for all APIs; but I’ve
>> started writing new nonce-misuse resistant cryptosystems[2], so I need to
>> have some byte-level layout within a byte array. I’m using
>> java.nio.ByteBuffer to provide mutable byte array “views” on top of an
>> existing byte array.
>> 
>> The underlying C API takes (const) char *s. jnr-ffi understands how to
>> translate both byte[] and ByteBuffer to char *. Previously, I had functions
>> like:
>> 
>> (defn f 
>>   [^bytes a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> All was well; no reflection. However, now `binding` has two signatures for
>> f: [byte[] byte[] byte[]] and [ByteBuffer byte[] byte[]]. If I remove the
>> first ^byte annotation, everything works well, but this generates reflection
>> warnings.
>> 
>> 1. Does this reflection warning mean that there will be actual reflection if
>> the type is known at the call site? (I believe the answer is “yes”.)
>> 2. Does that change with AOT? 
>> 3. Is there a way to keep the same fn name, e.g. have: 
>> 
>> (defn f 
>>   [a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> … without reflection, as long as all callers of f have the type of `a`
>> statically determined? Again, I’m assuming the answer here is “no”, because
>> this resolution is done locally.
>> 
>> I can solve this in a macro since the two definitions are identical except
>> for the type hint, but I’d first just like to check that I’m not missing
>> some of the finer points of Java interop/type hinting. Also, does this mean
>> that I necessarily have two fns with different names, one for each
>> signature? E.g.:
>> 
>> (defn f-bytes 
>>   [^bytes a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> (defn f-bytebuffer 
>>   [^java.nio.ByteBuffer a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> I know that having two overloads with the same arity doesn’t work, so I’m
>> guessing the answer is “no" there as well :-(
>> 
>> 
>> Thanks in advance! 
>> lvh 
>> 
>> [1]: https://github.com/lvh/caesium <https://github.com/lvh/caesium> 
>> [2]: https://www.lvh.io/posts/nonce-misuse-resistance-101.html
>> <https://www.lvh.io/posts/nonce-misuse-resistance-101.html>
>> 
>> -- 
>> 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
&

Re: Clojure docstring style

[Phillip Lord]

The problem is that the var might not be a var yet. You'd have to
re-render code after evaluation.

Phil

Christopher Small  writes:

> Seems like this shouldn't be a problem as long as you only try to render a 
> link if there's actually such a var. This might be a little messier, but 
> would make things (overall) nicer (I think) because you wouldn't have to 
> think about a separate bit of syntax. The rendering would just happen 
> differently depending on whether or not there was something to link to. I 
> already do markdown in most of my docstrings anyway, and I'd prefer not 
> having to rewrite a bunch of docstrings to take advantage of such a 
> feature; I'm sure there are others with me as well :-)
>
> This arguably violates least-surprise / separation of concerns, but in my 
> opinion not so significantly that the costs outweigh the benefits (again, 
> as long as you only tried to link if you knew it was a var).
>
> My 2 cents...
>
> Chris
>
>
> On Sunday, May 15, 2016 at 2:03:02 PM UTC-7, James Reeves wrote:
>>
>> If the docstrings are written in markdown, this would conflict as 
>> something in backticks isn't necessarily a var name.
>>
>> In Codox, I used the wiki-link style: [[clojure.core/map]].
>>
>> - James
>>
>> On 15 May 2016 at 18:40, cskksc  wrote:
>>
>>> Hello,
>>> We are working on a new feature in CIDER which would parse a docstring 
>>> and create hyperlinks that follow the functions/vars/interop-forms 
>>> mentioned there.
>>> It is very similar to the "See Also" links shown by ClojureDocs 
>>> . Right now, we are using backticks to identify 
>>> the reference forms and create links.
>>>
>>> So a function like;
>>>
>>> (defn test-mde
>>>   "Does something with `user-ns/user-fn`.
>>>Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
>>>   []
>>>   (+ 1 1))
>>>
>>> would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.
>>>
>>> What style do you tend to use in such docstrings ?
>>> It would help us figure out whether to continue with the backticks or do 
>>> something else, like adding a configuration variable for this.
>>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] CIDER 0.11 Released!

[Phillip Lord]

Kudos to Benedek Fazekas who added that feature.


Raymond Huang <12ay.hu...@gmail.com> writes:

> Congrats. This was a really awesome release. I really how jack-in
> dynamically adds the dependencies & plugins.
>
> No more out of sync issues :)
>
> On Thu, Mar 3, 2016 at 4:05 AM Phillip Lord <phillip.l...@newcastle.ac.uk>
> wrote:
>
>>
>> This is a really fantastic release. I thought after the debugger, you
>> could probably just stop, but enlighten is a really nice addition.
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] CIDER 0.11 Released!

[Phillip Lord]

This is a really fantastic release. I thought after the debugger, you
could probably just stop, but enlighten is a really nice addition.



Bozhidar Batsov <bozhi...@batsov.com> writes:

> Hey everyone,
>
> CIDER 0.11 (a.k.a. Bulgaria) is finally out!
>
> Today Bulgarians (like me) celebrate the country's Liberation Day and the
> rest of the
> world will get to celebrate the release of CIDER 0.11. :-)
>
> Once again we've got a ton of new features, refinements and bugfixes and I
> hope you're going to love them!
>
> The changelog is here
> https://github.com/clojure-emacs/cider/releases/tag/v0.11.0
>
> Enjoy!

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Phillip Lord]

I've been trying out RC1. I've tried enabling the direct linking in
leiningen, by sticking:

:jvm-opts ["-Dclojure.compiler.direct-linking=true"]

I can't see any particular performance change (when running tests
anyway).

Is there a way to know whether it is actually working?

Phil


Alex Miller  writes:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking

-- 
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: org-mode Clojure babel

[Phillip Lord]

If you are willing to entertain a slightly different interaction model,
you might want to take a look at the lentic package

https://github.com/phillord/lentic

Instead of Clojure snippets which you can pop out and edit, this gives
you two buffers, one entirely valid clojure (which syntax highlights,
you can eval, test and so forth) and one entirely valid org (which you
can publish, show-hide and so forth). You can edit either one (the
Clojure view or the Org-mode view) and changes percolate backward.

This video shows it working with org-mode and Emacs-lisp.

https://vimeo.com/116078853

And this video shows it working with latex and clojure.

https://vimeo.com/116141808

I don't have a video of it working with org and clojure, but it does
work with them. My tawny-owl library is being (slowly) ported to this
form of literate development.

https://github.com/phillord/tawny-owl/blob/master/src/tawny/owl.clj

It also allows integration with asciidoc, and clojure. I wrote these
slides:

http://homepages.cs.ncl.ac.uk/phillip.lord/download/tawny/icbo_2015/2015_lisbon.html

as literate clojure source.

Have fun.

Phil



Johannes Brauer <bra...@nordakademie.de> writes:

> Hi Karsten,
>
> thank you for the links to your project. But until now, I haven’t succeeded to
> setup my Emacs so that I can evaluate Clojure code snippets in an org file.
>
> Johannes
>> Am 03.11.2015 um 19:56 schrieb Karsten Schmidt <i...@toxi.co.uk>:
>>
>> Hi Johannes, checkout my leiningen template for org-mode projects
>> here: http://thi.ng/babel and an example project using this template
>> here: http://thi.ng/fabric
>>
>>
>> On 3 November 2015 at 13:03, Stuart Sierra <the.stuart.sie...@gmail.com> 
>> wrote:
>>> Hi Johannes
>>>
>>> I have a working Org babel & Clojure in my Emacs setup. It's idiosyncratic
>>> to my preferences, but maybe it will be useful:
>>> github.com/stuartsierra/dotfiles
>>>
>>> –S
>>>
>>>
>>>
>>> On Tuesday, November 3, 2015 at 3:25:51 AM UTC-5, Johannes wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am looking for a working environment for using org-mode with Clojure
>>>> babel. Googleing for the issue I can only find some apparently outdated
>>>> hints. I am using org-mode version 8.2.10, Clojure 1.6.0, Leiningen 2.5.1,
>>>> and CIDER 0.10.0.
>>>>
>>>> Any hints, where I can find the right configuration?
>>>>
>>>> Johannes
>>>>
>>> --
>>> 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.
>>
>>
>>
>> --
>> Karsten Schmidt
>> http://postspectacular.com | http://thi.ng | http://toxiclibs.org
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/PldQTR3yB3A/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> 
>
>
> Staatlich anerkannte private Fachhochschule
> NORDAKADEMIE
> Gemeinnützige Aktiengesellschaft
> Köllner Chaussee 11
> 25337 Elmshorn
>
> Vorstand:
> Prof. Dr. Georg Plate (Vorsitzender), Di

Re: [meta] Unwelcome changes around here.

[Phillip Lord]

We've been here before with Fluid Dynamics. The whole rational
explanation/discussion thing didn't work last time, and probably won't
this time.

I'd suggest ending this thread immediately.

Timothy Baldridge  writes:

> To expand my previous reply. What site are you talking about? I got your
> email via my email client (Gmail) so what are you talking about?
>
> And if you are talking about the Google Groups website, perhaps contact
> them? This is completely the wrong place to complain about how your browser
> reacts to some site's view of a mailing list. This list has 0 control over
> whatever site it is that you use, so complaining here not only is
> pointless, but is also just spam.
>
> Timothy
>
> On Thu, Oct 8, 2015 at 9:09 AM, Timothy Baldridge 
> wrote:
>
>> lol, wut?
>>
>> On Thu, Oct 8, 2015 at 9:06 AM, Fluid Dynamics  wrote:
>>
>>> I don't know what you guys did, but as of about 2 days ago, when browsing
>>> this site about 1 time in 20 after reading an article and then clicking
>>> "back" to go back to the topic list my main Firefox window disappears and
>>> is replaced by a small dialog with two options, "restart Firefox" and "quit
>>> Firefox". I DON'T WANT TO DO EITHER. I WANT TO GO BACK TO THE TOPIC LIST.
>>> THAT IS WHY I CLICKED THE "BACK" BUTTON AND NOT THE "RESTART OR QUIT"
>>> BUTTON.
>>>
>>> Whatever alterations you have made to this site a few days ago, you are
>>> to un-make immediately. Hijacking your site's viewers' browsers is NOT
>>> acceptable under ANY circumstances. If you have not restored the previous
>>> behavior ("back" button behaves exactly as advertised, 100% of the time) in
>>> three (3) days (so, by Monday morning), I will quit using this site and
>>> recommend to everyone I know -- friends, everyone I work with, bosses, etc.
>>> -- that they avoid this site due to browser hijacking behavior.
>>>
>>> I recommend you simply retrieve the site's code as it existed a week ago
>>> from your backup tapes (you DO keep backups, right?) and replace the
>>> currently running web-app with this older version. The version of a week
>>> ago lacked the objectionable browser hijacking behavior. It shouldn't take
>>> you more than 30 minutes. Assuming you did your due diligence and kept
>>> proper backups, especially making them before introducing changes that
>>> could have major repercussions. That makes the three-day deadline quite
>>> generous.

-- 
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: Where do I find javadoc for clojure interfaces?

[Phillip Lord]

Probably because they are not documented. This is the source code for
ISeq in total

/**
 * A persistent, functional, sequence interface
 * 
 * ISeqs are immutable values, i.e. neither first(), nor rest() changes
 * or invalidates the ISeq
 */
public interface ISeq extends IPersistentCollection {

Object first();

ISeq next();

ISeq more();

ISeq cons(Object o);

}

I think you are supposed to guess what the interfaces mean based on the
names of the methods.

Phil


crocket  writes:

> http://clojure.github.io/clojure/javadoc/ doesn't expost interfaces like 
> clojure.lang.ISeq, so when I refer to such interfaces, I have to download 
> clojure javadoc from maven.
> I'd like to refer to those interface on web browsers. Why are they not 
> exposed on the web?

-- 
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: Using metadata to specify how calls to a macro should be indented

[Phillip Lord]

Artur Malabarba  writes:
>>
> Yes, that's what the current (but unmerged) implementation does. :)
>
>> If this cache were persisted between Emacs sessions then the problem
>> largely goes away.
>>
> Yes, that's very plausible to do.

I am happy to do the implementation for this (i.e. the persistance!),
given that I am raising the problem, if that would be a help.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Phillip Lord]

Artur Malabarba  writes:

> You're right about indentation depending on the code being evaluated, but
> that's still better than nothing. ☺
>
> People who do a significant amount of coding without a live session can
> still manually configure indentation like they currently do, and they're no
> worse off.
>
> The editor can even parse the metadata map present in the defn/defmacro, so
> as to provide some "offline" support (though I don't foresee Cider doing
> that).


It's worth being explicit in the spec, then, about whether there is an
expectation that the indentation declaration is, itself, evaluated or
not.

IIRC, the (declare (indent 1)) forms of Emacs-Lisp are *not* evaluated
by the defun/defmacro macros, so are easy enough to pull out of code. If
there are eval'd then, it becomes impossible to do this with any
accuracy.

Specifically wrt to CIDER, the easier solution is the cache the metadata
map each time it is used. I suspect that CIDER would need this for
performance -- I mean indentation requiring ongoing evaluation in
Clojure is likely to be slow. If this cache were persisted between
Emacs sessions then the problem largely goes away.

Basically, I am suggesting automatic manual configuration if you will
excuse the oxymoron.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Phillip Lord]

Fluid Dynamics <a2093...@trbvm.com> writes:

> On Tuesday, September 22, 2015 at 6:31:34 AM UTC-4, Phillip Lord wrote:
>>
>> ... The interesting question then is what 
>> percentage of the time do Clojure developers work *without* a repl 
>> active.
>>
>
> Uhhh, zero? :) 

Some I am sure. I do, though. I often write and improve documentation
without a REPL, especially when I am using my old netbook. The REPL
shortens the battery live and isn't that useful when writing English.

Still, the problem is soluable in a number of ways, I guess, and I can't
think of a better alternative (to using metadata).

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Phillip Lord]

Artur Malabarba  writes:
> Over at CIDER we're adding a feature where the author of a macro (or 
> function) can specify how that macro should be indented by adding an :indent 
> metadata to its definition. This way the editor (and other tools, like 
> cljfmt) will know what's the proper way of indenting any macro (even those 
> custom-defined) without having to hardcode a bajillion names.


One slight disadvantage with this approach is that the indentation can
change depending on the evaluation status of the code. Consider this set
of events inside emacs (I'll get back to Clojure -- it's a general
problem not Emacs specific).

 - I open the file lentic.el
 - I type M-x indent-buffer

Now, lentic.el depends on m-buffer.el which has some macros with
"declare" forms (the elisp equivalent to the metadata you are talking
off). And these are used in lentic.el.

But I haven't loaded m-buffer.el yet. So the declare forms are not
active, so the m-buffer macros indent according to normal rules. Now, I
do

 - M-x eval-buffer
 - M-x indent-buffer

This loads lentic.el which loads m-buffer.el including the macros. So,
now I get different indentation patterns. Solution in Emacs space: force
loading on m-buffer.el whenever lentic.el is *opened* rather than loaded.

Using metadata in Clojure the same situation will arise, but will be
somewhat worse. Indentation will be likely to behave differently
depending on whether the REPL is open and the evaluation status of any
macros. Given the slow start up time of the clojure REPL, this is
perhaps a more significant issue. The interesting question then is what
percentage of the time do Clojure developers work *without* a repl
active.

Just a thought.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Homoiconicity in Clojure - the broken promise

[Phillip Lord]

Don't compile it, use the EDN reader instead.

You can't do functions and that sort of thing, but the data structures
will work.

Phil

Olek aleksander.nas...@gmail.com writes:

 Hi!

 Today I fall into:

  java.lang.RuntimeException: java.lang.ClassFormatError: Invalid method 
 Code length 88118 in class file xxx$eval304 (xxx.clj:274) (xxx.clj:3)

 problem.

 The reason is that I tried to use data as code and just execute the slurped 
 AST in order to produce another form of code (I'm converting the code from 
 one language to another).
 Is there any way to switch Clojure to interpreted mode instead of compiling 
 the data structure form? The structure what causes the headache are arrays 
 initializers.
 I would like to keep the code simple since the language should solve the 
 problem for me, not me for the case of stupid 64kb method limit.

 Thanks in advance,
 Olek

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Unable to write GPL software with clojure?

[Phillip Lord]

Sean Corfield s...@corfield.org writes:

 On 8/18/15, 3:04 PM, Phillip Lord clojure@googlegroups.com on behalf of 
 phillip.l...@russet.org.uk wrote:


There *is*, however, an issue with use of many parts of the Clojure
Ecosystem.

 Even if the Clojure/core definition extended to Contrib libraries, under
 this consideration, you couldn’t write a non-trivial Clojure program with just
 the core/contrib namespaces without duplicating a LOT of code that is already
 out there. So I believe Bodil is correct _in practice_ even if she may be
 _technically_ incorrect in theory.


I think that you are correct that the use of EPL has consequences, and I
would have assumed that what you said was correct, but then I checked
up. For instance, Magnar was worried about this use of GPL for his site.

http://www.parens-of-the-dead.com/

So, I went and looked it up and actually neither of the two libraries he
is using are EPL. So, already non-EPL licenced Clojure libraries are
more widespread than I thought.

It would be interesting to do a survey of license use. I am sure EPL is
common, partly because Clojure uses it, and partly because leiningen
puts it in as the default (bad leiningen!).


For example, I believe that releasing a leiningen plugin
under GPL would be impossible, since lein is EPL and is not part of the
standard interface (I pick lein as an example here, not for any other
reason).

 Actually, based on what both the Eclipse Foundation and the Free Software
 Foundation say about writing GPL plugins for Eclipse, I think this is a case
 where you _could_ write GPL Clojure code, albeit under a slightly modified GPL
 (see my response to Kyle, with links to both Eclipse and FSF websites
 discussing this exact situation).

Yeah, it's a variant on the classpath exception.


 Again tho’, you’d need to avoid the greater ecosystem of EPL-covered Clojure
 libraries and stick to just core (and maybe contrib).

It's an unfortunate situation in some ways, but one that has been
entered into consciously. Doubly unfortunate in that it is largely for
technical reasons, as far as I can tell, rather than a deliberate desire
to EPL and GPL to be incompatible. Such is life. Licences are more
complex than code.

 EPL is more business-friendly than GPL insofar as companies can combine EPL
 code into their (commercial) products much more easily than GPL code, so I’d
 view this as much less of a technical decision than a solid business decision,
 made for the benefit of Clojure at large, so it can spread into more
 companies.


I understand that. I'd rather not discuss motivations, lest we end up in
yet another long license thread. I am only interested in consequences.


 (caveat: IANAL but I’ve been through OSS license audits at companies that are
 large enough to care deeply about this sort of stuff — unfortunately)

Agreed. My concern with the EPL is (partly) that it is GPL incompatible,
but more the *reason* that it is incompatible. It has a choice of law
clause. Maybe that's fine for the US. But in the UK? I have no idea at
all whether it means anything at all (probably it does not), but
possibly it does.

It's not likely to change now as I said, so there is probably nothing
that can be done about it.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to write GPL software with clojure?

[Phillip Lord]

Bodil is wrong, I belive. You can write GPL software with clojure, in
the same way that you can write GPL software with Java. Or GPL software
for Windows.

The relevant provision in the GPL is the bit about standard interface
and system libraries. You can link GPL code to a system library
without release of the source of the system libraries at all.

For languages, we have this:

in the case of interfaces specified for a particular programming
language, one that is widely used among developers working in that
language.

This is a bit difficult to interpret, but for Clojure any library in
clojure.core which is released in the main Clojure jar would be covered.

There *is*, however, an issue with use of many parts of the Clojure
ecosystem. For example, I believe that releasing a leiningen plugin
under GPL would be impossible, since lein is EPL and is not part of the
standard interface (I pick lein as an example here, not for any other
reason). So, Clojure is not an ideal environment for GPL code, since
there will be many libraries you cannot use.

I do not believe that the EPL on Clojure has any implications at all for
code implemented in Clojure, but I do not know EPL that well. IIUC, I
cannot release modified versions of Clojure under anything other than
EPL, but that is the main limitation.

It's an unfortunate situation in some ways, but one that has been
entered into consciously. Doubly unfortunate in that it is largely for
technical reasons, as far as I can tell, rather than a deliberate desire
to EPL and GPL to be incompatible. Such is life. Licences are more
complex than code.


Kyle Sexton k...@mocker.org writes:
 Can anyone weigh in on whether it is possible to write GPL code with clojure?
 Seen some recent[1] tweets saying that the EPL on clojure core prevents
 writing GPL code with clojure.

 [1] - https://twitter.com/bodil/status/633566680879366144

-- 
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: multi-arity functions with macros

[Phillip Lord]

Fluid Dynamics a2093...@trbvm.com writes:
 (defn ^:private form-with-arity[n] 
   ;; left as an exercise for the reader 
 ) 

 (defmacro ^:private m-default-ontology 
   `(defn default-ontology 
   ~@(map form-with-arity (range 1 10 

 (m-default-ontology) 

 Or am I missing something more obvious? 

 Phil 


 Well, the example case could be replaced with (def default-ontology 
 dispatch). :)

Oh yes, that's true! Or rather I missed out some critical information.
The function is actually variadic, so there is a final, fall back
function of this form:

([f a b c  args]
   (do-something-different-with-apply f a b c args))

Also (although you can't tell from the information given), dispatch is a
macro, so (def default-ontology dispatch) changes the semantics quite a
lot!

 Beyond that, you might want to consider generating such repetitive and 
 predictably-structured functions with a custom def-something style macro, 
 but it looks like you already are.

Another possibility would be to use a macrolet, which would reduce some
of the cruft I guess. Or even

(eval
  `(defn stuff
 ~@(map...)))

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Time-Bombed Open License - thoughts?

[Phillip Lord]

Fergal Byrne fergalbyrnedub...@gmail.com writes:
 That's a great post (and the Mailpile post is also a great discussion of
 the topic), thanks for sharing.

 The GPL already has a clause which allows the owner (and downstream user)
 to defer, for 12 months, the full obligations of GPL

It really doesn't.

 see this guy's take:
 https://github.com/zooko/tgppl/blob/master/COPYING.TGPPL-v2-draft.rst


This is GPL with an exemption to it, which is a different thing. This
would only give you the right to distribute code licenced under the
TGPPL. You could not combine this code with GPL code as far as I can
see, and release it under any conditions other than the GPL.


 Our idea is a bit more startup-friendly - on the commercial side of the
 dual license, everyone can keep their improvements/extensions closed for up
 to the full duration of the time-bomb, but they then have to give it all
 back.

I am confused what side of the fence the startup is here. Are they the
people producing the software (in which case, getting funding with only
2 years of enforceable IP seems problematic) or are they they people
extending it? That might work I guess, because they would be able to use
software restrictively for 2 years, that otherwise they could not use at
all.

 As to enforceability, I'm guessing copying the language of GPL is hopefully
 sufficient. These things are rarely tested as far as I know, but I'm sure
 someone knows better than me.


The devil is in the detail. The GPL has been tested on a pretty regular
basis. The interesting thing about this would be working out exactly
what distribution means -- rather critical since it starts the 2 year
clock running in this case.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: multi-arity functions with macros

[Phillip Lord]

Interesting -- it's certainly more generic than the solution that I have
worked up. I'd need to add something for the variadic fall-back call.

Thank you!

Francis Avila fav...@breezeehr.com writes:

 This is exactly the approach to take: a macro which expands to a defn with 
 all your arities filled out.

 Here's a simple approach which might be enough for your problem: it will 
 splice in argument names whenever some marker symbol is encountered, and 
 repeat for the range of arities you want.


 (defn splice [marker replacement form]
   (cond
 (seq? form) (reduce #(if (= marker %2)
   (into %1 (reverse replacement))
   (conj %1 (splice marker replacement %2)))
   () (reverse form))
 
 (or (vector? form) (set? form))
 (reduce #(if (= marker %2)
   (into %1 replacement)
   (conj %1 (splice marker replacement %2)))
   (empty form) form)
 
 (map? form)
 (reduce-kv #(assoc %1 (splice marker replacement %2)
   (splice marker replacement %3)) {} form)
 
 (= marker form)
 (throw (ex-info Cannot splice into a top-level form! {}))
 
 :else form))

 (defmacro defvariadic
 ;; Full support for defn options (attr-map, docstring, pre/post conditions)
 ;; an exercise for the reader.
   [name marker max-arity params  body]
   (assert (and (symbol? name) (nil? (namespace name
   (assert (and (symbol? marker)))
   (assert (and (integer? max-arity) (= 0 max-arity 24)))
   (assert (vector? params))
   (let [arg-syms (mapv gensym (subs abcdefghijklmnopqrstuvwxyz 0 
 max-arity))
 params+bodies
  (map (fn [arity]
 (let [var-params (subvec arg-syms 0 arity)]
   (list* (splice marker var-params params)
 (splice marker var-params body
(range max-arity))]
 `(defn ~name ~@params+bodies)))


 This produces output like the following:

 (clojure.pprint/pprint (macroexpand-1
   '(defvariadic default-ontology-dispatch  5
 [f ]
 (dispatch f 


 (clojure.core/defn
  default-ontology-dispatch
  ([f] (dispatch f))
  ([f a23733] (dispatch f a23733))
  ([f a23733 b23734] (dispatch f a23733 b23734))
  ([f a23733 b23734 c23735] (dispatch f a23733 b23734 c23735))
  ([f a23733 b23734 c23735 d23736]
   (dispatch f a23733 b23734 c23735 d23736)))






 On Thursday, June 4, 2015 at 11:55:23 AM UTC-5, Phillip Lord wrote:


 I have a number of fairly nasty functions with a form that looks like 
 this: 

 (defn default-ontology 
   ([f] 
  (dispatch f)) 
   ([f a] 
  (dispatch f a)) 
   ([f a b] 
  (dispatch f a b)) 
   ([f a b c] 
  (dispatch f a b c)) 
   ([f a b c d] 
  (dispatch f a b c d)) 
   ([f a b c d e] 
  (dispatch f a b c d e)) 
   ([f a b c d e fa] 
  (dispatch f a b c d e fa)) 
   ([f a b c d e fa g] 
  (dispatch f a b c d e fa g)) 
   ([f a b c d e fa g h] 
  (dispatch f a b c d e fa g h)) 
   ([f a b c d e fa g h i] 
  (dispatch f a b c d e fa g h i)) 
   ([f a b c d e fa g h i j] 
  (dispatch f a b c d e fa g h i j))) 

 The reason for all of this is that I need to avoid the use of variadic 
 function calls for performance reasons -- this function gets called a 
 lot in my code base, and without this unwinding, I box and unbox 
 consistantly. 

 Now, I dislike the code repetition here, and indeed have found already 
 found one bug in my code where I missed a variable out, something like 

 ([f a b c d] 
  (dispatch f a b d)) 

 which is hard to pick up on. 

 I can't make the whole thing a macro because I need to pass this as a 
 first class function. And I can't macro each of the variadic elements 
 since the I'd need to return two elements at once. 

 The best I have done up with so far is: 

 (defn ^:private form-with-arity[n] 
   ;; left as an exercise for the reader 
 ) 

 (defmacro ^:private m-default-ontology 
   `(defn default-ontology 
   ~@(map form-with-arity (range 1 10 

 (m-default-ontology) 

 Or am I missing something more obvious? 

 Phil 



-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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

multi-arity functions with macros

[Phillip Lord]

I have a number of fairly nasty functions with a form that looks like
this:

(defn default-ontology
  ([f]
 (dispatch f))
  ([f a]
 (dispatch f a))
  ([f a b]
 (dispatch f a b))
  ([f a b c]
 (dispatch f a b c))
  ([f a b c d]
 (dispatch f a b c d))
  ([f a b c d e]
 (dispatch f a b c d e))
  ([f a b c d e fa]
 (dispatch f a b c d e fa))
  ([f a b c d e fa g]
 (dispatch f a b c d e fa g))
  ([f a b c d e fa g h]
 (dispatch f a b c d e fa g h))
  ([f a b c d e fa g h i]
 (dispatch f a b c d e fa g h i))
  ([f a b c d e fa g h i j]
 (dispatch f a b c d e fa g h i j)))

The reason for all of this is that I need to avoid the use of variadic
function calls for performance reasons -- this function gets called a
lot in my code base, and without this unwinding, I box and unbox
consistantly.

Now, I dislike the code repetition here, and indeed have found already
found one bug in my code where I missed a variable out, something like

([f a b c d]
 (dispatch f a b d))

which is hard to pick up on.

I can't make the whole thing a macro because I need to pass this as a
first class function. And I can't macro each of the variadic elements
since the I'd need to return two elements at once.

The best I have done up with so far is:

(defn ^:private form-with-arity[n]
  ;; left as an exercise for the reader
)

(defmacro ^:private m-default-ontology
  `(defn default-ontology
  ~@(map form-with-arity (range 1 10

(m-default-ontology)

Or am I missing something more obvious?

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[Phillip Lord]

richard.mo...@posteo.de writes:
 The goal of this project is to develop a comprehensive and extensible
 model for describing Clojure sources from an API perspective. I will
 also write a program that analyses Clojure sources according to this
 model and outputs data documenting their usage. This could be compared
 to Javadoc, but emitting data to be consumed by other tools instead of
 HTML. In order to foster adoption, I will provide extensive
 documentation, including examples of such consumer tools, and
 emphasize active communication with the community. ☙

I would like to see a mechanism for structure in the clojure doc
strings. So, consider the second definition in core.clj.


(def
 ^{:arglists '([x seq])
:doc Returns a new seq where x is the first element and seq is
the rest.
   :added 1.0
   :static true}

 cons (fn* ^:static cons [x seq] (. clojure.lang.RT (cons x seq

Analysing this further:

Returns a new seq where x is the first element and seq is the rest.

We have two uses of 'seq', where one refers to the general concept (or
to the interface ISeq), and the other refers to the parameter defined in
:arglists. We have 'x' which refers to an :arglists parameter also. And
we have 'first', 'rest' and 'seq' none of which refer to the function
names in the same namespace as cons. Although they might do if the doc
string were reworded:

Returns a new ISeq, s, where (first s) returns x and (rest s)
returns seq.


Not sure whether this is in scope or not, but it is about usage of
metadata.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[Phillip Lord]

Indeed. I think Emacs docstrings are a bottom line -- Clojure should be
able to make these distinctions at least. And this would in turn allow
tools to use them. Why can I not click on function names in a docstring
and go to the function definition?

Phil

Bozhidar Batsov bozhi...@batsov.com writes:

 I think the real problem is the lack of conventions for adding metadata to
 docstrings. I sorely miss `some-func/var' and SOME-PARAM from Emacs Lisp.
 It's always
 clear where you refer to other functions/variables and to parameters. This
 makes it way easier to read (and parse) a docstring.

 On 6 May 2015 at 14:17, Phillip Lord phillip.l...@newcastle.ac.uk wrote:

 richard.mo...@posteo.de writes:
  The goal of this project is to develop a comprehensive and extensible
  model for describing Clojure sources from an API perspective. I will
  also write a program that analyses Clojure sources according to this
  model and outputs data documenting their usage. This could be compared
  to Javadoc, but emitting data to be consumed by other tools instead of
  HTML. In order to foster adoption, I will provide extensive
  documentation, including examples of such consumer tools, and
  emphasize active communication with the community. 

 I would like to see a mechanism for structure in the clojure doc
 strings. So, consider the second definition in core.clj.


 (def
  ^{:arglists '([x seq])
 :doc Returns a new seq where x is the first element and seq is
 the rest.
:added 1.0
:static true}

  cons (fn* ^:static cons [x seq] (. clojure.lang.RT (cons x seq

 Analysing this further:

 Returns a new seq where x is the first element and seq is the rest.

 We have two uses of 'seq', where one refers to the general concept (or
 to the interface ISeq), and the other refers to the parameter defined in
 :arglists. We have 'x' which refers to an :arglists parameter also. And
 we have 'first', 'rest' and 'seq' none of which refer to the function
 names in the same namespace as cons. Although they might do if the doc
 string were reworded:

 Returns a new ISeq, s, where (first s) returns x and (rest s)
 returns seq.


 Not sure whether this is in scope or not, but it is about usage of
 metadata.

 Phil

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Performance of defmulti in both ClojureScript and Clojure

[Phillip Lord]

I think that the answer is, it depends, and, there might be some
surprises in store.

In my own use, I found multimethods collapse in performance as a result
of changes to the interface hierarchy in the library I was using (my
tests cases went from 45s to over 4mins).

I circumvented this by fiddling with the dispatch function, so that it
returned ONLY classes that exactly matched one of the ones in the
multi-method, and memoizing the look up of these classes. In effect,
this closes down the multi-method, so it can no longer be freely
extended. This dropped the time of my test cases dramatically.

How widely applicable these results are, I do not know, as I never got
down to the mechanistics underneath. Still, my conclusion is, you might
want to test things out first!

My full set of experiments are here...

http://www.russet.org.uk/blog/3007


Timur timurha...@gmail.com writes:

 Hi everyone,

 There are situations where I want to dispatch functions using based on 
 their certain properties. I can also use case statements instead but it 
 looks more coupled and more change is required if I want to add new types. 

 What I want to ask is if I need to avoid using multi-methods for 
 performance reasons? I read somewhere that they are not really fast but the 
 posts were old and the performance might have been improved in between. 
 Should I favor case and cond branches instead of defmulti when I need 
 performance? 

 Thanks for your help!!!

-- 
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: Performance of defmulti in both ClojureScript and Clojure

[Phillip Lord]

Alex Miller a...@puredanger.com writes:
 Sounds like you might have been running into the absence of multimethod 
 caching for the default case (http://dev.clojure.org/jira/browse/CLJ-1429), 
 which has been fixed in 1.7. 

No, I don't think; my default case was and is throw an exception.


 Just on a side note, that repo does not change the default lein :jvm-opts, 
 which are bad for benchmarking. I recommend at least:

   :jvm-opts ^:replace [-server]

 Criterium now yells at you if you haven't done this. 


I know. My use case, though, involves using Clojure through the REPL, so
I tested in that way, since this is how it runs in lein.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Generating .clj files with content

[Phillip Lord]

Tassilo Horn t...@gnu.org writes:
 Using qualified names (like clojure.core/ns) is perfectly fine except if
 a human is going to read the code.  But you can force unqualified
 symbols by using ~'sym.  And you can create a symbol from a string with
 the function `symbol`.


You might want to take a look at the backtick library

https://github.com/brandonbloom/backtick

It provides a syntax-quoting without namespace qualification (or with
it, at your option), which is nicer than putting ~'sym everywhere.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[Phillip Lord]

Fluid Dynamics a2093...@trbvm.com writes:

 On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:

 The benefit is that Emacs is that its not constantly changing, and it 
 gives you some stability over the years. I like latex, for instance, for 
 the same reason. I can still access a 10 year old document and use it.


 First of all, there are other posts in this thread complaining about 
 constantly changing stuff breaking things! One such post is by Colin Yates.


Yes. Obviously, newer stuff is changing.

 Second, to the extent that it isn't changing, it is legacy.

It makes little sense to complain about things changing, and then to say
things are legacy when they are not changing.

Legacy code is not code that is old. Legacy code is not code that you
wish were better. Legacy code is not even code that is nasty and hairy.

Legacy code is code for which there is a better alternative, but which
the activation energy of removing is too high.

I scanned most of the rest of your post. It's a bit of a ramble, and
doesn't relate to much of the software that I use. Broadly, I agree,
that old software sometimes behaves in a way that we would not write
today. Equally, software which has been written today sometimes suffers
from problems that were long solved in older software. The costs from
using old software are real, yes, but then so are the costs of using new
software, especially, if this entails constantly trying out the latest
and greatest technology just for the sake of it.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any chance of a module system being added to the language?

[Phillip Lord]

I did it with protege-nrepl.

Protege is a tool build on eclipse, which is build on OSGi.
protege-nrepl embed clojure inside Protege, and enables it to put up an
NREPL server.

I found it to be a bit of a nightmare to be honest. The key problem was
was that for protege-nrepl to be useful, I need to able to expand the
running Clojure dynamically. Otherwise, I have to bundle all of the
clojure that I want to use with protege.

Theoretically, this should be easy with pomegranate, but in practice
this fails because OSGi requires the package to state before what
classes a package is going to use when the OSGi package is built. But I
don't know what those are!

The eventually solution was to add this 

DynamicImport-Package*/DynamicImport-Package

to my maven config.

https://github.com/phillord/protege-nrepl/blob/master/nrepl-plugin/pom.xml

This solves the problem, but AFAICT defeats the point of OSGi since now
there is no isolation.

Phil

Colin Yates colin.ya...@gmail.com writes:

 Do you have any references to OSGi and Clojure?

 On 2 April 2015 at 15:11, Alex Miller a...@puredanger.com wrote:
 It's possible we could make use of Java's module system if it ever actually
 gets released in Java 9. While I followed it pretty extensively when they
 first started discussing it (7 or 8 years ago!) I have not been keeping up
 on it lately. Some people have used OSGi with Clojure but I don't gather
 that it's a picnic. Designing a good module system, especially one that
 takes into account Java's classloader architecture, is a challenging task.

 Personally, I think it's probably useful to think about your namespace
 layout, so I'm not really looking to get rid of the thinking part. :)


 On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote:

 I'd love a module system solving the following problems:

 1. Dependency isolation
 2. Being able to export vars without having to think about namespace
 layout in the project

 1. Is a serious problem where transitive dependencies on the classpath put
 consumers in jar hell and force library and tooling authors to either
 inline code, re-invent the wheel, attempt to run their code in isolated
 classloaders or turn to source rewriting.

 2. Is a nice to have which is solved today by in potemkin's import-vars,
 but I think this makes sense to include if modules are added to the
 language.

 We might get some of this for free whenever project jigsaw gets released,
 but considering it was due in 2007, originally, I'm hoping this can be
 solved without the help of Oracle.

 --
 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.

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[Phillip Lord]

Alexis flexibe...@gmail.com writes:

 Colin Yates colin.ya...@gmail.com writes:

 I used it a few years back

 [snip]

 [and] even after man-months spent tinkering, hunting down the right version
 on MELPA or MARMALADE (or whatever it is called)

 i basically only use MELPA and GNU ELPA. In terms of the ~200 packages i've
 installed from MELPA, i can't remember having to deal with versioning issues
 at all. Further, despite some people fretting about the theoretical lack of
 stability of packages on MELPA, i've only rarely had to deal with broken
 packages - and those breakages have been fixed very rapidly by the
 maintainers.

I have. Mostly with Clojure as it happens -- the move from slime to
nrepl was quite painful. And the lack of stability on MELPA was a
significant cause.

 *nod*

 However, Emacs configuration management has, i feel, improved significantly
 over the last couple of years, with things like `use-package`:

 https://github.com/jwiegley/use-package

 enabling one to create easily-reproducible config setups across
 environments/machines.

This was the cause of all my grief with MELPA though. My setup is
use-package based (actually, I added the ELPA/package.el integration).
I sync my .emacs across machines, and use-package auto-installs missing
packages. This meant I got different versions on every machine,
depending on when the auto-install happened.

Fingers crossed more package authors add support for MELPA stable. I use
it exclusively now.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[Phillip Lord]

Colin Yates colin.ya...@gmail.com writes:
 The camel breaking straw for me was yet another iteration of 'come on,
 let's tame this beast, find package X to scratch itch Y, update and
 watch something break. Spend hours numptying and googling around, give
 up, fresh re-install, do some paid work'. Rinse and repeat.

It is worth saying, of course, that a lot of this has gone away, and
that package management in Emacs has changed massively in the last few
years. MELPA-stable has helped me move of the bleeding edge in most
cases. Still not perfect, but it is coming along.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[Phillip Lord]

Fluid Dynamics a2093...@trbvm.com writes:
 That's nonsense.  As soon as you have made yourself acquainted with the 
 basic Emacs terminology and concepts, getting started with Clojure 
 development is a piece of cake.  Of course,


 the devil is in the details. Including the implementation details that leak 
 out all over the place, starting with the ubiquitous use of the term 
 buffer in user-facing documentation.


This is not an implementation detail. It's just the name that the Emacs
developers picked. There is a data structure which represents this idea
of a buffer underneath.

It's a slightly unfortunate name, as it's unusual, but better that
window which is usual but means something else. But what you see is
history poking through, not implementation detail. If Emacs were written
now, these things would have different names. It's a price you pay with
using emacs.

The benefit is that Emacs is that its not constantly changing, and it
gives you some stability over the years. I like latex, for instance, for
the same reason. I can still access a 10 year old document and use it.


Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[Phillip Lord]

Mikera mike.r.anderson...@gmail.com writes:

 I would say, lack of numpy or equivalent. And nice tools to link between 
 Clojure and the many C/Fortran numeric libraries. Python and R do this 
 natively. 


 core.matrix is effectively the equivalent of NumPy

 In some ways it is much more versatile, because it works with a general 
 array abstraction rather than a specific concrete array format. There are 
 core.matrix implementations (e.g. Clatrix) that link to native numerical 
 libraries.


I didn't know about the native implementation!

But my point was a more general one. If I have an old fortran numerical
library that I want to pull into my analysis. How easy is it to do this
in python and how easy in Clojure?

 native back end performance since you can use tools like Clatrix to access 
 BLAS etc. And aside from that, the JVM gives you a lot of big advantages on 
 the server side (sophisticated memory management, excellent JIT 
 compilation, concurrency, portability, library ecosystem etc.). I never 
 quite understand the motivation of people who seem to want to reinvent all 
 of this (probably badly) in native code. The JVM is an amazing piece of 
 engineering, and I believe that a lot of the sucess of Clojure comes from 
 taking advantage of this.


My experience of most big data projects is that a lot of it involves
writing some scripts to do some data munging, and then plug it into
some existing library for numerical analysis.

The JVM is a good piece of software and supports an amazing ecosystem.
It's just not that easy to break out of the ecosystem.

Of course, this might just be because people haven't tried enough. I
think that the lack of syntactic flexibility of Java made it problematic
in the past. Now with languages like Clojure or Scala which have at
least as much of flexibility as python (more in fact), perhaps this will
change.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[Phillip Lord]

Sayth Renshaw flebber.c...@gmail.com writes:
 I last learned clojure in 1.2. Just curious why Clojure hasn't
 developed as a go to for data science?

 It never seems to get a mention R,Python and now Julia get the
 attention. By design it would appear that Clojure would be a good fit.
 Is it a lack of libraries, ease of install, no good default
 environment (R Rstudio, IPython ) where as you would need to use emacs
 with clojure, or is there just a better default use of Clojure?


I would say, lack of numpy or equivalent. And nice tools to link between
Clojure and the many C/Fortran numeric libraries. Python and R do this
natively.

Maybe if Clojure pulls itself away from the JVM this will change. One
big problem with both python and R for data science is that a lot of
interactive data visualisation happens on the web these days, and
neither python nor R support that so well. An ecosystem with a C hosted
clojure at the back end and Clojure script at the front end might work
well.

Phil



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Licensing of software products created with Clojure and related

[Phillip Lord]

Well, you have to read the license, or employ a lawyer to do so.

You mostly can do what you want with Clojure under EPL. You can build 
proprietary products with Clojure and distribute them
with or without Clojure itself. The main limitation is that you cannot 
distribute a modified version of Clojure without releasing  the 
source to those modifications.

At least that is how I read it.


From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of David 
Christensen [dpchr...@holgerdanske.com]
Sent: 20 February 2015 18:02
To: clojure@googlegroups.com
Subject: Licensing of software products created with Clojure and related

clojure:

I'm looking for a LISP-like programming language with a robust library
and multi-platform support for open- and closed-source projects
(scripts, applications, libraries, plug-ins, whatever).  Clojure looks
like a good possibility.


It appears that Clojure itself is licensed under the Eclipse Public
License v 1.0:

 http://clojure.org/license

 https://www.eclipse.org/org/documents/epl-v10.php

 https://www.eclipse.org/legal/eplfaq.php


How do I figure out what licenses are involved for the various
combinations of target platforms (Linux, Windows, OS/X, iOS, Android,
WWW), libraries (Java/JRE, .NET, JavaScript), tools (leiningen), etc.?


How do I figure out what combinations are valid or invalid for open- and
closed-source development and distribution?


TIA,

David

--
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: Satisfies? seems strangely slow

[Phillip Lord]

Tassilo Horn t...@gnu.org writes:
 I don't think satisfies? is worth optimizing as using ton of it seems
 antithetical to protocols. It signals to me that a caller does in fact
 care about the implementation, whereas protocols are about not
 caring. Like your PR, if you want to ensure a protocol's coverage, you
 can also extend a protocol to Object and/or nil. Not sure what a valid
 use case would be for calling satisfies? on a hot path would be.

 I use satisfies? for optional features, e.g., if some data structure
 satisfies some protocol, then that optional feature is enabled, else
 it's disabled.  But that's not really on a hot path so I don't care much
 about satisfies? performance.


Have you tried just implementing the protocol over Object to do
nothing? Then putting use an alternative implementation of the protocol
where you want.

I did this to avoid lots of

(when (satisfies? AProc o)
   (do-method o))

and just have

(do-method o)

instead. But if I understand how protocols are implemented (which I
don't), I think this also avoids the type look up.

Phil
 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TDD and lein

[Phillip Lord]

CPU is cheap these days, why not do both?

I tests within CIDER when I want to. But I normally run lein test on
every file change (using a inotify script, but there's probably a nicer
way). This crashes a lot, for instance, when I save a half finished
change, but it also tells me when I have messed up what I think is a
trivial change.

Obviously, I don't do this on laptops running on batteries. But on a
desktop with multi-core and a second screen, it's helpful.

Udayakumar Rayala uday.ray...@gmail.com writes:

 Not sure if you are doing this, you can run the tests in cider itself. This
 is much quicker than running lein test outside particularly when you are
 doing TDD.

 I use clojure.test so every deftest method is a function which you can run
 to see if the test passes or fails. Or you can run run-tests
 https://clojuredocs.org/clojure.test/run-tests for running all or tests
 under a namespace.

 On Thu, Jan 8, 2015 at 5:11 PM, Robin Heggelund Hansen skinney...@gmail.com
 wrote:

 The reason lein is initially slow, has to do with Clojures bootstrapping
 process, which is slow. People tend to avoid starting clojure programs
 repeatedly, and thus do alot of work from the repl, or using leiningen
 plugins which keeps running and listens for changes.

 Take a look at lein-test-refresh for tdd:

 https://github.com/jakemcc/lein-test-refresh

 It detects when you change your code, incrementally compiles and re-runs
 the tests. It runs your tests everytime you save a file :)

 kl. 12:32:44 UTC+1 torsdag 8. januar 2015 skrev Andrea Crotti følgende:

 Hi guys,

 I'm starting to use Clojure a bit more seriously, I knew already Lisp a
 bit and Haskell, in plus I've been using Emacs for a long time so
 luckily it's not as hard, and it's a lot of fun.

 I'm using Emacs + Cider for development and it works wonderfully,
 however I have a few problems/questions trying to do TDD.

 1. Isn't it possible to make Lein more verbose?

It's often quite slow and it would be nice to know what is going
on, I can stand the slowness but at least tell me something :D

 2. When is exactly that I need to run again lein test (which is
painfully slow) and when just rerunning the tests from the same REPL
suffice?

I thought only when changing dependencies, but I had different
experiences so I'm not too sure about the rule.

And what command exactly is Cider triggering when I run the tests?
It would be nice to be able to see somewhere more information like:
- compiling file x
- running tests for y with command z

  3. Does incremental compilation work well/make sense for Clojure?
 I found something but the fact that it's not done straight away in
 Leiningen makes me think it's maybe not much used?

 Thanks a lot, and congratulations to all the developers for the great
 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.


-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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] lentic 0.6: Multiple syntactic views over Emacs buffers

[Phillip Lord]

Lentic.el 0.6 is now available.

Lentic is an Emacs mode which supports multiple views over the same text. This
can be used for a form of literate programming. It has specific support for
Clojure which it can combine with either LaTeX, Asciidoc or Org-Mode.

Two lentic buffers, by default, the two share content but are otherwise
independent. Therefore, you can have two buffers open, each showing the
content in different modes; to switch modes, you simply switch buffers. The
content, location of point, and view are shared.

However, lentic also allows a bi-directional transformation between lentic
buffers -- the buffers can have different but related text. This allows, for
example, one buffer to contain an Emacs lisp file, while the other contains
the same text but with ;; comment characters removed leaving the content in
org-mode, enabling a form of literate Emacs-Lisp programming with no change to
either org-mode or Emacs-Lisp. Ready made transformations are also available
for Clojure, latex and asciidoc.

Lentic is both configurable and extensible, using the EIEIO object system.

Lentic was previously known as Linked-Buffers.

The 0.6 release is heavily refactored from previous versions and includes an
incremental update feature which performs well, coping well with buffers of
3-4k lines in length.

Available on MELPA-stable, MELPA and Marmalade
https://github.com/phillord/lentic
http://www.russet.org.uk/blog/3035

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Is there a reason ns macro is not a function?

[Phillip Lord]

There are only, I think, four reasons for making things a macro rather
than a function. The one that seems to apply to the ns macro is that it
saves typing -- that is, you don't have to sprinkle quoted symbols
everywhere. And you can ignore the difference between lists and vectors.

Compare...

(ns my-name-space
  (:use [their-name])

with this...

(ns 'my-name-space
  [:use ['their-name-space]])

The disadvantage is that the ns macro is not extensible (not strictly a
consequence of it being a macro, but in practice it is so). So I wrote a
new namespace declaration that was a function. This lets me program the
ns declaration so, for example, I can share a set of imports between
namespaces.

https://github.com/phillord/namespace-experiments/blob/master/src/namespace/examples.clj

Not a serious project, and just something I was playing at, but I still
think that the idea is sound (unlike the implementation).

Phil


Angel Java Lopez ajlopez2...@gmail.com writes:

 Hi!

 My first guess: a normal function evaluates all its arguments. ns uses
 (:require ) (:use.. ) (:import ..) that should be not evaluated at ns
 apply. The alternative is to make ns an special form, but macro should be
 more flexible.

 Instead, in-ns is simpler, and it can be implemented as a normal function.

 Angel Java Lopez
 @ajlopez


 On Tue, Dec 30, 2014 at 5:30 AM, Petr petrg...@gmail.com wrote:

 Hello.

 Does anyone know why clojure.core/ns macro is not implemented as function?
 It seems that it should work that way except that probably it would be
 nicer to have in-ns call at the top level.

 --
 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.


-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Richelieu: a library for advising functions

[Phillip Lord]

Looks nice. It's pretty similar to Robert Hooke though -- which is more
of an advice library than a hook library despite it's name. 

Edwin Watkeys e...@poseur.com writes:

 Hello,

 Richelieu, a library for advising functions, is in something resembling 
 announcement-worthy shape. It's available at the following URL:

 http://github.com/thunknyc/richelieu

 During my experience writing thunknyc/profile and the associated CIDER 
 support, I realized that advising or decorating functions is something 
 that's been getting reinvented over and over. I wanted to put an end to 
 that. Richelieu supports advising functions as well as vars and namespaces. 
 Multiple advise functions can be associated with a function, and advise 
 functions have access to the underlying var or function this is being 
 decorated. Below is an edited sample from the README that shows how to 
 implement tracing advice using the library.

 I hope this may be useful to one or more people out there. I plan on 
 modifying thunknyc/profile to use Richelieu as part of a push to implement 
 additional profiling modalities.

 Regards,
 Edwin

 (require '[richelieu.core :refer [advice advise-ns
   *current-advised*
   defadvice]])

 ;;; Here are some simple functions.
 (defn add [ xs] (apply + xs))
 (defn mult [ xs] (apply * xs))
 (defn sum-squares [ xs]
   (apply add (map #(mult % %) xs)))

 ;;; This tracing advice shows how to get the current advised object,
 ;;; which can either be a var or a function value, depending on the
 ;;; context in which the advice was added.
 (def ^:dynamic *trace-depth* 0)

 (defn- ^:unadvisable trace-indent []
   (apply str (repeat *trace-depth* \space)))

 (defadvice trace
   Writes passed arguments and passes them to underlying
   function. Writes resulting value before returning it as result.
   [f  args] 
   (printf %s %s %s\n (trace-indent) *current-advised* args)
   (let [res (binding [*trace-depth* (inc *trace-depth*)]
   (apply f args))]
 (printf %s %s %s\n (trace-indent) *current-advised* res)
 res))

 (advise-ns 'user trace)

 (sum-squares 1 2 3 4)
 ;;; The above invocation produces the following output:

 ;;  #'user/sum-squares (1 2 3 4)
 ;;   #'user/mult (1 1)
 ;;   #'user/mult 1
 ;;   #'user/mult (2 2)
 ;;   #'user/mult 4
 ;;   #'user/mult (3 3)
 ;;   #'user/mult 9
 ;;   #'user/mult (4 4)
 ;;   #'user/mult 16
 ;;   #'user/add (1 4 9 16)
 ;;   #'user/add 30
 ;;  #'user/sum-squares 30

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Richelieu: a library for advising functions

[Phillip Lord]

I think yours might be nicer, to be honest, though, although Robert
Hooke has some features yours doesn't. Advising entire namespaces is an
interesting addition for sure.

I still don't understand why Robert Hooke has this name though. I can't
have been the only person expecting it to implements hooks.

Phil

Edwin Watkeys e...@poseur.com writes:

 Phillip,

 I’d cry if it weren’t so funny; I’ve just begun to make my way through the
 lastest Read Eval Print λove and the first page or two dwells on reinvention.
 At least mine wasn’t intentional.

 Edwin

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clj-fl 0.1.0.prealfa5 - Frame language library for Clojure

[Phillip Lord]

RDF and triples stores are closely related to Frame languages, although
frames can support more semantics than a triple store. Frame languages
were designed to for knowledge representation and then can be useful. To
my mind, their big advantage is that they are relatively easy and
intuitive for people to understand.

Without wishing this thread to become my library too, you might also
be interested in Tawny-OWL (https://github.com/phillord/tawny-owl). This
uses the form of a frame language (because it's easy to understand);
actually, the underlying semantics is a (subset) of first-order logic.

So, consider these examples taken from https://github.com/phillord/owl-primer/
As you can see, these statements can be build up into a relative complex
way, to represent complex knowledge.


(defclass Person
  :comment Represents the set of all people.
  :haskey hasSSN))

(defdproperty hasAge
  :domain Person
  :range :XSD_NON_NEGATIVE_INTEGER
  :characteristic :functional)

(defclass ChildlessPerson
  :equivalent (and Person (not Parent))
  :super (and Person
(not
  (owl-some
 (inverse hasParent)
 (owl-thing)


(defindividual John
  :type Father
  (at-least 2 hasChild Parent)
  (exactly 3 hasChild Parent)
  (exactly 5 hasChild)
  (at-most 4 hasChild Parent)
  :same
  other/JohnBrown
  :different Bill
  :fact
  (is hasWife Mary)
  (is hasAge 51))

Karsten Schmidt i...@toxi.co.uk writes:

 Hi Luciano,

 I never heard of this Frame language, but this seems closely related
 to RDF and triple stores, something I've been working on for the past
 year (not as often as I wished):

 http://thi.ng/trio

 This project is actually designed to only address the non-RDF aspects
 of triple stores, with the higher-level semantics refactored out into
 a separate library. Am still regularly reworking the core API and
 additional triple store functionality (e.g. indexing, alias support,
 query optimizations...), but it's generally completely usable and I
 have already successfully built a few projects around this toolkit...
 Worth pointing out is also the query engine (this lib's best  most
 powerful feature), which is loosely inspired by SPARQL (but has no RDF
 constraints). A rule-based inference engine is also in the works...

 https://github.com/thi-ng/trio/blob/develop/src/query.org#introductory-examples
 (featuring lots of graphviz examples)

 Am not sure what your plans are with clj-fl, but thought you might
 find this interesting/relevant...

 Good luck! :)

 Best, K.

 On 19 November 2014 14:52, Luciano Capitanio
 luciano.capita...@gmail.com wrote:
 CLj-fl is a Frame Language library for the Clojure ecosystem. Since I had a
 lot of fun playing with the Frame language, I decided to put together some
 of my toys in a library and let others to play with it.
 Looking forward for any comment, suggestions and pull requests.

 Announcement post:
 - Clj-fl is out!
 Previous posts on frame language:
 - Frame Language in Clojure (part 1)
 - Frame Language in Clojure (part 2)

 Luciano Capitanio

 high order dysfunctions

 --
 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.

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: If code is data why do we use text editors?

[Phillip Lord]

Thomas Huber th0mas.hu...@googlemail.com writes:

 Hi Phil, thanks for your reply.

 The source data structure doesn't have to contain only bare source code. 
 It could contain everything that is in a text file, but just saved in a 
 structured way. 


To contain everything, then the data model needs to be rich enough,
for instance to represent indentation. Ultimately, I would be interested
in seeing what the data model for this would look like; for comments, I
suspect, it would be 'at position 1 we have a; at position 2 we have
b'.

And data that is stored in a structure, needs to obey that structure all
of the time. With Clojure:


(println hello

of course, does not obey the structural requirements of the clojure
language. So, then, how do I type this? Which I might want to, until I
have finished.

The question is not about structured/unstructured representation. My
text editor is *already* structured. I use emacs, you can go and read
the source code if you want, but it has data structures which represents
buffers and strings. And more over, at my option, when I choose, I can
apply a high level structuring over this data -- that is, I can eval in
Clojure.

So, the question is, can you come up with a better data structure than
the one we have already? Or is a simple string representation enough.

Incidentally, if you think structured editing is good, do you remember
the Sinclair Spectrum keyboard which meant that you could only enter
valid tokens. How cool was that? Structured editing at it's finest.



 The data needs to be compiled to bytecode anyway.

But not continually. Only when I ask it to.


 I'm not sure if diffing is a huge problem. You can still pretty print you 
 source data and save it into a text file. 
 Diffing these files should be enough to get an idea what was changed. 
 And if not a special diffing tool would have other advantages to I think. 

And one huge disadvantage. You would have to write it.



 Finally, source code is often wrong, or a work in progress. Okay, with 
 paredit, Clojure can be mostly kept correct (syntactically) most of the 
 time, but lisp is the oddity, and you need all the brackets to enable 
 this. Even with paredit, for me, editing in this way fails often enough 
 for me, that I wrote something to switch paredit off rapidly, and then 
 back on again when I've fixed it. 


 You can still save your programm as a data structure even if its wrong. Or 
 am I missing your point?


Nope. You can only save your program in a data structure, if it obeys
that data structure. All of the advantages that you think are going to
come, happen as a result of having a data structure which enforces
correctness. So, you cannot put an incorrect program into the data
structure, unless you have a generic data structure which looks like a
sequence of characters. Which you already have.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Tawny-OWL 1.3.0

[Phillip Lord]

I am pleased to annouce the 1.3.0 release of Tawny-OWL, now available on
clojars and github (http://github.com/phillord/tawny-owl).

What is Tawny-OWL
=

Tawny-OWL allows construction of OWL ontologies, in a evaluative, functional
and fully programmatic environment. Think of it as the ontology engineering
equivalent of [R](http://www.r-project.org/). It has many advantages over
traditional ontology engineering tools, also described in a
[video introduction](https://vimeo.com/89782389).

- An interactive shell or REPL to explore and create ontologies.
- Source code, with comments, editable using any of a range of IDEs.
- Fully extensible -- new syntaxes, new data sources can be added by users
- Patterns can be created for individual ontologies; related classes can be
  built easily, accurately and maintainably.
- A unit test framework with fully reasoning.
- A clean syntax for versioning with any VCS, integrated with the IDE
- Support for packaging, dependency resolution and publication
- Enabled continuous integration with both ontology and software dependencies


For the Clojure developer
=

Tawny-OWL is predominately designed as a programmatic application for ontology
development, but it can be used as an API. OWL ontologies are a set of
statements about things and their relationships; underneath these statements
map to a subset of first-order logic which makes it possible to answer 
questions about these statements using highly-optimised reasoners.


Take Wing
=

Although in it's early stage, a rich manual is now being written for Tawny-OWL
https://github.com/phillord/take-wing
http://homepages.cs.ncl.ac.uk/phillip.lord/take-wing/take_wing.html

Changes
===

Two new features are added to this release. First, it is now possible to
annotate axioms as well as just entities. Second, new functions have been
added to make development of patterns easier, both in function and macro form.

Full change log is available.

https://github.com/phillord/tawny-owl/blob/master/docs/releases.md

-- 
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: If code is data why do we use text editors?

[Phillip Lord]

I can think of several reasons. 

First and most important, code is data, but source files are not code.
They are source and include many things a lot of which do not obey the
syntactic rules of the language. Comments and indentation are the most
obvious ones.

Second, reason is that not only do you need a special tool for editing,
you need a special tool for diffing as well. And version control. Maybe
you will have to rewrite these for every language now, rather than using
the lowest common denominator line-orientated syntax.

Also, you will have to update your editing environment for every new
version of the language.

Finally, source code is often wrong, or a work in progress. Okay, with
paredit, Clojure can be mostly kept correct (syntactically) most of the
time, but lisp is the oddity, and you need all the brackets to enable
this. Even with paredit, for me, editing in this way fails often enough
for me, that I wrote something to switch paredit off rapidly, and then
back on again when I've fixed it.

It sounds like a nice idea, but I think it's not. In fact, one of the
motivations behind my clojure library (Tawny-OWL) was to move away from
manipulating a program (well, not a program, but a complex, formal data
structure, but it's the same thing) by changing an live data structure,
and move toward a flat file that has to be parsed. Sounds like a
backwards step, but isn't.

Phil


Thomas Huber th0mas.hu...@googlemail.com writes:

 Hi, here is an idea that has been in my mind for a while. I wonder what you 
 think about it.

 In Clojure code is data, right? But when we program we manipulate flat text 
 files, not the data directly.

 Imagine your source code where a data structure (in memory). And 
 programming is done by manipulating this data structure. No text editor and 
 text files involved. 

 Your editor directly manipulates the source data and later saves it on disk 
 (maybe as a text file). 


 These are the benefits I can think of:

  - It enables you to use any Clojure function to manipulate your source 
 „code“. Giving you hole new opportunities for refactoring.This functions 
 can be provides as library. 


 - Really nice auto complete. 


 - Visual programming. Source code can be represented in many different ways 
 (not just text) . The easiest example I can think of is color. It can be 
 represented as text of course (#23FF02)

 but that’s a quite bad interface for humans. Why not display the actual 
 color and provide a color picker? Or what about music notes? Or Math 
 formulars? Or what about a tree view to move and rename functions like 
 files? 

 This could all be implemented in a way that every library can ship there 
 own „views“. I think this „views“ are basically macros that are not limited 
 to text. 


 - You don’t have to worry that you text files are in the same state as your 
 JVM (when developing interactive). You only work on your sourcedata and it 
 gets loaded into the JVM automatically.


 - Answer questions about your source code. What is the most called 
 function? Who depends on this namespace? Where is this function used? What 
 is the biggest function? Thinks like that become easy. Again you can ship 
 this queries as a library.




 The drawback is you can’t simply program using any text editor. You need a 
 special tool. But we have that anyway (syntax highlighting, paredit etc.). 
 Nobody programs using a bare text editor. 


 Maybe this idea is not new? What do you think?

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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 clojure infers types.

[Phillip Lord]

Ah, okay. I thought it might be this.

Not that I don't trust you, though, but how do you know this? Is there a
good way of finding out what clojure has infered or not? tools.analyzer?
I'm thinking from a point of view of the developer trying to get his
type hints sorted.

Phil

Nicola Mometto brobro...@gmail.com writes:

 The reason why that call doesn't require reflection is that
 Collection.unmodifiableSet has no overloaded methods, it only takes a
 Set so the compiler doesn't have to disambiguate between different
 signatures.

 Phillip Lord writes:

 Yes, I checked the code.

 (defn set
   Returns a set of the distinct elements of coll.
   {:added 1.0
:static true}
   [coll] (clojure.lang.PersistentHashSet/create (seq coll)))

 And that was my first assumption. But if clojure doesn't know the return
 type, then why does this:

 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 Not require reflection? Clojure should not know which method to call.
 Unless it is just because unmodifiableSet has an arity of one and it's
 the only arity of one, so it doesn't try to disambiguate.

 I guess even if set was type hinted (to IPersistentSet) it would still
 not work since, IPersistentSet is not assignable from java.util.Set.

 Phil



 Nicola Mometto brobro...@gmail.com writes:

 Actually `set` and a lot of other clojure.core functions are neither
 inlineable nor have type hints.

 Phillip Lord writes:

 I have a piece of code that looks like this

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (set classlist)
   (union-annotations classlist))

 The method signature is

 getOWLEquivalentClassesAxiom(Set,Set)

 On runing lein check I get


 Reflection warning, tawny/owl.clj:2219:6 - call to method
 getOWLEquivalentClassesAxiom on
 org.semanticweb.owlapi.model.OWLDataFactory can't be resolved (argument
 types: unknown, java.util.Set).

 which makes no sense. Surely, the return type of clojure.core/set is
 known to be java.util.Set? I have quite a few calls like this in my
 code, which is why I don't want to type hint the return of set
 individually.

 If I add a function like so:

 (defn ^java.util.Set hset [coll]
   (set coll))

 and call like this:

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (hset classlist)
   (union-annotations classlist))

 The reflection warning goes away.


 I've tried to reproduce this with simpler cases, like so:


 (defn one []
   (java.util.Collections/unmodifiableSet
(java.util.HashSet.)))


 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 But both of these pass lein check just fine. Which suggests that clojure
 knows set returns a java.util.Set object.

 Now, given that I can't give a simple test case, I realise that it's
 hard for anyone to work out what is happening. But, worse, I don't know
 how to debug this at all. So, how I find out what clojure things the
 return type of a function is? Or probe any further why this is failing?

 Phil

 --

 --
 Phillip Lord,   Phone: +44 (0) 191 222 7827
 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
 School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
 Room 914 Claremont Tower,   skype: russet_apples
 Newcastle University,   twitter: phillord
 NE1 7RU

 --

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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 clojure infers types.

[Phillip Lord]

I have a piece of code that looks like this

(.getOWLEquivalentClassesAxiom
  (owl-data-factory)
  (set classlist)
  (union-annotations classlist))

The method signature is

getOWLEquivalentClassesAxiom(Set,Set)

On runing lein check I get 


Reflection warning, tawny/owl.clj:2219:6 - call to method
getOWLEquivalentClassesAxiom on
org.semanticweb.owlapi.model.OWLDataFactory can't be resolved (argument
types: unknown, java.util.Set).

which makes no sense. Surely, the return type of clojure.core/set is
known to be java.util.Set? I have quite a few calls like this in my
code, which is why I don't want to type hint the return of set
individually.

If I add a function like so:

(defn ^java.util.Set hset [coll]
  (set coll))

and call like this:

(.getOWLEquivalentClassesAxiom
  (owl-data-factory)
  (hset classlist)
  (union-annotations classlist))

The reflection warning goes away.


I've tried to reproduce this with simpler cases, like so:


(defn one []
  (java.util.Collections/unmodifiableSet
   (java.util.HashSet.)))


(defn two []
  (java.util.Collections/unmodifiableSet
   (set [])))

But both of these pass lein check just fine. Which suggests that clojure
knows set returns a java.util.Set object.

Now, given that I can't give a simple test case, I realise that it's
hard for anyone to work out what is happening. But, worse, I don't know
how to debug this at all. So, how I find out what clojure things the
return type of a function is? Or probe any further why this is failing?

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how clojure infers types.

[Phillip Lord]

Yes, I checked the code.

(defn set
  Returns a set of the distinct elements of coll.
  {:added 1.0
   :static true}
  [coll] (clojure.lang.PersistentHashSet/create (seq coll)))

And that was my first assumption. But if clojure doesn't know the return
type, then why does this:

(defn two []
  (java.util.Collections/unmodifiableSet
   (set [])))

Not require reflection? Clojure should not know which method to call.
Unless it is just because unmodifiableSet has an arity of one and it's
the only arity of one, so it doesn't try to disambiguate.

I guess even if set was type hinted (to IPersistentSet) it would still
not work since, IPersistentSet is not assignable from java.util.Set.

Phil



Nicola Mometto brobro...@gmail.com writes:

 Actually `set` and a lot of other clojure.core functions are neither
 inlineable nor have type hints.

 Phillip Lord writes:

 I have a piece of code that looks like this

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (set classlist)
   (union-annotations classlist))

 The method signature is

 getOWLEquivalentClassesAxiom(Set,Set)

 On runing lein check I get


 Reflection warning, tawny/owl.clj:2219:6 - call to method
 getOWLEquivalentClassesAxiom on
 org.semanticweb.owlapi.model.OWLDataFactory can't be resolved (argument
 types: unknown, java.util.Set).

 which makes no sense. Surely, the return type of clojure.core/set is
 known to be java.util.Set? I have quite a few calls like this in my
 code, which is why I don't want to type hint the return of set
 individually.

 If I add a function like so:

 (defn ^java.util.Set hset [coll]
   (set coll))

 and call like this:

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (hset classlist)
   (union-annotations classlist))

 The reflection warning goes away.


 I've tried to reproduce this with simpler cases, like so:


 (defn one []
   (java.util.Collections/unmodifiableSet
(java.util.HashSet.)))


 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 But both of these pass lein check just fine. Which suggests that clojure
 knows set returns a java.util.Set object.

 Now, given that I can't give a simple test case, I realise that it's
 hard for anyone to work out what is happening. But, worse, I don't know
 how to debug this at all. So, how I find out what clojure things the
 return type of a function is? Or probe any further why this is failing?

 Phil

 --

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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.

Caching an anon function

[Phillip Lord]

I want to pass a java method call to a function. So instead of this:


(defn call-method []
  (.getCanonicalName Object))


I have something like this...

(defn indirect-call [f clazz]
  (f clazz))

(defn indirect-call-memfn []
  (indirect-call (memfn ^java.lang.Class getCanonicalName) Object))

(defn indirect-call-anon []
  (indirect-call #(.getCanonicalName ^java.lang.Class %) Object))

I am not sure which is faster yet, but either should work. But,
performance-wise I am creating a new function for every call (the
anonymous function) when I only ever need one. Which isn't idea.

One solution would be this:

(def indirect-call-memfn-cached
  (let [f (memfn ^java.lang.Class getCanonicalName)]
(fn []
  (indirect-call f Object

(def indirect-call-anon-cached
  (let [f #(.getCanonicalName ^java.lang.Class %)]
(fn []
  (indirect-call f Object


Or, if I want to stay using defn the slightly evil looking:

(let [f #(.getCanonicalName ^java.lang.Class %)]
  (defn indirect-call-defn-anon-cached[]
(indirect-call f Object)))


Which seems to work, but is fairly horrible syntactically.

I have thought about writing a macro which I might call one-fn which
looks like fn but caches. The best I have come up with is to turn the
contents of the form variable into a hash, and store the functions in
global state. So something like this...

(one-fn [x] (.getCanonicalName x))


At run time we would have something like

(if-let [f (get one-fn-state 423432423)]
  f
  (let [r (fn [x] (.getCanonicalName x))]
  (swap! one-fn-state assoc 423432423 r)
  r))
   

I can see some nasty edge cases where this will break, of course. But
most of all, I wonder whether I am missing something obvious that would
be far better. In the ideal world, I'd like one-fn to affect the
compiled code, so that a single instance is shared, but I can't see a
way to achieve this.

Thoughts? Has it already been done?

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Caching an anon function

[Phillip Lord]

Oh, dear, did I leave a trailing reference in my headers?

Mars0i marsh...@logical.net writes:

 Phil, I think your post accidentally ended up in the wrong place.  I 
 believe you intended to create a new thread.

 On Friday, October 31, 2014 4:55:39 AM UTC-5, Phillip Lord wrote:



 I want to pass a java method call to a function. So instead of this: 
 ...


-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-alpha3 now available

[Phillip Lord]

Reid McKenzie rmckenzi...@gmail.com writes:
 This suggests that |apply| is immensely expensive in general,
 and that such arity unrolling even for trivial functions would be a good
 thing. Albeit hard to build.


Wonder whether it is macroable. Something like


(def new-function
  (with-arities [20]
 [args]
 (blah args)
 [args  rest]
 (apply args rest)))


which gets replaced with

  (fn 
([]
 (blah))
([a]
 (blah a))
;;...etc
([a...t]
 (blah a...t))
([a...t  rest]
 (apply blah a...t rest)))
  

Where a...t are the symbols a to t. Would this help? The function blah,
of course, would know what it's arity is, but this is true for most
higher-order functions (if functions returned their arities, I guess you
could work around this, but they don't).

So, partial would become something like...

(def partial
  (with-arities [:all]
[args]
(fn [args] (args))
[args  rest]
(fn [ rst] (apply (list* args rst)


Just thinking aloud!

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-alpha3 now available

[Phillip Lord]

Reid McKenzie rmckenzi...@gmail.com writes:
 For the special case of a reduction over varargs as in #'clojure.core/+
 or #'clojure.core// where you're just generating Duff's I think the macro
 should be pretty straightforward but it won't be general at all. 

I tend to agree with the lack of generality -- from a little thinking,
that was the conclusion I've come to as well. Though, in my case, this
could easily be just because I didn't think about it enough.

 However I suspect that there are enough trivial reduction varargs
 functions as such that this may well be worth exploring. If I have
 time I'll kick this around some more today.


For my use case, I have four very similar and ideally very high arity.
I've already partially macro'ed them to save typing, but it's possible I
should go the rest of the way.

If you get anything working, do let me know. I'd be happy to steal
ideas:-)

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [ANN] Clojure 1.7.0-alpha3 now available

[Phillip Lord]

I am curious, with path CLJ-1430 why stop at 3 arguments? Why not unroll to 20?

I ask for a practical reason. In my own library, I have unrolled several 
functions which get called
a lot. Moving from all variadic to non-variadic up to 5 args has produced a 
given a 2x increase in 
my code under extreme circumstances. I was thinking of macro'ing it out to an 
arity of 20, but 
haven't yet, just because it seems a step too far.

Phil



From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Alex 
Miller [a...@puredanger.com]
Sent: 27 October 2014 03:42
To: clojure@googlegroups.com; clojure-...@googlegroups.com
Subject: [ANN] Clojure 1.7.0-alpha3 now available

Clojure 1.7.0-alpha3 is now available.

Try it via
- Download: http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha3/
- Download securely: 
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha3/
- Leiningen: [org.clojure/clojure 1.7.0-alpha3]

For users of Clojure 1.7.0-alpha2, there have been a few important changes in 
features under development:

Transducers:
- iteration function renamed to eduction
- Fixed several issues related to reduced values

*unchecked-math* boxed math warnings:
- warnings are now only emitted when (set! *unchecked-math* :warn-on-boxed). 
for old behavior (no warnings), use (set! *unchecked-math* true).

For other changes new in alpha3, see the issues marked (alpha3) in the 
changes below.


Clojure 1.7.0-alpha3 has the changes below from 1.6.0:

## 1 New and Improved Features

### 1.1 Transducers

Transducers is a new way to decouple algorithmic transformations from their
application in different contexts. Transducers are functions that transform
reducing functions to build up a recipe for transformation.

Also see: http://clojure.org/transducers

Many existing sequence functions now have a new arity (one fewer argument
than before). This arity will return a transducer that represents the same
logic but is independent of lazy sequence processing. Functions included are:

* conj (conjs to [])
* map
* mapcat
* filter
* remove
* take
* take-while
* drop
* drop-while
* cycle
* take-nth
* replace
* partition-by
* partition-all
* keep
* keep-indexed

Additionally some new transducer functions have been added:

* cat - concatenates the contents of each input
* de-dupe - removes consecutive duplicated values
* random-sample - returns items from coll with random probability

And this function can be used to make completing transforms:

* completing

There are also several new or modified functions that can be used to apply
transducers in different ways:

* sequence - takes a transformation and a coll and produces a lazy seq
* transduce - reduce with a transformation (eager)
* eduction - returns a reducible/seqable/iterable seq of applications of the 
transducer to items in coll. Applications are re-performed with every 
reduce/seq/iterator.
* run! - run the transformation for side effects on the collection

There have been a number of internal changes to support transducers:

* volatiles - there are a new set of functions (volatile!, vswap!, vreset!, 
volatile?) to create and use volatile boxes to hold state in stateful 
transducers. Volatiles are faster than atoms but give up atomicity guarantees 
so should only be used with thread isolation.
* array iterators - added support for iterators over arrays

Some related issues addressed during development:
* [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511)
* [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497)
* [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549) (alpha3)
* [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537) (alpha3)

### 1.2 Keyword and Symbol Construction

In response to issues raised in 
[CLJ-1439](http://dev.clojure.org/jira/browse/CLJ-1439), several changes have 
been made in symbol and keyword construction:

1) The main bottleneck in construction of symbols (which also occurs inside 
keywords) was interning of the name and namespace strings. This interning has 
been removed, resulting in a performance increase.

2) Keywords are cached and keyword construction includes a cache check. A 
change was made to only clear the cache reference queue when there is a cache 
miss.

### 1.3 Warn on Boxed Math

One source of performance issues is the (unintended) use of arithmetic 
operations on boxed numbers. To make detecting the presence of boxed math 
easier, a warning will now be emitted about boxed math if \*unchecked-math* is 
set to :warn-on-boxed (any truthy value will enable unchecked-math, only this 
specific value enables the warning).

Example use:

user (defn plus-2 [x] (+ x 2))  ;; no warning, but boxed
#'user/plus-2
user (set! *unchecked-math* :warn-on-boxed)
true
user (defn plus-2 [x] (+ x 2)) ;; now we see a warning
Boxed math warning, NO_SOURCE_PATH:10:18 - call: public static 

Re: CCW bug [SEVERE]

[Phillip Lord]

Fluid Dynamics a2093...@trbvm.com writes:

 On Saturday, October 25, 2014 10:42:24 PM UTC-4, tbc++ wrote:

 What if my file had been corrupted, or truncated and only the first 42 
 bytes of the new version written thus far, or something like that at the 
 moment when the hang started?

 So there's this new cool thing out there called a version control 
 system. One of the more popular programs in this category is known as 
 git...check it out sometime, it'll help you relax when programming, knowing 
 that previous versions of your file are only a few keystrokes away. 


 Besides, it's stupid to expect everyone to use a version control
 system, particularly just to ward against bugs that have no business
 existing in the first place. 

Actually, no, it's not. Using a VC system is something that more or less
every programmer should do. Combined with backups which, no doubt you
do, it makes the possibility of loosing work through someone elses fault
quite remote. A VC with a number back-up save function on your IDE is
the way to go.


 Really, you expect me to create an account and publish every little
 bit of code I play around with on github?

Publication of code for VCS isn't really necessary. RCS which was
released in 1982 didn't require it (actually, didn't support it). With
the advent of DVCS, it's not needed now.


 Sometimes I write some function or big static map or vector or
 something out a line at a time, saving every couple of minutes or if I
 pause for any reason. I'm certainly not about to commit code in such a
 state to a VCS, let alone publish it where others can see it.

That's what rebasing is for, although I agree it doesn't avoid the
usefulness of a numbered backup.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CCW bug [SEVERE]

[Phillip Lord]

Fluid Dynamics a2093...@trbvm.com writes:

 Really, you expect me to create an account and publish every little 
  bit of code I play around with on github? 

 Publication of code for VCS isn't really necessary. RCS which was 
 released in 1982 didn't require it (actually, didn't support it). With 
 the advent of DVCS, it's not needed now. 


 Objection: relevance? The OP specifically suggested github, 

You don't have to publish with github either, but then you do have to
pay them.



 Sometimes I write some function or big static map or vector or 
  something out a line at a time, saving every couple of minutes or if I 
  pause for any reason. I'm certainly not about to commit code in such a 
  state to a VCS, let alone publish it where others can see it. 

 That's what rebasing is for, although I agree it doesn't avoid the 
 usefulness of a numbered backup. 


 I don't even know what rebasing is. 

Rewriting history. The general usage pattern is that you start a feature
branch, make 20 attempts to get it working before you get it right. Once
it's right, you squash your previous commits down so that just the
correct changes get in. In the process, you lose the intermediate
history, which is a) good because you have deleted all the junk, so it's
easier to read and b) bad because you have lost the history.


 I'd much rather not have to either, not when my current workflow is
 fine for me just so long as my tools have the courtesy not to threaten
 to crash in the middle of a save. How many hours, weeks, or months of
 ascending some no-doubt-steep learning curve would be involved in
 following your recommendation? 

 Would I be able to resume making forward progress on my actual project
 by Christmas, or would it be closer to Valentine's Day?

That sort of depends on you. But, either way, you'll understand
rebasing, and you'll have some mighty tales to tell about the rebase vs
merge controversy. I've always found these go down very well at parties
or romantic dinners.

Phil



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Demoralising experience trying to install on Win 7

[Phillip Lord]

You could try this, although I don't have a windows box handy,, so can't vouch 
for it.


http://leiningen-win-installer.djpowell.net/



From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Geoff 
Caplan [ghcap...@gmail.com]
Sent: 25 October 2014 02:44
To: clojure@googlegroups.com
Subject: Demoralising experience trying to install on Win 7

Hi

Wanting to get Clojure running on a Win 7 machine with no diskspace for dual 
boot. It's been a demoralising experience.

I tried the Win installer linked from the Leiningen website. It failed to 
download the Leiningen 1 jar - the shell simply flashed open and crashed.

Dug around the git site and found a recent .bat file that's supposed to work 
with the latest Leiningen 2. Again, the shell flashed and crashed.

Then manually downloaded the latest Leiningen 2 preview. Again running lein 
simply flashes and crashes the shell.

There's been a recent open issue on Windows installation but it's supposed to 
be fixed.

The lein.bat file is on my path and has exec permissions. I have Java 8 SDK 
installed and healthy.

Not sure where I go from here - any advice much appreciated.

I'm dithering between Clojure and Haskell for my next project. The Haskell 
community provide a well-maintained batteries-included Windows install for GHCi 
- I was in the Repl 60 seconds after visiting their site. I've been struggling 
with Leiningen for an hour and getting nowhere.

It seems a great pity that the Clojure community seem to be ignoring those of 
us who are stuck with Windows - it must be having a negative effect on the 
uptake of the language. I see that this has been an issue for years, but hasn't 
been addressed. I'm more drawn to Clojure than to Haskell, but if I can't get 
it running I'll be forced to go elsewhere. Please help.

--
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.commailto: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: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:

 Sure, laziness feels like a subset of UAP.


 Regardless, we have a nice example in Clojure, where we not
 distinguishing between data and computation allows us to do something
 nice.


 Yes... I agree it allows us to do something, but let's agree to disagree on
 whether that something is nice :)


Laziness? In my experience it is not nearly as useful as it is suggested
to be, but it does seem to be pushed as a feature of clojure.

 All of this discussion has made me think I should revist the issue. I
 could put my own Map implementation on my vars as metadata, and have
 this map work lazily, so that the calculation of the :doc metadata
 happens through computation.

 That would be evil.


 It would... but if you're set on this path of evilness, you might want to
 look at def-map-type in https://github.com/ztellman/potemkin


That's useful indeed. One of the things putting me off my evil plan was
the prospect of implementing a clojure data structure in clojure; I know
what a pain that is. This might help to circumvent all of that.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:
 Which is nice and simple, yes. And has negative consequences in terms of
 extensibility. I understand if you are happy with this compromise. But
 it is a compromise.


 I don't disagree, but I do consider the compromise to be a minor one.

 UAP has huge disadvantages in terms of complexity, repetition, scalability,
 reliability, isolation, and a whole bunch of other things that Clojure is
 explicitly trying to avoid.

 On the other hand, I can't personally recall a situation where it would
 have actually been useful to me.


Okay. I can give you a very concrete example, and one where I think that
it probably has been actually useful to you.


Imagine you write the following piece of code:

(first l)

This returns a value. If we obeyed the universal access principle,
however, we would not know whether this resulted from computational or
otherwise. And, in fact, Clojure does exactly this. It's why you can
write:

(take 10 (range))

The argument that Clojure prefers data over APIs is, as far as I can
see, just wrong. If that were the case, why not drop ISeq (which is an
API) and use a cons cell (which is data)? Answer, because hiding the
distinction between accessing data and performing computation allows you
to do some very useful things. Including infinitely long sequences. In
fact, that Clojure is built over abstractions (i.e an API) is a major
selling point.

The distinction of Clojure is not that it prefers data over APIs, but
that it prefers relatively few APIs, reused where possible.

Phil












-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:

 On 21 October 2014 12:52, Phillip Lord phillip.l...@newcastle.ac.uk wrote:


 Okay. I can give you a very concrete example, and one where I think that
 it probably has been actually useful to you.

 Imagine you write the following piece of code:

 (first l)

 This returns a value. If we obeyed the universal access principle,
 however, we would not know whether this resulted from computational or
 otherwise. And, in fact, Clojure does exactly this.


 So you're saying laziness and UAP are the same thing in your view?

I am saying that UAP enables you to implement laziness freely.


 I'm not sure I'd necessarily consider deferring computation to be the same
 as uniform access. Deferring computation can occur once, so you couldn't,
 for instance, use it to solve the :doc problem you mentioned earlier, where
 the :doc string of a var would depend on the contents of the var.

No, for that you computational in general. Deferred computation would be
enough to support, for example, thalia's extended documentation,
although you'd have to decide up front.

Regardless, we have a nice example in Clojure, where we not
distinguishing between data and computation allows us to do something
nice.

Another example is memoize, which does the opposite -- it makes data
appear to be computation, and means that you can, for example, use a
intuitive recursive definition of fibonacci, without exploding the
compute time.


 To be clear, I don't think Clojure is necessarily against complexity, just
 against unnecessary complexity. The simplest thing possible, but no
 simpler.

Unfortunately, this distinction is one made at an application level, I
think, and not at a code level.

All of this discussion has made me think I should revist the issue. I
could put my own Map implementation on my vars as metadata, and have
this map work lazily, so that the calculation of the :doc metadata
happens through computation.

That would be evil.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:

 On 17 October 2014 16:21, Phillip Lord phillip.l...@newcastle.ac.uk wrote:
 http://en.wikipedia.org/wiki/Uniform_access_principle

 To my knowledge, Clojure cannot do this.


 Yes, Clojure pretty much rejects the idea of uniform access.


I don't think it does. I think it just does not support it which is a
somewhat different thing.


  With regard to automatically :doc string, why can't you set it when the
 var
  is created?

 Two reasons. The first is specific to my library, which is that the var
 contains a mutable Java object. So the :doc string may change over time,
 independently of the value of the var. Don't use mutable objects would
 be an obvious response, but not a useful one in this case.


 If you're placing mutable objects in a top-level var, and having that var's
 docstring change based on their contents, that's a strong indication you're
 doing something wrong.


Yes, this is certainly a possibility.


 It sounds like you're trying to interoperate with a Java library that's
 very structured around OOP principles, and very hard to translate into
 idiomatic Clojure. My guess is that you wouldn't have the issues you
 mention in a pure Clojure solution.


Which is the actuality. While using mutable objects and global state may
be an indication that I am doing something wrong, my belief is that
starting a software project by ignoring existing java libraries and
rewriting everything in Clojure is a much bigger error. I got to a
usable piece of software in two months; this would not have happened
from scratch.

Still, although my example might appear irrelevant to Clojure in
general, I don't think it is. Clojure's current docstring support is not
very good (and there was a thread here about it not long ago). It would
be nice to have something richer. For really rich documentation,
maintaining the docstrings is a different file might make sense. Clojure
can support this at the moment, but only in the way that I have -- the
var metadata could be updated at load time. What it cannot do (easily)
is support lazy loading of the file documentation at the point of first
use, because the decision was made originally that :doc metadata is a
value and is NOT computed.

Phil


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

Fluid Dynamics a2093...@trbvm.com writes:
 I don't know who is the outlier. The point is that Scala, for instance, 
 has explicit support to hide the distinction between accessing a value 
 and computing a value. The point is to support the uniform access 
 principle. 

 http://en.wikipedia.org/wiki/Uniform_access_principle 

 To my knowledge, Clojure cannot do this.


 It seems to me that some support could be created for this. Specifically, 
 we'd want to make it that a) (deref foo) on a non-IDeref just evaluates to 
 foo in a no-op, and furthermore that if foo is known at compile time not to 
 be an IDeref the (deref foo) compiles away to just foo, so has no runtime 
 cost; and b) (deref (delay (some-fcall))) amounts to (force (delay 
 (some-fcall))) and where the compiler knows the thing being derefed is a 
 delay (via type hint or whatever) is as efficient as just (some-fcall) at 
 run-time the first time called, and as efficient as ((constantly foo)) for 
 some value of foo thereafter.

 In that case, one could hide the computed-or-not nature of some data behind 
 expecting users to use @my-thing to access it, and if my-thing is not an 
 IDeref it is the same as my-thing, but it can be changed later to a delay 
 to make it a lazily-computed thing without breaking the API, and without 
 much runtime efficiency cost, given that the new object is hinted with 
 ^IDeref or something.


It's definately supportable. Symbol macros could also achieve the same
thing; Clojure has these, but not globally.

Phil


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:

 On 18 October 2014 08:28, Mark Engelberg mark.engelb...@gmail.com wrote:

 Yeah, it's hard to deny the convenience of Clojure's keyword lookups and
 standard assoc mechanism for getting and setting stored values, but I think
 Bertrand Meyer's Uniform Access Principle reflects some pretty deep
 thinking about the kinds of complications that arise in maintaining large
 programs.  Although the Clojure community mostly rejects the Uniform Access
 Principle right now, as people start writing larger programs in Clojure,
 and need to maintain them for longer periods of time, it will be
 interesting to see if the pendulum swings back in favor of uniform access.


 You make it sound as if structuring an application around data, rather than
 APIs, is untested at scale. I'd argue the opposite: the only architecture
 we know works at scale is data driven.

 The largest systems we've developed, including the web itself, are data
 driven. 


Interesting. So, if you resolve http://www.clojure.org, is this data or
is it computed?

I don't think you can tell. The web supports the Uniform Access
Principle.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:
  Yes, Clojure pretty much rejects the idea of uniform access.


 I don't think it does. I think it just does not support it which is a
 somewhat different thing.


 I thought it was pretty clear that Clojure prefers data over APIs. The
 uniform access principle is about preferring APIs over data, which seems
 counter to Clojure's ideology.

The uniform access principle is about having uniform access to data and
APIs. It's not about prefering one or the other.


 Still, although my example might appear irrelevant to Clojure in
 general, I don't think it is. Clojure's current docstring support is not
 very good (and there was a thread here about it not long ago). It would
 be nice to have something richer. For really rich documentation,
 maintaining the docstrings is a different file might make sense. Clojure
 can support this at the moment, but only in the way that I have -- the
 var metadata could be updated at load time. What it cannot do (easily)
 is support lazy loading of the file documentation at the point of first
 use, because the decision was made originally that :doc metadata is a
 value and is NOT computed.


 There's no reason why you have to use the :doc metadata for that. Just
 write another function that takes a var and spits out some documentation.

Yes, which is what I have done, of course. Now it won't work in any IDE
which looks for the docstring as :doc metadata. It is totally
unextensible. I do not think that this is good.



  The largest systems we've developed, including the web itself, are data
  driven.

 Interesting. So, if you resolve http://www.clojure.org, is this data or
 is it computed?

 I don't think you can tell. The web supports the Uniform Access
 Principle.


 The response may be computed, but once it's sent to the client it's
 immutable data.

Well, that's the point, you cannot tell. So, for example, I can provide
a website implemented over a relational database. Or I can serialize it
out as static files. Or I can add a caching layer which serializes
lazily, and redoes every hour.


 The response returned has no inherent API associated with it.

That sort of depends on the response.


 To put it another way, consider the function:

 (defn build-user [first-name last-name]
   {:first-name first-name
:last-name last-name
:full-name (str first-name   last-name)})

 Like a website, a function may perform computations, but its return
 value is immutable data. Would you say the above conforms the the
 Uniform Access Principle?

As I said at the beginning, it is possible to achieve UAP by making
*everything* a function. So, we can automatically achieve UAP by ONLY
using functions and never values.

So consider for example, this case.

(:doc (meta #'concat))

The return value of this expression can never be computed (short of
reimplementing ILookup or IMeta which, of course, we could do).

On the other hand

((:doc (meta #'concat)))

could be computed or not, since the function returned could just be
returning a value. So, the latter supports the UAP, the former doesn't.

In fact, this is how I squared the circle in my case. I changed

data-factory

to 

(data-factory)

In most cases the data-factory function just returns a constant value,
but it can use computation when I choose.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:
 Yes, which is what I have done, of course. Now it won't work in any IDE
 which looks for the docstring as :doc metadata. It is totally
 unextensible. I do not think that this is good.


 Clojure prefers simple solutions over easy solutions.

A nice aphorism sometimes, but content free in this case, I think.


 Unrestricted polymorphism and universal access would make solving this
 problem easier, but they also create more complexity.

 Or to put it another way, rather than trying to shoehorn a solution into a
 system that wasn't built for it, we should design a new system around the
 desired solution.

So, there is this tourist, and he asks a local, how do I get into
town. Hmmm, says the local, if I want to get into town, I wouldn't
start from here.

Software engineering is a compromise, and designing a new system is a
pain, especially if multiple people have to update to it. I think
Clojure's doc string support is weak. Part of the reason for this, is
because it is not extensible. The main reason that it is not extensible
is that, in Clojure, once you have decided that something is a value,
you are stuck.

Don't care about my use-case? That's fine. Have a look at Andy
Fingerhuts thalia which helps to fix Clojure's poor documentation.

https://github.com/jafingerhut/thalia

Same problem -- all has to be done up front, which is ugly and nasty. As
a result, I don't use thalia, which is a shame.


 The response may be computed, but once it's sent to the client it's
  immutable data.

 Well, that's the point, you cannot tell. So, for example, I can provide
 a website implemented over a relational database. Or I can serialize it
 out as static files. Or I can add a caching layer which serializes
 lazily, and redoes every hour.


 Yes, and so can a function. Clojure doesn't say, you shouldn't compute,
 it says, you should separate computations and data.

Which is nice and simple, yes. And has negative consequences in terms of
extensibility. I understand if you are happy with this compromise. But
it is a compromise.



 The point I was trying to make was that computed values (such as those
 produced by a web server) do not necessarily imply UAP.

 I don't disagree that UAP has some benefits, but it comes with a huge
 number of tradeoffs. Given that the problem it tries to solve is, in my
 experience at least, exceeding rare, it really doesn't seem worth the
 additional complexity.

Well, the question is, where does this additional complexity come from.
In Java, it results in enormous quantities of boilerplate get/set
methods. In Scala, these are autocoded away.

In Clojure, I don't see an easy solution. Not going to stop me using the
language, but it's a weak spot.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

Mark Engelberg mark.engelb...@gmail.com writes:
 But let's say later you decide you want your data model to be {:first-name
 Alice, :last-name Beasley, :email al...@example.com}, and you want to
 change name to be a computed value that concatenates first and last names
 -- this is going to break all your existing code.  If name were only
 accessed throughout your code via the call `get-name`, then it would be
 trivial to make this change.

 (Theoretically, it is possible to implement a revision to a person data
 structure by representing it as a custom map that reimplements keyword
 access so that (:name person) calls a function rather than does the usual
 keyword lookup, but I've never seen anyone do this, so I'm ignoring this
 possibility for the purpose of this discussion).


Actually, I think that this is a real problem with Clojure, and with
data access. It is very hard to change between accessing a var as a
value and through calling a value.

I can give two concrete examples of this. First, in my library I used a
var to store a factory object from a Java API. So I created one and
stored it in a var. This worked well, in general, but when I integrated
my library into an application, I realised that I need to get this
factory object from elsewhere -- in short I needed a function call. So I
had to change all of my `data-factory` calls to `(data-factory)`.

Another time the same issue hit me was with Clojure's :doc metadata.
This is stored as a string, but I wanted to be able to subvert this by
calculating the string from the object containing in the var. As far as
I can tell, this is impossible in Clojure without changing all the
client code that accesses the :doc metadata.

Java does not have this problem by common design patterns -- fields are
declared private and always accessed through a function. If I understand
things correctly, Scala avoids the problem in the same way, although it
autocodes the accessors for you, so avoids the boilerplate.

In Clojure, it seems the only way to avoid this would to wrap up values
in `constantly` and access everything as a function.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modelling in Clojure

[Phillip Lord]

James Reeves ja...@booleanknot.com writes:

 Actually, I think that this is a real problem with Clojure, and with
 data access. It is very hard to change between accessing a var as a
 value and through calling a value.


 Curiously, this is something I don't think I've ever run into.

 Perhaps I'm the outlier, but both the examples you give seem a little odd
 to me.

I don't know who is the outlier. The point is that Scala, for instance,
has explicit support to hide the distinction between accessing a value
and computing a value. The point is to support the uniform access
principle.

http://en.wikipedia.org/wiki/Uniform_access_principle

To my knowledge, Clojure cannot do this.

 Vars are generally reserved for constants, functions, dynamics and
 (sometimes) application caches. If you're putting anything else in a var,
 it's probably wrong.

When I first wrote the var, I thought it was going to be a constant.
However, during the development of my code base, I discovered in one or
two small uses cases, it could not be.


 With regard to automatically :doc string, why can't you set it when the var
 is created?


Two reasons. The first is specific to my library, which is that the var
contains a mutable Java object. So the :doc string may change over time,
independently of the value of the var. Don't use mutable objects would
be an obvious response, but not a useful one in this case.

The second reason is more general. I tried adding the :doc metadata to
the vars after they had all been created, but generating this string
involves pretty printing of lisp code, and this is computationally
intensive. In my hands, my code would take, say, 1 minute to load and
then I'd wait 5 minutes for the doc string metadata to update.

So, I want to do this lazily -- in practice, :doc strings are rarely
used, so why compute them all when only a few or none might ever be used.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Tawny-OWL 1.2

[Phillip Lord]

I am pleased to annouce the 1.2.0 release of Tawny-OWL, now available on
clojars and github (http://github.com/phillord/tawny-owl).

What is Tawny-OWL
=

Tawny-OWL allows construction of OWL ontologies, in a evaluative, functional
and fully programmatic environment. Think of it as the ontology engineering
equivalent of [R](http://www.r-project.org/). It has many advantages over
traditional ontology engineering tools, also described in a
[video introduction](https://vimeo.com/89782389).

- An interactive shell or REPL to explore and create ontologies.
- Source code, with comments, editable using any of a range of IDEs.
- Fully extensible -- new syntaxes, new data sources can be added by users
- Patterns can be created for individual ontologies; related classes can be
  built easily, accurately and maintainably.
- A unit test framework with fully reasoning.
- A clean syntax for versioning with any VCS, integrated with the IDE
- Support for packaging, dependency resolution and publication
- Enabled continuous integration with both ontology and software dependencies


For the Clojure developer
=

Tawny-OWL is predominately designed as a programmatic application for ontology
development, but it can be used as an API. OWL ontologies are a set of
statements about things and their relationships; underneath these statements
map to a subset of first-order logic which makes it possible to answer 
questions about these statements using highly-optimised reasoners.


Take Wing
=

Although in it's early stage, a rich manual is now being written for Tawny-OWL
https://github.com/phillord/take-wing
http://homepages.cs.ncl.ac.uk/phillip.lord/take-wing/take_wing.html

Changes
===
The main feature for the 1.2 release has been the incorporation of core.logic,
through (ab)use of the Tawny's querying facilities. A tighter integration
should be possible, having core.logic work directly over the OWL API, but this
was relatively simple to implement. It is performant enough for most uses (the
Gene Ontology renders to Clojure data structures in 1-2 seconds on my

One other substantial change is an aggressive micro-optimisation of
default-ontology and broadcast-ontology functionality. This functionality is
used in many parts of Tawny-OWL, so this results in a significant performance
enhancement.

Full change log is available.

https://github.com/phillord/tawny-owl/blob/master/docs/releases.md



-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: why ( 2) returns true

[Phillip Lord]

Robert Tweed fistful.of.spann...@gmail.com writes:


 In writing this, I thought I'd better also test what () and () evaluate to,
 because by the above definition, those should also evaluate to true.
 Unfortunately, at least in v1.6, they throw an arity error. IMO, by the same
 logic that says a single argument is valid, no arguments should be valid too.
 Consider the following perfectly valid use-case:

 (def in-order? #(apply  %)) ; Seems obviously correct, no?

 (def items [])   ; Maybe get this from a database; might be empty

 (in-order? items); Oops!

 ; ArityException Wrong number of args (0)...


 This should perhaps be considered a bug. I suppose it depends on your
 definition of in order for an empty set, but if we say that the most
 sensible definition is based on whether the invariant sort(x)=x holds true,
 then true is the correct result for the empty set.


I agree that according to the docstring,

Returns non-nil if nums are in monotonically decreasing order,
otherwise false.

then both:

() 
() 

should return non-nil since the numbers are in monotonicaly decreasing
order. This is what is known as a correct, but uncooperative answer.
So wrt the definition, the zero-arg call is special cased (i.e. it
throws an arity exception).

So, why not special case 1 arg as well, and have that except? It's a
reasonable question. I would submit a bug report and see if anyone else
agrees. Something is wrong for sure. Either ( x) should throw arity, or
() should return true, or the docstring should be changed to note the
special case for (). 


Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: why ( 2) returns true

[Phillip Lord]

Herwig Hochleitner hhochleit...@gmail.com writes:

 2014-09-17 11:51 GMT+02:00 Phillip Lord phillip.l...@newcastle.ac.uk:


 So, why not special case 1 arg as well, and have that except? It's a
 reasonable question. I would submit a bug report and see if anyone else
 agrees. Something is wrong for sure. Either ( x) should throw arity, or
 () should return true, or the docstring should be changed to note the
 special case for ().


 Totally agree, please post ticket number, so that we can favorite!



http://dev.clojure.org/jira/browse/CLJ-1526

-- 
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: why ( 2) returns true

[Phillip Lord]

Same argument applies (er...) to the zero element case.

Phil

Ashton Kemerling ashtonkemerl...@gmail.com writes:

 I wouldn't be surprised if the 1 arg form is to help people who use  along
 with apply, just in case the list is only 1 element long.

 On Wed, Sep 17, 2014 at 7:40 AM, Phillip Lord
 phillip.l...@newcastle.ac.uk wrote:

 Herwig Hochleitner hhochleit...@gmail.com writes:
 2014-09-17 11:51 GMT+02:00 Phillip Lord phillip.l...@newcastle.ac.uk:


 So, why not special case 1 arg as well, and have that except? It's a
 reasonable question. I would submit a bug report and see if anyone else
 agrees. Something is wrong for sure. Either ( x) should throw arity, or
 () should return true, or the docstring should be changed to note the
 special case for ().


 Totally agree, please post ticket number, so that we can favorite!
 http://dev.clojure.org/jira/browse/CLJ-1526
 -- 
 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.

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure terminology

[Phillip Lord]

jvanderhyde jamesvh...@hotmail.com writes:

 Thanks for the help, everyone. You managed to pin down my problem. I was 
 using Clojure from the ground up and a Scheme book, and the two together 
 got me confused. So, I can say it like this:

 Every expression is evaluated (meaning converted to a value), unless it is 
 quoted.
 Every expression evaluates to itself, except symbols and lists.

This last isn't really true. So, UUIDs, regexps and tagged literals
don't really evaluate to themselves either.

Phil


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure terminology

[Phillip Lord]

jvanderhyde jamesvh...@hotmail.com writes:

 Another random thought: What to you call this?
 [(+ 2 3) (+ 4 5)]
 It is an expression, but it is not a literal--I cannot say it evaluates to 
 itself.


So, only symbols and keywords really evaluate to themselves. All you are
showing is that vectors and lists are evaluated differently. It's not
true, for instance the first element of a literal list is treated as a
function. It's treated as a form that is evaluated. So for example:

((f x) y z)


would fail iff we expect the first element to be a function -- in this
case, it's not, it's a list! But it works because (f x) is evaled and it
evals to a function (well, if it doesn't it's going to crash).

You get around this by teaching that evaluation is inside out -- we
start from the inner form first,

 Sorry if I'm being pedantic. Maybe it doesn't matter. Terminology is 
 important, though, when I'm trying to teach.


Whether it is important or not depends on what you teach next. In
general, I would try and stick to the terminology of that Clojure
uses.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: why ( 2) returns true

[Phillip Lord]

Jeremy Vuillermet jeremy.vuiller...@gmail.com writes:

 Could it return a (partial  2) ?


Because  works with n args and not just two. 

( 2) = (partial  2)

then why not

( 2 3) =? (partial  2 3)

when is the sensible place to stop?

Now, if  took at most two args, this would be a sensible thing.

As far as I can see, with  defined as  it is you get the win that

( 10 9 8 7 6 5) 

works sensible but get a counter-intuitive behaviour for

( 1)

Gains and losses.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: why ( 2) returns true

[Phillip Lord]

Jeremy Vuillermet jeremy.vuiller...@gmail.com writes:

 Thanks, that' clearer.
 Also I didn't take time to read the docstring
   Returns non-nil if nums are in monotonically decreasing order, 
   otherwise false. 

 so I guess [2] is monotonically decreasing and increasing at the same
 time.


Yeah, so the same list can be both decreasing and increasing at the same time.

user (def l '(1))
#'user/l
user (apply  l)
true
user (apply  l)
true

So,  and  are not mutually exclusive. Numerically counter-intuitive, I
think, although logically expected.


 Maybe I just read too much about transducers and now I try -1 arity 
 everywhere


Basically, you were expecting a form of curry. I think that would make
sense, except that  is variadic. Got to know where to stop with
curries in functional programming as in life.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure terminology

[Phillip Lord]

jvanderhyde jamesvh...@hotmail.com writes:
 I want to say something like this:

 A word is considered a var unless it is quoted. Example: 'hello

 A list is considered a function invocation unless it is quoted. Example: 
 '(1 2 3)


I think you really need to bite the bullet and say everything is
evaluated, unless it is quoted. So:

Everything is evaluated unless it is quoted, in which case it is a
literal.

A word evaluates to a value. 

A list evaluates to the return value of a function call.

I would be careful with the var word because Clojure has a specific
meaning for var, and it is probably not somewhere you want to go.



 I don't think word is the correct term to use. Do I mean symbol? Do I 
 mean symbol instead of var?
 Is list better called a form or an s-expression?

I would just use expression because it's common to other languages.
But they are still not the same -- an expression can be a list, but
could be something else.


 Can someone help me with what I'm trying to say? It's OK to oversimplify, 
 but I don't want to use wrong words that will introduce confusion. Thanks 
 for the help.


If you really want to start simple, just drop the bit about quoting. In
Clojure, you rarely need to quote since you can use a vector instead of
a literal list, and it's a lisp-1. With a bit more fiddling you get:

A word evaluates to a value. 

A list is evaluated as a function call.

You can talk about quoting later when it becomes necessary.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is Clojure a language for growth?

[Phillip Lord]

aboy021 arthur.bo...@gmail.com writes:
 We've had trouble finding Clojure devs, and others have complained of how 
 hard it is to learn Clojure and read the code from open source projects, 
 especially for those with backgrounds in languages like C++.

 I think Clojure should be a good fit for us because it is expressive, 
 flexible, and we are still discovering new aspects of the problem domain. 
 I'm biased on this because I really enjoy Clojure at home, and want to use 
 it commercially.

 I'm really looking for arguments that will help me persuade my boss that 
 the risk of starting our next project in Clojure is one worth taking.



You will have problems finding developers with lots of experience of
Clojure. It's relatively new. There again, finding good developers is
hard in any language. You might find more luck looking for good
developers and then ask them to learn the language. If there are other
developers around, if they are good, they should be productive after a
couple of weeks, especially if there are other developers around to ask
questions of.

When I got my first Java job, I had no experience at it; day one was
popping into town to buy a how to program Java book.

Actually, I had very little experience and no qualifications in
programming at all; perhaps the world was a different place then.

Phil


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is Clojure a language for growth?

[Phillip Lord]

gvim gvi...@gmail.com writes:

 On 20/08/2014 14:09, Phillip Lord wrote:
 When I got my first Java job, I had no experience at it; day one was
 popping into town to buy a how to program Java book.

 Actually, I had very little experience and no qualifications in
 programming at all; perhaps the world was a different place then.


 How long ago was that?


Long enough ago that buying a book was my first port of call, rather
than googling for tutorials. More specifically, 1998. I was writing
applets in Java 1.0, server in 1.1.

Somehow I don't miss those days at all.

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Transducers are Coming

[Phillip Lord]

Oh dear, I still haven't understood the blogpost on reducers yet, and
now there is this one as well.

Phil


Rich Hickey richhic...@gmail.com writes:

 I pushed today the initial work on transducers. I describe transducers briefly
 in this blog post:

 http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming

 This work builds on the work done for reducers, bringing context-independent
 mapping, filtering etc to other areas, such as core.async.

 This is work in progress. We will be cutting alpha releases to help make it
 easier to start using core's transducers together with core.async's new
 support for them.

 I am very excited about this powerful technique and how we all might use it.

 Please have a look.

 Feedback welcome,

 Rich

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Namespace browser for Emacs users

[Phillip Lord]

It's very nice, but it breaks for me because I have used
(set! *print-length* 200) in my repl-options. 

When this bit of code is run

(let* ((form (sort (map name (keys (ns-publics (quote %s))
   (vars (cider-eval-and-get-value (format form namespace

The last value of vars ends up as \.\.\. rather than a string.

Is this more of an issue with cider?

Phil


Bozhidar Batsov bozhidar.bat...@gmail.com writes:

 Nicely done! As you might know I'm cider's maintainer and I actually had a 
 namespace browser on the roadmap. :-) I'd like to invite you to transfer 
 the project to the official clojure-emacs github organisation (to increase 
 the package's visibility and to make easier for the cider team to help you 
 with the maintenance). 

 I hope to eventually include cider-browse-ns in the standard cider package.

 On Monday, July 28, 2014 5:48:20 AM UTC+3, John Andrews wrote:

 Emacs users: I have put together a namespace browser which builds upon the 
 existing functionality of Cider. It is in early stages of development but I 
 find it quite useful.

 Check it out! https://github.com/jxa/cider-browse-ns
  

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Is Clojure fit for giant space-efficient in-memory tree structures?

[Phillip Lord]

When you get to very large size the efficiency of your data
representation is more likely to be the defining factor that the data
representation of the language that you are using. So, I don't think
that there is a specific answer, other than general advice for
optimisation. Try it first, and optimize it when you have no choice.

Phil

Vjeran Marcinko vmarci...@gmail.com writes:
 I am planning to play with implementing some giant in-memory index that is 
 basically tree-like structure containing counters on certain tree nodes, 
 and can aggregate billion data points and will probably consume tens of GBs 
 of RAM.

 Since space (memory)-efficiency is crucial here, I was wondering how good 
 Clojure is for this problem, and should I better just stick to plain java, 
 because it is well known that clojure's persistent data structures 
 sacrifice space (and some speed, but that is not such a big issue here) for 
 sake of immutability and good development practice?

-- 
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: leiningen project hooks

[Phillip Lord]

But where did you define the hook? In the project itself.

My current best solution to this problem is to use an alias and the
lein-exec plugin so I have a sort of working solution now, but I'd still
like it to be a bit slicker if possible.

Phil

Jason Felice jason.m.fel...@gmail.com writes:

 I think this approach should work.  When I've specified hooks in this way,
 I've specified the function name as well... e.g.:

 `:hooks [skeletor-clojure.hooks/add-revision-to-config.clj]`

 (don't let the `.clj` confuse you, the function name is _actually_
 `add-revision-to-config.clj`).


 On Fri, Jun 20, 2014 at 4:06 AM, Phillip Lord phillip.l...@newcastle.ac.uk
 wrote:



 I've been struggling with leiningen project hooks as I believe that I
 need them for my current project.

 I am writing an manual with code examples, using a literate programming
 technology. The main source is in asciidoc, but I can untangle these to
 produce valid clojure, which I can then evaluate and test.

 To do this, however, I need to run an external process to generate the
 source -- i.e. the Clojure files which are not really source in this
 case, before I try to load them and test the functions in them. In
 Maven, I can do this with the exec plugin by attaching to the initialize
 phase.

 I thought to try leiningen hooks but as far as I can see this is only
 possible within a plugin; so I have tried this...

 (defproject take-wing 0.1.0-SNAPSHOT
   :dependencies [[org.clojure/clojure 1.6.0]
  [uk.org.russet/tawny-owl 1.1.1-SNAPSHOT]]

   :hooks [take.build.gensource]
   )


 where take.build.gensource is defined in the src directory of the
 project (most of the rest of this directory will be generated).

 Error: cannot resolve take.build.gensource/activate hook
 Error: cannot resolve take.build.gensource/activate hook

 The take/build/gensource.clj file exists and it has an activate
 function.

 I am guessing that this is failing because leiningen is not looking in
 the project source-path, only it's own classpath. I'm a bit reticient to
 write a leiningen plugin for this as a) it would be entirely specific to
 this project and b) it would make the build more complex (AFAIK I'd have
 to do a pre-build for the plugin, then another for the actual project)
 and c) is a pain for anyone else.

 So, should hooks work under these circumstances? Or must I go the plugin
 route?

 Phil

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: leiningen project hooks

[Phillip Lord]

Ah, eval-in-leiningen I didn't know.

Googling that also suggests I can use .lein-classpath, then write what is 
effectively a local plugin which 
seems a simpler option still.

Thanks!

Phil


From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Jason 
Felice [jason.m.fel...@gmail.com]
Sent: 24 June 2014 17:08
To: clojure@googlegroups.com
Subject: Re: leiningen project hooks

I didn't think of that.  In my case, it was in a plugin.  I bet it would work 
if you set :eval-in-leiningen to true.

Plugins are also pretty easy to write.

I'm not sure you need the lien exec plugin...  an alias for [run -m 
foo.bar/baz]?




On Tue, Jun 24, 2014 at 12:03 PM, Phillip Lord 
phillip.l...@newcastle.ac.ukmailto:phillip.l...@newcastle.ac.uk wrote:

But where did you define the hook? In the project itself.

My current best solution to this problem is to use an alias and the
lein-exec plugin so I have a sort of working solution now, but I'd still
like it to be a bit slicker if possible.

Phil

Jason Felice jason.m.fel...@gmail.commailto:jason.m.fel...@gmail.com writes:

 I think this approach should work.  When I've specified hooks in this way,
 I've specified the function name as well... e.g.:

 `:hooks [skeletor-clojure.hooks/add-revision-to-config.clj]`

 (don't let the `.clj` confuse you, the function name is _actually_
 `add-revision-to-config.clj`).


 On Fri, Jun 20, 2014 at 4:06 AM, Phillip Lord 
 phillip.l...@newcastle.ac.ukmailto:phillip.l...@newcastle.ac.uk
 wrote:



 I've been struggling with leiningen project hooks as I believe that I
 need them for my current project.

 I am writing an manual with code examples, using a literate programming
 technology. The main source is in asciidoc, but I can untangle these to
 produce valid clojure, which I can then evaluate and test.

 To do this, however, I need to run an external process to generate the
 source -- i.e. the Clojure files which are not really source in this
 case, before I try to load them and test the functions in them. In
 Maven, I can do this with the exec plugin by attaching to the initialize
 phase.

 I thought to try leiningen hooks but as far as I can see this is only
 possible within a plugin; so I have tried this...

 (defproject take-wing 0.1.0-SNAPSHOT
   :dependencies [[org.clojure/clojure 1.6.0]
  [uk.org.russet/tawny-owl 1.1.1-SNAPSHOT]]

   :hooks [take.build.gensource]
   )


 where take.build.gensource is defined in the src directory of the
 project (most of the rest of this directory will be generated).

 Error: cannot resolve take.build.gensource/activate hook
 Error: cannot resolve take.build.gensource/activate hook

 The take/build/gensource.clj file exists and it has an activate
 function.

 I am guessing that this is failing because leiningen is not looking in
 the project source-path, only it's own classpath. I'm a bit reticient to
 write a leiningen plugin for this as a) it would be entirely specific to
 this project and b) it would make the build more complex (AFAIK I'd have
 to do a pre-build for the plugin, then another for the actual project)
 and c) is a pain for anyone else.

 So, should hooks work under these circumstances? Or must I go the plugin
 route?

 Phil

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to 
 clojure@googlegroups.commailto: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.commailto:clojure%2bunsubscr...@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.commailto:clojure%2bunsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


--
Phillip Lord,   Phone: +44 (0) 191 222 
7827tel:%2B44%20%280%29%20191%20222%207827
Lecturer in Bioinformatics, Email: 
phillip.l...@newcastle.ac.ukmailto:phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU

--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to 
clojure@googlegroups.commailto: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.commailto:clojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http

leiningen project hooks

[Phillip Lord]

I've been struggling with leiningen project hooks as I believe that I
need them for my current project.

I am writing an manual with code examples, using a literate programming
technology. The main source is in asciidoc, but I can untangle these to
produce valid clojure, which I can then evaluate and test.

To do this, however, I need to run an external process to generate the
source -- i.e. the Clojure files which are not really source in this
case, before I try to load them and test the functions in them. In
Maven, I can do this with the exec plugin by attaching to the initialize
phase.

I thought to try leiningen hooks but as far as I can see this is only
possible within a plugin; so I have tried this...

(defproject take-wing 0.1.0-SNAPSHOT
  :dependencies [[org.clojure/clojure 1.6.0]
 [uk.org.russet/tawny-owl 1.1.1-SNAPSHOT]]

  :hooks [take.build.gensource]
  )


where take.build.gensource is defined in the src directory of the
project (most of the rest of this directory will be generated).

Error: cannot resolve take.build.gensource/activate hook
Error: cannot resolve take.build.gensource/activate hook

The take/build/gensource.clj file exists and it has an activate
function.

I am guessing that this is failing because leiningen is not looking in
the project source-path, only it's own classpath. I'm a bit reticient to
write a leiningen plugin for this as a) it would be entirely specific to
this project and b) it would make the build more complex (AFAIK I'd have
to do a pre-build for the plugin, then another for the actual project)
and c) is a pain for anyone else.

So, should hooks work under these circumstances? Or must I go the plugin
route?

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

lein dependcies and exclusions

[Phillip Lord]

I'm struggling a little with dependencies in lein for an artifact that
is a dependency of a maven project. I have the following test sample
working.

This is project.clj


(defproject test-exclusion 0.1.0-SNAPSHOT
  :description FIXME: write description
  :url http://example.com/FIXME;
  :license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
  :dependencies [[org.clojure/clojure 1.6.0]
 [org.clojure/tools.nrepl 0.2.3]])



lein deps :tree

 [clojure-complete 0.2.3 :exclusions [[org.clojure/clojure]]]
 [org.clojure/clojure 1.6.0]
 [org.clojure/tools.nrepl 0.2.3 :exclusions [[org.clojure/clojure]]]

I don't understand where clojure-complete has come from here -- I've
disabled profile.clj for the test so it's not that. Otherwise, the
exclusions seem reasonable -- tools.nrepl specifies 1.2.0.

This generates the folling pom (which is what is used when maven starts).


dependencies
dependency
  groupIdorg.clojure/groupId
  artifactIdclojure/artifactId
  version1.6.0/version
/dependency
dependency
  groupIdorg.clojure/groupId
  artifactIdtools.nrepl/artifactId
  version0.2.3/version
/dependency
dependency
  groupIdorg.clojure/groupId
  artifactIdtools.nrepl/artifactId
  version0.2.3/version
  exclusions
exclusion
  groupIdorg.clojure/groupId
  artifactIdclojure/artifactId
/exclusion
  /exclusions
  scopetest/scope
/dependency
dependency
  groupIdclojure-complete/groupId
  artifactIdclojure-complete/artifactId
  version0.2.3/version
  exclusions
exclusion
  groupIdorg.clojure/groupId
  artifactIdclojure/artifactId
/exclusion
  /exclusions
  scopetest/scope
/dependency
  /dependencies


Both clojure-complete and tools.nrepl appear twice, the second time in
test scope with an exclusion. In many hands, this the second version
wins. A downstream project which depends on this project will not
include tools.nrepl as we are outside the test scope; this is breaking
my application.

Have I messed up?

Phil

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.