typo: try https://github.com/clojure/data.codec
On Oct 10, 6:31 pm, Alexander Taggart wrote:
> Base64 decoding support has been added.
>
> http://github.com/ataggart/clojure.data.codec
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
What about compared to the library I listed in the OP?
On Oct 10, 8:37 pm, Alexander Taggart wrote:
> I see about a 50% increased throughput over apache commons-codec as well. I
> use the perf-base64 ns generate input data and output timing files to keep
> track of changes to the performance ove
Base64 decoding support has been added.
http://github.com/ataggart/clojure.data.codec
--
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 - pleas
> What do the Clojure devs themselves do to keep their
> dev environment productive? Use ed and a raw repl
> running in two xterms? ;-) *)
Emacs inferior-lisp mode and Bash scripts. Not my first choice, but always
works.
-Stuart Sierra
clojure.com
--
You received this message because you are
I've already figured out how it works and have found the same 2:1
ratio. (This time on my 1.4GHz MacBook Air; The previous tests were on
a 2.4 GHz Core2Duo running Linux.)
When I did the quick-and-dirty benchmarking this afternoon I used
larger random inputs (1 to 8 MiB) allowing me to calculate a
I see about a 50% increased throughput over apache commons-codec as well. I
use the perf-base64 ns generate input data and output timing files to keep
track of changes to the performance over time, lest a regression creep in.
I'll add some documentation if you want to play with it.
--
You re
Cool!
I did some quick-and-dirty benchmarking of it this afternoon (GMT+2)
and got between 50 and 70 MiB/s on my machine. The Apache
implementation used for comparison by the unit tests came in at
between 30 and 40 MiB/s. Impressive.
I've since seen perf_base64.clj go in, though I'm not clear on
Cool! That would make a sweet example of "Clojure is fast at primitives."
-S
--
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 be patie
> On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote:
> Clojure unless somebody clever can make one that's actually *faster* than the
> best Java lib.
>
> Here ya go: https://github.com/ataggart/clojure.data.codec
I owe you a beer for the offset and length args. Thanks!
Stu
Stuart
On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote:
>
> Clojure unless somebody clever can make one that's actually *faster* than
> the best Java lib.
>
Here ya go: https://github.com/ataggart/clojure.data.codec
--
You received this message because you are subscribed to the Googl
The original clojure.contrib.base64 was little more than an exercise. This
is the kind of thing that Java libraries do well; don't see much point to
rewriting in Clojure unless somebody clever can make one that's actually
*faster* than the best Java lib.
-S
--
You received th
On 9 October 2011 20:13, Teemu Antti-Poika wrote:
> On Oct 9, 12:56 pm, Ray Miller wrote:
>> On 6 October 2011 19:38, Ray Miller wrote:
>> > Incidentally, I used the Apache Commons Base64 encoder, as the one in
>> > contrib was producing different results from the Apache Commons and
>> > Perl im
On Oct 9, 12:56 pm, Ray Miller wrote:
> On 6 October 2011 19:38, Ray Miller wrote:
> > Incidentally, I used the Apache Commons Base64 encoder, as the one in
> > contrib was producing different results from the Apache Commons and
> > Perl implementations. Perhaps a bug?
>
> ...
> This string diffe
curity.MessageDigest to give me the
MD5 digest as a byte array. When I transform this to base64 using the
Apache Commons library, I get the same result as above. But when I try
to do it with clojure.contrib.base64, I get a slightly different
string. It's quite possible I've misunderstood
> Sure, I'll start working on it. Do you want it to be worked on in a contrib
> project or just submit it once it's functional?
Whatever works best for you.
> Also, I assume you'd want this to work with 1.2, right?
I won't personally need that. Plus, this is the kind of lib where the code
w
Sure, I'll start working on it. Do you want it to be worked on in a contrib
project or just submit it once it's functional? Also, I assume you'd want
this to work with 1.2, right?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this gro
> I threw a base64 encoder together a while ago when playing with the new
> primitive stuff. Interesting to note that it is faster than the one in
> Apache commons-codec.
>
> https://github.com/ataggart/codec/blob/master/src/codec/base64.clj
Do you want to make this the basis for an improved c
On 6 October 2011 18:27, Aaron Bedra wrote:
> This actually introduces an opportunity for a much larger set of utilities.
>
> clojure.data.crypto
>
> base64 is part of this idea anyways, and putting it in place along with
> nice wrappers around the messy java crypto bits I think could provide a
>
I threw a base64 encoder together a while ago when playing with the new
primitive stuff. Interesting to note that it is faster than the one in
Apache commons-codec.
https://github.com/ataggart/codec/blob/master/src/codec/base64.clj
--
You received this message because you are subscribed to th
Sure, I can use that file. This DIY attitude doesn't benefit the
beginners. I can add and use that java, but 90% of clojure users will
use the clojure contrib function and 9% will use faster sun encoder,
because people don't know that Sun's implementations are slow and that
better ones are availabl
Just wanted to add the Apache commons codec has a base64
encoder/decoder. With a quick test I was able to encode a ~100MB file
in 2.3sec. Example code below:
In leiningen: [commons-codec "1.4"]
(require '[clojure.java.io :as io])
(import '[org.apache.commons.codec.binary Base64OutputStream])
(de
This actually introduces an opportunity for a much larger set of utilities.
clojure.data.crypto
base64 is part of this idea anyways, and putting it in place along with
nice wrappers around the messy java crypto bits I think could provide a
significant win. I have had to do this several times now
On Oct 6, 2011, at 4:44 AM, Jonathan Fischer Friberg wrote:
> thus enable all Clojure developers to have lightning
> fast Base64 encoding/decoding?
>
> This is already possible, if you're using leiningen:
> put the file in src/util/ and compile, you can now call it as usual.
I've used the sun.m
> I use Base64 encoding a lot and the slow implementation is hurting a
> lot. It's slower than Sun misc encoder/decoder
> and that one is very very slow. I was using Sun's implementation a bit
> and it took 80 seconds to encode a 56 MB file.
> Then I found this: http://migbase64.sourceforge.net/
>
Hi,
may I ask an heretic question?
When there is a fast migbase64... why not just use that one?
It was always promoted to use existing Java libraries where it made sense.
Or is clojurescript now changing this stance?
Sincerely
Meikel
--
You received this message because you are subscribed t
>
> thus enable all Clojure developers to have lightning
> fast Base64 encoding/decoding?
>
This is already possible, if you're using leiningen:
put the file in src/util/ and compile, you can now call it as usual.
On Thu, Oct 6, 2011 at 11:16 AM, Rok Lenarcic wrote:
> I use Base64 encoding a lot
I use Base64 encoding a lot and the slow implementation is hurting a
lot. It's slower than Sun misc encoder/decoder
and that one is very very slow. I was using Sun's implementation a bit
and it took 80 seconds to encode a 56 MB file.
Then I found this: http://migbase64.sourceforge.net/
It loaded fr
27 matches
Mail list logo
