Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Konrad Hinsen

On 26.02.2009, at 08:47, Jeff Valk wrote:

> String representation obviously uses :type now in a very particular  
> way. I'm not sure where this happens though. Can anyone shed some  
> light on the details?

print-method now dispatches on type, rather than class as it did  
before. There is no default implementation for print-method, so if  
you put something as :type that has no implementation of print- 
method, weird things will happen.

The fix is to provide a default implementation for print-method. Try  
executing this:

(defmethod print-method :default [o w] (print-method "failed" w))

before printing your object, and it should print "failed" without any  
exception. There should be a default in clojure.core, but I am not  
sure what it should best be. Should it print the object stripped of  
its metadata? Or a string indicating the problem? Or should it throw  
an exception?

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Konrad Hinsen

On 26.02.2009, at 01:51, Rich Hickey wrote:

> You raise interesting issues and I'd like to explore them further. I'm
> not sure the issues you have with type-tag-or-class dispatch are all
> that prohibitive. In any case, I've added a type function that returns
> the :type metadata or the class if none:

Thanks, that helps a lot! With a built-in universal dispatching  
function, most of my problems should be solved. Another useful  
function to have would be

(defn type-instance?
   "Evaluates x and tests if it is an instance of the type or class t.
Returns true or false"
   [t x]
   (identical? t (type x)))

for type-based dispatching inside a function.

> I'm not sure the mechanism you are using (actual Class types) allows
> for any more overloading - Class is a single slot too, after all.

True, but the number of classes is not limited. Java programmers can  
live with a single class hierarchy, so it can't be too bad. But  
Clojure's hierarchies are definitely more flexible.

> A bigger problem with the mechanism you've chosen is its dependence on
> some implementation details. I haven't promised, e.g. that every fn
> generates a unique class type.

I know, but as I said, my current implementation is just a proof of  
concept. It is not viable for production use for a variety of  
reasons. I was planning to replace it by something based on gen-class  
and proxy, but I will first try to get away with the new type function.

Konrad.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Laurent PETIT
2009/2/26 Konrad Hinsen 

>
> On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type function that returns
> > the :type metadata or the class if none:
>
> Thanks, that helps a lot! With a built-in universal dispatching
> function, most of my problems should be solved. Another useful
> function to have would be
>
> (defn type-instance?
>   "Evaluates x and tests if it is an instance of the type or class t.
>Returns true or false"
>   [t x]
>   (identical? t (type x)))
>
> for type-based dispatching inside a function.


or maybe generalize the existing 'instance? function to the above definition
?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



how to get concurrent - model design question

2009-02-26 Thread bOR_

Hi all.

First. For those who remember, I posted an individual-based model in
this group some time ago (eden.clj), and got some very helpful replies
on where I misunderstood clojure and did things the hard way. I wanted
to report that that model by now is written purely as nonblocking
agents, and is happily burning cpu cycles as it simulates the
evolution of our immune system :). thanks for that!

Second. I am updating an older model on Chlamydia prevalence in a
dynamic sexual contact network, and implemented it in clojure (http://
clojure.googlegroups.com/web/chlam-clean.clj), based on the model in
this paper (http://aje.oxfordjournals.org/cgi/content/abstract/
144/3/306). It isn't fully equivalent to the model in the paper yet
(for some reason, Chlamydia keeps going extinct), but that is
something I will puzzle over myself. I am however, still somewhat
fuzzy on what a good way is to get the model concurrent.

I tried replacing

(doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-host
pair-host breakup-host] i world]
   (e i

with

(doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-host
pair-host breakup-host] i world]
   (send-off (agent i) e)))

or

 (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-
host pair-host breakup-host] i world]
   (send-off (agent nil) (fn [_] (e i))

There doesn't seem to be any concurrency happening, and the whole
thing just slows down to not doing much at all. Anyone knows what I am
doing wrong?. Considering that I wrestled with this before in previous
posts in this group, I offer my apologies for not getting the correct
way of mixing agents and refs into my thick skull. (Luckily I have
grasped agents-only models, so there is hope :), but as I need refs in
this model, I'm again banging my head against the wall).



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront Assertion Failure

2009-02-26 Thread Itay Maman

Hi Onorio

RC1-147 requires the use of Clojure's latest snapshot (can be obtained
from the SVN).

-Itay



On Feb 26, 4:21 am, Onorio Catenacci  wrote:
> Hi Itay (and everyone else),
>
> Every time I try to run Waterfront I keep running into the same
> error.  On line 83 of kit.clj the assertion fails.
>
> Version of Clojure: Revision: 1173
> I just pulled Waterfront from the SourceForge site. (RC1-147).  I
> didn't see the older version so I don't know if that makes a
> difference in this case or not.
> Windows XP SP2
>
> I have the same error with both JDK 1.6.0_03 and 1.6.0_12.
>
> If there's a bug tracking system for Waterfront I'll add this to the
> defect tracking system.  I can send along the wf.bat I'm using
> (modified to my paths of course) if it makes a difference.  When I
> initially saw this issue Clojure was sitting in a directory name with
> spaces (something like "My Documents\Desktop") so I moved it to a
> directory that should be fine under 8.3 and that didn't make a
> difference.
>
> --
> Onorio Catenacci
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Konrad Hinsen

On Feb 26, 2009, at 1:51, Rich Hickey wrote:

> You raise interesting issues and I'd like to explore them further. I'm
> not sure the issues you have with type-tag-or-class dispatch are all
> that prohibitive. In any case, I've added a type function that returns
> the :type metadata or the class if none:
>
> user=> (type #^{:type ::Fred} [1 2 3])
> :user/Fred
>
> user=> (type "foo")
> java.lang.String
>
> which should help people standardize.

One inconvenience I noticed with types based on meta-data tags is  
that the type information does not participate in equality tests.  
This means I have to include the type information once again in the  
value itself if I want to make sure that no other type's value  
accidentally compare as identical to mine.

> If you want to multiplex multimethods for your ADT type, you can just
> define a single :type ::ADT, and then sub-dispatch on e.g. :adt-type.

That's not even necessary: I add a derive clause from ::adt to each  
of my data types and implement multimethods such as print-method  
for ::adt.

Konrad.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Syntax-quote only as a reader macro?

2009-02-26 Thread Konrad Hinsen

I am trying to do the equivalent of a syntax-quote (converting  
unqualified symbols to namespace-qualified symbols) inside a macro,  
but it seems there is no built-in function to do this. Am I  
overlooking something?

At the moment I am using the following function, which does a syntax- 
quote for a single symbol:

(defn symbol-in-current-ns
   [s]
   (symbol (str *ns*) (str s)))

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront - The Clojure-based editor for Clojure

2009-02-26 Thread Itay Maman



On Feb 26, 3:02 am, "Stephen C. Gilardi"  wrote:
> On Feb 24, 2009, at 6:47 PM, Itay Maman wrote:
>
> > This version is fully functional and so far I didn't encounter any
> > bugs.
> > I guess that over the course of the next few days, as people start
> > using this version,
> > a few issues may come up. I'd be glad to fix these.
>
> > I also took Mike's suggestion, Waterfromt's main window is now using
> > a side-by-side layout.
>
> Hi Itay,
>
> Very nice work on waterfront! I gave it a try on Mac OS X. It worked  
> well and showcases many cool ideas.
>
> I had a couple of issues:
>
> - when building on Mac OS X with Java 6 64-bit or Java 5 32-bit, I got  
> errors like this one:
>
>      [javac] Compiling 1 source file to /sq/ext/waterfront/waterfront/
> bin
>      [javac] /sq/ext/waterfront/lab/src/net/sourceforge/waterfront/ide/
> services/Main.java:92: method does not override a method from its  
> superclass
>      [javac]     @Override
>      [javac]      ^
>      [javac] 1 error
>
> in every case where @Override was present in the waterfront source.

In Java6 @Override can also be attached to a method that overrides an
interface-declared method. So, the code is not supposed to compile w/
a Java5 compiler. As for the Java6 compiler, my guess is that your
compile is configured to be Java5 complaint. So I would suggest to
specify "-source 1.6" in the javac command line. Anyway, I will add it
to the build.xml file.


>
> I was able to build successfully by commenting all of them out.
>
> - When using waterfront on Mac OS X, it appears that the control  
> characters intended to trigger menu selections (e.g. ^E) are being  
> intercepted before they reach the menus. In the specific case of ^E,  
> it is being interpreted by the text input field as "move to end of  
> line" which is a common meaning for it in Mac OS X. I suspect there is  
> a way to trigger menu items using the "command-key" on the Mac (while  
> still using the control key on Windows) and people using waterfront on  
> Mac OS X would benefit from a change to using that mechanism.

Sure.

>
> Thanks very much for waterfront!


You're very welcome.
>
> --Steve
>
>  smime.p7s
> 3KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront - The Clojure-based editor for Clojure

2009-02-26 Thread Konrad Hinsen

On Feb 26, 2009, at 12:30, Itay Maman wrote:

> In Java6 @Override can also be attached to a method that overrides an
> interface-declared method. So, the code is not supposed to compile w/
> a Java5 compiler. As for the Java6 compiler, my guess is that your
> compile is configured to be Java5 complaint. So I would suggest to
> specify "-source 1.6" in the javac command line. Anyway, I will add it
> to the build.xml file.

Do you need Java 1.6 features? Clojure itself works fine with 1.5,  
and there are still machines around for which there is no 1.6 (my PPC  
Mac running MacOS 10.4, for example), so it would be nice if  
Waterfront could work with Java 1.5 as well.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: how to get concurrent - model design question

2009-02-26 Thread Timothy Pratley

Hi Boris,

>  (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-
> host pair-host breakup-host] i world]
>            (send-off (agent nil) (fn [_] (e i))
>
> There doesn't seem to be any concurrency happening, and the whole
> thing just slows down to not doing much at all.

This code will create potentially (count world) threads 1. Just
using send instead of send-off would possibly speed things up a lot as
it will limit the number of threads. Also creating a new agent every
time just to provide a thread is not economical. You could instead
have a small pool of agents and reuse them. Or you could take
advantage of futures which have been recently added to run the task
without an agent at all:
(doseq [e [r s i n b] i world] (future (e i)))
Also you might consider using (comp) to compose the set of e into one
function, which will reduce the amount of dispatches. Lastly, why do
you say you have to use refs here? It isn't obvious to me from the
code - the world locations look like they could be agents - but I'm
probably missing something, its quite complex :)

Regards,
Tim.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Syntax-quote only as a reader macro?

2009-02-26 Thread Konrad Hinsen

On Feb 26, 2009, at 12:26, Konrad Hinsen wrote:

> At the moment I am using the following function, which does a syntax-
> quote for a single symbol:
>
> (defn symbol-in-current-ns
>[s]
>(symbol (str *ns*) (str s)))

Of course that should better be

