Re: Clojure on PyPy
On Nov 17, 2011, at 10:45 AM, Brent Millare wrote: ...The main point the poster should take away is the lack of any library/runtime tools, you have to build from the ground up many things you take for granted when targeting the JVM. I've thought about Clojure on PyPy too. My thought was that you would make Clojure an RPython addition to the RPython Python. That would give you a pretty good start at a library, at least. When I glanced at it, PyPy's build tools didn't seem to be sophisticated enough to handle this as some kind of add-in to the Python implementation: you would have had to fork PyPy to get this to work, or spend some time on the build tools. Maybe I missed something. I also felt that sticking with the official Java implementation of Clojure would be more practical. It would certainly be fun to put Clojure on PyPy, though. Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure on PyPy
On Nov 17, 2011, at 11:09 AM, Timothy Baldridge wrote: I also felt that sticking with the official Java implementation of Clojure would be more practical. It would certainly be fun to put Clojure on PyPy, though. There is one insanely off-the-wall idea I've been thinking about recently, however: 1) Implement a full JVM in PyPy using GNU Classpath. Write a Java bytecode interpreter in PyPy. This way you get the power of PyPy (tracing JIT) with the power of Java (classpath) 2) Run stock JVM Clojure on this interpreter 3) 4) Profit! LOL, that is awesomely insane! It would certainly be fascinating to see how it turned out in terms of comparative performance. Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conj extracurricular activities spreadsheet
Hi. I'm not sure how many of these I'll practically be able to attend, but I'll be optimistic. Please mark me down for Clojure and the web, literate programming, core.logic / minikanren, and music (voice, bringing it). Gary On Oct 25, 2011, at 10:25 PM, Michael Fogus mefo...@gmail.com wrote: We built quite a large list before the internet graffiti started taking over, so if you have an addition then please post it here and it'll be added. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: defprotocol problem in 1.3?
On Oct 4, 2011, at 7:40 PM, hgreen wrote: Somehow, I just knew someone was going ask why...? :-) :-) A while back, I constructed a little mechanism for defining data types, built on top of the protocol/record/type mechanism. Under certain circumstances, it generates protocols with no methods, basically in situations where it wants to identify a class of types as such, but those those types have no common methods that aren't already part of other protocols. Sounds strange, and probably is; but it's basically a manifestation of the fact that a protocol isn't just a collection of methods, but a property that can be tested, e.g., with satisfies?. Heh... An explanation that's several orders of magnitude more pretentious than the rather humble reality. In the end, it's not a huge deal to work around (it's not that hard to generate a dummy method), but it's just another set of tedious special cases to deal with. FWIW, sounds like what I call a marker interface (http://en.wikipedia.org/wiki/Marker_interface_pattern). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: suggestion for clojure development
On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote: On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein arthuredelst...@gmail.com wrote: You may think I'm doing it wrong, but I don't think I'm alone at all. I don't think you're doing anything wrong - and I'm sure many people only do minimal research on tools they use. I just think your expectations of Clojure the language are unrealistic, in terms of maintaining total compatibility with the myriad third party (and sometimes unmaintained) libraries. For comparison, Scala went thru a lot of binary compatibility issues in the transition from 2.7 to 2.8, to the point that even milestone builds were not always compatible with each other. This meant the entire tool chain had to be rebuilt on almost every milestone build. Apparently there were a few similar bumps on the transition to 2.9 (I don't know for sure: I lived thru the 2.7 to 2.8 debacle and chose not to go to 2.9). I hear similar stories for other fast-evolving languages. I think it's just a fact of life with new technologies - and we pay that price for being early adopters. FWIW, similarly, despite an intent of backwards compatibility, Python has had migration costs and small backward compatibility niggles for every single major release (2.2 - 2.3, 2.3 - 2.4, and so on) ever since I've been involved with it, which is...I dunno, more than 10 years now? My current project doesn't use 2.7 yet because the cost/benefit hasn't been there yet. And, of course, the switch to Python 3 intentionally broke backwards compatibility. Every major project I've been involved with had to set aside some not-insignificant amount of time to migrate our own code base, determine what to do with dependencies, and even help migrating some of the dependencies. We have said exactly the same sorts of things that Arthur is saying. :-) And then replied to ourselves with the same sorts of things that Sean is saying. Perhaps Java has been different, but the languages I use and follow have not, with the exception of JavaScript. I perceive it to be a mildly unfortunate fact of life at this point. Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: TriClojure
Awesome, thank you! Sadly, this week and next are unavailable for a couple of reasons, but please have another hack night and/or presentation soon! Gary On Jan 10, 2011, at 9:15 PM, Christopher Redinger wrote: Hey all! Just wanted to announce that we have formed TriClojure, the Triangle Clojure Users Group. Tomorrow night, Jan 11th, we are co-hosting with TriFunc a talk from Clojure/core member Aaron Bedra title Building Analytics with Incanter Compojure. If you are in the area, please drop by the Relevance, Inc offices in Durham at 7pm. If you didn't get enough notice for his meetup, don't worry! Next week, you can drop by the Raleigh.rb to hear Stu Halloway talk about Clojure for Ruby programmers. And don't forget to join our group for future meetup announcements: http://www.meetup.com/TriClojure/ 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: Collapse some functions? (was Re: clojure.core function decision tree)
On Nov 11, 2010, at 10:36 AM, Gary Poster wrote: To dupe, this is my really-fast definition of seq-reverse, ...really fast is supposed to mean really quickly written not highly performance optimized... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Collapse some functions? (was Re: clojure.core function decision tree)
On Nov 10, 2010, at 11:16 AM, Meikel Brandmeyer wrote: Hi, On 10 Nov., 17:09, Gary Poster gary.pos...@gmail.com wrote: I believe that the cost of having developers remember both rseq and reverse (why can't reverse just DTRT if it is given a vector?), last and peek (same), butlast and pop (same), and nth and get (same) is unnecessarily high. Ehm. No. rseq O(1), reverse O(n). peek O(1), last O(n). pop O(1), butlast O(n). get O(1), nth O(n). (Where O(1) might sometimes mean O(log32 n)) The different functions are there under different names, because they have different performance promises. But that's exactly my point. Why should developers have to remember to use rseq on a vector, as the first example? Why can't reverse simply be part of a protocol, so that it gives O(1) when it can? Is there *any* practical value to having reverse have O(n) performance on a vector? Clojure is advertised as a practical language (I remember reading it early in JoC, for instance), and I don't see it here. Then peek is not equivalent to last. For lists it is equivalent to first. OK, thank you. As I said initially, the email could have been researched better, but the larger thought is still valid, with other reasonable examples. Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Collapse some functions? (was Re: clojure.core function decision tree)
On Nov 10, 2010, at 6:59 AM, Pepijn de Vos wrote: Hi all, It occurred to me that Clojure has a huge core namespace. While OO languages like Python and Java stuff functions into modules and objects and have a core of a few dozen functions, Clojure's core contains everything you might need for most tasks, but has over 400 functions in core, with no easy way to navigate them. I'm hijacking the thread, but at least I changed the subject. :-P Your first paragraph reminded me of one of the clojure emails I've wanted to send lately, but haven't gotten around to. I agree with your observation, but in addition to tools to navigate the functions, I wanted to suggest that some of the functions should be collapsed, leading to a smaller collection of functions to actually have to know. Especially with protocols, I believe that the cost of having developers remember both rseq and reverse (why can't reverse just DTRT if it is given a vector?), last and peek (same), butlast and pop (same), and nth and get (same) is unnecessarily high. Those are all vector examples, which are all I had collected in my initial notes for the email. I suspect there are others, but I haven't done the work yet. I'd love to see these cleaned up, myself, and would be willing to help do so if my Clojure skills proved sufficient. Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Collapse some functions? (was Re: clojure.core function decision tree)
On Nov 10, 2010, at 1:38 PM, Meikel Brandmeyer wrote: Hi, Am 10.11.2010 um 17:37 schrieb Gary Poster: But that's exactly my point. Why should developers have to remember to use rseq on a vector, as the first example? Why can't reverse simply be part of a protocol, so that it gives O(1) when it can? Is there *any* practical value to having reverse have O(n) performance on a vector? Clojure is advertised as a practical language (I remember reading it early in JoC, for instance), and I don't see it here. You got this backwards. There is nothing wrong with reverse being fast on vectors. Cool. But it's promise is only O(n). In my opinion, its promise is that it reverses anything that supports the minimal seq interface. Its implementation can be pluggable via protocols, and we should be able to expect that the language provides reasonable implementations for its own data structures. (In fact, in Clojure, we should be able to expect that we can provide our own implementations for our own data structures.) If you need fast reversal you have to use rseq. It makes your intention explicit My intention to not be inefficient with a vector? That doesn't seem useful to me. My intention that I should be using a vector? If that's really important to me, then I can make some gesture to ensure it, I suppose, but I don't see that as being a reasonable common case. IMO, the reasonable common case for a practical language that is dynamically typed is that you take what you get and do your best with it. I think this--the idea that there is some value in being explicit that you expect a vector *by choosing these alternate vector-specific functions*--is the heart of our disagreement, as I highlight at the end. We seem to agree about most everything else. and will protect you from someone passing in a seq or a list. rseq will bark at you, while reverse silently decays your applications performance. Right, the silently decaying is my issue. It's not practical. It's giving a loaded gun to someone who cares about performance: reverse will always work, never complain, and silently and unnecessarily eat processing cycles if it is a vector. Another point is: last, butlast, reverse are all functions from the seq library. However there is a difference between seqs and datastructures. Currently there is a clear distinction between functions acting on datastructures and functions acting on seqs. And I think this is a good thing. One has to clearly understand both worlds: A vector is not a seq. A list happens to be its own seq. Not every seq is a list. Using the functions for datastructures clearly states in which world you are currently walking. As soon as you are in seq world you are in general bound to O(n). reverse being fast on vectors is at best an implementation detail. AFAICT, the difference between datastructures and seq is that a seq is an interface, while data structures are concrete implementations. With a language that offers pluggable implementations for the interfaces, let's use that feature! To be clear: I don't argue that reverse should be fast on vectors. I'm pretty sure that's shouldn't from context; please correct me otherwise. Of course this would be a useful optimisation which basically comes for free. I argue that removing the data structure functions with their performance promises is a logical consequence of such an optimisation. I agree. As mentioned above, I think the primary (only?) point that we disagree on is that I think that this is a good thing (because it will simplify the number of things people need to know to use clojure, and get rid of a loaded gun for novices or even the unwary), and you don't (because you feel that this is a valuable way to constrain types, AIUI). Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Resources on optimizing Clojure code
On Nov 4, 2010, at 1:32 PM, cej38 wrote: It is wonderful that people are so willing to help with a specific problem, and I encourage you to continue doing so, but I don't think anyone has answered the real question. Is there material out there that describes some of the mechanisms, tools, ideas, etc. that will allow the average clojure user to optimize their code. Chapter 12 of Joy of Clojure is about performance (type hints, transience, chunked sequences, memoization, coercion). Arguably much of the book is also about what you describe broadly, since it is trying to teach and encourage efficient, idiomatic Clojure usage generally, AIUI. Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
