Re: Compilation with Java class files
Hi, On Wed, Oct 14, 2009 at 8:50 PM, Manuel Woelker wrote: > > Hi all, > > after digging around a bit in the clojure code, trying to get the > compile to work, I found out that classes used by the compiled code > actually classloaded by the compiler. > > I can totally get behind the idea that code is data. But in this case > data is considered code, and is immediately executed. This leads to > all kinds of fun. > Like to have to specify to use headless mode when compiling something that uses swing/awt on a headless server. I guess one way to achieve this would be to use "Class handles", > instead of raw Class objects. Depending on situation these class > handles could either delegate to Class instances or use asm to get the > required information. This might be a best of both worlds solution. > If I understand both correctly what you propose and how the compiler works right now, it's one step but I think it won't be enough: you'll have at least to lazily initalize vars (or come up with a clever static analysis) to load only the required fns to support the macro. In the following case, how can you know that the class backing #'a must be loaded but not the on backing #'b? And what if #'c is not used anywhere? (defn a []) (defn b []) (defmacro c [] (a)) Ditto for used/required namespaces: you'll have to short-circuit their inits to not trigger many useless class loadings. Preventing java classes loading (and thus their init) requires to track vars inits because when you compile eg (defn bar[n] (Foo/baz n)), a class (say fn$42.class) is generated for (fn [n] (Foo/baz n)) (and it's where you propose to not load Foo) but immediately after fn$42 is instantiated (thus effectively loading Foo) and the resulting instance is put in #'bar. Christophe --~--~-~--~~~---~--~~ 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: Clojure's 2nd Birthday!
Uh oh, time for the "terrible twos". Who wants to throw the first tantrum? :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure's 2nd Birthday!
Hello, Exactly a year ago Rich posted this message on the list about "Clojure's first year" -- a year before that he had released Clojure. http://groups.google.com/group/clojure/msg/16fec21eb1fff8aa That makes today the second birthday of Clojure. Congratulations to Rich and the community. Clojure has proved to be an awesome programming environment already, and I am sure it will only get better this year :) Regards, BG Baishampayan Ghose oCricket.com signature.asc Description: OpenPGP digital signature
ANN: Cupboard, an embedded database library for Clojure
I would like to announce the release of Cupboard, an embedded database library for Clojure. In a nutshell, it allows saving arbitrary struct maps to a database. It supports indices on struct keys, ACID transactions, and retrieval using non-trivial queries. For more details and sample code, please see its README file. http://github.com/gcv/cupboard The documentation is still fairly minimal, but, along with the provided examples, should be enough to get started. Cupboard is built on top of Berkeley DB JE (and includes a fairly complete Clojure wrapper for JE as a separate API), so some familiarity with Berkeley DB will help, but is not required. All comments and bug reports welcome. Thanks, Constantine Vetoshev --~--~-~--~~~---~--~~ 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: prn/read and infinities
Hi Brian, On Oct 16, 5:18 am, Brian Hurt wrote: > with double precision infinities and NaNs. pr just calls .toString on > doubles, which for infinities and nans returns the string "Infinity" or > "NaN": > The problem is, when you try to read these values back in, they're > interpreted as symbols, not as numbers: Reading as a symbol would not be so bad in most cases, so long as the symbol resolved to what you wanted: user=> (eval (with-in-str (with-out-str (print "Double/ POSITIVE_INFINITY")) (read))) Infinity user=> (eval (with-in-str (with-out-str (pr Double/POSITIVE_INFINITY)) (read))) java.lang.Exception: Unable to resolve symbol: Infinity in this context (NO_SOURCE_FILE:16) I think it would be preferable for NaN Infinity -Infinity to be symbols that evaluate to a double, like so: user=> (def Infinity Double/POSITIVE_INFINITY) user=> (def -Infinity Double/NEGATIVE_INFINITY) user=> (def NaN Double/NaN) user=> (eval (with-in-str (with-out-str (pr Double/POSITIVE_INFINITY)) (read))) Infinity However that requires those definitions before the string can be read. If you want something that can be read independently then either those would need to be part of core or you could get around this by hooking in a print method : (defmethod print-method Double [#^Double x, #^java.io.Writer w] (.write w (condp = x Double/POSITIVE_INFINITY "Double/POSITIVE_INFINITY" Double/NEGATIVE_INFINITY "Double/NEGATIVE_INFINITY" Double/NaN "Double/NaN" (.toString x user=> (eval (with-in-str (with-out-str (pr Double/POSITIVE_INFINITY)) (read))) Double/POSITIVE_INFINITY Hope that helps, I guess it doesn't address the original question of reading them as actual numbers but for some reason doing so sounds suspicious to me - though I can't think of a reason why it would be a bad thing. Regards, Tim. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Project Euler: Problem suggestions that show off clojure?
I recently discovered Project Euler (http://projecteuler.net/) and have decided to take on some of the problems there to improve my clojure skills. I see from searching around that I'm not the first to have this idea so I thought I'd ask if anyone on this list who has done this can suggest problems that clojure is particularly well suited to solve. I'm especially interested in problems where you thought your solution shows off clojure's java interop and functional programming together. No need to submit your solution. That would spoil the fun! Just looking for pointers and maybe a word about why you thought clojure worked well for your solution. StanD. --~--~-~--~~~---~--~~ 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: clj-gradle – a Clojure Plugin for Gradle
The maven release plugin does pretty much that, only it doesn't do any ivy stuff. However, it also checks: * No uncommitted files * No files in working copy that are not under VCS * Automatically tags (and optionally branches) the code at time of release * Automatically incremements your version numbers Its very handy. -- Pull me down under... On Thu, Oct 15, 2009 at 7:30 PM, Meikel Brandmeyer wrote: > I don't really know what the maven release plugin does. And since I'm > not a professional software developer I also don't really know what > it's supposed to do. With gradle you define a task (uploadArchives) > which specifies repositories, where the resulting artifacts are > supposed to be published. For maven repos it generates a pom.xml, for > Ivy it generates an ivy.xml and for a simple ftp site it just puts the > file there. At least this is my understanding how it works. For me > this is sufficient. One can also have multiple archive definitions > containing differents sets of artifacts with different upload tasks. > So there is also some flexibility if necessary. > --~--~-~--~~~---~--~~ 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: clojure-mode patch for docstrings
On Thursday 15 October 2009 at 11:54 am, Phil Hagelberg wrote: > If you base it on the "maven" branch from my github repo, you should be > good. good stuff. thanks. > I've started a separate mailing list for swank-clojure, why don't > you join at http://groups.google.com/group/swank-clojure ? will do! - Jeff --~--~-~--~~~---~--~~ 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: Compilation with Java class files
Please note that in this discussion, I'm not trying to advocate pro/con things, but rather just trying to help you (and me in the process!) see/define the problems you think you see, etc. So more below ... 2009/10/15 Manuel Woelker > > On Thu, Oct 15, 2009 at 9:16 PM, Laurent PETIT > wrote: > > 2009/10/15 Manuel Woelker > >> > >> > How about the compiler just loads classes in a SecurityManager context > >> > that > >> > won't allow some naughtiness like System.exit()? Then you'd get a > >> > CompilerException caused by ExceptionInInitializerError caused by > >> > SecurityException rather than have your REPL, IDE, or whatever blow up > >> > from > >> > code like the above. :) > >> > >> Well, that seems like quite a hack. And it still doesn't cover things > >> like infinite loops (maybe inadvertently). Plus there may well be good > >> reasons to do certain things in clinit. What if the initializer throws > >> an exception because of some configuration error? > >> > >> As for macros: These must of course be executed during compilation, > >> that's the whole point of macros anyway. I would consider macros to be > >> more like "compiler extensions" that happen to live near the code. > >> > >> I took a closer look at the relevant methods and it seems like it > >> should be doable. > >> > >> Really looking forward to some feedback > > > > Manuel, > > > > Two more thoughts: > > > > 1/ wouldn't your solution limit too heavily the possibilities ? I mean it > > seems that you think that only defns, defmacros (and maybe defstructs) > and > > macro calls can be done at the top level. But even in the top level of a > > well behaving namespace, static initializations can occur, some of which > may > > be necessary for the defined macros to work well. > Well, I probably haven't quite grokked the macro system in its > entirety, but I would say that if a macro uses functions these > functions are "part of the compiler" as well. I still think these few > functions could be resolved as needed and then loaded just in time. > > > 2/ false sense of security: macros too can be buggy (especially when > being > > developed) and contain infinite loops, malicious code, etc. . It would > place > > a false sense of security (concerning the stability of the host compiling > > environment) to trust macros totally ? > Again, I am not all that familiar with macros so please correct me if > I am wrong on these points. > a. Macros are few and far between, even a medium sized project should > not have more than a handful of macros, but instead build on the > standard library of macros that is already available. > I haven't written any medium sized lisp project yet, and so I can't even less pretend I've written any well designed medium sized lisp project. But yes, I also read that it is considered good practice to use macros carefully, and that this generally ends with your project having not so much macros once you have the competence to correctly use higher order functions, for example. > b. Macros should only do source code transformation and should have no > other side effects. This makes it very unlikely that something nasty > could happen. > Yes, but I guess there are some areas where they could shine where accessing external resources is needed, either e.g. for reading external resources in the process, or even copying / transforming external resources, or also checking for the existence of external resources in the classpath, or also write / create new files. Especially thinking about it for when one has to integrate with existing frameworks which may force the user to create a lot of configuration files. For example macros could be used to automatically check/create/update web.xml files on the fly, giving the user immediate feedback if something is wrong in the configuration of the project. But to be honest I haven't seen this kind of use myself, just dreamed about it, so maybe it's not even recommanded to do such things. > c. Macros are part of the compiler. If you write a buggy macro you get > a buggy compiler. Hopefully you can find the bug and fix it. Note that > writing a macro is quite a different beast from just instanciating a > class. > Yes, but in the process, you would have blown away the compiler, and you wanted to avoid that. Writing recursive macros or macro defining macros is hard and I guess it's not so rare to go into infinite loops in the process. > I am not trying to deliberately criticise clojure and the process that > went into making it. Quite the opposite: I see a huge potential in > clojure and especially in its way to solve pressing concurrency issues > through immutability and its synchronization constructs. That is why I > care. But before I want to commit too much I want to check what I > perceive as possible weak spots. > Your questions are challenging and very interesting. I hope people more competent than me with clojure / lisp in general will take the time to address your points
Re: Circular dependencies (Clojure and Java)
2009/10/15 Manuel Woelker
>
> On Thu, Oct 15, 2009 at 9:43 PM, Laurent PETIT
> wrote:
> > 2009/10/15 Manuel Woelker
> >>
> >> On Thu, Oct 15, 2009 at 5:48 AM, jng27 wrote:
> >> >
> >> > The following seems like it could be a common scenario when attempting
> >> > to re-write parts of an existing Java application in Clojure.
> >> >
> >> > Let's say there exists Clojure code and Java code in the same
> >> > 'project'.
> >> > The Clojure code depends on the Java code in one direction and then
> >> > the same is true in the opposite direction.
> >> > Given that compiling Java and Clojure require separate and different
> >> > compilation steps, how would circular dependencies be resolved ?
> >> > e.g. A class is defined in the Clojure code that references Java
> >> > classes(yet to be compiled) and the same is true for the Java code
> >> > referencing classes defined in Clojure(yet to be compiled). It doesn't
> >> > seem like compiling one before the other would solve this issue.
> >> >
> >> One possible solution that could be feasible is a two pass compilation
> >> for clojure. The first compilation pass would basically just generate
> >> the skeletons for the classes, i.e. just the method "heads" with each
> >> method body being ignored and replaced with 'throw new
> >> IllegalStateExccpetion("You are using first pass compilation
> >> results")' or something along those lines. After this compilation pass
> >> the Java classes can be compiled just fine, since all method calls can
> >> be resolved. Finally the second pass of the clojure compilation fills
> >> in the real method bodies, now that Java classes have been generated.
> >> This should in theory work for most scenarios.
> >
> > But there is still the case of true circular dependencies between
> > definitions, even of interfaces (let's not talk about implementation
> code) :
> >
> > A java interface JavaInterface with a method of signature
> "ClojureInterface
> > foo()"
> > A clojure generated interface (via gen-interface) ClojureInterface with a
> > method of signature "JavaInterface bar()"
> >
> > Compiling JavaInterface requires ClojureInterface
> > Compiling ClojureInterface requires JavaInterface
> >
> > chess mat if not done by the same ubiquitous compiler :-(
> >
> I don't think so. The clojure compiler sees the method "JavaInterface
> bar()". In the first pass, it just assumes the JavaInterface to exist
> (i.e. that there is at least an "interface JavaInterface {}"
> somewhere). In this pass we do not care what the interface actually
> looks like, so we don't need it's definiton. We can thus produce
> stubbed "ClojureInterface.class". On the second pass, we expect the
> Java compiler to have compile the JavaInterface (which it can because
> it finds the ClojureInterface). Now we perform the usual checks,
> resolve JavaInterface see that it exists and do the normal compilation
> yielding the actual "ClojureInterface.class" with meaningful method
> bodies, and all is well.
>
> It seems that internally the java compilers (which are faced with the
> same problem in similar situation) follow a similar strategy. Of
> course they can forego the luxury of generating stubbed class files,
> and keep the state in their symbol table.
> (c.f.
> http://openjdk.java.net/groups/compiler/doc/compilation-overview/index.html
> though a little light on details)
>
>
If you're right, that's pretty cool ! (and I'm not at all versed into this
kind of stuff, so I really hope you're right and my feelings were wrong ! :)
--~--~-~--~~~---~--~~
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: Circular dependencies (Clojure and Java)
On Thu, Oct 15, 2009 at 9:43 PM, Laurent PETIT wrote:
> 2009/10/15 Manuel Woelker
>>
>> On Thu, Oct 15, 2009 at 5:48 AM, jng27 wrote:
>> >
>> > The following seems like it could be a common scenario when attempting
>> > to re-write parts of an existing Java application in Clojure.
>> >
>> > Let's say there exists Clojure code and Java code in the same
>> > 'project'.
>> > The Clojure code depends on the Java code in one direction and then
>> > the same is true in the opposite direction.
>> > Given that compiling Java and Clojure require separate and different
>> > compilation steps, how would circular dependencies be resolved ?
>> > e.g. A class is defined in the Clojure code that references Java
>> > classes(yet to be compiled) and the same is true for the Java code
>> > referencing classes defined in Clojure(yet to be compiled). It doesn't
>> > seem like compiling one before the other would solve this issue.
>> >
>> One possible solution that could be feasible is a two pass compilation
>> for clojure. The first compilation pass would basically just generate
>> the skeletons for the classes, i.e. just the method "heads" with each
>> method body being ignored and replaced with 'throw new
>> IllegalStateExccpetion("You are using first pass compilation
>> results")' or something along those lines. After this compilation pass
>> the Java classes can be compiled just fine, since all method calls can
>> be resolved. Finally the second pass of the clojure compilation fills
>> in the real method bodies, now that Java classes have been generated.
>> This should in theory work for most scenarios.
>
> But there is still the case of true circular dependencies between
> definitions, even of interfaces (let's not talk about implementation code) :
>
> A java interface JavaInterface with a method of signature "ClojureInterface
> foo()"
> A clojure generated interface (via gen-interface) ClojureInterface with a
> method of signature "JavaInterface bar()"
>
> Compiling JavaInterface requires ClojureInterface
> Compiling ClojureInterface requires JavaInterface
>
> chess mat if not done by the same ubiquitous compiler :-(
>
I don't think so. The clojure compiler sees the method "JavaInterface
bar()". In the first pass, it just assumes the JavaInterface to exist
(i.e. that there is at least an "interface JavaInterface {}"
somewhere). In this pass we do not care what the interface actually
looks like, so we don't need it's definiton. We can thus produce
stubbed "ClojureInterface.class". On the second pass, we expect the
Java compiler to have compile the JavaInterface (which it can because
it finds the ClojureInterface). Now we perform the usual checks,
resolve JavaInterface see that it exists and do the normal compilation
yielding the actual "ClojureInterface.class" with meaningful method
bodies, and all is well.
It seems that internally the java compilers (which are faced with the
same problem in similar situation) follow a similar strategy. Of
course they can forego the luxury of generating stubbed class files,
and keep the state in their symbol table.
(c.f.
http://openjdk.java.net/groups/compiler/doc/compilation-overview/index.html
though a little light on details)
Cheers
- Manuel
--~--~-~--~~~---~--~~
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: Compilation with Java class files
On Thu, Oct 15, 2009 at 9:16 PM, Laurent PETIT wrote: > 2009/10/15 Manuel Woelker >> >> > How about the compiler just loads classes in a SecurityManager context >> > that >> > won't allow some naughtiness like System.exit()? Then you'd get a >> > CompilerException caused by ExceptionInInitializerError caused by >> > SecurityException rather than have your REPL, IDE, or whatever blow up >> > from >> > code like the above. :) >> >> Well, that seems like quite a hack. And it still doesn't cover things >> like infinite loops (maybe inadvertently). Plus there may well be good >> reasons to do certain things in clinit. What if the initializer throws >> an exception because of some configuration error? >> >> As for macros: These must of course be executed during compilation, >> that's the whole point of macros anyway. I would consider macros to be >> more like "compiler extensions" that happen to live near the code. >> >> I took a closer look at the relevant methods and it seems like it >> should be doable. >> >> Really looking forward to some feedback > > Manuel, > > Two more thoughts: > > 1/ wouldn't your solution limit too heavily the possibilities ? I mean it > seems that you think that only defns, defmacros (and maybe defstructs) and > macro calls can be done at the top level. But even in the top level of a > well behaving namespace, static initializations can occur, some of which may > be necessary for the defined macros to work well. Well, I probably haven't quite grokked the macro system in its entirety, but I would say that if a macro uses functions these functions are "part of the compiler" as well. I still think these few functions could be resolved as needed and then loaded just in time. > 2/ false sense of security: macros too can be buggy (especially when being > developed) and contain infinite loops, malicious code, etc. . It would place > a false sense of security (concerning the stability of the host compiling > environment) to trust macros totally ? Again, I am not all that familiar with macros so please correct me if I am wrong on these points. a. Macros are few and far between, even a medium sized project should not have more than a handful of macros, but instead build on the standard library of macros that is already available. b. Macros should only do source code transformation and should have no other side effects. This makes it very unlikely that something nasty could happen. c. Macros are part of the compiler. If you write a buggy macro you get a buggy compiler. Hopefully you can find the bug and fix it. Note that writing a macro is quite a different beast from just instanciating a class. I am not trying to deliberately criticise clojure and the process that went into making it. Quite the opposite: I see a huge potential in clojure and especially in its way to solve pressing concurrency issues through immutability and its synchronization constructs. That is why I care. But before I want to commit too much I want to check what I perceive as possible weak spots. Maybe I am dead wrong, and my preconceived notions about what a compiler should or should not do simply clash with the lisp philosophy. But I still haven't heard neither a compelling argument _for_ this mode of operation nor _against_ an alternative class loading free approach. Cheers - Manuel --~--~-~--~~~---~--~~ 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: Circular dependencies (Clojure and Java)
2009/10/15 Manuel Woelker
>
> On Thu, Oct 15, 2009 at 5:48 AM, jng27 wrote:
> >
> > The following seems like it could be a common scenario when attempting
> > to re-write parts of an existing Java application in Clojure.
> >
> > Let's say there exists Clojure code and Java code in the same
> > 'project'.
> > The Clojure code depends on the Java code in one direction and then
> > the same is true in the opposite direction.
> > Given that compiling Java and Clojure require separate and different
> > compilation steps, how would circular dependencies be resolved ?
> > e.g. A class is defined in the Clojure code that references Java
> > classes(yet to be compiled) and the same is true for the Java code
> > referencing classes defined in Clojure(yet to be compiled). It doesn't
> > seem like compiling one before the other would solve this issue.
> >
> One possible solution that could be feasible is a two pass compilation
> for clojure. The first compilation pass would basically just generate
> the skeletons for the classes, i.e. just the method "heads" with each
> method body being ignored and replaced with 'throw new
> IllegalStateExccpetion("You are using first pass compilation
> results")' or something along those lines. After this compilation pass
> the Java classes can be compiled just fine, since all method calls can
> be resolved. Finally the second pass of the clojure compilation fills
> in the real method bodies, now that Java classes have been generated.
> This should in theory work for most scenarios.
>
But there is still the case of true circular dependencies between
definitions, even of interfaces (let's not talk about implementation code) :
A java interface JavaInterface with a method of signature "ClojureInterface
foo()"
A clojure generated interface (via gen-interface) ClojureInterface with a
method of signature "JavaInterface bar()"
Compiling JavaInterface requires ClojureInterface
Compiling ClojureInterface requires JavaInterface
chess mat if not done by the same ubiquitous compiler :-(
--~--~-~--~~~---~--~~
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: Circular dependencies (Clojure and Java)
On Thu, Oct 15, 2009 at 5:48 AM, jng27 wrote:
>
> The following seems like it could be a common scenario when attempting
> to re-write parts of an existing Java application in Clojure.
>
> Let's say there exists Clojure code and Java code in the same
> 'project'.
> The Clojure code depends on the Java code in one direction and then
> the same is true in the opposite direction.
> Given that compiling Java and Clojure require separate and different
> compilation steps, how would circular dependencies be resolved ?
> e.g. A class is defined in the Clojure code that references Java
> classes(yet to be compiled) and the same is true for the Java code
> referencing classes defined in Clojure(yet to be compiled). It doesn't
> seem like compiling one before the other would solve this issue.
>
One possible solution that could be feasible is a two pass compilation
for clojure. The first compilation pass would basically just generate
the skeletons for the classes, i.e. just the method "heads" with each
method body being ignored and replaced with 'throw new
IllegalStateExccpetion("You are using first pass compilation
results")' or something along those lines. After this compilation pass
the Java classes can be compiled just fine, since all method calls can
be resolved. Finally the second pass of the clojure compilation fills
in the real method bodies, now that Java classes have been generated.
This should in theory work for most scenarios.
--~--~-~--~~~---~--~~
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: Compilation with Java class files
2009/10/15 Manuel Woelker > > > How about the compiler just loads classes in a SecurityManager context > that > > won't allow some naughtiness like System.exit()? Then you'd get a > > CompilerException caused by ExceptionInInitializerError caused by > > SecurityException rather than have your REPL, IDE, or whatever blow up > from > > code like the above. :) > > Well, that seems like quite a hack. And it still doesn't cover things > like infinite loops (maybe inadvertently). Plus there may well be good > reasons to do certain things in clinit. What if the initializer throws > an exception because of some configuration error? > > As for macros: These must of course be executed during compilation, > that's the whole point of macros anyway. I would consider macros to be > more like "compiler extensions" that happen to live near the code. > > I took a closer look at the relevant methods and it seems like it > should be doable. > > Really looking forward to some feedback > Manuel, Two more thoughts: 1/ wouldn't your solution limit too heavily the possibilities ? I mean it seems that you think that only defns, defmacros (and maybe defstructs) and macro calls can be done at the top level. But even in the top level of a well behaving namespace, static initializations can occur, some of which may be necessary for the defined macros to work well. 2/ false sense of security: macros too can be buggy (especially when being developed) and contain infinite loops, malicious code, etc. . It would place a false sense of security (concerning the stability of the host compiling environment) to trust macros totally ? HTH, -- Laurent --~--~-~--~~~---~--~~ 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: Circular dependencies (Clojure and Java)
2009/10/15 Stuart Sierra > > On Oct 15, 7:56 am, Laurent PETIT wrote: > > if the clojure classes depend on the java classes in the implementation > and > > not in their interfaces ( extends, implements, methods signatures ), then > > you can write your gen-class with a separate namespace for the > > implementation of the class ( using :impl-ns ). Then you compile clojure > > code in 2 pass : 1/ compile the namespaces that use call gen-class and > > gen-interface for generating the class stubs 2/ compile java 3/ compile > all > > the remaining clojure code. > > I used this approach in the past, now I try to avoid circular > dependencies like this. > Indeed, tackling the problem at the source :) --~--~-~--~~~---~--~~ 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: Circular dependencies (Clojure and Java)
On Oct 15, 7:56 am, Laurent PETIT wrote: > if the clojure classes depend on the java classes in the implementation and > not in their interfaces ( extends, implements, methods signatures ), then > you can write your gen-class with a separate namespace for the > implementation of the class ( using :impl-ns ). Then you compile clojure > code in 2 pass : 1/ compile the namespaces that use call gen-class and > gen-interface for generating the class stubs 2/ compile java 3/ compile all > the remaining clojure code. I used this approach in the past, now I try to avoid circular dependencies like this. -SS --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
prn/read and infinities
So, I've hit a problem and I'm hoping for some help on how to solve it. The problem is that prn and read are not perfect duals- that is, not everything that prn produces can be read in by read. The specific case I'm hitting is with double precision infinities and NaNs. pr just calls .toString on doubles, which for infinities and nans returns the string "Infinity" or "NaN": user=> (with-out-str (pr Double/POSITIVE_INFINITY)) > "Infinity" > user=> (with-out-str (pr Double/NEGATIVE_INFINITY)) > "-Infinity" > user=> (with-out-str (pr Double/NaN)) > "NaN" > user=> > > The problem is, when you try to read these values back in, they're interpreted as symbols, not as numbers: user=> (class (with-in-str (with-out-str (pr Double/POSITIVE_INFINITY)) > (read))) > clojure.lang.Symbol > user=> > I'm not sure what the "right" way to solve it, but I'm inclined to advocate that Infinity and NaN should be reserved keywords recognized by the reader. Or possibly Clojure should automatically define the symbols Infinity and NaN to have the correct values. I'm not sure. Brian --~--~-~--~~~---~--~~ 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: Compilation with Java class files
> How about the compiler just loads classes in a SecurityManager context that > won't allow some naughtiness like System.exit()? Then you'd get a > CompilerException caused by ExceptionInInitializerError caused by > SecurityException rather than have your REPL, IDE, or whatever blow up from > code like the above. :) Well, that seems like quite a hack. And it still doesn't cover things like infinite loops (maybe inadvertently). Plus there may well be good reasons to do certain things in clinit. What if the initializer throws an exception because of some configuration error? As for macros: These must of course be executed during compilation, that's the whole point of macros anyway. I would consider macros to be more like "compiler extensions" that happen to live near the code. I took a closer look at the relevant methods and it seems like it should be doable. Really looking forward to some feedback - Manuel --~--~-~--~~~---~--~~ 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: clojure-mode patch for docstrings
Jeff Valk writes: >> Do you have any specific ideas for new features? > > Well one thing I started playing with is completion on the entire classpath > in swank-clojure. So for example, typing "clojure.contrib.a" would bring up: > clojure.contrib.accumulators > clojure.contrib.agent-utils > clojure.contrib.apply-macro > > And typing "java.io" would bring up: > java.io.CharArrayReader > java.io.CharArrayWriter > java.io.CharConversionException > java.io.FileFilter > ... > > This gives you completion even on your use/require/import lists, and > definitely makes Java interop a bit easier. Awesome; that looks great. > It needs polish but it's functional. If you think it would be a > worthwhile addition, give me a heads up when swank-clojure looks good > to hack. If you base it on the "maven" branch from my github repo, you should be good. I've started a separate mailing list for swank-clojure, why don't you join at http://groups.google.com/group/swank-clojure ? thanks, 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: locking semantics: queue for the monitor?
I think it uses intrinsic locks, which are always non-fair. You can instantiate fair locks (what you are asking for) with the implementations in this package: http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/package-summary.html But that requires you use lock.lock() and lock.unlock() directly in a try-finally structure. On Thu, Oct 15, 2009 at 4:26 PM, Garth Sheldon-Coulson wrote: > Hi All, > > If multiple threads are competing for the monitor of an object using > (locking obj ... ), is it a strict queue for the monitor (first in, first > lock) similar to send and send-off? Or are there other considerations? > > I would probably know this if I knew more about Java sync, but quick > web/groups searches don't give a clear answer. Sorry for the basic question. > > Garth > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
locking semantics: queue for the monitor?
Hi All, If multiple threads are competing for the monitor of an object using (locking obj ... ), is it a strict queue for the monitor (first in, first lock) similar to send and send-off? Or are there other considerations? I would probably know this if I knew more about Java sync, but quick web/groups searches don't give a clear answer. Sorry for the basic question. Garth --~--~-~--~~~---~--~~ 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: clojureshell-maven-plugin - easier clojure startup with maven
It should be noted that clojure-maven-plugin now also includes the clojure:swank and clojure:repl goals, and can do pretty much everything that clojureshell can. So I urge people to check out clojure-maven-plugin, it's really cool. Cheers, -- Fredrik On Thu, Oct 15, 2009 at 4:56 AM, ngocdaothanh wrote: > > clojure-maven-plugin is so good! Thanks a lot. > > clojureshell-maven-plugin explicitly loads Clojure 1.0, so I cannot > use 1.1.0-alpha-SNAPSHOT by declaring these in my pom.xml: > > ... > > >org.clojure >clojure-lang >1.1.0-alpha-SNAPSHOT > > > >org.clojure >clojure-contrib >1.0-SNAPSHOT > > > > > >tapestry-snapshots > > http://tapestry.formos.com/maven-snapshot-repository/ > > > ... > > > On Oct 15, 4:40 am, Stuart Sierra wrote: > > On Oct 14, 1:03 pm, ngocdaothanh wrote: > > > > > Is there a way to run a .clj file (with classpath correctly set by > > > Maven)? I don't want REPL, I just want to run a .clj file without > > > compiling. > > > > Look at the "clojure:run" target in the clojure-maven-plugin version > > 1.1:http://github.com/talios/clojure-maven-plugin > > > > -SS > > > -- == What am I up to? http://twitter.com/appelberg --~--~-~--~~~---~--~~ 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: Clojure Applets: Tutorial
The applet seems to work fine on my PowerPC Mac (10.4.11) with Java 1.5.0_19 On Oct 15, 12:50 pm, Andreas Wenger wrote: > Hi Jon, > > "Applet net.n01se.Tree" ist just an example I found on the web. My new > demo code can be found > here:http://www.xenoage.com/extern/clojurebook/applet2/cljapp.html > But as already said, Java 5 doesn't like it (see error message two > posts above) and tells me that the bytecode generated by the Clojure > compiler was wrong... Hm... --~--~-~--~~~---~--~~ 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: Circular dependencies (Clojure and Java)
Hello, One solution I've applied in the past: if the clojure classes depend on the java classes in the implementation and not in their interfaces ( extends, implements, methods signatures ), then you can write your gen-class with a separate namespace for the implementation of the class ( using :impl-ns ). Then you compile clojure code in 2 pass : 1/ compile the namespaces that use call gen-class and gen-interface for generating the class stubs 2/ compile java 3/ compile all the remaining clojure code. This one is not tested but should work: if the clojure classes depend on the java classes even in the signature, then maybe it could be easier to define these classes squeletons in java, and extend them for implementation in clojure. So 1/ create class ASqueleton java source code 2/ compile java , 3/ create gen-class that extends ASqueleton 4/ compile clojure HTHal (*), -- Laurent (Hope This Helps a little) 2009/10/15 jng27 > > The following seems like it could be a common scenario when attempting > to re-write parts of an existing Java application in Clojure. > > Let's say there exists Clojure code and Java code in the same > 'project'. > The Clojure code depends on the Java code in one direction and then > the same is true in the opposite direction. > Given that compiling Java and Clojure require separate and different > compilation steps, how would circular dependencies be resolved ? > e.g. A class is defined in the Clojure code that references Java > classes(yet to be compiled) and the same is true for the Java code > referencing classes defined in Clojure(yet to be compiled). It doesn't > seem like compiling one before the other would solve this issue. > > > > > --~--~-~--~~~---~--~~ 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: Clojure Applets: Tutorial
Hi Jon, "Applet net.n01se.Tree" ist just an example I found on the web. My new demo code can be found here: http://www.xenoage.com/extern/clojurebook/applet2/cljapp.html But as already said, Java 5 doesn't like it (see error message two posts above) and tells me that the bytecode generated by the Clojure compiler was wrong... Hm... --~--~-~--~~~---~--~~ 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: Problem with .NET interop
Thank you David, I'm impressed by your dedication to this project! - Dmitry On Oct 13, 10:58 pm, David Miller wrote: > Fixed in latest commit. (commit 7dd9fcb, which is taking quite some > time to appear on github, so make sure you see this one in the commit > history) > > -David > > On Oct 13, 2:22 am, Dmitry Kakurin wrote: > > > > > What's wrong with my definition of sqrt? > > > user=> (defn sqrt [x] (. System.Math Sqrt x)) > > #'user/sqrt > > user=> (sqrt 4) > > System.InvalidCastException: Specified cast is not valid. > > at lambda_method(Closure , Object ) > > at AFunction_impl.invoke(Object ) > > at lambda_method(Closure ) > > at AFunction_impl.invoke() > > at REPLCall(Closure ) > > > It works from REPL: > > user=> (. System.Math Sqrt 4) > > 2 > > > Notice that > > user=> (sqrt 4.0) > > 2 > > > works as expected. > > > - Dmitry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Circular dependencies (Clojure and Java)
The following seems like it could be a common scenario when attempting to re-write parts of an existing Java application in Clojure. Let's say there exists Clojure code and Java code in the same 'project'. The Clojure code depends on the Java code in one direction and then the same is true in the opposite direction. Given that compiling Java and Clojure require separate and different compilation steps, how would circular dependencies be resolved ? e.g. A class is defined in the Clojure code that references Java classes(yet to be compiled) and the same is true for the Java code referencing classes defined in Clojure(yet to be compiled). It doesn't seem like compiling one before the other would solve this issue. --~--~-~--~~~---~--~~ 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: clojure-mode patch for docstrings
On Wednesday 14 October 2009 at 07:11 pm, Phil Hagelberg wrote: > Currently with swank there are some changes on his branch that I haven't > been able to get working properly, so maybe for functionality there it > would be best if you wait till I have a chance to merge them, sorry. Good tip. Thanks. > Do you have any specific ideas for new features? Well one thing I started playing with is completion on the entire classpath in swank-clojure. So for example, typing "clojure.contrib.a" would bring up: clojure.contrib.accumulators clojure.contrib.agent-utils clojure.contrib.apply-macro And typing "java.io" would bring up: java.io.CharArrayReader java.io.CharArrayWriter java.io.CharConversionException java.io.FileFilter ... This gives you completion even on your use/require/import lists, and definitely makes Java interop a bit easier. It needs polish but it's functional. If you think it would be a worthwhile addition, give me a heads up when swank-clojure looks good to hack. - Jeff --~--~-~--~~~---~--~~ 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: Clojure Applets: Tutorial
Hi, I get "Applet net.n01se.Tree notinited" in the status bar on my Mac. Did you compile for Java 5? /Jon On Oct 15, 11:36 am, Andreas Wenger wrote: > Fantastic news: > > - Clojure applets do not have to be signed, when reflection can be > avoided (by type hints and so on) > - Java code is indeed not needed (thanks @ rob) > > I've updated the tutorial accordingly. > Here is another Clojure applet which works without Java code and > without signing:http://chouser.n01se.net/misc/tree.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: Clojure Applets: Tutorial
However, compatibility with Java 5 is lost again. Java 5 plugin shows the following error message when loading the applet (even when Clojure compiler was started with Java 5, but I guess, this does not matter anyway): Java Plug-in 1.5.0_19 Verwendung der JRE-Version 1.5.0_19 Java HotSpot(TM) Client VM Home-Verzeichnis des Benutzers = /home/andi [...] java.lang.VerifyError: class applet overrides final method “Ÿʐh ‘ .ó¬ʐh ‘ (<- yeah, really.) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java: 124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:172) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:144) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:687) at sun.applet.AppletPanel.createApplet(AppletPanel.java:723) at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1813) at sun.applet.AppletPanel.runLoader(AppletPanel.java:652) at sun.applet.AppletPanel.run(AppletPanel.java:326) at java.lang.Thread.run(Thread.java:595) /usr/share/themes/Human/gtk-2.0/gtkrc:51: error: lexical error or unexpected token, expected valid token Any idea? --~--~-~--~~~---~--~~ 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: Clojure Applets: Tutorial
Fantastic news: - Clojure applets do not have to be signed, when reflection can be avoided (by type hints and so on) - Java code is indeed not needed (thanks @ rob) I've updated the tutorial accordingly. Here is another Clojure applet which works without Java code and without signing: http://chouser.n01se.net/misc/tree.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 -~--~~~~--~~--~--~---
