parallel factorial (code in the files section)
Hello folks, In the process of learning agents I have written a parallel implementation of factorial function. The code is in files section as "parallel-factorial-example.clj", shared in the hope that it can help others to understand the agents. It is by no means a production code... Comments welcome. Kind regards, Vlad --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
Mibu writes: > I recommended clojure to a dozen friends or so and after a while none > of them stuck with it. I know clojure being a lisp and being at the > current development stage is not for everyone, but after I probed why > people gave up with it I saw the barriers to entry were largely > superficial and can be easily solved with some clarifications: > > The most problematic issue is the editor. There are too many options > to check and to choose from and there is no "best" option. I remember > I got analysis paralysis myself when I had to choose an environment > (thinking about configuring slime takes the zest away out of any > exciting new language). If you go with emacs+clojure-mode, you get > something very basic and for those not familiar with emacs, something > that looks very foreign. You want the powerful slime? You will be > exhausted with its setup or worse, defeated by it. The netbeans and > eclipse IDEs are still shaky. People usually tried to install > enclojure because its site looks the slickest but even with the alpha > tag the experience was disappointing to all. People who got my > recommendation after netbeans released v6.5 couldn't get enclojure to > run at all. > > I think the solution to this problem is to give a definitive > recommendation to a single simple editing option at the Getting > Started section and enumerate the other options with their ups and > downs, so people will have the right expectations about them. [...] I don't buy it. When you start using Python, nobody handholds you so that you can pick an editor. You just use whatever you have. So what's the deal here? Let people use whatever they want, try their stuff from the command-line and REPL, and once they get used to it, move up to Emacs and SLIME. I agree there are superficial barriers, though. I believe it is very important for Clojure to: a) have an build process that results in something that you can run from your command line right away (without learning about the syntax of java command-line arguments), b) have an easy and standardized way of installing and accessing libraries (for example, I am happy with Emacs/SLIME, but I do not know how to install and use clojure.contrib yet!), c) quickly develop a working module/library building system with automatic downloads. CPAN is what made Perl popular. This is something that Common Lisp failed horribly at. In general, prefer practicality over dogma. Common Lisp still hasn't dug itself out from the "filesystem? what filesystem? we have our ultra-flexible maxi-portable mega-abstractions called 'pathnames' that let us (theoretically) run the software unchanged on 75 dead platforms". A pity no one can actually use them correctly. And there still is no agreed-upon schema for installing libraries in the filesystem. If we don't get this right quickly, the result will be that core developers will know where to put stuff, and new users won't, resulting in lots of frustration, while core developers won't even understand what the problem is. --J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
trolltech QT opengl SLIME REPL mac os x
I am trying to write an application using the above libraries. There is no point to this app at the moment other than to take my time and enjoy learning clojure. I am hoping that anyone else with these problems will be able to find this post, so I am going to dump. I have had a hell of time getting things to work correctly. First I installed java 1.6, only to find out that trolltech doesn't support that version on os x because it is 64 bit and they haven't ported their libraries to cocoa. The error you get is an initializer failure in JambiObject; it takes quite a while to figure out the inconsistencies. Next I couldn't build because the ant process was finding two xercesimpl.jar files somehow and this was making the construction of the sax parser fail when the qt libs attempt to do their thing when the java task is loading the clojure class from the build directory. I then managed to get an app up and running; the cool thing is that when you close the app it just puts you back in the repl. Then you can call a function and give event handing back to QT. This is fun; I don't have to shutdown to try out lots of different stuff until I hang the process or crash QT. Finally I decided to try out some openGL. I got a complete hang every time I called GL, using the slime repl from emacs. I could get all the rest of my gui stuff working but anything GL related would hang. I tried switching from jogl to lwjgl and the result was the same. super hang. 4 hours of debugging later I tried running the helloGL QT demo and it was working. I then tried it from the command line repl and it worked. Finally I tried it from the slime repl and it just hung. So my question to the gurus in this forum is why, on mac os 10.5 using jvm 1.5 and the latest clojure, slime, aquamacs, clojure-contrib, qt, jogl, swank-clojure, NVIDIA 8600M GT, 2.5 ghz core 2 due, 4 gigs of ram, in a house that is 65 degrees fahrenheit, at 40.03N x 105.25W... would this exact scenario hang? I really want to use slime as my primary repl; I will have to use some crap null gl wrappers when I am not working on gl as it is unless I can get slime to play nice with gl. Clojure is the shit! Unfortunately, java still sucks. Not that it will stop me using clojure. Thanks! oh, the code is at: http://github.com/cnuernber/lambinator/tree/master Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
Mibu, Thanks for your post because it captures what I am passing through. I have not done FP before and I am not even a great programmer, and with FP comes a sea of concepts and abstracts I have not heard before. These concepts and abstracts led me to conclude that FP is not made for mere mortals like me, however, I refused to give up easily and I have been fighting to get my head around FP. First I met a rock, I could not get enough material on Clojure, then I ordered Clojure programming and the book is not even made for someone like me, it is made for 'others'. I took up Scheme just to see if I can port my understanding to Clojure. Here is the rat race I'm into, learning two new and strange languages together, and what have I achieved not much. The way I see it, Clojure family should try and explain Clojure such that none FP guys could easily work their way through. To me terms lazy-con, lazy-evaluation(and other lazies I may not have heard of), strict/non-strict, side effect/referential transparency ,lambda and others should be thoroughly explained and with examples and even placed side-by-side with imperative examples. What about REPL? And the macro, I must add each time I meet macro(s) or do they call it reader macro I start having headache, and finally I heard that Clojure does not have syntax , everything is syntatic sugar. I think I need a mentor! Emeka --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's code has moved to Google Code
Does it makes sense to subscribe this group to those? I.e. to have commit messages appear here. I've done it both ways on my own projects, and I'm of split mind about it. On Wed, Dec 17, 2008 at 9:33 AM, Rich Hickey wrote: > > > > On Dec 17, 8:22 am, Rich Hickey wrote: >> I've moved Clojure's source repo to Google Code: >> >> http://code.google.com/p/clojure/ >> >> as well as Clojure contrib: >> >> http://code.google.com/p/clojure-contrib/ >> >> All new checkins will occur there. >> > > There's also a read-only list/feed that will broadcast commit messages > from both clojure and clojure-contrib: > > http://groups.google.com/group/clojure-commits > > Rich > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
Regarding the editor part, Scite could be a good option, especially for beginners. It's a whole hell of a lot simpler than emacs and vim. All you really have to do by way of configuration is go to "Options" - > "Open User Options File" and paste in the following lines: --- file.patterns.lisp=*.lsp;*.lisp;*.clj command.go.$(file.patterns.lisp)=java -cp /home/jesse/clojure/ clojure.jar clojure.lang.Script "$(FilePath)" -- (change the path as appropriate of course) The syntax highlighting is kind of crude since it's meant for lisp, but that can be fixed by messing around with more configuration options. Now you can just hit F5 and start running stuff. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's code has moved to Google Code
-1 - Original Message > From: Craig Andera > To: clojure@googlegroups.com > Sent: Thursday, December 18, 2008 7:51:43 AM > Subject: Re: Clojure's code has moved to Google Code > > > Does it makes sense to subscribe this group to those? I.e. to have > commit messages appear here. I've done it both ways on my own > projects, and I'm of split mind about it. > > On Wed, Dec 17, 2008 at 9:33 AM, Rich Hickey wrote: > > > > > > > > On Dec 17, 8:22 am, Rich Hickey wrote: > >> I've moved Clojure's source repo to Google Code: > >> > >> http://code.google.com/p/clojure/ > >> > >> as well as Clojure contrib: > >> > >> http://code.google.com/p/clojure-contrib/ > >> > >> All new checkins will occur there. > >> > > > > There's also a read-only list/feed that will broadcast commit messages > > from both clojure and clojure-contrib: > > > > http://groups.google.com/group/clojure-commits > > > > Rich > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's code has moved to Google Code
On Thu, Dec 18, 2008 at 1:51 PM, Craig Andera wrote: > > Does it makes sense to subscribe this group to those? I.e. to have > commit messages appear here. I've done it both ways on my own > projects, and I'm of split mind about it. The clojure google group seems to me to be mostly for support and communication between users of clojure. As such, I think commit messages would add very little but noise to this list. If I want to look at commit messages, I'll do `svn log`. > > On Wed, Dec 17, 2008 at 9:33 AM, Rich Hickey wrote: >> >> >> >> On Dec 17, 8:22 am, Rich Hickey wrote: >>> I've moved Clojure's source repo to Google Code: >>> >>> http://code.google.com/p/clojure/ >>> >>> as well as Clojure contrib: >>> >>> http://code.google.com/p/clojure-contrib/ >>> >>> All new checkins will occur there. >>> >> >> There's also a read-only list/feed that will broadcast commit messages >> from both clojure and clojure-contrib: >> >> http://groups.google.com/group/clojure-commits >> >> Rich >> >> > >> > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
On Dec 18, 1:20 pm, Jan Rychter wrote: > I don't buy it. When you start using Python, nobody handholds you so > that you can pick an editor. You just use whatever you have. So what's > the deal here? An editor for a lisp language is not just a text editor for the source that you then compile. It's an environment that interacts with a REPL. So people can't just use whatever they've been using. The python example only strengthens my argument. Python comes with IDLE which is, similar to many lisp environments, a development environment with an interactive prompt, editor, debugger, etc. Very simple, yet complete and right there for someone new to the language. I think people new to something can't or won't deal with too many tangential issues. That's why selecting an IDE, dealing with classpaths, using svn, finding out where's the latest version, what are the right docs, or as you mentioned, how to install a library, or even how to indent your code are all issues that aren't going away, but shouldn't distract a new adopter who is still trying to get the hang of things. Options are good, but choices are painful, especially to people who feel insecure in their knowledge and judgment because they just got here. Their insecurity is justified. That's why I think definitive defaults are important for adoption of new things. Especially lispy things that look oh-so-foreign. On the same matter, you mentioned a central repository for libraries. I'm with you on that one. I also think a central spot to congregate around is important. IIRC, Rich wants the community to solve this issue by itself (maybe just the build mechanism issue, I don't remember exactly), and in a sense this matter will be solved eventually this way. I still think it would have been much better if an authoritative figure would come up and say, "let's meet over there." Btw, this is exactly what Rich did with the google group, the irc channel, and the wiki. He essentially said let's meet over there, and we all did. Unfortunately, not so with a central repo for external libraries. If anyone is interested in the subject of why excess choice is bad, I highly recommend this short and very thought-provoking talk by Barry Schwartz: http://www.ted.com/index.php/talks/barry_schwartz_on_the_paradox_of_choice.html Mibu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
--- On Thu, 12/18/08, Mibu wrote: > An editor for a lisp language is not just a text editor for > the source that you then compile. It's an environment that > interacts with a REPL. So people can't just use whatever > they've been using. Of course you can--there's no *requirement* that your editor is also your REPL environment, it's just really convenient. Dave --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's code has moved to Google Code
If you really want these commit messages to come to your mailbox, you could always use a service such as: http://www.rssfwd.com/ Note: This was merely the first Google result for "rss email". I have not tested this service, but it looks like it should do the trick. Has there been any thought to providing a twitter/laconica feed of commit messages? You could use a service like http://twitterfeed.com/ if you wanted to go the twitter-only route, or something like http://ciarang.com/posts/feed2omb for laconica. (needs to be hosted) I set up a friendfeed imaginary friend for myself, but I don't believe I can share it. On Thu, Dec 18, 2008 at 7:51 AM, Craig Andera wrote: > > Does it makes sense to subscribe this group to those? I.e. to have > commit messages appear here. I've done it both ways on my own > projects, and I'm of split mind about it. > > On Wed, Dec 17, 2008 at 9:33 AM, Rich Hickey wrote: >> >> >> >> On Dec 17, 8:22 am, Rich Hickey wrote: >>> I've moved Clojure's source repo to Google Code: >>> >>> http://code.google.com/p/clojure/ >>> >>> as well as Clojure contrib: >>> >>> http://code.google.com/p/clojure-contrib/ >>> >>> All new checkins will occur there. >>> >> >> There's also a read-only list/feed that will broadcast commit messages >> from both clojure and clojure-contrib: >> >> http://groups.google.com/group/clojure-commits >> >> Rich >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's code has moved to Google Code
On Dec 18, 7:51 am, "Craig Andera" wrote: > Does it makes sense to subscribe this group to those? I.e. to have > commit messages appear here. I've done it both ways on my own > projects, and I'm of split mind about it. > It's a distinct list in order to give people choice and keep the noise out of the group, so I won't be subscribing this group. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
On Dec 18, 2:37 pm, janus wrote: > I think I need a mentor! Come to the IRC channel (#clojure on irc.freenode.net). The people there are friendly, helpful, and surprisingly patient. Mibu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
20081217 Release
I've cut a new release, 20081217, which is available from Google Code: http://clojure.googlecode.com/files/clojure_20081217.zip It reflects the many enhancements made since the last release: AOT Compilation gen-class gen-interface clojure.main proxy performance tweaks move to EPL io! blocks atoms intern, trampoline, while enhanced doto, doseq uniform local bindings print multimethods print-dup maps implement java.util.Map agent watches *1 et al and many more fixes and enhancements: http://code.google.com/p/clojure/source/list This release should facilitate everyone using the same post-AOT API, and brings us closer to the 1.0 release. I'll be going through the docs to bring them up to date. If you are using an old release, please move to this one, as it is what the documentation will reflect moving forward. There are a few small things marked high priority I'd like to get done for 1.0: http://code.google.com/p/clojure/issues/list?can=2&q=priority:High Patches welcome from any registered contributors. Thanks again for all of your support and feedback! Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: code golf
Hello,
On Dec 18, 5:49 am, Chouser wrote:
> Which leads me to this, though it fails for reasons that escape me:
> (defn enc[s e](apply str(map`{~@(take-nth 2 e)}s)))
This one maybe fails because ~@ is a reader form that needs to expand
at compile time.
So if at compile time, e is not known (e.g. if e refers to a
function's argument), it fails.
But maybe, during the tests, e was bound to a literal string (and thus
usable at compile to for the expansion).
> But here's a form that works, oddly, and still manages to shave off a
> couple chars:
>
> (defn enc[s e](apply str(map`{0~@(cons 0(take-nth 2 e))}s)))
>
> --Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Superficial barriers to entry
Hi, On 18 Dez., 14:09, Mibu wrote: > An editor for a lisp language is not just a text editor for the source > that you then compile. It's an environment that interacts with a REPL. We should stay on the carpet, shouldn't we? If you have such an environment, fine. I use vim, which is undoubtedly one of the most powerful editors out there. But until recently I copy'n'pasted my code into the Repl. No SLIME here. Still I could edit Clojure code. This is just a matter of convenience. > So people can't just use whatever they've been using. The python > example only strengthens my argument. Python comes with IDLE which is, > similar to many lisp environments, a development environment with an > interactive prompt, editor, debugger, etc. Very simple, yet complete > and right there for someone new to the language. Now we turn back time to approx. one year after the first official Python release. Was there an IDLE? One year after the first official release of Perl. Was there a CPAN? (Honest questions, but I suspect both answers to be "No") There is so much going on at the editor front at the moment: - emacs + SLIME - a jedit mode - enclojure for netbeans - eclipse plugin - vim + gorilla If you just want to get started, use whatever you have, or Clojure Box to get an emacs + SLIME combination working out of the box, preconfigured, ready to repl away. Regarding syntax highlighting and indenting, the Vim mode is state of the art. I'm working on Gorilla to bring a SLIME-like feeling to the Vim world. Everything is in motion and develops. Maybe you just have the wrong expectations? Remember: Clojure was released *one* year ago! And now have again a look at the community. Everything is humming with activity. That not everything is ready to use is not surprising. So dear newbies: have some patience. Clojure is a language developing at a breath-taking pace. If you are learning not only Clojure, but also FP for example, then step back and wait for 1.0 to let the development stabilise or bring patience with you. Of course, there are still things missing, but the community is working on it. So don't turn Clojure down, because it's not perfect, yet. 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 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: Superficial barriers to entry
Mibu On Dec 18, 1:22 pm, Mibu wrote: > On Dec 18, 2:37 pm, janus wrote: > > > I think I need a mentor! > > Come to the IRC channel (#clojure on irc.freenode.net). The people > there are friendly, helpful, and surprisingly patient. > > Thanks for your advice,however, if you wont mind I will ant to be your mentee! Emeka --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
YAREPL - GUI repl updated
Yet Another REPL I uploaded a GUI repl to the group files earlier this year, and I've been updating it as Clojure has evolved. A new version has been uploaded (tested with SVN 1162) http://clojure.googlegroups.com/web/repl.clj , and I've also uploaded a couple of pictures, http://clojure.googlegroups.com/web/gui-repl-demo-1.PNG , http://clojure.googlegroups.com/web/gui-repl-demo-2.PNG. The second picture shows a recent improvement to the way multimethods are presented in the namespace tree. The repl can be run as a script (using clojure.lang.Script). It expects to find the clojure source (core.clj, set.clj, etc) on the classpath, and starts by loading these into a Swing JTree. The source is currently still in clojure.jar as generated by ant, so the following should work (assuming you have a classes directory where repl.clj resides): java -cp clojure.jar;./classes clojure.lang.Script ./classes/ repl.clj Basic paren, bracket and brace highlighting is provided. I find the namespace tree very helpful for browsing source, and I think the new handling of multimethods will be helpful also. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20081217 Release
> This release should facilitate everyone using the same post-AOT API, > and brings us closer to the 1.0 release. I'll be going through the > docs to bring them up to date. If you are using an old release, please > move to this one, as it is what the documentation will reflect moving > forward. Rich, if you put the docs in a public repo we could help with the burden and submit patches (e.g. the slightly out of date code for the Celsius calculator I noticed the other day). Cheers, -Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20081217 Release
On Dec 18, 2008, at 10:03 AM, Mark Fredrickson wrote: > >> This release should facilitate everyone using the same post-AOT API, >> and brings us closer to the 1.0 release. I'll be going through the >> docs to bring them up to date. If you are using an old release, >> please >> move to this one, as it is what the documentation will reflect moving >> forward. > > Rich, if you put the docs in a public repo we could help with the > burden and submit patches (e.g. the slightly out of date code for the > Celsius calculator I noticed the other day). > Yes, I plan to investigate using the Google Code wiki for the docs, but not right now. The calculator sample only became out of date last night when I cut a new release - (the docs other than the API page reflect the most recent release), and was changed last night to match the release. That doesn't negate your point, just another item to do :) Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: FAQ
On Dec 17, 6:28 pm, kkw wrote: > What's the recommended way of getting Clojure up and running? > - Download the latest snapshot with SVN > - Create the Clojure.jar file with Ant > - Test by starting up the REPL with "java -cp clojure.jar > clojure.lang.Repl" That's a good FAQ suggestion, Kev. With the latest release, it's even shorter! 1. Download clojure_20081217.zip 2. Run java -jar clojure.jar -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20081217 Release
FYI, I noticed that the readme.txt in the release still says to run with clojure.lang.Repl, when all you need now is: java -jar clojure.jar -Stuart Sierra On Dec 18, 8:46 am, Rich Hickey wrote: > I've cut a new release, 20081217, which is available from Google Code: > > http://clojure.googlecode.com/files/clojure_20081217.zip > > It reflects the many enhancements made since the last release: > > AOT Compilation > gen-class > gen-interface > clojure.main > proxy performance tweaks > move to EPL > io! blocks > atoms > intern, trampoline, while > enhanced doto, doseq > uniform local bindings > print multimethods > print-dup > maps implement java.util.Map > agent watches > *1 et al > > and many more fixes and enhancements: > > http://code.google.com/p/clojure/source/list > > This release should facilitate everyone using the same post-AOT API, > and brings us closer to the 1.0 release. I'll be going through the > docs to bring them up to date. If you are using an old release, please > move to this one, as it is what the documentation will reflect moving > forward. > > There are a few small things marked high priority I'd like to get done > for 1.0: > > http://code.google.com/p/clojure/issues/list?can=2&q=priority:High > > Patches welcome from any registered contributors. > > Thanks again for all of your support and feedback! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: YAREPL - GUI repl updated
On Thu, Dec 18, 2008 at 8:44 AM, MikeM wrote: > > Yet Another REPL > > I uploaded a GUI repl to the group files earlier this year, and I've > been updating it as Clojure has evolved. A new version has been > uploaded (tested with SVN 1162) http://clojure.googlegroups.com/web/repl.clj > , > and I've also uploaded a couple of pictures, > http://clojure.googlegroups.com/web/gui-repl-demo-1.PNG , > http://clojure.googlegroups.com/web/gui-repl-demo-2.PNG. The second > picture shows a recent improvement to the way multimethods are > presented in the namespace tree. > > The repl can be run as a script (using clojure.lang.Script). It > expects to find the clojure source (core.clj, set.clj, etc) on the > classpath, and starts by loading these into a Swing JTree. The source > is currently still in clojure.jar as generated by ant, so the > following should work (assuming you have a classes directory where > repl.clj resides): > java -cp clojure.jar;./classes clojure.lang.Script ./classes/ > repl.clj > > Basic paren, bracket and brace highlighting is provided. I find the > namespace tree very helpful for browsing source, and I think the new > handling of multimethods will be helpful also. Very cool! Another nice touch would be if you could display the source code for a function in the lower-left pane when a function is selected in the upper-right pane. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20081217 Release
On Dec 18, 10:44 am, Stuart Sierra wrote: > FYI, I noticed that the readme.txt in the release still says to run > with clojure.lang.Repl, when all you need now is: > java -jar clojure.jar > Starting with -jar shuts down the classpath, so is not something I think you want to show someone, as they will have to abandon that method almost immediately. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20081217 Release
On Thu, Dec 18, 2008 at 9:44 AM, Stuart Sierra wrote: > > FYI, I noticed that the readme.txt in the release still says to run > with clojure.lang.Repl, when all you need now is: > java -jar clojure.jar I wonder how many people will really use it that way (with -jar). The problem is that you can't also include clojure-contrib.jar if you use that form. I'm guessing that almost everybody wants that in the classpath too, but I could be wrong. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: FAQ
On Dec 18, 10:42 am, Stuart Sierra wrote: > On Dec 17, 6:28 pm, kkw wrote: > > > What's the recommended way of getting Clojure up and running? > > - Download the latest snapshot with SVN > > - Create the Clojure.jar file with Ant > > - Test by starting up the REPL with "java -cp clojure.jar > > clojure.lang.Repl" > > That's a good FAQ suggestion, Kev. With the latest release, it's even > shorter! > 1. Download clojure_20081217.zip > 2. Run java -jar clojure.jar > This begs (for me at least) the question: At what point does a FAQ become a restatement of the docs in Q/A format? And how do you avoid that? E.g. my answer to that question would be "read the Getting Started section of the docs". Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
I would like to see more practical screencasts. RH's Clojure talks are interesting but only at a high level. I'd like to see a screencast on Emacs/SLIME because I have no idea what the hell it is or what it offers over a basic screencast. Likewise, doing screencasts on macros, concurrency primitives, etc at a code level would be extremely helpful. I'm thinking along the same vein as Ryan Bates's RailsCasts (http://railscasts.com) mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
CLI launcher (was: Superficial barriers to entry)
Jan Rychter writes: > Let people use whatever they want, try their stuff from the command-line > and REPL, and once they get used to it, move up to Emacs and SLIME. Agreed. > I agree there are superficial barriers, though. I believe it is very > important for Clojure to: > > a) have an build process that results in something that you can run > from your command line right away (without learning about the syntax > of java command-line arguments), This was one of the most disorienting things I encountered when starting with clojure. I'm used to codebases providing a bin/ directory or at least a shell script to start from. It wouldn't be so bad if the java CLI launcher were any good, but it's pretty lousy. I've been looking at hashdot, (http://hashdot.sourceforge.net/) and it seems to address the weaknesses of the java command in a pretty intuitive way that makes it seem like a first-class citizen in Unix. It lets you write shebang-savvy scripts, and it sets the process names so you get something reasonable showing up in ps and top instead of the jumble of alphanumerics that the jvm shows by default. So far I've only used it with JRuby, but it's meant to work with any JVM-hosted language. It seems like it addresses a pain point that is particularly onerous with 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 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: Superficial barriers to entry
I agree, IDE wise, SciTe or Vim, a running REPL in a shell and load-file just does it for us... Years ago I was using Emacs but left it for other IDEs (Eclipse) for so long that I would need a few weeks to get back into it. Not having the time in the last 6 months to dedicate getting fluent again in Emacs, I got along with language sensitive editors. I do not feel it cost me time not using and advanced IDE since the amount of Clojure code lines is by far less than their Java equivalents. On the fly expression evaluation and other features like that are good but there is much more to learn before these features become essentials... Surprisingly, stability of the Clojure run time has not been a big issue in our project. Rich does a good job to maintain things stable. That's one of the best open source effort I saw in terms of robustness. Contributors are also clever people. Even if 1.0 is not out yet, useful work (i.e. production mode stuff) is doable with Clojure. We do it right now... Luc On Thu, 2008-12-18 at 05:52 -0800, Meikel Brandmeyer wrote: > Hi, > > On 18 Dez., 14:09, Mibu wrote: > > An editor for a lisp language is not just a text editor for the source > > that you then compile. It's an environment that interacts with a REPL. > > We should stay on the carpet, shouldn't we? If you have such an > environment, fine. I use vim, which is undoubtedly one of the most > powerful editors out there. But until recently I copy'n'pasted my code > into the Repl. No SLIME here. Still I could edit Clojure code. This > is just a matter of convenience. > > > So people can't just use whatever they've been using. The python > > example only strengthens my argument. Python comes with IDLE which is, > > similar to many lisp environments, a development environment with an > > interactive prompt, editor, debugger, etc. Very simple, yet complete > > and right there for someone new to the language. > > Now we turn back time to approx. one year after the first > official Python release. Was there an IDLE? One year after > the first official release of Perl. Was there a CPAN? (Honest > questions, but I suspect both answers to be "No") > > There is so much going on at the editor front at the moment: > - emacs + SLIME > - a jedit mode > - enclojure for netbeans > - eclipse plugin > - vim + gorilla > > If you just want to get started, use whatever you have, or > Clojure Box to get an emacs + SLIME combination working > out of the box, preconfigured, ready to repl away. > > Regarding syntax highlighting and indenting, the Vim mode > is state of the art. I'm working on Gorilla to bring a SLIME-like > feeling to the Vim world. > > Everything is in motion and develops. Maybe you just have > the wrong expectations? Remember: Clojure was released > *one* year ago! And now have again a look at the community. > Everything is humming with activity. That not everything > is ready to use is not surprising. > > So dear newbies: have some patience. Clojure is a language > developing at a breath-taking pace. If you are learning not > only Clojure, but also FP for example, then step back and > wait for 1.0 to let the development stabilise or bring patience > with you. > > Of course, there are still things missing, but the community > is working on it. So don't turn Clojure down, because it's > not perfect, yet. > > 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 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: FAQ
> Suggestions for entries welcome here. > > Rich How about: What language constructs/objects may be found in the function position of an expression? Ii like the fact that sets, maps and vectors are all 'functions of their keys', and that keywords and symbols are functions of maps. ((([ + - apply ] 2) hash-map [ 1 "one" 3 "three"]) 1 ) Examples would be useful --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
On Thu, Dec 18, 2008 at 3:20 AM, Jan Rychter wrote: > I don't buy it. When you start using Python, nobody handholds you so > that you can pick an editor. You just use whatever you have. So what's > the deal here? At least on Windows, Python comes with IDLE, which is surprisingly full-featured given its simplicity. It's got an integrated editor, repl, debugger, help files, etc. Very, very easy to get up and running, and I've used Python for real work for years without needing anything more elaborate. Perhaps the cream-of-the-crop for simple-to-use-but-powerful IDEs is DrScheme, the IDE that comes with PLT Scheme. I find it far more pleasant than the mega-complicated Java IDEs lke Eclipse. And of course, PLT has had many years of graduate students researching and including innovative features like their macro debugger, which I haven't seen in any other development environment. Something like that for Clojure would be a huge boon, but of course, it took them many man-years to develop, so I'm not holding my breath. Something along the lines of Python's IDLE seems more realistic. Clojure is designed to be a real-world language for practical use, so practical details, such as IDEs, take on significance. Yes, these are early days, and it's a sign that the language gets so much right that people "want it now", and overall, that's a good thing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: trolltech QT opengl SLIME REPL mac os x
Generally speaking, there are complications with using OpenGL from multiple threads, I wonder if the calls you make via the Slime/Swank interface are in a different thread than the one that allocated the OpenGL context. Here's some documentation that may be relevant if you are using OS X: http://developer.apple.com/documentation/graphicsimaging/Conceptual/OpenGL-MacProgGuide/opengl_threading/chapter_12_section_4.html#//apple_ref/doc/uid/TP40001987-CH409-SW9 http://developer.apple.com/documentation/graphicsimaging/Conceptual/OpenGL-MacProgGuide/opengl_threading/chapter_12_section_3.html#//apple_ref/doc/uid/TP40001987-CH409-SW7 On Dec 17, 11:33 pm, chris wrote: > I am trying to write an application using the above libraries. There > is no point to this app at the moment other than to take my time and > enjoy learning clojure. I am hoping that anyone else with these > problems will be able to find this post, so I am going to dump. > > I have had a hell of time getting things to work correctly. First I > installed java 1.6, only to find out that trolltech doesn't support > that version on os x because it is 64 bit and they haven't ported > their libraries to cocoa. The error you get is an initializer failure > in JambiObject; it takes quite a while to figure out the > inconsistencies. > > Next I couldn't build because the ant process was finding two > xercesimpl.jar files somehow and this was making the construction of > the sax parser fail when the qt libs attempt to do their thing when > the java task is loading the clojure class from the build directory. > > I then managed to get an app up and running; the cool thing is that > when you close the app it just puts you back in the repl. Then you > can call a function and give event handing back to QT. This is fun; I > don't have to shutdown to try out lots of different stuff until I hang > the process or crash QT. > > Finally I decided to try out some openGL. I got a complete hang every > time I called GL, using the slime repl from emacs. I could get all > the rest of my gui stuff working but anything GL related would hang. > I tried switching from jogl to lwjgl and the result was the same. > super hang. > > 4 hours of debugging later I tried running the helloGL QT demo and it > was working. I then tried it from the command line repl and it > worked. Finally I tried it from the slime repl and it just hung. > > So my question to the gurus in this forum is why, on mac os 10.5 using > jvm 1.5 and the latest clojure, slime, aquamacs, clojure-contrib, qt, > jogl, swank-clojure, NVIDIA 8600M GT, 2.5 ghz core 2 due, 4 gigs of > ram, in a house that is 65 degrees fahrenheit, at 40.03N x 105.25W... > > would this exact scenario hang? I really want to use slime as my > primary repl; I will have to use some crap null gl wrappers when I am > not working on gl as it is unless I can get slime to play nice with > gl. > > Clojure is the shit! > > Unfortunately, java still sucks. Not that it will stop me using > clojure. > > Thanks! > > oh, the code is at: http://github.com/cnuernber/lambinator/tree/master > > Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: trolltech QT opengl SLIME REPL mac os x
I think you are absolutely correct. I am using -XstartOnFirstThread, but I noticed when the application works it outputs a message about the CocoaCompatibilty enabled. This is triggered somehow from the jogl calls. This indicates there is some threading going on behind the scenes as that compatibility layer is for dealing with asyncronous calls to or from awt threads. I have decided to dump QT and move to a swing UI. I have read a lot of posts about the upgrades and openGL 2D integration it has in java 1.6 so I guess I will just try it out. I will do most of my rendering to FBO's anyway so I won't be using the pbuffer crap in it now; jogl exposes the base opengl calls and their extensions. QT freezes if you don't use -XstartOnFirstThread in your java arg; this is an indicator that mixing it with anything awt replated (as jogl certainly is) is going to have some perhaps dire consequences. Two of the three hard problems I came across were due to QT; I guess from my perspective, until they port it to cocoa, it isn't really useful for java on the mac. Really rough introduction to java, however. Everything I tried went bang in odd ways; and it wasn't clojure as much as it was jar, jni, dylib, mac hell. Luckily I work in c++ so I am used to all this shit. Thanks for the reply! Chris On Dec 18, 10:17 am, AA wrote: > Generally speaking, there are complications with using OpenGL from > multiple threads, I wonder if the calls you make via the Slime/Swank > interface are in a different thread than the one that allocated the > OpenGL context. Here's some documentation that may be relevant if you > are using OS X: > > http://developer.apple.com/documentation/graphicsimaging/Conceptual/O... > > http://developer.apple.com/documentation/graphicsimaging/Conceptual/O... > > On Dec 17, 11:33 pm, chris wrote: > > > I am trying to write an application using the above libraries. There > > is no point to this app at the moment other than to take my time and > > enjoy learning clojure. I am hoping that anyone else with these > > problems will be able to find this post, so I am going to dump. > > > I have had a hell of time getting things to work correctly. First I > > installed java 1.6, only to find out that trolltech doesn't support > > that version on os x because it is 64 bit and they haven't ported > > their libraries to cocoa. The error you get is an initializer failure > > in JambiObject; it takes quite a while to figure out the > > inconsistencies. > > > Next I couldn't build because the ant process was finding two > > xercesimpl.jar files somehow and this was making the construction of > > the sax parser fail when the qt libs attempt to do their thing when > > the java task is loading the clojure class from the build directory. > > > I then managed to get an app up and running; the cool thing is that > > when you close the app it just puts you back in the repl. Then you > > can call a function and give event handing back to QT. This is fun; I > > don't have to shutdown to try out lots of different stuff until I hang > > the process or crash QT. > > > Finally I decided to try out some openGL. I got a complete hang every > > time I called GL, using the slime repl from emacs. I could get all > > the rest of my gui stuff working but anything GL related would hang. > > I tried switching from jogl to lwjgl and the result was the same. > > super hang. > > > 4 hours of debugging later I tried running the helloGL QT demo and it > > was working. I then tried it from the command line repl and it > > worked. Finally I tried it from the slime repl and it just hung. > > > So my question to the gurus in this forum is why, on mac os 10.5 using > > jvm 1.5 and the latest clojure, slime, aquamacs, clojure-contrib, qt, > > jogl, swank-clojure, NVIDIA 8600M GT, 2.5 ghz core 2 due, 4 gigs of > > ram, in a house that is 65 degrees fahrenheit, at 40.03N x 105.25W... > > > would this exact scenario hang? I really want to use slime as my > > primary repl; I will have to use some crap null gl wrappers when I am > > not working on gl as it is unless I can get slime to play nice with > > gl. > > > Clojure is the shit! > > > Unfortunately, java still sucks. Not that it will stop me using > > clojure. > > > Thanks! > > > oh, the code is at: http://github.com/cnuernber/lambinator/tree/master > > > Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Superficial barriers to entry
On Thu, Dec 18, 2008 at 7:52 PM, Mike Perham wrote: > > I would like to see more practical screencasts. RH's Clojure talks > are interesting but only at a high level. I'd like to see a > screencast on Emacs/SLIME because I have no idea what the hell it is > or what it offers over a basic screencast. Perhaps this is what you're looking for: http://bc.tech.coop/blog/081209.html > Likewise, doing screencasts on macros, concurrency primitives, etc at > a code level would be extremely helpful. I'm thinking along the same > vein as Ryan Bates's RailsCasts (http://railscasts.com) -- Michael Wood --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
running Gorilla
I'm probably doing something wrong, but I haven't been able to get Gorilla to work with Vim. The installation instructions say: 1) Copy the after, doc and plugin directories into your .vim directory. I've done this. My ~/.vim directory now contains afterbin doc ftplugin plugin autoload compiler ftdetect indent syntax 2) Start Gorilla with java -cp clojure.jar:clojure-contrib.jar:gorilla.jar de.kotka.gorilla where each jar is specified with its path. I've done this in a Terminal window (on a Mac). It says "Listening..." and it's still running. 3) Start a Vim session. I've done this, but it doesn't seem to recognize Gorilla shortcuts. Should I be able to open a REPL buffer by entering ":sr"? Am I missing an installation step? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
On Thursday 18 December 2008 11:52, Mark Volkmann wrote: > I'm probably doing something wrong, but I haven't been able to get > Gorilla to work with Vim. The installation instructions say: > > ... > > I've done this, but it doesn't seem to recognize Gorilla shortcuts. > Should I be able to open a REPL buffer by entering ":sr"? > > Am I missing an installation step? First of all, check whether you Vim has the necessary Ruby support: % vim --version |sed -n -e 1p -e '/ruby/p' VIM - Vi IMproved 6.3 (2004 June 7, compiled Aug 15 2007 23:30:49) +path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby % vim --version |sed -n -e 1p -e '/[-+]ruby/p' VIM - Vi IMproved 7.1 (2007 May 12, compiled Dec 12 2007 14:10:50) +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent If you see "-ruby" then you're out of luck until you acquire or rebuild Vim with Ruby support. Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
(Ab)using agents for inter-process communication
Hi, I've not yet seen any examples on how to deal with external processes in Clojure (I hope I didn't overlook something in clojure-contrib). The following is my attempt to start a sub-process and to pass through stdout and stderr. The shell command prints out 1000 lines "hello" and a final "command finished". The problem is that nothing is printed by the Clojure program. If I increase the number of lines for example to 2000 (change "head -1000" to "head -2000"), I see a lot of output, but it is cut off somewhere in the middle and the final "command finished" does never appear. (use 'clojure.contrib.duck-streams) (defn copy [istream ostream] (println "copy" istream ostream) (loop [line (.readLine istream)] (if line (do (.println ostream line) (recur (.readLine istream)) (let [pb (new ProcessBuilder ["sh" "-c" "yes hello | head -1000; echo command finished"]) proc (.start pb) stdout (reader (.getInputStream proc)) stderr (reader (.getErrorStream proc)) stdout-agent (agent stdout) stderr-agent (agent stderr)] (send stdout-agent copy (writer *out*)) (send stderr-agent copy (writer *err*)) (await stdout-agent stderr-agent) (.waitFor proc) (shutdown-agents) (println "done")) Is this use of agents incorrect? Why can the program terminate before all the output from the sub- process has been passed through? Is there a better way to synchronize with sub-processes in Clojure, or is it necessary to synchronize completely at the Java level? Thanks Stephan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
find returns symbol keys without their metadata
Hi
I've been playing around using symbols with metadata as struct map
keys after reading this message:
http://groups.google.com/group/clojure/msg/68e7036dbd8ded29
It all works OK except when you use find to extract an entry. find
returns an entry containing the key passed to it, not the key in the
map. So if you don't use the original key to query the map you don't
get the metadata:
user=> (defstruct s (with-meta 'k {:a "A"}))
#'user/s
user=> (def s1 (struct s 1))
#'user/s1
user=> ^(first (keys s1))
{:a "A"}
user=> (find s1 'k)
[k 1]
user=> ^(first (find s1 'k))
nil
Would it make more sense for find to return an entry containing the
key from the map?
Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: running Gorilla
Hi, Am 18.12.2008 um 20:52 schrieb Mark Volkmann: I've done this, but it doesn't seem to recognize Gorilla shortcuts. Should I be able to open a REPL buffer by entering ":sr"? The keymappings are only active in Clojure buffers. Try editing a clojure file or set the filetype manually with ":setfiletype clojure". Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: running Gorilla
On Thu, Dec 18, 2008 at 2:07 PM, Randall R Schulz wrote: > > On Thursday 18 December 2008 11:52, Mark Volkmann wrote: >> I'm probably doing something wrong, but I haven't been able to get >> Gorilla to work with Vim. The installation instructions say: >> >> ... >> >> I've done this, but it doesn't seem to recognize Gorilla shortcuts. >> Should I be able to open a REPL buffer by entering ":sr"? >> >> Am I missing an installation step? > > First of all, check whether you Vim has the necessary Ruby support: > > % vim --version |sed -n -e 1p -e '/ruby/p' > VIM - Vi IMproved 6.3 (2004 June 7, compiled Aug 15 2007 23:30:49) > +path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby > > > % vim --version |sed -n -e 1p -e '/[-+]ruby/p' > VIM - Vi IMproved 7.1 (2007 May 12, compiled Dec 12 2007 14:10:50) > +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent > > If you see "-ruby" then you're out of luck until you acquire or rebuild > Vim with Ruby support. Do you mean that I'm out of luck if I do not see "ruby"? Here's what I get: VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 11 2008 17:20:43) +printer -profile -python +quickfix +reltime -rightleft -ruby +scrollbind -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
On Thursday 18 December 2008 12:13, Mark Volkmann wrote: > On Thu, Dec 18, 2008 at 2:07 PM, Randall R Schulz wrote: > > ... > > > > First of all, check whether you Vim has the necessary Ruby support: > > > > % vim --version |sed -n -e 1p -e '/ruby/p' > > ... > > > > If you see "-ruby" then you're out of luck until you acquire or > > rebuild Vim with Ruby support. > > Do you mean that I'm out of luck if I do not see "ruby"? No. This time I meant what I wrote. The minus sign means "without," the plus sign "with." > Here's what I get: > > VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 11 2008 17:20:43) > +printer -profile -python +quickfix +reltime -rightleft -ruby > +scrollbind That's your problem. At least one of them: -ruby Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Thursday 18 December 2008 12:07, Stephan Mühlstrasser wrote: > Hi, > > I've not yet seen any examples on how to deal with external processes > in Clojure (I hope I didn't overlook something in clojure-contrib). > > The following is my attempt to start a sub-process and to pass > through stdout and stderr. The shell command prints out 1000 lines > "hello" and a final "command finished". The problem is that nothing > is printed by the Clojure program. If I increase the number of lines > for example to 2000 (change "head -1000" to "head -2000"), I see a > lot of output, but it is cut off somewhere in the middle and the > final "command finished" does never appear. I just did something virtually identical to this: user=> (sh date) Thu Dec 18 12:19:42 PST 2008 (That's a macro for the convenience of not having to either use string literals or quote the arguments. The real work is done in a function.) > ... > > (let [pb (new ProcessBuilder ["sh" "-c" "yes hello | head -1000; echo > command finished"]) > proc (.start pb) > stdout (reader (.getInputStream proc)) > stderr (reader (.getErrorStream proc)) > stdout-agent (agent stdout) > stderr-agent (agent stderr)] > (send stdout-agent copy (writer *out*)) > (send stderr-agent copy (writer *err*)) > (await stdout-agent stderr-agent) > (.waitFor proc) > (shutdown-agents) > (println "done")) > > Is this use of agents incorrect? I would say it's an appropriate use, but you need to do it a little differently: First of all, use (send-off ...) or you'll have to wait for the agent to complete. Then use (await ...) on the agents. > Why can the program terminate before all the output from the sub- > process has been passed through? As long as the sub-process produces no more output than the operating system's pipe buffering limit, it can complete without blocking. > Is there a better way to synchronize with sub-processes in Clojure, > or is it necessary to synchronize completely at the Java level? I don't understand this question. Here's what my implementation looks like. It does not stand alone as shown, but you can probably figure out what the missing pieces do: (def *shell* "bash") (def *shopt* "-c") (defn- cat-proc-stream "Copy all the bytes from stream to the writer" [stream writer] (binding [*out* writer] (cat-stream stream))) (defn shf "Invoke a platform / external command" [& args] (let [out *out* err *err* cmd+args (flatten args) builder (if (and (= (count cmd+args) 1) (string? (first cmd+args))) (ProcessBuilder. (into-array (conj [] *shell* *shopt* (first cmd+args (ProcessBuilder. (into-array (map str cmd+args process (.start builder) stdout-copier (agent nil) stderr-copier (agent nil)] (send-off stdout-copier #(cat-proc-stream %2 err) (.getErrorStream process)) (send-off stderr-copier #(cat-proc-stream %2 out) (.getInputStream process)) (await stdout-copier stderr-copier)) ) (defmacro sh "Invoke a platform / external command without evaluating arguments" [& args] `(shf '~args)) > Thanks > Stephan Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Dec 18, 9:24 pm, Randall R Schulz wrote: > On Thursday 18 December 2008 12:07, Stephan Mühlstrasser wrote: > > > (let [pb (new ProcessBuilder ["sh" "-c" "yes hello | head -1000; echo > > command finished"]) > > proc (.start pb) > > stdout (reader (.getInputStream proc)) > > stderr (reader (.getErrorStream proc)) > > stdout-agent (agent stdout) > > stderr-agent (agent stderr)] > > (send stdout-agent copy (writer *out*)) > > (send stderr-agent copy (writer *err*)) > > (await stdout-agent stderr-agent) > > (.waitFor proc) > > (shutdown-agents) > > (println "done")) > > > Is this use of agents incorrect? > > I would say it's an appropriate use, but you need to do it a little > differently: First of all, use (send-off ...) or you'll have to wait for > the agent to complete. Then use (await ...) on the agents. I do use (await ...) on the agents. And I have also tried (send- off ...), but it didn't make a difference. > > Why can the program terminate before all the output from the sub- > > process has been passed through? > > As long as the sub-process produces no more output than the operating > system's pipe buffering limit, it can complete without blocking. My question was not precise enough. I meant why can the parent process - the Clojure program - terminate before all all the output has been passed through. > > Is there a better way to synchronize with sub-processes in Clojure, > > or is it necessary to synchronize completely at the Java level? > > I don't understand this question. As my approach (implement the synchronization at the Clojure level) doesn't work obviously, I wondered whether it must be done all at the Java level, e.g. don't use Clojure agents, but create Java threads explicitly, start them, and wait for completion by using Java functions. > Here's what my implementation looks like. It does not stand alone as > shown, but you can probably figure out what the missing pieces do: > Thanks for sharing this. At first look it looks similar to my approach, but there must be a certain important detail that is different. > Randall Schulz Regards Stephan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Thursday 18 December 2008 12:43, Stephan Mühlstrasser wrote: > On Dec 18, 9:24 pm, Randall R Schulz wrote: > > On Thursday 18 December 2008 12:07, Stephan Mühlstrasser wrote: > > > ... > > > > > > Is this use of agents incorrect? > > > > I would say it's an appropriate use, but you need to do it a little > > differently: First of all, use (send-off ...) or you'll have to > > wait for the agent to complete. Then use (await ...) on the agents. > > I do use (await ...) on the agents. And I have also tried (send- > off ...), but it didn't make a difference. I think I don't understand the difference between (send ...) and (send-off ...), but that may be where the difference in behavior between our otherwise very similar code arises. > > > Why can the program terminate before all the output from the sub- > > > process has been passed through? > > > > As long as the sub-process produces no more output than the > > operating system's pipe buffering limit, it can complete without > > blocking. > > My question was not precise enough. I meant why can the parent > process - the Clojure program - terminate before all all the output > has been passed through. Because it can terminate whenever it wants to. Child processes do not place any constraints upon their parents, at least not on Unix systems. > > > Is there a better way to synchronize with sub-processes in > > > Clojure, or is it necessary to synchronize completely at the Java > > > level? > > > > I don't understand this question. > > As my approach (implement the synchronization at the Clojure level) > doesn't work obviously, I wondered whether it must be done all at the > Java level, e.g. don't use Clojure agents, but create Java threads > explicitly, start them, and wait for completion by using Java > functions. Well, your code may not work at the moment, but the approach is sound, as my code points out (it does work). > > ... > > Thanks for sharing this. At first look it looks similar to my > approach, but there must be a certain important detail that is > different. > > Regards > Stephan Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Thu, Dec 18, 2008 at 3:07 PM, Stephan Mühlstrasser wrote: > > The following is my attempt to start a sub-process and to pass through > stdout and stderr. The shell command prints out 1000 lines "hello" > and a final "command finished". The problem is that nothing is printed > by the Clojure program. If I increase the number of lines for example > to 2000 (change "head -1000" to "head -2000"), I see a lot of output, > but it is cut off somewhere in the middle and the final "command > finished" does never appear. This is just a buffering/flushing problem. Try adding (.flush ostream) after your (.println ...) > Is this use of agents incorrect? Since the action you're sending could block on IO, you should use 'send-off' instead of 'send'. The difference is that the pool of threads used by 'send' doesn't grow with demand, so too many blocking threads could cause new 'send' calls to queue up unnecessarily. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: trolltech QT opengl SLIME REPL mac os x
For what its worth, I've had a similar setup working on Mac OS X 10.5: Aquamacs SLIME jogl-1.1.1 I'm pretty sure I'm running Java 1.6 (can't check now). I had no issues with hangs. Perhaps QT is the bad ingredient. /mike. On Thu, Dec 18, 2008 at 2:40 PM, chris wrote: > > I think you are absolutely correct. I am using -XstartOnFirstThread, > but I noticed when the application works it outputs a message about > the CocoaCompatibilty enabled. This is triggered somehow from the > jogl calls. This indicates there is some threading going on behind > the scenes as that compatibility layer is for dealing with asyncronous > calls to or from awt threads. > > I have decided to dump QT and move to a swing UI. I have read a lot > of posts about the upgrades and openGL 2D integration it has in java > 1.6 so I guess I will just try it out. I will do most of my rendering > to FBO's anyway so I won't be using the pbuffer crap in it now; jogl > exposes the base opengl calls and their extensions. QT freezes if you > don't use -XstartOnFirstThread in your java arg; this is an indicator > that mixing it with anything awt replated (as jogl certainly is) is > going to have some perhaps dire consequences. > > Two of the three hard problems I came across were due to QT; I guess > from my perspective, until they port it to cocoa, it isn't really > useful for java on the mac. > > Really rough introduction to java, however. Everything I tried went > bang in odd ways; and it wasn't clojure as much as it was jar, jni, > dylib, mac hell. Luckily I work in c++ so I am used to all this shit. > > Thanks for the reply! > > Chris > > On Dec 18, 10:17 am, AA wrote: >> Generally speaking, there are complications with using OpenGL from >> multiple threads, I wonder if the calls you make via the Slime/Swank >> interface are in a different thread than the one that allocated the >> OpenGL context. Here's some documentation that may be relevant if you >> are using OS X: >> >> http://developer.apple.com/documentation/graphicsimaging/Conceptual/O... >> >> http://developer.apple.com/documentation/graphicsimaging/Conceptual/O... >> >> On Dec 17, 11:33 pm, chris wrote: >> >> > I am trying to write an application using the above libraries. There >> > is no point to this app at the moment other than to take my time and >> > enjoy learning clojure. I am hoping that anyone else with these >> > problems will be able to find this post, so I am going to dump. >> >> > I have had a hell of time getting things to work correctly. First I >> > installed java 1.6, only to find out that trolltech doesn't support >> > that version on os x because it is 64 bit and they haven't ported >> > their libraries to cocoa. The error you get is an initializer failure >> > in JambiObject; it takes quite a while to figure out the >> > inconsistencies. >> >> > Next I couldn't build because the ant process was finding two >> > xercesimpl.jar files somehow and this was making the construction of >> > the sax parser fail when the qt libs attempt to do their thing when >> > the java task is loading the clojure class from the build directory. >> >> > I then managed to get an app up and running; the cool thing is that >> > when you close the app it just puts you back in the repl. Then you >> > can call a function and give event handing back to QT. This is fun; I >> > don't have to shutdown to try out lots of different stuff until I hang >> > the process or crash QT. >> >> > Finally I decided to try out some openGL. I got a complete hang every >> > time I called GL, using the slime repl from emacs. I could get all >> > the rest of my gui stuff working but anything GL related would hang. >> > I tried switching from jogl to lwjgl and the result was the same. >> > super hang. >> >> > 4 hours of debugging later I tried running the helloGL QT demo and it >> > was working. I then tried it from the command line repl and it >> > worked. Finally I tried it from the slime repl and it just hung. >> >> > So my question to the gurus in this forum is why, on mac os 10.5 using >> > jvm 1.5 and the latest clojure, slime, aquamacs, clojure-contrib, qt, >> > jogl, swank-clojure, NVIDIA 8600M GT, 2.5 ghz core 2 due, 4 gigs of >> > ram, in a house that is 65 degrees fahrenheit, at 40.03N x 105.25W... >> >> > would this exact scenario hang? I really want to use slime as my >> > primary repl; I will have to use some crap null gl wrappers when I am >> > not working on gl as it is unless I can get slime to play nice with >> > gl. >> >> > Clojure is the shit! >> >> > Unfortunately, java still sucks. Not that it will stop me using >> > clojure. >> >> > Thanks! >> >> > oh, the code is at: http://github.com/cnuernber/lambinator/tree/master >> >> > Chris > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from
Re: (Ab)using agents for inter-process communication
On Dec 18, 10:10 pm, Chouser wrote: > On Thu, Dec 18, 2008 at 3:07 PM, Stephan Mühlstrasser > > wrote: > > > The following is my attempt to start a sub-process and to pass through > > stdout and stderr. The shell command prints out 1000 lines "hello" > > and a final "command finished". The problem is that nothing is printed > > by the Clojure program. If I increase the number of lines for example > > to 2000 (change "head -1000" to "head -2000"), I see a lot of output, > > but it is cut off somewhere in the middle and the final "command > > finished" does never appear. > > This is just a buffering/flushing problem. Try adding > (.flush ostream) after your (.println ...) Thanks, that was it! I put the flush in the else clause in copy, so it flushes once at the end. > > Is this use of agents incorrect? > > Since the action you're sending could block on IO, you should use > 'send-off' instead of 'send'. The difference is that the pool of > threads used by 'send' doesn't grow with demand, so too many blocking > threads could cause new 'send' calls to queue up unnecessarily. Ah, I believe I finally understand the difference between send and send-off. To describe it in my own words, send-off creates a new thread each time, while send schedules to a thread in a thread pool. So this is the complete example again which now does work as expected: (use 'clojure.contrib.duck-streams) (defn copy [istream ostream] (println "copy" istream ostream) (loop [line (.readLine istream)] (if line (do (.println ostream line) (recur (.readLine istream))) (.flush ostream (let [pb (new ProcessBuilder ["sh" "-c" "yes hello | head -1000; echo command finished"]) proc (.start pb) stdout (reader (.getInputStream proc)) stderr (reader (.getErrorStream proc)) stdout-agent (agent stdout) stderr-agent (agent stderr)] (send-off stdout-agent copy (writer *out*)) (send-off stderr-agent copy (writer *err*)) (await stdout-agent stderr-agent) (.waitFor proc) (shutdown-agents) (println "done")) Thanks Stephan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: trolltech QT opengl SLIME REPL mac os x
On Dec 18, 2008, at 4:35 PM, Michael Reid wrote: > > For what its worth, I've had a similar setup working on Mac OS X 10.5: > > Aquamacs > SLIME > jogl-1.1.1 > > I'm pretty sure I'm running Java 1.6 (can't check now). I had no > issues with hangs. Perhaps QT is the bad ingredient. I'm thinking the same. Have been doing interactive 3d graphics with Clojure and jME (using LWJGL) and have had no issues launching a windowed scene and interacting with it via the REPL. Carbon Emacs and slime here. > > > /mike. > > > On Thu, Dec 18, 2008 at 2:40 PM, chris wrote: >> >> I think you are absolutely correct. I am using -XstartOnFirstThread, >> but I noticed when the application works it outputs a message about >> the CocoaCompatibilty enabled. This is triggered somehow from the >> jogl calls. This indicates there is some threading going on behind >> the scenes as that compatibility layer is for dealing with >> asyncronous >> calls to or from awt threads. >> >> I have decided to dump QT and move to a swing UI. I have read a lot >> of posts about the upgrades and openGL 2D integration it has in java >> 1.6 so I guess I will just try it out. I will do most of my >> rendering >> to FBO's anyway so I won't be using the pbuffer crap in it now; jogl >> exposes the base opengl calls and their extensions. QT freezes if >> you >> don't use -XstartOnFirstThread in your java arg; this is an indicator >> that mixing it with anything awt replated (as jogl certainly is) is >> going to have some perhaps dire consequences. >> >> Two of the three hard problems I came across were due to QT; I guess >> from my perspective, until they port it to cocoa, it isn't really >> useful for java on the mac. >> >> Really rough introduction to java, however. Everything I tried went >> bang in odd ways; and it wasn't clojure as much as it was jar, jni, >> dylib, mac hell. Luckily I work in c++ so I am used to all this >> shit. >> >> Thanks for the reply! >> >> Chris >> >> On Dec 18, 10:17 am, AA wrote: >>> Generally speaking, there are complications with using OpenGL from >>> multiple threads, I wonder if the calls you make via the Slime/Swank >>> interface are in a different thread than the one that allocated the >>> OpenGL context. Here's some documentation that may be relevant if >>> you >>> are using OS X: >>> >>> http://developer.apple.com/documentation/graphicsimaging/Conceptual/O >>> ... >>> >>> http://developer.apple.com/documentation/graphicsimaging/Conceptual/O >>> ... >>> >>> On Dec 17, 11:33 pm, chris wrote: >>> I am trying to write an application using the above libraries. There is no point to this app at the moment other than to take my time and enjoy learning clojure. I am hoping that anyone else with these problems will be able to find this post, so I am going to dump. >>> I have had a hell of time getting things to work correctly. First I installed java 1.6, only to find out that trolltech doesn't support that version on os x because it is 64 bit and they haven't ported their libraries to cocoa. The error you get is an initializer failure in JambiObject; it takes quite a while to figure out the inconsistencies. >>> Next I couldn't build because the ant process was finding two xercesimpl.jar files somehow and this was making the construction of the sax parser fail when the qt libs attempt to do their thing when the java task is loading the clojure class from the build directory. >>> I then managed to get an app up and running; the cool thing is that when you close the app it just puts you back in the repl. Then you can call a function and give event handing back to QT. This is fun; I don't have to shutdown to try out lots of different stuff until I hang the process or crash QT. >>> Finally I decided to try out some openGL. I got a complete hang every time I called GL, using the slime repl from emacs. I could get all the rest of my gui stuff working but anything GL related would hang. I tried switching from jogl to lwjgl and the result was the same. super hang. >>> 4 hours of debugging later I tried running the helloGL QT demo and it was working. I then tried it from the command line repl and it worked. Finally I tried it from the slime repl and it just hung. >>> So my question to the gurus in this forum is why, on mac os 10.5 using jvm 1.5 and the latest clojure, slime, aquamacs, clojure-contrib, qt, jogl, swank-clojure, NVIDIA 8600M GT, 2.5 ghz core 2 due, 4 gigs of ram, in a house that is 65 degrees fahrenheit, at 40.03N x 105.25W... >>> would this exact scenario hang? I really want to use slime as my primary repl; I will have to use some crap null gl wrappers when I am not working on gl as it is unless I can get slim
Re: Clojure's code has moved to Google Code
On Dec 18, 7:19 am, "Daniel Renfer" wrote: > If you really want these commit messages to come to your mailbox, you > could always use a service such as:http://www.rssfwd.com/ > Or you could just join that group. Google will send you emails. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Dec 18, 10:01 pm, Randall R Schulz wrote: > > > My question was not precise enough. I meant why can the parent > > process - the Clojure program - terminate before all all the output > > has been passed through. > > Because it can terminate whenever it wants to. Child processes do not > place any constraints upon their parents, at least not on Unix systems. I understand that the parent process can terminate whenever it wants. But in my program the "copy" function recurs over readLine until it returns null/nil, so it should read until the end of the output from the child process. And the calling thread waits for the completion of the agent functions with (await ...). The main thread should not come out of the (await ...) until both agent functions have copied their whole stream... But somehow the "copy" function is interrupted when the child process terminates. Maybe the missing piece is how your (cat-stream ...) function works, which is not included in your listing. How does it copy the data? Regards Stephan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Persistent storage
Hi, Perhaps this question has been asked here before but quick search didn't show anything relevant. Is is possible to use some kind of backend storage for Clojure's data structures? I mean something like Perl's "tie" function that makes data structures persistent (in sense of storage, not immutability). Such storage should be inherently immutable the way Clojure's data are (so a simple wrapper on sql is probably not good enough) and provide means of querying database and indexing (ideally multidimensional). I wonder if this could be at library level or would rather have to be hard-coded into Clojure itself. Did anyone try to do it? Regards, -r. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Typo on "Refs and Transactions" page
Hi all, I don't know if this is the right place to post this (if it's not, please let me know where to go), but the documentation on "Refs and Transactions" (http://clojure.org/refs) has a typo in the first sentence: "While Vars ensure safe use of mutable mutable storage locations". There should be only one "mutable". Unless "mutable mutable" means something I don't know about? If so, can we please change the nomenclature? ;) -Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
> > Ah, I believe I finally understand the difference between send and > send-off. To describe it in my own words, send-off creates a new > thread each time, while send schedules to a thread in a thread pool. > Not quite true, but close. Send-off requests a thread from a CachingThreadPool, but since CachingThreadPools are effectively unlimitted you get the effect you describe, with less overhead. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
On Thu, Dec 18, 2008 at 2:18 PM, Randall R Schulz wrote: > > On Thursday 18 December 2008 12:13, Mark Volkmann wrote: >> On Thu, Dec 18, 2008 at 2:07 PM, Randall R Schulz > wrote: >> > ... >> > >> > First of all, check whether you Vim has the necessary Ruby support: >> > >> > % vim --version |sed -n -e 1p -e '/ruby/p' >> > ... >> > >> > If you see "-ruby" then you're out of luck until you acquire or >> > rebuild Vim with Ruby support. >> >> Do you mean that I'm out of luck if I do not see "ruby"? > > No. This time I meant what I wrote. The minus sign means "without," the > plus sign "with." > > >> Here's what I get: >> >> VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 11 2008 17:20:43) >> +printer -profile -python +quickfix +reltime -rightleft -ruby >> +scrollbind > > That's your problem. At least one of them: -ruby Okay, I'm hot on the trail with this! Here's what I did. 1) download the vim source from ftp://ftp.vim.org/pub/vim/unix/ 2) unzip it 3) cd to that directory 4) run "./configure --enable-rubyinterp" 5) run "sudo make install" Now when I run vim --version |sed -n -e 1p -e '/ruby/p I see +ruby! Now though when I run vim I get the following: Error detected while processing /Users/Mark/.vim/plugin/gorilla.vim: line 558: LoadError: /usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle: dlopen(/usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle, 9): Symbol not found: _rb_eStandardError Press ENTER or type command to continue I don't know what to make of this. BTW, I have Ruby 1.8.7. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
Hi, Am 18.12.2008 um 23:06 schrieb Mark Volkmann: Error detected while processing /Users/Mark/.vim/plugin/gorilla.vim: line 558: LoadError: /usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle: dlopen(/usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle, 9): Symbol not found: _rb_eStandardError Press ENTER or type command to continue I don't know what to make of this. BTW, I have Ruby 1.8.7. To be honest: I never compiled vim with Ruby support. So I don't know, what shadows may lurk on this path. Your error messages hint that you a running on a Mac. If that is the case, try MacVim. It is ruby enabled and works with the standard ruby of Mac Os out of the box. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Typo on "Refs and Transactions" page
On Dec 18, 2008, at 4:52 PM, MattyDub wrote: > > Hi all, > I don't know if this is the right place to post this (if it's not, > please let me know where to go), but the documentation on "Refs and > Transactions" (http://clojure.org/refs) has a typo in the first > sentence: > "While Vars ensure safe use of mutable mutable storage locations". > There should be only one "mutable". > Unless "mutable mutable" means something I don't know about? If > so, can we please change the nomenclature? ;) > Fixed - thanks for the report. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Thursday 18 December 2008 13:33, Stephan Mühlstrasser wrote: > On Dec 18, 10:01 pm, Randall R Schulz wrote: > > > My question was not precise enough. I meant why can the parent > > > process - the Clojure program - terminate before all all the > > > output has been passed through. > > > > Because it can terminate whenever it wants to. Child processes do > > not place any constraints upon their parents, at least not on Unix > > systems. > > I understand that the parent process can terminate whenever it wants. > But in my program the "copy" function recurs over readLine until it > returns null/nil, so it should read until the end of the output from > the child process. And the calling thread waits for the completion of > the agent functions with (await ...). The main thread should not come > out of the (await ...) until both agent functions have copied their > whole stream... But somehow the "copy" function is interrupted when > the child process terminates. > > Maybe the missing piece is how your (cat-stream ...) function works, > which is not included in your listing. How does it copy the data? Nothing fancy: (defn cat-stream "Copy bytes from an InputStream to *out*" [stream] (let [reader (new BufferedReader (new InputStreamReader stream)) buffer (make-array Character/TYPE 1024)] (loop [n-read (.read reader buffer)] (when (> n-read 0) (.write *out* buffer 0 n-read) (recur (.read reader buffer (.flush *out*))) > Regards > Stephan Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
On Thu, Dec 18, 2008 at 4:10 PM, Meikel Brandmeyer wrote: > Hi, > > Am 18.12.2008 um 23:06 schrieb Mark Volkmann: >> >> Error detected while processing /Users/Mark/.vim/plugin/gorilla.vim: >> line 558: >> LoadError: /usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle: >> dlopen(/usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle, 9): >> Symbol not found: _rb_eStandardError >> Press ENTER or type command to continue >> >> I don't know what to make of this. >> BTW, I have Ruby 1.8.7. > > To be honest: I never compiled vim with Ruby support. > So I don't know, what shadows may lurk on this path. > > Your error messages hint that you a running on a Mac. > If that is the case, try MacVim. It is ruby enabled and > works with the standard ruby of Mac Os out of the box. Okay, I'm using MacVim now and I have a gorilla server running. What are the keystrokes to open a REPL buffer? The documentation says sr. I don't know what LocalLeader means. Is that just a colon? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Dec 18, 11:30 pm, Randall R Schulz wrote: > On Thursday 18 December 2008 13:33, Stephan Mühlstrasser wrote: > > > Nothing fancy: > > (defn cat-stream > > (.flush *out*))) > As Chouser pointed out, the flush is the important ingredient. After thinking a while about this, I'm wondering why it is necessary. The output stream should be flushed automatically when the program exits, but it looks like with Java and threads this is different. Regards Stephan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Thursday 18 December 2008 14:40, Stephan Mühlstrasser wrote: > On Dec 18, 11:30 pm, Randall R Schulz wrote: > > On Thursday 18 December 2008 13:33, Stephan Mühlstrasser wrote: > > > > > > Nothing fancy: > > > > (defn cat-stream > > > > (.flush *out*))) > > As Chouser pointed out, the flush is the important ingredient. > > After thinking a while about this, I'm wondering why it is necessary. > The output stream should be flushed automatically when the program > exits, but it looks like with Java and threads this is different. Java has no built-in auto-flushing that I've ever been aware of. > Regards > Stephan Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
LocalLeader usually means \ On Thu, Dec 18, 2008 at 3:36 PM, Mark Volkmann wrote: > > On Thu, Dec 18, 2008 at 4:10 PM, Meikel Brandmeyer wrote: > > Hi, > > > > Am 18.12.2008 um 23:06 schrieb Mark Volkmann: > >> > >> Error detected while processing /Users/Mark/.vim/plugin/gorilla.vim: > >> line 558: > >> LoadError: /usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle: > >> dlopen(/usr/local/lib/ruby/1.8/i686-darwin9.3.0/socket.bundle, 9): > >> Symbol not found: _rb_eStandardError > >> Press ENTER or type command to continue > >> > >> I don't know what to make of this. > >> BTW, I have Ruby 1.8.7. > > > > To be honest: I never compiled vim with Ruby support. > > So I don't know, what shadows may lurk on this path. > > > > Your error messages hint that you a running on a Mac. > > If that is the case, try MacVim. It is ruby enabled and > > works with the standard ruby of Mac Os out of the box. > > Okay, I'm using MacVim now and I have a gorilla server running. What > are the keystrokes to open a REPL buffer? The documentation says > sr. I don't know what LocalLeader means. Is that just a > colon? > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: (Ab)using agents for inter-process communication
On Thursday 18 December 2008 14:44, Randall R Schulz wrote: > On Thursday 18 December 2008 14:40, Stephan Mühlstrasser wrote: > > ... > > > > As Chouser pointed out, the flush is the important ingredient. > > > > After thinking a while about this, I'm wondering why it is > > necessary. The output stream should be flushed automatically when > > the program exits, but it looks like with Java and threads this is > > different. > > Java has no built-in auto-flushing that I've ever been aware of. I should say, none triggered by JVM shut-down. PrintStream and PrintWriter have an auto-flush mode that you can establish when constructing, but not control later (for whatever reason). > > Regards > > Stephan Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: find returns symbol keys without their metadata
On Dec 18, 2:30 pm, Chris Kent wrote:
> Hi
>
> I've been playing around using symbols with metadata as struct map
> keys after reading this
> message:http://groups.google.com/group/clojure/msg/68e7036dbd8ded29
>
> It all works OK except when you use find to extract an entry. find
> returns an entry containing the key passed to it, not the key in the
> map. So if you don't use the original key to query the map you don't
> get the metadata:
>
> user=> (defstruct s (with-meta 'k {:a "A"}))
> #'user/s
> user=> (def s1 (struct s 1))
> #'user/s1
> user=> ^(first (keys s1))
> {:a "A"}
> user=> (find s1 'k)
> [k 1]
> user=> ^(first (find s1 'k))
> nil
>
Fixed (svn 1175) - thanks for the report.
Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
test-is possible bug in are
If I understand correctly, (are (< 1 2, 5 7)) is equivalent to (is (< 1 2)) (is (< 5 7)) The following may be incorrect usage of are: (are < 1 2, 5 7) However, instead of complaining about the arguments, it hangs forever. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Persistent storage
On Thu, Dec 18, 2008 at 4:47 PM, r wrote: > > Is is possible to use some kind of backend storage for Clojure's data > structures? I mean something like Perl's "tie" function that makes > data structures persistent (in sense of storage, not immutability). > > Such storage should be inherently immutable the way Clojure's data are > (so a simple wrapper on sql is probably not good enough) and provide > means of querying database and indexing (ideally multidimensional). I would looove this. > I wonder if this could be at library level or would rather have to be > hard-coded into Clojure itself. Did anyone try to do it? I've pondered a couple approaches, though only enough to find problems. One approach would work act like a Clojure collection, with structural sharing on-disk. This would be great because it would have multi-versioning and transaction features built right in. It would also have the potential to cache some data in memory while managing reads and writes to disk. But Clojure's persistent collections rely on garbage collection -- when old versions of the collection are no longer referenced, the JVM cleans them up automatically. How would this work on disk? How would you define "no longer referenced"? Another approach would be at the Ref or Agent level, where watchers could be hooked in. (Watchers are currently only for agents, but are planned for refs as well.) Watchers are functions that are called when their underlying mutable object has a change committed, so they'd be able to sync the disk up with new in-memory value. But this means the whole collection would have to be in-memory. Also the watcher gets no hint as to *what* in the collection changed. So for now it seems we'll have to make do with "normal" mechansims like SQL libraries. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
Hi, Am 18.12.2008 um 23:36 schrieb Mark Volkmann: The documentation says sr. I don't know what LocalLeader means. Is that just a colon? The is a key you define yourself. I remapped the \ to , since \ is awkward to type on german keyboards. is for plugins, is for filetype plugins. See ":help mapleader" for more information. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
REPL Namespace Display
Hope this is the appropriate place for this... anyway, very trivial issue. I was playing around in an effort to begin to understand the ns fns & managed to get the current/active ns & REPL displayed ns out of synch via the following: user> *ns* # user> (in-ns 'howdy) # howdy> (clojure.core/refer 'clojure.core) nil howdy> *ns* # howdy> (remove-ns 'howdy) # howdy> *ns* # howdy> howdy> (in-ns 'user) # howdy> Switching to another ns corrects it. BTW l'm really looking forward to digging into this language as a long time Java wanna-be Lispy programmer (so thx Rich) -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 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: A try on condp
Hi, I reworked my initial proposal according to the comments of Rich. The syntax now looks as follows: (condp predicate expr test-expr result-expr test-expr :> result-expr ... default-expr) A result-expr is chosen according to (predicate test-expr expr). In the first form, result-expr is simply evaluated and the result is returned. In the second form, result-expr is expected to evaluate to a function. This function gets passed the return value of the predicate call. Whatever the function returns is returned by condp. If no test-expr leads to a success the default-expr is evaluated and the result returned. If no default-expr is supplied an exception is thrown. The patch is attached at the issue tracker. http://code.google.com/p/clojure/issues/detail?id=6#c2 Comments appreciated. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Suggestion: introduce (defn name attr-map? [params*] doc-string body) form.
All. I think it would be nice if the doc-string was allowed (in addition to current behavior) to immediately follow the params vector in the various defsomethings. To the best of my knowledge, such a change would be non-breaking because, a) It should be implemented such that (defn foo [] "bar") is a function that always returns the string "bar" - like it does today, and b) The "eggs" string following the params vector in (defn spam [] "eggs" "pokemon") is completely harmless in current code. Even though this change would introduce yet-another-way-to-def-fn, I think it is a good change because it allows be to keep my [params] on the same line as my defn's and still have a thorough doc-string. And in my humble opinion, I think it improves the readability of function definitions when the defn, name and [params] are on the same line regardless of how long the doc-string is. -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: REPL Namespace Display
On Thu, Dec 18, 2008 at 6:02 PM, brian wrote: > > Hope this is the appropriate place for this... anyway, very trivial > issue. I was playing around in an effort to begin to understand the > ns fns & managed to get the current/active ns & REPL displayed ns out > of synch via the following: > > user> *ns* > # > user> (in-ns 'howdy) > # > howdy> (clojure.core/refer 'clojure.core) > nil > howdy> *ns* > # > howdy> (remove-ns 'howdy) > # > howdy> *ns* > # > howdy> > howdy> (in-ns 'user) > # > howdy> > > Switching to another ns corrects it. We now have several Repls, and each acts slightly differently. I couldn't reproduce this with clojure.lang.Repl. I'm guessing from your prompt that you're using emacs/slime. Is that correct? --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Persistent storage
On Thu, 18 Dec 2008 18:06:40 -0500 Chouser wrote: > > On Thu, Dec 18, 2008 at 4:47 PM, r wrote: > > > > Is is possible to use some kind of backend storage for Clojure's > > data structures? I mean something like Perl's "tie" function that > > makes data structures persistent (in sense of storage, not > > immutability). > > > > Such storage should be inherently immutable the way Clojure's data > > are (so a simple wrapper on sql is probably not good enough) and > > provide means of querying database and indexing (ideally > > multidimensional). > > I would looove this. > This occurred to me the other day as well; the name "Mnejia" which popped into my head says a lot about the sort of thing I had in mind :) > > I wonder if this could be at library level or would rather have to > > be hard-coded into Clojure itself. Did anyone try to do it? > > I've pondered a couple approaches, though only enough to find > problems. > > One approach would work act like a Clojure collection, with structural > sharing on-disk. This would be great because it would have > multi-versioning and transaction features built right in. It would > also have the potential to cache some data in memory while managing > reads and writes to disk. > This is an interesting observation. Something in the vein of OTP's Mnesia for Clojure would be *very* cool indeed, and I have been thinking a lot about ways to implement distribution mechanisms for Clojure on top of which such a thing could be built. I imagine however that even sans distribution it would be quite powerful and useful, and a fun project. [ Mostly off-topic musings follow :) ] The big problem with mimicking Mnesia for distribution is that a lot of Erlang distribution idioms (used heavily in Mnesia AFAIK) rely on BEAM's ability to marshall funs across the network (and indeed I think Mnesia can even use that to serialize them on disk tables). If serialization of a fun is possible in Clojure, doing it is way over my head :) Obviously if you can serialize the sexp before the compiler gets ahold of it, this is easy, but usually you don't get that lucky. If one were able to marshall a Clojure fun, I had envisioned constructing a sort of "distributed send", probably built atop one of the many good message-queueing protocols already extant, that can be used to cause that fun to be run on a remote Agent, giving you a more Clojure-flavored distribution mechanism. Not RPC, but not exactly Actor model either. H... :) -Kyle --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Persistent storage
On Thu, Dec 18, 2008 at 11:06 PM, Chouser wrote: > > I've pondered a couple approaches, though only enough to find > problems. > > One approach would work act like a Clojure collection, with structural > sharing on-disk. This would be great because it would have > multi-versioning and transaction features built right in. It would > also have the potential to cache some data in memory while managing > reads and writes to disk. > > But Clojure's persistent collections rely on garbage collection -- > when old versions of the collection are no longer referenced, the JVM > cleans them up automatically. How would this work on disk? How would > you define "no longer referenced"? [1. just to confirm I understand you correctly: is this a "transparent" case where each newly constructed data structure is immediately written to disk?] I can see another problem here: assuming we have multiple "active" versions of such structure at the time of closing the application, which of them should we restore when the application restarts? Do we need explicit "save"&"restore" commands to mark the data we want anyway? Or is it better to automatically keep track of "heads" per (named) thread? Or use a (transparent) Ref? Another issue is the efficiency of the GC itself. Whatever scheme we use, Clojure is going to use GC a lot. This may cause strong fragmentation of data on disk (not to say about performance penalty). > Another approach would be at the Ref or Agent level, where watchers > could be hooked in. (Watchers are currently only for agents, but are > planned for refs as well.) Watchers are functions that are called > when their underlying mutable object has a change committed, so they'd > be able to sync the disk up with new in-memory value. But this means > the whole collection would have to be in-memory. Also the watcher > gets no hint as to *what* in the collection changed. > > So for now it seems we'll have to make do with "normal" mechansims > like SQL libraries. [2. is this an "opaque" case where data sit in memory and only when we switch the Ref the on-disk representation is updated?] Hiding the whole data structure behind the Ref and syncing data only when it changes would solve both problems mentioned above. The cost is that the data would not longer be updated incrementally so the whole structure would have to be flushed to the disk. This wouldn't be very efficient but would work with existing database back-ends. Perhaps it would be better to use a combination of 1. and 2., i.e. not only to hide data structures behind a Ref and commit changes to disk only when the Ref changes (as in 2.) but also to use a journal for tracking "modifications" to data so that only incremental changes have be done. Such journal could be translated (and optimized) into a bunch of INSERT&DELETE commands. Another question: what kind of data structures? List, vector and hash or maybe a new specialized type (a table)? Performance characteristics are going to be very different from in-memory data so maybe it makes sense for the whole mechanism to be opaque. -r. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Preparing for Release 1.0 (was: Re: 20081217 Release)
On Dec 18, 5:46 am, Rich Hickey wrote:
> I've cut a new release, 20081217, which is available from Google Code:
>
> http://clojure.googlecode.com/files/clojure_20081217.zip
Reading noob comments on this list, I suspect many people downloaded
the September Clojure tarball and tried (with mixed success) to get a
working development environment setup. Some would have given up on
Clojure while others would have learned that they were better off
using the development svn/git versions of things. However, the
development versions of libraries are not always stable so you can
potentially waste a lot of time trying to get a development
environment setup. Sure you can run Clojure from a command line or use
a lisp-ignorant text editor, but nobody is really going to do that for
very long. There are some "packaged" options that have been proposed
in the past ("Clojure Box" is one), but not everyone wants/needs
something like that either (many developers are happy to have just the
Clojure & Wiki setup instructions). However, all potential new Clojure
developers would almost certainly like to know that the packages that
they need to install will actually work together. Therefore, it might
be worthwhile to discuss a process whereby tarballs of "core Clojure-
related development libraries" that are known to work with a specific
release are saved off to a specific location (so that noob's can be
pointed to the latest set of files that are known to work together
instead of having to struggle with setting up multiple different
libraries that may or may not work properly together at any given
point in time). Currently, there are 4 key 3rd-party libraries that
most people need for developing Clojure code:
1. clojure-contrib
2. slime
3. clojure-mode
4. swank-clojure
(in the future, perhaps the Gorilla/Netbeans/Eclipse libs too;
however, maybe there won't be as many interdependent libraries and
potential for "breakage" with those)
For clojure-contrib, it would make sense to create a matching tarball
whenever a Clojure release occurs. For the other 3, it would be
necessary for someone to test and save off a copy of the libraries
somewhere (that by itself would make getting started with Clojure a
much easier task).
I'm not sure what the best way to manage this (the "where" and "who")
would be. One option would be to store files in the Clojure Google
Groups file area (although this could be a bit problematic since the
Google Groups file area isn't very "flexible" and everything is
jumbled in there together). Another option is to maintain the 3rd
party tarballs as separate "Featured" downloads in the clojure-contrib
Google Code Downloads area. I think the latter might make more sense
as it would keep "release-related" tarballs all in the clojure-contrib
project without actually "polluting" the clojure-contrib source
repository with foreign libraries. It would also provide "ownership"
of the process (assuming the clojure-contrib members are willing to
take this on).
Since the clojure_20081217.zip release is "pre-1.0", maybe we don't
need to do anything yet; however, it would be nice to come up with a
Clojure-community approach to deal with this issue in preparation for
a "post-1.0" world.
Thoughts?
--
Bill Clementson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Persistent storage
I've likewise though a fair bit about this, but haven't been able to come up with a particularly satisfying solution. One approach I've considered is a watcher-type system where persistence is defined in terms of immutable snapshots and append-only journals: you snapshot the data to disk occasionally and otherwise maintain persistence by appending changes to a journal before committing; these changes can be replayed in the case of failure. This will probably require additional hooks into Clojure's MVCC implementation. This might actually be workable for smallish data sets, where it is reasonable to hold everything in memory. Anyone interested in the topic of "persistent data structures on disk" might want to look into the implementation of CouchDB. They currently use (IIUC) a persistent B tree on disk that uses crash-safe append-only modifications and is "garbage collected" by occasionally copying over all reachable portions of the tree into a new file. This may be interesting in and of itself, but I also expect that we'll see more interesting things in this space from the CouchDB project. - Mark On Thu, Dec 18, 2008 at 7:53 PM, Kyle Schaffrick wrote: > > On Thu, 18 Dec 2008 18:06:40 -0500 > Chouser wrote: > >> >> On Thu, Dec 18, 2008 at 4:47 PM, r wrote: >> > >> > Is is possible to use some kind of backend storage for Clojure's >> > data structures? I mean something like Perl's "tie" function that >> > makes data structures persistent (in sense of storage, not >> > immutability). >> > >> > Such storage should be inherently immutable the way Clojure's data >> > are (so a simple wrapper on sql is probably not good enough) and >> > provide means of querying database and indexing (ideally >> > multidimensional). >> >> I would looove this. >> > > This occurred to me the other day as well; the name "Mnejia" which > popped into my head says a lot about the sort of thing I had in mind :) > >> > I wonder if this could be at library level or would rather have to >> > be hard-coded into Clojure itself. Did anyone try to do it? >> >> I've pondered a couple approaches, though only enough to find >> problems. >> >> One approach would work act like a Clojure collection, with structural >> sharing on-disk. This would be great because it would have >> multi-versioning and transaction features built right in. It would >> also have the potential to cache some data in memory while managing >> reads and writes to disk. >> > > This is an interesting observation. > > Something in the vein of OTP's Mnesia for Clojure would be *very* cool > indeed, and I have been thinking a lot about ways to implement > distribution mechanisms for Clojure on top of which such a thing could > be built. I imagine however that even sans distribution it would be > quite powerful and useful, and a fun project. > > [ Mostly off-topic musings follow :) ] > > The big problem with mimicking Mnesia for distribution is that a lot of > Erlang distribution idioms (used heavily in Mnesia AFAIK) rely on BEAM's > ability to marshall funs across the network (and indeed I think Mnesia > can even use that to serialize them on disk tables). If serialization of > a fun is possible in Clojure, doing it is way over my head :) Obviously > if you can serialize the sexp before the compiler gets ahold of it, this > is easy, but usually you don't get that lucky. > > If one were able to marshall a Clojure fun, I had envisioned > constructing a sort of "distributed send", probably built atop one of > the many good message-queueing protocols already extant, that can be > used to cause that fun to be run on a remote Agent, giving you a more > Clojure-flavored distribution mechanism. Not RPC, but not exactly Actor > model either. > > H... :) > > -Kyle > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
I think the point is that the installation documentation is a little lacking right now. Can you create a more thorough install doc which walks us through the setup? I'm an experienced Java developer so I had no problem getting the Gorilla server running but the vim setup is a mystery to me. I compiled MacVim with ruby support but, like Mark, have had no luck in getting VimClojure or the Gorilla plugin to work when following your minimal instructions. When I open a clj file, it says it is filetype=conf. Here's my .vim directory: mikeperham:~/.vim$ ls -lR total 0 drwxr-xr-x 3 mperham mperham 102 Dec 18 17:40 after drwxr-xr-x 3 mperham mperham 102 May 7 2007 autoload drwxr-xr-x 4 mperham mperham 136 Dec 18 17:29 bin drwxr-xr-x 5 mperham mperham 170 May 7 2007 compiler drwxr-xr-x 6 mperham mperham 204 Dec 18 17:27 doc drwxr-xr-x 4 mperham mperham 136 Dec 18 17:27 ftdetect drwxr-xr-x 6 mperham mperham 204 Dec 18 17:27 ftplugin drwxr-xr-x 5 mperham mperham 170 Dec 18 17:27 indent drwxr-xr-x 3 mperham mperham 102 Dec 18 17:40 plugin drwxr-xr-x 5 mperham mperham 170 Dec 18 17:27 syntax ./after: total 0 drwxr-xr-x 3 mperham mperham 102 Dec 18 17:40 ftplugin ./after/ftplugin: total 0 drwxr-xr-x 3 mperham mperham 102 Dec 18 17:40 clojure ./after/ftplugin/clojure: total 8 -rw-r--r-- 1 mperham mperham 1698 Dec 18 17:40 gorilla.vim ./autoload: total 48 -rw-r--r-- 1 mperham mperham 23455 Dec 14 2006 rubycomplete.vim ./bin: total 40 -rw-r--r-- 1 mperham mperham644 Dec 18 17:29 gen-completions.clj -rwxr-xr-x 1 mperham mperham 13171 Apr 15 2006 vim-ruby-install.rb ./compiler: total 24 -rw-r--r-- 1 mperham mperham 953 Apr 15 2006 eruby.vim -rw-r--r-- 1 mperham mperham 1815 Apr 15 2006 ruby.vim -rw-r--r-- 1 mperham mperham 837 Apr 15 2006 rubyunit.vim ./doc: total 40 -rw-r--r-- 1 mperham mperham 826 Dec 18 17:27 clojure.txt -rw-r--r-- 1 mperham mperham 1696 Jun 20 2006 ft-ruby-omni.txt -rw-r--r-- 1 mperham mperham 2259 May 7 2007 ft-ruby-syntax.txt -rw-r--r-- 1 mperham mperham 7298 Dec 18 17:40 gorilla.txt ./ftdetect: total 16 -rw-r--r-- 1 mperham mperham 48 Dec 18 17:27 clojure.vim -rw-r--r-- 1 mperham mperham 365 May 7 2007 ruby.vim ./ftplugin: total 32 drwxr-xr-x 3 mperham mperham 102 Dec 18 17:39 clojure -rw-r--r-- 1 mperham mperham 1500 Dec 18 17:27 clojure.vim -rw-r--r-- 1 mperham mperham 3115 May 7 2007 eruby.vim -rw-r--r-- 1 mperham mperham 8140 May 7 2007 ruby.vim ./ftplugin/clojure: total 8 -rw-r--r-- 1 mperham mperham 3121 Dec 18 17:27 completions ./indent: total 48 -rw-r--r-- 1 mperham mperham 5400 Dec 18 17:27 clojure.vim -rw-r--r-- 1 mperham mperham 1900 Apr 17 2007 eruby.vim -rw-r--r-- 1 mperham mperham 11683 Mar 21 2007 ruby.vim ./plugin: total 40 -rw-r--r-- 1 mperham mperham 16490 Dec 18 17:40 gorilla.vim ./syntax: total 88 -rw-r--r-- 1 mperham mperham 12433 Dec 18 17:27 clojure.vim -rw-r--r-- 1 mperham mperham 3121 May 7 2007 eruby.vim -rw-r--r-- 1 mperham mperham 23154 Nov 6 2007 ruby.vim On Dec 18, 5:09 pm, Meikel Brandmeyer wrote: > Hi, > > Am 18.12.2008 um 23:36 schrieb Mark Volkmann: > > > The documentation says sr. > > I don't know what LocalLeader means. Is that just a colon? > > The is a key you define yourself. I remapped > the \ to , since \ is awkward to type on german keyboards. > is for plugins, is for filetype > plugins. See ":help mapleader" for more information. > > Sincerely > Meikel > > smime.p7s > 5KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Typo on "Refs and Transactions" page
> > Fixed - thanks for the report. > ahh since you're here and responding, there is a reference to 'boot.clj' at http://clojure.org/getting_started which is no longer valid.. this page also points to sourceforge ... any plans for a bug/typo tracking system so we don't fill up the group with too much noise? daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Workflow troubles - exceptions in other threads
I must say, this is absolutely the first thing I've found about Clojure that is difficult or cumbersome - I've been more than pleased with how easy everything else has been. I'm a new to Emacs+Slime, and their learning curve has been the most difficult part, but so far I've overcome everything. However, I just started writing some more serious code, and am running into a problem. I am using Swing, and, those of you who know anything about Swing will know that most events are processed in a special thread, the Swing event thread. Well, I'm working in Emacs+Slime, and it appears that it is completely deaf to anything except what happens in the main Clojure REPL thread. A good portion of my code is executing in the swing thread, and when an exception occurs there, there is no clue in Emacs regarding what has taken place - it took me a while to figure out that there even was an exception. I have to create an explicit try/catch block, and even then, neither clojure *out* nor Java's System.out seem to be visible to my environment. I have no idea where System.out is directed to, and Clojure's *out* only seems to work for the REPL thread. In order to see what happens, I have to create some other side effect in the file system or in Swing. Now, I could just pull in a logging framework of some kind and tail the logs. But a lot of the joy Clojure has brought me, so far, has been that I can just hack around in the REPL and add that stuff as needed - it's a lot of work, just to see what's going on. So I guess my question is... is there any easy way to see System.out or System.err from my Slime environment? I don't mind catching the exceptions in my code, but I need some way to to /see/ them without dragging in a bunch of logging crap. Even Eclipse has a "console" that tracks System.out that you can print to from any thread... that sort of thing is a fairly basic requirement for debugging. Without it, I'm reduced to guesswork. Many thanks, -Luke --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: test-is possible bug in are
On Dec 18, 6:05 pm, "Mark Volkmann" wrote: > If I understand correctly, > > (are (< 1 2, 5 7)) > > is equivalent to > > (is (< 1 2)) > (is (< 5 7)) Not exactly. The first argument to "are" is a template expression, which is sort of like #(). The arguments to the template are symbols named "_1", "_2", "_3", "_4", and so on. The remaining arguments of "are" fill in the arguments to the template. So: (are (< _1 _2) 5 7 8 10) ;=> expands to (do (is (< 5 7)) (is (< 8 10)) Make sense? This is roughly equivalent to (map (fn [x y] (is (< x y))) [[5 7] [8 10]]) but it happens at compile time. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Workflow troubles - exceptions in other threads
On Thu, Dec 18, 2008 at 7:05 PM, levand wrote: > > I must say, this is absolutely the first thing I've found about > Clojure that is difficult or cumbersome - I've been more than pleased > with how easy everything else has been. I'm a new to Emacs+Slime, and > their learning curve has been the most difficult part, but so far I've > overcome everything. > > However, I just started writing some more serious code, and am running > into a problem. I am using Swing, and, those of you who know anything > about Swing will know that most events are processed in a special > thread, the Swing event thread. > > Well, I'm working in Emacs+Slime, and it appears that it is completely > deaf to anything except what happens in the main Clojure REPL thread. > A good portion of my code is executing in the swing thread, and when > an exception occurs there, there is no clue in Emacs regarding what > has taken place - it took me a while to figure out that there even was > an exception. I have to create an explicit try/catch block, and even > then, neither clojure *out* nor Java's System.out seem to be visible > to my environment. I have no idea where System.out is directed to, and > Clojure's *out* only seems to work for the REPL thread. In order to > see what happens, I have to create some other side effect in the file > system or in Swing. > > Now, I could just pull in a logging framework of some kind and tail > the logs. But a lot of the joy Clojure has brought me, so far, has > been that I can just hack around in the REPL and add that stuff as > needed - it's a lot of work, just to see what's going on. > > So I guess my question is... is there any easy way to see System.out > or System.err from my Slime environment? I don't mind catching the > exceptions in my code, but I need some way to to /see/ them without > dragging in a bunch of logging crap. Even Eclipse has a "console" that > tracks System.out that you can print to from any thread... that sort > of thing is a fairly basic requirement for debugging. Without it, I'm > reduced to guesswork. Add the following to your .emacs file: (add-hook 'slime-connected-hook (lambda () (interactive) (slime-redirect-inferior-output))) - Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Workflow troubles - exceptions in other threads
You, sir, are a genius. Thank you! Your blog posts on clojure+slime are excellent, too... this is what I get for trying to run with my own setup instead of just following your example. Many thanks, -Luke On Dec 18, 10:16 pm, "Bill Clementson" wrote: > On Thu, Dec 18, 2008 at 7:05 PM, levand wrote: > > > I must say, this is absolutely the first thing I've found about > > Clojure that is difficult or cumbersome - I've been more than pleased > > with how easy everything else has been. I'm a new to Emacs+Slime, and > > their learning curve has been the most difficult part, but so far I've > > overcome everything. > > > However, I just started writing some more serious code, and am running > > into a problem. I am using Swing, and, those of you who know anything > > about Swing will know that most events are processed in a special > > thread, the Swing event thread. > > > Well, I'm working in Emacs+Slime, and it appears that it is completely > > deaf to anything except what happens in the main Clojure REPL thread. > > A good portion of my code is executing in the swing thread, and when > > an exception occurs there, there is no clue in Emacs regarding what > > has taken place - it took me a while to figure out that there even was > > an exception. I have to create an explicit try/catch block, and even > > then, neither clojure *out* nor Java's System.out seem to be visible > > to my environment. I have no idea where System.out is directed to, and > > Clojure's *out* only seems to work for the REPL thread. In order to > > see what happens, I have to create some other side effect in the file > > system or in Swing. > > > Now, I could just pull in a logging framework of some kind and tail > > the logs. But a lot of the joy Clojure has brought me, so far, has > > been that I can just hack around in the REPL and add that stuff as > > needed - it's a lot of work, just to see what's going on. > > > So I guess my question is... is there any easy way to see System.out > > or System.err from my Slime environment? I don't mind catching the > > exceptions in my code, but I need some way to to /see/ them without > > dragging in a bunch of logging crap. Even Eclipse has a "console" that > > tracks System.out that you can print to from any thread... that sort > > of thing is a fairly basic requirement for debugging. Without it, I'm > > reduced to guesswork. > > Add the following to your .emacs file: > > (add-hook 'slime-connected-hook (lambda () > (interactive) > (slime-redirect-inferior-output))) > > - Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: REPL Namespace Display
That's correct. And I couldn't reproduce with the java clojure.lang.Repl either. Guess I was thinking it was just a pass through... I'm an emacs & slime noob too ;) -Brian On Dec 18, 6:00 pm, Chouser wrote: > On Thu, Dec 18, 2008 at 6:02 PM, brian wrote: > > > Hope this is the appropriate place for this... anyway, very trivial > > issue. I was playing around in an effort to begin to understand the > > ns fns & managed to get the current/active ns & REPL displayed ns out > > of synch via the following: > > > user> *ns* > > # > > user> (in-ns 'howdy) > > # > > howdy> (clojure.core/refer 'clojure.core) > > nil > > howdy> *ns* > > # > > howdy> (remove-ns 'howdy) > > # > > howdy> *ns* > > # > > howdy> > > howdy> (in-ns 'user) > > # > > howdy> > > > Switching to another ns corrects it. > > We now have several Repls, and each acts slightly differently. I > couldn't reproduce this with clojure.lang.Repl. I'm guessing from > your prompt that you're using emacs/slime. Is that correct? > > --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: FAQ
> Suggestions for entries welcome here. > > > > Rich > Here's another that was a "gotcha" for me for an hour or two... Why after using map/reduce/for to change a java object does the object remain unchanged? (defn initv1 [myseq] (let [v (java.util.Vector.)] (for [x myseq] (.addElement v x)) v)) (initv1 [1 2 3]) ; => (java.util.Vector. []) ; or... (defn initv2 [myseq] (let [v (java.util.Vector.)] (map (fn [x] (.addElement v x)) myseq) v)) (initv2 [1 2 3]) ; => (java.util.Vector. []) As map/reduce/for are lazy, the "let" construct does not actually "take" any elements from the map/reduce/for. In this case, use doseq... (defn initv3 [myseq] (let [v (java.util.Vector.)] (doseq [x myseq] (.addElement v x)) v)) (initv3 [1 2 3]) ; => (java.util.Vector. [1 2 3]) (Actually this happened in a more complex function, but the essence was that a new java object was instantiated in a let and I'd used a map to call a method on that object with all the items from a sequence. I could not understand why the object remained unchanged afterwards until I simplified it down to the above example). Regards, Adrian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: running Gorilla
Hi, On 19 Dez., 02:47, Mike Perham wrote: > Can you create a more thorough install doc which walks us through > the setup? Yes. It seems this is necessary. There is a small screencast available explaining the installation of VimClojure with a minimal set of required options. http://de.youtube.com/watch?v=rqweCwAMan0&fmt=18 > I compiled MacVim with ruby support. This is not necessary. MacVim comes with Ruby support enabled. > When I open a clj file, it says it is filetype=conf. I'm not sure, why this happens. I see this with markdown files. >From your file layout however, everything should work fine. I'll try to investigate 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 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: running Gorilla
Hi, On Fri, Dec 19, 2008 at 2:47 AM, Mike Perham wrote: > ./after/ftplugin/clojure: > total 8 > -rw-r--r-- 1 mperham mperham 1698 Dec 18 17:40 gorilla.vim The directory name "after" is IMHO just meant as a hint like in "copy this files AFTER building the gorilla jar" but not as the name of the final directory. So please copy the files into their corresponding directories under .vim without "after": USERNAME/.vim> pwd /Users/USERNAME/.vim USERNAME/.vim> find . ./doc ./doc/clojure.txt ./ftdetect ./ftdetect/clojure.vim ./ftplugin ./ftplugin/clojure ./ftplugin/clojure/completions ./ftplugin/clojure/gorilla.vim ./ftplugin/clojure.vim ./indent ./indent/clojure.vim ./plugin ./plugin/gorilla.vim ./syntax ./syntax/clojure.vim That should do the trick. Regards, Axel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Preparing for Release 1.0 (was: Re: 20081217 Release)
Hi, On 19 Dez., 02:10, bc wrote: > For clojure-contrib, it would make sense to create a matching tarball > whenever a Clojure release occurs. For the other 3, it would be > necessary for someone to test and save off a copy of the libraries > somewhere (that by itself would make getting started with Clojure a > much easier task). > > I'm not sure what the best way to manage this (the "where" and "who") > would be. The "who" is probably the maintainer/developer of the third-party library. The "where" is probably the place for the "who" hosts his project. > One option would be to store files in the Clojure Google > Groups file area (although this could be a bit problematic since the > Google Groups file area isn't very "flexible" and everything is > jumbled in there together). Another option is to maintain the 3rd > party tarballs as separate "Featured" downloads in the clojure-contrib > Google Code Downloads area. I think the latter might make more sense > as it would keep "release-related" tarballs all in the clojure-contrib > project without actually "polluting" the clojure-contrib source > repository with foreign libraries. It would also provide "ownership" > of the process (assuming the clojure-contrib members are willing to > take this on). I don't think, that the Google Group is a suitable place for such files. Concerning the contrib download area: who decides, which projects are allowed to go there? Who plays the postman who puts up the files? (The upstream author is probably not allowed to...) A centralised approach would be feasible if there was some CCAN, where every author can upload his files himself. I would propose, that the files are hosted where ever they are hosted now with suitable labels with which Clojure version they work. This works out of the box with the least amount of trouble. 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 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: running Gorilla
Hi, On 19 Dez., 08:04, "Axel Schlueter" wrote: > The directory name "after" is IMHO just meant as a hint like > in "copy this files AFTER building the gorilla jar" but not as > the name of the final directory. No it is not. The after is there on purpose. It says "load this file after loading the 'normal' ftplugin(s) for this filetype". 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 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 -~--~~~~--~~--~--~---