(defn qualified-symbol
   [s]
   (let [s-str (str s)]
 (if (.contains s-str "/")
   s
   (symbol (str *ns*) s-str

so that it doesn't mess up already qualified symbols.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront Assertion Failure

2009-02-26 Thread Onorio Catenacci

On Feb 26, 6:10 am, Itay Maman  wrote:
> Hi Onorio
>
> RC1-147 requires the use of Clojure's latest snapshot (can be obtained
> from the SVN).
>

I figured that was probably the case but I thought you might want to
know about the assertion failure in case it were some other issue.

--
Onorio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Rich Hickey



On Feb 26, 4:00 am, Konrad Hinsen  wrote:
> On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type function that returns
> > the :type metadata or the class if none:
>
> Thanks, that helps a lot! With a built-in universal dispatching
> function, most of my problems should be solved. Another useful
> function to have would be
>
> (defn type-instance?
>"Evaluates x and tests if it is an instance of the type or class t.
> Returns true or false"
>[t x]
>(identical? t (type x)))
>
> for type-based dispatching inside a function.
>

I'm pretty sure you'd want that to use isa?

Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Rich Hickey



On Feb 26, 4:17 am, Laurent PETIT  wrote:
> 2009/2/26 Konrad Hinsen 
>
>
>
>
>
> > On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > > You raise interesting issues and I'd like to explore them further. I'm
> > > not sure the issues you have with type-tag-or-class dispatch are all
> > > that prohibitive. In any case, I've added a type function that returns
> > > the :type metadata or the class if none:
>
> > Thanks, that helps a lot! With a built-in universal dispatching
> > function, most of my problems should be solved. Another useful
> > function to have would be
>
> > (defn type-instance?
> >   "Evaluates x and tests if it is an instance of the type or class t.
> >Returns true or false"
> >   [t x]
> >   (identical? t (type x)))
>
> > for type-based dispatching inside a function.
>
> or maybe generalize the existing 'instance? function to the above definition
> ?

I'm not sure I'd want to do that. You'd still need actual class
detectors.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront - The Clojure-based editor for Clojure

2009-02-26 Thread Timothy Pratley

super slick, I love it!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Rich Hickey



On Feb 26, 6:19 am, Konrad Hinsen  wrote:
> On Feb 26, 2009, at 1:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type function that returns
> > the :type metadata or the class if none:
>
> > user=> (type #^{:type ::Fred} [1 2 3])
> > :user/Fred
>
> > user=> (type "foo")
> > java.lang.String
>
> > which should help people standardize.
>
> One inconvenience I noticed with types based on meta-data tags is
> that the type information does not participate in equality tests.
> This means I have to include the type information once again in the
> value itself if I want to make sure that no other type's value
> accidentally compare as identical to mine.
>

Well, you have to do something (type in value, or override equals) but
I can't hardwire the relationship between type and equality,
especially not as an identity compare. There is no general solution,
else equals() wouldn't be overridable. Polymorphic equality is an
important capability, e.g. so sets and maps with different
implementations can interoperate.

> > If you want to multiplex multimethods for your ADT type, you can just
> > define a single :type ::ADT, and then sub-dispatch on e.g. :adt-type.
>
> That's not even necessary: I add a derive clause from ::adt to each
> of my data types and implement multimethods such as print-method
> for ::adt.
>

I know, just noting sub-dispatching is possible.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Is syntax quote "reader" only?

2009-02-26 Thread Chouser

On Mon, Feb 16, 2009 at 8:31 PM, Brian Will  wrote:
>
> I'm a bit mystified how syntax quote does what it does. I don't see
> how syntax quote can quote the whole while unquoting parts without
> some evaluation-time intervention. If I had to implement it myself,
> I'd just punt the problem to evaluation-time by introducing a special
> form 'unquote', e.g.:
>
>  `(a b ~(c d))
>
>  (quote ((unquote a) 3 (unquote (c d)))
>
> But this isn't what Clojure does, so I'm wondering, how does syntax
> quote do its business while remaining strictly a reader-time only
> mechanism?

Use the source, Luke.

http://code.google.com/p/clojure/source/browse/trunk/src/jvm/clojure/lang/LispReader.java?r=1287#656

It looks like the reader reads the whole syntax-quoted form, and then
walks it recursively looking for unquote forms.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront Assertion Failure

2009-02-26 Thread Itay Maman



On Feb 26, 2:11 pm, Onorio Catenacci  wrote:
> On Feb 26, 6:10 am, Itay Maman  wrote:
>
> > Hi Onorio
>
> > RC1-147 requires the use of Clojure's latest snapshot (can be obtained
> > from the SVN).
>
> I figured that was probably the case but I thought you might want to
> know about the assertion failure in case it were some other issue.

OK, I see your point now.

-Itay

>
> --
> Onorio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront - The Clojure-based editor for Clojure

2009-02-26 Thread Itay Maman



On Feb 26, 2:02 pm, Konrad Hinsen  wrote:
> On Feb 26, 2009, at 12:30, Itay Maman wrote:
>
> > In Java6 @Override can also be attached to a method that overrides an
> > interface-declared method. So, the code is not supposed to compile w/
> > a Java5 compiler. As for the Java6 compiler, my guess is that your
> > compile is configured to be Java5 complaint. So I would suggest to
> > specify "-source 1.6" in the javac command line. Anyway, I will add it
> > to the build.xml file.
>
> Do you need Java 1.6 features? Clojure itself works fine with 1.5,  
> and there are still machines around for which there is no 1.6 (my PPC  
> Mac running MacOS 10.4, for example), so it would be nice if  
> Waterfront could work with Java 1.5 as well.

No I don't need Java6. My Eclipse is configured to be Java6-compliant
so it generates
these @Overrides annotations automatically. I agree with your point.
I'll get rid of those.

Coming to think about it, I don't even need the Java code so much. It
is just a few classes
which realize some low-level UI stuff which seemed to be more natural
in Java than in Clojure.
I do want to translate them to Clojure at some point. This will solve
this issue altogether.

-Itay

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: how to get concurrent - model design question

2009-02-26 Thread bOR_

Thanks for the reply Timothy! I'll look into the future things :).

The main reason for using refs was because I am constructing a contact
network between different refs (a graph, consisting of nodes and
edges.), which changes over time (all the short-term and long-term
relations between hosts being started and breaking down again). If two
of my refs start a steady relation together, I want a guarantee that
one refers to the other in its :steady key, and the other refers to
the one. So it seemed to me that both have to change simultaneously. I
don't want host 1 to start initiating a steady relationship with host
2, while at the same time host 2 is  starting one with host 3. I wrote
an earlier version of this model with agents, but couldn't see how to
guarantee bidirectional edges in a concurrent situation.

On Feb 26, 12:59 pm, Timothy Pratley  wrote:
> Hi Boris,
>
> >  (doseq [e [retire-host slowdown-host infect-hosts naturalrecovery-
> > host pair-host breakup-host] i world]
> >            (send-off (agent nil) (fn [_] (e i))
>
> > There doesn't seem to be any concurrency happening, and the whole
> > thing just slows down to not doing much at all.
>
> This code will create potentially (count world) threads 1. Just
> using send instead of send-off would possibly speed things up a lot as
> it will limit the number of threads. Also creating a new agent every
> time just to provide a thread is not economical. You could instead
> have a small pool of agents and reuse them. Or you could take
> advantage of futures which have been recently added to run the task
> without an agent at all:
> (doseq [e [r s i n b] i world] (future (e i)))
> Also you might consider using (comp) to compose the set of e into one
> function, which will reduce the amount of dispatches. Lastly, why do
> you say you have to use refs here? It isn't obvious to me from the
> code - the world locations look like they could be agents - but I'm
> probably missing something, its quite complex :)
>
> Regards,
> Tim.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: new laziness: terminology help

2009-02-26 Thread Rich Hickey



On Feb 25, 8:02 pm, Mark Engelberg  wrote:
> On Wed, Feb 25, 2009 at 6:59 AM, Stuart Halloway
>
> > I believe it would be simpler to leave out this footnote. In my
> > perfect world, seq/ISeq/sequence are synonyms, and nillability is a
> > property only of *functions*: seq and next.
>
> I understand why it is useful to use the noun "seq" to mean the forced
> non-nil non-empty sequences that are returned by the seq function.
> But I think it's going to be very confusing if you use the term seq to
> mean something different than what "seq?" tests for.  So I'd vote for
> either Stuart's interpretation, or changing the name "seq?" to
> something like "sequence?" (which I think it was at one stage of
> development).

I'm fine with Stuart's interpretation. People need to resist their
urge to superimpose types that don't exist on the return values of
functions. There is only ISeq. And some function might return one or
not.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront - The Clojure-based editor for Clojure

2009-02-26 Thread Laurent PETIT
2009/2/26 Itay Maman 

>
>
>
> On Feb 26, 2:02 pm, Konrad Hinsen  wrote:
> > On Feb 26, 2009, at 12:30, Itay Maman wrote:
> >
> > > In Java6 @Override can also be attached to a method that overrides an
> > > interface-declared method. So, the code is not supposed to compile w/
> > > a Java5 compiler. As for the Java6 compiler, my guess is that your
> > > compile is configured to be Java5 complaint. So I would suggest to
> > > specify "-source 1.6" in the javac command line. Anyway, I will add it
> > > to the build.xml file.
> >
> > Do you need Java 1.6 features? Clojure itself works fine with 1.5,
> > and there are still machines around for which there is no 1.6 (my PPC
> > Mac running MacOS 10.4, for example), so it would be nice if
> > Waterfront could work with Java 1.5 as well.
>
> No I don't need Java6. My Eclipse is configured to be Java6-compliant
> so it generates


What ? You used Eclipse, and still wanted to get rid of it and of clojuredev
! How sad I am ... ;-)

I've taken a look at what you've done, wow !

How long did it take to realize that ? Were you working on it daily, or
nightly ?

Keep up the good work !

-- 
Laurent



>
> these @Overrides annotations automatically. I agree with your point.
> I'll get rid of those.
>
> Coming to think about it, I don't even need the Java code so much. It
> is just a few classes
> which realize some low-level UI stuff which seemed to be more natural
> in Java than in Clojure.
> I do want to translate them to Clojure at some point. This will solve
> this issue altogether.
>
> -Itay
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Laurent PETIT
2009/2/26 Rich Hickey 

>
>
>
> On Feb 26, 4:17 am, Laurent PETIT  wrote:
> > 2009/2/26 Konrad Hinsen 
> >
> >
> >
> >
> >
> > > On 26.02.2009, at 01:51, Rich Hickey wrote:
> >
> > > > You raise interesting issues and I'd like to explore them further.
> I'm
> > > > not sure the issues you have with type-tag-or-class dispatch are all
> > > > that prohibitive. In any case, I've added a type function that
> returns
> > > > the :type metadata or the class if none:
> >
> > > Thanks, that helps a lot! With a built-in universal dispatching
> > > function, most of my problems should be solved. Another useful
> > > function to have would be
> >
> > > (defn type-instance?
> > >   "Evaluates x and tests if it is an instance of the type or class t.
> > >Returns true or false"
> > >   [t x]
> > >   (identical? t (type x)))
> >
> > > for type-based dispatching inside a function.
> >
> > or maybe generalize the existing 'instance? function to the above
> definition
> > ?
>
> I'm not sure I'd want to do that. You'd still need actual class
> detectors.


But the definition and implementation of the above 'type-instance? function
works for classes, and I don't think the point of the current instance? is
to check that the given class parameter is a real class or not ? It is
checking the type of the instance passed to it ?

Or am I missing something ?



>
>
> Rich
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: The Sequential interface (implementation question)

2009-02-26 Thread Rich Hickey



On Feb 26, 12:00 am, dmiller  wrote:
> Regarding the Sequential interface:
>
> There are a number of places where  (x instanceof Sequential) is taken
> to imply something else about x:
>
>  (a) that casting in the form of ((IPersistentCollection)x)  is okay,
> or
>  (b) that RT.seq(x) will succeed, or
>  (c) that Rt.count(x) will succeed
>
> Note that (a) implies (b) and (c).
>
> In arbitrary code, these conclusions do not necessarily follow.
>
> Occurrences (same in both pre- and post-lazy change codebases)
>
> Type (a):
>
> APersistentVector.doEquals
> APersistentVector.doEquiv
> PersistentQueue.equals
> PersistentQueue.equiv
> RT.nth
>
> Type (b):
>
> ASeq.equals
> ASeq.equiv
>
> Type (c):
>
> PersistentList.EmptyList.equals
>
> Sample code:  PersistentQueue.equals:
>
> public boolean equals(Object obj){
>
> if(!(obj instanceof Sequential))
> return false;
> ISeq ms = ((IPersistentCollection) obj).seq();
> ...
>
> }
>
> Sample code:  ASeq.equiv:
>
> public boolean equiv(Object obj){
>
> if(!(obj instanceof Sequential || obj instanceof List))
> return false;
> ISeq ms = RT.seq(obj);
> ...
>
> The following interfaces extend Sequential:  IPersistentList,
> IPersistentVector, ISeq
>
> In core.clj, Sequential is used only in the definition of (sequential?
> x).
>
> Why does Sequential exist at all?  Why not just use
> IPersistentCollection?
> Are the listed interfaces the only ones intended to extend Sequential?
> Is there an implicit charge to anyone extending/implementing
> Sequential to guarantee (a), (b), (c)?
>
> Put another way, is there any meaning to being Sequential but not
> IPersistentCollection?
>

Sequential is a marker interface. It doesn't imply the success of
casts that follow it, they are independent tests. Sequential is used
to help partition the collections space for equality purposes, so
sequentials/sets/maps are never equal to things outside of their
'category'. Sequential unifies vectors/lists/seqs.

Chouser did a great graph:

http://github.com/Chouser/clojure-classes/raw/master/graph-w-legend.png

Rich


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Laurent PETIT
Would it make sense to make instance?/type-instance?/type .. multimethods
themselves ?

2009/2/26 Konrad Hinsen 

>
> On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type function that returns
> > the :type metadata or the class if none:
>
> Thanks, that helps a lot! With a built-in universal dispatching
> function, most of my problems should be solved. Another useful
> function to have would be
>
> (defn type-instance?
>   "Evaluates x and tests if it is an instance of the type or class t.
>Returns true or false"
>   [t x]
>   (identical? t (type x)))
>
> for type-based dispatching inside a function.
>
> > I'm not sure the mechanism you are using (actual Class types) allows
> > for any more overloading - Class is a single slot too, after all.
>
> True, but the number of classes is not limited. Java programmers can
> live with a single class hierarchy, so it can't be too bad. But
> Clojure's hierarchies are definitely more flexible.
>
> > A bigger problem with the mechanism you've chosen is its dependence on
> > some implementation details. I haven't promised, e.g. that every fn
> > generates a unique class type.
>
> I know, but as I said, my current implementation is just a proof of
> concept. It is not viable for production use for a variety of
> reasons. I was planning to replace it by something based on gen-class
> and proxy, but I will first try to get away with the new type function.
>
> Konrad.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Rich Hickey



On Feb 26, 8:30 am, Laurent PETIT  wrote:
> 2009/2/26 Rich Hickey 
>
>
>
>
>
> > On Feb 26, 4:17 am, Laurent PETIT  wrote:
> > > 2009/2/26 Konrad Hinsen 
>
> > > > On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > > > > You raise interesting issues and I'd like to explore them further.
> > I'm
> > > > > not sure the issues you have with type-tag-or-class dispatch are all
> > > > > that prohibitive. In any case, I've added a type function that
> > returns
> > > > > the :type metadata or the class if none:
>
> > > > Thanks, that helps a lot! With a built-in universal dispatching
> > > > function, most of my problems should be solved. Another useful
> > > > function to have would be
>
> > > > (defn type-instance?
> > > >   "Evaluates x and tests if it is an instance of the type or class t.
> > > >Returns true or false"
> > > >   [t x]
> > > >   (identical? t (type x)))
>
> > > > for type-based dispatching inside a function.
>
> > > or maybe generalize the existing 'instance? function to the above
> > definition
> > > ?
>
> > I'm not sure I'd want to do that. You'd still need actual class
> > detectors.
>
> But the definition and implementation of the above 'type-instance? function
> works for classes, and I don't think the point of the current instance? is
> to check that the given class parameter is a real class or not ? It is
> checking the type of the instance passed to it ?
>
> Or am I missing something ?
>

The definition above is definitely broken in using identical?

I'll think about extending instance? to use type + isa?

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mini-Kanren

2009-02-26 Thread Michel S.

Hi Jim,

On Feb 25, 6:38 pm, jim  wrote:
> I've just uploaded a file that has the Mini-Kanren logic programming
> system described in "The Reasoned Schemer" implemented in idiomatic
> Clojure.  The file is:
>
> http://clojure.googlegroups.com/web/mini_kanren.clj
>
I'm still reading my way through it, but so far, this caught my eye:

"In Scheme, passing cons one parameter encloses that parameter in a
list, essentially cons'ing it to an empty list"

As far as I know, no Scheme implementation does that. a cons is
strictly a pair of two things, where the idiomatic usage is that the
second thing is either another cons or the empty list, thus forming a
proper list, versus a list terminated by a dotted pair, which is an
improper list.

(list x), in both Scheme and Clojure, produces a list with one item in
it.

Regards,

--
Michel S.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



function call preconditions

2009-02-26 Thread Laurent PETIT
Hello,

While not checking types at compile time, it seems to me that a lot of
clojure code still needs in the docstring some sort of "preconditions
warnings".
For example, that you can't pass a first argument if it cannot be callable
as a function, or if it cannot succeed the (seq) test ...

Couldn't it be great if such a knowledge wasn't captured in the doc string,
but in something that could be more useful (optionally of course, for
performance purposes) : some sort of optional precondition part of the
function/macro definition. Of course, this would then be written in clojure
itself.

This information could then be :
 * added at the beginning or end of the docstring (or put in another
docstring) at compilation time
 * added as an optional precondition check each time the function is called
(activable globally via some global var that could be named
*check-preconditions* for example)

Indeed, I guess it's easier to fail quickly when something goes wrong, but
if the argument is passed over some other function, and used later in some
agent, or deeper in the code, I guess it is sometimes hard to identify where
things started to go wrong (or maybe it is not such a problem with clojure
?)


I feel sorry to see and place in the docstrings structured information that
could be (optionally, of course) expressed in a more structured format ...


What do you think about that ?

Regards,

-- 
Laurent

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Laurent PETIT
2009/2/26 Rich Hickey 

>
>
>
> On Feb 26, 8:30 am, Laurent PETIT  wrote:
> > 2009/2/26 Rich Hickey 
> >
> >
> >
> >
> >
> > > On Feb 26, 4:17 am, Laurent PETIT  wrote:
> > > > 2009/2/26 Konrad Hinsen 
> >
> > > > > On 26.02.2009, at 01:51, Rich Hickey wrote:
> >
> > > > > > You raise interesting issues and I'd like to explore them
> further.
> > > I'm
> > > > > > not sure the issues you have with type-tag-or-class dispatch are
> all
> > > > > > that prohibitive. In any case, I've added a type function that
> > > returns
> > > > > > the :type metadata or the class if none:
> >
> > > > > Thanks, that helps a lot! With a built-in universal dispatching
> > > > > function, most of my problems should be solved. Another useful
> > > > > function to have would be
> >
> > > > > (defn type-instance?
> > > > >   "Evaluates x and tests if it is an instance of the type or class
> t.
> > > > >Returns true or false"
> > > > >   [t x]
> > > > >   (identical? t (type x)))
> >
> > > > > for type-based dispatching inside a function.
> >
> > > > or maybe generalize the existing 'instance? function to the above
> > > definition
> > > > ?
> >
> > > I'm not sure I'd want to do that. You'd still need actual class
> > > detectors.
> >
> > But the definition and implementation of the above 'type-instance?
> function
> > works for classes, and I don't think the point of the current instance?
> is
> > to check that the given class parameter is a real class or not ? It is
> > checking the type of the instance passed to it ?
> >
> > Or am I missing something ?
> >
>
> The definition above is definitely broken in using identical?
>
> I'll think about extending instance? to use type + isa?


Yes, I agree. I hadn't realized the above definition was broken, and was
speaking about its purpose that I indeed thought could be integrated in
instance? without breaking instance? semantics nor existing code.

-- 
Laurent


>
>
> Rich
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Extensive use of let?

2009-02-26 Thread Luke VanderHart

Very interesting ideas, everyone... thanks a lot for the input.

Yeah, I recognize that each case is going to be different - I guess I
was just looking for suggestions on how to manage it. Which I found...
Comp and partial look particularly interesting. Thanks!

-Luke

On Feb 25, 5:09 pm, Kevin Downey  wrote:
> You should look at "->"
> it lest you take (op3 (op2 (op1 input))) and write it as (-> input op1 op2 
> op3)
> there is also "comp" which composes functions, and partial for partial
> application.
>
> some example comp 
> usage:http://github.com/hiredman/clojurebot/blob/297e266b0badf0f301a556e957...
>
>
>
>
>
> On Wed, Feb 25, 2009 at 12:57 PM, levand  wrote:
>
> > Recently, in my code, I have been struggling with which of the two
> > equivalent forms is, in a general sense, "better".
>
> > (defn my-fn1 [input]
> >  (let [value1 (op1 input)
> >        value2 (op2 input)
> >        value3 (op4 value1 value2)]
> >    (op5 value3)))
>
> > (defn my-fn2 [input]
> >  (op5 (op4 (op1 input) (op2 input
>
> > Now, the second is definitely cleaner and more elegant, besides being
> > smaller, which is a non-trivial benefit when I have a fair amount of
> > code to page through.
>
> > However, if I've been away from the code awhile, it's much easier to
> > come back determine what the code is doing when its written the first
> > way, especially when it uses descriptive names. An operation that is
> > impenetrable when written in nested form can become quite simple when
> > each step is broken down and labeled.
>
> > Clojure is my first Lisp - should I just stick with the second form
> > until I learn to "see through" the nested s-expressions?
>
> > It's not that I'm trying to make my code more imperative - Although I
> > come from a Java background, I love functional programming, and it is
> > a delight to see how much I can do without side-effects. But I do miss
> > the self-documentation that well-named variables can provide.
>
> > Any thoughts? Also, is there any performance degradation from the
> > first way, or can the compiler optimize it away?
>
> --
> 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
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 plugin for IntelliJ IDEA published

2009-02-26 Thread Ilya Sergey

Hello.

Simplest way to run empty REPL is to create empty Clojure script and
invoke new run configuration on it (marking appropriate checkbox in
configuration settings). In next version we're going to integrate
support for background REPL, but for now we have no, so there is no
possibility to load some file or Sexpr from editor by keyboard
shortcut. You should restart script or paste Sexpr to REPL console
manually.
So, a support for this feature is a min priority for now. As for
parentheses, what kind of support do you mean? We're going to
implement so-called "surround with" feature, to help simply surround
selected code fragment with parentheses. for now you can use Ctrl-W
shortcut to select nested forms incrementally in editor.

With best regards,
Ilya Sergey


On Feb 26, 7:48 am, CuppoJava  wrote:
> Hi Ilya,
> I also just started using the plugin and it's very good. Thank you for
> this great plugin.
> I have a few questions about how to use it though:
>
> How to I start a REPL without loading a script? Just a blank slate
> REPL?
> Is there a shortcut for Sending current sexp, or selected text to
> REPL?
>
> May I ask what your upcoming priorities are for the project? I would
> love for a basic Paredit to be supported. Parenthesis are just too
> much trouble to maintain manually.
>
> Thanks again for the great work
>   -Patrick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront - The Clojure-based editor for Clojure

2009-02-26 Thread Itay Maman

>
> What ? You used Eclipse, and still wanted to get rid of it and of clojuredev
> ! How sad I am ... ;-)

:))

>
> I've taken a look at what you've done, wow !
>
> How long did it take to realize that ? Were you working on it daily, or
> nightly ?

I had a couple of weeks off at Dec. Since Jan. it is mostly night-
time.

>
> Keep up the good work !

Thanks.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Syntax-quote only as a reader macro?

2009-02-26 Thread Konrad Hinsen

On Feb 26, 2009, at 13:04, Konrad Hinsen wrote:

> Of course that should better be
...

>
> so that it doesn't mess up already qualified symbols.

And even that is not good enough: it won't handle symbols/vars from  
other namespaces that are referred to. And that's where I am lost. I  
can't find any way to obtain the qualified symbol that an unqualified  
one would resolve to. There are a couple of ways to get the var it  
refers to (for example ns-resolve), but I don't want the var, I want  
the symbol, for use in a macro.

I checked the compiler source code and found  
clojure.lang.Compiler.resolveSymbol, which does exactly what I need,  
but it's not public.

I figured out one way to do it, but it relies on features that are  
perhaps not safe to rely on: I get var first, and then I get the  
var's namespace from its public attribute ns:

(defn qualified-symbol
   [s]
   (if-let [var (resolve s)]
 (symbol (str (.ns var)) (str (.sym var)))
 s))

This seems to work fine for all cases I can imagine. But I'd love to  
see a cleaner way to do this.

Konrad.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mini-Kanren

2009-02-26 Thread jim

I don't have a Scheme here to check it out, but doesn't

(cons 1)

yield

'(1)

or am I wrong?

In either case how could it be stated more accurately/clearly?

Thanks
Jim

On Feb 26, 7:52 am, "Michel S."  wrote:
> Hi Jim,
>
> "In Scheme, passing cons one parameter encloses that parameter in a
> list, essentially cons'ing it to an empty list"
>
> As far as I know, no Scheme implementation does that. a cons is
> strictly a pair of two things, where the idiomatic usage is that the
> second thing is either another cons or the empty list, thus forming a
> proper list, versus a list terminated by a dotted pair, which is an
> improper list.
>
> (list x), in both Scheme and Clojure, produces a list with one item in
> it.
>
> Regards,
>
> --
> Michel S.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mini-Kanren

2009-02-26 Thread Pierpaolo Bernardi
On Thu, Feb 26, 2009 at 4:03 PM, jim  wrote:

>
> I don't have a Scheme here to check it out, but doesn't
>
> (cons 1)
>
> yield
>
> '(1)


no. in scheme (and in all modern lisps), cons is a 2 arguments procedure.
Giving it 1 is an error.

Some very old lisp dialects supplied NIL in place of missing arguments. In
these lisps
(cons 1) was equivalent to (cons 1 nil)

Cheers
P.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Clojure documentation problems

2009-02-26 Thread Chouser

On Wed, Feb 25, 2009 at 6:00 AM, David Sletten  wrote:
>
> Whoops...it's "rational?" that was missing from the API page and
> still is.

The API page is programmaticly generated from the docstrings, but like
the rest of the site generally reflects the latest release, not the
latest svn version.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mini-Kanren

2009-02-26 Thread jim

Looking at the code, lcons does indeed require two parms.  I must've
been zoned out when I wrote the comment.  Thanks for catching that.

On Feb 26, 9:10 am, Pierpaolo Bernardi  wrote:
> no. in scheme (and in all modern lisps), cons is a 2 arguments procedure.
> Giving it 1 is an error.
>
> Some very old lisp dialects supplied NIL in place of missing arguments. In
> these lisps
> (cons 1) was equivalent to (cons 1 nil)
>
> Cheers
> P.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Richer 'partial'

2009-02-26 Thread Anand Patil

Hi all,

I could use a version of 'partial' that would allow me to:

- Partially apply a function to any of its arguments, not just the
first one
- 'Unapply' a partially-applied function from one of its arguments.

Is any such thing already available?

Thanks,
Anand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Laurent PETIT
2009/2/26 Anand Patil 

>
> Hi all,
>
> I could use a version of 'partial' that would allow me to:
>
> - Partially apply a function to any of its arguments, not just the
> first one


That's already the case, haven't you made a little test ?


>
> - 'Unapply' a partially-applied function from one of its arguments.


Not possible as far as I know. Could you please explain use cases you have
in mind for such a feature ?


>
>
> Is any such thing already available?
>
> Thanks,
> Anand
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Jeffrey Straszheim
"partial" is a currying function.  It can be provided any number of
parameter(s), but it is always behaves sequentially from start to finish.
 That is what currying *is*.

You can easily partially apply to other arguments by doing this: #(fred %1
some-arg %2 other-arg).

"partial" could not easily support "unapplying" it.

On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil <
anand.prabhakar.pa...@gmail.com> wrote:

>
> Hi all,
>
> I could use a version of 'partial' that would allow me to:
>
> - Partially apply a function to any of its arguments, not just the
> first one
> - 'Unapply' a partially-applied function from one of its arguments.
>
> Is any such thing already available?
>
> Thanks,
> Anand
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



some vs. contains? for a list

2009-02-26 Thread Mark Volkmann

I thought for sure it would be faster to use "some" to determine
whether an item was in a list rather than convert the list to a set
and then use "contains?", but it turns out I was wrong. The latter
approach takes about 1/3 to 1/2 the time! This is the case even when
the list contains 100 items. Of course I realize that if this is a
commonly needed operation for a particular collection, it's better to
use a set instead of a list in the first place.

(def stooges (list "Moe" "Larry" "Curly"))
(time (some #(= % "Curly") stooges))
(time (contains? (set stooges) "Curly"))

-- 
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 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Laurent PETIT
2009/2/26 Jeffrey Straszheim 

> "partial" is a currying function.  It can be provided any number of
> parameter(s), but it is always behaves sequentially from start to finish.
>  That is what currying *is*.
>

Ah, I thought currying / uncurrying what the term reserved for this
operation (as I remember from Haskell) that changes the arity of functions (
transforming and untransforming a function of n parameters into a function
of a tuple of n elements) ?



>
> You can easily partially apply to other arguments by doing this: #(fred %1
> some-arg %2 other-arg).
>
> "partial" could not easily support "unapplying" it.
>
> On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil <
> anand.prabhakar.pa...@gmail.com> wrote:
>
>>
>> Hi all,
>>
>> I could use a version of 'partial' that would allow me to:
>>
>> - Partially apply a function to any of its arguments, not just the
>> first one
>> - 'Unapply' a partially-applied function from one of its arguments.
>>
>> Is any such thing already available?
>>
>> Thanks,
>> Anand
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



"Adding" strings

2009-02-26 Thread Peter Wolf

Hey all,

What is the idiomatic way to concatenate strings?  Here are some things 
that I expected to work, but didn't

(+ "foo" "bah")
(conj "foo" "bah")
(into "foo" "bah")

For the moment I am doing

(.concat "foo" "bah")

But it seems wrong

Thanks
P



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread Laurent PETIT
(str "foo" "bah")

and if you have a collection you can (apply str coll)

HTH,

-- 
Laurent

2009/2/26 Peter Wolf 

>
> Hey all,
>
> What is the idiomatic way to concatenate strings?  Here are some things
> that I expected to work, but didn't
>
>(+ "foo" "bah")
>(conj "foo" "bah")
>(into "foo" "bah")
>
> For the moment I am doing
>
>(.concat "foo" "bah")
>
> But it seems wrong
>
> Thanks
> P
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread pmf

On Feb 26, 5:11 pm, Peter Wolf  wrote:
> What is the idiomatic way to concatenate strings?  Here are some things
> that I expected to work, but didn't
>
>     (+ "foo" "bah")
>     (conj "foo" "bah")
>     (into "foo" "bah")
>
> For the moment I am doing
>
>     (.concat "foo" "bah")

(str "foo" "bah")

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread Shawn Hoover
On Thu, Feb 26, 2009 at 11:11 AM, Peter Wolf  wrote:

>
> Hey all,
>
> What is the idiomatic way to concatenate strings?  Here are some things
> that I expected to work, but didn't
>
>(+ "foo" "bah")
>(conj "foo" "bah")
>(into "foo" "bah")
>
> For the moment I am doing
>
>(.concat "foo" "bah")
>
> But it seems wrong
>
> Thanks
> P
>

Try (str "foo" "bah").

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Anand Patil

Thanks for the responses, guys.

>> - Partially apply a function to any of its arguments, not just the
>> first one

>That's already the case, haven't you made a little test ?

I meant I want to apply it out of sequence, sorry.

> You can easily partially apply to other arguments by doing this: #(fred %1
> some-arg %2 other-arg).

That makes sense, thanks, though it's not any easier to unapply than
partial. I guess I could make a new 'partial-like' function that
returns code to apply a function, with nil's in unapplied argument
slots... ?

> Not possible as far as I know. Could you please explain use cases you have
> in mind for such a feature ?

Sure, it's the lazy cells I've been working on. When a cell's parent
changes, I don't want it to compute right away- I want it to register
the fact that the parent has changed, switch to an 'unevaluated'
state, and 'unapply' its childrens' update functions on itself.

I won't explain how I'm doing it right now for fear of muddying the
waters, but it feels overcomplicated and un-idiomatic.

Thanks,
Anand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Anand Patil

Thanks for the responses, guys.

>> - Partially apply a function to any of its arguments, not just the
>> first one

>That's already the case, haven't you made a little test ?

I meant I want to apply it out of sequence, sorry.

> You can easily partially apply to other arguments by doing this: #(fred %1
> some-arg %2 other-arg).

That makes sense, thanks, though it's not any easier to unapply than
partial. I guess I could make a new 'partial-like' function that
returns code to apply a function, with nil's in unapplied argument
slots... ?

> Not possible as far as I know. Could you please explain use cases you have
> in mind for such a feature ?

Sure, it's the lazy cells I've been working on. When a cell's parent
changes, I don't want it to compute right away- I want it to recognize
the new value, but switch to an un-evaluated state. Since the cell has
no value, it would be nice if its children could just un-apply their
update functions on it.

I won't explain how I'm doing it right now for fear of muddying the
waters, but it feels overcomplicated and un-idiomatic.

Thanks,
Anand

On Feb 26, 4:00 pm, Laurent PETIT  wrote:
> 2009/2/26 Jeffrey Straszheim 
>
> > "partial" is a currying function.  It can be provided any number of
> > parameter(s), but it is always behaves sequentially from start to finish.
> >  That is what currying *is*.
>
> Ah, I thought currying / uncurrying what the term reserved for this
> operation (as I remember from Haskell) that changes the arity of functions (
> transforming and untransforming a function of n parameters into a function
> of a tuple of n elements) ?
>
>
>
> > You can easily partially apply to other arguments by doing this: #(fred %1
> > some-arg %2 other-arg).
>
> > "partial" could not easily support "unapplying" it.
>
> > On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil <
> > anand.prabhakar.pa...@gmail.com> wrote:
>
> >> Hi all,
>
> >> I could use a version of 'partial' that would allow me to:
>
> >> - Partially apply a function to any of its arguments, not just the
> >> first one
> >> - 'Unapply' a partially-applied function from one of its arguments.
>
> >> Is any such thing already available?
>
> >> Thanks,
> >> Anand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Anand Patil

Sorry, I thought I had pushed 'stop' in time to stop the first
response.

On Feb 26, 4:16 pm, Anand Patil 
wrote:
> Thanks for the responses, guys.
>
> >> - Partially apply a function to any of its arguments, not just the
> >> first one
> >That's already the case, haven't you made a little test ?
>
> I meant I want to apply it out of sequence, sorry.
>
> > You can easily partially apply to other arguments by doing this: #(fred %1
> > some-arg %2 other-arg).
>
> That makes sense, thanks, though it's not any easier to unapply than
> partial. I guess I could make a new 'partial-like' function that
> returns code to apply a function, with nil's in unapplied argument
> slots... ?
>
> > Not possible as far as I know. Could you please explain use cases you have
> > in mind for such a feature ?
>
> Sure, it's the lazy cells I've been working on. When a cell's parent
> changes, I don't want it to compute right away- I want it to recognize
> the new value, but switch to an un-evaluated state. Since the cell has
> no value, it would be nice if its children could just un-apply their
> update functions on it.
>
> I won't explain how I'm doing it right now for fear of muddying the
> waters, but it feels overcomplicated and un-idiomatic.
>
> Thanks,
> Anand
>
> On Feb 26, 4:00 pm, Laurent PETIT  wrote:
>
> > 2009/2/26 Jeffrey Straszheim 
>
> > > "partial" is a currying function.  It can be provided any number of
> > > parameter(s), but it is always behaves sequentially from start to finish.
> > >  That is what currying *is*.
>
> > Ah, I thought currying / uncurrying what the term reserved for this
> > operation (as I remember from Haskell) that changes the arity of functions (
> > transforming and untransforming a function of n parameters into a function
> > of a tuple of n elements) ?
>
> > > You can easily partially apply to other arguments by doing this: #(fred %1
> > > some-arg %2 other-arg).
>
> > > "partial" could not easily support "unapplying" it.
>
> > > On Thu, Feb 26, 2009 at 10:24 AM, Anand Patil <
> > > anand.prabhakar.pa...@gmail.com> wrote:
>
> > >> Hi all,
>
> > >> I could use a version of 'partial' that would allow me to:
>
> > >> - Partially apply a function to any of its arguments, not just the
> > >> first one
> > >> - 'Unapply' a partially-applied function from one of its arguments.
>
> > >> Is any such thing already available?
>
> > >> Thanks,
> > >> Anand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread mikel



On Feb 26, 9:24 am, Anand Patil 
wrote:
> Hi all,
>
> I could use a version of 'partial' that would allow me to:
>
> - Partially apply a function to any of its arguments, not just the
> first one
> - 'Unapply' a partially-applied function from one of its arguments.
>
> Is any such thing already available?

Other people have explained currying and partial application, and why
it doesn't normally spply the feature you want.

Normally, in a lnaguage that supplies partial application, the way to
achieve the effect you want is to use combinators that change the
order of arguments.

A combinator is a function whose arguments are functions, and whose
return value is a function; partial is a combinator.

Suppose you have a function that works like this:

(foo x y)

...and you want to partially apply foo, but the argument you want to
apply it to is the y argument, not the x argument. You can't, because
partially applying foo will apply it to the x argument.

What you need is a combinator that reverses the order of foo's
arguments. You want to call

(swap foo)

and get back a function that works exactly like foo, except that it
taks arguments y x instead of x y.

It turns out that this is easy to write:

(defn swap [f]
   (fn [y x]
  (f x y)))

swap is the combinator you need in this case. You can get the effect
described above by doing (partial (swap f) y)

So, to get the effect you want, figure out the transformation you
would need on the argument list and write a combinator that implements
it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Anand Patil



On Feb 26, 4:41 pm, mikel  wrote:
> Other people have explained currying and partial application, and why
> it doesn't normally spply the feature you want.

I'd be interested in reading about this if you know of a link.

> Normally, in a lnaguage that supplies partial application, the way to
> achieve the effect you want is to use combinators that change the
> order of arguments.

OK, that sounds like a clean functional way to do it. Thanks.

Anand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Christian Vest Hansen

Nice initiative!

However, it the net-ssh dependency has problems:

[cvh: ~]$ sudo gem install djspiewak-buildr
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem)

On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak  wrote:
>
> I'm pleased to announce preliminary (and very experimental) support
> for the Clojure AOT compiler and REPL within Apache Buildr (http://
> buildr.apache.org).  At present, this support is only available within
> my Git fork available here: git://github.com/djspiewak/buildr.git
> More specifically, Clojure support is available within the "clojure"
> and "master" branches ("master" branch alone contains REPL support).
> It should be possible to install this particular version of Buildr by
> using the following commands, though I'm honestly not sure how up to
> date GitHub's gem repository is:
>
>  gem sources -a http://gems.github.com
>  sudo gem install djspiewak-buildr
>
> Once installed, Clojure support is activated in a project simply by
> storing your .clj scripts within the src/main/clojure directory.  Note
> that the (ns) directive will need to match the subdirectory, otherwise
> compilation will fail.  By default, every script is compiled to the
> target/classes directory.  Namespaces are auto-detected from the
> directory structure.  Only updated files are re-compiled (based on
> mtime of .clj file and its corresponding *__init.class).  If you wish
> to override the auto-detection and specify a reduced set of
> namespaces, it can be done using the `compile.using` directive within
> your project definition in your buildfile.  Thusly:
>
> define 'clojure-contrib' do
>  compile.using :libs => ['clojure.contrib.command-line',
> 'clojure.contrib.mmap']
> end
>
> Any scripts which are *not* pre-compiled will be copied verbatim to
> the target/classes directory w.r.t. their position in the directory
> structure.  Note that you will need to have set CLOJURE_HOME for this
> to work.
>
> You will have to be using the "master" branch from my git repository
> in order to use the Clojure REPL through Buildr (or install via the
> gem command given above).  To invoke, simply run the following command
> somewhere in your project hierarchy:
>
>  buildr shell
>
> This will launch the Clojure REPL pointing at your project's
> dependencies and the updated target/classes directory (compilation is
> re-run if necessary).  Additionally, if you have a valid license for
> JavaRebel, you can make use of it with the REPL by setting the
> REBEL_HOME environment variable.
>
> Note that you cannot mix Java and Clojure sources within the same
> project.

Aww... :(

>  However, this is fairly easy to overcome by splitting the
> languages into separate sub-projects.  Thus, your top-level project
> might contain all of your Clojure sources, while the sub-project might
> contain Java.  There are more details regarding this process on the
> Buildr project page.
>
> One thing to keep in mind is that Buildr was designed to serve as a
> build system for more static languages (specifically: Java, Scala,
> Groovy).  Thus, it is pre-biased toward things like a separate
> compilation phase (the REPL points to target/classes rather than src/
> main/clojure).
>
> Fair warning: this language support is *extremely* experimental and
> probably not too reliable at this point.  Also note that while it is
> possible that Clojure support will be merged into the Buildr trunk in
> future, it has not yet been decided one way or another (see
> https://issues.apache.org/jira/browse/BUILDR-259).  Use at your own
> risk!
> >
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread mikel



On Feb 25, 6:51 pm, Rich Hickey  wrote:


> user=> (type #^{:type ::Fred} [1 2 3])
> :user/Fred

This is extremely appealing, as David said, for those of us building
type systems for our application data.

There's one wart for my particular use:

(binding [*print-dup* true]
(prn-str #^{:type ::Fred} [1 2 3]))

java.lang.StackOverflowError (NO_SOURCE_FILE:0)
  [Thrown class clojure.lang.Compiler$CompilerException]


Oops. Can't serialize an object with attached metadata.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Jeff Valk

Thanks for the insight, Konrad. I know this is a sideshow to the larger 
discussion on types, but it does present an unexpected usability issue.

On 26 February 2009 at 02:44, Konrad Hinsen wrote:

> The fix is to provide a default implementation for print-method. Try  
> executing this:
> 
> (defmethod print-method :default [o w] (print-method "failed" w))

This prevents the stack overflow. But I'd prefer a more forgiving default print 
behavior.

> There should be a default in clojure.core, but I am not 
> sure what it should best be. Should it print the object stripped of  
> its metadata?

I vote for this. A default that re-dispatches on class (as you suggested, 
stripping the :type metadata), falls back to the previous print behavior.

(defmethod print-method :default [o, #^java.io.Writer w]
  (if (:type (meta o))
(print-method (with-meta o (dissoc (meta o) :type)) w)
(do
  (.write w "#<")
  (.write w (.getSimpleName (class o)))
  (.write w " ")
  (.write w (str o))
  (.write w ">"

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Daniel Spiewak

Odd.  Must be a problem with RubyForge.  If you try again, does it
work?

Daniel

On Feb 26, 10:58 am, Christian Vest Hansen 
wrote:
> Nice initiative!
>
> However, it the net-ssh dependency has problems:
>
> [cvh: ~]$ sudo gem install djspiewak-buildr
> ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
>     timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem)
>
>
>
> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak  wrote:
>
> > I'm pleased to announce preliminary (and very experimental) support
> > for the Clojure AOT compiler and REPL within Apache Buildr (http://
> > buildr.apache.org).  At present, this support is only available within
> > my Git fork available here: git://github.com/djspiewak/buildr.git
> > More specifically, Clojure support is available within the "clojure"
> > and "master" branches ("master" branch alone contains REPL support).
> > It should be possible to install this particular version of Buildr by
> > using the following commands, though I'm honestly not sure how up to
> > date GitHub's gem repository is:
>
> >  gem sources -ahttp://gems.github.com
> >  sudo gem install djspiewak-buildr
>
> > Once installed, Clojure support is activated in a project simply by
> > storing your .clj scripts within the src/main/clojure directory.  Note
> > that the (ns) directive will need to match the subdirectory, otherwise
> > compilation will fail.  By default, every script is compiled to the
> > target/classes directory.  Namespaces are auto-detected from the
> > directory structure.  Only updated files are re-compiled (based on
> > mtime of .clj file and its corresponding *__init.class).  If you wish
> > to override the auto-detection and specify a reduced set of
> > namespaces, it can be done using the `compile.using` directive within
> > your project definition in your buildfile.  Thusly:
>
> > define 'clojure-contrib' do
> >  compile.using :libs => ['clojure.contrib.command-line',
> > 'clojure.contrib.mmap']
> > end
>
> > Any scripts which are *not* pre-compiled will be copied verbatim to
> > the target/classes directory w.r.t. their position in the directory
> > structure.  Note that you will need to have set CLOJURE_HOME for this
> > to work.
>
> > You will have to be using the "master" branch from my git repository
> > in order to use the Clojure REPL through Buildr (or install via the
> > gem command given above).  To invoke, simply run the following command
> > somewhere in your project hierarchy:
>
> >  buildr shell
>
> > This will launch the Clojure REPL pointing at your project's
> > dependencies and the updated target/classes directory (compilation is
> > re-run if necessary).  Additionally, if you have a valid license for
> > JavaRebel, you can make use of it with the REPL by setting the
> > REBEL_HOME environment variable.
>
> > Note that you cannot mix Java and Clojure sources within the same
> > project.
>
> Aww... :(
>
>
>
> >  However, this is fairly easy to overcome by splitting the
> > languages into separate sub-projects.  Thus, your top-level project
> > might contain all of your Clojure sources, while the sub-project might
> > contain Java.  There are more details regarding this process on the
> > Buildr project page.
>
> > One thing to keep in mind is that Buildr was designed to serve as a
> > build system for more static languages (specifically: Java, Scala,
> > Groovy).  Thus, it is pre-biased toward things like a separate
> > compilation phase (the REPL points to target/classes rather than src/
> > main/clojure).
>
> > Fair warning: this language support is *extremely* experimental and
> > probably not too reliable at this point.  Also note that while it is
> > possible that Clojure support will be merged into the Buildr trunk in
> > future, it has not yet been decided one way or another (see
> >https://issues.apache.org/jira/browse/BUILDR-259).  Use at your own
> > risk!
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Laurent PETIT
Wow, great !

Some notes I took while reading your e-mail : (those are some pitfalls I
came through while implementing clojuredev's eclipse auto-build feature)

 * does it support namespaces separated in several files (handling files
that begin with 'in-ns, or just not trying to compile them ?)
 * if so, will it support the scenario of multiple files per ns, where just
another file (and not the file defining the ns) is modified ?
 * there is also another problem : if some macros are defined in a namespace
A, used in a namespace B, then if you just change the macro and recompile
namespace A, I don't think code using the macros in namespace B will see the
changes ?

Those considerations, among other things, have made me consider just
recompiling the entire project every time a resource or set of resources
change, so that it is reliable, if not totally optimized (but so far, for
the size of the projects, I guess it's still not a performance bottleneck).

My 0,02 €,

-- 
Laurent


2009/2/21 Daniel Spiewak 

>
> I'm pleased to announce preliminary (and very experimental) support
> for the Clojure AOT compiler and REPL within Apache Buildr (http://
> buildr.apache.org).  At present, this support is only available within
> my Git fork available here: git://github.com/djspiewak/buildr.git
> More specifically, Clojure support is available within the "clojure"
> and "master" branches ("master" branch alone contains REPL support).
> It should be possible to install this particular version of Buildr by
> using the following commands, though I'm honestly not sure how up to
> date GitHub's gem repository is:
>
>  gem sources -a http://gems.github.com
>  sudo gem install djspiewak-buildr
>
> Once installed, Clojure support is activated in a project simply by
> storing your .clj scripts within the src/main/clojure directory.  Note
> that the (ns) directive will need to match the subdirectory, otherwise
> compilation will fail.  By default, every script is compiled to the
> target/classes directory.  Namespaces are auto-detected from the
> directory structure.  Only updated files are re-compiled (based on
> mtime of .clj file and its corresponding *__init.class).  If you wish
> to override the auto-detection and specify a reduced set of
> namespaces, it can be done using the `compile.using` directive within
> your project definition in your buildfile.  Thusly:
>
> define 'clojure-contrib' do
>  compile.using :libs => ['clojure.contrib.command-line',
> 'clojure.contrib.mmap']
> end
>
> Any scripts which are *not* pre-compiled will be copied verbatim to
> the target/classes directory w.r.t. their position in the directory
> structure.  Note that you will need to have set CLOJURE_HOME for this
> to work.
>
> You will have to be using the "master" branch from my git repository
> in order to use the Clojure REPL through Buildr (or install via the
> gem command given above).  To invoke, simply run the following command
> somewhere in your project hierarchy:
>
>  buildr shell
>
> This will launch the Clojure REPL pointing at your project's
> dependencies and the updated target/classes directory (compilation is
> re-run if necessary).  Additionally, if you have a valid license for
> JavaRebel, you can make use of it with the REPL by setting the
> REBEL_HOME environment variable.
>
> Note that you cannot mix Java and Clojure sources within the same
> project.  However, this is fairly easy to overcome by splitting the
> languages into separate sub-projects.  Thus, your top-level project
> might contain all of your Clojure sources, while the sub-project might
> contain Java.  There are more details regarding this process on the
> Buildr project page.
>
> One thing to keep in mind is that Buildr was designed to serve as a
> build system for more static languages (specifically: Java, Scala,
> Groovy).  Thus, it is pre-biased toward things like a separate
> compilation phase (the REPL points to target/classes rather than src/
> main/clojure).
>
> Fair warning: this language support is *extremely* experimental and
> probably not too reliable at this point.  Also note that while it is
> possible that Clojure support will be merged into the Buildr trunk in
> future, it has not yet been decided one way or another (see
> https://issues.apache.org/jira/browse/BUILDR-259).  Use at your own
> risk!
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Daniel Spiewak


> > Note that you cannot mix Java and Clojure sources within the same
> > project.
>
> Aww... :(

Joint-compilation is actually a hard problem normally.  However, since
Clojure is late-bound, I should be able to do it without too much
horror.  Actually, I should be able to do joint compilation with Java,
Scala or Groovy (Scala and Groovy would be mutually exclusive).  I
just have to figure out how to trick Buildr into letting me register a
compiler in this fashion.  So, the feature is coming, it's just not
immediately present.

Daniel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread mikel



On Feb 26, 10:58 am, Anand Patil 
wrote:
> On Feb 26, 4:41 pm, mikel  wrote:
>
> > Other people have explained currying and partial application, and why
> > it doesn't normally spply the feature you want.
>
> I'd be interested in reading about this if you know of a link.

What I meant was, other people have talked about it *in this
thread*. :-) As in, farther up the page. :-)

But you can find more about currying here:

http://en.wikipedia.org/wiki/Currying

> > Normally, in a lnaguage that supplies partial application, the way to
> > achieve the effect you want is to use combinators that change the
> > order of arguments.
>
> OK, that sounds like a clean functional way to do it. Thanks.

This article includes some discussion of combinators, including
examples of some standard ones:

http://en.wikipedia.org/wiki/Combinators#Examples_of_combinators

Combinators are sort of interesting in themselves; it turns out that
the standard combinators S and K are Turing complete; that is, a
language consisting only of S and K is sufficient to compute anything
that can be computed (although such a language would be neither
convenient nor efficient). That's sort of surprising.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: some vs. contains? for a list

2009-02-26 Thread Jason Wolfe

Hi Mark,

The results will depend on the objects you are comparing.  If you need
to search through the list multiple times, converting to a set once is
almost certainly going to be faster.  But, if you're just doing it
once, iterating will usually be much faster:

user> (time (dotimes [_ 10] (contains? (set (range 100)) 10)))
"Elapsed time: 7708.336 msecs"

user> (time (dotimes [_ 10] (some #(= 10 %) (range 100
"Elapsed time: 291.474 msecs"

user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains?
s 10
"Elapsed time: 27.978 msecs"

In a simple test I get similar results for strings too... what
conditions were you testing under?

-Jason

On Feb 26, 7:53 am, Mark Volkmann  wrote:
> I thought for sure it would be faster to use "some" to determine
> whether an item was in a list rather than convert the list to a set
> and then use "contains?", but it turns out I was wrong. The latter
> approach takes about 1/3 to 1/2 the time! This is the case even when
> the list contains 100 items. Of course I realize that if this is a
> commonly needed operation for a particular collection, it's better to
> use a set instead of a list in the first place.
>
> (def stooges (list "Moe" "Larry" "Curly"))
> (time (some #(= % "Curly") stooges))
> (time (contains? (set stooges) "Curly"))
>
> --
> 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 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Daniel Spiewak


>  * does it support namespaces separated in several files (handling files
> that begin with 'in-ns, or just not trying to compile them ?)
>  * if so, will it support the scenario of multiple files per ns, where just
> another file (and not the file defining the ns) is modified ?

I didn't even know Clojure's AOT compiler supported this.  I thought
that the name of the file was forced to match the name of the
namespace it represents?  If that is not the case, then the solution
would probably be to just not compile the in-ns files, though that
seems annoyingly-ugly.

Right now, compilation detection is exclusively based on filenames.
So if you have a file src/main/clojure/clojure/contrib/command-
line.clj, then Buildr will dispatch the compilation of namespace
"clojure.contrib.command-line".  I thought about doing fancy parsing
to checkout the ns declarations, but given Clojure's dynamic nature, I
would never be able to *guarantee* any sort of accuracy in that
approach.

>  * there is also another problem : if some macros are defined in a namespace
> A, used in a namespace B, then if you just change the macro and recompile
> namespace A, I don't think code using the macros in namespace B will see the
> changes ?

This case didn't occur to me, but you're right that it would be
problematic.  I should probably change the compilation to just
recompile everything when any file has changed.  Darn those macros...

Daniel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: some vs. contains? for a list

2009-02-26 Thread Jason Wolfe

Well, I guess the second number is a bit misleading.  Of course, when
you're iterating the time taken will depend on the (expected) presence
and position of the target in the list.  Still, the order is the same
even in the worst case:

user> (time (dotimes [_ 10] (some #(= 100 %) (range 100
"Elapsed time: 2213.944 msecs"


On Feb 26, 10:02 am, Jason Wolfe  wrote:
> Hi Mark,
>
> The results will depend on the objects you are comparing.  If you need
> to search through the list multiple times, converting to a set once is
> almost certainly going to be faster.  But, if you're just doing it
> once, iterating will usually be much faster:
>
> user> (time (dotimes [_ 10] (contains? (set (range 100)) 10)))
> "Elapsed time: 7708.336 msecs"
>
> user> (time (dotimes [_ 10] (some #(= 10 %) (range 100
> "Elapsed time: 291.474 msecs"
>
> user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains?
> s 10
> "Elapsed time: 27.978 msecs"
>
> In a simple test I get similar results for strings too... what
> conditions were you testing under?
>
> -Jason
>
> On Feb 26, 7:53 am, Mark Volkmann  wrote:
>
> > I thought for sure it would be faster to use "some" to determine
> > whether an item was in a list rather than convert the list to a set
> > and then use "contains?", but it turns out I was wrong. The latter
> > approach takes about 1/3 to 1/2 the time! This is the case even when
> > the list contains 100 items. Of course I realize that if this is a
> > commonly needed operation for a particular collection, it's better to
> > use a set instead of a list in the first place.
>
> > (def stooges (list "Moe" "Larry" "Curly"))
> > (time (some #(= % "Curly") stooges))
> > (time (contains? (set stooges) "Curly"))
>
> > --
> > 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 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread Anand Patil

On Feb 26, 5:27 pm, mikel  wrote:
> On Feb 26, 10:58 am, Anand Patil 
> wrote:
>
> > On Feb 26, 4:41 pm, mikel  wrote:
>
> > > Other people have explained currying and partial application, and why
> > > it doesn't normally spply the feature you want.
>
> > I'd be interested in reading about this if you know of a link.
>
> What I meant was, other people have talked about it *in this
> thread*. :-) As in, farther up the page. :-)

Ha! I see. :) I was hoping for a reason why these languages don't
provide more general partial application in addition to currying, but
that's probably available in the Wikipedia article.

> Combinators are sort of interesting in themselves; it turns out that
> the standard combinators S and K are Turing complete; that is, a
> language consisting only of S and K is sufficient to compute anything
> that can be computed (although such a language would be neither
> convenient nor efficient). That's sort of surprising.

That is surprising. I go now to ponder.

Anand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Waterfront's Issue tracker is up

2009-02-26 Thread Itay Maman

For those of you who encountered issues/bugs with Waterfront, you not
submit reports at: 
http://sourceforge.net/tracker2/?func=browse&group_id=249246&atid=1126790

My intention is to get Waterfront into contrib in the near future.
Till then, Waterfront will stay on sf.net.

Also, thank you very much for the warm feedback and the wise comments.

-Itay

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Waterfront's Issue tracker is up

2009-02-26 Thread Itay Maman

Should be "you can now submit..."
Sorry for the typo.

-Itay


On Feb 26, 9:37 pm, Itay Maman  wrote:
> For those of you who encountered issues/bugs with Waterfront, you not
> submit reports 
> at:http://sourceforge.net/tracker2/?func=browse&group_id=249246&atid=112...
>
> My intention is to get Waterfront into contrib in the near future.
> Till then, Waterfront will stay on sf.net.
>
> Also, thank you very much for the warm feedback and the wise comments.
>
> -Itay
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Richer 'partial'

2009-02-26 Thread mikel



On Feb 26, 12:34 pm, Anand Patil 
wrote:
> On Feb 26, 5:27 pm, mikel  wrote:
>
> > On Feb 26, 10:58 am, Anand Patil 
> > wrote:
>
> > > On Feb 26, 4:41 pm, mikel  wrote:
>
> > > > Other people have explained currying and partial application, and why
> > > > it doesn't normally spply the feature you want.
>
> > > I'd be interested in reading about this if you know of a link.
>
> > What I meant was, other people have talked about it *in this
> > thread*. :-) As in, farther up the page. :-)
>
> Ha! I see. :) I was hoping for a reason why these languages don't
> provide more general partial application in addition to currying, but
> that's probably available in the Wikipedia article.

I don't know that you'll find that question answered explicitly. I
think the answer would be that (1) supporting that feature creates a
lot of syntactic complexity (you need some notational mechanism for
designating which arguments you're going to apply the function to, and
anything you choose is going to be kind of messy), and (2) with
combinators, you don't need it.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread Peter Wolf

Thanks all.

I think appending a bunch of strings is a pretty common operation. 

Is there any reason that str is limited to 2 arguments?  It would be 
nice to do (str "foo" "bar" "baz") --> "foobarbaz".

Is there a good reason that + can't do the right thing as with other 
Java and scripting languages?  I think this would be popular with 
non-LISPers.

P



Laurent PETIT wrote:
> (str "foo" "bah")
>
> and if you have a collection you can (apply str coll)
>
> HTH,
>
> -- 
> Laurent
>
> 2009/2/26 Peter Wolf mailto:opus...@gmail.com>>
>
>
> Hey all,
>
> What is the idiomatic way to concatenate strings?  Here are some
> things
> that I expected to work, but didn't
>
>(+ "foo" "bah")
>(conj "foo" "bah")
>(into "foo" "bah")
>
> For the moment I am doing
>
>(.concat "foo" "bah")
>
> But it seems wrong
>
> Thanks
> P
>
>
>
>
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread Matt Revelle

On Feb 26, 2009, at 2:01 PM, Peter Wolf wrote:

>
> Thanks all.
>
> I think appending a bunch of strings is a pretty common operation.
>
> Is there any reason that str is limited to 2 arguments?  It would be
> nice to do (str "foo" "bar" "baz") --> "foobarbaz".

It does.  Try it out.  =)

>
>
> Is there a good reason that + can't do the right thing as with other
> Java and scripting languages?  I think this would be popular with
> non-LISPers.
>
>
> P
>
>
>
> Laurent PETIT wrote:
>> (str "foo" "bah")
>>
>> and if you have a collection you can (apply str coll)
>>
>> HTH,
>>
>> --  
>> Laurent
>>
>> 2009/2/26 Peter Wolf mailto:opus...@gmail.com>>
>>
>>
>>Hey all,
>>
>>What is the idiomatic way to concatenate strings?  Here are some
>>things
>>that I expected to work, but didn't
>>
>>   (+ "foo" "bah")
>>   (conj "foo" "bah")
>>   (into "foo" "bah")
>>
>>For the moment I am doing
>>
>>   (.concat "foo" "bah")
>>
>>But it seems wrong
>>
>>Thanks
>>P
>>
>>
>>
>>
>>
>>
>>>
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Clojure plugin for IntelliJ IDEA published

2009-02-26 Thread CuppoJava

Hello Ilya,
Thanks for the workaround.

I'm glad to hear you're working on a "surround with" feature. Some
other parenthesis commands that I most commonly use is:
  1) Delete next Sexp.
  2) Splice Sexp. (Remove the parenthesis around the current sexp).
  3) Move cursor to next/previous sexp.

Just from a personal point of view, my most wanted features would be,
in order of preference
  1) Keyboard shortcuts for sending sexps to REPL.
  2) Parenthesis commands
  3) Working Debugger. (This would be extremely useful. But I'm making
do without it for now.)

Thanks
-Patrick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread Perry Trolard

> Is there any reason that str is limited to 2 arguments?  It would be
> nice to do (str "foo" "bar" "baz") --> "foobarbaz".

Try it! (Hint: "With more than one arg, returns the concatenation of
the str values of the args.")

> Is there a good reason that + can't do the right thing as with other
> Java and scripting languages?  I think this would be popular with
> non-LISPers.

I think any desire for that disappears once you discover str, but the
implementation reason against it is that it'd require arg checks for
+, which you want to be fast. Look at the source for + & str --
they're both optimized for what they do.

Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Phil Hagelberg

Peter Wolf  writes:

> Is there a good reason that + can't do the right thing as with other 
> Java and scripting languages?  I think this would be popular with 
> non-LISPers.

Putting a type check in + would slow down basic math, and there is a
class of user who will complain loudly if basic math slows
down. However, this also means that > and < also don't work on strings,
which is pretty lousy.

One approach that's been proposed in #clojure is to make these functions
more capable by default, but then provide a fast-math library that could
redefine them in terms of numerics-only. I'm a big fan of functions
doing the most helpful thing by default but being able to offer better
speed when you need it.

Convenience vs speed is always a trade-off, but I think convenience
should win in the default case. What do others think about this?

-Phil

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Syntax-quote only as a reader macro?

2009-02-26 Thread Chouser

On Thu, Feb 26, 2009 at 9:36 AM, Konrad Hinsen
 wrote:
>
> I figured out one way to do it, but it relies on features that are
> perhaps not safe to rely on: I get var first, and then I get the
> var's namespace from its public attribute ns:
>
> (defn qualified-symbol
>   [s]
>   (if-let [var (resolve s)]
>     (symbol (str (.ns var)) (str (.sym var)))
>     s))
>
> This seems to work fine for all cases I can imagine. But I'd love to
> see a cleaner way to do this.

I've got essentially the same thing for use in error-kit:

  (defn- qualify-sym [sym]
(let [v (resolve sym)]
  (assert v)
  (apply symbol (map #(str (% ^v)) [:ns :name]

Of course it depends on the var existing at the time the macro is
expanded, but if that weren't true how could the macro have any idea
what namespace the symbol belonged to?

BTW, I'd recommend avoiding using the name of builtins like 'var' for
your own locals.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Cosmin Stejerean
On Thu, Feb 26, 2009 at 1:18 PM, Phil Hagelberg  wrote:

>
> Peter Wolf  writes:
>
> > Is there a good reason that + can't do the right thing as with other
> > Java and scripting languages?  I think this would be popular with
> > non-LISPers.
>
> Putting a type check in + would slow down basic math, and there is a
> class of user who will complain loudly if basic math slows
> down. However, this also means that > and < also don't work on strings,
> which is pretty lousy.
>
> One approach that's been proposed in #clojure is to make these functions
> more capable by default, but then provide a fast-math library that could
> redefine them in terms of numerics-only. I'm a big fan of functions
> doing the most helpful thing by default but being able to offer better
> speed when you need it.
>
> Convenience vs speed is always a trade-off, but I think convenience
> should win in the default case. What do others think about this?
>

I would much rather have a fast-math library that redefined common operators
for numeric types only, and had the default +, <, > be multimethods.

-- 
Cosmin Stejerean
http://offbytwo.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Daniel Spiewak

> > > Note that you cannot mix Java and Clojure sources within the same
> > > project.

It is supported in the latest changeset.  The following configurations
are possible:

-
Just Clojure:
 * src/main/clojure

Clojure and Scala:
 * src/main/clojure
 * src/main/scala

Clojure, Scala and Java:
 * src/main/clojure
 * src/main/scala
 * src/main/java

Clojure and Groovy:
 * src/main/clojure
 * src/main/groovy

Clojure, Groovy and Java:
 * src/main/clojure
 * src/main/groovy
 * src/main/java

Clojure and Java:
 * src/main/clojure
 * src/main/java
-

You'll notice that "Clojure, Scala and Groovy" is not among the
possibilities.  This is because the Groovy joint compiler and the
Scala joint compiler both expect to be able to interleave Java
dependencies within their type resolution process.  They do not have
support for the same functionality with each other, meaning that
circular dependencies cannot be compiled between the two languages.

Note that this is all predicated on a (possibly faulty) assumption
about the Clojure compiler: everything must be late-bound.  If
Clojure's compiler needs to resolve types at compile-time, then this
could potentially fail in unexpected ways.  Specifically, circular
dependencies between Clojure and Java/Scala/Groovy would not be
possible.  In such a case, you would need to somehow factor the
circularity out into a separate .clj file and then exclude that file
from compilation (forcing late binding).  I honestly don't know if
this is the compiler's behavior or not, but I thought it was worth the
warning.

One small change: in order to use this functionality now, you will
need to include the following line at the top of your buildfile:

require 'buildr/clojure'

Joint compilation with Scala/Java or Groovy/Java does not necessitate
an extra "require", but this first one is necessary to get the process
started and ensure that Clojure's compiler becomes the dominant
selection.

Daniel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: "Adding" strings

2009-02-26 Thread opus111
Doh!  *engage brain BEFORE emailing*

Sorry to be not thinking...  Coffee now!

:-P

Sent via BlackBerry from T-Mobile

-Original Message-
From: Perry Trolard 

Date: Thu, 26 Feb 2009 11:13:49 
To: Clojure
Subject: Re: "Adding" strings



> Is there any reason that str is limited to 2 arguments?  It would be
> nice to do (str "foo" "bar" "baz") --> "foobarbaz".

Try it! (Hint: "With more than one arg, returns the concatenation of
the str values of the args.")

> Is there a good reason that + can't do the right thing as with other
> Java and scripting languages?  I think this would be popular with
> non-LISPers.

I think any desire for that disappears once you discover str, but the
implementation reason against it is that it'd require arg checks for
+, which you want to be fast. Look at the source for + & str --
they're both optimized for what they do.

Perry


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: function call preconditions

2009-02-26 Thread Mark H.

On Feb 26, 5:55 am, Laurent PETIT  wrote:
> While not checking types at compile time, it seems to me that a lot of
> clojure code still needs in the docstring some sort of "preconditions
> warnings".

Do you mean something like "Contract Programming," as in e.g., the
Eiffel programming language?

mfh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: function call preconditions

2009-02-26 Thread Laurent PETIT
My first thought was just : "could some information that is currently placed
in the docstring be more useful is written differently, while still
complying with the DRY principle (that is, the parts that are extracted from
the current docstring should still be available in a useful form to the
clients of your function/macro".

The evident think that can be very easily formalized in the docstrings is
some sort of type restriction on the arguments.

A generalization of this, though, is indeed what Eiffel offers as Design By
Contract. Something like that is already present (I guess) as validators on
refs, atoms and agents.

-- 
Laurent

2009/2/26 Mark H. 

>
> On Feb 26, 5:55 am, Laurent PETIT  wrote:
> > While not checking types at compile time, it seems to me that a lot of
> > clojure code still needs in the docstring some sort of "preconditions
> > warnings".
>
> Do you mean something like "Contract Programming," as in e.g., the
> Eiffel programming language?
>
> mfh
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



read file into byte[]

2009-02-26 Thread Martin DeMello

Is there a quick way to read a file into a java array of bytes?

martin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: some vs. contains? for a list

2009-02-26 Thread Mark Volkmann

On Thu, Feb 26, 2009 at 12:02 PM, Jason Wolfe  wrote:
>
> Hi Mark,
>
> The results will depend on the objects you are comparing.  If you need
> to search through the list multiple times, converting to a set once is
> almost certainly going to be faster.  But, if you're just doing it
> once, iterating will usually be much faster:

That makes sense, but doesn't match the results I see. See my
additional detail below.

> user> (time (dotimes [_ 10] (contains? (set (range 100)) 10)))
> "Elapsed time: 7708.336 msecs"
>
> user> (time (dotimes [_ 10] (some #(= 10 %) (range 100
> "Elapsed time: 291.474 msecs"
>
> user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains?
> s 10
> "Elapsed time: 27.978 msecs"
>
> In a simple test I get similar results for strings too... what
> conditions were you testing under?

Here's the actual code I ran to test.

(def stooges (list
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
  "Moe" "Larry" "Curly"))

(time (dotimes [_ 1000] (some #(= % "Curly") stooges)))

(time (dotimes [_ 1000] (contains? (set stooges) "Curly")))

(let [s (set stooges)]
  (time (dotimes [_ 1000] (contains? s "Curly"

I'm seeing a wide variation in results. Here are results from consecutive runs.

"Elapsed time: 40.515 msecs"
"Elapsed time: 121.825 msecs"
"Elapsed time: 1.163 msecs"

"Elapsed time: 69.026 msecs"
"Elapsed time: 60.438 msecs"
"Elapsed time: 1.732 msecs"

So sometimes converting to a set for a single lookup (the second case)
is faster, but not usually.

> On Feb 26, 7:53 am, Mark Volkmann  wrote:
>> I thought for sure it would be faster to use "some" to determine
>> whether an item was in a list rather than convert the list to a set
>> and then use "contains?", but it turns out I was wrong. The latter
>> approach takes about 1/3 to 1/2 the time! This is the case even when
>> the list contains 100 items. Of course I realize that if this is a
>> commonly needed operation for a particular collection, it's better to
>> use a set instead of a list in the first place.
>>
>> (def stooges (list "Moe" "Larry" "Curly"))
>> (time (some #(= % "Curly") stooges))
>> (time (contains? (set stooges) "Curly"))

-- 
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 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: some vs. contains? for a list

2009-02-26 Thread Jason Wolfe

Ah, OK, a couple of things.

First, if you're running timing experiments, you probably want the  
times to be measured in seconds for them to be at all reliable.  It  
seems to take up to 10 seconds of executing a bit of code before  
HotSpot is done optimizing it (depending on complexity of what you're  
running -- here, probably not so much), so usually you want to execute  
at least one "throw-away" run, and then do a final set of timings.   
Even then, if your final times aren't at least a second or so, you'll  
end up running afoul of intermittent GC overhead (sometimes it will  
happen during your run, sometimes not).  At least, that's how I  
understand things.

Second, building the set in your case will be faster since there are  
only 10 unique elements.  AFAIK this means only 10 new "Set" object  
creations, compared to 100 if the elements were all unique.

Cheers,
Jason



On Feb 26, 2009, at 12:15 PM, Mark Volkmann wrote:

>
> On Thu, Feb 26, 2009 at 12:02 PM, Jason Wolfe   
> wrote:
>>
>> Hi Mark,
>>
>> The results will depend on the objects you are comparing.  If you  
>> need
>> to search through the list multiple times, converting to a set once  
>> is
>> almost certainly going to be faster.  But, if you're just doing it
>> once, iterating will usually be much faster:
>
> That makes sense, but doesn't match the results I see. See my
> additional detail below.
>
>> user> (time (dotimes [_ 10] (contains? (set (range 100)) 10)))
>> "Elapsed time: 7708.336 msecs"
>>
>> user> (time (dotimes [_ 10] (some #(= 10 %) (range 100
>> "Elapsed time: 291.474 msecs"
>>
>> user> (time (let [s (set (range 100))] (dotimes [_ 10] (contains?
>> s 10
>> "Elapsed time: 27.978 msecs"
>>
>> In a simple test I get similar results for strings too... what
>> conditions were you testing under?
>
> Here's the actual code I ran to test.
>
> (def stooges (list
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
>  "Moe" "Larry" "Curly"))
>
> (time (dotimes [_ 1000] (some #(= % "Curly") stooges)))
>
> (time (dotimes [_ 1000] (contains? (set stooges) "Curly")))
>
> (let [s (set stooges)]
>  (time (dotimes [_ 1000] (contains? s "Curly"
>
> I'm seeing a wide variation in results. Here are results from  
> consecutive runs.
>
> "Elapsed time: 40.515 msecs"
> "Elapsed time: 121.825 msecs"
> "Elapsed time: 1.163 msecs"
>
> "Elapsed time: 69.026 msecs"
> "Elapsed time: 60.438 msecs"
> "Elapsed time: 1.732 msecs"
>
> So sometimes converting to a set for a single lookup (the second case)
> is faster, but not usually.
>
>> On Feb 26, 7:53 am, Mark Volkmann  wrote:
>>> I thought for sure it would be faster to use "some" to determine
>>> whether an item was in a list rather than convert the list to a set
>>> and then use "contains?", but it turns out I was wrong. The latter
>>> approach takes about 1/3 to 1/2 the time! This is the case even when
>>> the list contains 100 items. Of course I realize that if this is a
>>> commonly needed operation for a particular collection, it's better  
>>> to
>>> use a set instead of a list in the first place.
>>>
>>> (def stooges (list "Moe" "Larry" "Curly"))
>>> (time (some #(= % "Curly") stooges))
>>> (time (contains? (set stooges) "Curly"))
>
> -- 
> 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 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Syntax-quote only as a reader macro?

2009-02-26 Thread Konrad Hinsen

On 26.02.2009, at 20:25, Chouser wrote:

> I've got essentially the same thing for use in error-kit:
>
>   (defn- qualify-sym [sym]
> (let [v (resolve sym)]
>   (assert v)
>   (apply symbol (map #(str (% ^v)) [:ns :name]

Except that you get the information from the metadata. I wonder which  
method is safer in the long run?

> Of course it depends on the var existing at the time the macro is
> expanded, but if that weren't true how could the macro have any idea
> what namespace the symbol belonged to?

Given that I want to replicate exactly what happens when the compiler  
resolves a symbol, the only problem would be a symbol referring to  
something else than a var. My understanding is that that shouldn't  
happen.

> BTW, I'd recommend avoiding using the name of builtins like 'var' for
> your own locals.

In theory I agree, but in practice I can't remember all those  
builtins, most of which I never use...

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



order of the arguments for functions, think an easy way.

2009-02-26 Thread camponoblanco


This is an example:


(contains? (set (range 100)) 10)))
(some #(= 10 %) (range 100

I would like some way to rule the order of the arguments.  For example
what - where.

contains? what where
some what where

I'm sure you can think some rules to cover many cases.  As I am not so
young, I'm getting fond of  rules to make life easier.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Algebraic data types in clojure.contrib

2009-02-26 Thread Konrad Hinsen

On 26.02.2009, at 10:00, Konrad Hinsen wrote:

> I know, but as I said, my current implementation is just a proof of
> concept. It is not viable for production use for a variety of
> reasons. I was planning to replace it by something based on gen-class
> and proxy, but I will first try to get away with the new type  
> function.

I just committed a completely new implementation to clojure.contrib.  
It uses a vector with type metadata for representing algebraic data  
types. Overall I am rather happy with this version. It is used almost  
exactly like the previous one.

There is probably still room for improvement, but I don't expect the  
interface to change significantly any more, so I'd say it's safe for  
adoption by adventurous Clojurians :-)

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Christian Vest Hansen

On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak  wrote:
>
> Odd.  Must be a problem with RubyForge.  If you try again, does it
> work?

I tried again at home and got quite a bit further. Maybe it was just a
hiccup at rubyforge.

However, I still see some questionable things in the output, and I
have yet to actually try it out (this is the first time I'm trying out
buildr). Here in verbatim:

rowe:~$ sudo gem install djspiewak-buildr
Building native extensions.  This could take a while...
Successfully installed builder-2.1.2
Successfully installed net-ssh-2.0.4
Successfully installed net-sftp-2.0.1
Successfully installed rubyzip-0.9.1
Successfully installed highline-1.5.0
Successfully installed rubyforge-1.0.1
Successfully installed hoe-1.7.0
Successfully installed rjb-1.1.6
Successfully installed Antwrap-0.7.0
Successfully installed rspec-1.1.4
Successfully installed xml-simple-1.0.11
Successfully installed archive-tar-minitar-0.5.2
Successfully installed djspiewak-buildr-1.3.4
13 gems installed
Installing ri documentation for builder-2.1.2...
ERROR:  While generating documentation for builder-2.1.2
... MESSAGE:   Unhandled special: Special: type=17, text=""
... RDOC args: --ri --op
/opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder --
Easy XML Building --main README --line-numbers --quiet lib CHANGES
Rakefile README doc/releases/builder-1.2.4.rdoc
doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc
(continuing with the rest of the installation)
Installing ri documentation for net-ssh-2.0.4...
Installing ri documentation for net-sftp-2.0.1...
Installing ri documentation for highline-1.5.0...
Installing ri documentation for rubyforge-1.0.1...
Installing ri documentation for hoe-1.7.0...
Installing ri documentation for Antwrap-0.7.0...
Installing ri documentation for rspec-1.1.4...
Installing ri documentation for archive-tar-minitar-0.5.2...
Installing ri documentation for djspiewak-buildr-1.3.4...
File not found: lib
rowe:~$ ruby --version
ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin8]
rowe:~$


A failure to generate the docs I can live with, but that "File not
found" line looks pretty suspect.


>
> Daniel
>
> On Feb 26, 10:58 am, Christian Vest Hansen 
> wrote:
>> Nice initiative!
>>
>> However, it the net-ssh dependency has problems:
>>
>> [cvh: ~]$ sudo gem install djspiewak-buildr
>> ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
>>     timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem)
>>
>>
>>
>> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak  wrote:
>>
>> > I'm pleased to announce preliminary (and very experimental) support
>> > for the Clojure AOT compiler and REPL within Apache Buildr (http://
>> > buildr.apache.org).  At present, this support is only available within
>> > my Git fork available here: git://github.com/djspiewak/buildr.git
>> > More specifically, Clojure support is available within the "clojure"
>> > and "master" branches ("master" branch alone contains REPL support).
>> > It should be possible to install this particular version of Buildr by
>> > using the following commands, though I'm honestly not sure how up to
>> > date GitHub's gem repository is:
>>
>> >  gem sources -ahttp://gems.github.com
>> >  sudo gem install djspiewak-buildr
>>
>> > Once installed, Clojure support is activated in a project simply by
>> > storing your .clj scripts within the src/main/clojure directory.  Note
>> > that the (ns) directive will need to match the subdirectory, otherwise
>> > compilation will fail.  By default, every script is compiled to the
>> > target/classes directory.  Namespaces are auto-detected from the
>> > directory structure.  Only updated files are re-compiled (based on
>> > mtime of .clj file and its corresponding *__init.class).  If you wish
>> > to override the auto-detection and specify a reduced set of
>> > namespaces, it can be done using the `compile.using` directive within
>> > your project definition in your buildfile.  Thusly:
>>
>> > define 'clojure-contrib' do
>> >  compile.using :libs => ['clojure.contrib.command-line',
>> > 'clojure.contrib.mmap']
>> > end
>>
>> > Any scripts which are *not* pre-compiled will be copied verbatim to
>> > the target/classes directory w.r.t. their position in the directory
>> > structure.  Note that you will need to have set CLOJURE_HOME for this
>> > to work.
>>
>> > You will have to be using the "master" branch from my git repository
>> > in order to use the Clojure REPL through Buildr (or install via the
>> > gem command given above).  To invoke, simply run the following command
>> > somewhere in your project hierarchy:
>>
>> >  buildr shell
>>
>> > This will launch the Clojure REPL pointing at your project's
>> > dependencies and the updated target/classes directory (compilation is
>> > re-run if necessary).  Additionally, if you have a valid license for
>> > JavaRebel, you can make use of it with the REPL by setting the
>> > REBEL_HOME environment variable.
>>
>> > Note t

Re: order of the arguments for functions, think an easy way.

2009-02-26 Thread Stephen C. Gilardi


On Feb 26, 2009, at 3:57 PM, camponoblanco wrote:


This is an example:


(contains? (set (range 100)) 10)))
(some #(= 10 %) (range 100

I would like some way to rule the order of the arguments.  For example
what - where.

contains? what where
some what where

I'm sure you can think some rules to cover many cases.  As I am not so
young, I'm getting fond of  rules to make life easier.


This previous discussion may be helpful:

http://groups.google.com/group/clojure/browse_frm/thread/8b2c8dc96b39ddd7?tvc=1&q=order+of+arguments

--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Daniel Spiewak

I'm not sure what the File not found thing is all about, but you
should still be ok (crazy gems).  Try the following:

  buildr --version

Daniel

On Feb 26, 3:16 pm, Christian Vest Hansen 
wrote:
> On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak  wrote:
>
> > Odd.  Must be a problem with RubyForge.  If you try again, does it
> > work?
>
> I tried again at home and got quite a bit further. Maybe it was just a
> hiccup at rubyforge.
>
> However, I still see some questionable things in the output, and I
> have yet to actually try it out (this is the first time I'm trying out
> buildr). Here in verbatim:
>
> rowe:~$ sudo gem install djspiewak-buildr
> Building native extensions.  This could take a while...
> Successfully installed builder-2.1.2
> Successfully installed net-ssh-2.0.4
> Successfully installed net-sftp-2.0.1
> Successfully installed rubyzip-0.9.1
> Successfully installed highline-1.5.0
> Successfully installed rubyforge-1.0.1
> Successfully installed hoe-1.7.0
> Successfully installed rjb-1.1.6
> Successfully installed Antwrap-0.7.0
> Successfully installed rspec-1.1.4
> Successfully installed xml-simple-1.0.11
> Successfully installed archive-tar-minitar-0.5.2
> Successfully installed djspiewak-buildr-1.3.4
> 13 gems installed
> Installing ri documentation for builder-2.1.2...
> ERROR:  While generating documentation for builder-2.1.2
> ... MESSAGE:   Unhandled special: Special: type=17, text=""
> ... RDOC args: --ri --op
> /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder --
> Easy XML Building --main README --line-numbers --quiet lib CHANGES
> Rakefile README doc/releases/builder-1.2.4.rdoc
> doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc
> (continuing with the rest of the installation)
> Installing ri documentation for net-ssh-2.0.4...
> Installing ri documentation for net-sftp-2.0.1...
> Installing ri documentation for highline-1.5.0...
> Installing ri documentation for rubyforge-1.0.1...
> Installing ri documentation for hoe-1.7.0...
> Installing ri documentation for Antwrap-0.7.0...
> Installing ri documentation for rspec-1.1.4...
> Installing ri documentation for archive-tar-minitar-0.5.2...
> Installing ri documentation for djspiewak-buildr-1.3.4...
> File not found: lib
> rowe:~$ ruby --version
> ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin8]
> rowe:~$
>
> A failure to generate the docs I can live with, but that "File not
> found" line looks pretty suspect.
>
>
>
>
>
> > Daniel
>
> > On Feb 26, 10:58 am, Christian Vest Hansen 
> > wrote:
> >> Nice initiative!
>
> >> However, it the net-ssh dependency has problems:
>
> >> [cvh: ~]$ sudo gem install djspiewak-buildr
> >> ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
> >>     timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem)
>
> >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak  
> >> wrote:
>
> >> > I'm pleased to announce preliminary (and very experimental) support
> >> > for the Clojure AOT compiler and REPL within Apache Buildr (http://
> >> > buildr.apache.org).  At present, this support is only available within
> >> > my Git fork available here: git://github.com/djspiewak/buildr.git
> >> > More specifically, Clojure support is available within the "clojure"
> >> > and "master" branches ("master" branch alone contains REPL support).
> >> > It should be possible to install this particular version of Buildr by
> >> > using the following commands, though I'm honestly not sure how up to
> >> > date GitHub's gem repository is:
>
> >> >  gem sources -ahttp://gems.github.com
> >> >  sudo gem install djspiewak-buildr
>
> >> > Once installed, Clojure support is activated in a project simply by
> >> > storing your .clj scripts within the src/main/clojure directory.  Note
> >> > that the (ns) directive will need to match the subdirectory, otherwise
> >> > compilation will fail.  By default, every script is compiled to the
> >> > target/classes directory.  Namespaces are auto-detected from the
> >> > directory structure.  Only updated files are re-compiled (based on
> >> > mtime of .clj file and its corresponding *__init.class).  If you wish
> >> > to override the auto-detection and specify a reduced set of
> >> > namespaces, it can be done using the `compile.using` directive within
> >> > your project definition in your buildfile.  Thusly:
>
> >> > define 'clojure-contrib' do
> >> >  compile.using :libs => ['clojure.contrib.command-line',
> >> > 'clojure.contrib.mmap']
> >> > end
>
> >> > Any scripts which are *not* pre-compiled will be copied verbatim to
> >> > the target/classes directory w.r.t. their position in the directory
> >> > structure.  Note that you will need to have set CLOJURE_HOME for this
> >> > to work.
>
> >> > You will have to be using the "master" branch from my git repository
> >> > in order to use the Clojure REPL through Buildr (or install via the
> >> > gem command given above).  To invoke, simply run the following command
> >> > somewhere in your pr

Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Peter Wolf

OK had my coffee, and had several thoughts...

1 -- What are Strings?  How should the Clojure programmer think about 
them?  Are they sequences, in which case all the sequence functions 
should work.  Or are they atomic built-in types like Integers and Floats?

2 -- There is already some type checking in + to deal with Integers, 
Floats and infinite precision.  Line 1212 of Numbers.java has the ops() 
method which (I think) implements this

static Ops ops(Object x){
Class xc = x.getClass();

if(xc == Integer.class)
return INTEGER_OPS;
else if(xc == Double.class)
return DOUBLE_OPS;
else if(xc == Float.class)
return FLOAT_OPS;
else if(xc == BigInteger.class)
return BIGINTEGER_OPS;
else if(xc == Long.class)
return BIGINTEGER_OPS;
else if(xc == Ratio.class)
return RATIO_OPS;
else if(xc == BigDecimal.class)
return BIGDECIMAL_OPS;
else
return INTEGER_OPS;
}

3 -- Type hints can take the place of a fast-math library.  The compiler 
could automatically call the appropriate fast math routine when given 
the necessary information.

So my vote is that String are atomic built in objects, and at least +, < 
and > should work with Strings.  The behavior should be just like Java, 
so (+ "foo" 2) --> "foo2"

I don't think this will slow down math because the String case will be 
the last "else if" in ops() and will only happen when the args are not 
some sort of Number.

Finally, if it doesn't already, I would expect type hints to make things 
faster.  So, it should not be necessary to explicitly call a fast-math 
library.

My 2 n00by cents...
P



Phil Hagelberg wrote:
> Peter Wolf  writes:
>
>   
>> Is there a good reason that + can't do the right thing as with other 
>> Java and scripting languages?  I think this would be popular with 
>> non-LISPers.
>> 
>
> Putting a type check in + would slow down basic math, and there is a
> class of user who will complain loudly if basic math slows
> down. However, this also means that > and < also don't work on strings,
> which is pretty lousy.
>
> One approach that's been proposed in #clojure is to make these functions
> more capable by default, but then provide a fast-math library that could
> redefine them in terms of numerics-only. I'm a big fan of functions
> doing the most helpful thing by default but being able to offer better
> speed when you need it.
>
> Convenience vs speed is always a trade-off, but I think convenience
> should win in the default case. What do others think about this?
>
> -Phil
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Christian Vest Hansen

rowe:~$ buildr --version
/opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
`gem_original_require': no such file to load -- buildr (LoadError)
from 
/opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
`require'
from 
/opt/local/lib/ruby/gems/1.8/gems/djspiewak-buildr-1.3.4/bin/buildr:18
from /opt/local/bin/buildr:19:in `load'
from /opt/local/bin/buildr:19
rowe:~$ gem --version
1.3.1
rowe:~$

On Thu, Feb 26, 2009 at 10:30 PM, Daniel Spiewak  wrote:
>
> I'm not sure what the File not found thing is all about, but you
> should still be ok (crazy gems).  Try the following:
>
>  buildr --version
>
> Daniel
>
> On Feb 26, 3:16 pm, Christian Vest Hansen 
> wrote:
>> On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak  wrote:
>>
>> > Odd.  Must be a problem with RubyForge.  If you try again, does it
>> > work?
>>
>> I tried again at home and got quite a bit further. Maybe it was just a
>> hiccup at rubyforge.
>>
>> However, I still see some questionable things in the output, and I
>> have yet to actually try it out (this is the first time I'm trying out
>> buildr). Here in verbatim:
>>
>> rowe:~$ sudo gem install djspiewak-buildr
>> Building native extensions.  This could take a while...
>> Successfully installed builder-2.1.2
>> Successfully installed net-ssh-2.0.4
>> Successfully installed net-sftp-2.0.1
>> Successfully installed rubyzip-0.9.1
>> Successfully installed highline-1.5.0
>> Successfully installed rubyforge-1.0.1
>> Successfully installed hoe-1.7.0
>> Successfully installed rjb-1.1.6
>> Successfully installed Antwrap-0.7.0
>> Successfully installed rspec-1.1.4
>> Successfully installed xml-simple-1.0.11
>> Successfully installed archive-tar-minitar-0.5.2
>> Successfully installed djspiewak-buildr-1.3.4
>> 13 gems installed
>> Installing ri documentation for builder-2.1.2...
>> ERROR:  While generating documentation for builder-2.1.2
>> ... MESSAGE:   Unhandled special: Special: type=17, text=""
>> ... RDOC args: --ri --op
>> /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder --
>> Easy XML Building --main README --line-numbers --quiet lib CHANGES
>> Rakefile README doc/releases/builder-1.2.4.rdoc
>> doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc
>> (continuing with the rest of the installation)
>> Installing ri documentation for net-ssh-2.0.4...
>> Installing ri documentation for net-sftp-2.0.1...
>> Installing ri documentation for highline-1.5.0...
>> Installing ri documentation for rubyforge-1.0.1...
>> Installing ri documentation for hoe-1.7.0...
>> Installing ri documentation for Antwrap-0.7.0...
>> Installing ri documentation for rspec-1.1.4...
>> Installing ri documentation for archive-tar-minitar-0.5.2...
>> Installing ri documentation for djspiewak-buildr-1.3.4...
>> File not found: lib
>> rowe:~$ ruby --version
>> ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin8]
>> rowe:~$
>>
>> A failure to generate the docs I can live with, but that "File not
>> found" line looks pretty suspect.
>>
>>
>>
>>
>>
>> > Daniel
>>
>> > On Feb 26, 10:58 am, Christian Vest Hansen 
>> > wrote:
>> >> Nice initiative!
>>
>> >> However, it the net-ssh dependency has problems:
>>
>> >> [cvh: ~]$ sudo gem install djspiewak-buildr
>> >> ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
>> >>     timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem)
>>
>> >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak  
>> >> wrote:
>>
>> >> > I'm pleased to announce preliminary (and very experimental) support
>> >> > for the Clojure AOT compiler and REPL within Apache Buildr (http://
>> >> > buildr.apache.org).  At present, this support is only available within
>> >> > my Git fork available here: git://github.com/djspiewak/buildr.git
>> >> > More specifically, Clojure support is available within the "clojure"
>> >> > and "master" branches ("master" branch alone contains REPL support).
>> >> > It should be possible to install this particular version of Buildr by
>> >> > using the following commands, though I'm honestly not sure how up to
>> >> > date GitHub's gem repository is:
>>
>> >> >  gem sources -ahttp://gems.github.com
>> >> >  sudo gem install djspiewak-buildr
>>
>> >> > Once installed, Clojure support is activated in a project simply by
>> >> > storing your .clj scripts within the src/main/clojure directory.  Note
>> >> > that the (ns) directive will need to match the subdirectory, otherwise
>> >> > compilation will fail.  By default, every script is compiled to the
>> >> > target/classes directory.  Namespaces are auto-detected from the
>> >> > directory structure.  Only updated files are re-compiled (based on
>> >> > mtime of .clj file and its corresponding *__init.class).  If you wish
>> >> > to override the auto-detection and specify a reduced set of
>> >> > namespaces, it can be done using the `compile.using` directive within
>> >> > your project definition in your buildfile.  Thusly:
>>
>> >> > defi

Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Allen Rohner


>
> So my vote is that String are atomic built in objects, and at least +, <
> and > should work with Strings.  The behavior should be just like Java,
> so (+ "foo" 2) --> "foo2"
>

-1

Concatenation is not addition. I'm almost opposed to numeric operators
all together. If we wrote (add 2 3), there would be no confusion at
all about what (add "foo" 2) should do, because you'd be writing (conj
"foo" (str 2))

If addition between a string and number is defined, what is
subtraction between a string and a number?

Allen




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: unbean

2009-02-26 Thread Kevin Albrecht

Thanks.  I will definitely be using this function... keep me up to
date on any changes.

Bill wrote:
> > It occurs to me that the "unbean" function could be very useful when
> > writing tests for code that calls Java objects.
>
> Yes, that is exactly the use I have in mind.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: how to get concurrent - model design question

2009-02-26 Thread Timothy Pratley

Ah I see, yes that makes sense.
Relationships truly are a contract in this case!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Laurent PETIT
Agree,

I even think there *could* be some utility in having the opposite behavior
(but I'm not even sure about that) :

(+ "1" 2) --> 3 by + trying to cast its non numeric arguments before
throwing an exception ...

-- 
Laurent

2009/2/26 Allen Rohner 

>
>
> >
> > So my vote is that String are atomic built in objects, and at least +, <
> > and > should work with Strings.  The behavior should be just like Java,
> > so (+ "foo" 2) --> "foo2"
> >
>
> -1
>
> Concatenation is not addition. I'm almost opposed to numeric operators
> all together. If we wrote (add 2 3), there would be no confusion at
> all about what (add "foo" 2) should do, because you'd be writing (conj
> "foo" (str 2))
>
> If addition between a string and number is defined, what is
> subtraction between a string and a number?
>
> Allen
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Phil Hagelberg

Laurent PETIT  writes:

> > Concatenation is not addition. I'm almost opposed to numeric operators
> > all together. If we wrote (add 2 3), there would be no confusion at
> > all about what (add "foo" 2) should do, because you'd be writing (conj
> > "foo" (str 2))
>
> Agree

