Re: oo
I'm very interested in this thread. I'm having trouble figuring out exactly which situations require prefer-method and which do not. One thing that would help me understand the issues more deeply would be if someone could post the simplest possible multimethod that requires prefer-method to disambiguate. In Rich's list of ideals, I particularly appreciate the desire to be able impose a parent on a child without changing the child. This has come up for me, and I was grateful Clojure had this ability. I didn't see anything in the list of ideals that explains the lack of a next-method, and it's not really clear to me how to reap some of the benefits of inheritance without this. On a somewhat related note, as my code grows, and I'm using more complicated data structures, representing all of them as hash tables is starting to feel a little too, well, unstructured. Can anyone else report from the Clojure trenches on ways to manage this complexity? --~--~-~--~~~---~--~~ 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: oo
I think I've answered at least part of my own question. This is the
simplest ambiguous case I've found:
ab
| |
--
|
c
user (defmulti test-prefer :tag)
#'user/test-prefer
user (defmethod test-prefer ::a [h] a)
#MultiFn clojure.lang.mult...@6551c1
user (defmethod test-prefer ::b [h] b)
#MultiFn clojure.lang.mult...@6551c1
user (derive ::c ::a)
nil
user (derive ::c ::b)
nil
user (test-prefer {:tag ::a})
a
user (test-prefer {:tag ::b})
b
user (test-prefer {:tag ::c})
; Evaluation aborted.
user (prefer-method test-prefer ::a ::b)
#MultiFn clojure.lang.mult...@6551c1
user (test-prefer {:tag ::c})
a
So if I understand correctly, the crux of the problem is that this
preference information is not part of the actual derive hierarchy.
This gives added flexibility to customize on a method by method basis,
but at a cost.
One cost seems to be that if an outside user wants to write a new
method on this very same type hierarchy, he can only do it if he knows
how the types are derived from one another inside the library so that
he can restate all the necessary precedences with appropriate
prefer-method calls on his own new method.
Another interesting question is whether at least test-prefer is safe
for extension. Here's a potential problem I see. Let's say that in
the above example, type ::c is what is intended to be publicly
visible, and the base classes ::a or ::b just provide the base
implementation for various methods, including prefer-method.
I may come along and want to extend test-prefer to a type ::d which
derives from ::c and ::e, where ::e provides an alternative
implementation.
ab (a and b are intended to be hidden from end-user)
| |
--
|
c e
| |
|
d
(derive ::d ::c)
(derive ::d ::e)
(defmethod test-prefer ::e [h] e)
Now, as an external user, I know nothing about where test-prefer on
::c gets its behavior. Obviously, I have to disambiguate between
whether test-prefer chooses ::c over ::e, so I may try something like
this:
(prefer-method test-prefer ::c ::e)
But this will not work. I still get an error saying I need to
disambiguate between ::a and ::e. And not knowing anything about ::a,
I could be very confused, and not know how to provide this
information.
Considering how complex the situation can get with single dispatch, I
imagine it gets even more complex in multiple dispatch situations. In
the multimethods example at clojure.org/multimethods, an example is
given of disambiguating between [::shape ::rect] and [::rect ::shape].
But again, if you're writing the bar method from outside of the
library which defines ::shape and ::rect, you might not even know
which is more specific. It might be easier to choose a strategy, such
as more specific on the leftmost taking precedence, than to know the
details of how the various types in the library interact.
Anyway, this is my attempt to digest and restate what I've learned
from this thread and from tinkering around. Any other good examples
that illustrate some of the difficulties?
--~--~-~--~~~---~--~~
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: oo
On Mar 27, 2009, at 9:25, Mark Engelberg wrote: I think I've answered at least part of my own question. This is the simplest ambiguous case I've found: ab | | -- | c Indeed. An ambiguous situation can occur whenever the type hierarchy graph is not a tree. Since it takes at least three nodes to make a graph that is not a tree, your example is the simplest one possible. So if I understand correctly, the crux of the problem is that this preference information is not part of the actual derive hierarchy. That is one way to put it, but I think there are other possible solutions than putting the preference information into the hierarchy. One cost seems to be that if an outside user wants to write a new method on this very same type hierarchy, he can only do it if he knows how the types are derived from one another inside the library so that he can restate all the necessary precedences with appropriate prefer-method calls on his own new method. That could be avoided with a set of utility functions/macros for placing types into a hierarchy and for defining multimethods. These utility functions could take care of adding prefer-method calls as necessary. Of course, if this is a frequent need, explicitly language support would be preferable, but at least that would be a way to experiment with design options to figure out what works best. Now, as an external user, I know nothing about where test-prefer on ::c gets its behavior. Obviously, I have to disambiguate between whether test-prefer chooses ::c over ::e, so I may try something like this: (prefer-method test-prefer ::c ::e) But this will not work. I still get an error saying I need to disambiguate between ::a and ::e. And not knowing anything about ::a, I could be very confused, and not know how to provide this information. True. It would be nice if prefer-method could itself figure out that ::a provides the implementation for ::c. But again that functionality can be added with utility functions, as the hierarchy can be explored using the functions parents, ancestors, and descendants. Considering how complex the situation can get with single dispatch, I imagine it gets even more complex in multiple dispatch situations. In the multimethods example at clojure.org/multimethods, an example is given of disambiguating between [::shape ::rect] and [::rect ::shape]. But again, if you're writing the bar method from outside of the library which defines ::shape and ::rect, you might not even know which is more specific. It might be easier to choose a strategy, such as more specific on the leftmost taking precedence, than to know the details of how the various types in the library interact. I am not so sure about this. I wonder if there is a real-life use case where a client library would need to solve dispatching issues on types in another library about which it doesn't know anything. If there isn't, the problem is not relevant, and if there is, I'd like to see a demonstration that something like left-to-right precedence is indeed a reasonable default. On the other hand, I would definitely like to be able to implement left-to-right precedence myself on top of Clojure's multimethods, and it seems that at the moment this is not possible. Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Slime bug
I think I found a bug in swank. When I execute in the SLIME REPL (loop [i 0] (when ( i 50) (println i) (recur (inc i it goes for a while (the last printed number varies greatly), then inevitably throws the exception below. This looks like a but in swank's output stream implementation. Is this the right place to report this bug? I installed SLIME for Clojure following the instructions at http://riddell.us/tutorial/slime_swank/slime_swank.html I'm a Java programmer trying to grok Clojure, so far I am very very impressed. Many kudos to the Clojure folks! Best regards, Curran Kelleher java.lang.StringIndexOutOfBoundsException: String index out of range: 6 (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [CAUSE] Throw cause of this exception Backtrace: 0: clojure.lang.Compiler.eval(Compiler.java:4533) 1: clojure.core$eval__3969.invoke(core.clj:1738) 2: swank.commands.basic$eval_region__650.invoke(basic.clj:35) 3: swank.commands.basic$listener_eval__659.invoke(basic.clj:49) 4: clojure.lang.Var.invoke(Var.java:346) 5: user$eval__1833.invoke(Unknown Source) 6: clojure.lang.Compiler.eval(Compiler.java:4522) 7: clojure.core$eval__3969.invoke(core.clj:1738) 8: swank.core$eval_in_emacs_package__307.invoke(core.clj:55) 9: swank.core$eval_for_emacs__382.invoke(core.clj:123) 10: clojure.lang.Var.invoke(Var.java:354) 11: clojure.lang.AFn.applyToHelper(AFn.java:179) 12: clojure.lang.Var.applyTo(Var.java:463) 13: clojure.core$apply__3228.doInvoke(core.clj:408) 14: clojure.lang.RestFn.invoke(RestFn.java:428) 15: swank.core$eval_from_control__310.invoke(core.clj:62) 16: swank.core$eval_loop__313.invoke(core.clj:67) 17: swank.core$spawn_repl_thread__441$fn__470$fn__472.invoke(core.clj: 168) 18: clojure.lang.AFn.applyToHelper(AFn.java:171) 19: clojure.lang.AFn.applyTo(AFn.java:164) 20: clojure.core$apply__3228.doInvoke(core.clj:408) 21: clojure.lang.RestFn.invoke(RestFn.java:428) 22: swank.core$spawn_repl_thread__441$fn__470.doInvoke(core.clj:165) 23: clojure.lang.RestFn.invoke(RestFn.java:402) 24: clojure.lang.AFn.run(AFn.java:37) 25: java.lang.Thread.run(Thread.java:636) Caused by: String index out of range: 6 [Thrown class java.lang.StringIndexOutOfBoundsException] Restarts: 0: [ABORT] Return to SLIME's top level. Backtrace: 0: java.lang.AbstractStringBuilder.substring (AbstractStringBuilder.java:875) 1: java.lang.StringBuffer.substring(StringBuffer.java:433) 2: swank.util.io$call_on_flush_stream__161$fn__163.invoke(io.clj:25) 3: clojure.proxy.java.io.StringWriter.flush(Unknown Source) 4: clojure.core$flush__4135.invoke(core.clj:2057) 5: clojure.core$prn__4138.doInvoke(core.clj:2066) 6: clojure.lang.RestFn.applyTo(RestFn.java:142) 7: clojure.core$apply__3228.doInvoke(core.clj:408) 8: clojure.lang.RestFn.invoke(RestFn.java:428) 9: clojure.core$println__4144.doInvoke(core.clj:2079) 10: clojure.lang.RestFn.invoke(RestFn.java:413) 11: user$eval__1836.invoke(Unknown Source) 12: clojure.lang.Compiler.eval(Compiler.java:4522) 13: clojure.core$eval__3969.invoke(core.clj:1738) 14: swank.commands.basic$eval_region__650.invoke(basic.clj:35) 15: swank.commands.basic$listener_eval__659.invoke(basic.clj:49) 16: clojure.lang.Var.invoke(Var.java:346) 17: user$eval__1833.invoke(Unknown Source) 18: clojure.lang.Compiler.eval(Compiler.java:4522) 19: clojure.core$eval__3969.invoke(core.clj:1738) 20: swank.core$eval_in_emacs_package__307.invoke(core.clj:55) 21: swank.core$eval_for_emacs__382.invoke(core.clj:123) 22: clojure.lang.Var.invoke(Var.java:354) 23: clojure.lang.AFn.applyToHelper(AFn.java:179) 24: clojure.lang.Var.applyTo(Var.java:463) 25: clojure.core$apply__3228.doInvoke(core.clj:408) 26: clojure.lang.RestFn.invoke(RestFn.java:428) 27: swank.core$eval_from_control__310.invoke(core.clj:62) 28: swank.core$eval_loop__313.invoke(core.clj:67) 29: swank.core$spawn_repl_thread__441$fn__470$fn__472.invoke(core.clj: 168) 30: clojure.lang.AFn.applyToHelper(AFn.java:171) 31: clojure.lang.AFn.applyTo(AFn.java:164) 32: clojure.core$apply__3228.doInvoke(core.clj:408) 33: clojure.lang.RestFn.invoke(RestFn.java:428) 34: swank.core$spawn_repl_thread__441$fn__470.doInvoke(core.clj:165) 35: clojure.lang.RestFn.invoke(RestFn.java:402) 36: clojure.lang.AFn.run(AFn.java:37) 37: java.lang.Thread.run(Thread.java:636) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
printing a ref with type metadata
Hi,
When I type the following in at the REPL:
(def foo (ref {} :meta {:type :t}))
and then try to print it, I get the following error:
java.lang.ClassCastException: clojure.lang.Ref (NO_SOURCE_FILE:0)
[Thrown class clojure.lang.Compiler$CompilerException]
Is this a bug?
Thanks,
Scott
--~--~-~--~~~---~--~~
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: oo
2009/3/27 Konrad Hinsen konrad.hin...@laposte.net
On the other hand, I would definitely like to be able to implement
left-to-right precedence myself on top of Clojure's multimethods, and
it seems that at the moment this is not possible.
Yes.
And also the ability to redefine the method that tries to determine
candidate dispatch values, so that one could write polymorphic functions not
only based on ahead of time defined data hierarchy graphs.
One solution could be to add more options to defmulti.
Another solution could be to have a *defmulti-flavor* global var that could
have for value some hashmap : { :dispatch-value-matcher function1
:dispatch-value-narrower function2 } that could be bound to a different
flavor for certain multifunctions by library creators.
Without that, for example, I don't know how one could prevent the
combinatorial explosion of the prefer-method calls to make, even inside the
boundaries of a library, even with simple hierarchies without multiple
inheritence, for the following problem:
A, B, C, D, E, F all inherit from Z.
The library implementor wants to provide specialized functions such as:
(defmethod a-method [A B C D] [a b c d] ...)
(defmethod a-method [A B D C] [a b d c] ...)
If the implementor is able to concisely describe the resolution mechanism
with an algorithm (a function), he still will have to implement the results
of his algorithm in terms of prefer-method declarations.
For example, the classic above cited resolution mechanism the leftmost
specific wins must be manually hard-coded. And in this special case it gets
even worse for extension purpose as well.
--
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
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
-~--~~~~--~~--~--~---
questions about clojure.contrib.error-kit
(1) Is there any reasonable way to attach handlers to lazy sequences such that the handlers will still be in place outside the original handler scope, when the sequence is finally evaluated? (It is not obvious to me how to do this without making the handler system part of the language core.) (2) When using continue-with while mapping a sequence, I find myself wanting to simply ignore error conditions (instead of having continue- with contribute nil or some error token to the sequence which I then have to filter out). What is the most idiomatic way to do this? Thanks, Stu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
PATCH: printing a ref with type metadata
On Mar 27, 2009, at 12:55, Konrad Hinsen wrote: I'd say yes. Here's what happens: Typing foo at the REPL causes a call to clojure.core/print-method. This is a multimethod that dispatches on the result of clojure.core/type, which is the value of the :type tag in the metadata if there is one. Since there is no implementation for type :t, the default implementation is called, which is: (defmethod print-method :default [o, #^Writer w] (print-method (vary-meta o #(dissoc % :type)) w)) It is the call to vary-meta that fails for a ref. The attached patch fixes the bug. Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- print-method.patch Description: Binary data
Re: printing a ref with type metadata
On Mar 26, 2009, at 22:44, srader wrote:
When I type the following in at the REPL:
(def foo (ref {} :meta {:type :t}))
and then try to print it, I get the following error:
java.lang.ClassCastException: clojure.lang.Ref (NO_SOURCE_FILE:0)
[Thrown class clojure.lang.Compiler$CompilerException]
Is this a bug?
I'd say yes. Here's what happens: Typing foo at the REPL causes a
call to clojure.core/print-method. This is a multimethod that
dispatches on the result of clojure.core/type, which is the value of
the :type tag in the metadata if there is one. Since there is no
implementation for type :t, the default implementation is called,
which is:
(defmethod print-method :default [o, #^Writer w]
(print-method (vary-meta o #(dissoc % :type)) w))
It is the call to vary-meta that fails for a ref.
Konrad.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Are there ways to propagate bindings to child threads?
Hi, all. Story: I couldn't understand my binding form behavior. (binding [*print-level* 2 *print-length* 2] (some-function)) but, some outputs didn't confirm the bound value. After some investigation on my code and output, I found the reason. - I used pmap Well, I can use set!, but I think that's not a solution. I could set! *print-level* and *print-length. But I couldn't set! other defs defined in other ns. (I guess that's not intended use of set!. right?) And think about something like *out*. I don't know that's intended behavior of binding or not. Anyway I think something like thread-propagate-binding is needed. Thanks. --~--~-~--~~~---~--~~ 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: Will Clojure work on AppEngine?
Google will officially announce Java support for AppEngine at the end of May at Google IO: http://ru.ly/T6 Clojure web apps will have access to BigTable and be able to auto-scale based on load. Clojure in the cloud! Robin On Feb 2, 2:35 pm, Mark Derricutt m...@talios.com wrote: I wonder if the Classloader issues that currently affect OSGi would impact an app-engine style deployment scenario as well. My understanding of the issue is that each different classloader would pick up its own RT and compile/generate up different versions of the core classes under each classloader. ( I'm willing to be totally corrected here, I'm still very new to clojure, and the issues we're seeing under OSGi ). ...and then Buffy staked Edward. The End. On Tue, Feb 3, 2009 at 8:26 AM, Robin robi...@gmail.com wrote: I am not an expert on the JVM, but I think Google's runtime will disallow uploading precompiled bytecode (jar). The assumption is that if you can compile it on their servers, then it is legal and therefore safe. I hope they allow the use of ASM library. Obviously this is speculation, but can you foresee any corner cases where Clojure's use of ASM might be considered 'unsafe' by Google? Thanks, Robin On Jan 29, 9:33 am, Rich Hickey richhic...@gmail.com wrote: On Jan 27, 2:44 pm, Robin robi...@gmail.com wrote: Under a huge assumption that Google will soon announce a 'Java compatible' runtime forAppEngine. Could Clojure work out of the box? Would Clojure's dynamic generation of ASM/bytecode pose a security problem for a generic sandboxed environment? If expected conflicts exist, what kind of adaptation would it take to port Clojure? I imagine ahead-of-time compiled Clojure code would pose the least challenge, at it requires no custom classloader or dynamic bytecode. Currently, AOT is enabling both untrusted applets and conversion for Android/Dalvik. As far as dynamic bytecode, that has a lot to do with the sandbox. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
children function for hierarchies
I noticed that core doesn't have a children function for hierarchies, although it has parents, descendants, and ancestors. Here's one: (defn children ([tag] (set (filter (fn [t] (contains? (parents t) tag)) (descendants tag ([h tag] (set (filter (fn [t] (contains? (parents h t) tag)) (descendants h tag) The repetition is necessary because clojure.core/global-hierarchy is private. -Stuart Sierra --~--~-~--~~~---~--~~ 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: Are there ways to propagate bindings to child threads?
On Fri, Mar 27, 2009 at 4:06 PM, hjlee hj.d@gmail.com wrote: Hi, all. Story: I couldn't understand my binding form behavior. (binding [*print-level* 2 *print-length* 2] (some-function)) but, some outputs didn't confirm the bound value. After some investigation on my code and output, I found the reason. - I used pmap Well, I can use set!, but I think that's not a solution. I could set! *print-level* and *print-length. But I couldn't set! other defs defined in other ns. (I guess that's not intended use of set!. right?) And think about something like *out*. I don't know that's intended behavior of binding or not. Anyway I think something like thread-propagate-binding is needed. Maybe this explains what you are seeing? http://groups.google.com/group/clojure/browse_thread/thread/2bc20199ae5db74d/444619b6093073d5?lnk=gstq=Unexpected+binding+behavior#444619b6093073d5 -- Michael Wood esiot...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 and swank on Android?
After some googling I found out that some people were able to run Clojure on Android phones. Did anyone tried to port swank to Android? It might seem like a good idea to start swank server on the phone, connnect with slime, and have good old live programming environment. Regards, Marko Kocić --~--~-~--~~~---~--~~ 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: Are there ways to propagate bindings to child threads?
On Fri, Mar 27, 2009 at 10:06 AM, hjlee hj.d@gmail.com wrote: Hi, all. Story: I couldn't understand my binding form behavior. (binding [*print-level* 2 *print-length* 2] (some-function)) but, some outputs didn't confirm the bound value. After some investigation on my code and output, I found the reason. - I used pmap Well, I can use set!, but I think that's not a solution. I could set! *print-level* and *print-length. But I couldn't set! other defs defined in other ns. (I guess that's not intended use of set!. right?) And think about something like *out*. You could always propagate the bindings like so: (binding [*print-level* 2 *print-length* 2] (some-function *print-level* *print-length*)) Or write a wrapper function that takes the binding values, rebinds them, and calls some-function. Of course, doing so seems like it exposes a leaky abstraction. You wouldn't necessarily expect that you'd have to write it one way for map and another for pmap, but maybe it is just a case of programmer beware. Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
extra166y
I'm attempting to run some functions in the parallel library. I've downloaded jsr166y and put it in my classpath. Apparently, all of the functions that the parallel library uses got split into another library called extra166y (and the namespace was changed as well). I figured that it would be a simple matter of changing the imported namespace in parallel.clj, but now I get the following error: Exception in thread main java.lang.UnsupportedClassVersionError: Bad version number in .class file (parallel.clj:0) at clojure.lang.Compiler.eval(Compiler.java:4533) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.RT.loadResourceScript(RT.java:325) at clojure.lang.RT.loadResourceScript(RT.java:316) at clojure.lang.RT.load(RT.java:394) at clojure.lang.RT.load(RT.java:366) at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) at clojure.core$load__5036.doInvoke(core.clj:3740) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.core$load_one__4988.invoke(core.clj:3585) at clojure.core$load_lib__5009.doInvoke(core.clj:3622) at clojure.lang.RestFn.applyTo(RestFn.java:147) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$load_libs__5021.doInvoke(core.clj:3648) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$require__5027.doInvoke(core.clj:3708) at clojure.lang.RestFn.invoke(RestFn.java:426) at user$eval__79.invoke(alg.clj:1) at clojure.lang.Compiler.eval(Compiler.java:4522) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.RT.loadResourceScript(RT.java:325) at clojure.lang.RT.loadResourceScript(RT.java:316) at clojure.lang.RT.load(RT.java:394) at clojure.lang.RT.load(RT.java:366) at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) at clojure.core$load__5036.doInvoke(core.clj:3740) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.core$load_one__4988.invoke(core.clj:3585) at clojure.core$load_lib__5009.doInvoke(core.clj:3622) at clojure.lang.RestFn.applyTo(RestFn.java:147) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$load_libs__5021.doInvoke(core.clj:3648) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$require__5027.doInvoke(core.clj:3708) at clojure.lang.RestFn.invoke(RestFn.java:413) at user$eval__76.invoke(main.clj:6) at clojure.lang.Compiler.eval(Compiler.java:4522) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.Compiler.loadFile(Compiler.java:4813) at clojure.main$load_script__5793.invoke(main.clj:206) at clojure.main$init_opt__5796.invoke(main.clj:211) at clojure.main$initialize__5806.invoke(main.clj:239) at clojure.main$null_opt__5828.invoke(main.clj:264) at clojure.main$legacy_script__5843.invoke(main.clj:295) at clojure.lang.Var.invoke(Var.java:346) at clojure.main.legacy_script(main.java:34) at clojure.lang.Script.main(Script.java:20) Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) 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 java.lang.ClassLoader.loadClass(ClassLoader.java:316) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at clojure.lang.RT.classForName(RT.java:1486) at clojure.core$import__4007.doInvoke(core.clj:1870) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.parallel$eval__91.invoke(parallel.clj:38) at clojure.lang.Compiler.eval(Compiler.java:4522) ... 52 more Is there any way to fix this?
Re: extra166y
Hi Jason, If you use the jsr166y from the files section of the group (http:// clojure.googlegroups.com/web/jsr166y.jar) you should be okay. I know this doesn't help with the exception you are getting, but it may get you moving forward. Cheers, Tom http://clojure-log.n01se.net/date/2009-01-31.html#12:19 On Mar 27, 1:55 pm, Jason Baker amnorv...@gmail.com wrote: I'm attempting to run some functions in the parallel library. I've downloaded jsr166y and put it in my classpath. Apparently, all of the functions that the parallel library uses got split into another library called extra166y (and the namespace was changed as well). I figured that it would be a simple matter of changing the imported namespace in parallel.clj, but now I get the following error: Exception in thread main java.lang.UnsupportedClassVersionError: Bad version number in .class file (parallel.clj:0) at clojure.lang.Compiler.eval(Compiler.java:4533) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.RT.loadResourceScript(RT.java:325) at clojure.lang.RT.loadResourceScript(RT.java:316) at clojure.lang.RT.load(RT.java:394) at clojure.lang.RT.load(RT.java:366) at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) at clojure.core$load__5036.doInvoke(core.clj:3740) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.core$load_one__4988.invoke(core.clj:3585) at clojure.core$load_lib__5009.doInvoke(core.clj:3622) at clojure.lang.RestFn.applyTo(RestFn.java:147) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$load_libs__5021.doInvoke(core.clj:3648) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$require__5027.doInvoke(core.clj:3708) at clojure.lang.RestFn.invoke(RestFn.java:426) at user$eval__79.invoke(alg.clj:1) at clojure.lang.Compiler.eval(Compiler.java:4522) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.RT.loadResourceScript(RT.java:325) at clojure.lang.RT.loadResourceScript(RT.java:316) at clojure.lang.RT.load(RT.java:394) at clojure.lang.RT.load(RT.java:366) at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) at clojure.core$load__5036.doInvoke(core.clj:3740) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.core$load_one__4988.invoke(core.clj:3585) at clojure.core$load_lib__5009.doInvoke(core.clj:3622) at clojure.lang.RestFn.applyTo(RestFn.java:147) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$load_libs__5021.doInvoke(core.clj:3648) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$require__5027.doInvoke(core.clj:3708) at clojure.lang.RestFn.invoke(RestFn.java:413) at user$eval__76.invoke(main.clj:6) at clojure.lang.Compiler.eval(Compiler.java:4522) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.Compiler.loadFile(Compiler.java:4813) at clojure.main$load_script__5793.invoke(main.clj:206) at clojure.main$init_opt__5796.invoke(main.clj:211) at clojure.main$initialize__5806.invoke(main.clj:239) at clojure.main$null_opt__5828.invoke(main.clj:264) at clojure.main$legacy_script__5843.invoke(main.clj:295) at clojure.lang.Var.invoke(Var.java:346) at clojure.main.legacy_script(main.java:34) at clojure.lang.Script.main(Script.java:20) Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) 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 java.lang.ClassLoader.loadClass(ClassLoader.java:316) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374) at
Scala vs Clojure
Can anyone who has tried both of these languages to a decent degree compare them in practical terms? In other words, I am not interested in the technical aspects of the languages themselves (e.g. dynamic vs static typing) but things like IDE support, tools (lexers and parsers), standard libraries, books and their quality, existing commercial applications and the commercial viability of shipping products targeted at their programmers (e.g. libraries)? I've never done anything significant on the JVM so I'm interested in picking one of these two languages and shipping a product for it. I've done a lot of commercial work with F# over the past 2 years but all Microsoft-related sales have died this year so I'm looking to diversify... Many thanks, -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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: oo
On Mar 27, 5:56 am, Konrad Hinsen konrad.hin...@laposte.net wrote: On Mar 27, 2009, at 9:25, Mark Engelberg wrote: Considering how complex the situation can get with single dispatch, I imagine it gets even more complex in multiple dispatch situations. In the multimethods example at clojure.org/multimethods, an example is given of disambiguating between [::shape ::rect] and [::rect ::shape]. But again, if you're writing the bar method from outside of the library which defines ::shape and ::rect, you might not even know which is more specific. It might be easier to choose a strategy, such as more specific on the leftmost taking precedence, than to know the details of how the various types in the library interact. I am not so sure about this. I wonder if there is a real-life use case where a client library would need to solve dispatching issues on types in another library about which it doesn't know anything. No, because such a library won't get used. If I offered a customer a library with the caveat that his people might run into unexpected dispatch conflicts that could be solved simply by reading the library sources, he'd say, thanks, I'll pass. If there isn't, the problem is not relevant, and if there is, I'd like to see a demonstration that something like left-to-right precedence is indeed a reasonable default. I can tell you about large software projects in which left-to-right precedence worked well. Demonstrate? That's a lot of code to recapitulate! There is nothing magical about left-to-right precedence, except that *you know in advance what it is*. You can reason about it, because you know what it is. You can predict what kinds of uses will be a problem, and therefore can avoid those problems. For purposes of writing reusable and extensible subsystems, *any* defined order is better than no defined order. On the other hand, I would definitely like to be able to implement left-to-right precedence myself on top of Clojure's multimethods, and it seems that at the moment this is not possible. There it is: it's fine if Clojure doesn't define a default and universal traversal order for MultiFn dispatch, as long as I can define such an order when I need it. prefer-method isn't quite enough, because it only works on dispatch values that are already defined. In order to make a safely-extensible library, I need to be able to prescribe a traversal order over dispatch values that haven't yet been created. I have a separate issue with prefer-method, in that it defines traversal order implicitly, in a way that is hard to digest. That is, you can't look in one place to find out what the traversal is; you instead have to search out all the prefer-method calls and piece the order together from examining each of them. That's tangential to the present discussion, though. If none of these considerations moves Rich much, that's okay. He gave us the tools we need to write our own solutions. --~--~-~--~~~---~--~~ 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: PATCH: printing a ref with type metadata
Thanks for the explanation and the patch. But instead of patching print-method, maybe vary-meta should be patched to handle refs? Scott On Mar 27, 7:07 am, Konrad Hinsen konrad.hin...@laposte.net wrote: On Mar 27, 2009, at 12:55, Konrad Hinsen wrote: I'd say yes. Here's what happens: Typing foo at the REPL causes a call to clojure.core/print-method. This is a multimethod that dispatches on the result of clojure.core/type, which is the value of the :type tag in the metadata if there is one. Since there is no implementation for type :t, the default implementation is called, which is: (defmethod print-method :default [o, #^Writer w] (print-method (vary-meta o #(dissoc % :type)) w)) It is the call to vary-meta that fails for a ref. The attached patch fixes the bug. Konrad. print-method.patch 1KViewDownload --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
