Re: Beginner's question regarding implementing a constructor using gen-class

[Alex Osborne]

Hi Gregg,

Gregg Williams  writes:

> (ns genclassInteger
>  (:gen-class
>:extends [java.lang.Integer])
>  ;(:import (java.lang   Integer))   ; < unnecessary, right?
>  )

> -
>
> This returns the error:
>
>  Exception in thread "main" java.lang.ClassNotFoundException:
> [java/lang/Integer] (genclassInteger.clj:1)

I don't know why you're getting that particular exception but
java.lang.Integer is a "final" class. [1]  You therefore can't extend
it. 

Also Java doesn't support multiple-inheritance of classes, so I don't
think the class you pass to :extends should be wrapped in a vector.

Finally, having a namespace without a "." in it means you're
generating a class in the default package.  Java doesn't like this at
all and places some weird restrictions on classes in the default
package. [2]  This is may not be the cause of your problem but it's
something I'd avoid anyway.

So try something more like this:

(ns myproject.myfoo
  (:gen-class
   :extends some.package.Foo))

Hope that helps,

Alex

[1] http://en.wikipedia.org/wiki/Final_(Java)
[2] http://stackoverflow.com/questions/283816

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

Re: Beginner's question regarding implementing a constructor using gen-class

[Alex Osborne]

Gregg Williams  writes:

