(doall (pmap (range ...))) may be a viable approach also,
depending on the behaviour you want.
On Sat, May 19, 2018 at 11:42 PM, Renata Soares
wrote:
> It worked, thanks!
>
> Em sábado, 19 de maio de 2018 19:38:28 UTC-3, Alex Engelberg escreveu:
>>
>> Not sure what's going on with shutdown-agen
It worked, thanks!
Em sábado, 19 de maio de 2018 19:38:28 UTC-3, Alex Engelberg escreveu:
>
> Not sure what's going on with shutdown-agents, but you could call (run!
> deref ...) to wait for all the futures to complete.
>
> On Sat, May 19, 2018 at 3:29 PM Renata Soares > wrote:
>
>> Hello,
>>
>>
Not sure what's going on with shutdown-agents, but you could call (run!
deref ...) to wait for all the futures to complete.
On Sat, May 19, 2018 at 3:29 PM Renata Soares
wrote:
> Hello,
>
> I am using future this way:
>
> (doall (map #(future () (range 1 max-size))
>
> When the max-size is
On Monday, July 25, 2016 at 10:56:09 AM UTC-5, Mars0i wrote:
>
> just noticed this morning that :path is explained in "clojure.spec -
> Rationale and Overview".
>
There's also material about :path in your Spec Guide, but I had not fully
understood it. I get it now--at least up to the level of
Alex, thanks very much. That's all very helpful. Just what I needed. I
hadn't seen an explanation of the meaning of :path, :via, and :in, and was
guessing about them from experiments.:via and :in aren't mentioned in
the docstring, so I wasn't sure whether to depend on them. (The source
On Sunday, July 24, 2016 at 10:40:41 PM UTC-5, Mars0i wrote:
>
> spec/explain-data seems very important. It allows programmatic responses
> to spec failures. Maybe explain-data's behavior hasn't yet stabilized,
> though? The structure of the return value has changed between 1.9.0-alpha7
> t
Sorry for my delayed answer. I've tried examples with only futures that you
give and they works really fine, all agent were closed.
And I figured out that this problem arises only when I using datomic.api.
> java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-
Serzh:
Could you give a few details about the software machine where you saw it
not terminate, even after an hour? I may try collecting some info like
this to add to the Clojure ticket. In particular, the outputs of the
following commands.
java -version
uname -a
lsb_release -d
time java -jar cl
On my Ubuntu 14.04 laptop process doesn't terminates at all. I was waiting
about an hour.
Also this issue affects code which uses datomic.api, which, I think, uses
futures too.
Середа, 30 липня 2014 р. 22:50:11 UTC+3 користувач Andy Fingerhut написав:
>
> Never is an awfully long time :-) If yo
Never is an awfully long time :-) If you wait about 60 seconds, the
command you gave calling (future 1) does terminate, at least on Mac OS X
10.8.5 where I tested it, and I have seen the same behavior on Linux and I
think Windows.
This version terminates much more quickly:
java -jar clojure-1.6.
Hi Gary,
I wrote my initial post in January, but I just wanted to say... Thanks for
taking the time to write your reply - I very much appreciated it.
I suspect I will be writing algorithms in C++ for a while to come, but at
some point I hope to do comparisons with Clojure versions.
Regards,
It depends on your workload and use-cases, and you could fill many
textbooks with a discussion of the tradeoffs, but I can think of some rules
of thumb that point in clojure's favor.
The most essential metric for me to see has been Amdahl's Law:
http://en.wikipedia.org/wiki/File:AmdahlsLaw.svg
To
oh thats a much better option! thanks!
On Mon, Jun 10, 2013 at 4:30 PM, James Reeves wrote:
> On 10 June 2013 13:59, Nicola Mometto wrote:
>
>>
>> They're in the core.incubator contrib repository
>> https://github.com/clojure/core.incubator
>
>
> They're also in the clojure.core namespace for
On 10 June 2013 13:59, Nicola Mometto wrote:
>
> They're in the core.incubator contrib repository
> https://github.com/clojure/core.incubator
They're also in the clojure.core namespace for Clojure 1.5 onward, but
renamed to some-> and some->>.
- James
--
--
You received this message because
great, thanks!
On Mon, Jun 10, 2013 at 3:59 PM, Nicola Mometto wrote:
>
> They're in the core.incubator contrib repository
> https://github.com/clojure/core.incubator
>
> shlomivak...@gmail.com writes:
>
> > Hey, its been a while since this discussion ended..
> >
> > I read through it and now i
They're in the core.incubator contrib repository
https://github.com/clojure/core.incubator
shlomivak...@gmail.com writes:
> Hey, its been a while since this discussion ended..
>
> I read through it and now i am fully confused, where did -?> and -?>> end
> up being in?
>
> Thanks,
> Shlomi
>
> On
Hey, its been a while since this discussion ended..
I read through it and now i am fully confused, where did -?> and -?>> end
up being in?
Thanks,
Shlomi
On Thursday, April 21, 2011 5:51:59 PM UTC+3, Ivan Koblik wrote:
>
> Hi Paul,
>
> Thanks, good to know. Sorry for the misleading email.
>
>
Paul,
Thanks... but I want the opposite of delay.
Basically, I do not want to consume a thread waiting for a Future to be
satisfied. I want to continue a computation on a different thread once the
Future/Promise is satisfied. Why?
Think of a web app that's serving either a long poll or a web soc
Oh! I see, you want promises with callbacks (which you want to be futures).
Once a promise is delivered, you want to kick off a future (in Clojure,
futures consume a thread from the thread pool to do their work).
It's been discussed before:
https://groups.google.com/forum/?fromgroups=#!topic/cl
You might find this work in progress interesting then:
http://github.com/clojure/core.async
On Thu, May 30, 2013 at 3:46 PM, David Pollak wrote:
> Paul,
>
> Thanks... but I want the opposite of delay.
>
> Basically, I do not want to consume a thread waiting for a Future to be
> satisfied. I wan
I'm not entirely sure what you're trying to accomplish in a larger context,
but perhaps you're looking for something like this?
(delay (deref (future (and (Thread/sleep 2000) (+ 1 2)
... or maybe you want just `delay`
Cheers,
Paul
On Thursday, May 30, 2013 6:09:02 AM UTC-7, David Pollak w
Okay... I wrote my own:
https://github.com/projectplugh/plugh/blob/master/src/plugh/util/misc.clj#L51
One can register for on-done and on-fail. I'll work on adding fail-fast and
also map (so one can transform the future and execute code when the
transformed future has been realized/delivered/fini
by the second future, I mean an instance of
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html ,
which just has to conform to the interface, and doesn't actually have to
execute on a different thread. Clojure's 'future' function returns an
instance of one of these that uses
Maybe an easy solution: wrap the first future in another future that
blocking-derefs, then performs your extra computation? Do an extra
'realized?' check for the optimization you mention. That would still
consume threads in the case that it's not realized, but I think it gets you
what you want.
According to this article, Clojure does not yet have this facility:
http://java.dzone.com/articles/promises-and-futures-clojure
This is something that is being worked on and discussed, though:
http://dev.clojure.org/display/design/Promises
https://groups.google.com/forum/#!topic/clojure-dev/7BKQi9
Yes I know, but my membership approval is still pending on clojure-dev (CA
on the way), and from what I have read, I am supposed to ask first on the
ML before creating a JIRA ticket.
http://dev.clojure.org/display/design/JIRA+workflow
Slow process...
Max
On Saturday, October 27, 2012 1:02:4
+1 That would be nice. This may not be the right place for the suggestion
though.
On Thursday, October 25, 2012 2:43:58 PM UTC+2, Max Penet wrote:
>
> wrong commit:
> https://github.com/mpenet/clojure/commit/9c6e47524dc21c6bdfaa9d0cc2a69377cc69cbf3
>
>
> On Thursday, October 25, 2012 2:35:01 P
wrong commit:
https://github.com/mpenet/clojure/commit/9c6e47524dc21c6bdfaa9d0cc2a69377cc69cbf3
On Thursday, October 25, 2012 2:35:01 PM UTC+2, Max Penet wrote:
>
> Another enhancement proposal, would it be possible to have a future-call
> arity with an additional argument as the ExecutorServi
There will be further releases of ClojureScript One.
As we work on ClojureScript projects for clients, we are learning a lot
about what works well and what doesn't. In the future, we will use what we
have learned to make improvements to ClojureScript One.
We also plan to move some of the includ
Hi Paul,
Thanks, good to know. Sorry for the misleading email.
Cheers,
Ivan.
On 21 April 2011 08:47, pmbauer wrote:
> Ivan,
> clojure/core use a different workflow than is typical for github
> projects.
> The github readme doesn't indicate, but you may find the process here:
>
> http://clojur
Ivan,
clojure/core use a different workflow than is typical for github
projects.
The github readme doesn't indicate, but you may find the process here:
http://clojure.org/contributing
http://clojure.org/patches
Cheers,
pm
On Apr 20, 1:44 am, Ivan Koblik wrote:
> Hello Konrad,
>
> Git workflow i
clojure/core use an alternative workflow to typical OSS on github, so
the eqqon link is not apropos.
The clojure github readme doesn't advertise the workflow, but you can
find it here:
http://clojure.org/contributing
http://clojure.org/patches
On Apr 20, 1:44 am, Ivan Koblik wrote:
> Hello Konra
On 20 Apr 2011, at 13:58, Stuart Halloway wrote:
There are several new top-level projects at https://github.com/
clojure to cover the various contrib libraries people have asked for.
Thanks!
I just pushed tools.macro to github. I'll wait a while to see if this
causes any catastrophes. If no
I'll bring over c.c.strint.
- Chas
On Apr 20, 2011, at 7:58 AM, Stuart Halloway wrote:
> There are several new top-level projects at https://github.com/clojure to
> cover the various contrib libraries people have asked for.
>
> Mapping to old contrib names is shown at
> http://dev.clojure.org
There are several new top-level projects at https://github.com/clojure to cover
the various contrib libraries people have asked for.
Mapping to old contrib names is shown at
http://dev.clojure.org/display/design/Contrib+Library+Names.
Stu
--
You received this message because you are subscribe
Hello Konrad,
Git workflow is a little bit different. You don't really need commit rights
to contribute. I found a rather nice explanation of Git workflow here:
http://www.eqqon.com/index.php/Collaborative_Github_Workflow
Hope it helps.
Cheers,
Ivan.
On 19 April 2011 16:40, Konrad Hinsen wrot
On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote:
>> Concerning my own modules in old contrib, there are three that I use myself
>> and that I am planning to maintain, independently of where they will end up:
>> - clojure.contrib.monads
>> - clojure.contrib.macro-utils
>> - clojure.contrib.gener
2011/4/19 Stuart Halloway :
> 2011/4/19 Stuart Halloway :
>
> Concerning my own modules in old contrib, there are three that I use myself
> and that I am planning to maintain, independently of where they will end up:
>
> - clojure.contrib.monads
>
> - clojure.contrib.macro-utils
>
> - clojure.contr
> 2011/4/19 Stuart Halloway :
>>> Concerning my own modules in old contrib, there are three that I use myself
>>> and that I am planning to maintain, independently of where they will end up:
>>> - clojure.contrib.monads
>>> - clojure.contrib.macro-utils
>>> - clojure.contrib.generic
>>
>> There i
2011/4/19 Stuart Halloway :
>> Concerning my own modules in old contrib, there are three that I use myself
>> and that I am planning to maintain, independently of where they will end up:
>> - clojure.contrib.monads
>> - clojure.contrib.macro-utils
>> - clojure.contrib.generic
>
> There is an empty
> Concerning my own modules in old contrib, there are three that I use myself
> and that I am planning to maintain, independently of where they will end up:
> - clojure.contrib.monads
> - clojure.contrib.macro-utils
> - clojure.contrib.generic
There is an empty repos already waiting for your macr
On 19 April 2011 08:25, Konrad Hinsen wrote:
> On 19 Apr 2011, at 03:02, Sean Corfield wrote:
>
>>> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
If nothing else is decided collectively, I'll maintain them as private
projects on Google Codes or Bitbucket.
>>
>> If they don't end
On Mon, Apr 18, 2011 at 11:25 PM, Konrad Hinsen
wrote:
> I'll try to see if I can manage to migrate to new contrib (I am not exactly
> looking forward to all those new tools to learn)
I hadn't needed to deal with maven until I tried to set up
clojure.java.jdbc - but that was the only piece I was
On 19 Apr 2011, at 02:15, Rich Hickey wrote:
The only criterion for migrating into new contrib is someone willing
to do the work of moving, and, subsequently, maintaining.
OK, thanks for the clarification!
Stuart Sierra has documented the process here:
http://dev.clojure.org/display/design
On 19 Apr 2011, at 03:02, Sean Corfield wrote:
On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
If nothing else is decided collectively, I'll maintain them as
private
projects on Google Codes or Bitbucket.
If they don't end up as part of the new lineup of contrib libraries,
would you at le
2011/4/19 Rich Hickey :
>
> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
>
>> On 18 Apr 2011, at 17:47, Laurent PETIT wrote:
>>
>>> The -?> and -?>> macros are currently inside "old", "soon to be
>>> deprecated" clojure contrib.
>>
>> I must confess that I don't even know what those macros do,
Rich,
Thanks for the feedback and righting some things for me. Can you
speak to the -?> and -?>> macros, specifically if you think nil should
be handled differently, or if these macros code find a new home in
core?
That said, I'd happily pitch in and help maintain a handful of the
contrib libs f
> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
>> If nothing else is decided collectively, I'll maintain them as private
>> projects on Google Codes or Bitbucket.
If they don't end up as part of the new lineup of contrib libraries,
would you at least keep them on github.com?
On Mon, Apr 18,
On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
On 18 Apr 2011, at 17:47, Laurent PETIT wrote:
The -?> and -?>> macros are currently inside "old", "soon to be
deprecated" clojure contrib.
I must confess that I don't even know what those macros do, so I
have no opinion.
However, I thin
+1 for Konrad's Monad library
sent from my mobile device
On Apr 18, 2011 9:19 PM, "Paul deGrandis" wrote:
> I very much like the -?> and -?>> macros and fine them pretty useful.
> I'd support their addition into core.
>
> Also, regarding Konrad's comment:
> I also find a lot of random one-off th
I very much like the -?> and -?>> macros and fine them pretty useful.
I'd support their addition into core.
Also, regarding Konrad's comment:
I also find a lot of random one-off things in old contrib that I think
are useful to use as well as to read through some of the source. I
think something l
On 18 Apr 2011, at 17:47, Laurent PETIT wrote:
The -?> and -?>> macros are currently inside "old", "soon to be
deprecated" clojure contrib.
I must confess that I don't even know what those macros do, so I have
no opinion.
However, I think the question of "what will happen to module
cloju
On Mon, Apr 18, 2011 at 9:33 AM, James Reeves wrote:
> I use it, and I think more people would use it if this were in core.
I only discovered them recently - they would certainly be more
discoverable in core and that would lead to greater use (so the
question then will be whether Clojure/core con
I use -?> quite often.
On Mon, Apr 18, 2011 at 11:47 AM, Laurent PETIT wrote:
> Hello,
>
> The -?> and -?>> macros are currently inside "old", "soon to be
> deprecated" clojure contrib.
>
> They have proven useful to me a number of times, and I personnally
> wouldn't see them stay in the soon "de
I definitely find them useful.
On Apr 18, 8:47 am, Laurent PETIT wrote:
> Hello,
>
> The -?> and -?>> macros are currently inside "old", "soon to be
> deprecated" clojure contrib.
>
> They have proven useful to me a number of times, and I personnally
> wouldn't see them stay in the soon "deprecat
On 18 April 2011 16:47, Laurent PETIT wrote:
> So the question is: do a sufficiently important number of other people
> use and want them as well ? If so, I may ask to the clojure-dev ml if
> and how and/or where we could move this macro so that it is still
> visible and `usable`.
I use it, and
Hi,
On Jun 1, 4:22 pm, Michael Jaaka wrote:
> Shouldn't the future block inherit by default the bindings of calling
> thread?
Asides from the question whether bindings should be inherited or not,
you can work around your trouble via bound-fn and future-call.
(future-call (bound-fn [] (do-stuff
57 matches
Mail list logo
