Re: ANN: Om 0.8.0-alpha1, Reference Cursors!

[Jonas Enlund]

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.

lein.bat self-install has been broken for a month

[Matching Socks]

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: Modelling in Clojure

[Brandon Bloom]

>
> 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.

Re: Modelling in Clojure

[James Reeves]

On 18 October 2014 21:02, Mark Engelberg  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: ANN: Om 0.8.0-alpha1, Reference Cursors!

[Ahmad Hammad]

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

[Nahuel Greco]

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 
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: Dynamically generate jar from clojure

[Denis Fuenzalida]

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: book for a beginner with some exercises

[Eric Normand]

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: Calling empty on a map entry

[Mark Engelberg]

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: Modelling in Clojure

[Mark Engelberg]

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.

Calling empty on a map entry

[Alex Engelberg]

(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: [PSA] Clojars scp disabled until further notice

[tcrayford]

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.

Re: behaviour of map

[Jonathan Winandy]

On Seq, no, but you can use a transducer to make it read-ahead.

Eg :
https://gist.github.com/cgrand/c8fa256c9ed8331f9cf1

from Christophe Grand.

On Oct 18, 2014 8:18 PM, "shahrdad shadab" 
wrote:

> 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 
>> 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 
>>> 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.
>

-- 
You 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
F

Re: behaviour of map

[shahrdad shadab]

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 
> 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 
>> 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: behaviour of map

[Jonathan Winandy]

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  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 
> 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

[James Reeves]

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 
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.

behaviour of map

[shahrdad shadab]

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: Modelling in Clojure

[Luc Préfontaine]

+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  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éfontaine 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.

Re: [ClojureScript] ANN: Om 0.8.0-alpha1, Reference Cursors!

[Daniel Kersten]

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  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

[Chris Ford]

James might be too modest to mention this as an exemplar as he's the
maintainer, but for me, 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  wrote:

> On 18 October 2014 08:28, Mark Engelberg  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.

ANN: Om 0.8.0-alpha1, Reference Cursors!

[David Nolen]

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 Reeves]

On 18 October 2014 08:28, Mark Engelberg  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.

Re: Modelling in Clojure

[Tom Oram]

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  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  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: agent validation fails in STM

[Linus Ericsson]

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" :

> 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.

[UPDATE] Spring/Clojure integration / Clojure functions via JMX

[henrik42]

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: Modelling in Clojure

[Mark Engelberg]

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  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.