Re: Creating map from string
Ok, those sugggestions work great. Thanks for the help. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Clojurescript One and Websockets
I'm not involved (much) with Webbit other than using it in prod for my web socket stuff. I believe Kushal Pisavadia (cc'd) & James Reeves have been talking about webbit features that Ring could leverage, but I'm not familiar with the details. Cheers, Jay On Sat, Mar 17, 2012 at 7:23 PM, Brian Rowe wrote: > Hey Jay, > > Are there any plans to make a ring adapter for webbit? > > > On Friday, March 2, 2012 6:40:27 AM UTC-5, Jay Fields wrote: >> >> clojure + web sockets, not using >> aleph: http://blog.jayfields.com/2011/02/clojure-web-socket-introduction.html >> >> On Mar 1, 2012, at 10:51 PM, Brian Rowe wrote: >> >> Hi, >> >> I'm thinking about using clojurescript one a starting point for a web >> game. I would like to use websockets as the primary communication mechanism >> between the browser and the server. As far as I know Zack Tellman's Aleph >> is the only clojure web server that supports websockets. Is this true? If >> so, are there any guides showing how to modify clojurescript one to use >> Aleph? If there are no guides, how much work would it take to modify cljs >> one to use aleph? >> >> 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Creating map from string
On Sun, Mar 18, 2012 at 21:04, Jimmy wrote:
> Hi,
>
> I would like to generate a hashmap from a string. The key portions of
> the string will have some a prefix such as @ to define that they are
> a key. So the following string
>
> "@key1 this is a value @another-key and another value @test1 and
> other value"
>
> would get converted to.
>
> { :@key1 "this is a value", :@another-key "and another
> value" , :@test1 "and other value"}
>
> What's the best way to do this?
> Thanks,
> Jimmy
Things to think about when designing an ad-hoc format:
- How are you handling white space?
Your example seems to indicate that any amount of white space is
allowed and ignored between key and value or value and key, but white
space internal to the value is preserved. I suppose keys will never
contain white space since that's not expressible as the first bit of
white space following the key marks the transition to value.
- Values can't be empty, consist of, start with or end with white space.
- Values can't contain @ unless you provide some kind of escaping convention.
// Ben
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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 url exception
Explanation/clarification added to the ticket. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: clojurewest talk videos?
Yes, all talks were recorded and will be released on http://infoq.com starting in about 3 weeks on a rolling basis. Alex On Sunday, March 18, 2012 1:12:41 PM UTC-5, Las wrote: > > Hi, > > will the videos of the talks be available for those who did not make it to > the conference? > > thx > > -- > László Török > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: clojurewest talk videos?
Clojure-related posts/presentations from InfoQ should be automatically propagated to Planet Clojure... On Mon, Mar 19, 2012 at 3:33 PM, Alex Miller wrote: > Yes, all talks were recorded and will be released on http://infoq.com > starting in about 3 weeks on a rolling basis. > > Alex > > > On Sunday, March 18, 2012 1:12:41 PM UTC-5, Las wrote: >> >> Hi, >> >> will the videos of the talks be available for those who did not make it to >> the conference? >> >> thx >> >> -- >> László Török >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/core accepted as a Google Summer of Code 2012 Mentoring Organization!
I saw there was a GSoC 2012 unsession at Clojure/West, how'd that go? Anybody want to summarize? David On Fri, Mar 16, 2012 at 10:10 PM, Baishampayan Ghose wrote: > Woohoo! Huge win. > > Psst, can I be a mentor? May be an assistant mentor? I don't have any > specific project idea in mind, but I am interested in ClojureScript > besides Core Clojure. > > Regards, > BG > > On Fri, Mar 16, 2012 at 12:07 PM, David Nolen > wrote: > > http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012 > > > > Congratulations to the entire Clojure community, we have a lot to look > > forward to this summer. > > > > David > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Clojure Dev" group. > > To post to this group, send email to clojure-...@googlegroups.com. > > To unsubscribe from this group, send email to > > clojure-dev+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/clojure-dev?hl=en. > > > > -- > Baishampayan Ghose > b.ghose at gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "Clojure Dev" group. > To post to this group, send email to clojure-...@googlegroups.com. > To unsubscribe from this group, send email to > clojure-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/clojure-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure code optimizer
On Sat, Mar 17, 2012 at 5:59 PM, Andru Gheorghiu wrote: > Hello, > > I am a third year student majoring in computer science and I am > interested in the Clojure code optimizer project proposed for GSoC > 2012. Could you please give more details (or examples) on the types of > optimizations the optimizer should be able to do? Also, what is a tree > shaker implementation? > As far as I know this is dead-code elimination. > I was thinking that an optimizer could be implemented as a rule engine > similar to Jess or CLIPS in which rules contains patterns which need > to be replaced and the code to replace them with. For example one > could write patterns for generic linear recursive functions that > should be replaced with linear iterative functions. Similarly patterns > can be written for functions which replicate the behavior of an > already existing function (such as reverse, map, apply etc) and a rule > to replace those functions with the predefined ones. > > Thank you, > Andru Gheorghiu There's actually some work happening along these lines with Kibit, https://github.com/jonase/kibit. Is this something that interests you? 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: understanding data structures, and other low-level stuff
I've got my copy of Cormen, Leiserson, and Rivest's book with me now, which is the 3rd edition, and looking in the index under "persistent" it does have one exercise in chapter 13 on that topic, and a mention later in the book that is a paragraph or two long with a reference to a research paper. So while that book isn't a good reference for persistent data structures in particular, it is a good reference for the more widely known (and some not-so-widely known) mutable data structures. If you learn at least a few of those, then you are very well prepared to understand Clojure's persistent data structures, too, and there are blog posts on the topic that can get you a lot of the way there (once you understand the basics), e.g.: http://blog.higher-order.net/2009/09/08/understanding-clojures-persistenthashmap-deftwice/ The book does assume a knowledge of how basic arrays work, but those are quite simple and hopefully my message below is nearly as much as there is to know about them. To get an understanding of data structures like hash tables and some different kinds of trees, you can probably get there just reading a few of the introductory sections at the beginning, and then jump to those specific sections. Save all the stuff on algorithms for when and if you are interested. Andy On Mar 18, 2012, at 8:57 PM, Andy Fingerhut wrote: > Feel free to ask follow-up questions on the basics privately, since many > Clojure programmers are probably already familiar with them, whereas > follow-up questions on persistent data structures are very on-topic, since I > would guess many people who have studied computer science and/or programming > for a while may not be familiar with them. > > The classic model of an array is based upon the implementation of physical > RAM in a computer: a physical RAM, at a high level and leaving out details of > variations, is a device where you either give it a command READ and an > address, and it returns an 8-bit byte stored at that location, or you give it > a WRITE command, an address, and an 8-bit value, and it stores the 8-bit > value at the location given by the address. > > A classic array is a one-dimensional structure indexed by an integer i, > usually from 0 up to some maximum value N, and every item in the array stores > an item of the same size and type, e.g. all 32-bit integers, or all pointers > to some object elsewhere in the memory. If every item fits in exactly B > bytes, and the first item of the array begins at address A in the memory, > then item i will be at address A+B*i in the memory. In terms of performance, > computers are designed to be able to access any address in their memory in > the same amount of time, no matter what address it is stored at, so with a > couple of instructions to calculate A+B*i, the computer can read or write any > element of an array within a constant amount of time (constant meaning it > doesn't get larger or smaller depending upon the size of the array -- it is > always the same no matter the array's size). With other non-array data > structures like trees, accessing an element takes longer as the data > structure grows to contain more items. > > I don't recall if it covers persistent data structures like the ones most > commonly used in Clojure, but Cormen, Leiserson, and Rivest's "Introduction > to Algorithms" is used in many colleges as a text in courses on algorithms > and data structures. There are probably other books that would be better as > a "primer", and it does assume you are comfortable with at least algebra and > a bit more math, but if you got through a chapter of it and understood even > half of it, you'd have learned something worth knowing about the subject. > > http://www.amazon.com/Introduction-Algorithms-Includes-CD-Rom-Thomas/dp/0072970545/ref=sr_1_2?ie=UTF8&qid=1332128117&sr=8-2 > > There is a newer edition than the one I linked to, but an older used copy for > $25.00 might be closer to what you want if you aren't sure yet. > > Andy > > On Mar 15, 2012, at 12:15 PM, Nic Long wrote: > >> Hi all, >> >> I am starting to learn Clojure after buying the book 7 Languages in 7 >> Weeks (really interesting read) and working through the examples >> there. But my background is PHP (and no Computer Science degree) so my >> understanding of data structures and in general, my understanding of >> low-level CS ideas, is pretty limited to say the least - PHP only has >> arrays (which I read are only 'ordered hash tables' in fact) and >> objects so I've never had to think hard about which data structures to >> use, nor how they actually work. >> >> So I guess I'm asking whether anyone can recommend some good primers >> on data structures, both as they relate to Clojure, but also how they >> work in the fundamentals - e.g. what exactly is the classic model of >> an 'array' and how does it work, etc. I have read the various >> performance commitments for the data-types in
Re: understanding data structures, and other low-level stuff
This book: Purely Functional Data Structures http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf is a good read. Though, It only contains a small reference (half a page) about persistent data structures. On Mar 19, 2012, at 7:28 PM, Andy Fingerhut wrote: > I've got my copy of Cormen, Leiserson, and Rivest's book with me now, which > is the 3rd edition, and looking in the index under "persistent" it does have > one exercise in chapter 13 on that topic, and a mention later in the book > that is a paragraph or two long with a reference to a research paper. > > So while that book isn't a good reference for persistent data structures in > particular, it is a good reference for the more widely known (and some > not-so-widely known) mutable data structures. If you learn at least a few of > those, then you are very well prepared to understand Clojure's persistent > data structures, too, and there are blog posts on the topic that can get you > a lot of the way there (once you understand the basics), e.g.: > > http://blog.higher-order.net/2009/09/08/understanding-clojures-persistenthashmap-deftwice/ > > The book does assume a knowledge of how basic arrays work, but those are > quite simple and hopefully my message below is nearly as much as there is to > know about them. To get an understanding of data structures like hash tables > and some different kinds of trees, you can probably get there just reading a > few of the introductory sections at the beginning, and then jump to those > specific sections. Save all the stuff on algorithms for when and if you are > interested. > > Andy > > On Mar 18, 2012, at 8:57 PM, Andy Fingerhut wrote: > >> Feel free to ask follow-up questions on the basics privately, since many >> Clojure programmers are probably already familiar with them, whereas >> follow-up questions on persistent data structures are very on-topic, since I >> would guess many people who have studied computer science and/or programming >> for a while may not be familiar with them. >> >> The classic model of an array is based upon the implementation of physical >> RAM in a computer: a physical RAM, at a high level and leaving out details >> of variations, is a device where you either give it a command READ and an >> address, and it returns an 8-bit byte stored at that location, or you give >> it a WRITE command, an address, and an 8-bit value, and it stores the 8-bit >> value at the location given by the address. >> >> A classic array is a one-dimensional structure indexed by an integer i, >> usually from 0 up to some maximum value N, and every item in the array >> stores an item of the same size and type, e.g. all 32-bit integers, or all >> pointers to some object elsewhere in the memory. If every item fits in >> exactly B bytes, and the first item of the array begins at address A in the >> memory, then item i will be at address A+B*i in the memory. In terms of >> performance, computers are designed to be able to access any address in >> their memory in the same amount of time, no matter what address it is stored >> at, so with a couple of instructions to calculate A+B*i, the computer can >> read or write any element of an array within a constant amount of time >> (constant meaning it doesn't get larger or smaller depending upon the size >> of the array -- it is always the same no matter the array's size). With >> other non-array data structures like trees, accessing an element takes >> longer as the data structure grows to contain more items. >> >> I don't recall if it covers persistent data structures like the ones most >> commonly used in Clojure, but Cormen, Leiserson, and Rivest's "Introduction >> to Algorithms" is used in many colleges as a text in courses on algorithms >> and data structures. There are probably other books that would be better as >> a "primer", and it does assume you are comfortable with at least algebra and >> a bit more math, but if you got through a chapter of it and understood even >> half of it, you'd have learned something worth knowing about the subject. >> >> http://www.amazon.com/Introduction-Algorithms-Includes-CD-Rom-Thomas/dp/0072970545/ref=sr_1_2?ie=UTF8&qid=1332128117&sr=8-2 >> >> There is a newer edition than the one I linked to, but an older used copy >> for $25.00 might be closer to what you want if you aren't sure yet. >> >> Andy >> >> On Mar 15, 2012, at 12:15 PM, Nic Long wrote: >> >>> Hi all, >>> >>> I am starting to learn Clojure after buying the book 7 Languages in 7 >>> Weeks (really interesting read) and working through the examples >>> there. But my background is PHP (and no Computer Science degree) so my >>> understanding of data structures and in general, my understanding of >>> low-level CS ideas, is pretty limited to say the least - PHP only has >>> arrays (which I read are only 'ordered hash tables' in fact) and >>> objects so I've never had to think hard about which data structures to >>> use,
Re: ANN: A Brief Beginner's Guide to Clojure
On Mar 15, 12:21 pm, Phil Dobbin wrote: > > On 14/03/2012 18:24, John Gabriele wrote: > > > I wrote a [brief beginner's guide to Clojure][1] that might interest > > those who are brand new to Clojure. > >[snip] > > Thanks for this, John. You're welcome, Phil. Feedback is, of course, appreciated. > I'm just beginning with Clojure myself & just > happen to have a Debian box handy too :-) Always nice to have a Debian box handy. :) Also, sorry for the belated reply. I haven't checked the group in a couple of days, but also my posts seem to take a while to appear. ---John -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Mapping first element only: how to preserve vectors
Hi! I'm a beginner at clojure and enjoying the learning process. While writing my first nontrivial program, I noticed that I'm transforming only first elements in the list, so I factored this transformation out by writing next function: (defn map-first [f coll] (map #(cons (f (first %)) (rest %)) coll)) And it almost works as expected: Clojure> (map-first #(* 2 %) '((2) (3 3) (3 [2 4]) *[4 10]*)) ((4) (6 3) (6 [2 4]) *(8 10)*) Note that the last element of the list is a vector, but ends up as a list. Sure, my program doesn't complain and I don't see a scenario where this might be a problem, but I wondered if there is some way to preserve vectors. Second question that is less academic: how about performance? Would it be much better, where possible, to start mapping these values separately and only then build the whole structure or is there not much to be gained? Thank you very much for attention! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Returning Success
I am writing a game in Clojure, and I often need some functions to return whether they succeeded in doing what they are supposed to do (for example, moving that unit one field to the left may fail due to... I don't know, a wall?). But if there is one thing I really like about LISPs is the idea of pure functions. So, most of those state-manipulating functions like moving really just return a new world state. Which may or may not be the same as the previous one, depending on the circumstances. I see several ways to achieve what I want, that is to return both the new world state and success status. 1) Compare the old and new value - doesn't seem very efficient. 2) Return [new-state success?] instead of just new-state - requires too much acrobatics from the user of the function (which is still me, but whatever). 3) def some atom that will be set accordingly - I thought this was a step in the right direction, but... global mutable state? Yuck. 4) Allow an optional last argument to world-modifying functions which is an atom that gets set to the success value. This is what I ultimately settled for, and I think it is somewhat elegant. That way I minimize the side effects to a level I can fully control. I currently have a function called safe-reset! which is basically (and a (reset! a v)), so I don't have to type it out every time myself, and all functions that have that optional last argument simply call themselves with an additional nil. Now, my question is - is there some neater scheme for doing this? And if not, then at least I hope my idea is helpful to someone. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ClojureScript error messages
I pushed the patch to my fork on github in this commit: https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 Should I submit a pull request? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Clojurescript One Errors
On Mar 16, 10:19 pm, John Collins wrote: > I copied the clojurescript one project and made changes to the html files. > > When I do (go) after `lein repl` I get errors in the browser about not > being able to resolve some namespaces. And also the wiki makes no mention > how to compile the project after any modifications to the files. So please > I need help on how to do this compilation step as I suspect that could be > the cause why all the namespaces are not being resolved properly. You should be able to edit the files, see the changes in your browser and not worry about compiling. In brief what changes did you make to which files and what was the 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: Clojurescript One and Websockets
I am in discussion with James, but it's very high-level at the moment and no work has been done on integration yet. I don't think it'll get into the next tagged release of Ring (1.1) in time, as that's likely to be released fairly soon once the current set of issues are cleared up. On 19 March 2012 12:19, Jay Fields wrote: > I'm not involved (much) with Webbit other than using it in prod for my > web socket stuff. > > I believe Kushal Pisavadia (cc'd) & James Reeves have been talking > about webbit features that Ring could leverage, but I'm not familiar > with the details. > > Cheers, Jay > > On Sat, Mar 17, 2012 at 7:23 PM, Brian Rowe wrote: > > Hey Jay, > > > > Are there any plans to make a ring adapter for webbit? > > > > > > On Friday, March 2, 2012 6:40:27 AM UTC-5, Jay Fields wrote: > >> > >> clojure + web sockets, not using > >> aleph: > http://blog.jayfields.com/2011/02/clojure-web-socket-introduction.html > >> > >> On Mar 1, 2012, at 10:51 PM, Brian Rowe wrote: > >> > >> Hi, > >> > >> I'm thinking about using clojurescript one a starting point for a web > >> game. I would like to use websockets as the primary communication > mechanism > >> between the browser and the server. As far as I know Zack Tellman's > Aleph > >> is the only clojure web server that supports websockets. Is this > true? If > >> so, are there any guides showing how to modify clojurescript one to use > >> Aleph? If there are no guides, how much work would it take to modify > cljs > >> one to use aleph? > >> > >> 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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ClojureScript error messages
On Mon, Mar 19, 2012 at 1:36 PM, Aaron wrote: > I pushed the patch to my fork on github in this commit: > https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 > > Should I submit a pull request? Clojure doesn't take pull requests. Have you sent in your CA? If so open a ticket and attach a patch in JIRA. Thanks! 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: The extensible reader
On Sunday, March 18, 2012 9:07:54 PM UTC-4, Brent Millare wrote:
>
>
> this form is still unreadable by default, but with tagged literals, allows
> users to define custom reader behavior per class.
> #java.class.name [args*]
>
>
That syntax is already used for defrecords.
Clojure 1.4.0-beta2
user=> (defrecord Foo [a b])
user.Foo
user=> (read-string "#user.Foo[1 2]")
#user.Foo{:a 1, :b 2}
user=>
> Either that or is there a way to alter the printing behavior of java
> objects locally, instead of globally as when defining a print-method for
> that type?
>
Sure, just define your own print function that defaults to the standard
Clojure print.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: clojurewest talk videos?
Alex, I never signed the release (my apologies) - but I'm fine with it... any alt. release I can provide? Bill - On Mar 19, 2012, at 9:33 AM, Alex Miller wrote: > Yes, all talks were recorded and will be released on http://infoq.com > starting in about 3 weeks on a rolling basis. > > Alex > > > On Sunday, March 18, 2012 1:12:41 PM UTC-5, Las wrote: > Hi, > > will the videos of the talks be available for those who did not make it to > the conference? > > thx > > -- > László Török > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: Returning Success
If the success/failure of the function makes sense to represent in game-world terms, you could encode the information in the world object, perhaps as a flag that can be attached to the relevant object. In your example, the unit might be given a "state" with the value :blocked, indicating that something is currently blocking its movement. Another option would be metadata, though that feels ugly to me. Or the simplest option: just have your functions return nil to indicate that the world state should remain unchanged from its previous value. [Minor nitpick about your email: lisps aren't necessarily functional (e.g. Common Lisp).] -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Returning Success
I liked approach 2 myself, if the goal is to stick with pure functions when it isn't too difficult. It avoids the comparison of 1, and gets you back exactly the info you want to go onwards from there. You can add a caveat that I haven't written a lot of application code with Clojure, so weight this advice however you like. Andy On Mar 19, 2012, at 3:56 AM, Narvius wrote: > I am writing a game in Clojure, and I often need some functions to return > whether they succeeded in doing what they are supposed to do (for example, > moving that unit one field to the left may fail due to... I don't know, a > wall?). > > But if there is one thing I really like about LISPs is the idea of pure > functions. So, most of those state-manipulating functions like moving really > just return a new world state. Which may or may not be the same as the > previous one, depending on the circumstances. > > I see several ways to achieve what I want, that is to return both the new > world state and success status. > 1) Compare the old and new value - doesn't seem very efficient. > 2) Return [new-state success?] instead of just new-state - requires too much > acrobatics from the user of the function (which is still me, but whatever). > 3) def some atom that will be set accordingly - I thought this was a step in > the right direction, but... global mutable state? Yuck. > 4) Allow an optional last argument to world-modifying functions which is an > atom that gets set to the success value. This is what I ultimately settled > for, and I think it is somewhat elegant. That way I minimize the side effects > to a level I can fully control. > I currently have a function called safe-reset! which is basically (and a > (reset! a v)), so I don't have to type it out every time myself, and all > functions that have that optional last argument simply call themselves with > an additional nil. > > Now, my question is - is there some neater scheme for doing this? And if not, > then at least I hope my idea is helpful to someone. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Returning Success
Hi, Am Montag, 19. März 2012 11:56:28 UTC+1 schrieb Narvius: > > 1) Compare the old and new value - doesn't seem very efficient. > > Just return the very same world state object? You can easily and insanely fast decide whether it was changed by virtue of "identical?". Then you don't need any special handling of returned nils or composite return values. If you don't care for the check just pass it along. If you do, well, there you are: identical?`. 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: The extensible reader
> That syntax is already used for defrecords.
>
> Clojure 1.4.0-beta2
> user=> (defrecord Foo [a b])
> user.Foo
> user=> (read-string "#user.Foo[1 2]")
> #user.Foo{:a 1, :b 2}
> user=>
>
>
Technically, there is no space with that method. As it is currently
implemented, tags are separated by a space between the clojure data it is
tagging.
> Sure, just define your own print function that defaults to the standard
> Clojure print.
>
>
That works! Some how the obvious can be quite elusive at times.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Mapping first element only: how to preserve vectors
On Mon, Mar 19, 2012 at 9:40 AM, Bojan wrote: > Hi! > > I'm a beginner at clojure and enjoying the learning process. While writing > my first nontrivial program, I noticed that I'm transforming only first > elements in the list, so I factored this transformation out by writing next > function: > > (defn map-first [f coll] > (map #(cons (f (first %)) (rest %)) coll)) > > And it almost works as expected: > Clojure> (map-first #(* 2 %) '((2) (3 3) (3 [2 4]) [4 10])) > ((4) (6 3) (6 [2 4]) (8 10)) > > Note that the last element of the list is a vector, but ends up as a list. > Sure, my program doesn't complain and I don't see a scenario where this > might be a problem, but I wondered if there is some way to preserve vectors. Cons returns lists. (Well, seqs. For the most part the distinction is unimportant.) Doing what you ask is tricky. Changing cons to conj doesn't help (as rest returns a seq too). This: (defn map-first [f coll] (map #(into (empty %) (cons (f (first %)) (rest %))) coll)) reverses all the non-vectors. I doubt it can be done without the ugliness of introducing a conditional that checks for vector-ness or seq-ness. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Returning Success
On Mon, Mar 19, 2012 at 3:56 AM, Narvius wrote: > 2) Return [new-state success?] instead of just new-state - requires too much > acrobatics from the user of the function (which is still me, but whatever). Destructuring makes it easy to work with multi-value returns: (let [[state status] (make-move old-state)] (if status (do-stuff-with state) (println "move failed"))) More likely tho' I suspect you might want to return a specific failure: [new-state nil] - state changed successfully [old-state some-failure] - state failed to change because of that failure (which might be a string or some more complex description) In general, you may just want to get the (same or updated) state back and then continue to process it, reporting errors as you go? Something like this: (loop [state initial-state] (let [[new-state failure] (change-world state)] (when failure (println "ERROR:" failure)) (recur new-state)) As others have indicated, there are many possible solutions... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Returning Success
I read this and wondered why you care? Isn't it sufficient to return the new world state? You could use identical? as someone suggested but why bother? It sounds like the player should be able to keep bumping into the wall if they keep making the same move. I am just curious why the problem is more than computing the new world state from the old world state + user input + world self actions. What logic depends on whether it changed? To redraw or not? I'm learning functional myself so I like to hear how others design their solutions. On Mar 19, 5:56 am, Narvius wrote: > I am writing a game in Clojure, and I often need some functions to return > whether they succeeded in doing what they are supposed to do (for example, > moving that unit one field to the left may fail due to... I don't know, a > wall?). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: 3d modeling tools
On Mar 16, 2012, at 10:05 AM, Niels van Klaveren wrote: > AFAIK there's not much projects focussing on 3D in Clojure, but you can take > a look at processing (http://processing.org) and one of it's Clojure > wrappers. It's a great little language for 2D/3D visuals, and there's plenty > of swarm-like demos for it (http://openprocessing.org). For 3D calculations, > (verlet) physics and more there's the java library toxiclibs > (http://toxiclibs.org), whose author is currently porting/wrapping to > Clojure. > > It's not really a cut-and-dried solution, but it's pretty flexible and has a > simple API unlike a lot of 3D projects which focus very narrowly on games > development. Thanks Niels. I've actually used Processing quite a bit -- even taught a couple of courses with it -- and I've played a little with the Processing library via Clojure. I'll have to look into that again in this context. I recall some frustration with Clojure+Processing which I think stemmed from (1) feeling trapped in the applet context, (2) not knowing how to run programs that use the library on nodes without graphic displays (from which I would dump data to files -- I do lots of runs on cluster nodes to collect data), and (3) not knowing how to get Processing-based projects to take advantage of multiple cores. If you or anyone else has comments related to these issues then I would love to hear them. The toxiclibs library also looks quite interesting. Do you know of any examples that show this being invoked from Clojure? -Lee -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 code optimizer
Hi Andru and thank you for expressing interest in this proposal. > Could you please give more details (or examples) on the types of > optimizations the optimizer should be able to do? Also, what is a tree > shaker implementation? > As David wrote, this is dead code elimination and in LISP world is also known as tree shaking. Contrary to pattern matching (for which you expressed desire), dead code elimination is usually more advanced approach, sometimes requiring passing through the code multiple times, inspecting compiler facilities or simply doing a bunch of tricks to remove obvious and not so obvious unused code. Take this example: (defonce *always-true* true) (if *always-true* (println "Always executed") (println "Never executed")) Matching this case could be hard for pattern matching tools; they often do not understand the content outside given pattern. True optimizer would pick up *always-true* and notice it will never be changed for this block. However, if I do some weird magic inside some function and globally change the value of *always-true* at some point, optimizer should recognize this case or would remove valid code. Also, often case for optimizers is to precompute simple expressions in compilation phase yielding static values, like: (let [a 0 b (+ a 1)] (if something b)) here it could rewrite whole block as: (if something 1) or even can recognize Clojure patterns like: (apply + (range 1 10)) where the pattern matching approach could rewrite expression to (+ 1 2 3 4 5 6 ... 9) and optimizer would simply produce 45. Using this case you can see how pattern matching can be a part of optimizer. I'm hoping I manage to fully describe you an idea behind this proposal. Of course, taking some expert system approach and doing Kibit-style matching can be a good starting point too :) Also, if you are interested to take tree shaking way, a good starting point can be SBCL alpha shaker at http://jsnell.iki.fi/tmp/shake.lisp. Unfortunately without documentation, but the code is quite easy to follow. Sanel On Saturday, March 17, 2012 10:59:44 PM UTC+1, Andru Gheorghiu wrote: > > Hello, > > I am a third year student majoring in computer science and I am > interested in the Clojure code optimizer project proposed for GSoC > 2012. Could you please give more details (or examples) on the types of > optimizations the optimizer should be able to do? Also, what is a tree > shaker implementation? > I was thinking that an optimizer could be implemented as a rule engine > similar to Jess or CLIPS in which rules contains patterns which need > to be replaced and the code to replace them with. For example one > could write patterns for generic linear recursive functions that > should be replaced with linear iterative functions. Similarly patterns > can be written for functions which replicate the behavior of an > already existing function (such as reverse, map, apply etc) and a rule > to replace those functions with the predefined ones. > > Thank you, > Andru Gheorghiu > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Returning Success
On Mon, Mar 19, 2012 at 3:56 AM, Narvius wrote: > I see several ways to achieve what I want, that is to return both the new > world state and success status. > 1) Compare the old and new value - doesn't seem very efficient. > Probably not as inefficient as you think. Identical things are recognized as equal right away, unequal things are almost certain to have different hash values and be recognized as unequal immediately. Only slow path are large equal structures that were created by separate processes and therefore aren't identical. > 2) Return [new-state success?] instead of just new-state - requires too > much acrobatics from the user of the function (which is still me, but > whatever). > Probably it's more Clojuresque to return new-state or nil, and handle both cases anywhere you call the function. Whether you choose to return [new-state success?] or new-state or nil, monads could help you with the acrobatics. That's exactly the kind of thing they are good for. Options 3 and 4 seem like things you should avoid if you can make 1 or 2 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
Re: Returning Success
On Mar 19, 2012, at 5:31 PM, Michael Gardner wrote:
> Or the simplest option: just have your functions return nil to indicate that
> the world state should remain unchanged from its previous value.
If your world state is a hash-map, you could also return partial states and
merge them into the existing world; that would make nil automatically mean "no
change". Let's say your world has the key :player (among other things):
(defn move-player [{:keys [player ...]} ...]
(when (can-move player)
{:player (assoc player ...)}))
The above returns nil when (can-move player) returns false; otherwise it
returns a hash-map with only the key :player defined. Then (merge world
(move-player world ...)) does the right thing, with no special-casing of nil
needed.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Returning Success
On Mon, Mar 19, 2012 at 7:14 PM, jk wrote: > I read this and wondered why you care? Isn't it sufficient to return > the new world state? You could use identical? as someone suggested but > why bother? It sounds like the player should be able to keep bumping > into the wall if they keep making the same move. One good example is you want to play a "bump" sound each time they hit the wall. Without some info in the state about what just happened, i.e. the result of the last action, you don't know whether to do side-effects like this. In his Clojure/West talk (sorry, slides aren't posted), Stuart Sierra, suggested storing results or side-effects of a pure function in a result or action key on the state map. I also like this approach for a few reasons: * assuming your state's in an atom or ref, your state transition functions will play nicely with swap! and alter. No need to create an anonymous wrapper function just to use them and check return codes. Anonymous functions passed to swap! always seems like a smell to me. * your state transition functions will play nicely with the threading operator. They'll read nicely like (-> my-state funca funcb ...) * storing side-effects and errors as say a vector of values in a key on the state can be manipulated by other transition functions later in the chain and easily dispatched over by a multi-method or whatever One area I'm not quite sure about is multiple threads beating on something like this. Suppose the typical pattern is something like this: (doseq [action (:actions (swap! state-atom do-something))] (execute-action action)) well if several threads are doing this at once, the actions could be executed multiple times. I'm not sure of a great solution to this. I have ideas, but I'm not that fond of any of them. hope this helps. feel free to correct me if I'm totally wrong. Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: 3d modeling tools
If you are going to use processing from Clojure, you'll want to checkout Quil: https://github.com/quil/quil It's a more Clojure friendly take on processing sketches, and it's a lot less painful to get up and running. -Jeff On Mar 19, 4:15 pm, Lee Spector wrote: > On Mar 16, 2012, at 10:05 AM, Niels van Klaveren wrote: > > > AFAIK there's not much projects focussing on 3D in Clojure, but you can > > take a look at processing (http://processing.org) and one of it's Clojure > > wrappers. It's a great little language for 2D/3D visuals, and there's > > plenty of swarm-like demos for it (http://openprocessing.org). For 3D > > calculations, (verlet) physics and more there's the java library toxiclibs > > (http://toxiclibs.org), whose author is currently porting/wrapping to > > Clojure. > > > It's not really a cut-and-dried solution, but it's pretty flexible and has > > a simple API unlike a lot of 3D projects which focus very narrowly on games > > development. > > Thanks Niels. > > I've actually used Processing quite a bit -- even taught a couple of courses > with it -- and I've played a little with the Processing library via Clojure. > I'll have to look into that again in this context. > > I recall some frustration with Clojure+Processing which I think stemmed from > (1) feeling trapped in the applet context, (2) not knowing how to run > programs that use the library on nodes without graphic displays (from which I > would dump data to files -- I do lots of runs on cluster nodes to collect > data), and (3) not knowing how to get Processing-based projects to take > advantage of multiple cores. If you or anyone else has comments related to > these issues then I would love to hear them. > > The toxiclibs library also looks quite interesting. Do you know of any > examples that show this being invoked from Clojure? > > -Lee -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: ringMon Ring middleware that provides monitoring and nREPL remote interface to any Ring based Clojure web app
Hi all, The first non-snapshot release of ringMon 0.1.1 is now in Clojars. The demo is at http://noirmon.herokuapp.com/ringmon/monview.html The source is at https://github.com/zoka/ringMon/ Regards Zoka -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN: ringMon 0.1.1 released
Hi all. The first non-snapshot release of ringMon 0.1.1 is available at Clojars. The ringMon is a Ring middleware that can be easily added to an existing Ring based application. It injects a monitoring page that displays application data of interest (JMX and derived values). The page also provides Web front end to nREPL server that runs in context of the web application itself. I can be used to provide easy insight into applications deployed on cloud platforms like Heroku, The demo showcase app is at: http://noirmon.herokuapp.com/ Source code is at: https://github.com/zoka/ringMon/ Regards Zoka -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
