italian government is making a fast call for contributions on telemedicine and data analysis solutions in order to contain the spread of Covid-19
Hi all, italian government is making a fast call for contributions on telemedicine and data analysis solutions in order to contain the spread of Covid-19. Government is looking for working solutions to adapt/integrate with existing information systems. In my experience solutions written in Clojure will respond to interoperabilty and integration requirements better than others. This is the link to the page of the fast call (in italian) https://innovazione.gov.it/telemedicina-e-sistemi-di-monitoraggio-una-call-per-tecnologie-per-il-contrasto-alla-diffusione-del-covid-19/ Google translator is making a good job https://translate.google.com/translate?hl=en=auto=en=https%3A%2F%2Finnovazione.gov.it%2Ftelemedicina-e-sistemi-di-monitoraggio-una-call-per-tecnologie-per-il-contrasto-alla-diffusione-del-covid-19%2F but I can help with translation if needed. If you own relevant solutions please consider a contribution. Thank you, Luca -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/5a7505cb-9129-4db0-92bc-b4317241de6c%40googlegroups.com.
Re: try catch leaking exception
Thanks for the advice. I will keep it in mind.
Luca
Il giorno mercoledì 14 febbraio 2018 20:05:32 UTC+1, Erik Assum ha scritto:
>
> There is also https://github.com/magnars/realize/blob/master/README.md which
> helps with this problem.
>
> Erik.
> --
> i farta
>
> 14. feb. 2018 kl. 12:20 skrev Thomas Heller <th.h...@gmail.com
> >:
>
> lazy-seq is the short answer.
>
> You are constructing the seq inside the try/catch but it is realized
> outside of that so no exceptions will be caught.
>
> (defn gen-ym-list [from to]
> (try
> (->> (p/periodic-seq (f/parse ym-fmt from) (t/months 1))
> (take-while #(not (t/after? % (f/parse ym-fmt to
> (into [])
> (catch Exception _ nil)))
>
> This forces the seq inside the try/catch.
>
> HTH,
> Thomas
>
> On Wednesday, February 14, 2018 at 11:46:58 AM UTC+1, icamts wrote:
>>
>> Hi all,
>> I found an unexpected behavior of (try ... (catch ...)) special form.
>> Can someone help me understand it better?
>>
>> These are project.clj and core.clj of my test project. The test project
>> zip file is provided as an attachment.
>>
>> (defproject try-try "0.0.0"
>> :description "unexpected try beahvior"
>> :url "http://example.com/FIXME;
>> :license {:name "Eclipse Public License"
>> :url "http://www.eclipse.org/legal/epl-v10.html"}
>> :dependencies [[org.clojure/clojure "1.8.0"]
>> [org.clojure/tools.cli "0.3.5"]
>> [clj-time "0.14.0"]
>> [joda-time/joda-time "2.9.7"]])
>>
>> (ns try-try.core
>> (:require [clj-time.core :as t]
>> [clj-time.format :as f]
>> [clj-time.periodic :as p]))
>>
>> (def ym-fmt (f/formatter "MM"))
>>
>> (defn gen-ym-list [from to]
>> (try
>> (->> (p/periodic-seq (f/parse ym-fmt from) (t/months 1))
>> (take-while #(not (t/after? % (f/parse ym-fmt to)
>> (catch Exception _ nil)))
>>
>> (defn gen-ym-list* [from to]
>> (try
>>(let [ym-from (f/parse ym-fmt from)
>> ym-to (f/parse ym-fmt to)]
>> (->> (p/periodic-seq ym-from (t/months 1))
>> (take-while #(not (t/after? % ym-to)
>>(catch Exception _ nil)))
>>
>> (gen-ym-list "2017" "201802"); returns nil as expected
>>
>> (gen-ym-list "201712" "2018"); throws unexpected exception
>>
>> (gen-ym-list* "2017" "201802"); returns nil as expected
>>
>> (gen-ym-list* "201712" "2018"); returns nil as expected
>>
>> (use 'clojure.walk)
>>
>> (macroexpand-all
>> `(try
>> (->> (p/periodic-seq (f/parse ym-fmt from) (t/months 1))
>> (take-while #(not (t/after? % (f/parse ym-fmt to)
>> (catch Exception _ nil)))
>>
>> (macroexpand-all
>> `(try
>> (let [date-from (f/parse ym-fmt from)
>> date-to (f/parse ym-fmt to)]
>> (->> (p/periodic-seq date-from (t/months 1))
>>(take-while #(not (t/after? % date-to)
>> (catch Exception _ nil)))
>>
>> gen-ym-list doesn't catch IllegalArgumentException thrown when to
>> argument is malformed. It catches the same exception thrown when from is
>> malformed.
>>
>> gen-ym-list* with arguments parsing in an initial let form works as
>> expected.
>>
>> From macro expansion I can see the to is parsed inside a fn*. Is this a
>> known limit in try-catch special form? Or a bug? Thanks in advance for your
>> help.
>>
>> Cheers,
>> Luca
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@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: try catch leaking exception
Thanks a lot. I was far from it and now I'm grateful for this new insight.
We never stop learning.
Cheers,
Luca
On Wednesday, February 14, 2018 at 12:20:20 PM UTC+1, Thomas Heller wrote:
>
> lazy-seq is the short answer.
>
> You are constructing the seq inside the try/catch but it is realized
> outside of that so no exceptions will be caught.
>
> (defn gen-ym-list [from to]
> (try
> (->> (p/periodic-seq (f/parse ym-fmt from) (t/months 1))
> (take-while #(not (t/after? % (f/parse ym-fmt to
> (into [])
> (catch Exception _ nil)))
>
> This forces the seq inside the try/catch.
>
> HTH,
> Thomas
>
> On Wednesday, February 14, 2018 at 11:46:58 AM UTC+1, icamts wrote:
>>
>> Hi all,
>> I found an unexpected behavior of (try ... (catch ...)) special form.
>> Can someone help me understand it better?
>>
>> These are project.clj and core.clj of my test project. The test project
>> zip file is provided as an attachment.
>>
>> (defproject try-try "0.0.0"
>> :description "unexpected try beahvior"
>> :url "http://example.com/FIXME;
>> :license {:name "Eclipse Public License"
>> :url "http://www.eclipse.org/legal/epl-v10.html"}
>> :dependencies [[org.clojure/clojure "1.8.0"]
>> [org.clojure/tools.cli "0.3.5"]
>> [clj-time "0.14.0"]
>> [joda-time/joda-time "2.9.7"]])
>>
>> (ns try-try.core
>> (:require [clj-time.core :as t]
>> [clj-time.format :as f]
>> [clj-time.periodic :as p]))
>>
>> (def ym-fmt (f/formatter "MM"))
>>
>> (defn gen-ym-list [from to]
>> (try
>> (->> (p/periodic-seq (f/parse ym-fmt from) (t/months 1))
>> (take-while #(not (t/after? % (f/parse ym-fmt to)
>> (catch Exception _ nil)))
>>
>> (defn gen-ym-list* [from to]
>> (try
>>(let [ym-from (f/parse ym-fmt from)
>> ym-to (f/parse ym-fmt to)]
>> (->> (p/periodic-seq ym-from (t/months 1))
>> (take-while #(not (t/after? % ym-to)
>>(catch Exception _ nil)))
>>
>> (gen-ym-list "2017" "201802"); returns nil as expected
>>
>> (gen-ym-list "201712" "2018"); throws unexpected exception
>>
>> (gen-ym-list* "2017" "201802"); returns nil as expected
>>
>> (gen-ym-list* "201712" "2018"); returns nil as expected
>>
>> (use 'clojure.walk)
>>
>> (macroexpand-all
>> `(try
>> (->> (p/periodic-seq (f/parse ym-fmt from) (t/months 1))
>> (take-while #(not (t/after? % (f/parse ym-fmt to)
>> (catch Exception _ nil)))
>>
>> (macroexpand-all
>> `(try
>> (let [date-from (f/parse ym-fmt from)
>> date-to (f/parse ym-fmt to)]
>> (->> (p/periodic-seq date-from (t/months 1))
>>(take-while #(not (t/after? % date-to)
>> (catch Exception _ nil)))
>>
>> gen-ym-list doesn't catch IllegalArgumentException thrown when to
>> argument is malformed. It catches the same exception thrown when from is
>> malformed.
>>
>> gen-ym-list* with arguments parsing in an initial let form works as
>> expected.
>>
>> From macro expansion I can see the to is parsed inside a fn*. Is this a
>> known limit in try-catch special form? Or a bug? Thanks in advance for your
>> help.
>>
>> Cheers,
>> Luca
>>
>>
>>
--
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: clojure.compiler.disable-locals-clearing memory leak?
Are you using the same JVM? It's an optimization introduced at some point in JVM GC. It can be turned off with the JVM flag -XX:-UseGCOverheadLimit. See https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html Il giorno lunedì 25 gennaio 2016 07:49:03 UTC+1, Mars0i ha scritto: > > In my application, I seem to get a memory leak when I use > -Dclojure.compiler.disable-locals-clearing=true in Clojure 1.7.0 and 1.8.0, > but not in 1.6.0. (i.e. I get "java.lang.OutOfMemoryError: GC overhead > limit exceeded" with the more recent versions). > > Any guesses about why this might happen? Just curious. > > (I think I can live without disabling locals-clearing. I don't fully > understand it. Not sure why I started using it. I don't use a debugger.) > -- 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: some guidance sought
Not a pointer but this may help in testing your implementation: https://github.com/ztellman/collection-check Il giorno lunedì 10 agosto 2015 00:31:25 UTC+2, William la Forge ha scritto: I've done a lot with AA trees in the past, creating variations that are immutable, durable (replacing b-trees) and versioned of vectors, maps and sets. I would like to migrate these ideas from Java to Clojure, while implementing the interfaces appropriate for Clojure. Still being very much a newbie, I'd appreciate some pointers, relevant docs and/or examples. 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: Size of Java serialized Clojure data structures
Hi Alan, I did the same experiment, with the same variable names too :) have a look at the github issue. Finally I discovered prevayler calls reset method on oos every time it writes to it. This is why the overhead is written every time. Klaus, prevayler author, says it is so to prevent leaks and I still don't understand which leaks he refers to. But the difference in size has an explanation now. Thanks, Luca Il giorno sabato 8 agosto 2015 01:48:51 UTC+2, Alan Malloy ha scritto: You must be doing something wrong, or describing your method badly, because the vector [:a1 1] doesn't take nearly that much space in my experiments. The first object you write to a stream requires quite a bit of overhead, but after that future objects are relatively cheap. Here's an example you can try yourself: user (def baos (ByteArrayOutputStream.)) user (def oos (ObjectOutputStream. baos)) user (.writeObject oos [:a1 1]) user (.size baos) 671 user (.writeObject oos [:a1 1]) user (.size baos) 719 user (.writeObject oos [:a1 1]) user (.size baos) 767 user (.writeObject oos [:x 2]) user (.size baos) 845 So the first write takes around 600 bytes of overhead, and each write of [:a1 1] takes around 40-50 bytes. Writing a new vector with two different objects takes more, because it can't reuse references to constants like :a1, but it is still just 80 bytes. Nowhere near 1KB per small vector. -- 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: Size of Java serialized Clojure data structures
Yes. I suggested nippy. The question is about the size of Java serialized Clojure data structures. Can a two element vector be 1kB in size? Why serialization in my REPL experiment (see the code following the link in my previous mail) produces a 80MB byte buffer while prevayler logs are 1GB? Il giorno venerdì 7 agosto 2015 13:51:45 UTC+2, Gary Verhaegen ha scritto: You should probably look at Clojure-specific solutions, starting with EDN (i.e. essentially pr-str), fressian, transit or nippy. Clojure data structures have a lot of properties that can be exploited (we only care about the abstract type and the actual data), so a serializer can make a lot of assumptions that a generic Java solution can't. -- 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.
Size of Java serialized Clojure data structures
Hi all, I opened this issue on github project prevayler-clj https://github.com/klauswuestefeld/prevayler-clj/issues/1 because 1M short vectors, like this [:a1 1], forming the state of the prevayler, results in 1GB file size when serialized, one by one, with Java writeObject. Is it possible? About 1kB for each PersistentVector? Further investigations demonstrated the same amount of vectors can be serialized in a 80MB file. So, what's going wrong in prevayler serialization? Any suggestion is welcome. Thanks in advance. Luca -- 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: (flatten non-sequential) has a surprising result
Hi Pablo,
I think you're right. Have a look at flatten source
(defn flatten
Takes any nested combination of sequential things (lists, vectors,
etc.) and returns their contents as a single, flat sequence.
(flatten nil) returns an empty sequence.
{:added 1.2
:static true}
[x]
(filter (complement sequential?)
(rest (tree-seq sequential? seq x
it is the rest function that causes this behavior and it seems to be just
an optimization to avoid filtering the first element of tree-seq that is
known to be the whole sequence. A simpler definition of flatten seems to
have the behavior you expected.
(defn flatten1 [x] (filter (complement sequential?) (tree-seq sequential?
seq x)))
Il giorno mercoledì 1 luglio 2015 13:55:28 UTC+2, J. Pablo Fernández ha
scritto:
Hello Clojurists,
Today I was surprised by the result of (flatten 1) which is '(). I was
expecting '(1) or an error. Talking in some other people in #clojure @
clojurians.net, not everybody agrees that '(1) is a good result but that
'() is somewhat surprising. Would it be better if it raised an error when
the attribute is not sequential?
--
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: Integration with Mutable Object-Oriented Eventing Hell
Hi Christian, I've been a bit too technical. What I mean is give your OO system a new interface made of functions. Choose functions according to your needs and develop a layer of functions that can create and access your objects instances. It's my opinion this is the stateful bridge in your first e-mail. Develop new features in clojure over this layer. This is a way to use your OO system. If you need to extend your objects the excellent clojure type selection flowchart by Chas Emerick will help to understand options clojure gives to you. https://github.com/cemerick/clojure-type-selection-flowchart/ Il giorno venerdì 4 aprile 2014 11:24:18 UTC+2, Christian Eitner ha scritto: Hi Luca, On Thursday, April 3, 2014 11:57:27 AM UTC+2, icamts wrote: Hi Christian, I think you are looking for this. http://en.wikipedia.org/wiki/Facade_pattern In clojure you can use a def for each private member of the facade. Alternatively you can write a function to instantiate and return private members. Use a defn for each facade's methods. I'm not sure in how the facade pattern would help me on the conceptual level. I'm pretty confident that I can work out the technical details of how to get my fingers at the existing objects or how to interface from the OO world into Clojure code. The question is more like, how should I model the integration? It seems pretty useless and/or dangerous to me to put the mutable objects into Clojure's immutable data structures and work on the them directly. Would I kind of extract the objects' data (value-like) into my data structures, perform operations an these and in the end retransform those values onto the objects? I don't think you'll be able to restore clojure processed values in all objects. Maybe you'll need to extend Java types in clojure (see before). That's more like the patterns I am searching for. Thanks, Christian I hope this helps, Luca -- 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: Integration with Mutable Object-Oriented Eventing Hell
Hi Christian, I think you are looking for this. http://en.wikipedia.org/wiki/Facade_pattern In clojure you can use a def for each private member of the facade. Alternatively you can write a function to instantiate and return private members. Use a defn for each facade's methods. Luca Il giorno mercoledì 2 aprile 2014 14:48:39 UTC+2, Christian Eitner ha scritto: Hello everybody, Given an enormous network of inter-referenced, mutable objects which have to change in-place driven by events (= the OO system). Which strategy would you recommend to plug into such a system with Clojure, building an island of immutable functional programming saneness? How to build this famous 'stateful bridge' that I have read about here and there, but have not found concrete examples for? Or would you really dissuade me from trying anything like that, and treat Clojure's 'hostedness' as simply a way to use the host's array of libraries? Any hints or references to further literature would be welcome. Thanks for your consideration, Christian -- 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: om: state management considerations
Hi Rle,
I'm a clojurescript / om newbie too. I'll try to answer to the best of my
knowledge and maybe someone else can improve this first guess.
Il giorno giovedì 27 marzo 2014 09:20:41 UTC+1, rlewczuk ha scritto:
Hi,
After playing a bit with om, I'm somewhat confused about state maintaining
possibilities it offers. There is global application state and local
component state. I have some doubts about using local state as it seems to
lead to troubles as soon as code grows a bit (I'm thinking about
traditional widgets, eg. data table with editing capability - somewhat
boring stuff, yet quite common in many cases). Most common approach to this
seems to be to set up some local state and then use core.async channels for
communication and updating global state asynchronousluy (go ...) blocks.
My feeling is that it creates lots of places with application state which
negates to some extent main premise of state handling by om. Do I need to
use local state at all ? Are there any alternatives ? I'm thinking about
using keyword namespacing in global state to separate concerns, for example
viewed data table row could be kept as something like :d/current-row
somewhere in global state ('d' stands for data) but when row editing starts
:e/current-row appears and is used by input fields ('e' stands for
editing). UI configuration (column descriptions etc.) would use 'u' prefix
(eg. :u/columns) for example etc.
Don't mess up application state with view state information. You can keep
your current / editing row in the local state of a table component that
contains your row components. As a further optimization you may render your
table as pure html and mount a row component over one row only when editing
it. Om components are already flyweight. If it's feasible and how easily it
can be done seems to be a matter of react.js (owner of mount / unmount
lifecycle) more than om.
As a rule of thumb for myself: application state should not change if you
change your view (e.g. represent data with a table or with a chart). It may
be bound to your use case. So if it contains some flags for user
interaction they are ok.
My feeling is that keeping application state strictly in global state
would make some things easier (testing+debugging UI components, recording
user sessions in full detail by listening on :tx-listen etc.). But blindly
following all-in-global state also can have its pitfalls that I'm not aware
of (as cljs/reactjs/om newbie).
When you add a component you need to make rooms for its state in the
application state. I fear this is very error prone.
There are the following aspects of UI state as I see it:
- hardcoded UI config data (widget descriptions, column descriptions etc.);
pass them in as :opts
- customizable UI config data (eg. skins and styles that application user
can choose);
in the application state; you can load / store them in a user profile at
the server side
- UI code (function references sometimes bound somewhere to application
state);
(not sure I understand the question) may be in functions in the same file
of your component definition functions
- UI state (eg. currently edited data, flags marking that data is being
edited/viewed row being selected etc.)
in local state
- business data (fetched REST from backend);
in application state
- inherently stateful stuff (eg. core.async channels);
in local state or in global shared state for inter components communication
- etc.
My question is: where would you recommend placing individual bits of
config/data/state listed above (global state? local state? :opts ? global
:shared ? etc.) ?
Regards,
rle
I hope this helps,
Luca
--
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.
core.async threadpool size
Hi all, quite a funny question. Thread pool size in core.async is twice the number of processors plus 42. https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/exec/threadpool.clj 42? The question is: 1) should it be 4 or 2? 2) 42 is the response to life, universe and everything 3) for some technical reason 42 is also a good minimum number for a thread pool Luca -- 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: core.async threadpool size
Thank you Ben. Can we speculate on a go-off macro? Like in agents send / send-off to have go-off blocks executed by a cached thread pool executor? Luca Il giorno giovedì 27 marzo 2014 16:01:16 UTC+1, Ben Mabey ha scritto: I asked Timothy Baldridge about this on IRC when the change was made that added 42 and this was the reply I got: we're trying to strike a balance there, we don't want people to do IO inside a go block, but if they have to we'd don't want it to totally stall out. Here is the full conversation: http://clojure-log.n01se.net/date/2013-08-29.html#15:45a -Ben On 3/27/14, 8:55 AM, icamts wrote: Hi all, quite a funny question. Thread pool size in core.async is twice the number of processors plus 42. https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/exec/threadpool.clj 42? The question is: 1) should it be 4 or 2? 2) 42 is the response to life, universe and everything 3) for some technical reason 42 is also a good minimum number for a thread pool Luca -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. 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: core.async threadpool size
Thank you again Ben, now it is more clear. Luca Il giorno giovedì 27 marzo 2014 16:43:51 UTC+1, Ben Mabey ha scritto: If you want or need to block in a go-block then you should use the `thread` macro instead of the `go` macro. A thread macro block will be ran in a cached thread pool as you seem to be wanting: https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L379 Just note that you will need to use the blocking CSP operator variants, e.g. !! instead of !, while inside of `thread`. -Ben On 3/27/14, 9:24 AM, icamts wrote: Thank you Ben. Can we speculate on a go-off macro? Like in agents send / send-off to have go-off blocks executed by a cached thread pool executor? Luca Il giorno giovedì 27 marzo 2014 16:01:16 UTC+1, Ben Mabey ha scritto: I asked Timothy Baldridge about this on IRC when the change was made that added 42 and this was the reply I got: we're trying to strike a balance there, we don't want people to do IO inside a go block, but if they have to we'd don't want it to totally stall out. Here is the full conversation: http://clojure-log.n01se.net/date/2013-08-29.html#15:45a -Ben On 3/27/14, 8:55 AM, icamts wrote: Hi all, quite a funny question. Thread pool size in core.async is twice the number of processors plus 42. https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/exec/threadpool.clj 42? The question is: 1) should it be 4 or 2? 2) 42 is the response to life, universe and everything 3) for some technical reason 42 is also a good minimum number for a thread pool Luca -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@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 clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. 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: (series of swap! on atom) == single swap!
Hi t x and Jan, what about performing the side effect part of the function adding a watch? (They are no more in alpha with the upcoming 1.6.) Cheers, Luca Il giorno lunedì 17 febbraio 2014 09:29:57 UTC+1, t x ha scritto: Hi Jan, Thanks for your explanations. I have no idea how I managed to completely misunderstand clojure/atom for the past few years -- I suspect it's because I never use clojure/STM, and as a result, I've never had an atom roll back on me. I've decided to switch to agents. Thanks again for catching this fundamental error. On Sun, Feb 16, 2014 at 11:00 PM, Jan Herich jan.h...@gmail.comjavascript: wrote: Hi t x, I think, that lock-free approach an it's semantics is more in line with other Clojure reference types such as refs. It also encourages you to only use pure functions for state transitions, among other things, such as significant performance benefits in comparison with lock based approaches, see for example this article. If you really want to update some reference with function which will also perform impure actions such as file I/O, consider using agents and send or send-off (the latter in case of I/O blocking actions), functions given to send and send-off are guaranteed to run only once. Dňa pondelok, 17. februára 2014 2:36:59 UTC+1 t x napísal(-a): Hi Jan, You're right. I'm wrong. I'm grateful you pointed this out -- this would have otherwise been impossible to debug. === To everyone: Why can swap! be retried? This confuses me -- to implement swap!, why can't we * have a lock * ensure that only one swap! is in session at any given time * have the given swap! complete before running the next swap! Thanks! On Sun, Feb 16, 2014 at 3:51 PM, Jan Herich jan.h...@gmail.com wrote: I'm afraid your understanding of atom swap! operations is not quite correct - update function must (or should) be pure as well. See the documentation for swap!, update function could be potentially called multiple times if there are more threads of execution updating one atomic reference - there is simple compare and set mechanism involved, which compares the old value of the atom (input for the update function) and sets the atom to new value (return value from the update function) only value of the atom reference was not changed in between, if yes the compare and set is retried until ti succeeds. Dňa nedeľa, 16. februára 2014 23:35:24 UTC+1 t x napísal(-a): I believe that's the STM approach, which has the advanrtage of: * can synchronize across multiple pieces of data but has the disadvantage of: * work must be pure since it can be retried * possibly less efficient due to possibility of retrying In the example I posted above, I only need to: * modify a single atom and the approach I presented above: * can be impure, since it is guaranteed to only run once * is guaranteed to succeed (without retrys) On Sun, Feb 16, 2014 at 2:25 PM, Ramesh ramesh1...@gmail.com wrote: You can use a ref instead of an atom. And use dosync with multiple alter, so everything is safely inside a transaction. On Feb 16, 2014 2:04 PM, t x txre...@gmail.com wrote: Hi John, Your solution is perfectly valid and optimal for the problem I described above. Unfortunately, I forgot to mention an additional constraint: sometimes I do: (let [ foo (:some-selector @data-atom) ] (swap! data-atom update-in [:other-selector] ... )) which the - doesn't quite work on, but my ugly hack above does resolve. The problem being -- I want to update one part of the atom, but it depends on another part of the atom. I ended up with the following hack: (defn tswap! [atm func] (swap! atm (fn [old] (let [natm (atom old)] (func natm) @natm On Sat, Feb 15, 2014 at 4:09 PM, John D. Hume duelin@gmail.com wrote: On Sat, Feb 15, 2014 at 6:04 PM, t x txre...@gmail.com wrote: (defn what-I-want [] (with-atom some-atom assoc-in ... assoc-in ... update-in ...)) I often do something like this and don't find it too ugly: (swap! my-atom #(- % (assoc-in [:k] v) (update-in [:k2] inc) ,,,)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from
Re: OT: Enterprise Schedulers
Hi Adrian, I've been discovered :) I enjoyed exploring a ESB scenario. In abstract you may go along the lines of any of ESB solutions this way: 1) Any task is performed by suitably configured components 2) componets live in a container 3) components communicate through a message router 4) special components resolve technology itegration issues (connectors) Another interesting approach is provided by Akka. Have a look to this thread https://groups.google.com/forum/#!topic/akka-user/KFzPbaNglPQ A clojure library providing erlang like actors is pulsar https://github.com/puniverse/pulsar Cheers, Luca Il giorno mercoledì 12 febbraio 2014 13:37:28 UTC+1, Adrian Mowat ha scritto: Hi Luca Thanks for the links! I definitely have a lot of hammock time ahead of me :-) Cheers Adrian On 11 Feb 2014, at 14:37, icamts wrote: Hi Adrian, the answer is more off-topic than the question :) but have a look to Spagic (I'm a member of the developers' team), Mule ESB, Petals ESB or Talend ESB. You may already know Talend as an ETL solution. You'll find tools to define, configure and run instances of services or processes. Monitong application with re-start / re-run facilities. Connectors for services / processes integration. In a ESB scenario developers will design simple processes with a quartz or file polling connector followed by a script / custom component designed to accomplist the batch task. Custom components can be written in clojure if you reify the required interface. The only cavevat is the AOT compilation. Some other ideas are below, along your problem statement. Cheers, Luca - Be controlled by artifacts developers control - Probably be github friendly Put service deployment directory and estensions / plugins directory under version control and copy them as a part of the deployment process. An ESB can be deployed like a simple webapp. - - Provide a direct relationship between an application and its tasks Choose meaningful service names. Deploy a local ESB in the same AS of your application and use an in-memory invoker / connector. - Support separate sandbox, staging and production environments Use different ESB instances. - Be scalable Single task scalability is up to your code. - Be distributed - jobs for application X can run on the same host as application X or on a different host or cluster as needed Sevices / processes can be run on every ESB instance. Use in-memory invoker / connector or soap invoker / connector. - Be secure Use https for remote connection. Use sftp for file transfer. - Be easy to administer - Job progress and status is visible Service progress notification is up to your code and not a monitor console feature. Process running step is available. - - Alert when a job fails Use a mail connector to alert on job fails - - Easy to re-run a job Restart / rerun through monitoring console. - - Easy to spin up new hosts and/or move all processing to a different host Deploy a new instance with the same configuration. No running service can be moved. Running processes may be moved. It depends on workflow engine implementation details. - - Provide a standard way of organising assets like files and configs across all our applications (Not sure what you mean.) - Comply with our hybrid infrastructure (stuff runs internally and in the cloud) - Data can move internal - cloud Is it an ETL task? - - Data can move cloud - internal Same as before - - Data can be processed entirely within a host That's so - Support different ways of triggering a job - Scheduled tasks Use a quartz input connector - - Run when file x arrives Use a file poller input connector - - Run job y after job x completes Use an output connector to trigger the next job start or design a process with jobs in a sequence. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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/95W4MlkFgnY/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups
Re: OT: Enterprise Schedulers
Hi Adrian, the answer is more off-topic than the question :) but have a look to Spagic (I'm a member of the developers' team), Mule ESB, Petals ESB or Talend ESB. You may already know Talend as an ETL solution. You'll find tools to define, configure and run instances of services or processes. Monitong application with re-start / re-run facilities. Connectors for services / processes integration. In a ESB scenario developers will design simple processes with a quartz or file polling connector followed by a script / custom component designed to accomplist the batch task. Custom components can be written in clojure if you reify the required interface. The only cavevat is the AOT compilation. Some other ideas are below, along your problem statement. Cheers, Luca - Be controlled by artifacts developers control - Probably be github friendly Put service deployment directory and estensions / plugins directory under version control and copy them as a part of the deployment process. An ESB can be deployed like a simple webapp. - - Provide a direct relationship between an application and its tasks Choose meaningful service names. Deploy a local ESB in the same AS of your application and use an in-memory invoker / connector. - Support separate sandbox, staging and production environments Use different ESB instances. - Be scalable Single task scalability is up to your code. - Be distributed - jobs for application X can run on the same host as application X or on a different host or cluster as needed Sevices / processes can be run on every ESB instance. Use in-memory invoker / connector or soap invoker / connector. - Be secure Use https for remote connection. Use sftp for file transfer. - Be easy to administer - Job progress and status is visible Service progress notification is up to your code and not a monitor console feature. Process running step is available. - - Alert when a job fails Use a mail connector to alert on job fails - - Easy to re-run a job Restart / rerun through monitoring console. - - Easy to spin up new hosts and/or move all processing to a different host Deploy a new instance with the same configuration. No running service can be moved. Running processes may be moved. It depends on workflow engine implementation details. - - Provide a standard way of organising assets like files and configs across all our applications (Not sure what you mean.) - Comply with our hybrid infrastructure (stuff runs internally and in the cloud) - Data can move internal - cloud Is it an ETL task? - - Data can move cloud - internal Same as before - - Data can be processed entirely within a host That's so - Support different ways of triggering a job - Scheduled tasks Use a quartz input connector - - Run when file x arrives Use a file poller input connector - - Run job y after job x completes Use an output connector to trigger the next job start or design a process with jobs in a sequence. -- 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/groups/opt_out.
Re: Very strange behaviour in reducers
Similar threads are
https://groups.google.com/forum/?hl=en#!topic/clojure/A1gW_BB_4MU
https://groups.google.com/forum/?hl=en#!topic/clojure-dev/scvyi2Cwk7g
Luca
Il giorno martedì 14 gennaio 2014 16:43:10 UTC+1, Yves Parès ha scritto:
Hello!
When mapping and reducing a map, it seems arguments are passed differently
to the function that is mapped depending on whether you reduce with
r/reduce or r/fold:
(r/fold +
(r/map (fn [k v] (inc v)) {:a 4 :b 5}))
But:
(r/reduce +
(r/map (fn [[k v]] (inc v)) {:a 4 :b 5}))
The function r/mapped is the same each time, but if the return value of
r/map is further reduce with r/fold, it received 2 arguments (key and
value). However, if it is reduced with r/reduce, the fn is called with ONE
pair [k v].
Is that normal?
--
--
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/groups/opt_out.
Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata
Try these in a REPL user= (ns-map *ns*) user= (keys (ns-map *ns*)) user= (vals (ns-map *ns*)) user= (map meta (vals (ns-map *ns*))) user= (ns proof) proof= (defn ^:my-x-comp func1 [] (prn func1 executed)) proof= (filter #(:my-x-comp (meta %)) (vals (ns-map *ns*))) proof= ((first (filter #(:my-x-comp (meta %)) (vals (ns-map *ns*) not sure this is the right way, just an experiment with REPL. (I chose the wrong reply option and send this only to you, Jace, this morning. Sorry.) Luca Out of curiousity, where do the defs go? Could one iterate over all the vars in the runtime environment? Would I just get pointers to native code? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/groups/opt_out.
Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata
Hi Jace, this is my first answer in this group. Maybe I'm at the same point you are, except my background is in Java, so I just want to share what I understood in the hope to expand your question for the comunity. I found myself to use a lot of code generation in Java to have the glue among components written for me by various technologies. Maybe this is the same you do with reflection. Lot of metadata and conventions above configuration to avoid configuration getting more complex than the system itself. Maybe functions are your components in Clojure and you can explore defined functions with ns functions (http://clojure.org/Namespaces). I think these are the metadata you talk about and you don't need to accumulate them in macros. I don't know how to explore functions metadata (i.e. their arguments) but it shoud be a matter of function itself to establish its arguments meaning. Maybe you can use macros to have the glue code written for you or maybe you can use other functions for this purpose. You cannot learn about this in 21 days (http://norvig.com/21-days.html). I found this interesting link googling the sentence: Bad programming is easy. Idiots can learn it in 21 days, even if they are Dummies. found in HtDP ( http://www.ccs.neu.edu/home/matthias/HtDP2e/) :) I don't know how SICP compares to HtDP but thank you for the reference. I can point you to the next book I'll read about macros: let over lambda (http://letoverlambda.com/), but as stated in the introduction macros are the last step to become a well rounded (Lisp) programmer, maybe other aspects of FP itself should be known before. In the hope this little can be useful, Luca Il giorno giovedì 8 agosto 2013 04:19:15 UTC+2, Jace Bennett ha scritto: Thanks to the community for a wondrous programming environment. I discovered SICP last year, and fell in love with the idea of lisp. But I've come to a point where I think I need practice on moderately sized projects before more reading will help. When starting on almost any moderately scoped effort, I quickly run into a class of problems which I think may be a fit for macros, but I want to understand what is the idiomatic way to approach them in clojure. Most of my professional experience is in .NET, and that is probably coloring my thought patterns a bit. In that context, I often use reflection scans and type metadata to configure infrastructural bits and dry things up. Instead of having to explicitly register components in the more dynamic areas of my app, I use conventions to select components to register from the metadata I have about my code. I can imagine using macros in clojure to accumulate metadata about my declarations so that I can query them at runtime. For example, maybe a defendpoint macro that sets up a handler AND adds it to the routing table (or more directly an endpoint map which I then use to make routing decisions among other things). Admittedly, something about the sound of the phrase it's just data tells me I'm sniffin up the wrong tree here. But I don't know how to turn that nagging feeling into working code. Is this a reasonable use of the macro? What about doing the registration at macro-expansion time vs emitting runtime code to do it? How should one approach the problems space otherwise? Thanks for your time. -- -- 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/groups/opt_out.