I agree regarding concatenation as well, but I think the case for
comparison of non-numerics is still pretty strong.

-Phil

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Mike Benfield



On Feb 26, 4:56 pm, Peter Wolf  wrote:

>
> So my vote is that String are atomic built in objects, and at least +, <
> and > should work with Strings.  The behavior should be just like Java,
> so (+ "foo" 2) --> "foo2"


I have an HP calculator. (I may get some of the details wrong here, I
haven't used it lately, but this is the gist of the thing.) + adds
numbers. + also concatenates lists. But wait, UNLESS the lists are
lists of numbers, in which case it adds numbers componentwise. Which
means you have to create a new function or operator if you actually
want to be sure you are concatenating lists. It's just dumb. The point
is, functions should not take on all kinds of extraneous
responsibilities that are completely unrelated to their purpose. +
adds numbers. str concatenates strings.

BTW, I don't know if this concept of "built in object" you keep saying
has any meaning in Clojure. Strings are just objects of the class
String, just like in Java.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Allen Rohner


> I agree regarding concatenation as well, but I think the case for
> comparison of non-numerics is still pretty strong.
>
> -Phil

Are you referring to using <, >, =, with objects that implement
java.lang.Comparable?

i.e. given x.compareTo(y) == -1
(< x y)
=> true

I would find that useful.

Allen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Mathy operations on non-numerics (was "Adding" strings)

2009-02-26 Thread Allen Rohner

 If we wrote (add 2 3), there would be no confusion at
> all about what (add "foo" 2) should do, because you'd be writing (conj
> "foo" (str 2))

