Re: confused on set!
Ah, okay, I see the idea. I'm not sure why it doesn't work.
For now, I think, using an atom and reset! seems to do the job!
Phil
atkaaz atk...@gmail.com writes:
The following idea came to me in the shower, sort of out of the blue, and I
don't know why I didn't think of it before(I'm disappointed with myself)
so, why not use the same thing as clojure does? even though it does it in
java, you can do it in clojure, the only thing is that you have to do it
once, probably where you define the var, such as(well unfortunately it
doesn't work O_o maybe someone can explain?):
(I was gonna try java interop but I notice there's *
clojure.core/push-thread-bindings*)
=* (def ^:dynamic *test4* false)*
#'cgws.notcore/*test4*
= *(push-thread-bindings {#'*test4* true})*
nil
= **test4**
*false*
= (pop-thread-bindings)
nil
= *test4*
false
= (def ^:dynamic a 1)
#'cgws.notcore/a
= (push-thread-bindings {#'a 2})
nil
= a
1
= (set! a 3)
IllegalStateException Can't change/establish root binding of: a with set
clojure.lang.Var.set (Var.java:233)
(defn *push-thread-bindings*
WARNING: This is a low-level function. Prefer high-level macros like
binding where ever possible.
Takes a map of Var/value pairs. Binds each Var to the associated value for
the current thread. Each call *MUST* be accompanied by a matching call to
pop-thread-bindings wrapped in a try-finally!
(push-thread-bindings bindings)
(try
...
(finally
(pop-thread-bindings)))
{:added 1.1
:static true}
[bindings]
(clojure.lang.Var/pushThreadBindings bindings))
nil
=* *clojure-version**
{:interim true, :major 1, :minor* 6*, :incremental 0, :qualifier master}
so if this worked as I expected then the following two statements would be
in the same place:
= (def ^:dynamic *test1*)
#'cgws.notcore/*test1*
= (push-thread-bindings {#'test1 default value here})
nil
;and the third could be anywhere (in current thread, 'cause just as
clojure's *warn-on-reflection* when on a different thread you still can't
set! it)
= (set! test1 user value)
IllegalStateException Can't change/establish root binding of: test1 with
set clojure.lang.Var.set (Var.java:233)
*So, is **push-thread-bindings broken(unlikely) or am I missing
something(most certainly so) ?*
On Fri, May 17, 2013 at 6:49 PM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
Jim jimpil1...@gmail.com writes:
On 17/05/13 11:00, Phillip Lord wrote:
It's a nice language, I think. It inherits however the some of the
nastiness of Java, in particular it doesn't integrate at all into the
OS; the makes it not a good fit for little scripting, one-off jobs which
form the basis of a lot of scientific computing.
aaa yes indeed...the jvm is indeed very heavy-weight for such scripting
tasks...on the other hand have you looked at clojure-py? I'm not
up-to-date
with its current state/features but it should be viable for little
scripting
jobs... :)
Well, I an proficient in python, so it's probably easier just to use
python. Even if the documentation sucks.
Which gives me the dynamic scoped behaviour, but not the global
resetting behaviour.
I quickly wrote the following but I get an exception which I
don't have the time to sort at the moment...maybe later this evening...
:)
It's okay! I have a workable solution now, even if it still seems a
little unfair that I cannot take the same approach that clojure.core
does under the same circumstances!
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.
--
--
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
Re: confused on set!
The following idea came to me in the shower, sort of out of the blue, and I
don't know why I didn't think of it before(I'm disappointed with myself)
so, why not use the same thing as clojure does? even though it does it in
java, you can do it in clojure, the only thing is that you have to do it
once, probably where you define the var, such as(well unfortunately it
doesn't work O_o maybe someone can explain?):
(I was gonna try java interop but I notice there's *
clojure.core/push-thread-bindings*)
=* (def ^:dynamic *test4* false)*
#'cgws.notcore/*test4*
= *(push-thread-bindings {#'*test4* true})*
nil
= **test4**
*false*
= (pop-thread-bindings)
nil
= *test4*
false
= (def ^:dynamic a 1)
#'cgws.notcore/a
= (push-thread-bindings {#'a 2})
nil
= a
1
= (set! a 3)
IllegalStateException Can't change/establish root binding of: a with set
clojure.lang.Var.set (Var.java:233)
(defn *push-thread-bindings*
WARNING: This is a low-level function. Prefer high-level macros like
binding where ever possible.
Takes a map of Var/value pairs. Binds each Var to the associated value for
the current thread. Each call *MUST* be accompanied by a matching call to
pop-thread-bindings wrapped in a try-finally!
(push-thread-bindings bindings)
(try
...
(finally
(pop-thread-bindings)))
{:added 1.1
:static true}
[bindings]
(clojure.lang.Var/pushThreadBindings bindings))
nil
=* *clojure-version**
{:interim true, :major 1, :minor* 6*, :incremental 0, :qualifier master}
so if this worked as I expected then the following two statements would be
in the same place:
= (def ^:dynamic *test1*)
#'cgws.notcore/*test1*
= (push-thread-bindings {#'test1 default value here})
nil
;and the third could be anywhere (in current thread, 'cause just as
clojure's *warn-on-reflection* when on a different thread you still can't
set! it)
= (set! test1 user value)
IllegalStateException Can't change/establish root binding of: test1 with
set clojure.lang.Var.set (Var.java:233)
*So, is **push-thread-bindings broken(unlikely) or am I missing
something(most certainly so) ?*
On Fri, May 17, 2013 at 6:49 PM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
Jim jimpil1...@gmail.com writes:
On 17/05/13 11:00, Phillip Lord wrote:
It's a nice language, I think. It inherits however the some of the
nastiness of Java, in particular it doesn't integrate at all into the
OS; the makes it not a good fit for little scripting, one-off jobs which
form the basis of a lot of scientific computing.
aaa yes indeed...the jvm is indeed very heavy-weight for such scripting
tasks...on the other hand have you looked at clojure-py? I'm not
up-to-date
with its current state/features but it should be viable for little
scripting
jobs... :)
Well, I an proficient in python, so it's probably easier just to use
python. Even if the documentation sucks.
Which gives me the dynamic scoped behaviour, but not the global
resetting behaviour.
I quickly wrote the following but I get an exception which I
don't have the time to sort at the moment...maybe later this evening...
:)
It's okay! I have a workable solution now, even if it still seems a
little unfair that I cannot take the same approach that clojure.core
does under the same circumstances!
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.
--
--
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.
Re: confused on set!
Jim - FooBar(); jimpil1...@gmail.com writes:
You can count on that! In addition, whenever I find some free time I'd like to
have a look at the lib and familiarise myself with it...and who knows, I may
even have some (humble yet constructive) comments/feedback. Also, I think
you'll find Clojure is a joy to work with in most domains (my main discipline
is NLP but anything that involves 'heavy-data-lifting' is also a good
candidate).
It's a nice language, I think. It inherits however the some of the
nastiness of Java, in particular it doesn't integrate at all into the
OS; the makes it not a good fit for little scripting, one-off jobs which
form the basis of a lot of scientific computing.
aha! I see what you mean...how about 'with-bindings' then? something like this
should run the tests just fine:
(defn ontology-reasoner-fixture [tests]
(with-bindings {#'r/*reasoner-progress-monitor*
r/reasoner-progress-monitor-silent} tests))
...shorter, same behaviour and as a bonus you're not limited to vars declared
as dynamic. This should work with vanilla 'def' too :)
Which gives me the dynamic scoped behaviour, but not the global
resetting behaviour.
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.
Re: confused on set!
On 17/05/13 11:00, Phillip Lord wrote: It's a nice language, I think. It inherits however the some of the nastiness of Java, in particular it doesn't integrate at all into the OS; the makes it not a good fit for little scripting, one-off jobs which form the basis of a lot of scientific computing. aaa yes indeed...the jvm is indeed very heavy-weight for such scripting tasks...on the other hand have you looked at clojure-py? I'm not up-to-date with its current state/features but it should be viable for little scripting jobs... :) Which gives me the dynamic scoped behaviour, but not the global resetting behaviour. well, the thing is that Clojure in general is not well suited for imperative style code. There are some constructs that make it easier (e.g. with-local-vars), but for the most part you are expected to follow the 'functional-transformation' route instead of the 'imperative-mutation' one...If you absolutely need the global resettable behaviour I can only suggest an atom. Then, when you want to use that in tests, a little try-finally macro which swaps the atom and resets it in the finally clause would simulate your dynamic scope. I quickly wrote the following but I get an exception which I don't have the time to sort at the moment...maybe later this evening... :) (defmacro abinding [bs body] (let [pairs (partition 2 bs) ;;partition the bindings old-values (map (comp deref first) pairs) ;;save the original values _ (doseq [[b v] pairs] (reset! b v)) ;;introduce the new values restore (fn [] (map #(reset! (first %1) %2) pairs old-values))] ;;define the restoring fn `(try ~@body (finally (restore))) )) Jim -- -- 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.
Re: confused on set!
Jim jimpil1...@gmail.com writes: On 17/05/13 11:00, Phillip Lord wrote: It's a nice language, I think. It inherits however the some of the nastiness of Java, in particular it doesn't integrate at all into the OS; the makes it not a good fit for little scripting, one-off jobs which form the basis of a lot of scientific computing. aaa yes indeed...the jvm is indeed very heavy-weight for such scripting tasks...on the other hand have you looked at clojure-py? I'm not up-to-date with its current state/features but it should be viable for little scripting jobs... :) Well, I an proficient in python, so it's probably easier just to use python. Even if the documentation sucks. Which gives me the dynamic scoped behaviour, but not the global resetting behaviour. I quickly wrote the following but I get an exception which I don't have the time to sort at the moment...maybe later this evening... :) It's okay! I have a workable solution now, even if it still seems a little unfair that I cannot take the same approach that clojure.core does under the same circumstances! 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.
Re: confused on set!
Jim - FooBar(); jimpil1...@gmail.com writes:
(set!*my-test* true)
(alter-var-root #'*my-test* (constantly true))
here explains what you're asking:
http://clojure.org/Vars
scroll down to until you see
No, this only explains why
(def ^{:dynamic true} *my-test* false)
(set! *my-test* true)
causes an error. What it doesn't explain is why
(set! *warn-on-reflection* true)
works just fine. Is the REPL running inside a binding? Is it possible to
add other forms of this binding? Or not? And if it is okay to use set!
on *warn-on-reflection*, why is it not okay to allow me, as the library
developer, to define similar properties for my library which work in a
similar way.
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.
Re: confused on set!
On Thu, May 16, 2013 at 11:33 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Jim - FooBar(); jimpil1...@gmail.com writes: causes an error. What it doesn't explain is why (set! *warn-on-reflection* true) works just fine. Is the REPL running inside a binding? Is it possible to add other forms of this binding? Or not? And if it is okay to use set! This was discussed here a couple of months ago: https://groups.google.com/d/msg/clojure/ufoDL6eNL3U/DUbKH5yqzqUJ -- -- 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.
Re: confused on set!
On 16/05/13 11:33, Phillip Lord wrote: And if it is okay to use set! on*warn-on-reflection*, why is it not okay to allow me, as the library developer, to define similar properties for my library which work in a similar way. well, nothing stops you from providing bindings at the main entry point of your library, much in the same way that Clojure does...then consumers can use set! as you expect. That said, I wouldn't go down that road simply because it gives that 'global-state' smell... Jim -- -- 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.
Re: confused on set!
Jim jimpil1...@gmail.com writes:
On 16/05/13 11:33, Phillip Lord wrote:
And if it is okay to use set!
on*warn-on-reflection*, why is it not okay to allow me, as the library
developer, to define similar properties for my library which work in a
similar way.
well, nothing stops you from providing bindings at the main entry point of
your library, much in the same way that Clojure does...then consumers can use
set! as you expect. That said, I wouldn't go down that road simply because it
gives that 'global-state' smell...
I don't have a main entry point. And, yes, I want global-state for
exactly the same reason that Clojure does. I have a process that
produces logging output, and I want the user to be able to define
where that output goes. Basically, the same as doing:
(set! *out* some-sensible-value)
but different because I also want to be able to choose between a
GUI output, and text.
So, I guess, my two options are:
(def
^{:dynamic true}
*can-we-change-it* (atom John))
(println @*can-we-change-it*)
(reset! *can-we-change-it* Paul)
(println @*can-we-change-it*)
(binding [*can-we-change-it*
(atom George)]
(println @*can-we-change-it*))
(println @*can-we-change-it*)
(def
^{:dynamic true}
*can-we-change-this-one* Mick)
(println *can-we-change-this-one*)
(alter-var-root #'*can-we-change-this-one*
(fn [x] Keith))
(println *can-we-change-this-one*)
(binding [*can-we-change-this-one*
Bill]
(println *can-we-change-this-one*))
(println *can-we-change-this-one*)
Of which, I think, the former is the best option, although it's going to
break my existing code which uses binding forms.
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.
Re: confused on set!
why not ref and dosync?
On Thu, May 16, 2013 at 2:45 PM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
Jim jimpil1...@gmail.com writes:
On 16/05/13 11:33, Phillip Lord wrote:
And if it is okay to use set!
on*warn-on-reflection*, why is it not okay to allow me, as the library
developer, to define similar properties for my library which work in a
similar way.
well, nothing stops you from providing bindings at the main entry point
of
your library, much in the same way that Clojure does...then consumers
can use
set! as you expect. That said, I wouldn't go down that road simply
because it
gives that 'global-state' smell...
I don't have a main entry point. And, yes, I want global-state for
exactly the same reason that Clojure does. I have a process that
produces logging output, and I want the user to be able to define
where that output goes. Basically, the same as doing:
(set! *out* some-sensible-value)
but different because I also want to be able to choose between a
GUI output, and text.
So, I guess, my two options are:
(def
^{:dynamic true}
*can-we-change-it* (atom John))
(println @*can-we-change-it*)
(reset! *can-we-change-it* Paul)
(println @*can-we-change-it*)
(binding [*can-we-change-it*
(atom George)]
(println @*can-we-change-it*))
(println @*can-we-change-it*)
(def
^{:dynamic true}
*can-we-change-this-one* Mick)
(println *can-we-change-this-one*)
(alter-var-root #'*can-we-change-this-one*
(fn [x] Keith))
(println *can-we-change-this-one*)
(binding [*can-we-change-this-one*
Bill]
(println *can-we-change-this-one*))
(println *can-we-change-this-one*)
Of which, I think, the former is the best option, although it's going to
break my existing code which uses binding forms.
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.
--
--
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.
Re: confused on set!
On 16/05/13 12:45, Phillip Lord wrote: I have a process that produces logging output, and I want the user to be able to define where that output goes. or you can define a multi-method or a tiny protocol with 2-3 implementations (for GUI, raw-text or file-output) and let your user select what he needs and potentially extend the functionality...why does this have to be a statefull call? dynamic scope should be treated with care Jim ps: multi-methods allow for :default implementation which sounds to me like it would suit your needs... -- -- 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.
Re: confused on set!
On 16/05/13 12:52, AtKaaZ wrote: why not ref and dosync? a bit heavyweight isn't it? A bit off topic but I remember when Clojure came out, STM was the big selling point! I've been programming Clojure for more than 3 years now and I've yet to write code that uses STM but that wasn't intentional...I just did not need to (slightly ironic I find)... :) dynamic scope is another story though...I very much intentionally stayed away from it! Jim -- -- 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.
Re: confused on set!
you're right, I somehow didn't read what he was using it for, just looked at the examples he gave and assumed generic var In a way I'm in his shoes, but I always assumed that the user would use binding even if that meant encompassing the whole program in it. Like if you wanted to disable asserts ok bad example since set! works for this too, but I have something like that and I was ok with the idea that the user would use binding around the whole code to set that. Maybe I should consider other alternatives... but now I can't think:) On Thu, May 16, 2013 at 3:01 PM, Jim jimpil1...@gmail.com wrote: On 16/05/13 12:52, AtKaaZ wrote: why not ref and dosync? a bit heavyweight isn't it? A bit off topic but I remember when Clojure came out, STM was the big selling point! I've been programming Clojure for more than 3 years now and I've yet to write code that uses STM but that wasn't intentional...I just did not need to (slightly ironic I find)... :) dynamic scope is another story though...I very much intentionally stayed away from it! Jim -- -- 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- 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.
Re: confused on set!
On 16/05/13 13:56, AtKaaZ wrote: In a way I'm in his shoes, but I always assumed that the user would use binding even if that meant encompassing the whole program in it. personally, I find it rather unpleasant to depend on a lib that forces me to use 'binding' in such a top-level fashion...Clojure does this internally to provide convenience knobs for certain static resources (e.g. *in* *out*) and for vars that don't really get involved in your business logic (e.g. *warn-on-reflection* *unhecked-math*) but I don't think I've ever seen code that binds these from top to bottom. *in* *out* usually appear in a limited 'binding' expression (2-3 lines) and *warn-on-reflection* *unhecked-math* usually appear to be set at the top of a namespace. For state that your actual logic depends on, people seem to be in favour of atoms (including myself) or in fact any reference-type depending on your use-case semanticsIt just is more transparent... :) that said, I think the OP is not looking for state but for polymorphic behavior...hence, my previous suggestion. Jim -- -- 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.
Re: confused on set!
Jim jimpil1...@gmail.com writes: On 16/05/13 12:52, AtKaaZ wrote: why not ref and dosync? a bit heavyweight isn't it? 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. dynamic scope is another story though...I very much intentionally stayed away from it! It's useful, but scary. It mixes with laziness badly, but then, so do exceptions. 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. 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.
Re: confused on set!
Jim jimpil1...@gmail.com writes: On 16/05/13 13:56, AtKaaZ wrote: In a way I'm in his shoes, but I always assumed that the user would use binding even if that meant encompassing the whole program in it. personally, I find it rather unpleasant to depend on a lib that forces me to use 'binding' in such a top-level fashion...Clojure does this internally to provide convenience knobs for certain static resources (e.g. *in* *out*) and for vars that don't really get involved in your business logic (e.g. *warn-on-reflection* *unhecked-math*) 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? that said, I think the OP is not looking for state but for polymorphic behavior...hence, my previous suggestion. Pretty much. Or what you might call slow state. The user might want to switch between the defaults, but the code itself never will. 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.
Re: confused on set!
Jim jimpil1...@gmail.com writes: On 16/05/13 12:45, Phillip Lord wrote: I have a process that produces logging output, and I want the user to be able to define where that output goes. or you can define a multi-method or a tiny protocol with 2-3 implementations (for GUI, raw-text or file-output) and let your user select what he needs and potentially extend the functionality...why does this have to be a statefull call? dynamic scope should be treated with care Jim ps: multi-methods allow for :default implementation which sounds to me like it would suit your needs... 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 could use a multi-method, but then it would have to dispatch on the basis of some thing stateful; back to square one. I think I have a solution, now, though. Still not convinced that clojure.core has got this right. But, I can move forward and, thanks to this discussion, I don't think I have missed anything 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/groups/opt_out.
Re: confused on set!
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). :-)
It's useful, but scary. It mixes with laziness badly, but then, so do
exceptions.
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
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?
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. 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.
HTH,
Jim
--
--
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.
Re: confused on set!
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.
Re: confused on set!
On 16/05/13 16:48, Phillip Lord wrote:
I have one main user at the moment, although she is my PhD student; I
claim no coercion.
I am a Ph.D student myself and that's exactly where I will most likely
need ontologies...
Something tells me we're going to be in contact soon :)
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.
You can count on that! In addition, whenever I find some free time I'd
like to have a look at the lib and familiarise myself with it...and who
knows, I may even have some (humble yet constructive) comments/feedback.
Also, I think you'll find Clojure is a joy to work with in most domains
(my main discipline is NLP but anything that involves
'heavy-data-lifting' is also a good candidate).
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.
aha! I see what you mean...how about 'with-bindings' then? something
like this should run the tests just fine:
(defn ontology-reasoner-fixture [tests]
(with-bindings {#'r/*reasoner-progress-monitor*
r/reasoner-progress-monitor-silent} tests))
...shorter, same behaviour and as a bonus you're not limited to vars
declared as dynamic. This should work with vanilla 'def' too :)
Jim
--
--
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.
confused on set!
I'm still a bit confused on the use of set!
I would like to define a configuration variable that is easy to change,
but which is not critical to my infrastructure; it's will set some
default behaviours.
Now, I can do things like
(binding [*warn-on-reflection* true]
(do-some-function))
and it does the right thing. Similarly, I can do
(def ^{:dynamic true} *my-test* false)
(binding [*my-test* true]
(do-some-function))
and this all works.
However, while I can do
(set! *warn-on-reflection* true)
I cannot do
(set! *my-test* true)
because I cannot change the root binding. What I confused about is how
does this work with *warn-on-reflection*? Where is the root binding? And
how come I am not trying to set it also? Can I get similar behaviour for
one of my vars? Or do I need to do something like:
(def *my-test* (atom true))
(reset! *my-test false)
but then I loose my dynamic binding?
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.
Re: confused on set!
On 15/05/13 17:23, Phillip Lord wrote: I cannot do (set!*my-test* true) (alter-var-root #'*my-test* (constantly true)) Jim -- -- 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.
Re: confused on set!
On 15/05/13 17:28, Jim - FooBar(); wrote: On 15/05/13 17:23, Phillip Lord wrote: I cannot do (set!*my-test* true) (alter-var-root #'*my-test* (constantly true)) Jim here explains what you're asking: http://clojure.org/Vars scroll down to until you see (*set!*var-symbol expr) HTH, Jim -- -- 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.
Re: confused on set!
I think the answer is in RT 's doInit
Var.pushThreadBindings(
RT.mapUniqueKeys(CURRENT_NS, CURRENT_NS.deref(),
WARN_ON_REFLECTION, WARN_ON_REFLECTION.deref()
,RT.UNCHECKED_MATH, RT.UNCHECKED_MATH.deref()));
it basically does a
(binding [*warn-on-reflection* currentvaluehere])
where currentvaluehere is false
so it's like:
(binding [*my-test1* *my-test1*]
(set! *my-test1* true))
basically set! works because you're not seeing the root binding, you're
inside a binding already, at least that's what I'm getting out of it.
Which leads you to the following:
user= (.start (Thread. (fn [] (do (set! *warn-on-reflection* true)
(println inthread)
Exception in thread Thread-12 java.lang.IllegalStateException: Can't
change/establish root binding
of: *warn-on-reflection* with set
at clojure.lang.Var.set(Var.java:233)
at user$eval1176$fn__1177.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:722)
nil
On Wed, May 15, 2013 at 7:23 PM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
I'm still a bit confused on the use of set!
I would like to define a configuration variable that is easy to change,
but which is not critical to my infrastructure; it's will set some
default behaviours.
Now, I can do things like
(binding [*warn-on-reflection* true]
(do-some-function))
and it does the right thing. Similarly, I can do
(def ^{:dynamic true} *my-test* false)
(binding [*my-test* true]
(do-some-function))
and this all works.
However, while I can do
(set! *warn-on-reflection* true)
I cannot do
(set! *my-test* true)
because I cannot change the root binding. What I confused about is how
does this work with *warn-on-reflection*? Where is the root binding? And
how come I am not trying to set it also? Can I get similar behaviour for
one of my vars? Or do I need to do something like:
(def *my-test* (atom true))
(reset! *my-test false)
but then I loose my dynamic binding?
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.
--
--
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.
