Class generation
On Oct 19, 1:12 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> At that point, I'll have some syntax for adorning defns with metadata
> that will do what was once the work of genclass, and I'll be able to
> incorporate in that the enhancements to genclass that have been
> requested.
>
> I hope to have some drops of AOT soon after I return from Lisp50 at
> OOPSLA. Until then, I'd encourage everyone who has ideas about how the
> metadata annotations might look to chime in.
I'd think you'd annotate each "arity clause" in a fn with it's
destination, and use the function metadata for whole-class things.
(defn Clazz
"example class defined through Clojure"
{:extends OtherClazz
:fields '[#^Integer aaa #^Integer bbb]}
;; super constructor args specified
#^{:constructor [Object Object]}
([this #^Integer init-aaa]
(prn "initializing")
;; vector returned for super constructor args
[4 5])
;; a simple method that returns the sum of an argument and a field
#^{:method fff}
(#^BigInteger [this n]
(+ (. this aaa) n)))
(I haven't played with metadata enough so some details may be
off)
I left out the initialization of the fields as they either have to be
returned from our "constructor" as a map (like what gen-class does),
or they have to be non-final so they can be set from our external
"constructor", or the complete constructor has to be baked into the
class making it completely non-malleable. The function compilation
code needs to know about every possible detail we wish to support. I'd
hope it would be possible to define static members, mutable fields,
annotations, etc, so that generated classes could look like first-
class JVM libraries rather than wrappers. (A Clojure library would
likely expose functional semantics over setField methods, but I don't
see a reason to disallow mutable fields. But does code to generate
mutable fields belong in the core?)
What could be a lot simpler and more flexible is providing a hook into
the compiler that would take a method expression (one function arity
clause) and an ASM MethodVisitor on which to write bytecode. With some
primitive forms for calling super methods/constructors and hooks into
AOT class saving, Clojure macros could be written to generate any sort
of class, while all of the details and tradeoffs could be kept well
away from Compiler land. (One could even extend those macros to
generate some hand-assembled methods if they needed more exact control
and didn't want to drop to Java)
Steve
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Modified doto
On non-backwards compatible language changes in general, isn't it trivial to write a source-code converter? Especially given the ease of Clojure's macro system, all you would need is a systematic find and replace on any code that uses the current doto right? That would save the manual labor of having to updating all the current libraries. Or am I missing something vital? -Patrick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: playing with metadata
Hi Stuart and Rich, Stuart Halloway <[EMAIL PROTECTED]> writes: > Hi Jose, > > The key determinant of metadata in Clojure is whether the data is > orthogonal to equality. Would two tasks with identical behavior but > different staleness predicates be equal? I would say no, hence a > staleness predicate would be data, not metadata. > Only if you consider the staleness predicate as metadata attached to the build procedure. In my proposal, all behaviour would be metadata, and staleness predicates would be part of that behaviour. I was thinking of a task as a set of generic functions (staleness, build...) acting on data with the right structure. The whole bunch of functions (stored in a map, actually as Rich suggests) would become metadata attached to the data. Something like an alternative to multimethods, if you will. That way, the actual data can be viewed as an entity in and by itself, usable in other contexts. One could also think of it as cheap prototypes (in the Self vein) where method slots are stored as metadata [1]. It could be argued, though, that two objects with different methods should be considered different, and metadata would then be a bad implementation choice. But then again, comparing behaviour (as represented by procedures) is always a pesky business. Thanks to both for chiming in! Cheers, jao Footnotes: [1] Actually, another fun project would be a port of something like Prometheus (http://www.forcix.cx/software/prometheus/prometheus.html) to Clojure [2], perhaps using such a mechanism. [2] BTW, what's the accepted spelling: Clojure or clojure? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (seq? "abc")
On Oct 2, 2008, at 2:58 PM, Stuart Halloway wrote: > Right. So, should sort work? > > user=> (sort "bca") > java.lang.IncompatibleClassChangeError: Class java.lang.String does > not implement the requested interface java.util.Collection It does work and returns a sorted seq of characters. I don't know why you got the result you did. I think I've seen IncompatibleClassChangeErrors clear with a re-launch of Clojure, but I don't know what causes them: user=> (sort "bca") (\a \b \c) On Oct 2, 2008, at 5:26 PM, Stephen C. Gilardi wrote: > I think changing [sort and sort-by] to be consistent with the rest > of the sequence functions in [automatically calling seq on their > arguments] would be a good idea. Looking further into this, I see that doing this would be incorrect. Preserving the type of the argument through to an internal call to "to- array" allows for an efficient, type-specific operation to put the contents of coll into the Java array that's used for sorting. --Steve --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
take goes too far
I ran into a problem with "take" today (thanks to wwmorgan on IRC for helping steer me away from blaming "filter"). My actual code had to do with computing a subset of primes, but let's take a simpler example. (defn painful-seq [] (lazy-cat [0 1 2] (comment lots of hard work here) (list 99))) user=> (lazy-cat [0 1 2] (painful-list)) (0 1 2 99) This is meant to represent 3 easy-to-compute values, followed by the hard-to-compute number 99. So now if we take only those first three, we avoid having to compute 99, right? user=> (take 3 (painful-seq)) (0 1 2) Well, it looks good. But let's "instrument" the code, as the cool kids put it: (defn painful-seq [] (lazy-cat [0 1 2] (println "hurt me plenty") (list 99))) user=> (take 3 (painful-seq)) (0 1 hurt me plenty 2) Whoops. The return value is correct as we saw earlier, but before 2 gets returned, we apparently go on and compute that next expensive value. This is despite the fact that nobody even wants it. So I wrote up an new "take" function that seems to fix this: user=> (my-take 3 (painful-seq)) (0 1 2) Of course if you actually want the fourth value, there's nothing I can do for you. (0 1 hurt me plenty 2 99) Here's "my-take" renamed to "take" for easy patching of boot.clj: http://paste.lisp.org/display/69146 --Chouser --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Patch: supporting primitive and array classes in print-method
The existing implementation of print-method for Class objects emits unreadable representations for primitive classes (Float/TYPE, etc) and array classes (Object[], etc). Attached is a patch that results in both types of classes being printed readably. Rich, thanks for the feedback in irc... - Chas --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~--- class-print-method.patch Description: Binary data
Re: Clojure and introspection/reflection analysis?
On Oct 24, 5:36 pm, BerlinBrown <[EMAIL PROTECTED]> wrote: > On Oct 24, 2:34 am, mritun <[EMAIL PROTECTED]> wrote: > > > > > Hi > > > Take a look at btrace. It is DTrace like dynamic instrumentation tool > > for JVM (DTrace : System :: btrace : JVM, though DTrace is superset of > > btrace). > > > It allows you to instrument JVM at bytecode level with no changes in > > code. > > > It might also help going forward to enhance clojure to insert btrace > > probes. These probes can help expose higher level details to > > instrumentation tools like btrace and would help professional > > developers immensely. > > > - Akhilesh > > > On Oct 24, 5:03 am, BerlinBrown <[EMAIL PROTECTED]> wrote: > > > > On Oct 23, 6:42 pm, BerlinBrown <[EMAIL PROTECTED]> wrote: > > > > > I asked this on common lisp thread but I want to work with clojure as > > > > well: > > > > > With clojure and I am assuming the introspection properties. How > > > > can I add code to clojure code that will tell me when a function > > > > is called and when has finished executing. I want to take any lisp > > > > code and this particular modification to the code. I figure with > > > > lisp's AST analysis, this should be possible. > > > > > For example, pseudo code in common lisp, hello_world.lisp: > > > > > (defun hello-world () > > > > (format t "Hello World")) > > > > > (hello-world) > > > > > And then I have a utility to load hello_world.lisp and execute > > > > the hello-world call. > > > > > At the command line: > > > > #Inspect: hello-world function was called > > > > #Hello World > > > > #Inspect: hello-world has finished executing. > > > > Another similar question (second question): > > > > If you have used ASM, I can do a lot of this "trace" type > > > functionality with the bytecode manipulator ASM (and obviously > > > reflection) but I was also looking for the clojure way. > > > http://asm.objectweb.org/). > > > Or maybe even reflection. Is there something in clojure that might > > > allow me to see when a function is called. > > > > For example, with ASM, I can get the following information of a > > > method: > > > > protected (Ljava/lang/String;)V > > > ALOAD 0 > > > INVOKESPECIAL java/lang/Object.()V > > > ALOAD 0 > > > ALOAD 1 > > > PUTFIELD org/objectweb/asm/Attribute.type : Ljava/lang/String; > > > RETURN > > > MAXSTACK = 2 > > > MAXLOCALS = 2 > > > > > > > What is put on the stack and when methods are invoked. > > > > Does something similar exist for ASM? > > http://clojure.org/other_libraries > > Zipper may also be something that I could use. Is the zipper library still available? http://groups.google.com/group/clojure/browse_thread/thread/a0c84046d3f31c88/f612a67cd0c4af15?lnk=gst&q=zipper#f612a67cd0c4af15 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure and introspection/reflection analysis?
On Oct 24, 2:34 am, mritun <[EMAIL PROTECTED]> wrote: > Hi > > Take a look at btrace. It is DTrace like dynamic instrumentation tool > for JVM (DTrace : System :: btrace : JVM, though DTrace is superset of > btrace). > > It allows you to instrument JVM at bytecode level with no changes in > code. > > It might also help going forward to enhance clojure to insert btrace > probes. These probes can help expose higher level details to > instrumentation tools like btrace and would help professional > developers immensely. > > - Akhilesh > > On Oct 24, 5:03 am, BerlinBrown <[EMAIL PROTECTED]> wrote: > > > On Oct 23, 6:42 pm, BerlinBrown <[EMAIL PROTECTED]> wrote: > > > > I asked this on common lisp thread but I want to work with clojure as > > > well: > > > > With clojure and I am assuming the introspection properties. How > > > can I add code to clojure code that will tell me when a function > > > is called and when has finished executing. I want to take any lisp > > > code and this particular modification to the code. I figure with > > > lisp's AST analysis, this should be possible. > > > > For example, pseudo code in common lisp, hello_world.lisp: > > > > (defun hello-world () > > > (format t "Hello World")) > > > > (hello-world) > > > > And then I have a utility to load hello_world.lisp and execute > > > the hello-world call. > > > > At the command line: > > > #Inspect: hello-world function was called > > > #Hello World > > > #Inspect: hello-world has finished executing. > > > Another similar question (second question): > > > If you have used ASM, I can do a lot of this "trace" type > > functionality with the bytecode manipulator ASM (and obviously > > reflection) but I was also looking for the clojure way. > > http://asm.objectweb.org/). > > Or maybe even reflection. Is there something in clojure that might > > allow me to see when a function is called. > > > For example, with ASM, I can get the following information of a > > method: > > > protected (Ljava/lang/String;)V > > ALOAD 0 > > INVOKESPECIAL java/lang/Object.()V > > ALOAD 0 > > ALOAD 1 > > PUTFIELD org/objectweb/asm/Attribute.type : Ljava/lang/String; > > RETURN > > MAXSTACK = 2 > > MAXLOCALS = 2 > > > > > What is put on the stack and when methods are invoked. > > > Does something similar exist for ASM? http://clojure.org/other_libraries Zipper may also be something that I could use. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Ideal Hash Trees (Bagwell paper)
Hi there, First, thanks for this great language and all the media available. Clojure talks are really good ! Just in one of these talks, Rich talks about "Array Mapped Trees" and I have read that Bagwell's paper : "Ideal Hash Trees". Maybe my question is pretty dummy but Bagwell talks about key insertion/search in these hashes and I do not get how to distinguish between a bucket that is a Key/Value pair (so it is a terminal node) and a Map/Base one (so it is a pointer to another hash table) neither during initial insertions nor searching for keys. Any help to clarify this ? Thx ! Best regards, Raúl --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
On Fri, Oct 24, 2008 at 10:31 AM, Craig Andera <[EMAIL PROTECTED]> wrote: > >>> It's very likely/nearly certain I'm still doing something wrong - I >>> appreciate the help. > > Indeed it was me: everything started working as soon as I made sure my > .clj files were in CLASSPATH the way require describes they should be. > I'm sure it doesn't help that I'm a Java n00b in addition to being a > Clojure neophyte. > > As a bonus, require works now, too. Lesson learned: putting your files > anywhere else is asking for trouble. > > Thanks, Bill - it's always inspiring when someone else makes an effort > - keeps me from ignoring the problem for too long! (Been a fan of your > blog for quite a while now, BTW.) Hat tip to Allen as well. Great - glad to hear that you got it working! - Bill --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch available: *print-length*, *print-level*
On Oct 24, 1:16 pm, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote: > *print-length* and *print-level* do affect print and println as well > as pr and prn and pr-str. Ah, my mistake. Never mind, then. -Stuart --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
>> It's very likely/nearly certain I'm still doing something wrong - I >> appreciate the help. Indeed it was me: everything started working as soon as I made sure my .clj files were in CLASSPATH the way require describes they should be. I'm sure it doesn't help that I'm a Java n00b in addition to being a Clojure neophyte. As a bonus, require works now, too. Lesson learned: putting your files anywhere else is asking for trouble. Thanks, Bill - it's always inspiring when someone else makes an effort - keeps me from ignoring the problem for too long! (Been a fan of your blog for quite a while now, BTW.) Hat tip to Allen as well. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch available: *print-length*, *print-level*
On Oct 24, 2008, at 12:18 PM, Stuart Sierra wrote: > On Oct 24, 2:55 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote: >> I've uploaded a patch that implements Common Lisp's *print-length* >> and >> *print-level* for Clojure: > > Really nice. Thanks, Stephen! Thanks! :-) > Could the *print-level* cutoff > indicator be something more visible than '#'? Maybe '#=(...)' or > something. I went with Common Lisp precedent. Thinking about it further, it seems it would be nice to use something that's guaranteed unreadable. As it is now, it will be a \# followed by a collection-dependent separator or by a collection-dependent "end" character (like \) or \] or \}). Perhaps it would be better to print a known, fixed dispatch character right after the \# so that the entire thing is guaranteed unreadable. Do we have a dispatch character reserved for that already? > I've attached a patch to add *print-str-length* that does the same > thing for strings: > > user=> (set! *print-str-length* 30) > 30 > user=> (slurp "bigfile.xml") > " user=> (count *1) > 2540 Neat. I like it. > I feel like these variables should be named '*pr-level*' and so on, > since they affect 'pr' and 'pr-str' but not 'print'. *print-length* and *print-level* do affect print and println as well as pr and prn and pr-str. --Steve --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
On Fri, Oct 24, 2008 at 8:16 AM, Craig Andera <[EMAIL PROTECTED]> wrote: > >> No, that's not enough. You didn't specify the port that you want to >> connect to JSwat on. add "address=" (or something similar) to this >> to specify which port you want to use. In my blog example, I'm using >> "": >> -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address= > >> Port "50525" is the port that SLIME/SWANK is using to establish the >> communications between your running Clojure instance and the emacs >> lisp code. You can't use this same port for JSwat. > > Actually, there are two port-related messages in *inferior-lisp*: one > talks about the port that SLIME is using to talk to SWANK, and I used > the other one. So it appears that a port is chosen for you if you > don't specify one. And as I said, I'm able to attach JSwat and set > (and, more importantly, trigger) breakpoints in boot.clj. So I don't > think anything was wrong with how I was connecting JSwat. > > That said, I went head and did as you suggested (it's a PITA to look > up the port every time as I had been doing), but still no luck. > >> If you do the above, it should work for you. > > If only that were true. :) > > It's very likely/nearly certain I'm still doing something wrong - I > appreciate the help. I'm grasping at straws here, but: 1. Presumably, you're running a compatible version of JSwat (the latest version doesn't work with Java 1.5) 2. Presumably, you've tried setting breakpoints on multiple lines in your source file (for some reason, you can't always set a breakpoint on a clojure line - I haven't figured out why, maybe something to do with whether the statement is defined with defn or not). 3. Presumably, you've tried debugging different source files (in case there's some peculiar problem with the specific source file you're attempting to debug) It might help if you create a small clojure program, and note down all the steps that you go through. Then, I can replicate what you're doing and see if I get a different result. - Bill --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch available: *print-length*, *print-level*
On Oct 24, 12:18 pm, "Stuart Sierra" <[EMAIL PROTECTED]> wrote:
> I've attached a patch to add *print-str-length* that does the same
> thing for strings:
Okay, NOW I've attached a patch.
-Stuart
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Index: src/clj/clojure/boot.clj
===
--- src/clj/clojure/boot.clj (revision 1077)
+++ src/clj/clojure/boot.clj (working copy)
@@ -3451,6 +3451,15 @@
is nil indicating no limit."}
*print-level* nil)
+(def
+ #^{:doc "*print-str-length* controls the maximum length of a
+ string the printer will print. If it is bound to logical false,
+ there is no limit. Otherwise, it must be bound to an integer
+ indicating the maximum length of string to print. Longer strings
+ will be truncated with '...' to represent the remaining
+ characters."}
+*print-str-length* nil)
+
(defn- print-sequential [#^String begin, print-one, #^String sep, #^String end, sequence, #^Writer w]
(binding [*print-level* (and *print-level* (dec *print-level*))]
(if (and *print-level* (neg? *print-level*))
@@ -3545,12 +3554,15 @@
(defmethod print-method String [#^String s, #^Writer w]
(if *print-readably*
-(do (.append w \")
- (dotimes n (count s)
-(let [c (.charAt s n)
- e (char-escape-string c)]
- (if e (.write w e) (.append w c
- (.append w \"))
+(let [s (if (and *print-str-length* (> (count s) *print-str-length*))
+ (str (subs s 0 *print-str-length*) "...")
+ s)]
+ (do (.append w \")
+ (dotimes n (count s)
+(let [c (.charAt s n)
+ e (char-escape-string c)]
+ (if e (.write w e) (.append w c
+ (.append w \")))
(.write w s))
nil)
Index: src/jvm/clojure/lang/Repl.java
===
--- src/jvm/clojure/lang/Repl.java (revision 1077)
+++ src/jvm/clojure/lang/Repl.java (working copy)
@@ -26,6 +26,7 @@
static final Var warn_on_reflection = RT.var("clojure", "*warn-on-reflection*");
static final Var print_meta = RT.var("clojure", "*print-meta*");
static final Var print_length = RT.var("clojure", "*print-length*");
+static final Var print_str_length = RT.var("clojure", "*print-str-length*");
static final Var print_level = RT.var("clojure", "*print-level*");
static final Var star1 = RT.var("clojure", "*1");
static final Var star2 = RT.var("clojure", "*2");
@@ -47,6 +48,7 @@
warn_on_reflection, warn_on_reflection.get(),
print_meta, print_meta.get(),
print_length, print_length.get(),
+ print_str_length, print_str_length.get(),
print_level, print_level.get(),
star1, null,
star2, null,
Re: Patch available: *print-length*, *print-level*
On Oct 24, 2:55 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote: > I've uploaded a patch that implements Common Lisp's *print-length* and > *print-level* for Clojure: Really nice. Thanks, Stephen! Could the *print-level* cutoff indicator be something more visible than '#'? Maybe '#=(...)' or something. I've attached a patch to add *print-str-length* that does the same thing for strings: user=> (set! *print-str-length* 30) 30 user=> (slurp "bigfile.xml") " (count *1) 2540 I feel like these variables should be named '*pr-level*' and so on, since they affect 'pr' and 'pr-str' but not 'print'. -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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: use spit from clojure.contrib.duck_streams
On Oct 24, 2008, at 9:44 AM, stephan wrote: > user> (use 'clojure.contrib.duck_streams) > gives me this exception: > java.lang.Exception: namespace 'clojure.contrib.duck_streams' not > found after loading '/clojure/contrib/duck_streams/ > duck_streams.clj' (NO_SOURCE_FILE:0) - Lisps traditionally favor names with hyphens in them and Clojure continues that tradition. - For interop with Java, Clojure Namespace names map to corresponding Java Package names which in turn map to locations in ClassPath. - Unfortunately, names with hyphens in them are not legal Java Package names. (see http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.7 ). - To handle this clash, Clojure automatically converts hyphens to underscores to produce the file/directory/package names associated with a namespace. - The namespace you're looking for above is 'clojure.contrib.duck- streams' (with a hyphen). --Steve --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: use spit from clojure.contrib.duck_streams
Hi J. Thanks, that makes things a little bit clearer for a non-java- programmer. It was actually my fault to use the underscore in duck_streams instead of the minus sign. Best, Stephan On Oct 24, 4:20 pm, "J. McConnell" <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 9:44 AM, stephan <[EMAIL PROTECTED]> wrote: > > > I downloaded the svn trunk of clojure-contrib, used ant to build the > > jar-file, and copied that into a directory included in the classpath. > > Unfortunately, jars within directories in the classpath aren't picked > up by the classloaders. You either need to include the clojure-contrib > jar itself in the classpath or include the clojure-contrib/src > directory in the classpath. By including the clojure-contrib/src > directory, you won't have to build with ant anymore, which is nice, so > that's the route I've gone for now (until clojure-contrib requires an > actual build, e.g. if it includes some Java source that needs to be > built). > > HTH, > > - J. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: use spit from clojure.contrib.duck_streams
On Oct 24, 9:44 am, stephan <[EMAIL PROTECTED]> wrote: > user> (use 'clojure.contrib.duck_streams) > gives me this exception: > java.lang.Exception: namespace 'clojure.contrib.duck_streams' not > found after loading '/clojure/contrib/duck_streams/ > duck_streams.clj' (NO_SOURCE_FILE:0) Hi Stephan, This is because the underscores in file names become hyphens in library names. You want this: (use 'clojure.contrib.duck-streams) Why, you ask? Well, Lisps typically use hyphens instead of underscores, but Java doesn't allow hyphens in package names. So... we have a hack. -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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
> No, that's not enough. You didn't specify the port that you want to > connect to JSwat on. add "address=" (or something similar) to this > to specify which port you want to use. In my blog example, I'm using > "": > -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address= > Port "50525" is the port that SLIME/SWANK is using to establish the > communications between your running Clojure instance and the emacs > lisp code. You can't use this same port for JSwat. Actually, there are two port-related messages in *inferior-lisp*: one talks about the port that SLIME is using to talk to SWANK, and I used the other one. So it appears that a port is chosen for you if you don't specify one. And as I said, I'm able to attach JSwat and set (and, more importantly, trigger) breakpoints in boot.clj. So I don't think anything was wrong with how I was connecting JSwat. That said, I went head and did as you suggested (it's a PITA to look up the port every time as I had been doing), but still no luck. > If you do the above, it should work for you. If only that were true. :) It's very likely/nearly certain I'm still doing something wrong - I appreciate the help. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
Hi Craig, On Fri, Oct 24, 2008 at 7:55 AM, Craig Andera <[EMAIL PROTECTED]> wrote: > >> Are you doing all of the following: >> >> 1. Specify the appropriate debug options when you start Clojure (see >> step #4 in my blog post) > > Yep. Here's the full command line: > > c:\WINDOWS\system32\java.exe -Xdebug > -Xrunjdwp:transport=dt_socket,server=y,suspend=n -cp > "C:/bin/clojure/clojure/svn/clojure.jar;c:/data/.clojure/*" > clojure.lang.Repl No, that's not enough. You didn't specify the port that you want to connect to JSwat on. add "address=" (or something similar) to this to specify which port you want to use. In my blog example, I'm using "": -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address= >> 2. Load the Clojure source file you want to debug (you can't debug >> definitions created in the repl) > > Did so from the SLIME REPL via (load-file "/path/to/my/source.clj") > >> 3. Start JSwat and use the "Session/Attach..." menu option to attach >> to the correct host/port (in my case, "localhost" and "" since I'm >> debugging a local Java instance and I specified port "" when I >> started Java) > > Yep. Localhost and 50525 for me this time (got port from the message > spewed into *inferior-lisp*). Port "50525" is the port that SLIME/SWANK is using to establish the communications between your running Clojure instance and the emacs lisp code. You can't use this same port for JSwat. >> 4. In JSwat, open the same Clojure source file you loaded in step #2 >> and add a breakpoint (you can just click on the source line#) - note >> that you can only add breakpoints to lines in a defn, not lines in a >> defmacro definition > > Yep. > >> 5. In the Clojure repl evaluate a form that will call the function >> that has your breakpoint. > > Yep. > >> 6. In JSwat, you should see that the breakpoint has been hit and >> program execution is paused > > Nope. :p > > Fortunately I've since solved the problem I originally wanted the > debugger for (yay REPL), but it still would be nice to get this to > work... If you do the above, it should work for you. > I'm puzzled by my ability to successfully hit breakpoints in boot.clj. > That seems to imply I'm doing something partially right. -- Bill Clementson --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
> Are you doing all of the following: > > 1. Specify the appropriate debug options when you start Clojure (see > step #4 in my blog post) Yep. Here's the full command line: c:\WINDOWS\system32\java.exe -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n -cp "C:/bin/clojure/clojure/svn/clojure.jar;c:/data/.clojure/*" clojure.lang.Repl > 2. Load the Clojure source file you want to debug (you can't debug > definitions created in the repl) Did so from the SLIME REPL via (load-file "/path/to/my/source.clj") > 3. Start JSwat and use the "Session/Attach..." menu option to attach > to the correct host/port (in my case, "localhost" and "" since I'm > debugging a local Java instance and I specified port "" when I > started Java) Yep. Localhost and 50525 for me this time (got port from the message spewed into *inferior-lisp*). > 4. In JSwat, open the same Clojure source file you loaded in step #2 > and add a breakpoint (you can just click on the source line#) - note > that you can only add breakpoints to lines in a defn, not lines in a > defmacro definition Yep. > 5. In the Clojure repl evaluate a form that will call the function > that has your breakpoint. Yep. > 6. In JSwat, you should see that the breakpoint has been hit and > program execution is paused Nope. :p Fortunately I've since solved the problem I originally wanted the debugger for (yay REPL), but it still would be nice to get this to work... I'm puzzled by my ability to successfully hit breakpoints in boot.clj. That seems to imply I'm doing something partially right. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
Hi Craig, On Fri, Oct 24, 2008 at 6:23 AM, Craig Andera <[EMAIL PROTECTED]> wrote: > > [Tried sending this before. Never appears to have shown up. Trying > again after mucking with my Google account some.] > > On Tue, Oct 21, 2008 at 11:11 AM, Allen Rohner <[EMAIL PROTECTED]> wrote: >> >>> I wonder if this doesn't have something to do with the fact that I'm >>> doing everything via the REPL. Is it possible to break on code you've >>> evaluated via M-x slime-eval-buffer? I'm able to set breakpoints in >>> (e.g.) boot.clj. >> >> I think it does. The compiler associates a file name line number with >> each line in your file. The debugger uses those line numbers to set >> breakpoints i.e. "set breakpoint on file foo.clj, line 15". Eval-ing >> into the repl you don't get useful line numbers. Try using slime-load- >> file. > > No love with slime-load-file. When I get some time I'll try sticking > my code into a .jar and see if that gets me anywhere. > > Or has anyone ever gotten this to work? I was able to get JSwat to work with Clojure (see my blog post from yesterday: http://bc.tech.coop/blog/081023.html) Are you doing all of the following: 1. Specify the appropriate debug options when you start Clojure (see step #4 in my blog post) 2. Load the Clojure source file you want to debug (you can't debug definitions created in the repl) 3. Start JSwat and use the "Session/Attach..." menu option to attach to the correct host/port (in my case, "localhost" and "" since I'm debugging a local Java instance and I specified port "" when I started Java) 4. In JSwat, open the same Clojure source file you loaded in step #2 and add a breakpoint (you can just click on the source line#) - note that you can only add breakpoints to lines in a defn, not lines in a defmacro definition 5. In the Clojure repl evaluate a form that will call the function that has your breakpoint. 6. In JSwat, you should see that the breakpoint has been hit and program execution is paused -- Bill Clementson --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: use spit from clojure.contrib.duck_streams
On Fri, Oct 24, 2008 at 9:44 AM, stephan <[EMAIL PROTECTED]> wrote: > > I downloaded the svn trunk of clojure-contrib, used ant to build the > jar-file, and copied that into a directory included in the classpath. Unfortunately, jars within directories in the classpath aren't picked up by the classloaders. You either need to include the clojure-contrib jar itself in the classpath or include the clojure-contrib/src directory in the classpath. By including the clojure-contrib/src directory, you won't have to build with ant anymore, which is nice, so that's the route I've gone for now (until clojure-contrib requires an actual build, e.g. if it includes some Java source that needs to be built). HTH, - J. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Weird exception behavior
Right, I meant derive. Sorry. I was just trying to understand the best way to deal with errors in Clojure. I thought what you were saying was that we could derive exceptions from RuntimeException and they wouldn't get wrapped. It seems to negate the value of try/catch if every exception (including RuntimeExceptions) are wrapped in RuntimeExceptions that have to be unwrapped to find the true cause. I have noticed in the REPL in emacs I have to usually drill down three or four levels to find the true cause (and file and line no) of an exception. However, since I'm relatively new here, I did a search in the archive, and turned up this message, which seems to layout a better, more Clojureish way to handle errors using dynamic vars bound to 'recovery' functions. http://groups.google.com/group/clojure/msg/842e8bb058015282 Paul On Fri, Oct 24, 2008 at 8:18 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > > On Oct 24, 7:46 am, "Paul Stadig" <[EMAIL PROTECTED]> wrote: >> So the moral of the story (in terms of idiomatic clojure) is to >> declare RuntimeExceptions instead of Exceptions (if you need to >> declare an exception)? Or is there a better way to handle errors? >> > > You don't declare exceptions in Clojure. If you mean derive from > RuntimeException, that won't help, as at present most wrapping > contexts just catch any Exception (which will catch RuntimeExceptions) > and throw wrapped in a new RuntimeException. I recommend you try to > use an existing Exception type when possible (there are too many > already), and derive from Exception otherwise. > > The real issue is on the handling side. In general, I think unless you > are directly calling something that declares specific exceptions, you > need to catch Exception then see what you've got, including examining > the cause. You should presume that all generic plumbing, i.e. most of > Clojure, might throw Exceptions, sometimes wrapping others. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: playing with metadata
Hi Jose, The key determinant of metadata in Clojure is whether the data is orthogonal to equality. Would two tasks with identical behavior but different staleness predicates be equal? I would say no, hence a staleness predicate would be data, not metadata. I'll be interested to hear what others think. Cheers, Stu > Hi, > > In order to learn and experiment with clojure, i'm implementing a (for > now, toy) build system. The idea is to replace makefiles or ant build > files or your-favourite-make-replacement files by specifications > written > in a clojure-based embedded DSL (same thing as, for example, Rake or > Scons). > > A central concept in such a system is, of course, a task, which has > associated some unsurprising bits of data: a build procedure, > dependencies, a staleness predicate... In other languages (i've coded > some prototypes in Scheme and Common Lisp in the past) you would > typically define some sort of structured type to hold this data (for > instance, i was using CLOS in CL). But i was thinking that, in > clojure, > it could make sense to put this information in (possibly tagged) > metadata, so that any clojure object can behave as a task. > > My gut feeling is that such design would buy me some flexibility, > avoiding the usual type system straitjacket; and, anyway, it seems > kinda > fun. But clojure is the first language i use providing metadata, and i > lack the experience to know whether i'm on sound ground here. > > So, my question: do you think that this would be a good, idiomatic use > of metadata? Is there any code or conceptual discussion on metadata > and > its uses? > > Thanks, > jao > -- > Always have a vision. Why spend your life making other people’s > dreams? > -Orson Welles (1915-1985) > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: playing with metadata
On Oct 24, 7:58 am, "Jose A. Ortega Ruiz" <[EMAIL PROTECTED]> wrote: > Hi, > > In order to learn and experiment with clojure, i'm implementing a (for > now, toy) build system. The idea is to replace makefiles or ant build > files or your-favourite-make-replacement files by specifications written > in a clojure-based embedded DSL (same thing as, for example, Rake or > Scons). > > A central concept in such a system is, of course, a task, which has > associated some unsurprising bits of data: a build procedure, > dependencies, a staleness predicate... In other languages (i've coded > some prototypes in Scheme and Common Lisp in the past) you would > typically define some sort of structured type to hold this data (for > instance, i was using CLOS in CL). But i was thinking that, in clojure, > it could make sense to put this information in (possibly tagged) > metadata, so that any clojure object can behave as a task. > > My gut feeling is that such design would buy me some flexibility, > avoiding the usual type system straitjacket; and, anyway, it seems kinda > fun. But clojure is the first language i use providing metadata, and i > lack the experience to know whether i'm on sound ground here. > > So, my question: do you think that this would be a good, idiomatic use > of metadata? Is there any code or conceptual discussion on metadata and > its uses? > It seems like this data is the actual task data, not metadata, so you could just use maps - they're flexible in that no particular attributes (keys) would be required. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Weird exception behavior
Thanks 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
use spit from clojure.contrib.duck_streams
Hello, I tried to use the duck_streams library from clojure-contrib. I downloaded the svn trunk of clojure-contrib, used ant to build the jar-file, and copied that into a directory included in the classpath. but: user> (use 'clojure.contrib.duck_streams) gives me this exception: java.lang.Exception: namespace 'clojure.contrib.duck_streams' not found after loading '/clojure/contrib/duck_streams/ duck_streams.clj' (NO_SOURCE_FILE:0) How can I tell clojure, where to look for the contrib sources? Do I have to copy the contrib directory to a certain location in the directory file? I couldn't find anything about that in the documentation. Thanks for your help, Stephan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
playing with metadata
Hi, In order to learn and experiment with clojure, i'm implementing a (for now, toy) build system. The idea is to replace makefiles or ant build files or your-favourite-make-replacement files by specifications written in a clojure-based embedded DSL (same thing as, for example, Rake or Scons). A central concept in such a system is, of course, a task, which has associated some unsurprising bits of data: a build procedure, dependencies, a staleness predicate... In other languages (i've coded some prototypes in Scheme and Common Lisp in the past) you would typically define some sort of structured type to hold this data (for instance, i was using CLOS in CL). But i was thinking that, in clojure, it could make sense to put this information in (possibly tagged) metadata, so that any clojure object can behave as a task. My gut feeling is that such design would buy me some flexibility, avoiding the usual type system straitjacket; and, anyway, it seems kinda fun. But clojure is the first language i use providing metadata, and i lack the experience to know whether i'm on sound ground here. So, my question: do you think that this would be a good, idiomatic use of metadata? Is there any code or conceptual discussion on metadata and its uses? Thanks, jao -- Always have a vision. Why spend your life making other people’s dreams? -Orson Welles (1915-1985) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Debugging with JSwat
[Tried sending this before. Never appears to have shown up. Trying again after mucking with my Google account some.] On Tue, Oct 21, 2008 at 11:11 AM, Allen Rohner <[EMAIL PROTECTED]> wrote: > >> I wonder if this doesn't have something to do with the fact that I'm >> doing everything via the REPL. Is it possible to break on code you've >> evaluated via M-x slime-eval-buffer? I'm able to set breakpoints in >> (e.g.) boot.clj. > > I think it does. The compiler associates a file name line number with > each line in your file. The debugger uses those line numbers to set > breakpoints i.e. "set breakpoint on file foo.clj, line 15". Eval-ing > into the repl you don't get useful line numbers. Try using slime-load- > file. No love with slime-load-file. When I get some time I'll try sticking my code into a .jar and see if that gets me anywhere. Or has anyone ever gotten this to work? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: BUG? Can't bind a macro
On Oct 24, 7:19 am, MikeM <[EMAIL PROTECTED]> wrote: > On Oct 23, 9:02 pm, "Mike Hinchey" <[EMAIL PROTECTED]> wrote: > > > Binding isn't suppose to work for macros. Macros expand during > > compile-time, and binding only affects vars at runtime. > > Binding works on vars, and a macro is a function in a var, so binding > does work on macros. But you hit the nail on the head with compile- > time vs runtime. My test case is compiled with the standard 'and', > then 'and' is bound before the expression is executed, but it's too > late to make a difference. > > The following works as I wanted: > > (binding [and bind-test] > (load-file "./classes/bind-test.clj") > ) > > where bind-test.clj contains (and ...). This works since the 'and' > binding is executed before the file is loaded and compiled. > Rebinding of macros is currently not supported. I make no guarantees that that will continue to work. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Weird exception behavior
On Oct 24, 7:46 am, "Paul Stadig" <[EMAIL PROTECTED]> wrote: > So the moral of the story (in terms of idiomatic clojure) is to > declare RuntimeExceptions instead of Exceptions (if you need to > declare an exception)? Or is there a better way to handle errors? > You don't declare exceptions in Clojure. If you mean derive from RuntimeException, that won't help, as at present most wrapping contexts just catch any Exception (which will catch RuntimeExceptions) and throw wrapped in a new RuntimeException. I recommend you try to use an existing Exception type when possible (there are too many already), and derive from Exception otherwise. The real issue is on the handling side. In general, I think unless you are directly calling something that declares specific exceptions, you need to catch Exception then see what you've got, including examining the cause. You should presume that all generic plumbing, i.e. most of Clojure, might throw Exceptions, sometimes wrapping others. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch available: *print-length*, *print-level*
On Oct 24, 2:55 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote: > Rich mentioned on #clojure that a patch to implement *print-length* > would be welcome. > > I've uploaded a patch that implements Common Lisp's *print-length* and > *print-level* for Clojure: > >http://clojure.googlegroups.com/web/print-length-level.patch > > The CL docs are at: > >http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_lev.htm > > *print-length* can be especially useful in Clojure's repl to avoid > accidentally printing an infinite seq and having to abort your session. > > I've enclosed an example and docs below. > Awesome - thanks! Patch applied (SVN 1077) 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Weird exception behavior
So the moral of the story (in terms of idiomatic clojure) is to declare RuntimeExceptions instead of Exceptions (if you need to declare an exception)? Or is there a better way to handle errors? Paul On Fri, Oct 24, 2008 at 7:39 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > > On Oct 23, 10:11 pm, jim <[EMAIL PROTECTED]> wrote: >> Rich, >> >> When I do the following: >> >> (gen-and-load-class 'user.UserException :extends Exception) >> >> (defn th [arg] >> (throw (new user.UserException "thrown exception"))) >> >> (defn test-fn [] >> (try >>(dorun (map th '(1 2 3))) >>(catch user.UserException e >> (println "caught" e)) >>(finally (println "finally clause" >> >> and then execute test-fn, the exception is not caught. >> >> user=> (test-fn) >> finally clause >> java.lang.RuntimeException: user.UserException: thrown exception >> (NO_SOURCE_FILE:0) >> >> So am I doing something wrong or is this a bug when an exception is >> thrown from inside a call to map? >> > > Currently ISeq (the interface for seqs) doesn't declare any exceptions > on first/rest, therefor no implementations, e.g. LazyCons, can throw > checked exceptions. So, if they encounter an exception in the > implementation closure, they have to wrap it in an unchecked > exception, like RuntimeException. > > This is a good example of why checked exceptions are bad - they force > intervening parties who should have no participation in the process to > be involved in exception declarations and handling, thereby thwarting > the basic premise of exceptions - communication between the party that > had the problem and the party that can do something about it. > > In any case, the only way to fix this is to declare that first/rest > throw Exception in ISeq, which would be a big change (because > everything that calls them would then have to declare exceptions, and > everything that calls them... - complete inanity). > > They definitely weren't thinking about closures and higher-order > programming when they invented checked exceptions - it invariably > leads to everything declaring they throw the root Exception, so why > bother? > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Weird exception behavior
On Oct 23, 10:11 pm, jim <[EMAIL PROTECTED]> wrote: > Rich, > > When I do the following: > > (gen-and-load-class 'user.UserException :extends Exception) > > (defn th [arg] > (throw (new user.UserException "thrown exception"))) > > (defn test-fn [] > (try >(dorun (map th '(1 2 3))) >(catch user.UserException e > (println "caught" e)) >(finally (println "finally clause" > > and then execute test-fn, the exception is not caught. > > user=> (test-fn) > finally clause > java.lang.RuntimeException: user.UserException: thrown exception > (NO_SOURCE_FILE:0) > > So am I doing something wrong or is this a bug when an exception is > thrown from inside a call to map? > Currently ISeq (the interface for seqs) doesn't declare any exceptions on first/rest, therefor no implementations, e.g. LazyCons, can throw checked exceptions. So, if they encounter an exception in the implementation closure, they have to wrap it in an unchecked exception, like RuntimeException. This is a good example of why checked exceptions are bad - they force intervening parties who should have no participation in the process to be involved in exception declarations and handling, thereby thwarting the basic premise of exceptions - communication between the party that had the problem and the party that can do something about it. In any case, the only way to fix this is to declare that first/rest throw Exception in ISeq, which would be a big change (because everything that calls them would then have to declare exceptions, and everything that calls them... - complete inanity). They definitely weren't thinking about closures and higher-order programming when they invented checked exceptions - it invariably leads to everything declaring they throw the root Exception, so why bother? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: BUG? Can't bind a macro
On Oct 23, 9:02 pm, "Mike Hinchey" <[EMAIL PROTECTED]> wrote: > Binding isn't suppose to work for macros. Macros expand during > compile-time, and binding only affects vars at runtime. Binding works on vars, and a macro is a function in a var, so binding does work on macros. But you hit the nail on the head with compile- time vs runtime. My test case is compiled with the standard 'and', then 'and' is bound before the expression is executed, but it's too late to make a difference. The following works as I wanted: (binding [and bind-test] (load-file "./classes/bind-test.clj") ) where bind-test.clj contains (and ...). This works since the 'and' binding is executed before the file is loaded and compiled. Thanks very much for your help. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Modified doto
On Thu, Oct 23, 2008 at 4:53 PM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > > On Oct 21, 10:30 am, mb <[EMAIL PROTECTED]> wrote: >> Hi, >> >> On 21 Okt., 14:41, mb <[EMAIL PROTECTED]> wrote:> (defmacro doto-> >> >> The name is actually also up to discussion. doto is already >> in use and this change is incompatible to "legacy" code. >> I couldn't come up with a good alternative... >> > > I'd rather enhance doto to do this and not add another variant. The > break would be that current (doto x (foo 42)) would have to become > (doto x (.foo 42)). > > Any thoughts on this as part of the upcoming bit of breaking changes? In addition, I think having to always use dot-something for methods is good consistency. +1. > > Rich > > > > -- 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Modified doto
On 23 Okt, 16:53, Rich Hickey <[EMAIL PROTECTED]> wrote: > On Oct 21, 10:30 am, mb <[EMAIL PROTECTED]> wrote: > > > Hi, > > > On 21 Okt., 14:41, mb <[EMAIL PROTECTED]> wrote:> (defmacro doto-> > > > The name is actually also up to discussion. doto is already > > in use and this change is incompatible to "legacy" code. > > I couldn't come up with a good alternative... > > I'd rather enhance doto to do this and not add another variant. The > break would be that current (doto x (foo 42)) would have to become > (doto x (.foo 42)). > > Any thoughts on this as part of the upcoming bit of breaking changes? > > Rich +1, would be a very nice change. /mac --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Fri, Oct 24, 2008 at 5:16 PM, Adam Jones <[EMAIL PROTECTED]> wrote: > > > > On Oct 22, 6:17 am, Chouser <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 22, 2008 at 4:30 AM, Brett Morgan <[EMAIL PROTECTED]> > wrote: > > > > > I understand the lisp way is to use the reader plus macros to interpret > the > > > incoming data stream. This is hella cool in that it seriously cuts down > on > > > the amount of development work I have to do. The reader is already > done, and > > > using macros to build the tree walker? And have them applied to a stm > core? > > > Very lightweight in comparison to what I'd do traditionally. Very cool. > > > > I think that if you use "read" rather than "load" or "eval" on the > > incoming s-expressions, you'll have a lot less to worry about. > > Without the eval step there's no need to try to block arbitrary > > function calls and such, because they'll never be evaluated in the > > first place -- any symbols that match function call names will simply > > be returned from the reader as symbols. > > > > If you then want to call macroexpand on them to help process the > > expressions (I've got no sense of whether this would be a useful > > approach or not) then the only code being run would be your own macro. > > There'd be no way for the incoming s-expressions to define new macros > > or functions. > > > > Perhaps you'd still want to audit the LispReader.java code for > > security vulnerabilities and/or run the reader in some sort of Java > > sandbox, but I wouldn't be surprised if neither of these is actually > > necessary. > > > > --Chouser > > > > This is exactly the suggestion I was going to make. Dealing with > untrusted code doesn't seem to be one of the main design > considerations of Clojure. That I know of, there are no provisions to > keep someone from re-defing existing functions, reaching out of their > current namespace, or jumping into those aspects of Java land that are > available. The safest way to handle data from the client is to keep it > as data and write code to parse and react to it, anything else is > setting up a creativity contest between yourself and anyone trying to > break the application. If companies like Microsoft and Oracle can't > win those with all of their money, a single individual doesn't stand a > chance. > My understanding of the lisp way, and I am but a newbie in the land of lisp, is to deal with untrusted code by writing an meta-circular interpreter for a language that is appropriate for the situation at hand. If you don't trust the people generating the code not re-def functions, take def out of the interpreter. Or leave it in, and have it guard predefined functions. My excitement with clojure is that i get to make lots of dsls really easily, at least in comparison to the heavy engineering approach that is required in the java world... > > -Adam > > > -- Brett Morgan http://brett.morgan.googlepages.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure and introspection/reflection analysis?
Hi Take a look at btrace. It is DTrace like dynamic instrumentation tool for JVM (DTrace : System :: btrace : JVM, though DTrace is superset of btrace). It allows you to instrument JVM at bytecode level with no changes in code. It might also help going forward to enhance clojure to insert btrace probes. These probes can help expose higher level details to instrumentation tools like btrace and would help professional developers immensely. - Akhilesh On Oct 24, 5:03 am, BerlinBrown <[EMAIL PROTECTED]> wrote: > On Oct 23, 6:42 pm, BerlinBrown <[EMAIL PROTECTED]> wrote: > > > > > I asked this on common lisp thread but I want to work with clojure as > > well: > > > With clojure and I am assuming the introspection properties. How > > can I add code to clojure code that will tell me when a function > > is called and when has finished executing. I want to take any lisp > > code and this particular modification to the code. I figure with > > lisp's AST analysis, this should be possible. > > > For example, pseudo code in common lisp, hello_world.lisp: > > > (defun hello-world () > > (format t "Hello World")) > > > (hello-world) > > > And then I have a utility to load hello_world.lisp and execute > > the hello-world call. > > > At the command line: > > #Inspect: hello-world function was called > > #Hello World > > #Inspect: hello-world has finished executing. > > Another similar question (second question): > > If you have used ASM, I can do a lot of this "trace" type > functionality with the bytecode manipulator ASM (and obviously > reflection) but I was also looking for the clojure way. > http://asm.objectweb.org/). > Or maybe even reflection. Is there something in clojure that might > allow me to see when a function is called. > > For example, with ASM, I can get the following information of a > method: > > protected (Ljava/lang/String;)V > ALOAD 0 > INVOKESPECIAL java/lang/Object.()V > ALOAD 0 > ALOAD 1 > PUTFIELD org/objectweb/asm/Attribute.type : Ljava/lang/String; > RETURN > MAXSTACK = 2 > MAXLOCALS = 2 > > > What is put on the stack and when methods are invoked. > > Does something similar exist for ASM? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