I wrote this too hastily. This could more easily be written (str "foo"
2)

--Allen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: Clojure plugin for IntelliJ IDEA published

2009-02-26 Thread Howard Lewis Ship

I've only had a couple of minutes to work with it, but I'm already
liking it.  I just can't keep switching between Emacs and IDEA and
IDEA is the work that pays the bills!

On Thu, Feb 26, 2009 at 11:08 AM, CuppoJava  wrote:
>
> Hello Ilya,
> Thanks for the workaround.
>
> I'm glad to hear you're working on a "surround with" feature. Some
> other parenthesis commands that I most commonly use is:
>  1) Delete next Sexp.
>  2) Splice Sexp. (Remove the parenthesis around the current sexp).
>  3) Move cursor to next/previous sexp.
>
> Just from a personal point of view, my most wanted features would be,
> in order of preference
>  1) Keyboard shortcuts for sending sexps to REPL.
>  2) Parenthesis commands
>  3) Working Debugger. (This would be extremely useful. But I'm making
> do without it for now.)
>
> Thanks
> -Patrick
> >
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: ANN: Preliminary Clojure Support in Buildr

2009-02-26 Thread Daniel Spiewak

Crud.  I suspect this is something weird with the way that the GitHib
gem server works.  I'll try to repeat the problem on Ubuntu as soon as
I get back to my computer.  In the meantime, you could try these
commands:

  sudo gem uninstall djspiewak-buildr
  sudo gem install djspiewak-buildr

