Re: STM criticisms from Bryan Cantrill (Sun)
On Nov 4, 2:15 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > On Nov 4, 3:47 am, "Christian Vest Hansen" <[EMAIL PROTECTED]> > wrote: > > My view is that TMs are another tool in the box, just like CAS, locks, > > agents, volatile, thread-locals, immutables, atomics and all the rest > > of java.util.concurrent. > > Precisely. I agree. However, in pure Java the locks, volatility, immutability, atomics, java.util.concurrent are all accessible and can all interact, e.g., you can create your own synchronizer based on locks and volatiles, combined java.util.concurrent classes. Is this the case in Clojure? In Clojure the locks are not accessible to the user which is generally a good thing. However the 'toolbox argument' is saying: "OK, *sometimes* you do want locks," and saying "STM is no silver bullet so go ahead and use locks in those (rare cases)." Now, I have yet to see an actual example that the STM is not good enough;^1 however, for this particular argument to hold we need to consider how to combine these tools in an actual Clojure application. So really, I am wondering whether it is possible combine all these concurrency tools in a Clojure program. For example you can (from pure Clojure) create a ConcurrentHashMap and hammer on it from different threads -- works out of the box, no need for locks or Java classes. But what about volatiles and acquiring locks? Can you have a decent Clojure program that uses locks in one component, together with STM and agents in others? What about interaction between such components? /krukow ^1 Even STM opponent and concurrency guru Cliff Click seems to be impressed with Clojure ;-) http://blogs.azulsystems.com/cliff/2008/09/jvm-language-su.html Comment: [[ I'm not doing Clojure enough justice here. [...] The purely functional data-structures also look really nice; and the STM scaled surprisingly well. I definitely need to do some coding with it. [...] Cliff ]] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Pathetic n00b wonders how to deploy
On 31 Okt., 04:46, JCB <[EMAIL PROTECTED]> wrote: > 1) does Clojure maintain the CL notion of a "running image" (ACL > terms), or a "core" (sbcl terms)? You can do this with Scriba. Scriba allows you to save a "running image" of a scripting session on the JVM. It does not in particular support Clojure, but I think it can be adapted to any scripting language. And it's open sourced. http://www.kobrix.com/scriba.jsp hth, Robert Pfeiffer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Having struggle in understanding FP (and Clojure question)
Hi, On 5 Nov., 08:31, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > That's exactly my point. Multimethods may well be sufficient or even > superior for implementing OO concepts useful in Clojure. We will see > when someone actually uses them this way (or has it already > happened?). But as long as the most important interfaces (sequences, > maps, numbers), which happen to be the ones also used by the built-in > types, don't use the same mechanism, there will always be first-class > and second-class citizens in Clojure's datatype universe. I don't think that there are first-class and second-class citizens. They just have a different aspect. Having pure Clojure "classes" with multimethods might well be integrated and nice, but you get problems when you have to interface to Java. On the other hand using Java classes gives you easy interface, but you have to live with gen-class. So which one is first, which one second class? I think each solution has just different Pros and Cons. What would interesting, is the question, whether both approaches could be combined. We make a Java class (via gen-class), which gets a default implementation for each method, which references a similar named multimethod instead of the Class-methodName. Clojure "classes" deriving from that class do not provide an a Java method themselves, but register with the multimethod. The Clojure code could use the multimethods, while there are still the methods available for a Java interface. So the downside would be that one can only inherit from one such prototype class (since it needs to be a class, not an interface, for the default implementation of the methods) or one has to respecify the method - multimethod translation in all sub classes. Maybe a modified gen-class could support? (These are just random thoughts. Maybe they make sense, maybe not.) For the built-in datatypes: I implemented nth and get as multimethods (as some kind of proof-of-concept), but Rich was not very interested due to performance issues and the fact, that the datatypes are used internally in very low-level areas. I don't really follow the argument about monkey patching. I think it's not monkey patching at all, since the multimethods only define the interface. So I don't modify a thing which is returned by hash-map. That's still a hash map using the hash-map implementation. - http://clojure-log.n01se.net/date/2008-10-06.html#13:18 Sincerely Meikel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A question about test-is
On Tue, Nov 4, 2008 at 8:47 PM, Chanwoo Yoo <[EMAIL PROTECTED]> wrote: > Thank you for your kind exaplanation. :) To a newbie like me, list and > vector seemed that they have no significant difference. No problem, I think everyone runs into these kinds of issues when they first look at Clojure. However, after spending some time with it, you start to see how deliberate and consistent these choices were. In this case, it would be possible to write assoc so that it handled lists, maybe by having "x" below be the position in the list where to place the new value, but a) you really aren't "assoc"iating anything, because lists don't have keys and b) there are different performance characterstics, assoc on vectors would be O(1) but assoc on lists would be O(N). Rich takes great care in trying to guarantee certain performance characteristics with functions like this, wherever he can. That's one of the reasons we have vectors in the first place, rather than just implementing them on top of lists, because vectors and lists have different performance characteristics and are useful for different things. Please someone correct me if I was off on any of the above, but I hope it's helpful regardless. Regards, - J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Nov 4, 4:37 pm, Matthias Benkard <[EMAIL PROTECTED]> wrote: > > The CPL doesn't allow me to choose the GPL. Instead, it forces me to > apply a CPL-compatible, GPL-like license -- a thing which may or may > not currently exist, but which will certainly make my library useless > to almost everybody because without GPL compatibility, it in turn > forces a non-GPL-compatible license onto my library's users, who will > probably want to make use of GPL-licensed libraries as well as mine. > Are you sure? You're not modifying the clojure source, so you're not creating a derivative work. I would think you can create a GPL licensed library in that case. Anyone who uses your library and distributes the result would have to GPL their work. This has no bearing on the clojure license. It's analagous to claiming that Intel have to GPL their design for the x86 chips that Linux runs on, because Linux itself is GPL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Having struggle in understanding FP (and Clojure question)
On Nov 5, 2008, at 11:12, mb wrote: > I don't think that there are first-class and second-class citizens. > They just have a different aspect. Right, one can't say one is superior to the other. There are just two separate worlds, each having its own characteristics. > Having pure Clojure "classes" with > multimethods might well be integrated and nice, but you get problems > when you have to interface to Java. On the other hand using Java > classes gives you easy interface, but you have to live with gen-class. But does gen-class have to look the way it does? Couldn't the same functionality be provided in a way that looks more like a proper part of the language? > What would interesting, is the question, whether both approaches > could be combined. We make a Java class (via gen-class), which > gets a default implementation for each method, which references > a similar named multimethod instead of the Class-methodName. That sounds like an interesting idea. > For the built-in datatypes: I implemented nth and get as multimethods > (as some kind of proof-of-concept), but Rich was not very interested > due to performance issues and the fact, that the datatypes are used > internally in very low-level areas. I can understand performance arguments, of course. And I don't really want to modify the built-in types in any way, I just want to be able to use the same interfaces in completely independent datatype implementations. The current implementation of nth provides a special implementation for each kind of datatype that it knows about, and fails for unknown types. Shouldn't it be possible to add a default case at the end that calls a Clojure multimethod? That shouldn't have any performance impact on the built-in datatypes. > I don't really follow the argument about monkey patching. I think > it's not monkey patching at all, since > the multimethods only define the interface. I agree. It's no more monkey-patching than any use of multimethods would be monkey-patching. 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Having struggle in understanding FP (and Clojure question)
Hi, On 5 Nov., 15:40, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > But does gen-class have to look the way it does? Couldn't the same > functionality be provided in a way that looks more like a proper part > of the language? I'm not sure about the form itself. I had look at a CLOS tutorial and that defclass doesn't look to different in the form the function is called, a mix of keywords and arguments. My main concern with gen-class is that it doesn't use the namespace itself. I posted a patch[1] yesterday which addresses the namespace and -/_ translation. I rose this also some weeks ago on the list but there was no response. So the general interest seems to be pretty low. On the other hand Rich, seems to have something like this on his TODO list[2]. But maybe everything is different again because of AOT. So I'm not sure, what his plans are for gen-class right now. [1]: http://groups.google.com/group/clojure/browse_thread/thread/386d90a8b757aee4 [2]: http://richhickey.backpackit.com/pub/1597914 > The current implementation of nth provides a special implementation > for each kind of datatype that it knows about, and fails for unknown > types. Shouldn't it be possible to add a default case at the end that > calls a Clojure multimethod? That shouldn't have any performance > impact on the built-in datatypes. That is a good idea. It would be really cool. Sincerely Meikel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Nov 5, 2008, at 0:49, Mibu wrote: > You do know these licenses only hold in the litigious USA and some of > its subsidiaries? Even there, they're practically unenforceable. In > other places, developers usually ignore this red herring legal mambo > jumbo and just use the technology. Common law and common sense do the > rest. I agree. Can anyone cite a single lawsuit concerning an inappropriate mix of licenses? 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Having struggle in understanding FP (and Clojure question)
On Nov 4, 11:46 pm, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > > Long answer: SISAL is an example of a functional parallel language > > Ah, right, there was SISAL... unfortunately long forgotten. I saw a retrospective presentation on it at SIAM PP this spring by one of the Livermore folks who promoted it. Pretty neat! > > One could express solving linear systems (which is what I presume you > > mean by "matrix inversion," unless you really want the entries of the > > inverse) in a purely functional way using a language like SISAL with a > > compiler that optimizes away temporaries, and the resulting > > Could one? That was actually the core of my question. Of course HPC > applications would require smart compilers that, but first of all > there must be a purely functional algorithm that can be transformed > automatically into an efficient one. Do you know any references to > such algorithms in linear algebra? There's probably a big difference between "in theory" and "in practice" in this case ;-) SISAL didn't have multidimensional arrays so I doubt very much that it could have optimized away the creation of matrix temporaries. The usual trick to make things look functional is to index vector variables with the current iteration, so that you aren't overwriting anything. Then if the compiler can prove that there are no read-after- write conflicts, it can collapse the vector variables into one vector and replace copies with destructive writes. I haven't seen a purely functional formulation of LU factorization but it could be done without too much trouble. Of course there's no reason to go through that effort because people spend so much time optimizing LU and its constituent components that you would be better off reusing their work. > Of course, HPC applications dealing with large data sets would always > want algorithms that modify matrices in place instead of allocating > more memory. I don't expect a purely OO HPC world any time soon. But > it would still be interesting to know how many of the traditional CPU- > hungry algorithms already have known efficient functional equivalents. To me the more interesting and rewarding task is to figure out how to splice existing HPC libraries into a functional framework, without losing the ability to reason functionally about the components. > Me too. HPC is only one aspect of my work. And I think languages like > Clojure can be useful for generating specialized HPC code as well, > just like FFTW uses Caml code for generating C routines. Definitely! We've got at least one fellow here who uses Common Lisp to generate stencil codes. He's been thinking about switching to Clojure ever since he and I worked on a thorny Lisp problem together ;-) mfh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
N00B Question -- Trying to understand Interfaces
Hello all, I am just about to write my first Clojure code to teach myself the language. I thought I might try Bulls&Cows aka Mastermind. This is the game where one player hides a pattern of colors, the other guesses a pattern, and the first says something like "1 correct color in the right place, and 2 correct colors in the wrong places". I want the computer to guess the pattern. The algorithm I want to use is to generate the set of all possible answers, select one at random as the guess, and then successively remove those inconsistent with the set of responses received so far. This approach turns out to be close to optimal and the set of consistent guesses shrinks rapidly. I want to do this with sequence and filters. I want to make my own kind of lazy sequence that is the set of all possible guesses, and then filter it for consistency with the responses. My problem is getting my mind around the Sequence interface. I don't really understand how to make my own "type" of sequence. I don't really want a List, Vector or Map-- I want an infinite sequence defined by an algorithm. In Java I would expect to define my own class that implements the ISeq interface. What is the Clojure equivalent? For example, how would one make the sequence of all positive integers? I'm sure it's trivial, but it will un-stick me. Also I haven't found the right document/screencast that talks about this. Can someone give me a pointer. Thanks in advance Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: N00B Question -- Trying to understand Interfaces
Hi Peter, For the sequence of positive integers: (iterate inc 1) Take a look at the lazy-seqs library in Clojure-Contrib for some more interesting lazy sequences. Cheers, Stuart > Hello all, I am just about to write my first Clojure code to teach > myself the language. > > I thought I might try Bulls&Cows aka Mastermind. This is the game > where > one player hides a pattern of colors, the other guesses a pattern, and > the first says something like "1 correct color in the right place, > and 2 > correct colors in the wrong places". I want the computer to guess the > pattern. > > The algorithm I want to use is to generate the set of all possible > answers, select one at random as the guess, and then successively > remove > those inconsistent with the set of responses received so far. This > approach turns out to be close to optimal and the set of consistent > guesses shrinks rapidly. > > I want to do this with sequence and filters. I want to make my own > kind > of lazy sequence that is the set of all possible guesses, and then > filter it for consistency with the responses. > > My problem is getting my mind around the Sequence interface. I don't > really understand how to make my own "type" of sequence. I don't > really > want a List, Vector or Map-- I want an infinite sequence defined by an > algorithm. > > In Java I would expect to define my own class that implements the ISeq > interface. What is the Clojure equivalent? > > For example, how would one make the sequence of all positive integers? > I'm sure it's trivial, but it will un-stick me. > > Also I haven't found the right document/screencast that talks about > this. Can someone give me a pointer. > > Thanks in advance > Peter > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Files in Clojure Google Groups
Maybe everyone submitting new/updated file should announce it on the list in preferred format (with full filename, etc), so it could be fulltext searchable. Not the best enterprise class solution, but working - I've tried it for tsp.zip. :) On 10/31/08, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > > On Oct 30, 3:57 pm, bc <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Is there any way to enter an annotation or comments when a file is > > uploaded to the Clojure Google Groups file area? I've recently had a > > look at a few things there and it would be nice to have some context > > or background on why they were uploaded. For example, "tsp.zip" is a > > Traveling Salesperson example but, unless you download it and look at > > the code, how would you know that? Another example is "Clojure.png" > > which has a nice graphical representation of the Clojure reader. Was > > this part of a documentation effort or was it uploaded as an example > > as part of a discussion (a search on "Clojure.png" in the group didn't > > produce any matches)? It would be nice to have some form of comments/ > > annotations about the files. > > > > > > That's a good point. Unfortunately, it doesn't look like Google Groups > supports any annotations on the files. Suggestions for alternatives > welcome. > > > Rich > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: quote + #^ bug?
I don't know why you're getting this behavior, but you can do what you
want by using with-meta instead of #^
user=> (meta (with-meta 'sss {:tag 'mmm}))
{:tag mmm}
On Nov 4, 8:24 pm, Stephen Wrobleski <[EMAIL PROTECTED]> wrote:
> On rev 1086:
>
> user=> (meta `#^mmm sss)
> {:tag user/mmm}
>
> user=> (def obj '#^mmm sss)
> #=(var user/obj)
> user=> (meta obj)
> {:tag mmm}
>
> ; Okay.. However, this is not what I'd expect:
>
> user=> (meta '#^mmm sss)
> nil
>
> Seems like the metadata doesn't carry through the quote? (but for some
> reason, does so when on the RHS of a def)
>
> Regards,
> Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: N00B Question -- Trying to understand Interfaces
Ah thank you, now I am un-stuck. ISeq really only exists for Java interop right? You don't really implement new sequence data types, rather you combine things like ITERATE and MAPCAT with your own functions to define your own sequences. Is it correct to say that sequences are not really a type of data, as much as the control structure-- they take the place of WHILE, FOR, LOOP etc. in Clojure. Thanks P Stuart Halloway wrote: > Hi Peter, > > For the sequence of positive integers: (iterate inc 1) > > Take a look at the lazy-seqs library in Clojure-Contrib for some more > interesting lazy sequences. > > Cheers, > Stuart > > >> Hello all, I am just about to write my first Clojure code to teach >> myself the language. >> >> I thought I might try Bulls&Cows aka Mastermind. This is the game >> where >> one player hides a pattern of colors, the other guesses a pattern, and >> the first says something like "1 correct color in the right place, >> and 2 >> correct colors in the wrong places". I want the computer to guess the >> pattern. >> >> The algorithm I want to use is to generate the set of all possible >> answers, select one at random as the guess, and then successively >> remove >> those inconsistent with the set of responses received so far. This >> approach turns out to be close to optimal and the set of consistent >> guesses shrinks rapidly. >> >> I want to do this with sequence and filters. I want to make my own >> kind >> of lazy sequence that is the set of all possible guesses, and then >> filter it for consistency with the responses. >> >> My problem is getting my mind around the Sequence interface. I don't >> really understand how to make my own "type" of sequence. I don't >> really >> want a List, Vector or Map-- I want an infinite sequence defined by an >> algorithm. >> >> In Java I would expect to define my own class that implements the ISeq >> interface. What is the Clojure equivalent? >> >> For example, how would one make the sequence of all positive integers? >> I'm sure it's trivial, but it will un-stick me. >> >> Also I haven't found the right document/screencast that talks about >> this. Can someone give me a pointer. >> >> Thanks in advance >> Peter >> >> >> >> > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: N00B Question -- Trying to understand Interfaces
Hi, Am 05.11.2008 um 17:33 schrieb Peter Wolf: Also I haven't found the right document/screencast that talks about this. Can someone give me a pointer. A bit long, but ...: http://blip.tv/file/734409 Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: STM criticisms from Bryan Cantrill (Sun)
On Nov 4, 10:53 am, Rich Hickey <[EMAIL PROTECTED]> wrote: > Once detected, a deadlock can still be a bear to reproduce/debug, and > often does not appear until the worst possible time - production. So far, my experience (both direct & observed from others) with deadlocks has been: - indeed you get nailed in production - the post-mortem stack traces are good enough to figure out what happened - the fix forces you to think through the concurrency aspects of your code, but if you manage to do that then the bug stays fixed (if you fail to think it thru, e.g. "I'll just yank this lock" you are generally in for a world of hurt) - HotSpot is a ~500KLoC highly concurrent program with about ~100 named unique locks; we use aggressive lock-ranking asserts and in all the years of hacking HotSpot I've only ever seen 2 deadlocks (there were lots before the aggressive lock-ranking asserts - and those 2 deadlocks were because some more junior engineer skirted the asserts rather than fix the potential deadlock). > What's even more insidious is the memory not accessed under a lock > that should have been, and the ensuing corruption. No argument there. #1 bug for Azul (and we train all our SE's to look for it) is HashMap corruption leading to a closed-cycle linked list, and threads stuck forever spinning down the infinite list. > As far as livelock, if you get it to happen > it is usually due to long-running transactions competing with short > ones, and you can readily see/reproduce it under test loads. Here I'll disagree. Clojure uses a particular STM implementation, but does not dictate at the language level the implementation. Different STM implementations have wildly different performance characteristics, and there's a rich academic literature on how bad it gets. "In practice" (for such little "practice" as there is; Clojure might well rapidly have the most "practice") STM's indeed "get bad" unless they are pampered well (i.e. expert tuning). The problem is: what "gets bad" varies wildly by STM implementations - so fixing the "long transactions are getting live-locked by short runs" via hacking the STM will surely performance-break some other program. Here's where I think the root of my anguish lies: the STM runtime&performance is opaque, so changing either it OR my program to get performance is a hit-or-miss affair. At least with locks I can tell you something about what's going on, and make some kind of engineering guess as to what hacks will help & why. Random almost-unrelated correlation: making a long transaction into a series of short ones for performance looks a whole lot like making fine-grained locking from coarse-grained locking: - You are breaking the atomic/locked region into parts - You wouldn't bother expect performance sucks otherwise - The danger is in missing a path that needs to be atomic - Failure will be rare, unpredictable (untestable), unreproducible and generally only under heavy load (i.e., production). - Clojure's Immutibility won't save you here; you still must transact around the correct set of Ref's. > Rich Don't get me wrong: I think Clojure is on to something good here - Immutability IS the Big Hammer For Concurrency here, and the STM is just one of several flavors of "Big Hammer isn't working so I need another approach". Given the Immutability-By-Default, STM has a much better chance of being performant than in other languages so it makes sense to give it a go. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Nov 5, 3:33 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Are you sure? You're not modifying the clojure source, so you're not > creating a derivative work. I would think you can create a GPL > licensed library in that case. I can, but noone else will be allowed to redistribute it or works based upon it because the GPL disallows combining the work with CPL'd code. Imagine this scenario: There's a GPL'd Java library A. Its license disallows combining it with something CPL'd like Clojure. I can't release a programme based upon both Clojure and A because by doing so, I'd be combining A with Clojure. The CPL doesn't care, but the GPL does. I should probably have stated this more explicitely. > Anyone who uses your library and > distributes the result would have to GPL their work. If I create a library and put a GPL + “special Clojure exception” (analogous to the OpenSSL exception that is so common) on it (or maybe a GPL + “CPL exception” or whatever), then yes, something like that will be the result. And that would be a fine situation, if Clojure code could only call other Clojure code. But obviously, most GPL'd Java libraries don't do this, if only for the fact that their authors didn't know or care about Clojure when they started their project. > It's analagous to claiming that Intel > have to GPL their design for the x86 chips that Linux runs on, because > Linux itself is GPL. This analogy seems to evade my mind. Matthias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
sequence question and style question
(1) Is there a simpler way to define pairwise, which takes an existing sequence and then returns its items a pair at a time? (defn pairwise [& seq] (map vector (take-nth 2 seq) (take-nth 2 (rest seq (2) When writing a function like pairwise, are there any bright-line rules about whether to use variable arity? Cheers, Stuart --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Programming Clojure beta book now available
Since nobody else has mentioned it, I thought people on this group would be interested to know that Stuart Halloway's new Clojure book "Programming Clojure" is now available. I've also announced it on my blog: http://bc.tech.coop/blog/081105.html Congratulations Stuart, I've bought the combo package and am looking forward to reading the book and following progress as you flesh out material in the remaining chapters! -- Bill Clementson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM criticisms from Bryan Cantrill (Sun)
> No argument there. #1 bug for Azul (and we train all our SE's to look > for it) is HashMap corruption leading to a closed-cycle linked list, > and threads stuck forever spinning down the infinite list. if you can share, i'd find it very interesting to learn about the top 5 or 10 such bugs. sincerely. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Programming Clojure beta book now available
On Nov 5, 2008, at 12:56 PM, bc wrote: > > Since nobody else has mentioned it, I thought people on this group > would be interested to know that Stuart Halloway's new Clojure book > "Programming Clojure" is now available. I've also announced it on my > blog: > http://bc.tech.coop/blog/081105.html > > Congratulations Stuart, I've bought the combo package and am looking > forward to reading the book and following progress as you flesh out > material in the remaining chapters! Congratulations, Stuart! Purchasing a copy here too. -Matt > > > -- > Bill Clementson > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: sequence question and style question
On Wed, Nov 5, 2008 at 12:56 PM, Stuart Halloway <[EMAIL PROTECTED]> wrote: > > (1) Is there a simpler way to define pairwise, which takes an existing > sequence and then returns its items a pair at a time? > > (defn pairwise [& seq] > (map vector (take-nth 2 seq) (take-nth 2 (rest seq The built-in (partition) function does this, no? (partition 2 my-seq) Best, Graham > > (2) When writing a function like pairwise, are there any bright-line > rules about whether to use variable arity? > > Cheers, > Stuart > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Wed, Nov 5, 2008 at 12:53 PM, Matthias Benkard <[EMAIL PROTECTED]> wrote: > > On Nov 5, 3:33 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: >> Are you sure? You're not modifying the clojure source, so you're not >> creating a derivative work. I would think you can create a GPL >> licensed library in that case. > > I can, but noone else will be allowed to redistribute it or works > based upon it because the GPL disallows combining the work with CPL'd > code. > > Imagine this scenario: There's a GPL'd Java library A. Its license > disallows combining it with something CPL'd like Clojure. I can't > release a programme based upon both Clojure and A because by doing so, > I'd be combining A with Clojure. Hi, But you could release your program, and your installer could download library A and install it, no? The sticking point is in redistribution, not installation or use. Best, Graham > > The CPL doesn't care, but the GPL does. I should probably have stated > this more explicitely. > > >> Anyone who uses your library and >> distributes the result would have to GPL their work. > > If I create a library and put a GPL + "special Clojure > exception" (analogous to the OpenSSL exception that is so common) on > it (or maybe a GPL + "CPL exception" or whatever), then yes, something > like that will be the result. And that would be a fine situation, if > Clojure code could only call other Clojure code. But obviously, most > GPL'd Java libraries don't do this, if only for the fact that their > authors didn't know or care about Clojure when they started their > project. > > >> It's analagous to claiming that Intel >> have to GPL their design for the x86 chips that Linux runs on, because >> Linux itself is GPL. > > This analogy seems to evade my mind. > > Matthias > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Programming Clojure beta book now available
Just bought mine :-) Matt Revelle wrote: > On Nov 5, 2008, at 12:56 PM, bc wrote: > > >> Since nobody else has mentioned it, I thought people on this group >> would be interested to know that Stuart Halloway's new Clojure book >> "Programming Clojure" is now available. I've also announced it on my >> blog: >> http://bc.tech.coop/blog/081105.html >> >> Congratulations Stuart, I've bought the combo package and am looking >> forward to reading the book and following progress as you flesh out >> material in the remaining chapters! >> > > Congratulations, Stuart! > > Purchasing a copy here too. > > -Matt > > >> -- >> Bill Clementson >> > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: sequence question and style question
Duh. Thanks, and I will be adding that to the sequences chapter. :-/ Stuart > > On Wed, Nov 5, 2008 at 12:56 PM, Stuart Halloway > <[EMAIL PROTECTED]> wrote: >> >> (1) Is there a simpler way to define pairwise, which takes an >> existing >> sequence and then returns its items a pair at a time? >> >> (defn pairwise [& seq] >> (map vector (take-nth 2 seq) (take-nth 2 (rest seq > > The built-in (partition) function does this, no? > > (partition 2 my-seq) > > Best, > Graham > > >> >> (2) When writing a function like pairwise, are there any bright-line >> rules about whether to use variable arity? >> >> Cheers, >> Stuart >> >> >>> >> > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Programming Clojure beta book now available
Thanks Bill! I blogged this too, even though you scooped me. :-) http://blog.thinkrelevance.com/2008/11/5/clojure-beta-book-available > Since nobody else has mentioned it, I thought people on this group > would be interested to know that Stuart Halloway's new Clojure book > "Programming Clojure" is now available. I've also announced it on my > blog: > http://bc.tech.coop/blog/081105.html > > Congratulations Stuart, I've bought the combo package and am looking > forward to reading the book and following progress as you flesh out > material in the remaining chapters! > > -- > Bill Clementson > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: sequence question and style question
On Wed, Nov 5, 2008 at 2:00 PM, Stuart Halloway <[EMAIL PROTECTED]> wrote: > > Duh. Thanks, and I will be adding that to the sequences chapter. :-/ > > Stuart You're welcome -- looking forward to the book! Best, Graham > >> >> On Wed, Nov 5, 2008 at 12:56 PM, Stuart Halloway >> <[EMAIL PROTECTED]> wrote: >>> >>> (1) Is there a simpler way to define pairwise, which takes an >>> existing >>> sequence and then returns its items a pair at a time? >>> >>> (defn pairwise [& seq] >>> (map vector (take-nth 2 seq) (take-nth 2 (rest seq >> >> The built-in (partition) function does this, no? >> >> (partition 2 my-seq) >> >> Best, >> Graham >> >> >>> >>> (2) When writing a function like pairwise, are there any bright-line >>> rules about whether to use variable arity? >>> >>> Cheers, >>> Stuart >>> >>> >>> >> >> > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Programming Clojure beta book now available
Hehe, in the blogging world, it's the quick and the dead! On Wed, Nov 5, 2008 at 11:11 AM, Stuart Halloway <[EMAIL PROTECTED]> wrote: > > Thanks Bill! > > I blogged this too, even though you scooped me. :-) > > http://blog.thinkrelevance.com/2008/11/5/clojure-beta-book-available > >> Since nobody else has mentioned it, I thought people on this group >> would be interested to know that Stuart Halloway's new Clojure book >> "Programming Clojure" is now available. I've also announced it on my >> blog: >> http://bc.tech.coop/blog/081105.html >> >> Congratulations Stuart, I've bought the combo package and am looking >> forward to reading the book and following progress as you flesh out >> material in the remaining chapters! >> >> -- >> Bill Clementson >> > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
I love it how developers talk about legal issues as if they were software issues: license compatibility, backward compatibility, dual- licensing, license interop, adherence to license clauses, migration to a different license, forking of licenses, license features, supporting a license or license requirements, license names with Three-Letter- Acronyms, version numbers, and even the way developers declare their licenses at the beginning of sources files. It's all there in any license flame war populated by software developers. Free software licenses are a convention or a trend of open source projects. Who said an OS project must have a license? Sure it's convenient when one is really needed or if you really want to virally and forcefully push your agenda onto others, but for most free projects, if you just let them loose, there really are no issues of liability, copyright, trademarks, patents, code mixing, tainted code, distribution rights or even credits. It may seem there are issues thanks to the verbose legal gobbledygook licenses are written in, but really it's all bull. Now, I'm not a lawyer, nor I play one on TV, but the truth is software developers know about legal issues as much as legal professionals know about software. One effect of this, is paralysis. Remember when you needed to deal with something awfully bureaucratic, and you just put it off? Same thing happens when people are faced with a difficult dilemma, they avoid it. People see licenses, and immediately enter a moral dilemma -- should they ignore the will of the developer and possibly break the law or should they pay a lawyer? Which is the greater sin? Lispers were always avant-garde, ignoring convention, only considering merit. Why can't we debate whether a license is needed at all for a free project? It's like inventing a new programming language and debating how you should retrofit it with OOP features because all the other cool languages do it. Mibu (Too idealistic? Hey, it's a flame war. Just playing by the rules...) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Nother N00B Question
I just browsed Stuart's wonderful book. Lots of great stuff, which I will enjoy working though However, I didn't find a section that talks about how to do non-functional stuff in Clojure. Might be a good section to add for N00Bs For example, I'm implementing my Mastermind game. I want to prompt the user, read a value, change the state of the game, iterate... For example Guess 1 >> Blue, Blue, Green, Red Response << 1 Black, 2 White Guess 2 >> Blue, Green, Red, White Response << ... At some point, almost all interesting programs read input, change state and generate output. What is the Clojure way? Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Nother N00B Question
Duh... I should read more carefully. I just found the section on loop/recur. Still, it might be good to expand that section, and highlight it. I suspect that every N00B will wonder how to implement a console app. And every LISPer will try to implement the REPL in Clojure. P Peter Wolf wrote: > I just browsed Stuart's wonderful book. Lots of great stuff, which I > will enjoy working though > > However, I didn't find a section that talks about how to do > non-functional stuff in Clojure. Might be a good section to add for > N00Bs > > For example, I'm implementing my Mastermind game. I want to prompt > the user, read a value, change the state of the game, iterate... > > For example > > Guess 1 >> Blue, Blue, Green, Red > Response << 1 Black, 2 White > Guess 2 >> Blue, Green, Red, White > Response << ... > > At some point, almost all interesting programs read input, change > state and generate output. What is the Clojure way? > > Peter > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Nother N00B Question
Peter, You might look at the loop special form: (defn game "Runs the game, returning the final state" [] (loop [state (initial-state)] (report state) (if (final? state) state (recur (compute-new-state state (read-line)) for your own definitions of initial-state, report, final?, and compute- new-state. On Nov 5, 3:01 pm, Peter Wolf <[EMAIL PROTECTED]> wrote: > I just browsed Stuart's wonderful book. Lots of great stuff, which I > will enjoy working though > > However, I didn't find a section that talks about how to do > non-functional stuff in Clojure. Might be a good section to add for N00Bs > > For example, I'm implementing my Mastermind game. I want to prompt the > user, read a value, change the state of the game, iterate... > > For example > > Guess 1 >> Blue, Blue, Green, Red > Response << 1 Black, 2 White > Guess 2 >> Blue, Green, Red, White > Response << ... > > At some point, almost all interesting programs read input, change state > and generate output. What is the Clojure way? > > Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Wednesday 05 November 2008 12:00, Mibu wrote: > I love it how developers talk about legal issues as if they were > software issues: license compatibility, backward compatibility, dual- > licensing, license interop, adherence to license clauses, migration > to a different license, forking of licenses, license features, > supporting a license or license requirements, license names with > Three-Letter- Acronyms, version numbers, and even the way developers > declare their licenses at the beginning of sources files. ... You send this as a reply to my message, yet I said nothing of the sort. And perhaps you should ponder the similarity between the formal systems of the law and those of digital information systems. You might find they have more in common than you seem to think. > Lispers were always avant-garde, ignoring convention, only > considering merit. Why can't we debate whether a license is needed at > all for a free project? ... I think the answer is that very few people see it as a matter that requires debate _whether_ a license is required. One has to make formal the conditions under which a work of of technological authorship is made available to the world at large. Programmers work long and hard on their projects, whether large or small, and most of us naturally view the fruits of our labor with a strong sense of ownership. And I'd say that attitude is well deserved. All programming is hard. Library design is harder. Language design is much harder, perhaps even the hardest sub-discipline of all on the software side of IT. > Mibu > > (Too idealistic? Hey, it's a flame war. Just playing by the rules...) You have some odd ideas. No one is flaming. There is no war. And if there is an idealism in what you suggest, it's barely discernable. Unless perhaps it is that you renounce all notions of ownership, perhaps only for intellectual property. You're entitled to that viewpoint, of course, but don't expect to find many technologists to share such a view. Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
> Unless perhaps it is that you renounce all notions of ownership, > perhaps only for intellectual property. You're entitled to that > viewpoint, of course, but don't expect to find many technologists to > share such a view. I don't renounce ownership rights at all, not even for intellectual property. I just think "free" software licenses are useless at best and counterproductive at worst when applied to projects that are supposed to be free. About the flame war thingy, it's with a tongue-in-cheek. Mibu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Nother N00B Question
On Nov 5, 2008, at 3:01 PM, Peter Wolf wrote: > > I just browsed Stuart's wonderful book. Lots of great stuff, which I > will enjoy working though > > However, I didn't find a section that talks about how to do > non-functional stuff in Clojure. Might be a good section to add for > N00Bs > > For example, I'm implementing my Mastermind game. I want to prompt > the > user, read a value, change the state of the game, iterate... > > For example > > Guess 1 >> Blue, Blue, Green, Red > Response << 1 Black, 2 White > Guess 2 >> Blue, Green, Red, White > Response << ... > > At some point, almost all interesting programs read input, change > state > and generate output. What is the Clojure way? Check out page 24 for mention of refs. > > > Peter > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Wednesday 05 November 2008 12:30, Mibu wrote: > > Unless perhaps it is that you renounce all notions of ownership, > > perhaps only for intellectual property. You're entitled to that > > viewpoint, of course, but don't expect to find many technologists > > to share such a view. > > I don't renounce ownership rights at all, not even for intellectual > property. I just think "free" software licenses are useless at best > and counterproductive at worst when applied to projects that are > supposed to be free. Then I don't think you understand what licenses are for. What you advocate leaves authors powerless to exert any control over their works, since the public domain is the absence of ownership and, hence, of control. > ... > > Mibu Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
> I don't renounce ownership rights at all, not even for intellectual > property. I just think "free" software licenses are useless at best > and counterproductive at worst when applied to projects that are > supposed to be free. Free software needs a license if it's going to be adopted by organizations with lawyers. That's true independent of their inherent utility (or lack thereof). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Nother N00B Question
Thanks, the "hello" example on page 25 is perfect. Matt Revelle wrote: > On Nov 5, 2008, at 3:01 PM, Peter Wolf wrote: > > >> I just browsed Stuart's wonderful book. Lots of great stuff, which I >> will enjoy working though >> >> However, I didn't find a section that talks about how to do >> non-functional stuff in Clojure. Might be a good section to add for >> N00Bs >> >> For example, I'm implementing my Mastermind game. I want to prompt >> the >> user, read a value, change the state of the game, iterate... >> >> For example >> >> Guess 1 >> Blue, Blue, Green, Red >> Response << 1 Black, 2 White >> Guess 2 >> Blue, Green, Red, White >> Response << ... >> >> At some point, almost all interesting programs read input, change >> state >> and generate output. What is the Clojure way? >> > > Check out page 24 for mention of refs. > > >> Peter >> >> > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Nov 5, 6:55 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > I agree. Can anyone cite a single lawsuit concerning an inappropriate > mix of licenses? Usually these license issues get resolved before court. The fact is that it is illegal to combine CPL and GPL code in certain manners. Doing that anyways and crossing your fingers that you won't get sued doesn't sound like the best policy. cs --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Nov 5, 12:00 pm, Mibu <[EMAIL PROTECTED]> wrote: > Why can't we debate whether a license is needed at all for a > free project? > (Too idealistic? Hey, it's a flame war. Just playing by the rules...) This is sounding awfully trollish of you. I didn't start this thread to cause a "flame war". My apologies to Rich and others if it seemed that way. I genuinely care about removing barriers to open source interoperability. My motives are pure. cs --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Concerned about Clojure's license choice.
On Nov 5, 4:13 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Nov 5, 12:00 pm, Mibu <[EMAIL PROTECTED]> wrote: > > > Why can't we debate whether a license is needed at all for a > > free project? > > (Too idealistic? Hey, it's a flame war. Just playing by the rules...) > > This is sounding awfully trollish of you. I didn't start this thread > to cause a "flame war". My apologies to Rich and others if it seemed > that way. I genuinely care about removing barriers to open source > interoperability. My motives are pure. > I'll grant that as true, and would like to end the current discussion for now, as it's gone on pretty long and has run out of productive content. This list has been free of 'wars' and I'd like to keep it that way. Here's where I stand with Clojure's licensing: For the short term, it's going to remain CPL. The next likely candidate would be EPL, CPL's successor, in wide use by Eclipse et al, and acceptable to Google Code. If the EPL and GPL folks can hammer out compatibility, great. Until then, I'll not let it become my problem. I will not be using any 'customized' license. Using a well known license intact is the only way to make it easy for users to vet the license for use. Anything else requires lawyers for me and them. I will not be dual licensing with GPL or LGPL. Both licenses allow the creation of derived works under GPL, a license I cannot use in my work. Allowing derived works I cannot use is not reciprocal and make no sense for me. Thanks to all for your opinions - let's move on. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
jEdit Mode for Clojure
Just thought it was about time I gave someone a heads up about this...
Mostly for amusement, I created a jEdit mode for Clojure a while
back. I don't get a chance to play with Clojure all that much, so it
hasn't been heavily tested ("go-to" *is* a Clojure "keyword",
right?). ;-) It's primarily based upon the Vim mode in terms of what
keywords it supports and how. Auto-indentation was something I looked
at, but it isn't something I actually bothered to support due to time
constraints (jEdit is capable of some pretty slick auto-indenting
where Lisp-like languages are concerned).
You can get the mode here:
http://github.com/djspiewak/jedit-modes/tree/master/clojure.xml
Feedback is always welcome and I am willing to make changes to the
mode per request (hint: patches/pull requests not required, but
appreciated from those who know how to edit jEdit modes). You guys
use this language, not me, so you're a much better judge of what the
editor support should be like. Enjoy!
Daniel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Nother N00B Question
Thank you so much, Stuart! Congratulations~ I really look forward to reading this book. :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch: callable defstruct (PersistentStructMap$Def extends AFn)
On Wed, Nov 5, 2008 at 12:10 AM, Chouser <[EMAIL PROTECTED]> wrote:
> The attached patch allows:
>
> user=> (point 42 11)
> {:x 42, :y 11}
The right tool for the job makes all the difference. Attached is a
much simpler patch to accomplish the same thing.
--Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
commit f107e22f4cf3447543310f6b157b36dcad7ae4cd
Author: Chouser <[EMAIL PROTECTED]>
Date: Wed Nov 5 23:15:52 2008 -0500
PersistentStructMap$Def extends RestFn
diff --git a/src/jvm/clojure/lang/PersistentStructMap.java b/src/jvm/clojure/lang/PersistentStructMap.java
index 055448c..a54b683 100644
--- a/src/jvm/clojure/lang/PersistentStructMap.java
+++ b/src/jvm/clojure/lang/PersistentStructMap.java
@@ -18,14 +18,19 @@ import java.io.Serializable;
public class PersistentStructMap extends APersistentMap{
-public static class Def implements Serializable{
+public static class Def extends RestFn implements Serializable{
final ISeq keys;
final IPersistentMap keyslots;
Def(ISeq keys, IPersistentMap keyslots){
+ super(0);
this.keys = keys;
this.keyslots = keyslots;
}
+
+ protected Object doInvoke(Object args) throws Exception{
+ return construct(this, (ISeq)args);
+ }
}
final Def def;
A trivial question about type and class
Hi all. In Stuart's book - Programming Clojure, there is a multi
method like following:
(defmulti blank? class)
(defmethod blank? String [s] (every? #{\space} s))
(defmethod blank? nil [_] true)
After reading the method, I was curious about type or class of native
data structures of Clojure. So I typed next code in slime. Hmm.. I
didn't understand why classes of {:a 1} and {} are not same. Like
Stuart's code, to make multi method branching based on clojure data
structure type(map, vector, list), what symbol should I use? (Like
String for "string", Is there a Map for {:a 1}? I tried
PersistentHashMap, HashMap, Map, so on.. I didn't find it.)
user> (= (class "abc") String)
true
user> (class {:a 1 :b 2})
#=clojure.lang.PersistentHashMap
user> (class {})
#=clojure.lang.PersistentHashMap
user> (= (class {:a 1}) (class {}))
false
user> (= (class {:a 1}) (class {:b 2}))
true
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: A trivial question about type and class
On 6 Nov, 07:25, Chanwoo Yoo <[EMAIL PROTECTED]> wrote:
> Hi all. In Stuart's book - Programming Clojure, there is a multi
> method like following:
>
> (defmulti blank? class)
> (defmethod blank? String [s] (every? #{\space} s))
> (defmethod blank? nil [_] true)
>
> After reading the method, I was curious about type or class of native
> data structures of Clojure. So I typed next code in slime. Hmm.. I
> didn't understand why classes of {:a 1} and {} are not same. Like
> Stuart's code, to make multi method branching based on clojure data
> structure type(map, vector, list), what symbol should I use? (Like
> String for "string", Is there a Map for {:a 1}? I tried
> PersistentHashMap, HashMap, Map, so on.. I didn't find it.)
>
> user> (= (class "abc") String)
> true
> user> (class {:a 1 :b 2})
> #=clojure.lang.PersistentHashMap
> user> (class {})
> #=clojure.lang.PersistentHashMap
> user> (= (class {:a 1}) (class {}))
> false
> user> (= (class {:a 1}) (class {:b 2}))
> true
I don't have the book yet so I don't know what Stuarts intention was
with the example but here are my thoughts on the matter.
Dispatching based on type (class) makes more sense for java objects
such as a String than the Clojure data structures since Clojure
focuses more on value-equals semantics (which in dispatch would be
sort of like duck typing) than identity comparison.
For a discussion about dispatching based on type see this old thread:
http://groups.google.com/group/clojure/browse_thread/thread/74d430f8e4353725/d16b548d4d46aab0
/mac
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: A trivial question about type and class
On Thu, Nov 6, 2008 at 8:25 AM, Chanwoo Yoo <[EMAIL PROTECTED]> wrote:
>
> Hi all. In Stuart's book - Programming Clojure, there is a multi
> method like following:
>
> (defmulti blank? class)
> (defmethod blank? String [s] (every? #{\space} s))
> (defmethod blank? nil [_] true)
>
> After reading the method, I was curious about type or class of native
> data structures of Clojure. So I typed next code in slime. Hmm.. I
> didn't understand why classes of {:a 1} and {} are not same. Like
> Stuart's code, to make multi method branching based on clojure data
> structure type(map, vector, list), what symbol should I use? (Like
> String for "string", Is there a Map for {:a 1}? I tried
> PersistentHashMap, HashMap, Map, so on.. I didn't find it.)
I think what you're looking for is "clojure.lang.PersistentHashMap"
instead of just "PersistentHashMap".
user=> String
java.lang.String
user=> PersistentHashMap
java.lang.Exception: Unable to resolve symbol: PersistentHashMap in this context
[...]
user=> clojure.lang.PersistentHashMap
clojure.lang.PersistentHashMap
user=>
I don't know much about Clojure, though, so I suspect there is better
advice than the above :)
> user> (= (class "abc") String)
> true
> user> (class {:a 1 :b 2})
> #=clojure.lang.PersistentHashMap
> user> (class {})
> #=clojure.lang.PersistentHashMap
> user> (= (class {:a 1}) (class {}))
> false
> user> (= (class {:a 1}) (class {:b 2}))
> true
That seems rather strange to me too.
--
Michael Wood <[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