> Now I'm working on
> the "Graph Editor" program described at 
> http://www.piccolo2d.org/learn/grapheditor.html
> .
>
> In this sample program (which you don't really need to look at) I need
> to subclass a Piccolo2D class to create a class named GraphEditor ,
> but unlike the last time (see "Java interop question: proxy or gen-
> class?" in this group), I can't subclass using proxy because *this*
> subclass, GraphEditor, adds a new method. This means I have to use gen-
> class.

Actually looking at the sample code, GraphEditor doesn't appear to
override any methods of PCanvas, so why does it need to be a subclass at
all?  I'd just create a regular instance of PCanvas and work with that
instead:

(defn create-graph-editor [width height]
  (let [canvas (doto (PCanvas.)
 (.setPreferredSize width height))
node-layer (.getLayer canvas)
edge-layer (PLayer.)
random (Random.)]
(-> canvas (.getRoot) (.addChild edgeLayer))
(-> canvas (.getCamera) (.addLayer 0 edgeLayer))
;;
;; ... and so on.  I'd actually probably break the
;; constructor up into multiple functions, it's
;; rather large.
;;
canvas))

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

beginer jedit problem

[Marko Srepfler]

Windows 7
jre 1.6
command mode

error on getting started jline

C:\clojure-1.1.0>dir
 Volume in drive C has no label.
 Volume Serial Number is 303A-A5FF

 Directory of C:\clojure-1.1.0

28.04.2010.  10:43  .
28.04.2010.  10:43  ..
28.04.2010.  10:2877 .gitignore
28.04.2010.  10:28 8.923 build.xml
28.04.2010.  10:28 6.574 changes.txt
28.04.2010.  10:28 1.846.856 clojure.jar
28.04.2010.  10:2812.917 epl-v10.html
28.04.2010.  10:36  jline-0.9.91
28.04.2010.  10:3661.187 jline-0.9.91.jar
28.04.2010.  10:34  jline-0.9.94
28.04.2010.  10:28   828 pom-template.xml
28.04.2010.  10:28 2.318 readme.txt
28.04.2010.  10:29  src
28.04.2010.  10:29  test
   8 File(s)  1.939.680 bytes
   6 Dir(s)  42.299.772.928 bytes free

C:\clojure-1.1.0>java -cp jline-0.9.91.jar:clojure.jar
jline.ConsoleRunner cloju
re.main
Exception in thread "main" java.lang.ClassNotFoundException:
clojure.main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.misc.Launcher$ExtClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at jline.ConsoleRunner.main(ConsoleRunner.java:69)

C:\clojure-1.1.0>

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

Re: Insert into an indexed seq

[James Reeves]

On Apr 27, 7:45 pm, Sean Devlin  wrote:
> However, there are still problems
> that require me to use an expensive operation.

Could you give an example of such a problem? There may be another way
of solving it you have not considered.

- James

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

Re: deftype and final classes

[Jarkko Oranen]

On Apr 28, 5:00 am, Richard Newman  wrote:

> Opinions, thoughts, critiques, "you're insane"s, etc. welcome.

The patches look fine to me and the change is well justified since you
have a real use case. I don't think restricting deftype to final
classes would serve any real purpose. I'd just go ahead and make an
assembla ticket for this, but of course it's safest to wait for Rich's
opinion.

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

Re: deftype and final classes

[Rich Hickey]

On Apr 27, 10:00 pm, Richard Newman  wrote:
> Further to IRC conversations:
>
> I'm attempting to generate a JAX-WS service using Clojure. The main  
> stumbling block was annotations; that's been removed, so I gave it a  
> shot using deftype.
>
> My first strike works code-wise, so I sent it to the list earlier today.
>
> When it comes to actually integrating the output into the Java world,  
> though, things get hairy. JAX-WS has a bunch of demands on classes in  
> order for its tools (such as wsgen) to accept them:
>
> 
>
> ---
> JAX-WS endpoints must follow these requirements:
>
> * The implementing class must be annotated with either the  
> javax.jws.WebService or javax.jws.WebServiceProvider annotation.
> * The implementing class may explicitly reference an SEI through the  
> endpointInterface element of the @WebService annotation, but is not  
> required to do so. If no endpointInterface is not specified in  
> @WebService, an SEI is implicitly defined for the implementing class.
> * The business methods of the implementing class must be public, and  
> must not be declared static or final.
> * Business methods that are exposed to web service clients must be  
> annotated with javax.jws.WebMethod.
> * Business methods that are exposed to web service clients must have  
> JAX-B-compatible parameters and return types. See Default Data Type  
> Bindings.
> * The implementing class must not be declared final and must not be  
> abstract.
> * The implementing class must have a default public constructor.
> * The implementing class must not define the finalize method.
> * The implementing class may use the javax.annotation.PostConstruct or  
> javax.annotation.PreDestroy annotations on its methods for lifecycle  
> event callbacks.
>
> The @PostConstruct method is called by the container before the  
> implementing class begins responding to web service clients.
>
> The @PreDestroy method is called by the container before the endpoint  
> is removed from operation.
> ---
>
> The classes generated by deftype are final; the javap output is
>
> ---
> public final class com.example.FooBarService extends java.lang.Object  
> implements com.example.FooBarInterface{
>    public static {};
>    public com.example.FooBarService();
>    public java.lang.String createCustomer(java.lang.String,  
> java.lang.String, java.lang.String);}
>
> ---
>
> That doesn't make JAX-WS's tools happy:
>

What are you going to do about:

default public constructor?

Remember that deftype is not primarily an interop feature. It's not
going to become Java-in-parens, as that doesn't add much value over
Java for the significant complexity it introduces into Clojure.

While non-final seems small, I'm concerned that accommodating various
interop requirements (many of which are horrid) will complicate
deftype, and the lives of its users.

Rich

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Insert into an indexed seq

[Rich Hickey]

On Apr 27, 2010, at 2:45 PM, Sean Devlin wrote:


You're right, inserting into a vector is fundamentally slow.
Inserting into a list (must traverse elements) or String (Char Array)
isn't any better.  I get why Clojure doesn't include certain
operations on certain data structures (e.g. assoc on a list), because
it's the wrong tool for the job. However, there are still problems
that require me to use an expensive operation.

Maybe I'm too focused on my current project, and wrong about how much
a typical person would use insert.  Still, its absence seems like an
oversight.



What are missing are finger trees, as Chouser said. Not having insert  
on vector is not an oversight.


Rich


Sean

On Apr 27, 2:05 pm, Chouser  wrote:
On Tue, Apr 27, 2010 at 1:31 PM, Sean Devlin  
 wrote:

Is there a built in to insert a value into an "indexed" seq?



For example:



user=> (insert [:a :b :c :d] 2 :q)
(:a :b :q :c :d)



Not sure if I'm missing something simple...


That's a vector, which cannot efficiently splice internally, so
it's not supported directly.  However, you can build a new vector
with your value included:

  (apply conj [:a :b] :q [:c :d])
  ;=> [:a :b :q :c :d]


Also, why does this work:
user=> (assoc [:a :b :c :d] 2 :q)
[:a :b :q :d]



And this doesn't:
user=> (dissoc [:a :b :c :d] 2)
#



Annoying.


Again, vectors cannot efficiently insert or remove items except
from the right-hand end, though as you note items can replaced
internally.

  (let [v [:a :b :c :d]]
(into (subvec v 0 2) (subvec v 3)))
  ;=> [:a :b :d]

There are immutable collections that support both numeric-indexed
lookups and internal splicing, they're just not currently included
with Clojure.  See for example finger trees:

   http://functionaljava.googlecode.com/svn/artifacts/2.21/javadoc/fj/da 
...


--Chouserhttp://joyofclojure.com/

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group 
athttp://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


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

Can't figure out how to use binding

[SpiderPig]

Hi,
I wrote this code to redirect a repl to a JFrame.
I used the JConsole class from Beanshell

(def console (bsh.util.JConsole.))
(def frame (doto (javax.swing.JFrame.) (.add console) (.setSize 500
500) (.setVisible true) ))

(binding [*out* (java.io.OutputStreamWriter. (.getOut console))]
 [*in* (clojure.lang.LineNumberingPushbackReader. (.getIn
console))]
 (.start (Thread. #(clojure.main/repl

But it doesn't work. *in* and *out* are not redirected.

If I change the last line from
(.start (Thread. #(clojure.main/repl
to
(clojure.main/repl)

then *out* gets redirected but not *in*
Am I doing something wrong here?

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

Testing equality

[WoodHacker]

Can someone explain to me why this doesn't work:

  (let [ p "Bill/"
  sep (System/getProperty "file.separator")
   ]

  (if (= (last p) sep)
  (println "found separator")
  (println "no separator")
  )

The (= (last p) sep) always returns false.   If I print them out
inside pipes they look like
| / | and | / | (white space on either side of the slash).

Is this some sort of bug?   Is there a better solution for finding a
file separator at the end of a line?

Bill




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

Re: Testing equality

[David Nolen]

On Wed, Apr 28, 2010 at 9:30 AM, WoodHacker  wrote:

> Can someone explain to me why this doesn't work:
>
>  (let [ p "Bill/"
>  sep (System/getProperty "file.separator")
>   ]
>
>  (if (= (last p) sep)
>  (println "found separator")
>  (println "no separator")
>  )


(last p)

Will return a char, while

(System/geProperty "file.separator")

returns a string.

(= (str \/) "/") ; true

David

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

Re: Testing equality

[Teemu Antti-Poika]

On Apr 28, 4:30 pm, WoodHacker  wrote:
> Can someone explain to me why this doesn't work:
>
>   (let [ p     "Bill/"
>           sep (System/getProperty "file.separator")
>            ]
>
>       (if (= (last p) sep)
>           (println "found separator")
>           (println "no separator")
>   )
>
> The (= (last p) sep) always returns false.   If I print them out
> inside pipes they look like
> | / | and | / | (white space on either side of the slash).
>
> Is this some sort of bug?   Is there a better solution for finding a
> file separator at the end of a line?

In the above p is a character /, and sep is a string of one char "/",
therefore they are not equal.

Maybe you should use String's endsWith?

(.endsWith "bill/" (System/getProperty "file.separator"))

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

Re: Can't figure out how to use binding

[Meikel Brandmeyer]

Hi,

On 28 Apr., 01:52, SpiderPig  wrote:

>      (.start (Thread. #(clojure.main/repl

bindings are thread-local. So your in/out bindings are not
valid in the new thread. Try the following:

(.start (Thread. (bound-fn [] (clojure.main/repl)))

Sincerely
Meikel

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

Re: Testing equality

[Adrian Cuthbertson]

(last p) returns a char \/
(first p) returns \B)

so, use (= (str (last p)) sep)

-Rgds, Adrian.

On Wed, Apr 28, 2010 at 3:30 PM, WoodHacker  wrote:
> Can someone explain to me why this doesn't work:
>
>  (let [ p     "Bill/"
>          sep (System/getProperty "file.separator")
>           ]
>
>      (if (= (last p) sep)
>          (println "found separator")
>          (println "no separator")
>  )
>
> The (= (last p) sep) always returns false.   If I print them out
> inside pipes they look like
> | / | and | / | (white space on either side of the slash).
>
> Is this some sort of bug?   Is there a better solution for finding a
> file separator at the end of a line?
>
> Bill
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Testing equality

[Mike DeLaurentis]

Depending on what you're trying to do with paths, you may want to construct
File objects and then get the paths from them.  For example,

(let [home (File. "/Users/Bill")
bashrc (File . home ".bashrc")]
  (.getPath bashrc))

I think that tends to be less cumbersome than stringing path components
together directly.


On Wed, Apr 28, 2010 at 9:37 AM, Teemu Antti-Poika wrote:

>
>
> On Apr 28, 4:30 pm, WoodHacker  wrote:
> > Can someone explain to me why this doesn't work:
> >
> >   (let [ p "Bill/"
> >   sep (System/getProperty "file.separator")
> >]
> >
> >   (if (= (last p) sep)
> >   (println "found separator")
> >   (println "no separator")
> >   )
> >
> > The (= (last p) sep) always returns false.   If I print them out
> > inside pipes they look like
> > | / | and | / | (white space on either side of the slash).
> >
> > Is this some sort of bug?   Is there a better solution for finding a
> > file separator at the end of a line?
>
> In the above p is a character /, and sep is a string of one char "/",
> therefore they are not equal.
>
> Maybe you should use String's endsWith?
>
> (.endsWith "bill/" (System/getProperty "file.separator"))
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Questions about program design

[Andrew Brookins]

On Tue, Apr 27, 2010 at 10:21 AM, Miki  wrote:
> Hello Andrew,
>
>> So, for people like me, can any of you suggest some transcribed
>> lectures, screencasts, books, blog posts, or other errata that discuss
>> the difference between program design in a language like Clojure and
>> an OO language like Ruby or Java?
> Two books that helped me are 
> http://mitpress.mit.edu/sicp/full-text/book/book.html
> and http://www.paulgraham.com/onlisptext.html
>
> HTH
> --
> Miki
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

Thanks, Miki.  I've been reading Paul Graham's essays lately, and I
did not realize that a book was available.  Good stuff.

Andrew

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

Re: beginer jedit problem

[Chris Perkins]

On Apr 28, 4:56 am, Marko Srepfler  wrote:
> C:\clojure-1.1.0>java -cp jline-0.9.91.jar:clojure.jar

You need to separate your classpath entries with a semicolon, not a
colon.

- Chris Perkins

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

Re: Defining a namespace inside a let

[Nate Young]

On Apr 26, 5:25 pm, David McNeil  wrote:
> I am experimenting with clojure.test and I encountered the following
> situation which I cannot explain.
>
> This code:
>
> (println (do
>            (ns ns01
>              (:use clojure.test))
>            (deftest test1 nil)
>            (run-tests)))
>
> Produces the expected result (note: it runs one test):
This is actually NOT what I'm seeing.  At least when I run it, it
appears to run exactly zero tests.

> [snip]
>
> (println (let []
>            (do
>              (ns ns02
>                (:use clojure.test))
>              (deftest test1 nil)
>              (run-tests
>
> Then I get the unexpected result that no tests are executed:
The let here is, I believe a red herring.  Again, with what I'm
seeing, this form executes the same way as the above and runs exactly
zero tests.

> Seems there is something going on with namespaces that I do not
> understand and I hope that somewhere here can explain it.
I think I can explain the above behavior and suggest a way to obtain
the behavior you want.
I don't think it has as much to do with namespaces as it does with the
evaluation rule and it's relationship to def.

You've defined a do, which will execute each of the forms in turn, but
the deftest (a macro which expands to a def form) creates it's test
function in the namespace that the do was executed in, not the
namespace created and switched to just previously.

In fact, if you check your namespace, you should see that test1 is
defined not in ns01/ns02, but in user (or whichever namespace you
executed the do from).

What I can't sufficiently explain is why def doesn't see the binding
of *ns* but run-tests obviously does, as it tries to find all tests
defined in ns01/ns02 (of which there are none).
(println (do
   (ns ns03
 (:use clojure.test))
   (binding [*ns* (find-ns 'ns03)]
 (deftest test3 nil))
   (run-tests)))

Now, when the do evaluates the second form, it uses the namespace that
was created by the first form.

Hope this helps.

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

Re: Serializable Collections ?

[Jules]

Brian,

Thanks for getting back to me :-)

I look forward to your changes making it into the mainline.

I'm going to register with Assembla and watch this ticket. If I find a
way to vote for it, I will do.

Jules


On Apr 27, 3:59 pm, Brian Hurt  wrote:
> On Tue, Apr 27, 2010 at 9:10 AM, Jules  wrote:
> > Guys,
>
> > I've searched the group and cannot find an answer to this one...
>
> > Why are many of the more common collection types in Clojure not
> > Serializable :
>
> I have an assemblia ticket open on this 
> issue:https://www.assembla.com/spaces/clojure/tickets/281-make-more-datastr...
>
> I need to finish a new version of the patch that more carefully controls
> what is serialized.
>
> Brian
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: deftype and final classes

[Richard Newman]

What are you going to do about:

default public constructor?


The JAX-WS tools don't really care if javac generates a default  
constructor or if Clojure does. The deftype constructor with no fields  
defined is:


   public com.example.FooBarService();

which -- assuming it calls super() and initializes any instance vars  
-- is identical to the constructor that javac would produce.


wsgen runs without complaint once the class is declared non-final, so  
I assume it's happy with what Clojure produces.




Remember that deftype is not primarily an interop feature. It's not
going to become Java-in-parens, as that doesn't add much value over
Java for the significant complexity it introduces into Clojure.


Understood.



While non-final seems small, I'm concerned that accommodating various
interop requirements (many of which are horrid) will complicate
deftype, and the lives of its users.


I would personally draw that line at "anything which can't be defined  
simply in an option, or which breaks the contract between a def'ed  
type and the rest of Clojure".


For example, if deftype required a finalizer to work with the Clojure  
runtime, I'd give up. Similarly, if some other part of Clojure  
demanded that all def'ed types must be implemented as final classes,  
I'd settle for gen-class.


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

Reading properties file the proper way

[K.]

Hello,

What is the best way to read a property file in a path independent
way? I would like to be able to read the file and this regardless of
where my clojure program is called from (this must also work if my
program is bundled as a jar).

clojure.contrib.java-utils/read-properties is nice but it takes a
file, how could a relative file be expressed relatively to a namespace
name, project root directory or relatively to a clojure file?

I did try with ClassLoader/getSystemResourceAsStream :

(defn- read-properties
 "Read properties from filename. Filename is searched in the
classpath"
   ;; see also clojure.contrib.java-utils
   [filename]
   (with-open [b (ClassLoader/getSystemResourceAsStream filename)]
 (doto (java.util.Properties.)
   (.load b

It works fine and you can specify a filename relatively to a namespace
like this : "namespace/myconfig.properties".

However this breaks with "lein swank" since lein swank uses its own
classloader.

What is the best solution?

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

Re: Reading properties file the proper way

[Phil Hagelberg]

On Wed, Apr 28, 2010 at 10:01 AM, K.  wrote:
> I did try with ClassLoader/getSystemResourceAsStream :
>
> However this breaks with "lein swank" since lein swank uses its own
> classloader.

The problem with this is that it's using the System classloader. Try
using the thread's classloader:

(into {} (doto (java.util.Properties.)
   (.load (-> (Thread/currentThread)
  (.getContextClassLoader)
  (.getResourceAsStream "log4j.properties")

Also note that Properties are j.u.Maps, so they can be put into Clojure maps.

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

Re: ClojureCLR start-up time

[Joerthan Panest]

Defining CLR2 in release on the new2 branch allowed me to compile
without issue.

I still have the several second delay, and from what little I kind
find around I suppose that is typical. Is that correct? Is there any
way to bring that down?

Thank you,
Joerthan

On Apr 23, 9:45 pm, dmiller  wrote:
> I haven't compiled under a release in a while.  Recent changes to the
> build system may have messed it up.  I'll check it out.
>
> David
>
> On Apr 23, 2:11 am, Joerthan Panest  wrote:
>
>
>
> > Hello,
>
> > I am considering ClojureCLR for embedding in an application, but it appears
> > as though it takes ~4secs to start up. Is this typical? Is there a way to
> > speed up? I realize that this could be hidden by opening it in a background
> > process and leaving it open but I can see where that is less than ideal in
> > some situations.
>
> > I also noticed that the current development environment has many references
> > to Debug bin settings and a short attempt to get it in Release mode failed
> > with a number of errors. Is this due to the nature of the required run-time
> > information or simply because it is still a Beta?
>
> > Thank you,
> > Joerthan
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 
> > athttp://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

seq fns promoted to clojure.core!

[Stuart Halloway]

Several clojure.contrib.seq/seq-utils functions have been promoted  
(with some modification) to clojure.core.


Here's the super-terse summary from the code comment:

;;   moved to clojure.core: flatten, partition-all, frequencies,
;;  reductions, shuffle, partition-by
;;   moved with semantic changes:
;; group-by now returns an *unsorted* map
;;   moved with name changes:
;; rand-elt => clojure.core/rand-nth
;; includes? => clojure.core/seq-contains?

I am standing by in IRC to answer questions you may have, and will be  
following this email one with a longer one detailing the rationale for  
these changes.


Thanks!

Stu

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

clojure 1.2 seq fn enhancement FAQ

[Stuart Halloway]

After review, several seq functions from clojure-contrib have been  
promoted to clojure [1], [2], [3]. Hopefully the FAQ below will answer  
the major questions you may have:


1. Is this a breaking change to Clojure?
No. Rich is super-careful to grow Clojure by expansion, not by  
breaking change.


2. Is this a breaking change to Contrib?
Yes. Contrib is a community-contribution area. Part of its mission is  
to germinate ideas that may get promoted to Clojure, and when that  
happens contrib users will have to adapt. Usually this will simply  
mean removing a require/use, or changing a fn name.


3. Why did some of the fn names change?
Because they were bad names. :-) Clojure is careful to encourage the  
use of fns that will have good performance characteristics, and make  
it obvious which fns are "seq-y" (therefore O(n)). rand-elt became  
rand-nth to make it clear that its performance is bound to the  
performance of nth on the underlying collection. Similarly, includes?  
became seq-contains? to make clear that the fn must walk the sequence.  
Avoid seq-contains? when you have a set or map!


4. Why did some semantics change?
Because they were not the most generally-desirable semantics. The  
contrib group-by returned a sorted map, when in most cases sorting is  
overkill, so the new core fn returns a plain ol' map.


5. Couldn't you have left the old fns in place in contrib, to avoid  
breakage?
No, for multiple reasons. Name collisions are one. But the bigger one  
is that the fns in core have been audited by Rich for performance and  
correctness. Leaving the old fns in contrib would be a recipe for  
lower-performing (or even, in rare cases, buggy) programs.


6. Why did this break my project?
Hopefully it doesn't. But, it seems that a lot of people are tracking  
their apps (via leiningen or maven) to build snapshots of both Clojure  
and Contrib. This is a risky development practice, particularly in the  
case of Contrib. As a community, we need to develop a saner way to  
stay near the edge without being right on it.


7. How do I fix it?
Your code gets smaller. Remove requires or uses that refer to promoted  
fns. You already have them in core! For the fns whose names have  
changed, update the names in your code.


Comments and questions welcome!

Stu

[1] 
https://www.assembla.com/spaces/clojure/tickets/312-audit---promote-some-clojure-contrib-seq-fns
[2] 
http://github.com/richhickey/clojure/tree/a55df92faa0c51c634d93a8d991ccfd2638b108b
[3] 
http://github.com/richhickey/clojure-contrib/commit/78ee9b3e64c5ac6082fb223fc79292175e8e4f0c

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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 4:31 PM, Stuart Halloway wrote:

After review, several seq functions from clojure-contrib have been  
promoted to clojure [1], [2], [3]. Hopefully the FAQ below will  
answer the major questions you may have:


Cool!


3. Why did some of the fn names change?
...Similarly, includes? became seq-contains? to make clear that the  
fn must walk the sequence. Avoid seq-contains? when you have a set  
or map!


Wait, what? Why should seq-contains? be slower than contains? Isn't  
this exactly the kind of thing that protocols are supposed to be  
solving? Your nice video showed that very thing, right?





6. Why did this break my project?
Hopefully it doesn't. But, it seems that a lot of people are  
tracking their apps (via leiningen or maven) to build snapshots of  
both Clojure and Contrib. This is a risky development practice,  
particularly in the case of Contrib. As a community, we need to  
develop a saner way to stay near the edge without being right on it.


Indeed. Tracking the bleeding edge is always dicey... :-(

Thanks!

-Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Meikel Brandmeyer]

Hi,

On Wed, Apr 28, 2010 at 05:06:21PM -0400, Douglas Philips wrote:

> Wait, what? Why should seq-contains? be slower than contains? Isn't
> this exactly the kind of thing that protocols are supposed to be
> solving? Your nice video showed that very thing, right?

If you have a map or a set looking up a key is fast. So contains? is
fast (read O(1) resp. something like O(log32 N)). seq-contains? does
a linear search through a sequence. That is O(N). Protocols cannot
change this.

Sincerely
Meikel

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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 5:14 PM, Meikel Brandmeyer wrote:

If you have a map or a set looking up a key is fast. So contains? is
fast (read O(1) resp. something like O(log32 N)). seq-contains? does
a linear search through a sequence. That is O(N). Protocols cannot
change this.


How is having an optimized version of seq-contains? for sets/maps any  
different from what Stuart showed in his video, where reduce can have  
a specialization that is faster on some types?


-Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Meikel Brandmeyer]

Hi,

On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:

> How is having an optimized version of seq-contains? for sets/maps
> any different from what Stuart showed in his video, where reduce can
> have a specialization that is faster on some types?

A faster reduce is still O(N). If you need fast lookup use the correct
data structure. If you do linear search it's gonna be slow, so make it
clear in the code! This makes the developer aware of the implications.

Sincerely
Meikel

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

constructing a lazy sequence from a Java API that returns pages of data

[.Bill Smith]

I have a Java API that retrieves "pages" of data from a database: you
specify the page number and the page size, it it retrieves row numbers
page-number*page_size  through (page-number+1)*page_size - 1.  I'd
like to construct a lazy sequence that gets its data using that Java
API.  I'm using Clojure 1.1.  I would prefer not to use 1.2 until it's
released.  I suspect there's a posting or web page somewhere that lays
out the general template for doing this kind of thing.  Anyone have
any suggestions?

Thanks,
Bill Smith
Austin, TX

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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 5:32 PM, Meikel Brandmeyer wrote:

On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:


How is having an optimized version of seq-contains? for sets/maps
any different from what Stuart showed in his video, where reduce can
have a specialization that is faster on some types?


A faster reduce is still O(N). If you need fast lookup use the correct
data structure. If you do linear search it's gonna be slow, so make it
clear in the code! This makes the developer aware of the implications.



Stuart's comment was to not use seq-contains? on maps or sets.
There is no reason that it cannot be the same speed as contains? if a  
set or map is passed in.
Wasn't the whole point of having sequences as an abstraction to get  
away from all the cruft that traditional lisp had built up around  
concrete types? Why go back to that here? Can't protocols handle  
optimizing this case?
If some function I call uses seq-contains? (so that it can get all the  
wonderful seq-ness abstractness clojure offers) I should have to know  
that internal detail and not pass in a map or set? or worse, fail to  
get an optimization in that case? C'mon, this should be an easy  
protocol win (or maybe I don't really understand the limits on what  
protocols can do.)


-Doug


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

Re: constructing a lazy sequence from a Java API that returns pages of data

[ataggart]

(defn pages
  ([src size] (pages src 0 size))
  ([src start size]
(lazy-seq
  (if-let [page (.getPage src start size)]
(cons page (pages src (inc start) size))

On Apr 28, 2:38 pm, ".Bill Smith"  wrote:
> I have a Java API that retrieves "pages" of data from a database: you
> specify the page number and the page size, it it retrieves row numbers
> page-number*page_size  through (page-number+1)*page_size - 1.  I'd
> like to construct a lazy sequence that gets its data using that Java
> API.  I'm using Clojure 1.1.  I would prefer not to use 1.2 until it's
> released.  I suspect there's a posting or web page somewhere that lays
> out the general template for doing this kind of thing.  Anyone have
> any suggestions?
>
> Thanks,
> Bill Smith
> Austin, TX
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: clojure 1.2 seq fn enhancement FAQ

[Meikel Brandmeyer]

Hi,

On Wed, Apr 28, 2010 at 05:39:37PM -0400, Douglas Philips wrote:

> Stuart's comment was to not use seq-contains? on maps or sets.
> There is no reason that it cannot be the same speed as contains? if
> a set or map is passed in.

Ah, ok. I misunderstood what you were saying. But I think it doesn't
change the argumentation. If seq-contains? was fast on maps and sets,
people would abandon contains? because seq-contains? is "always right":
works on seqs, fast on maps and sets. And again we are in the situation,
that the developer does not make his intentions explicit.

Sincerely
Meikel

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

Re: clojure 1.2 seq fn enhancement FAQ

[Stuart Halloway]

The "seq" in "seq-contains?" says "I want a sequential search."  
Protocols *could* make this do something different, but that would  
violate the contract of this function.


Another way to put it: If you wrote a protocol to pick a fast  
implementation based on type, then seq-contains? would be the fn that  
the protocol would call if it couldn't find anything faster.


There have to be primitive things somewhere...

Stu


On 2010 Apr 28, at 5:32 PM, Meikel Brandmeyer wrote:

On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:


How is having an optimized version of seq-contains? for sets/maps
any different from what Stuart showed in his video, where reduce can
have a specialization that is faster on some types?


A faster reduce is still O(N). If you need fast lookup use the  
correct
data structure. If you do linear search it's gonna be slow, so make  
it
clear in the code! This makes the developer aware of the  
implications.



Stuart's comment was to not use seq-contains? on maps or sets.
There is no reason that it cannot be the same speed as contains? if  
a set or map is passed in.
Wasn't the whole point of having sequences as an abstraction to get  
away from all the cruft that traditional lisp had built up around  
concrete types? Why go back to that here? Can't protocols handle  
optimizing this case?
If some function I call uses seq-contains? (so that it can get all  
the wonderful seq-ness abstractness clojure offers) I should have to  
know that internal detail and not pass in a map or set? or worse,  
fail to get an optimization in that case? C'mon, this should be an  
easy protocol win (or maybe I don't really understand the limits on  
what protocols can do.)


-Doug


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 6:10 PM, Stuart Halloway wrote:

The "seq" in "seq-contains?" says "I want a sequential search."  
Protocols *could* make this do something different, but that would  
violate the contract of this function.


How would having it work faster if passed a set or map violate that?  
There is no ordering guarantee for those types. Is this a contract to  
be slow? Is there something about the comparison being done by seq- 
contains? that is different from contains? would seq-contains? somehow  
return a different answer? And what about the sorted collections,  
where seq-contains? could be fast if the value sought was smaller or  
larger than the values contained?


I don't see the distinction(s) you're trying to make here.


Another way to put it: If you wrote a protocol to pick a fast  
implementation based on type, then seq-contains? would be the fn  
that the protocol would call if it couldn't find anything faster.


There have to be primitive things somewhere...


If so, then why isn't there a vector-first and a list-first and abc- 
first that I can use when I 'know' what type I'm working with?


Aren't they all subsumed under 'first' because Clojure understands  
that premature optimization based on concrete types was the wrong  
thing to do? At least that is the message I got from Rich's videos  
explaining why tying all of the "old" lisp goodness to concrete types  
was wrong (unnecessarily limiting).


   -Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Stuart Halloway]

Another way to put it: If you wrote a protocol to pick a fast  
implementation based on type, then seq-contains? would be the fn  
that the protocol would call if it couldn't find anything faster.


There have to be primitive things somewhere...


If so, then why isn't there a vector-first and a list-first and abc- 
first that I can use when I 'know' what type I'm working with?


Specializations are available where there is a clear use case, e.g.  
contains?, peek (instead of last), disj, etc.


Aren't they all subsumed under 'first' because Clojure understands  
that premature optimization based on concrete types was the wrong  
thing to do? At least that is the message I got from Rich's videos  
explaining why tying all of the "old" lisp goodness to concrete  
types was wrong (unnecessarily limiting).


Tying to concrete types is limiting. *Never* having special purpose  
fns that know about performance characteristics is also limiting.


contains?/seq-contains? mark a divide where it is very easy for a  
language to quietly help programmers do the wrong thing.


Stu


  -Doug

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
Specializations are available where there is a clear use case, e.g.  
contains?, peek (instead of last), disj, etc.

...
Tying to concrete types is limiting. *Never* having special purpose  
fns that know about performance characteristics is also limiting.


contains?/seq-contains? mark a divide where it is very easy for a  
language to quietly help programmers do the wrong thing.


Such as littering my application code with type-checks to decide if it  
should call contains? or seq-contains?

That seems exactly the wrong thing to do.

Please explain how making seq-contains? fast for sets and maps is  
wrong (exactly how does it violate some contract and what contract,  
explicitly is that a violation of) and application code type checking  
is right, because I really don't understand why making seq-contains?  
fast isn't just a huge win-win.


-Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 6:06 PM, Meikel Brandmeyer wrote:

Ah, ok. I misunderstood what you were saying. But I think it doesn't
change the argumentation. If seq-contains? was fast on maps and sets,
people would abandon contains? because seq-contains? is "always  
right":
works on seqs, fast on maps and sets. And again we are in the  
situation,

that the developer does not make his intentions explicit.


What is the intention to be made exlicit here? That some sequences are  
better than others? (car/cdr/list from old-school lisps were exactly  
this kind of thinking, whether deliberate or not.)


How is it a developer is supposed to say: "only use a set or map" here?
I'm new enough to Clojure that I'm not clear on how duck-type-y the  
idioms are.

Should I use assert to make my intention clear?
raise an exception?
just call some function that cares and expect that it will either  
assert or raise for me?
Isn't this just the kind of thing that protocols are for? Again, I  
think Stuarts video example with reduce is quite apropos. For certain  
things, we can make some operations faster, and we can do it, post- 
facto, wihin clojure itself.


-Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Mark Engelberg]

On Wed, Apr 28, 2010 at 2:39 PM, Douglas Philips  wrote:
> If some function I call uses seq-contains? (so that it can get all the 
> wonderful seq-ness abstractness clojure offers) I should have to know that 
> internal detail and not pass in a map or set? or worse, fail to get an 
> optimization in that case? C'mon, this should be an easy protocol win (or 
> maybe I don't really understand the limits on what protocols can do.)

Doug, I also am not particularly enamored of the name seq-contains?  I
agree that it conjures up notions of Scheme's proliferation of names
like list-ref, vector-ref, string-ref, etc.

But I think you're not fully appreciating the complexity of the
situation.  This is not just about performance, but a question of two
different possible semantics for "contains?", which is why it can't
*only* be addressed with a protocol.

The fundamental problem is that some Clojure data structures have a
dual nature.  For example, a vector can be thought of as a collection
of items, or you can think of it as a mapping from integers to items.
A hash map can be thought of as a map, or as a sequence of key-value
pairs.

The current "contains?" function is really a "contains-key?" function.
 It treats the input as a data structure with keys (a map or a set),
and asks whether it contains a given key.  This has been a tremendous
source of confusion to some people who apply the contains? function to
a vector, and are startled to discover that it is only asking whether
the item is a *key* in the vector, (i.e., in the case of a vector, a
valid index between 0 and length-1).  Arguably, contains-key? would
have been a much better name, and made the semantics much more clear.

There are some people who believe that Clojure would benefit from a
variant of "contains?" that views the input as a collection.  But how
to make this clear?  That's why the proposal is for a new function
called "seq-contains?".  It's not so much a warning of "this thing has
performance like a linear search", as much as, "it views your data as
a sequence".  So for example, calling seq-contains? on a vector will
actually test whether the item is an element of the vector collection.
 Calling seq-contains? on a map will actually test whether a given
[key value] pair is in the map (rather than just testing for the
existence of a key).

So what are some other options?:

1.  Don't include seq-contains?  The behavior you want can usually be
achieved by using (some #{item} coll).  Disadvantage - if you're
testing to see if the collection contains nil, that won't work.
2.  Rename contains? to contains-key? and make a function with the new
semantics called contains?  Disadvantage - breaks existing code.
3.  Keep one function called contains?, but use protocols to achieve
different semantics for different kind of data structures.  So for
sets and maps, contains? would work like a contains-key? function, but
for vectors and other sequences, it would be a more intuitive
contains-item? function.  Disadvantage - semantics depends on knowing
what kind of thing you're passing to the function, also might break
existing code if anyone is actually currently using contains? on
vectors.

I'm not crazy about the name seq-contains? (and I'm skeptical that it
even belongs in the core), but all the other solutions I can think of
also have major disadvantages.

That said, you make an excellent point about performance.  Even though
the new seq-contains? is intended to treat the underlying data
structure as a sequence from a semantics standpoint, there is
absolutely no reason at all why its performance should be bound by
this.  Clearly contains? and seq-contains? have identical semantics
for a set, so for a set data structure the new seq-contains? should
also use protocols to achieve the same speed, so seq-contains?
performs identically on a set as contains?  Similarly, even though the
new seq-contains? will have a new meaning for hash maps (testing for a
key-value pair rather than just a key), clearly it is possible to use
protocols to perform this test far faster than a linear sequential
search.

So, if things do move forward with seq-contains? to create a new
semantic notion in the clojure core of how to test for containment, I
absolutely agree that protocols should be used to make this new notion
to continue to have good performance on those sorts of collections for
which it is possible to have superior performance than a sequential
search.

--Mark

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

Re: seq fns promoted to clojure.core!

[liebke]

Unfortunately, group-by is a commonly used function name, used in both
Incanter and swank-clojure. I've renamed Incanter's group-by to group-
on, but the naming conflict of clojure.core/group-by and swank-
clojure.util/group-by is preventing swank from starting up using
either lein swank or the swank scripts included with Labrepl and
Incanter. I'm dead in the water, any suggested work arounds?

David


On Apr 28, 4:01 pm, Stuart Halloway  wrote:
> Several clojure.contrib.seq/seq-utils functions have been promoted  
> (with some modification) to clojure.core.
>
> Here's the super-terse summary from the code comment:
>
> ;;   moved to clojure.core: flatten, partition-all, frequencies,
> ;;                          reductions, shuffle, partition-by
> ;;   moved with semantic changes:
> ;;     group-by now returns an *unsorted* map
> ;;   moved with name changes:
> ;;     rand-elt => clojure.core/rand-nth
> ;;     includes? => clojure.core/seq-contains?
>
> I am standing by in IRC to answer questions you may have, and will be  
> following this email one with a longer one detailing the rationale for  
> these changes.
>
> Thanks!
>
> Stu
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: clojure 1.2 seq fn enhancement FAQ

[Stuart Halloway]

Wow, and I thought this was a sore subject before, when there was no  
seq-contains? and its absence was always a Top 5 FAQ. :-)


I'll wait for Rich to maybe chime in on seq-contains?. Other than seq- 
contains? are people liking the new fns? Anybody having issues we  
didn't anticipate?


Stu


On Wed, Apr 28, 2010 at 2:39 PM, Douglas Philips  wrote:
If some function I call uses seq-contains? (so that it can get all  
the wonderful seq-ness abstractness clojure offers) I should have  
to know that internal detail and not pass in a map or set? or  
worse, fail to get an optimization in that case? C'mon, this should  
be an easy protocol win (or maybe I don't really understand the  
limits on what protocols can do.)


Doug, I also am not particularly enamored of the name seq-contains?  I
agree that it conjures up notions of Scheme's proliferation of names
like list-ref, vector-ref, string-ref, etc.

But I think you're not fully appreciating the complexity of the
situation.  This is not just about performance, but a question of two
different possible semantics for "contains?", which is why it can't
*only* be addressed with a protocol.

The fundamental problem is that some Clojure data structures have a
dual nature.  For example, a vector can be thought of as a collection
of items, or you can think of it as a mapping from integers to items.
A hash map can be thought of as a map, or as a sequence of key-value
pairs.

The current "contains?" function is really a "contains-key?" function.
It treats the input as a data structure with keys (a map or a set),
and asks whether it contains a given key.  This has been a tremendous
source of confusion to some people who apply the contains? function to
a vector, and are startled to discover that it is only asking whether
the item is a *key* in the vector, (i.e., in the case of a vector, a
valid index between 0 and length-1).  Arguably, contains-key? would
have been a much better name, and made the semantics much more clear.

There are some people who believe that Clojure would benefit from a
variant of "contains?" that views the input as a collection.  But how
to make this clear?  That's why the proposal is for a new function
called "seq-contains?".  It's not so much a warning of "this thing has
performance like a linear search", as much as, "it views your data as
a sequence".  So for example, calling seq-contains? on a vector will
actually test whether the item is an element of the vector collection.
Calling seq-contains? on a map will actually test whether a given
[key value] pair is in the map (rather than just testing for the
existence of a key).

So what are some other options?:

1.  Don't include seq-contains?  The behavior you want can usually be
achieved by using (some #{item} coll).  Disadvantage - if you're
testing to see if the collection contains nil, that won't work.
2.  Rename contains? to contains-key? and make a function with the new
semantics called contains?  Disadvantage - breaks existing code.
3.  Keep one function called contains?, but use protocols to achieve
different semantics for different kind of data structures.  So for
sets and maps, contains? would work like a contains-key? function, but
for vectors and other sequences, it would be a more intuitive
contains-item? function.  Disadvantage - semantics depends on knowing
what kind of thing you're passing to the function, also might break
existing code if anyone is actually currently using contains? on
vectors.

I'm not crazy about the name seq-contains? (and I'm skeptical that it
even belongs in the core), but all the other solutions I can think of
also have major disadvantages.

That said, you make an excellent point about performance.  Even though
the new seq-contains? is intended to treat the underlying data
structure as a sequence from a semantics standpoint, there is
absolutely no reason at all why its performance should be bound by
this.  Clearly contains? and seq-contains? have identical semantics
for a set, so for a set data structure the new seq-contains? should
also use protocols to achieve the same speed, so seq-contains?
performs identically on a set as contains?  Similarly, even though the
new seq-contains? will have a new meaning for hash maps (testing for a
key-value pair rather than just a key), clearly it is possible to use
protocols to perform this test far faster than a linear sequential
search.

So, if things do move forward with seq-contains? to create a new
semantic notion in the clojure core of how to test for containment, I
absolutely agree that protocols should be used to make this new notion
to continue to have good performance on those sorts of collections for
which it is possible to have superior performance than a sequential
search.

--Mark

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with

Re: seq fns promoted to clojure.core!

[Phil Hagelberg]

On Wed, Apr 28, 2010 at 4:43 PM, liebke  wrote:
> Unfortunately, group-by is a commonly used function name, used in both
> Incanter and swank-clojure. I've renamed Incanter's group-by to group-
> on, but the naming conflict of clojure.core/group-by and swank-
> clojure.util/group-by is preventing swank from starting up using
> either lein swank or the swank scripts included with Labrepl and
> Incanter. I'm dead in the water, any suggested work arounds?

I just pushed an fixed swank to clojars a few minutes ago; this should
solve the issue. Swank's old definition is basically the same as the
one in core modulo some transient use, so swank now falls back to its
own definition only if it's not defined in clojure.core.

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

Re: seq fns promoted to clojure.core!

[Stuart Halloway]

One option is to configure lein to use a specific timestamp instead of  
snapshot. Then you can back off the edge a little.


Stu


Unfortunately, group-by is a commonly used function name, used in both
Incanter and swank-clojure. I've renamed Incanter's group-by to group-
on, but the naming conflict of clojure.core/group-by and swank-
clojure.util/group-by is preventing swank from starting up using
either lein swank or the swank scripts included with Labrepl and
Incanter. I'm dead in the water, any suggested work arounds?

David


On Apr 28, 4:01 pm, Stuart Halloway  wrote:

Several clojure.contrib.seq/seq-utils functions have been promoted
(with some modification) to clojure.core.

Here's the super-terse summary from the code comment:

;;   moved to clojure.core: flatten, partition-all, frequencies,
;;  reductions, shuffle, partition-by
;;   moved with semantic changes:
;; group-by now returns an *unsorted* map
;;   moved with name changes:
;; rand-elt => clojure.core/rand-nth
;; includes? => clojure.core/seq-contains?

I am standing by in IRC to answer questions you may have, and will be
following this email one with a longer one detailing the rationale  
for

these changes.

Thanks!

Stu

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group 
athttp://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient  
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


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

Re: seq fns promoted to clojure.core!

[Phil Hagelberg]

On Wed, Apr 28, 2010 at 4:50 PM, Stuart Halloway
 wrote:
> One option is to configure lein to use a specific timestamp instead of
> snapshot. Then you can back off the edge a little.

Yeah, using Clojure version "1.2.0-master-20100426.160114-46" would
allow you to hold off on bringing in the changes until you have time
to devote to tracking down breakages. The matching contrib version is
"1.2.0-20100427.200505-82".

This works for Leiningen, Maven, Ivy, etc; anything that uses the
maven repository format.

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

Re: clojure 1.2 seq fn enhancement FAQ

[Michael Gardner]

On Apr 28, 2010, at 6:38 PM, Mark Engelberg wrote:

> 2.  Rename contains? to contains-key? and make a function with the new
> semantics called contains?  Disadvantage - breaks existing code.

You could also alias contains? to contains-key?, use seq-contains? (or some 
other new name) for this new function, and deprecate contains? with an eye 
towards removal down the road. Deprecation has been used successfully even in 
mature languages, hasn't 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ClojureCLR start-up time

[dmiller]

You're brave being on the new2 branch.  It's pretty raw development in
there.  The current commit is okay, I try to mark the interim ones.

Yes, the CLR2 symbol needs to be defined. That flag became necessary
when they made some incompatible namespace changes in the DLR to
accommodate CLR 2 verus CLR 4.   I'll go back into the builds and make
sure it is there for the release builds.

Startup times have crept up slowly with some of the recent changes in
the compiler.   I have a plan to simplify the loading process.  I've
been avoiding making too many ancillary changes in the compiler while
I've been porting all the compiler changes that went into the 'new'
work on the JVM version.  I'll put startup time improvement next in
the queue.

-David

On Apr 28, 2:28 pm, Joerthan Panest  wrote:
> Defining CLR2 in release on the new2 branch allowed me to compile
> without issue.
>
> I still have the several second delay, and from what little I kind
> find around I suppose that is typical. Is that correct? Is there any
> way to bring that down?
>
> Thank you,
> Joerthan
>
> On Apr 23, 9:45 pm, dmiller  wrote:
>
>
>
> > I haven't compiled under a release in a while.  Recent changes to the
> > build system may have messed it up.  I'll check it out.
>
> > David
>
> > On Apr 23, 2:11 am, Joerthan Panest  wrote:
>
> > > Hello,
>
> > > I am considering ClojureCLR for embedding in an application, but it 
> > > appears
> > > as though it takes ~4secs to start up. Is this typical? Is there a way to
> > > speed up? I realize that this could be hidden by opening it in a 
> > > background
> > > process and leaving it open but I can see where that is less than ideal in
> > > some situations.
>
> > > I also noticed that the current development environment has many 
> > > references
> > > to Debug bin settings and a short attempt to get it in Release mode failed
> > > with a number of errors. Is this due to the nature of the required 
> > > run-time
> > > information or simply because it is still a Beta?
>
> > > Thank you,
> > > Joerthan
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with 
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/clojure?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 
> > athttp://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: clojure 1.2 seq fn enhancement FAQ

[Rich Hickey]

On Apr 28, 7:17 pm, Douglas Philips  wrote:
> On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
>
> > Specializations are available where there is a clear use case, e.g.
> > contains?, peek (instead of last), disj, etc.
> ...
> > Tying to concrete types is limiting. *Never* having special purpose
> > fns that know about performance characteristics is also limiting.
>
> > contains?/seq-contains? mark a divide where it is very easy for a
> > language to quietly help programmers do the wrong thing.
>
> Such as littering my application code with type-checks to decide if  
it

> should call contains? or seq-contains?
> That seems exactly the wrong thing to do.
>
> Please explain how making seq-contains? fast for sets and maps is
> wrong (exactly how does it violate some contract and what contract,
> explicitly is that a violation of) and application code type checking
> is right, because I really don't understand why making seq-contains?
> fast isn't just a huge win-win.
>

It is an important aspect of Clojure that, in general, performance  
guarantees are part of the semantics of functions. In particular,  
functions are not supported on data structures where they are not  
performant.


You can't just swap out sequences or lists for maps or sets in a  
program. So, you need to use the right data structure for the job, and  
then the right functions will be available. When it makes sense, some  
functions are maximally polymorphic (e.g. seq, or into). But lookup,  
under any name, shouldn't be, IMO, so it isn't in Clojure. Similarly  
there is no insert at the beginning of vectors, append to end of  
lists, lookup for values of maps, insertion in the middle of sequences  
etc. I simply don't want to provide the tools for people to write  
programs in Clojure with N^2 performance - that benefits no one. But  
I've seen such performance degradation in many a Lisp program as  
people build upon O(n) functions on lists.


If you have a lookup table in your program, please use a set or map,  
or, if by index, a vector. You will have get, contains? or nth  
available, performance will be good, and that will be clear from the  
code.


seq-contains? exists because sometimes, say in a macro, you have a  
known short sequence and need to test for the presence of something.  
There's no need to copy it into a set. And people have been rolling  
their own includes? etc for this job. Now everyone can use seq- 
contains? for that. Its poor performance is indicated by its name and  
documentation. Should someone try to take a piece of code based on seq- 
contains? and try to scale it, they will see that function as an  
obvious bottleneck.


Your type-check argument is a straw man that doesn't hold up in  
Clojure practice. People tend to use the right data structures for the  
job and don't choose algorithms via type checks.


Clojure is not particularly duck-type-y, in general things are not  
unified by the presence of same-named functions but by underlying  
shared abstractions. Just because protocols can be used to make things  
reach many types doesn't mean they should be used to unify things that  
aren't uniform.


If you want to get a feel for how the abstractions in Clojure are  
organized, have a look at the slides in the middle of this  
presentation (about 30 pages in):


http://clojure.googlegroups.com/web/tutorial.pdf

While you may not agree with it (and everyone disagrees with  
contains? :), at least the design is a considered one.


Rich

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: constructing a lazy sequence from a Java API that returns pages of data

[.Bill Smith]

Thanks Alex.

On Apr 28, 4:55 pm, ataggart  wrote:
> (defn pages
>   ([src size] (pages src 0 size))
>   ([src start size]
>     (lazy-seq
>       (if-let [page (.getPage src start size)]
>         (cons page (pages src (inc start) size))
>
> On Apr 28, 2:38 pm, ".Bill Smith"  wrote:
>
>
>
> > I have a Java API that retrieves "pages" of data from a database: you
> > specify the page number and the page size, it it retrieves row numbers
> > page-number*page_size  through (page-number+1)*page_size - 1.  I'd
> > like to construct a lazy sequence that gets its data using that Java
> > API.  I'm using Clojure 1.1.  I would prefer not to use 1.2 until it's
> > released.  I suspect there's a posting or web page somewhere that lays
> > out the general template for doing this kind of thing.  Anyone have
> > any suggestions?
>
> > Thanks,
> > Bill Smith
> > Austin, TX
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 
> > athttp://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 7:38 PM, Mark Engelberg wrote:

But I think you're not fully appreciating the complexity of the
situation.  This is not just about performance, but a question of two
different possible semantics for "contains?", which is why it can't
*only* be addressed with a protocol.


...


The fundamental problem is that some Clojure data structures have a
dual nature.  For example, a vector can be thought of as a collection
of items, or you can think of it as a mapping from integers to items.
A hash map can be thought of as a map, or as a sequence of key-value
pairs.


Agreed on the hash map. For vectors, Clojure has already decided that  
'seq'ing them ignores their indexes.




The current "contains?" function is really a "contains-key?" function.


Agreed.


There are some people who believe that Clojure would benefit from a
variant of "contains?" that views the input as a collection.  But how
to make this clear?  That's why the proposal is for a new function
called "seq-contains?".  It's not so much a warning of "this thing has
performance like a linear search", as much as, "it views your data as
a sequence".


Yup.

...



So, if things do move forward with seq-contains? to create a new
semantic notion in the clojure core of how to test for containment, I
absolutely agree that protocols should be used to make this new notion
to continue to have good performance on those sorts of collections for
which it is possible to have superior performance than a sequential
search.


Perhaps protocols are a touchy subject and there is another mechanism  
to use, but I haven't yet seen a coherent argument against some  
mechanism for enhancing performance.


Thanks for the detailed analysis. I guess I had hoped it wouldn't've  
been necessary. :)


-Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Meikel Brandmeyer]

Hi,

On 29 Apr., 01:38, Mark Engelberg  wrote:

> 1.  Don't include seq-contains?  The behavior you want can usually be
> achieved by using (some #{item} coll).  Disadvantage - if you're
> testing to see if the collection contains nil, that won't work.

Not entirely correct. (some #(= % item) coll) works always and is
basically how seq-contains? is implemented. However there are
opinions that some is not obvious enough.

Sincerely
Meikel

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

Re: clojure 1.2 seq fn enhancement FAQ

[Douglas Philips]

On 2010 Apr 28, at 11:04 PM, Rich Hickey wrote:
It is an important aspect of Clojure that, in general, performance  
guarantees are part of the semantics of functions. In particular,  
functions are not supported on data structures where they are not  
performant.


Understood. That isn't the point/question I was trying to raise.
Again, back to the demo of protocols in Stuart's video, the question  
isn't "is seq-contains? potentially lying about its performance" but  
"why shouldn't any function, including seq-contains? be as fast as it  
can be, when it can be?"


...however interesting it might be for other reasons>...




And people have been rolling their own includes? etc for this job.  
Now everyone can use seq-contains? for that. Its poor performance is  
indicated by its name and documentation. Should someone try to take  
a piece of code based on seq-contains? and try to scale it, they  
will see that function as an obvious bottleneck.


Really? We've known for a long time that people suck at guessing where  
programs have performance bottlenecks (1), and that taking a premature  
optimization attitude "obvious bottleneck" is wrong headed (2).


(1) consing is bad!
(2) 20G of garbage per second and the CPU utilization barely breaks  
10%? Hmmm, I guess consing isn't so bad and that thinking "consing is  
bad" is just another old, preconceived notion proved wrong, so that  
'obvious bottleneck' turns out not to be so obvious after all.


Shouldn't seq-contains? be parallelizable, esp. vectors where you can  
easily create O(1) slices... or use other techniques when sequences of  
certain kinds might have other exploitable properties?



What is the purpose, goal, design-rationale of not making seq- 
contains? fast on maps or sets?




Clojure is not particularly duck-type-y, in general things are not  
unified by the presence of same-named functions but by underlying  
shared abstractions. Just because protocols can be used to make  
things reach many types doesn't mean they should be used to unify  
things that aren't uniform.


Are saying that seq-contains? will not work on sets and maps because  
they aren't uniform w.r.t. sequences or that they are uniform, but  
protocols won't fit here as an optimization technique because _  
(being brand new, I don't know all the subtleties of protocols), or ???




If you want to get a feel for how the abstractions in Clojure are  
organized, have a look at the slides in the middle of this  
presentation (about 30 pages in):


http://clojure.googlegroups.com/web/tutorial.pdf


Actually I have seen those slides already, but had lost track of where  
I had found them, thanks for the reminder pointer.




While you may not agree with it (and everyone disagrees with  
contains? :), at least the design is a considered one


I generally agree with the design Clojure embodies as an outlook :).
As to contains? ... I agree with Mark Engelberg's detailed analysis  
and conclusions.



   -Doug

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

Re: clojure 1.2 seq fn enhancement FAQ

[Meikel Brandmeyer]

Hi,

On 29 Apr., 01:43, Stuart Halloway  wrote:

> I'll wait for Rich to maybe chime in on seq-contains?. Other than seq-
> contains? are people liking the new fns? Anybody having issues we  
> didn't anticipate?

I was a little bit surprised about map-indexed and keep-indexed.
Why specialised functions when (map f (indexed coll)) just works
as well, but I must confess that having (f idx item) is nicer compared
to (f [idx item]). On the other hand one could do (map #(apply f %)
(indexed coll)), but again this doesn't play nice with #() functions.

One thing I noticed in the implementation of keep-indexed.

keepi is defined as (letfn [(keepi [idx coll] ...)] ...). However in
the
non-chunked case it is called as (keepi f (inc idx) (rest s)) resp.
as (keepi f (rest s)). I think there is something goofy going on here.

Sincerely
Meikel

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

Re: beginer jedit problem

[Marko Srepfler]

Same error
I think the problem is that jline extract dll and load, probably
Windows 7 security dont allow this,
on windows 7 x64 with 64 bit java says error in jline.dll

C:\clojure>java -cp jline-0.9.91.jar;clojure.jar jline.ConsoleRunner
clojure.mai
n
Exception in thread "main" java.lang.ClassNotFoundException:
clojure.main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.misc.Launcher$ExtClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at jline.ConsoleRunner.main(ConsoleRunner.java:69)

C:\clojure>java -cp jline-0.9.91.jar:clojure.jar jline.ConsoleRunner
clojure.mai
n
Exception in thread "main" java.lang.ClassNotFoundException:
clojure.main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.misc.Launcher$ExtClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at jline.ConsoleRunner.main(ConsoleRunner.java:69)

C:\clojure>java -cp jline-0_9_5.jar;clojure.jar jline.ConsoleRunner
clojure.main

Exception in thread "main" java.lang.ClassNotFoundException:
clojure.main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.misc.Launcher$ExtClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at jline.ConsoleRunner.main(ConsoleRunner.java:69)

On Apr 28, 5:38 pm, Chris Perkins  wrote:
> On Apr 28, 4:56 am, Marko Srepfler  wrote:
>
> > C:\clojure-1.1.0>java -cp jline-0.9.91.jar:clojure.jar
>
> You need to separate your classpath entries with a semicolon, not a
> colon.
>
> - Chris Perkins
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: clojure 1.2 seq fn enhancement FAQ

[Mark Engelberg]

On Wed, Apr 28, 2010 at 10:49 PM, Douglas Philips  wrote:
> What is the purpose, goal, design-rationale of not making seq-contains? fast
> on maps or sets?

I think Rich's point is that if seq-contains? is sometimes fast and
sometimes slow, then it makes it harder to reason about a program that
uses seq-contains?.  Is this one of the "slow" usages, or one of the
"fast" usages?  On the other hand, with the current plan, you know
exactly what performance you're getting.  contains? will always be
fast on sets and maps (albeit returning meaningless results for lists,
and counterintuitive results for vectors).  seq-contains? always does
a linear search.  So if you see seq-contains? in your code, this
serves as a big red flag that either you should be using a set data
structure and contains?, or you better be sure your sequence is
relatively small.

If seq-contains? sometimes had good performance, then people would
start using a mixture of seq-contains? and contains? for sets and
maps, and it would be less clear when you were using seq-contains?
"improperly".

> I generally agree with the design Clojure embodies as an outlook :).
> As to contains? ... I agree with Mark Engelberg's detailed analysis and
> conclusions.

Thanks.  But I definitely see the logic of Rich's approach as well.

As a side note, maybe contains? should return an error message when
used on a non-keyed collection like a list.  With the confusion that's
sure to result from having both contains? and seq-contains? in the
core with slightly different semantics, applicable inputs, and
performance, an error message for inappropriate uses of contains?
would be very valuable, I think.

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