Re: Patch: precompiling Clojure core sources in Ant build script
Hi Matt, On Tue, Dec 9, 2008 at 6:43 PM, MattyDub <[EMAIL PROTECTED]> wrote: > > I did an 'svn update' on my clojure (I'm now at revision 1149), and > ran ant clean, then ant (the default target). Then I deleted my old > swank-clojure directory, and did a git clone of > git://github.com/jochu/swank-clojure.git. > I made sure my .emacs was correctly pointing to the appropriate > paths. I still get the same error. Perhaps I'm using it > incorrectly? What is the proper usage? I start slime: > M-x slime > then load the file by using C-x C-e on the following line in ants.clj: > (load-file "c:/home/ants.clj") > Then in a buffer pointing to ants.clj, I put the point over a call to > render-place, and do M-. And I get this stack trace: > Debugger entered--Lisp error: (error "Synchronous Lisp Evaluation > aborted.") > signal(error ("Synchronous Lisp Evaluation aborted.")) > error("Synchronous Lisp Evaluation aborted.") > funcall(error "Synchronous Lisp Evaluation aborted.") > apply(funcall (error "Synchronous Lisp Evaluation aborted.")) > (let* ((tag ...) (slime-stack-eval-tags ...)) (apply (function > funcall) (catch tag ... ...))) > slime-eval((swank:find-definitions-for-emacs "render-place")) > slime-find-definitions-rpc("render-place") > funcall(slime-find-definitions-rpc "render-place") > slime-find-definitions("render-place") > (slime-edit-definition-cont (slime-find-definitions name) name > where) > (or (run-hook-with-args-until-success (quote slime-edit-definition- > hooks) name where) (slime-edit-definition-cont (slime-find-definitions > name) name where)) > slime-edit-definition("render-place") > call-interactively(slime-edit-definition) > > I must be doing something wrong - any ideas what? > -Matt Hmm, looks like I was mistaken in my earlier email. I get the same thing when I do M-. on "render-place". However, if I place the point on "defn" (or any other symbol name that is in a jar file), it goes to the correct source in the jar file. At first, I thought it was because ant.clj was not in the class path; however, it doesn't work when ant.clj is in the class path either. I applied the find-definitions-for-emacs patch proposed in the earlier email; however, that doesn't work either. This used to work for local definitions and was broken a few svn changes ago. It was fixed for clojure definitions that are in jar files; however, it seems to still be broken for local definitions. - 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: Non-NS-qualified hierarchies
On Tue, Dec 9, 2008 at 7:05 PM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > Thanks. I think it does a bit too much - I only want to relax the > requirement for namespace-qualification, not any of the other > assertions (e.g. that the participants are either Named or Classes, > can't be = etc). Right, that makes sense. I believe this new patch is closer to what you are looking for. It moves the namespace checks for both tag and parent to the two argument case and keeps the not=, class? or Named checks in the three argument case. A couple tests: kant[~/src/clojure]$ iclj 1:1 user=> (derive :child :parent) java.lang.Exception: Assert failed: (namespace parent) (repl-1:1) 1:2 user=> (derive (make-hierarchy) :child :parent) {:parents {:child #{:parent}}, :ancestors {:child #{:parent}}, :descendants {:parent #{:child}}} 1:3 user=> (derive 1 :parent) java.lang.Exception: Assert failed: (namespace parent) (repl-1:3) 1:4 user=> (derive (make-hierarchy) 1 :parent) java.lang.Exception: Assert failed: (or (class? tag) (instance? clojure.lang.Named tag)) (repl-1:4) Is this better? - 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 -~--~~~~--~~--~--~--- Index: src/clj/clojure/core.clj === --- src/clj/clojure/core.clj (revision 1149) +++ src/clj/clojure/core.clj (working copy) @@ -3041,12 +3041,15 @@ child can be either a namespace-qualified symbol or keyword or a class. h must be a hierarchy obtained from make-hierarchy, if not supplied defaults to, and modifies, the global hierarchy." - ([tag parent] (alter-var-root #'global-hierarchy derive tag parent) nil) + ([tag parent] + (assert (namespace parent)) + (assert (or (class? tag) (and (instance? clojure.lang.Named tag) (namespace tag + + (alter-var-root #'global-hierarchy derive tag parent) nil) ([h tag parent] (assert (not= tag parent)) - (assert (or (class? tag) (and (instance? clojure.lang.Named tag) (namespace tag + (assert (or (class? tag) (instance? clojure.lang.Named tag))) (assert (instance? clojure.lang.Named parent)) - (assert (namespace parent)) (let [tp (:parents h) td (:descendants h)
def* froms
I generally like the various def* macros from clojure.contrib.def. I was wondering though if it would make sense unify the syntax of all the def* macros from both clojure.contrib.def and clojure.core, especially with respect to doc strings and attr-maps. For example in clojure.core we have defn with the arglist: (defn name doc-string? attr-map? [params*] body) This seems like it should be the prototype on which other def* forms are based, in particular the basic pattern of name, then doc-string? then attr-map?, then some forms that define the associated value. Currently for defstruct we have: (defstruct name & keys) Would this make sense?: (defstruct doc-string? attr-map? name & keys) Then in clojure.contrib.def for defvar we have: (defvar name init doc) Which puts the doc string after the value forms instead of before them. I would have expected: (defvar doc-string? attr-map? name init) I think we could implement e.g. the defstruct change without breaking any existing code, but changes like those to defvar would be breaking. What do others think of this basic approach to def* forms and the possibility of making changes to unify them in core and contrib.def? I'd be happy to send some patches; I just wanted to feel out what others thought about the issue first. - Mark --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
throw-if with no exception class
The throw-if function from clojure.contrib.except will throw a specified exception type. If none is specified, it throws a java.lang.Exception. I was expecting it would through a java.lang.RuntimeException. Which seems more correct? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: precompiling Clojure core sources in Ant build script
I did an 'svn update' on my clojure (I'm now at revision 1149), and ran ant clean, then ant (the default target). Then I deleted my old swank-clojure directory, and did a git clone of git://github.com/jochu/swank-clojure.git. I made sure my .emacs was correctly pointing to the appropriate paths. I still get the same error. Perhaps I'm using it incorrectly? What is the proper usage? I start slime: M-x slime then load the file by using C-x C-e on the following line in ants.clj: (load-file "c:/home/ants.clj") Then in a buffer pointing to ants.clj, I put the point over a call to render-place, and do M-. And I get this stack trace: Debugger entered--Lisp error: (error "Synchronous Lisp Evaluation aborted.") signal(error ("Synchronous Lisp Evaluation aborted.")) error("Synchronous Lisp Evaluation aborted.") funcall(error "Synchronous Lisp Evaluation aborted.") apply(funcall (error "Synchronous Lisp Evaluation aborted.")) (let* ((tag ...) (slime-stack-eval-tags ...)) (apply (function funcall) (catch tag ... ...))) slime-eval((swank:find-definitions-for-emacs "render-place")) slime-find-definitions-rpc("render-place") funcall(slime-find-definitions-rpc "render-place") slime-find-definitions("render-place") (slime-edit-definition-cont (slime-find-definitions name) name where) (or (run-hook-with-args-until-success (quote slime-edit-definition- hooks) name where) (slime-edit-definition-cont (slime-find-definitions name) name where)) slime-edit-definition("render-place") call-interactively(slime-edit-definition) I must be doing something wrong - any ideas what? -Matt On Dec 9, 4:23 pm, "Bill Clementson" <[EMAIL PROTECTED]> wrote: > Hi Matt, > > > > On Tue, Dec 9, 2008 at 4:15 PM, MattyDub <[EMAIL PROTECTED]> wrote: > > > I recently tried M-. for the first time with clojure + SLIME and it > > broke for me (with a "Lisp error: (error "Synchronous Lisp Evaluation > > aborted.")"); other parts of SLIME work (e.g., C-M-x, or C-x C-e), but > > this doesn't . I didn't understand the previous messages in this > > thread: > > 1) Stephen Gilardi said to add "/ > > src/clj" to his classpath - what classpath? The swank-clojure-jar- > > path in my .emacs? Or another classpath? > > 2) Feng suggested a patch, but didn't mention what file to make that > > patch in - what file was that for? > > Has this problem been patched yet? Should I just update my swank- > > clojure, or something? Any help is appreciated. (I'm inferring from > > the first method that swank-clojure supports slime-edit-definition - > > if I'm incorrect, please let me know.) > > The problem has been fixed. If you download both the latest SVN > version of Clojure and the latest GIT version of swank-clojure, you > should be fine. > > - 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: why can't I set! stuff in user.clj?
On Tuesday 09 December 2008 18:10, Randall R Schulz wrote: > ... > > Since I love to share my BASH code (and I anxiously look forward to > the day that I'm willing to share my Clojure code), I've attached my > "clojure-svn" script. ... By the way, tab stops are set at 4-column intervals. I forgot to expand the file before attaching it. RRS --~--~-~--~~~---~--~~ 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: why can't I set! stuff in user.clj?
On Tuesday 09 December 2008 15:13, Brian Doyle wrote: > Steve, > > Could you post your bash shell script that starts Clojure? I would > like to see what you have concerning the new options that can be > passed to the updated clojure.jar. Thanks. Since I love to share my BASH code (and I anxiously look forward to the day that I'm willing to share my Clojure code), I've attached my "clojure-svn" script. The name emphasizes that I'm launching the SVN version of Clojure, though I make no use of the "official" release any more. Since this is for me only, it has no diagnostics or --help option. It also assumes that rlwrap is available. Similarly, it assumes the existence of a completion file. Search for RLWRAP to find all rlwrap dependencies. Randall Schulz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- clojure-svn Description: application/shellscript
Re: why can't I set! stuff in user.clj?
On Dec 9, 2008, at 6:13 PM, Brian Doyle wrote: Could you post your bash shell script that starts Clojure? I would like to see what you have concerning the new options that can be passed to the updated clojure.jar. Thanks. [Reposting with a change and a correction: clojure.contrib.repl_ln now supports -i and --init args, $JAVAEXTDIR was an error.] #!/bin/bash set -o errexit set -o nounset #set -o xtrace SQ=/sq CLJ=$SQ/clj ETC=$CLJ/etc LOCAL=$CLJ/local EXT=$SQ/ext CLOJURE=$EXT/clojure CONTRIB=$EXT/clojure-contrib SWANK=$EXT/swank-clojure EXTDIRS=$EXT/java/ext CLOJURESRC=$CLOJURE/src/clj CONTRIBSRC=$CONTRIB/src CPDIRS=$ETC:$LOCAL:$CONTRIBSRC:$CLOJURESRC:$SWANK INIT="--init $ETC/init.clj" JAVA=java OPTIONS="-Xms32M -Xmx128M -server" CLASSPATH="-cp $CPDIRS" JAVAEXTDIRS="-Djava.ext.dirs=$EXTDIRS" #MAIN="clojure.contrib.repl_ln $INIT" MAIN="clojure.main $INIT --repl" exec $JAVA $OPTIONS $CLASSPATH $JAVAEXTDIRS $MAIN $@ I have symbolic links to clojure.jar and clojure-contrib.jar (and several more jars) in the one dir listed in $EXTDIRS. All jars within (or symbolic linked from within) the directories listed in the value of java.ext.dirs are classpath roots as well. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: why can't I set! stuff in user.clj?
On Dec 9, 2008, at 6:13 PM, Brian Doyle wrote: Could you post your bash shell script that starts Clojure? I would like to see what you have concerning the new options that can be passed to the updated clojure.jar. Thanks. Here it is: #!/bin/bash set -o errexit set -o nounset #set -o xtrace SQ=/sq CLJ=$SQ/clj ETC=$CLJ/etc LOCAL=$CLJ/local EXT=$SQ/ext CLOJURE=$EXT/clojure CONTRIB=$EXT/clojure-contrib SWANK=$EXT/swank-clojure EXTDIRS=$EXT/java/ext CLOJURESRC=$CLOJURE/src/clj CONTRIBSRC=$CONTRIB/src CPDIRS=$ETC:$LOCAL:$CONTRIBSRC:$CLOJURESRC:$SWANK JAVA=java OPTIONS="-Xms32M -Xmx128M -server" CLASSPATH="-cp $CPDIRS" JAVAEXTDIRS="-Djava.ext.dirs=$EXTDIRS" #MAIN="clojure.contrib.repl_ln" MAIN="clojure.main --init $ETC/init.clj --repl" exec $JAVA $OPTIONS $CLASSPATH $JAVAEXTDIRS $MAIN $@ I have symbolic links to clojure.jar and clojure-contrib.jar (and several more jars) in $JAVAEXTDIR. All jars within (or symbolic linked from within) the directories listed in the value of java.ext.dirs are classpath roots as well. clojure.contrib.repl_ln (commented out as an alternate MAIN above) doesn't currently handle --init args. I think it should and I'll put that in soon. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Patch: precompiling Clojure core sources in Ant build script
Hi Matt, On Tue, Dec 9, 2008 at 4:15 PM, MattyDub <[EMAIL PROTECTED]> wrote: > > I recently tried M-. for the first time with clojure + SLIME and it > broke for me (with a "Lisp error: (error "Synchronous Lisp Evaluation > aborted.")"); other parts of SLIME work (e.g., C-M-x, or C-x C-e), but > this doesn't . I didn't understand the previous messages in this > thread: > 1) Stephen Gilardi said to add "/ > src/clj" to his classpath - what classpath? The swank-clojure-jar- > path in my .emacs? Or another classpath? > 2) Feng suggested a patch, but didn't mention what file to make that > patch in - what file was that for? > Has this problem been patched yet? Should I just update my swank- > clojure, or something? Any help is appreciated. (I'm inferring from > the first method that swank-clojure supports slime-edit-definition - > if I'm incorrect, please let me know.) The problem has been fixed. If you download both the latest SVN version of Clojure and the latest GIT version of swank-clojure, you should be fine. - 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: Calling superclass methods from implemented methods
On Tue, Dec 9, 2008 at 4:28 PM, Matt Revelle <[EMAIL PROTECTED]> wrote: > > On Dec 9, 2008, at 10:03 AM, Rich Hickey wrote: > >> >> >> >> On Dec 9, 12:24 am, Matt Revelle <[EMAIL PROTECTED]> wrote: >>> The attached patch adds :super-methods option to generate-class as a >>> map, {local-name [name [param-types] return-type], ...}. The >>> mechanics work as Rich suggested in an earlier message, a method is >>> created that has the same type signature as the exposed method - it >>> loads the arguments, invokes the method, and returns the result. >>> >>> An example can be viewed here:http://gist.github.com/33787 >>> >>> I haven't done extensive testing, but seems to work. >>> >> >> A couple of thoughts. >> >> First - the local name must be a valid Java method name - you are >> using dashes in your method names in the example code. Some VMs will >> balk at this. >> >> >> Second - it seems tedious and error-prone to have to specify the >> signatures, which must match the method sigs. > > I was going for explicitness, but agree it's both tedious and error- > prone. Fixed. > >> >> >> Third, if a method is overloaded, multiple :super-methods entries must >> be made. >> >> Perhaps it would be better, and more consistent with :exposes, to take >> a map of method_name -> exposing_method_name, and generate a set of >> overloaded methods matching all overloads of the super method: >> >> :exposes-methods {update super_update, render super_render} >> >> This way people can't get the sigs wrong, and a single entry covers >> all overloads. > > Thanks for the feedback, attached patch uses the syntax you suggested > and constructs all overloaded variants of the specified methods. > > Updated usage example: > http://gist.github.com/33787 > Patch applied (svn 1149) - 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 -~--~~~~--~~--~--~---
Re: Patch: precompiling Clojure core sources in Ant build script
I recently tried M-. for the first time with clojure + SLIME and it broke for me (with a "Lisp error: (error "Synchronous Lisp Evaluation aborted.")"); other parts of SLIME work (e.g., C-M-x, or C-x C-e), but this doesn't . I didn't understand the previous messages in this thread: 1) Stephen Gilardi said to add "/ src/clj" to his classpath - what classpath? The swank-clojure-jar- path in my .emacs? Or another classpath? 2) Feng suggested a patch, but didn't mention what file to make that patch in - what file was that for? Has this problem been patched yet? Should I just update my swank- clojure, or something? Any help is appreciated. (I'm inferring from the first method that swank-clojure supports slime-edit-definition - if I'm incorrect, please let me know.) Thanks, -Matt On Nov 14, 1:38 pm, Feng <[EMAIL PROTECTED]> wrote: > On Nov 14, 4:09 pm, "Graham Fawcett" <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Nov 14, 2008 at 4:01 PM, Stephen C. Gilardi <[EMAIL PROTECTED]> > > wrote: > > > > On Nov 14, 2008, at 3:38 PM, Graham Fawcett wrote: > > > > I'm sure there's a work-around, of course. The meta information is still > > > there: > > > > This appears to be because the sources are no longer included in > > > clojure.jar. I added "/src/clj" to my > > > classpath and now it works. > > > Thanks, Steve -- an easy fix! > > > Best, > > Graham > > > > --Steve > > M-. will jump to wrong place if defs are not in namespace master .clj. > I already reported it to swank-clojure owner. I guess the fix should > be in git repo soon. > > This should fix it. > > (defn- namespace-to-path [ns] > (let [ns-str (name (ns-name ns))] > (-> ns-str > (.substring 0 (.lastIndexOf ns-str ".")) > (.replace \- \_) > (.replace \. \/ > > (defslimefn find-definitions-for-emacs [name] > (let [sym-name (read-from-string name) > sym-var (ns-resolve (maybe-ns *current-package*) sym-name)] > (when-let [meta (and sym-var (meta sym-var))] > (if-let [path (or (slime-find-file-in-paths (str (namespace-to- > path (:ns meta)) > (.separator > File) > (:file meta)) > (slime-search-paths)) > ;; This is OK for namespace master .clj, but not for help files. > ; (slime-find-file-in-paths (str (namespace- > to-path (:ns meta)) ".clj") > ; (slime-search- > paths)) > (slime-find-file-in-paths (:file meta) > (slime-search-paths)))] > `((~(str "(defn " (:name meta) ")") > (:location > ~path > (:line ~(:line meta)) > nil))) > `((~(str (:name meta)) > (:error "Source definition not found."))) > > regards, > > - Feng --~--~-~--~~~---~--~~ 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: Non-NS-qualified hierarchies
On Mon, Dec 8, 2008 at 9:21 AM, J. McConnell <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 9:05 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: >> >> On Dec 7, 9:01 am, Mibu <[EMAIL PROTECTED]> wrote: >>> Is it possible to remove the asserts in derive that restrict the >>> parent and child to namespace-qualified names? >>> >>> It would be much more useful if the asserts are moved to the global- >>> hierarchy case ([child parent]) and the "private" hierarchies ([h >>> child parent]) can do as they wish. >> >> Added to todo[1] - patch welcome > > I believe this should do it. > Thanks. I think it does a bit too much - I only want to relax the requirement for namespace-qualification, not any of the other assertions (e.g. that the participants are either Named or Classes, can't be = etc). 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: why can't I set! stuff in user.clj?
Steve, Could you post your bash shell script that starts Clojure? I would like to see what you have concerning the new options that can be passed to the updated clojure.jar. Thanks. On Tue, Dec 9, 2008 at 1:59 PM, Stephen C. Gilardi <[EMAIL PROTECTED]> wrote: > user.clj is loaded before thread-local bindings are established. I see > you're using Repl.java. You can see the call to pushThreadBindings there to > see how it works. user.clj allows you to set up the user namespace, but not > set! most vars. > With the repl in clojure.main, you can include an init file on your > "java..." command line using the "-i" option. It will be loaded after those > bindings have been established. We do not have anything like a > "repl-init.clj" file that's auto-loaded if it exists to accomplish these > kinds of settings. It might be a good idea to have one, loaded from > classpath, with a suitable name. > > More complete solutions to this initialization task (.e.g., for the bash > shell) look in a few places for init files. That's something to consider as > well. > > --Steve > > On Dec 9, 2008, at 3:12 PM, Stuart Halloway wrote: > > > Why can't I call set! in user.clj? (And what is the idiomatic way to > do what I want here?) > > (set! *print-length* 103) > -> Exception in thread "main" java.lang.ExceptionInInitializerError > at clojure.lang.Repl.(Repl.java:23) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: > Can't change/establish root binding of: *print-length* with set > > Thanks, > 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: memory issue with nth
I believe my analysis was incorrect. Never mind! On Dec 9, 1:23 pm, Paul Mooser <[EMAIL PROTECTED]> wrote: > This does NOT occur if I do this directly from the repl (ie, java -cp > clojure.jar clojure.lang.Repl), but it DOES happen if I am accessing > the repl through SLIME. Does anyone know why this might be ? --~--~-~--~~~---~--~~ 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: Calling superclass methods from implemented methods
On Dec 9, 2008, at 10:03 AM, Rich Hickey wrote: > > > > On Dec 9, 12:24 am, Matt Revelle <[EMAIL PROTECTED]> wrote: >> The attached patch adds :super-methods option to generate-class as a >> map, {local-name [name [param-types] return-type], ...}. The >> mechanics work as Rich suggested in an earlier message, a method is >> created that has the same type signature as the exposed method - it >> loads the arguments, invokes the method, and returns the result. >> >> An example can be viewed here:http://gist.github.com/33787 >> >> I haven't done extensive testing, but seems to work. >> > > A couple of thoughts. > > First - the local name must be a valid Java method name - you are > using dashes in your method names in the example code. Some VMs will > balk at this. > > > Second - it seems tedious and error-prone to have to specify the > signatures, which must match the method sigs. I was going for explicitness, but agree it's both tedious and error- prone. Fixed. > > > Third, if a method is overloaded, multiple :super-methods entries must > be made. > > Perhaps it would be better, and more consistent with :exposes, to take > a map of method_name -> exposing_method_name, and generate a set of > overloaded methods matching all overloads of the super method: > > :exposes-methods {update super_update, render super_render} > > This way people can't get the sigs wrong, and a single entry covers > all overloads. Thanks for the feedback, attached patch uses the syntax you suggested and constructs all overloaded variants of the specified methods. Updated usage example: http://gist.github.com/33787 Take care! -Matt --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- genclass_expose-super-methods.diff Description: Binary data > > 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: memory issue with nth
This does NOT occur if I do this directly from the repl (ie, java -cp clojure.jar clojure.lang.Repl), but it DOES happen if I am accessing the repl through SLIME. Does anyone know why this might be ? --~--~-~--~~~---~--~~ 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: why can't I set! stuff in user.clj?
user.clj is loaded before thread-local bindings are established. I see you're using Repl.java. You can see the call to pushThreadBindings there to see how it works. user.clj allows you to set up the user namespace, but not set! most vars. With the repl in clojure.main, you can include an init file on your "java..." command line using the "-i" option. It will be loaded after those bindings have been established. We do not have anything like a "repl-init.clj" file that's auto-loaded if it exists to accomplish these kinds of settings. It might be a good idea to have one, loaded from classpath, with a suitable name. More complete solutions to this initialization task (.e.g., for the bash shell) look in a few places for init files. That's something to consider as well. --Steve On Dec 9, 2008, at 3:12 PM, Stuart Halloway wrote: Why can't I call set! in user.clj? (And what is the idiomatic way to do what I want here?) (set! *print-length* 103) -> Exception in thread "main" java.lang.ExceptionInInitializerError at clojure.lang.Repl.(Repl.java:23) Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Can't change/establish root binding of: *print-length* with set Thanks, 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
Re: Understanding SLIME blog post
Hi Tom, On Tue, Dec 9, 2008 at 12:28 PM, Tom Emerson <[EMAIL PROTECTED]> wrote: > > Nice post as always, Bill. Thanks. :) > One thing I add to my .emacs for SLIME/Clojure is the following: > > (global-set-key "\C-cs" 'slime-selector) > (def-slime-selector-method ?l > "most recently visited clojure-mode buffer." > (slime-recently-visited-buffer 'clojure-mode)) > > This rebinds the selector shortcut for switching to the most recent > lisp-mode buffer to switch to the most recent Clojure mode buffer. > This lets me switch back and forth between the REPL and the file I'm > editing easily with C-c s r and C-c s l. That's a good tip. Normally the "l" binding of slime-selector takes you to the last lisp-mode buffer, so changing it to go to the last clojure-mode buffer is really useful. However, if you're using SLIME with other Lisps as well, you probably wouldn't want that to be the global binding for the "l" selector. You can run multiple REPL's simultaneously, so (for example), you might have SBCL running in one SLIME REPL and Clojure running in another SLIME REPL; therefore, you would probably want the "l" selector to go to the CL source buffer when you're working in the SBCL REPL. So, instead of overriding the "l" selector, you could create a new "j" binding for clojure-mode files: (def-slime-selector-method ?j "most recently visited clojure-mode buffer." (slime-recently-visited-buffer 'clojure-mode)) That way, you could switch between the SBCL REPL and a CL source buffer with C-c s r and C-c s l and switch between a Clojure REPL and a Clojure source buffer with C-c s r and C-c s j. Alternatively, I guess you could either defadvice the slime-selector function to swap the "l" method depending on whether the REPL was SBCL or Clojure or write a "wrapper" function that called either function as appropriate. Thanks, 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: why can't I set! stuff in user.clj?
On Tuesday 09 December 2008 12:33, Mark Volkmann wrote: > On Tue, Dec 9, 2008 at 2:12 PM, Stuart Halloway > > <[EMAIL PROTECTED]> wrote: > > Why can't I call set! in user.clj? (And what is the idiomatic way > > to do what I want here?) > > > > (set! *print-length* 103) > > -> Exception in thread "main" java.lang.ExceptionInInitializerError > >at clojure.lang.Repl.(Repl.java:23) > > Caused by: java.lang.RuntimeException: > > java.lang.IllegalStateException: Can't change/establish root > > binding of: *print-length* with set > > I do that in my user.clj and it works with the version of Clojure in > Subversion as of this morning. > > I run it with a script that does this. > > CP=$CLOJURE_JAR:$CONTRIB_JAR:$BOOK_DIR:. > ... > java -cp $CP clojure.main --init ~/user.clj --repl So for me it turns out that if you put a directory holding user.clj on the class-path, you get the ExceptionInInitializerError, but if you use the --init .../user.clj option (and don't put the directory holding it in the class-path), it works. Randall Schulz --~--~-~--~~~---~--~~ 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: Lazy sequences without caching?
On Tue, Dec 9, 2008 at 3:08 PM, Stephan Mühlstrasser < [EMAIL PROTECTED]> wrote: > > > > On Dec 9, 8:48 pm, "Drew Olson" <[EMAIL PROTECTED]> wrote: > > On Tue, Dec 9, 2008 at 2:28 PM, Stephan Mühlstrasser < > > > > [EMAIL PROTECTED]> wrote: > > > > > On Dec 9, 12:34 am, "harrison clarke" <[EMAIL PROTECTED]> wrote: > > > > you're keeping the head of the sequence, and thus all the elements > > > between > > > > the head and nth. > > > > > > it's because you're using def, basically. > > > > Ok, I'm confused here. Why does wrapping his logic into a > > function alleviate this problem? Can you give a more detailed > explanation, > > I'd like to understand what's going on here. > > > > - Drew > > I hope that I understood it myself now, so I try to explain: > > The wrapping into a function in the second approach is just for > convenience, and doesn't really matter. This is equivalent: > > user=> (defn triangle-numbers [current cumulated] >(let [next (+ current cumulated)] >(lazy-cons next (triangle-numbers (inc current) next > #'user/triangle-numbers > user=> (nth (triangle-numbers 1 0) 1000) > 501501 > > The problem with the first approach is that the head is assigned to a > variable, and this produces the caching effect. In the second approach > all items that are consumed from the sequence are discarded > afterwards, and thus no memory problem occurs. Thanks both of you for the responses. That makes a lot more sense to me. - Drew > > > Regards > 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 -~--~~~~--~~--~--~---
Re: why can't I set! stuff in user.clj?
On Tue, Dec 9, 2008 at 2:12 PM, Stuart Halloway <[EMAIL PROTECTED]> wrote: > > Why can't I call set! in user.clj? (And what is the idiomatic way to > do what I want here?) > > (set! *print-length* 103) > -> Exception in thread "main" java.lang.ExceptionInInitializerError >at clojure.lang.Repl.(Repl.java:23) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: > Can't change/establish root binding of: *print-length* with set I do that in my user.clj and it works with the version of Clojure in Subversion as of this morning. I run it with a script that does this. CP=$CLOJURE_JAR:$CONTRIB_JAR:$BOOK_DIR:. ... java -cp $CP clojure.main --init ~/user.clj --repl -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: Understanding SLIME blog post
Nice post as always, Bill. One thing I add to my .emacs for SLIME/Clojure is the following: (global-set-key "\C-cs" 'slime-selector) (def-slime-selector-method ?l "most recently visited clojure-mode buffer." (slime-recently-visited-buffer 'clojure-mode)) This rebinds the selector shortcut for switching to the most recent lisp-mode buffer to switch to the most recent Clojure mode buffer. This lets me switch back and forth between the REPL and the file I'm editing easily with C-c s r and C-c s l. -tree -- Tom Emerson [EMAIL PROTECTED] http://www.dreamersrealm.net/~tree --~--~-~--~~~---~--~~ 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: why can't I set! stuff in user.clj?
Stuart, I have a ~/.cljrc file that has this stuff in there and in my bash (clj) script to start clojure I do: $JAVA -cp $CLOJURE_JARS clojure.lang.Repl ~/.cljrc On Tue, Dec 9, 2008 at 1:12 PM, Stuart Halloway <[EMAIL PROTECTED]>wrote: > > Why can't I call set! in user.clj? (And what is the idiomatic way to > do what I want here?) > > (set! *print-length* 103) > -> Exception in thread "main" java.lang.ExceptionInInitializerError >at clojure.lang.Repl.(Repl.java:23) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: > Can't change/establish root binding of: *print-length* with set > > Thanks, > 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 -~--~~~~--~~--~--~---
why can't I set! stuff in user.clj?
Why can't I call set! in user.clj? (And what is the idiomatic way to do what I want here?) (set! *print-length* 103) -> Exception in thread "main" java.lang.ExceptionInInitializerError at clojure.lang.Repl.(Repl.java:23) Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Can't change/establish root binding of: *print-length* with set Thanks, 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: Lazy sequences without caching?
On Dec 9, 8:48 pm, "Drew Olson" <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 2:28 PM, Stephan Mühlstrasser < > > [EMAIL PROTECTED]> wrote: > > > On Dec 9, 12:34 am, "harrison clarke" <[EMAIL PROTECTED]> wrote: > > > you're keeping the head of the sequence, and thus all the elements > > between > > > the head and nth. > > > > it's because you're using def, basically. > > Ok, I'm confused here. Why does wrapping his logic into a > function alleviate this problem? Can you give a more detailed explanation, > I'd like to understand what's going on here. > > - Drew I hope that I understood it myself now, so I try to explain: The wrapping into a function in the second approach is just for convenience, and doesn't really matter. This is equivalent: user=> (defn triangle-numbers [current cumulated] (let [next (+ current cumulated)] (lazy-cons next (triangle-numbers (inc current) next #'user/triangle-numbers user=> (nth (triangle-numbers 1 0) 1000) 501501 The problem with the first approach is that the head is assigned to a variable, and this produces the caching effect. In the second approach all items that are consumed from the sequence are discarded afterwards, and thus no memory problem occurs. Regards 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 -~--~~~~--~~--~--~---
Re: Lazy sequences without caching?
well, the problem with using def is that you're pinning the head of the sequence to a variable. if you wrap it in a fn, then you're making a new sequence each time you call the fn. so the head of the sequence isn't attached to anything, only the function that creates it is. On Tue, Dec 9, 2008 at 3:48 PM, Drew Olson <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 2:28 PM, Stephan Mühlstrasser < > [EMAIL PROTECTED]> wrote: > >> >> On Dec 9, 12:34 am, "harrison clarke" <[EMAIL PROTECTED]> wrote: >> > you're keeping the head of the sequence, and thus all the elements >> between >> > the head and nth. >> > >> > it's because you're using def, basically. >> > >> > > Ok, I'm confused here. Why does wrapping his logic into a > function alleviate this problem? Can you give a more detailed explanation, > I'd like to understand what's going on here. > > - Drew > > >> >> > if you make a function to return the sequence, and pass the result >> directly >> > to nth, without let-binding it or anything, it should work. >> >> Ok, I got it: >> >> user=> (defn triangle-numbers >> [] >>(let [rest-fn >>(fn rest-fn [current cumulated] >>(let [next (+ current cumulated)] >> (lazy-cons next (rest-fn (inc current) next] >>(rest-fn 1 0))) >> #'user/triangle-numbers >> user=> (nth (triangle-numbers) 100) >> 5151 >> user=> (nth (triangle-numbers) 1000) >> 501501 >> >> Thanks! >> 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 -~--~~~~--~~--~--~---
patch: idiot proof error message when compiling to the wrong place
Provides an error message like: (compile 'com.thinkrelevance.Hello) -> java.lang.RuntimeException: Unable to write to /some/bad/loc/ classes/com/thinkrelevance/Hello.class (Hello.clj:1) I used a RuntimeException because the constructor for IOException did not take a "cause" argument. Cheers, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~--- idiot_proof_error_message_when_compile_path_points_nowhere.diff Description: Binary data
Re: Lazy sequences without caching?
On Tue, Dec 9, 2008 at 2:28 PM, Stephan Mühlstrasser < [EMAIL PROTECTED]> wrote: > > On Dec 9, 12:34 am, "harrison clarke" <[EMAIL PROTECTED]> wrote: > > you're keeping the head of the sequence, and thus all the elements > between > > the head and nth. > > > > it's because you're using def, basically. > > > Ok, I'm confused here. Why does wrapping his logic into a function alleviate this problem? Can you give a more detailed explanation, I'd like to understand what's going on here. - Drew > > > if you make a function to return the sequence, and pass the result > directly > > to nth, without let-binding it or anything, it should work. > > Ok, I got it: > > user=> (defn triangle-numbers > [] >(let [rest-fn >(fn rest-fn [current cumulated] >(let [next (+ current cumulated)] > (lazy-cons next (rest-fn (inc current) next] >(rest-fn 1 0))) > #'user/triangle-numbers > user=> (nth (triangle-numbers) 100) > 5151 > user=> (nth (triangle-numbers) 1000) > 501501 > > Thanks! > 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 -~--~~~~--~~--~--~---
Re: Lazy sequences without caching?
On Dec 9, 12:34 am, "harrison clarke" <[EMAIL PROTECTED]> wrote: > you're keeping the head of the sequence, and thus all the elements between > the head and nth. > > it's because you're using def, basically. > > if you make a function to return the sequence, and pass the result directly > to nth, without let-binding it or anything, it should work. Ok, I got it: user=> (defn triangle-numbers [] (let [rest-fn (fn rest-fn [current cumulated] (let [next (+ current cumulated)] (lazy-cons next (rest-fn (inc current) next] (rest-fn 1 0))) #'user/triangle-numbers user=> (nth (triangle-numbers) 100) 5151 user=> (nth (triangle-numbers) 1000) 501501 Thanks! 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 -~--~~~~--~~--~--~---
Re: recur vs. lazy: establishing guidelines
On Dec 9, 11:18 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote: > Hi all, > > I am working on the functional programming chapter for the book this > week, and I have been reviewing uses of loop/recur vs. lazy-cat/lazy- > cons in Clojure to come up with some guidelines. > > Here is where I am: If your function creates/returns only atoms or > fixed size collections, loop/recur is fine. If it might return (or > internally create) variable/huge/infinite collections, use lazy-*. > > To make this more concrete: If you buy these guidelines, then butlast > is incorrect. If you point it at something huge it consumes all of > memory: > > (last (butlast (take 1 (iterate inc 0 > -> java.lang.OutOfMemoryError: Java heap space > > A lazy version works just fine: > > (defn lazy-butlast [s] > (if (rest s) > (lazy-cons (first s) (allbutlast (rest s))) > nil)) > > (last (lazy-butlast (take 1 (iterate inc 0 > -> 9998 > > But I bet that isn't the whole story. What are the counterarguments in > favor of non-lazy butlast? > > Cheers, > Stuart I am assuming 'allbutlast' is 'lazy-butlast'. Not really an in favor of butlast, but lazy-butlast also seems much faster. user=> (time (last (butlast (take 100 (iterate inc 0) "Elapsed time: 2710.068764 msecs" 98 user=> (time (last (lazy-butlast (take 100 (iterate inc 0) "Elapsed time: 714.63721 msecs" 98 user=> (time (last (butlast (take 100 (iterate inc 0) "Elapsed time: 1832.329244 msecs" 98 user=> (time (last (lazy-butlast (take 100 (iterate inc 0) "Elapsed time: 710.971437 msecs" 98 user=> (time (last (butlast (take 100 (iterate inc 0) "Elapsed time: 1266.704242 msecs" 98 user=> (time (last (lazy-butlast (take 100 (iterate inc 0) "Elapsed time: 701.681986 msecs" 98 user=> (time (last (butlast (take 100 (iterate inc 0) "Elapsed time: 1712.931529 msecs" 98 user=> (time (last (lazy-butlast (take 100 (iterate inc 0) "Elapsed time: 694.106062 msecs" 98 user=> Parth --~--~-~--~~~---~--~~ 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: recur vs. lazy: establishing guidelines
On Dec 9, 1:18 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote: > Here is where I am: If your function creates/returns only atoms or > fixed size collections, loop/recur is fine. If it might return (or > internally create) variable/huge/infinite collections, use lazy-*. I agree in general, although I'd simply say that loop/recur should be used only when there is no high-level (filter, map, reduce, ...) or lazy-* equivalent. On the other hand, some algorithms are clearer with loop/recur, especially when translated from an imperative style. -the other 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 -~--~~~~--~~--~--~---
anyone experience with brics.automaton regex engine?
Hi all. Ported my research project to clojure, and now just benchmarking parts of it. I am currently spending about 5/6th of all simulation time doing regular expressions, so I looked into alternative regex engines, optimizing the regular expression and trying to find out whether clojure's (re-pattern also compiles the regex. This old website lists the performance of several regex engines (the fastest ones are also 'incomplete' compared to the other ones): http://www.tusker.org/regex/regex_benchmark.html , and I am trying to get one of them to run in clojure. As I've no experience with java, I am struggling a bit. (add-classpath "file:///home/boris/projects/chapter4/automaton.jar") (import '(brics.automaton.RegExp)) (import '(brics.automaton.Automaton)) (import '(brics.automaton.RunAutomaton)) The above all loads fine, but the examples on the brics website (http://www.brics.dk/~amoeller/automaton/faq.html ), is quite minimal.. and I tried a few guesses how to call it through clojure [I tried (.. new Regex ("ana")), for example]. Any help with translating the syntax in this example to the clojure version would be appreciated! [java example:] RegExp r = new RegExp("ab(c|d)*"); Automaton a = r.toAutomaton(); String s = "abcccdc"; System.out.println("Match: " + a.run(s)); // prints: true [example of a typical string and regex in the model] "GEDFFEDBGBFEBADACACAFGCBGDDEGGEFDFFFGDCGFGAEAGCFFBCDDCDEBCDAAFDCECCGABCGAAABBBCAFGACAABGFEBDACDFEAAGFGCGDFDGDAAEBFBGBCBDAFDFGFBCFBEABECBBAAEBABGAGFBBAAFFGGBDABFGFAFAEBBBACGEACCEBBCAFDGCADEBGCGFEEEFEADBCGCFBCEFGGGECEGEDCFCCBADBEABCCFGEADDDBEDBBFDBFDCBGDAEFECDEBFGBCBCCBEDEFGGEGCEABAFGECGCACFEGDDAEBAACDBFCGCEAEFEBBABAACFEECFDEAFFGAFEFBDCFCABEEBACBFDCEEAFFBCEDAFFDACEAABBEGFCGDCBFFBBFDDDEEBFCEGCFEFCAAGGEBBGDBCEEGFCFDDFBBFECEGGDBEFBGABFBGEACGAADAFBBDEAGDBADEECAEAAGEGEFEDCABBGFGBEFEFACEBEFFGFCFFDCB" ((?=([ BD][ ABCDF][ FG][ ABDEF][ ABCDFG][ ABCDEFG][ BCEG][ ABEG] [ BCDEFG])) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A generic tree walker - clojure.contrib.walk
Hi folks, I just committed a new contrib lib, an experimental tree walker for Clojure. I'm hoping it will make it easier to write macros that need to do transformations arbitrary code structures. -Stuart Sierra - clojure.contrib.walk/walk ([f form]) Performs a depth-first, post-order traversal of form. Calls f on each sub-form, uses f's return value in place of the original. Recognizes all Clojure data structures except sorted-map-by. Consumes seqs as with doall. - clojure.contrib.walk/walk-replace ([smap form]) Recursively transforms form by replacing keys in smap with their values. Like clojure/replace but works on any data structure. - clojure.contrib.walk/keywordize-keys ([m]) Recursively transforms all map keys from strings to keywords. - clojure.contrib.walk/stringify-keys ([m]) Recursively transforms all map keys from keywords to strings. - clojure.contrib.walk/pr-walk ([form]) Demonstrates the behavior of walk by printing each form as it is walked. Returns form. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Understanding SLIME blog post
Hi all, With the recent huge surge of interest in Clojure, a lot of people have started using Emacs/SLIME for Clojure development. However, if you haven't developed in a Lisp-like language previously, SLIME may be quite confusing. I've posted a summary of a bunch of SLIME-related links on my blog: http://bc.tech.coop/blog/081209.html Hopefully, that will help to bring people up-to-speed on SLIME and some of the tips & techniques for using it effectively. -- 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 -~--~~~~--~~--~--~---
recur vs. lazy: establishing guidelines
Hi all, I am working on the functional programming chapter for the book this week, and I have been reviewing uses of loop/recur vs. lazy-cat/lazy- cons in Clojure to come up with some guidelines. Here is where I am: If your function creates/returns only atoms or fixed size collections, loop/recur is fine. If it might return (or internally create) variable/huge/infinite collections, use lazy-*. To make this more concrete: If you buy these guidelines, then butlast is incorrect. If you point it at something huge it consumes all of memory: (last (butlast (take 1 (iterate inc 0 -> java.lang.OutOfMemoryError: Java heap space A lazy version works just fine: (defn lazy-butlast [s] (if (rest s) (lazy-cons (first s) (allbutlast (rest s))) nil)) (last (lazy-butlast (take 1 (iterate inc 0 -> 9998 But I bet that isn't the whole story. What are the counterarguments in favor of non-lazy butlast? Cheers, 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: Running clojure-contrib.jar
Thanks All, It's working now,I followed Stuarts instructions(example 1). Emeka --~--~-~--~~~---~--~~ 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: PCL -> Clojure examples updated
The PCL -> Clojure blog helped turn me on to Clojure... She's a valuable asset. Glad to see she hasn't been left wearing a red dress out in the rain. You must be swamped with the book deadlines. Thank You for making the time to continue sharing and updating the pcl -> clojure code. On Dec 9, 10:34 am, Stuart Halloway <[EMAIL PROTECTED]> wrote: > Over the last few weeks I have updated the examples in the Practical > Common Lisp -> Clojure blog series [1]. They should be up-to-date with > the changes to binding forms in Clojure, plus a few errata fixes. > > Enjoy, and let me know if you find errors. > > Cheers, > Stu > > [1]http://blog.thinkrelevance.com/2008/9/16/pcl-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 -~--~~~~--~~--~--~---
PCL -> Clojure examples updated
Over the last few weeks I have updated the examples in the Practical Common Lisp -> Clojure blog series [1]. They should be up-to-date with the changes to binding forms in Clojure, plus a few errata fixes. Enjoy, and let me know if you find errors. Cheers, Stu [1] http://blog.thinkrelevance.com/2008/9/16/pcl-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: Calling superclass methods from implemented methods
On Dec 9, 12:24 am, Matt Revelle <[EMAIL PROTECTED]> wrote: > The attached patch adds :super-methods option to generate-class as a > map, {local-name [name [param-types] return-type], ...}. The > mechanics work as Rich suggested in an earlier message, a method is > created that has the same type signature as the exposed method - it > loads the arguments, invokes the method, and returns the result. > > An example can be viewed here:http://gist.github.com/33787 > > I haven't done extensive testing, but seems to work. > A couple of thoughts. First - the local name must be a valid Java method name - you are using dashes in your method names in the example code. Some VMs will balk at this. Second - it seems tedious and error-prone to have to specify the signatures, which must match the method sigs. Third, if a method is overloaded, multiple :super-methods entries must be made. Perhaps it would be better, and more consistent with :exposes, to take a map of method_name -> exposing_method_name, and generate a set of overloaded methods matching all overloads of the super method: :exposes-methods {update super_update, render super_render} This way people can't get the sigs wrong, and a single entry covers all overloads. 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: List comprehension: :when AND :while for the same binding?
On Mon, Dec 8, 2008 at 7:15 PM, Chouser <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 10:42 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: >> >> On Dec 8, 10:08 am, Chouser <[EMAIL PROTECTED]> wrote: >>> >>> doseq currently supports both. If both appear on the same binding, >>> the :while is always test first regardless of the order in which they >>> appear in the doseq. The thinking is that if the :while is false, >>> there's no need to check the :when. >>> >>> Is this Good, and should 'for' work the same way? >>> >> >> Yes. > > The attached patch adds support for :when and :while on the binding > expression in 'for'. The macro now parses its arguments using code > almost identical to 'doseq'. I've changed some local names in 'for' > and 'doseq' where they are similar to each other, so that both have > what I believe to be more descriptive names. > > If these extra renaming changes are undesirable, I can certainly > create a smaller patch. > > I've also attached a set of tests that I used. All but > While-and-When-Same-Binding behaved identically before and after my > changes to 'for'. > Patch applied (svn 1148) - 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 -~--~~~~--~~--~--~---
Re: clojure.contrib.test-is: first major rewrite
On Dec 9, 2:56 am, Dan Larkin <[EMAIL PROTECTED]> wrote: > Just one bone to pick, though. The "are" macro doesn't work so well > if I want to test a custom assert-expr function that only deals with a > single expression. Yeah, "are" isn't right. It's going to change, either by specifying the number of arguments, as Frantisek suggested, or with a template expression. For now, I recommend just using "is". -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: Extending Clojure's STM with external transactions
Since it requires changes to the Clojure runtime, it probably doesn't make much sense to put it in contrib. I've posted it as an attachment to the group. --Dave Griffith --~--~-~--~~~---~--~~ 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: Extending Clojure's STM with external transactions
Cool stuff, Dave. I'm interested to see/test it, could you post it as an attachment to this group or commit it to contrib ? Cheers, Razvan. On Dec 8, 9:08 pm, Dave Griffith <[EMAIL PROTECTED]> wrote: > Okay, hacking complete. I've got a patch that extends the Clojure STM > so that it will make appropriate callouts to an external transaction > manager that cause the STMs transaction to be atomic/consistent/ > isolated with respect to an external transaction, using a "dosync- > external" macro. Note that this is not the same as XA support. The > Clojure STM is in charge of the transaction as a whole, not the > external transaction manager. (Among other things, this means that > transactions can not span multiple transaction managers. You'll get > an exception if you try.) The external transaction manager must > implement the clojure.lang.ITransactionManager interface, which means > that to use any given external transaction manager you will need to > implement a small adapter to that interface, and instantiate it > appropriately. > > This code is highly experimental, and should not be used for > production purposes. Contents may have settled during shipping. All > models over 18. > > Where should I send the patch? > > --Dave Griffith --~--~-~--~~~---~--~~ 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: java built in HTTP server, proxy and HttpHandler interface
Hello Steve, > It may be that *out* gets redirected. Another difference between out > and err is that System/err is often associated with an "autoflush" > stream. It's possible that your output to *out* has ben buffered and > that you need a call to (flush) to ensure it's displayed. Not calling the flush could be the culprit... > On a separate note, one convenient thing about Clojure namespaces is > that they are created with "java.lang" already (effectively) imported. > An unqualified call like > > (.println System/err "something") Just learnt that *err* is defined in clojure so: (. *err* println "something") works :-). Kind regards, Vlad PS: uploaded example of handling "post" in http server: http-server- post.clj --~--~-~--~~~---~--~~ 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: Noob question on strings.
Hi all, > I think the reader gets confused after your initial "C:\dev\java > \clojure\clj-repl.bat" > If you start the repl again and try the string with \\ it works fine. > Also, when the reader gets confused by the above string, it seems to > miss the " at the end. If you enter a " by itself it seems to right > itself: Yes, thanks, you are all quite right. The reader had got confused somehow, and was treating the input as an unterminated string. Just putting a " on its own solved the problem. --~--~-~--~~~---~--~~ 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: Noob question on strings.
On Dec 9, 6:47 am, Ant <[EMAIL PROTECTED]> wrote: > Hi all, > > I've just started looking with interest at the language, and have > decided to port some of my smaller programs and scripts to Clojure as > a way of getting to know the language. I am stumbling over Strings at > the moment, as I am trying to read a file. I have tried the following: > > user=> "C:\dev\java\clojure\clj-repl.bat" > ")\n" > user=> java.lang.Exception: Invalid token: C: > java.lang.Exception: ReaderError:(8,1) Invalid token: C: > at clojure.lang.LispReader.read(LispReader.java:164) > at clojure.lang.Repl.main(Repl.java:68) > Caused by: java.lang.Exception: Invalid token: C: > at clojure.lang.LispReader.interpretToken(LispReader.java:266) > at clojure.lang.LispReader.read(LispReader.java:156) > ... 1 more > > OK, so that didn't work. I read the docs on Strings: > > Strings - Enclosed in "double quotes". May span multiple lines. > Standard Java escape characters are supported. > > So next I tried, thinking it may be the backslashes that were the > problem, and needed escaping: > > "C:\\dev\\java\\clojure\\clj-repl.bat" > "\n" > user=> java.lang.Exception: Invalid token: C: > java.lang.Exception: ReaderError:(10,1) Invalid token: C: > at clojure.lang.LispReader.read(LispReader.java:164) > at clojure.lang.Repl.main(Repl.java:68) > Caused by: java.lang.Exception: Invalid token: C: > at clojure.lang.LispReader.interpretToken(LispReader.java:266) > at clojure.lang.LispReader.read(LispReader.java:156) > ... 1 more > > Same error, and it seems to me that the double quoted string isn't > being accepted as a string literal. I tried converting the path to > forward slashes: > > java.lang.Exception: No such namespace: C:/dev/java/clojure > clojure.lang.Compiler$CompilerException: NO_SOURCE_FILE:0: No such > namespace: C:/dev/java/clojure > at clojure.lang.Compiler.analyze(Compiler.java:3713) > at clojure.lang.Compiler.analyze(Compiler.java:3671) > at clojure.lang.Compiler.eval(Compiler.java:3895) > at clojure.lang.Repl.main(Repl.java:75) > Caused by: java.lang.Exception: No such namespace: C:/dev/java/clojure > at clojure.lang.Compiler.resolveIn(Compiler.java:3998) > at clojure.lang.Compiler.resolve(Compiler.java:3972) > at clojure.lang.Compiler.analyzeSymbol(Compiler.java:3955) > at clojure.lang.Compiler.analyze(Compiler.java:3686) > ... 3 more > > So it seems that this isn't being treated as a string at all! It > thinks that the slashes are denoting a namespace. What am I missing > here? I think the reader gets confused after your initial "C:\dev\java \clojure\clj-repl.bat" If you start the repl again and try the string with \\ it works fine. Also, when the reader gets confused by the above string, it seems to miss the " at the end. If you enter a " by itself it seems to right itself: $ java -jar clojure.jar Clojure user=> "C:\dev\java\clojure\clj-repl.bat" java.lang.Exception: Unsupported escape character: \d java.lang.Exception: ReaderError:(1,1) Unsupported escape character: \d at clojure.lang.LispReader.read(LispReader.java:164) at clojure.lang.Repl.main(Repl.java:68) -- snip -- user=> "C:\\dev\\java\\clojure\\clj-repl.bat" "\n" user=> java.lang.Exception: Invalid token: C: java.lang.Exception: ReaderError:(2,1) Invalid token: C: at clojure.lang.LispReader.read(LispReader.java:164) at clojure.lang.Repl.main(Repl.java:68) Caused by: java.lang.Exception: Invalid token: C: at clojure.lang.LispReader.interpretToken(LispReader.java:266) at clojure.lang.LispReader.read(LispReader.java:156) ... 1 more -- snip -- user=> " " \n" user=> "C:\\dev\\java\\clojure\\clj-repl.bat" "C:\\dev\\java\\clojure\\clj-repl.bat" user=> --~--~-~--~~~---~--~~ 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: Noob question on strings.
On Tue, Dec 9, 2008 at 1:47 PM, Ant <[EMAIL PROTECTED]> wrote: > > Hi all, > > I've just started looking with interest at the language, and have > decided to port some of my smaller programs and scripts to Clojure as > a way of getting to know the language. I am stumbling over Strings at > the moment, as I am trying to read a file. I have tried the following: > > user=> "C:\dev\java\clojure\clj-repl.bat" > ")\n" > user=> java.lang.Exception: Invalid token: C: > java.lang.Exception: ReaderError:(8,1) Invalid token: C: >at clojure.lang.LispReader.read(LispReader.java:164) >at clojure.lang.Repl.main(Repl.java:68) > Caused by: java.lang.Exception: Invalid token: C: >at clojure.lang.LispReader.interpretToken(LispReader.java:266) >at clojure.lang.LispReader.read(LispReader.java:156) >... 1 more [...] > java.lang.Exception: No such namespace: C:/dev/java/clojure [...] It looks like you've got an unterminated string before you start. e.g.: $ java -cp clojure.jar clojure.main Clojure user=> string-that-does-not-start-with-a-quote" java.lang.Exception: Unable to resolve symbol: string-that-does-not-start-with-a-quote in this context (NO_SOURCE_FILE:0) user=> "C:\dev\something" "\n" user=> java.lang.Exception: Invalid token: C: user=> java.lang.Exception: Unsupported character: \dev user=> java.lang.Exception: Unsupported character: \something user=> So try restarting the repl. Or else type a single " and press Enter and see what you get. If you don't get something like "\n" printed by itself with no exceptions, try it again. -- Michael Wood <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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: java built in HTTP server, proxy and HttpHandler interface
On Dec 9, 2008, at 7:30 AM, prhlava wrote: > The > > (. java.lang.System/err println "something") > > works from in handler (it looks that *out* gets re-directed)... It may be that *out* gets redirected. Another difference between out and err is that System/err is often associated with an "autoflush" stream. It's possible that your output to *out* has ben buffered and that you need a call to (flush) to ensure it's displayed. On a separate note, one convenient thing about Clojure namespaces is that they are created with "java.lang" already (effectively) imported. An unqualified call like (.println System/err "something") should always compile and run. --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: Noob question on strings.
On Dec 9, 4:47 pm, Ant <[EMAIL PROTECTED]> wrote: > Hi all, > > I've just started looking with interest at the language, and have > decided to port some of my smaller programs and scripts to Clojure as > a way of getting to know the language. I am stumbling over Strings at > the moment, as I am trying to read a file. I have tried the following: > > user=> "C:\dev\java\clojure\clj-repl.bat" > ")\n" > user=> java.lang.Exception: Invalid token: C: > java.lang.Exception: ReaderError:(8,1) Invalid token: C: > at clojure.lang.LispReader.read(LispReader.java:164) > at clojure.lang.Repl.main(Repl.java:68) > Caused by: java.lang.Exception: Invalid token: C: > at clojure.lang.LispReader.interpretToken(LispReader.java:266) > at clojure.lang.LispReader.read(LispReader.java:156) > ... 1 more > > OK, so that didn't work. I read the docs on Strings: > > Strings - Enclosed in "double quotes". May span multiple lines. > Standard Java escape characters are supported. > > So next I tried, thinking it may be the backslashes that were the > problem, and needed escaping: > > "C:\\dev\\java\\clojure\\clj-repl.bat" > "\n" > user=> java.lang.Exception: Invalid token: C: Seems to work for me (on Linux with svn HEAD): user=> "C:\\dev\\java\\clojure\\clj-repl.bat" "C:\\dev\\java\\clojure\\clj-repl.bat" user=> "C:/dev/java/clojure/clj-repl.bat" "C:/dev/java/clojure/clj-repl.bat" user=> "C:" "C:" What release are you using? I am assuming you are on windows based on the string. Maybe you can try with the latest svn sources. Parth > java.lang.Exception: ReaderError:(10,1) Invalid token: C: > at clojure.lang.LispReader.read(LispReader.java:164) > at clojure.lang.Repl.main(Repl.java:68) > Caused by: java.lang.Exception: Invalid token: C: > at clojure.lang.LispReader.interpretToken(LispReader.java:266) > at clojure.lang.LispReader.read(LispReader.java:156) > ... 1 more > > Same error, and it seems to me that the double quoted string isn't > being accepted as a string literal. I tried converting the path to > forward slashes: > > java.lang.Exception: No such namespace: C:/dev/java/clojure > clojure.lang.Compiler$CompilerException: NO_SOURCE_FILE:0: No such > namespace: C:/dev/java/clojure > at clojure.lang.Compiler.analyze(Compiler.java:3713) > at clojure.lang.Compiler.analyze(Compiler.java:3671) > at clojure.lang.Compiler.eval(Compiler.java:3895) > at clojure.lang.Repl.main(Repl.java:75) > Caused by: java.lang.Exception: No such namespace: C:/dev/java/clojure > at clojure.lang.Compiler.resolveIn(Compiler.java:3998) > at clojure.lang.Compiler.resolve(Compiler.java:3972) > at clojure.lang.Compiler.analyzeSymbol(Compiler.java:3955) > at clojure.lang.Compiler.analyze(Compiler.java:3686) > ... 3 more > > So it seems that this isn't being treated as a string at all! It > thinks that the slashes are denoting a namespace. What am I missing > here? --~--~-~--~~~---~--~~ 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: java built in HTTP server, proxy and HttpHandler interface
Well, The (. java.lang.System/err println "something") works from in handler (it looks that *out* gets re-directed)... Vlad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Noob question on strings.
Hi all, I've just started looking with interest at the language, and have decided to port some of my smaller programs and scripts to Clojure as a way of getting to know the language. I am stumbling over Strings at the moment, as I am trying to read a file. I have tried the following: user=> "C:\dev\java\clojure\clj-repl.bat" ")\n" user=> java.lang.Exception: Invalid token: C: java.lang.Exception: ReaderError:(8,1) Invalid token: C: at clojure.lang.LispReader.read(LispReader.java:164) at clojure.lang.Repl.main(Repl.java:68) Caused by: java.lang.Exception: Invalid token: C: at clojure.lang.LispReader.interpretToken(LispReader.java:266) at clojure.lang.LispReader.read(LispReader.java:156) ... 1 more OK, so that didn't work. I read the docs on Strings: Strings - Enclosed in "double quotes". May span multiple lines. Standard Java escape characters are supported. So next I tried, thinking it may be the backslashes that were the problem, and needed escaping: "C:\\dev\\java\\clojure\\clj-repl.bat" "\n" user=> java.lang.Exception: Invalid token: C: java.lang.Exception: ReaderError:(10,1) Invalid token: C: at clojure.lang.LispReader.read(LispReader.java:164) at clojure.lang.Repl.main(Repl.java:68) Caused by: java.lang.Exception: Invalid token: C: at clojure.lang.LispReader.interpretToken(LispReader.java:266) at clojure.lang.LispReader.read(LispReader.java:156) ... 1 more Same error, and it seems to me that the double quoted string isn't being accepted as a string literal. I tried converting the path to forward slashes: java.lang.Exception: No such namespace: C:/dev/java/clojure clojure.lang.Compiler$CompilerException: NO_SOURCE_FILE:0: No such namespace: C:/dev/java/clojure at clojure.lang.Compiler.analyze(Compiler.java:3713) at clojure.lang.Compiler.analyze(Compiler.java:3671) at clojure.lang.Compiler.eval(Compiler.java:3895) at clojure.lang.Repl.main(Repl.java:75) Caused by: java.lang.Exception: No such namespace: C:/dev/java/clojure at clojure.lang.Compiler.resolveIn(Compiler.java:3998) at clojure.lang.Compiler.resolve(Compiler.java:3972) at clojure.lang.Compiler.analyzeSymbol(Compiler.java:3955) at clojure.lang.Compiler.analyze(Compiler.java:3686) ... 3 more So it seems that this isn't being treated as a string at all! It thinks that the slashes are denoting a namespace. What am I missing here? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
import doesn't work when jar was loaded with add-classpath ?
When I load a JAR at runtime with add-classpath (add-classpath "file:///Users/reb/java/jena.jar") and try user=> (import '(com.hp.hpl.jena.rdf.model ModelFactory)) I get java.lang.ClassNotFoundException: com.hp.hpl.jena.rdf.model.ModelFactory (NO_SOURCE_FILE:0) user=> However, I can still use the classes if I fully qualify them. The same import does work if I add the JAR to the classpath when invoking java, but that seems to be less flexible. Am I doing something wrong? Is this a bug? Any advice gratefully received! --~--~-~--~~~---~--~~ 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-contrib documentation
Hi Mark, Most modules in clojure-contrib (including test-is) contain documentation and examples directly in the header comment of the source file. Cheers, Paul. 2008/12/9 Mark Volkmann <[EMAIL PROTECTED]> > > Is there a primary website that provides documentation and examples of > using the various libraries in clojure-contrib? My googling efforts > have come up empty so far. I'm particularly interested in learning > more about test-is at the moment. > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne & Wear, DH5 8NE. This message is intended only for the use of the person(s) ("the intended recipient(s)") to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ 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: java built in HTTP server, proxy and HttpHandler interface
Hello Kyle, What got me started is java code on: http://www.java2s.com/Code/Java/JDK-6/LightweightHTTPServer.htm But what is strange that java code handler can print to console and clojure version (if run as a script) does not. How do you go about debugging the handler? Kind regards, Vlad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---