Re: Modelling in Clojure
Yeah, it's hard to deny the convenience of Clojure's keyword lookups and standard assoc mechanism for getting and setting stored values, but I think Bertrand Meyer's Uniform Access Principle reflects some pretty deep thinking about the kinds of complications that arise in maintaining large programs. Although the Clojure community mostly rejects the Uniform Access Principle right now, as people start writing larger programs in Clojure, and need to maintain them for longer periods of time, it will be interesting to see if the pendulum swings back in favor of uniform access. It will be fun to have this conversation again in 5 years time. The good news is that if the community does start to see more value in uniform access, achieving that is just a few macros away. --Mark On Fri, Oct 17, 2014 at 10:49 PM, Mars0i marsh...@logical.net wrote: On Thursday, October 16, 2014 11:53:42 PM UTC-5, puzzler wrote: In Clojure, non-computed fields are usually accessed directly by keyword, whereas computed fields require an actual API. This difference in access style complicates things if you want to change which things are stored versus computed. This also means that you have to remember which data has a keyword accessor and which uses a function. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[UPDATE] Spring/Clojure integration / Clojure functions via JMX
Hi folks, I added code that lets you call your clojure functions via JMX operations. https://github.com/henrik42/spring-break#jmxmbeans Cheers Henrik -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: agent validation fails in STM
You are right! If, say, a file write, fails the data would reside only in your memory refs. One way to make sure the two thing are always in sync is to be able to rollback the in-memory state (and replaying all subsequent actions) by holding on to the old version until the agent could be derefed as correctly updated to or maybe even beyond the expected version of the datastructure. I think. Im not sure how you would persist the queue of incoming actions by the same pattern, though. I guess you should have a look on Two-phase commits. /Linus Den 15 okt 2014 20:15 skrev shahrdad shadab clojure.langu...@gmail.com: Hi folks I know when I send/send-off an action to an agent within a STM transaction no action will be dispatched if transaction fails to commit. I was expecting similar behaviour when agent fails: the transaction does not commit when the action puts the agent in an invalid / failed state. It seems my expectation is wrong because the sent action will be dispatched only when transaction successfully committed which by the time it is too late to un-commit things. In such scenario the resource (database, file,...) will be out of sync with the modified collection in STM. Am I missing any thing here? Any comments is highly appreciated. Thanks a lot Best regards Shahrdad -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
While this discussing has taken a slight tangent from my original question, it's been a very interesting read. Thanks for all your thoughts everyone. You guys rock! On 18 October 2014 08:28, Mark Engelberg mark.engelb...@gmail.com wrote: Yeah, it's hard to deny the convenience of Clojure's keyword lookups and standard assoc mechanism for getting and setting stored values, but I think Bertrand Meyer's Uniform Access Principle reflects some pretty deep thinking about the kinds of complications that arise in maintaining large programs. Although the Clojure community mostly rejects the Uniform Access Principle right now, as people start writing larger programs in Clojure, and need to maintain them for longer periods of time, it will be interesting to see if the pendulum swings back in favor of uniform access. It will be fun to have this conversation again in 5 years time. The good news is that if the community does start to see more value in uniform access, achieving that is just a few macros away. --Mark On Fri, Oct 17, 2014 at 10:49 PM, Mars0i marsh...@logical.net wrote: On Thursday, October 16, 2014 11:53:42 PM UTC-5, puzzler wrote: In Clojure, non-computed fields are usually accessed directly by keyword, whereas computed fields require an actual API. This difference in access style complicates things if you want to change which things are stored versus computed. This also means that you have to remember which data has a keyword accessor and which uses a function. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/v03o5MWys9E/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
On 18 October 2014 08:28, Mark Engelberg mark.engelb...@gmail.com wrote: Yeah, it's hard to deny the convenience of Clojure's keyword lookups and standard assoc mechanism for getting and setting stored values, but I think Bertrand Meyer's Uniform Access Principle reflects some pretty deep thinking about the kinds of complications that arise in maintaining large programs. Although the Clojure community mostly rejects the Uniform Access Principle right now, as people start writing larger programs in Clojure, and need to maintain them for longer periods of time, it will be interesting to see if the pendulum swings back in favor of uniform access. You make it sound as if structuring an application around data, rather than APIs, is untested at scale. I'd argue the opposite: the only architecture we know works at scale is data driven. The largest systems we've developed, including the web itself, are data driven. Above a certain size, they have to be, due to latency and consistency concerns. Structuring a large system into isolated services that communicate with data is a tried and tested architecture. There may be a place for the Uniform Access Principle at the medium scale, where an application is large, but not so large it can't be hosted on one machine. I don't think the relative merits of data-driven vs. api-driven approaches has been proven at this scale. That said, I think there are reasons for betting on Clojure's approach. Ultimately it comes down to whether we try to *manage* complexity or *remove* complexity. The Uniform Access Principle falls in the former camp, along with OOP and encapsulation. They're tools to manage connections between components of a codebase. Clojure takes the more aggressive stance, and suggests that rather than managing complexity, we should be focused on getting rid of it wherever possible. For instance, where OOP languages try to manage state change though encapsulation, Clojure just removes mutable state entirely, or at least places it in confinement. Where complexity *can't* be removed, then we start to get Clojure code that begins to look similar to OO designs. Stuart Sierra's components, for instance, look somewhat similar to stripped-down objects. The difference in Clojure's approach is that these constructs are a last resort, rather than the norm. - James -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ANN: Om 0.8.0-alpha1, Reference Cursors!
I'm happy to announce the release of Om 0.8.0-alpha1. This release includes the single biggest conceptual enhancement since its initial release - Reference Cursors. As we begin to build larger and larger applications with Om, we often run afoul of the need to organize our application around a hierarchical tree. This is more problematic than in React itself as Om emphasizes a programming model that supports full snapshotting of the application state. This seemingly beneficial property actually exacerbates the hierachical issue and often leads to an incredible amount non-modular programming! The introduction of Reference Cursors allow Om programmers to stop thinking in terms of trees and return to a more natural mode of UI programming - simply calling out into shared APIs around application data precisely where you need it. No need to pass data through intermediate components on way to the target child component - Reference Cursors allow you to get at the data exactly where it is required and this without abandoning the ability to time travel over your application state. There are more thoughts and details here: https://github.com/swannodette/om/wiki/Advanced-Tutorial#reference-cursors Please give Reference Cursors a try in your application and send lots of feedback! This is an alpha release. No previous Om APIs should be affected, however the Reference Cursor feature is largely untested beyond a simple example in the repo. https://github.com/swannodette/om Cheers, 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
James might be too modest to mention this as an exemplar as he's the maintainer, but for me, Ring https://github.com/ring-clojure/ring is a great example of the success of data-as-API. HTTP requests are represented as a nested map with well-known keys, and middleware works with these fields or even adds new ones. On 18 October 2014 16:50, James Reeves ja...@booleanknot.com wrote: On 18 October 2014 08:28, Mark Engelberg mark.engelb...@gmail.com wrote: Yeah, it's hard to deny the convenience of Clojure's keyword lookups and standard assoc mechanism for getting and setting stored values, but I think Bertrand Meyer's Uniform Access Principle reflects some pretty deep thinking about the kinds of complications that arise in maintaining large programs. Although the Clojure community mostly rejects the Uniform Access Principle right now, as people start writing larger programs in Clojure, and need to maintain them for longer periods of time, it will be interesting to see if the pendulum swings back in favor of uniform access. You make it sound as if structuring an application around data, rather than APIs, is untested at scale. I'd argue the opposite: the only architecture we know works at scale is data driven. The largest systems we've developed, including the web itself, are data driven. Above a certain size, they have to be, due to latency and consistency concerns. Structuring a large system into isolated services that communicate with data is a tried and tested architecture. There may be a place for the Uniform Access Principle at the medium scale, where an application is large, but not so large it can't be hosted on one machine. I don't think the relative merits of data-driven vs. api-driven approaches has been proven at this scale. That said, I think there are reasons for betting on Clojure's approach. Ultimately it comes down to whether we try to *manage* complexity or *remove* complexity. The Uniform Access Principle falls in the former camp, along with OOP and encapsulation. They're tools to manage connections between components of a codebase. Clojure takes the more aggressive stance, and suggests that rather than managing complexity, we should be focused on getting rid of it wherever possible. For instance, where OOP languages try to manage state change though encapsulation, Clojure just removes mutable state entirely, or at least places it in confinement. Where complexity *can't* be removed, then we start to get Clojure code that begins to look similar to OO designs. Stuart Sierra's components, for instance, look somewhat similar to stripped-down objects. The difference in Clojure's approach is that these constructs are a last resort, rather than the norm. - James -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] ANN: Om 0.8.0-alpha1, Reference Cursors!
Fantastic work, David! Thank you for all your hard work on Om! This is definitely an exciting release and I look forward to playing with it over the coming days. I'll be sure to report back on my experience with it. On 18 October 2014 16:53, David Nolen dnolen.li...@gmail.com wrote: I'm happy to announce the release of Om 0.8.0-alpha1. This release includes the single biggest conceptual enhancement since its initial release - Reference Cursors. As we begin to build larger and larger applications with Om, we often run afoul of the need to organize our application around a hierarchical tree. This is more problematic than in React itself as Om emphasizes a programming model that supports full snapshotting of the application state. This seemingly beneficial property actually exacerbates the hierachical issue and often leads to an incredible amount non-modular programming! The introduction of Reference Cursors allow Om programmers to stop thinking in terms of trees and return to a more natural mode of UI programming - simply calling out into shared APIs around application data precisely where you need it. No need to pass data through intermediate components on way to the target child component - Reference Cursors allow you to get at the data exactly where it is required and this without abandoning the ability to time travel over your application state. There are more thoughts and details here: https://github.com/swannodette/om/wiki/Advanced-Tutorial#reference-cursors Please give Reference Cursors a try in your application and send lots of feedback! This is an alpha release. No previous Om APIs should be affected, however the Reference Cursor feature is largely untested beyond a simple example in the repo. https://github.com/swannodette/om Cheers, David -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
+1. Two years ago we went all data driven here. We stripped the code size and complexity by a huge factor. All data encapsulation code was sent to the trash can. Our processing is driven by data more than by code. We ended up with a significant increase in generic code not linked to the business domain and the rest is made up mostly of DSLs. What a relief Luc P. On 18 October 2014 08:28, Mark Engelberg mark.engelb...@gmail.com wrote: Yeah, it's hard to deny the convenience of Clojure's keyword lookups and standard assoc mechanism for getting and setting stored values, but I think Bertrand Meyer's Uniform Access Principle reflects some pretty deep thinking about the kinds of complications that arise in maintaining large programs. Although the Clojure community mostly rejects the Uniform Access Principle right now, as people start writing larger programs in Clojure, and need to maintain them for longer periods of time, it will be interesting to see if the pendulum swings back in favor of uniform access. You make it sound as if structuring an application around data, rather than APIs, is untested at scale. I'd argue the opposite: the only architecture we know works at scale is data driven. The largest systems we've developed, including the web itself, are data driven. Above a certain size, they have to be, due to latency and consistency concerns. Structuring a large system into isolated services that communicate with data is a tried and tested architecture. There may be a place for the Uniform Access Principle at the medium scale, where an application is large, but not so large it can't be hosted on one machine. I don't think the relative merits of data-driven vs. api-driven approaches has been proven at this scale. That said, I think there are reasons for betting on Clojure's approach. Ultimately it comes down to whether we try to *manage* complexity or *remove* complexity. The Uniform Access Principle falls in the former camp, along with OOP and encapsulation. They're tools to manage connections between components of a codebase. Clojure takes the more aggressive stance, and suggests that rather than managing complexity, we should be focused on getting rid of it wherever possible. For instance, where OOP languages try to manage state change though encapsulation, Clojure just removes mutable state entirely, or at least places it in confinement. Where complexity *can't* be removed, then we start to get Clojure code that begins to look similar to OO designs. Stuart Sierra's components, for instance, look somewhat similar to stripped-down objects. The difference in Clojure's approach is that these constructs are a last resort, rather than the norm. - James -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
behaviour of map
Greeting everyone, It might be stupid question but I expect (first (map (fn [_] (println executed)) [1 2 3 4])) prints only once (realizing only first element in lazy seq returned by map) but it prints four times. Can some one shed a light why? Thanks in advance Best regards Shahrdda -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: behaviour of map
Some lazy lists are chunked for efficiency, which means Clojure will read-ahead and evaluate a number of elements in advance. Often the outputs from the various list handling functions are chunked (e.g. map, range, etc.), while creating a seq explicitly with lazy-seq will not be chunked. - James On 18 October 2014 18:28, shahrdad shadab clojure.langu...@gmail.com wrote: Greeting everyone, It might be stupid question but I expect (first (map (fn [_] (println executed)) [1 2 3 4])) prints only once (realizing only first element in lazy seq returned by map) but it prints four times. Can some one shed a light why? Thanks in advance Best regards Shahrdda -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: behaviour of map
You can try in you repl with (take 1 (map (fn [_] (println executed)) (vec (range 100 (take 32 (map (fn [_] (println executed)) (vec (range 100 (take 33 (map (fn [_] (println executed)) (vec (range 100 you will observe the 32 sized chunks. On Sat, Oct 18, 2014 at 7:36 PM, James Reeves ja...@booleanknot.com wrote: Some lazy lists are chunked for efficiency, which means Clojure will read-ahead and evaluate a number of elements in advance. Often the outputs from the various list handling functions are chunked (e.g. map, range, etc.), while creating a seq explicitly with lazy-seq will not be chunked. - James On 18 October 2014 18:28, shahrdad shadab clojure.langu...@gmail.com wrote: Greeting everyone, It might be stupid question but I expect (first (map (fn [_] (println executed)) [1 2 3 4])) prints only once (realizing only first element in lazy seq returned by map) but it prints four times. Can some one shed a light why? Thanks in advance Best regards Shahrdda -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: behaviour of map
Thanks a lot for your explanation, the thing that confuses me was the same function used with repeatedly only prints once: (first (repeatedly 4 #(do (println executed!) (inc 1 I guess because Clojure does not read-ahead in this scenario. Am I right? On Sat, Oct 18, 2014 at 1:41 PM, Jonathan Winandy jonathan.wina...@gmail.com wrote: You can try in you repl with (take 1 (map (fn [_] (println executed)) (vec (range 100 (take 32 (map (fn [_] (println executed)) (vec (range 100 (take 33 (map (fn [_] (println executed)) (vec (range 100 you will observe the 32 sized chunks. On Sat, Oct 18, 2014 at 7:36 PM, James Reeves ja...@booleanknot.com wrote: Some lazy lists are chunked for efficiency, which means Clojure will read-ahead and evaluate a number of elements in advance. Often the outputs from the various list handling functions are chunked (e.g. map, range, etc.), while creating a seq explicitly with lazy-seq will not be chunked. - James On 18 October 2014 18:28, shahrdad shadab clojure.langu...@gmail.com wrote: Greeting everyone, It might be stupid question but I expect (first (map (fn [_] (println executed)) [1 2 3 4])) prints only once (realizing only first element in lazy seq returned by map) but it prints four times. Can some one shed a light why? Thanks in advance Best regards Shahrdda -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSA] Clojars scp disabled until further notice
Phil, I've used scp uploads in the past. They're much easier when e.g. you wanna upload a java library you've forked. Without scp uploads (or an easy copy/paste curl alternative), you have to go through getting the project to build with lein by itself. It's not *too* difficult to get a maven based project uploaded to clojars (https://github.com/ato/clojars-web/wiki/Pushing has an easy to follow section), but getting ant or other projects up there is painful. Other than that, I've happily converted over to `lein deploy` for my lein-based projects. Tom On Wednesday, 24 September 2014 17:57:49 UTC-5, Phil Hagelberg wrote: Greetings, Clojure hackers. Due to the recent vulnerability in Bash[1], the scp-based deploy services on clojars.org has been disabled for the time being. If you have been using this (as opposed to the HTTPS deploy used by `lein deploy clojars` and `maven deploy`), we'd be interested in hearing From you. In particular we would like to know reasons why you haven't upgraded, assuming it's not just I started on scp and it worked well, so I never saw the need to change anything. If you haven't tried HTTPS-based deploys, now would be a great time to do so and see if they work for you. If not, let us know why, either here or on the Leiningen issue tracker[2]. The HTTPS-based deploys are definitely a superior implementation that we encourage. We would like to bring scp deploys back online in the near future, but as you know Clojars is a volunteer-run service without many resources, and we have no immediate timeline for this. -Phil [1] - http://seclists.org/oss-sec/2014/q3/650 [2] - https://github.com/technomancy/leiningen/issues/new -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Calling empty on a map entry
(def map-entry (first {1 2}))
(empty map-entry)
= nil
Up until now my understanding was that map entries are completely
interchangeable with vectors, in that you can conj and assoc just like
vectors, and you can even call them like functions. I figured that calling
empty on a map entry would return an empty vector. Does this seem like a
reasonable functionality demand, or can someone shed some light on why this
is the current behavior?
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
I think all of James' points about the proven value of structuring an application primarily around data rather than a complex API are right on point. It is one of the things I love about the Clojure philosophy. But there's nothing about the value of data-driven development that requires data lookups and data computations to be so different. There's plenty of room for Clojure to have continued evolution in this area and still preserve the essence of its approach. For example, consider that several years ago, Rich declared that Clojure would never have a simple mutable box. But lo and behold, now we have volatiles. Consider the rise of records, protocols, and components -- a lot of judiciously applied OOish concepts. I really enjoy introducing Java programmers to the Clojure way of thinking about data. But when I do, I like to explain the current thinking in the Clojure community, talk about some of the most triumphant success stories (e.g., Ring), acknowledge some of the pain points, talk about some of the ways that Clojure has grown to handle other data modeling pain points, and some of the ways that Clojure may continue to grow. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling empty on a map entry
See this thread: https://groups.google.com/forum/#!searchin/clojure/unexpected$20behavior$20of$20clojure.core$2Fempty/clojure/z4GiyxvFEqg/zxwTklPa2mEJ -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: book for a beginner with some exercises
Hi there, If you're looking for books, I don't know of any. But my Intro to Clojure videos have lots of exercises and start from the beginning. http://www.purelyfunctional.tv/intro-to-clojure In terms of exercises, I cut my Clojure teeth on Project Euler. https://projecteuler.net/ Once you solve a problem, you'll get access to lots of solutions in many languages. Very good problems. Thanks Eric On Tuesday, October 14, 2014 6:57:50 AM UTC-5, Roelof Wobben wrote: Hello, Is there a book for a beginner in Clojure where I can learn things and practice the things I learned with some exercises ? Roelof -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dynamically generate jar from clojure
Hi Arkadiusz, You're right: you should leverage on the existing functionality from Leiningen itself as much as possible. I think you'd want to follow an approach like this: - Create your Clojure-based web application, include Leiningen itself as a runtime dependency - Generate a project skeleton much like a project template does, you'd add the dependencies you want to add (eg. parkour) on this step and probably set the :main namespace - Replace one or more files from the user's request - Run the uberjar task to produce the jar file you want to send back to users Probably a good place to start looking would be the guide to write plugins for Leiningen: https://github.com/technomancy/leiningen/blob/stable/doc/PLUGINS.md Also worth mentioning: I assume you want to run a service like this in a very controlled environment, it's very likely it will be a function very intensive on the server itself, and check many potential security concerns (eg. how to audit, restricting potentially risky functions/namespaces). Regards, Denis El viernes, 17 de octubre de 2014 18:02:45 UTC-3, Arkadiusz Bicz escribió: Hi I would like to generate jar from clojure script dynamically from clojure. I have server which gets clojure scripts from users and server have to generate jar file from it plus some other dependences like parkour lib. Server than send jar for usage by othere servers in different phisical machines. Should I include lein jar in my class path and use its functionality? Many Thanks, Arkadiusz Bicz -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
Maybe we need some sort of lazy map where:
(def m (assoc-computed {:first-name Robert :last-name Plankton}
:full-name #(str (:first-name %) (:last-name
%
;; will call the function to compute the value and will memoize it:
(:full-name m)
;; now the memoized value is returned without calling the function
(:full-name m)
;; equality / hashing will trigger computation+memoization of all m
;; computed keys if they aren't computed yet:
(= m other-map)
Computing functions must be pure, so m internally is a mutable object but
you can't really distinguish it from an immutable one :)
Saludos,
Nahuel Greco.
On Sat, Oct 18, 2014 at 5:02 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
I think all of James' points about the proven value of structuring an
application primarily around data rather than a complex API are right on
point. It is one of the things I love about the Clojure philosophy.
But there's nothing about the value of data-driven development that
requires data lookups and data computations to be so different. There's
plenty of room for Clojure to have continued evolution in this area and
still preserve the essence of its approach.
For example, consider that several years ago, Rich declared that Clojure
would never have a simple mutable box. But lo and behold, now we have
volatiles. Consider the rise of records, protocols, and components -- a
lot of judiciously applied OOish concepts.
I really enjoy introducing Java programmers to the Clojure way of thinking
about data. But when I do, I like to explain the current thinking in the
Clojure community, talk about some of the most triumphant success stories
(e.g., Ring), acknowledge some of the pain points, talk about some of the
ways that Clojure has grown to handle other data modeling pain points, and
some of the ways that Clojure may continue to grow.
--
You 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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You 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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: ANN: Om 0.8.0-alpha1, Reference Cursors!
Brilliant! Looking forward to digging into it. P.S I was wondering when that Advanced tutorial was going to be written, looks like its up! Don't know how you find the time but glad that you do! On Saturday, October 18, 2014 5:53:57 PM UTC+2, David Nolen wrote: I'm happy to announce the release of Om 0.8.0-alpha1. This release includes the single biggest conceptual enhancement since its initial release - Reference Cursors. As we begin to build larger and larger applications with Om, we often run afoul of the need to organize our application around a hierarchical tree. This is more problematic than in React itself as Om emphasizes a programming model that supports full snapshotting of the application state. This seemingly beneficial property actually exacerbates the hierachical issue and often leads to an incredible amount non-modular programming! The introduction of Reference Cursors allow Om programmers to stop thinking in terms of trees and return to a more natural mode of UI programming - simply calling out into shared APIs around application data precisely where you need it. No need to pass data through intermediate components on way to the target child component - Reference Cursors allow you to get at the data exactly where it is required and this without abandoning the ability to time travel over your application state. There are more thoughts and details here: https://github.com/swannodette/om/wiki/Advanced-Tutorial#reference-cursors Please give Reference Cursors a try in your application and send lots of feedback! This is an alpha release. No previous Om APIs should be affected, however the Reference Cursor feature is largely untested beyond a simple example in the repo. https://github.com/swannodette/om Cheers, 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
On 18 October 2014 21:02, Mark Engelberg mark.engelb...@gmail.com wrote: I think all of James' points about the proven value of structuring an application primarily around data rather than a complex API are right on point. It is one of the things I love about the Clojure philosophy. But there's nothing about the value of data-driven development that requires data lookups and data computations to be so different. There's plenty of room for Clojure to have continued evolution in this area and still preserve the essence of its approach. It seems counter to the idea of keeping code and data separate, and also a fairly leaky abstraction. If you allow computed fields that are indistinguishable from value fields, then you remove many of the guarantees that you have with a pure data structure. For example, how would you serialise a computed field? Would you just ignore it? Does that mean that changing the computed fields around would result in different serialisation? Is there any way of connecting a serialised data structure with computed fields to the right code? So the approach isn't without tradeoffs and increased complexity. I'd also need convincing this is even a problem, as I don't recall a time when this would have been useful in my own work. - James -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
I don't know who is the outlier. The point is that Scala, for instance, has explicit support to hide the distinction between accessing a value and computing a value. The point is to support the uniform access principle. http://en.wikipedia.org/wiki/Uniform_access_principle In one sense, accessing data and calling functions uniform: keyword lookups are just function calls themselves. In another sense, lookup by keyword requires implementing ILookup etc rather than changing a simple function. If you take the stance that the data is your API (and you should), then it makes sense that switching from a keyword lookup to a function call is a breaking change! It shouldn't be easy to rip the data-rug out from under your callers. At least it *is* possible, depending on how far you're willing to go down the Clojure interfaces rabbit hole. Of course, this equation changes even more in favor of Clojure's keywords approach if your client lives across the network. That said, if you're not sure if you want to make the data your API, you can reserve the right to change your mind later quite easily. Let's say you have (ns user) and want to create a username function: (def username :username) ; tada! Yes, this requires some foresight. Back in my C# days, the guidance was always make everything a property. That was especially important if you cared about binary compatibility, since changing from a readonly field to a getter was a breaking ABI change. But you know what, over quite a few major and minor releases of our widely used APIs, I don't recall ever once changing from a trivial `return foo` getter to more complex getter logic. The expectation that a getter is a simple data read was always a core part of the public interface. -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
lein.bat self-install has been broken for a month
Last week, I ran into Leiningen issue 1702, lein self-install/upgrade/downgrade is broken in lein.bat (2.5.0)[1]. Here's how it happened: I emailed a Windows user a pointer to leiningen.org. I got an email back saying -- doesn't work. We worked around it by editing lein.bat in Notepad and removing five lines. Problem solved. Therefore, the present memo to the assembled is just a contemplation. Issue 1702 was opened one month ago, September 18. It is now closed, although the lein.bat I got today from the link on leiningen.org still exhibited the problem. I guess the fix will surface in a future official release. Issue 1702 refers informatively to a pull in which the problem was introduced[2]. The chain of notes is something to think about. --- [1] https://github.com/technomancy/leiningen/issues/1702 [2] https://github.com/technomancy/leiningen/pull/1599 -- You 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: Om 0.8.0-alpha1, Reference Cursors!
Hi Interesting work as usual! One quick question: What is the difference between (let [xs (om/observe owner (items))] ...) as seen in the sub-view component versus the one in main-view which doesn't use `om/observe`: (let [xs (items)] ...) /Jonas On Saturday, October 18, 2014 6:53:50 PM UTC+3, David Nolen wrote: I'm happy to announce the release of Om 0.8.0-alpha1. This release includes the single biggest conceptual enhancement since its initial release - Reference Cursors. As we begin to build larger and larger applications with Om, we often run afoul of the need to organize our application around a hierarchical tree. This is more problematic than in React itself as Om emphasizes a programming model that supports full snapshotting of the application state. This seemingly beneficial property actually exacerbates the hierachical issue and often leads to an incredible amount non-modular programming! The introduction of Reference Cursors allow Om programmers to stop thinking in terms of trees and return to a more natural mode of UI programming - simply calling out into shared APIs around application data precisely where you need it. No need to pass data through intermediate components on way to the target child component - Reference Cursors allow you to get at the data exactly where it is required and this without abandoning the ability to time travel over your application state. There are more thoughts and details here: https://github.com/swannodette/om/wiki/Advanced-Tutorial#reference-cursors Please give Reference Cursors a try in your application and send lots of feedback! This is an alpha release. No previous Om APIs should be affected, however the Reference Cursor feature is largely untested beyond a simple example in the repo. https://github.com/swannodette/om Cheers, 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
