lazy-xml/emit does not pad deeply
Hi,
user=> (use 'clojure.contrib.lazy-xml)
nil
user=> (emit '{:tag :foo :attrs {:a "b" :c "d"} :content
({:tag :bar :attrs {:e "f"} :content ({:tag :baz :attrs nil :content
("hello")})})} :pad true)
hello
nil
The 'foo' element is getting the requested padding, but it does not
propagate to the nested elements.
I believe line 150 of lazy-xml.clj should read,
(apply emit-element c opts)
to fix this.
Regards,
Phil
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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
-~--~~~~--~~--~--~---
cloggle: OpenGL library for Clojure
It's essentially a thin wrapper on JOGL, but I intend to improve the interface in future. http://github.com/ChickenProp/cloggle/tree/master Clojure, the JVM and opengl are all fairly new to me, so I'd appreciate feedback about my coding style, potential pitfalls, and anything else you can think of. cloggle itself is currently less than 60 lines, including blanks and comments. This is a horrible speed metric, but the example "gears" program (based on one posted here a while ago) runs at 240fps for me, compared to 515fps for glxgears. --~--~-~--~~~---~--~~ 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 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: cloggle: OpenGL library for Clojure
On May 10, 12:37 am, David Nolen wrote: > Cool, I couldn't get this to work, I get an exception like the following: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: > wrong number of arguments Is this with gears.clj? Could you post a full backtrace and relevant software versions? This looks like the sort of error that might be caused by the second bug listed in the README, but I'd like to confirm that. (Not that that bug doesn't need fixing either way.) > > The original version works alright for me. > > Also you should organize the library folder in the standard way so that your > library can be loaded without tweaking: > > /src/net/philh/cloggle.clj That's a good point, I'll fix it now. Though I'm not sure how I'll organise things for git if I want to write another library - do you know of a better way than to have a separate src/net/philh directory in each library's tree? > > On Sat, May 9, 2009 at 4:05 PM, philip.hazel...@gmail.com < > > philip.hazel...@gmail.com> wrote: > > > It's essentially a thin wrapper on JOGL, but I intend to improve the > > interface in future. > > >http://github.com/ChickenProp/cloggle/tree/master > > > Clojure, the JVM and opengl are all fairly new to me, so I'd > > appreciate feedback about my coding style, potential pitfalls, and > > anything else you can think of. cloggle itself is currently less than > > 60 lines, including blanks and comments. > > > This is a horrible speed metric, but the example "gears" program > > (based on one posted here a while ago) runs at 240fps for me, compared > > to 515fps for glxgears. --~--~-~--~~~---~--~~ 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 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: cloggle: OpenGL library for Clojure
8)
> at java.awt.Component.dispatchEventImpl(Component.java:4144)
> at java.awt.Component.dispatchEvent(Component.java:3903)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
> at
> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Thank you. This does indeed appear to be caused by that bug. I think
I've worked out a reasonable way to fix it, but in the meantime I've
inserted a workaround into gears.clj. Could you test the new version?
I would also be interested in seeing the output of
(map #(cons (.getName %) (seq (.getParameterTypes %)))
(filter #(#{"glLightfv" "glMaterialfv"} (.getName %))
(seq (.getDeclaredMethods javax.media.opengl.GL
>
> On Sat, May 9, 2009 at 10:02 PM, philip.hazel...@gmail.com <
>
> philip.hazel...@gmail.com> wrote:
>
> > On May 10, 12:37 am, David Nolen wrote:
> > > Cool, I couldn't get this to work, I get an exception like the following:
> > > Exception in thread "AWT-EventQueue-0"
> > java.lang.IllegalArgumentException:
> > > wrong number of arguments
>
> > Is this with gears.clj? Could you post a full backtrace and relevant
> > software versions? This looks like the sort of error that might be
> > caused by the second bug listed in the README, but I'd like to confirm
> > that. (Not that that bug doesn't need fixing either way.)
>
> > > The original version works alright for me.
>
> > > Also you should organize the library folder in the standard way so that
> > your
> > > library can be loaded without tweaking:
>
> > > /src/net/philh/cloggle.clj
> > That's a good point, I'll fix it now. Though I'm not sure how I'll
> > organise things for git if I want to write another library - do you
> > know of a better way than to have a separate src/net/philh directory
> > in each library's tree?
>
> > > On Sat, May 9, 2009 at 4:05 PM, philip.hazel...@gmail.com <
>
> > > philip.hazel...@gmail.com> wrote:
>
> > > > It's essentially a thin wrapper on JOGL, but I intend to improve the
> > > > interface in future.
>
> > > >http://github.com/ChickenProp/cloggle/tree/master
>
> > > > Clojure, the JVM and opengl are all fairly new to me, so I'd
> > > > appreciate feedback about my coding style, potential pitfalls, and
> > > > anything else you can think of. cloggle itself is currently less than
> > > > 60 lines, including blanks and comments.
>
> > > > This is a horrible speed metric, but the example "gears" program
> > > > (based on one posted here a while ago) runs at 240fps for me, compared
> > > > to 515fps for glxgears.
--~--~-~--~~~---~--~~
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
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: Override the + operator for a 'struct'
On May 17, 1:14 am, "Michel S." wrote: > In Clojure, it is possible to do the former -- (def orig+ +) -- but it > appears that overriding a clojure.core definition is not possible. I'd > love to be wrong on this, though. > > user=> (def + -) > java.lang.Exception: Name conflict, can't def + because namespace: > user refers to:#'clojure.core/+ (NO_SOURCE_FILE:5) This just means you can't create user/+. What you can do is redefine clojure.core/+. user=> (def clojure.core/+ -) java.lang.Exception: Can't create defs outside of current ns (NO_SOURCE_FILE:1) user=> (in-ns 'clojure.core) # clojure.core=> (def + -) #'clojure.core/+ clojure.core=> (in-ns 'user) # user=> (+ 3 1) 2 I'm sure this is something you should avoid, especially given the other solutions. But the option is there. --~--~-~--~~~---~--~~ 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 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: Help with Math Question
On Jun 4, 6:23 am, CuppoJava wrote: > Hey guys, > I'm really stuck on this math question, and I'm wondering if you guys > know of any links that may help me. > > Given: f(x,y), a0, a list of numbers v. > Find: g(x,y) and b0 such that: > > (reduce f a0 v) = (reduce g b0 (reverse v)) > > Thanks for your help > -Patrick This might be a cop-out, but: g(x, y) = x, and b0 = (reduce f a0 v). If that's not an adequate answer, could you provide more background? I don't think there's a general-case solution that works if v is not known, but that's purely intuitive. I don't know how to prove it, or even argue it convincingly. (Maybe I'll give that a go while I should be revising...) Mark Reid's solution works if f is commutative and associative. --~--~-~--~~~---~--~~ 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: Help with Math Question
On Jun 4, 3:00 pm, CuppoJava wrote: > Hey guys. > Thanks for the help. I have to clarify my question a bit. > > f(x,y) and a0 are given and do not assume any properties. > Find g(x,y) and b0, such that for *any* list of numbers v, > > (reduce f a0 v) = (reduce g b0 (reverse v)) This is not always possible. Proof: assume, for some f and a, that we have the requisite g and b. Suppose a is such that (f a x) = x for any x. Case one: v = [v1]. It follows that (f a v1) = (g b v1) = v1. Case two: v = [v1 v2]. Then (f (f a v1) v2) = (f v1 v2) = (g (g b v2) v1) = (g v2 v1). Case three: v = [v1 v2 v3]. Then (f (f (f a v1) v2) v3) = (g (g (g b v3) v2) v1) (f (f v1 v2) v3) = (g (g v3 v2) v1) = (g (f v2 v3) v1) = (f v1 (f v2 v3)), for any v1, v2, v3. So f is associative. Thus, if f is not associative, either (f a x) != x for some x, or no such g, b exist. OTOH, if f is associative and we have (f a x) = x, then g = (flip f) works with b = a. I haven't been able to prove the existence or nonexistence of such g, b in other cases of f, a yet. I suspect f is required to be associative regardless of the value of a. > > -- > > In case it helps at all, my specific problem is like this: > > v is a list of number pairs. > v = [ [1 1] [0.5 1] [0.1 1] [0.3 3] ] > a0 = [0 0] > > and f = > (fn [[c2 a2] [c a]] > [(+ c (* (- 1 a) c2)) a2]) This makes things much simpler, yes. I haven't analysed this function mathematically, so I can't say whether it's possible under the given constraints. But it might be, which is probably better than a "no". And it will be easier to prove things about this specific function than about all functions. > > It's the formula I'm using for blending translucent pixels on top of > each other. > Currently I'm drawing back to front and accumulating the color with > the above function. > > But for optimization purposes, it's much better to render front to > back and take advantage of an early exit condition. But for that, I > need a inverse-reduce function g(x,y), which is how this question > popped into my head. Does it have to be (reduce f a0 v) = (reduce g b0 (reverse v))? It might be simpler if it were (reduce f (cons a0 v)) = (reduce g (reverse (cons b0 v))). Does the early exit condition depend on f/g, or might it be possible to have g simply collect values of (reverse v), and then later pass them to f? What little I know of the subject makes me suspect the answers are both "yes it does", but it can't hurt to ask. > > Thanks so much for the help > -Patrick --~--~-~--~~~---~--~~ 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: pprint
On Jul 1, 9:52 am, Laurent PETIT wrote:
> As far as IDE integration is concerned, i would not bother (at first)
> about incremental thing. I rather intend to always parse the entire
> edited file content (of course if this causes a performance problem, I
> might rethink about it). For performance testing, I've found that
> clojure/core.clj is a good candidate :-)
You may have considered this already, but always reparsing the whole
file will make things interesting when the code is in an invalid state
during editing. Top-level forms will look like they're several levels
deep, potentially in places they really shouldn't be.
Depending on what you do with the information, that might not be a
problem. And there's certainly something to be said for starting with
the simplest possible implementation. But for a more powerful
approach, it's possible to use information from the user's typing to
work out "this ( is probably unmatched, and the next ) is closing the
preceeding (".
Source:
http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/
(You can probably scroll down to "on a whim".)
-Phil
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Adding type hint causes compiler error
Hi, The following code works as expected: (import 'javax.imageio.ImageIO 'java.io.File 'java.awt.image.BufferedImage) (defn bi-get-pixels [bi] (vec (.. bi (getData) (getPixels 0 0 (.getWidth bi) (.getHeight bi) nil (bi-get-pixels (. ImageIO read (File. "/home/phil/prog/small- test.png"))) But if *warn-on-reflection* is true, it generates four warnings. If we try to shut it up with a type hint: (defn bi-get-pixels [#^BufferedImage bi] (vec (.. bi (getData) (getPixels 0 0 (.getWidth bi) (.getHeight bi) nil Exception in thread "main" java.lang.IllegalArgumentException: More than one matching method found: getPixels (imagio-test.clj:7) at clojure.lang.Compiler.analyzeSeq(Compiler.java:4558) ... Caused by: java.lang.IllegalArgumentException: More than one matching method found: getPixels at clojure.lang.Compiler.getMatchingParams(Compiler.java:2122) at clojure.lang.Compiler$InstanceMethodExpr. (Compiler.java:1159) at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java: 810) at clojure.lang.Compiler.analyzeSeq(Compiler.java:4551) ... 34 more The problem here is that getPixels has three forms: ( http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/Raster.html ) double[] getPixels(int x, int y, int w, int h, double[] dArray) Returns a double array containing all samples for a rectangle of pixels, one sample per array element. float[]getPixels(int x, int y, int w, int h, float[] fArray) Returns a float array containing all samples for a rectangle of pixels, one sample per array element. int[] getPixels(int x, int y, int w, int h, int[] iArray) Returns an int array containing all samples for a rectangle of pixels, one sample per array element. In each case, if the final argument is NULL it is ignored, and if not the array is populated with the return data from the call (generating an error if it's not large enough). Is it possible to specify which invocation of getPixels I intend without passing an array? I've tried putting #^ints in some likely- looking places, but nil can't be type-hinted and the others seem to have no effect. I've also tried splitting the .. up: (defn bi-get-pixels [#^BufferedImage bi] (let [rast (.getData bi) #^ints pi (.getPixels rast 0 0 (.getWidth bi) (.getHeight bi) nil)] pi)) But this doesn't work either. I could do manual reflection on Raster to get the correct method and .invoke it, but that seems far more complicated than necessary. Any other ideas? -Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Adding type hint causes compiler error
On Jul 5, 10:31 pm, Mark Triggs wrote: > (defn bi-get-pixels > [#^BufferedImage bi] > (let [raster (.getData bi) > pixels (.getPixels raster 0 0 (.getWidth bi) (.getHeight bi) > (cast (Class/forName "[I") nil))] > (vec pixels))) This still generates a single reflection warning, but #^ints before the cast fixes it. That gave me an idea: (defn bi-get-pixels [#^BufferedImage bi] (vec (.. bi (getData) (getPixels 0 0 (.getWidth bi) (.getHeight bi) #^ints (identity nil) Which does the right thing with no warnings. Thanks for the help, -Phil > > Cheers, > > Mark > > On Jul 5, 10:18 pm, "philip.hazel...@gmail.com" > > wrote: > > Hi, > > > The following code works as expected: > > > (import 'javax.imageio.ImageIO 'java.io.File > > 'java.awt.image.BufferedImage) > > (defn bi-get-pixels > > [bi] > > (vec (.. bi (getData) (getPixels 0 0 (.getWidth bi) (.getHeight bi) > > nil > > (bi-get-pixels (. ImageIO read (File. "/home/phil/prog/small- > > test.png"))) > > > But if *warn-on-reflection* is true, it generates four warnings. If we > > try to shut it up with a type hint: > > > (defn bi-get-pixels > > [#^BufferedImage bi] > > (vec (.. bi (getData) (getPixels 0 0 (.getWidth bi) (.getHeight bi) > > nil > > > Exception in thread "main" java.lang.IllegalArgumentException: More > > than one matching method found: getPixels (imagio-test.clj:7) > > at clojure.lang.Compiler.analyzeSeq(Compiler.java:4558) > > ... > > Caused by: java.lang.IllegalArgumentException: More than one matching > > method found: getPixels > > at clojure.lang.Compiler.getMatchingParams(Compiler.java:2122) > > at clojure.lang.Compiler$InstanceMethodExpr. > > (Compiler.java:1159) > > at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java: > > 810) > > at clojure.lang.Compiler.analyzeSeq(Compiler.java:4551) > > ... 34 more > > > The problem here is that getPixels has three forms: > > (http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/Raster.html) > > double[] getPixels(int x, int y, int w, int h, double[] dArray) > > Returns a double array containing all samples for a > > rectangle of pixels, one sample per array element. > > float[] getPixels(int x, int y, int w, int h, float[] fArray) > > Returns a float array containing all samples for a rectangle > > of pixels, one sample per array element. > > int[] getPixels(int x, int y, int w, int h, int[] iArray) > > Returns an int array containing all samples for a rectangle > > of pixels, one sample per array element. > > > In each case, if the final argument is NULL it is ignored, and if not > > the array is populated with the return data from the call (generating > > an error if it's not large enough). > > > Is it possible to specify which invocation of getPixels I intend > > without passing an array? I've tried putting #^ints in some likely- > > looking places, but nil can't be type-hinted and the others seem to > > have no effect. I've also tried splitting the .. up: > > > (defn bi-get-pixels > > [#^BufferedImage bi] > > (let [rast (.getData bi) > > #^ints pi (.getPixels rast 0 0 (.getWidth bi) (.getHeight bi) nil)] > > pi)) > > > But this doesn't work either. I could do manual reflection on Raster > > to get the correct method and .invoke it, but that seems far more > > complicated than necessary. Any other ideas? > > > -Phil > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Adding type hint causes compiler error
On Jul 6, 12:25 pm, Jarkko Oranen wrote: > (ints nil) might also work It does indeed. This seems to be as good a solution as could be hoped for, thank you. --~--~-~--~~~---~--~~ 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: Penumbra, a new set of OpenGL bindings
On Jul 1, 8:16 am, ztellman wrote: > Most of the OpenGL code I've seen has been a fairly literal > translation of the corresponding Java, so as a way of getting my feet > wet in Clojure I've written something that tries to be a little more > idiomatic. It can be found athttp://github.com/ztellman/penumbra/tree/master > > The only really novel thing it brings to the table is intra-primitive > transformations, which means that you can update the transformation > matrix while defining a shape. It's always bothered me that OpenGL > doesn't allow this, so I added an additional transform step before > passing the coords to glVertex. This can be bypassed, but if you use > call lists it doesn't affect your performance at all. > > If anyone has any questions or thoughts, I'd be happy to hear them. Nice work. I hope you don't mind if I copy some ideas when I get around to making cloggle more idiomatic. --~--~-~--~~~---~--~~ 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: procedural docstring attachment
On Jul 7, 5:11 am, Timothy Pratley wrote:
> I have a function that relies on a keyword being supplied. The keyword
> is used to find something in a static map. I want to put in the doc-
> string:
> (str "blah blah blah, arg1 must be one of " (keys map))
> Suggestions?
You can put the docstring directly in the metadata of the function
name, where it will get evaluated:
(defn #^{:doc (str "blah blah blah, arg1 must be one of " (keys map))}
my-fn ...)
--~--~-~--~~~---~--~~
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: comment macro not ignoring contents
On Jul 17, 4:56 am, Richard Newman wrote: > If you want unsyntactic input in your file, comment it out with > semicolons. > > Adding true block comments -- #| |# -- is on the to-do list. While we're on the subject, are there any plans for a sexp-comment? Essentially I'm looking for reader syntax that removes the next expression from the parse tree entirely. (comment ...) returns nil, which isn't always appropriate. (You can't use it to remove one of the (arglist body) forms of a defn, for example.) And using semicolons often requires you to move closing parens to the next line. Block comments work for this, but I consider them more verbose than necessary - maybe that's just me. (I once tried to write a reader macro for CL which would do this, but the best I got was one which would read two forms and ignore the first.) --~--~-~--~~~---~--~~ 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: comment macro not ignoring contents
On Jul 17, 1:52 pm, Rich Hickey wrote: > #_ does what you want: > > user=> (list 1 2 #_42 3) > (1 2 3) Thanks for pointing that out. I notice this is actually on the reader page - apologies for not looking properly. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Compiling a namespace causes subsequent uses of it to fail.
(ns testcomp) (var-get (or (ns-resolve *ns* 'foo) (intern *ns* 'foo :foo))) ;; foo ;(1) ;; (println foo) ;(2) ;; (do foo 3);(3) ;; (fn [] foo) ;(4) ;; ((fn [] foo)) ;(5) ;; ((fn [] (println foo))) ;(6) With (1)-(6) all commented out, behaviour is as expected: you can compile and use testcomp, and foo is bound to :foo. With any of (1)-(3) uncommented, you can use testcomp with no problems as long as it's uncompiled. If you compile it and subsequently attempt to use it, you get an ExceptionInInitializerError caused by an IllegalStateException due to Var testcomp/foo being unbound. What seems to be happening (according to my limited understanding of compilation) is that testcomp__init.class contains a reference to foo which causes it to be interned (but unbound) before the body code is run. ns-resolve then sees this Var, returns it, and var-get raises an exception. With (1)-(3) commented out, (4)-(6) can be uncommented and expected behaviour returns. testcomp__init.class no longer contains a reference to foo (I checked with grep). I'm doing something like this in a library, and (5)/(6) provide a workaround, but is this something that can be fixed at the language level? I recognise it's not an issue that will commonly be run into, and that the complexities of compilation might make it unavoidable. java version "1.6.0_14", clojure commit 5f1e6ed540eab11281b7bfb19f831b7e445ed0d0 (1 Sep 09). --~--~-~--~~~---~--~~ 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: Compiling a namespace causes subsequent uses of it to fail.
On Jun 23, 12:29 pm, Stuart Halloway wrote: > I think the behavior you are seeing here is reasonable. When you mix > compilation and dynamic access to vars, you need to reason carefully about > the order in which things will happen. In general I would say that code working differently depending on whether it's compiled or not is a bug. But I understand that as bugs go, this one is probably not a big deal, and may be more trouble than it's worth to fix. At the least I think a note should be added somewhere to the docs about it though. > More usefully: you can write a test in your var-get expression that will make > it do what you want in all scenarios. Just add a bound? test before trying to > get the value out of variable. Thanks. I'll bear this in mind if I ever pick up the code again. Phil > > Sorry this was missed earlier. > > Cheers, > Stu > > > (ns testcomp) > > (var-get (or (ns-resolve *ns* 'foo) > > (intern *ns* 'foo :foo))) > > ;; foo ;(1) > > ;; (println foo) ;(2) > > ;; (do foo 3) ;(3) > > ;; (fn [] foo) ;(4) > > ;; ((fn [] foo)) ;(5) > > ;; ((fn [] (println foo))) ;(6) > > > With (1)-(6) all commented out, behaviour is as expected: you can > > compile and use testcomp, and foo is bound to :foo. > > > With any of (1)-(3) uncommented, you can use testcomp with no problems > > as long as it's uncompiled. If you compile it and subsequently attempt > > to use it, you get an ExceptionInInitializerError caused by an > > IllegalStateException due to Var testcomp/foo being unbound. What > > seems to be happening (according to my limited understanding of > > compilation) is that testcomp__init.class contains a reference to foo > > which causes it to be interned (but unbound) before the body code is > > run. ns-resolve then sees this Var, returns it, and var-get raises an > > exception. > > > With (1)-(3) commented out, (4)-(6) can be uncommented and expected > > behaviour returns. testcomp__init.class no longer contains a reference > > to foo (I checked with grep). > > > I'm doing something like this in a library, and (5)/(6) provide a > > workaround, but is this something that can be fixed at the language > > level? I recognise it's not an issue that will commonly be run into, > > and that the complexities of compilation might make it unavoidable. > > > java version "1.6.0_14", clojure commit > > 5f1e6ed540eab11281b7bfb19f831b7e445ed0d0 (1 Sep 09). > > --~--~-~--~~~---~--~~ > > 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
