Re: clojure.contrib.logging in "side-effect free" functions?
When the docs say not to use side-effects in a function or block of code,
they're not saying you can't use side-effects at all; it's just a reminder
that using side-effects can cause nasty surprises for one or more of these
reasons:
1. The code may be evaluated later than you expect.
2. It might not be evaluated at all.
3. It might be evaluated more than once (with dosync, for instance).
Even though logging is technically all about side-effects, logging is not
normally considered a side-effect because most programs don't rely on
logging for correctness. Also, it's totally possible to mix side-effects
with lazy streams in a sane way; the dorun and doall functions exist for
just that purpose. Just use your judgement and don't rely on side-effects
more than you have to.
On Thu, Jun 17, 2010 at 11:07 AM, William Wadsworth <
will.wadsworth...@gmail.com> wrote:
> Hi.
>
> I have just started learning Clojure and I am really enjoying
> myself. However, I am still getting to grips with the workings of its
> concurrency model, so please excuse me if my question seems too
> obvious.
>
> I have some code that reads data from a file, parses it and generates
> a CSV file. The flow is as follows:
>
>
> (use 'clojure.contrib.duck-streams)
> (use 'clojure.contrib.pprint)
>
> (defn parse-line [s]
> (cl-format nil "~{\"~A\"~^,~}" (into [] (.split s ";"
>
> (let [input-seq (for [line (read-lines "input.dat")]
> (parse-line line))]
> (write-lines "out.CSV" input-seq))
>
>
> Now the question:
>
> I would like to generate log entries for any malformed lines occurring
> in the input file. Once of the ways might be to do this in parse-line
> using clojure.contrib.logging as follows:
>
>
> (use 'clojure.contrib.logging)
>
> (defn parse-line [s]
> (let [cs (into [] (.split s ";"))]
>(if (= (count cs) 5)
> (cl-format nil "~{\"~A\"~^,~}" cs)
> (error "Incorrect number of columns in file."
>
>
> Since FOR returns a lazy sequence of the results, is this function
> safe? (Seeing that it is not side-effect free?)
>
> BTW:
> clojure.contrib.logging indicates that it can use an agent for
> logging. Is my assumption that invoking the logger (with or without
> an agent) within a function would still mean that the function has
> side-effects correct?
>
> Martin.
>
> --
> 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 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: Enhanced Primitive Support
On Sat, Jun 19, 2010 at 5:41 AM, Heinz N. Gies wrote: > Lets get away from the argument already cast and bring a new one. It is an > impossible situation that the literal 1 in one place has a different meaning > and behavior then in another place. This is in fact a show stopper, I'm > serious, this would be worst then java. > > (* 1 0.2) -> works fine > > but > > (loop [n 1 r 1](if (zero? n) r (recur (dec n) (* r 0.2 > > does not because the 1 there is not the 1 in the upper example, that is so > utterly wrong and horrible please think about it and think about how you'd > sell someone he has to know where a literal means what, I can guarantee you > this will keep many people from this wonderful language :(. I think you're misinterpreting what's going on here. There's no trickery with the type of 1 or r, and the expression (* r 0.2) will correctly return 0.2. The problem is that when 0.2 is passed into recur, it's coerced to a long, so it becomes 0. I do agree that the end result is unfortunate. I would be much happier if types of loop variables were based not just on their initializers, but also on the types of the arguments to recur. This would certainly result in some needless boxing, but the compiler would still be able to use primitives in a lot of cases. In particular, it could use primitives whenever the loop variable's new value is computed using only arithmetic operators or other :static functions that return primitives. The only possible harm would come from a very particular set of circumstances: (1) the loop variable is initialized with a primitive, (2) the performance of the loop depends in the variable being primitive, (3) a the compiler can't prove that the variable is re-bound with a primitive in a recur form, and (4) the actual value used to re-bind the variable is a boxed primitive of same type as the variable's initializer. If (1) is not true, the variable would not be primitive anyway; if (2) is not true, there may be some unnecessary boxing, but it doesn't hurt anything; if (3) is not true, the compiler can use primitives just as it does now; and if (4) is not true, the compiler is correctly forced to use a boxed type for the variable, whereas today it incorrectly tries to unbox the value, resulting in either a ClassCastException or a numeric conversion that silently loses precision. -- 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
How I learned to stop worrying and love condp
I was in to process of writing a rant against condp when I realized I had been thinking about it all wrong. Here is what I wanted at first: (defmacro casep [pred & clauses] `(condp #(%2 %1) ~pred ~...@clauses)) In other words, I want to be able to specify a unary predicate instead of a binary predicate and a single argument for it. I know from reading discussions on clojure-dev that the main advantage of condp over casep is that condp evaluates its first two arguments only once, and writing the same code using casep would could cause a lot of redundant evaluation. While I agree that condp earns its keep on that basis, I was still annoyed by the way condp calls the predicate you give it. I was hoping that condp could use an off-the-shelf function like apply, so I could get the effect of casep just by writing code like (condp apply my-unary-predicate ...); IMHO this is a perfectly readable idiom, but, alas, it's wrong; in place of apply, you have to use something like #(%2 %1), which looks far too Perlish for my taste. The saving grace of condp is that there are a lot more useful binary predicates than I had realized at first. When I went back and re-examined some of my code, I found you can do some cool things with condp that would not be possible if condp passed the arguments to the predicate in a different order: ;; Which value is less then 3? (condp < 3 x ... y ... z ...) ;; Which set contains x? (condp contains? x set-a ... set-b ... set-c ...) ;; Which object (represented as a map) is flagged as special? (condp get :special? map-a ... map-b ... map-c) ;; Which predicate does x satisfy? (condp apply [x] integer? ... string? ... nil? ...) Even a use case that's tailor-made for casep is not so bad if you're willing to turn the test expressions into functions: ;; Which item satisfies my-pred? (condp apply [my-pred] #(% item-a) ... #(% item-b) ... #(% item-c) ...) -- 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: mutating multiple java swing components
This is how I would write it: (doseq [[main fixed] (map vector mainTables fixedTables)] (println "Setting up table") (doto fixed (.setAutoCreateColumnsFromModel false) (.setModel (.getModel main)) (.setSelectionModel (.getSelectionModel main)) (.setFocusable false)) (let [column (.getColumn (.getColumnModel main) 0)] (println column) (.removeColumn (.getColumnModel main) column) (.addColumn (.getColumnModel fixed) column))) (println mainTables) (println fixedTables) On Fri, Apr 9, 2010 at 10:39 AM, Josh Stratton wrote: > Here's an example of trying to use "map" to bring the two tables > together together in the same scope. I'm doing this because the nth > element in one sequence correlates to its nth counterpart in the > second sequence. mainTables is a sequence of JTables and fixedTables > is an equally sized sequence of JTables. For some reason though it > appears that setupTable is never being called. Why is that? Is there > a better way to do this? > >(defn setupTable [main fixed] > (println "Setting up table") > (doto fixed >(.setAutoCreateColumnsFromModel false) >(.setModel (.getModel main)) >(.setSelectionModel (.getSelectionModel main)) >(.setFocusable false)) > > ; remove the first column from the main table and add it to > the > fixed table > (let [column (.getColumn (.getColumnModel main) 0)] > (println column) > (.removeColumn (.getColumnModel main) column) > (.addColumn (.getColumnModel fixed) column) > ) > ) > >(map (fn [main fixed] (setupTable main fixed)) mainTables > fixedTables) >(println mainTables) >(println fixedTables) > > On Thu, Apr 8, 2010 at 4:30 PM, Josh Stratton > wrote: > >> It sounds like the doseq is the macro you're looking for, e.g. > >> (doseq [c my-components] > >> (.setVisible c true)) > > > > That works once I've done the initial mapping and I want to set > > values, but what if I still want the two components--the old and new > > one--in the same scope at the same time? > > > > In python, one might do something like this: > > > > for i,component in oldComponents: > > newComponents[i].setValue(oldComponents[i]) > > if (oldComponents[i].getAttribute() > 5): > > newComponents[i].setAttribute(0) > > else: > > newComponents[i].setAttribute(1) > > > > I guess I was just trying to avoid using index notation. Would zip be > > the appropriate solution here, where I can set the two lists together > > in tuples of old and new? > > > -- 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: mutating multiple java swing components
It sounds like the doseq is the macro you're looking for, e.g. (doseq [c my-components] (.setVisible c true)) On Thu, Apr 8, 2010 at 5:07 PM, strattonbrazil wrote: > What's the function to call java code on multiple java components? If > I have a sequence of Java swing components and I want to go through > and set the same properties for each one, I would use a for loop in > Java. If I were using immutable structs in clojure, I'd just a map > and just change the keys I'd want to change. Should I still use a map > if I don't care about what I'm returning and I just want to call set* > methods on each component? > > -- > 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 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: How to efficiently import large array of doubles from file?
The overhead of using a Clojure vector will be a little more than 2.5x on a 32-bit Sun JVM, because each Java object has an 8-byte overhead, and storing references to those objects in a Clojure vector will use just over 4 bytes per object. I'm not sure what the figure would be for a 64-bit JVM, but I would expect it to be substantially worse, possibly as much as 5x. On Mon, Feb 22, 2010 at 4:30 AM, Johann Kraus wrote: > Hi everyone, > > I need some help for loading in large data from file. For instance, > I'm trying to load from a text file one line of 5000 double values > (separated by comma). Having 8 byte per double I would assume this to > fit into ~400MB of memory, at least when using a java double array > internally. However, when loading with read-lines from > clojure.contrib.duck-streams and (map #(Double/parseDouble %) (.split > line ",")) clojure requires several GB of RAM. Any suggestions for how > to get this down to 400MB? And what would be the overhead if reading > into a clojure vector, which I really would prefer to using java > arrays? > > Thanks > Johann > > -- > 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 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: newbie question: Please help me stop creating constructors
Right, nesting everything inside a single function makes it impossible to
unit test the inner functions--they don't even have names in the global
scope! In retrospect, I think the solution I posted is more cute than it is
practical. Passing around a map of intermediate values seems to be the
winner all around, but it still seems a little odd to me. Idiomatic Clojure
code manipulates maps far more than I've seen in any other language.
On Fri, Feb 19, 2010 at 11:30 AM, Yaron wrote:
> With this approach how would I test the individual functions defined
> inside of the let? Wouldn't they be invisible to me and the test
> framework which would only see "sell-or-rent"?
>
> On Feb 18, 4:27 pm, John Williams wrote:
> > I'm no Clojure guru myself, but one approach you may want to consider is
> > nest all your auxiliary functions inside the main function, and use
> ordinary
> > let-bindings the same way you've been trying to use global bindings:
> >
> > (defn sell-or-rent [{:keys [supplied-1 supplied-2]}]
> > (let [derived-1 (+ 1 supplied-1)
> > derived-2 (* 2 supplied-2)]
> > (letfn [(f [x y z] ...)
> > (g [x] ...)]
> > ...)))
> >
> > This has the disadvantage of indenting all your helper functions much
> more
> > than they would be otherwise, but it gets the job done without any messy
> > global variables or thunks. If you want to expose more functions than
> just
> > sell-or-rent, you could write some very OO-flavored code:
> >
> > ;; Define a function to create objects.
> > (defn pseudo-constructor [{:keys [supplied-1 supplied-2]}]
> > (let [member-var-1 (+ 1 supplied-1)
> > member-var-2 (* 2 supplied-2)]
> > (letfn [(private-method-1 [] "priv1")
> > (private-method-2 [] "priv2")]
> > {:public-method-1 (fn [x y z] "pub1")
> >:public-method-2 (fn [x y] "pub2")})))
> >
> > ;; Use the object.
> > (let [obj (pseudo-constructor {:supplied-1 1
> >:supplied-2 2})]
> > (println ((:public-method-1 obj) "x" "y" "z"))
> > (println ((:public-method-2 obj) "x" "y")))
> >
> > --jw
> >
> > On Mon, Feb 15, 2010 at 11:24 AM, Yaron wrote:
> > > I am writing a calculator to figure out if I should sell or rent my
> > > home using Clojure. This is my first Clojure program so I'm about as
> > > wet behind the ears as it gets. So far everything is actually going
> > > really well (reminds me of the fun I had with Scheme in college) but
> > > for one thing. My calculator needs 30+ arguments from the user in
> > > order to run. Furthermore I have a bunch of secondary values that are
> > > derived from the arguments the user submits.
> >
> > > So imagine the user submits a value A. I will have a value B whose
> > > definition will be something like (+ 1 A) (yes, more complex in
> > > reality, but you get the idea).
> >
> > > If I were back in Java or C# I would define a class, submit A (and
> > > it's 29+ friends) in the constructor and then create a property on the
> > > class B.
> >
> > > In Clojure I have taken a different approach. I first create (def *A*
> > > 3) where 3 is a completely bogus value I just made up. Then at run
> > > time I use bindings to re-bind A to the actual value the user passed
> > > in.
> >
> > > But my problem is, what to do about B? I thought of doing something
> > > like (def *B* 3) and then in the binding passing in a function like
> > > (defn B-Gen [] (+ *A* 1)) to create a new binding to B but I quickly
> > > realized this would be a bug inducing nightmare. If I forget to
> > > include one of the derived values in the binding or put them in the
> > > wrong order then I would get the wrong value.
> >
> > > So what I currently do is:
> > > (def *A* 3) ; A bogus value that will later be rebound
> > > (defn B [] (+ *A* 3))
> >
> > > The good news is, that this works and doesn't require any book
> > > keeping.
> >
> > > The bad news is that it's ugly. If I want to do something trivial like
> > > divide B by 2 I have to call B as a function(/ (B) 2) instead of the
> > > more natural (/ B 2). And of course this approach is pretty
> > > unfortunate from a performance perspective as I'm constantly having to
> > > recalculate what are effectively static values. Yes, I could use
> > > m
Re: newbie question: Please help me stop creating constructors
I'm no Clojure guru myself, but one approach you may want to consider is
nest all your auxiliary functions inside the main function, and use ordinary
let-bindings the same way you've been trying to use global bindings:
(defn sell-or-rent [{:keys [supplied-1 supplied-2]}]
(let [derived-1 (+ 1 supplied-1)
derived-2 (* 2 supplied-2)]
(letfn [(f [x y z] ...)
(g [x] ...)]
...)))
This has the disadvantage of indenting all your helper functions much more
than they would be otherwise, but it gets the job done without any messy
global variables or thunks. If you want to expose more functions than just
sell-or-rent, you could write some very OO-flavored code:
;; Define a function to create objects.
(defn pseudo-constructor [{:keys [supplied-1 supplied-2]}]
(let [member-var-1 (+ 1 supplied-1)
member-var-2 (* 2 supplied-2)]
(letfn [(private-method-1 [] "priv1")
(private-method-2 [] "priv2")]
{:public-method-1 (fn [x y z] "pub1")
:public-method-2 (fn [x y] "pub2")})))
;; Use the object.
(let [obj (pseudo-constructor {:supplied-1 1
:supplied-2 2})]
(println ((:public-method-1 obj) "x" "y" "z"))
(println ((:public-method-2 obj) "x" "y")))
--jw
On Mon, Feb 15, 2010 at 11:24 AM, Yaron wrote:
> I am writing a calculator to figure out if I should sell or rent my
> home using Clojure. This is my first Clojure program so I'm about as
> wet behind the ears as it gets. So far everything is actually going
> really well (reminds me of the fun I had with Scheme in college) but
> for one thing. My calculator needs 30+ arguments from the user in
> order to run. Furthermore I have a bunch of secondary values that are
> derived from the arguments the user submits.
>
> So imagine the user submits a value A. I will have a value B whose
> definition will be something like (+ 1 A) (yes, more complex in
> reality, but you get the idea).
>
> If I were back in Java or C# I would define a class, submit A (and
> it's 29+ friends) in the constructor and then create a property on the
> class B.
>
> In Clojure I have taken a different approach. I first create (def *A*
> 3) where 3 is a completely bogus value I just made up. Then at run
> time I use bindings to re-bind A to the actual value the user passed
> in.
>
> But my problem is, what to do about B? I thought of doing something
> like (def *B* 3) and then in the binding passing in a function like
> (defn B-Gen [] (+ *A* 1)) to create a new binding to B but I quickly
> realized this would be a bug inducing nightmare. If I forget to
> include one of the derived values in the binding or put them in the
> wrong order then I would get the wrong value.
>
> So what I currently do is:
> (def *A* 3) ; A bogus value that will later be rebound
> (defn B [] (+ *A* 3))
>
> The good news is, that this works and doesn't require any book
> keeping.
>
> The bad news is that it's ugly. If I want to do something trivial like
> divide B by 2 I have to call B as a function(/ (B) 2) instead of the
> more natural (/ B 2). And of course this approach is pretty
> unfortunate from a performance perspective as I'm constantly having to
> recalculate what are effectively static values. Yes, I could use
> memoization but many of these values are pretty trivial (usually just
> algebra equations) and I suspect the overhead of memoization exceeds
> the perf improvement.
>
> But in any case the whole approach of having to take what really are
> static values and turn them into functions feels really hacky. So my
> guess is that I'm thinking about this problem the wrong way. I'm stuck
> in my old imperative/OO constructor world.
>
> What's the right way to think about primary values that will be
> rebound (once) that then have dependent values that need to be
> recalculated when that rebinding happens?
>
> Thanks,
>
> Yaron
>
> --
> 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 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: error reporting for macro expansion
I'm concerned specifically about exceptions that occur during macro expansion. As often as not, these exceptions are the result of calling the macro with incorrect arguments rather than any problem in the macro itself, but the stack trace doesn't contain enough information to locate the offending macro call. For instance, the stack trace I posted reports macro-fail.clj line 0 as the ultimate source of the problem, even though the macro is called on line 3. I've done some more tests using the 1.0 release as well as the latest head from git, and in both versions, the stack trace contains the name of the file where the macro is called, but the line number is always 0. Since the file name is correct, I think my comments about hacking the reader were off-base, but there is definitely a problem with reporting the correct line number. On Mon, Feb 8, 2010 at 2:08 PM, Michał Marczyk wrote: > On 8 February 2010 20:11, John R. Williams > wrote: > > ;; macro-fail.clj > > (defmacro broken [] (/ 0 0)) > > (broken) > > [ ... ] > > As you can see, line 3, where the macro is used, appears nowhere in > > the stack trace. > > That's because execution never reaches this point, because the (/ 0 0) > bit gets executed at macro expansion time. You'd have to syntax-quote > it to fail at runtime: > > (defmacro broken [] `(/ 0 0)) > > (A regular quote would probably also do.) > > Also, note the user$broken ... line in your stack trace -- it does > contain a useful indication of the source of the problem. > > Sincerely, > Michał > > -- > 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 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
