Re: Weird nested macro problem
Hi, On 2 Feb., 08:44, Ken Wesson kwess...@gmail.com wrote: This also means that macros should not use list? to test whether an object is a nonatomic s-expression. Unfortunately core doesn't contain a compact test for atomicity; to get all the list-y things that print as (foo bar baz ...) you can use something like (and (coll? x) (not (or (vector? x) (map? x) (set? x))) which should return logical true only when x is list-y. Wrap that in a predicate function and use it in your macros in place of list?. seq? should just do fine, since lists are their own seq. coll? just checks for IPersistentCollection. Why should that hint to list-y printing? All in all, this casts another question mark on this style of programming, IMHO. 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: AOP in Clojure
I think what a Ring middleware[1] does might be very close what you want to do with AOP. Clojure has a natural way to decorate an existing body of code using higher order functions and macros. [1] http://github.com/mmcgrana/ring Could you share some use cases that you want to achieve with AOP? Regards, Shantanu On Feb 2, 6:09 pm, Nebojsa Stricevic nebojsa.strice...@gmail.com wrote: Hi, Are there any general purpose libraries/frameworks with nice API/DSL for Aspect Oriented Programming for Clojure? Or is there someone working on it? Is it needed? Possible? Cheers, -- 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: AOP in Clojure
On Feb 2, 2:09 pm, Nebojsa Stricevic nebojsa.strice...@gmail.com wrote: Hi, Are there any general purpose libraries/frameworks with nice API/DSL for Aspect Oriented Programming for Clojure? Or is there someone working on it? Is it needed? Possible? I agree with Shantanu and feel that Ring is a nice example of AOP behaviour using functions. For a general purpose library you may find Robert Hooke useful: https://github.com/technomancy/robert-hooke 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
java.io.IOException with compile
Hello, What's wrong with this example? $ cat testlongname/editor/controller/listeners/ swing_test_listeners.clj (ns testlongname.editor.controller.listeners.swing-test-listeners (:use clojure.contrib.monads)) (defn some-long-function-name-abdefghijklmnopqrstuvxwyz- abdefghijklmnopqrstuvxwyz-abdefghijklmnopqrstuvxwyz- abdefghijklmnopqrstuvxwyz-abdefghijklmnopqrstuvxwyz- abdefghijklmnopqrstuvxwyz-abdefghijklmnopqrstuvxwyz- abdefghijklmnopqrstuvxwyz- [x] ;; (domonad maybe-m ;; [a 10 ;; b 12 ;; c 13] ;; (prn )) ) [ /tmp/testlongname/src]$ lein repl REPL started; server listening on localhost:34076. user= (compile 'testlongname.editor.controller.listeners.swing-test- listeners) java.io.IOException: File name too long (swing_test_listeners.clj:4) I know the function name is absurdly long but this is just to illustrate the problem. I'm having the same problem on a real project where the function name is shorter but with some closures define in its scope. Is there a workaround? -- 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: java.io.IOException with compile
Hi, I'll just throw a wild guess into the room and say that your filename hits the filename limit imposed by the file system of your system. 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: how to print-dup records?
Ive just thought up that using print-dup for records might become a nightmare. This is because it will now matter which ns you load it from. If it loads an ns where the constructor function isnt defined or isnt imported, it will throw an error. This will become a nightmare when mixes records from various nses. A possible solution would be to create a generic function, called new-record, which takes the ns and the constructor function (find-ns ns-of-function function-symbol) and then call that. Pretty simple. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: how to print-dup records?
Hi, why don't you just fully qualify the constructor function? Works from everywhere. 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: Weird nested macro problem
Thanks. That is indeed what fixed it! And macroexpand (and pr in general) should have an option to mark what is a list and what is a cons thingy. That is confusing. On Feb 2, 2011, at 1:48 AM, George Jahad wrote: As usual, Meikel has the right answer. But I didn't quite get it at first. It looks like syntax-quote generates cons's, not lists: user (type (nth `(handler-case :type (println test) (~'handle foo)) 3)) clojure.lang.Cons Your macroexpand-1 example worked because the reader doesn't distinguish between cons's and lists. Because handler-case is expecting a list and syntax-quote won't generate one, you'll have to write your macro like this: (defmacro test-failure [ forms] `(handler-case :type ~@forms ~(list 'handle :error/error '(println error happened Finally, a shameless plug: you could have used the cdt, or debug-repl to set a break around line 92 and figure it out yourself. That's what I did. On Feb 1, 2:31 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, the failing part is actually not the comparison of the symbols, but the check for listness. user= (list? (nth `(handler-case :type (println test) (~'handle foo)) 3)) false user= (seq? (nth `(handler-case :type (println test) (~'handle foo)) 3)) true 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 -- 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: a handy little function I haven't seen before
FYI: There is clojure.contrib.repl-utils/show -- 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
java interop question
I am doing some prototyping with the event processing framework Esper (http://esper.codehaus.org/) and I'm running up against my ignorance of clojure/java interop. I would like to create a java bean in clojure that is visible to the Esper runtime; I found some sample Java code that I clojurized as follows: (ns cepdemo.core (:import [com.espertech.esper.client Configuration UpdateListener EPServiceProviderManager EPRuntime])) (defrecord Tick [symbol price timestamp]) (defn generate-random-tick [runtime] (let [price (rand-int 10) timestamp (java.util.Date.) symbol AAPL tick (Tick. symbol price timestamp)] (print Sending tick: tick) (.sendEvent runtime tick))) (defn cep-listener [] (proxy [UpdateListener] [] (update [new-data old-data] (print event received: new-data (defn config [] (let [cep-config (Configuration.)] (.addEventType cep-config StockTick (.getName Tick)) (let [cep-sp (EPServiceProviderManager/getProvider myCEPEngine cep-config) cep-rt (.getEPRuntime cep-sp) cep-admin (.getEPAdministrator cep-sp) cep-statement (.createEPL cep-admin select * from StockTick(symbol='AAPL').win:length(2) having avg(price) 6.0)] (.addListener cep-statement cep-listener) (doseq [i (range 10)] (generate-random-tick cep-rt) The error I get is: Property named 'symbol' is not valid in any stream [select * from StockTick(symbol='AAPL').win:length(2) having avg(price) 6.0] from which I conclude that defrecord may not be the way to create a java bean. Do I need to use gen-class? -- 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: java.io.IOException with compile
You surely mean that swing_test_listeners $some_long_function_xyx_.class is too long. On Feb 2, 6:51 am, Meikel Brandmeyer m...@kotka.de wrote: Hi, I'll just throw a wild guess into the room and say that your filename hits the filename limit imposed by the file system of your system. 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: a handy little function I haven't seen before
show's a very cool function, but has a different purpose, (afaik).
It displays the structure of an instance, but not it's contents. get-
all-fields displays the contents. For example, if a is defined like
so:
(def a (partial conj [98]))
get-all-fields will show me that the parameters to partial, f and
arg1, are conj and [98] respectively:
(pprint (get-all-fields a))
{:__meta {:line 2009},
:arg1 [98],
:const__0 #Var@6b28215d: #core$apply clojure.core$apply@39bb49e2,
:f #core$conj clojure.core$conj@1548d6e2}
On Feb 2, 7:36 am, Miki miki.teb...@gmail.com wrote:
FYI: There is clojure.contrib.repl-utils/show
--
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: java.io.IOException with compile
Hi, Am 02.02.2011 um 17:30 schrieb Armando Blancas: You surely mean that swing_test_listeners $some_long_function_xyx_.class is too long. Yes. This is what I implied. 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: a handy little function I haven't seen before
George this is super cool! I can't wait to see this show up in swank-clojure
*ahem* Phil.
On Feb 2, 2011, at 12:03 PM, George Jahad wrote:
show's a very cool function, but has a different purpose, (afaik).
It displays the structure of an instance, but not it's contents. get-
all-fields displays the contents. For example, if a is defined like
so:
(def a (partial conj [98]))
get-all-fields will show me that the parameters to partial, f and
arg1, are conj and [98] respectively:
(pprint (get-all-fields a))
{:__meta {:line 2009},
:arg1 [98],
:const__0 #Var@6b28215d: #core$apply clojure.core$apply@39bb49e2,
:f #core$conj clojure.core$conj@1548d6e2}
On Feb 2, 7:36 am, Miki miki.teb...@gmail.com wrote:
FYI: There is clojure.contrib.repl-utils/show
--
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: Weird nested macro problem
On Wed, Feb 2, 2011 at 3:22 AM, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 2 Feb., 08:44, Ken Wesson kwess...@gmail.com wrote: This also means that macros should not use list? to test whether an object is a nonatomic s-expression. Unfortunately core doesn't contain a compact test for atomicity; to get all the list-y things that print as (foo bar baz ...) you can use something like (and (coll? x) (not (or (vector? x) (map? x) (set? x))) which should return logical true only when x is list-y. Wrap that in a predicate function and use it in your macros in place of list?. seq? should just do fine, since lists are their own seq. coll? just checks for IPersistentCollection. Why should that hint to list-y printing? Combining coll? with (not (or (vector?) (map?) (set?))) eliminates the other three types of coll and leaves seqs and lists. Oddly, I seem to remember having had to work around a lack of seq? previously, yet it says on the API page that it's been there since 1.0. Or perhaps it was the larger problem of determining if something will work with (seq x) that was lacking built-in API... It does indeed seem that seq? on lists returns true, so it looks like you can just use that instead of list? in macros to check for (foo ...) s-expressions. -- 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: a handy little function I haven't seen before
Actually, you should thank hiredman, for adding the original wall-hack-
field. I just wrapped some lipstick around it.
On Feb 2, 9:40 am, Dan Larkin d...@danlarkin.org wrote:
George this is super cool! I can't wait to see this show up in swank-clojure
*ahem* Phil.
On Feb 2, 2011, at 12:03 PM, George Jahad wrote:
show's a very cool function, but has a different purpose, (afaik).
It displays the structure of an instance, but not it's contents. get-
all-fields displays the contents. For example, if a is defined like
so:
(def a (partial conj [98]))
get-all-fields will show me that the parameters to partial, f and
arg1, are conj and [98] respectively:
(pprint (get-all-fields a))
{:__meta {:line 2009},
:arg1 [98],
:const__0 #Var@6b28215d: #core$apply clojure.core$apply@39bb49e2,
:f #core$conj clojure.core$conj@1548d6e2}
On Feb 2, 7:36 am, Miki miki.teb...@gmail.com wrote:
FYI: There is clojure.contrib.repl-utils/show
--
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
Deflayout - define Swing UI declaratively
Since defining the UI in Clojure is pretty tedious process, even with all nice interop features, I decided to write a small library to do this more easily and in a declarative way. I was inspired by a series of blogposts by Stuart Sierra, he wrote a wonderful macro that deals with GridBagLayout. But often you don't need that complex layout, any simpler layout will do. So I spent an evening writing this https://github.com/alexander-yakushev/deflayout . Currently only BorderLayout and FlowLayout are supported, but layouts can be added easily. I wanted somebody to look at the code and give the opinion about what can be done better and what changes can be made. Usage of the lib is very easy. Here is an example from my tetris game: (deflayout frame (:border) :WEST gamepanel :EAST (deflayout sidepanel (:flow :TRAILING) nextpanel (JButton. Exit))) In this example we define, that the frame will use BorderLayout and add two panels - one on the west side, and second one on the east one. Sidepanel that we add is the macro call itself, with FlowLayout and two elements added - another panel and a button. As you see, the macro executes the code differently based on which layout is used. Thus, when the BorderLayout is used, arguments are read by pairs where the first argument is position and the second is the object. Instead, in FlowLayout all objects are just passed sequentially. I will surely extend this macro to cover all other layouts, but I need some of the guidance and recommendations. Also, I would be happy if Stuart Sierra allowed me to include his GridBagLayout code into the lib. -- 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: AOP in Clojure
Thanks for these answers. I forgot about Robert Hooke, although I've seen it already. I don't have a real use case yet. I'm researching Domain Specific Languages composition/combining, so AOP could be useful. I've checked some Clojure tracing code, I'll dig into Ring more and Robert Hooke looks very useful. Greets, -- Nebojša Stričević -- 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
extend-protocol with defrecord
Hi All,
I've found extending-protocol to hold on to a references to records when
they're redefined.
example (defprotocol ToExtend
(foo [this]))
ToExtend
example (defrecord Extender1 [])
example.Extender1
example (extend-protocol ToExtend Extender1 (foo [this] extender1))
nil
example ToExtend
{:impls {example.Extender1 {:foo #example$eval3465$fn__3466
example$eval3465$fn__3466@5549f0e}}, :on-interface example.ToExtend, :on
example.ToExtend, :sigs {:foo {:doc nil, :arglists ([this]), :name foo}},
:var #'example/ToExtend, :method-map {:foo :foo}, :method-builders
{#'example/foo #example$eval3417$fn__3418 example$eval3417$fn__3418@71a67fe
}}
example (count (:impls ToExtend))
1
example (defrecord Extender1 [a])
example.Extender1
example (foo (Extender1. a))
No implementation of method: :foo of protocol: #'example/ToExtend found for
class: example.Extender1
[Thrown class java.lang.IllegalArgumentException]
example (extend-protocol ToExtend Extender1 (foo [this] extender1a))
nil
example (foo (Extender1. a))
extender1a
example ToExtend
{:impls {example.Extender1 {:foo #example$eval3519$fn__3520
example$eval3519$fn__3520@4d86d315}, example.Extender1 {:foo
#example$eval3465$fn__3466 example$eval3465$fn__3466@5549f0e}},
:on-interface example.ToExtend, :on example.ToExtend, :sigs {:foo {:doc nil,
:arglists ([this]), :name foo}}, :var #'example/ToExtend, :method-map {:foo
:foo}, :method-builders {#'example/foo #example$eval3417$fn__3418
example$eval3417$fn__3418@71a67fe}}
example (count (:impls ToExtend))
2
You'll notice in the map returned after the second (extend-protocol) that
:impls has example.Extender1 listed twice. I assume this is because they're
different records, though the fact that they share the same name is
confusing (hence the example of the exception being thrown).
A few questions:
- Is this expected behaviour?
- If so, why? It feels odd to have two classes of the same name (type
even?) act differently
In the other examples of extend-protocol being used
(compojure.response/Renderable) types far less likely to be redefined are
being used, so perhaps this is only to be used with types that change less?
If that is the case then how does one achieve what I'm trying to do; extend
Renderable to support my own types being passed to it without Renderable
acting on my previous types?
Cheers,
mike
--
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: extend-protocol with defrecord
Michael Ossareh ossa...@gmail.com writes: You'll notice in the map returned after the second (extend-protocol) that :impls has example.Extender1 listed twice. I assume this is because they're different records, though the fact that they share the same name is confusing (hence the example of the exception being thrown). A few questions: - Is this expected behaviour? - If so, why? It feels odd to have two classes of the same name (type even?) act differently This has to be the case as you might have instances of the old version of the class hanging around, which you could call protocol functions on. The JVM doesn't let you modify existing classes in place (for obvious reasons: what is it supposed to do if you changed the primitive type of a field). All you can do is load a new one (possibly with the same name) and then create some new instances with that new class. In the other examples of extend-protocol being used (compojure.response/Renderable) types far less likely to be redefined are being used, so perhaps this is only to be used with types that change less? If that is the case then how does one achieve what I'm trying to do; extend Renderable to support my own types being passed to it without Renderable acting on my previous types? Could you rephrase this? I'm not sure I understand what you're trying to achieve. The dynamic redefinition features are supposed to be used for solely as handy hack for interactive development. So if your environment gets messed up too much you can just reload everything in a fresh JVM. In a finished program redefinition should never occur. -- 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: Helper functions for accessing properties in clojure-clr 1.2.0
On Feb 1, 6:10 pm, Matthew D. Swank akopa.gmane.pos...@gmail.com wrote: AFAIK clojure-clr doesn't have built-in support for accessing properties. Ok David Miller let me know off list the existing interop handle properties. -- 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: extend-protocol with defrecord
On Wed, Feb 2, 2011 at 18:49, Alex Osborne a...@meshy.org wrote: Michael Ossareh ossa...@gmail.com writes: You'll notice in the map returned after the second (extend-protocol) that :impls has example.Extender1 listed twice. I assume this is because they're different records, though the fact that they share the same name is confusing (hence the example of the exception being thrown). A few questions: - Is this expected behaviour? - If so, why? It feels odd to have two classes of the same name (type even?) act differently This has to be the case as you might have instances of the old version of the class hanging around, which you could call protocol functions on. The JVM doesn't let you modify existing classes in place (for obvious reasons: what is it supposed to do if you changed the primitive type of a field). All you can do is load a new one (possibly with the same name) and then create some new instances with that new class. Ahh, as proven here: example (defprotocol Extended (foo [this])) Extended example (defrecord Extender []) example.Extender example (extend-protocol Extended Extender (foo [this] first)) nil example (def x (Extender.)) #'example/x example (foo x) first example (defrecord Extender [a]) example.Extender example (extend-protocol Extended Extender (foo [this] (:a this))) nil example (foo x) first example (foo (Extender. second)) second This is clearly quite cool and I'm now interested in more! In the other examples of extend-protocol being used (compojure.response/Renderable) types far less likely to be redefined are being used, so perhaps this is only to be used with types that change less? If that is the case then how does one achieve what I'm trying to do; extend Renderable to support my own types being passed to it without Renderable acting on my previous types? Could you rephrase this? I'm not sure I understand what you're trying to achieve. The dynamic redefinition features are supposed to be used for solely as handy hack for interactive development. So if your environment gets messed up too much you can just reload everything in a fresh JVM. In a finished program redefinition should never occur. Thanks for asking me to step back and think about it - you're right - it is clear to me now - this caught me out as a result of repl based work and stray references. -- 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.comclojure%2bunsubscr...@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: Helper functions for accessing properties in clojure-clr 1.2.0
Specifically, in ClojureCLR property access in CLR interop is treated in the same way as fields and zero-arity methods. For class properties, ClassName/PropertyName works. For instance properties, (.PropertyName instance) or (. instance PropertyName) In essence, fields, properties and zero-arity methods are referenced in the same way, and are checked in this order. You can also access the getter/setter methods of a property directly. (get_PropertyName and (set_PropertyName) Where properties are not handled is in type/interface specification/ implementation. Specifically, places that allow method definition (gen-interface and company) and places that allow method definition (deftype and company) do not allow specification of properties. Technically, this is quite easy. The difficutly is that the syntax of these macros typically do not make it easy to distinguish the intent of defining properties versus defining zero-arity methods. This is discussed more fully at https://github.com/richhickey/clojure-clr/wiki/Extending-deftype-and-company-for-CLR. I still need to come up with a good mechanism for referring to events. Suggestions welcomed. --David On Feb 2, 9:09 pm, Matthew D. Swank akopa.gmane.pos...@gmail.com wrote: On Feb 1, 6:10 pm, Matthew D. Swank akopa.gmane.pos...@gmail.com wrote: AFAIK clojure-clr doesn't have built-in support for accessing properties. Ok David Miller let me know off list the existing interop handle properties. -- 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
ClojureCLR: change in naming/location of AOT-compiled assemblies
I've made a change to the naming and location of AOT-compiled assemblies generated by ClojureCLR. Previously, ClojureCLR had followed the conventions of ClojureJVM in naming/locating class files (assemblies in CLR-land) generated by AOT- compilation. Thus, doing (compile 'a.b.c) would find source file AppBase\a\b\c.clj and generate AppBase\a\b\c.clj.dll. In the lastest commit, this has been changed so that (compile 'a.b.c) will find source file AppBase\a\b\c.clj and generate AppBase \a.b.c.clj.dll. Obviously, this change will force recompilation of existing apps. Otherwise, it should have no effect. Completely arbitrarily, ClojureCLR names the AOT-compilation generated files whatever.clj.dll. The .clj. is superfluous, but does serve as a visual indication of the assembly's origin. Question: Useful, or just annoying? Unnecessary explanation: The reason for the change has to do with limitations of assembly loading. As previously coded, (compile 'a.b.c) would generate AppBase\a\b.c.clj.dll and (compile 'd.e.c) would generate AppBase\d \e\c.clj.dll. There are circumstances where the latter would not compile but might load the former instead. This has to do with name resolution in the load-from context in assembly loading, which does not consider location. The simplest solution was to encode namespace information i the filename, so assemblies can be differentiated by file name instead of location. -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
Anyone want to take a crack at making the fasta shootout program faster?
I've done a pass through most of the Clojure programs on the shootout web site recently, making some of them faster, and choosing -Xmx command line arguments when running them to keep the memory usage down to a reasonable level -- not always the smallest heap size that works, mind you -- just one that avoids exorbitantly large memory usage. http://shootout.alioth.debian.org The Clojure program for the fasta problem, with source code, AOT compilation command, and execution command given on this web page: http://shootout.alioth.debian.org/u32/program.php?test=fastalang=clojureid=3 still takes about 6x to 8x more time than the best Java 6 -server program here, depending upon which of the four machines it is run on: http://shootout.alioth.debian.org/u32/program.php?test=fastalang=javaid=3 I'm sure the Clojure program can be made faster, e.g. by doing fewer calls to write to the output file, with more bytes per call. Most of the time seems to be file writing and generating random numbers in gen- random!, at least on my systems where I've done testing and profiling. I'm also seeing a fair amount of time spent in calls to java.lang.Double.valueOf, according to the built-in profiler that comes with the Hotspot JVM. Note: The web site is Clojure 1.2 only right now, so don't expect a tweaked-out program using things that only work in Clojure 1.3 to work there yet. Other tips: + Test your program by comparing its output to the Java program with the same command line args. The Java program isn't guaranteed to be bug free, but it has been tested a fair amount. + If you decide to submit, please take some time to select a -Xmx max heap size argument that gives a good tradeoff between low memory use and not too much extra time spent doing GC because of it. I've got some scripts to help automate finding such a value if you are interested, and I'd even volunteer to run them for you if you send me your program. Still, it is straightforward to do by hand, too -- no rocket science involved. You are of course free to work on any of the problems you wish, but I just wanted to point out this one as being what I consider a bit stubborn to squeeze down the run time. Andy -- 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
Why take-last of empty collection is nil?
Should not it be empty colection instead?
It seems odd to me since it is inconsistent and forces to consider one
more case (nil or collection).
And another question. I have written this function
(defn index-by
Make map (f x) - x
[f coll]
(reduce #(assoc %1 (f %2) %2) {} coll))
I wonder, is there already such function somewhere in Clojure libraries?
--
Petr Gladkikh
--
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: Why take-last of empty collection is nil?
Hi,
On 3 Feb., 08:04, Petr Gladkikh petrg...@gmail.com wrote:
Should not it be empty colection instead?
It seems odd to me since it is inconsistent and forces to consider one
more case (nil or collection).
It is consistent. There is a difference between () and nil. () is the
empty list. However there is no empty sequence. Either there is
something or there is nothing. Why would you have to check for nil?
You can pass nil to any of the sequence library functions without fear
of harm. When you write such a function yourself, there is usually a
single check in the beginning when realising the sequence. Something
like (when-let [s (seq coll)] ...).
I never encountered any problems with this. Do you have a concrete
example where this causes trouble for you?
And another question. I have written this function
(defn index-by
Make map (f x) - x
[f coll]
(reduce #(assoc %1 (f %2) %2) {} coll))
I wonder, is there already such function somewhere in Clojure libraries?
You are probably looking for group-by, although it's slightly
different in that it collects all pre-images of a value (f x) in case
your function is not injective.
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: Deflayout - define Swing UI declaratively
On Feb 2, 7:43 pm, Alexander Yakushev yakushev.a...@gmail.com wrote: Usage of the lib is very easy. Here is an example from my tetris game: (deflayout frame (:border) :WEST gamepanel :EAST (deflayout sidepanel (:flow :TRAILING) nextpanel (JButton. Exit))) I haven't done any Swing programming in Clojure yet but this looks really cool. It looks much nicer than the standard Java API I struggled with a few years ago. 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
Re: Why take-last of empty collection is nil?
On Thu, Feb 3, 2011 at 2:31 AM, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 3 Feb., 08:04, Petr Gladkikh petrg...@gmail.com wrote: Should not it be empty colection instead? It seems odd to me since it is inconsistent and forces to consider one more case (nil or collection). It is consistent. There is a difference between () and nil. () is the empty list. However there is no empty sequence. According to Clojure 1.2 itself, there is: user= (seq? ()) true The empty list is both, it seems. :) However, user= (seq ()) nil so (if-let [s (seq x)] ...) still works to separate empty lists (indeed, all empty colls) from non-empty ones. Also of interest is user= (seq? nil) false The sequence functions accept it nonetheless, and most accept vectors, sets, and maps as well. In particular: user= (nth nil 42) nil user= (nth nil 42 not found) not found -- 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
