Re: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching
On 13/05/2011, at 2:21 PM, David Nolen wrote: > - instance? or custom predicate matches done w/ if I did quite a bit of this in the context of a Smalltalk implementation. One of the key features is fast type testing. I note in your example case you are relying on an id generic to provide the type tags that are type-hierarchy aware. As long as your type tests are wrt a tree, rather than a graph, then maintaining a DFS number on the tree gives very cheap subclass testing. In a dynamic language you have to maintain that number in the face of changes to the tree, which can be optimised in various ways such as an initial sparse allocation, with an increase in sparseness as you note parts of the tree being updated dynamically. Also you need to allow your dispatch functions to either be updated in response to tree changes (not a great idea) or to use a level of indirection so that you reference the type tree in some way in your test and get the appropriate id range on the fly (and, of course, maintain the bounding pair of ids in the tree for each node). Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain -- You 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: xml parsing
On 17/03/2011, at 8:20 AM, Laurent PETIT wrote: > 2011/3/16 Stuart Sierra > I think xml-seq is returning a sequence representing a depth-first traversal > of the XML document. So the first item in the sequence is the entire > document, followed by the first element under the root, and so on. > > That's not the definition of depth-first, is it ? It's a pre-order depth-first traversal. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 On the other side, you have the customer and/or user, and they tend to do what we call "automating the pain." They say, "What is it we're doing now? How would that look if we automated it?" Whereas, what the design process should properly be is one of saying, "What are the goals we're trying to accomplish and how can we get rid of all this task crap?" -- Alan Cooper -- You 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: Literate Clojure - a good lead ...
On 22/07/2010, at 3:08 AM, Tim Daly wrote: > "Language integration" is a false goal. It is technically possible to > call functions in any language from latex but unnecessary in general. > It is technically possible to generate latex from any language. Have you read the paper? Being able to automatically embed the output of examples is a big win IMO. > Symbol resolution is also rarely an issue in literate programs. > Your prose is intended to explain "why" a code chunks exists, > not "how" a code chunk works. If you explain the problem you > are trying to solve and the issues of various approaches you considered > then I can usually understand the solution. Symbol resolution allows the environment to link symbols and their occurrences, and the same with hyperlinked output. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 All that is required for evil to triumph is that good men do nothing. -- You 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: Literate Clojure - a good lead ...
On 21/07/2010, at 10:29 PM, Tim Daly wrote: > The PLT Scheme mechanism mentioned above is a good idea > but it has a niche quality to it. > > Latex is an industry standard publication language. Many > books and technical papers, especially in mathematics, > use it. Some conferences require it. All publishers support > it and it is widely used. Going from the PLT form to Latex is possible. Why use Latex when you can use Clojure? The essence of the PLT model is the language integration that allows symbol resolution by reusing the language mechanism for the documentation. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The fact that an opinion has been widely held is no evidence whatever that it is not utterly absurd. -- Bertrand Russell -- You 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
Literate Clojure - a good lead ...
Might be of interest to some here: http://lambda-the-ultimate.org/node/4017 Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams -- You 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: Enhanced Primitive Support
On 18/06/2010, at 4:28 PM, Richard Newman wrote: >> This imposes too high a burden on any programmer who cares about safety. >> >> Don't buy it. That's the whole point of BigInt contagion. If fact and foo >> are correctly written this will work. > > It only takes one library to screw up, and the whole stack falls down. > > Screwing up can occur because of omission (fact being written with a "1", not > "1N", and not being tested with large inputs), or by design. > > This whole debate arose because people care about the speed of their numeric > functions! The safety bignums (which make things slower) will be omitted for > performance reasons, or by accident, and people won't obey the contract of > the function… or won't be able to because of the complex interactions between > libraries. I can't control where every value in my program goes. > > In Clojure as it stands now, those edge cases would see a small performance > penalty as bignums occurred (and then it would go away if they got demoted!). > After this change, a one-in-a-million collision of numbers and > performance-oriented programming would throw an exception with no way to > recover from higher up the stack. > > A programmer who really cares about safety would thus indeed have to shoulder > a massive burden: either review and get complete test coverage over every > library in their dependency stack, or ensure that no non-bignum can ever > enter a library function. I guess that also means no strings, no file sizes, > no URLs, no values which might get recombined… because any of those values > could produce a non-bignum and enter an unsafe Clojure library function, > causing an overflow with no possibility of continuing. (This ain't Common > Lisp.) > > Having digested Rich's notes, pretty much the only thing that I disagree with > is the lack of automatic bignum promotion/demotion. It seems like too much of > a bad tradeoff, sacrificing one of Clojure's selling points for a little > numeric performance. Thus far, Clojure has done pretty well in lexically > scoping its "please make this fast and unsafe" bits — primitive calls, loop, > transients. This would break that pattern. +1, what I've been trying to say. > I wonder: is there's a middle ground, where primitives are automatic almost > everywhere, but bignum promotion on overflow is still possible? That's what I was suggesting by having two versions of functions, one with primitives and one with boxed values. I did some investigation on this for a Smalltalk JIT using LLVM, in the form of partial specialisation e.g. dynamically generating type-specialised versions of functions (methods in ST) and using the types available at the call site to dispatch - which is more obvious in Clojure because we already have multi-method dispatch. For Clojure you wouldn't test all types, it could just be a binary choice of all primitives where expected or not Of course where a type-specialised function calls another type-specialised function you can avoid the dispatch entirely because you have the type information at the call site. This way, you can pay for the type-driven dispatch once at the start of a computation and end up doing minimal testing (basically dynamically checking that type invariants are maintained e.g. args haven't been promoted in the case under discussion). IMO this is speed + safety. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Reflecting on W.H. Auden's contemplation of 'necessary murders' in the Spanish Civil War, George Orwell wrote that such amorality was only really possible, 'if you are the kind of person who is always somewhere else when the trigger is pulled'. -- John Birmingham, "Appeasing Jakarta" -- You 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: Enhanced Primitive Support
On 18/06/2010, at 2:26 PM, David Nolen wrote: > On Fri, Jun 18, 2010 at 12:24 AM, Antony Blakey > wrote: > > That's fine for fact, but as a consumer of library functions, how do I know > when I should pass in bigints? How do I know when an intermediate value, for > my particular combination of parameter values, is going to overflow? > > If the library isn't communicating that to you isn't that just a broken API > that you don't want to participate in? Tag information on arglists is > available: No. How do I know whether I need to pass a bigint literal or not? For what possible input values will overflow be an issue? It's easy to see with fact, but that's because the function implementation is clearly visible, and has well known growth properties of a single argument. And it's not just literals - when functions are composed from other functions that have this same problem and return primitive types - hence using the static versions of functions - the question in general becomes impossible to answer, not only because there might be a number of parameters with interdependencies, but because the structure of intermediate results may not be visible to the consumer. And what if you don't have the source to the function? This proposal not only puts the burden of promotion and representation choice onto the user of a function, but it requires that promotion be done before the function is executed, in a precautionary way, rather than iff needed. This proposal is IMO a very bad idea. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Lack of will power has caused more failure than lack of intelligence or ability. -- Flower A. Newhouse -- You 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: Enhanced Primitive Support
On 18/06/2010, at 12:30 PM, Rich Hickey wrote: > You raise several points, I'll take them in turn. First, things are not as > dire as you state. Certainly one could write a version of fact that hardwired > bigints as you showed. But you need not - here's the original naive > definition: > > (defn fact [n] > (if (zero? n) 1 (* n (fact (dec n) > > Such logic that doesn't specify one of the components (in this case, n) is > still polymorphic, as are operations with mixed components. So the power is > in the hands of the supplier of n: > > user=> (fact 10) > 3628800 > > user=> (fact 40) > java.lang.ArithmeticException: integer overflow > > user=> (fact 40N) > 8159152832478977343456112695961158942720N That's fine for fact, but as a consumer of library functions, how do I know when I should pass in bigints? How do I know when an intermediate value, for my particular combination of parameter values, is going to overflow? Should I just use 'N' on every number to every function? This proposal destroys the black-box nature of functions, and seems to me to be the easy solution rather than the best solution, which, I acknowledge, might be very hard work, possibly involving every such function having 2 polymorphic variants, one generic boxed form and one unboxed form, automatically selected and call-site-cached like OO dispatch. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain -- You 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: Commercially-supported, polished Clojure development environment
On 14/06/2010, at 9:25 PM, Laurent PETIT wrote: > Hi Chas, > > I'm interested in being able to consult the detail of the answers (not > just the summary view), 'cause I guess there could be interesting > stuff in the "free form" parts of it (and the summary page just > presents a few of these answers). +1 Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 What can be done with fewer [assumptions] is done in vain with more -- William of Ockham (ca. 1285-1349) -- You 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: Interface to integrate transactions with Clojure transactions
On 11/06/2010, at 1:48 PM, Antony Blakey wrote: > > On 11/06/2010, at 7:28 AM, James Reeves wrote: > >> On 10 June 2010 22:40, Michael Jaaka wrote: >>> Not good, since if database commit fail it is too late for dosync to >>> rollback. >>> In fact database commit should somehow cooparate with dosync commit >>> which is just a case of distributed transaction. >> >> You're right. In which case, I don't believe there's a way to do this >> without accessing the clojure.lang.LockingTransaction class directly. > > It's not possible to do this without a two phase commit, which would require > quite a change to clojure's transactional mechanism in order to break the > existing commit login into a prepare and commit. Now that I think about it, you could do this in clojure if you treat the clojure transaction as the last in line requiring prepare/commit. The final transaction participant can fold the prepare/commit into a simple commit using the following algorithm: prepare all data sources if any fail rollback all data sources and rollback the clojure transaction else commit the clojure transaction if it succeeds commit all data sources else rollback all data sources This doesn't give you full 2PC because it doesn't handle comms failure, but it does handle normal transactional semantics. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain -- You 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: Interface to integrate transactions with Clojure transactions
On 11/06/2010, at 7:28 AM, James Reeves wrote: > On 10 June 2010 22:40, Michael Jaaka wrote: >> Not good, since if database commit fail it is too late for dosync to >> rollback. >> In fact database commit should somehow cooparate with dosync commit >> which is just a case of distributed transaction. > > You're right. In which case, I don't believe there's a way to do this > without accessing the clojure.lang.LockingTransaction class directly. It's not possible to do this without a two phase commit, which would require quite a change to clojure's transactional mechanism in order to break the existing commit login into a prepare and commit. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 2:27 PM, James Cunningham wrote: > > > On May 30, 9:23 pm, Antony Blakey wrote: >> I care about Mac and Windows primarily, and building software that will sell >> (not dev tools) requires good native look and feel. > > Do you have a single example of an SWT app that has a decent feel on > OS X? I've spent a fair amount of time with Eclipse lately, and--- > frankly---it feels about as native as an Alabaman in Nice. No native > toolbar, no native tabs, slower and uglier than either Netbeans or > Intellij. My only other experience with an SWT app was entirely > negative from a performance and look-and-feel perspective (Vuze). Vuze looks OK to me in the 5 minutes I've just spent. In any case, my opinion comes from doing parallel GUI development in IB and SWT to see if I could use Clojure/SWT rather than MacRuby (XCode/IB). I'm not using the RCP which imprints it's own not-really-OSX flavour in spite of the widgets. You have to do more than just use SWT to get a Mac application to feel right, and one's GUI layout code needs to be parametric and rules based, rather than just swapping the L&F. That said, it's still easier than writing three UIs. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honours the servant and has forgotten the gift. -- Albert Einstein -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 2:04 PM, lprefonta...@softaddicts.ca wrote: > Two alternatives seem to gather some support, Swing and SWT. Now what are > the > cost/benefits of choosing SWT ? See below. > What value brings SWT ? > > a) Performance ? Maybe a few years ago but presently > Swing and SWT are similar in terms of performance in general. Not my experience, but YMMV, and in any case not the deciding factor for me. > c) Cosmetic aspect ? SWT "wins" for its ability to look like other apps > on a given platform. Swing offers a uniform look and feel. > > So the only "feature" offered by SWT if I follow your point is c). > At what cost ? Well, I'd argue that it's more than cosmetic, which I take you to mean pejoratively. In fact I place an enormous value on this point, for what seems to me to be a slight cost (and the major one is manual management of resource lifetime, not deployment). > Back to "why does producing software has to be more painful than necessary" > and "what value brings SWT overall". I guess we just differ in our assessment of 'necessary' and 'value' in this paragraph. > >> >>> Were not in the cosmetics business however so we speak for our business >>> (cross-platform, cross-language, cross-) >> >> You are begging the question then. > > Swing has prove itself up to know (and improved a lot), why get entangled > in a complex process with all the above ramifications ? > > Simplicity as some value. You should meditate a bit on this. I'm a big fan of simplicity. However there are two sayings that come to mind: 1. Make everything as simple as possible, but not simpler. (Albert Einstein) 2. For every complex problem, there is an answer that is clear, simple - and wrong (H. L. Mencken). Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
I doubt this subthread is of any use to the OP at this point. On 31/05/2010, at 12:31 PM, lprefonta...@softaddicts.ca wrote: > Any suggestion is welcomed but I doubt we can find a core group of > developers that will "win" this survey. It's a survey group of 1 i.e. what are *his* responses to those questions. > Yep but then you need to ship the DLLs (and any other native implementations > for > the various platforms) with a synced version of the wrapper. > Of course the native libraries may vary according to the platorm/maintenance > releases, ... And yet, somehow, commercial software is produced ... > So should we expect problems in other OSes ? What about testing then ? > Do we multiply the number of test suites to run by the number of platforms > we support multiplied by the different versions of SWT ? No, you treat SWT as a black box as regards testing. It has it's own test regime and cross-platform validation. > Were not in the cosmetics business however so we speak for our business > (cross-platform, cross-language, cross-) You are begging the question then. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt. -- Bertrand Russell -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 12:31 PM, Mike Meyer wrote: > On Mon, 31 May 2010 10:53:45 +0930 > Antony Blakey wrote: > >> >> On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: >>> also lets not forget about LD_LIBRARY_PATH issues, >> No Mac or Windows user would encounter these. > > You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In > an ideal world - where every developer did things right - you'd never > need it on any system. We don't live in such a world. In particular, > OSX tends to ship with obsolete versions of *very* popular Unix > libraries. So much so that you wind up having to choose between > building obsolete versions of the tools you want, losing valuable > features and bug fixes; or building current versions of libraries in > the system, leading to having to make sure your code and only your > code finds it - even when you're dynamically loading frameworks that > want to use the system version of the same library. > > On Windows, the problem is so common it's been given the name "DLL > hell". I build installers that include chains of co-dependent base libraries with isolating setups (programatically mutated binary and load paths) for multiple platforms, so I know about this issue, but I'm talking specifically about SWT which doesn't suffer from that problem. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 11:13 AM, Marc Spitzer wrote: > I actually primarily do not care about mac or windows, personally or > professionally. Also keep in mind that one of the selling points of > clojure is that it runs where *Java* runs not mac and windows, I would > think that in my mind anyway, be a strong contributing point. Now to > be honest I am responsible for Macs at work but hopefully less of them > as time goes by. This is obviously another input into Luke's decision making. What kind of apps does he want to target, what kind of developers, what platforms, with what intentions. > Have you ever heard of DLL HELL? It is a special case of library path > issues, they exist every where you have shared libs/DLLS being loaded. That only happens if you try to share the DLL, which isn't necessary. > And as a sysadmin I have had LD issues with OSX. Consumer apps using SWT don't have this problem on OSX. > your right we should all be using pcbsd much better, http://pcbsd.org/ LOL. > native integration is not quality, quality is quality native > integration is look and feel. which is an essential part of quality from a user's perspective for the two consumer desktop platforms. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead. -- Ron Avitzur -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: > I do agree with you for 'a' native wrapper. What is your opinion for > all native wrappers? The thing is that each platform that requires > native code is a source of tech support requests. Now let me go with > the things I have at work: > 1: redhat 64 and 32 bit, various flavors > 2: solaris x86 and sparc various flavors > 3: aix various flavors > 4: mac os various flavors including powerpc > 5: windows > 6 other linuxes I care about Mac and Windows primarily, and building software that will sell (not dev tools) requires good native look and feel. > also lets not forget about LD_LIBRARY_PATH issues, No Mac or Windows user would encounter these. > incomparable > installed libs, the need to go off the reservation to get something > working. Instead of yum working on my redhat boxes I need to compile > a specific version of something *AND* make sure this app finds it but > that the other apps do not. And this is just one reason Linux on the desktop is a million miles from Mac and Windows. > well java is not good enough if you want a native look, you need C/C++ > and binding that java uses. And why should Luke be a martyr and pay > the price in his personal time/life for something that should be fun. a) SWT is not martydom, and is a lot better than Swing for a native L&F b) Luke asked for opinions. > Also please keep in mind that "Better" is a good target and generally > much more achievable then superlative. Shipped is also a wonderful > thing. Better and shipped are really cool. And if you keep shipping > better thing you get to superlative. Not if your toolkit (Swing) places an upper bound on the quality of your app. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 9:44 AM, Marc Spitzer wrote: > 2: it is good enough IMO This is the entire point. Swing is not good enough if you want to build something with native integration and correct look and feel. Everything else comes down to whether developers are prepared to pay the price for producing something great. And anyway is 'good enough' what we should be aiming for. How about going for something superlative rather than something mediocre. Bundling SWT into a native wrapper isn't a big deal. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams -- You 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 28/05/2010, at 9:21 AM, Armando Blancas wrote: >> Remember, the actual API won't matter - that will be completely >> abstracted away. So try to focus on the framework's look and feel. >> Thanks! >> -Luke > > SWT, because of the native look and feel. I really don't like the > looks of Swing. As a user of some Swing app, I don't find solace from > thinking how convenient it was for the programmers to deliver that > thing to me. As a developer, dealing with the packaging/deployment > just comes with the job and the results, I think, are well worth the > effort. +1 SWT. I think arguments that focus on the ease of deployment are misguided because an app is *used* far more times than it is deployed, so one really should focus on the quality of the end application. In any case, deployment and packaging for different platforms is easy to automate. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt. -- Bertrand Russell -- You 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: matchure becoming clojure.contrib.match
On 25/05/2010, at 3:10 PM, Meikel Brandmeyer wrote: > Hi, > > On May 25, 2:33 am, Stuart Halloway wrote: > >> How can we get both? > > By providing a non-monolithic build? Yes, and ensuring that the subprojects use semantic versioning e.g. major version number increments on a non-backwards compatible change, and hopefully real subproject releases that one can depend on. Something doesn't have to be perfect before it's usable, so people should be encouraged to do real releases as opposed to forever staying in alpha/beta and hence never providing reliable semantic versioning drop points e.g. stable major version numbers. I only raise this point because being a subproject IME discourages major-point releases in deference to the version number of the containing project. In an ideal world of course. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Reflecting on W.H. Auden's contemplation of 'necessary murders' in the Spanish Civil War, George Orwell wrote that such amorality was only really possible, 'if you are the kind of person who is always somewhere else when the trigger is pulled'. -- John Birmingham, "Appeasing Jakarta" -- You 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: matchure becoming clojure.contrib.match
On 24/05/2010, at 1:11 PM, Drew Colthorp wrote: > A few weeks ago I announced a pattern matching library called > matchure. I'm excited to say it's being merged into clojure.contrib as > clojure.contrib.match. I'd like some feedback on ideas for some > backward-incompatible changes I'm planning to make before it's > actually pushed to clojure.contrib. ... > Anyone have an opinion? Yes - please don't put this in clojure.contrib, for two reasons: 1. The stated instruction is to not depend on clojure.contrib, and the feedback I've received when I stated that I did in fact depend on it was that I was a fool for not following the instructions i.e. RTFI. 2. clojure.contrib is a large, monolithic bag of stuff, with a single version number. So to track changes to matchure I will be forced to track all of the changes to clojure.contrib. This is made even more difficult because clojure.contrib has no backwards compatibility intention. I know you don't either, but given the large number of different components in clojure.contrib, the likelihood of breaking changes for each commit is greatly increased. It's been breaking a lot recently, and given the number of third party components that depend on it (in spite of the warning), the knock-on effect is playing havoc with configuration management. Why don't you just keep developing as matchure - there's no reason that everything destined for core needs to first pass into the quarantine zone that is clojure.contrib. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. --Stephen F Roberts -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-contrib diffs?
On 03/05/2010, at 1:06 PM, Timothy Washington wrote: > I've noticed that there are some big clojure-contrib source differences > between the 'master' branch and '1.1.0'. For example 1) 'io' is in master, > but not 1.1.0 2) json is in master, but json.read and json.write are in 1.1.0 > > I assume new developments are going into 1.1.0. But is it possible to keep > track of the lost libs like io? These are the sources I'm looking at. > • http://richhickey.github.com/clojure-contrib/ > • http://richhickey.github.com/clojure-contrib/branch-1.1.x/index.html 1.1.0 is stable. The git master is the upcoming 1.2.0 BTW: You can't depend on *anything* in contrib. It's not part of standard clojure (despite IMO being implicitly promoted that way on clojure.org) and there are no guarantees about backwards compatibility. It's been stated that contrib is a playground for new ideas that might make it into core clojure. Of course, there are many useful libraries that are only available in contrib - contrib acts as a magnet, and then infects all those useful libraries with it's "you shouldn't be using me" status. I'd like to advise you to only rely on single-purpose packages you find through dependency resolution (maven or lein) rather then the one-version-fits-all you're-a-fool-if-you-use-this indispensable big bundle of stuff that is contrib. But IMO that's not really feasible. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new. -- Steve Jobs -- You 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: HOWTO http.agent ( PUT or potential 500 )
On 03/05/2010, at 10:47 AM, Timothy Washington wrote: > Hey, ok so a noobie question here. I'm trying to use the 'http-agent' > function to make HTTP calls. I can do so easily as in fig. 1. But when I try > to make a PUT call as in fig. 2, I get a pretty ugly stacktrace, the bottom > one having the error "Caused by: java.lang.IllegalArgumentException: No > method in multimethod 'send-request-entity' for dispatch value: class > clojure.lang.PersistentStructMap" (fig. 3). > > I figure I'm doing something dumb here but can't figure out what... > 1) I've tried adding a no-op handler function (fn [agnt] ) to see if the > error goes away - nope. > 2) I tried adding the example handler function that writes the response > directly to dis - no dice > :handler (fn [agnt] (with-open [w (clojure.contrib.io/writer > "/tmp/out")](clojure.contrib.io/copy (clojure.contrib.http.agent/stream > agnt) w))) > > Is there anything obvious I'm missing here? The error is that it can't send your XML as the body. Convert the XML to a string and send that. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- You 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: Beginner's question regarding implementing a constructor using gen-class
On 30/04/2010, at 3:46 PM, Gregg Williams wrote: > Have you ever wanted to abandon a simple program with a bug that has > been DRIVING YOU CRAZY because it's just got to be something SO > simple, you'd be embarrassed to admit that you didn't see WHAT WAS > STARING YOU IN THE FACE all along? Well, this is mine: > > (ns org.InfoML.genclassObject > (:gen-class > :extends [java.lang.Object] :extends java.lang.Object (or just extends Object, because java.lang.* is automatically imported) Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince. -- You 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: seq-contains? in practice
While I have no position on seq-contains?, I question this methodology, which I've seen a few times now. It's early days for Clojure, you're sampling a very small codebase, and there may be as yet unforseen idiomatic uses (such as you point out for testing) which invalidates this argument. In addition I think you may be begging the question somewhat. Rich's explanation is more sound than this argument. On 29/04/2010, at 9:40 PM, Stuart Halloway wrote: > "In theory, there is no difference between theory and practice. In practice, > there is." -Yogi Berra (maybe). > > The recent thread on the new seq functions spun off into a theoretical > discussion about whether about the merits of having contains? and > seq-contains? as separate functions. I would like to ground that discussion > with some observations from real-world use: > > Doing an O(n) search of a seq (via includes? or, under its new name, > seq-contains?) occurs the following number of times in various libraries: > > Clojure: 0. > Contrib: 0. > Compojure:1. (and it's wrong--should be a set test) > Incanter: 0. > > (There are a few calls to seq-contains? in the test suite for contrib, and I > wrote all of them. If you write lots of unit tests you already know why such > calls make sense there.) > > Also, AFAICT, there are *no* examples of using instance checks to select the > right containment function. So the theoretical concerns about this issue > have basically no exemplars in practice. > > "In theory, you may be right about 'contains?.' In practice, Rich Hickey is > right." - Stu Halloway. :-) Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Man will never be free until the last king is strangled with the entrails of the last priest. -- Denis Diderot -- You 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: Which version of Netbeans to use Compojure on OSX?
On 22/04/2010, at 10:48 AM, Sean Devlin wrote: > I think* the SE one will work, but I haven't tested it. Yes it does. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If at first you don’t succeed, try, try again. Then quit. No use being a damn fool about it -- W.C. Fields -- You 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: Version of netbeans with extra Clojure and Polyglot Maven/Leiningen support ...
On 12/04/2010, at 3:42 PM, mac wrote: > Yes, this is very interesting and I would love to try it. > Since I do most of my programming on a mac, a .dmg file would work > fine for me. OK, I'll setup a download site with the .app for Mac users and the patches against release68_fixes for anyone else. I also have a version (1.1.1) of the Enclojure plugin that fixes the can't-find-clojure-jar when starting a project REPL (which is 100% of the time with my version of NB). I've sent a pull request to Eric, but in the meantime I'll make my version available. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 All that is required for evil to triumph is that good men do nothing. -- You 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 To unsubscribe, reply using "remove me" as the subject.
Re: New clojure support in Polyglot Maven
On 10/04/2010, at 12:24 AM, Graham Fawcett wrote: > Your building/installation instructions are a bit on the terse side, > and left this Maven newbie in trial-and-error-land. :) I haven't written any instructions, but yes, the instructions on the project aren't extensive. And the documentation that is on the sonatype site for clojure support is out of date because I don't yet have write access to the wiki yet. Sorry, I know software without good documentation is only half done. > Particularly > this statement confused me, because I don't know what an "assembly > play" is, or why I'd want one: > > After this completes, you can unzip the assembly play with polyglot > maven: > > unzip pmaven-cli/target/pmaven-*-bin.zip > ./pmaven-cli*/bin/mvn > > Or did you mean "unzip the assembly, and play with polyglot maven"? Yes. Actually, this is a bad use of the term because 'assembly' means something specific in maven land i.e. the assembly plugin that does Leiningen uberjar kind of things (on steroids, of course). > After trial-and-erroring, I gathered that after unzipping I ended up > with a 'polyglot maven' directory whose 'bin/mvn' could be used to run > tasks like 'mvn -f project.clj'. I assume that the Maven 2 instance I > used to build polyglot-maven is not modified in any way (e.g. it > wasn't retooled to be able to run 'mvn -f project.clj'). Is that > correct? No it doesn't touch existing maven installations, polyglot maven currently includes maven 3.0 alpha 7. > To use this on an ongoing basis, should I should unzip polyglot-maven > somewhere stable, and then just add the new 'polylot-maven/bin' to my > PATH? (That may seem a silly question, but maybe there's a more > Mavenish way to do these things, and I just don't know about it.) No, that's right. Although be aware that there are a few things that Maven 3.0 isn't backward compatible with yet. In particular I can't use the Atlassian plugin. > One last point -- I tried 'mvn -f project.clj' on one of my existing > Leiningen projects, and it failed because the project.clj contained > some clauses that Polyglot Maven didn't expect (:main, :compile-path). > These may not be relevant in a Maven build, but it would be nice if > they could exist in the project.clj file without causing an error when > using your tool. You've gone so far with Leiningen support already, > this would be a valuable next step. Yes, the extensive and complete Leiningen documentation indicates that there are a number of things not covered in my defproject macro :) I waver between thinking I should ignore properties I don't understand and wanting to deal with everything I possibly can, by treating unknowns as errors because you never know when that unknown property really is important. OTOH, I don't deal with Leiningen plugins and have no plans to, so maybe in this case "ignorance is bliss" is the best strategy. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Lack of will power has caused more failure than lack of intelligence or ability. -- Flower A. Newhouse -- You 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 To unsubscribe, reply using "remove me" as the subject.
Version of netbeans with extra Clojure and Polyglot Maven/Leiningen support ...
I have a private build of Netbeans that adds the following features to the maven support: 1. In the project view, Clojure srcs are listed under 'Clojure Packages' and 'Clojure Test Packages', using a package view - no more digging through directories under 'Other Sources'. 2. Polyglot Maven poms and Leiningen project.clj files appear under 'Project Files'. 3. If Polyglot Maven is set as your Maven in Netbeans Preferences, then the Project Files context menu has actions to convert pom.clj -> pom.xml, pom.xml -> pom.clj and project.clj -> pom.xml, with appropriate dependency etc. refreshing and diagnostics output. This means you can modify your project.clj/pom.clj and regenerate pom.xml, which is then picked up by Netbeans, without leaving Netbeans. This stuff can't be done in a plugin as it involves mods to core modules, and hence it will be quite some time, if ever, before it appears in official Netbeans. Is there any interest in these features, and if so, how do people suggest I make it available. I can easily post patches against the release68_fixes sources if you can build and package Netbeans yourself, or I can make an OS/X .dmg available (but not other platforms). Of course it works with the latest update-site version of Enclojure, and apart from a small bug with REPL classpath detection, that I hope is fixed soon, is really a very nice Clojure environment with useful, albeit minimal Polyglot Maven and Leiningen integration. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 All that is required for evil to triumph is that good men do nothing. -- You 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 To unsubscribe, reply using "remove me" as the subject.
Re: New clojure support in Polyglot Maven
On 08/04/2010, at 9:09 PM, Jarkko Oranen wrote: > >> Hopefully you can see that this syntax falls out of the direct construction >> of maven Model object, unmediated by intermediate syntax or data >> structuring. So there's a good reason for the way it looks. >> > > Right. Thanks for the thorough explanation. It's not so bad if you > quote the vectors instead of the individual symbols. However, it seems > to me that defmaven could very well be a plain function in that case > (just (reset! *MODEL* (apply Model args))). :) Yes, you're right. I'll make that change. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King -- You 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 To unsubscribe, reply using "remove me" as the subject.
Re: New clojure support in Polyglot Maven
On 08/04/2010, at 5:45 PM, Jarkko Oranen wrote:
> Looks cool. This should help the XML-allergic :)
>
> Though, is there a reason why all symbol arguments to defmodel have to
> be quoted? It looks rather unpleasant. Seems like you should be able
> to fix that by changing the body of defmaven to
> `(reset! *MODEL* (Model ~@(for [a args] `(quote ~a
>
> Another possible approach is to wrap the free key-value pairs in a map
> or a vector so that it's easy to quote the whole form.
The point is that the unlike defproject, the body is assumed to be executable
content, rather than just data. And you can do
:dependencies '[[org.clojure/clojure-contrib "1.2.0-SNAPSHOT"]
...
[hiccup "0.2.3"]]
which reduces the amount of quoting.
In fact, this defmaven form:
(defmaven 'org.clojure/clojure "1.2.0-master-SNAPSHOT"
:model-version "4.0.0"
:name "Lamdras Website"
:description "Acumen / LRMDS Integration"
:properties { :project.build.sourceEncoding "UTF-8" }
:packaging "war"
:dependencies [['ring/ring-servlet "0.2.0-RC2"]
['ring/ring-devel "0.2.0-RC2"]
['clj-routing/ "0.1.0-SNAPSHOT"]
['clout "0.2.0-SNAPSHOT"]
['compojure "0.4.0-SNAPSHOT"]
['hiccup "0.1.0-SNAPSHOT"]
'org.clojure/clojure
'org.clojure/clojure-contrib
'congomongo/congomongo]
:provided-dependencies [['org.mortbay.jetty/servlet-api-2.5 "6.1.14"]]
:build [:final-name "website"
:plugins [['org.apache.maven.plugins/maven-compiler-plugin "2.1"
:source "1.6" :target "1.6"]
['com.theoryinpractise/clojure-maven-plugin "1.3.1"
:sourceDirectories ["src/main/java"]
:executions [[:id "compile-clojure" :phase "compile" :goals
["compile"
['org.mortbay.jetty/maven-jetty-plugin "6.1.10"
:scanIntervalSeconds 10 :stopKey "foo" :stopPort ]]])
has an equivalent, canonical representation something like this:
(Model
:group-id "org.clojure" :artifact-id "clojure" :version "1.2.0-master-SNAPSHOT"
:model-version "4.0.0"
:name "Lamdras Website"
:description "Acumen / LRMDS Integration"
:properties { :project.build.sourceEncoding "UTF-8" }
:packaging "war"
:dependencies [(Dependency :group-id "ring" :artifact-id "ring-servlet"
:version "0.2.0-RC2")
(Dependency :group-id "ring" :artifact-id "ring-devel" :version
"0.2.0-RC2")
(Dependency :group-id "clj-routing" :artifact-id "clj-routing"
:version "0.1.0-SNAPSHOT")
(Dependency :group-id "clout" :artifact-id "clout" :version
"0.2.0-SNAPSHOT")
(Dependency :group-id "compojure" :artifact-id "compojure"
:version "0.4.0-SNAPSHOT")
(Dependency :group-id "hiccup" :artifact-id "hiccup" :version
"0.1.0-SNAPSHOT")
(Dependency :group-id "org.clojure" :artifact-id "clojure")
(Dependency :group-id "org.clojure" :artifact-id
"clojure-contrib")
(Dependency :group-id "congomongo" :artifact-id "congomongo")
(Dependency :group-id "org.mortbay.jetty" :artifact-id
"servlet-api-2.5" :version "6.1.14" scope: "provided")]
:build (Build
:final-name "website"
:plugins [(Plugin :group-id "org.apache.maven.plugins" :artifact-id
"maven-compiler-plugin" :version "2.1"
:configuration: [[:source "1.6"] [:target "1.6"]])
(Plugin :group-id "com.theoryinpractise" :artifact-id
"clojure-maven-plugin" :version "1.3.1"
:configuration [[:sourceDirectories [[:sourceDirectory
"src/main/java"
:executions [(Execution :id "compile-clojure" :phase
"compile" :goals ["compile"])])
(Plugin :group-id "org.mortbay.jetty" :artifact-id
"maven-jetty-plugin" :version "6.1.10"
:configuration [[:scanIntervalSeconds 10] [:stopKey "foo"]
[:stopPort ]])]))
where Model, Dependency, Build,. Plugin, Execution (and many more) are
functions that create e.g.
New clojure support in Polyglot Maven
I've just pushed a major update to the Clojure support in pmaven to http://github.com/sonatype/polyglot-maven. It now covers 100% of maven by reflecting over the maven object model. Examples are in the tests and in the reader.clj source file. It includes leiningen support e.g. mvn -f project.clj install should work. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King -- You 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 To unsubscribe, reply using "remove me" as the subject.
Re: Leiningen integration?
For those interested in clojure maven, I've just published http://github.com/AntonyBlakey/polyglot-maven/tree/reflective-clojure-dsl , which is a clojure front-end for polyglot maven. It could do with more testing, and documentation, but apart from dealing with namespaces and attributes in the configuration xml (trivial), and having the writer simplify it's output, it's feature-complete. It uses reflective macros over the maven object model, so it should be 100% complete coverage of maven, in very little code. Because of the lack of docs, look at the tests or the example at the end of reader.clj to see how it works. Because it's a programatic format with declarative conveniences, I hope it's fairly straightforward to understand. It also includes a leiningen defproject macro. I'm hoping to uploaded a prebuilt zip soon. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Always have a vision. Why spend your life making other people’s dreams? -- Orson Welles (1915-1985) -- You 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 To unsubscribe, reply using "remove me" as the subject.
Re: Leiningen integration?
I'm working on Clojure support for polyglot maven, and I anticipate publishing
an initial feature-complete 100%-of-Maven version today. It not only
reads/writes a programatic format like this:
(defmaven 'org.clojure/clojure "1.2.0-master-SNAPSHOT"
:model-version "4.0.0"
:name "Lamdras Website"
:description "Acumen / LRMDS Integration"
:properties { :project.build.sourceEncoding "UTF-8" }
:packaging "war"
:dependencies [['ring/ring-servlet "0.2.0-RC2"]
['ring/ring-devel "0.2.0-RC2"]
['clj-routing/ "0.1.0-SNAPSHOT"]
['clout "0.2.0-SNAPSHOT"]
['compojure "0.4.0-SNAPSHOT"]
['hiccup "0.1.0-SNAPSHOT"]
'org.clojure/clojure
'org.clojure/clojure-contrib
'congomongo/congomongo]
:provided-dependencies [['org.mortbay.jetty/servlet-api-2.5 "6.1.14"]]
:build [:final-name "website"
:plugins [['org.apache.maven.plugins/maven-compiler-plugin "2.1"
:source "1.6" :target "1.6"]
['com.theoryinpractise/clojure-maven-plugin "1.3.1"
:sourceDirectories ["src/main/java"]
:executions [[:id "compile-clojure" :phase "compile" :goals
["compile"
['org.mortbay.jetty/maven-jetty-plugin "6.1.10"
:scanIntervalSeconds 10 :stopKey "foo" :stopPort ]]])
but also reads leiningen project.clj files *unmodified*. So this is some degree
of leiningen support given NB's maven support. Polyglot maven can convert
between input formats, so it can read a leiningen project.clj and write a
pom.xml, adding the plugins required (which are actually added by the
defproject macro when the project.clj is read). You can then go from the
pom.xml to pom.clj, which produces the 'native' format shown above. It doesn't
write a leiningen project.clj.
I also have a private build of NB that integrates polyglot maven, treating all
the different pom.* language files and project.clj as 'Project Files', using
whatever pom/project file is available as maven input. Furthermore it provides
'Clojure Packages' nodes in the project explorer, so you don't have to dig
through directories under 'Other Sources'. I'm not sure how to publish these
changes yet (they can't be done as a plugin, they're core maven package mods) -
I think I need to go through some administrative rigmarole with netbeans.org
On 03/04/2010, at 11:55 AM, Eric Thorsen wrote:
> I'm disappointed that I cannot plug the clojars repo into Netbeans and
> I'm not certain what the full plan of Leiningen is in lue of the
> polyglot project (http://polyglot.sonatype.org) which appears to have
> Clojure support moved up as a first class supported language. I
> started Enclojure because I wanted to code in Clojure and have all my
> developers do the same and wanted tools to support that. I would much
> rather be defining my build scripts in Clojure but I'd hate to have to
> veer away from all that is there in Maven so the polyglot project
> would be more interesting to me than something custom just for the
> Clojure community. Netbeans, Eclipse and IntelliJ appear to do maven
> really well and I really want to spend my time working on things that
> will help me move my Clojure development forward and getting involved
> in a custom build system when maven and polyglot are around would be
> unlikely to pull me away from other features.
>
> I know Leinigen can generate pom.xml files and if your sources are in
> the appropriate directories (or the source dir is defined in the pom),
> you can work with the REPL and it will support it like any other maven
> project. It is a unidirectional path however so some of the goodies
> of being able to search through indexed repos and add them to your pom
> will have to be enter manually into your project.clj and you would
> regenerate the pom.
>
> You still get all the repl support and completion with all your
> dependancies recognized which is not nothing and may get you where you
> want to be for now.
>
> I hope this is helpful.
> Eric
>
> On Mar 17, 9:36 am, Phil Ventura wrote:
>> Are there any plans to integrate Leiningen into enclojure?
>
> --
> You received this message because you are subscribed to the Google Groups
> "enclojure" group.
> To post to this group, send email to encloj...@googlegroups.com.
> To unsubscribe from this group, send email to
> enclojure+unsubscr...@goog
Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
On 28/03/2010, at 8:01 PM, B Smith-Mannschott wrote:
> On Sun, Mar 28, 2010 at 08:39, Antony Blakey wrote:
>>
>> On 28/03/2010, at 4:42 PM, Antony Blakey wrote:
>>
>>> (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2"
>>> :add-default-plugins true
>>> :description "Simple Clojure interface to Apache CouchDB, fork of the
>>> original project with function arguments instead of *server* and some other
>>> changes."
>>> :dependencies [["org.clojure:clojure:1.1.0-master-SNAPSHOT"]
>>> ["org.clojure:clojure-contrib:1.0-SNAPSHOT"]
>>> ["org.clojure:clojure-http-client:1.0.0-SNAPSHOT"]])
>>
>> Actually, it's even simpler than that because the string-format coordinates
>> removes the need to wrap the coordinate in a vector:
>
> True, but concatenating the three coordinates together into a single
> string smells like a [first normal form][1NF] violation to me. I think
> Leiningen's notation is a better fit and more idiomatic as Clojure,
> even if it is a little more verbose to type.
Having completed this now, so I can read leningen files, the problem is that
the leiningen format needs to be quoted i.e the macro needs to transform
:dependencies [[a/b "1.0"]]
into
:dependencies '[[a/b "1.0"]]
which means that the dependencies list cannot be computed dynamically (well,
without extra syntax to unquote). It would have been ok if leiningen required
quoted symbols e.g.
:dependencies [['a/b "1.0"]]
> - Clojure code manipulating poloyglot's notation is more complex
> because it must be parsed first, and then recombined. Leiningen's
> notation already is 'parsed'.
Parsing is still required in order to deal with the optional nature of the
group id and version number e.g.
(defmulti parse-reference class)
(defmethod parse-reference clojure.lang.Symbol
[reference]
(let [artifact (name reference)
group (if-let [g (namespace reference)] g artifact)]
{:group-id group :artifact-id artifact}))
(defmethod parse-reference clojure.lang.PersistentVector
[reference]
(let [ga (parse-reference (reference 0))]
(if (and (> (count reference) 1) (= (class (reference 1)) String))
(assoc ga :version (reference 1))
ga)))
So the difference is minor.
> - Editing just the version of a dependency (or the project itself) is
> a fairly common occurrence and is somewhat more awkward if you're
> editing only *part* of a string literal, rather than a single token.
Agreed.
Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Always have a vision. Why spend your life making other people’s dreams?
-- Orson Welles (1915-1985)
--
You 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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
APSHOT"]
[org.sonatype.pmaven/pmaven-jruby
"0.8-SNAPSHOT"]
[org.sonatype.pmaven/pmaven-commands
"0.8-SNAPSHOT"]
[org.sonatype.pmaven/pmaven-clojure
"0.8-SNAPSHOT"]
[org.sonatype.pmaven/pmaven-scala
"0.8-SNAPSHOT"]]}
:test-dependencies [[junit "4.7"]
org.codehaus.groovy/groovy]
:modules ["pmaven-common" "pmaven-maven-plugin" "pmaven-groovy"
"pmaven-yaml" "pmaven-clojure" "pmaven-jruby" "pmaven-scala" "pmaven-cli"
"pmaven-commands"]
:default-goal "install"
:plugins [[org.apache.maven.plugins/maven-surefire-plugin "2.5"
:redirectTestOutputToFile true
:forkMode
"once"
:argLine
"-ea"
:failIfNoTests false
:workingDirectory "${project.build.directory}"
:excludes
["**/Abstract*.java" "**/Test*.java"]
:includes
["**/*Test.java"]]
[org.apache.maven.plugins/maven-compiler-plugin "2.0.2" :source
"1.5" :target "1.5"]
[org.codehaus.gmaven/gmaven-plugin "1.2" :providerSelection "1.7"
[:default [["generateStubs" "compile" "generateTestStubs"
"testCompile"
[org.codehaus.plexus/plexus-component-metadata "1.5.1"
[:default [["generate-metadata" "generate-test-metadata"
[org.apache.maven.plugins/maven-release-plugin "2.0-beta-9"
:useReleaseProfile false
:goals "deploy"
:arguments "-B -Prelease"
:autoVersionSubmodules true]
[org.apache.maven.plugins/maven-scm-plugin "1.2"]])
--
Note that dependencies without version numbers aren't wrapped in vectors. This
is very common in child modules because the parent specifies the version
numbers, as shown above in the dependency-management section.
Things such as :packaging have sensible defaults (in that case, "jar"), and if
:model-version and :add-default-plugins is omitted then it will assume it is a
leiningen project.clj. Therefore leiningen input files are valid polyglot maven
input files. It isn't 100% or bidirectionally interoperable because a)
leiningen plugins don't work and b) leiningen can't take the full format. Given
all of the above, the following leiningen project.clj would be valid input to
polyglot maven:
--
(defproject org.clojars.the-kenny/clojure-couchdb "0.2"
:description "Simple Clojure interface to Apache CouchDB, fork of the original
project with function arguments instead of *server* and some other changes."
:dependencies [[org.clojure/clojure "1.1.0-master-SNAPSHOT"]
[org.clojure/clojure-contrib "1.0-SNAPSHOT"]
[org.clojure/clojure-http-client "1.0.0-SNAPSHOT"]]
:dev-dependencies [[lein-clojars "0.5.0-SNAPSHOT"]
[org.clojure/swank-clojure "1.0"]])
--
There's one wrinkle to do with :dev-dependencies, which need to be ignored, but
that's trivial.
Opinions on any of this? As long as plugins could be written in Clojure (and
Scala/Ruby/Groovy presumably), would current leiningen users use polyglot maven?
Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the Spanish
Civil War, George Orwell wrote that such amorality was only really possible,
'if you are the kind of person who is always somewhere else when the trigger is
pulled'.
-- John Birmingham, "Appeasing Jakarta"
--
You 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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
On 28/03/2010, at 8:01 PM, B Smith-Mannschott wrote: > - Clojure code manipulating poloyglot's notation is more complex > because it must be parsed first, and then recombined. Leiningen's > notation already is 'parsed'. Partly parsed. The most 'correct' form would be [groupdId artifactId version] i.e. not conflating the groupId and artifactId into a single lexical value. > - Editing just the version of a dependency (or the project itself) is > a fairly common occurrence and is somewhat more awkward if you're > editing only *part* of a string literal, rather than a single token. I prefer the forms that don't invent new lexical constructs. For a start they're more amenable to manipulation using direct language facilities. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If a train station is a place where a train stops, what's a workstation? -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Can I GPL my Clojure project?
On 28/03/2010, at 5:33 PM, Stefan Kamphausen wrote: > It will be interesting how the licenses will be interpreted in Clojure > where Java and Lisp bump together. The Java-world probably had it's > discussion, too, no? The "Classpath Exception" is the principal result of this discussion: http://www.gnu.org/software/classpath/license.html Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
On 28/03/2010, at 4:42 PM, Antony Blakey wrote: > (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2" > :add-default-plugins true > :description "Simple Clojure interface to Apache CouchDB, fork of the > original project with function arguments instead of *server* and some other > changes." > :dependencies [["org.clojure:clojure:1.1.0-master-SNAPSHOT"] > ["org.clojure:clojure-contrib:1.0-SNAPSHOT"] > ["org.clojure:clojure-http-client:1.0.0-SNAPSHOT"]]) Actually, it's even simpler than that because the string-format coordinates removes the need to wrap the coordinate in a vector: (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2" :add-default-plugins true :description "Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes." :dependencies ["org.clojure:clojure:1.1.0-master-SNAPSHOT" "org.clojure:clojure-contrib:1.0-SNAPSHOT" "org.clojure:clojure-http-client:1.0.0-SNAPSHOT"]) Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
[I've cross posted because I think this is relevent to both lists] I've started fixing some bugs in the Clojure support in polyglot maven. I've sent pull requests upstream, but until then you can get it from http://github.com/AntonyBlakey/polyglot-maven. It works as my default maven (although there are some plugins such as the Atlassian stuff that doesn't work in Maven 3), and is self hosting. The simplest pom.clj, corresponding to this leiningen project: (defproject org.clojars.the-kenny/clojure-couchdb "0.2" :description "Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes." :dependencies [[org.clojure/clojure "1.1.0-master-SNAPSHOT"] [org.clojure/clojure-contrib "1.0-SNAPSHOT"] [org.clojure/clojure-http-client "1.0.0-SNAPSHOT"]] :dev-dependencies [[lein-clojars "0.5.0-SNAPSHOT"] [org.clojure/swank-clojure "1.0"]]) is: (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2" :add-default-plugins true :description "Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes." :dependencies [["org.clojure:clojure:1.1.0-master-SNAPSHOT"] ["org.clojure:clojure-contrib:1.0-SNAPSHOT"] ["org.clojure:clojure-http-client:1.0.0-SNAPSHOT"]]) The most obvious difference is in the coordinate syntax. Note that this includes the clojure-maven-plugin, so you get the following clojure-specific goals: clojure:compile clojure:test clojure:run clojure:repl clojure:swank clojure:nailgun You can package using "mvn package", and install to the local repository using "mvn install". There are many other things you can do using existing maven plugins. I have a branch that allows leiningen-format artifact references e.g. (defproject main org.clojars.the-kenny/clojure-couchdb "0.2" :add-default-plugins true :description "Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes." :dependencies [[org.clojure/clojure "1.1.0-master-SNAPSHOT"] [org.clojure/clojure-contrib "1.0-SNAPSHOT"] [org.clojure/clojure-http-client "1.0.0-SNAPSHOT"]]) The single benefit is that it would be easy to allow an existing unmodified project.clj to be used by maven, although without leiningen plugins. I'm not sure if it's worth it, and I'm interested in hearing arguments pro and con. My next step is to make sure it's easy to write polyglot maven plugins in Clojure, with easy deployment. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Choosing a Clojure build tool
I'm now using polyglot maven for a project in both NetBeans/Enclojure and
Intellij/LaClojure. The pom.clj for one of my subprojects looks like this:
--
(defproject main "com.linkuistics.lamdras:website:1.0-SNAPSHOT"
:model-version "4.0.0"
:name "Lamdras Website"
:description "Acumen / LRMDS Integration"
:packaging "war"
:properties {:project.build.sourceEncoding "UTF-8"}
:dependencies [["ring:ring-servlet:0.2.0-RC2"]
["ring:ring-devel:0.2.0-RC2"]
["clj-routing:clj-routing:0.1.0-SNAPSHOT"]
["clout:clout:0.2.0-SNAPSHOT"]
["compojure:compojure:0.4.0-SNAPSHOT"]
["hiccup:hiccup:0.1.0-SNAPSHOT"]
["org.clojure:clojure:1.2.0-master-SNAPSHOT"]
["org.clojure:clojure-contrib:1.2.0-master-SNAPSHOT"]
["congomongo:congomongo:0.1.2-SNAPSHOT"]
["jline:jline:0.9.94"]]
:provided-dependencies [["org.mortbay.jetty:servlet-api-2.5:6.1.14"]]
:final-name "website"
:plugins [["org.apache.maven.plugins:maven-war-plugin:2.1-beta-1"]
["org.apache.maven.plugins:maven-compiler-plugin:2.1"
{:configuration {:source "1.6" :target "1.6"}}]
["com.theoryinpractise:clojure-maven-plugin:1.3.1" {:executions
[{:id "compile-clojure" :phase "compile" :goals ["compile"]}]}]
["org.mortbay.jetty:maven-jetty-plugin:6.1.10" {:configuration
{:scanIntervalSeconds "10" :stopKey "foo" :stopPort ""}}]])
--
which isn't at all painful. It's early days yet, and neither IDE picks up the
pom.clj, so I have to run the translator to get a pom.xml, but that's trivial -
the command to produce pom.xml from pom.clj (and the translation is
bidirectional) is this:
translate pom.clj newpom.xml
assuming the polyglot maven translate command is on your path. Note that you
can use either maven 2 or 3 to run the resultant pom.xml.
You can use either declarative or imperative code in the pom.clj i.e. you can
call methods on the pom's object model to build up a project definition, which
you can then run using polyglot maven or translate to a pom.xml which can then
be run.
Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
On the other side, you have the customer and/or user, and they tend to do what
we call "automating the pain." They say, "What is it we're doing now? How would
that look if we automated it?" Whereas, what the design process should properly
be is one of saying, "What are the goals we're trying to accomplish and how can
we get rid of all this task crap?"
-- Alan Cooper
--
You 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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Choosing a Clojure build tool
On 26/03/2010, at 4:37 PM, Rayne wrote: > I don't think I've ever seen a language in which part of the community > shunned build tools written in the language itself. It's quite > hilarious. People aren't shunning anything because it's written in Clojure. I think that reinventing all that Maven can do, all of the IDE support, tools, documentation etc is misdirected effort. Especially given the appearance of polyglot Maven (Maven 3), which is Maven recast as a Java library that can be driven by languanges such as Clojure. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Choosing a Clojure build tool
On 26/03/2010, at 4:37 PM, Rayne wrote: > I don't think I've ever seen a language in which part of the community > shunned build tools written in the language itself. It's quite > hilarious. I've seen many examples where an overwhelming Not-Invented-Here attitude lead to failure. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Clojure/LLVM
Has anyone looked at driving LLVM from Clojure and then doing code generation to LLVM? I've had some experience doing it in a JIT context for VisualWorks Smalltalk, but I'd rather not reinvent the wheel. I'd love to be able to use Clojure on the iPad. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Did you hear about the Buddhist who refused Novocain during a root canal? His goal: transcend dental medication. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Why I have chosen not to employ clojure
On 22/03/2010, at 9:28 AM, e wrote: > And don't get me started on trying to get emacs or vi all hooked up on my > mac. I've never succeeded. I'm about to use Clojure commercially, but it's been a frustrating exercise getting setup. I've ended up using LaClojure on IntelliJ, but that wasn't trivial because of a plugin versioning issue. CCW doesn't autoindent (I know that's coming) and I've been unable to get Enclojure's project REPL to work when using Clojure 1.2. I had a stretch of using almost Emacs exclusively for 15 years, but compared to any IDE thats absolutely not newbie friendly, and not as good as an IDE IMO. In any case, the package manager hangs 80% of the time trying to grab stuff from the net. IMHO a significant sociological issue is that so many clojure devs use Emacs, are coming at this from a 'rebirth-of-lisp' POV, and seem to have adopted the cultural values of Lisp when it comes to development practices. To be successful however Clojure needs to adopt 'mainstream' values - introduce just one 'different' thing i.e. the language, rather than expecting people to adopt both the language, and a different development environment / toolchain e.g. leiningen etc (which IMO is classic NIH). You can't cross the chasm with too much baggage. Personally I don't believe this will happen unless core developers use the tools and practices that users want to use. The end-user itches and the developer itches need to be aligned. Just my $0.02. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It's amazing that the one side of the conversation that survived is "I don't know art, but I know what I like". The reply from the artist was "Madam, so does a cow". -- Carl Kirkendall -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Leiningen, Clojure and libraries: what am I missing?
On 05/03/2010, at 5:29 AM, David Nolen wrote: > On Thu, Mar 4, 2010 at 10:19 AM, Stuart Sierra > wrote: > As many of you know, I've always been tepid on lein. I'd rather go > with Maven whole-hog, because that offers the most robust model for > incorporating Java libraries. > > If Lein evolves to to handle dependencies of dependencies and intelligently > generates the classpath based on these dependencies (instead of copying files > around) what advantage does Maven really have? The tools (e.g. Archiva, Nexus et al), documentation, IDE support, integration with other languages e.g. mixed Java/Clojure/Scala/Groovy projects. The more clojure integrates with the existing ecosystem, the more likely it is to succeed, especially in a viral sense. This is the essence of clojure being a JVM language with great integration with Java. Personally I wish that leiningen effort was instead put towards polyglot maven http://polyglot.sonatype.org/ Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre -- You 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: Package manager proposal
On 07/08/2009, at 7:15 PM, Howard Lewis Ship wrote: > > Ruby and Gem is such great terminology, can we come up with something > half as cool? Closure and Resolution, are a pair of parallel hononymic puns. Or Clojure/Seal - you close the package and seal it. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre --~--~-~--~~~---~--~~ You 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: Package manager proposal
On 06/08/2009, at 8:58 PM, Daniel wrote: > Have a look at Buckminster: http://www.eclipse.org/buckminster/ > Not sure if it's going to work for non-JVM approaches (you'll probably > have to code up a plugin of some sort), but it's a meta package > manager, and can do more than just dependency resolution. For > instance, you can specify, if you would like to have a dependency as a > published Jar, or if you would like it to be checked from the version > control system, so that you can fix bugs in the dependency. > Note that this is the most under-documented project I have found in a > long time. This is the first I've heard of this project, but what about the 255 page user guide available from: http://mirror.cc.vt.edu/pub/eclipse/tools/buckminster/doc/BuckyBook.pdf ? Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If at first you don’t succeed, try, try again. Then quit. No use being a damn fool about it -- W.C. Fields --~--~-~--~~~---~--~~ You 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: Poll for a new name for clojure eclipse plugin 'clojure-dev'
eclisp :) On 24/06/2009, at 11:05 AM, Matthew Erker wrote: > > I second that vote. > (Though I prefer Clipse, which is somewhat taken.) > > > On Jun 23, 6:47 pm, Rayne wrote: >> I vote Corona. > > > Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare --~--~-~--~~~---~--~~ You 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 goes Git!
On 17/06/2009, at 10:58 AM, Antony Blakey wrote: > http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github BTW: the first episode of this is free, and includes a section called 'Send Pull Request'. It's purely about GitHub, rather than git itself. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams --~--~-~--~~~---~--~~ You 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 goes Git!
On 17/06/2009, at 10:58 AM, Antony Blakey wrote: > For anyone looking for explanatory material on git, I have, and can > therefore recommend these: > > http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git > http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github > https://peepcode.com/products/git And I forgot I had this: https://peepcode.com/products/git-internals-pdf Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 On the other side, you have the customer and/or user, and they tend to do what we call "automating the pain." They say, "What is it we're doing now? How would that look if we automated it?" Whereas, what the design process should properly be is one of saying, "What are the goals we're trying to accomplish and how can we get rid of all this task crap?" -- Alan Cooper --~--~-~--~~~---~--~~ You 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 goes Git!
For anyone looking for explanatory material on git, I have, and can therefore recommend these: http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github https://peepcode.com/products/git Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Success is not the key to happiness. Happiness is the key to success. -- Albert Schweitzer --~--~-~--~~~---~--~~ You 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 goes Git!
On 17/06/2009, at 10:37 AM, Mark Volkmann wrote: > I think you've got that backwards. A "git push" is how I would ask > the remote repo to accept my changes. A "git pull" says I want to > update my local repo with changes someone made in the remote repo. No, you can send a *request* to Rich, via GitHub, to pull from your repository. That's what a git pull *request* is - it's a request for someone else to git pull. A 'git pull' is, as you say, the command to pull commits into your repository and apply them, but that's not what Rich is talking about here. A common GitHub workflow is to fork someone's repository, clone your fork, push your changes to your GitHub fork, and then send a pull request to the owner of the 'canonical' repository that you forked from, asking them to pull certain commits from your fork. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams --~--~-~--~~~---~--~~ You 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 goes Git!
On 17/06/2009, at 10:29 AM, Mark Volkmann wrote: > On Tue, Jun 16, 2009 at 7:17 PM, Rich Hickey > wrote: > > Clojure and contrib repos are now on GitHub: > > http://github.com/richhickey/clojure > http://github.com/richhickey/clojure-contrib > > In particular, please don't send pull requests via GitHub at this > time. > > What's the reason to avoid "git pull"? Is there another way to get > updates? To send a pull *request* in git is asking a remote repository to accept *your* changes. It's how you contribute, it's not about updating your copy of the repository. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery --~--~-~--~~~---~--~~ You 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: ANN: Full, continuously updated documentation for clojure.contrib
On 05/05/2009, at 1:53 AM, Tom Faulhaber wrote: > Antony: There is a way for authors to add links either to other pages > in the wiki or externally. See DataLog and Monad for examples of how > this works. One of the issues here is that doc strings are repurposed > in a lot of ways and authors generally only want to write docs once so > we need to keep the formatting very simple and not assume that folks > will be reading the docs on the wiki. The problem with relying on links is that it separates the documentation from the code - the documentation is less likely to be written and maintained if it's not right there, with the source files, and that's ignoring the issues of tool support and version control. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: Full, continuously updated documentation for clojure.contrib
This is really good. Have you considered a mechanism for including richer documentation per contribution/namespace, ala javadocs package document e.g. html files with images etc ? On 04/05/2009, at 4:11 PM, Tom Faulhaber wrote: > > Hello everybody, > > As many of you know, I have been working on a "contrib autodoc robot" > for the last little while. > > It is now up and running and you can use the results here: > > http://code.google.com/p/clojure-contrib/wiki/OverviewOfContrib > > It includes: > * An overview of each namespace in contrib (including the author and > shortcut links to documentation for each of the functions). > * An API page for each name space that includes the doc string for > each function or variable in the namespace and a direct link to the > source for that function or variable. > * An index of all the documented functions and variables so that you > can find them by name. > * A JSON file that allows other tools to build off this information > (at http://clojure-contrib.googlecode.com/svn/wiki/ApiDocIndex.json - > still very much under development). > > Each page has a sidebar to allow for quick access from place to place. > > All the pages are stored in the wiki on the google code home for > clojure-contrib. This is both a blessing and a curse, since the google > code wiki is a little brain-dead. As a result, the formatting is not > as awesome as I would like. > > The goal of this project is to make contrib a more open and accessible > resource for the community. Please take advantage of this to see and > understand the great stuff that folks have added to contrib for your > programming pleasure. I will be making sure it is kept up-to-date > (eventually that will be automated, but for now I have to type "ant" > once in a while). > > To contrib authors: I have added metadata to your namespaces. Please > update and correct it as you would like. The updates will be > propagated to the site. Also, please review the doc for your > contributions to make sure it is complete and correct in general. Let > me know if anything doesn't seem to be going through the wringer > correctly. > > Happy perusing! > > Tom > > > Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On 21/04/2009, at 10:51 AM, Antony Blakey wrote: > On 21/04/2009, at 10:22 AM, Rich Hickey wrote: > >> I'm unfamiliar with the POM version coordinate system - any hints? > > My comment was in support of Laurent's proposal. I'm a relative > maven newb, but this is my take: > > POMs use the concept of a coordinate, which is > ::: to identify a > particular artifact e.g. library. GroupId + Artifact Id is a > qualified name - think java package name. Packaging specifies how > the artifact is packaged e.g. jar or war, but it doesn't contribute > the id of the project. Version numbers are as you expect, but can be > suffixed with '-SNAPSHOT', which effectively creates a distinct > subspace of versions ordered by creation date. By depending on a > 'a.b.c-SNAPSHOT' version, you get the latest (by date) artifact > marked with 'a.b.c-SNAPSHOT'. When you release the artifact you > remove the '-SNAPSHOT'. In effect the suffix creates two different > versioning spaces, one of which is strictly determined by the > hierarchic numeric ordering, and another that allows duplicates > ordered by date within a specific hierarchically ordered version. > AFAIK, an 'a.b.c-SNAPSHOT' version will not satisfy a request for > 'a.b.c' e.g. -SNAPSHOT is not a further qualifier. This BTW presumes a fairly simplistic dependency selection mechanism. In a previous life I did a lot of work with dependency algebras, and a far more powerful solution for managing configuration is to allow artifacts to be annotated with multidimensional versioning attributes organized by feature, using an ordered unification based configuration resolution mechanism. Somewhat like versioned requires/provides but with richer semantics. My experience was such systems are too complicated for mass deployment, and their use needs to be motivated by a significant configuration management requirement, which is why I suggest sticking to the far simpler maven/ivy POM model. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 All that is required for evil to triumph is that good men do nothing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On 21/04/2009, at 10:22 AM, Rich Hickey wrote: > I'm unfamiliar with the POM version coordinate system - any hints? My comment was in support of Laurent's proposal. I'm a relative maven newb, but this is my take: POMs use the concept of a coordinate, which is ::: to identify a particular artifact e.g. library. GroupId + Artifact Id is a qualified name - think java package name. Packaging specifies how the artifact is packaged e.g. jar or war, but it doesn't contribute the id of the project. Version numbers are as you expect, but can be suffixed with '- SNAPSHOT', which effectively creates a distinct subspace of versions ordered by creation date. By depending on a 'a.b.c-SNAPSHOT' version, you get the latest (by date) artifact marked with 'a.b.c-SNAPSHOT'. When you release the artifact you remove the '-SNAPSHOT'. In effect the suffix creates two different versioning spaces, one of which is strictly determined by the hierarchic numeric ordering, and another that allows duplicates ordered by date within a specific hierarchically ordered version. AFAIK, an 'a.b.c-SNAPSHOT' version will not satisfy a request for 'a.b.c' e.g. -SNAPSHOT is not a further qualifier. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead. -- Ron Avitzur --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On 21/04/2009, at 5:12 AM, Laurent PETIT wrote:
> To give you more ideas, there is a convention in tools like maven/ivy
> that when you're starting the hack on a branch targeting some version
> M.m.r , you immediately rename the place in code where you maintain
> the version number by appending the -SNAPSHOT keyword.
> So every build that does not remove this -SNAPSHOT suffix can not be
> mistaken with the real release.
>
> Note that such tools are not as "structured" as you suggest and just
> reserve a single field for version numbering.
>
> I think it is a good idea to add this :status attribute. It could be
> used to mark progression towards a fully featured version, as well :
>
> { :major 1 :minor 0 :release 0 :status :SNAPSHOT }
> then
> { :major 1 :minor 0 :release 0 :status :RC1 } (release candidate 1)
> then
> { :major 1 :minor 0 :release 0 :status :RC2 } (release candidate 2)
> etc.
> and finally
> { :major 1 :minor 0 :release 0 :status :GA1 } (Global Availibility 1)
Given the likelihood that pom's will be used by some people, with
maven or ivy, it would be good to have some scheme that maps to and
from the pom version coordinate system in a transparent fashion,
particularly in relation to this particular feature of that system.
Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Always have a vision. Why spend your life making other people’s dreams?
-- Orson Welles (1915-1985)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: On Stuart's Book
On 20/04/2009, at 6:13 PM, fft1976 wrote: > On Apr 19, 3:20 am, Antony Blakey wrote: > >> If I use Clojure commercially, I'll certainly pay for it. > > Please do not forget to pay for JVM, Java, Linux, tar and others. When they start asking for donations, and don't use a GPL license (which is a form of license that in effect requires that I reciprocally donate my labour, which is fine), then maybe I'll consider it. Specifically, I don't personally use Linux (I'm on OSX), Sun owns the JVM/Java brand and makes money from it, and none of the things you list are exactly niche products like Clojure. Or are you suggesting I shouldn't donate to Clojure? This is not the place for an o/s flamewar, so lets take this offlist. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 75% of statistics are made up on the spot. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: On Stuart's Book
On 19/04/2009, at 6:32 PM, Rayne wrote: > Oh, I apologize. I didn't realize that Rich wrote that for Stu's book. > I paid more attention to the insides of the book than the foreward :p. > > On Apr 19, 1:44 am, George Jahad wrote: >> On Apr 18, 3:38 pm, Rayne wrote: >> >>> So you want him to write something that Rich hasn't said on his >>> website to market his book? :\ If not you're going to clarify a bit. >> >> Rayne, I think you are getting stuck on the very point I was. It >> feels very odd paying for Stuarts book, when Rich has done so much >> and >> I've not given him a dime. Why not? There's a donation link for Clojure. You don't need to feel odd. >> It's only because Rich is strongly encouraging the book that I >> purchased it, and I suspect I'm not the only person with that >> discomfort Just for a counter data point, I have no problem paying for documentation and books - something that most o/s/ software is completely lacking. It's the task that virtually no-one wants to do (with a few significant exceptions). I've bought every Scala book available, and I'll do the same for Clojure to encourage the market for books in niche markets. If I use Clojure commercially, I'll certainly pay for it. Apart from the fact that I believe one should do so, it has the practical benefit of encouraging those who would do such work, especially in the field of development tools. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Did you hear about the Buddhist who refused Novocain during a root canal? His goal: transcend dental medication. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: On Stuart's Book
On 19/04/2009, at 8:08 AM, Rayne wrote: > > So you want him to write something that Rich hasn't said on his > website to market his book? :\ But Rich has written that - it's from Rich's forward to Stuart's book. Am I misunderstanding your point? Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On 18/04/2009, at 5:38 PM, Konrad Hinsen wrote: > > On 18.04.2009, at 01:13, Dan wrote: > >> do you prefer to have some clojure users united against subversion, >> or divided by Rich not having chosen their preferred DVCS >> (Mercurial users vs Git users, not sure whether clojure needs those >> kinds of nonsense internal wars in the community ) >> >> We seem to be unanimous in preferring git. > > Not at all. I am a convinced Mercurial user, for example, and I don't > even have git installed on my machine (I do have svn). However, I > didn't participate in this debate because I think it is pointless. > VCS issues are as much a matter of personal preference as technical > merit. It's Rich who does all of the commits, so it's for him to > choose. That's not the case for contrib. If Rich is the only committer *and contributor* to core, then it's a moot point what VCS is used for core. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A Buddhist walks up to a hot-dog stand and says, "Make me one with everything". He then pays the vendor and asks for change. The vendor says, "Change comes from within". --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
On 18/04/2009, at 11:51 AM, mikel wrote: >> It's not clear how to use the stuff in clojure-contrib, which >> certainly seems like the 'standard library' of useful tools that >> makes >> clojure into something other than a lispy language using Java >> libraries. > > > This is a good point. Using clojure.contrib is in fact extremely easy, > but it's hard to tell that from the point of view of a new user. I was > a new user recently enough to remember my initial confusion about how > to set up my development environment and how to arrange it so that > clojure.contrib was as readily accessible as it should be. I wasn't talking about how to get it on the classpath so much as documentation for the individual components in clojure-contrib. IMO those components should be broken out, and documented. I have commercial experience developing Smalltalk applications which has shown me that you *can* survive without extensive documentation iff you have fantastic code navigation and exploration. I'm not talking about find-doc et al, but some way of navigating live code. So when I say that documentation is necessary, I admit that one alternative would be a code navigation tool as part of the core. One way to do this would be an ultra-lightweight server as part of core that serves up a hyperlinked cross-ref view of the source, ala the Smalltalk Browser. I don't think this should be relegated to the individual IDEs. The weakness of the Smalltalk approach as compared to javadoc (say) is that it's easy to cop out and regard functional-level documentation is being sufficient, whereas you also require architectural/expository documentation, and that really needs to be rich e.g. package level javadoc as opposed to class/method level documentation. I think some mechanism to do that is required. My overall point being that there is a conflict in knowing that documentation is absolutely required for mass-acceptance and arms- length use and yet knowing that documentation generally won't be written and even when it is, it needs to be integrated. IMO javadoc is a significant reason for the success of java, and something at least as good, and preferably live and reflective, is required for Clojure. I get the feeling that for the purposes of a book about the language, 1.0 is pretty much ready now, although wasn't there something about method dispatch / hierarchies that Rich was looking at? Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
As a lurker, considering Clojure for a project, the thing that is giving me pause isn't 1.0 per se, but the combination of a good library mechanism and documentation. I have Stuart's book, and I agree in the strongest possible terms that it should be a book explicitly about a stable Clojure 1.0. The choice for me is between Scala and Clojure, and the languages themselves are not a discriminator - it's the environments around the languages that determine the outcome. It's not clear how to use the stuff in clojure-contrib, which certainly seems like the 'standard library' of useful tools that makes clojure into something other than a lispy language using Java libraries. Please don't under-estimate the extent to which good documentation, an obvious and clean code base (which clojure-contrib isn't) and a documented story for packaging and managing extensions/contributions, gives the impression of quality, at least with respect to the kind of 'quality' that comforts and convinces arms-length users. The website is quite good in some of those respects for clojure core. Also +1 for moving to git and github - in my experience it motivates contributions/contributors because it is such a low-barrier platform for collaborative/experimentation. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Has anyone on this group ever tried Forth?
On 11/04/2009, at 12:53 PM, e wrote: > J seems cool, and, from what I understand, is a descendant of > forth. How does Factor compare to J? J is a descendent of APL, done by the late Ken Iverson, the creator of APL. A big change is the substitution of ASCII for the traditional APL operators. More convenient, but for me it loses some of the charm of APL. Not at all Lispy. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A priest, a minister and a rabbi walk into a bar. The bartender says "What is this, a joke?" --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Has anyone on this group ever tried Forth?
On 10/04/2009, at 4:43 PM, CuppoJava wrote: > > Hi everyone, > I was browsing through webpages and the language Forth caught my eye. > Reading through it's supposed advantages it sounded very interesting, > and I was wondering if anyone here has any experience with it, and can > comment. > > I'm asking on the Clojure forum instead of the Forth forum because I > agree with the programming values that Clojure emphasizes, and would > like to hear opinions from people with similar values to myself. > > I'm most interested in it's productivity aspect. (ie. how quick can I > get real work done) If you are interested in Forth you should probably check Factor at http://factorcode.org/ Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Scala vs Clojure
On 01/04/2009, at 1:26 PM, Rayne wrote: > > Unless they slowed down, the pace in which Enclojure was improving > would put me dead on. Neither the site nor the mailing list shows a lot of activity - it's not dead, but it is taking a long time compared to the IntelliJ support, which was my point. > I personally use IntelliJ IDEA. But who says I > paid for it? I'm not sure what point you are making. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Don't anthropomorphize computers. They hate that. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Scala vs Clojure
On 01/04/2009, at 10:01 AM, e wrote: > but the InteliJ IDE isn't free, is it? So what? I'm a professional developer. I make money using these tools. The money people pay for IntelliJ is one reason that the Scala support in IntelliJ is more ambitious and why the IntelliJ Clojure plugin is more advanced. I'd happily pay for NetBeans or Eclipse, and/or support for Clojure and Scala. I buy a lot of software, and when I use good O/ S software, I donate $ to support it e.g. Firebug. IntelliJ is cheap for a personal license (USD$249). Even VisualWorks Smalltalk, for which I pay 5% of my gross billings, is good deal because the productivity benefits pay for themselves. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 He who would make his own liberty secure, must guard even his enemy from repression. -- Thomas Paine --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Fresh Clojure Tutorial
On 01/04/2009, at 10:47 AM, Laurent PETIT wrote: > Something that can be thought of as "workable specs" for the GUI, > where one does not have to switch language from one abstraction > level to the other. You should have a look at the Scala wrapping of SWT. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A Buddhist walks up to a hot-dog stand and says, "Make me one with everything". He then pays the vendor and asks for change. The vendor says, "Change comes from within". --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Scala vs Clojure
On 28/03/2009, at 5:21 PM, Rayne wrote: > I'd say Enclojure is close to > production-ready. From my playing with it, plus the list of things not yet done, I don't think this is true. The IntelliJ clojure support seems more advanced right now, and I'm starting to use that in production. IMO the new NetBeans 6.7 L&F on OSX now looks better than any other java IDE on OSX (but enclojure doesn't run on it). If enclojure did formatting and ran on 6.7 I'd probably choose that for Clojure development, although another consideration is that if you want to do mixed Scala/Clojure development, IntelliJ's Scala support has considerably loftier goals than Eclipse/NetBeans e.g. first-class support for the language model wrt refactoring etc. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Lack of will power has caused more failure than lack of intelligence or ability. -- Flower A. Newhouse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Namespaces, use, and refer
On 02/03/2009, at 7:23 PM, Konrad Hinsen wrote: > For namespaces other than clojure.core, an acceptable solution is to > use the :only keyword in the :use clause of the ns macro. This just > requires a bit more work in typing, but I don't see any other > potential difficulty. I am currently converting all my code to > use :only, and I haven't had any bad surprises until now. For > clojure.core, listing all imported symbols explicitly would be a real > pain, but I don't see any other simple solution. I just hope someone > else does :-) I'm a clojure newb, but couldn't you reflect on a given version to generate an import file that used :only to import every name visible in that version? Then you could import that file, which would be a version constant (although I'm not clear yet if clojure allows transitive imports). It should be easy to generate such a file privately for any given snapshot (although I imagine it would be best as an official version artifact). Alternatively of course every name could be tagged with version metadata and import enhanced to take a version spec, but that seems far more intrusive (and in any case precisely equivalent to my first suggestion). Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
