The go block itself (and thus any call to walker) returns a channel. This
value is indeed thrown away; its utility lies entirely in the fact that the
caller had to wait for it. All of the actual values from the tree are
written to the supplied channel 'ch', and the ultimate caller of this
function
For this value please read the value taken from this channel.
On Sep 14, 2013 12:21 AM, Alan Shaw noden...@gmail.com wrote:
The go block itself (and thus any call to walker) returns a channel. This
value is indeed thrown away; its utility lies entirely in the fact that the
caller had to wait
Timothy, thanks,for giving a thorough answer to my questions, I appreciate
this! As far as I understood, you did some work for Clojure team, and you
have the necessary knowledge to express a knowing opinion on what are the
implications of the matter. That was one of the things I wanted to know
7) Maybe genclass and stuff can still get away as it is now, falling back
to boxing and reduced number of types? Or special genclass metadata hints
be introduced? Still, not everyone will use that. But those who will, could
spare a couple more hints to the compiler..
--
--
You received this
Hello,
Consider the following problem:
(def v [1 2 3])
(def l '(4 5 6))
; we need to apply in sequence
; `v - (func v e)`,
; where `e` goes over elements of the list `l`
(def new-v (apply-from-list func v l))
For example, if `(def func conj)`, then the value of `new-v` is `[1 2 3 4 5
6]`.
Why not just (reduce func v l)?
On Sat, Sep 14, 2013 at 8:12 AM, Bogdan Opanchuk manti...@gmail.com wrote:
Hello,
Consider the following problem:
(def v [1 2 3])
(def l '(4 5 6))
; we need to apply in sequence
; `v - (func v e)`,
; where `e` goes over elements of the list `l`
(def
Hi Cedric,
Thanks, I'm feeling really silly now... I should have thought about folds
the first second after encountering this :)
--
--
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
If you're working with large text files, tsv especially, you may encounter
Java's memory overhead for Strings as well.
I remember parsing a 1GB TSV file into EDN, and watching it consume 10GB of
RAM.
I'd recommend taking a look at the Iota library to see if it would be of
any help to you,
Hi,
I'm just watching some videos from Clojure/conj 2012 and would like to
peruse the slides, but I haven't found a download anywhere on the Internet.
Does somebody here have them?
Any help will be much appreciated.
--
--
You received this message because you are subscribed to the Google
Very interesting. Thanks.
On Saturday, September 14, 2013 5:48:57 AM UTC-7, TheBusby wrote:
If you're working with large text files, tsv especially, you may encounter
Java's memory overhead for Strings as well.
I remember parsing a 1GB TSV file into EDN, and watching it consume 10GB
of
Excuse me, when I said Vertex3f I meant Vector3f.
суббота, 14 сентября 2013 г., 15:14:01 UTC+4 пользователь Alex Fowler
написал:
Timothy, thanks,for giving a thorough answer to my questions, I appreciate
this! As far as I understood, you did some work for Clojure team, and you
have the
1) Clojure is said to be data-oriented.
Well it is, it's just that your definition of data is radically different
from the normal business use case. In the line of work I'm in, big data
is millions of hash maps filled with heterogeneous data types. In these
cases, Clojure really shines.
2)
On 14 September 2013 12:14, Alex Fowler alex.murat...@gmail.com wrote:
Timothy, thanks,for giving a thorough answer to my questions, I appreciate
this! As far as I understood, you did some work for Clojure team, and you
have the necessary knowledge to express a knowing opinion on what are the
+1 on all the answers from Timothy to these items
Been working with Clojure for 5 years by now handling huge data loads
in real time. You want to get lean and mean performance in specific
areas then thunk down to Java or native libs.
We never had to do from Clojure btwy, there's been always an
Hello all,
I am developing an application and I use core.async to push data from
multiple threads within an infinite
(go (while true
(let [data (! @my-channel)
do processing here...))
in order to be processed.
I keep my channel inside an atom defined at the start of my app.
If an
I am developing an application and I use core.async to push data from
multiple threads within an infinite
(go (while true
(let [data (! @my-channel)
(do processing here...)))
in order to be processed. As you probably already figured out, I store my
channel inside an atom defined at
Hi all,
This follows a previous post I made (see
herehttps://groups.google.com/forum/#!searchin/clojure/stefon/clojure/rCmPYa0Vw-4/XZx1CIaoEB4J).
I was looking for a simple, Clojure-based blog engine that allowed me to
stitch together components on an as needed basis.
I didn't find one. And to
Each Contributor must identify itself as the originator of its Contribution,
if any, in a manner that reasonably allows subsequent Recipients to identify
the originator of the Contribution.
That's my problem.
On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:
On Sat, Sep 14, 2013 at 5:31 PM, Musical Notation
musicdenotat...@gmail.com wrote:
Each Contributor must identify itself as the originator of its Contribution,
if any, in a manner that reasonably allows subsequent Recipients to identify
the originator of the Contribution.
That's my problem.
Perhaps a bit intense but this problem might lend itself to mixed integer
linear programming. MILP is a very broad formulation of optimization
problems. Optimal solution of MILP problems is NP-Hard but very mature
software solutions exist. I don't know what's out there in Clojure land
for
Hi,
I put up a screenshot and a it now will show a little bit of unimportant
stacktrace near the important stuff. Please let me know if you have any
more ideas.
thanks,
Jake
On Friday, September 13, 2013 12:21:00 PM UTC-6, Christopher Allen wrote:
Link:
Hi,
I put up a screenshot and a it now will show a little bit of unimportant
stacktrace near the important stuff. Please let me know if you have any
more ideas. Bump your version to 0.2.2.
thanks,
Jake
On Friday, September 13, 2013 12:21:00 PM UTC-6, Christopher Allen wrote:
Link:
You know you're a lisp programmer when you feel conflicted about balancing
parentheses around emoticons. (like this :)) (or like this :)
- Korny
On 13 Sep 2013 12:35, Cedric Greevey cgree...@gmail.com wrote:
On Thu, Sep 12, 2013 at 2:47 PM, Mimmo Cosenza mimmo.cose...@gmail.comwrote:
Hi All,
On Saturday, 14 September 2013 01:04:16 UTC+8, tbc++ wrote:
This would be better, IMHO, than forever accepting semantics that
prevent idiomatic code from ever being truly fast.
You're going to have a hard time convincing people to give up some of
the dynamism of Clojure just for the sake
24 matches
Mail list logo