Re: Patch: precompiling Clojure core sources in Ant build script

2008-12-09 Thread Bill Clementson

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

2008-12-09 Thread J. McConnell
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

2008-12-09 Thread Mark McGranaghan

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

2008-12-09 Thread Mark Volkmann

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

2008-12-09 Thread MattyDub

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?

2008-12-09 Thread Randall R Schulz

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?

2008-12-09 Thread Randall R Schulz
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?

2008-12-09 Thread Stephen C. Gilardi


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?

2008-12-09 Thread Stephen C. Gilardi


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

2008-12-09 Thread Bill Clementson

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

2008-12-09 Thread Rich Hickey

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

2008-12-09 Thread MattyDub

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

2008-12-09 Thread Rich Hickey

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?

2008-12-09 Thread Brian Doyle
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

2008-12-09 Thread Paul Mooser

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

2008-12-09 Thread Matt Revelle

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

2008-12-09 Thread Paul Mooser

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?

2008-12-09 Thread Stephen C. Gilardi
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

2008-12-09 Thread Bill Clementson

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?

2008-12-09 Thread Randall R Schulz

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?

2008-12-09 Thread Drew Olson
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?

2008-12-09 Thread Mark Volkmann

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

2008-12-09 Thread Tom Emerson

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?

2008-12-09 Thread Brian Doyle
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?

2008-12-09 Thread Stuart Halloway

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?

2008-12-09 Thread Stephan Mühlstrasser



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?

2008-12-09 Thread harrison clarke
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

2008-12-09 Thread Stuart Halloway
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?

2008-12-09 Thread Drew Olson
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?

2008-12-09 Thread Stephan Mühlstrasser

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

2008-12-09 Thread Parth Malwankar



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

2008-12-09 Thread Stuart Sierra

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?

2008-12-09 Thread bOR_

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

2008-12-09 Thread Stuart Sierra

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

2008-12-09 Thread bc

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

2008-12-09 Thread Stuart Halloway

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

2008-12-09 Thread janus



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

2008-12-09 Thread Mon Key

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

2008-12-09 Thread Stuart Halloway

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

2008-12-09 Thread Rich Hickey



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?

2008-12-09 Thread Rich Hickey

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

2008-12-09 Thread Stuart Sierra

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

2008-12-09 Thread Dave Griffith

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

2008-12-09 Thread Razvan Ludvig

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

2008-12-09 Thread prhlava


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.

2008-12-09 Thread Ant

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.

2008-12-09 Thread Mark Wutka



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.

2008-12-09 Thread Michael Wood

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

2008-12-09 Thread Stephen C. Gilardi


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.

2008-12-09 Thread Parth Malwankar



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

2008-12-09 Thread prhlava


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.

2008-12-09 Thread Ant

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 ?

2008-12-09 Thread rob.blackwell

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

2008-12-09 Thread Paul Drummond
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

2008-12-09 Thread prhlava


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
-~--~~~~--~~--~--~---