Re: Miscellaneous noob questions
Jared wrote: I'm a little confused over when to use a var vs. a ref vs. an agent vs. an atom. For writing small (<200 lines) single-threaded programs when do I want to use each one? ref - When you need to mutate multiple things together synchronously. atom - When you need to mutate a single thing synchronously. agent - When you need to mutate a single thing asynchronously. var - Only for top level bindings which can be mutated globally or on a per-thread basis. All of the above are thread-safe and can be used to build concurrent applications; which one you choose is entirely your decision. Clojure provides you all the tools that you *might* need. You just have to be responsible about using those tools. Hope that helps. Shoot back if you have more questions. Regards, BG -- Baishampayan Ghose oCricket.com -- You 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: Miscellaneous noob questions
Hi, On Jun 18, 9:01 am, Baishampayan Ghose wrote: > ref - When you need to mutate multiple things together synchronously. I'd like to add: When you need to mutate one thing several times synchronously. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Richard Newman writes: > 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, This nicely summarizes my thoughts. The other parts of Rich's notes seem very elegant, but I can see lack of promotion leading to problem in my own code. Some external input causing an intermediate result to overflow would certainly happen. Probably at the least convenient time possible. (Have we discarded the concept of a set of non-promoting math functions that are only used during optimization? prim-+ prim-/ etc.) Cheers, Chris Dean -- You 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
Dear all, just finished to read the proposals. - prim is great and would allow to keep performance in more idiomatic code - I am pro-num. It allows to get read of plenty of annotations or java methods. Annotations are difficult for beginners, makes code hard to read, maintain and modify, even for experts. Moreover, in those days of 64-bits integers, the need for bigint is quite rare, except for Fibonacci or factorial functions ;-b. That's a bit provocative, but I think most code that needs bigints are "number-centric" code. I mean code whose primary interest is the treatment of numbers. Whereas every single program suffers from annotation or boxing. Currently, all programs have to pay (annotations, speed, and/or java code). I feel it is fairer that a few programs, that have high expectation on numbers, should pay. I think, however, it is important we ensure they have a way to pay. And that it is not too expensive. Maybe, it could be interesting to keep the old behaviour in safe-+, safe-* and the like? Or, as Rich said, to make a good big numbers implementation that scales well to small integers. Maybe, there should be a compiler option for default arithmetic : * choose from long (the default default), int (for people wanting to run clojure on a mobile phone), FastAndCleverBigNums (for people caring about safety and having unusually big numbers) * the same could be made for default decimal arithmetic. One of the great benefit of num, is that it allows: - equal, which is a big step forward. Altogether, I like very much the fact that these proposals, together with protocols and datatypes, gives a way to obtain high performance Clojure code in a Java-agnostic way. It seems a good thing for clojure in clojure and porting to other platforms. Best regards, Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On a totally different point: is there a way of having he equivalent of #^final/#^static for defs? Sometimes, you know a def won't be dynamically bound/redefined. Would there be a benefit for the JITed code (less memory barriers or more asm reordering) to give a way to pass this information to the JVM? Best, Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Fri, Jun 18, 2010 at 8:58 AM, Richard Newman wrote: > 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. It can already happen: a library can screw you by design. (defn fact [n] (loop [r (int 1) n (int n)] (recur (* r n) (dec n user=> (fact 40) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0) Actually people who want numerical perfs have to do very invasive type hinting and other interfaces workaround because primitives are... primitives (not objects). With contagious bigints (let's nick name them "safeints" and assume they are not BigInteger but something à la kawa) a single N on literals or having all your inputs going through a safeint conversion would trigger safe computations (unless you try to call a static primitive-hinted fn but the compiler would then bark). Of course a rogue fn can still internally convert to primitives and overflow but you can't do anything to protect you from that. As for mixing several numebr representations in a single collection, I think it's a problem of normalizing data but most of the time your are either in safeland or in fastland so your representations will be homogeneous (safehints or (boxed) primitives). A middleground may be to keep the semantics proposed by Rich but: * integer literals default to safeint (unless suffixed by L for long) * scientific notation and decimal literals default to double (unless suffixed by M or N) * implement a better bigint. Christophe -- European Clojure Training Session: Brussels, 23-25/6 http://conj-labs.eu/ Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.cgrand.net/ (en) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Miscellaneous noob questions
Hi, On Jun 18, 12:12 pm, Baishampayan Ghose wrote: > Yep. Thanks for the correction, Meikel. I would say "addition", not "correction". What you said is was absolutely correct. :) Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Miscellaneous noob questions
Meikel Brandmeyer wrote: ref - When you need to mutate multiple things together synchronously. I'd like to add: When you need to mutate one thing several times synchronously. Yep. Thanks for the correction, Meikel. Regards, BG -- Baishampayan Ghose oCricket.com -- You 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 June 2010 05:57, Mark Engelberg wrote: > I assume that most Clojure users really like its dynamic nature. If > this is true, then for most of us, the common case is to NOT annotate > our code with types. Certainly I like the idea of making it as easy > as possible to write fast code in Clojure. I want my dynamically > typed code to be as fast as it can be, and it's nice to know that > there is a way to write statically typed code that is even faster. > But I really don't want to incur a penalty (i.e., possibility of > Arithmetic Exception) when I'm not using type annotations. > > I agree that the burden on those who want to write type annotated code > is too high. I agree that this should be made easier. But > ultimately, I still want the burden to be on them (or me, the 1% time > I need it), not those of us who prefer unannotated code. I that some > of the changes you have proposed for moving the annotations into the > header, along with literal notation for long (i.e., 0L rather than > (long 0)) would be preferable to the bigint dichotomy. QFT -- I'm in absolute agreement. It seems to me that in its current shape, the new design -- actually the "no automatic promotion/demotion" part -- would amount to sacrificing correctness for performance *by default*; that doesn't strike me as a good way to go. Not a single language I like using does that... this of course includes my favourite language, Clojure, as it currently stands on the master branch. :-) Part of the reason why I think this is a bad idea is that while it is all very well to say that people should know what they're doing, libraries should be well-designed and have excellent test coverage etc., this is not what happens in practice. (It's also perfectly possible to write correct concurrent programmes with locks...). And not necessarily through lack of dilligence; I know I have learned many a gotcha by getting bitten by it (and rather expect to accumulate plenty more "bites" in the years to come). I suppose that's fine as long as one is learning something useful in the process, but I should think that top numeric performance is something required only by a certain part of the community -- a sizeable one, no doubt, but hardly a majority share -- in fact comprising the people most likely to know what they're doing when dealing with numbers (why would someone *not* doing involved numeric computations know what s/he's doing with numbers on a comparable level to someone who is?). Making things significantly easier for them would be welcome, of course, but perhaps not at the cost of making *everyone* deal with entirely new kinds of complexity to support that. I wouldn't know if the "good" solution Antony Blakey mentions is feasible currently, but if it isn't, I'd prefer the language to err on the side of caution, while perhaps offering a better system for hand-annotating things for top performance (some people have been using pretty ingenious macros to ease things a little -- perhaps these could be improved upon to produce an acceptable close-to-universal solution)? Right, so these are my initial impressions. I'll continue thinking about this, the new developments do seem attractive in many ways (^:static is very cool indeed!) and I'm curious to see if I might be able to bring myself to see more positive sides to the long/bigint split (as well as come to an opinion on the equals issue). All the best, Michał -- You 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
Just tried out num branch and I really like how easy it is to be fast! However... Consider: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) (defn twice-fact [n] (fact (fact n))) (defn bad-twice-fact [n] (fact (-> n fact range last inc))) user=> (fact (fact 5)) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:3) user=> (fact (fact 5N)) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user=> (twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:5) user=> (twice-fact 5N) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user=> (bad-twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:7) user=> (bad-twice-fact 5N) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:8) > Don't buy it. That's the whole point of BigInt contagion. If fact and foo > are correctly written this will work. BigInt contagion doesn't help if in some convoluted manner a BigInt's value is used to construct a primitive sufficiently large that later causes an overflow. It'd sure be nice if I could just write ((safe bad-twice-fact) 5) and get back a BigInt. Maybe ((safe foo) x) can ensure all arguments and return values of function foo are boxed, and recursively, ensures boxing of arguments and return values for all functions called by foo, etc. Is that possible? Would that guarantee safety? Carson On Jun 17, 11:35 pm, David Nolen wrote: > On Fri, Jun 18, 2010 at 2:10 AM, Mark Engelberg > wrote: > > > Elaborating on Anthony's explanation, let's say you call (fact (foo n)). > > 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. > > > > (defn fact [n] > (if (zero? n) 1N (* n (fact (dec n) > > (defn foo [n] > (inc n)) > > (fact (foo 40)) > (fact (foo 40N)) > > Both work. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
compiling the instructions of a simple vm into a function
Recently, I implemented last year's ICFP problem. Part of it is writing a VM that consists of memory slots, some registers and input and input ports. It takes a list of instructions, works them off one after the other, reading from input or memory, calculating something and the changing registers or writing to memory or output. My implementation worked, but I wanted to make it faster, and thought compiling the instructions into a function using a macro could help. Indeed, my vm got 5 times faster, using arrays and an imperative style (generated by the compiler). But the macro I wrote is butt-ugly, so I thought I might get some advice on this list... To keep it simple I'll use an even simpler VM that only has memory and a simple instruction set. Example of an instruction: [+ 2 3] That means: read memory at address 2, read memory at address 3 and write the sum of both values back to address 2. This is how I use the compiler macro, feeding in 3 instructions: user=> (def compiled (compile-instructions '([+ 2 3] [- 0 1] [+ 1 0]))) #'user/compiled user=> (fn? compiled) true Now let's allocate an int array for the memory, using a size of 4 slots: user=> (def memory (into-array Integer/TYPE (range 4))) #'user/memory user=> (seq memory) (0 1 2 3) And now let's run the instructions on that memory: user=> (compiled memory) 0 user=> (seq memory) (-1 0 5 3) And finally, here comes the code for the macro - but be warned, I'm lacking formal macro education, which is why I'd appreciate any good comment: (defmacro compile-instructions [instructions] (let [memory (gensym "memory-")] (apply list 'fn [memory] (map (fn [[op m1 m2]] (list aset memory m1 (list op (list aget memory m1) (list aget memory m2 (eval instructions) I'm not using the backtick as it seemed simpler for what I was trying to do. I don't know if eval is evil and there's a better alternative? I'm actually not so sure whether it is good to roll out all instructions for performance. It might makes things actually slower, as the JIT can compile less, apart from the fact that a Java method is limited to 64k in size, so the number of instructions I can compile is limited: user=> (def compiled (compile-instructions (take 1150 (cycle '([+ 2 3] [- 0 1] [+ 1 0]) java.lang.ClassFormatError: Invalid method Code length 65581 in class file user$compiled__97 (NO_SOURCE_FILE:25) It blows up at just above 1k instructions. -- You 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 Fri, Jun 18, 2010 at 11:47 AM, Carson wrote: > Don't buy it. That's the whole point of BigInt contagion. If fact and foo > > are correctly written this will work. > > BigInt contagion doesn't help if in some convoluted manner a BigInt's > value is used to construct a primitive sufficiently large that later > causes an overflow. > > > I would like to see that in real examples. And not in something that tend to be mainly a program that crunch numbers. (I think a program "about numbers" could take a bit of complexity to handle numbers. If you write a program to that generates web page, you agree to have an html library and not have "every structure in clojure is html".) On the other hand, programs that have few number computations - mainly to handle a few stats and indices - but that are spread in a lot of code (I think most program are like that) should benefit from good performance without annotating all the code. -- You 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 Jun 18, 2:44 am, Christophe Grand wrote: > With contagious bigints (let's nick name them "safeints" and assume > they are not BigInteger but something à la kawa) a single N on > literals or having all your inputs going through a safeint conversion > would trigger safe computations (unless you try to call a static > primitive-hinted fn but the compiler would then bark). I think the example (defn bad-twice-fact [n] (fact (-> n fact range last inc))) shows it takes more than safeint conversion of arguments to the "surface" function to trigger safe computations. All functions called by the "surface" function needs to have their arguments converted to bigints too, and their return values probably, just in case. Although I'm not sure if even that's enough without auto-promotion (if I understand auto-promotion correctly...). But note the example doesn't even use any type hints or explicit conversion to primitives (the point is the conversion may occur as a legitimate side effect of doing something else). *Still*, I'm in favour of fast by default, with an *easy* way to make things safe as an option. > > Of course a rogue fn can still internally convert to primitives and > overflow but you can't do anything to protect you from that. > > As for mixing several numebr representations in a single collection, I > think it's a problem of normalizing data but most of the time your are > either in safeland or in fastland so your representations will be > homogeneous (safehints or (boxed) primitives). > > A middleground may be to keep the semantics proposed by Rich but: > * integer literals default to safeint (unless suffixed by L for long) > * scientific notation and decimal literals default to double (unless > suffixed by M or N) > * implement a better bigint. > > Christophe > > -- > European Clojure Training Session: Brussels, 23-25/6http://conj-labs.eu/ > Professional:http://cgrand.net/(fr) > On Clojure:http://clj-me.cgrand.net/(en) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Jun 18, 4:22 am, Nicolas Oury wrote: > On Fri, Jun 18, 2010 at 11:47 AM, Carson wrote: > > Don't buy it. That's the whole point of BigInt contagion. If fact and foo > > > are correctly written this will work. > > > BigInt contagion doesn't help if in some convoluted manner a BigInt's > > value is used to construct a primitive sufficiently large that later > > causes an overflow. > > > I would like to see that in real examples. And not in something that tend > > to be mainly a program that crunch numbers. > (I think a program "about numbers" could take a bit of complexity to handle > numbers. > If you write a program to that generates web page, you agree to have an > html library and not have "every structure in clojure is html".) I agree! Sorry I have no real examples, just my contrived example. But note the example I used isn't *that* contrived, in the sense that it doesn't use any type hints or explicit conversion to primitives to cause an overflow on purpose. The point is that the overflow may occur as a legitimate side effect of doing something else, whereas it currently will not. And *still*, I'm in favour of fast by default, with an *easy* way to make things safe as an option. The key is to make the safe option *easy*. > On the other hand, programs that have few number computations - mainly to > handle a few stats and indices - but that are spread in a lot of code > (I think most program are like that) should benefit from good performance > without annotating all the code. -- You 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
I'm no expert in this field. What I would like to avoid, is having to become expert in the field to expect the prevention of more : * nightmare debug sessions because of my own code or third party libraries code * crash in production code which might derive from the choices. I tend to think that it seems wrong to require more knowledge from people wanting to write *more* correct code than from people wanting to write faster/performant code. This is were I would place the cursor. 2010/6/18 Carson : > On Jun 18, 2:44 am, Christophe Grand wrote: >> With contagious bigints (let's nick name them "safeints" and assume >> they are not BigInteger but something à la kawa) a single N on >> literals or having all your inputs going through a safeint conversion >> would trigger safe computations (unless you try to call a static >> primitive-hinted fn but the compiler would then bark). > > I think the example > (defn bad-twice-fact [n] (fact (-> n fact range last inc))) > shows it takes more than safeint conversion of arguments to the > "surface" function to trigger safe computations. All functions called > by the "surface" function needs to have their arguments converted to > bigints too, and their return values probably, just in case. Although > I'm not sure if even that's enough without auto-promotion (if I > understand auto-promotion correctly...). But note the example doesn't > even use any type hints or explicit conversion to primitives (the > point is the conversion may occur as a legitimate side effect of doing > something else). > > *Still*, I'm in favour of fast by default, with an *easy* way to make > things safe as an option. > > >> >> Of course a rogue fn can still internally convert to primitives and >> overflow but you can't do anything to protect you from that. >> >> As for mixing several numebr representations in a single collection, I >> think it's a problem of normalizing data but most of the time your are >> either in safeland or in fastland so your representations will be >> homogeneous (safehints or (boxed) primitives). >> >> A middleground may be to keep the semantics proposed by Rich but: >> * integer literals default to safeint (unless suffixed by L for long) >> * scientific notation and decimal literals default to double (unless >> suffixed by M or N) >> * implement a better bigint. >> >> Christophe >> >> -- >> European Clojure Training Session: Brussels, 23-25/6http://conj-labs.eu/ >> Professional:http://cgrand.net/(fr) >> On Clojure:http://clj-me.cgrand.net/(en) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
2010/6/18 Carson : > And *still*, I'm in favour of fast by default, with an *easy* way to > make things safe as an option. The key is to make the safe option > *easy*. The solution is easy: write java code by default, and clojure code when you want to be safe :-p -- You 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
I too think that "correct by default" is a much better idea than "fast by default." One way I think about this is that the meaning of +, for example, is the sum of its numeric arguments. The performance characteristics are not part of this core meaning, although of course everyone will be happier the better the performance is. Nonetheless, I think that the meaning should be correctly maintained as a first priority, and that means giving the right answer regardless of how many bits are needed. I frequently produce BigIntegers, even in code that's not particularly math-heavy. It has always galled me that in most programming languages any such code breaks because of low-level implementation issues that I don't want to have to think about most of the time. I usually just want the right answer, and I certainly don't want to have to think about the binary representations every time I write code that handles numbers. If I find that my code is too slow then I'll have to think about it, and that's when it makes sense to have to deal with declarations or type hints or special faster unsafe arguments or whatever. Ideally this will take as little work as possible, but I think it'd be a bad approach to make fast free (default) at the cost of saying "but the meaning of + may not actually be numeric sum, and this depends on the number of bits required to represent your numbers, so you better always be thinking about low level representation stuff whenever you use numbers." -Lee On Jun 18, 2010, at 8:10 AM, Laurent PETIT wrote: > I'm no expert in this field. > > What I would like to avoid, is having to become expert in the field to > expect the prevention of more : > > * nightmare debug sessions because of my own code or third party > libraries code > * crash in production code > > which might derive from the choices. > > I tend to think that it seems wrong to require more knowledge from > people wanting to write *more* correct code than from people wanting > to write faster/performant code. This is were I would place the > cursor. > > 2010/6/18 Carson : >> On Jun 18, 2:44 am, Christophe Grand wrote: >>> With contagious bigints (let's nick name them "safeints" and assume >>> they are not BigInteger but something à la kawa) a single N on >>> literals or having all your inputs going through a safeint conversion >>> would trigger safe computations (unless you try to call a static >>> primitive-hinted fn but the compiler would then bark). >> >> I think the example >> (defn bad-twice-fact [n] (fact (-> n fact range last inc))) >> shows it takes more than safeint conversion of arguments to the >> "surface" function to trigger safe computations. All functions called >> by the "surface" function needs to have their arguments converted to >> bigints too, and their return values probably, just in case. Although >> I'm not sure if even that's enough without auto-promotion (if I >> understand auto-promotion correctly...). But note the example doesn't >> even use any type hints or explicit conversion to primitives (the >> point is the conversion may occur as a legitimate side effect of doing >> something else). >> >> *Still*, I'm in favour of fast by default, with an *easy* way to make >> things safe as an option. >> >> >>> >>> Of course a rogue fn can still internally convert to primitives and >>> overflow but you can't do anything to protect you from that. >>> >>> As for mixing several numebr representations in a single collection, I >>> think it's a problem of normalizing data but most of the time your are >>> either in safeland or in fastland so your representations will be >>> homogeneous (safehints or (boxed) primitives). >>> >>> A middleground may be to keep the semantics proposed by Rich but: >>> * integer literals default to safeint (unless suffixed by L for long) >>> * scientific notation and decimal literals default to double (unless >>> suffixed by M or N) >>> * implement a better bigint. >>> >>> Christophe >>> >>> -- >>> European Clojure Training Session: Brussels, 23-25/6http://conj-labs.eu/ >>> Professional:http://cgrand.net/(fr) >>> On Clojure:http://clj-me.cgrand.net/(en) >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options,
Re: Miscellaneous noob questions
> I'm a little confused over when to use a var vs. a ref vs. an agent > vs. an atom. For writing small (<200 lines) single-threaded programs > when do I want to use each one? In addition to the great answers you got here, you could have a look at my screencast series on vars, refs, agents, and atoms: http://link.pluralsight.com/clojure Ignore the (unfortunate) prominence of the Silverlight player - the "mobile" button will give you downloads in all sorts of formats. -- You 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 Fri, Jun 18, 2010 at 6:47 AM, Carson wrote: > (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) > (defn twice-fact [n] (fact (fact n))) > (defn bad-twice-fact [n] (fact (-> n fact range last inc))) > Not only is it contrived, under the proposal, this implementation of fact is broken. It needs to be fixed to: (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) With that change bad-twice-fact is not actually bad. As Christophe Grand has mentioned one of the main things that is be complained about from the BigInt supporters *is already a problem* in Clojure. Nothing new to see here. Finally having actually tried out the new branches, this is a good change for me. I'd like to hear more from the BigInt crowd about whether getting their code to work with the new branches is actually causing problems. So far it just seems like talk. -- You 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
+1 to safe-by-default. I use clojure for games, but if it will be possible to easily make computations fast, safe-by-default is more important. -- You 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 Jun 18, 2010, at 1:23 AM, Mark Engelberg wrote: On Thu, Jun 17, 2010 at 9:20 PM, David Nolen wrote: The problem is that it distinctly *not* easy to write fast numeric code in Clojure. It requires expert Clojure knowledge. Right, but with just the prim branch and a shorthand for long literals, you get: (defn ^:static fib ^long [^long n] (if (<= n 1L) 1L (+ (fib (dec n)) (fib (- n 2L) which really isn't that bad. So my claim is that the prim branch gets you far enough along the road to easy fast numeric code, without screwing with the numeric tower. This L suffix idea is a non-starter. Here's why: We're in a reader based language. The reader reads objects. When the reader reads 42, it must return an object. It cannot return an int or a long primitive. Right now, it returns an Integer. I've also conducted experiments where it returned a Long. Certainly 420 will be a Long. What different thing would the reader return given 42L, or 420L? Given an int 42 what should the printer print? And long 42, Long 42? Would (= 42L (read-string (pr-str 42L)))? -- The second thing I don't see being acknowledged is that the real problem here is the semantic difference. It's not a matter of getting at a primitive operation when handed a boxed number - that already happens, and pretty efficiently. It is the fact that the results have to go somewhere, and the difference in 'where' creates a difference in semantics. In master right now: (+ x y) and (+ (identity x) y) can produce different results. We already have bug reports around this, and user confusion. Fixing it requires adopting a single semantic for +. Choosing auto-promotion precludes the use of + on primitives, a huge loss IMO. Choosing throw-on-overflow precludes auto- promotion, but preserves polymorphism otherwise, and gives the compiler free reign to optimize since it will never be altering the semantics by doing so. I don't see a way around this fundamental dichotomy. The semantics for + should be unified, and the operator that makes the other choice needs to be called something else, or placed somewhere else. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Problems with URL params and http-agent
Hmm, this is a good idea and I got the GET request string as...
*/exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declare
default element namespace 'com/interrupt/bookkeeping/users';//user[
@id='one']*
This exact URI (behind http://localhost:8080) works when used by the
browser, or wget. The service is a RESTful interface around the eXist XML
DB. And I'm suspecting the DB is returning the correct result, I'm just not
handling it somehow in clojure. I though my code was pretty straight forward
(carbon copy of Stuart Halloway's handler).
(clojure.contrib.http.agent/result (clojure.contrib.http.agent/http-agent "
http://localhost:6300/exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declaredefault
element namespace 'com/interrupt/bookkeeping/users';//user[
@id='one']"
:method "GET"
:header {"Content-Type" "text/xml"}
:handler (fn [agnt]
(with-open [w (clojure.contrib.io/writer "/tmp/out")]
(clojure.contrib.io/copy (clojure.contrib.http.agent/stream agnt) w))
)
)
)
Hmmm
Tim
On Thu, Jun 17, 2010 at 2:26 PM, Jim Blomo wrote:
> On Wed, Jun 16, 2010 at 6:21 PM, Timothy Washington
> wrote:
> > Hey all, something very weird happens when trying to use the http-agent.
> If
> > I execute a) or b) in a browser, I get the desired result XML.
> > a) http://RESTful/path/to/xml
> > b) http://RESTful/path/to/xml?_wrap=no&_query=declare default element
> > namespace 'com/interrupt/bookkeeping/users';//user[ @id='one']
>
> It's hard to say without the specific error you're seeing and what
> service you're hitting, but one technique I've used for debugging HTTP
> calls is to setup netcat on another port. Then make the same requests
> with the browser and library to the new port and compare netcat's
> output. Perhaps they are escaping the paths differently. Cheers,
>
> Jim
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problems with URL params and http-agent
Oh... and the /tmp/out file is empty.
Tim
On Fri, Jun 18, 2010 at 8:53 AM, Timothy Washington wrote:
> Hmm, this is a good idea and I got the GET request string as...
> */exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declare
> default element namespace 'com/interrupt/bookkeeping/users';//user[
> @id='one']*
>
> This exact URI (behind http://localhost:8080) works when used by the
> browser, or wget. The service is a RESTful interface around the eXist XML
> DB. And I'm suspecting the DB is returning the correct result, I'm just not
> handling it somehow in clojure. I though my code was pretty straight forward
> (carbon copy of Stuart Halloway's handler).
>
> (clojure.contrib.http.agent/result (clojure.contrib.http.agent/http-agent
> "
> http://localhost:6300/exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declaredefault
> element namespace 'com/interrupt/bookkeeping/users';//user[
> @id='one']"
> :method "GET"
> :header {"Content-Type" "text/xml"}
> :handler (fn [agnt]
> (with-open [w (clojure.contrib.io/writer "/tmp/out")]
> (clojure.contrib.io/copy (clojure.contrib.http.agent/stream agnt) w))
> )
> )
> )
>
>
> Hmmm
> Tim
>
>
> On Thu, Jun 17, 2010 at 2:26 PM, Jim Blomo wrote:
>
>> On Wed, Jun 16, 2010 at 6:21 PM, Timothy Washington
>> wrote:
>> > Hey all, something very weird happens when trying to use the http-agent.
>> If
>> > I execute a) or b) in a browser, I get the desired result XML.
>> > a) http://RESTful/path/to/xml
>> > b) http://RESTful/path/to/xml?_wrap=no&_query=declare default element
>> > namespace 'com/interrupt/bookkeeping/users';//user[ @id='one']
>>
>> It's hard to say without the specific error you're seeing and what
>> service you're hitting, but one technique I've used for debugging HTTP
>> calls is to setup netcat on another port. Then make the same requests
>> with the browser and library to the new port and compare netcat's
>> output. Perhaps they are escaping the paths differently. Cheers,
>>
>> Jim
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problems with URL params and http-agent
That's a good idea which I tried. But no dice. I have a feeling I'm not handling the response properly in Clojure. See my other posts here. Tim On Thu, Jun 17, 2010 at 3:57 PM, RandyHudson wrote: > You don't want to encode the whole URL, just the keys and values in > the query string. Something like this: > > (defn encode-params [request-params] > (let [encode #(URLEncoder/encode (str %) "UTF-8") >coded (for [[n v] request-params] (str (encode n) "=" (encode > v)))] >(apply str (interpose "&" coded > > > > > > On Jun 16, 9:21 pm, Timothy Washington wrote: > > Hey all, something very weird happens when trying to use the http-agent. > If > > I execute a) or b) in a browser, I get the desired result XML. > > a)http://RESTful/path/to/xml > > b)http://RESTful/path/to/xml?_wrap=no&_query=declaredefault element > > namespace 'com/interrupt/bookkeeping/users';//user[ @id='one'] > > > > However, using clojure, If I try the same call, d) in this case will NOT > > work. > > c) (clojure.contrib.http.agent/http-agent "http://RESTful/path/to/xml";) > > ; works > > d) (clojure.contrib.http.agent/http-agent " > http://RESTful/path/to/xml?_wrap=no&_query=declaredefault element > namespace > > 'com/interrupt/bookkeeping/users';//user[ @id='one']") ; doesn't > > work > > > > I've tried url-encoding the url using the below function, but that > doesn't > > help either. > > (defn url-encode [text] > > (URLEncoder/encode text "UTF-8")) > > > > Is the something obvious I'm missing? > > Thanks > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You 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 14:49, Rich Hickey wrote: > I don't see a way around this fundamental dichotomy. The semantics for + > should be unified, and the operator that makes the other choice needs to be > called something else, or placed somewhere else. My preference would be "placed somewhere else". We have namespaces, so why not profit from them? My vote would be for: 1) clojure.core/+ doing bigint promotion and reduction under all circumstances (no optimizations that would break the semantics) 2) clojure.fastmath/+ doing type-specific and optimized addition. This would retain the "safe by default" approach that I think fits Clojure best, and yet make it easy to use the "fast" version everywhere with nothing to change but the ns form at the top of a module. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Jun 18, 2010, at 6:47 AM, Carson wrote: Just tried out num branch and I really like how easy it is to be fast! However... Consider: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) (defn twice-fact [n] (fact (fact n))) (defn bad-twice-fact [n] (fact (-> n fact range last inc))) user=> (fact (fact 5)) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:3) user=> (fact (fact 5N)) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user=> (twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:5) user=> (twice-fact 5N) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user=> (bad-twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:7) user=> (bad-twice-fact 5N) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:8) Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. BigInt contagion doesn't help if in some convoluted manner a BigInt's value is used to construct a primitive sufficiently large that later causes an overflow. It'd sure be nice if I could just write ((safe bad-twice-fact) 5) and get back a BigInt. Maybe ((safe foo) x) can ensure all arguments and return values of function foo are boxed, and recursively, ensures boxing of arguments and return values for all functions called by foo, etc. Is that possible? Would that guarantee safety? -- While range could be written differently, this is tantamount to saying - if I use a bigint to lookup another number in some mapping, it might not be a bigint. Yes, ok, but not a real issue. - Note - I don't mean to single you out, as others are using the same language, but I find this whole characterization of throw-on-overflow being somehow 'unsafe' to be a bit specious. I want it to be perfectly clear to everyone, this is not a choice between good math and bad math, i.e. C/Java style truncating/wrapping of results. That will never be the default. Such silent truncation/ wrap is truly unsafe, and often the proposed alternative. It was a surprising result that optimizations of hot spot, combined with pipelining and speculative execution on modern processors, makes the overflow checking a very minor overhead above the raw operations, and, in my mind, a third, new, viable and safe high-performance option. Is a program that might throw an exception unsafe? If so, no Java program is safe. Is a vector that throws an exception when asked to store something at an index out of range, rather than grow to accommodate it, unsafe? This is in many ways similar - you are creating a result that doesn't fit, and need to be using a bigger container. So, let's go easy on the hyperbole. The behavior might not be what you desire, but it is not unsafe. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 Jun 18, 5:45 am, David Nolen wrote: > On Fri, Jun 18, 2010 at 6:47 AM, Carson wrote: > > (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) > > (defn twice-fact [n] (fact (fact n))) > > (defn bad-twice-fact [n] (fact (-> n fact range last inc))) > > Not only is it contrived, under the proposal, this implementation of fact is > broken. It needs to be fixed to: > > (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) > > With that change bad-twice-fact is not actually bad. I appreciate what you're saying, and the example above is not broken. Recall from here: On Jun 17, 8:00 pm, Rich Hickey wrote: ... > 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 > > I think you can always write code in this way, such that it will work > with any of the numeric types, without dictating. I believe the example (which I have tried on the num branch) shows providing a BigInt argument does not always make things safe. That is all. Carson > As Christophe Grand has mentioned one of the main things that is be > complained about from the BigInt supporters *is already a problem* in > Clojure. Nothing new to see here. > > Finally having actually tried out the new branches, this is a good change > for me. I'd like to hear more from the BigInt crowd about whether getting > their code to work with the new branches is actually causing problems. > > So far it just seems like talk. -- You 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 Jun 18, 2010, at 8:56 AM, Konrad Hinsen wrote: On 18.06.2010, at 14:49, Rich Hickey wrote: I don't see a way around this fundamental dichotomy. The semantics for + should be unified, and the operator that makes the other choice needs to be called something else, or placed somewhere else. My preference would be "placed somewhere else". We have namespaces, so why not profit from them? My vote would be for: 1) clojure.core/+ doing bigint promotion and reduction under all circumstances (no optimizations that would break the semantics) 2) clojure.fastmath/+ doing type-specific and optimized addition. This would retain the "safe by default" approach that I think fits Clojure best, and yet make it easy to use the "fast" version everywhere with nothing to change but the ns form at the top of a module. Which then begs the questions: - how will someone 'protect' themselves from libraries written using fastmath? - similar looking code will change semantics when the ns switch is made - seems dangerous as it might violate the presumptions of the original authors. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 Fri, Jun 18, 2010 at 2:20 PM, Rich Hickey wrote: > > On Jun 18, 2010, at 8:56 AM, Konrad Hinsen wrote: > > On 18.06.2010, at 14:49, Rich Hickey wrote: >> >> I don't see a way around this fundamental dichotomy. The semantics for + >>> should be unified, and the operator that makes the other choice needs to be >>> called something else, or placed somewhere else. >>> >> >> My preference would be "placed somewhere else". We have namespaces, so why >> not profit from them? >> >> My vote would be for: >> >> 1) clojure.core/+ doing bigint promotion and reduction under all >> circumstances (no optimizations that would break the semantics) >> >> 2) clojure.fastmath/+ doing type-specific and optimized addition. >> >> This would retain the "safe by default" approach that I think fits Clojure >> best, and yet make it easy to use the "fast" version everywhere with nothing >> to change but the ns form at the top of a module. >> >> > Which then begs the questions: > > - how will someone 'protect' themselves from libraries written using > fastmath? > > - similar looking code will change semantics when the ns switch is made - > seems dangerous as it might violate the presumptions of the original > authors. > > Rich > > In this situation, I would rather have some kind of toggle *use-bigints-by-default* (defaulted to false) used by the compiler. Then, if someone needs big integers, he can switch the toggle and recompile everything. You wouldn't have to change the libraries ns. As for being predictable, if you have numbers that can be bigger than 10^19, you would probably know it in advance. (indices, counters and the like don't grow that big) -- You 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
2010/6/18 Rich Hickey : > I want it to be perfectly clear to everyone, this is not a choice between > good math and bad math, i.e. C/Java style truncating/wrapping of results. > That will never be the default. Such silent truncation/wrap is truly unsafe, > and often the proposed alternative. It was a surprising result that > optimizations of hot spot, combined with pipelining and speculative > execution on modern processors, makes the overflow checking a very minor > overhead above the raw operations, and, in my mind, a third, new, viable and > safe high-performance option. > > Is a program that might throw an exception unsafe? If so, no Java program is > safe. > > Is a vector that throws an exception when asked to store something at an > index out of range, rather than grow to accommodate it, unsafe? This is in > many ways similar - you are creating a result that doesn't fit, and need to > be using a bigger container. > > So, let's go easy on the hyperbole. The behavior might not be what you > desire, but it is not unsafe. > Fair enough. -- You 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
2010/6/18 Nicolas Oury : > > > On Fri, Jun 18, 2010 at 2:20 PM, Rich Hickey wrote: >> >> On Jun 18, 2010, at 8:56 AM, Konrad Hinsen wrote: >> >>> On 18.06.2010, at 14:49, Rich Hickey wrote: >>> I don't see a way around this fundamental dichotomy. The semantics for + should be unified, and the operator that makes the other choice needs to be called something else, or placed somewhere else. >>> >>> My preference would be "placed somewhere else". We have namespaces, so >>> why not profit from them? >>> >>> My vote would be for: >>> >>> 1) clojure.core/+ doing bigint promotion and reduction under all >>> circumstances (no optimizations that would break the semantics) >>> >>> 2) clojure.fastmath/+ doing type-specific and optimized addition. >>> >>> This would retain the "safe by default" approach that I think fits >>> Clojure best, and yet make it easy to use the "fast" version everywhere with >>> nothing to change but the ns form at the top of a module. >>> >> >> Which then begs the questions: >> >> - how will someone 'protect' themselves from libraries written using >> fastmath? >> >> - similar looking code will change semantics when the ns switch is made - >> seems dangerous as it might violate the presumptions of the original >> authors. >> >> Rich > > In this situation, I would rather have some kind of toggle > *use-bigints-by-default* (defaulted to false) used by the compiler. > Then, if someone needs big integers, he can switch the toggle and recompile > everything. No please, not even in my worst nightmares ! Semantic changing compilation flags ? So I use lib A which needs lib B compiled with flags C and D, but I also use lib E which needs lib B compiled with other values for the flags ... I think this just is a recipe for disaster. > You wouldn't have to change the libraries ns. > As for being predictable, if you have numbers that can be bigger than 10^19, > you would probably know it in advance. > (indices, counters and the like don't grow that big) -- You 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 Jun 18, 6:11 am, Rich Hickey wrote: > On Jun 18, 2010, at 6:47 AM, Carson wrote: > > Just tried out num branch and I really like how easy it is to be > > fast! However... > > > Consider: > > > (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) > > (defn twice-fact [n] (fact (fact n))) > > (defn bad-twice-fact [n] (fact (-> n fact range last inc))) > > > user=> (fact (fact 5)) > > java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:3) > > user=> (fact (fact 5N)) > > 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N > > user=> (twice-fact 5) > > java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:5) > > user=> (twice-fact 5N) > > 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N > > user=> (bad-twice-fact 5) > > java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:7) > > user=> (bad-twice-fact 5N) > > java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:8) > > >> Don't buy it. That's the whole point of BigInt contagion. If fact > >> and foo > >> are correctly written this will work. > > > BigInt contagion doesn't help if in some convoluted manner a BigInt's > > value is used to construct a primitive sufficiently large that later > > causes an overflow. > > > It'd sure be nice if I could just write ((safe bad-twice-fact) 5) and > > get back a BigInt. Maybe ((safe foo) x) can ensure all arguments and > > return values of function foo are boxed, and recursively, ensures > > boxing of arguments and return values for all functions called by foo, > > etc. Is that possible? Would that guarantee safety? > > -- > While range could be written differently, this is tantamount to saying > - if I use a bigint to lookup another number in some mapping, it might > not be a bigint. Yes, ok, but not a real issue. > > - > Note - I don't mean to single you out, as others are using the same > language, but I find this whole characterization of throw-on-overflow > being somehow 'unsafe' to be a bit specious. > > I want it to be perfectly clear to everyone, this is not a choice > between good math and bad math, i.e. C/Java style truncating/wrapping > of results. That will never be the default. Such silent truncation/ > wrap is truly unsafe, and often the proposed alternative. It was a > surprising result that optimizations of hot spot, combined with > pipelining and speculative execution on modern processors, makes the > overflow checking a very minor overhead above the raw operations, and, > in my mind, a third, new, viable and safe high-performance option. > > Is a program that might throw an exception unsafe? If so, no Java > program is safe. > > Is a vector that throws an exception when asked to store something at > an index out of range, rather than grow to accommodate it, unsafe? > This is in many ways similar - you are creating a result that doesn't > fit, and need to be using a bigger container. > > So, let's go easy on the hyperbole. The behavior might not be what you > desire, but it is not unsafe. > > Rich hmm...didn't see this earlier. You're right, it's not unsafe, it's undesired behaviour. My mistake describing it that way. -- You 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 Fri, Jun 18, 2010 at 2:35 PM, Laurent PETIT wrote: > > No please, not even in my worst nightmares ! > Semantic changing compilation flags ? So I use lib A which needs lib B > compiled with flags C and D, but I also use lib E which needs lib B > compiled with other values for the flags ... I think this just is a > recipe for disaster. > Seen like this, this does not look so great. However, I would like to note that, in this specific situation, there is a flag that subsumes the other. I can't see someone relying on overflow (as opposed to promotion) for its behavior... It would be a bit sick. -- You 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 Jun 17, 2010, at 11:57 PM, Mark Engelberg wrote: Thanks for the responses. Going back to the naive factorial function: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) Right now, user=> (fact 40) 8159152832478977343456112695961158942720 Under the proposed changes, user=> (fact 40) java.lang.ArithmeticException: integer overflow So the same code now risks an arithmetic exception. What have I, the programmer, gained from this new level of risk? The answer, if I'm the kind of programmer who has no interest in putting in type annotations into the header of the function, is nothing. There is no speed improvement without the additional type annotations. So all I've gained is the /potential/ for a speed improvement. I fully acknowledge this is a breaking change that doesn't suit your preferences. But again, you are over- and misstating things. The benefit does not only accrue to those annotating their arguments. Because many functions and methods return primitives (and more will, now that fns can return primitives), any operations on their results and/or literals can be optimized. E.g. things like (if (< (dec (count x)) 100) ...) can now be optimized into primitives. I assume that most Clojure users really like its dynamic nature. If this is true, then for most of us, the common case is to NOT annotate our code with types. Certainly I like the idea of making it as easy as possible to write fast code in Clojure. I want my dynamically typed code to be as fast as it can be, and it's nice to know that there is a way to write statically typed code that is even faster. But I really don't want to incur a penalty (i.e., possibility of Arithmetic Exception) when I'm not using type annotations. I agree that the burden on those who want to write type annotated code is too high. I agree that this should be made easier. But ultimately, I still want the burden to be on them (or me, the 1% time I need it), not those of us who prefer unannotated code. I that some of the changes you have proposed for moving the annotations into the header, along with literal notation for long (i.e., 0L rather than (long 0)) would be preferable to the bigint dichotomy. I agree that an improved bigint type would address the performance aspect of my argument. On the other hand, it wouldn't really address the problem of using these things in sets and hash tables. I think it's very important that Clojure have one unique canonical representation for numbers arrived at through Clojure-based computations. It is very difficult to use numbers sanely if that's not the case. Agreed that this equality bit is a separate issue. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
While I enjoy a theoretical debate as much as the next person, it would be nice to see (1) examples of real code that fail on reasonable inputs, if this change were made. And how difficult it would be to fix them. (2) examples of real code that get way faster, and the ease of making those changes (if any). WRT #1, we have tested a few dozen libs, and found only a single trivial breakage in their test suites. But I would say tha is still just plural anecdotes. More data welcome! -- You 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 Fri, Jun 18, 2010 at 2:49 PM, Rich Hickey wrote: > This L suffix idea is a non-starter. Here's why: > > We're in a reader based language. The reader reads objects. When the reader > reads 42, it must return an object. It cannot return an int or a long > primitive. Right now, it returns an Integer. I've also conducted experiments > where it returned a Long. Certainly 420 will be a Long. What > different thing would the reader return given 42L, or 420L? Given an > int 42 what should the printer print? And long 42, Long 42? Would (= 42L > (read-string (pr-str 42L)))? But what if the reader reads 42 as a BigInteger (or an alternative implementation) and 42L as a Long? then you should be able to tell them apart. I agree with the goals of the num branch, I'm just unconvinced by the reader defaulting to Long for integer literals. Christophe -- You 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 Jun 18, 2010, at 15:11 , Rich Hickey wrote: > So, let's go easy on the hyperbole. The behavior might not be what you > desire, but it is not unsafe. I agree with both actually it isn't unsafe but in my eyes undesired, met me explain. In generally it seems we have two options: 1) We make fast default and loose auto promotion in the number stack. 2) We make it more difficult to be fast (as in extra work) but keep promotion. Lets hope that I got this right otherwise the following argumentation can be skipped since it's based on this understandings. (of cause there might be a way to accomplish both which would - without question the best way to go ;) Now let see the auto promotion has one very nice effect, it just works. That simple and this is in my eyes hugely important, because it gives people a happy and fluffy feeling to be able to write normal code without special considerations and deep knowledge of types and hinting. Lets face it for 90% of people it does not matter that it is a long or bigint or even a double they expect math to just work, this is one of the reasons why people enjoy languages like Ruby or buy Apple hardware - because it just works (yes we don't play on the same ground but it was a good principle of it). If we go to the point where people need to know that they have to pass a 42N instead of 42 or get an exception it is just plain ugly, it is javaish and that things are not javaish is one thing poeple love about clojure, and just to not be tossed in the bucket, it is not insecure just horrible inconvenient and annoying. But lets look at the other side of the coin, performance. We all want it - of cause otherwise we'd put a lot of (Thread/sleep 1000) in our code but, again lets face the reality, most of us don't need it. Most of the time we don't need to do fac or fib or very fast math, in 90% of the cases what clojure offers is just fast enough since the bottle necks isn't arithmetics. For the rest 10% of the cases, well if you are in that case you likely have a complex algorithm. This again means that you belong to the people who really know what they are doing, and know what your algorithm works, given that someone in this position should know where to put performance optimization so the fact that it needs to be explict isn't that horrible in my eyes usually the code that has to be made more complex is alway some kind of focus code where you do way more then just toss a few statics on it and hope that it is fast but try every trick to get it fast - so you'll have the work anyway. Now what is my conclusion: lets keep the 'it just works' and sacrifice some out of the box performance gains which 90% of the users won't notice anyway and half of the people notice it will only do so because they benchmark for exactly this. Especially since number arithmetics are rarely the bottlenecks, database lookups, string manipulations, IO, network and object allocation those are things that eat much performacne in the most cases. Just my two (european!) cent :) That said I find the possible performance gain extraordinary and brilliant, and I'm all for it just not for the sacrifice of 'it just works'. I rather write (long 1) in 2 functions where it is really needed then making sure I write 42N or ^Bigint in every function where I'm not 100% certain (which will likely be all but the two functions where I'd write logn). Regards, Heinz -- You 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
> So the same code now risks an arithmetic exception. What have I, the > programmer, gained from this new level of risk? The answer, if I'm > the kind of programmer who has no interest in putting in type > annotations into the header of the function, is nothing. There is no > speed improvement without the additional type annotations. So all > I've gained is the /potential/ for a speed improvement. It will be much easier for people to write fast library code (including in Clojure and contrib). So if you ever use Clojure libraries, you will get a speed boost. -- You 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 Fri, Jun 18, 2010 at 3:11 PM, Heinz N. Gies wrote: > > But lets look at the other side of the coin, performance. We all want it - > of cause otherwise we'd put a lot of (Thread/sleep 1000) in our code but, > again lets face the reality, most of us don't need it. Most of the time we > don't need to do fac or fib or very fast math, in 90% of the cases what > clojure offers is just fast enough since the bottle necks isn't arithmetics. > For the rest 10% of the cases, well if you are in that case you likely have > a complex algorithm. This again means that you belong to the people who > really know what they are doing, and know what your algorithm works, given > that someone in this position should know where to put performance > optimization so the fact that it needs to be explict isn't that horrible in > my eyes usually the code that has to be made more complex is alway some kind > of focus code where you do way more then just toss a few statics on it and > hope that it is fast but try every trick to get it fast - so you'll have the > work anyway. > > > I am not sure (= (* 20 not-a-bottleneck) not-a-bottleneck) or more precisely: (= (* 20 not-a-bottleneck-1 ... not-a-bottleneck-250) not-a-bottleneck) -- You 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
I meant: (= (* 20 (+ not-a-bottleneck-1 ... not-a-bottleneck-250)) not-a-bottleneck) -- You 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 Jun 18, 2010, at 10:09 AM, Christophe Grand wrote: On Fri, Jun 18, 2010 at 2:49 PM, Rich Hickey wrote: This L suffix idea is a non-starter. Here's why: We're in a reader based language. The reader reads objects. When the reader reads 42, it must return an object. It cannot return an int or a long primitive. Right now, it returns an Integer. I've also conducted experiments where it returned a Long. Certainly 420 will be a Long. What different thing would the reader return given 42L, or 420L? Given an int 42 what should the printer print? And long 42, Long 42? Would (= 42L (read-string (pr-str 42L)))? But what if the reader reads 42 as a BigInteger (or an alternative implementation) and 42L as a Long? then you should be able to tell them apart. And keeps them that way? Hrm. Then most programs, that currently have no bigints, will now be full of them. And the boxed math will be slower still, as it will be the (possibly improved, but still more complex) logic of bigints. And the interop will be trickier. The current boxing matches the boxing you will get from things from the outside world. This wouldn't. And if this is just a 'way to communicate with the compiler' thing, then read/print round-tripping will break. I agree with the goals of the num branch, I'm just unconvinced by the reader defaulting to Long for integer literals. It's important not to get focused on the literals. There are primitives coming from other places as well. The semantic dichotomy is the driver. The choice of the semantics of + can't be based upon the boxed-ness of the argument, as it is now. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Leiningen documentation review?
On Thu, Jun 17, 2010 at 11:14 PM, Howard Lewis Ship wrote: > I've been using Lein in earnest the last couple of days, prepping for > a talk on Clojure for OSCON. I'm hitting enough issues to make me > think that 1.2 needs a bit of TLC before a release. > > Don't get me wrong; I like Lein, how easy it installs, and how focused > it is. I'm just finding that, despite being "in theory" customizable > to slightly different directory layouts (I like a Maven style layout, > with src/main/clojure, src/test/clojure, target/classes, etc.) ... > well, it just doesn't work in practice. Yes, that's definitely true. I think you are one of the first people to actually use those customizations, so you're hitting all the edge cases. > I'm doing what I can to help with patches and bug reports. Thanks; it's appreciated. I will make sure they are addressed before the 1.2 release. Hope the talk goes well. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 Jun 18, 2010, at 16:24 , Nicolas Oury wrote: > I am not sure (= (* 20 not-a-bottleneck) not-a-bottleneck) > > or more precisely: > (= (* 20 not-a-bottleneck-1 ... not-a-bottleneck-250) not-a-bottleneck) Point is, no one will write 250 variables even less so values by hand, it will be a map, reduce or whatever and then it's pretty easy to type hint it if the performance is an issue at this point and if you write this code you likely will know that this is a bottleneck. (I ignore the * there since you corrected it, otherwise it'd be a nice Palce to point out that it is likely becoming a overflow and an exception w/o automatic promotion :P) Regards, Heinz -- You 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
> > > Point is, no one will write 250 variables even less so values by hand, it > will be a map, reduce or whatever and then it's pretty easy to type hint it > if the performance is an issue at this point and if you write this code you > likely will know that this is a bottleneck. (I ignore the * there since you > corrected it, otherwise it'd be a nice Palce to point out that it is likely > becoming a overflow and an exception w/o automatic promotion :P) > > That would have been really better to have an exception as it was a bug :-b. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure / Common Lisp Question
As an informal survey of people who use both Clojure and Common Lisp for different projects, what do you see as the main determining factors behind your choice to use either Clojure or Common Lisp for a project, given the present state of Clojure. Let's only assume we are talking about projects you completely own and have complete freedom to do what you want with. Common lisp: Compiled on the processor, fast. Reader macros. Quality, not quantity of libraries. Multi-paradigm programming with no nudging -- programmer has freedom to be insane/bizarre in ways Clojure makes hard (see Let Over Lambda for examples) Downsides: Hard to deploy. -- but not a problem as server side of web app Can't run on on GAE. -- need to run a server or rent/maintain virtual server. Limited to native librares, though they tend to be awesome. Clojure: Neat concurrency stuff. Better deployment. Can run on Google App Engine. (maybe ABCL can too, but I wouldn't want to use that personally). Lots of Java libraries, many more than for CL. Increasing a large number of awesome native libraries. Downsides: As server side of web app in apache, less straigtforward requires Tomcat, Java crud. Java interop is great-- but Java itself sucks! There is an impedance mismatch of language semantics. The nudging of paradigm/idiom makes many things easier in Common Lisp. Lots of cool benefits of Clojure (such as any/all GUI stuff for example) depend on crufty Java nonsense you must contend with. So, for me at this point, if I don't need interesting concurrent stuff, and I do my own hosting, Common Lisp in Hunchentoot or mod lisp still seems like a superior web development approach. On the other hand if I am doing desktop apps, applets, want to use GAE, etc, Clojure seems better. I feel like as time goes on we will be more abstracted away from the pain of Java. Any thoughts on how you make your decision for specific projects? Thanks, Rob -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen documentation review?
On Jun 17, 12:24 am, Phil Hagelberg wrote: > Mostly I'd like feedback on the > tutorial:http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > But if you've got some time to look over the readme, that would be > great too:http://github.com/technomancy/leiningen/blob/master/README.md > This sentence in the README: "On Windows you can download lein.bat" contains a link to an old and busted version of lein.bat that can only lead to tears and misery for new users :) Could you either update it to point to a newer version of lein.bat, or at least upload leiningen-1.1.0-standalone.jar to http://repo.technomancy.us/ - I think that's all that's required in order to make the old instructions workable. Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
Experiment results : I switched a program to num. It was quite straightforward. First I had to replace a few unchecked-add by +. Has unchecked-add changed name? (I use it for indices when itering on a java array, if there is an overflow, you will know it beforehand) The only funny event is that it was much much much slower at first. Mainly doing reflection stuff. I used *warn-on-reflection* and found: ( < val 0) where val is a double. Ugly, bad and wrong. I am not proud. (* some-int some-double), that I changed to (* (double some-int) some-double) Then, I had some results on the benchmark I use to test my change. (I remove 14 seconds to each, because it is the compilation time. As this program is made to run for a long time and I want to test the stationary speed,I put a very low threshold for the jit. I don't know if it is a good idea or not.) Initial program : 92 seconds - 14 = 78s Corrected program with master : 86 seconds - 14 = 72s Corrected program with num : 80 seconds - 14 = 66s Note that it is quite heavy on the GC, so there is 5s gc in that, which increase still more the difference. Altogether, it is around 10% faster, without touching any annotation and static function. Moreover, it might be difficult to believe if you read the beginning of my mail, but I spend a lot of time adding annotations where I thought it was useful. That's difficult, and still there is a nice speedup. Most of all, I could start added annotations to function. The problem is I use a lot of protocols. Are there plans for support of prim in protocols? Last thing, there is no single bottleneck that I could rewrite easily. This 10% is spread over the program. Result of profiling: Interpreted + native Method 0.2% 2 +10clojure.core__init.load 0.1% 8 + 0distribution.FastProductWithinComp.non_local_draw 0.1% 7 + 0clojure.core$vector.invoke 0.1% 7 + 0java.util.WeakHashMap.get ... 2.8% 177 +32Total interpreted (including elided) Compiled + native Method 2.4% 183 + 0clojure.lang.RT.seqFrom 2.2% 164 + 1distribution.FastProductWithinComp.non_local_draw 1.9%61 +81java.util.WeakHashMap.getTable 1.4% 103 + 0clojure.lang.RestFn.invoke 0.8%62 + 1clojure.core.protocols$fn__5284.invoke 0.7%51 + 0clojure.lang.RT.next 0.4%31 + 1clojure.lang.Var.pushThreadBindings 14.8% 1019 + 100Total compiled (including elided) Stub + native Method 81.3% 0 + 6154java.lang.Object.hashCode And yes, this 10% are obtained in a code that mainly use HashMaps to retrieve already computed values (81.3% seems spent there). So I would expect far better speed-up in a more typical program. (Game : guess what the program does from its profile...) -- You 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: Problems with URL params and http-agent
On 18 June 2010 14:53, Timothy Washington wrote: > Hmm, this is a good idea and I got the GET request string as... > /exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declare > default element namespace 'com/interrupt/bookkeeping/users';//user[ > @id='one'] > This exact URI (behind http://localhost:8080) works when used by the > browser, or wget.[...] But spaces etc. are not valid as part of a URI. They need to be escaped. What happens if you try this hard-coded URL: http://localhost:8080/exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declare%20default%20element%20namespace%20%27com/interrupt/bookkeeping/users%27%3B//user%5B%40id%3D%27one%27%5D Try that in the browser, wget and also your Clojure program. It might also help to get a simple CGI script or something that can extract the _wrap and _query parameters from the query string and just print or log them so you can compare what you get from the browser and wget and your program. -- Michael Wood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: compiling the instructions of a simple vm into a function
First a simple version, equivalent to yours but more readable. (defmacro compile-instructions [instructions] (let [memory (gensym "memory-")] `(fn [~memory] ~@(map (fn [[op m1 m2]] `(aset ~memory ~m1 (~op (aget ~memory ~m1) (aget ~memory ~m2 instructions (def memory (into-array Integer/TYPE (range 4))) (def compiled (compile-instructions ([+ 2 3] [- 0 1] [+ 1 0]))) And another one to workaround the JVM 64K "feature". I split the generated code into blocks of 500 instructions. (def length-threshold 500) (defmacro protected-fn [binding-form & body] (if (<= (count body) length-threshold) `(fn ~binding-form ~...@body) (let [small-funs (partition length-threshold length-threshold () body) let-block (map (fn [bod] (let [name (gensym "let-")] [name `(fn [...@binding-form] ~@ bod)] )) small-funs)] `(let [~@(apply concat let-block)] (protected-fn [...@binding-form] ~@(map (fn [[name code]] `(~name ~...@binding-form)) let-block)) (defmacro compile-instructions-2 [instructions] (let [memory (gensym "memory-")] `(protected-fn [~memory] ~@(map (fn [[op m1 m2]] `(aset ~memory ~m1 (~op (aget ~memory ~m1) (aget ~memory ~m2 instructions (def compiled-2 (eval `(compile-instructions-2 ~(take 1150 (cycle '([+ 2 3] [- 0 1] [+ 1 0])) This last line is quite ugly. In fact, if you want to use compile-instruction programatically, maybe it should not be a macro but a function. Then using a code-generating function in a macro is easy. Plus, it is easy to eval the generated code. But, be careful, you have to eval it once, just after the compiling phase. Then, you get a real function. eval is evil, but eval is not evil is a compiler (you have to evaluate the code you read). However eval is evil again in an "embedded compiler", when you use macro to extend Clojure. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Fri, 18 Jun 2010 09:20:35 -0400, Rich Hickey wrote: On Jun 18, 2010, at 8:56 AM, Konrad Hinsen wrote: On 18.06.2010, at 14:49, Rich Hickey wrote: I don't see a way around this fundamental dichotomy. The semantics for + should be unified, and the operator that makes the other choice needs to be called something else, or placed somewhere else. If you are doing a lot of work with whichever semantic requires decorated use, then it is going to seem awkward. A namespace based solution would allow "natural" use of whichever semantic was appropriate for the domain you are coding. It would still require an explicit choice - pulling in a different namespace. - how will someone 'protect' themselves from libraries written using fastmath? If I understand correctly, that is still an issue, whatever syntax is chosen. - similar looking code will change semantics when the ns switch is made The switch is explicit. - seems dangerous as it might violate the presumptions of the original authors. Not sure I understand this. Presumably if you change your selected semantics within a namespace, you had better be sure of how that affects all the functions in that namespace. -- Hugo Duncan -- You 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: Upgrade from 1.1 to 1.2
On Thu, Jun 17, 2010 at 11:50 PM, Laurent PETIT wrote:
> Hi,
>
> 2010/6/18 Wilson MacGyver :
>> ^ was deprecated in 1.1 as per release note below
>> The ^ reader macro has been deprecated as a shortcut for meta in the
>> hopes that it can eventually replace the #^ reader macro.
>
> No, it's not that gray: in 1.2 (so in clojure master, and all new
> branches like prim, equal, etc.), ^ now has the same semantics as #^.
> #^ is still working as usual, but becomes deprecated. The behaviour of
> the old ^, as mentioned by Howard, requires the explicit (meta ) call.
>
> Howard, another point to have in mind in 1.2: some libraries from
> clojure contrib have partially migrated to clojure. For example I/O
> stuff has appeared in clojure.java.io. String manipulation stuff also.
> As a result, you may encounter warnings in your own code, or in
> libraries you use which may not yet have migrated to 1.2 (which is to
> be expected, since 1.2 is not out), or not be prepared for 1.2 (by
> avoiding 'use-ing foreign namespaces, but rather using aliases). The
> warnings will tell you when a var is re-def-ined (this is a new
> feature, which may or may no stay in core : before this warning
> feature, you just wouldn't have been able to compile the code,
> redefinitions of vars bound to external namespaces vars was an error.
> The new "warning only" behaviour tries to enhance the user experience:
> allow the code to run, until everybody has removed the warnings in new
> versions of their code).
>
Right, I'm working through that code right now.
What's really got me worried is this:
Exception in thread "main" java.lang.IllegalArgumentException: Wrong
number of args (3) passed to: cascade$link (views.clj:25)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5373)
at clojure.lang.Compiler.analyze(Compiler.java:5187)
at clojure.lang.Compiler.analyze(Compiler.java:5148)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3054)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5368)
Problem is, cascade/link does take 3 args:
(defmacro link
"Creates a link to a view or action function. Additional path info
data may be specified (as a seq of
data items),
as well as query parameters (as a map whose keys are strings or
keywords and whose values are converted to strings.).
Uses standard keys from the env map. The resulting link is returned
as a string."
([env function]
(link env function nil))
([env function extra-path-info]
(link env function extra-path-info nil))
([env function extra-path-info query-parameters]
`(link-path ~env (link-map-from-function ~function
~extra-path-info ~query-parameters
And the call looks kosher:
(defaction increment-count
{:path "count/increment"}
[env]
[count :int]
(send-redirect env (link env show-counter [(inc count)]))) ;
view.clj, line 25
> HTH,
>
> --
> Laurent
>
> --
> You 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
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
--
You 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: Leiningen documentation review?
On Jun 16, 9:24 pm, Phil Hagelberg wrote: > Mostly I'd like feedback on the > tutorial:http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md It looks quite good. Maybe some mention of `lein clean` is warranted. It would preclude a lot of the "Hey I just upgraded library X and now everything is broken" kinds of questions I see on various mailing lists. The part discussing the group-id/artifact-id etc. is great for those of us who don't know maven. Can you consider adding something about how to name a project in project.clj so that it can be pushed to clojars cleanly? On clojars you see projects named with a bare word, like "compojure" and "swank-clojure", and then others with a one-word group-id, "foo/bar", then others with a full domain, "org.clojars.someguy/baz". This is a bit of a mess. But I wonder how many packages are pushed to clojars under the wrong name or wrong group-id accidentally, not realizing how it would end up looking. It might be helpful to promote a convention for project naming, if nothing else. Or if there's already some convention that I'm missing, maybe explain the convention. Just a thought. --Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Leiningen documentation review?
On Fri, Jun 18, 2010 at 8:20 AM, Chris Perkins wrote: > On Jun 17, 12:24 am, Phil Hagelberg wrote: > This sentence in the README: "On Windows you can download lein.bat" > contains a link to an old and busted version of lein.bat that can only > lead to tears and misery for new users :) Oh right; I will update that to point to the master branch instead of stable. The Windows support is totally volunteer-driven since I don't have a copy of Windows to test it on. For the 1.1.0 release we had Rob Wolfe helping out to adapt the bash script to a batch file, but we haven't had anyone step up for this release. Volunteers welcome. > Could you either update it to point to a newer version of lein.bat, or > at least upload leiningen-1.1.0-standalone.jar to http://repo.technomancy.us/ > - I think that's all that's required in order to make the old > instructions workable. I'm trying to move away from using my personal web site, so the instructions now point to the Github Downloads section instead. Does that work OK? -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Leiningen documentation review?
On Fri, Jun 18, 2010 at 10:14 AM, Brian Carper wrote: > It looks quite good. Maybe some mention of `lein clean` is > warranted. It would preclude a lot of the "Hey I just upgraded > library X and now everything is broken" kinds of questions I see on > various mailing lists. Definitely. > The part discussing the group-id/artifact-id etc. is great for those > of us who don't know maven. Can you consider adding something about > how to name a project in project.clj so that it can be pushed to > clojars cleanly? On clojars you see projects named with a bare word, > like "compojure" and "swank-clojure", and then others with a one-word > group-id, "foo/bar", then others with a full domain, > "org.clojars.someguy/baz". This is a bit of a mess. There's some mention of this in the readme, but I will expand it and move it to the tutorial. It is important that people understand when org.clojars.$USERNAME is appropriate since otherwise they will squat on group-ids that belong to someone else. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Upgrade from 1.1 to 1.2
I've noticed that logging has moved into clojure.jar ... could Clojure start leveraging logging to identify what namespace its compiling and why; I'd love to see something like: [Compiler] Compiling namepace cascade [Compiler] Namespace cascade imports namespace cascade.asset [Compiler] Compiling namespace cascade.asset [Compiler] Compiled function cascade.asset/is-allowed-path [Compiler] Finished compiling namespace cascade.asset [Compiler] Finished compiling namespace cascade etc. One thing I've done in Tapestry is similar to this .. a thing I call the OperationTracker which tracks what Tapestry is doing using a stack of descriptive strings (stored in a ThreadLocal). When a deeply nested exception occurs, Tapestry can describe why it got to that point, i.e. [ 1] Realizing service Foo [ 2] Instantiating core service implementation silly.example.FooImpl [ 3] Finding injection for parameter #2 of silly.example.FooImpl(Bar, Baz) [ 4] Realizing service Baz This can be an alternative to logging, since its only needed when something goes wrong. This is really handy since so much code goes through the same exact methods, just with different parameters, which is in common with Clojure. I've spent many years working on exception reporting in Tapestry ... I'd love to see some of the same love for Clojure! On Thu, Jun 17, 2010 at 11:50 PM, Laurent PETIT wrote: > Hi, > > 2010/6/18 Wilson MacGyver : >> ^ was deprecated in 1.1 as per release note below >> The ^ reader macro has been deprecated as a shortcut for meta in the >> hopes that it can eventually replace the #^ reader macro. > > No, it's not that gray: in 1.2 (so in clojure master, and all new > branches like prim, equal, etc.), ^ now has the same semantics as #^. > #^ is still working as usual, but becomes deprecated. The behaviour of > the old ^, as mentioned by Howard, requires the explicit (meta ) call. > > Howard, another point to have in mind in 1.2: some libraries from > clojure contrib have partially migrated to clojure. For example I/O > stuff has appeared in clojure.java.io. String manipulation stuff also. > As a result, you may encounter warnings in your own code, or in > libraries you use which may not yet have migrated to 1.2 (which is to > be expected, since 1.2 is not out), or not be prepared for 1.2 (by > avoiding 'use-ing foreign namespaces, but rather using aliases). The > warnings will tell you when a var is re-def-ined (this is a new > feature, which may or may no stay in core : before this warning > feature, you just wouldn't have been able to compile the code, > redefinitions of vars bound to external namespaces vars was an error. > The new "warning only" behaviour tries to enhance the user experience: > allow the code to run, until everybody has removed the warnings in new > versions of their code). > My experience over the last several years is that warnings are always ignored. Better to fail hard, fast and early ... as long as you inform the dev what broke and how to fix it! > HTH, > > -- > Laurent > > -- > You 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 -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- You 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 Thu, Jun 17, 2010 at 9:06 PM, Stuart Halloway wrote: > It will be much easier for people to write fast library code (including in > Clojure and contrib). So if you ever use Clojure libraries, you will get a > speed boost. I am skeptical of this claim. Since static functions lose some of their dynamism, I don't think library writers are going to rush to convert all their code over to the "fast" format. I think library writers will care the most about ensuring their functions play well with Clojure's dynamic ecosystem, and so, as before, type-optimized code will be written only sparingly. (I'll admit though, I don't fully understand yet which dynamic features are lost by static functions, and how much of an impact it will have, so I could be wrong about this. Just wanted to throw this out as something to consider.) -- You 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
- There is a speedup without static or annotation. - Static keep the dynamic semantic, if I understood well the proposal (only direct first-order call are static) On Fri, Jun 18, 2010 at 6:51 PM, Mark Engelberg wrote: > On Thu, Jun 17, 2010 at 9:06 PM, Stuart Halloway > wrote: > > It will be much easier for people to write fast library code (including > in Clojure and contrib). So if you ever use Clojure libraries, you will get > a speed boost. > > I am skeptical of this claim. Since static functions lose some of > their dynamism, I don't think library writers are going to rush to > convert all their code over to the "fast" format. I think library > writers will care the most about ensuring their functions play well > with Clojure's dynamic ecosystem, and so, as before, type-optimized > code will be written only sparingly. (I'll admit though, I don't > fully understand yet which dynamic features are lost by static > functions, and how much of an impact it will have, so I could be wrong > about this. Just wanted to throw this out as something to consider.) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: code review request: clojure.java.io
2010/5/11 Stuart Halloway > Assembla Ticket #311 [1] calls for the promotion of clojure.contrib.iointo > clojure (as > clojure.java.io). I have attached a patch, and am requesting comments and > code review from the community. I think I have found a bug in the clojure.contrib.io code. The current 1.2 master branch contains the following : (extend Socket IOFactory (assoc default-streams-impl :make-input-stream (fn [^Socket x opts] (.getInputStream x)) :output-stream (fn [^Socket x opts] (output-stream (.getOutputStream x) opts Note that :output-stream is not part of the IOFactory protocol. The intended keyword was most probably :make-output-stream. Also, the body should not contain a call to output-stream, since it calls make-output-stream. I propose that the last line is changed so that the code becomes the following: (extend Socket IOFactory (assoc default-streams-impl :make-input-stream (fn [^Socket x opts] (.getInputStream x)) :make-output-stream (fn [^Socket x opts] (.getOutputStream x Now, one can make output streams from sockets again (this threw an exception[1] before): (output-stream (Socket. "example.com" 1234)) So what is the next step for me now? I am not formally a contributor yet. It will take approx a week until my signed CA arrives. I will gladly help with whatever I can do in the mean time... // raek [1] The exception: java.lang.IllegalArgumentException: Cannot open <#> as an OutputStream. -- You 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 Jun 18, 8:49 am, Rich Hickey wrote:
> Fixing it requires adopting a single
> semantic for +. Choosing auto-promotion precludes the use of + on
> primitives, a huge loss IMO. Choosing throw-on-overflow precludes auto-
> promotion, but preserves polymorphism otherwise, and gives the
> compiler free reign to optimize since it will never be altering the
> semantics by doing so.
>
> I don't see a way around this fundamental dichotomy. The semantics for
> + should be unified, and the operator that makes the other choice
> needs to be called something else, or placed somewhere else.
I'm just a newbie here, but I would prefer the simpler and faster +
(with throw-on-overflow). I don't want to annotate my arguments
(carefully!) to get primitive performance. I want the best
performance in the simple cases. The primitive domain is big enough
for most programs.
I would be willing to use separate function names ("auto-promo-+",
etc.) to get the "safe" auto-promotion semantics. Perhaps they could
be in a separate namespace so that you can make your + symbol refer to
the auto-promoting one if you want to pay the cost. By the way, I
also want to know if a library is using auto-promotion so that I can
avoid it unless I really need it. And, yes, I think I'll know enough
about my domain to make that decision.
Steve Miner
--
You 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: Leiningen documentation review?
On Jun 18, 1:21 pm, Phil Hagelberg wrote: > On Fri, Jun 18, 2010 at 8:20 AM, Chris Perkins > wrote: > > This sentence in the README: "On Windows you can download lein.bat" > > contains a link to an old and busted version of lein.bat that can only > > lead to tears and misery for new users :) > > Oh right; I will update that to point to the master branch instead of stable. > > I'm trying to move away from using my personal web site, so the > instructions now point to the Github Downloads section instead. Does > that work OK? I just tried out the instructions from lein.bat on master, and it works beautifully. Thanks, Phil. Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
I've revised and enhanced the strategy, based upon the feedback here. I think it is a nice compromise. Docs (see update section at the top) https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support Code: http://github.com/richhickey/clojure/commit/c79d28775e06b196ae1426f6c1446d00b621d2e1 Thanks to all for the feedback, keep it coming! Rich On Jun 17, 2010, at 4:13 PM, Rich Hickey wrote: I've been doing some work to enhance the performance, and unify the semantics, of primitives, in three branches. I've started to document this work here: https://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support Feedback welcome, Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 Jun 18, 2010, at 22:52 , Rich Hickey wrote: > I've revised and enhanced the strategy, based upon the feedback here. I think > it is a nice compromise. I agree this is a very nice compromise :) great work again and it is really cool to see how a community effort shapes clojure itself :D Regards, Heinz -- You 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 Fri, Jun 18, 2010 at 4:52 PM, Rich Hickey wrote: > I've revised and enhanced the strategy, based upon the feedback here. I > think it is a nice compromise. > > Docs (see update section at the top) > > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support > > Code: > > > http://github.com/richhickey/clojure/commit/c79d28775e06b196ae1426f6c1446d00b621d2e1 > > Thanks to all for the feedback, keep it coming! > > Rich Tried it out. Even faster than before. Love it. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
How to derive a protocol from another protocol?
I'm trying to develop a hierarchy (of sorts) of protocols and I'm
coming at it in from a Java Perspective, which I fully understand
might be my problem. In Java, I would do something like this:
interace A {
public void aFoo();
}
interface B {
public void bFoo();
}
interfacece AB extends A, B {
public void abFoo();
}
Then, I could have some objects that implement A, or B or AB (for
both). I'm trying to accomplish something similar with protocols in
Clojure, but I don't see how to. I would have expected that I could
have done something like (extend-protocol AB A B) to accomplish this.
It seems, however that I have to provide a concrete implementation in
that case.
I see that there is "satsifies?" function which determines if an
instance meets a protocol. Then, to implement the protocol, we use
"extend-protocol". It seems that it would make sense to implement a
protocol with "satisfy-protocol" -- as extend-protocol does now...and
then to use "extend-protocol" to create a new protocol based upon a
simpler protocol.
Can anyone describe the correct approach for extending protocols?
Thanks!
-Travis
--
You 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
labrepl isn't a project in netbeans 6.8 - (Ubuntu 10.04)
I was following the instructions to get labrepl up and running and hit a snag. Netbeans does not recognize Samples/Clojure/Relevance LabReplProject as a project. After creating it it does not appear in the Projects window. So I go to File -> Open Project and click on RelevanceLabRepl and hit Open Project. Instead of opening the project it displays the subfolders. Also, when RelevanceLabRepl is selected it does not display a name for Project Name:, and the box Open as Main Project is grayed out. I do have a normal clojure project that I can open. I am using clojure 1.0 if that matters. -- You 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 June 2010 15:08, Stuart Halloway wrote: > While I enjoy a theoretical debate as much as the next person, it would be > nice to see > > (1) examples of real code that fail on reasonable inputs, if this change > were made. And how difficult it would be to fix them. > > (2) examples of real code that get way faster, and the ease of making those > changes (if any). > > WRT #1, we have tested a few dozen libs, and found only a single trivial > breakage in their test suites. But I would say tha is still just plural > anecdotes. More data welcome! I'm new to clojure, and while I have an interest in fast number crunching, and in easily using big numbers, I don't have a valid opinion on the whole matter. However, I know that some time back, Python changed in precisely the opposite direction - from separate small and big numbers to a unified numeric type. Their situation is completely different (not least because all Python objects are effectively boxed, so the speed benefit of primitive arithmetic isn't relevant) but there may be real-world examples of code that demonstrates (1) in the Python discussions. If the information might be useful, I'd be happy to do some searching of the archives. Paul. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Possible Clojure Bug
I ran this in a slime REPL on AQUAMACS with clojure 1.1. It appears to be a bug. Am I mistaken? user> (def conj-test-vector ["1" "2" "3" "4"]) #'user/conj-test-vector user> conj-test-vector ["1" "2" "3" "4"] user> (conj conj-test-vector "5") ["1" "2" "3" "4" "5"] user> (conj conj-test-vector ["test"]) ["1" "2" "3" "4" ["test"]] user> (conj conj-test-vector "6") ["1" "2" "3" "4" "6"] user> Regards Phil Leone -- You 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
Delete my last post
Mistake there is no error -- You 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: parallel vs serial iteration in a "for" loop
Hey Meikel, On Jun 17, 10:48 pm, Meikel Brandmeyer wrote: > Hi, > > On Jun 18, 1:35 am, viksit wrote: > > > (loop for x in '(a b c d e) > > for y in '(1 2 3 4 5) > > collect (list x y) ) > > > ((A 1) (B 2) (C 3) (D 4) (E 5)) > > > Are there any good (and idiomatic) methods to achieve this using a > > Clojure loop construct? > > user=> (map vector [:a :b :c :d :e] [1 2 3 4 5]) > ([:a 1] [:b 2] [:c 3] [:d 4] [:e 5]) Oh yes, thanks. I know about using the map method - I was just wondering if Clojure's loop supports (or has any plans to support) the loop construct as in CL (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/ node235.html). And if not, then are there any ways to "loop" through 2 lists in parallel. Cheers Viksit > > Sincerely > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Save for the new equality semantics (bravo!), most of this can be viewed as a loss for newcomers to the language, especially those using project euler to learn the language. Shame you've been unable to think of some way to garuntee top performance while keeping overflow prevention the norm. On Jun 17, 3:13 pm, Rich Hickey wrote: > I've been doing some work to enhance the performance, and unify the > semantics, of primitives, in three branches. I've started to document > this work here: > > https://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support > > Feedback welcome, > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
This also seems to break the principle of make it work, make it right, make it fast. Math in Clojure isn't to the point that it works well yet. -- You 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
classpath and require
C:\Projects.clj>java -cp c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar clojure.main Clojure 1.1.0-alpha-SNAPSHOT user=> (require 'examples.introduction) java.io.FileNotFoundException: Could not locate examples/introduction__init.class or examples/introduction.clj on classpath: (NO_SOURCE_FILE:0) user=> C:\Projects.clj>echo %CLASSPATH% C:\Projects.clj;C:\clojure;C:\clojure-contrib C:\Projects.clj>dir examples\introduction.clj Volume in drive C is xxx Volume Serial Number is - Directory of C:\Projects.clj\examples 06/18/2010 04:52 PM40 introduction.clj 1 File(s) 40 bytes 0 Dir(s) xx,xxx,xxx bytes free C:\Projects.clj> -- You 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 June 2010 21:47, Daniel wrote: > Save for the new equality semantics (bravo!), most of this can be > viewed as a loss for newcomers to the language, especially those using > project euler to learn the language. Shame you've been unable to > think of some way to garuntee top performance while keeping overflow > prevention the norm. Actually the new idea with the + / +' split addresses this, so the Eulerians (?) among us may be happy again. I take it you've posted without reading the bottom of the thread or your message was stuck in the moderation queue... Incidentally, at first glance, I love the new tip of equal. Really exciting stuff! :-) Sincerely, Michał -- You 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: How to derive a protocol from another protocol?
Unless I'm mistaken, protocols cannot be derived. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: classpath and require
have you tried starting with: c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar;c: \projects.clj clojure.main On Jun 18, 2:00 pm, Mohammad Khan wrote: > C:\Projects.clj>java -cp > c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar clojure.main > Clojure 1.1.0-alpha-SNAPSHOT > user=> (require 'examples.introduction) > java.io.FileNotFoundException: Could not locate > examples/introduction__init.class or examples/introduction.clj on > classpath: (NO_SOURCE_FILE:0) > user=> > > C:\Projects.clj>echo %CLASSPATH% > C:\Projects.clj;C:\clojure;C:\clojure-contrib > C:\Projects.clj>dir examples\introduction.clj > Volume in drive C is xxx > Volume Serial Number is - > Directory of C:\Projects.clj\examples > > 06/18/2010 04:52 PM 40 introduction.clj > 1 File(s) 40 bytes > 0 Dir(s) xx,xxx,xxx bytes free > > C:\Projects.clj> -- You 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 Jun 18, 2010, at 22:02 , Daniel wrote: > This also seems to break the principle of make it work, make it right, > make it fast. Math in Clojure isn't to the point that it works well > yet. Daniel the decision was to keep things working and add speed as an option by using +' (and friends) specifically. So actually what happened is exactly what you wished for :). Just tested with the newest code: user=> (defn fact [n] (if (zero? n) 1 (*' n (fact (dec' n) #'user/fact user=> (fact 42) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:3) user=> (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) #'user/fact user=> (fact 42) 14050061177528798985431426062445115699363840N Regards, Heinz -- You 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: How to derive a protocol from another protocol?
I believe that too. It is not clear to me why you would need that without static typing. On Fri, Jun 18, 2010 at 10:50 PM, David Nolen wrote: > Unless I'm mistaken, protocols cannot be derived. > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You 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: Problems with URL params and http-agent
That works, thanks. It's a bit weird because I did try just http encoding the parameters before. But I obviously encoded the wrong characters, or maybe used the wrong character encoding. Hmmm. Thanks :) On Fri, Jun 18, 2010 at 11:24 AM, Michael Wood wrote: > On 18 June 2010 14:53, Timothy Washington wrote: > > Hmm, this is a good idea and I got the GET request string as... > > > /exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declare > > default element namespace 'com/interrupt/bookkeeping/users';//user[ > > @id='one'] > > This exact URI (behind http://localhost:8080) works when used by the > > browser, or wget.[...] > > But spaces etc. are not valid as part of a URI. They need to be escaped. > > What happens if you try this hard-coded URL: > > > http://localhost:8080/exist/rest/rootDir/system.main.system/aauthentication.main.authentication/users.aauth.users/user.one/user.one?_wrap=no&_query=declare%20default%20element%20namespace%20%27com/interrupt/bookkeeping/users%27%3B//user%5B%40id%3D%27one%27%5D > > Try that in the browser, wget and also your Clojure program. It might > also help to get a simple CGI script or something that can extract the > _wrap and _query parameters from the query string and just print or > log them so you can compare what you get from the browser and wget and > your program. > > -- > Michael Wood > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
scala
Quick disclaimer - there are a lot of things I like in Scala and I think Odersky & crew have done some very impressive work bringing functional language concepts to the VM and giving Java developers a path forward. I also don't think Clojure vs x language battles are very productive and don't want to encourage one. Anyway, I imagine my trajectory as a developer over the last 10 years is pretty typical. I started out doing Java stuff but fell in love with Ruby and Rails in 2004 and have been working almost entirely in Ruby since. The idea that all that heavy, cumbersome Java cruft could in many cases be dispensed with was a revelation and the discovery that I could build software in a language that offered *no* compile time error checking that was still robust was a very pleasant surprise. Like a lot of Ruby hackers though, I also saw some warts in the language and also remained curious about other approaches. Also like a lot of Ruby hackers, the recent rise of new JVM languages has piqued my interest, particularly Scala and Clojure. Scala seemed like a more natural step from Ruby and my first experiences with it were encouraging. It seemed to offer a lot of the expressiveness of Ruby but with potentially much better performance and more robust runtime and, intriguingly, static type checking. However, after writing a handful of small but non-trivial programs in it the complexity lurking under the surface started peeking through and the intricacies of the type system and the significant complexity of the language itself became more apparent. It started to feel like a step back to the rigors of Java and heavyweight syntax and fights with the compiler. The predominant Scala web platform, Lift, also seemed to have a very heavy, enterprisey sort of "correctness" about it that felt overengineered. So I bounced over to Clojure and its clean, elegant core and minimal, flexible syntax seemed very refreshing. It felt much more in the liberal, malleable spirit of Ruby. The functional stuff was a bit of a stretch but it also seemed built on a simpler set of core concepts than the featureful but complex Scala collections. Unfortunately there seems to be a lot more commercial momentum for Scala though. It's still a blip compared to the mainstream languages but I'm seeing more and more job posts mentioning it, and hardly any for Clojure. I don't think Scala is a bad language overall, but I'm not sure I'd dump Ruby for it. On the other hand, I can imagine migrating most of my dev work over to Clojure with the right project. Has anybody else wrestled with this choice? Any thoughts? -- You 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: Possible Clojure Bug
On Jun 18, 2010, at 18:48 , pleone wrote: > I ran this in a slime REPL on AQUAMACS with clojure 1.1. It appears to > be a bug. Am I mistaken? > > user> (def conj-test-vector ["1" "2" "3" "4"]) > #'user/conj-test-vector > user> conj-test-vector > ["1" "2" "3" "4"] > user> (conj conj-test-vector "5") > ["1" "2" "3" "4" "5"] > user> (conj conj-test-vector ["test"]) > ["1" "2" "3" "4" ["test"]] > user> (conj conj-test-vector "6") > ["1" "2" "3" "4" "6"] I'm not sure what would be a bug it all looks pretty sane to me, conj does not change the def'ed object (that is why it does not grow) and conjing another vector of cause adds the vector and not it's elements :) Regards heinz. -- You 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: classpath and require
Whoops, that should read: java -cp c:\clojure-contrib\clojure-contrib.jar;c:\clojure \clojure.jar;c: \projects.clj clojure.main On Jun 18, 2:51 pm, Rob Lachlan wrote: > have you tried starting with: > > c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar;c: > \projects.clj clojure.main > > On Jun 18, 2:00 pm, Mohammad Khan wrote: > > > > > C:\Projects.clj>java -cp > > c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar clojure.main > > Clojure 1.1.0-alpha-SNAPSHOT > > user=> (require 'examples.introduction) > > java.io.FileNotFoundException: Could not locate > > examples/introduction__init.class or examples/introduction.clj on > > classpath: (NO_SOURCE_FILE:0) > > user=> > > > C:\Projects.clj>echo %CLASSPATH% > > C:\Projects.clj;C:\clojure;C:\clojure-contrib > > C:\Projects.clj>dir examples\introduction.clj > > Volume in drive C is xxx > > Volume Serial Number is - > > Directory of C:\Projects.clj\examples > > > 06/18/2010 04:52 PM 40 introduction.clj > > 1 File(s) 40 bytes > > 0 Dir(s) xx,xxx,xxx bytes free > > > C:\Projects.clj> -- You 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: Possible Clojure Bug
I think he retracted this post in a separate new thread not long after posting this. cheers Rob On Jun 18, 2:56 pm, "Heinz N. Gies" wrote: > On Jun 18, 2010, at 18:48 , pleone wrote: > > > I ran this in a slime REPL on AQUAMACS with clojure 1.1. It appears to > > be a bug. Am I mistaken? > > > user> (def conj-test-vector ["1" "2" "3" "4"]) > > #'user/conj-test-vector > > user> conj-test-vector > > ["1" "2" "3" "4"] > > user> (conj conj-test-vector "5") > > ["1" "2" "3" "4" "5"] > > user> (conj conj-test-vector ["test"]) > > ["1" "2" "3" "4" ["test"]] > > user> (conj conj-test-vector "6") > > ["1" "2" "3" "4" "6"] > > I'm not sure what would be a bug it all looks pretty sane to me, conj does > not change the def'ed object (that is why it does not grow) and conjing > another vector of cause adds the vector and not it's elements :) > > Regards > heinz. -- You 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 Fri, Jun 18, 2010 at 1:52 PM, Rich Hickey wrote: > I've revised and enhanced the strategy, based upon the feedback here. I > think it is a nice compromise. Looks good to me. -- You 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
In connection to a conversation on #clojure (in progress as I write)... Apparently loop/recur locals are now primitive by default: (defn fact [n] (loop [n n r 1] (if (zero? n) r ;; note the regular * on the next line (recur (dec n) (* r n) will throw ArithmeticException because of integer overflow, because r is a long. The solution provided by Rich is to "hint" r to be a boxed number: (num r) => gives old behaviour. I'm vaguely in favour of switching around to boxed-by-default locals, but that's just a very early initial impression... Just wanted to point this out for the consideration of others here. Sincerely, Michał -- You 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 Jun 18, 2010, at 22:52 , Rich Hickey wrote: > Thanks to all for the feedback, keep it coming! Okay you asked for it :P to quote from the IRC: mmarczyk: also, (defn fact [n] (loop [n n r 1] (if (zero? n) 1 (recur (dec n) (* r n) throws on (fact 40) -- that's with *, not *' and it trhows: java.lang.IllegalArgumentException: Value out of range for long: 158905670470170624000 and as you explained it is because 1 is a primitive instead of a Number. This is quite frankly not the best behavior in my eyes. Not only is the error message overly cryptic, and if you hadn't explained us what went wrong we likely taken hours to figure it out, but also the behavior is very very strange. This again is not 'it just works' but 'it works most of the time and if not has horrible painful and unpredictable consequences'. I start this again, I know, but imagine someone starting to code in clojure and reaching this point, they will be super frustrated, toss the language in the next corner and start crying for the next full moon. Don't get me wrong it is not a reason to drop the language, god (or whatever you believe in) forbid, but it is very well a reason not to learn the language. I say it frankly if that would have been one of my first experiences, before I learned what joy and beauty clojure can be, I'd had turned without a second thought - and taking this is a very simple example many newcomers might actually write, this is a not unlikely scenario. Regards, Heinz -- You 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: scala
I've spent a number of years looking for a functional programming language suitable for the kind of work I do. evaluating Clojure, Haskell, Erlang, Scala, F#, Mozart, ML, Clean, Racket, and probably some others I'm not thinking about right now. For me, once Clojure hit 1.0 status, it was clearly the best choice for my purposes. Scala is probably my second choice, but I think there's a chance it would be my first if I were working on a large team -- I have an unfounded opinion that static typing can be especially useful for ensuring that components produced by different individuals get properly linked up. But as a solo developer, I feel great about my decision to use Clojure. So to answer your question, yes, a lot of us have spent time evaluating many languages and agonizing over which is the best one for our purposes. Try the languages that interest you, and decide for yourself. -- You 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: parallel vs serial iteration in a "for" loop
Personally, I think the cl loop-macro is kind of ugly. Yes, it's a nice dsl for looping, but it is almost too powerful for my taste. Too complicated to learn, if you can accomplish the same thing with sexps. However, you can combine doseq, destructuring and the map-stuff by Meikel Brandmeyer to loop over two lists in parallel: (doseq [[a b] (map vector [:a :b :c :d :e] [1 2 3 4 5])] (println a "," b)) (You can also try to port the loop-macro from common lisp to clojure, that would be interesting) On Fri, Jun 18, 2010 at 7:45 PM, viksit wrote: > Hey Meikel, > > On Jun 17, 10:48 pm, Meikel Brandmeyer wrote: >> Hi, >> >> On Jun 18, 1:35 am, viksit wrote: >> >> > (loop for x in '(a b c d e) >> > for y in '(1 2 3 4 5) >> > collect (list x y) ) >> >> > ((A 1) (B 2) (C 3) (D 4) (E 5)) >> >> > Are there any good (and idiomatic) methods to achieve this using a >> > Clojure loop construct? >> >> user=> (map vector [:a :b :c :d :e] [1 2 3 4 5]) >> ([:a 1] [:b 2] [:c 3] [:d 4] [:e 5]) > > Oh yes, thanks. I know about using the map method - I was just > wondering if Clojure's loop supports (or has any plans to support) the > loop construct as in CL (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/ > node235.html). And if not, then are there any ways to "loop" through 2 > lists in parallel. > > Cheers > Viksit > >> >> Sincerely >> Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Moritz Ulrich Programmer, Student, Almost normal Guy http://www.google.com/profiles/ulrich.moritz -- You 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 Jun 19, 2010, at 0:32 , Heinz N. Gies wrote: > > On Jun 18, 2010, at 22:52 , Rich Hickey wrote: > >> Thanks to all for the feedback, keep it coming! Another one: http://gist.github.com/444344 This is the same problem as with the exception but this time it does not crash just return very odd and utterly wrong value. This is actually broken in my eyes since it will lead to unexplaind errors especially since (* 1 0.2) works just fine in repl. Again the values in a binding form should be from the NumberStack by default and only get primitive when explicitly declared so for the sake of not confusing the hell out of people. Regards, Heinz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure script in the classpath
I've just seen a couple of postings which, if I'm not mistaken, imply that it's possible to have a Clojure script in my classspath. Is that right? I come from a Python background (little or no Java experience) and the idea that anything other than .class or .jar files (or directories) could be on the classpath never occurred to me. Can anyone give me a complete example of how this works? (I probably need to get the file names and namespaces right, something I'm still struggling with - again the Java/JVM requirements for filenames that match classnames is a new concept for me). Could I have found anything about this on the web? The Java documentation (http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html) didn't mention anything other than classes/jars/zips/directories, and my Google skills didn't turn up anything clojure-specific. Thanks, Paul. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: classpath and require
No, it didn't work.. what else I could be missing.. On Fri, Jun 18, 2010 at 5:56 PM, Rob Lachlan wrote: > Whoops, that should read: > > java -cp c:\clojure-contrib\clojure-contrib.jar;c:\clojure > \clojure.jar;c: > \projects.clj clojure.main > > On Jun 18, 2:51 pm, Rob Lachlan wrote: > > have you tried starting with: > > > > c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar;c: > > \projects.clj clojure.main > > > > On Jun 18, 2:00 pm, Mohammad Khan wrote: > > > > > > > > > C:\Projects.clj>java -cp > > > c:\clojure-contrib\clojure-contrib.jar;c:\clojure\clojure.jar > clojure.main > > > Clojure 1.1.0-alpha-SNAPSHOT > > > user=> (require 'examples.introduction) > > > java.io.FileNotFoundException: Could not locate > > > examples/introduction__init.class or examples/introduction.clj on > > > classpath: (NO_SOURCE_FILE:0) > > > user=> > > > > > C:\Projects.clj>echo %CLASSPATH% > > > C:\Projects.clj;C:\clojure;C:\clojure-contrib > > > C:\Projects.clj>dir examples\introduction.clj > > > Volume in drive C is xxx > > > Volume Serial Number is - > > > Directory of C:\Projects.clj\examples > > > > > 06/18/2010 04:52 PM40 introduction.clj > > >1 File(s) 40 bytes > > >0 Dir(s) xx,xxx,xxx bytes free > > > > > C:\Projects.clj> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Sorry guys - missed that latest post. This new approach is something I can definitely get behind. :) -- You 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
Basic toolset for non-Java programmer
I'm wondering, what would be a useful basic set of tools for a newcomer to Clojure with no Java background? I'm not really talking about IDEs (everyone has their own opinions about IDEs, and I've seen some discussions elsewhere to give me some pointers on that one). I'm more interested in things like build tools, testing frameworks, debuggers, etc. Also, in terms of deployment, what should I be looking at? To try to clarify what I mean: - Build tools: There seem to be things like ant, maven, leiningen. How do they relate to each other? Is there an "obvious" best answer or should I be expecting to check them all out depending on my needs? In that case, are there any good comparisons around? - Debuggers: Should I be assuming I use my IDE for debugging? What if I stick to a basic text editor to develop my code? Is there a good standalone debugger? - Profilers: Same sort of question - do IDEs offer this, are there standalone tools? - Testing: I've not really got to the documentation on Clojure's own testing tools, so maybe that's all I need, but are there testing frameworks I should look at, that sort of thing? - Deployment: For simple standalone utilities, am I looking at bat file wrappers (I'm on Windows mainly) to set classpath and the like? Given that there are some annoying limitations with bat files (nasty nesting behaviour, ugly console windows for GUI applications), are there any commonly used better solutions? For web applications, I gather that a servlet container (all that fancy J2EE stuff :-)) and something like compojure is a good place to start. For non-web long-running services, is it still reasonable to use an application server, or should I be looking at something to wrap a Clojure app up as a Windows service (something like "Java Service Wrapper" (http://wrapper.tanukisoftware.org/doc/english/download.jsp) came up for me on a Google search)? That's a lot of stuff, and I certainly don't need to dive into all of this at once, but any pointers, comments or suggestions would be very gratefully received. Thanks in advance, Paul. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: scala
Bear in mind that Scala is about 5 years older than Clojure, so it's had more time to build up momentum. On Jun 18, 5:56 pm, cageface wrote: > Unfortunately there seems to be a lot more commercial momentum for > Scala though. It's still a blip compared to the mainstream languages > but I'm seeing more and more job posts mentioning it, and hardly any > for Clojure. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Turnabout is fair play, so I've produced a version that swaps the defaults, still in the 'equal' branch: Docs: https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support Code: http://github.com/richhickey/clojure/commit/310534b8e7e7f28c75bb122b4bf1bee320cdae67 You can get the older arbitrary-precision default with this commit: http://github.com/richhickey/clojure/commit/7652f7e935684d3c7851fbcad8ddce97e510a5a6 I've also temporarily enabled a diagnostic (in both) that tells you when you have a mismatch between a loop initializer and its recur form. It goes off over a hundred times in Clojure itself, when using the arbitrary precision default. In each case, the recur value is needlessly being boxed, every iteration of a loop, for loops that will never be bigints; indexes, counters etc. I expect this will be very typical of most code. But removing that useless overhead would be a lot of tedious work. With the defaults swapped, only 2 warnings. Pay for what you use ... Rich On Jun 18, 4:52 pm, Rich Hickey wrote: > I've revised and enhanced the strategy, based upon the feedback here. > I think it is a nice compromise. > > Docs (see update section at the top) > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Pr... > > Code: > > http://github.com/richhickey/clojure/commit/c79d28775e06b196ae1426f6c... > > Thanks to all for the feedback, keep it coming! > > Rich > > On Jun 17, 2010, at 4:13 PM, Rich Hickey wrote: > > > > > I've been doing some work to enhance the performance, and unify the > > semantics, of primitives, in three branches. I've started to document > > this work here: > > >https://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support > > > Feedback welcome, > > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
> I've also temporarily enabled a diagnostic (in both) that tells you > when you have a mismatch between a loop initializer and its recur > form. It goes off over a hundred times in Clojure itself, when using > the arbitrary precision default. In each case, the recur value is > needlessly being boxed, every iteration of a loop, for loops that will > never be bigints; indexes, counters etc. I expect this will be very > typical of most code. But removing that useless overhead would be a > lot of tedious work. > > With the defaults swapped, only 2 warnings. > How often does the warning go off if you go back to arbitrary-precision by default, but make literals return boxed numbers again? I suspect your comparison is unfair because lots of the loop initializers are probably literals. --- A concern I have is that interop forms that return primitives can cause a loop var to have a primitive type. (loop [procs (.availableProcessors Runtime/getRuntime)] ; Current clojure makes procs a primitive, do people really expect that? Would it be possible for loop to use boxed numbers always by default, and only use primitives if some specific metadata is on the initializer? So in that world: (loop [i 5] ; Boxing is always done by the loop statement, even if initialized with a primitive (loop [procs (.availableProcessors Runtime/getRuntime)] ; Boxing is done by the loop statement (loop [^:primitive procs (.availableProcessors Runtime/getRuntime)] ; Primitive is used, good because we are expecting it I'm not sure which order the metadata should go in such a scheme. (loop [^:primitive i 5] (loop [i ^:primitive 5] (loop [i (prim 5)] --Aaron -- You 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
An idea to consider: How about keeping the arbitrary-precision default, but add a loop' construct to the family of +',-',*',inc', and dec' for primitive optimization? The loop' construct would bind primitive literals, whereas the loop construct would keep the literals boxed, so people who don't want to analyze types rigorously in their loop/recur constructs won't get mismatch errors. I see that using primitive literals by default in loop/recur offers speed benefits for the common case (recur type matches the loop-declared type), but I worry about how hard it might be to analyze and make sure that I'm always recurring with a type that exactly matches what is in the loop. Any other ideas on how to solve the problem of mismatch errors for "casual coders"? -- You 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 Jun 18, 2010, at 9:52 PM, Aaron Cohen wrote: I've also temporarily enabled a diagnostic (in both) that tells you when you have a mismatch between a loop initializer and its recur form. It goes off over a hundred times in Clojure itself, when using the arbitrary precision default. In each case, the recur value is needlessly being boxed, every iteration of a loop, for loops that will never be bigints; indexes, counters etc. I expect this will be very typical of most code. But removing that useless overhead would be a lot of tedious work. With the defaults swapped, only 2 warnings. How often does the warning go off if you go back to arbitrary-precision by default, but make literals return boxed numbers again? I suspect your comparison is unfair because lots of the loop initializers are probably literals. It would be easy to make it go away. The point is not the mismatches themselves, but they serve as a counter - how many loops had primitive init and needed only primitive arithmetic? Each warning is a case where it could be automatically fast but isn't. Making the warning go away will leave the inefficiency but make it silent. It is just a measurable loss to counter all the theoretical arguments being made. --- A concern I have is that interop forms that return primitives can cause a loop var to have a primitive type. (loop [procs (.availableProcessors Runtime/getRuntime)] ; Current clojure makes procs a primitive, do people really expect that? Would it be possible for loop to use boxed numbers always by default, and only use primitives if some specific metadata is on the initializer? So in that world: (loop [i 5] ; Boxing is always done by the loop statement, even if initialized with a primitive (loop [procs (.availableProcessors Runtime/getRuntime)] ; Boxing is done by the loop statement (loop [^:primitive procs (.availableProcessors Runtime/getRuntime)] ; Primitive is used, good because we are expecting it I'm not sure which order the metadata should go in such a scheme. (loop [^:primitive i 5] (loop [i ^:primitive 5] (loop [i (prim 5)] Yes, it's easy to imagine a world where people who want efficient code have to jump through hoops to get it. OTOH, you can just say (num some- expr) to force it to be boxed, if you want assurance of an Object initializer. Which will be the more common need? I have to say I'm in the 'pay for what you use' camp - you need a box, you ask for one. If I don't (and neither do any of those loops), why should I have to do extra work to avoid it? Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
So far most of the action has concerned arithmetic ops (+, -, *, /). Will these new semantics include the bit-shift operators? I vote yes. My use cases for bit ops would benefit from primitive ops. On a related note, my use cases call for silent overflow of bit shifts (pseudo random number generators). Will there be a way to disable overflow exceptions (either via a binding or through unchecked-* functions)? Thanks, -Mark On Jun 18, 8:33 pm, Rich Hickey wrote: > Turnabout is fair play, so I've produced a version that swaps the > defaults, still in the 'equal' branch: > > Docs: > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Pr... > > Code: > > http://github.com/richhickey/clojure/commit/310534b8e7e7f28c75bb122b4... > > You can get the older arbitrary-precision default with this commit: > > http://github.com/richhickey/clojure/commit/7652f7e935684d3c7851fbcad... > > I've also temporarily enabled a diagnostic (in both) that tells you > when you have a mismatch between a loop initializer and its recur > form. It goes off over a hundred times in Clojure itself, when using > the arbitrary precision default. In each case, the recur value is > needlessly being boxed, every iteration of a loop, for loops that will > never be bigints; indexes, counters etc. I expect this will be very > typical of most code. But removing that useless overhead would be a > lot of tedious work. > > With the defaults swapped, only 2 warnings. > > Pay for what you use ... > > Rich > > On Jun 18, 4:52 pm, Rich Hickey wrote: > > > > > I've revised and enhanced the strategy, based upon the feedback here. > > I think it is a nice compromise. > > > Docs (see update section at the top) > > >https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Pr... > > > Code: > > >http://github.com/richhickey/clojure/commit/c79d28775e06b196ae1426f6c... > > > Thanks to all for the feedback, keep it coming! > > > Rich > > > On Jun 17, 2010, at 4:13 PM, Rich Hickey wrote: > > > > I've been doing some work to enhance the performance, and unify the > > > semantics, of primitives, in three branches. I've started to document > > > this work here: > > > >https://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support > > > > Feedback welcome, > > > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 Jun 18, 2010, at 10:09 PM, Mark Engelberg wrote: An idea to consider: How about keeping the arbitrary-precision default, but add a loop' construct to the family of +',-',*',inc', and dec' for primitive optimization? The loop' construct would bind primitive literals, whereas the loop construct would keep the literals boxed, so people who don't want to analyze types rigorously in their loop/recur constructs won't get mismatch errors. I see that using primitive literals by default in loop/recur offers speed benefits for the common case (recur type matches the loop-declared type), but I worry about how hard it might be to analyze and make sure that I'm always recurring with a type that exactly matches what is in the loop. Did you try it? The compiler does that analysis and reports any mismatch: user=> (defn foo [] (loop [x 42] (recur 4.2))) NO_SOURCE_FILE:2 recur arg for primitive local: x is not matching primitive, had: double, needed: long user=> (defn foo [] (loop [x 42] (recur false))) NO_SOURCE_FILE:5 recur arg for primitive local: x is not matching primitive, had: java.lang.Boolean, needed: long user=> (defn foo [] (loop [x 4.2] (recur (meta #'first NO_SOURCE_FILE:15 recur arg for primitive local: x is not matching primitive, had: java.lang.Object, needed: double Any other ideas on how to solve the problem of mismatch errors for "casual coders"? Those could become hard errors again. But there are legitimate correct cases that would then need annotation: (defn foo [] (loop [x 42] (recur (:y z Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
