Re: classpath in clojure box

2010-01-15 Thread brian

ok i see it

Brian

Shawn Hoover wrote:


On Thu, Jan 14, 2010 at 3:17 AM, brian brw...@gmail.com 
mailto:brw...@gmail.com wrote:


The above didn't work, but apparently it doesn't pick up my .emacs
file, which has

(setq swank-clojure-classpath
   (list c:/shcloj-code/code/examples))

itknows where home is, when it boots up, the default is my home
dir, where .emacs is


when i do C-h v

swank-clojure-classpath is a variable defined in `swank-clojure.el'.
Its value is
(c:/Program Files/Clojure
Box/emacs/site-lisp/../../swank-clojure/src
c:/shcloj-code/code/examples c:/Program Files/Clojure
Box/lib/clojure-contrib.jar c:/Program Files/Clojure
Box/lib/clojure.jar c:/Program Files/Clojure
Box/lib/commons-codec-1.3.jar c:/Program Files/Clojure
Box/lib/commons-fileupload-1.2.1.jar c:/Program Files/Clojure
Box/lib/commons-io-1.4.jar c:/Program Files/Clojure
Box/lib/compojure.jar c:/Program Files/Clojure
Box/lib/grizzly-http-servlet-1.9.10.jar c:/Program Files/Clojure
Box/lib/grizzly-http-webserver-1.9.10.jar c:/Program
Files/Clojure Box/lib/jetty-6.1.15.jar c:/Program Files/Clojure
Box/lib/jetty-util-6.1.15.jar c:/Program Files/Clojure
Box/lib/servlet-api-2.5-20081211.jar)


Actually it's there, buried between the swank-clojure/src and 
clojure-contrib.jar. It's Clojure Box's fault on the ordering, but it 
would only matter if you were trying to put your own version of 
swank-clojure on the classpath.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Question about seq

2010-01-15 Thread Sean Devlin
Hey everyone,
I was working with seq today, and I was wondering why I got a certain
result.

user= (seq [])
nil

Why is nil returned, instead of an empty sequence?

Sean
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Question about seq

2010-01-15 Thread Laurent PETIT
Hey,

I guess because a sequence is not a datastructure.
If there is nothing to iterate over via 'first or 'next, then it's nil.

And an empty sequence is precisely that: nil.

In my point of view, a sequence is more like a functional iterator:
calling first on it will always return the same value, calling next on
it will return either nil if we are at the end, either a new seq ...

Hope I'm clear and also correct,

-- 
Laurent


2010/1/15 Sean Devlin francoisdev...@gmail.com:
 Hey everyone,
 I was working with seq today, and I was wondering why I got a certain
 result.

 user= (seq [])
 nil

 Why is nil returned, instead of an empty sequence?

 Sean

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Question about seq

2010-01-15 Thread Stephen C. Gilardi
On Jan 15, 2010, at 3:26 AM, Sean Devlin wrote:

 user= (seq [])
 nil
 
 Why is nil returned, instead of an empty sequence?

It's fundamental to Clojure's seq abstraction that every seq has a first. There 
is no such thing as an empty seq. If you call the seq function on an empty 
collection, it can't return a seq because that (hypothetical) seq would have no 
first. Instead seq returns nil meaning no seq.

(seq x) (used as a predicate) is the canonical way in Clojure to ensure that x 
contains at least one item.

Rich's video about Clojure sequences at iTunes and on blip.tv provides more 
details and rationale.

--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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Question about seq

2010-01-15 Thread Adrian Cuthbertson
Hi Sean,

The background to this lies in the implementation of lazy sequences -
seq returns an implementation of ISeq for the data structure in
question - nil when there are no elements in the structure. Have a
look at http://clojure.org/sequences and also http://clojure.org/lazy
which gives the full reasoning behind this. It clarifies when to use
next and when to use rest (lazy sequences).

-Hth, Adrian.

On Fri, Jan 15, 2010 at 10:26 AM, Sean Devlin francoisdev...@gmail.com wrote:
 Hey everyone,
 I was working with seq today, and I was wondering why I got a certain
 result.

 user= (seq [])
 nil

 Why is nil returned, instead of an empty sequence?

 Sean

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Many foolish questions

2010-01-15 Thread Michael Wood
2010/1/15 Simon Brooke still...@googlemail.com:
 OK, I'm trying to get seriously stuck in, and the first thing I'm
 trying to do is reimplement an inference engine I first wrote in
 Portable Standard Lisp and then in InterLisp-D in /idiomatic/ Clojure.
 So please have patience with me...

 If one has something which is strongly typed, is it idiomatic to make
 a Java class to hold it?

 I want a structure like this

 (defstruct feature :name :default)

 but I want in addition to constrain the binding of :name to be always
 a Clojure keyword and the binding of :default to be always a boolean -
 the Clojure values either true or false.

 I've tried

 (defstruct feature [#^Keyword :name] :default)

#^something applies to the thing to the right of it.  There's no need
to enclose anything in square brackets.  But this won't work here
anyway:

user= (defstruct feature #^Keyword :name :default)
java.lang.IllegalArgumentException: Metadata can only be applied to IMetas
:default
java.lang.Exception: Unmatched delimiter: )

 but the reader spits an illegal argument exception. Is there different
 syntax which the reader could parse? Or am I using the wrong kind of
 thing?

 Of course given that a struct is immutable I could have a make-feature
 function which has type-hinted args:

 (defn
        #^{:doc Make a feature safely}
        make-feature [#^Keyword name #^bool default]
        (struct-map feature :name name :default default))

defn also supports docstrings more directly like this:

(defn make-feature
  Make a feature safely
  [...]
  (struct-map ...))

 This works and does sort-of what I want - I can't guarantee that

Does it?

user= (defn
  #^{:doc Make a feature safely}
  make-feature [#^Keyword name #^bool default]
  (struct-map feature :name name :default default))
#'user/make-feature
user= (make-feature some name 42)
{:name some name, :default 42}

 nothing outside my make-feature function will make features but I
 don't think I need to. However, it feels clunky - I instinctively feel
 there must be a better way. Is this what deftype should be used for?
 If so, where is it documented? The book I'm using - Stuart Halloway's
 'Programming Clojure' - doesn't seem to have it (or if it has I've
 missed it). Also, I don't seem to have deftype in my 1.1.0 rc3 build :

 cc.journeyman.dtree.dtree= (doc deftype)
 java.lang.Exception: Unable to resolve var: deftype in this context
 (NO_SOURCE_FILE:20)

 I've also grepped the source code of clojure and failed to find it.

It's not in any official release yet.  In your git checkout do
something like this to get it:

$ git checkout -b new origin/new

That will create a branch called new based on the new branch in
Rich's repository.  Then you can git pull as usual to keep it
updated.  If you want to switch back to master, just do git checkout
master.

I've not tried deftype yet, so I don't know if it's what you're looking for.

-- 
Michael Wood esiot...@gmail.com
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: dgraph 1.0, a dependency graph library for Clojure

2010-01-15 Thread Laurent PETIT
2010/1/15 Constantine Vetoshev gepar...@gmail.com:
 I would like to announce the release of dgraph 1.0, a dependency graph
 implementation for Clojure.

 http://github.com/gcv/dgraph

 dgraph provides a mostly pure functional data structure whose nodes
 behave like cells in a spreadsheet. Data changes in stored nodes cause
 their dependent computed nodes to invalidate and recalculate
 themselves. Dependency graphs are immutable, just like Clojure's built-
 in persistent data structures, so changing a stored node actually
 augments an existing graph and returns a new one with shared
 structure.

 I wrote this to simplify UI programming, and it has helped reduce the
 pain significantly. The README file in the GitHub repository has some
 usage examples and ideas.

 Comments and bug reports welcome.

Hello Constantine,

Great job !

I would like to know, is there an essential reason for not having
stored the dependency graph as a hidden property of the graph ?

Do you have examples of where you see it interesting to use (and not
abuse :-) ) side effects in combination with eager/patient ?

Are there implicit hypothesis (not yet documented ? or maybe I
overlooked) on the types that can be used for the keys of the graph ?

For those of use who do not know cl cells, would it be easy to explain
in which area it differs ?

Cheers,

-- 
Laurent


 Thanks,
 Constantine Vetoshev

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Why is (shutdown-agents) not used and explained more in Clojure concurrency examples

2010-01-15 Thread ggras
Hi,

I am learning Clojure for some weeks now and i've just started playing
around with threads.

But as soon as i used threads in a clojure script the program had a 60
seconds period of doing nothing after the script completed and before
it returned to the command prompt or Slime REPL prompt. I assumed this
must be some kind of timeout setting in Java or Clojure but i didn't
know how to change or delete this.
So I've tried some thread example scripts i found (for example the
barbershop scripts from CGrand or LauJensen) with different Clojure
versions, Java versions and different PCs, always with the same
result.

At last after some hours of unsuccessful tries and google searches i
stumbled across some short answer here in this group mentioning
(shutdown-agents). So i did (doc shutdown-agents):
---
clojure.core/shutdown-agents
([])
  Initiates a shutdown of the thread pools that back the agent system.
  Running actions will complete, but no new actions will be accepted
---
Aha!!
Using this command as the last statement in the example scripts
immediately solved my problem.

So my question is: Is there a reason why (shutdown-agents) is not used
and/or explained more in Clojure concurrency examples? Doing so would
avoid some frustration for the people learning Clojure IMHO.

Any comment to shed some light on this would be appreciated.

Thanks
Gerhard
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[im]mutability, threads, state and idiom

2010-01-15 Thread Simon Brooke
Right, I'm trying to get my head around the consequences of
immutability for the sort of programming practices I'm used to, and
how I change the way I do things to fit in with it. Initially I
thought 'well, immutability just means you can't use rplaca and
rplacd, and I've very rarely used either so it doesn't affect me.' But
then I saw that it does. So I'm going right back to one of the first
programs I ever wrote in LISP, which was a multi-player text adventure
game.

To represent a player arriving in a room, you did something like

;; pseudo lisp - actual details unimportant
(defun move (player room)
  (let ((oldroom (get player 'location))(player-terminal (get player
'terminal)))
(put oldroom 'players (remove player (get oldroom 'players)))
(map (get oldroom 'players)
  '(lambda (other) (print (list (get player 'name) 'has 'left)
(get other 'terminal)))
(print (append '(you are in) (get room 'description)) player-
terminal)
(map (get room 'players)
  '(lambda (other) (print (list (get player 'name) 'has 'arrived)
(get other 'terminal))
(print (list (get other 'name) 'is 'here) player-terminal)))
(put player 'location room)
(put room 'players (cons player (get room 'players)

OK, not very functional or elegant. However, it operates mainly by
manipulating property lists, and property lists are  essentially maps,
so at first glance easy to translate... but if the maps are immutable,
then I can't do anything equivalent to

(put oldroom 'players (remove player (get oldroom 'players)))

I can create a new /copy/ of oldroom which is identical to oldroom
except that it has a different set of players, but I can't then set
all things that pointed to oldroom to point to the new copy. So that
way of working doesn't work. We cannot change state on either the
players or the rooms.

My next thought is that I need a new state-holding data structure
which maps players to rooms and vice-versa:

(def
#^{:doc A map which maps every player to his/her location, and
every
   location to the players who are present there}
*player-location-map* {})

(defn
#^{:doc Move player, assumed to be a struct of type player,
to location, assumed to be a struct of type location}
move [player location]
(let [old-location (player *player-location-map*)]
;; do things to announce move to others at new location, and
describe others to player
;; do this first because player is not there yet
(map #(announce-arrival player %) (location 
*player-location-map*))
(print-to-user player (format You are in %s (:description
location))
(map
#(print-to-user player (format %s is here (:name %)))
(location *player-location-map*))
(def *player-location-map*
(merge
{player location}
{location (cons player (location 
*player-location-map*)) }
{old-location (remove #(identical? player %) 
(old-location *player-
location-map*)) }
*player-location-map*))
;; do things to announce move to players at old location
(map #(announce-departure player %) (old-location 
*player-location-
map*)

This gives us just one global variable which holds state about who is
where; and, providing the implementation of a map is fairly efficient,
it does so without a huge amount of overhead. I'm always wary of
global variables... It seems (it isn't working yet, for the reason
that follows) that this approach would work. Is it a good one?

However, it raises the next issue. Suppose we want to construct the
old classic maze of twisty little passages, all alike. So we have,
notionally:

(def maze1 {:description a maze of twisty passages, all alike :north
maze2 :east maze3 :west maze4})
(def maze2 {:description a maze of twisty passages, all alike :north
maze1 :east maze4 :west maze3})

This doesn't work because at the time we try to create maze1, maze2
doesn't exist. If we created maze1 without the reference to maze2 (and
assuming maze3 and maze4 already existed), we could then create maze2.
But we couldn't subsequently fix up the pointer from maze1 to maze2,
because doing so would create a new copy of maze1 and maze2's :north
would still point to the old copy.

Of course we could invent six more magic global maps *north-of*, *east-
of*, *south-of*, *west-of*, *above*, *below*... but this is all
starting to look awfully clunky (yes, OK, we could have one global map
with keys :north-of, :east-of... each pointing to another map, but
that's just hiding the clunkiness behind a facade).

The adventure game's collection of rooms is just an example of the
general case of a cyclic directed graph. Surely there must be some
clean idiomatic way 

Re: mutability, threads, state and idiom

2010-01-15 Thread ataggart


On Jan 15, 7:25 am, Simon Brooke still...@googlemail.com wrote:
 So, there seem to be four possibilities

 (1) I've chosen the wrong language for the problem, or vice versa;
 (2) There is some idiomatic means of managing mutable state which I've
 missed;
 (3) The right solution is to create a hybrid system using POJOs for
 the mutable state;
 (4) The right solution is to create a hybrid system using a relational
 database for the mutable state.

 Opinions?

2.

http://clojure.org/refs
http://clojure.org/atoms
http://clojure.org/agents
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: mutability, threads, state and idiom

2010-01-15 Thread Meikel Brandmeyer
Hi,

On Jan 15, 4:25 pm, Simon Brooke still...@googlemail.com wrote:
 Right, I'm trying to get my head around the consequences of
!-- SNIP --
 Opinions?

You have to distinguish between identity and state.

Disclaimer: I have no clue whatsoever about game design.

The different rooms are identities, the different players are
identities. An identity might have a varying state over time. So the
right thing to call for are Clojure's state handling facilities, eg.
Refs.

(declare player1 ork *room1* *room2*)

(def player1 (ref {:in-room *room1* :inventory nil}))
(def ork (ref {:in-room *room2* :health 100}))
(def *room1* (ref {:occupants #{player1}}))
(def *room2* (ref {:occupants #{ork}}))

Now time evolves and the player in front of the keyboard goes south:

(dosync
  (alter player1 assoc :in-room *room2*)
  (alter *room1* update-in [:occupants] disj player1)
  (alter *room2* update-in [:occupants] conj player1))

Now the refs look like this:

player1 (ref {:in-room *room2* :inventory nil})
ork (ref {:in-room *room2* :health 100})
*room1* (ref {:occupants #{}})
*room2* (ref {:occupants #{player1 ork}})

The STM takes care to coordinate these changes also across different
threads.

You might want to explore http://clojure.org and watch some of Rich's
screencasts.

Hope this helps to get you started.

Sincerely
Meikel
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: mutability, threads, state and idiom

2010-01-15 Thread ataggart
Also check out Rich's video covering concurrency, and in particular
his Ants program:
http://blip.tv/file/812787

For more on state stuff:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

And a neat series showing how games which look imperative can be bent
to be (mostly) functional:
http://prog21.dadgum.com/23.html
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Many foolish questions

2010-01-15 Thread Rayne
Ignore this. ;)

deftype and reify and all of that good stuff are now in the Clojure
master branch. Rich pulled new into master a few days ago.

On Jan 15, 4:09 am, Michael Wood esiot...@gmail.com wrote:
 2010/1/15 Simon Brooke still...@googlemail.com:



  OK, I'm trying to get seriously stuck in, and the first thing I'm
  trying to do is reimplement an inference engine I first wrote in
  Portable Standard Lisp and then in InterLisp-D in /idiomatic/ Clojure.
  So please have patience with me...

  If one has something which is strongly typed, is it idiomatic to make
  a Java class to hold it?

  I want a structure like this

  (defstruct feature :name :default)

  but I want in addition to constrain the binding of :name to be always
  a Clojure keyword and the binding of :default to be always a boolean -
  the Clojure values either true or false.

  I've tried

  (defstruct feature [#^Keyword :name] :default)

 #^something applies to the thing to the right of it.  There's no need
 to enclose anything in square brackets.  But this won't work here
 anyway:

 user= (defstruct feature #^Keyword :name :default)
 java.lang.IllegalArgumentException: Metadata can only be applied to IMetas
 :default
 java.lang.Exception: Unmatched delimiter: )

  but the reader spits an illegal argument exception. Is there different
  syntax which the reader could parse? Or am I using the wrong kind of
  thing?

  Of course given that a struct is immutable I could have a make-feature
  function which has type-hinted args:

  (defn
         #^{:doc Make a feature safely}
         make-feature [#^Keyword name #^bool default]
         (struct-map feature :name name :default default))

 defn also supports docstrings more directly like this:

 (defn make-feature
   Make a feature safely
   [...]
   (struct-map ...))

  This works and does sort-of what I want - I can't guarantee that

 Does it?

 user= (defn
   #^{:doc Make a feature safely}
   make-feature [#^Keyword name #^bool default]
   (struct-map feature :name name :default default))
 #'user/make-feature
 user= (make-feature some name 42)
 {:name some name, :default 42}

  nothing outside my make-feature function will make features but I
  don't think I need to. However, it feels clunky - I instinctively feel
  there must be a better way. Is this what deftype should be used for?
  If so, where is it documented? The book I'm using - Stuart Halloway's
  'Programming Clojure' - doesn't seem to have it (or if it has I've
  missed it). Also, I don't seem to have deftype in my 1.1.0 rc3 build :

  cc.journeyman.dtree.dtree= (doc deftype)
  java.lang.Exception: Unable to resolve var: deftype in this context
  (NO_SOURCE_FILE:20)

  I've also grepped the source code of clojure and failed to find it.

 It's not in any official release yet.  In your git checkout do
 something like this to get it:

 $ git checkout -b new origin/new

 That will create a branch called new based on the new branch in
 Rich's repository.  Then you can git pull as usual to keep it
 updated.  If you want to switch back to master, just do git checkout
 master.

 I've not tried deftype yet, so I don't know if it's what you're looking for.

 --
 Michael Wood esiot...@gmail.com
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: mutability, threads, state and idiom

2010-01-15 Thread Laurent PETIT
Simon,

To be very clear, and incite you to watch all those videos and read
all this material:

One of the key motivations (if not the primary) of Rich writing
clojure has been constructing a language which would offer built-in
semantics to manage state change over time.

So you're really in the right language regarding your concerns !

This is what makes clojure so different from other pure functional
languages or from pure non functional languages, as Rich stated in
one of his videos:

Clojure has a story for the parts of your program you cannot write
purely functionally.

HTH,

-- 
Laurent

2010/1/15 ataggart alex.tagg...@gmail.com:
 Also check out Rich's video covering concurrency, and in particular
 his Ants program:
 http://blip.tv/file/812787

 For more on state stuff:
 http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

 And a neat series showing how games which look imperative can be bent
 to be (mostly) functional:
 http://prog21.dadgum.com/23.html

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: dgraph 1.0, a dependency graph library for Clojure

2010-01-15 Thread Constantine Vetoshev
On Jan 14, 7:29 pm, Timothy Pratley timothyprat...@gmail.com wrote:
 To give me a
 head-start, are there key differences with clojure.contrib.dataflow so
 I can better understand?

Thank you for your interest. I have not extensively used c.c.dataflow,
so I apologize if I misrepresent it, but here are some key
differences:

1. c.c.dataflow feels imperative in nature. build-dataflow returns a
ref. Functions which manipulate these refs — such as update-values,
add-cells, and remove-cells — use destructive modification. dgraph
tries pretty hard to work functionally, just like Clojure's built-in
persistent data structures. A dgraph is immutable, but supports an
extend operation similar to assoc and conj. Extended dgraphs share
structure with original dgraphs as much as possible.

2. c.c.dataflow does not seem to support lazily computed nodes. A node
put in a dataflow computes itself immediately. dgraph supports this
behavior with eager nodes, but has two other modes: lazy and patient.
I tried to explain how those work in the README. Please let me know if
the documentation makes no sense. I'll add a more detailed example to
the source repository later today.
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Question about seq

2010-01-15 Thread Stephen C. Gilardi

On Jan 15, 2010, at 4:01 AM, Stephen C. Gilardi wrote:

 On Jan 15, 2010, at 3:26 AM, Sean Devlin wrote:
 
 user= (seq [])
 nil
 
 Why is nil returned, instead of an empty sequence?
 
 There is no such thing as an empty seq.

This was true at one time, but isn't true after the changes to Clojure that 
added LazySeq.

For example:

user= (def e (filter even? [1]))
#'user/e
user= (type e)
clojure.lang.LazySeq ; e is a lazy seq
user= (seq? e)
true ; e is a seq
user= (empty? e)
true ; e is empty
user= e
()   ; e prints as an empty seq

 (seq x) (used as a predicate) is the canonical way in Clojure to ensure that 
 x contains at least one item.

This is still true (and is mentioned in the doc for empty?)

user= (seq e)
nil  ; seq e is nil

--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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: mutability, threads, state and idiom

2010-01-15 Thread Raoul Duke
On Fri, Jan 15, 2010 at 7:58 AM, ataggart alex.tagg...@gmail.com wrote:
 And a neat series showing how games which look imperative can be bent
 to be (mostly) functional:
 http://prog21.dadgum.com/23.html

i find it interesting that there are so many drastically different
approaches cf. http://world.cs.brown.edu/

sincerely.
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Lazy recursive walk.

2010-01-15 Thread Nicolas Buduroi
Hi, I'm still not familiar with laziness and I'm trying to make a
function recursively walk arbitrary data structures to perform some
action on all strings. The non-lazy version is quite easy to do:

(use
  'clojure.walk
  'clojure.contrib.str-utils)

(defn recursive-string-walk [f form]
  (walk #(if (string? %) (f %) (recursive-string-walk f %))
identity form))

But it blow up the stack quite rapidly, I've tried to inject some
laziness inside, but only came up with a slight improvement. It can
take forms that are a little more than two time as deep.

(defn recursive-string-walk [f form]
  (walk #(cond
   (string? %) (f %)
   (seq? %)(lazy-seq (recursive-string-walk f %))
   :default(recursive-string-walk f %))
identity form))

Is there a way too make a fully lazy version of this function?

Thanks

- budu
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Lazy recursive walk.

2010-01-15 Thread Sean Devlin
Did you try wrapping everything w/ a call to lazy-seq?

On Jan 15, 3:21 pm, Nicolas Buduroi nbudu...@gmail.com wrote:
 Hi, I'm still not familiar with laziness and I'm trying to make a
 function recursively walk arbitrary data structures to perform some
 action on all strings. The non-lazy version is quite easy to do:

 (use
   'clojure.walk
   'clojure.contrib.str-utils)

 (defn recursive-string-walk [f form]
   (walk #(if (string? %) (f %) (recursive-string-walk f %))
     identity form))

 But it blow up the stack quite rapidly, I've tried to inject some
 laziness inside, but only came up with a slight improvement. It can
 take forms that are a little more than two time as deep.

 (defn recursive-string-walk [f form]
   (walk #(cond
            (string? %) (f %)
            (seq? %)    (lazy-seq (recursive-string-walk f %))
            :default    (recursive-string-walk f %))
     identity form))

 Is there a way too make a fully lazy version of this function?

 Thanks

 - budu
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Lazy recursive walk.

2010-01-15 Thread Nicolas Buduroi

On Jan 15, 3:25 pm, Sean Devlin francoisdev...@gmail.com wrote:
 Did you try wrapping everything w/ a call to lazy-seq?

Yes, it doesn't seem change anything.
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: dgraph 1.0, a dependency graph library for Clojure

2010-01-15 Thread Constantine Vetoshev
On Jan 15, 5:59 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 I would like to know, is there an essential reason for not having
 stored the dependency graph as a hidden property of the graph ?

I'm not sure I understand your question. You can see the stored graph
if you take the function returned by dg/make-dgraph and call it
without any arguments. I consider that an implementation detail,
though.

The dependency graph returned by dg/make-graph is a closure rather
than a data structure mainly to allow shortcut syntax for accessing
and setting node values: (my-dgraph :my-node) is just a function
call. So is (my-dgraph :my-node new-node-value). If my-dgraph was not
a function, there would have to be a more verbose calling convention.
(Reader macro support in Clojure would have taken away some of the
verbosity.)

 Do you have examples of where you see it interesting to use (and not
 abuse :-) ) side effects in combination with eager/patient ?

I just checked in a Swing usage example which uses side effects to
update the UI (http://github.com/gcv/dgraph/blob/master/src/examples/
dgraph/swing.clj). Please let me know if it makes sense. I hope the
concept is useful outside of just making Swing programming less
agonizing, though. :)

 Are there implicit hypothesis (not yet documented ? or maybe I
 overlooked) on the types that can be used for the keys of the graph ?

Not particularly, no. I have always used keywords, so they are best-
tested. Even so, any type usable as a key in a normal Clojure map
should work. If you find something not working with another type,
definitely let me know, and I'll try to fix it.

 For those of use who do not know cl cells, would it be easy to explain
 in which area it differs ?

Cells the Common Lisp library lets you put slots of CLOS objects on a
dependency graph. Put another way, any slot in any CLOS object can
become a node on the graph. The Clojure dgraph library isolates the
entire dependency graph in a separate, immutable data structure.
Clojure cannot readily adopt the Cells way of doing things, because it
has no CLOS and no meta-object protocol. dgraph also tries to at allow
and even encourage purely functional use, in spite of its usefulness
in side-effect-ridden UI code. Cells is more imperative in nature.

Thanks for your interest in dgraph!
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: mutability, threads, state and idiom

2010-01-15 Thread Simon Brooke
On 15 Jan, 17:40, Laurent PETIT laurent.pe...@gmail.com wrote:
 Simon,

 To be very clear, and incite you to watch all those videos and read
 all this material:

 One of the key motivations (if not the primary) of Rich writing
 clojure has been constructing a language which would offer built-in
 semantics to manage state change over time.

 So you're really in the right language regarding your concerns !

 This is what makes clojure so different from other pure functional
 languages or from pure non functional languages, as Rich stated in
 one of his videos:

 Clojure has a story for the parts of your program you cannot write
 purely functionally.


Thanks Laurent, atagart, Meikel. That's all extremely helpful. I'm
just now implementing the command parser, and having a lot of fun. I'm
thinking about how most efficiently to use the transactional memory to
hold state, but the command parser is pretty much pure functional and
so is easy.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Clojure on Ideone!

2010-01-15 Thread sphere research
Hi,

test Clojure on ideone.com
(more: http://www.facebook.com/pages/ideone/245768360841)

see the example: http://ideone.com/Aymq9Tg4

if you wish, we could install Clojure on spoj.pl,

regards,

IdeoneSPOJ Team
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: clojure unicode on Windows

2010-01-15 Thread Kevin Downey
are you using the repl directly? or wrapped in jline or rlwrap?

On Wed, Jan 13, 2010 at 3:02 PM, Lukas Lehner lehner.lu...@gmail.com wrote:
 Ok, tried to put this at the top of the file, but same bad result on Win
 (System/setProperty file.encoding  UTF8)

 and actually here
 http://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding
 it looks like JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 has the same effect,
 and should be used (and I am using it)

 Is everybody here running macs and linuxes? :(

 And, more important now is actually REPL
 user= (System/setProperty file.encoding  UTF8)
 UTF8
 user= éőó
 �o�
 user=

 L

 On 1/13/2010 11:34 PM, Kevin Downey wrote:

 java uses local settings, on windows the default encoding is some
 godawful thing (same on Mac, still godawful, but different) set
 file.encoding to pick something sane

 On Wed, Jan 13, 2010 at 1:52 PM, Lukas Lehnerlehner.lu...@gmail.com
  wrote:


 Hi all

 The clojure unicode reading, evaluating and printing was discussed
  already
 with various results. Let me add one more, and kindly ask for advice if
 anyone has.

 OS: Windows 7
 clojure 1.1
 C:\java -version
 Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
 java version 1.6.0_17
 Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
 Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)

 chcp: 437

 java clojure.main
 user=  éáú
 java.lang.Exception: Unable to resolve symbol: ��� in this context
 (NO_SOURCE_FILE:0)

 You see the problem.

 chcp: 65001

 java clojure.main
 user=  éáú


 C:\

  In this case REPL is killed without any message


 File unicode-test.clj in unicode:
 (println (seq (.split őúáé öüü? sdf \\W+)))

 c:\java clojure.main unicode-test.clj
 Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
 Exception in thread main java.lang.Exception: Unable to resolve symbol:
 
 in this context (unicode-test.clj:0)0)

 rest of the error at http://clojure.pastebin.com/m2235d7fb


 OS: FreeBSD 7.2
 clojure 1.1
 java -version
 java version 1.6.0_07
 Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
 Diablo Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)

 locale
 LANG=en_US.UTF-8
 LC_CTYPE=en_US.UTF-8
 LC_COLLATE=en_US.UTF-8
 LC_TIME=en_US.UTF-8
 LC_NUMERIC=en_US.UTF-8
 LC_MONETARY=en_US.UTF-8
 LC_MESSAGES=en_US.UTF-8
 LC_ALL=en_US.UTF-8

 java clojure.main
 user=  éőó
 java.lang.Exception: Unable to resolve symbol: ó�éőó in this context
 (NO_SOURCE_FILE:0)
 user=  éőó
 éőó
 user=  (println éőó)
 éőó
 nil
 user=  (def éőó 0)
 java.lang.Exception: Unable to resolve symbol: �0 in this context
 (NO_SOURCE_FILE:6)
 user=

 better but still not bulletproof

 testing also the same script like on windows
 java clojure.main unicode-test.clj
 ( sfd)

 No errors :) but of course it did not split the way I wanted...


 Anyone having better results with unicode and encoding? Preferably on
 windows.


 Thank you in advance
 Lukas





 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en






 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en




-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Cond, and abusing or

2010-01-15 Thread Simon Brooke
There's an old programmers hack that works in many languages of
abusing the logical or operator to try a sequence of operations until
one returns something useful. It appears that this works in Clojure,
too.

The reason I tried it is that I'm unhappy with Clojure's
implementation of cond. Consider the following interaction:

You are in a shed.
There is a box here
There is a knife here
= open the box
You open the box.
There is a knife in the box
= Take the knife out of the box
You take the knife out of the box

Now, consider a recursive repertoire structure in which each element
is a tuple {token, before-action, sub-repertoire, after-action} a
subset of which is like this

((take
 ()
 ((the
(bind-target-and-continue player (cdr line) (caddr
repertoire) context)
((out () () (take-from-container player (cdr line)
(caddr repertoire) context))
))
(take-from-environment player (cdr line) (caddr repertoire)
context)))

The action parts may internally recurse into the interpreter; so for
example bind-target-and-continue puts the token that follows the
into the context as the target and then re-enters the interpreter with
the remainder of the line and the sub-repertoire

So given 'take the knife out of the box'

== at take there is no before action, so we interpret the sub-
repertoire
 at the there is a before action, so we bind knife as target,
and interpret the rest of the line with the sub-repertoire
== at out there is no before-action or sub-repertoire, so we
evaluate the after-action which tells us to treat what's left of the
line (of the box) as a container specifier, locate a container that
matches that description in the environment, and take the knife out of
it, rather than the knife in the environment

But given just 'take the knife'

== at take there is no before action, so we interpret the sub-
repertoire
 at the there is a before action, so we bind knife as target,
and interpret the rest of the line with the sub-repertoire
 but there is no rest-of-line, so interpreting it returns null
== so we interpret the post action on take, and take the knife from
the environment, not the one in the box.

You can build up remarkably convincing interpreters for a subset of
imperative English with this and a few Eliza style tricks. In portable
standard lisp one would write

(cond
  ((eval before-action))
  ((interpret player sub-repertoire context))
  ((eval after-action)))

This is because each clause of the cond statement was an implicit do
list, so

(let ((a 'foo)(b nil))
  (cond
(a)
(b)))

= foo

Each of a and b are evaluated at most once (as a has a non-nil binding
in this case b is not evaluated at all).

To achieve this with Clojure's cond I have to do either

(let [a 'foo b nil]
  (cond
a a
b b))

= foo

in which case a is evaluated twice; or

(let [a 'foo b nil]
  (let [value-of-a a value-of-b b]
(cond
  (not (= nil value-of-a))
  value-of-a
  (not (= nil value-of-b))
  value-of-b)))

= foo

which only evaluates a once but it always evaluates b whether it needs
to or not, /and/ it's fugly and hard to read, /and/ it's very likely
inefficient (but someone more fluent in Clojure could probably replace
my (not (= nil thing)) with something cleaner); or else

(let [a 'foo b nil]
  (or a b))

= foo

which is simple and easy to read, but is exploiting the left-to-right
evaluation strategy of the or operator. It isn't (or ought not to need
to be) part of the contract of the or operator that it evaluates left
to right. On a massively parallel machine, all branches of the or
might be explored simultaneously. So this sort of hack leaves me
feeling dirty.

Comments?

Is there (once again) something more elegant I've missed?
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Cond, and abusing or

2010-01-15 Thread Rich Hickey


On Jan 15, 5:02 pm, Simon Brooke still...@googlemail.com wrote:
 There's an old programmers hack that works in many languages of
 abusing the logical or operator to try a sequence of operations until
 one returns something useful. It appears that this works in Clojure,
 too.

 The reason I tried it is that I'm unhappy with Clojure's
 implementation of cond. Consider the following interaction:

 You are in a shed.
     There is a box here
     There is a knife here
 = open the box
 You open the box.
     There is a knife in the box
 = Take the knife out of the box
 You take the knife out of the box

 Now, consider a recursive repertoire structure in which each element
 is a tuple {token, before-action, sub-repertoire, after-action} a
 subset of which is like this

     ((take
          ()
          ((the
             (bind-target-and-continue player (cdr line) (caddr
 repertoire) context)
             ((out () () (take-from-container player (cdr line)
 (caddr repertoire) context))
             ))
         (take-from-environment player (cdr line) (caddr repertoire)
 context)))

 The action parts may internally recurse into the interpreter; so for
 example bind-target-and-continue puts the token that follows the
 into the context as the target and then re-enters the interpreter with
 the remainder of the line and the sub-repertoire

 So given 'take the knife out of the box'

 == at take there is no before action, so we interpret the sub-
 repertoire
  at the there is a before action, so we bind knife as target,
 and interpret the rest of the line with the sub-repertoire
 == at out there is no before-action or sub-repertoire, so we
 evaluate the after-action which tells us to treat what's left of the
 line (of the box) as a container specifier, locate a container that
 matches that description in the environment, and take the knife out of
 it, rather than the knife in the environment

 But given just 'take the knife'

 == at take there is no before action, so we interpret the sub-
 repertoire
  at the there is a before action, so we bind knife as target,
 and interpret the rest of the line with the sub-repertoire
  but there is no rest-of-line, so interpreting it returns null
 == so we interpret the post action on take, and take the knife from
 the environment, not the one in the box.

 You can build up remarkably convincing interpreters for a subset of
 imperative English with this and a few Eliza style tricks. In portable
 standard lisp one would write

     (cond
       ((eval before-action))
       ((interpret player sub-repertoire context))
       ((eval after-action)))

 This is because each clause of the cond statement was an implicit do
 list, so

     (let ((a 'foo)(b nil))
       (cond
         (a)
         (b)))

 = foo

 Each of a and b are evaluated at most once (as a has a non-nil binding
 in this case b is not evaluated at all).

 To achieve this with Clojure's cond I have to do either

     (let [a 'foo b nil]
       (cond
         a a
         b b))

 = foo

 in which case a is evaluated twice; or

     (let [a 'foo b nil]
       (let [value-of-a a value-of-b b]
         (cond
           (not (= nil value-of-a))
           value-of-a
           (not (= nil value-of-b))
           value-of-b)))

 = foo

 which only evaluates a once but it always evaluates b whether it needs
 to or not, /and/ it's fugly and hard to read, /and/ it's very likely
 inefficient (but someone more fluent in Clojure could probably replace
 my (not (= nil thing)) with something cleaner); or else

     (let [a 'foo b nil]
       (or a b))

 = foo

 which is simple and easy to read, but is exploiting the left-to-right
 evaluation strategy of the or operator. It isn't (or ought not to need
 to be) part of the contract of the or operator that it evaluates left
 to right. On a massively parallel machine, all branches of the or
 might be explored simultaneously. So this sort of hack leaves me
 feeling dirty.

 Comments?

 Is there (once again) something more elegant I've missed?

or has left-to-right and short-circuiting in its contract and will
never be executed in parallel (any parallel or would be a different
thing). The 'hack' is fine, and clean. As far as cond, as in many
areas, like 'let', Clojure opts out of the increased verbosity and
clutter of the additional grouping, admittedly losing the facility you
desire. It's a tradeoff I think serves the common case well.

Note that condp supports a ternary clause form that shovels the test
expr into the result expr (this more of a hack for your purposes):

(let [a 'foo b nil]
  (condp #(or %1 %2) nil
   a : identity
   b : identity))

= foo

There has been some talk of adding : to cond also.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 

Re: Cond, and abusing or

2010-01-15 Thread Scott Burson
On Jan 15, 2:02 pm, Simon Brooke still...@googlemail.com wrote:
 There's an old programmers hack that works in many languages of
 abusing the logical or operator to try a sequence of operations until
 one returns something useful. It appears that this works in Clojure,
 too.

Certainly, this is a very common idiom in Common Lisp and other older
dialects.  I guess there are a few people who don't like it, but a lot
of us do it routinely.  You'll even see stuff like

  (or (try-to-construct-a-foo)
   (error Couldn't construct a foo))

-- Scott
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

aot defprotocol for java interop?

2010-01-15 Thread Raoul Duke
hi,

anybody have a simple example of compiling a protocol + using it from
java? i'm not having luck getting anything working yet.

thanks.
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Funding Clojure 2010

2010-01-15 Thread Mark Derricutt
Paypal can be setup for reoccuring payments.  I know I do that with
DropBox - not sure how one sets that up thou...

-- 
Pull me down under...

On Fri, Jan 15, 2010 at 6:29 PM, Brian Goslinga
quickbasicg...@gmail.com wrote:
 I think it would be useful if there was some way to (mostly)
 automatically donate $10/month.
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en