Re: clojure-backtracking-monads .. can it emulate prolog?
On 3 Nov 2010, at 06:04, Sunil S Nandihalli wrote: Hello everybody, I was wondering if one can code in a way semantically similar to prolog using the backtracking monads.. Has anybody tried it .. ? I did see the tutorial which demonstrates backtracking monads .. http://brehaut.net/blog/2010/ghosts_in_the_machine Have a look at this tutorial: http://intensivesystems.net/tutorials/logic_prog.html and get the code that goes with it: http://github.com/jduey/mini-kanren It's not quite full-fledged Prolog, but you can do a lot with it. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-backtracking-monads .. can it emulate prolog?
Thanks Konrad. I will look at it. Sunil On Wed, Nov 3, 2010 at 1:08 PM, Konrad Hinsen wrote: > On 3 Nov 2010, at 06:04, Sunil S Nandihalli wrote: > > Hello everybody, >> I was wondering if one can code in a way semantically similar to prolog >> using the backtracking monads.. Has anybody tried it .. ? I did see the >> tutorial which demonstrates backtracking monads .. >> http://brehaut.net/blog/2010/ghosts_in_the_machine >> > > Have a look at this tutorial: > >http://intensivesystems.net/tutorials/logic_prog.html > > and get the code that goes with it: > >http://github.com/jduey/mini-kanren > > It's not quite full-fledged Prolog, but you can do a lot with it. > > Konrad. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You 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: StackOverflowError while using map inside a reduce
On Wed, Nov 3, 2010 at 2:35 AM, Meikel Brandmeyer wrote: > Hi, > > On 3 Nov., 00:40, Rasmus Svensson wrote: > >> I think the problem is that this reduction will build an expression like >> this: >> >> (map + ... (map + ... (map + ... (map + ... > levels> >> >> When clojure tries to realize an element of the resulting lazy seq, >> every level will result in a nested method call, which will eventually >> blow the stack. > > Exactly. Much better than my try on an explanation. The doall in my > example realises each sequence as it is created by reduce. Hence this > deep nesting level of calls cannot happen. Thank you both for the explanation. I hadn't realized that reduce could work with lazy sequences in that way. I figured it was doing the equivalent of a "doall" already for each element of the sequence, but apparently not. :-) So now I see how the nesting can happen. Thanks! -John -- You 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: A question on distributed computing
Some things are certainly possible. It depends whether you consider all computers to be friendly of some of them to be evil. If all of them are friendly, you can annotate your data by permissions. Else, you need either to check what you send to other computers, or crypt with different keys. -- You 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
Some questions about Clojure Protocols
1. How to combine protocols? For example I have protocols walks, talks, sleeps, now how might I come up with an abstraction which walks-talks-and-sleeps ? In Java one might create an interface which extends multiple interfaces. Although getting an instance which walks-talks-and-sleeps is made easy with deftype. On a related note if I have a protocol P how can I create a protocol with is a union of P and java.lang.Comparable ? 2. Does it make sense to have "static" fns as part of Clojure protocols? For example a fn such as can-walk? could make sense as part of the walks protocol. I realize I can create a (defn can-walk? ...) in the protocol ns and its the same from caller's pov .. (proto-ns/can-walk? ...). But how about having can-I-walk? as part of the walks protocol itself (somehow to me it gives a more complete feeling). Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
Bug with instance? inside deftypes
Clojure 1.2.0 1:1 user=> 1:2 user=> 1:3 user=> (deftype T [] Object (equals [this o] (if (instance? T o) true false))) user.T 1:4 user=> (def t (T.)) #'user/t 1:5 user=> (.equals t t) false 1:6 user=> (deftype T [] Object (equals [this o] (if (= T (class o)) true false))) user.T 1:7 user=> (def t (T.)) #'user/t 1:8 user=> (.equals t t) true 1:9 user=> (doc deftype) especially says: > In the method bodies, the (unqualified) name can be used to name the class > (for calls to new, instance? etc). Somebody on the IRC pointed out: >> while compiling the deftype, T resolves to a different class object (a >> compiler-generated stub class) which might conflict with the special >> inlining of instance? Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Some questions about Clojure Protocols
On Wed, Nov 3, 2010 at 10:32 AM, ka wrote: > 1. How to combine protocols? > AFAIK, it is not possible. You must implement all the different protocols. It might look desapointing, but on the other hand it is not necessary. (As there is no static typing in Clojure) What is your use-case? > 2. Does it make sense to have "static" fns as part of Clojure > protocols? > What do you mean by "static" functions? -- You 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: to macro or not?
On 11/2/2010 12:38 PM, Laurent PETIT wrote: 2010/10/30 Tim Daly: Macros in lisp get used for three general purposes, at least in my experience. The first purpose is efficiency. In common lisp you will find that you can generate very machine-efficient (aka optimized fortran level) binary instruction sequences if you add type information. This gets tedious to do in code so you write a macro. So (+ x y) has to assume that x and y are anything, including non-numeric. If you write a (plus x y) macro it can expand to (the fixnum (+ (the fixnum x) (the fixnum y))) which I have seen optimized into a single machine instruction. Macros could be used to solve the boxing/unboxing issues in Clojure. For writing DSLs, consider the excellent speak of cgrand at the conj : (not= DSL macros) Here are the slides: http://speakerrate.com/talks/4895-not-dsl-macros Yes, I saw the slides. I disagree with the speaker, at least, from what I could see from the slides. Tim Daly -- You 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: A question on distributed computing
On Wed, Nov 3, 2010 at 1:04 AM, Vivek Khurana wrote: > > > On Nov 2, 8:56 pm, Ken Wesson wrote: > > > That seems impossible assuming you don't trust the software running on > the > > other node. > > > > It is not impossible. There are projects by Cornell .University, > jiff[1] and fabric[2] which have achieved the same. Jiff is > modification of java and fabric is based on jiff.Both languages run > inside JVM. I'd expect those involve trusting the JVM and the hardware of the remote node, even if not the software running on that JVM. You need to work out your trust model more exactly. What specifically don't you trust? Just the user at the remote node? The code running on the JVM? The JVM itself? The hardware? The network infrastructure between? If you just don't trust the remote user and the network between, it may suffice to give him a closed source program and encrypt the network traffic -- though ultimately that would fall before a determined enough adversary (as all attempts at copy protection by game companies and movie studios have proven through their notorious strings of failures). Closed source just slows down reverse engineering; it doesn't stop it. Basically this works only if the potentially hostile node will be operated by a non-techie or by someone who at least can't modify the running system past a certain point. Employees that don't have write access, say, but might go poking into confidential records on a lark. With pretty much any other assumption about the threat model all that changes: you could have a determined hacker sit down at the remote node and replace anything from the CPU to the JVM or parts of the operating system with hostile code, undermining whatever you're running on top of it. The one thing guaranteed to minimize your exposure in this case is what I prescribed: dole out information to remote nodes on a need-to-know basis. Have them submit proposed edits back to your own (trusted) node where the edits (or even the entire remote node) can be rejected if anything is amiss -- if it tries to change any of these things it shouldn't try to change, into the IP blacklist it goes. And of course give each node a key pair and encrypt each transmission with the public key for the recipient node, so the network traffic can't be sniffed by third parties (short of compromising many nodes to root out their private keys). There are ways to go even further -- submitting computations, say, to multiple nodes and if they disagree on the answer resubmitting to a disjoint set, so one can only be sabotaged by someone who can predict exactly which nodes it'll be sent to and compromise them all, or else someone who can compromise all the nodes, period. Distributed computing projects tend to go this far. So do file sharing systems -- they're under constant attack by determined adversaries (even if this time the law is on those adversaries' side!) and have evolved towards decentralization, being physically widely distributed, and having cross-checks (such as databases of file hashes, including of known bad files, and requiring swarm download sources to agree on the file's hash so if any one of them tries to slip in a bad packet the others can detect it). The Freenet project has perhaps the ultimate level of paranoia of this sort, where the things to protect in this case are a) the integrity of the network itself and b) the confidentiality of who-published-what. Ultimately, though, if you think simply sprinkling permissions flags into your data here and there and trusting some part of the remote system (even the JVM) to enforce it will work, even if you throw in a load of obfuscation and encryption and make the node software closed-source, in the vast majority of cases it simply won't hold up in the face of a determined assault by any adversary with full control of the remote hardware. If it was possible the movie industry's attempts to stop blurays being ripped and shared could have actually worked, whereas computer security professionals are pretty much unanimous that all such attempts were doomed to failure from the get-go; and the empirical evidence seems to be strongly in favor of what those security professionals said. -- You 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: to macro or not?
2010/11/3 Tim Daly : > > > On 11/2/2010 12:38 PM, Laurent PETIT wrote: >> >> 2010/10/30 Tim Daly: >>> >>> Macros in lisp get used for three general purposes, at least >>> in my experience. >>> >>> The first purpose is efficiency. In common lisp you will find >>> that you can generate very machine-efficient (aka optimized >>> fortran level) binary instruction sequences if you add type >>> information. This gets tedious to do in code so you write a >>> macro. So (+ x y) has to assume that x and y are anything, >>> including non-numeric. If you write a (plus x y) macro it >>> can expand to >>> (the fixnum (+ (the fixnum x) (the fixnum y))) >>> which I have seen optimized into a single machine instruction. >>> Macros could be used to solve the boxing/unboxing issues in >>> Clojure. >> >> For writing DSLs, consider the excellent speak of cgrand at the conj : >> (not= DSL macros) >> >> Here are the slides: http://speakerrate.com/talks/4895-not-dsl-macros > > Yes, I saw the slides. I disagree with the speaker, at least, from > what I could see from the slides. If you could argument more, this could be the start of an interesting thread ... -- You 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: Some questions about Clojure Protocols
On Nov 3, 6:32 am, ka wrote: > 1. How to combine protocols? Just define types that extend all the protocols. > On a related note if I have a protocol P how can I create a protocol > with is a union of P and java.lang.Comparable ? You can't. But you can define a type that extends both P and Comparable. > 2. Does it make sense to have "static" fns as part of Clojure > protocols? No. These are just ordinary functions. Protocols provide just one thing: polymorphic functions. They are not intended to provide "type" or hierarchy like Java classes / interfaces. -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: A question on distributed computing
Before going down this road, I'd strongly recommend reading Ross Anderson's paper "Programming Satan's Computer": http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf In addition, Ross has generously put the first edition of his book "Security Engineering" online: http://www.cl.cam.ac.uk/~rja14/book.html The original poster talked about health data, but didn't mention the trust model. Getting this right is a monumental task and one I wouldn't approach willingly. Chris On Wed, Nov 3, 2010 at 5:11 AM, nicolas.o...@gmail.com wrote: > Some things are certainly possible. It depends whether you consider > all computers to be friendly of > some of them to be evil. > > If all of them are friendly, you can annotate your data by permissions. > > Else, you need either to check what you send to other computers, or > crypt with different keys. > > -- > You 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 > -- | Chris Petrilli | petri...@amber.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-backtracking-monads .. can it emulate prolog?
Hi Konrad, It is really nice .. But I was wondering if it had a cut operator or predicate .. similar to '!' in prolog.. Thanks, Sunil. On Wed, Nov 3, 2010 at 1:20 PM, Sunil S Nandihalli < sunil.nandiha...@gmail.com> wrote: > Thanks Konrad. I will look at it. > Sunil > > > On Wed, Nov 3, 2010 at 1:08 PM, Konrad Hinsen > wrote: > >> On 3 Nov 2010, at 06:04, Sunil S Nandihalli wrote: >> >> Hello everybody, >>> I was wondering if one can code in a way semantically similar to prolog >>> using the backtracking monads.. Has anybody tried it .. ? I did see the >>> tutorial which demonstrates backtracking monads .. >>> http://brehaut.net/blog/2010/ghosts_in_the_machine >>> >> >> Have a look at this tutorial: >> >>http://intensivesystems.net/tutorials/logic_prog.html >> >> and get the code that goes with it: >> >>http://github.com/jduey/mini-kanren >> >> It's not quite full-fledged Prolog, but you can do a lot with it. >> >> Konrad. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- You 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: REQUEST for feedback on http://clojure.org
Michael: thanks for those tips. I can't do anything about those but I will raise it... ka: you can find that kind of stuff now on the Clojure confluence pages: http://dev.clojure.org/display/design/Home On Nov 2, 10:43 pm, ka wrote: > Hi Alex, Can we have a section: Clojure - What's next? Dishes out > some details & links for the next versions and ideas. -- You 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: Bug with instance? inside deftypes
I would guess the problem is referring to T inside the deftype. This works; (deftype T [] Object (equals [this o] (if (instance? (class this) o) true false))) (let [t (T.)] (.equals t t)) ==> true On Wed, Nov 3, 2010 at 12:39 PM, ka wrote: > Clojure 1.2.0 > 1:1 user=> > 1:2 user=> > 1:3 user=> (deftype T [] Object (equals [this o] (if (instance? T o) > true false))) > user.T > 1:4 user=> (def t (T.)) > #'user/t > 1:5 user=> (.equals t t) > false > 1:6 user=> (deftype T [] Object (equals [this o] (if (= T (class o)) > true false))) > user.T > 1:7 user=> (def t (T.)) > #'user/t > 1:8 user=> (.equals t t) > true > 1:9 user=> > > (doc deftype) especially says: >> In the method bodies, the (unqualified) name can be used to name the class >> (for calls to new, instance? etc). > > Somebody on the IRC pointed out: >>> while compiling the deftype, T resolves to a different class object (a >>> compiler-generated stub class) which might conflict with the special >>> inlining of instance? > > Thanks > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Bug with instance? inside deftypes
Hi, On 3 Nov., 14:58, Adrian Cuthbertson wrote: > I would guess the problem is referring to T inside the deftype. This works; > > (deftype T [] Object (equals [this o] (if (instance? (class this) o) > true false))) > (let [t (T.)] (.equals t t)) > ==> true I hope that this is not the end of the story. :/ Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-backtracking-monads .. can it emulate prolog?
Sunil, I've been away from that code for a while, so I forget the details about its cut operator. However, I would really encourage you to read The Reasoned Schemer, which is where that code came from. I'm also intending to change it to use Fogus' unifier when I get home. Jim On Nov 3, 8:14 am, Sunil S Nandihalli wrote: > Hi Konrad, > It is really nice .. But I was wondering if it had a cut operator or > predicate .. similar to '!' in prolog.. > Thanks, > Sunil. > > On Wed, Nov 3, 2010 at 1:20 PM, Sunil S Nandihalli < > > sunil.nandiha...@gmail.com> wrote: > > Thanks Konrad. I will look at it. > > Sunil > > > On Wed, Nov 3, 2010 at 1:08 PM, Konrad Hinsen > > wrote: > > >> On 3 Nov 2010, at 06:04, Sunil S Nandihalli wrote: > > >> Hello everybody, > >>> I was wondering if one can code in a way semantically similar to prolog > >>> using the backtracking monads.. Has anybody tried it .. ? I did see the > >>> tutorial which demonstrates backtracking monads .. > >>>http://brehaut.net/blog/2010/ghosts_in_the_machine > > >> Have a look at this tutorial: > > >> http://intensivesystems.net/tutorials/logic_prog.html > > >> and get the code that goes with it: > > >> http://github.com/jduey/mini-kanren > > >> It's not quite full-fledged Prolog, but you can do a lot with it. > > >> Konrad. > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >>http://groups.google.com/group/clojure?hl=en -- You 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: Java gotchas now clojure gotchas
It would seem that a solution to this problem would be to treat such automatic boxing/upcasting similar to reflection -- i.e., have an option that causes Clojure to spit out a warning when such boxing/ upcasting occurs, alerting the performance conscious of the need to change the code that is generating the offense. On Nov 2, 9:26 pm, CuppoJava wrote: > Personally, I find the added time and complexity required to be > careful about such problems (ie. numerical overflow) is easier to deal > with than later having to optimize subtle performance problems that > arise from these automatic boxing / upcasting solutions. From the > frequency of performance-related posts on the newsgroup, it seems I'm > not the only one who finds optimizing Clojure difficult enough as it > is. > -Patrick > > On Nov 2, 6:22 pm, box wrote: > > > > > > > > > Math/abs doesn't always return positive numbers. example: > > > user=> (def min-int -2147483648) > > #'user/min-int > > > user=> min-int > > -2147483648 > > > user=> (Math/abs min-int) > > -2147483648 > > > user=> (def min-int+1 (+ 1 min-int)) > > #'user/min-int+1 > > > user=> min-int+1 > > -2147483647 > > > user=> (Math/abs (- min-int+1 1)) > > -2147483648 > > > (Math/abs (- Integer/MIN_VALUE 1)) > > 2147483649 > > > so, in order to solve this problem, clojure needs it's own ABS, or it > > needs to convert a negative int approaching Integer/MIN_VALUE to > > something else before it reaches Integer/MIN_VALUE. > > > so, does it sound sane for clojure to fix java's surprises? -- You 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: Java gotchas now clojure gotchas
Hi, On 3 Nov., 15:37, Mark Hamstra wrote: > It would seem that a solution to this problem would be to treat such > automatic boxing/upcasting similar to reflection -- i.e., have an > option that causes Clojure to spit out a warning when such boxing/ > upcasting occurs, alerting the performance conscious of the need to > change the code that is generating the offense. At least for loop this happens when *warn-on-reflection* is true. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Ok... Fair enough. Most of my comment related to Spring, not to Grails. Grails has other issues which I won't get into here. I have nothing but respect for Rails, and I look forward to the day when Clojure has a comparable system. On Nov 2, 2:32 pm, Wilson MacGyver wrote: > On Tue, Nov 2, 2010 at 12:49 PM, Luke VanderHart > > wrote: > > fanvie, two comments: > > 2. You don't need 99% of the special crap that Spring/Grails gives > > you. Clojure's abstractions are smaller, yes, but the're just as > > powerful, and give you more control, in a more standardized way, then > > Spring does. > > I'll take exception to this comment. I think calling what grails as a > framework > provide you as "special crap", is at best, a disservice to grails as well as > other web framework. > > At the end of the day, people want to deliver a solution for a problem they > are > working on. Not focusing on "oh look, shiny technology and abstractions" > > There is value in being able to define a domain object, and right off the bat > have ORM taken care of for you, tables created, controllers setup > with CRUD/webservice/scafold. > > and then grails war to produce a complete single war file to deploy to any > java application server. > > Not everyone "needs" it, but that doesn't make it crap. > > --- > Omnem crede diem tibi diluxisse supremum. -- You 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-backtracking-monads .. can it emulate prolog?
thanks Jim for your email. I will try to get my hands on Reasoned Schemer.. :) Sunil. On Wed, Nov 3, 2010 at 7:44 PM, jim wrote: > Sunil, > > I've been away from that code for a while, so I forget the details > about its cut operator. However, I would really encourage you to read > The Reasoned Schemer, which is where that code came from. > > I'm also intending to change it to use Fogus' unifier when I get home. > > Jim > > On Nov 3, 8:14 am, Sunil S Nandihalli > wrote: > > Hi Konrad, > > It is really nice .. But I was wondering if it had a cut operator or > > predicate .. similar to '!' in prolog.. > > Thanks, > > Sunil. > > > > On Wed, Nov 3, 2010 at 1:20 PM, Sunil S Nandihalli < > > > > sunil.nandiha...@gmail.com> wrote: > > > Thanks Konrad. I will look at it. > > > Sunil > > > > > On Wed, Nov 3, 2010 at 1:08 PM, Konrad Hinsen < > konrad.hin...@fastmail.net>wrote: > > > > >> On 3 Nov 2010, at 06:04, Sunil S Nandihalli wrote: > > > > >> Hello everybody, > > >>> I was wondering if one can code in a way semantically similar to > prolog > > >>> using the backtracking monads.. Has anybody tried it .. ? I did see > the > > >>> tutorial which demonstrates backtracking monads .. > > >>>http://brehaut.net/blog/2010/ghosts_in_the_machine > > > > >> Have a look at this tutorial: > > > > >>http://intensivesystems.net/tutorials/logic_prog.html > > > > >> and get the code that goes with it: > > > > >>http://github.com/jduey/mini-kanren > > > > >> It's not quite full-fledged Prolog, but you can do a lot with it. > > > > >> Konrad. > > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "Clojure" group. > > >> To post to this group, send email to clojure@googlegroups.com > > >> Note that posts from new members are moderated - please be patient > with > > >> your first post. > > >> To unsubscribe from this group, send email to > > >> clojure+unsubscr...@googlegroups.com > > > > > >> For more options, visit this group at > > >>http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A suggestion for the next Conj
I'd really like to meet everybody from IRC and github, but apparently missed some. So perhaps we can have a meet-and-greet session, where folks will stand up and announce their IRC and github nicks! We also need some color coding, as @hiredman could be easily confused with @liebke! @alexyk -- You 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-backtracking-monads .. can it emulate prolog?
On Wed, Nov 3, 2010 at 11:53 AM, Sunil S Nandihalli < sunil.nandiha...@gmail.com> wrote: > thanks Jim for your email. I will try to get my hands on Reasoned Schemer.. > :) > Sunil. > I've been working through it and it's an eye-opening book, particularly for me as I'm not that familiar with Prolog. It's inspired me to download far too many related papers :) Things I find fascinating about miniKanren (just my impressions, I could be off/wrong about all of these): * is only some 317 lines of code! Maxwell's Equations of Logic Programming?! * embedded, allows you mix Functional and Logic Pogramming paradigms - also ditches Prolog syntax * pure relational programming, kind of the way Haskell is purely functional (no cut) * good foundation for building a type-inferencer * amenable to aggressive optimizations (full Kanren seems competitive with mature Prologs) * amenable to parallelization David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-backtracking-monads .. can it emulate prolog?
On Wed, Nov 3, 2010 at 12:38 PM, David Nolen wrote: > On Wed, Nov 3, 2010 at 11:53 AM, Sunil S Nandihalli < > sunil.nandiha...@gmail.com> wrote: > >> thanks Jim for your email. I will try to get my hands on Reasoned >> Schemer.. :) >> Sunil. >> > William Byrd's dissertation, http://gradworks.umi.com/33/80/3380156.html is a great source for context, additional info, prior research, papers, etc. -- You 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: A suggestion for the next Conj
I was thinking that it would be handy if the "badges" next year had space for that. I'd be happy to whip up something to collect the data and print the badges. Chris On Wed, Nov 3, 2010 at 12:35 PM, Alexy Khrabrov wrote: > I'd really like to meet everybody from IRC and github, but apparently missed > some. So perhaps we can have a meet-and-greet session, where folks will > stand up and announce their IRC and github nicks! We also need some color > coding, as @hiredman could be easily confused with @liebke! > > @alexyk > > -- > You 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 > -- | Chris Petrilli | petri...@amber.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A suggestion for the next Conj
Badges could have much bigger font/be more readable, but they are not the only, and not the main thing; a mixer format is, and it should be something deliberate as even random motion over 2 days is not enough to bring all particles next to each other! -- Alexy On Nov 3, 2010, at 12:52 PM, Christopher Petrilli wrote: > I was thinking that it would be handy if the "badges" next year had > space for that. I'd be happy to whip up something to collect the data > and print the badges. > > Chris > > On Wed, Nov 3, 2010 at 12:35 PM, Alexy Khrabrov > wrote: >> I'd really like to meet everybody from IRC and github, but apparently missed >> some. So perhaps we can have a meet-and-greet session, where folks will >> stand up and announce their IRC and github nicks! We also need some color >> coding, as @hiredman could be easily confused with @liebke! >> >> @alexyk >> >> -- >> You 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 >> > > > > -- > | Chris Petrilli > | petri...@amber.org > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You 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: A suggestion for the next Conj
Speed dating at the clojure conj, yay ! (not totally non-sense, really) 2010/11/3 Alexy Khrabrov : > Badges could have much bigger font/be more readable, but they are not the > only, and not the main thing; a mixer format is, and it should be something > deliberate as even random motion over 2 days is not enough to bring all > particles next to each other! > > -- Alexy > > On Nov 3, 2010, at 12:52 PM, Christopher Petrilli wrote: > >> I was thinking that it would be handy if the "badges" next year had >> space for that. I'd be happy to whip up something to collect the data >> and print the badges. >> >> Chris >> >> On Wed, Nov 3, 2010 at 12:35 PM, Alexy Khrabrov >> wrote: >>> I'd really like to meet everybody from IRC and github, but apparently >>> missed some. So perhaps we can have a meet-and-greet session, where folks >>> will stand up and announce their IRC and github nicks! We also need some >>> color coding, as @hiredman could be easily confused with @liebke! >>> >>> @alexyk >>> >>> -- >>> You 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 >>> >> >> >> >> -- >> | Chris Petrilli >> | petri...@amber.org >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A suggestion for the next Conj
Very fast 3 minutes talk could be fun too. Name, nicknames, and what you are using Clojure for. No slides of course. Best, Nicolas. -- You 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: Some questions about Clojure Protocols
On Wed, Nov 3, 2010 at 5:37 AM, Stuart Sierra wrote: > Protocols provide just one thing: polymorphic functions. They are not > intended to provide "type" or hierarchy like Java classes / > interfaces. Well, they also provide a second thing -- a way to bundle multiple functions as something that is required to be implemented together and an easy way to test whether all of those required functions are implemented. So the original poster has a valid point. If you don't always want to require them as a bundle, you get better reuse and composition out of having one protocol per function. But this proliferation of protocols can be a little awkward to manage with the current scheme. -- You 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: From jetty to war?
On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart wrote: > I have nothing but respect for Rails, and I look forward to the day > when Clojure has a comparable system. I sort of have to ask "why?" - what's wrong with using Rails on JRuby for the front end and Clojure for the model? Why are folks so insistent on monolingual systems? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You 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: From jetty to war?
Sean Corfield wrote .. > On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart > wrote: > > I have nothing but respect for Rails, and I look forward to the day > > when Clojure has a comparable system. > > I sort of have to ask "why?" - what's wrong with using Rails on JRuby > for the front end and Clojure for the model? > > Why are folks so insistent on monolingual systems? No idea at all why it's so obsessive :), if a tool offers more comfort than another, well I'll choose the first one. Maybe because I am aging (not sure yet if it's a symptom of a disease or some form of wisdom :). The idea is to not let earlier choices fossilize but keep looking on better alternatives as time passes by. Luc P. > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
most companys i know - i have come around a lot last years - clearly prefer spring to grails because: 1. the integration-aspect is much more important for them than partial productivity win or promise. 2. java is established in their tech portfolio groovy is not clojure is completely out of scope for 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: A suggestion for the next Conj
2010/11/3 nicolas.o...@gmail.com : > Very fast 3 minutes talk could be fun too. interspaced between 2 talks, hmm, interesting ! (but it could have worked for the first conj where we were just 200, but maybe will not work for the next, if we're > 1000 :-) ) > > Name, nicknames, and what you are using Clojure for. > No slides of course. > > Best, > > Nicolas. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A suggestion for the next Conj
Are there any plans on having an edition of the Conj somewhere in europe? If not, I'd like to suggest we have one over here :) U -- You 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 this bug in Google AppEngine, appengine-clj or Clojure itself?
Does anybody know if this fix made it to the released jar? On Oct 17, 12:18 am, Mike Hinchey wrote: > I think it is caused by those 2 clojure bugs (which seem to be the same > thing). You may be able to work around that problem by patching > appengine-clj to hint the method call to be on the public interface: > DatastoreService. > > (defn current-transaction > "Returns the current datastore transaction, or nil if not within a > transaction." [] (.getCurrentTransaction > ^com.google.appengine.api.datastore.DatastoreService > (datastore) nil)) -- You 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: Resources on optimizing Clojure code
Sorry for the delayed response. OK... here's an example; my solution to problem 187: (defn divides? [n d] (zero? (rem n d)) ) (declare prime? prime-seq) (defn prime? [n] (if (< n 2) false (every? #(not (divides? n %)) (take-while #(<= (* % %) n) prime- seq))) ) (def prime? (memoize prime?)) (def prime-seq (lazy-seq (concat '(2 3 5 7) (filter #(prime? %) (map #(+ (* 2 %) 7) (iterate inc 1) ) (defn factorize [n] (loop [test-primes prime-seq tmp n retval '()] (if (= 1 tmp) retval (if (prime? tmp) (concat retval (list tmp)) (let [p (first test-primes)] (if (divides? tmp p) (recur test-primes (quot tmp p) (concat retval (list p))) (recur (rest test-primes) tmp retval)) ) (defn twice-composite? [n] (= 2 (count (factorize n))) ) (count (filter twice-composite? (range 1 30))) This appears to be correct, since I get the answer 10 for this one case. However, trying to run for n<10^6 takes 6-11 seconds, and for 10^7 at least three minutes, so running for 10^8 is like going to take on the order of hours. I know that my prime number generator is nowhere near optimal, and I know that in order to efficiently solve a lot of the Euler problems, you cannot simply brute force them; you need to choose your algorithm wisely. Anyway... any suggestions would be greatly appreciated. dan kefford On Nov 2, 4:52 pm, Alan wrote: > Usually it's more about the algorithm than the language. Java can > generally do things faster than clojure, simply because it has fewer > layers, but the speedup is a linear factor. If the java solution for > 1000 elements takes 5ms and your clojure code takes even a second, > it's likely that clojure isn't to blame. Maybe you could post one of > your solutions, or simply compare it to a java solution yourself? > > On Nov 2, 10:32 am, Dan Kefford wrote: > > > Hello fellow clojurians... > > > I've been using Clojure now fairly regularly for the past two months > > solving problems on Project Euler. I've been fairly successful solving > > them but there are times where the performance of my code either > > stinks (the answer may come back in 5-10 minutes) or not at all even > > though I have effectively solved the problem (the code is correct and > > will return the answer for n < 1000 but for n < 10^8... forget about > > it.) > > > My question is: are there any materials out there on how to optimize > > performance of Clojure code? There doesn't seem to be a lot out there. > > > Thanks in advance, > > > dan kefford -- You 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: Resources on optimizing Clojure code
Your Clojure implementation of your particular approach is reasonable, but you need a cleverer approach. I'll send you a hint offline. -- You 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: From jetty to war?
I have no problem at all with polyglot systems. That said, Clojure, as a general-purpose programming language, is in my subjective opinion superior to Ruby. Furthermore, there is nothing special about Ruby that makes it particularly suited to webapps (MVC webapps, perhaps, but MVC is not the only paradigm) As such, I expect and would welcome an eventual Clojure web framework with the same level of polish and stability as Rails. I don't mind polyglot programming, but one-language programming is easier. Plus, I just like working in Clojure. I don't think that's unreasonable, is it? Development platforms are not a zero-sum game. Just because I work on/prefer a Clojure framework to a Ruby one doesn't mean I'm trying to insult or belittle Rails. On Nov 3, 1:43 pm, Sean Corfield wrote: > On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart > > wrote: > > I have nothing but respect for Rails, and I look forward to the day > > when Clojure has a comparable system. > > I sort of have to ask "why?" - what's wrong with using Rails on JRuby > for the front end and Clojure for the model? > > Why are folks so insistent on monolingual systems? > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. --http://getrailo.com/ > An Architect's View --http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood -- You 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: Resources on optimizing Clojure code
One idea that I had was to inline the factoring logic into twice- composite. Who cares about the factors? We just want to know if there are two or not: (defn twice-composite? [n] (loop [ps prime-seq tmp n p-count 0] (if (< 2 p-count) false (if (= 1 tmp) (= 2 p-count) (let [p (first ps)] (if (divides? tmp p) (recur ps (quot tmp p) (inc p-count)) (recur (rest ps) tmp p-count)) ) But this lead to even slower code. On Nov 3, 2:15 pm, Mark Engelberg wrote: > Your Clojure implementation of your particular approach is reasonable, > but you need a cleverer approach. I'll send you a hint offline. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure coalesce function at SO with monads - help's needed
Hi, When I stumbled upon the question "Clojure coalesce function" at StackOverflow today, I saw a place for "reverted" maybe-m and sequence-m monads. It seemed to have been easy, but turned out not. I can't figure out how to use monads for the task at hand. Could someone point me into a right direction? Here's what I've figured out so far. (with-monad identity-m (defn coalesce [& xs] (m-until #(not (nil? (first %))) rest xs))) It doesn't return the first non-nil value, but merely starts with one and moves on if there're more forms in xs. Somehow I feel it's the usecase for monads, but without help chances are I won't find the solution. [1] http://stackoverflow.com/questions/4086889/clojure-coalesce-function Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- You 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 on Javascript
On Fri, Oct 29, 2010 at 21:32, Michael Gardner wrote: > Agreed. What is the point of Javascript on the server side? Familiarity? > Consistency with client-side code? > I guess what Java was meant to be, to some degree? "Write once run anywhere". I for one am still hankering for a great way to write code that can run in both the JVM and the client-side JS-vm; this code must understand the DOM which is often not the case on the server side. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Constructing Nested Trees and Memory Consumption
Hi,
I've been playing around with breaking apart a list of postal codes to
be stored in a tree with leaf nodes containing information about that
area. I have some code that works with medium-ish size inputs but
fails with a GC Overhead error with larger input sets (1.5m rows) and
would really appreciate anyone being able to point me in the right
direction.
The full code is up as a gist here: https://gist.github.com/661278
My input file contains something like:
SW1A 1,10
SW1A 2,20
...
Which are then mapped to 2 trees:
{"S" {"W" {"1" {"A" {"1" 10}
{"S" {"W" {"1" {"A" {"2" 20}
I then want to continually fold those trees into a master tree. For
the 2 maps above the merged tree would be:
{"S" {"W" {"1" {"A" {"1" 10 "2" 20}
I'm sure I'm missing all kinds of awesome core/contrib functions to
make it more concise and would appreciate anyone pointing out
alternatives also.
The main problem is that it fails when my input data gets sufficiently
large. On my MacBook Pro it falls over with an input set of 1.5m
records (although a lot of these would be branches from the first few
levels). It reports GC Overhead limit exceeded, although also ran out
of heap size before I upped that.
I assume this is because during the tree reduction it's still
retaining references to nodes eventually causing it to build
continually larger structures?
I've included the reduce function (and how that gets called to produce
results) inline:
(defn merge-tree
[tree other]
(if (not (map? other))
tree
(merge-with (fn [x y] (merge-tree x y))
tree other)))
(def results (reduce merge-tree
{}
(map record-to-tree
postcodes-from-file)))
All help much appreciated,
Paul
--
You 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: From jetty to war?
> Why are folks so insistent on monolingual systems? This was/is one of the original selling points and philosophies of Rails - a monolingual system should mean less context switching, less glue code for things to talk to each other, fewer bugs and mistakes stemming from uniformity of language, and better "flow" to the programming. Thanks, Peter -Original Message- From: lprefonta...@softaddicts.ca Sender: clojure@googlegroups.com Date: Wed, 03 Nov 2010 13:52:13 To: Reply-To: clojure@googlegroups.com Subject: Re: From jetty to war? Sean Corfield wrote .. > On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart > wrote: > > I have nothing but respect for Rails, and I look forward to the day > > when Clojure has a comparable system. > > I sort of have to ask "why?" - what's wrong with using Rails on JRuby > for the front end and Clojure for the model? > > Why are folks so insistent on monolingual systems? No idea at all why it's so obsessive :), if a tool offers more comfort than another, well I'll choose the first one. Maybe because I am aging (not sure yet if it's a symptom of a disease or some form of wisdom :). The idea is to not let earlier choices fossilize but keep looking on better alternatives as time passes by. Luc P. > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A suggestion for the next Conj
I agree about the "speed dating" concept or something to have each of us talk at least once with everyone else (as long as the group size is feasible). We mostly all groan at these ice breaker type activities but they do tend to work ok at getting people in larger groups to interact at least on that initial surface level. Thanks, Peter -Original Message- From: Laurent PETIT Sender: clojure@googlegroups.com Date: Wed, 3 Nov 2010 18:16:02 To: Reply-To: clojure@googlegroups.com Subject: Re: A suggestion for the next Conj Speed dating at the clojure conj, yay ! (not totally non-sense, really) 2010/11/3 Alexy Khrabrov : > Badges could have much bigger font/be more readable, but they are not the > only, and not the main thing; a mixer format is, and it should be something > deliberate as even random motion over 2 days is not enough to bring all > particles next to each other! > > -- Alexy > > On Nov 3, 2010, at 12:52 PM, Christopher Petrilli wrote: > >> I was thinking that it would be handy if the "badges" next year had >> space for that. I'd be happy to whip up something to collect the data >> and print the badges. >> >> Chris >> >> On Wed, Nov 3, 2010 at 12:35 PM, Alexy Khrabrov >> wrote: >>> I'd really like to meet everybody from IRC and github, but apparently >>> missed some. So perhaps we can have a meet-and-greet session, where folks >>> will stand up and announce their IRC and github nicks! We also need some >>> color coding, as @hiredman could be easily confused with @liebke! >>> >>> @alexyk >>> >>> -- >>> You 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 >>> >> >> >> >> -- >> | Chris Petrilli >> | petri...@amber.org >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Spit is core now. How to append?
Clojuredocs mentioned that opts could be passed to clojure.java.io/ Writer, but (little Java background), I'm having a hard time figuring out what the analog to "options" is in the Java API. Any help? Thanks, -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: From jetty to war?
On Wed, Nov 3, 2010 at 10:59 AM, wrote: > This was/is one of the original selling points and philosophies of Rails - a > monolingual system should mean less context switching, less glue code for > things to talk to each other, fewer bugs and mistakes stemming from > uniformity of language, and better "flow" to the programming. Well, that's one of the selling points of any full stack framework in any language (and, as you can probably guess, I don't buy it :) My experience is that full stack frameworks get you quickly to a part-way solution but the closer you get to your full solution, you harder you have to work against the framework to make progress. A discussion about frameworks came up on one of the XP lists a while back and the feeling was that micro-frameworks are much better - more agile - than full-stack frameworks, and that's something I agree with. Anyway, I think we're a long way off topic for the OP / question now... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Constructing Nested Trees and Memory Consumption
On Wed, Nov 3, 2010 at 12:22 PM, Paul Ingles wrote: > (defn merge-tree > [tree other] > (if (not (map? other)) >tree >(merge-with (fn [x y] (merge-tree x y)) >tree other))) > You can get rid of the anonymous function here and just do (merge-with merge-tree tree other). That shouldn't be the cause of your problem, though. -- You 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: A suggestion for the next Conj
Another possibility is to have something online, based on registration, that let's people write a little bit about themselves and offers tags or some such so attendees can find interesting / similar (or different!) people to meet. I've used such networking apps at a couple of conferences but I don't know if they're free... As attendee numbers grow, face-to-face interaction with _everyone_ becomes really hard to manage and even an ice breaker evening doesn't let you get to meet everyone... On Wed, Nov 3, 2010 at 11:05 AM, wrote: > I agree about the "speed dating" concept or something to have each of us talk > at least once with everyone else (as long as the group size is feasible). We > mostly all groan at these ice breaker type activities but they do tend to > work ok at getting people in larger groups to interact at least on that > initial surface level. -- You 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: Spit is core now. How to append?
I figured it out; if anyone has trouble with this in the future and Googles this, it's done by (spit f content :append true) On Nov 3, 1:57 pm, Daniel Bell wrote: > Clojuredocs mentioned that opts could be passed to clojure.java.io/ > Writer, but (little Java background), I'm having a hard time figuring > out what the analog to "options" is in the Java API. Any help? > > Thanks, -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: From jetty to war?
Sean Corfield wrote .. > Why are folks so insistent on monolingual systems? We're facing that now, and with a mono-lingual system, you know everyone can contribute to any part of the project. If different parts are in different languages, then people working in one area won't necessarily be able to help with other parts should they need the help. Of course, what you're calling "insistent" is just people wanting to the frameworks to exist so they *can* do that, not really insisting that some current system be monolingual in spite of that lack. Even the above (admittedly minor) advantage to monolingual systems is enough to justify wanting those frameworks even while you're building multilingual systems. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Resources on optimizing Clojure code
All the time spent factoring is wasted. You can *construct* and/or count the semiprimes far more efficiently than your method of factoring each number one a time in order to filter the semiprimes from the entire range of numbers up to 10^8. Your approach is fundamentally slow; this has nothing to do with Clojure. I sent you more hints privately. -- You 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: From jetty to war?
On Wed, Nov 3, 2010 at 3:31 PM, Mike Meyer wrote: > We're facing that now, and with a mono-lingual system, you know > everyone can contribute to any part of the project. If different parts > are in different languages, then people working in one area won't > necessarily be able to help with other parts should they need the > help. Solution: don't have monolingual programmers on your team :) I do understand the forces at play here. I've worked with a lot of monolingual teams and seen these same discussions about wishing we had framework X from language Y. I just cringe at the work invested in recreating all these frameworks in so many languages - especially when we're (nearly) all on the same JVM and we _could_ leverage these other languages / frameworks as-is. It just seems like so much wasted effort :( I'll shut up about this now... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You 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: to macro or not?
For writing DSLs, consider the excellent speak of cgrand at the conj : (not= DSL macros) Here are the slides: http://speakerrate.com/talks/4895-not-dsl-macros Yes, I saw the slides. I disagree with the speaker, at least, from what I could see from the slides. If you could argument more, this could be the start of an interesting thread ... The arguments seems to be that 1) DSLs are not general purpose or turing complete That depends. Axiom had an internal DSL that was basically a sugar-coated lisp with a python-like syntax. It was both general purpose and turing complete. A large portion of the DSL was implemented in macros. 2) Users don't want a DSL In work my users want a DSL. It enable them to write their specifications in their language. I do a trivial paren-shift (since they write F(x) rather than (F x)) and I can implement their specification directly using macros. The macros are context sensitive so they expand differently in different environments. I generate XML, assembler, and lisp using the F macro. This allows me to communicate directly to my users because they hardly notice the paren-shift. We can be sure that the DSL statements match the spec. In another project I modified the lisp readtable so that, with a combination of macros, the user could write python-like surface syntax and lisp could read and execute it without a parser. The user did not know the implementation was lisp. Macros allowed me to rewrite the "parse tree" so it expanded into proper lisp. In either case you could argue that "users did not know they were using a DSL so they couldn't have wanted it". However, a DSL is an implementation technique rather than something users would want. 3) macros add complexity I'm at a complete loss to explain this. I use macros like (with-open-file, (while-protected, (maybe, (destructure, (spadcall, (seq, (lazy-eval, and many more to encapsulate useful control structure. For example, the seq macro allows an early exit from deeply nested code, essentially being a well-shaped goto. The spadcall macro encapsulates a compile time lookup in a static table and rewriting its argument to insert fixed integer array indexes turning an apparent function call into an array lookup. A "send" macro on a uniprocessor compiles to a stack push but on a multicore it compiles to a protected message queue append. A well-chosen set of macros can create and support any special kind of programming paradigm such as object-oriented, aspect-oriented, message-passing, blackboarding, pattern-matching, and any other idea that you like. If you're a Java programmer you could write a "with-singleton" macro, or many other types of macros that support the Booch "patterns" (why a lisper would WANT to support Booch patterns is beyond me but...). Macros, used properly, give amazing power, clarity, and flexibilty. I've been writing them for many years. I have never met a native Lisp programmer who would have created the slide deck I saw. Native Java programmers have no equivalent construct to macros (no, decorations are not macros) so they would find macros complex, limited, and obscure. Tim Daly -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Constructing Nested Trees and Memory Consumption
I could be missing something, but since you say you're running into
problems as your data gets large, I think you're possibly running into
2 things:
1. You're reading all the data into memory, and keeping it there, in
the form of the lines from the file.
2. The way you're defining postcodes-from-file results in holding on
to the head of the sequence, meaning parts of the sequence that aren't
being used anymore can't be garbage collected. You probably want to
make this into a function rather than a def, so that it gets created
when you invoke the function, but not bound anywhere that causes it to
be a gc root.
Does that make sense?
On Nov 3, 9:22 am, Paul Ingles wrote:
> Hi,
>
> I've been playing around with breaking apart a list of postal codes to
> be stored in a tree with leaf nodes containing information about that
> area. I have some code that works with medium-ish size inputs but
> fails with a GC Overhead error with larger input sets (1.5m rows) and
> would really appreciate anyone being able to point me in the right
> direction.
>
> The full code is up as a gist here:https://gist.github.com/661278
>
> My input file contains something like:
>
> SW1A 1,10
> SW1A 2,20
> ...
>
> Which are then mapped to 2 trees:
>
> {"S" {"W" {"1" {"A" {"1" 10}
> {"S" {"W" {"1" {"A" {"2" 20}
>
> I then want to continually fold those trees into a master tree. For
> the 2 maps above the merged tree would be:
>
> {"S" {"W" {"1" {"A" {"1" 10 "2" 20}
>
> I'm sure I'm missing all kinds of awesome core/contrib functions to
> make it more concise and would appreciate anyone pointing out
> alternatives also.
>
> The main problem is that it fails when my input data gets sufficiently
> large. On my MacBook Pro it falls over with an input set of 1.5m
> records (although a lot of these would be branches from the first few
> levels). It reports GC Overhead limit exceeded, although also ran out
> of heap size before I upped that.
>
> I assume this is because during the tree reduction it's still
> retaining references to nodes eventually causing it to build
> continually larger structures?
>
> I've included the reduce function (and how that gets called to produce
> results) inline:
>
> (defn merge-tree
> [tree other]
> (if (not (map? other))
> tree
> (merge-with (fn [x y] (merge-tree x y))
> tree other)))
>
> (def results (reduce merge-tree
> {}
> (map record-to-tree
> postcodes-from-file)))
>
> All help much appreciated,
> Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Constructing Nested Trees and Memory Consumption
Why not just sort the text file and then build the merged trees
directly, without the numerous intermediate trees?
On Wed, Nov 3, 2010 at 12:22 PM, Paul Ingles wrote:
> Hi,
>
> I've been playing around with breaking apart a list of postal codes to
> be stored in a tree with leaf nodes containing information about that
> area. I have some code that works with medium-ish size inputs but
> fails with a GC Overhead error with larger input sets (1.5m rows) and
> would really appreciate anyone being able to point me in the right
> direction.
>
> The full code is up as a gist here: https://gist.github.com/661278
>
> My input file contains something like:
>
> SW1A 1,10
> SW1A 2,20
> ...
>
> Which are then mapped to 2 trees:
>
> {"S" {"W" {"1" {"A" {"1" 10}
> {"S" {"W" {"1" {"A" {"2" 20}
>
> I then want to continually fold those trees into a master tree. For
> the 2 maps above the merged tree would be:
>
> {"S" {"W" {"1" {"A" {"1" 10 "2" 20}
>
> I'm sure I'm missing all kinds of awesome core/contrib functions to
> make it more concise and would appreciate anyone pointing out
> alternatives also.
>
> The main problem is that it fails when my input data gets sufficiently
> large. On my MacBook Pro it falls over with an input set of 1.5m
> records (although a lot of these would be branches from the first few
> levels). It reports GC Overhead limit exceeded, although also ran out
> of heap size before I upped that.
>
> I assume this is because during the tree reduction it's still
> retaining references to nodes eventually causing it to build
> continually larger structures?
>
> I've included the reduce function (and how that gets called to produce
> results) inline:
>
> (defn merge-tree
> [tree other]
> (if (not (map? other))
> tree
> (merge-with (fn [x y] (merge-tree x y))
> tree other)))
>
> (def results (reduce merge-tree
> {}
> (map record-to-tree
> postcodes-from-file)))
>
> All help much appreciated,
> Paul
>
> --
> You 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
--
Cheers,
Leif
--
You 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: Resources on optimizing Clojure code
If you want to do this, you can do it simpler, without the loop and temp var: (defn twice-composite? [n] (->> (take-while #(< % n) prime-seq) (every #(or (divides? (* 2 %) n) (not (divides? % n but this is not what you want. See the hints I sent you off the list. On Wed, Nov 3, 2010 at 2:34 PM, Dan Kefford wrote: > One idea that I had was to inline the factoring logic into twice- > composite. Who cares about the factors? We just want to know if there > are two or not: > > (defn twice-composite? [n] > (loop [ps prime-seq > tmp n > p-count 0] > (if (< 2 p-count) > false > (if (= 1 tmp) > (= 2 p-count) > (let [p (first ps)] > (if (divides? tmp p) > (recur ps (quot tmp p) (inc p-count)) > (recur (rest ps) tmp p-count)) > ) > > But this lead to even slower code. > > On Nov 3, 2:15 pm, Mark Engelberg wrote: >> Your Clojure implementation of your particular approach is reasonable, >> but you need a cleverer approach. I'll send you a hint offline. > > -- > You 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 -- Cheers, Leif -- You 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: A suggestion for the next Conj
I really like this idea. On Wed, Nov 3, 2010 at 1:16 PM, Laurent PETIT wrote: > Speed dating at the clojure conj, yay ! (not totally non-sense, really) > > 2010/11/3 Alexy Khrabrov : > > Badges could have much bigger font/be more readable, but they are not the > only, and not the main thing; a mixer format is, and it should be something > deliberate as even random motion over 2 days is not enough to bring all > particles next to each other! > > > > -- Alexy > > > > On Nov 3, 2010, at 12:52 PM, Christopher Petrilli wrote: > > > >> I was thinking that it would be handy if the "badges" next year had > >> space for that. I'd be happy to whip up something to collect the data > >> and print the badges. > >> > >> Chris > >> > >> On Wed, Nov 3, 2010 at 12:35 PM, Alexy Khrabrov > >> wrote: > >>> I'd really like to meet everybody from IRC and github, but apparently > missed some. So perhaps we can have a meet-and-greet session, where folks > will stand up and announce their IRC and github nicks! We also need some > color coding, as @hiredman could be easily confused with @liebke! > >>> > >>> @alexyk > >>> > >>> -- > >>> You 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 > >>> > >> > >> > >> > >> -- > >> | Chris Petrilli > >> | petri...@amber.org > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure application in the wild, to learn beautiful Clojure technique(s) from
Try ants demo - https://github.com/krukow/ants-demo. It's an updated version of the original Rich Hickey demo. On Sun, Oct 31, 2010 at 9:13 PM, Alex Baranosky < alexander.barano...@gmail.com> wrote: > Thanks for these applications to look at. These look nice, but don't have > much use for STM. > > Do you know of any applications that make a lot of use of Software > Transactional Memory? > > > -- You 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: A suggestion for the next Conj
We could set up a web app that uses data mining algorithms to analyze people's interests, experience with Clojure, industries they work in, Myers-Briggs type, and other information to put together compatible small groups of people. I just had a "How big of a nerd can I be?" moment. But that doesn't mean its not a good idea. On Nov 3, 4:56 pm, Sean Corfield wrote: > Another possibility is to have something online, based on > registration, that let's people write a little bit about themselves > and offers tags or some such so attendees can find interesting / > similar (or different!) people to meet. I've used such networking apps > at a couple of conferences but I don't know if they're free... > > As attendee numbers grow, face-to-face interaction with _everyone_ > becomes really hard to manage and even an ice breaker evening doesn't > let you get to meet everyone... > > > > > > > > On Wed, Nov 3, 2010 at 11:05 AM, wrote: > > I agree about the "speed dating" concept or something to have each of us > > talk at least once with everyone else (as long as the group size is > > feasible). We mostly all groan at these ice breaker type activities but > > they do tend to work ok at getting people in larger groups to interact at > > least on that initial surface level. -- You 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: A question on distributed computing
Hi Vivek, thanks for the info on the Cornell projects. (- jiff f) [2] Fabric: a federated, distributed system for securely and reliably storing, sharing, and computing information. http://www.cs.cornell.edu/projects/fabric/ The Fabric programming language is based on Jif. [1] Jif: Java + information flow http://www.cs.cornell.edu/jif/ On Nov 3, 4:04 pm, Vivek Khurana wrote: > On Nov 2, 8:56 pm, Ken Wesson wrote: > > > That seems impossible assuming you don't trust the software running on the > > other node. > > It is not impossible. There are projects by Cornell .University, > jiff[1] and fabric[2] which have achieved the same. Jiff is > modification of java and fabric is based on jiff.Both languages run > inside JVM. So I was wondering if it is possible to add some kind of > access control policy on clojure code, via an extension or as language > feature ? > > regards > Vivek -- You 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: From jetty to war?
btw.: me too has great respect for ruby/rails one of the nice aspects of clojure is, that multiple currents and flavours of modern programming accumulate/reconvene in there. like evolution. diversity is good. it produces its own power and controversy. my fazit: clojure has great potential for webapp-development. but atm many libs/tools are in an early state or missing. this situation will improve/clear up over the years ... -- You 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
Reloading java classes
Is it possible to reload modified classes? I would likely to quickly test my java classes with 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: Constructing Nested Trees and Memory Consumption
In addition to this, note that every java.lang.String, i.e. every "A"
in your example data structures below, requires storage for one
java.lang.Object (8 bytes on 32-bit JVMs, 16 bytes on 64-bit JVMs)
plus an array of java char's, where I think that is equal to the size
of a java.lang.Object plus 2 bytes for each char.
So "A" requires 8+8+2=18 bytes on a 32-bit JVM (perhaps more with
padding of these objects for memory alignment purposes), or 16+16+2=34
bytes on a 64-bit JVM (again, perhaps more with padding). That is
before taking into account the memory required for Clojure sets.
I'd recommend changing your code to use Java chars instead of single-
char Java strings. That plus the change Paul suggests below should
reduce memory consumption significantly.
Andy
On Nov 3, 2010, at 5:26 PM, Paul Mooser wrote:
I could be missing something, but since you say you're running into
problems as your data gets large, I think you're possibly running into
2 things:
1. You're reading all the data into memory, and keeping it there, in
the form of the lines from the file.
2. The way you're defining postcodes-from-file results in holding on
to the head of the sequence, meaning parts of the sequence that aren't
being used anymore can't be garbage collected. You probably want to
make this into a function rather than a def, so that it gets created
when you invoke the function, but not bound anywhere that causes it to
be a gc root.
Does that make sense?
On Nov 3, 9:22 am, Paul Ingles wrote:
Hi,
I've been playing around with breaking apart a list of postal codes
to
be stored in a tree with leaf nodes containing information about that
area. I have some code that works with medium-ish size inputs but
fails with a GC Overhead error with larger input sets (1.5m rows) and
would really appreciate anyone being able to point me in the right
direction.
The full code is up as a gist here:https://gist.github.com/661278
My input file contains something like:
SW1A 1,10
SW1A 2,20
...
Which are then mapped to 2 trees:
{"S" {"W" {"1" {"A" {"1" 10}
{"S" {"W" {"1" {"A" {"2" 20}
I then want to continually fold those trees into a master tree. For
the 2 maps above the merged tree would be:
{"S" {"W" {"1" {"A" {"1" 10 "2" 20}
I'm sure I'm missing all kinds of awesome core/contrib functions to
make it more concise and would appreciate anyone pointing out
alternatives also.
The main problem is that it fails when my input data gets
sufficiently
large. On my MacBook Pro it falls over with an input set of 1.5m
records (although a lot of these would be branches from the first few
levels). It reports GC Overhead limit exceeded, although also ran out
of heap size before I upped that.
I assume this is because during the tree reduction it's still
retaining references to nodes eventually causing it to build
continually larger structures?
I've included the reduce function (and how that gets called to
produce
results) inline:
(defn merge-tree
[tree other]
(if (not (map? other))
tree
(merge-with (fn [x y] (merge-tree x y))
tree other)))
(def results (reduce merge-tree
{}
(map record-to-tree
postcodes-from-file)))
All help much appreciated,
Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Reloading java classes
On Nov 3, 2010, at 9:24 PM, Seth wrote: > Is it possible to reload modified classes? I would likely to quickly > test my java classes with clojure. http://www.zeroturnaround.com/jrebel/ Used to have a free, um, Scala license too... -- Alexy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Constructing Nested Trees and Memory Consumption
On Nov 3, 2010, at 8:31 PM, Andy Fingerhut wrote: > I'd recommend changing your code to use Java chars instead of single-char > Java strings. That plus the change Paul suggests below should reduce memory > consumption significantly. Another option is to .intern() the strings. You'll still create lots of garbage while reading the input file, though. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Constructing Nested Trees and Memory Consumption
Check out assoc-in, get-in, and update-in. They make working with
nested maps a breeze. Here's a rewrite of your code:
(ns user
(:require [clojure.string :as str]
[clojure.java.io :as io]))
(def postcode-trie
(with-open [r (io/reader "/path/to/data.csv")]
(reduce
(fn [trie line]
(let [[postcode region] (.split line ",")
postcode (str/replace postcode " " "")]
(assoc-in trie postcode region)))
{}
(line-seq r
(get-in postcode-trie "SW1A2")
;; => "20"
This stores keys of the tree (trie) as characters instead of strings,
which lets you use get-in easily.
Using line-seq might help mitigate unnecessary memory usage, though as
Andy mentions, Java objects just carry a lot of baggage.
Justin
On Nov 3, 12:22 pm, Paul Ingles wrote:
> Hi,
>
> I've been playing around with breaking apart a list of postal codes to
> be stored in a tree with leaf nodes containing information about that
> area. I have some code that works with medium-ish size inputs but
> fails with a GC Overhead error with larger input sets (1.5m rows) and
> would really appreciate anyone being able to point me in the right
> direction.
>
> The full code is up as a gist here:https://gist.github.com/661278
>
> My input file contains something like:
>
> SW1A 1,10
> SW1A 2,20
> ...
>
> Which are then mapped to 2 trees:
>
> {"S" {"W" {"1" {"A" {"1" 10}
> {"S" {"W" {"1" {"A" {"2" 20}
>
> I then want to continually fold those trees into a master tree. For
> the 2 maps above the merged tree would be:
>
> {"S" {"W" {"1" {"A" {"1" 10 "2" 20}
>
> I'm sure I'm missing all kinds of awesome core/contrib functions to
> make it more concise and would appreciate anyone pointing out
> alternatives also.
>
> The main problem is that it fails when my input data gets sufficiently
> large. On my MacBook Pro it falls over with an input set of 1.5m
> records (although a lot of these would be branches from the first few
> levels). It reports GC Overhead limit exceeded, although also ran out
> of heap size before I upped that.
>
> I assume this is because during the tree reduction it's still
> retaining references to nodes eventually causing it to build
> continually larger structures?
>
> I've included the reduce function (and how that gets called to produce
> results) inline:
>
> (defn merge-tree
> [tree other]
> (if (not (map? other))
> tree
> (merge-with (fn [x y] (merge-tree x y))
> tree other)))
>
> (def results (reduce merge-tree
> {}
> (map record-to-tree
> postcodes-from-file)))
>
> All help much appreciated,
> Paul
--
You 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: Bug with instance? inside deftypes
>> I would guess the problem is referring to T inside the deftype. This also works: (deftype T [] Object (equals [this o] (if (= T (class o)) true false))) But as Meikel said hope that this is not the end of the story. -- You 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: From jetty to war?
On Wed, 3 Nov 2010 16:26:13 -0700 Sean Corfield wrote: > On Wed, Nov 3, 2010 at 3:31 PM, Mike Meyer > wrote: > > We're facing that now, and with a mono-lingual system, you know > > everyone can contribute to any part of the project. If different parts > > are in different languages, then people working in one area won't > > necessarily be able to help with other parts should they need the > > help. > Solution: don't have monolingual programmers on your team :) What, we shouldn't hire Americans? :-) That only helps if everyone actually knows all the languages involved (we're looking at Ruby, Python and I'm trying to make a case for Clojure - but the critical language for my part of it is going to be XPath and/or XQuery). Finding good people is hard enough that wanting them to be good in three or four languages is enough to break the camels back. If you've got time to cross-train them - then you don't need > I do understand the forces at play here. I've worked with a lot of > monolingual teams and seen these same discussions about wishing we had > framework X from language Y. I just cringe at the work invested in > recreating all these frameworks in so many languages - especially when > we're (nearly) all on the same JVM and we _could_ leverage these other > languages / frameworks as-is. It just seems like so much wasted effort Except (in least in this case) some of the languages aren't on the JVM. In fact, I'm starting to get pressure against Jython and Clojure because of the legal mess that's starting to embroil the Java world. Way off topic, but anyone got any advice on *that*? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some questions about Clojure Protocols
> AFAIK, it is not possible. You must implement all the different protocols. > It might look desapointing, but on the other hand it is not necessary. > (As there is no static typing in Clojure) > What is your use-case? Current use case is that I want an abstraction which comprises of a set of operations I want + Comparable + Serializable > Just define types that extend all the protocols. > You can't. But you can define a type that extends both P and Comparable. Currently I'm struggling with the following problem - Suppose I consider something satisfying 'Coolness' property if it does x, y, z + is comparable + serializes. To do this I create a protocol 'OnlyHalfCoolness': (defprotocol OnlyHalfCooless x y z) and two deftypes Cool1, Cool2: (deftype Cool1 ... OnlyHalfCoolness .. Comparable .. Serializable) (deftype Cool2 ... OnlyHalfCoolness .. Comparable .. Serializable) Now I need to write a function: is-this-cool? Instead of (defn is-this-cool? [o] (satisfies? Coolness o)) I need to now write: (defn is-this-cool? [o] (or (instance? Cool1 o) (instance? Cool2 o)) or, (even worse) (defn is-this-cool? [o] (and (satisfies? OnlyHalfCoolness o) (instance? Comparable o) (instance? Serializable o)) A type hierarchy is not required - but I think a way to compose (atleast union) abstractions would be nice. Are there some fundamental problems with - (defprotocol Coolness .. Comparable .. Serializable .. x y z) ? > What do you mean by "static" functions? Normal functions which do not dispatch based on the type of their first argument. Forget about this - thinking more about it - they don't really make too much sense in protocols. -- You 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
*warn-on-reflection* broken in 1.2?
The website has this example: (set! *warn-on-reflection* true) -> true (defn foo [s] (.charAt s 1)) -> Reflection warning, line: 2 - call to charAt can't be resolved. -> #user/foo When I try this in a Clojure 1.2 REPL generated by Enclojure 1.4.0/NB 6.9.1 I don't see the reflection warning in any of Repl, *err*, and *out*. Is this actually broken in Clojure 1.2 or is it Enclojure screwing up? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Constructing Nested Trees and Memory Consumption
One more suggestion: Try simply creating one giant map that maps
complete postal code strings directly to the associated data values,
without any tree data structure explicitly created in your code. The
code will be a lot simpler, and the underlying data structure is
likely to be competitive memory-wise and access-time-wise to the data
structure you are currently using. You can also use a transient map
[1] as long as you are content to limit yourself to a single thread
doing the reading and map construction -- it will be faster than a non-
transient map. I suspect it might generate somewhat less garbage
needing collection while you are building it, too.
[1] see http://clojure.org/transients
Andy
On Nov 3, 2010, at 6:31 PM, Andy Fingerhut wrote:
In addition to this, note that every java.lang.String, i.e. every
"A" in your example data structures below, requires storage for one
java.lang.Object (8 bytes on 32-bit JVMs, 16 bytes on 64-bit JVMs)
plus an array of java char's, where I think that is equal to the
size of a java.lang.Object plus 2 bytes for each char.
So "A" requires 8+8+2=18 bytes on a 32-bit JVM (perhaps more with
padding of these objects for memory alignment purposes), or
16+16+2=34 bytes on a 64-bit JVM (again, perhaps more with
padding). That is before taking into account the memory required
for Clojure sets.
I'd recommend changing your code to use Java chars instead of single-
char Java strings. That plus the change Paul suggests below should
reduce memory consumption significantly.
Andy
On Nov 3, 2010, at 5:26 PM, Paul Mooser wrote:
I could be missing something, but since you say you're running into
problems as your data gets large, I think you're possibly running
into
2 things:
1. You're reading all the data into memory, and keeping it there, in
the form of the lines from the file.
2. The way you're defining postcodes-from-file results in holding on
to the head of the sequence, meaning parts of the sequence that
aren't
being used anymore can't be garbage collected. You probably want to
make this into a function rather than a def, so that it gets created
when you invoke the function, but not bound anywhere that causes it
to
be a gc root.
Does that make sense?
On Nov 3, 9:22 am, Paul Ingles wrote:
Hi,
I've been playing around with breaking apart a list of postal
codes to
be stored in a tree with leaf nodes containing information about
that
area. I have some code that works with medium-ish size inputs but
fails with a GC Overhead error with larger input sets (1.5m rows)
and
would really appreciate anyone being able to point me in the right
direction.
The full code is up as a gist here:https://gist.github.com/661278
My input file contains something like:
SW1A 1,10
SW1A 2,20
...
Which are then mapped to 2 trees:
{"S" {"W" {"1" {"A" {"1" 10}
{"S" {"W" {"1" {"A" {"2" 20}
I then want to continually fold those trees into a master tree. For
the 2 maps above the merged tree would be:
{"S" {"W" {"1" {"A" {"1" 10 "2" 20}
I'm sure I'm missing all kinds of awesome core/contrib functions to
make it more concise and would appreciate anyone pointing out
alternatives also.
The main problem is that it fails when my input data gets
sufficiently
large. On my MacBook Pro it falls over with an input set of 1.5m
records (although a lot of these would be branches from the first
few
levels). It reports GC Overhead limit exceeded, although also ran
out
of heap size before I upped that.
I assume this is because during the tree reduction it's still
retaining references to nodes eventually causing it to build
continually larger structures?
I've included the reduce function (and how that gets called to
produce
results) inline:
(defn merge-tree
[tree other]
(if (not (map? other))
tree
(merge-with (fn [x y] (merge-tree x y))
tree other)))
(def results (reduce merge-tree
{}
(map record-to-tree
postcodes-from-file)))
All help much appreciated,
Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: *warn-on-reflection* broken in 1.2?
I get the expected result in my REPL via SLIME:
user> *clojure-version*
{:major 1, :minor 2, :incremental 0, :qualifier ""}
user> (set! *warn-on-reflection* true)
true
user> (defn foo [s] (.charAt s 1))
Reflection warning, NO_SOURCE_FILE:1 - call to charAt can't be resolved.
#'user/foo
Regards,
Stuart
On 4 November 2010 15:11, Ken Wesson wrote:
> The website has this example:
>
> (set! *warn-on-reflection* true)
> -> true
> (defn foo [s] (.charAt s 1))
> -> Reflection warning, line: 2 - call to charAt can't be resolved.
> -> #user/foo
>
> When I try this in a Clojure 1.2 REPL generated by Enclojure 1.4.0/NB
> 6.9.1 I don't see the reflection warning in any of Repl, *err*, and
> *out*.
>
> Is this actually broken in Clojure 1.2 or is it Enclojure screwing up?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Resources on optimizing Clojure code
If you're looking to generate all the numbers with exactly two prime factors (counting multiplicity), I have clojure code that generates the ones up to 10^8 in under two minutes: com.example.sbox=> (time (count (semiprimes-to 1))) "Elapsed time: 106157.33292 msecs" 41803068 It's single-threaded code running on a 2.5GHz machine, so I didn't achieve this through massive parallelism or running it on a Cray or anything. :) If anyone wants more details or the code itself I can post it or email it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A suggestion for the next Conj
On Wed, Nov 3, 2010 at 7:47 PM, Nick Brown wrote: > We could set up a web app that uses data mining algorithms to analyze > people's interests, experience with Clojure, industries they work in, > Myers-Briggs type, and other information to put together compatible > small groups of people. Or you could leverage Google Buzz or something similar to do all that work for you. :) -- You 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: From jetty to war?
On Wed, Nov 3, 2010 at 8:51 PM, Mike Meyer wrote: >> Solution: don't have monolingual programmers on your team :) > What, we shouldn't hire Americans? :-) Normally that joke is aimed at Brits like me :) > That only helps if everyone actually knows all the languages involved Well, smart people pick up new languages pretty easily and you don't need _experts_ in all those languages to make it work. > Except (in least in this case) some of the languages aren't on the > JVM. In fact, I'm starting to get pressure against Jython and Clojure > because of the legal mess that's starting to embroil the Java > world. Way off topic, but anyone got any advice on *that*? That's an interesting one. In my opinion it's a very paranoid (and uninformed) company that actually thinks they need to worry about *JVM*-based languages. There are multiple JVM implementations and none of the important ones are the subject of litigation. If you're not building Java-based apps for Android, why would they care? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You 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: Some questions about Clojure Protocols
Hi, On 4 Nov., 04:58, ka wrote: > (defprotocol OnlyHalfCooless x y z) > > Instead of > (defn is-this-cool? [o] (satisfies? Coolness o)) > > I need to now write: > (defn is-this-cool? [o] (or (instance? Cool1 o) (instance? Cool2 o)) > or, (even worse) > (defn is-this-cool? [o] (and (satisfies? OnlyHalfCoolness o) > (instance? Comparable o) (instance? Serializable o)) May I ask a heretic question: Why don't you specify the contract in the docstring of the protocol? (defprotocol Coolness "Yadddayaddablablablubber. Cool things have to be Comparable and Serializable." (x ..) (y ...)) If someone doesn't adhere to this contract, it's his program which is broken, not yours. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
