>
> Dynamical languages are above all oriented toward practical programming
> needs *in certain contexts*--in other contexts, static typing is more
> practical.
>
Agreed -- which is why I find your speculation about "lightening up" with
"more experience ... meeting the demands of practical cod
producing it next week.
>
>
> Marc
>
> On Wed, Jan 23, 2013 at 11:24 AM, Mark Hamstra
>
> > wrote:
>
>> I certainly understand the exploration and learning motivation -- I did
>> much the same thing. At this point, I wouldn't consider either of
t class name (e.g. fn_123).
> There is high likelihood that the name assigned on the master is not the
> same as the name on the task JVMs, so you wind up with a
> ClassNotFoundException.
>
> I don't know why this would work for you. If you have any insight on
> this, I wo
Hmmm... a lot of duplicated work. Sorry I didn't get my stuff in a more
usable form for you, but I wasn't aware that anybody was even interested in
it. I've got some stuff that I want to rework a little, and I'm still
thinking through the best way to integrate with the new reducers code in
Cl
Yup, something like that is gonna work.
Thanks!
On Tuesday, September 4, 2012 2:34:27 PM UTC-7, Mark Hamstra wrote:
>
> So I'm working on developing a Clojure api for a distributed data analysis
> framework. A key part of that has to be the ability to pass functions as
>
So I'm working on developing a Clojure api for a distributed data analysis
framework. A key part of that has to be the ability to pass functions as
parameters into various map, reduce, filter, groupBy, etc. functions.
Since this a framework developed in Scala, these function parameters
eventu
"Clojed-form" implementations (vs. "cludged-form") is probably too cute by
half
--
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
s/Clojure/Closure/
On Jul 26, 7:35 pm, Mark Hamstra wrote:
> ...and Clojure Inspector itself only works with out-of-date versions
> of Firefox and Firebug.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
...and Clojure Inspector itself only works with out-of-date versions
of Firefox and Firebug.
--
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 -
It would seem that a solution to this problem would be to treat such
automatic boxing/upcasting similar to reflection -- i.e., have an
option that causes Clojure to spit out a warning when such boxing/
upcasting occurs, alerting the performance conscious of the need to
change the code that is gener
My results are actually worse. I get about a 40x slowdown, going from
~50ms in 1.2.0 to ~2000ms in 1.3.0-alpha2.
On Oct 29, 12:41 pm, Btsai wrote:
> Could someone else also try the sample code I included to see if they
> also experience the same ~10x slowdown for (count (filter ...)) in 1.3
> A
The context of the comment is functional programming vs. OO
programming. Pure functions compose better than do state-containing
objects, and 100! is much larger than 10!, so you have many more
options for composition/reuse with 100 functions that operate on a
single data abstraction.
On Sep 3, 2:
On May 6, 10:46 pm, MarkSwanson wrote:
> > or as-str from c.c.java-utils (I think)
>
> Good one. It's in string.clj in the latest git.
It looks like identical code for as-str is in both java_utils.clj and
string.clj
Is there a good reason for this duplication?
--
You received this message beca
On Apr 29, 2:17 am, Mark Engelberg wrote:
> On Wed, Apr 28, 2010 at 10:49 PM, Douglas Philips wrote:
> > What is the purpose, goal, design-rationale of not making seq-contains? fast
> > on maps or sets?
>
> I think Rich's point is that if seq-contains? is sometimes fast and
> sometimes slow, th
Try Rich's commit 1b8d5001ba094053b24c55829994785be422cfbf
For me, he's fixed the build problem.
--
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 moderat
Craig,
I enjoyed you presentations, but I have a bit of a tangent question.
I'm still new to slime, so it's not a comfortable environment for me
yet. What I am wondering is how exactly, when operating with the
split code and repl buffers, you are getting code buffer expressions
to evaluate in the
You're not alone. I see the very same thing.
Quad core, Ubuntu 10.04, Linux 2.6.32-21-generic
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
--
You received this message because you are subscribed to
Does "from scratch" assume Slime is already installed?
On Jan 18, 4:42 pm, Brent Millare wrote:
> I made a write up of my experiences setting up swank-clojure from
> scratch. Although my method ignores matching the versions up because
> all is built from the current sources (which can potential
See *print-length* and *print-level* in the core API.
On Jan 18, 4:22 pm, Raoul Duke wrote:
> hi,
>
> hmmm, i wish there were a way (or that it was the default) to tell the
> repl to not continue to loop for ever over things it has already
> "printed" out when i eval something that is a cyclic t
19 matches
Mail list logo
