Re: Proposal: clojure.io
On 01.01.2010, at 03:58, Phil Hagelberg wrote: > I welcome discussion about this proposal. Do you think it's > necessary? Are > there any functions we should leave out? Any others we should > promote from > contrib? I am very much in favour of a clojure.io library. It's difficult to do much useful computing without I/O, and what there is in clojure.core is insufficient. Your selection covers all I need and more, so it's fine with me. My only suggestion is to move all I/O-related functions from clojure.core to clojure.io for consistency. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 + Redis
There you go: http://github.com/purcell/redis-memo I doubt the memoize functions provided therein will be directly useful to you, but you may find a few lines of helpful code there. Best of luck with your experiment. -Steve On 31 Dec 2009, at 16:20, Gabi wrote: > Yes. I think it is of much interest. What if I stored a shared data > structure in redis (only because its the fastest), using your memoize > variant, and process (maybe even updated it) it in parallel from > different Clojure nodes. Some kind of primitive map/reduce mechanism I > think. > > On Dec 31, 12:29 pm, Steve Purcell wrote: >> Not sure if it's any help, but here's a variant of memoize I wrote, which >> stores arbitrary readable/printable objects to redis: >> >> http://gist.github.com/266689 >> >> (If there's any interest, I'll wrap it up in a github project and push it to >> clojars.) >> >> Redis isn't a hierarchical store, so its array/set operations would only >> benefit the most shallow of data structures. >> >> -Steve >> >> On 30 Dec 2009, at 11:52, Gabi wrote: >> >>> On first look, Redis and Clojure seems to be a perfect match. They >>> both handle sets and maps efficiently. If one could find an easy way >>> to store and retrieve Clojure data structures to Redis (even a small >>> subset- just a list or a set), a distributed clojure app could be very >>> easy (and effective?) thing to do - The stateless Clojure nodes would >>> share and operate on the same central data structure which is stored >>> in Redis). What do you thing ? Is it worth investigating further? >> >>> -- >>> You 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 > -- You 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: Proposal: clojure.io
Hi, On Jan 1, 3:58 am, Phil Hagelberg wrote: > I've been looking over our use of contrib in our large-ish project > at work. About 90% of the invocations of contrib functions are > I/O-related. evil mutable little bastards, these files ;-) > I wonder if it would be a good idea to include a clojure.io > namespace in Clojure itself. inc > I've prototyped this in the attached file. Most of the functions come > from contrib's duck-streams library. I've taken everything from > duck-streams except read-lines, file-str, make-parents, and pwd. > > read-lines was left out since ... Sounds reasonable. > I welcome discussion about this proposal. Do you think it's > necessary? Are there any functions we should leave out? > Any others we should promote from contrib? I don't know whether it's in contrib already but I'd very much appreciate a few macros lifting the burden of Java's io-lib with Reader, BufferedReader, File, PushbackReader, WhateverReader and ...Writers. Coming from the Lisp world this feels rather ugly to my fingers. Kind regards, Stefan -- You 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/SLIME/Emacs questions
FWIW I have never touched ELPA but got a setup with SLIME from CVS plus SBCL and Clojure. A rudimentary description can be found at http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup The only part that feels tricky is compiling swank for which I needed a Maven setup, IIRC. Regards, Stefan -- You 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 + Redis
Jackrabbit is heavy. It might be powerful but I am sure it is much slower than Redis or MongoDB. On Dec 31 2009, 6:59 pm, jem wrote: > Something else to look at might be the Apache Jackrabbit project > athttp://jackrabbit.apache.org/. > > I've been looking at tools along these lines as well, and recently > looked at Redis for the same reasons. Right now, though, I'm focusing > my attention on Jackrabbit which is an implementation of the JSR170 > repository specifications. It supports hierarchical data and lists. > I was looking for some way to save dynamic objects (basically runtime > defined maps) and this looks like it might work. > > JSR170 defines a repository as: > > "A content repository consists of one or more workspaces, each of > which contains a tree of items. An item is either a node or a > property. Each node may have zero or more child nodes and zero or more > child properties. There is a single root node per workspace, which has > no parent. All other nodes have one parent. Properties have one parent > (a node) and cannot have children; they are the leaves of the tree. > All of the actual content in the repository is stored within the > values of the properties." > > The available property types cover what appear to be all the bases, > including references to other nodes to prevent cycles when > serializing. It can support annotated Java objects or use the Node > building capability directly and allows querying similar to XPath. > Since it is a Java project, using it from Clojure should be trivial to > use. > > On Dec 31, 5:29 am, Steve Purcell wrote: > > > Not sure if it's any help, but here's a variant of memoize I wrote, which > > stores arbitrary readable/printable objects to redis: > > >http://gist.github.com/266689 > > > (If there's any interest, I'll wrap it up in a github project and push it > > to clojars.) > > > Redis isn't a hierarchical store, so its array/set operations would only > > benefit the most shallow of data structures. > > > -Steve > > > On 30 Dec 2009, at 11:52, Gabi wrote: > > > > On first look, Redis and Clojure seems to be a perfect match. They > > > both handle sets and maps efficiently. If one could find an easy way > > > to store and retrieve Clojure data structures to Redis (even a small > > > subset- just a list or a set), a distributed clojure app could be very > > > easy (and effective?) thing to do - The stateless Clojure nodes would > > > share and operate on the same central data structure which is stored > > > in Redis). What do you thing ? Is it worth investigating further? > > > > -- > > > You 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: Language similarities
Everything looks the same if you use a loose enough equality function I guess. Using a loose enough equality function, you can argue that Clojure is just Lisp running on top of a mutable, Object Oriented framework (the JVM). Immutable data structures and controlled changes of immutable values is nothing new. Make the equality function even more loose and you can argue that Clojure and C# is pretty much the same. Both languages JIT compiles to machine code, are executed by a CPU and modify states (memory, magnetic plates, the temperature of the PC etc.) However, in reality the "small differences" makes a big difference for people using the languages. I personally feel that it makes a big difference using C# instead of C or Clojure instead of Lisp. -- You 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: Language similarities
Paul Graham might be correct that main stream languages will incorporate features that Lisp had many years ago but the result won't be Lisp. -- You 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/SLIME/Emacs questions
and FWIW I got the whole thing going without ELPA by using the instructions here: http://learnclojure.blogspot.com/2009/11/installing-clojure-on-ubuntu-910-karmic.html but on OSX. On 1 Jan 2010, at 11:30, Stefan Kamphausen wrote: > FWIW I have never touched ELPA but got a setup with SLIME from CVS > plus SBCL and Clojure. A rudimentary description can be found at > http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup > > The only part that feels tricky is compiling swank for which I needed > a Maven setup, IIRC. > > Regards, > Stefan > > -- > You 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 Edmund "The future is here. It's just not widely distributed yet" -- Gibson -- You 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/SLIME/Emacs questions
On 01.01.2010, at 12:30, Stefan Kamphausen wrote: > FWIW I have never touched ELPA but got a setup with SLIME from CVS > plus SBCL and Clojure. A rudimentary description can be found at > http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup > > The only part that feels tricky is compiling swank for which I needed > a Maven setup, IIRC. I just run swank from source code, uncompiled. No Maven, no worry :-) Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Proposal: clojure.io
Phil, Overall I think this is a good idea, but I get the feeling duck- streams isn't quite ready, at least not today. However, this isn't to say that it couldn't be ready if we worked hard on it over the next few months. Here are some things to look into off the top of my head 1. I'd recommend adding support for general unix file utilities. I've written some of them myself, and you can review/borrow/steal code from here: http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/src/lib/sfd/file_utils.clj 2. duck-streams works very well for text, but not binary formats. I know there was discussion about it here: http://groups.google.com/group/clojure/browse_thread/thread/416ca90d3ce2fa3/d64648f34e5c8668 3. There should be a brainstorming session to see what objects reader/ writer will dispatch over, and the multimethods improved accordingly. This should probably happen anyway. Also, there's a bigger question of how Clojure will support IO. This becomes very platform specific, at least part of it do. Rich/the community will have to decide how to handle IO on multiple platforms, or to stick w/ the JVM for now. I know what I've described is a lot of work, but it's what is involved with creating a really well polished library. I think in the end this will be library we're all proud of. Thanks for bringing the idea up :) Sean On Jan 1, 6:27 am, Stefan Kamphausen wrote: > Hi, > > On Jan 1, 3:58 am, Phil Hagelberg wrote: > > > I've been looking over our use of contrib in our large-ish project > > at work. About 90% of the invocations of contrib functions are > > I/O-related. > > evil mutable little bastards, these files ;-) > > > I wonder if it would be a good idea to include a clojure.io > > namespace in Clojure itself. > > inc > > > I've prototyped this in the attached file. Most of the functions come > > from contrib's duck-streams library. I've taken everything from > > duck-streams except read-lines, file-str, make-parents, and pwd. > > > read-lines was left out since ... > > Sounds reasonable. > > > I welcome discussion about this proposal. Do you think it's > > necessary? Are there any functions we should leave out? > > Any others we should promote from contrib? > > I don't know whether it's in contrib already but I'd very much > appreciate a few macros lifting the burden of Java's io-lib with > Reader, BufferedReader, File, PushbackReader, WhateverReader > and ...Writers. Coming from the Lisp world this feels rather ugly to > my fingers. > > Kind regards, > Stefan -- You 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/SLIME/Emacs questions
Hi, On Jan 1, 4:35 pm, Konrad Hinsen wrote: > On 01.01.2010, at 12:30, Stefan Kamphausen wrote: > > The only part that feels tricky is compiling swank for which I needed > > a Maven setup, IIRC. > > I just run swank from source code, uncompiled. No Maven, no worry :-) I had some errors before compiling and putting the resulting JAR on the CP. But I'm not much of a Java-hero. What is your classpath? I have swank-clojure/target/swank-clojure-1.0-SNAPSHOT.jar on it. Cheers, Stefan -- You 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: Language similarities
I would like to add Ada exception management. I don't know if there were previous work on the field. Any info? I worked with Algol, but I don't remember if something like exceptions was present those days. Any early Lisp exception management? And namespaces. The first Eiffel had no management of name collision; it has some sort of renaming. The first time I saw namespaces was in nineties C++, then popularized by Java packages. Any previous work on that? Smalltalk categories, dictionaries could be considered namespaces? Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez On Tue, Dec 29, 2009 at 6:34 AM, Martin Coxall wrote: > > On 29 Dec 2009, at 04:14, jim wrote: > > > Had an interesting conversation with a programmer friend of mine. He's > > skeptical of my Lisp leanings and mostly sticks to the 'normal' > > languages; C++, Java, etc. > > > > I made that comment that pretty much all the languages derived from > > Algol like the C family, Java, Pascal, etc. were pretty much the same. > > He looked at me like I was insane. :) :) > > Well, you're basically correct. The block structure was finalised in 1960 > as part of Algol, and everything else (mainly the OO stuff) was all present > and correct in Simula in 1967. > > Since that point, imperative languages have barely changed in the last 33 > years. The only notable exception to this was Ada growing generics in 1987, > and their evolution into C++ templates. > > Martin > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > 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/SLIME/Emacs questions
On 01.01.2010, at 17:29, Stefan Kamphausen wrote:
> I had some errors before compiling and putting the resulting JAR on
> the CP. But I'm not much of a Java-hero. What is your classpath? I
> have swank-clojure/target/swank-clojure-1.0-SNAPSHOT.jar on it.
I always work with the latest Clojure ("new" branch from github).
Here's my swank setup in .emacs:
(setq swank-clojure-classpath
(list "~/Development/clojure/clojure.jar"
"~/Development/clojure-contrib/clojure-contrib.jar"
"~Development/clojure-dev-utilities"))
The last entry is a directory which contains among other stuff the
directory "swank" that contains swank.clj and the rest of the swank
source code.
Konrad.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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/SLIME/Emacs questions
Stefan Kamphausen writes: > you may want to read the thread > http://groups.google.com/group/clojure/browse_frm/thread/3e5f416e3f2a1884/337057edae5dcdc3 I had read that thread /twice/ before, as well as the thread on the SLIME mailing list, but I had neglected to try disabling autodoc-mode. This morning, doing so makes things work much better. However, I still notice that when I first run SLIME, the *inferior-lisp* buffer comes up with a responsive REPL, but the SLIME REPL connection is flaky. It takes a long time to finally come through, if it ever does. Perhaps there's some race condition there. Sometimes taking focus away from the Emacs window, doing something, else, and returning to Emacs will cause the SLIME REPL to finally wake up and finish its connection sequence. At that point the animated REPL banner flies out and I have a working REPL. But presentations still don't work. -- Steven E. Harris -- You 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: Language similarities
On Fri, 1 Jan 2010 13:45:43 -0300 Angel Java Lopez wrote: > I would like to add Ada exception management. I don't know if there were > previous work on the field. Any info? I worked with Algol, but I don't > remember if something like exceptions was present those days. Any early Lisp > exception management? Try/Catch were add to MacLisp in 1972, because the previous error handling facilities (ERR/ERRSET) were being abused to get that behavior. This predates the formation of the Ada working group by a couple of years. > And namespaces. The first Eiffel had no management of name collision; it has > some sort of renaming. The first time I saw namespaces was in nineties C++, > then popularized by Java packages. Any previous work on that? Smalltalk > categories, dictionaries could be considered namespaces? Python dates back to the 80s, and namespaces are a core concept: "Namespaces are one honking great idea -- let's do more of those!" is part of the Zen of python. But Common Lisp had them for package management dating back to the early 80s. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You 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/SLIME/Emacs questions
"Steven E. Harris" writes: > This morning, doing so makes things work much better. Still I see this in the *inferior-lisp* buffer when starting slime: , | (require 'swank.swank) | | (swank.swank/ignore-protocol-version "2009-12-23") | | (swank.swank/start-server "c:/DOCUME~1/seh/LOCALS~1/Temp/slime.3420" :encoding "iso-latin-1-unix") | | Listening for transport dt_socket at address: | Clojure 1.1.0 | user=> | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | WARNING: reader macro ^ is deprecated; use meta instead | nil | user=> user=> "2009-12-23" | user=> user=> Connection opened on local port 3464 | # | user=> user=> user=> ` Note that I'm using Clojure 1.1.0. Could that be the problem? This is within GNU Emacs 23.1.1 on Windows XP. Once that *inferior-lisp* buffer is up, if I run `slime-repl', the REPL may take an arbitrarily long time to finally connect to Swank. And if it does ever connect, and I shut it down via the "sayoonara" command, I can't get it to start again successfully. -- Steven E. Harris -- You 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/SLIME/Emacs questions
"Steven E. Harris" writes:
> Rob Wolfe writes:
>
>> I did it like this (I assume that clojure-mode.el has been installed):
>
> Thanks, Rob. I followed your instructions after not being able to get
> Clojure to cooperate with my normal Swank/SLIME installation, and it
> works, but only to a point: The SLIME REPL buffer (invoked via the
> function `slime-repl') falls out of step with the *inferior-lisp*
> buffer.
So how do you exactly start SLIME for Clojure?
These settings:
(require 'slime)
(slime-setup '(slime-repl))
(defun run-clojure ()
"Starts clojure in Slime"
(interactive)
(slime 'clojure))
should cause automatic start of *inferior-lisp* and *slime-repl clojure*
after typing "M-x run-clojure"
>
> This never happens to me when using SLIME with a Common Lisp, such as
> CLISP. Here, Clojure starts up just fine in the *inferior-lisp* buffer,
> but the SLIME REPL doesn't seem to connect properly. Maybe it connects
> at the network level, but each form entered in the SLIME REPL yields
> messages like this in the minibuffer:
>
> ,
> | ; pipelined request... (swank:listener-eval "
> `
What do you see in *messages* buffer? Maybe there are some helpful
messages. I can see this:
"""
Polling "/tmp/slime.6251".. (Abort with `M-x slime-abort-connection'.) [31
times]
Connecting to Swank on port 40585.. [2 times]
Connected. Hacks and glory await!
"""
What version of Clojure do you use? I use clojure.jar built from sources
taken from GIT repository (I tried Clojure 1.0 and it worked too).
I agree with Stefan Kamphausen that "connection-serve" in swank.clj
should not fail silently. Now we don't know what is the problem.
If I were you I would change this function as Stefan suggested
and see what is going on:
(defn- connection-serve [conn]
(let [control
(dothread-swank
(thread-set-name "Swank Control Thread")
(try
(control-loop conn)
(catch Exception e
;; fail silently
(.printStackTrace e)
(.printStackTrace (.getCause e))
nil)))
read
(dothread-swank
(thread-set-name "Read Loop Thread")
(try
(read-loop conn control)
(catch Exception e
;; This could be put somewhere better
(.interrupt control)
(dosync (alter *connections* (partial remove #{conn}))]
(dosync
(ref-set (conn :control-thread) control)
(ref-set (conn :read-thread) read
>
> That's a sign that the REPL is sending commands to the SWANK back-end,
> but it's not receiving a timely response. Meanwhile, the Clojure REPL in
> the *inferior-lisp* buffer remains responsive.
>
> Trying to evaluate Clojure forms from a buffer other than the REPL (via,
> say, `C-x e', usually doesn't work. There's no error reported, but none
> of the resulting values display in the minibuffer, and any definitions
> evaluated there have no apparent side effect on the Clojure REPL
> available in the *inferior-lisp* buffer.
>
> I've also noticed that the SLIME "presentations" feature doesn't work
> with Clojure. That may be a symptom of the SLIME REPL not meeting up
> properly with the Clojure REPL.
Yes, apparently connection with *slime-repl clojure* failed
and it does not work properly now.
HTH,
Rob
--
You 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: strange typecheck error
Happy New Year to you, Alex. I reproduced the problem as follows: user=> (loop [x (byte 0) count 0] (if (< count 10) (recur 0 (inc count java.lang.RuntimeException: java.lang.IllegalArgumentException: recur arg for primitive local: x must be matching primitive (NO_SOURCE_FILE: 57) user=> If the compiler detects that a loop binding evaluates to a primitive, it insists that the corresponding recur argument be a reducible to a primitive as well. You can short-circuit that logic with a type hint, like this: user=> (loop [x #^Object (byte 0)] (if (< x 10) (recur (inc x nil user=> It's ugly but it works. If you change line 65 in your example from "char (.read ireader)]" to "char #^Object (.read ireader)]", the compile error should go away. The example in my previous posting didn't have that problem because 0 by itself is an Integer object, not an int primitive. On Dec 31 2009, 12:45 pm, Alex Ott wrote: > Hello Bill > > .Bill Smith at "Thu, 31 Dec 2009 09:20:16 -0800 (PST)" wrote: > .S> I tried out your example with a couple of files and it appeared to > .S> work. Is it supposed to fail, or is this an example of what you had > .S> to do to work around the problem you mentioned? > > Yes, this is working variant > > if you'll replace '(.read ireader)' in 'recur' on line 80 with 'res', then > it will fail. > > .S> It's certainly ok for a function to return different data types. I > .S> guess the simplest example of that would be the identity function. > > thanks for identity example, i'll look to it > > P.S. Happy New Year to you, and rest of clojure community > > -- > With best wishes, Alex Ott, MBAhttp://alexott.blogspot.com/ > http://xtalk.msk.su/~ott/http://alexott-ru.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Language similarities
On Fri, Jan 01, 2010 at 12:31:16PM -0500, Mike Meyer wrote: >On Fri, 1 Jan 2010 13:45:43 -0300 >Angel Java Lopez wrote: > >> I would like to add Ada exception management. I don't know if there were >> previous work on the field. Any info? I worked with Algol, but I don't >> remember if something like exceptions was present those days. Any early Lisp >> exception management? > >Try/Catch were add to MacLisp in 1972, because the previous error >handling facilities (ERR/ERRSET) were being abused to get that >behavior. This predates the formation of the Ada working group by a >couple of years. I don't think I've ever seen any cross references between any of the Lisp documentation and any of the Ada documentation. The Ada rationale only references a couple of obscure papers about exceptions. Perhaps they didn't want to scare people by mentioning where they got the idea. I guess another concept that wasn't really accepted until a "mainstream" language started using it. 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: Clojure/SLIME/Emacs questions
Rob Wolfe writes: > So how do you exactly start SLIME for Clojure? I've tried both `C-u - M-x slime RET clojure' and `run-clojure', which both amount to the same thing eventually > These settings: [...] > should cause automatic start of *inferior-lisp* and *slime-repl clojure* > after typing "M-x run-clojure" They do -- sometimes -- /eventually/. There is a very long gap between the *inferior-lisp* process starting and the SLIME-Swank connection completing, and the REPL appears only after that connection succeeds. > What do you see in *messages* buffer? The same as yours: ,[ *Messages* buffer ] | Polling "c:/DOCUME~1/seh/LOCALS~1/Temp/slime.5844".. | (Abort with `M-x slime-abort-connection'.) [22 times] | Connecting to Swank on port 3681.. [2 times] | Connected. Let the hacking commence! ` But note that the connection attempt message repeated 22 times. And in between the "connecting" and "connected" messages, there was a lag of maybe a minute, during which I went in and interacted with the Clojure REPL in the *inferior-lisp* buffer, trying to kick the connection to completion. If I just start SLIME and /don't/ interact with the *inferior-lisp* buffer, the connection "never" completes, or at least not within the five minutes I let it sit undisturbed. This is the only content in the *slime-events* buffer while I'm waiting for the connection to complete: ,[ *slime-events* buffer ] | (:emacs-rex | (swank:connection-info) | "COMMON-LISP-USER" t 1) ` > What version of Clojure do you use? The Clojure 1.1.0 Jar that I downloaded from code.google.com. > I use clojure.jar built from sources taken from GIT repository (I > tried Clojure 1.0 and it worked too). That's a good sign that something more recent than Clojure 1.0 should work. > I agree with Stefan Kamphausen that "connection-serve" in swank.clj > should not fail silently. Now we don't know what is the problem. I changed `connection-serve' per your suggestion. The Swank back-end didn't dump any exception traces to the *inferior-lisp* buffer. The behavior looks like it suffers a race, or maybe the socket connection request isn't noticed as intended. -- Steven E. Harris -- You 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: Proposal: clojure.io
On Dec 31 2009, 9:58 pm, Phil Hagelberg wrote: > I wonder if it would be a good idea to include a clojure.io > namespace in Clojure itself. I've mentioned the idea a few times on IRC, > and people seemed to be very much in favour. I've considered this too, but I know Rich Hickey has plans for a dedicated I/O library. It's been on http://clojure.org/todo for a while. Details are sketchy, but presumably it would be functional, stream-based, and thread-safe. The I/O contrib libs are mostly convenience wrappers around the java.io classes and do not represent a well-thought-out API. (I know because I wrote some of them.) -SS -- You 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/SLIME/Emacs questions
"Steven E. Harris" writes: > This is the only content in the *slime-events* buffer while I'm waiting > for the connection to complete: > > ,[ *slime-events* buffer ] > | (:emacs-rex > | (swank:connection-info) > | "COMMON-LISP-USER" t 1) > ` I also confirmed that `slime-set-connection-info' isn't being called until after the long lag, which means that the REX above is part of what's hanging. Either the Swank side isn't receiving the request or it's not responding from the SLIME function `connection-info' in file basic.clj. The hang can be well /before/ this point too, but I've at least established that it's not after `slime-set-connection-info'. My next step will be to instrument the Swank side to see when `connection-info' is being called. -- Steven E. Harris -- You 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
import as a macro; dynamic imports?
I should have brought this up before 1.1 was released, but I'm bothered by the change of clojure.core/import from a function to a macro. If I'm creating a namespace dynamically, I can't evaluate the name of the class I want to pass to import. The only way is to use undocumented Java functions, like: (defn import-name "Import a class named c (a String) into namespace n." [n c] (.importClass n (clojure.lang.RT/classForName c))) Of course, I can write a macro that evaluates the strings, but that's not really what I want. I want the equivalent of clojure.core/intern for classes. Is there a better way? -SS -- You 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 + Redis
I've just recently been poking around these NoSQLs investigating their features, so... Redis has limited data structures - flat un-nested lists and sets, and plain strings. It doesn't have sets exactly - just keys and values. Nothing nested at all, unless you serialize to strings. No indexes, although you can hack up your own. To be honest, Redis isn't that impressive versus what's in Clojure already. It's an in-memory DB (so it's not much different from ref +dosync) and it intermittently spits a snapshot to disk. If you can live with an in-process DB, you could copy (and exceed) its features including snapshot saving in a page of pure Clojure code, and beat it on speed too. Contrast MongoDB: slower because it bothers to save things, but still around twice as fast as MySQL and much faster than CouchDB (cite: the benchmarks page). Arbitrarily nested collections, indexes, atomic updates (in place operations like inc and append, or atomic compare- and-set), JSON syntax, typed data, replication (built in) and sharding (via a broker process). (MongoDB downsides: it grows files in a very greedy way to try and minimize data fragmentation, and it needs a 64bit machine to store more than about 2Gb.) On Dec 30 2009, 11:52 am, Gabi wrote: > On first look, Redis and Clojure seems to be a perfect match. They > both handle sets and maps efficiently. If one could find an easy way > to store and retrieve Clojure data structures to Redis (even a small > subset- just a list or a set), a distributed clojure app could be very > easy (and effective?) thing to do - The stateless Clojure nodes would > share and operate on the same central data structure which is stored > in Redis). What do you thing ? Is it worth investigating further? -- You 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 + Redis
Oops, typo - I meant, doesn't have hashes. On Jan 1, 9:07 pm, Julian Morrison wrote: > It doesn't have sets exactly - just keys and values. -- You 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: Proposal: clojure.io
Sean Devlin writes: > 1. I'd recommend adding support for general unix file utilities. > I've written some of them myself, and you can review/borrow/steal code > from here: > > http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/src/lib/sfd/file_utils.clj These are all one-line wrappers around Java methods. I know Rich has stated that the Clojure philosophy is to avoid such wrappers unless they provide significant additional value. Perhaps this will need to change as people start to write more cross-platform code, but I don't know if we're to that point yet. > 2. duck-streams works very well for text, but not binary formats. I > know there was discussion about it here: > > http://groups.google.com/group/clojure/browse_thread/thread/416ca90d3ce2fa3/d64648f34e5c8668 I believe it's the case that reader and writer don't work for binary formats, but copy should. Copying between two files or between a file and a byte array should work fine unless I'm missing something. This should be better-documented though. > 3. There should be a brainstorming session to see what objects reader/ > writer will dispatch over, and the multimethods improved accordingly. > This should probably happen anyway. It covers everything I can think of, but if you've got suggestions let's hear them. -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/SLIME/Emacs questions
Rob Wolfe writes: > Stefan Tilkov writes: > >> Two quick Emacs/Clojure questions I can't seem to find the answer to: >> >> - In his screencasts, Sean Devlin moves the mouse over an item in his >> REPL history and it becomes highlighted (and he can paste it to the >> current prompt with one click) >> - Also in his screencasts, Lau Jensen types something like g-i-v, then hits >> some key combination and gets an expansion like get-integer-value >> >> I can't seem to find out how to get these to work, any hint would be >> appreciated. > > I did it like this (I assume that clojure-mode.el has been installed): > > 1. downloaded slime and swank-clojure You can get this to work, but as you can see it's very manual and error-prone. The basic slime REPL is working using automated installation from ELPA, and William Douglas is working on adding fuzzy completion to that. It's highly recommended that you follow this approach rather than copying and pasting several pages of one-off configuration. For instance, adding jline to your classpath is redundant if you're using slime. -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
Creating deftype instance from inside a protocol method
I want to create a new instance of a deftype from inside one of its methods. A basic example would be (defprotocol Foo (foo [x])) (deftype Bar [i] Foo (foo [] (Bar (inc i (foo (Bar 0)) This fails with an exception: java.lang.ClassCastException: java.lang.Class cannot be cast to clojure.lang.IFn (NO_SOURCE_FILE:0) Apparently the value of Bar inside the method definition is not yet the value that it will have after the deftype is completed. The following workaround works but is not very elegant: (declare new-Bar) (deftype Bar [i] Foo (foo [] (new-Bar (inc i (def new-Bar Bar) (foo (Bar 0)) Does anyone have a better idea? Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Proposal: clojure.io
I think something more abstract would be good. A function or macro where you pass it an "IO Spec" and it takes care of all the class stuff. (io/read [:bytes :from :as p] (do-stuff-with-a-byte p)) (io/read [:lines :from :as p] (do-stuff-with-a-string p)) (io/read [:lines :from ]) ;no :as binding or body, results in a lazy-seq of lines so you can specify the IO behavior you want, and let the implementation map the spec to a class. that being said, you would still want something like duckstreams for interop, and possibly io/read and io/write would be implemented using duckstreams. So I see no harm in pulling duckstreams in. P.S. scopes are great for the lazy-seq case On Fri, Jan 1, 2010 at 1:34 PM, Phil Hagelberg wrote: > Sean Devlin writes: > >> 1. I'd recommend adding support for general unix file utilities. >> I've written some of them myself, and you can review/borrow/steal code >> from here: >> >> http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/src/lib/sfd/file_utils.clj > > These are all one-line wrappers around Java methods. I know Rich has > stated that the Clojure philosophy is to avoid such wrappers unless they > provide significant additional value. Perhaps this will need to change > as people start to write more cross-platform code, but I don't know if > we're to that point yet. > >> 2. duck-streams works very well for text, but not binary formats. I >> know there was discussion about it here: >> >> http://groups.google.com/group/clojure/browse_thread/thread/416ca90d3ce2fa3/d64648f34e5c8668 > > I believe it's the case that reader and writer don't work for binary > formats, but copy should. Copying between two files or between a file > and a byte array should work fine unless I'm missing something. This > should be better-documented though. > >> 3. There should be a brainstorming session to see what objects reader/ >> writer will dispatch over, and the multimethods improved accordingly. >> This should probably happen anyway. > > It covers everything I can think of, but if you've got suggestions let's > hear them. > > -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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure + Intellij IDEA: stepping through Clojure implementation code
Hello, In order to get a better understanding of how some things happen in Clojure, I'd like to step through Clojure code (and I mean the Java code used to implement Clojure). Basically, just debug a REPL, set breakpoints etc. Since there's a free version of IDEA, I downloaded it and successfully created an IDEA project out of existing Clojure sources. Now when I try to get a REPL (by using clojure.main as the startup class), I get an error about clojure/core.clj not being on the classpath. While a very rough solution would be to just move clj/clojure somewhere on the path, I'd like to know how to change the classpath for a module. I did try playing with the module settings and add a 'library' which has a path to clj/clojure, but I must be doing something wrong, as it doesn't seem to affect the -cp option of the java invocation (I'm checking this using the output window). Since I am a complete IDEA newbie, I'd be very happy if someone who is using IDEA to work on Clojure can provide a few pointers. I don't mind trying this with Eclipse, so Eclipse advice is welcome too. Many thanks and Happy New Year everyone, -- Miron Brezuleanu -- You 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: Creating deftype instance from inside a protocol method
On Fri, 01 Jan 2010 17:13:01 -0500, Konrad Hinsen wrote: > I want to create a new instance of a deftype from inside one of its > methods. I ended-up using extend-type for this case. Hugo -- You 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: update-in and get-in why no default?
On Dec 13, 1:24 am, Rich Hickey wrote: > fnil seems to me to have greater utility than patching all functions > that apply functions with default-supplying arguments. Hi Rich, To further comment on fnil, after having experimented with it a bit now, I've come to slightly prefer specifying the 'default' value before the function just because I think it reads nicer: (fnil 0 inc) ;; instead of (fnil inc 0) (fnil [] conj) ;; instead of (fnil conj []) I read it as "fill nil with 0 for inc" I suppose "fill nil of inc with 0" makes just as much sense but I find "inc 0" leads my eye to believe 0 will always be passed to inc, whereas "0 inc" does not. Putting the function last makes it clearer to me that the 0 is conditional. It also looks more like if nil 0. This contrasts with get, which makes perfect sense having the default last, but I think at this point fnil and get are sufficiently far apart that a different argument order would not be surprising. Just a small observation I thought I'd raise for discussion to see what preferences are out there if this function becomes widespread. Regards, Tim. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 + Redis
I am interested in the idea: Completely stateless set of Clojure nodes (on many machines), operating on a central state stored in some datastore. If transactions could be managed somehow, I think it would be very compelling model for many applications. On Jan 1, 11:07 pm, Julian Morrison wrote: > I've just recently been poking around these NoSQLs investigating their > features, so... > > Redis has limited data structures - flat un-nested lists and sets, and > plain strings. It doesn't have sets exactly - just keys and values. > Nothing nested at all, unless you serialize to strings. No indexes, > although you can hack up your own. > > To be honest, Redis isn't that impressive versus what's in Clojure > already. It's an in-memory DB (so it's not much different from ref > +dosync) and it intermittently spits a snapshot to disk. If you can > live with an in-process DB, you could copy (and exceed) its features > including snapshot saving in a page of pure Clojure code, and beat it > on speed too. > > Contrast MongoDB: slower because it bothers to save things, but still > around twice as fast as MySQL and much faster than CouchDB (cite: the > benchmarks page). Arbitrarily nested collections, indexes, atomic > updates (in place operations like inc and append, or atomic compare- > and-set), JSON syntax, typed data, replication (built in) and sharding > (via a broker process). > > (MongoDB downsides: it grows files in a very greedy way to try and > minimize data fragmentation, and it needs a 64bit machine to store > more than about 2Gb.) > > On Dec 30 2009, 11:52 am, Gabi wrote: > > > On first look, Redis and Clojure seems to be a perfect match. They > > both handle sets and maps efficiently. If one could find an easy way > > to store and retrieve Clojure data structures to Redis (even a small > > subset- just a list or a set), a distributed clojure app could be very > > easy (and effective?) thing to do - The stateless Clojure nodes would > > share and operate on the same central data structure which is stored > > in Redis). What do you thing ? Is it worth investigating further? -- You 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
Sequence to Vector
What is the preferred way getting a vector back from sequence, after a sequence producing operation (like sort)? Does using (vec..) on a sequence that was a vector is costly? One (bad?) possibility is creating a new vector out of sequence: (vec (sort [1 2 3 4 5 6])) I am asking because I need random access (nth ..) to huge sorted vectors - which are now actually huge sequences after the sort, with horrible O(n) random access time -- You 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: Proposal: clojure.io
Kevin Downey writes: > (io/read [:lines :from :as p] >(do-stuff-with-a-string p)) > > (io/read [:lines :from ]) ;no :as binding or body, results > in a lazy-seq of lines And it's important to specify whether "p" in the former or the head item in the sequence in the latter remain valid after the next step to the next line. Though obviously easier to use, it annoys me when a line-by-line library function forces fresh allocation for every line. I'd like to see an option to reuse a buffer that holds the most-recently-read line, and stepping to the next line overwrites that buffer. The line offered is a read-only /view/ of the mutable buffer. "Saving" a line for future use hence requires an explicit copy -- something that's not likely idiomatic in Java or Clojure. -- Steven E. Harris -- You 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
SLIME/Swank problem with swank.util.sys/get-pid and RuntimeMXBean (was: Clojure/SLIME/Emacs questions)
"Steven E. Harris" writes: > My next step will be to instrument the Swank side to see when > `connection-info' is being called. I found the problem: swank.util.sys/get-pid. It looks like the JMX call to get the PID hangs. If I visit the *inferior-lisp* buffer's REPL and evaluate the following form, the REPL finishes connecting immediately: ,[ Fragment of `get-pid' function ] | (.. java.lang.management.ManagementFactory | (getRuntimeMXBean) (getName) (split "@")) ` Apparently forcing more than one call through that path kicks it out of some wait, and the thread blocked on the Swank-side function `swank.commands.basic/connection-info' finally finishes its call to get-pid. Note that calling java.lang.management.ManagementFactory#getRuntimeMXBean() is not sufficient to unblock the thread in `connection-info'. It takes the following call to RuntimeMXBean#getName() to unblock the wait. Is there a separate mailing list to which I should report this problem? -- Steven E. Harris -- You 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: Proposal: clojure.io
My 2c. In any clojure.io library, make sure none of the warts that are planned to be fixed in NIO2 are codified. JDK7 includes work on Path, large directory traversal, event notifications etc. See http://java.sun.com/developer/technicalArticles/javase/nio/ Alexander 2010/1/1 Phil Hagelberg > > I've been looking over our use of contrib in our large-ish project > at work. About 90% of the invocations of contrib functions are > I/O-related. I wonder if it would be a good idea to include a clojure.io > namespace in Clojure itself. I've mentioned the idea a few times on IRC, > and people seemed to be very much in favour. > > I've prototyped this in the attached file. Most of the functions come > from contrib's duck-streams library. I've taken everything from > duck-streams except read-lines, file-str, make-parents, and pwd. > > read-lines was left out since using it will quite often result in a > leak; closing resources inside a lazy-seq is almost always > problematic. with-in-reader should be used instead. file-str was omitted > because file from java-utils is much nicer. make-parents was omitted in > favour of a new more general function, mkdir. pwd was omitted because > the JVM doesn't have a notion of a "working directory" as most > environments do. But it could be moved to contrib's java-utils if people > are fond of it. > > I've also taken the file, delete-file, and delete-file-recursively > functions from java-utils. I've added support for treating ~ as $HOME to > file since that was present in duck-streams' file-str function. delete-file > and delete-file-recursively are especially necessary if you ever write > tests for functions that create files. relative-path-string and as-file > were also taken from java-utils simply because they are used for the > file function. > > I welcome discussion about this proposal. Do you think it's necessary? Are > there any functions we should leave out? Any others we should promote from > contrib? > > -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 > -- You 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: Proposal: clojure.io
On Jan 1, 4:34 pm, Phil Hagelberg wrote: > Sean Devlin writes: > > 1. I'd recommend adding support for general unix file utilities. > > I've written some of them myself, and you can review/borrow/steal code > > from here: > > >http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/s... > > These are all one-line wrappers around Java methods. I know Rich has > stated that the Clojure philosophy is to avoid such wrappers unless they > provide significant additional value. Perhaps this will need to change > as people start to write more cross-platform code, but I don't know if > we're to that point yet. You missed a small detail. There is a call to the to-file function in there. This allows the file utilities to work on file objects or string paths the same way. I like this trick because it lets the fns work on a broader set of inputs > > 2. duck-streams works very well for text, but not binary formats. I > > know there was discussion about it here: > > >http://groups.google.com/group/clojure/browse_thread/thread/416ca90d3... > > I believe it's the case that reader and writer don't work for binary > formats, but copy should. Copying between two files or between a file > and a byte array should work fine unless I'm missing something. This > should be better-documented though. > > > 3. There should be a brainstorming session to see what objects reader/ > > writer will dispatch over, and the multimethods improved accordingly. > > This should probably happen anyway. > > It covers everything I can think of, but if you've got suggestions let's > hear them. The java.sql.Clob & Blob interfaces might be a nice cases to add (where possible). Sean > > -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: Sequence to Vector
You vec approach is the current solution. I'm 95% sure you'll have to pay the O(n) once, but you'll be good to go after that. Sean On Jan 1, 7:19 pm, Gabi wrote: > What is the preferred way getting a vector back from sequence, after a > sequence producing operation (like sort)? Does using (vec..) on a > sequence that was a vector is costly? > > One (bad?) possibility is creating a new vector out of sequence: > > (vec (sort [1 2 3 4 5 6])) > > I am asking because I need random access (nth ..) to huge sorted > vectors - which are now actually huge sequences after the sort, with > horrible O(n) random access time -- You 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: update-in and get-in why no default?
Tim, I don't think your version of the signature supports variadic defaults well. Also, I'd (initially) implement fnil differently that Rich. Here's my fnil-2 that I *suspect* has the intended behavior (defn fnil-2 [f & defaults] (fn[& args] (let [used-args (map (fn [default-value value] (if value value default-value)) defaults args)] (apply f used-args user=>(def nil+ (fnil-2 + 0 1 2 3 4 5 6)) user=>(nil+ nil) 0 user=>(nil+ 0 nil) 1 user=>(nil+ 0 0 nil) 2 user=>(nil+ 0 0 0 nil) 3 ... user=>(nil+ 0 0 0 0 0 0 nil) 6 ;This example exceeds the provided # of nil values user=>(nil+ 0 0 0 0 0 0 0 nil) NPE You get the idea. Also, Rich's style matches the signature of partial better, which I personally prefer. Just my $.02 Sean On Jan 1, 6:45 pm, Timothy Pratley wrote: > On Dec 13, 1:24 am, Rich Hickey wrote: > > > fnil seems to me to have greater utility than patching all functions > > that apply functions with default-supplying arguments. > > Hi Rich, > > To further comment on fnil, after having experimented with it a bit > now, I've come to slightly prefer specifying the 'default' value > before the function just because I think it reads nicer: > (fnil 0 inc) ;; instead of (fnil inc 0) > (fnil [] conj) ;; instead of (fnil conj []) > I read it as "fill nil with 0 for inc" > I suppose "fill nil of inc with 0" makes just as much sense but I find > "inc 0" leads my eye to believe 0 will always be passed to inc, > whereas "0 inc" does not. Putting the function last makes it clearer > to me that the 0 is conditional. It also looks more like if nil 0. > This contrasts with get, which makes perfect sense having the default > last, but I think at this point fnil and get are sufficiently far > apart that a different argument order would not be surprising. > > Just a small observation I thought I'd raise for discussion to see > what preferences are out there if this function becomes widespread. > > Regards, > Tim. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: SLIME/Swank problem with swank.util.sys/get-pid and RuntimeMXBean
"Steven E. Harris" writes: > Is there a separate mailing list to which I should report this problem? There's http://groups.google.com/group/swank-clojure, though for this particular issue you can just continue in this thread. But I'm not quite following on the exact problem and specific repro case; could you clarify? Does it occur with the latest version of swank-clojure? -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: Proposal: clojure.io
Stuart Sierra writes: > On Dec 31 2009, 9:58 pm, Phil Hagelberg wrote: >> I wonder if it would be a good idea to include a clojure.io >> namespace in Clojure itself. I've mentioned the idea a few times on IRC, >> and people seemed to be very much in favour. > > I've considered this too, but I know Rich Hickey has plans for a > dedicated I/O library. It's been on http://clojure.org/todo for a > while. Details are sketchy, but presumably it would be functional, > stream-based, and thread-safe. Hmm... last I heard those features were abandoned or shelved, but I could be wrong. If there are plans and ideas for a more functional I/O library in the near future we should be discussing that instead. I'm just speaking from what's worked for me in the past year. -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: Sequence to Vector
On Fri, Jan 1, 2010 at 7:19 PM, Gabi wrote: > > I am asking because I need random access (nth ..) to huge sorted > vectors - which are now actually huge sequences after the sort, with > horrible O(n) random access time Clojure's 'sort' actually copies your input collection into an array, and then uses java.util.Arrays/sort to sort it in place. It then wraps a seq around that array, which is good in that it makes that array essentially immutable, but bad for indexed lookup. You might consider using java.util.Array/sort yourself, then you could get very fast indexed lookups into the sorted array using 'aget'. A bit uglier, but ought to be quite fast. It does raise the question of whether it would be good for ArraySeqs to implement Indexed. Then 'nth' would be fast on the object that 'sort' returns. --Chouser -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Language similarities
I can attest from personal experience that many of the folks who were working on Ada were quite familiar with everything going on with Lisp as well as Smalltalk and other language trends of the day (this was around 1980). While many of the ideas in Ada aren't so popular now (and weren't even while the language was being developed), it certainly wasn't due to ignorance of what was happening around them. Tom On Jan 1, 10:45 am, David Brown wrote: > On Fri, Jan 01, 2010 at 12:31:16PM -0500, Mike Meyer wrote: > >On Fri, 1 Jan 2010 13:45:43 -0300 > >Angel Java Lopez wrote: > > >> I would like to add Ada exception management. I don't know if there were > >> previous work on the field. Any info? I worked with Algol, but I don't > >> remember if something like exceptions was present those days. Any early > >> Lisp > >> exception management? > > >Try/Catch were add to MacLisp in 1972, because the previous error > >handling facilities (ERR/ERRSET) were being abused to get that > >behavior. This predates the formation of the Ada working group by a > >couple of years. > > I don't think I've ever seen any cross references between any of the > Lisp documentation and any of the Ada documentation. The Ada > rationale only references a couple of obscure papers about exceptions. > Perhaps they didn't want to scare people by mentioning where they got > the idea. > > I guess another concept that wasn't really accepted until a > "mainstream" language started using it. > > 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: Clojure 1.1 release
Howard Lewis Ship writes: > Is this available via a Maven repo yet and, if so, what version of > clojure-contrib is compatible (and stable?). I just added the 1.1.x branch to build.clojure.org, so you can use http://build.clojure.org/snapshots to get it. It looks like contrib has finally had its version number bumped, though it hasn't had an official release, so 1.1.0-master-SNAPSHOT works for it. -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: leiningen javac plugin
Saul writes: > Many thanks. This works for me and I find it useful. However, in a > perfect world: > > lein compile > > would also compile my java source code or call compile-java before > performing a compile. In fact in this perfect world: > > lein swank > > would download all dependencies, compile java files and then start a > swank server. Is there anyway to get leiningen plugins to depend on > each other or has this behaviour been omitted by design? I am not opposed to setting up a hooks system that would define a number of built-in hooks for which plugins could add functions, much like the way Emacs does it. I haven't needed it myself, but if you would find it useful and care enough to take the time to implement it, I welcome a discussion of the feature. -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: leiningen plugins and scripting
Saul writes: > Hello, > I'm moving a small project over from maven built scala to leiningen > built clojure. One of the features that was available with the maven > scala plugin was the ability to run scala scripts: > > mvn scala:script -DscriptFile=scripts/build_db.scala > > This is useful for doing project specific tasks that are too > specialised for a plugin such as downloading content or sending > emails. It would be really cool to be able to do something like this > in leiningen. For small tasks, you can simply define them in project.clj. Just use with-ns: (use 'clojure.contrib.with-ns) (with-ns 'leiningen.build-db (defn build-db "Build a DB from scratch." [project & args] (do things to build the db))) Tasks are simply functions named $TASK defined in the leiningen.$TASK namespace. They take a project arg as well as any further command-line arguments. Of course, for anything longer than a few lines you're not going to want it in project.clj. But you can include a src/leiningen/ for your longer custom tasks. There shouldn't be any problems with that, but I haven't tried it myself to confirm. -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: Leiningen uberjar: excluding dev-dependencies; new minus-clojure task
Perry Trolard writes: > Currently for the Leiningen uberjar task, all dev-dependencies are > included in the resulting standalone jar. In a comment in uberjar.clj, > there's a note that excluding these is on the todo list. I wonder if > there are any ideas on how best to do it? One simple way would be to simply invoke clean and deps before running the main uberjar code, but that's wasteful. > I tried to tackle this in a naive way — finding jar files based on the > project name — but this doesn't catch dependecies futher down the > chain, e.g. for lein-clojars this'll find the lein-clojars.jar but > won't find jsch.jar, its dependency. More maven-aware folks may have > better ideas, but how does this solution sound: segregating dev- > dependencies in the /lib/dev directory upon download? For > lein tasks that construct the project classpath, lib/dev would then be > included in it; for the uberjar task, only jars in the lib directory > would be zipped up. I'm a little reluctant to make calculating the classpath any more complicated than it currently is since that logic needs to be duplicated in a few places, but I agree that the current situation is not great. Another idea would be to write a hidden blacklist file when fetching the dev dependencies. The uberjar could then check that to know which jars to skip. I'm not sure which approach I prefer... thoughts? > I was working on uberjar because I want to write a similar task as a > plugin, which is an uberjar without clojure & clojure-contrib > included, so that I can drop a project & its dependencies in my local > Clojure development environment, e.g. my Clojure saxon wrapper library > as well as the Java Saxon jars it depends on. Anyone else have this > use case? I'm not sure I understand. Why don't you just open your saxon wrapper project in your IDE directly rather than adding an uberjar generated from it? Plus if you put clojure and contrib on the classpath before your uberjar, then the versions in your uberjar will be shadowed. -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
