Re: pre-conditions on >!
Consider the following attempt: for some reason, after the assertion fails, the main repl thread seems to lock up Line 1 Line 2 // after this, no more is printed Question: what is causing the problem -- and how do I fix it? Thanks! === code === (ns test (:require #+clj [clojure.core.async.impl.protocols :as impl] #+cljs [cljs.core.async.impl.protocols :as impl] #+clj [clojure.core.async.impl.channels :as channels] #+cljs [cljs.core.async.impl.channels :as channels] #+clj [clojure.core.async :as async] #+cljs [cljs.core.async :as async])) (do (deftype CheckedBuffer [buf check] impl/Buffer (full? [this] (impl/full? buf)) (remove! [this] (impl/remove! buf)) (add! [this itm] (check itm) (impl/add! buf itm))) (defn cchan [n check] (channels/chan (CheckedBuffer. (async/buffer n) check))) (def oc (cchan 100 #(assert (even? % (println "Line 1") (async/alts!! [[oc 2]] :default :chan-full) (println "Line 2") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 3") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 4") ) On Tue, Jan 21, 2014 at 11:46 PM, Kelker Ryan wrote: > Can't you just test the value before placing a value in a channel? > > 22.01.2014, 16:27, "t x" : > > Hi, > > > ## Question: > > For a channel, is it possible to put a pre-condition of sorts on a > channel? > > For example: > > (let [chan (async/chan 100)] > (set-pre-condition! chan even?) > (put! chan 1) ;; exception thrown > (>!! chan 3) ;; exception thrown > ) > > ## Asides > > It's important that I want the exception to be thrown at the time of > put, NOT at the time of take via 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/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. > -- -- 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: pre-conditions on >!
With apologies for spamming: in case anyone else wanted a solution to this problem: I believe the right layer is to wrap at the Channel layer, rather than the Buffer layer: for example: (ns test (:require #+clj [clojure.core.async.impl.protocols :as impl] #+cljs [cljs.core.async.impl.protocols :as impl] #+clj [clojure.core.async.impl.channels :as channels] #+cljs [cljs.core.async.impl.channels :as channels] #+clj [clojure.core.async :as async] #+cljs [cljs.core.async :as async])) (do (deftype CheckedChannel [chan check] impl/WritePort (put! [this val handler] (check val) (impl/put! chan val handler)) impl/ReadPort (take! [this handler] (impl/take! chan handler)) impl/Channel (close! [this] (impl/close! chan))) (defn cchan [n check] (CheckedChannel. (async/chan n) check)) (def oc (cchan 100 #(assert (even? % (println "Line 1") (async/alts!! [[oc 2]] :default :chan-full) (println "Line 2") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 3") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 4") ) On Wed, Jan 22, 2014 at 12:02 AM, t x wrote: > Consider the following attempt: > > for some reason, after the assertion fails, the main repl thread seems to > lock up > > Line 1 > Line 2 // after this, no more is printed > > > Question: what is causing the problem -- and how do I fix it? > > Thanks! > > === code === > > (ns test > (:require >#+clj [clojure.core.async.impl.protocols :as impl] >#+cljs [cljs.core.async.impl.protocols :as impl] >#+clj [clojure.core.async.impl.channels :as channels] >#+cljs [cljs.core.async.impl.channels :as channels] >#+clj [clojure.core.async :as async] >#+cljs [cljs.core.async :as async])) > > (do > > (deftype CheckedBuffer [buf check] > impl/Buffer > (full? [this] (impl/full? buf)) > (remove! [this] (impl/remove! buf)) > (add! [this itm] > (check itm) > (impl/add! buf itm))) > > > (defn cchan [n check] > (channels/chan (CheckedBuffer. (async/buffer n) check))) > > > (def oc (cchan 100 #(assert (even? % > > (println "Line 1") > (async/alts!! [[oc 2]] :default :chan-full) > (println "Line 2") > (async/alts!! [[oc 3]] :default :chan-full) > (println "Line 3") > (async/alts!! [[oc 3]] :default :chan-full) > (println "Line 4") > > ) > > > > On Tue, Jan 21, 2014 at 11:46 PM, Kelker Ryan wrote: > >> Can't you just test the value before placing a value in a channel? >> >> 22.01.2014, 16:27, "t x" : >> >> Hi, >> >> >> ## Question: >> >> For a channel, is it possible to put a pre-condition of sorts on a >> channel? >> >> For example: >> >> (let [chan (async/chan 100)] >> (set-pre-condition! chan even?) >> (put! chan 1) ;; exception thrown >> (>!! chan 3) ;; exception thrown >> ) >> >> ## Asides >> >> It's important that I want the exception to be thrown at the time of >> put, NOT at the time of take via > 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/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. >> > > -- -- 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: pre-conditions on >!
use filter> user=> (def c (chan 10)) #'user/c user=> (def cf (filter> #(if (even? %) % (throw (IllegalArgumentException.))) c)) #'user/cf user=> (>!! cf 2) nil user=> (>!! cf 1) IllegalArgumentException user/fn--4294 (form-init9067455327434905636.clj:1) user=> (>!! cf 4) nil user=> ( ( wrote: > With apologies for spamming: > > in case anyone else wanted a solution to this problem: > > I believe the right layer is to wrap at the Channel layer, rather than the > Buffer layer: for example: > > > (ns test > (:require >#+clj [clojure.core.async.impl.protocols :as impl] >#+cljs [cljs.core.async.impl.protocols :as impl] >#+clj [clojure.core.async.impl.channels :as channels] >#+cljs [cljs.core.async.impl.channels :as channels] >#+clj [clojure.core.async :as async] >#+cljs [cljs.core.async :as async])) > > (do > > (deftype CheckedChannel [chan check] > impl/WritePort (put! [this val handler] > (check val) > (impl/put! chan val handler)) > impl/ReadPort (take! [this handler] > (impl/take! chan handler)) > impl/Channel (close! [this] >(impl/close! chan))) > > > (defn cchan [n check] > (CheckedChannel. (async/chan n) check)) > > > (def oc (cchan 100 #(assert (even? % > > (println "Line 1") > (async/alts!! [[oc 2]] :default :chan-full) > (println "Line 2") > (async/alts!! [[oc 3]] :default :chan-full) > (println "Line 3") > (async/alts!! [[oc 3]] :default :chan-full) > (println "Line 4") > > ) > > > > On Wed, Jan 22, 2014 at 12:02 AM, t x wrote: > >> Consider the following attempt: >> >> for some reason, after the assertion fails, the main repl thread seems to >> lock up >> >> Line 1 >> Line 2 // after this, no more is printed >> >> >> Question: what is causing the problem -- and how do I fix it? >> >> Thanks! >> >> === code === >> >> (ns test >> (:require >>#+clj [clojure.core.async.impl.protocols :as impl] >>#+cljs [cljs.core.async.impl.protocols :as impl] >>#+clj [clojure.core.async.impl.channels :as channels] >>#+cljs [cljs.core.async.impl.channels :as channels] >>#+clj [clojure.core.async :as async] >>#+cljs [cljs.core.async :as async])) >> >> (do >> >> (deftype CheckedBuffer [buf check] >> impl/Buffer >> (full? [this] (impl/full? buf)) >> (remove! [this] (impl/remove! buf)) >> (add! [this itm] >> (check itm) >> (impl/add! buf itm))) >> >> >> (defn cchan [n check] >> (channels/chan (CheckedBuffer. (async/buffer n) check))) >> >> >> (def oc (cchan 100 #(assert (even? % >> >> (println "Line 1") >> (async/alts!! [[oc 2]] :default :chan-full) >> (println "Line 2") >> (async/alts!! [[oc 3]] :default :chan-full) >> (println "Line 3") >> (async/alts!! [[oc 3]] :default :chan-full) >> (println "Line 4") >> >> ) >> >> >> >> On Tue, Jan 21, 2014 at 11:46 PM, Kelker Ryan wrote: >> >>> Can't you just test the value before placing a value in a channel? >>> >>> 22.01.2014, 16:27, "t x" : >>> >>> Hi, >>> >>> >>> ## Question: >>> >>> For a channel, is it possible to put a pre-condition of sorts on a >>> channel? >>> >>> For example: >>> >>> (let [chan (async/chan 100)] >>> (set-pre-condition! chan even?) >>> (put! chan 1) ;; exception thrown >>> (>!! chan 3) ;; exception thrown >>> ) >>> >>> ## Asides >>> >>> It's important that I want the exception to be thrown at the time of >>> put, NOT at the time of take via >> 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/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.
Re: core.async question - canceling thread
So far, this is the only way I've figured out that works: (defn try-fib [n] (let [ch (timeout 1000) th (Thread. #(>!! ch (fib n))) _ (.start th) answer (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: core.async question - canceling thread
You can put the computation into a future, and cancel the future after the timeout. BTW is it idiomatic to write to the timeout channel? I thought one should use something like (alts!! [c (timeout 1000)]). JW On Wednesday, January 22, 2014 11:30:23 AM UTC+1, puzzler wrote: > > So far, this is the only way I've figured out that works: > > (defn try-fib [n] > (let [ch (timeout 1000) > th (Thread. #(>!! ch (fib n))) > _ (.start th) > answer ( (if answer answer > (do (.stop th) nil > > But there are a couple bazillion sources that say you should never, ever > stop a thread. Is it perfectly safe in a situation like this where the > thread is running a pure function with no mutable state? > > Is there a better approach that is more integrated with core.async and > more safe? > -- -- 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: Security implications of code is data/data is code
Sorry Luc P., you are right. I meant that people wouldn't do that without a good reason, but it was not what I wrote. On Wednesday, January 22, 2014 3:10:27 AM UTC-2, Luc wrote: > > Your last statement is incomplete. > > It all depends on trust. We do eval at > runtime of code and data w/o edn > but we know it comes from a secured > source. > > Doing such thing from an unsecured > alien source would "potentially" look insane. Lets not presume about > the insanity of the designer w/o some deeper analysis :))) > > Luc P. > > > Hi Daniel, > > > > I'm not an expert in security but AFAIK this is not a problem. Every > user > > input is a string and you chose how to parse it. There is a edn reader > that > > is safe, but you can use specific parsers depending on the input. Of > course > > if you read and eval the string anything could happen, but nobody would > do > > that. > > > > Best, > > mynomoto > > > > On Tuesday, January 21, 2014 10:22:11 PM UTC-2, Daniel Compton wrote: > > > > > > I've been thinking for a while about what the security implications > are > > > for a homoiconic language like Clojure where code is data and data is > code. > > > What protections do you have against malicious input being > automatically > > > evaluated by the reader? It seems like every user input would be a > possible > > > case of 'Clojure injection'. Is this an issue or am I missing > something > > > really obvious here? > > > > > > Thanks, Daniel. > > > > > > > -- > > -- > > 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 clojure+u...@googlegroups.com . > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > Luc Prefontaine> sent by ibisMail! > -- -- 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.
(go (loop [ ..] (try ... (catch ..)))) won't compile
Hi, I have a processing loop in a go block and I wanted to make sure that the processing continue with the next iteration if an exception is thrown. The following code doesn't seem to be accepted by the go macro: (go (loop [xs (range 10)] (when-let [x (first xs)] (try (println x) (recur (rest x)) (catch Throwable t nil) as it returns IllegalArgumentException No implementation of method: :emit-instruction of protocol: #'clojure.core.async.impl.ioc-macros/IEmittableInstruction found for class: clojure.core.async.impl.ioc_macros.Jmp I can't think of an alternative right now, any ideas? -- László Török -- -- 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: MyType cannot be cast to MyType?
Thank you for that. I've found that the code works correctly if I just copy it into the repl and run it; it's only when I load it in Eclipse (with Counterclockwise) using ctrl-alt-s that it displays the error. Is there some way to reset the repl to a blank state (remove all previous class definitions) other than just closing and re-opening it? On Wednesday, 22 January 2014 12:11:07 UTC+11, Stuart Sierra wrote: > > Hello Jonathan, > > In my experience, an error along the lines of "class Foo cannot be cast to > Foo" is usually caused by re-evaluating class definitions, either by > reloading files or by re-evaluating definitions in your REPL or IDE. > > Here is a smaller example that demonstrates the problem: > > (deftype Foo [x]) > > (def a-foo (Foo. 1)) > > (defn use-foo [^Foo foo] > (prn (.x foo))) > > ;; Re-evaluate the definition of Foo, > ;; perhaps in a REPL or editor: > (deftype Foo [x]) > > (type a-foo) ;;=> user.Foo > > (= Foo (type a-foo)) ;;=> false > > (use-foo a-foo) > ;; java.lang.ClassCastException: > ;; user.Foo cannot be cast to user.Foo > > The object `*a-foo*` is an instance of the **first** definition of the > type Foo, which was overwritten by the **second** definition of the type > Foo. > > This problem is caused by a combination of Clojure's runtime generation of > Java classes and the way JVM ClassLoaders work. > > -S > > > > On Sunday, January 19, 2014 9:20:03 PM UTC-5, Jonathan Barnard wrote: >> >> For fun, I've been porting a very simple particle animation from Java to >> Clojure. It was somewhat slow so to see how fast I could make it I decided >> to try using mutation. I've defined a Particle type, and a PSlice type that >> contains an array of objects and a length (number of non-nil objects in the >> slice), but when I try to provide type hints for this slice type, I get the >> error: >> >> *ClassCastException MyProject.core.PSlice cannot be cast to * >> >> *MyProject.core.PSlice *Is this a bug, or am I doing something wrong? My >> code defining the two types is: >> >> (definterface IPt >> (^Double gx []) (^Double gy []) (^Double gz []) (^Double gvx []) >> (^Double gvy []) (^Double gvz []) (^Double gR []) (^Double glife []) >> (^Boolean gis []) >> (sx [^Double v]) (sy [^Double v]) (sz [^Double v]) (svx [^Double v]) >> (svy [^Double v]) (svz [^Double v]) (sR [^Double v]) (slife [^Double v]) >> (^Boolean sis [^Boolean v])) >> >> (deftype Particle [^:unsynchronized-mutable ^Double x >> ^:unsynchronized-mutable ^Double y ^:unsynchronized-mutable ^Double z >>^:unsynchronized-mutable ^Double vx >> ^:unsynchronized-mutable ^Double vy ^:unsynchronized-mutable ^Double vz >>^:unsynchronized-mutable ^Double R >> ^:unsynchronized-mutable ^Double life ^:unsynchronized-mutable ^Boolean is] >> IPt >> (gx [_] x) (gy [_] y) (gz [_] z) (gvx [_] vx) (gvy [_] vy) (gvz [_] vz) >> (gR [_] R) (glife [_] life) (gis [_] is) >> (sx [this v] (set! x v)) (sy [this v] (set! y v)) (sz [this v] (set! z >> v)) >> (svx [this v] (set! vx v)) (svy [this v] (set! vy v)) (svz [this v] >> (set! vz v)) >> (sR [this v] (set! R v)) (slife [this v] (set! life v)) (sis [this v] >> (set! is v))) >> >> (definterface ISlice >> (^Long gLen []) >> (sLen [^Long x]) >> (^Particle gPt [^Long n]) >> (sPt [^Long n ^Particle pt] )) >> >> (deftype PSlice [^"[Ljava.lang.Object;" pts ^:unsynchronized-mutable >> ^Long len] >> ISlice >> (gLen [_] len) >> (sLen [this new-len] (set! len new-len)) >> (gPt [this n] (aget pts n)) >> (sPt [this n pt] (aset pts n pt))) >> >> >> Then the error occurs if I define a PSlice, such as by: >> >> (def tslice (PSlice. (make-array Object 100) 0)) >> >> and a function: >> >> (defn test-fn [^PSlice slice] >> (print (.gLen slice)) >> ) >> >> Then call (test-fn tslice). >> >> Note that the function will work as intended if no type hints are >> provided, but will run quite slowly due to reflection, defeating the point >> of using mutation. >> > -- -- 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: (go (loop [ ..] (try ... (catch ..)))) won't compile
Sorry, too eager too soon. (loop (try ..) ) obviously doesn't work :) 2014/1/22 László Török > Hi, > > I have a processing loop in a go block and I wanted to make sure that the > processing continue with the next iteration if an exception is thrown. > > The following code doesn't seem to be accepted by the go macro: > > (go > (loop [xs (range 10)] >(when-let [x (first xs)] > (try >(println x) >(recur (rest x)) >(catch Throwable t nil) > > as it returns IllegalArgumentException No implementation of method: > :emit-instruction of protocol: > #'clojure.core.async.impl.ioc-macros/IEmittableInstruction found for class: > clojure.core.async.impl.ioc_macros.Jmp > > I can't think of an alternative right now, any ideas? > > -- > László Török > -- László Török -- -- 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.
Simple Macros
Hi, I've been using clojure for a few months now, but I've tried to avoid writing my own macros in production code, because of the general warnings I've heard about misusing their power and the challenges I've run into with debugging them. I was looking through the core.async code, and I noticed that the go-loop macro is almost trivial (as far as I understand)[1]. I was wondering if people had advice on when to write these sorts of macros vs. when to just use the trivial expansion in the code? (Or alternatively, what am I missing in this macro definition?) (defmacro go-loop "Like (go (loop ...))" [bindings & body] `(go (loop ~bindings ~@body))) Thanks in advance, Alejandro [1]: https://github.com/clojure/core.async/blame/fe8103da637f2475e7fce5e9675326c7450c4399/src/main/clojure/clojure/core/async.clj#L446 -- -- 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: (go (loop [ ..] (try ... (catch ..)))) won't compile
Just pull the exception out of the loop logic: (go (loop [xs (range 10)] (if-let [x (first xs)] (if (= ::error (try (println x) (catch Throwable t ::error))) (recur (rest x)) - James On 22 January 2014 11:05, László Török wrote: > Hi, > > I have a processing loop in a go block and I wanted to make sure that the > processing continue with the next iteration if an exception is thrown. > > The following code doesn't seem to be accepted by the go macro: > > (go > (loop [xs (range 10)] >(when-let [x (first xs)] > (try >(println x) >(recur (rest x)) >(catch Throwable t nil) > > as it returns IllegalArgumentException No implementation of method: > :emit-instruction of protocol: > #'clojure.core.async.impl.ioc-macros/IEmittableInstruction found for class: > clojure.core.async.impl.ioc_macros.Jmp > > I can't think of an alternative right now, any ideas? > > -- > László Török > > -- > -- > 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.
tools.cli and required arguments
Hi all! Trying to use clojure.tools.cli to help us parse command line arguments. However we are having trouble understanding how to specify required arguments. The following example taken from the documentation ( https://github.com/clojure/tools.cli#quick-start) should give a required argument (but we have commented out default value). However errors is nil: (def cli-options ;; An option with a required argument [["-p" "--port PORT" "Port number" ; :default 80 :parse-fn #(Integer/parseInt %) :validate [#(< 0 % 0x1) "Must be a number between 0 and 65536"]] ;; A non-idempotent option ["-v" nil "Verbosity level" :id :verbosity :default 0 :assoc-fn (fn [m k _] (update-in m [k] inc))] ;; A boolean option defaulting to nil ["-h" "--help"]]) ;=> (var user/cli-options) (:errors (parse-opts [] cli-options)) ;=> nil Actually giving it a value will give an error though: (:errors (parse-opts ["--port" ""] cli-options)) ;=> ["Error while parsing option \"--port \": java.lang.NumberFormatException: For input string: \"\""] >From the documentation it seems that specifying the second part of the "long option" should be enough to make an argument required. So this minimal example should also produce errors: (def cli-options-simplified [["-p" "--port PORT" "Port number"]]) ;=> (var user/cli-options-simplified) (:errors (parse-opts [] cli-options-simplified)) ;=> nil So what are we misunderstanding? Any pointers would be greatly appreciated. Using Clojure 1.5.1 with tools.cli 0.3.1. Cheers, Alf -- -- 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.
random thought on #_
I like #_, it's very useful I had a thought I'd like to have #__ - two _ to comment 2 expressions - specifically for commenting in maps Then I thought #_n where n is an integer - to comment as many as you need. end of my thought. Dave -- -- 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: tools.cli and required arguments
On Wed 22 Jan 2014 at 01:48:22PM +0100, Alf Kristian Støyle wrote:
> From the documentation it seems that specifying the second part of the
> "long option" should be enough to make an argument required. So this
> minimal example should also produce errors:
>
> (def cli-options-simplified
> [["-p" "--port PORT" "Port number"]])
> ;=> (var user/cli-options-simplified)
>
> (:errors (parse-opts [] cli-options-simplified))
> ;=> nil
>
> So what are we misunderstanding? Any pointers would be greatly appreciated.
>
> Using Clojure 1.5.1 with tools.cli 0.3.1.
Hi Alf,
An option with a required argument (via "--port PORT" or the :required
entry) only specifies that the option must be followed by an argument
_if_ it is specified on the command line. For example,
$ cmd --port
is an error, but simply
$ cmd
is not.
If you would like require that --port must be specified in every
invocation, you can assert its existence/value in the options map:
(let [{:keys [options errors …]} (parse-opts argv cli-options)]
…
(assert (:port options) "`--port` must be specified")
…)
You can, of course, set a :default value for a required option.
HTH
guns
pgpBXXVLuJtaf.pgp
Description: PGP signature
Re: Simple Macros
On Tue 21 Jan 2014 at 07:33:43PM -0800, Alejandro Ciniglio wrote: > I was wondering if people had advice on when to write these sorts of > macros vs. when to just use the trivial expansion in the code? (Or > alternatively, what am I missing in this macro definition?) > > (defmacro go-loop > "Like (go (loop ...))" > [bindings & body] > `(go (loop ~bindings ~@body))) go-loop needs to be a macro to capture the unevaluated let bindings: (go-loop [i 0] …) If go-loop were a function, this code would throw an error because i is undefined. guns pgpV9FBLIxrCe.pgp Description: PGP signature
Re: tools.cli and required arguments
Thanks! That does explain it :)
Would be nice to be able to specify that an option "must be specified in
every invocation" though. I think it would lead to better error messages,
e.g. if several "mandatory" options are forgotten, they will be shown at
once. That is a bit of a hassle when doing it yourself.
Haven't looked too hard at the source though, but any chance of
contributing a patch to something like that?
E.g.
[["-p" "--port PORT" "Port number"
:mandatory true]]
Cheers,
Alf
On 22 January 2014 14:04, guns wrote:
> On Wed 22 Jan 2014 at 01:48:22PM +0100, Alf Kristian Støyle wrote:
>
> > From the documentation it seems that specifying the second part of the
> > "long option" should be enough to make an argument required. So this
> > minimal example should also produce errors:
> >
> > (def cli-options-simplified
> > [["-p" "--port PORT" "Port number"]])
> > ;=> (var user/cli-options-simplified)
> >
> > (:errors (parse-opts [] cli-options-simplified))
> > ;=> nil
> >
> > So what are we misunderstanding? Any pointers would be greatly
> appreciated.
> >
> > Using Clojure 1.5.1 with tools.cli 0.3.1.
>
> Hi Alf,
>
> An option with a required argument (via "--port PORT" or the :required
> entry) only specifies that the option must be followed by an argument
> _if_ it is specified on the command line. For example,
>
> $ cmd --port
>
> is an error, but simply
>
> $ cmd
>
> is not.
>
> If you would like require that --port must be specified in every
> invocation, you can assert its existence/value in the options map:
>
> (let [{:keys [options errors …]} (parse-opts argv cli-options)]
> …
> (assert (:port options) "`--port` must be specified")
> …)
>
> You can, of course, set a :default value for a required option.
>
> HTH
> guns
>
--
--
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: random thought on #_
#_ nests nicely: #_#_ comments out the next two expressions. Christophe On Wed, Jan 22, 2014 at 2:03 PM, Dave Sann wrote: > I like #_, it's very useful > > I had a thought I'd like to have #__ - two _ to comment 2 expressions - > specifically for commenting in maps > > Then I thought > > #_n where n is an integer - to comment as many as you need. > > end of my thought. > > > Dave > > -- > -- > 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. > -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting & Contracting http://lambdanext.eu/ -- -- 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: random thought on #_
another little gem. Just what I wanted. It didn't occur to me that it would work this way - but now it seems obvious Thanks Christophe Dave On Thursday, 23 January 2014 00:21:53 UTC+11, Christophe Grand wrote: > > #_ nests nicely: > #_#_ comments out the next two expressions. > > Christophe > > > On Wed, Jan 22, 2014 at 2:03 PM, Dave Sann > > wrote: > >> I like #_, it's very useful >> >> I had a thought I'd like to have #__ - two _ to comment 2 expressions - >> specifically for commenting in maps >> >> Then I thought >> >> #_n where n is an integer - to comment as many as you need. >> >> end of my thought. >> >> >> Dave >> >> -- >> -- >> 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 clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > On Clojure http://clj-me.cgrand.net/ > Clojure Programming http://clojurebook.com > Training, Consulting & Contracting http://lambdanext.eu/ > -- -- 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: Simple Macros
guns writes: > On Tue 21 Jan 2014 at 07:33:43PM -0800, Alejandro Ciniglio wrote: > >> I was wondering if people had advice on when to write these sorts of >> macros vs. when to just use the trivial expansion in the code? (Or >> alternatively, what am I missing in this macro definition?) >> >> (defmacro go-loop >> "Like (go (loop ...))" >> [bindings & body] >> `(go (loop ~bindings ~@body))) > > go-loop needs to be a macro to capture the unevaluated let bindings: > > (go-loop [i 0] …) > > If go-loop were a function, this code would throw an error because i is > undefined. > > guns That's not the question - it was about: (go (loop [...] ...)) vs. (go-loop [...] ...) To answer it: (go (loop ...)) is a frequently used idiom, so someone decided that it's worth adding a trivial macro to make it look a bit cleaner. It's more or less the same for `with-open'.: You could just write the (let [...] (try ... (finally ...))) yourself, but it's much easier to understand the purpose when you read `with-open'. -- Moritz Ulrich pgpZyu7NHe8M4.pgp Description: PGP signature
Re: tools.cli and required arguments
On 22 January 2014 13:21, Alf Kristian Støyle wrote: > Thanks! That does explain it :) > > Would be nice to be able to specify that an option "must be specified in > every invocation" though. I think it would lead to better error messages, > e.g. if several "mandatory" options are forgotten, they will be shown at > once. That is a bit of a hassle when doing it yourself. Take a look at Cliopatra; they have added a :required flag to the option specification which does just what you want. I've had great success using Cliopatra to build Clojure command-line tools. https://github.com/runa-dev/cliopatra Ray. -- -- 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: ClojureScript integration with Emacs/Cider ?
Sorry about the late response, Gary. Would you mind taking the discussion over
to cider’s issue tracker? (I tend to miss emails, but I don’t miss issues :-)
).
The second change seems totally reasonable. I guess ritz’s complete middleware
returns the completion candidates in some odd format. Regarding the
tooling-session - why can’t the completions be generated using the tooling
session with ClojureScript (my knowledge of it is pretty basic). I guess this
was something to do with piggieback, right?
--
Cheers,
Bozhidar
On Saturday, January 18, 2014 at 8:56 PM, Gary Trakhman wrote:
> Bozhidar, I had to slightly modify cider-interaction.el to make autocomplete
> work for cljs.
>
> --- cider-interaction.el2014-01-18 13:51:28.082131609 -0500
> +++ /home/gary/.emacs.d/elpa/cider-0.4.0/cider-interaction.el 2014-01-17
> 19:06:45.872591834 -0500
> @@ -469,12 +469,12 @@
>(let ((strlst (plist-get
> (nrepl-send-request-sync
>(list "op" "complete"
> -"session" (nrepl-current-tooling-session)
> +"session" (nrepl-current-session)
> "ns" nrepl-buffer-ns
> "symbol" str))
> :value)))
> (when strlst
> - (car strlst
> + strlst)))
>
>
>
> Here's the current implementing code:
> https://github.com/gtrak/nrepl-complete/blob/master/src/nrepl_complete/middleware.clj
>
> Here's a screenshot: http://i.imgur.com/GmBJ6Fj.png
>
> It can't be implemented for cljs on the tooling session without sending the
> real session id over somehow, it seems this would be wasteful and not a good
> precedent for other middlewares.
>
> I'd appreciate your thoughts.
>
> I'm also curious what it would take to make the display pretty like ac-nrepl,
> which I had to disable.
>
> As soon as this stuff is finalized, I'll package everything up nice and make
> a first release.
>
>
>
> On Mon, Jan 13, 2014 at 10:21 AM, Gary Trakhman (mailto:gary.trakh...@gmail.com)> wrote:
> > Austin's lein-plugin already manipulates project middlewares, so that's an
> > easy target. Onward!
> >
> >
> > On Mon, Jan 13, 2014 at 10:10 AM, Bozhidar Batsov > (mailto:bozhi...@batsov.com)> wrote:
> > > Cider’s completion understands a `complete` op, so the middleware is the
> > > best approach if you ask me. The only reason that there’s also an eval
> > > based completion mechanism (the one used by default) is that
> > > clojure-complete is present as a REPLy (which is used by lein) dependency
> > > and many newcomers have absolutely no idea what an nREPL middleware is.
> > > Unfortunately it’s hard to balance initial easy of setup and good design
> > > decisions.
> > >
> > > --
> > > Cheers,
> > > Bozhidar
> > >
> > >
> > > On Monday, January 13, 2014 at 4:55 PM, Gary Trakhman wrote:
> > >
> > >
> > >
> > > > On talking to Chas,
> > > > https://github.com/cemerick/piggieback/issues/22
> > > >
> > > > it seems like the right approach is to reify ac-nrepl's use of eval
> > > > into a real "complete" op, and reimplement it to use that, then a
> > > > common middleware can either use clojure's environment
> > > > (clojure-complete) or piggieback's compiler state to implement the
> > > > appropriate auto-complete based on the active repl.
> > > >
> > > > The issue here is that clojure's auto-complete takes the JVM state as
> > > > an implicit parameter, whereas cljs-complete requires an 'env' arg that
> > > > has to come from somewhere (piggieback has a var that keeps track of
> > > > repl session state). Ac-nrepl shouldn't be able to eval code, that
> > > > means it's being coupled to the JVM state, which won't do for cljs or
> > > > other sorts of repls-on-repls.
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jan 13, 2014 at 9:03 AM, Gary Trakhman > > > (mailto:gary.trakh...@gmail.com)> wrote:
> > > > > I've released a cljs port of clojure-complete:
> > > > >
> > > > > Here's the mailing list announcement, also inlined.
> > > > >
> > > > > https://groups.google.com/forum/#!topic/clojurescript/Dt1s4laHFXc
> > > > > cljs-complete, A Clojure library designed to auto-complete
> > > > > clojurescript based on cljs compiler state.
> > > > >
> > > > > - With leiningen:
> > > > > [cljs-complete "0.1.0"]
> > > > >
> > > > > - Usage
> > > > >
> > > > > ;; env is pulled from cljs compiler state
> > > > > => (completions @cljs.env/*compiler* "al" 'cljs.core)
> > > > > ("alength" "alter-meta!")
> > > > >
> > > > > This is meant to hook into piggieback, that'll be the next thing I
> > > > > try. I hope I can get some help with the hairy emacs bits :-).
> > > > >
> > > > >
> > > > > On Tuesday, January 7, 2014 1:54:27 AM UTC-5, Bozhidar Batsov wrote:
> > > > > > I'm cider's maintainer. The problem with code completion for
> > > > > > ClojureScript is that the default mechanism
Re: random thought on #_
On 22/01/14 13:21, Christophe Grand wrote: #_ nests nicely: #_#_ comments out the next two expressions. Christophe WHAT?!!! I had no idea.I guess you do learn something new every day :) 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: MyType cannot be cast to MyType?
Take a look at Stuart's tools.namespace ( https://github.com/clojure/tools.namespace), although be wary of the protocol issue as it is something that is pointed out in the warnings section of that project. Mauricio -- -- 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: tools.cli and required arguments
On Wed 22 Jan 2014 at 02:21:51PM +0100, Alf Kristian Støyle wrote: > Would be nice to be able to specify that an option "must be specified > in every invocation" though. I think it would lead to better error > messages, e.g. if several "mandatory" options are forgotten, they will > be shown at once. That is a bit of a hassle when doing it yourself. > > Haven't looked too hard at the source though, but any chance of > contributing a patch to something like that? > > E.g. > [["-p" "--port PORT" "Port number" > :mandatory true]] I think the nicest thing about the original design of tools.cli is that it is conceptually a transformation of a default map of values into another map of values. Kind of like: (reduce option-rules default-map ARGV) ; => new-map From this POV, it makes more sense to me to assert the shape and value of `new-map` than to validate the membership of `ARGV`. I hope this makes sense. That said, there is definitely plenty of room for a more convenient framework on top of tools.cli. The recent reboot of the library was primarily aimed at increasing the flexibility of the argument tokenizer (e.g. supporting GNU option conventions) and that of summary generation. I purposefully made no attempts at adding anything fancier than that since the API change was already jarring. Also, in my experience with CLI libraries in other languages, programmers simply cannot agree on a single way to structure command line programs. Therefore, it my hope that `parse-opts` can at least serve as a common base between such libraries and for Clojurists interested in rolling their own.¹ If a clear favorite does emerge in the future, then that will be a great candidate for inclusion in tools.cli before an eventual 1.0 release. Cheers, guns ¹ What is unfortunate is that many libraries ship with their own ad-hoc parsers that use regular expressions or simple word matching. `parse-opts` tokenizes input before parsing so things like clumped options (`-abc`) are properly handled. pgp3eImZv75sZ.pgp Description: PGP signature
Re: tools.cli and required arguments
Ok, thanks for the reply guys :) Cheers, Alf On 22 January 2014 16:04, guns wrote: > On Wed 22 Jan 2014 at 02:21:51PM +0100, Alf Kristian Støyle wrote: > > > Would be nice to be able to specify that an option "must be specified > > in every invocation" though. I think it would lead to better error > > messages, e.g. if several "mandatory" options are forgotten, they will > > be shown at once. That is a bit of a hassle when doing it yourself. > > > > Haven't looked too hard at the source though, but any chance of > > contributing a patch to something like that? > > > > E.g. > > [["-p" "--port PORT" "Port number" > > :mandatory true]] > > I think the nicest thing about the original design of tools.cli is that > it is conceptually a transformation of a default map of values into > another map of values. Kind of like: > > (reduce option-rules default-map ARGV) ; => new-map > > From this POV, it makes more sense to me to assert the shape and value > of `new-map` than to validate the membership of `ARGV`. I hope this > makes sense. > > That said, there is definitely plenty of room for a more convenient > framework on top of tools.cli. The recent reboot of the library was > primarily aimed at increasing the flexibility of the argument tokenizer > (e.g. supporting GNU option conventions) and that of summary generation. > > I purposefully made no attempts at adding anything fancier than that > since the API change was already jarring. > > Also, in my experience with CLI libraries in other languages, > programmers simply cannot agree on a single way to structure command > line programs. Therefore, it my hope that `parse-opts` can at least > serve as a common base between such libraries and for Clojurists > interested in rolling their own.¹ > > If a clear favorite does emerge in the future, then that will be a great > candidate for inclusion in tools.cli before an eventual 1.0 release. > > Cheers, > guns > > ¹ What is unfortunate is that many libraries ship with their own > ad-hoc parsers that use regular expressions or simple word matching. > `parse-opts` tokenizes input before parsing so things like clumped > options (`-abc`) are properly handled. > -- -- 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: Security implications of code is data/data is code
Just joking :) There are a bunch of "golden rules" that violate on a regular basis for good reasons. With some satisfaction I have to confess. When you have a muti purpose tool in your hands that you can bend to almost any use it's hard to be restrained by taboos :) Luc P. > Sorry Luc P., you are right. > I meant that people wouldn't do that without a good reason, but it was not > what I wrote. > > On Wednesday, January 22, 2014 3:10:27 AM UTC-2, Luc wrote: > > > > Your last statement is incomplete. > > > > It all depends on trust. We do eval at > > runtime of code and data w/o edn > > but we know it comes from a secured > > source. > > > > Doing such thing from an unsecured > > alien source would "potentially" look insane. Lets not presume about > > the insanity of the designer w/o some deeper analysis :))) > > > > Luc P. > > > > > Hi Daniel, > > > > > > I'm not an expert in security but AFAIK this is not a problem. Every > > user > > > input is a string and you chose how to parse it. There is a edn reader > > that > > > is safe, but you can use specific parsers depending on the input. Of > > course > > > if you read and eval the string anything could happen, but nobody would > > do > > > that. > > > > > > Best, > > > mynomoto > > > > > > On Tuesday, January 21, 2014 10:22:11 PM UTC-2, Daniel Compton wrote: > > > > > > > > I've been thinking for a while about what the security implications > > are > > > > for a homoiconic language like Clojure where code is data and data is > > code. > > > > What protections do you have against malicious input being > > automatically > > > > evaluated by the reader? It seems like every user input would be a > > possible > > > > case of 'Clojure injection'. Is this an issue or am I missing > > something > > > > really obvious here? > > > > > > > > Thanks, Daniel. > > > > > > > > > > -- > > > -- > > > 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 clojure+u...@googlegroups.com . > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > > Luc Prefontaine> sent by ibisMail! > > > > -- > -- > 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. > -- Luc Prefontaine sent by ibisMail! -- -- 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: avoiding repetition in ns declarations
There's nothing built in to Clojure that does this, but you can easily define a function in one namespace that calls `require` for your other namespaces. Note that this may reduce readability of your source code if you forget exactly which namespaces that special function loads. -S -- -- 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: avoiding repetition in ns declarations
t x writes: > (ns foo.bar > ... > ... > ... ) > > There's basically 10 lines of require that I want as part of nearly _every_ > ns I declare is there a way to define some soft of alias / abbrevraviation > that is used in namespaces at will? > > For example: > > ## somewhere, in a magic file: > > (def require-standard > (require [ ... :as ... ]) > (require [ ... :as ... ]) > (require [ ... :as ... ]) > (require [ ... :as ... ])) > > (ns foo.bar > require-standard > ...) Not inside the ns macro, no. (ns foo.bar [:require [my-standard-requires]) (my-standard-requires/require-standard) I wrote a toy implementation of a ns form which was extensible in this way; the idea is that you could define a set of standard import or require statements in one place and reuse them. It might even be possible to store imports in a flat file, or to drag imports directly from a jar file. https://github.com/phillord/namespace-experiments There's been lots of discussion on the namespace macro here previously; to my mind the biggest problem is that it only does what it does, and nothing else. I routinely use a java library with 150 interfaces, and the inability to import * is beyond a PITA. If slamhound worked for me, it might help a bit, but I'd still end up with 150 imported classes in my ns form which isn't ideal. 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: avoiding repetition in ns declarations
Not addressing the main problem, but require takes multiple libspecs, so you can write (ns foo (:require [foo.bar :as bar] [foo.quux :as quux])) to avoid repeating the keyword, at least. :require in ns expands to a call to require-the-function, so the latter supports multiple libspecs too (and so require-standard could be written more succinctly). Cheers, Michał On 22 January 2014 08:15, t x wrote: > Hi, > > I have the following problem: > > (ns foo.bar > ... > ... > ... ) > > There's basically 10 lines of require that I want as part of nearly _every_ > ns I declare is there a way to define some soft of alias / abbrevraviation > that is used in namespaces at will? > > For example: > > ## somewhere, in a magic file: > > (def require-standard > (require [ ... :as ... ]) > (require [ ... :as ... ]) > (require [ ... :as ... ]) > (require [ ... :as ... ])) > > (ns foo.bar > require-standard > ...) > > 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/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: [ANN] clj.jdbc 0.1.0-beta5
Looks nice. Thanks for sharing. -- -- 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: core.async question - canceling thread
On Wed, Jan 22, 2014 at 2:51 AM, Jozef Wagner wrote: > You can put the computation into a future, and cancel the future after the > timeout. > I experimented with that, but it didn't seem to work. I suspect that "canceling a future" doesn't really do what I think it should do. I would appreciate some further clarity on how future cancellations work, and if someone thinks it applies here, would like to see concretely how to do it. -- -- 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: (go (loop [ ..] (try ... (catch ..)))) won't compile
hi, that's what I ended up doing :) 2014/1/22 James Reeves > Just pull the exception out of the loop logic: > > (go > (loop [xs (range 10)] >(if-let [x (first xs)] > (if (= ::error (try (println x) (catch Throwable t ::error))) >(recur (rest x)) > > - James > > > On 22 January 2014 11:05, László Török wrote: > >> Hi, >> >> I have a processing loop in a go block and I wanted to make sure that the >> processing continue with the next iteration if an exception is thrown. >> >> The following code doesn't seem to be accepted by the go macro: >> >> (go >> (loop [xs (range 10)] >>(when-let [x (first xs)] >> (try >>(println x) >>(recur (rest x)) >>(catch Throwable t nil) >> >> as it returns IllegalArgumentException No implementation of method: >> :emit-instruction of protocol: >> #'clojure.core.async.impl.ioc-macros/IEmittableInstruction found for class: >> clojure.core.async.impl.ioc_macros.Jmp >> >> I can't think of an alternative right now, any ideas? >> >> -- >> László Török >> >> -- >> -- >> 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. > -- László Török -- -- 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: core.async question - canceling thread
What is the task doing? If it is in a tight loop, it must check explicitly whether the interrupt flag is set and abort. If it is waiting on some resource, it will receive InterruptedException. Regards, Praki Prakash On Wed, Jan 22, 2014 at 11:20 AM, Mark Engelberg wrote: > On Wed, Jan 22, 2014 at 2:51 AM, Jozef Wagner wrote: > >> You can put the computation into a future, and cancel the future after >> the timeout. >> > > I experimented with that, but it didn't seem to work. I suspect that > "canceling a future" doesn't really do what I think it should do. I would > appreciate some further clarity on how future cancellations work, and if > someone thinks it applies here, would like to see concretely how to do it. > > -- > -- > 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: core.async question - canceling thread
I think the fib example is a good one in the sense that you are dealing with an already function that takes a long time, and isn't written as a loop. But in general, I want to solve the problem for an arbitrary long-running computation, for example, a call into a library that you don't control. One of the flagship examples for core.async is the example where you try two different engines to look something up, return the first one or timeout. Similarly, I want to try to solve a computational problem two different ways, and take the first solution or timeout. But of course, that only works if I can stop the computation from spinning CPU once I already have a solution (or timeout). Rewriting the underlying algorithms to constantly check for an interrupt is not an option. On Wed, Jan 22, 2014 at 11:31 AM, Praki Prakash wrote: > What is the task doing? If it is in a tight loop, it must check explicitly > whether the interrupt flag is set and abort. If it is waiting on some > resource, it will receive InterruptedException. > > Regards, > Praki Prakash > > > On Wed, Jan 22, 2014 at 11:20 AM, Mark Engelberg > wrote: > >> On Wed, Jan 22, 2014 at 2:51 AM, Jozef Wagner wrote: >> >>> You can put the computation into a future, and cancel the future after >>> the timeout. >>> >> >> I experimented with that, but it didn't seem to work. I suspect that >> "canceling a future" doesn't really do what I think it should do. I would >> appreciate some further clarity on how future cancellations work, and if >> someone thinks it applies here, would like to see concretely how to do it. >> >> -- >> -- >> 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. > -- -- 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: pre-conditions on >!
Jozef: (let [] (def c (async/chan 10)) (def cf (async/filter> #(if (even? %) % (assert false)) c)) (async/>!! cf 2) (try (async/>!! cf 1) (catch Exception e (println "caught exception"))) ) I believe filter> causes the exception to be thrown in a _different_ thread, not the thread that does the >!! On Wed, Jan 22, 2014 at 2:14 AM, Jozef Wagner wrote: > use filter> > > user=> (def c (chan 10)) > #'user/c > user=> (def cf (filter> #(if (even? %) % (throw > (IllegalArgumentException.))) c)) > #'user/cf > user=> (>!! cf 2) > nil > user=> (>!! cf 1) > IllegalArgumentException user/fn--4294 > (form-init9067455327434905636.clj:1) > user=> (>!! cf 4) > nil > user=> ( 2 > user=> ( 4 > > JW > > > On Wed, Jan 22, 2014 at 9:43 AM, t x wrote: > >> With apologies for spamming: >> >> in case anyone else wanted a solution to this problem: >> >> I believe the right layer is to wrap at the Channel layer, rather than >> the Buffer layer: for example: >> >> >> (ns test >> (:require >>#+clj [clojure.core.async.impl.protocols :as impl] >>#+cljs [cljs.core.async.impl.protocols :as impl] >>#+clj [clojure.core.async.impl.channels :as channels] >>#+cljs [cljs.core.async.impl.channels :as channels] >>#+clj [clojure.core.async :as async] >>#+cljs [cljs.core.async :as async])) >> >> (do >> >> (deftype CheckedChannel [chan check] >> impl/WritePort (put! [this val handler] >> (check val) >> (impl/put! chan val handler)) >> impl/ReadPort (take! [this handler] >> (impl/take! chan handler)) >> impl/Channel (close! [this] >>(impl/close! chan))) >> >> >> (defn cchan [n check] >> (CheckedChannel. (async/chan n) check)) >> >> >> (def oc (cchan 100 #(assert (even? % >> >> (println "Line 1") >> (async/alts!! [[oc 2]] :default :chan-full) >> (println "Line 2") >> (async/alts!! [[oc 3]] :default :chan-full) >> (println "Line 3") >> (async/alts!! [[oc 3]] :default :chan-full) >> (println "Line 4") >> >> ) >> >> >> >> On Wed, Jan 22, 2014 at 12:02 AM, t x wrote: >> >>> Consider the following attempt: >>> >>> for some reason, after the assertion fails, the main repl thread seems >>> to lock up >>> >>> Line 1 >>> Line 2 // after this, no more is printed >>> >>> >>> Question: what is causing the problem -- and how do I fix it? >>> >>> Thanks! >>> >>> === code === >>> >>> (ns test >>> (:require >>>#+clj [clojure.core.async.impl.protocols :as impl] >>>#+cljs [cljs.core.async.impl.protocols :as impl] >>>#+clj [clojure.core.async.impl.channels :as channels] >>>#+cljs [cljs.core.async.impl.channels :as channels] >>>#+clj [clojure.core.async :as async] >>>#+cljs [cljs.core.async :as async])) >>> >>> (do >>> >>> (deftype CheckedBuffer [buf check] >>> impl/Buffer >>> (full? [this] (impl/full? buf)) >>> (remove! [this] (impl/remove! buf)) >>> (add! [this itm] >>> (check itm) >>> (impl/add! buf itm))) >>> >>> >>> (defn cchan [n check] >>> (channels/chan (CheckedBuffer. (async/buffer n) check))) >>> >>> >>> (def oc (cchan 100 #(assert (even? % >>> >>> (println "Line 1") >>> (async/alts!! [[oc 2]] :default :chan-full) >>> (println "Line 2") >>> (async/alts!! [[oc 3]] :default :chan-full) >>> (println "Line 3") >>> (async/alts!! [[oc 3]] :default :chan-full) >>> (println "Line 4") >>> >>> ) >>> >>> >>> >>> On Tue, Jan 21, 2014 at 11:46 PM, Kelker Ryan wrote: >>> Can't you just test the value before placing a value in a channel? 22.01.2014, 16:27, "t x" : Hi, ## Question: For a channel, is it possible to put a pre-condition of sorts on a channel? For example: (let [chan (async/chan 100)] (set-pre-condition! chan even?) (put! chan 1) ;; exception thrown (>!! chan 3) ;; exception thrown ) ## Asides It's important that I want the exception to be thrown at the time of put, NOT at the time of take via >>> 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/groups/opt_out. --
Re: avoiding repetition in ns declarations
Staurt, Phillip: Correct me if I'm wrong, the main idea recommended is: (1) don't try to do it via (:require ...) inside of (ns ... ) (2) define a function, which calls (require ... ) [i.e. the function, outside of (ns ... )] Thus, the end solution ends up being: magic.cljx (defn load-standard-requires [] (require ... ) (require ... )) foo.cljx: (ns foo ... ) (magic/load-standard-requires) bar.cljx: (ns bar .. ) (magic/load-standard-requires) Can either of you confirm this is the main plan of attack you have suggested? (It seems reasonable, but I want to make sure I understand what you're recommending.) On Wed, Jan 22, 2014 at 9:33 AM, Michał Marczyk wrote: > Not addressing the main problem, but require takes multiple libspecs, > so you can write > > (ns foo > (:require [foo.bar :as bar] > [foo.quux :as quux])) > > to avoid repeating the keyword, at least. :require in ns expands to a > call to require-the-function, so the latter supports multiple libspecs > too (and so require-standard could be written more succinctly). > > Cheers, > Michał > > > On 22 January 2014 08:15, t x wrote: > > Hi, > > > > I have the following problem: > > > > (ns foo.bar > > ... > > ... > > ... ) > > > > There's basically 10 lines of require that I want as part of nearly > _every_ > > ns I declare is there a way to define some soft of alias / > abbrevraviation > > that is used in namespaces at will? > > > > For example: > > > > ## somewhere, in a magic file: > > > > (def require-standard > > (require [ ... :as ... ]) > > (require [ ... :as ... ]) > > (require [ ... :as ... ]) > > (require [ ... :as ... ])) > > > > (ns foo.bar > > require-standard > > ...) > > > > 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/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. > -- -- 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: core.async question - canceling thread
If you want to be able to control an arbitrary long-running function, a safe way is to run it in a separate process. That way you can safely terminate it anytime you want. Of course this opens up a lot of other issues :) On Wed, Jan 22, 2014 at 9:15 PM, Mark Engelberg wrote: > I think the fib example is a good one in the sense that you are dealing > with an already function that takes a long time, and isn't written as a > loop. > > But in general, I want to solve the problem for an arbitrary long-running > computation, for example, a call into a library that you don't control. > > One of the flagship examples for core.async is the example where you try > two different engines to look something up, return the first one or > timeout. Similarly, I want to try to solve a computational problem two > different ways, and take the first solution or timeout. But of course, > that only works if I can stop the computation from spinning CPU once I > already have a solution (or timeout). > > Rewriting the underlying algorithms to constantly check for an interrupt > is not an option. > > > > > On Wed, Jan 22, 2014 at 11:31 AM, Praki Prakash > wrote: > >> What is the task doing? If it is in a tight loop, it must check >> explicitly whether the interrupt flag is set and abort. If it is waiting on >> some resource, it will receive InterruptedException. >> >> Regards, >> Praki Prakash >> >> >> On Wed, Jan 22, 2014 at 11:20 AM, Mark Engelberg < >> mark.engelb...@gmail.com> wrote: >> >>> On Wed, Jan 22, 2014 at 2:51 AM, Jozef Wagner wrote: >>> You can put the computation into a future, and cancel the future after the timeout. >>> >>> I experimented with that, but it didn't seem to work. I suspect that >>> "canceling a future" doesn't really do what I think it should do. I would >>> appreciate some further clarity on how future cancellations work, and if >>> someone thinks it applies here, would like to see concretely how to do it. >>> >>> -- >>> -- >>> 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. >> > > -- > -- > 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: pre-conditions on >!
no, in the same thread. your code is wrong, assert never throws an exception. On Wed, Jan 22, 2014 at 9:17 PM, t x wrote: > Jozef: > > (let [] > > (def c (async/chan 10)) > > (def cf (async/filter> #(if (even? %) % > (assert false)) > c)) > > (async/>!! cf 2) > > (try > (async/>!! cf 1) > (catch Exception e > (println "caught exception"))) > > ) > > > I believe filter> causes the exception to be thrown in a _different_ > thread, not the thread that does the >!! > > > On Wed, Jan 22, 2014 at 2:14 AM, Jozef Wagner wrote: > >> use filter> >> >> user=> (def c (chan 10)) >> #'user/c >> user=> (def cf (filter> #(if (even? %) % (throw >> (IllegalArgumentException.))) c)) >> #'user/cf >> user=> (>!! cf 2) >> nil >> user=> (>!! cf 1) >> IllegalArgumentException user/fn--4294 >> (form-init9067455327434905636.clj:1) >> user=> (>!! cf 4) >> nil >> user=> (> 2 >> user=> (> 4 >> >> JW >> >> >> On Wed, Jan 22, 2014 at 9:43 AM, t x wrote: >> >>> With apologies for spamming: >>> >>> in case anyone else wanted a solution to this problem: >>> >>> I believe the right layer is to wrap at the Channel layer, rather than >>> the Buffer layer: for example: >>> >>> >>> (ns test >>> (:require >>>#+clj [clojure.core.async.impl.protocols :as impl] >>>#+cljs [cljs.core.async.impl.protocols :as impl] >>>#+clj [clojure.core.async.impl.channels :as channels] >>>#+cljs [cljs.core.async.impl.channels :as channels] >>>#+clj [clojure.core.async :as async] >>>#+cljs [cljs.core.async :as async])) >>> >>> (do >>> >>> (deftype CheckedChannel [chan check] >>> impl/WritePort (put! [this val handler] >>> (check val) >>> (impl/put! chan val handler)) >>> impl/ReadPort (take! [this handler] >>> (impl/take! chan handler)) >>> impl/Channel (close! [this] >>>(impl/close! chan))) >>> >>> >>> (defn cchan [n check] >>> (CheckedChannel. (async/chan n) check)) >>> >>> >>> (def oc (cchan 100 #(assert (even? % >>> >>> (println "Line 1") >>> (async/alts!! [[oc 2]] :default :chan-full) >>> (println "Line 2") >>> (async/alts!! [[oc 3]] :default :chan-full) >>> (println "Line 3") >>> (async/alts!! [[oc 3]] :default :chan-full) >>> (println "Line 4") >>> >>> ) >>> >>> >>> >>> On Wed, Jan 22, 2014 at 12:02 AM, t x wrote: >>> Consider the following attempt: for some reason, after the assertion fails, the main repl thread seems to lock up Line 1 Line 2 // after this, no more is printed Question: what is causing the problem -- and how do I fix it? Thanks! === code === (ns test (:require #+clj [clojure.core.async.impl.protocols :as impl] #+cljs [cljs.core.async.impl.protocols :as impl] #+clj [clojure.core.async.impl.channels :as channels] #+cljs [cljs.core.async.impl.channels :as channels] #+clj [clojure.core.async :as async] #+cljs [cljs.core.async :as async])) (do (deftype CheckedBuffer [buf check] impl/Buffer (full? [this] (impl/full? buf)) (remove! [this] (impl/remove! buf)) (add! [this itm] (check itm) (impl/add! buf itm))) (defn cchan [n check] (channels/chan (CheckedBuffer. (async/buffer n) check))) (def oc (cchan 100 #(assert (even? % (println "Line 1") (async/alts!! [[oc 2]] :default :chan-full) (println "Line 2") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 3") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 4") ) On Tue, Jan 21, 2014 at 11:46 PM, Kelker Ryan wrote: > Can't you just test the value before placing a value in a channel? > > 22.01.2014, 16:27, "t x" : > > Hi, > > > ## Question: > > For a channel, is it possible to put a pre-condition of sorts on a > channel? > > For example: > > (let [chan (async/chan 100)] > (set-pre-condition! chan even?) > (put! chan 1) ;; exception thrown > (>!! chan 3) ;; exception thrown > ) > > ## Asides > > It's important that I want the exception to be thrown at the time of > put, NOT at the time of take via 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/
Re: pre-conditions on >!
Damn it, you're right. :-) (try (async/>!! cf 1) (catch Throwable e (println "caught exception"))) catches it. On Wed, Jan 22, 2014 at 12:30 PM, Jozef Wagner wrote: > no, in the same thread. your code is wrong, assert never throws an > exception. > > > On Wed, Jan 22, 2014 at 9:17 PM, t x wrote: > >> Jozef: >> >> (let [] >> >> (def c (async/chan 10)) >> >> (def cf (async/filter> #(if (even? %) % >> (assert false)) >> c)) >> >> (async/>!! cf 2) >> >> (try >> (async/>!! cf 1) >> (catch Exception e >> (println "caught exception"))) >> >> ) >> >> >> I believe filter> causes the exception to be thrown in a _different_ >> thread, not the thread that does the >!! >> >> >> On Wed, Jan 22, 2014 at 2:14 AM, Jozef Wagner wrote: >> >>> use filter> >>> >>> user=> (def c (chan 10)) >>> #'user/c >>> user=> (def cf (filter> #(if (even? %) % (throw >>> (IllegalArgumentException.))) c)) >>> #'user/cf >>> user=> (>!! cf 2) >>> nil >>> user=> (>!! cf 1) >>> IllegalArgumentException user/fn--4294 >>> (form-init9067455327434905636.clj:1) >>> user=> (>!! cf 4) >>> nil >>> user=> (>> 2 >>> user=> (>> 4 >>> >>> JW >>> >>> >>> On Wed, Jan 22, 2014 at 9:43 AM, t x wrote: >>> With apologies for spamming: in case anyone else wanted a solution to this problem: I believe the right layer is to wrap at the Channel layer, rather than the Buffer layer: for example: (ns test (:require #+clj [clojure.core.async.impl.protocols :as impl] #+cljs [cljs.core.async.impl.protocols :as impl] #+clj [clojure.core.async.impl.channels :as channels] #+cljs [cljs.core.async.impl.channels :as channels] #+clj [clojure.core.async :as async] #+cljs [cljs.core.async :as async])) (do (deftype CheckedChannel [chan check] impl/WritePort (put! [this val handler] (check val) (impl/put! chan val handler)) impl/ReadPort (take! [this handler] (impl/take! chan handler)) impl/Channel (close! [this] (impl/close! chan))) (defn cchan [n check] (CheckedChannel. (async/chan n) check)) (def oc (cchan 100 #(assert (even? % (println "Line 1") (async/alts!! [[oc 2]] :default :chan-full) (println "Line 2") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 3") (async/alts!! [[oc 3]] :default :chan-full) (println "Line 4") ) On Wed, Jan 22, 2014 at 12:02 AM, t x wrote: > Consider the following attempt: > > for some reason, after the assertion fails, the main repl thread seems > to lock up > > Line 1 > Line 2 // after this, no more is printed > > > Question: what is causing the problem -- and how do I fix it? > > Thanks! > > === code === > > (ns test > (:require >#+clj [clojure.core.async.impl.protocols :as impl] >#+cljs [cljs.core.async.impl.protocols :as impl] >#+clj [clojure.core.async.impl.channels :as channels] >#+cljs [cljs.core.async.impl.channels :as channels] >#+clj [clojure.core.async :as async] >#+cljs [cljs.core.async :as async])) > > (do > > (deftype CheckedBuffer [buf check] > impl/Buffer > (full? [this] (impl/full? buf)) > (remove! [this] (impl/remove! buf)) > (add! [this itm] > (check itm) > (impl/add! buf itm))) > > > (defn cchan [n check] > (channels/chan (CheckedBuffer. (async/buffer n) check))) > > > (def oc (cchan 100 #(assert (even? % > > (println "Line 1") > (async/alts!! [[oc 2]] :default :chan-full) > (println "Line 2") > (async/alts!! [[oc 3]] :default :chan-full) > (println "Line 3") > (async/alts!! [[oc 3]] :default :chan-full) > (println "Line 4") > > ) > > > > On Tue, Jan 21, 2014 at 11:46 PM, Kelker Ryan > wrote: > >> Can't you just test the value before placing a value in a channel? >> >> 22.01.2014, 16:27, "t x" : >> >> Hi, >> >> >> ## Question: >> >> For a channel, is it possible to put a pre-condition of sorts on a >> channel? >> >> For example: >> >> (let [chan (async/chan 100)] >> (set-pre-condition! chan even?) >> (put! chan 1) ;; exception thrown >> (>!! chan 3) ;; exception thrown >> ) >> >> ## Asides >> >> It's important that I want the exception to be thrown at the time >> of put, NOT at the time of take via > Thanks! >> >> >> -- >> -- >> You received this message because you are subscribed to the Go
Reminder: Clojure/West CFP closes Friday!
If you're interested in submitting a talk to Clojure/West in San Francisco, March 24-26, time is running out! CFP: https://cognitect.wufoo.com/forms/clojurewest-2014-call-for-presentations/ Other useful links: Site: http://clojurewest.org Registration: https://www.eventbrite.com/e/clojurewest-2014-tickets-10153269703 Training: https://www.eventbrite.com/e/sf-clojure-training-intro-to-clojure-datomic-clojurescript-tickets-10165560465 Sponsorship: http://www.clojurewest.org/sponsorship-prospectus.pdf Alex -- -- 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: core.async question - canceling thread
Is there a convenient way within Clojure to launch a Clojure function or Java call in a separate process as opposed to a separate thread? Only way I know of is to literally shell out to the command prompt and launch a new executable. On Wed, Jan 22, 2014 at 12:19 PM, Jozef Wagner wrote: > If you want to be able to control an arbitrary long-running function, a > safe way is to run it in a separate process. That way you can safely > terminate it anytime you want. Of course this opens up a lot of other > issues :) > > > On Wed, Jan 22, 2014 at 9:15 PM, Mark Engelberg > wrote: > >> I think the fib example is a good one in the sense that you are dealing >> with an already function that takes a long time, and isn't written as a >> loop. >> >> But in general, I want to solve the problem for an arbitrary long-running >> computation, for example, a call into a library that you don't control. >> >> One of the flagship examples for core.async is the example where you try >> two different engines to look something up, return the first one or >> timeout. Similarly, I want to try to solve a computational problem two >> different ways, and take the first solution or timeout. But of course, >> that only works if I can stop the computation from spinning CPU once I >> already have a solution (or timeout). >> >> Rewriting the underlying algorithms to constantly check for an interrupt >> is not an option. >> >> >> >> >> On Wed, Jan 22, 2014 at 11:31 AM, Praki Prakash >> wrote: >> >>> What is the task doing? If it is in a tight loop, it must check >>> explicitly whether the interrupt flag is set and abort. If it is waiting on >>> some resource, it will receive InterruptedException. >>> >>> Regards, >>> Praki Prakash >>> >>> >>> On Wed, Jan 22, 2014 at 11:20 AM, Mark Engelberg < >>> mark.engelb...@gmail.com> wrote: >>> On Wed, Jan 22, 2014 at 2:51 AM, Jozef Wagner wrote: > You can put the computation into a future, and cancel the future after > the timeout. > I experimented with that, but it didn't seem to work. I suspect that "canceling a future" doesn't really do what I think it should do. I would appreciate some further clarity on how future cancellations work, and if someone thinks it applies here, would like to see concretely how to do it. -- -- 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. >>> >> >> -- >> -- >> 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.co
Re: avoiding repetition in ns declarations
On Wed, Jan 22, 2014 at 3:19 PM, t x wrote: > (defn load-standard-requires [] > (require ... ) > (require ... )) ... > Can either of you confirm this is the main plan of attack you have > suggested? > I don't actually *recommend* doing this. But it will work. My recommendation is to just repeat the :require directives in every namespace that needs them, or refactor your code to use fewer namespaces. -S -- -- 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: core.async question - canceling thread
On Thursday, 23 January 2014 02:37:43 UTC+5:30, puzzler wrote: > > Is there a convenient way within Clojure to launch a Clojure function or > Java call in a separate process as opposed to a separate thread? Only way > I know of is to literally shell out to the command prompt and launch a new > executable. > There's ProcessBuilder and Runtime.exec stuff, but it will have the JVM and Clojure initialization overhead anyway. http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html http://www.tutorialspoint.com/java/lang/runtime_exec_envp.htm Shantanu -- -- 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: core.async question - canceling thread
So I guess this gets back to my earlier question: when is it safe to terminate a thread? I know that I often hit Ctrl-C in the REPL to terminate a long running function, and I've never really worried about it screwing things up. On Wed, Jan 22, 2014 at 1:29 PM, Shantanu Kumar wrote: > > > On Thursday, 23 January 2014 02:37:43 UTC+5:30, puzzler wrote: >> >> Is there a convenient way within Clojure to launch a Clojure function or >> Java call in a separate process as opposed to a separate thread? Only way >> I know of is to literally shell out to the command prompt and launch a new >> executable. >> > > There's ProcessBuilder and Runtime.exec stuff, but it will have the JVM > and Clojure initialization overhead anyway. > > http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html > > http://www.tutorialspoint.com/java/lang/runtime_exec_envp.htm > > Shantanu > > -- > -- > 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: core.async question - canceling thread
It's not safe if the thread is holding any locks. It *may* also leak native resources if the thread is holding those, but native resources held by a heap-allocated Java object are supposed to be cleaned up by the finalizer if the object is GC'd, and I think Thread.stop properly removes that thread's locals as root set objects for GC, so native leaking would only happen if the thread held native resources directly in locals, which would only happen if it was executing a native method at the time of the stop. I don't know if the JVM/JNI has a safeguard against native leaks from threads being aborted while in native code, but I'd be mildly surprised if it did. Clojure threads will potentially be holding locks if they are using locking, dosync, swap!, or pretty much any of the concurrency primitives in Clojure. That *might* include Var lookups; I'm not sure (*dynamic* var lookups involve ThreadLocal, which might use locks under the hood). Many Java objects use locks somewhere under the hood as well -- certainly everything in j.u.concurrent is suspect in that regard (and therefore, swap! and many other Clojure concurrency primitives). I'd be very leery of playing around with Thread.stop in any circumstance more complicated than the thread's .run method is doing a pure math loop or something similar. If it touches Java libraries (outside of java.lang.String, java.math, and other value types) or uses Clojure primitives (and how is it supposed to join its results back into the bigger picture without them?) then it's dangerous. If it is a tight loop of math stuff then you can check for the interrupted flag. My recommendation? Stay far, far away from Thread.stop (and .suspend) and sprinkle Thread.sleep(1)s here and there in the math (maybe every certain number of iterations -- a millisecond is still a LONG time compared to primitive arithmetic ops). That should cause the thread to die with an InterruptedException if .interrupt is called on it. If the thread does any blocking I/O (or blocking core.async/j.u.concurrent stuff) with any frequency it should also go tits up pretty quickly if .interrupted. On Wed, Jan 22, 2014 at 4:31 PM, Mark Engelberg wrote: > So I guess this gets back to my earlier question: when is it safe to > terminate a thread? > > I know that I often hit Ctrl-C in the REPL to terminate a long running > function, and I've never really worried about it screwing things up. > > > On Wed, Jan 22, 2014 at 1:29 PM, Shantanu Kumar > wrote: > >> >> >> On Thursday, 23 January 2014 02:37:43 UTC+5:30, puzzler wrote: >>> >>> Is there a convenient way within Clojure to launch a Clojure function or >>> Java call in a separate process as opposed to a separate thread? Only way >>> I know of is to literally shell out to the command prompt and launch a new >>> executable. >>> >> >> There's ProcessBuilder and Runtime.exec stuff, but it will have the JVM >> and Clojure initialization overhead anyway. >> >> http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html >> >> http://www.tutorialspoint.com/java/lang/runtime_exec_envp.htm >> >> Shantanu >> >> -- >> -- >> 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. > -- -- 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/grou
Re: Profiling, VisualVM & random-pause
On Tue, Jan 21, 2014 at 1:50 PM, Yves Parès wrote: > 2) All my methods listed in the profiler are suffixed by .invoke. Is it > normal or is pathological of something (I haven't aot-compiled anything, I > don't know if it may have an impact here), like unnecessary reflection > calls? > That's normal. Your fns are compiled to implementors of clojure.lang.IFn, where you can see those invoke methods declared. For methods with "rest args", they'll subclass clojure.lang.RestFn, and in profilers you'll see RestFn#invoke calling your function's doInvoke method. -- -- 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: core.async question - canceling thread
For processes, there is a https://github.com/Raynes/conch but I haven't used it yet so I don't know how mature it is. On Wed, Jan 22, 2014 at 10:45 PM, Cedric Greevey wrote: > It's not safe if the thread is holding any locks. It *may* also leak > native resources if the thread is holding those, but native resources held > by a heap-allocated Java object are supposed to be cleaned up by the > finalizer if the object is GC'd, and I think Thread.stop properly removes > that thread's locals as root set objects for GC, so native leaking would > only happen if the thread held native resources directly in locals, which > would only happen if it was executing a native method at the time of the > stop. I don't know if the JVM/JNI has a safeguard against native leaks from > threads being aborted while in native code, but I'd be mildly surprised if > it did. > > Clojure threads will potentially be holding locks if they are using > locking, dosync, swap!, or pretty much any of the concurrency primitives in > Clojure. That *might* include Var lookups; I'm not sure (*dynamic* var > lookups involve ThreadLocal, which might use locks under the hood). Many > Java objects use locks somewhere under the hood as well -- certainly > everything in j.u.concurrent is suspect in that regard (and therefore, > swap! and many other Clojure concurrency primitives). > > I'd be very leery of playing around with Thread.stop in any circumstance > more complicated than the thread's .run method is doing a pure math loop or > something similar. If it touches Java libraries (outside of > java.lang.String, java.math, and other value types) or uses Clojure > primitives (and how is it supposed to join its results back into the bigger > picture without them?) then it's dangerous. If it is a tight loop of math > stuff then you can check for the interrupted flag. > > My recommendation? Stay far, far away from Thread.stop (and .suspend) and > sprinkle Thread.sleep(1)s here and there in the math (maybe every certain > number of iterations -- a millisecond is still a LONG time compared to > primitive arithmetic ops). That should cause the thread to die with an > InterruptedException if .interrupt is called on it. If the thread does any > blocking I/O (or blocking core.async/j.u.concurrent stuff) with any > frequency it should also go tits up pretty quickly if .interrupted. > > > On Wed, Jan 22, 2014 at 4:31 PM, Mark Engelberg > wrote: > >> So I guess this gets back to my earlier question: when is it safe to >> terminate a thread? >> >> I know that I often hit Ctrl-C in the REPL to terminate a long running >> function, and I've never really worried about it screwing things up. >> >> >> On Wed, Jan 22, 2014 at 1:29 PM, Shantanu Kumar > > wrote: >> >>> >>> >>> On Thursday, 23 January 2014 02:37:43 UTC+5:30, puzzler wrote: Is there a convenient way within Clojure to launch a Clojure function or Java call in a separate process as opposed to a separate thread? Only way I know of is to literally shell out to the command prompt and launch a new executable. >>> >>> There's ProcessBuilder and Runtime.exec stuff, but it will have the JVM >>> and Clojure initialization overhead anyway. >>> >>> http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html >>> >>> http://www.tutorialspoint.com/java/lang/runtime_exec_envp.htm >>> >>> Shantanu >>> >>> -- >>> -- >>> 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. >> > > -- > -- > You received this message because you are subscribed to the Google > G
Re: avoiding repetition in ns declarations
Maybe there should be a way to export stuff for transitive inclusion: (ns common-includes (:require [foo.core :refer [fooify] :export true]) ...) ... (ns my-ns (:require [common-includes :as c])) (defn bar [x] (c/fooify x 42)) On Wed, Jan 22, 2014 at 4:22 PM, Stuart Sierra wrote: > > On Wed, Jan 22, 2014 at 3:19 PM, t x wrote: > >> (defn load-standard-requires [] >> (require ... ) >> (require ... )) > > ... > > Can either of you confirm this is the main plan of attack you have >> suggested? >> > > > I don't actually *recommend* doing this. But it will work. > > My recommendation is to just repeat the :require directives in every > namespace that needs them, or refactor your code to use fewer namespaces. > > -S > > > -- > -- > 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: [ANN] Jig
Very impressive work! I was thinking of letting components not only implement the Lifecycle protocol but also a protocol that defines the functionality of the component. To give a simple example, there could be a jdbc component that establishes a connection on init etc., and which also implements a JDBCProtocol, e.g. functionalities such as provided by clojure.java.jdbc/query etc. Does that make sense? I ask because I didn't see any of the extensions or examples done in this way, and because there doesn't seem to be much code that supports fetching and manipulating the system map which seems to speak against this approach? Op vrijdag 11 oktober 2013 18:23:41 UTC+2 schreef Malcolm Sparks: > > A few months ago, Stuart Sierra blogged about the workflow he follows for > building Clojure applications. > > "One of the great pleasures of working with a dynamic language is being > able to build a system while simultaneously interacting with it. " > -- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded > > Since then I've been using this workflow for my own projects, and found it > to be amazingly effective. > > I've added some extra features, and the result is Jig, which builds on > Stuart's work in the following ways :- > >- Multiple components can each contribute to the 'system' map >- Components are started in dependency order >- Components are specified and configured in a config (edn) file >- Jig can host 'plain old' Leiningen projects - Jig will even 'reload' >them too e.g. if their project.clj dependencies change. >- Jig can host multiple projects simultaneously > > There's a small but growing list of optional re-usable components that > provide extra functionality :- > >- Pedestal services support. Jig provides the system map and 'url-for' >function in the service context. >- Nginx cache purging on reload >- Git pull prior reload >- Reload via JMX >- nREPL >- Stencil cache purging >- Firefox remote control support for 'browser refresh on reload' > > I know others are working on similar designs. I'd be interested to hear > what people think and whether this is useful. > > Thanks, > > Malcolm > > PS: Jig can be found here: https://github.com/juxt/jig > > > > -- -- 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: core.async question - canceling thread
I took a stab at it in pure core.async, unfortunately, it does not work; I would be curious if anyone could explain why. (use '[clojure.core.async :only [timeout 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: [ANN] Jig
(follow up) I just realized that another approach would be to hold the jdbc connection type implementing the JDBCProtocol in system under [:jdbc-component :db] or something, and then call the clojure.java.jdbc/query like functions on that. Anyway, I would be very happy to hear your comments on 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/groups/opt_out.
Re: Clojure development & laptop battery usage
Not true. More RAM, more power. If it hits swap, even more power. That has been my personal observation. On Monday, January 20, 2014 6:53:14 AM UTC+1, g vim wrote: > > On 20/01/2014 05:43, john walker wrote: > > The JVM hasn't been receiving the love it deserves lately! Fortunately, > > percent memory usage isn't going to have any effect on battery life > > until you hit swap. The resources you should consider are just activity > > on the cpu/gpu/disk. > > > > So yeah, it's light table. It's not its fault for being released ~2014. > > Ah, good. So RAM usage is irrelevant as far as battery life goes. I can > use Vim instead of LightTable so problem solved. > > gvim > -- -- 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.
cljs error handling
In clj, I can do something like:
(defn exception->error [exception]
{:tag :error
:object (ex-data exception)
:message (.getMessage exception)
:stack-trace (=> **
(.getStackTrace exception)
(filter #(.endsWith (.getFileName %) "clj") **)
(filter (fn [sf]
(let [cn (.getClassName sf)]
(not (or (.startsWith cn "clojure")
(.startsWith cn "cljx") **)
(map (fn [sf]
{:file-name (.getFileName sf)
:line-number (.getLineNumber sf)
:class-name (.getClassName sf)}) **))})
in cljs, what is the equiv I can do?
Basically, I want the message, object thrown (via ex-info), and a
stacktrace consisting of file names / line numbers.
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/groups/opt_out.
ANN Langohr 2.3.2 is released
Langohr [1] is a minimalistic, feature complete Clojure client for RabbitMQ. Release notes: http://blog.clojurewerkz.org/blog/2014/01/22/langohr-2-dot-3-2-is-released/ 1. http://clojurerabbitmq.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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.
core.async over websocket + cljs + clojure
Hi, I apologize for my vague question. Does anyone have a good example / blog / library for using the core.async abstraction across a websocket. * one side of the channel is in clojure land * other side of the channel is in cljs land * I promise that all messages can be encoded via pr-str and read via clojure.edn/read-string What I'm struggling with are matters of: * how to ensure data is not lost even when websocket disconects / reconnects * "naming" on client/server side to ensure messages go to right channels on both sides * issues I haven't even begun to imagine. Good news: * I control both sides: both the clj and cljs side, so any workable design is fine. 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/groups/opt_out.
Re: core.async over websocket + cljs + clojure
Ah, what good timing! David Pollak's project Plugh does this, essentially as an implementation detail. I spent some time with him today discussing this, as I want to use exactly this functionality in a project I'm building. The plan is for me to create a standalone project, based on the kernel of David's code, and enhance it to address a number of issues that he identified as needing work before the project could be used in production code, and then - hopefully - people will use it and provide additional integrations (such as core.async over a message hub to provide server-to-server operation, or core.async between browser client and server using more transmission methods than just web sockets). David's code addresses naming using a registry of channels, identified by GUIDs, on both sides. The web socket reconnection issue is one of the specific enhancements he identified that I plan to figure out and address. There are several others (including actually "GC'ing" closed channels on the other side of the address space divide). Sean On Jan 22, 2014, at 11:39 PM, t x wrote: > Hi, > > I apologize for my vague question. > > Does anyone have a good example / blog / library for using the core.async > abstraction across a websocket. > > * one side of the channel is in clojure land > * other side of the channel is in cljs land > > * I promise that all messages can be encoded via pr-str and read via > clojure.edn/read-string > > What I'm struggling with are matters of: > > * how to ensure data is not lost even when websocket disconects / reconnects > > * "naming" on client/server side to ensure messages go to right channels on > both sides > > * issues I haven't even begun to imagine. > > Good news: > > * I control both sides: both the clj and cljs side, so any workable design > is fine. > > 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/groups/opt_out. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
