2010/12/16 Sunil S Nandihalli
> double-dispatch in clojure .. thats neat... Thanks Stuart.
Really, that's "double-dispatch with protocols", 'cause
double-triple-whatever-dispatch on anything you know 'bout the function
arguments is solved since the introduction of multimethods.
Cheers,
--
La
Indeed !
I was stuck in the macro thinking, thanks for getting us out of it !
And then this solution not only works for literal strings:
user=> (foo (str "yo" "man"))
#'user/yoman
user=> yoman
"yoman"
user=>
2010/12/16 Robert McIntyre
> no need to use macros at all:
>
> (defn foo
> "creates
my bad .. thats what I meant..:)
On Thu, Dec 16, 2010 at 2:10 PM, Laurent PETIT wrote:
> 2010/12/16 Sunil S Nandihalli
>
> double-dispatch in clojure .. thats neat... Thanks Stuart.
>
>
> Really, that's "double-dispatch with protocols", 'cause
> double-triple-whatever-dispatch on anything you kn
Hi,
Am 16.12.2010 um 04:16 schrieb Nicolas Buduroi:
> So we could always use RT/classForName to detect what classes are
> available. Do you think the extend-type thrown exception can possibly
> be fixed or is it a fundamental limitation?
I think the problem here is „when“ not „where.“ The „exten
Laurent and Robert,
Thank you all.
On Thu, Dec 16, 2010 at 9:44 AM, Laurent PETIT wrote:
> Indeed !
>
> I was stuck in the macro thinking, thanks for getting us out of it !
>
> And then this solution not only works for literal strings:
>
> user=> (foo (str "yo" "man"))
> #'user/yoman
> user=> y
> Worse, from the sounds of it the new + isn't exactly the old
> unchecked-+; it still checks for overflow rather than allowing
> wrapping. That's going to add a compare-and-branch to every add
> instruction and halve the speed of those operators on typical
> hardware. Compare-and-throw-exception i
> On Tue, Dec 14, 2010 at 9:56 PM, David Nolen wrote:
>> On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote:
>>>
>>> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
As Brian said, primitive math is now the default in 1.3. If auto-
promotion on overflow is desired, you can use the +
> In practice, I haven't seen a significant speed improvement in the new branch
> of Clojure (except on specific benchmarks that intentionally test Clojure's
> new default primitive math). In my day-to-day code, all my numbers, despite
> being perfectly small enough to fit in a long, end up get
Hi all,
Are there any plans to move in the direction John Rose is talking about here? I
guess the timeframe would depend on when this tech makes it into production
branches, but is it on the radar at least?
http://blogs.sun.com/jrose/entry/scheme_in_one_class
Regards,
Robbie
--
You rec
In general you should prefer doseq because it doesn't hold on to the head,
correct?
Sent from my iPhone
On Dec 15, 2010, at 5:14 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 15.12.2010 um 19:54 schrieb Brian Marick:
>
>> (See also #'dorun.)
>
> Argh. See also doseq.
>
> Sincerely
> Meikel
>
Hi,
Am 16.12.2010 um 14:50 schrieb Jay Fields:
> In general you should prefer doseq because it doesn't hold on to the head,
> correct?
dorun does the same. But it constructs a lazy sequence of return values which
is thrown away immediately. This is very ugly and wasteful. Doing some
microbenc
Certainly on the radar. But not usable until it's available in the majority
of production JDKs out there. Java moves slowly; even Clojure's dependence
on 1.5 has been a blocker for some folks.
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Grou
Thank you for sharing Midje with us. I too would like to hear how it
relates to clojure.test.
--
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 moderate
On Dec 16, 2010, at 12:21 AM, Shantanu Kumar wrote:
> 1. Is there any example app that demonstrates how to use Midje?
The introduction to the basic feature set is here:
https://github.com/marick/Midje/blob/master/examples/sweet-examples/basic/test/basic/core_test.clj
As a simple example, I conve
Cool, that explain everything. Thanks
On Dec 16, 4:40 am, Meikel Brandmeyer wrote:
> Hi,
>
> Am 16.12.2010 um 04:16 schrieb Nicolas Buduroi:
>
> > So we could always use RT/classForName to detect what classes are
> > available. Do you think the extend-type thrown exception can possibly
> > be fix
On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway
wrote:
>> Worse, from the sounds of it the new + isn't exactly the old
>> unchecked-+; it still checks for overflow rather than allowing
>> wrapping. That's going to add a compare-and-branch to every add
>> instruction and halve the speed of those o
On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
wrote:
> I wrote:
>> Breaking source compatibility with just about every single preexisting
>> line of Clojure code out there is supposed to make our lives *easier*?
>> I'd dearly love to know how -- my cousin is a stage magician and he's
>> always
> The
> common case is test and accept the result, returning it, in both
> cases; so the common case should have comparable execution speed given
> both implementations. If not, something is wrong someplace else with
> at least one of the implementations (or, much less likely, with the
> JVM/JIT).
On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson wrote:
> On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway
> wrote:
> >> Worse, from the sounds of it the new + isn't exactly the old
> >> unchecked-+; it still checks for overflow rather than allowing
> >> wrapping. That's going to add a compare-and-b
On Dec 16, 2010, at 12:21 AM, Shantanu Kumar wrote:
> 2. Why would I use Midje instead of clojure.test?
Oh, one other thing: you can mix and match Midje and Clojure.test tests. Midje
uses the clojure.test reporting mechanism. You can start adding Midje tests to
your existing test files and c
> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
> wrote:
>> I wrote:
>>> Breaking source compatibility with just about every single preexisting
>>> line of Clojure code out there is supposed to make our lives *easier*?
>>> I'd dearly love to know how -- my cousin is a stage magician and he's
>>
On Thu, Dec 16, 2010 at 11:36 AM, David Nolen wrote:
> On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson wrote:
>>
>> On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway
>> wrote:
>> >> Worse, from the sounds of it the new + isn't exactly the old
>> >> unchecked-+; it still checks for overflow rather th
On Thu, Dec 16, 2010 at 12:04 PM, Stuart Halloway
wrote:
> I wrote:
>> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
>> wrote:
>>> I wrote:
Breaking source compatibility with just about every single preexisting
line of Clojure code out there is supposed to make our lives *easier*?
>>
>>> Worse, from the sounds of it the new + isn't exactly the old
>>> unchecked-+; it still checks for overflow rather than allowing
>>> wrapping. That's going to add a compare-and-branch to every add
>>> instruction and halve the speed of those operators on typical
>>> hardware. Compare-and-throw-e
>
> The overflow check is the same whether you react to an overflow by
> boxing the result or react to an overflow by throwing an exception!
But then all the rest of the code has to check whether things are boxed or not.
Moreover, the JVM makes it very hard (impossible) to manipulate
something th
*begin rant*
I have yet to see anyone who posts the classic "rtfm" (even politely)
response search previous posts and realize that "rtfm" responses have
already been sent and refrain from sending the same explanation of how
to use a mailing list over and over and over. Simple customer service
>> It takes almost zero time to offer opinions without bothering to check.
>
> That looks like yet another unproductive, non-constructive personal criticism.
Why do you think so? These people are just requesting you to check
things for yourself instead engaging in this meaningless argument. The
de
Hello,
I'm trying to insert in a database large number of records, however
it's not scaling correctly. For 100 records it takes 10 seconds, for
100 records it takes 2 min to save. But for 250 records it
throws Java Heap out of memory exception.
I've tried separting the records processing
On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson wrote:
> The overflow check is the same whether you react to an overflow by
> boxing the result or react to an overflow by throwing an exception!
>
It's not the same at all.
If you box the result all further arithmetic computations slows down. You
ca
On Thu, Dec 16, 2010 at 12:13 PM, Stuart Halloway
wrote:
Worse, from the sounds of it the new + isn't exactly the old
unchecked-+; it still checks for overflow rather than allowing
wrapping. That's going to add a compare-and-branch to every add
instruction and halve the speed o
On Thu, Dec 16, 2010 at 12:14 PM, nicolas.o...@gmail.com
wrote:
>>
>> The overflow check is the same whether you react to an overflow by
>> boxing the result or react to an overflow by throwing an exception!
>
> But then all the rest of the code has to check whether things are boxed or
> not.
> M
On Dec 16, 2010, at 11:19 AM, Ken Wesson wrote:
> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
> wrote:
>> I wrote:
>>> Breaking source compatibility with just about every single preexisting
>>> line of Clojure code out there is supposed to make our lives *easier*?
>>> I'd dearly love to kno
On Thu, Dec 16, 2010 at 12:22 PM, Baishampayan Ghose wrote:
>>> It takes almost zero time to offer opinions without bothering to check.
>>
>> That looks like yet another unproductive, non-constructive personal
>> criticism.
>
> Why do you think so?
Because of the implication that my opinions are
On Thu, Dec 16, 2010 at 12:24 PM, David Nolen wrote:
> On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson wrote:
>>
>> The overflow check is the same whether you react to an overflow by
>> boxing the result or react to an overflow by throwing an exception!
>
> It's not the same at all.
> If you box the
>> yet you are accusing people of criticizing you just because they feel you
>> should do a bit more
>> research about this.
>
> I'm asking them to explain themselves better, and their responses are
> not any kind of explanation.
Please try putting yourself in their shoes. They have already
expla
On Thu, Dec 16, 2010 at 1:06 PM, Ken Wesson wrote:
> I don't know how common dynamic binding is in application code. It
> tends to be in library code more often, which is a smaller number of
> changes to make. Plus, the dynamic binding changes have a rationale
> behind them that actually seems to
> wrote:
> Worse, from the sounds of it the new + isn't exactly the old
> unchecked-+; it still checks for overflow rather than allowing
> wrapping. That's going to add a compare-and-branch to every add
> instruction and halve the speed of those operators on typical
> hardware.
On Thu, Dec 16, 2010 at 1:15 PM, Baishampayan Ghose wrote:
>>> yet you are accusing people of criticizing you just because they feel you
>>> should do a bit more
>>> research about this.
>>
>> I'm asking them to explain themselves better, and their responses are
>> not any kind of explanation.
>
You might be coming to near OOM with using in-memory processing but
don't know it, and the batched (lazy) version is probably holding onto
data creating the mem leak. Would you be able to post the relevant
source?
--
You received this message because you are subscribed to the Google
Groups "Cloj
I'm trying to use << from clojure.contrib.strint perform string
interpolation in a string variable. The following,
(ns strint-test (:use clojure.contrib.strint))
(def v 1)
(println (<< "v: ~{v}"))
(def s "v: ~{v}")
(println (<< (str s)))
(println (<< s))
results in
v: 1
v: ~{v}
java.lang.Runt
On Thu, 16 Dec 2010 10:18:47 -0700
Terrance Davis wrote:
> *begin rant*
>
> I have yet to see anyone who posts the classic "rtfm" (even politely)
> response search previous posts and realize that "rtfm" responses have
> already been sent and refrain from sending the same explanation of how
>
>
> I was wondering if anyone has been working
> on implementing a bit syntax for Clojure in the rough conceptual style
> of Erlang's bit syntax.
>
I'm not an erlang-pro, just dabbled enough to know I like the pattern
matching, which is what you're talking about here, I believe.
> I'm looking fo
On Thu, Dec 16, 2010 at 2:56 PM, Michael wrote:
>
> I'm trying to use << from clojure.contrib.strint perform string
> interpolation in a string variable. The following,
>
> (ns strint-test (:use clojure.contrib.strint))
>
> (def v 1)
> (println (<< "v: ~{v}"))
>
> (def s "v: ~{v}")
> (println (<<
> On Thu, 16 Dec 2010 10:18:47 -0700
> Terrance Davis wrote:
>
>> *begin rant*
>>
>> I have yet to see anyone who posts the classic "rtfm" (even politely)
>> response search previous posts and realize that "rtfm" responses have
>> already been sent and refrain from sending the same explanation
The only things I know that Gloss lacks relative to Erlang's
functionality is arbitrary bit-lengths for integers and mixed-endian
support, both of which I plan to add in the near future. Lacking
Erlang's built in pattern matching, the Clojure implementation will
probably be less elegant in some ca
On Thu, Dec 16, 2010 at 6:01 PM, Zach Tellman wrote:
> The only things I know that Gloss lacks relative to Erlang's
> functionality is arbitrary bit-lengths for integers and mixed-endian
> support, both of which I plan to add in the near future. Lacking
> Erlang's built in pattern matching, the C
On Thu, 16 Dec 2010 17:50:58 -0500
Stuart Halloway wrote:
> > On Thu, 16 Dec 2010 10:18:47 -0700
> > Terrance Davis wrote:
> >
> >> *begin rant*
> >>
> >> I have yet to see anyone who posts the classic "rtfm" (even politely)
> >> response search previous posts and realize that "rtfm" response
Hi Daniel,
I'm fairly certain this is not exactly what you're looking for, but
it's somewhat related and it might give you a fuller image -- my
tiny clj-bitfields library:
https://github.com/nathell/clj-bitfields
Best,
Daniel Janus
--
You received this message because you are subscribed to t
On Thu, Dec 16, 2010 at 09:19, clj123 wrote:
> Hello,
>
> I'm trying to insert in a database large number of records, however
> it's not scaling correctly. For 100 records it takes 10 seconds, for
> 100 records it takes 2 min to save. But for 250 records it
> throws Java Heap out of memor
Michael writes:
> I'm trying to use << from clojure.contrib.strint perform string
> interpolation in a string variable. The following,
> (def s "v: ~{v}")
> (println (<< (str s)))
> (println (<< s))
This is not going to be possible (at least not efficiently: you could
technically do itwith &en
50 matches
Mail list logo
