a macro to debug the let form
Hello everybody, I was trying to learn to write clojure macros and the code is posted here in the following link https://gist.github.com/715047 There are basically three macros 1. with-seperator - a zero argument macro and is supposed to just draw a line to indicate beginning and ending of the execution of the body. 2. display-local-bindings - a function to print the local bindings in the lexical scope where the macro is called 3. letd - a helper macro to print the values of all the bindings followed by printing of the local bindings using display-local-bindings The letd macro as posted works as expected but without the seperation line . It is supposed to print the seperation line when I uncomment line 14 and comment line 15 but some how this is causing the &env variable automatically passed with every macro to be nil display-local-binding .. but the I feel it is not the case .. can somebody help me understand this. This was an exercise to learn macro writing than to writing a letd debugging helper function.. Thanks, Sunil. -- 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: every-nth
Hi, On 25 Nov., 05:06, Sunil S Nandihalli wrote: > (defn every-nth [n coll] > (letfn [(evn [cn s] > (when s > (if (= cn 1) > (lazy-seq (cons (first s) (evn n (next s > (evn (dec cn) (next s)] > (evn n coll))) Since you want to learn how lazy-seq works here some feedback. * Make the lazy-seq the outer-most part of your function to allow as much laziness as possible. There other opinions out there about the placement of lazy-seq, but there are also a lot of people complaining about eg. a filter doing an expensive predicate call because the input sequence is not as lazy as it could be. By placing lazy-seq outermost you leave the decision to them when to realize an element. * You should call seq on coll before passing it to evn. Think of [] as input. It will be truthy in the when check and we do some unnecessary loop, where we actually could short circuit. * Don't call next in the true branch of the if. It realises an element of the input sequence where it is not necessary. Use rest. * Don't call evn in the false branch of the if. It will be true recursion and might blow the stack for large n. You Use recur. Here is the version I would write in this case. (defn every-nth [n coll] (let [step (fn step [s] (lazy-seq (loop [s (seq s) cnt n] (when s (if (= cnt 1) (cons (first s) (step (rest s))) (recur (next s) (dec cnt)))] (step coll))) * lazy-seq is outer-most. * The recur is turned into a loop to avoid stacking lazy-seq on lazy-seq. * The input sequence is only realised inside the lazy-seq. Also in the true branch we use rest to defer realisation of the next seq step. In the false branch we use next, because we need the value anyway. As a rule of thumb: write your generating function with "normal" recursion first. Then simply wrap a lazy-seq around it. Hope that helps. Sincerely Meikel -- 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: ANN: ClojureQL 1.0.0 finally released as public beta
Hi Brenton, Yes the OFFSET/LIMIT syntax differs from backend to backend. However in some instances (like MySQL/PostgreSQL) they have ensured compatability so that the same statement will run on several DBs although the syntax might not be considered 'native'. For something like Oracle there actually isnt a syntax for LIMIT so instead they do something like SELECT * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber, columns FROM tablename ) WHERE rownumber <= n But as you can see it would be trivial to express this in terms of ClojureQL: (defn oracle-take [tname limit] (-> (table (str "(SELECT ROW_NUMBER() OVER (ORDER BY key ASC)" " AS rownumber,columns" " FROM " (to-tablename tname) ")")) (select (where (<= :rownumber limit))) (project ["*"]))) (to-sql (oracle-table :users 10)) ["SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber,columns FROM users) WHERE (rownumber <= ?)" 10] >From the outset it has been my ambition to make ClojureQL extremely composable and as far as possible allow users to directly insert strings into the query to allow for backend specific customization. The entire design-plan of this customization is not yet thought out so input is welcomed. To me, flexibility and leaving with the power to the user is the key to wide adoption across various backends. Lau On Nov 24, 11:42 pm, Brenton wrote: > > ClojureQL does not take the backend in to account. This is the one > > feature from the old CQL that I didn't want to carry over because it > > would be impossible for me to cater to all backends. If you hit > > specific problems, let me know and I'll see what we can do. > > > We adhere to SQL92 and test everything on MySQL and Postgres. If > > you're in a situation where thats not good enough, its always possible > > to supply part of your expression as a string. > > Lau > > Off the top of my head, I know that the LIMIT syntax for SQL Server is > totally different. A lot of the apps that I write end up getting > deployed using Oracle and SQL Server. If you plan for CQL to be widely > used I think you will need to take backends into account. You don't > need to implement them all yourself, but you should provide a way so > that others can implement them when they need to. > > Brenton -- 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: every-nth
On 25 November 2010 16:56, Ken Wesson wrote: > Eh. This is weird. It seems that (partition n coll) drops the last > part of coll if it's not a multiple of n in size; e.g. (partition 3 [1 > 2 3 4 5]) yields ((1 2 3)) and not ((1 2 3) (4 5)). (partition n n [] > coll) does do that though. > See also partition-all: user=> (partition-all 3 [1 2 3 4 5]) ((1 2 3) (4 5)) Regards, Stuart -- 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: distinguishing the symbols generated by gensym from those that were part of the code
On Thu, Nov 25, 2010 at 1:06 AM, Sunil S Nandihalli
wrote:
> Hello everybody,
> Is there a function which can tell me if a particular symbol was generated
> by gensym or was present in the code?
> Sunil.
I don't think so.
On the other hand:
(def my-gensyms (atom #{}))
(defn my-gensym
([]
(let [s (gensym)]
(swap! my-gensyms conj s)
s))
([prefix]
(let [s (gensym prefix)]
(swap! my-gensyms conj s)
s)))
(defn is-my-gensym? [s]
(contains? @my-gensyms s))
will let you create gensyms with my-gensym and later check is a symbol
was created with is-my-gensym?.
Warning: a hashset grows in memory for every gensym created with my-gensym.
--
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: every-nth
Thanks everybody, Clojure community is awesome .. and also I just wanted to learn to use lazy-seq that is why it was written in the way I showed you all. Thanks again. Sunil. On Thu, Nov 25, 2010 at 11:26 AM, Ken Wesson wrote: > Eh. This is weird. It seems that (partition n coll) drops the last > part of coll if it's not a multiple of n in size; e.g. (partition 3 [1 > 2 3 4 5]) yields ((1 2 3)) and not ((1 2 3) (4 5)). (partition n n [] > coll) does do that though. > > OTOH, > > (mapcat identity (partition 1 n coll)) > (apply concat (partition 1 n coll)) > (keep-indexed (fn [i x] (if (= 0 (rem i n)) x)) coll) > (map first (partition-all n coll)) > (mapcat identity (partition-all n coll)) > (apply concat (partition-all n coll)) > > and the winner is: > > (flatten (partition 1 n coll)) > > Only 30 characters. :) > > -- > 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
distinguishing the symbols generated by gensym from those that were part of the code
Hello everybody, Is there a function which can tell me if a particular symbol was generated by gensym or was present in the code? Sunil. -- 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: every-nth
Eh. This is weird. It seems that (partition n coll) drops the last part of coll if it's not a multiple of n in size; e.g. (partition 3 [1 2 3 4 5]) yields ((1 2 3)) and not ((1 2 3) (4 5)). (partition n n [] coll) does do that though. OTOH, (mapcat identity (partition 1 n coll)) (apply concat (partition 1 n coll)) (keep-indexed (fn [i x] (if (= 0 (rem i n)) x)) coll) (map first (partition-all n coll)) (mapcat identity (partition-all n coll)) (apply concat (partition-all n coll)) and the winner is: (flatten (partition 1 n coll)) Only 30 characters. :) -- 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: every-nth
I stand corrected. I thought it required another arg. Yours was right already. On Nov 24, 2010, at 11:53 PM, David Sletten wrote: > > On Nov 24, 2010, at 11:45 PM, Ken Wesson wrote: > >> On Wed, Nov 24, 2010 at 11:11 PM, Baishampayan Ghose >> wrote: I just needed a function for every-nth element in a sequence.. I know it can be trivially implemented as .. (defn every-nth [n coll] (letfn [(evn [cn s] (when s (if (= cn 1) (lazy-seq (cons (first s) (evn n (next s (evn (dec cn) (next s)] (evn n coll))) But I remember seeing inbuilt function .. can anybody help me find it? >>> >>> take-nth should do the job - >>> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/take-nth >> >> And it can be even more trivially implemented as (map first (partition >> n coll)). :) >> > > (map first (partition 1 n coll)) > > >> -- >> 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 -- 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: every-nth
On Wed, Nov 24, 2010 at 11:53 PM, David Sletten wrote: > > On Nov 24, 2010, at 11:45 PM, Ken Wesson wrote: > >> On Wed, Nov 24, 2010 at 11:11 PM, Baishampayan Ghose >> wrote: I just needed a function for every-nth element in a sequence.. I know it can be trivially implemented as .. (defn every-nth [n coll] (letfn [(evn [cn s] (when s (if (= cn 1) (lazy-seq (cons (first s) (evn n (next s (evn (dec cn) (next s)] (evn n coll))) But I remember seeing inbuilt function .. can anybody help me find it? >>> >>> take-nth should do the job - >>> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/take-nth >> >> And it can be even more trivially implemented as (map first (partition >> n coll)). :) > > (map first (partition 1 n coll)) Yes, that seems to work too, but it's also two characters longer. :) -- 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: every-nth
On Nov 24, 2010, at 11:45 PM, Ken Wesson wrote: > On Wed, Nov 24, 2010 at 11:11 PM, Baishampayan Ghose > wrote: >>> I just needed a function for every-nth element in a sequence.. I know it >>> can be trivially implemented as .. >>> (defn every-nth [n coll] >>> (letfn [(evn [cn s] >>> (when s >>> (if (= cn 1) >>> (lazy-seq (cons (first s) (evn n (next s >>> (evn (dec cn) (next s)] >>> (evn n coll))) >>> But I remember seeing inbuilt function .. can anybody help me find it? >> >> take-nth should do the job - >> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/take-nth > > And it can be even more trivially implemented as (map first (partition > n coll)). :) > (map first (partition 1 n coll)) > -- > 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: every-nth
On Wed, Nov 24, 2010 at 11:11 PM, Baishampayan Ghose wrote: >> I just needed a function for every-nth element in a sequence.. I know it >> can be trivially implemented as .. >> (defn every-nth [n coll] >> (letfn [(evn [cn s] >> (when s >> (if (= cn 1) >> (lazy-seq (cons (first s) (evn n (next s >> (evn (dec cn) (next s)] >> (evn n coll))) >> But I remember seeing inbuilt function .. can anybody help me find it? > > take-nth should do the job - > http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/take-nth And it can be even more trivially implemented as (map first (partition n coll)). :) -- 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: every-nth
> I just needed a function for every-nth element in a sequence.. I know it > can be trivially implemented as .. > (defn every-nth [n coll] > (letfn [(evn [cn s] > (when s > (if (= cn 1) > (lazy-seq (cons (first s) (evn n (next s > (evn (dec cn) (next s)] > (evn n coll))) > But I remember seeing inbuilt function .. can anybody help me find it? take-nth should do the job - http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/take-nth Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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
every-nth
Hello everybody, I just needed a function for every-nth element in a sequence.. I know it can be trivially implemented as .. (defn every-nth [n coll] (letfn [(evn [cn s] (when s (if (= cn 1) (lazy-seq (cons (first s) (evn n (next s (evn (dec cn) (next s)] (evn n coll))) But I remember seeing inbuilt function .. can anybody help me find it? Sunil. -- 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: discussing Clojure with non-CS types
I must admit that even though I love Clojure and use it daily for many things, I don't like using it very much for my research (machine learning) which involves a lot of number crunching. The main reasons being: Numerical software involves a lot of array indexing, and loops, and not much else. Clojure's functional data structures are elegant, but are not quite fast enough for heavy numerical processing so I still need to use native arrays. And if all I'm using is native arrays, the java syntax for arrays is much easier on the eyes than a bunch of nested s-exps. The other reason is that Clojure emphasizes functional programming and discourages mutation. This is fine, as I believe well-written code is usually functional anyway. The problem is that bad code is usually easier to write in an imperative way than a functional way, and the ability to write bad code is important I think. It's usually a lot quicker to whip up a mutative hack than think through the problem and factor out components and be functional about the whole thing. And usually, in the very very early stages of programming something, when you don't clearly know what it is you're programming, it's nice to be able to whip out a quick and dirty mutative hack. And then make it nice and elegant and functional later on, but Clojure makes doing that difficult for me. -Patrick On Nov 24, 3:12 pm, Mike Meyer wrote: > On Wed, 24 Nov 2010 09:20:49 -0800 (PST) > > cej38 wrote: > > I am a physicist. I have been using Clojure full time for the last > > year and a half. The reasons that Rich (and most other Clojure > > evangelists) give for using Clojure, are all nice and good, but they > > point to what computer scientists think about. If you want scientists > > and engineers to think about switching to Clojure, you need to talk to > > the concerns that they have. Of course, there is some overlap. > > The thing is, I'm not sure it's the best choice for such people. At > least, not yet. The LISP-like syntax means you have to explain the > code if you publish it, a problem that some alternatives - which have > most of your advantages - don't have. Look at Python, a descendant of > ABC, which was designed for teaching/prototyping. It's been described > as "executable pseudo-code". > > > Here are some reasons that I would give for using clojure: > > 1. Most data analysis gets done by writing little programs that do > > certain tasks. When writing in Fortran I more or less have to write a > > new program to do each task. In clojure, I might have to write a new > > function, but I keep finding that functions that I wrote before, will > > help with these new problems. Code re-use is much higher! Less time > > coding. > > I think this says more about your coding style than Clojure. I find > that true in most of the languages I write in, but I structure > programs to make it so. > > > 2. fewer number of parameters that need to be passed into > > subroutines. When writing fortran/C programs, you not only need to > > pass in the data, but you also need to pass in parameters that > > describe the data. In clojure, you usually only pass in the data. > > The same is true of Python, and most modern languages. Clojure's data > structures - which make this possible - have been around in other > languages for quite a while now. > > > 3. (related to 2) Everything is a function, thus, as long as the > > inputs and outputs are the same, you can change the internals at > > will. This makes it super easy to try rewriting code to make it run > > faster. > > The same is true of Python. > > > 4. Using the REPL you write fewer bugs. In an imperative language you > > have to make a guess as to how a whole (possibly very long) subroutine > > should be written before writing it and then debug. Using the REPL > > you start with the most basic steps of the subroutine, make sure those > > work, and then continue to build until you have something that works. > > This is also true of Python's REPL. > > > 5. ease of changing function calls to allow for extra stuff/ > > functionality without breaking other stuff. An example would be best > > here. Suppose I had defined some function that worked for a specific > > purpose: > > (defn setzero [value] > > "If value is less than 1.0E-8 setzero returns zero.." > > (if (tolerance? value 1.0E-8) 0 value)) > > The same is true of Python: > > def setzero(value): > "If value is less than 1.0E-8 setzero returns zero" > return 0 if tolerance_p(value, 1.0E-8) else value > > > > > and later I decided that I would really like to use that same function > > again, but that 1.0E-8 won't work in this new case. I can change > > setzero so that it will work with all of my old code (without change > > to the old code) but I can make it work new code as well. > > (defn setzero > > "If value is less than parameter setzero returns zero. If no > > parameter is specified, the default value of 1.0E-8 is used." > > ([value] > > (setzero
Re: sort-by reverse order?
Very nice On Tue, Nov 23, 2010 at 4:03 PM, Tyler Perkins wrote: > Nice! And with just a bit more, we have a clean, sorting DSL: > > (def asc compare) > (def desc #(compare %2 %1)) > ;; compare-by generates a Comparator: > (defn compare-by [& key-cmp-pairs] > (fn [x y] > (loop [[k cmp & more] key-cmp-pairs] > (let [result (cmp (k x) (k y))] > (if (and (zero? result) more) > (recur more) > result) > > (sort (compare-by :last-name asc, :date-of-birth desc) coll) > > -- > 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: appengine-magic 0.3.0: Clojure on Google App Engine
On Nov 24, 7:58 pm, Constantine Vetoshev wrote: > You can't directly use datastore functions from the REPL. When I said > "interactive development through the REPL", I meant the ability to > recompile individual files and functions inside a running application > — this definitely works across the board; it was a design requirement > for appengine-magic. I can verify that everything else does work very well. > That said, I hear you loud and clear. Several other people have asked > me about making it possible to use the datastore from the REPL. I > actually tried to get that into this release, but it requires a decent > amount of hackery. I'll see what I can do about putting this into the > next release. Understood! Good to know it is possible at least on some level. -- Vesa Marttila -- 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: ANN: ClojureQL 1.0.0 finally released as public beta
> ClojureQL does not take the backend in to account. This is the one > feature from the old CQL that I didn't want to carry over because it > would be impossible for me to cater to all backends. If you hit > specific problems, let me know and I'll see what we can do. > > We adhere to SQL92 and test everything on MySQL and Postgres. If > you're in a situation where thats not good enough, its always possible > to supply part of your expression as a string. Lau Off the top of my head, I know that the LIMIT syntax for SQL Server is totally different. A lot of the apps that I write end up getting deployed using Oracle and SQL Server. If you plan for CQL to be widely used I think you will need to take backends into account. You don't need to implement them all yourself, but you should provide a way so that others can implement them when they need to. Brenton -- 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: Question about an idiom.....
2010/11/24 Mike Meyer > On Wed, 24 Nov 2010 22:51:09 +0100 > Daniel Werner wrote: > > > On 24 November 2010 21:40, Mike Meyer > > wrote: > > > Could someone explain where this urge to write (-> expr (func arg)) > > > instead of (func expr arg) comes from? > > > > I like to use -> and ->> because they allow me to add more steps to > > the "pipeline" as needed, without requiring ever more deeply nested > > parentheses. Of course, the examples you cited were intentionally > > trivial > > Those cases weren't "intentionally trivial", they were the > point. What's the motive for using -> when there's only one form after > the expression? I get why you'd do it with two or more forms - it > reduces the nesting, and reading left-to right follows the evaluation > order. But with just one form it's liable to have the opposite effect > on nesting, and it makes the evaluation order read zig-zag. > I don't know. -?> could have its use, since it would prevent throwing a NullPointerException if the receiver is null, but plain -> .. ? -- 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: Question about an idiom.....
On Wed, 24 Nov 2010 22:51:09 +0100 Daniel Werner wrote: > On 24 November 2010 21:40, Mike Meyer > wrote: > > Could someone explain where this urge to write (-> expr (func arg)) > > instead of (func expr arg) comes from? > > I like to use -> and ->> because they allow me to add more steps to > the "pipeline" as needed, without requiring ever more deeply nested > parentheses. Of course, the examples you cited were intentionally > trivial Those cases weren't "intentionally trivial", they were the point. What's the motive for using -> when there's only one form after the expression? I get why you'd do it with two or more forms - it reduces the nesting, and reading left-to right follows the evaluation order. But with just one form it's liable to have the opposite effect on nesting, and it makes the evaluation order read zig-zag. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Question about an idiom.....
On 24 November 2010 21:40, Mike Meyer
wrote:
> Could someone explain where this urge to write (-> expr (func arg))
> instead of (func expr arg) comes from?
I like to use -> and ->> because they allow me to add more steps to
the "pipeline" as needed, without requiring ever more deeply nested
parentheses. Of course, the examples you cited were intentionally
trivial, but in a setting where you either have many consecutive
transformations on a piece of data, or you *expect* that these
transformations will grow numerous in the future, threading can help
keep the visual and cognitive complexity down. One could probably say
it makes nested s-exprs more scalable ;-)
Interestingly, in languages that prefer dot (.) method call notation
instead of prefix notation, the issue hasn't ever come up for me
because one generally doesn't have a choice. Take Pythons SQLAlchemy
as an example:
Customer.query.filter_by(validated=True).group_by('customer_gender').add_column(func.count()).values(Customer.customer_id)
Pretty neat, isn't it? The threading operators nicely introduce this
style of writing into the world of prefix notation.
--
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: ANN: ClojureQL 1.0.0 finally released as public beta
No problem Luke.
ClojureQL does not take the backend in to account. This is the one
feature from the old CQL that I didn't want to carry over because it
would be impossible for me to cater to all backends. If you hit
specific problems, let me know and I'll see what we can do.
We adhere to SQL92 and test everything on MySQL and Postgres. If
you're in a situation where thats not good enough, its always possible
to supply part of your expression as a string.
I just implemented the final piece before 1.0.0 FINAL today, which is
a predicate compiler that captures the environment and automatically
paramterizes all predicates. To help spread such lightweight news
snippets Ive put up this tumblr in case anybody's interested:
http://laujensen.tumblr.com
Lau
On Nov 24, 9:31 pm, Luke VanderHart wrote:
> Thanks... I think I do see the benefit. I'll certainly give it a try
> and see if I can get the feel of it.
>
> One question... You say it generates optimized SQL. Does it take the
> DBMS into account? I know the performance profiles of various SQL
> idioms vary widely between MySQL and Oracle, for example - what may be
> better as a subselect on one may sometimes be better as a join on
> another.
>
> Thanks so much for the detailed answer...
>
> -Luke
>
> On Nov 24, 3:37 am, LauJensen wrote:
>
> > Hi Luke,
>
> > Thanks!
>
> > Initially CQL0.1 was motivated by "everything in Clojure" which was
> > the driving design principle behind the first version of CQL. When
> > I scrapped that project (for reasons you can read on my blog) I
> > instead turned my attention towards Relational Algebra as this
> > gives you unique ways to compose and express your queries, in
> > my opinion far superior to the SQL language itself.
>
> > Example from our test suite: Lets say you want to define a table
> > which computes an aggregate on a column, ex counting pictures
> > by user id and then join those stats to your users table. In CQL
> > you will (hopefully) intuitively write:
>
> > (let [photo-counts (-> (table :photos)
> > (aggregate [[:count/* :as :cnt]]
> > [:id])))]
> > (-> (table :users)
> > (join photo-counts (= {:users.id :photos.id}))
>
> > I think thats really as simple as you can express that join operation.
> > However for the SQL to work/be efficient, you need to detect when
> > a join benefits from spawning subselects and ClojureQL handles this
> > for you completely transparently, so if you execute the above
> > statement
> > the following is actually generated and run:
>
> > "SELECT users.*,photos_aggregation.cnt FROM users
> > LEFT OUTER JOIN
> > (SELECT photos.user_id,count(photos.*) AS cnt FROM photos GROUP BY
> > user_id)
> > AS photos_aggregation ON (users.user_id = photos_aggregation.user_id)"
>
> > And notice how your reference to :id in photos is automatically
> > aliased
> > to photos_aggregation. There are SQL statements which are truely
> > complex
> > and it takes a long time to master SQL and get comfortable with such
> > queries.
> > It is my ambition that ClojureQL will take away that complexity while
> > still
> > generating the most efficient SQL statements possible. The
> > implications for
> > Q/A on your projects will be substantial I hope.
>
> > And even if I was only doing CRUD - I'd prefer to do it (and have my
> > developers do it)
> > in Clojure, which is guaranteed to compile to correct SQL.
>
> > Answers your question?
>
> > Lau
>
> > On Nov 24, 1:56 am, Luke VanderHart wrote:
>
> > > Lau,
>
> > > This is really impressive, and I can't wait to experiment with it.
>
> > > That said, I'm curious as to what good use cases for this would be,
> > > and what it's motivation is. SQL is already a highly specialized DSL
> > > for slinging around relational data that most developers are already
> > > pretty good with. I'm wondering how useful it is to have a separate
> > > relational DSL. Is this motivated by the same "everything in Clojure"
> > > philosophy (like Hiccup or Scriptjure)? Not that there's anything
> > > wrong with that... I'm just curious as to use cases.
>
> > > Or does it confer some other benefit over SQL besides being Clojure?
> > > The only thing I see is the ability to reuse and compose fragments of
> > > relational logic. Unarguably, that is very cool, but off the top of my
> > > head I can't think of any particular benefit it would give, at least
> > > in my apps. 99% of my database interaction is a fixed set of CRUD
> > > operations, which (unless I'm missing something) would be just as easy
> > > to write in SQL directly.
>
> > > Thanks,
> > > -Luke
>
> > > On Nov 18, 2:10 pm, LauJensen wrote:
>
> > > > Hi gents,
>
> > > > For those of you who have followed the development
> > > > of ClojureQL over the past 2.5 years you'll be excited
> > > > to know that ClojureQL is as of today being released
> > > > as 1.0.0 beta1.
>
> > > > That means that the significant primitives from Relational
> > > > Algebra are all in place and func
ANN: Durable Clojure - Functions and Closures
Extension of http://groups.google.com/group/clojure/browse_thread/thread/7c917e983f345723/a7ee771a7bcaaefc Hi everyone! I've extended the Clojure core to extend durability to functions and closures. 1. Functions with lexical and dynamic bindings are now supported. This includes functions that generate functions. 1.a. There is a slight overhead applied to all compiled functions; the bytecode is inaccessible at runtime except through a cache which maintains an entry for all classes regardless of whether they are eventually persisted or not. This doubles memory required per class, but should, in practice, be negligible. 2. Identities of identities are now supported. This means that persistent data structures of identities can be saved, i.e. you can have a ref of a hash-map of refs. 3. sorted-map and sorted-set are now supported. Get it here: git://github.com/kwanalyssa/clojure.git More testing, especially performance testing, is very welcome. However, at this point, I've satisfied my own requirements. I'd love to get this in scope eventually for enhancing Clojure core, if pain- free persistence is part of the grand vision. Discussion of API and implementation is also welcome. Thanks! Alyssa Kwan -- 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: Question about an idiom.....
2010/11/24 Mike Meyer
> On Wed, 24 Nov 2010 00:37:07 -0800 (PST)
> LauJensen wrote:
>
> You just touched on an idiom I see fairly often here that bugs me. I'm
> not intentionally singling you - or CQL! - out for this, but you made
> a comment that sets up my question perfectly.
>
> > (let [photo-counts (-> (table :photos)
> >(aggregate [[:count/* :as :cnt]] [:id])))]
> >(-> (table :users)
> > (join photo-counts (= {:users.id :photos.id}))
> >
> > I think thats really as simple as you can express that join operation.
>
> Um, I can see two macros that, if expanded in place, would result in a
> simpler expression (assuming that CQL doesn't redefine ->):
>
> (let [photo-counts (aggregate (table :photos) [[:count/* :as :cnt]] [:id])]
> (join (table :users) photo-counts (= {:users.id :photos.id})))
>
> I also fixed the parens - I think. I removed one after [:id], and it
> seems like two were missing at the end as well.
>
> Ok, I understand why you would use -> if you're threading through
> multiple forms. I don't know that I like it, but I can at least
> understand it. But when it's only one form? In the best case - when
> the form is a symbol, as in (-> 1 inc) - it just wastes three
> characters to reverse the form and argument. More often - for example
> (-> 1 (+ 2)) - it also adds another level of parenthesis, which I
> thought most people considered a hindrance to comprehension.
>
> Could someone explain where this urge to write (-> expr (func arg))
> instead of (func expr arg) comes from?
>
Maybe the lack of refactoring tools: expressions starting big, then some
pieces are refactored out, but not totally ?
I know my code looks like this sometimes, and I have to go back to it to
remove these remaining (-> a b).
--
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
Question about an idiom.....
On Wed, 24 Nov 2010 00:37:07 -0800 (PST)
LauJensen wrote:
You just touched on an idiom I see fairly often here that bugs me. I'm
not intentionally singling you - or CQL! - out for this, but you made
a comment that sets up my question perfectly.
> (let [photo-counts (-> (table :photos)
>(aggregate [[:count/* :as :cnt]] [:id])))]
>(-> (table :users)
> (join photo-counts (= {:users.id :photos.id}))
>
> I think thats really as simple as you can express that join operation.
Um, I can see two macros that, if expanded in place, would result in a
simpler expression (assuming that CQL doesn't redefine ->):
(let [photo-counts (aggregate (table :photos) [[:count/* :as :cnt]] [:id])]
(join (table :users) photo-counts (= {:users.id :photos.id})))
I also fixed the parens - I think. I removed one after [:id], and it
seems like two were missing at the end as well.
Ok, I understand why you would use -> if you're threading through
multiple forms. I don't know that I like it, but I can at least
understand it. But when it's only one form? In the best case - when
the form is a symbol, as in (-> 1 inc) - it just wastes three
characters to reverse the form and argument. More often - for example
(-> 1 (+ 2)) - it also adds another level of parenthesis, which I
thought most people considered a hindrance to comprehension.
Could someone explain where this urge to write (-> expr (func arg))
instead of (func expr arg) comes from?
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ANN: ClojureQL 1.0.0 finally released as public beta
Thanks... I think I do see the benefit. I'll certainly give it a try
and see if I can get the feel of it.
One question... You say it generates optimized SQL. Does it take the
DBMS into account? I know the performance profiles of various SQL
idioms vary widely between MySQL and Oracle, for example - what may be
better as a subselect on one may sometimes be better as a join on
another.
Thanks so much for the detailed answer...
-Luke
On Nov 24, 3:37 am, LauJensen wrote:
> Hi Luke,
>
> Thanks!
>
> Initially CQL0.1 was motivated by "everything in Clojure" which was
> the driving design principle behind the first version of CQL. When
> I scrapped that project (for reasons you can read on my blog) I
> instead turned my attention towards Relational Algebra as this
> gives you unique ways to compose and express your queries, in
> my opinion far superior to the SQL language itself.
>
> Example from our test suite: Lets say you want to define a table
> which computes an aggregate on a column, ex counting pictures
> by user id and then join those stats to your users table. In CQL
> you will (hopefully) intuitively write:
>
> (let [photo-counts (-> (table :photos)
> (aggregate [[:count/* :as :cnt]]
> [:id])))]
> (-> (table :users)
> (join photo-counts (= {:users.id :photos.id}))
>
> I think thats really as simple as you can express that join operation.
> However for the SQL to work/be efficient, you need to detect when
> a join benefits from spawning subselects and ClojureQL handles this
> for you completely transparently, so if you execute the above
> statement
> the following is actually generated and run:
>
> "SELECT users.*,photos_aggregation.cnt FROM users
> LEFT OUTER JOIN
> (SELECT photos.user_id,count(photos.*) AS cnt FROM photos GROUP BY
> user_id)
> AS photos_aggregation ON (users.user_id = photos_aggregation.user_id)"
>
> And notice how your reference to :id in photos is automatically
> aliased
> to photos_aggregation. There are SQL statements which are truely
> complex
> and it takes a long time to master SQL and get comfortable with such
> queries.
> It is my ambition that ClojureQL will take away that complexity while
> still
> generating the most efficient SQL statements possible. The
> implications for
> Q/A on your projects will be substantial I hope.
>
> And even if I was only doing CRUD - I'd prefer to do it (and have my
> developers do it)
> in Clojure, which is guaranteed to compile to correct SQL.
>
> Answers your question?
>
> Lau
>
> On Nov 24, 1:56 am, Luke VanderHart wrote:
>
>
>
>
>
>
>
> > Lau,
>
> > This is really impressive, and I can't wait to experiment with it.
>
> > That said, I'm curious as to what good use cases for this would be,
> > and what it's motivation is. SQL is already a highly specialized DSL
> > for slinging around relational data that most developers are already
> > pretty good with. I'm wondering how useful it is to have a separate
> > relational DSL. Is this motivated by the same "everything in Clojure"
> > philosophy (like Hiccup or Scriptjure)? Not that there's anything
> > wrong with that... I'm just curious as to use cases.
>
> > Or does it confer some other benefit over SQL besides being Clojure?
> > The only thing I see is the ability to reuse and compose fragments of
> > relational logic. Unarguably, that is very cool, but off the top of my
> > head I can't think of any particular benefit it would give, at least
> > in my apps. 99% of my database interaction is a fixed set of CRUD
> > operations, which (unless I'm missing something) would be just as easy
> > to write in SQL directly.
>
> > Thanks,
> > -Luke
>
> > On Nov 18, 2:10 pm, LauJensen wrote:
>
> > > Hi gents,
>
> > > For those of you who have followed the development
> > > of ClojureQL over the past 2.5 years you'll be excited
> > > to know that ClojureQL is as of today being released
> > > as 1.0.0 beta1.
>
> > > That means that the significant primitives from Relational
> > > Algebra are all in place and functional. The documentation
> > > is there and I've even made a screencast in order to get
> > > you guys started.
>
> > > Personally Im excited about this version because it really
> > > does change the way you work with a database. Queries
> > > are incredibly composable!
>
> > > For more information, please checkout this blogpost +
> > > screencast:http://bestinclass.dk/index.clj/2010/11/clojureql--1.0.0-now-in-beta
>
> > > Best regards,
> > > Lau
--
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: discussing Clojure with non-CS types
On Wed, 24 Nov 2010 09:20:49 -0800 (PST) cej38 wrote: > I am a physicist. I have been using Clojure full time for the last > year and a half. The reasons that Rich (and most other Clojure > evangelists) give for using Clojure, are all nice and good, but they > point to what computer scientists think about. If you want scientists > and engineers to think about switching to Clojure, you need to talk to > the concerns that they have. Of course, there is some overlap. The thing is, I'm not sure it's the best choice for such people. At least, not yet. The LISP-like syntax means you have to explain the code if you publish it, a problem that some alternatives - which have most of your advantages - don't have. Look at Python, a descendant of ABC, which was designed for teaching/prototyping. It's been described as "executable pseudo-code". > Here are some reasons that I would give for using clojure: > 1. Most data analysis gets done by writing little programs that do > certain tasks. When writing in Fortran I more or less have to write a > new program to do each task. In clojure, I might have to write a new > function, but I keep finding that functions that I wrote before, will > help with these new problems. Code re-use is much higher! Less time > coding. I think this says more about your coding style than Clojure. I find that true in most of the languages I write in, but I structure programs to make it so. > 2. fewer number of parameters that need to be passed into > subroutines. When writing fortran/C programs, you not only need to > pass in the data, but you also need to pass in parameters that > describe the data. In clojure, you usually only pass in the data. The same is true of Python, and most modern languages. Clojure's data structures - which make this possible - have been around in other languages for quite a while now. > 3. (related to 2) Everything is a function, thus, as long as the > inputs and outputs are the same, you can change the internals at > will. This makes it super easy to try rewriting code to make it run > faster. The same is true of Python. > 4. Using the REPL you write fewer bugs. In an imperative language you > have to make a guess as to how a whole (possibly very long) subroutine > should be written before writing it and then debug. Using the REPL > you start with the most basic steps of the subroutine, make sure those > work, and then continue to build until you have something that works. This is also true of Python's REPL. > 5. ease of changing function calls to allow for extra stuff/ > functionality without breaking other stuff. An example would be best > here. Suppose I had defined some function that worked for a specific > purpose: > (defn setzero [value] > "If value is less than 1.0E-8 setzero returns zero.." > (if (tolerance? value 1.0E-8) 0 value)) The same is true of Python: def setzero(value): "If value is less than 1.0E-8 setzero returns zero" return 0 if tolerance_p(value, 1.0E-8) else value > > and later I decided that I would really like to use that same function > again, but that 1.0E-8 won't work in this new case. I can change > setzero so that it will work with all of my old code (without change > to the old code) but I can make it work new code as well. > (defn setzero > "If value is less than parameter setzero returns zero. If no > parameter is specified, the default value of 1.0E-8 is used." > ([value] > (setzero value 1.0E-8)) > ([value parameter] > (if (tolerance? value 1.0E-8) 0 parameter))) def setzero(value, parameter=1.0E-8): """If value is less than parameter setzero returns zero The default value of parameter is 1.0E-8""" return 0 if tolerance_p(value, parameter) else value (ok, I followed the comment not the code) > 6. Many types of Concurrency "without all that mucking about in" MPI, > openMP and the like (Thanks to Douglas Adams.) Not true in Python. Worse yet, even the most recent versions of Python's C implementation still suffer with the GIL. This (along with just flat liking functional programming and LISPy languages) is why I'm looking at clojure. But as you say, these are a professional programmers reasons for using it; I'm not sure they carry enough weight to overcome the advantages Python (or other, similar languages) might offer. > 7. Is it a scripting language or a compiled language? Yes. Depending > on what you need it for. I often use the REPL and my code to script > stuff. There are also times where you want to have a real program as > a JAR file, clojure can be both. The same is true of Python. In fact, it's true twice: if you think that the JVM is fast enough, you can run your code in Jython and leverage Java tools. If that's not fast enough, you can wrap your favorite native FORTRAN libraries (assuming it hasn't already been done) along with a graphics library, and play with them all in the REPL. Not merely exploratory programming, but full-blown visual exploratory data ana
Re: memcache, redis connection pooling
I highly recommend jedis for redis java lib. It supports connection pooling, pub/sub. and works with the 2.0 protocol. https://github.com/xetorthio/jedis Any reason why you want to use both memcached and redis at the same time? redis is basically memcached++, with collection/queue support as values, and persist the data to disk periodically. I'm not sure what memcached fits in here if you already have redis. On Sun, Nov 21, 2010 at 6:55 AM, Saul Hazledine wrote: > Has anyone got experience of using this library with Clojure? Also, is > there a similar library for Redis? > > Another possibility is forking and adding pooling to existing memcache > and redis libraries written in Clojure. If I attempted this, does > anybody know of a good TCP/IP connection pool library that works with > Clojure? > > Thanks in advance for any help. > Saul > > -- > 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 -- Omnem crede diem tibi diluxisse supremum. -- 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: record serialization
That was me and I blogged it for good measure ( http://tech.puredanger.com/2010/11/23/implementing-java-interfaces-with-clojure-records/ ) and added the example to clojure docs ( http://clojuredocs.org/clojure_core/clojure.core/defrecord#example_550 ). On Nov 24, 6:10 am, Islon Scherer wrote: > Thanks for the answers! > Some guy told me on irc that you can implement interfaces right in the > record definition like > (defrecord R [a b] SomeInterface (methods...)) > > Regards. > Islon > > On Nov 24, 4:25 am, Shantanu Kumar wrote: > > > > > > > > > Shantanu Kumar wrote: > > > Islon Scherer wrote: > > > > Yes, java serialization is what I want but I don't know how to do a > > > > record implement the Serializable interface. > > > > The following two steps may help: > > > > (defrecord Foo [a b]) > > > (extend java.io.Serializable Foo) > > > Oops! that was a bit too fast. Records already implement Serializable. > > > Regards, > > 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
Re: *warn-on-reflection* broken in 1.2?
On Wed, Nov 24, 2010 at 11:18 AM, Sergey Didenko wrote: > Here is the Enclojure ticket - > https://www.assembla.com/spaces/enclojure/tickets/83-rebinding-of-vars-does-not-work-in-ide-repl--e-g--*print-meta*--*warn-on-reflection* It seems to me that *warn-on-reflection* is working, but the reflection warnings are being sent to *out* and *out* isn't being flushed when they are; sending a println to *out* with e.g. (future (println "foo")) forces all undisplayed reflection warnings to come vomiting forth. user=> (set! *warn-on-reflection* true) true user=> (defn foo [x] (.length x)) #'user/foo (nothing else in Repl, nothing in *out*) user=> (println "foo") foo nil (nothing else in Repl, nothing in *out*) user=> (future (println "foo")) # user=> (and over in *out*:) Reflection warning, NO_SOURCE_PATH:9 - reference to field length can't be resolved. foo -- 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: IDE and editors for Clojure
On Wed, Nov 24, 2010 at 1:33 PM, Sergey Didenko wrote: > I use Enclojure. > > It works quite well though has some bugs. For example *warn-on-reflection* > can not be set from its REPL. I use a standalone REPL for this case. Actually it can be set. There seems to be a bug in 1.4.0 with buffering. The reflection warnings appear in *out* instead of in the Repl tab and only appear if something else is sent to *out* with println which flushes *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: Porting libraries to ClojureCLR
I gave some thought to the Integer vs. Int32 issue. I think what would help here is a way to alias classes when :importing them. It would require tweaking the ns macro and possibly parts of the runtime. The outcome would be to allow something like (ns foo (:import (java.util.concurrent AtomicBoolean (ConcurrentHashMap :as CHM) AtomicInteger))) (defn make-default-chm [] (CHM. 12 12 12)) ... Handy so far for abbreviating some longer classnames, and the application to CLR portability is apparent: (ns foo (:import (System (Int32 :as Integer In theory, you'd just add this import to make code full of ^Integer hints compile under ClojureCLR. You'd still need two versions of the source file though, a CLR version with the import and a JVM version without. But then why not go even further and have the ns macro able to tell what platform it's on? (ns foo (:import-jvm (package1.package2 BarBaz as BBaz)) (:import-clr (Package3.Package4.BooBaz as BBaz))) (code-using-BBaz...) Now in theory the one source file works under both. Of course this doesn't help you if the BarBaz and BooBaz classes have sufficiently different behavior that they can't be drop-in replacements for each other. In that case the ideal would be to have Clojure wrappers for the classes that translated into their semantics from some common API -- an abstraction layer with separate JVM and CLR versions (and normal imports). Now the problem becomes selecting between these, but if the ns macro is going to learn to tell if it's running on a JVM or the CLR anyway, why not add, also, :use-jvm, :use-clr, :require-jvm, and :require-clr? Now the appropriate abstraction layer can be used depending on the underlying runtime without having to maintain two separate source trees mostly containing copies of the same files but for a few platform-specific ones. Instead there will be two differently-named versions of each platform-specific file and one of everything else in a single source tree, and in some cases fewer platform-specific files (e.g. where Int32 vs. Integer had formerly required there be two versions of a file but :import-foo allows there to be just one). -- 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: discussing Clojure with non-CS types
Another thought: 9. Unit testing is much easier! The effort it takes to write unit tests is Fortran is so high, it might as well be impossible, and thus almost no one does 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
Re: Is clojure.core/syntax-quote gone from clojure-1.2?
+1 -- 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: discussing Clojure with non-CS types
Having a fast code is important, but as I have often said to colleagues, computer time is cheap, my time is not. If I can write code that does the same thing in two languages, and the code written in one language runs in half the time of the other, while the code in the other language took half the time to write, which one should I use? -- 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: IDE and editors for Clojure
I use Enclojure. It works quite well though has some bugs. For example *warn-on-reflection* can not be set from its REPL. I use a standalone REPL for this case. -- 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: discussing Clojure with non-CS types
> I am a physicist. I have been using Clojure full time for the last > year and a half. The reasons that Rich (and most other Clojure > evangelists) give for using Clojure, are all nice and good, but they > point to what computer scientists think about. If you want scientists > and engineers to think about switching to Clojure, you need to talk to > the concerns that they have. Of course, there is some overlap. If you're comparing with Fortran, my favorite advantage is that I can create a new array in a function, and return it from that function. In Fortran, I would have needed to create the array in whatever code calls that function, and pass the array in. This issue adds a lot of overhead to any effort to reuse code. (I'm not sure if this issue was fixed in the more recent Fortran 2003 or 2008 versions.) I know a lot of nuclear engineers, from my previous life as a nuclear engineering grad student, and I have been unable to convince any of them to try languages other than Fortran. Their arguments fall into three categories. 1) Not fast enough. If it's even a little slower than Fortran, that's unacceptable. Even C++ is not acceptable for this reason, and anything with garbage collection is worthy of a raised nose. This actually seems like a legitimate reason. I just think that faster development time is worth giving up some execution speed, especially if you can use the extra time to experiment with possibly faster algorithms. Additionally, raw execution speed is one of the priorities for the upcoming Clojure 1.3. 2) It's not Fortran, and I don't have time to learn another language. I have work to do. Of course, much of that work involves programming in Fortran, and would get done so much faster in any other language. 3) It doesn't work on [big computer configured by someone else]. Of course, the computer was configured that way to support a bunch of engineers who only program in Fortran. If this were the real problem, the computer would be configured differently. = I think the best thing you can do to convince your colleagues to use Clojure, is to create open source Clojure libraries and applications that they would find useful. Eventually they will want more than what the applications provide out of the box. The desire to customize their favorite tool will provide an immediate motivation to learn Clojure, and the fact that such a great tool was created in Clojure will be good evidence that Clojure could be useful in other projects. Bonus points if that tool, created in Clojure, turns out to be faster than they would have expected from a Fortran program. -- 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: discussing Clojure with non-CS types
yes On Nov 24, 12:28 pm, Joop Kiefte wrote: > 2010/11/24 cej38 : > > > > > > > 5. ease of changing function calls to allow for extra stuff/ > > functionality without breaking other stuff. An example would be best > > here. Suppose I had defined some function that worked for a specific > > purpose: > > > (defn setzero [value] > > "If value is less than 1.0E-8 setzero returns zero.." > > (if (tolerance? value 1.0E-8) 0 value)) > > > and later I decided that I would really like to use that same function > > again, but that 1.0E-8 won't work in this new case. I can change > > setzero so that it will work with all of my old code (without change > > to the old code) but I can make it work new code as well. > > > (defn setzero > > "If value is less than parameter setzero returns zero. If no > > parameter is specified, the default value of 1.0E-8 is used." > > ([value] > > (setzero value 1.0E-8)) > > ([value parameter] > > (if (tolerance? value 1.0E-8) 0 parameter))) > > You mean this I suppose: > > (defn setzero > "If value is less than parameter setzero returns zero. If no > parameter is specified, the default value of 1.0E-8 is used." > ([value] > (setzero value 1.0E-8)) > ([value parameter] > (if (tolerance? value parameter) 0 value))) -- 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: appengine-magic 0.3.0: Clojure on Google App Engine
On Nov 24, 6:41 am, Vesa Marttila wrote: > I have a question about this release: I understood from this release > announcement that entities can be saved from the REPL, but I was not > able to do so and the official documentation still states that it > can't be > done, which is the case? You can't directly use datastore functions from the REPL. When I said "interactive development through the REPL", I meant the ability to recompile individual files and functions inside a running application — this definitely works across the board; it was a design requirement for appengine-magic. You need to use an editor-linked REPL for this functionality, such as SLIME. I believe VimClojure, Enclojure (NetBeans), Counterclockwise (Eclipse), and La Clojure (IntelliJ IDEA) should also work, but do not use them myself. That said, I hear you loud and clear. Several other people have asked me about making it possible to use the datastore from the REPL. I actually tried to get that into this release, but it requires a decent amount of hackery. I'll see what I can do about putting this into the next release. -- 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: discussing Clojure with non-CS types
2010/11/24 cej38 : > 5. ease of changing function calls to allow for extra stuff/ > functionality without breaking other stuff. An example would be best > here. Suppose I had defined some function that worked for a specific > purpose: > > (defn setzero [value] > "If value is less than 1.0E-8 setzero returns zero.." > (if (tolerance? value 1.0E-8) 0 value)) > > and later I decided that I would really like to use that same function > again, but that 1.0E-8 won't work in this new case. I can change > setzero so that it will work with all of my old code (without change > to the old code) but I can make it work new code as well. > > (defn setzero > "If value is less than parameter setzero returns zero. If no > parameter is specified, the default value of 1.0E-8 is used." > ([value] > (setzero value 1.0E-8)) > ([value parameter] > (if (tolerance? value 1.0E-8) 0 parameter))) You mean this I suppose: (defn setzero "If value is less than parameter setzero returns zero. If no parameter is specified, the default value of 1.0E-8 is used." ([value] (setzero value 1.0E-8)) ([value parameter] (if (tolerance? value parameter) 0 value))) -- 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
discussing Clojure with non-CS types
I am a physicist. I have been using Clojure full time for the last year and a half. The reasons that Rich (and most other Clojure evangelists) give for using Clojure, are all nice and good, but they point to what computer scientists think about. If you want scientists and engineers to think about switching to Clojure, you need to talk to the concerns that they have. Of course, there is some overlap. I will note that this is a quick listing of ideas to discuss. There are surely more points to make, and better, cleaner ways of discussing them. Also, I haven't made any effort to use well thought out English sentences. Here are some reasons that I would give for using clojure: 1. Most data analysis gets done by writing little programs that do certain tasks. When writing in Fortran I more or less have to write a new program to do each task. In clojure, I might have to write a new function, but I keep finding that functions that I wrote before, will help with these new problems. Code re-use is much higher! Less time coding. 2. fewer number of parameters that need to be passed into subroutines. When writing fortran/C programs, you not only need to pass in the data, but you also need to pass in parameters that describe the data. In clojure, you usually only pass in the data. 3. (related to 2) Everything is a function, thus, as long as the inputs and outputs are the same, you can change the internals at will. This makes it super easy to try rewriting code to make it run faster. 4. Using the REPL you write fewer bugs. In an imperative language you have to make a guess as to how a whole (possibly very long) subroutine should be written before writing it and then debug. Using the REPL you start with the most basic steps of the subroutine, make sure those work, and then continue to build until you have something that works. 5. ease of changing function calls to allow for extra stuff/ functionality without breaking other stuff. An example would be best here. Suppose I had defined some function that worked for a specific purpose: (defn setzero [value] "If value is less than 1.0E-8 setzero returns zero.." (if (tolerance? value 1.0E-8) 0 value)) and later I decided that I would really like to use that same function again, but that 1.0E-8 won't work in this new case. I can change setzero so that it will work with all of my old code (without change to the old code) but I can make it work new code as well. (defn setzero "If value is less than parameter setzero returns zero. If no parameter is specified, the default value of 1.0E-8 is used." ([value] (setzero value 1.0E-8)) ([value parameter] (if (tolerance? value 1.0E-8) 0 parameter))) 6. Many types of Concurrency "without all that mucking about in" MPI, openMP and the like (Thanks to Douglas Adams.) 7. Is it a scripting language or a compiled language? Yes. Depending on what you need it for. I often use the REPL and my code to script stuff. There are also times where you want to have a real program as a JAR file, clojure can be both. 8. Every problem has been solved twice in Java. Meaning it has been solved three times in clojure. The underlying theme is that you can quickly write the code that you need to do your job, so that you can get back to doing your job. -- 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: priority queue for scheduling events in the future
Thanks! On Wed, Nov 24, 2010 at 8:30 AM, Tom Faulhaber wrote: > OK, I'm doing stuff there now. > > I'll move the comment to the ns doc string, then. > > There are still issues with autodoc and protocols/types, but priority > queues look like they'll be a good sandbox for resolving them. > > Tom > > -- 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: priority queue for scheduling events in the future
OK, I'm doing stuff there now. I'll move the comment to the ns doc string, then. There are still issues with autodoc and protocols/types, but priority queues look like they'll be a good sandbox for resolving them. Tom On Nov 24, 2:51 am, Mark Engelberg wrote: > No reason other than my lack of knowledge that ns doc strings are picked up > by autodoc and comments are not. :) > > On Wed, Nov 24, 2010 at 12:36 AM, Tom Faulhaber wrote: > > > Mark, > > > Is there a reason that you put the documentation in a comment rather > > than as the ns doc string so that autodoc would pick it up? Currently, > > priority queues are undiscoverable by autodoc users. > > > Tom -- 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: *warn-on-reflection* broken in 1.2?
Here is the Enclojure ticket - https://www.assembla.com/spaces/enclojure/tickets/83-rebinding-of-vars-does-not-work-in-ide-repl--e-g--*print-meta*--*warn-on-reflection* > On 4 November 2010 15:11, Ken Wesson wrote: > >> The website has this example: >> >> (set! *warn-on-reflection* true) >> -> true >> (defn foo [s] (.charAt s 1)) >> -> Reflection warning, line: 2 - call to charAt can't be resolved. >> -> #user/foo >> >> When I try this in a Clojure 1.2 REPL generated by Enclojure 1.4.0/NB >> 6.9.1 I don't see the reflection warning in any of Repl, *err*, and >> *out*. >> >> Is this actually broken in Clojure 1.2 or is it Enclojure screwing up? >> >> -- 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: ANN: Gloss, a byte-format DSL
ByteBuffers have an order() method which allows you to toggle the
endianness. I haven't tested this, but since everything is built on
top of Java's ByteBuffer functionality it should be fine as long as
the ByteBuffers are correctly set and correctly ordered with respect
to each other.
Zach
On Nov 23, 2:52 pm, zoka wrote:
> JVM stores numbers in in big endian format - is there a way to process
> binary stream containing little endian numbers?
>
> Zoka
>
> On Nov 24, 7:24 am, Zach Tellman wrote:
>
>
>
>
>
>
>
> > Good question. The solution didn't make the cut for my initial
> > release, but will be added soon. My plan is to have an (ordered-
> > map ...) frame which encodes and decodes the keys in the given order.
> > So for C interop, the frame would be
>
> > (ordered-map :a :int16, :b :float32)
>
> > An alternative would be to just turn any vector which is alternating
> > keys and types into an ordered-map, but that seems a bit too magical.
>
> > Zach
>
> > On Nov 23, 12:12 pm, Chris Perkins wrote:
>
> > > On Nov 23, 12:03 pm, Zach Tellman wrote:
>
> > > > When writing Calx [1], I discovered it was a huge pain to deal with
> > > > mixed C datatypes in Java. When writing Aleph [2], I discovered the
> > > > problem increases by a factor of ten when dealing with streams of
> > > > bytes. In an attempt to alleviate my own pain, and hopefully help a
> > > > few other people out, I've written Gloss, which can transform a simple
> > > > byte-format specification into an encoder and streaming decoder.
>
> > > > A full writeup can be found athttps://github.com/ztellman/gloss/wiki.
>
> > > > A few people have already asked me how this differs from protocol
> > > > buffers, so I'll preemptively answer that protocol buffers are a fixed
> > > > format that cannot be used to interface with external systems. Gloss
> > > > is less performant than protocol buffers, but is also much less picky
> > > > about formats.
>
> > > > If anyone has any questions, I'd be happy to answer them.
>
> > > Looks very useful, Zach. Thanks.
>
> > > I have a question.
>
> > > I have only taken a quick look, so maybe I'm misunderstanding the
> > > intent, but it's not clear to me how you would use this for sending
> > > and receiving structured data from, say, a C program.
>
> > > Taking your example from the wiki:
>
> > > (def fr (compile-frame {:a :int16, :b :float32}))
>
> > > Let's say I want to talk to a C program that speaks in structs, like
> > > this:
>
> > > struct Foo { short a; float b; }
>
> > > The problem is, the C program cares about order - the short comes
> > > before the float. How does the Clojure program know what order I need
> > > the fields in, since I have specified the format with a map; an
> > > unordered data structure? Is there another way to specify a structure
> > > where order of the fields matters? If so, why have two ways of doing
> > > it? Or am I just missing something?
>
> > > Thanks,
>
> > > - Chris
--
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: ANN: Gloss, a byte-format DSL
On Nov 24, 12:42 am, Michael Wood wrote:
> Hi
>
> On 24 November 2010 04:43, Zach Tellman wrote:
>
> > There are a couple of different things being discussed here. I don't
> > think there's any harm in allowing maps as frames, as long as people
> > understand that they're arbitrarily ordered (alphabetically by key,
> > but that's an implementation detail) and that keys specified aren't
> > optional - if they're not all there, the encoder will fail.
>
> > The first issue you raised was that we might want to have finer
> > control over how maps are encoded, so that we can ensure compatibility
> > with C structs. This is true, but we still want the decoded versions
> > of these ordered lists to be maps, because {:a 1, :b 2} is much more
> > convenient than [:a 1 :b 2] or [[:a 1] [:b 2]].
>
> > The second issue you're raising is backwards compatibility. It's
>
> I don't think he's talking about backwards compatibility at all.
Chris raised the issue of breaking a format by adding keys, but that
will happen no matter how the format is ordered. I just wanted to
make sure that was clear.
>
> Assume you have two C structs that you need to interoperate with. The
> first has a few fields and the second has many fields. If you specify
> the format with a map, then when you serialise your Clojure data, the
> smaller one will create the values in the order you specified in the
> map. The larger one will be in some arbitrary order which depends on
> Clojure's implementation and will likely not match up with the actual
> struct definition.
>
> Or to put it another way, say you have many structs. The first
> several have few fields, so you happily use maps to specify them.
> Everything works fine. Then you get to a larger struct and you find
> that your fields land up in the wrong part of the serialised output.
>
> I haven't looked at Gloss yet, so maybe this isn't possible for some reason?
I feel like I must have done a poor job describing the ordered-map
mechanism earlier. This codec is fine:
(defcodec c {:a :int16, :b :float32})
as long as Gloss is on both sides of the encoding and decoding, or if
the default ordering is coincidentally correct. However, if we want
to invert the position of :a and :b, we use ordered-map:
(defcodec c (ordered-map :b :float32, :a :int16))
This codec still consumes and emits standard Clojure maps, it just
makes sure that the values are encoded in a particular order. The
frame is the only thing that has to change to make the encoding
explicitly ordered; everything else can continue to use unordered
hashes without concern.
I think this solves the problem you describe, but maybe I'm
misunderstanding you.
Zach
>
> > [...] I wrote the
> > library mostly to help me write Redis and AMQP clients, but I'm hoping
> > people will find it useful for a variety of purposes.
>
> I have used Python's struct library a few times (and perl's
> pack/unpack once or twice), so I'm sure Gloss would be useful for the
> same sorts of things.
>
> --
> Michael Wood
--
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: Porting libraries to ClojureCLR
I thought about that a little too. The thing is that clojure is doing something almost imposible. There is almost know way around writing you json library backand in clr interop. If we want to make clojure programm that run on the clr, the jvm and possibly in the browser we have to write pure clojure but not using native stuff is against the clojure way. So how can we solve this? I think we need a kind of tagsystem. With the tags you could indicate if a library is pure clojure or if it uses lower level stuff. For librarys that use jvm we have to define a interface with the clr version can mirror. That way we would at least not need to change code that runes on these librarys. That would need lots of communication between the clr and jvm people. But there will always be code that only runes on one host. You cant (trivially) call hadoop on the clr for example. The other possibility is to develop to diffrent ecosystems but that would make it even harder to switch from one to the other. In the long run the librarys that are writen in pure clojure will hopfully become the standard. - The same problem we have with the typesystem. No idea how to solve that. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure / OpenJDK / fork join (etc.) at FOSDEM
All: Join us at FOSDEM 2011 to be part of our sessions where we'll discuss the state of Free Java! This is the PERFECT place to talk about cool things going on with Clojure such as taking advantage of JDK 7 or JDK 8 features *today* through OpenJDK trunk. Typically this conference has brought together JVM experts from Sun (now Oracle), major industry players and very creative open source projects. Please submit a talk right away! http://wiki.debian.org/Java/DevJam/2011/Fosdem Our theme is "Java Sans Frontières" * Why Free Java technology is awesome * Standing on the Shoulders of Free Java * The future of Free Java The Call For Participation is OPEN NOW, but closes on the 3rd of December... So send in a talk proposal today and join us in Brussels 5-6 February! Why FOSDEM? * Engage in scintillating discussions with smart hackers over world famous Belgian Beer * Join the Web of Trust by getting your strong new key signed * Indulge in exquisite chocolate * Visit historic Brussels within walking distance Why the Free Java DevJam? * This is the most significant non-commercial, neutral environment for Java developers to meet * Learn how to get involved in technical Free Java projects * We will not shy away from politics (especially this year)! * We will get together for an awesome dinner * You will meet historic hackers in the evolution of Free Java Please join the freejava-devr...@lists.fosdem.org list for general discussion about the event. http://lists.fosdem.org/mailman/listinfo/freejava-devroom To submit a formal Talk Proposal follow the guidelines at http://wiki.debian.org/Java/DevJam/2011/Fosdem/CallForParticipation Respectfully, Andrew Haley GCJ Maintainer, GNU Classpath, IcedTea & OpenJDK Developer. Andrew John Hughes IcedTea Maintainer, GNU Classpath Maintainer, OpenJDK & GCJ Developer Christian Thalinger OpenJDK developer, former CACAO Maintainer Mark Wielaard GNU Classpath Maintainer, GCJ, IcedTea & OpenJDK contributor. Tom Marble Java Libre hacker, Former OpenJDK Ambassador -- 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: appengine-magic 0.3.0: Clojure on Google App Engine
On Nov 23, 6:55 pm, Constantine Vetoshev wrote: > appengine-magic abstracts away nearly all the boilerplate necessary to > deploy an App Engine application. It also enables interactive > development through the REPL. The new version has full support for > many App Engine services: the datastore, memcache, user Google account > authentication, the blobstore, sending and receiving email, task > queues, and remote URL access. Hi! I've been playing around with appengine-magic and I've so far been very satisfied so thank you for it. I have a question about this release: I understood from this release announcement that entities can be saved from the REPL, but I was not able to do so and the official documentation still states that it can't be done, which is the case? -- Vesa Marttila -- 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: ANN: Gloss, a byte-format DSL
JVM stores numbers in in big endian format - is there a way to process
binary stream containing little endian numbers?
Zoka
On Nov 24, 7:24 am, Zach Tellman wrote:
> Good question. The solution didn't make the cut for my initial
> release, but will be added soon. My plan is to have an (ordered-
> map ...) frame which encodes and decodes the keys in the given order.
> So for C interop, the frame would be
>
> (ordered-map :a :int16, :b :float32)
>
> An alternative would be to just turn any vector which is alternating
> keys and types into an ordered-map, but that seems a bit too magical.
>
> Zach
>
> On Nov 23, 12:12 pm, Chris Perkins wrote:
>
> > On Nov 23, 12:03 pm, Zach Tellman wrote:
>
> > > When writing Calx [1], I discovered it was a huge pain to deal with
> > > mixed C datatypes in Java. When writing Aleph [2], I discovered the
> > > problem increases by a factor of ten when dealing with streams of
> > > bytes. In an attempt to alleviate my own pain, and hopefully help a
> > > few other people out, I've written Gloss, which can transform a simple
> > > byte-format specification into an encoder and streaming decoder.
>
> > > A full writeup can be found athttps://github.com/ztellman/gloss/wiki.
>
> > > A few people have already asked me how this differs from protocol
> > > buffers, so I'll preemptively answer that protocol buffers are a fixed
> > > format that cannot be used to interface with external systems. Gloss
> > > is less performant than protocol buffers, but is also much less picky
> > > about formats.
>
> > > If anyone has any questions, I'd be happy to answer them.
>
> > Looks very useful, Zach. Thanks.
>
> > I have a question.
>
> > I have only taken a quick look, so maybe I'm misunderstanding the
> > intent, but it's not clear to me how you would use this for sending
> > and receiving structured data from, say, a C program.
>
> > Taking your example from the wiki:
>
> > (def fr (compile-frame {:a :int16, :b :float32}))
>
> > Let's say I want to talk to a C program that speaks in structs, like
> > this:
>
> > struct Foo { short a; float b; }
>
> > The problem is, the C program cares about order - the short comes
> > before the float. How does the Clojure program know what order I need
> > the fields in, since I have specified the format with a map; an
> > unordered data structure? Is there another way to specify a structure
> > where order of the fields matters? If so, why have two ways of doing
> > it? Or am I just missing something?
>
> > Thanks,
>
> > - Chris
>
>
--
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: Porting libraries to ClojureCLR
On 24 November 2010 02:11, JMatt wrote: > The easiest way to prevent divergence is to write and use native > clojure libraries. I totally agree. However because of clojure's excellent interop capabilities it is extremely common (in fact encouraged) for developers to directly use Java code. For example the json library I am porting (https://github.com/danlarkin/clojure-json) directly uses java.IO.StringReader etc. I currently plan to do what you have suggested - implement a single API using both Java and CLR components by means of defprotocol and extend-type. It should work for this simple case. But actually I think that the better solution would be for the json library to have no VM-specific code and instead rely on lower-level clojure libraries to provide the reading/writing/buffer capabilities. It is those libraries which should switch implementation based on VM. Another interesting problem is type hints. CLR equivalent to Integer is Int32, so for my first stab I have broken java compatibility by directly replacing #^Integer with #^Int32. Ultimately I will have to create a new type (IntegerType) and have the implementation switch based on the VM. > I know I'd prefer to use clojure > if I had to write .NET code some time in the future. Yeah, it makes a huge difference! For anyone that's interested, the current port is at https://github.com/davidjagoe/clojure-json but please note that I have temporarily broken java compatibility and unicode is not supported at the moment because the .net readers don't have an equivalent to java's read() which does the right thing wrt chars... .net treats everything as a byte. Boo. Cheers, David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: record serialization
Thanks for the answers! Some guy told me on irc that you can implement interfaces right in the record definition like (defrecord R [a b] SomeInterface (methods...)) Regards. Islon On Nov 24, 4:25 am, Shantanu Kumar wrote: > Shantanu Kumar wrote: > > Islon Scherer wrote: > > > Yes, java serialization is what I want but I don't know how to do a > > > record implement the Serializable interface. > > > The following two steps may help: > > > (defrecord Foo [a b]) > > (extend java.io.Serializable Foo) > > Oops! that was a bit too fast. Records already implement Serializable. > > Regards, > 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
Re: priority queue for scheduling events in the future
No reason other than my lack of knowledge that ns doc strings are picked up by autodoc and comments are not. :) On Wed, Nov 24, 2010 at 12:36 AM, Tom Faulhaber wrote: > Mark, > > Is there a reason that you put the documentation in a comment rather > than as the ns doc string so that autodoc would pick it up? Currently, > priority queues are undiscoverable by autodoc users. > > Tom > > -- 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: (into my_vec) of order O(n)
Hi, On 24 Nov., 11:35, Andreas Kostler wrote: > Where's the flaw in my thinking there? This is what (concat ...) does. However, a vector promises O(log32 N) random access, which you can't if you don't add elements of the second argument into the vector structure. Then you can only promis O(n) for random access. Hope this helps. Sincerely Meikel -- 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
(into my_vec) of order O(n)
Can someone please explain why an insert into a vector: (insert my_vec [:a :b :c] (range 10)) would be of linear time complexity based on the size of the second argument? I would have thought that this would boil down to something like adding a reference to the first element of the sequence returned by range to the end of the vector...which I would have thought could be achieved in constant time. Where's the flaw in my thinking there? Cheers Andreas -- 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
Is clojure.core/syntax-quote gone from clojure-1.2?
I was looking for it, but to no avail! Anyway, something I was wondering about. Why don't we take the best from all possible worlds? In this case, Clojure and Scheme (R6RS). It would be nice to have syntax-quote, unquote, and unquote-splicing as true macros (or special forms), and keep `, ~, and ~@ (and of course auto-gensyms) as convenient reader shortcuts. Just seems more elegant, plus it let's you do things like building arbitrary syntax-quote expressions with Lisp itself (lispier, heh?). Now, who would go to such extremes? ... well, you never know :) But, something more important! Why not adopt R6RS's expansion rules for syntax-quotes? This is something that was hinted at even in the Common Lisp specs, the only problem being that, at the time, Scheme didn't entirely get it right when it came to the distributive application of unquote applied to an unquote-splicing in a nested syntax-quote (backquote): Example - (def a 2) (def b 3) (def c 5) (def x `(a b c)) ``(~...@x) ---> `(~user/a ~user/b ~user/c) and finally to: (2 3 5) But R6RS finally got it right, and now (unquote a1 a2 a3 ...) really does what it should, so you get the exact same behavior. R6RS defines the nested syntax-quote expansion like so: "Quasiquote forms may be nested. Substitutions are made only for unquoted components appearing at the same nesting level as the outermost quasiquote. The nesting level increases by one inside each successive quasiquotation, and decreases by one inside each unquotation." This is, curiously, more or less how Paul Graham puts it for Common Lisp in his ANSI Common Lisp book. And, by the way, I've noticed that SBCL employs this exact rule when expanding backquotes. The upshot (among other things) for Clojure is that, if Rich likes the idea, we would finally get a decent, human-understandable, expansion of syntax-quote forms as well. Compare the above: ``(~...@x) ---> (clojure.core/seq (clojure.core/concat (clojure.core/ list user/a user/b user/c))) to this: ``(~...@x) ---> `(~user/a ~user/b ~user/c) or, at most: ``(~...@x) ---> (syntax-quote ((unquote user/a) (unquote user/b) (unquote user/c))) And that was a really simple nested syntax-quote. I wouldn't even want to try tackling more complex ones. Anyway, just an idea. Rock -- 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
a simple .. macro for debugging code inside ->>
Hello everybody, I just wrote a simple macro for debugging the ->> .. just thought of sharing it with you all (defmacro print-and-return ([x] `(let [x# ~x] (println x#) x#)) ([flag x] `(let [flag# '~flag x# ~x] (println flag#) (println x#) x#))) (defmacro ->>d [ & args] `(->> ~@(interpose 'print-and-return args) print-and-return)) (defmacro ->>dd [& args] `(->> ~@(interleave args (map (fn [x] (list 'print-and-return x)) args ;-- (->>dd (range 10) (map inc) (filter even?)) (range 10) (0 1 2 3 4 5 6 7 8 9) (map inc) (1 2 3 4 5 6 7 8 9 10) (filter even?) (2 4 6 8 10) ;- (->>d (range 10) (map inc) (filter even?)) (0 1 2 3 4 5 6 7 8 9) (1 2 3 4 5 6 7 8 9 10) (2 4 6 8 10) ;-- would love to see some of the other macros that you all have written to enable debugging.. :) thanks, Sunil. -- 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: priority queue for scheduling events in the future
2010/11/24 HiHeelHottie : > > Does anybody know of an implementation for a priority queue that can > be used for scheduling events in the future? I would like to put a > map associated with a timestamp into the queue and be able to pull out > all maps at or before a given time in order. I would also recommend looking into the classes in java.util.concurrent, especially DelayQueue. http://download.oracle.com/javase/6/docs/api/java/util/concurrent/DelayQueue.html // raek -- 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: ANN: Gloss, a byte-format DSL
Hi
On 24 November 2010 04:43, Zach Tellman wrote:
> There are a couple of different things being discussed here. I don't
> think there's any harm in allowing maps as frames, as long as people
> understand that they're arbitrarily ordered (alphabetically by key,
> but that's an implementation detail) and that keys specified aren't
> optional - if they're not all there, the encoder will fail.
>
> The first issue you raised was that we might want to have finer
> control over how maps are encoded, so that we can ensure compatibility
> with C structs. This is true, but we still want the decoded versions
> of these ordered lists to be maps, because {:a 1, :b 2} is much more
> convenient than [:a 1 :b 2] or [[:a 1] [:b 2]].
>
> The second issue you're raising is backwards compatibility. It's
I don't think he's talking about backwards compatibility at all.
Assume you have two C structs that you need to interoperate with. The
first has a few fields and the second has many fields. If you specify
the format with a map, then when you serialise your Clojure data, the
smaller one will create the values in the order you specified in the
map. The larger one will be in some arbitrary order which depends on
Clojure's implementation and will likely not match up with the actual
struct definition.
Or to put it another way, say you have many structs. The first
several have few fields, so you happily use maps to specify them.
Everything works fine. Then you get to a larger struct and you find
that your fields land up in the wrong part of the serialised output.
I haven't looked at Gloss yet, so maybe this isn't possible for some reason?
> [...] I wrote the
> library mostly to help me write Redis and AMQP clients, but I'm hoping
> people will find it useful for a variety of purposes.
I have used Python's struct library a few times (and perl's
pack/unpack once or twice), so I'm sure Gloss would be useful for the
same sorts of things.
--
Michael Wood
--
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: ANN: ClojureQL 1.0.0 finally released as public beta
Hi Luke,
Thanks!
Initially CQL0.1 was motivated by "everything in Clojure" which was
the driving design principle behind the first version of CQL. When
I scrapped that project (for reasons you can read on my blog) I
instead turned my attention towards Relational Algebra as this
gives you unique ways to compose and express your queries, in
my opinion far superior to the SQL language itself.
Example from our test suite: Lets say you want to define a table
which computes an aggregate on a column, ex counting pictures
by user id and then join those stats to your users table. In CQL
you will (hopefully) intuitively write:
(let [photo-counts (-> (table :photos)
(aggregate [[:count/* :as :cnt]]
[:id])))]
(-> (table :users)
(join photo-counts (= {:users.id :photos.id}))
I think thats really as simple as you can express that join operation.
However for the SQL to work/be efficient, you need to detect when
a join benefits from spawning subselects and ClojureQL handles this
for you completely transparently, so if you execute the above
statement
the following is actually generated and run:
"SELECT users.*,photos_aggregation.cnt FROM users
LEFT OUTER JOIN
(SELECT photos.user_id,count(photos.*) AS cnt FROM photos GROUP BY
user_id)
AS photos_aggregation ON (users.user_id = photos_aggregation.user_id)"
And notice how your reference to :id in photos is automatically
aliased
to photos_aggregation. There are SQL statements which are truely
complex
and it takes a long time to master SQL and get comfortable with such
queries.
It is my ambition that ClojureQL will take away that complexity while
still
generating the most efficient SQL statements possible. The
implications for
Q/A on your projects will be substantial I hope.
And even if I was only doing CRUD - I'd prefer to do it (and have my
developers do it)
in Clojure, which is guaranteed to compile to correct SQL.
Answers your question?
Lau
On Nov 24, 1:56 am, Luke VanderHart wrote:
> Lau,
>
> This is really impressive, and I can't wait to experiment with it.
>
> That said, I'm curious as to what good use cases for this would be,
> and what it's motivation is. SQL is already a highly specialized DSL
> for slinging around relational data that most developers are already
> pretty good with. I'm wondering how useful it is to have a separate
> relational DSL. Is this motivated by the same "everything in Clojure"
> philosophy (like Hiccup or Scriptjure)? Not that there's anything
> wrong with that... I'm just curious as to use cases.
>
> Or does it confer some other benefit over SQL besides being Clojure?
> The only thing I see is the ability to reuse and compose fragments of
> relational logic. Unarguably, that is very cool, but off the top of my
> head I can't think of any particular benefit it would give, at least
> in my apps. 99% of my database interaction is a fixed set of CRUD
> operations, which (unless I'm missing something) would be just as easy
> to write in SQL directly.
>
> Thanks,
> -Luke
>
> On Nov 18, 2:10 pm, LauJensen wrote:
>
> > Hi gents,
>
> > For those of you who have followed the development
> > of ClojureQL over the past 2.5 years you'll be excited
> > to know that ClojureQL is as of today being released
> > as 1.0.0 beta1.
>
> > That means that the significant primitives from Relational
> > Algebra are all in place and functional. The documentation
> > is there and I've even made a screencast in order to get
> > you guys started.
>
> > Personally Im excited about this version because it really
> > does change the way you work with a database. Queries
> > are incredibly composable!
>
> > For more information, please checkout this blogpost +
> > screencast:http://bestinclass.dk/index.clj/2010/11/clojureql--1.0.0-now-in-beta
>
> > Best regards,
> > Lau
--
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: priority queue for scheduling events in the future
Mark, Is there a reason that you put the documentation in a comment rather than as the ns doc string so that autodoc would pick it up? Currently, priority queues are undiscoverable by autodoc users. Tom On Nov 23, 9:41 pm, Mark Engelberg wrote: > In 1.3, you can use clojure.contrib.priority-map. > Documentation found in comment at top of > source:https://github.com/clojure/clojure-contrib/blob/master/modules/priori... -- 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
