Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
You could do what one of my "modern language" (python) students did. Put the open parens at the end of the line and it looks like python! ( defun foo ( arg1 arg2 arg3 ) ( let ( tmp1 tmp2 ) ( firstFunction arg1 ) ( secondFunction arg2 ) ( thirdFunction arg3 ))) auggghhh! my eyes! my eyes :-) Back in the pre-history while I worked in the "machine room" a student came to me with FORTRAN code. He discovered that FORTRAN ignored spaces so he has a solid block of code from column 8 to column 71 that went on for pages. There is no disputing taste. Fortunately, lisp doesn't care. Since it is still "in the early days" of Clojure it might be a good idea to follow the style set in clojure core.clj. You never know when your code might become a candidate for inclusion and the last thing you want is to be rejected for style. Tim Daly kyle smith wrote: On Aug 19, 12:08 pm, Brian Goslinga wrote: Here is another trick that works for me in Emacs: delete most of the stack of closing parens, and then spam the ) key until the Emacs matches it to the desired opening paren. this. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Is there a construct-hash macro?
Dear all, when you write a deftype and want to define a hashCode method, it would be really great to have access to a macro (construct-hash arg1 argn) that would compute the hash code of each arguments and combine them in a good way to produce a hash-code. Is there anything like that in core or contrib? (The same kind of idea could be applied for a generic equality macro, that checks identity, type and then the pairs of arguments given) Best regards, Nicolas. -- 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 there a construct-hash macro?
There's the undocumented clojure.core/hash-combine (wrapping a static method of clojure.lang.Util) which could perhaps be used for this purpose with reduce. It doesn't appear to be used anywhere, though -- I wonder about its current status...? At any rate, an officially supported (= documented) tool to do this would indeed be useful -- (inc) from me. Sincerely, Michał -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
My rough estimate is that more than 40 replies to that thread heave been generated up to now (I deleted the 28 ones without reading them after reading a couple of replies to the original post). Hmmm,,, I am about to think that we could have powered a small town with all that electrical nerve impulse that has been spent on this subject not withstanding the electricity spent in wires and servers to spread this thread every where around the planet. And yet no consensus has been reached... maybe we should drop the subject for now ? Luc P. Tim Daly wrote .. > You could do what one of my "modern language" (python) students did. > Put the open parens at the end of the line and it looks like python! > > ( > defun foo ( > arg1 arg2 arg3 ) ( > let ( > tmp1 tmp2 ) ( > firstFunction arg1 ) ( > secondFunction arg2 ) ( > thirdFunction arg3 ))) > > auggghhh! my eyes! my eyes :-) > > Back in the pre-history while I worked in the "machine room" > a student came to me with FORTRAN code. He discovered that FORTRAN > ignored spaces so he has a solid block of code from column 8 to > column 71 that went on for pages. > > There is no disputing taste. Fortunately, lisp doesn't care. > > Since it is still "in the early days" of Clojure it might be a > good idea to follow the style set in clojure core.clj. You never > know when your code might become a candidate for inclusion and > the last thing you want is to be rejected for style. > > Tim Daly > > kyle smith wrote: > > On Aug 19, 12:08 pm, Brian Goslinga wrote: > > > >> Here is another trick that works for me in Emacs: delete most of the > >> stack of closing parens, and then spam the ) key until the Emacs > >> matches it to the desired opening paren. > >> > > > > this. > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To 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 testing (and *load-tests*)
I'm sure this is just me being dumb about bindings but I've been writing tests and I saw in the docs it says you can cause deftest and with-test to not generate tests if you bind *load-tests* to false - for production. I can't quite get my head around how I would bind that variable in a way that actually affects how files containing tests are loaded / compiled. Can someone point me at a good example of a project / source code that includes tests in source files but also has a production binding for *load-tests* ? Thanx! -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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 testing (and *load-tests*)
Hi Sean, As far as I know, that feature never saw much use. Most people like to keep their test and main sources separate, and build tools assume this. To bind *load-tests* during compilation, you would need to control your own build process. Basically, you would have to launch Clojure and execute a script that binds *load-tess* and then calls "compile" by hand. I don't think this is possible with Leiningen or Maven, but you could do it with Ant. I doubt it's worth the trouble. -S On Aug 29, 3:46 pm, Sean Corfield wrote: > I'm sure this is just me being dumb about bindings but I've been > writing tests and I saw in the docs it says you can cause deftest and > with-test to not generate tests if you bind *load-tests* to false - > for production. > > I can't quite get my head around how I would bind that variable in a > way that actually affects how files containing tests are loaded / > compiled. > > Can someone point me at a good example of a project / source code that > includes tests in source files but also has a production binding for > *load-tests* ? > > Thanx! -- 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 it possible in theory to write/modify a Clojure compiler that doesn't
Has anyone actually implemented this sort of placeholder strategy before? --Robert McIntyre On Sat, Aug 28, 2010 at 3:04 PM, Michael Wood wrote: > On 28 August 2010 19:27, Michał Marczyk wrote: >> On 28 August 2010 19:19, Luke VanderHart wrote: >>> I'm not just talking about class hierarchy dependencies, but also >>> reference dependencies. >> >> Ah, I see. In that case, maybe generate placeholders for all the >> classes to be implemented in Clojure (with all methods doing something >> like "throw new RuntimeException()"), compile those stubs with javac >> together with all the Java classes, then discard the placeholder >> .class files and compile the Clojure classes? > > I believe this discussion has been had before with similar conclusion. > > -- > 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 -- 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: where did I read that?
That's a neat improvement to be able to ignore the value when you don't need it, thanks Michał Marczyk. Also, though both proxies happen to work with clojure's (read) function, every read operation of the pushback reader would have to be wrapped in the variable changing code to guarantee correctness in all cases. So the proxy needs about 3-5 more methods to be a complete covering. you wouldn't want me to do (.skip reader 5) and have *current-char-number* become wrong! The perils of mutable state are made of this... :( >From a code reuse standpoint, isn't this kinda lame? --Robert McIntyre On Sat, Aug 28, 2010 at 5:28 PM, Michał Marczyk wrote: > On 28 August 2010 22:14, evins.mi...@gmail.com wrote: >> I was actually asking how to avoid doing what you did :-). If it's >> necessary to do it, that's fine, but I thought I'd ask first, in case >> there was a way around it that I hadn't noticed. > > Well, some level of reimplementation will probably be necessary (if > there is an implementation of an "indexing reader" in the base class > libraries, I'd love to learn about it, but I don't think there is!). > > Having said that, you could take Robert's approach and have the proxy > implement a new interface (which you can define through definterface) > to check current offset: > > ;;; untested... > > (definterface IReaderOffset > (^int readerOffset [])) > > ;;; and the proxy form: > (proxy [java.io.PushbackReader IReaderOffset] [...] > (read ...) > (unread ...) > (readerOffset [] @*current-char-number*)) > > ;;; also, drop the final (fn ...) form from read-with-number -- > ;;; return the proxy itself instead; maybe also rename > ;;; to e.g. indexing-reader? > > Then you could use the regular read function and say (.readerOffset > reader-instance) to find out what the current index is. This does at > least have the nice property that you can ignore the extra information > when it's not needed (as you could with multiple return values in CL). > > Sincerely, > Michał > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Hi, Am 28.08.2010 um 19:09 schrieb Michał Marczyk: > I'm sure I'm missing lots of things, but I'd love to know which, so -- > please let me know. :-) In fact, your two-pass scenario is probably the best you can get, since you can define arbitrary classes in arbitrary namespaces. (Whether this is advisable is a different question!) So any compiler trying to translate a classname to a defining namespace must fail in general. This could only be remedied by following a convention of one class per namespace which is quite a restriction. Just scanning the source files will also fail, because classes might be generated by macros. And macros might to depend on arbitrary functions defined in the file. So they can only be expanded by loading the file and executing the functions. Hence you cannot discover class generation in general. So I would suspect that your two pass scenario is a strict limit. 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: Question about testing (and *load-tests*)
Thanx Stuart. I had a feeling it might require that. I've mostly been using lein and keeping the tests separate but when I saw that in the docs I thought I'd try it because it would be kinda convenient inside CCW / Eclipse while developing. On Sunday, August 29, 2010, Stuart Sierra wrote: > Hi Sean, > > As far as I know, that feature never saw much use. Most people like to > keep their test and main sources separate, and build tools assume > this. > > To bind *load-tests* during compilation, you would need to control > your own build process. Basically, you would have to launch Clojure > and execute a script that binds *load-tess* and then calls "compile" > by hand. I don't think this is possible with Leiningen or Maven, but > you could do it with Ant. I doubt it's worth the trouble. > > -S > > > On Aug 29, 3:46 pm, Sean Corfield wrote: >> I'm sure this is just me being dumb about bindings but I've been >> writing tests and I saw in the docs it says you can cause deftest and >> with-test to not generate tests if you bind *load-tests* to false - >> for production. >> >> I can't quite get my head around how I would bind that variable in a >> way that actually affects how files containing tests are loaded / >> compiled. >> >> Can someone point me at a good example of a project / source code that >> includes tests in source files but also has a production binding for >> *load-tests* ? >> >> Thanx! > > -- > 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 -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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 testing (and *load-tests*)
So I thought I'd see if I could use tests in source code and add a hook to lein to bind *load-tests* to false around the compile but I'm missing something... Here's my hook: (ns leiningen.notests) (use 'robert.hooke) (defn no-tests [task & args] (binding [clojure.test/*load-tests* false] (apply task args))) (add-hook #'leiningen.compile/compile no-tests) I've added this to my project.clj: :dev-dependencies [[robert/hooke "1.0.2"]] :hooks [leiningen.notests] lein happily pulled down the library and tries to run the hook but I get: Warning: problem requiring hooks: java.lang.Exception: Unable to resolve var: clojure.test/*load-tests* in this context (notests.clj:6) Fair enough, I thought, maybe I need to require or use clojure.test in the hook. I added (use 'clojure.test) and got this error: Warning: problem requiring hooks: java.lang.NoClassDefFoundError: Could not initialize class clojure.test__init (notests.clj:1) I've tried (:use [clojure.test]) in the (ns) and (:require [clojure.test]) but I still hit this error. What am I missing? (I'm still struggling with the build / dependency aspect of this stuff) Thanx, Sean On Sun, Aug 29, 2010 at 2:57 PM, Sean Corfield wrote: > Thanx Stuart. I had a feeling it might require that. I've mostly been > using lein and keeping the tests separate but when I saw that in the > docs I thought I'd try it because it would be kinda convenient inside > CCW / Eclipse while developing. > > On Sunday, August 29, 2010, Stuart Sierra wrote: >> Hi Sean, >> >> As far as I know, that feature never saw much use. Most people like to >> keep their test and main sources separate, and build tools assume >> this. >> >> To bind *load-tests* during compilation, you would need to control >> your own build process. Basically, you would have to launch Clojure >> and execute a script that binds *load-tess* and then calls "compile" >> by hand. I don't think this is possible with Leiningen or Maven, but >> you could do it with Ant. I doubt it's worth the trouble. >> >> -S >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Performance of ensure
Hi,
I have two refs a1, a2. One thread modifies a1, another modifies a2.
Sample code: http://gist.github.com/556679
If I don't ensure any ref in the transaction, the code runs in ~ 0.2
ms.
$ java -cp lib/clojure-1.2.0.jar\;src clojure.main -e "(require 'tt)
(tt/transaction-simul {:ensure2 false :ensure1 false}) (System/exit
0)"
Amounts=[-100,-100]
"Elapsed time: 0.248209 msecs"
If I ensure the non-modifying ref - the code takes variable amount of
time - ranging from 1 second to 15 seconds (10 runs).
$ java -cp lib/clojure-1.2.0.jar\;src clojure.main -e "(require 'tt)
(tt/transaction-simul {:ensure2 true :ensure1 false}) (System/exit 0)"
Amounts=[100,-100]
"Elapsed time: 7545.406736 msecs"
If I ensure both refs - the code takes even more time (on average).
$ java -cp lib/clojure-1.2.0.jar\;src clojure.main -e "(require 'tt)
(tt/transaction-simul {:ensure2 true :ensure1 true}) (System/exit 0)"
Amounts=[-100,100]
"Elapsed time: 10705.949317 msecs"
Can someone explain to me what ensure exactly does (implementation
wise)? and why its taking so much time?
Thanks!
PS: If someone is interested in the context - my first blog entry:
http://ka133.blogspot.com/2010/08/serializable-concurrency-sql-clojure.html
--
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: Extending Clojure's STM with external transactions
I'm resurrecting this thread from quite a while ago... I'm very interested in being able to ensure that the state of a ref is persisted as part of the same transaction that updates the ref. Performance is not important; correctness is. Has any further work been done on this front? http://groups.google.com/group/clojure/browse_thread/thread/aa22a709501a64ac -- 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 it possible in theory to write/modify a Clojure compiler that doesn't
I don't think two pases is enough. What if a clojure file uses reflection (with macros of course) on a compiled java file to generate classes, sort of like how lancet works but generating classes instead of functions? And then those classes are used from other clojure and java files. Oh, and then another clojure file does the same reflection based junk to make more classes, from the classes that were generated from the first clojure file. These classes are, of course, used by other java and clojure files. In this case the only way I can think to compile everything (and sadly I'm doing something like this on my current project in lieu of a better way) is to: try to compile all the java files first (fail at some), try to compile all the clojure files (fail at some), try to compile all the java files (fail at some, but a little bit less than the first time), repeat until bytecode-level quiescence. The clojure compiler and java compiler will at most have to be invoked something like n times where n is the total number of source files in the project in certain pathological conditions as above. However, no matter what crazy stuff they're doing, as long as there no circular dependencies I think I can prove that this process will always make progress and converge to a steady state. I can make a concrete example of this condition if anyone's interested (at least I think I can!) As wasteful as it sounds is it really that bad? If the compilers only tried files that weren't already compiled and had minimal startup time then this sort of oscillation can be continued until quiescence is reached and will only take around the same time as single pass over all files. I've screwed around with this a lot and think that it would be a triumph if clojure and java could be intermixed freely. Then, there are no barriers to rewriting just one piece of a tightly interconnected java program in clojure for greater clarity/efficiency. You can just replace one java file with one clojure file, and use a java-clojure aware compiler instead of pure javac. I dream of the day where you could do this in a streamlined way in eclipse, so that everyone else on the project can focus on the concepts behind the program, not trivial minutiae like compile order. --Robert McIntyre On Sun, Aug 29, 2010 at 4:46 PM, Meikel Brandmeyer wrote: > Hi, > > Am 28.08.2010 um 19:09 schrieb Michał Marczyk: > >> I'm sure I'm missing lots of things, but I'd love to know which, so -- >> please let me know. :-) > > In fact, your two-pass scenario is probably the best you can get, since you > can define arbitrary classes in arbitrary namespaces. (Whether this is > advisable is a different question!) So any compiler trying to translate a > classname to a defining namespace must fail in general. This could only be > remedied by following a convention of one class per namespace which is quite > a restriction. > > Just scanning the source files will also fail, because classes might be > generated by macros. And macros might to depend on arbitrary functions > defined in the file. So they can only be expanded by loading the file and > executing the functions. Hence you cannot discover class generation in > general. > > So I would suspect that your two pass scenario is a strict limit. > > 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
Very slow compile on ext4
On an ext4 file system, building 04764db9b takes an awful lot of time: BUILD SUCCESSFUL Total time: 1 minute 38 seconds On a RAM disk on the same system, it's just: BUILD SUCCESSFUL Total time: 8 seconds This seems to be caused by excessive fsync() calls. Are those really necessary? Or do you think ext4 should be fixed? 8-) -- 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
NullPointerExecption after Java class import
I am using GATE java libs in my clojure code and behaviour of the application changes after Java class import. I don't even have to initialize it. This runs fine (a bit shorter version than it is): (ns gate (:import (gate Gate) (java.io File))) (defn gate-init [gate-home] (Gate/setGateHome (File. gate-home)) (Gate/init))) Now if I import gate.Factory class, like this (gate Gate Factory), I get the exception: Caused by: java.lang.NullPointerException at gate.Factory.createResource(Factory.java:154) How can import of a class cause this? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Question about testing (and *load-tests*)
On Sun, Aug 29, 2010 at 5:27 PM, Sean Corfield wrote: > So I thought I'd see if I could use tests in source code and add a > hook to lein to bind *load-tests* to false around the compile but I'm > missing something... > > (defn no-tests [task & args] > (binding [clojure.test/*load-tests* false] > (apply task args))) > > (add-hook #'leiningen.compile/compile no-tests) > > What am I missing? You're very close. If the tests ran in the same JVM as Leiningen, this would work. However, Leiningen has to spawn another JVM in order to avoid contamination. Leiningen uses the leiningen.test/form-for-testing-namespaces function to return a form that's evaled in the project's JVM. You would have to add a hook to wrap that form in a binding call: (defn add-load-tests-binding [f & args] `(binding [clojure.test/*load-tests* false] ~(apply f args))) (add-hook #'leiningen.test/form-for-testing-namespaces add-load-tests-binding) The problem is that doesn't quite work because clojure.test isn't loaded in your project JVM yet. And you can't just require it right before you bind it either, since you can't compile a form that loads a var and includes it at compile-time either; the var must exist at compile-time. This is why you see the use of ns-resolve in form-for-testing-namespaces--that way the var doesn't need to be loaded at compile time. I'm not sure if there's a way around it aside from nesting evals. Anyone else have an idea? -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: NullPointerExecption after Java class import
Hello, I don't know this library specifically, but the NPE is probably occurring in a static initialisation block. I believe static initialisation occurs when the class is first loaded. Regards, Stuart On 30 August 2010 06:42, zm wrote: > > I am using GATE java libs in my clojure code and behaviour of the > application changes after Java class import. I don't even have to > initialize it. > > This runs fine (a bit shorter version than it is): > > (ns gate > (:import > (gate Gate) > (java.io File))) > > (defn gate-init > [gate-home] > (Gate/setGateHome (File. gate-home)) > (Gate/init))) > > Now if I import gate.Factory class, like this (gate Gate Factory), I > get the exception: > > Caused by: java.lang.NullPointerException >at gate.Factory.createResource(Factory.java:154) > > How can import of a class cause this? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To 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
