Jim <jimpil1...@gmail.com> writes:
> On 16/05/13 15:07, Phillip Lord wrote:
>> Yep, that's the problem. The library in question
>> (https://github.com/phillord/tawny-owl) is meant to be usable by people
>> who don't want to know that they are writing clojure.
> Funny that you're writing an ontology lib - my research is increasingly
> driving me towards using ontologies and therefore I may actually be your first
> user! (assuming that the lib is still in construction and has no users yet).
> :-)
I have one main user at the moment, although she is my PhD student; I
claim no coercion.
Give me a shout if your are more interested. I'm more interested in
ontologies than in clojure. Clojure just happened to be a good solution
to the problem I faced with tawny.
>> It's nice, though for use in test fixtures....
>>
>> (defn ontology-reasoner-fixture [tests]
>> (binding [r/*reasoner-progress-monitor*
>> r/reasoner-progress-monitor-silent]
>> (tests)))
>>
>> for instance. This prevents the code from either poping up a GUI or
>> generating lots of spam output, which is not good in a test.
> I'd write it like so:
>
> (defn ontology-reasoner-fixture
> [tests & {:keys [monitor]
> :or {monitor r/reasoner-progress-monitor-silent}}]
> (tests monitor))) ;;tests fn needs to accept an arg
>
I can't. This is use the clojure.test. The fixture gets passed a closure
that runs all the tests. It doesn't take an argument. Even if I could,
it would just pass the problem onward.
If I am doing this:
(r/isuperclass? p/FourCheesePizza p/CheesyPizza)
I really do not want to have pass in the progress monitor, at this
point. Worse, the reasoners are actually created as a side effect, and
this happens lazily. So, it's hard to know when.
All of this is very non-clojurish of course. I am just using it wrapper
around Java with a highly flexible syntax.
>> And having established a clear use case, which appears well motivated
>> and sensible, Clojure prevents me from providing the same convenience
>> knobs for my own library; at least in the same way.
>>
>> Okay, so I can use atoms. My question, why does clojure.core not?
>
> many of these settable vars point to something mutable in the first place
> (e.g. *in* & *out*). It wouldn't make sense to wrap them in atoms - it would
> be a waste of semantics. Imagine wrapping an arraylist with an atom...what is
> the point?
Indeed. Same in my case.
>
>> And which is the right default to pick? This is the problem. On my big
>> screen, the GUI is okay. On my netbook, it's a pain. On travis, running
>> headless, I want /dev/null.
>
> I can't express any opinions on that I'm afraid...I thought that your
> default' behaviour was clear to you..something like "always use silent monitor
> unless the user says otherwise".
Oh, sorry, I just meant that the default is arbitrary. The user needs to
be able to set it up, sometimes at the repl, and sometimes dynamically.
> The way you're describing it now it sounds like the ability to specify
> profiles in leiningen is what you need...since you can't avoid this
> particular type of 'deployment-specific' state, a config-map wrapped
> in an atom would suffice I think.
Hadn't thought about that; will investigate. I need to extend lein
anyway, so I can auto deploy ontologies.
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/groups/opt_out.