Daniel

On Feb 26, 3:59 pm, Christian Vest Hansen 
wrote:
> rowe:~$ buildr --version
> /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
> `gem_original_require': no such file to load -- buildr (LoadError)
>         from 
> /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
> `require'
>         from 
> /opt/local/lib/ruby/gems/1.8/gems/djspiewak-buildr-1.3.4/bin/buildr:18
>         from /opt/local/bin/buildr:19:in `load'
>         from /opt/local/bin/buildr:19
> rowe:~$ gem --version
> 1.3.1
> rowe:~$
>
>
>
> On Thu, Feb 26, 2009 at 10:30 PM, Daniel Spiewak  wrote:
>
> > I'm not sure what the File not found thing is all about, but you
> > should still be ok (crazy gems).  Try the following:
>
> >  buildr --version
>
> > Daniel
>
> > On Feb 26, 3:16 pm, Christian Vest Hansen 
> > wrote:
> >> On Thu, Feb 26, 2009 at 6:17 PM, Daniel Spiewak  
> >> wrote:
>
> >> > Odd.  Must be a problem with RubyForge.  If you try again, does it
> >> > work?
>
> >> I tried again at home and got quite a bit further. Maybe it was just a
> >> hiccup at rubyforge.
>
> >> However, I still see some questionable things in the output, and I
> >> have yet to actually try it out (this is the first time I'm trying out
> >> buildr). Here in verbatim:
>
> >> rowe:~$ sudo gem install djspiewak-buildr
> >> Building native extensions.  This could take a while...
> >> Successfully installed builder-2.1.2
> >> Successfully installed net-ssh-2.0.4
> >> Successfully installed net-sftp-2.0.1
> >> Successfully installed rubyzip-0.9.1
> >> Successfully installed highline-1.5.0
> >> Successfully installed rubyforge-1.0.1
> >> Successfully installed hoe-1.7.0
> >> Successfully installed rjb-1.1.6
> >> Successfully installed Antwrap-0.7.0
> >> Successfully installed rspec-1.1.4
> >> Successfully installed xml-simple-1.0.11
> >> Successfully installed archive-tar-minitar-0.5.2
> >> Successfully installed djspiewak-buildr-1.3.4
> >> 13 gems installed
> >> Installing ri documentation for builder-2.1.2...
> >> ERROR:  While generating documentation for builder-2.1.2
> >> ... MESSAGE:   Unhandled special: Special: type=17, text=""
> >> ... RDOC args: --ri --op
> >> /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder --
> >> Easy XML Building --main README --line-numbers --quiet lib CHANGES
> >> Rakefile README doc/releases/builder-1.2.4.rdoc
> >> doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc
> >> (continuing with the rest of the installation)
> >> Installing ri documentation for net-ssh-2.0.4...
> >> Installing ri documentation for net-sftp-2.0.1...
> >> Installing ri documentation for highline-1.5.0...
> >> Installing ri documentation for rubyforge-1.0.1...
> >> Installing ri documentation for hoe-1.7.0...
> >> Installing ri documentation for Antwrap-0.7.0...
> >> Installing ri documentation for rspec-1.1.4...
> >> Installing ri documentation for archive-tar-minitar-0.5.2...
> >> Installing ri documentation for djspiewak-buildr-1.3.4...
> >> File not found: lib
> >> rowe:~$ ruby --version
> >> ruby1.8.7(2008-08-11 patchlevel 72) [i686-darwin8]
> >> rowe:~$
>
> >> A failure to generate the docs I can live with, but that "File not
> >> found" line looks pretty suspect.
>
> >> > Daniel
>
> >> > On Feb 26, 10:58 am, Christian Vest Hansen 
> >> > wrote:
> >> >> Nice initiative!
>
> >> >> However, it the net-ssh dependency has problems:
>
> >> >> [cvh: ~]$ sudo gem install djspiewak-buildr
> >> >> ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
> >> >>     timed out (http://gems.rubyforge.org/gems/net-ssh-2.0.4.gem)
>
> >> >> On Sat, Feb 21, 2009 at 10:33 PM, Daniel Spiewak  
> >> >> wrote:
>
> >> >> > I'm pleased to announce preliminary (and very experimental) support
> >> >> > for the Clojure AOT compiler and REPL within Apache Buildr (http://
> >> >> > buildr.apache.org).  At present, this support is only available within
> >> >> > my Git fork available here: git://github.com/djspiewak/buildr.git
> >> >> > More specifically, Clojure support is available within the "clojure"
> >> >> > and "master" branches ("master" branch alone contains REPL support).
> >> >> > It should be possible to install this particular version of Buildr by
> >> >> > using the following commands, though I'm honestly not sure how up to
> >> >> > date GitHub's gem repository is:
>
> >> >> >  gem sources -ahttp://gems.github.com
> >> >> >  sudo gem install djspiewak-buildr
>
> >> >> > Once installed, Clojure support is activated in a project simply by
> >> >> > storing your .clj scripts within the src/main/clojure directory.  Note
> >> >> > that the (ns) directive will need to match the subdirectory, otherwise
> >> 

Please help me get rid of my mutable code.

2009-02-26 Thread CuppoJava

Hi,
After having used Clojure for a few months now, I'm still having lots
of trouble separating my mutable code from my immutable code. My use-
case is pretty typical I think, so I'm wondering what sort of
structure everyone else is using.

Here's my current structure.

I have an engine that manages a list of sprites. The engine runs in a
loop and updates all the sprites incrementally sixty times a second.
When an event occurs, the engine notifies each sprite. When a sprite
receives an event, it processes it, and then notifies each of it's
listeners. Typical Java event listener model.

Well this scheme has mutability written all over it.
I'm currently representing sprites as references of immutable maps. So
my code is literally littered with (dosync) instructions.

How would I go about separating my mutable code from my immutable
code? I think I need a completely different angle to attack the
problem?

Thanks a lot for the help
  -Patrick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: read file into byte[]

2009-02-26 Thread Chouser

On Thu, Feb 26, 2009 at 3:04 PM, Martin DeMello  wrote:
>
> Is there a quick way to read a file into a java array of bytes?

(let [fl (java.io.File. "/tmp/datafile")
  ary (make-array Byte/TYPE (.length fl))]
  (with-open [strm (java.io.FileInputStream. fl)]
(.read strm ary 0 (.length fl)))
  ary)

Hm.  Or maybe java.nio?

(with-open [strm (java.io.FileInputStream. "/tmp/datafile")]
  (let [ch (.getChannel strm)
buf (java.nio.ByteBuffer/allocate (.size ch))]
(.read ch buf)
(.array buf)))

Bleh.  Anybody got something better?

(with-open [strm (java.io.FileInputStream. "/tmp/datafile")]
  (let [ch (.getChannel strm)
buf (.map ch java.nio.channels.FileChannel$MapMode/READ_ONLY 0
(.size ch))
ary (make-array Byte/TYPE (.size ch))]
(.get buf ary)
ary))

Seriously, what's with this API?  I give up.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: read file into byte[]

2009-02-26 Thread Stuart Sierra

On Feb 26, 3:04 pm, Martin DeMello  wrote:
> Is there a quick way to read a file into a java array of bytes?

You want Apache Commons IO:
http://commons.apache.org/io/

Specifically, http://tinyurl.com/cytspt

-Stuart Sierra

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



  1   2   >