Yes, you right.
Definitely both atom and dynamic is too much, the idea is to set once for
the whole section at the very start, given anyway the possibility to change
it by bindig when it is necessary...
I guess that i should use only dynamic... but i got some problem changing
the var...
I shoul
> I am unsure about the atom of api-key, in theory i won't need to change my
> api-key, but idk... You can get a lot of api-key gratis which are a little
> limited or just one payed api-key that can do everything...
My point was that once you've declared api-key {:dynamic true} (which
by the way i
Yep, i changed it in futures...
I am unsure about the atom of api-key, in theory i won't need to change my
api-key, but idk... You can get a lot of api-key gratis which are a little
limited or just one payed api-key that can do everything...
Il giorno giovedì 24 maggio 2012 00:56:25 UTC-5, Ulis
> Looking the code again I believe that I should use a future and not an
> agent...
> I am right ???
I would think so. AFAIK, the advice has always been "if you need to do
some computation on another thread don't (ab)use agents, use futures".
Additionally, you have[1]:
(def #^{:dynamic true} *ap
Looking the code again I believe that I should use a future and not an
agent...
I am right ???
Il giorno martedì 22 maggio 2012 16:10:58 UTC-5, Simone Mosciatti ha
scritto:
>
> Hi everybody,
>
> I have release a library to query the echonest[1][2] API.
> This is my very first job so I'm looking
Hi everybody,
I have release a library to query the echonest[1][2] API.
This is my very first job so I'm looking for feedback, especially about how
to manage some basic configuration[3] and how introduce asynchronously
agent[4]...
I am very happy to have finished this job...
Please contact me
