Re: pointfree library
i have updated the library to use arrows, rather than just functions. (it still works with functions) to make a new kind of arrow, you need to implement: arr (creates an arrow from a function) >>> (combines arrows left to right) fst (makes arrow work on the first element of a vector, leaving the other elements alone) ttt (arrow works on second element of a vector if the first element is true) the other arrow combinators use those, so they don't need to be reimplemented for every kind of arrow. http://github.com/hclarke/pointfree-clojure --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Compiling latest ClojureCLR
The latest commit allows ClojureCLR to run against the most recent commit of the DLR. >> The more final solution will be an installer that takes care of all of >> this. > > That sounds interesting. Any plans for clojure.contrib? I'd be really > interested in helping where I can, and porting clojure code to .NET is > something I can do. I'm aware of the fact that Clojure core isn't > ported completely yet, but I think work can proceed in parallel on > core and contrib. Some device to avoid duplicate work on porting > clojure.contrib would be nice. I'm hoping someone will step up on writing an installer. The only major piece of the core not completed is genclass. The main items on the agenda at the moment: 1) Finish BigDecimal to remove vjslib dependency (should be done in a few more days). 2) Implementing genclass 3) Creating an installer 4) Converting clojure.contrib Item (3) can be done by anyone with appropriate .Net skills. Item (4) requires Clojure app programmer knowledge more than Clojure internals knowledge. - David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Infinite sequences hang sets and maps
Luke VanderHart wrote: > On Oct 29, 4:01 am, Mark Engelberg wrote: >> I see your point that hashCode could be made to work on infinite >> sequences, but since hashing is almost always a prelude to testing for >> equality, I'm hard pressed to think of an example of why you'd want to >> be able to do this. Can you illustrate with an example? > Wouldn't hashCode be called every time you use an infinite sequence as > a key in a hash map? Yes, but this is another case where hashing is a prelude for testing equality. If there's a hash collision then the map will have to use equality testing to distinguish between two keys. If you make hashCode always work on infinite sequences, then sometimes using them as keys in maps will work and other times -- seemingly randomly -- it won't. In my opinion this is much worse than them never working as map keys. > That strikes me as a problem, since everything else in Clojure makes > perfectly good map keys. "Everything else" in Clojure is also printable and equality testable in finite time. There's just some things you can't do reliably with infinite sequences. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using loop/recur and destructuring
>From looking at the source code the loop macro, it looks like this might be particular to destructuring with loop, rather than being related to destructuring in general ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Two minor typos in the cheatsheet
Thanks for your findings! Should be corrected in the new revision. Greetings, Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using loop/recur and destructuring
A user on IRC named hiredman had the excellent idea (which should have occurred to me, but didn't) to macroexpand my code. A macro expansion of (loop [[head & tail] (repeat 1)] (recur tail)) results in: (let* [G__10 (repeat 1) vec__11 G__10 head (clojure.core/nth vec__11 0 nil) tail (clojure.core/nthnext vec__11 1)] (loop* [G__10 G__10] (clojure.core/let [[head & tail] G__10] (recur tail So, if I'm interpreting this correctly, it appears if you destructure in this way, there is going to be a reference to the seq held outside the loop itself. Does this mean, then, that this kind of heap explosion is inevitable using destructuring with large lazy seqs? It's hard for me to believe that is the case, and I'm definitely not a macro expert, so I'd be happy to be shown to be wrong. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using loop/recur and destructuring
I actually restructured my code (not the toy example posted here) to avoid the destructuring, and was disappointed to find it also eventually blows up on 1.6 as well. I'm reasonably certain in that case that I'm not holding on to any of the sequence (since I don't refer to it outside the invocation for the initial value of the loop, so I'm still hoping people can help me suss this out. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
I'm running a poll to see what most Clojure users use for Clojure development.
Obviously Emacs is, and will likely continue to be in the lead. However, it will be very interesting to see how many people vote for the other choices. If you want to vote, the poll is located here. I'll post the outcome on my blog in about a month and probably link it on the Clojure reddit. http://acidrayne.net/?p=81 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ClojureCLR - clojure.contrib.repl-utils
Miron, There is very little progress on clojure-clr.contrib. The process is not that hard, just tedious. I can give hints to anyone who wants to work on it. I plan to work on it next after finishing BigDecimal. I do see the issues tab on the github site. However, I've got contributor status on that, so I may see things other don't. I don't have admin capabilities on that site, so I can't enable it. That would be up to Rich. I hope you can at least see the wiki tab. Regarding this specific issue, (apply (fn [] 1)) doesn't work in ClojureJVM either, at least not the build I have. user=> (apply (fn [] 1)) java.lang.IllegalArgumentException: Wrong number of args passed to: core$apply (NO_SOURCE_FILE:0) apply requires at least on argument in addition to the fn. user=> (doc apply) - clojure.core/apply ([f args* argseq]) Applies fn f to the argument list formed by prepending args to argseq. (apply (fn [] 1) nil), (apply (fn [] 1 ()), apply (fn [] 1) []) all work. --David On Oct 31, 2:40 pm, Miron Brezuleanu wrote: > Hi, > > What's the status of clojure.contrib translations for ClojureCLR? Is > there a clojure-clr.contrib? (couldn't find something like that on > github). > > I'm especially interested in repl-utils, and I'm thinking of starting > to translate it myself, but it would be nice to avoid duplicating > effort. > > Also, I didn't see an Issues tab on the ClojureCLR page on GitHub. The > issue I'd like to report is a small one, `apply` behaves differently. > For instance, on Clojure JVM the following works: > > user=> (apply (fn [] 1)) > 1 > > It doesn't work on the latest ClojureCLR. Of course, this is > equivalent to "((fn [] 1))" (which works on both Clojures) but I find > the `apply` version clearer than double parentheses. > > Sorry about multi-topicness and thanks for any pointers, > -- > Miron Brezuleanu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Compiling latest ClojureCLR
Hello David, On Sat, Oct 31, 2009 at 11:31 PM, dmiller wrote: > > Miron, > > You discovered what I discovered just a day or two ago: A release or > two ago. the DLR team made some breaking changes to namespaces and > moved a key method to another assembly. I'm really upset by the move > of SimpleCallHelper. I hate to reference the whole Dynamic assembly > just to pick up one method. I thought that it was a setup issue (turns out it was a different DLR version, could have been other things). This is what prompted me to write the email - I assumed that a clean environment was a chance to get a clear sequence of steps to make things work. > I haven't had a chance to update the ClojureCLR source to fix this > problem. I'll try to get that fixed this weekend. Apologies for your > pain. No need to apologize. We're a .NET shop at work and I'd really love to be able to write some of my money-earning code in Clojure, which would be impossible without ClojureCLR, so I'm actually very grateful. Thanks! > The more final solution will be an installer that takes care of all of > this. That sounds interesting. Any plans for clojure.contrib? I'd be really interested in helping where I can, and porting clojure code to .NET is something I can do. I'm aware of the fact that Clojure core isn't ported completely yet, but I think work can proceed in parallel on core and contrib. Some device to avoid duplicate work on porting clojure.contrib would be nice. Thanks again, -- Miron Brezuleanu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Compiling latest ClojureCLR
Miron, You discovered what I discovered just a day or two ago: A release or two ago. the DLR team made some breaking changes to namespaces and moved a key method to another assembly. I'm really upset by the move of SimpleCallHelper. I hate to reference the whole Dynamic assembly just to pick up one method. I haven't had a chance to update the ClojureCLR source to fix this problem. I'll try to get that fixed this weekend. Apologies for your pain. The more final solution will be an installer that takes care of all of this. The dependency on vjslib should be gone in no more than a week. I'm just finishing an implementation of BigDecimal that will render vjslib unnecessary. This will also enable the folks interested in Mono to start playing. I'll amend the install page on the wiki with some of your more detailed steps. Thanks. -David On Oct 31, 5:58 am, Miron Brezuleanu wrote: > Hello, > > I've tried compiling the latest ClojureCLR and ... it wasn't easy. > Maybe because my setup is missing stuff (a fresh virtual machine with > Windows Server 2003, Visual Studio 2008 SP1 and the Visual J# > redistributables). Anyway, I managed to come up with a reproducible > list of steps that got me into a ClojureCLR REPL and I'm thinking that > the list of steps may be 1) useful to other people and/or 2) useful to > me because it will trigger emails containing corrections to my > process. If this is the wrong mailing list, please tell me which is > the correct mailing list (I've seen ClojureCLR threads here before, > couldn't find a ClojureCLR mailing list). > > > > Cheers, > -- > Miron Brezuleanu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
ClojureCLR - clojure.contrib.repl-utils
Hi, What's the status of clojure.contrib translations for ClojureCLR? Is there a clojure-clr.contrib? (couldn't find something like that on github). I'm especially interested in repl-utils, and I'm thinking of starting to translate it myself, but it would be nice to avoid duplicating effort. Also, I didn't see an Issues tab on the ClojureCLR page on GitHub. The issue I'd like to report is a small one, `apply` behaves differently. For instance, on Clojure JVM the following works: user=> (apply (fn [] 1)) 1 It doesn't work on the latest ClojureCLR. Of course, this is equivalent to "((fn [] 1))" (which works on both Clojures) but I find the `apply` version clearer than double parentheses. Sorry about multi-topicness and thanks for any pointers, -- Miron Brezuleanu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Implementation of zipmap
If that is the case, it could be implemented using transients for a
performance increase.
On Oct 30, 10:53 am, Alex Osborne wrote:
> Chouser wrote:
> > On Fri, Oct 30, 2009 at 11:30 AM, Alex Osborne wrote:
> >> John Harrop wrote:
> >>> Was something wrong with this?:
>
> >>> (defn my-zipmap
> >>> "Returns a map with the keys mapped to the corresponding vals."
> >>> [keys vals]
> >>> (into {} (map vec (partition 2 (interleave keys vals)
>
> >>> :)
> >> One reason might be that the original zipmap is 5-10 times faster for
> >> large numbers of entries as it doesn't create all the temporary seqs.
>
> > Another might be that into, partition and interleave don't exist
> > yet when zipmap is defined.
>
> Yep, although nothing else in core uses zipmap, so it could be moved
> after them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Write big numbers with thousands grouping.
On Sat, Oct 31, 2009 at 1:23 PM, Stuart Sierra wrote: > > For even more fun, you can take advantage of the fact that commas are > whitespace, and use a macro to do it at compile time: > > (defmacro bignum [& parts] > (read-string (apply str parts))) > > (bignum 99,871,142) > 99871142 Eh. Who needs converting to a string and back? Why not: (defmacro bignum [& args] `(reduce (fn [a# b#] (+ a# (apply * b#))) 0 (map vector (reverse '~args) (iterate (fn [x#] (* 1000 x#)) 1 user=> (bignum 318,584,297) 318584297 No mess, no fuss. For some reason though changing "defmacro" here to "definline" doesn't work. It says # which is clearly bogus, since the only & in there indicates a rest part rather than being in a position where it would be evaluated as a var name. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Embedding Clojure in NetKernel
On Oct 28, 7:43 am, Tony Butterfield wrote: > 1) start and stop the Clojure runtime on demand. "Clojure runtime" is a bit of a misnomer; Clojure has no runtime other than the compiler. That's why all the methods of clojure.lang.RT are static. > there a way to cleanly shutdown. I.e. stop threads, and enable a full > garbage collection of the Clojure libraries? Just guessing, but this should do it: 1. (shutdown-agents) 2. release all references to clojure.lang.RT 3. System.gc() > 2) is there a way to ensure isolation of functionality in one runtime? Nope. Again, there's no such thing as a Clojure runtime. Clojure is really more like a special kind of Classloader that happens to load .clj files. -SS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Periodic tasks
On Sat, Oct 31, 2009 at 12:36 PM, Luke VanderHart wrote: > Why not just run an agent that does something, then calls sleep for N > seconds, then calls the next thing? > > Granted, it will eat up a thread in your agent thread pool, but if > you've only got one of these in the app it shouldn't be a problem. > > Or you could go the Java route, and start a daemon thread manually. Or you could use send-off instead of send; send-off doesn't consume from a finite thread pool and is thus suitable for long-running (or blocking, e.g. I/O) tasks. Incidentally, if you ever want to simply reset the state of an agent to a particular value, analogously to ref-set and reset!, this can work: (defn set-agent [a v] (send a (fn [_] v))) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Periodic tasks
On Oct 31, 11:42 am, Richard Newman wrote: > VimClojure relies on Nailgun, with a bunch of people on this list > using it with Clojure every day. My recollection from list and IRC was that (aside from random nailgun issues + the project not being updated in 4 years) there was an issue with dynamic classes being created and never expired. Is that inaccurate? I'm also not sure how one would work around the security issues of running a single nailgun for a variety of tasks that needed different user permissions I'd love to hear success stories from people using nailgun to actually run frequent scripted tasks out of cron, as opposed to for development. It would make clojure more palatable for my work environment. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Write big numbers with thousands grouping.
For even more fun, you can take advantage of the fact that commas are whitespace, and use a macro to do it at compile time: (defmacro bignum [& parts] (read-string (apply str parts))) (bignum 99,871,142) 99871142 -SS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Embedding Clojure in NetKernel
Hi Tony, The CloNK module is licensed under the Apache 2.0 license, a copy of which is contained in the file: urn.com.tohono.clonk.mod/META-INF/LICENSES/Apache-LICENSE-2.0.txt and documented in urn.com.tohono.clonk.mod/docs/guide/license.mw The end result is that I would be delighted if you were able to update this module and contribute it back to the community. Please feel free to ask any questions you may have about Clojure -- I've found this group to be both tremendously knowledgable and very helpful. cheers, -tom On Oct 29, 2:08 pm, Tony Butterfield wrote: > Hi Roman, > sure. Tom sent me a link to this thread: > > http://groups.google.com/group/clojure/browse_thread/thread/d98cedb86... > > and also he sent me a tgz of hisNetKernelmodule. I believe he has > licensed it to be freely available: > > /** > * CloNK4 Project : Clojure forNetKernel4. > * Copyright (C) 2008 by Tohono Consulting LLC. All rights reserverd. > * > * This program is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > */ > > However I'll need him to confirm that before distributing it. Tom did > a great job of getting it working and solving a lot of the integration > issues. But things seem to have changed a bit in both theNetKernel > world and Clojure world since this code was written and it doesn't > work now. I'm working through it try > to get it on its feet again. Though my knowledge of Clojure is very > limited. > > I'll post again on this group when I get something working or need to > ask for help. > > Cheers, > Tony > > On Oct 29, 9:58 am, Roman Roelofsen > wrote: > > > Do you mind sharing the links? I am interested in it as well. > > > Thanks! > > > Roman > > > 2009/10/28 Tony Butterfield : > > > > Tom Hicks has just pointed me to an old thread which answers > > > questions about namespaces and isolation. Let me read and > > > absorb all that work first - I suspect it answers a lot of my > > > questions. > > > > Cheers, Tony > > > > On Oct 28, 11:43 am, Tony Butterfield wrote: > > >> Hi Everybody > > > >> this is my first post to this group so please tell me If I'm posting > > >> in the wrong place. I've been looking at integrating Clojure into > > >>NetKernelas language runtime library but I'm struggling a bit for a > > >> lack of examples. There are two things I'm trying to achieve: > > > >> 1) start and stop the Clojure runtime on demand. I need to do this so > > >> that new versions can be deployed whilst the server is live. Looking > > >> at the latest version (1.0.0) I see that I no longer need to call > > >> RT.init() and that startup is done statically. That's fine but is > > >> there a way to cleanly shutdown. I.e. stop threads, and enable a full > > >> garbage collection of the Clojure libraries? > > > >> 2) is there a way to ensure isolation of functionality in one runtime? > > >> I can see how I can use namespaces to avoid naming collisions but is > > >> it possible to enforce tighter security across namespaces or is there > > >> another technique? I'm quite new to closure so sorry if that is a > > >> stupid question - the trouble is I want to get it running inside > > >>NetKernelas good environment to explore the language - horse before > > >> the cart! When Clojure scripts execute insideNetKernelenvironment it > > >> is important that they act like pure functions with no side-effects on > > >> others. > > > >> Thanks in advance for you advice, > > > >> Tony --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Infinite sequences hang sets and maps
Wouldn't hashCode be called every time you use an infinite sequence as a key in a hash map? That strikes me as a problem, since everything else in Clojure makes perfectly good map keys. On Oct 29, 4:01 am, Mark Engelberg wrote: > On Wed, Oct 28, 2009 at 11:08 PM, John Harrop wrote: > > For the specific case of hashCode, no; identical values must have identical > > hashes but different values need not have different hashes. Collisions due > > to the hypothetical cutoff get exponentially less likely with each > > additional increment of 1 of the cutoff length. > > I see your point that hashCode could be made to work on infinite > sequences, but since hashing is almost always a prelude to testing for > equality, I'm hard pressed to think of an example of why you'd want to > be able to do this. Can you illustrate with an example? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Periodic tasks
> > Overhead from starting and stopping the JVM every couple of minutes > would probably be unacceptable. My understanding is that solutions > like Nailgun don't work correctly with Clojure either. VimClojure relies on Nailgun, with a bunch of people on this list using it with Clojure every day. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Periodic tasks
Why not just run an agent that does something, then calls sleep for N seconds, then calls the next thing? Granted, it will eat up a thread in your agent thread pool, but if you've only got one of these in the app it shouldn't be a problem. Or you could go the Java route, and start a daemon thread manually. -Luke On Oct 30, 12:05 am, Stefan Arentz wrote: > What is a good and simple way to run periodic tasks in Clojure? I need > to run a simple function every couple of minutes. And make sure that > if it throws an exception that it won't kill the periodic task. > > I come from a Spring world where XML, Timers, Jobs and Quartz rule the > world, so am hoping for something small and elegant for Closure :-) > > S. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Write big numbers with thousands grouping.
(defn bignum [coll] (reduce #(+ %1 (apply * %2)) 0 (map vector (reverse coll) (iterate #(* 1000 %) 1 user=> (bignum [102 317 926]) 102317926 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Periodic tasks
On Oct 31, 5:22 am, alxtoth wrote: > Why not use the OS task scheduler? On un*x there is good old cron or > at. On windoze there is similar task scheduler. > Overhead from starting and stopping the JVM every couple of minutes would probably be unacceptable. My understanding is that solutions like Nailgun don't work correctly with Clojure either. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generating Java and C# wrappers
On Sat, Oct 31, 2009 at 12:44 AM, John Ky wrote: > Hi Stuart, > > I wasn't very clear. > > Essentially, the problem I have boils down to having to maintain two > separate code bases for my API - one in C# and one in Java. There is some > overhead in maitaining two different code bases - for instance, whenever, I > fix a bug in one or add a feature in one, I need to do the same in the > other. I also need to write all my unit test cases in each language for > both APIs, adding more work still. > > Given that both Clojure and ClojureCLR exists, it should be theoretically > possible to write the logic of my API in the Clojure language and run them > on both the JVM, or the CLR. As I would need to do networking with my API, > all the runtime specific stuff, I could wrap with a common interface andthen > call them from Clojure. In this case, I would only need to maintain one API > logic, and two runtime specific abstraction wrappers. > > Unfortunately, as I am writing an API, and not my own application, I would > still need to provide a Java or C# wrapper so that other people who don't > use or know Clojure and can interface with my code - which again is more > work. > > So the question is - would it make sense to specify that interface (ie. the > Java and C# ones) in a language neutral specification with Clojure data > structures, then from those data structures generate Java wrappers and C# > wrappers around my clojure API logic code? > > There may not be such a solution in existence today - so essentially, the > question is does such a solution make sense? > > Is that feasible or even possible or desirable? Or am I just being silly? > What about doing this?: * Most of the code-base is in namespaces project.core.this * There's a single namespace project.wrap with platform-specific code. The wrap.clj file has two versions, a CLR version and a Java version. * You compile the project excluding the CLR version of wrap.clj to a jar and distribute that to Java users. * You compile the project excluding the Java version of wrap.clj to whatever archive format .NET uses and distribute that to .NET users. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generalizing -> & ->>
On Sat, Oct 31, 2009 at 9:13 AM, Daniel Werner < daniel.d.wer...@googlemail.com> wrote: > > On Oct 29, 9:35 pm, "AndrewC." wrote: > > Here's a macro that generalizes the two 'threading' macros -> and ->>. > > There have been multiple discussions on this group where similar > operators have been proposed, with some implementations very closely > matching this one. If the demand is so high, maybe it is finally time > to add one of the proposals to clojure.contrib.core (or even > clojure.core)? > > Personally, I prefer the syntax of Andrew's implementation to the ones > posted in the past. The syntax, perhaps; the names are, at least to me, completely meaningless, unlike e.g. comp, partial, and friends from clojure.core that do similar things. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Memoize improvement
Actually, the code I posted might behave less well if the timing is less
uniform. It's better to store wait times with queue entries rather than with
cache entries:
(defn my-memoize
"Returns a memoized version of a referentially transparent
function. The memoized version of the function keeps a cache of
the mapping from arguments to results and, when calls with the
same arguments are repeated often, has higher performance at
the expense of higher memory use. Cached results are removed
from the cache when their time to live value expires."
[function time-to-live]
(let [cached-results (ref {})
last-time (ref (System/currentTimeMillis))
expiry-queue (ref [])
process-queue #(when-not (empty? @expiry-queue)
(Thread/sleep
(:wait (first @expiry-queue)))
(dosync
(let [args (:item (first (ensure
expiry-queue)))
item (get (ensure cached-results) args)
t (- (:time item) 100)]
(if (<= t (System/currentTimeMillis))
(alter cached-results dissoc args))
(ref-set expiry-queue
(vec (rest @expiry-queue)
(recur))
ts-agent (agent nil)]
(fn [& args]
(let [result (if-let [r (get @cached-results args)]
(:result r)
(apply function args))]
(dosync
(let [t (+ time-to-live (System/currentTimeMillis))
l (max (ensure last-time) (System/currentTimeMillis))
w (- t l)
q (ensure expiry-queue)]
(alter cached-results assoc args
{:result result :time t})
(ref-set last-time t)
(alter expiry-queue conj {:item args :wait w})
(if (empty? q)
(send ts-agent (fn [_] (.start (Thread. process-queue)))
result
This version also drops the println.
user=> (def x (my-memoize #(do (println %) (+ % 10)) 1000))
#'user/x
user=> (doall (for [n [1 2 4 1 2 3 1 2 3 2 3 2 3 2 3 1 4]] (do (Thread/sleep
300) (x n
1
2
4 ; pause
3 ; long pause
1
4
(11 12 14 11 12 13 11 12 13 12 13 12 13 12 13 11 14)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Memoize improvement
On Fri, Oct 30, 2009 at 7:57 PM, Stefan Arentz wrote:
> This is some of my first Clojure code so it might not be the
> greatest ... yet!
>
It's quite interesting.
(defn my-memoize
> "Returns a memoized version of a referentially transparent
> function. The
> memoized version of the function keeps a cache of the mapping from
> arguments
> to results and, when calls with the same arguments are repeated
> often, has
> higher performance at the expense of higher memory use. Cached
> results are
> removed from the cache when their time to live value expires."
> [function time-to-live]
> (let [cached-results (atom {})]
> (fn [& arguments]
> (swap! cached-results expire-cached-results time-to-live)
> (println cached-results)
> (if-let [entry (find @cached-results arguments)]
> (:result (val entry))
> (let [result (apply function arguments)]
> (swap! cached-results assoc arguments { :result
> result :time (System/currentTimeMillis)})
> result)
I'd make a couple of changes, though. First:
(defn my-memoize
"Returns a memoized version of a referentially transparent
function. The memoized version of the function keeps a cache of
the mapping from arguments to results and, when calls with the
same arguments are repeated often, has higher performance at
the expense of higher memory use. Cached results are removed
from the cache when their time to live value expires."
[function time-to-live]
(let [cached-results (atom {})]
(fn [& arguments]
(swap! cached-results expire-cached-results time-to-live)
(let [result (if-let [r (get @cached-results arguments)]
(:result r)
(apply function arguments))]
(swap! cached-results assoc arguments
{:result result :time (System/currentTimeMillis)})
result
This resets the expiry clock on a result if the same arguments occur again.
So instead of a result expiring n seconds after being put in, it only does
so if there's an n-second period during which that result isn't used at all.
A more sophisticated change is to make expire-cached-results happen even if
the function stops being called for a long time. That requires threading.
Most efficient might be to dispense with the {:result result :time time} and
just map arguments onto results, but whenever one does an (apply function
arguments) one also assoc's the result into the map in the atom AND starts a
thread:
(.start (Thread. #(Thread/sleep time-to-live) (swap! cached-results dissoc
arguments)))
Poof! After time-to-live that particular result disappears. This reverts to
having the result expire n seconds after being put in, though, and it also
potentially spawns large numbers of threads, albeit mostly all sleeping at
once.
The "result goes away if unused for n seconds" behavior and accumulation of
threads can both be nixed, though:
(defn my-memoize
"Returns a memoized version of a referentially transparent
function. The memoized version of the function keeps a cache of
the mapping from arguments to results and, when calls with the
same arguments are repeated often, has higher performance at
the expense of higher memory use. Cached results are removed
from the cache when their time to live value expires."
[function time-to-live]
(let [cached-results (ref {})
last-time (ref (System/currentTimeMillis))
expiry-queue (ref [])
process-queue #(when-not (empty? @expiry-queue)
(Thread/sleep
(:wait (get @cached-results (first
@expiry-queue
(dosync
(let [args (first (ensure expiry-queue))
item (get (ensure cached-results) args)
t (- (:time item) 100)]
(if (<= t (System/currentTimeMillis))
(alter cached-results dissoc args))
(ref-set expiry-queue
(vec (rest @expiry-queue)
(recur))
ts-agent (agent nil)]
(fn [& args]
(let [result (if-let [r (get @cached-results args)]
(:result r)
(apply function args))]
(dosync
(let [t (+ time-to-live (System/currentTimeMillis))
l (max (ensure last-time) (System/currentTimeMillis))
w (- t l)
q (ensure expiry-queue)]
(println t w q @cached-results)
(alter cached-results assoc args
{:result result :time t :wait w})
(ref-set last-time t)
(alter expiry-queue conj args)
(if (empty? q)
(send ts-agent (fn [_] (.start (Thread. process-queue)))
result
This is tested and works:
user=> (def x (my-memoize #(do (println %) (+ % 10)) 100
Re: Generalizing -> & ->>
On Oct 29, 9:35 pm, "AndrewC." wrote: > Here's a macro that generalizes the two 'threading' macros -> and ->>. There have been multiple discussions on this group where similar operators have been proposed, with some implementations very closely matching this one. If the demand is so high, maybe it is finally time to add one of the proposals to clojure.contrib.core (or even clojure.core)? Personally, I prefer the syntax of Andrew's implementation to the ones posted in the past. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is running a script without leaving Clojure?
Thanks! 2009/10/31 Chouser > > On Fri, Oct 30, 2009 at 4:44 PM, Chick Corea > wrote: > > > > Where are those and other CLI options documented? I have not found > > them. > > > > A "usage" or "help" message could help w/ this, too. > > java -cp clojure.jar clojure.main --help > > --Chouser > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: can I make this faster (and leaner) ?
On Fri, Oct 30, 2009 at 7:47 PM, DavidF wrote: > > Try this: > > (def *valid-chars* [ \a \b \c \d \e \f \g \h \i \j \k \l \m > \n \o \p \q \r \s \t \u \v \w \x \u \z > \0 \1 \2 \3 \4 \5 \6 \7 \8 \9 ] ) > > (defn generate-key [keylength] >(for [x (range keylength)] (nth *valid-chars* (rand-int (count > *valid- > chars*) There's a perfectly good reusable function hidden in there: (defn rand-elt [coll] (nth coll (rand-int (count coll (defn generate-key [key-length] (for [x (range key-length)] (rand-elt *valid-chars*))) And you might want to wrap that for loop in (apply str ~the-loop). It also might be more idiomatic to call *valid-chars* +valid-chars+ if it's not normally going to be rebound or otherwise changed. (While we're on the topic of valid chars, how come the reader page http://clojure.org/reader at clojure.org doesn't list as legal identifier characters some characters that occur in identifiers in clojure.core? Specifically, =, >, and <. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure contrib http-agent hangs when making a POST request
Rob, that's perfect. Thanks very much for looking into that and supplying the patch. Hopefully we can get that applied to the source in git. On Oct 30, 9:58 pm, Rob Wolfe wrote: > Alex writes: > > Hi, > > > I'm getting some strange errors when trying to make a POST request > > using the Clojure contrib http-agent library (http:// > > richhickey.github.com/clojure-contrib/http.agent-api.html). > > > When I run: > > > (use 'clojure.contrib.http.agent) > > > (println (string (http-agent "http://www.google.com"; :method > > "POST" :body "param=true"))) > > > The REPL simply hangs forever. > > > However, when I run the following: > > > (def agt (http-agent "http://www.google.com"; :method "POST" :body > > "param=true")) > > ;...wait a bit or add a (Thread/sleep 1000) > > (println (string agt)) > > > I get a correct response (Google saying it doesn't like POST requests) > > > Also, the (result ... ) function appears to work fine also: > > > (println (result (http-agent "http://www.google.com"; :method > > "POST" :body "param=true"))) > > > So it looks like something in the (string ... ) function is causing it > > to hang if the response has not yet completed. Anyone have any idea > > what might be causing this? > > I guess the problem is in "string" function, because it tries > to get "content encoding" of stream which is not available. > In this case output stream was presumably closed by server. > So I can see two solutions: > > 1) always waiting until request is completed using "result" function > > > (ns test2 > (:require [clojure.contrib.http.agent :as http] > [clojure.contrib.duck-streams :as ds])) > > (let [agnt > (http/http-agent "http://www.google.com"; > :method "POST" > :body "param=true")] > (http/result agnt) > (println "string: " (http/string agnt))) > (shutdown-agents) > > > 2) applying this patch on original clojure.contrib.http.agent, > which imho solves this problem > > > --- a/src/clojure/contrib/http/agent.clj > +++ b/src/clojure/contrib/http/agent.clj > @@ -263,9 +263,12 @@ > headers, or clojure.contrib.duck-streams/*default-encoding* if it is > not specified." > ([http-agnt] > - (string http-agnt (or (.getContentEncoding > - #^HttpURLConnection (::connection @http-agnt)) > - duck/*default-encoding*))) > + (let [a @http-agnt] > + (if (= (::state a) ::receiving) > + (string http-agnt (or (.getContentEncoding > + #^HttpURLConnection (::connection > @http-agnt)) > + duck/*default-encoding*)) > + (string http-agnt duck/*default-encoding* > ([http-agnt #^String encoding] > (.toString (get-byte-buffer http-agnt) encoding))) > > > HTH, > Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Periodic tasks
Hi Why not use the OS task scheduler? On un*x there is good old cron or at. On windoze there is similar task scheduler. If you think a little that's what it takes: simple reliable and if it fails with whatever error will start again in 2 minutes. Just don't forget to write to log files , and rotate those files sometimes. I am sure there are more fancy solutions than cron, and some that don't require megabytes of XML as the usual Java stuff -Alex On Oct 30, 6:05 am, Stefan Arentz wrote: > What is a good and simple way to run periodic tasks in Clojure? I need > to run a simple function every couple of minutes. And make sure that > if it throws an exception that it won't kill the periodic task. > > I come from a Spring world where XML, Timers, Jobs and Quartz rule the > world, so am hoping for something small and elegant for Closure :-) > > S. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generating Java and C# wrappers
Hi Stuart, I wasn't very clear. Essentially, the problem I have boils down to having to maintain two separate code bases for my API - one in C# and one in Java. There is some overhead in maitaining two different code bases - for instance, whenever, I fix a bug in one or add a feature in one, I need to do the same in the other. I also need to write all my unit test cases in each language for both APIs, adding more work still. Given that both Clojure and ClojureCLR exists, it should be theoretically possible to write the logic of my API in the Clojure language and run them on both the JVM, or the CLR. As I would need to do networking with my API, all the runtime specific stuff, I could wrap with a common interface andthen call them from Clojure. In this case, I would only need to maintain one API logic, and two runtime specific abstraction wrappers. Unfortunately, as I am writing an API, and not my own application, I would still need to provide a Java or C# wrapper so that other people who don't use or know Clojure and can interface with my code - which again is more work. So the question is - would it make sense to specify that interface (ie. the Java and C# ones) in a language neutral specification with Clojure data structures, then from those data structures generate Java wrappers and C# wrappers around my clojure API logic code? There may not be such a solution in existence today - so essentially, the question is does such a solution make sense? Is that feasible or even possible or desirable? Or am I just being silly? Cheers, -John On Sat, Oct 31, 2009 at 1:16 AM, Stuart Sierra wrote: > > On Oct 30, 6:18 am, John Ky wrote: > > I've been wondering if there was a way to specify the Java and C# wrapper > > classes/interfaces to wrap Clojure code in Clojure, and then writing out > > them to a file so that they can ge compiled by their respective > compilers. > > I'm not sure I understand your question. There are two distinct > versions of Clojure: the original, which targets the JVM, and > ClojureCLR, which targets the CLR. Neither one generates Java or C# > source code; both generate bytecode for their respective runtimes. > > ClojureCLR is at http://github.com/richhickey/clojure-clr > > -SS > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Compiling latest ClojureCLR
Hello, I've tried compiling the latest ClojureCLR and ... it wasn't easy. Maybe because my setup is missing stuff (a fresh virtual machine with Windows Server 2003, Visual Studio 2008 SP1 and the Visual J# redistributables). Anyway, I managed to come up with a reproducible list of steps that got me into a ClojureCLR REPL and I'm thinking that the list of steps may be 1) useful to other people and/or 2) useful to me because it will trigger emails containing corrections to my process. If this is the wrong mailing list, please tell me which is the correct mailing list (I've seen ClojureCLR threads here before, couldn't find a ClojureCLR mailing list). So here's my list of steps: 1. Create a 'clojure' directory somewhere convenient (this dir will be denoted by $CLOJURE below). 2. Download the DLR from http://dlr.codeplex.com/SourceControl/ListDownloadableCommits.aspx#DownloadLatest Right now the archive name is dlr-33505.zip, denoting the revision. The revision numbers will obviously increase. 3. Unzip the DLR archive into $CLOJURE 4. Load the $CLOJURE/DLR_Main/Src/Codeplex-DLR.sln solution in Visual Studio 2008 SP1. 5. Build it, close Visual Studio. 6. Clone the clojure-clr repository by running git clone git://github.com/richhickey/clojure-clr.git in $CLOJURE (the commit I used is f62dd19) 7. Open the $CLOJURE/clojure-clr/Clojure/ClojureCLR.sln solution in Visual Studio 2008 SP1. 8. Check the references of the Clojure project. If there is a yellow warning sign next to the 'vjslib' reference, you need to close the solution, download the VJ# redistributable from http://www.microsoft.com/downLoads/details.aspx?familyid=F72C74B3-ED0E-4AF8-AE63-2F0E42501BE1&displaylang=en , install it and go to step 7. 9. Check that the projects in the Runtime/ solution folder are loaded. Seems like this setup is similar to dmiller's - the projects load OK. 10. Since I was not interested in running the ClojureCLR tests, I did not install nunit or RhinoMocks. So building the whole solution won't work. Try building the Clojure project. 11. Get 134 errors, very similar to 'The type or namespace name 'Linq' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)'. Scratch head (optional sub-step). Remember that there is a 'System.Linq.Expressions' in .NET 3.5. Look for 'System.Linq.Expressions' in Runtime/Microsoft.Scripting.Core/Actions/BinaryOperationsBinder.cs. The #if directive at the start of the file provides a hint that we may want to use 'Microsoft.Scripting.Ast' instead (because the DLR assemblies we're interested in are compiled for .NET 2.0). Use Control-Shift-F to replace 'Microsoft.Linq.Expressions' with 'Microsoft.Scripting.Ast' across the entire solution. Save all, close the opened files, try building the Clojure project again. 12. Oh joy. The error count is down to two. Scratch head (again, this is optional). The errors are similar to 'The type or namespace name 'Utils' does not exist in the namespace 'Microsoft.Scripting.Ast' (are you missing an assembly reference?)'. Apparently we need 'SimpleCallHelper' from that namespace. Searching for it inside the DLR solution reveals that it is defined in project 'Microsoft.Dynamic' in the DLR. Add this project to the 'Runtime' solution folder inside the ClojureCLR solution (Existing Project, Microsoft.Dynamic.csproj). Also add a reference to the project to the Clojure project. Try compiling the Clojure project again. 13. The compilation succeeds. Wonderful. Build the Clojure.Compile project, then the Clojure.Main project. 14. Run the $CLOJURE/clojure-clr/Clojure/Clojure.Main/bin/Debug/Clojure.Main.exe. Celebrate getting a Clojure REPL by typing (+ 1 1) or your favourite Clojure expression. Cheers, -- Miron Brezuleanu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: bugs in cl-format.clj
OK, fixed. Grab the latest contrib from github and you should be all set. Feel free to let me know directly if you see any other issues. I'm sure they're there! :-) Tom On Oct 30, 11:20 pm, Tom Faulhaber wrote: > I've added assembla ticket #40 for these > issues:https://www.assembla.com/spaces/clojure-contrib/tickets/40-bugs-in-cl... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
