On 06/14/2012 07:32 PM, Anurag Mendhekar wrote:
This, along with other complexities in the standard, cause h264 code to
be mostly hideous, although video coding is based on very elegant
mathematics. One of my goals of doing this in Scheme is to bring that
elegance into real implementations.
(OK,
At Thu, 14 Jun 2012 17:12:05 -0700 (PDT),
Anurag Mendhekar wrote:
> 2. Typed racket is also something we will explore. Are there any
> benchmarks out there for typed v. untyped racket?
Our PLDI 2011 paper has benchmark results:
http://www.ccs.neu.edu/racket/pubs/pldi11-thacff.pdf
We've continued
Mendhekar
Cc: "users@racket-lang.org" ; Eli Barzilay
Sent: Thursday, June 14, 2012 5:18 PM
Subject: Re: [racket] H264 Codec in Racket
Tony Garnock Jones has some bit comprehension libraries on planet I believe.
On Jun 14, 2012, at 8:12 PM, Anurag Mendhekar wrote:
>
>Thanks
t we can move
> back-and-forth between typed and untyped racket.
>
> Best,
>
> A.
> From: Eli Barzilay
> To: Anurag Mendhekar
> Cc: "users@racket-lang.org"
> Sent: Thursday, June 14, 2012 7:26 AM
> Subject: Re: [racket] H264 Codec in Racket
>
> Mor
rsday, June 14, 2012 7:26 AM
Subject: Re: [racket] H264 Codec in Racket
More than a week ago, Anurag Mendhekar wrote:
> I'm considering writing an H.264 encoder/decoder in Racket. Has
> anyone tried such a thing before?
>
> Codecs require a lot of bit-whacking and the h264
On Jun 14, 2012, at 2:22 PM, Petr Samarin wrote:
> On Jun 14, 2012, at 4:26 PM, Eli Barzilay wrote:
>> Racket has the advantage of
>> macros, which can often be used in such bit-whacking (nice term)
>> situations. It can be used to easily pre-generate some code that
>> would otherwise be too com
10 minutes ago, Petr Samarin wrote:
> On Jun 14, 2012, at 4:26 PM, Eli Barzilay wrote:
>
> Racket has the advantage of macros, which can often be used in
> such bit-whacking (nice term) situations. It can be used to
> easily pre-generate some code that would otherwise be too
> com
On Jun 14, 2012, at 4:26 PM, Eli Barzilay wrote:
> Racket has the advantage of
> macros, which can often be used in such bit-whacking (nice term)
> situations. It can be used to easily pre-generate some code that
> would otherwise be too complicated to write.
Can you point to some example where R
More than a week ago, Anurag Mendhekar wrote:
> I'm considering writing an H.264 encoder/decoder in Racket. Has
> anyone tried such a thing before?
>
> Codecs require a lot of bit-whacking and the h264 standard is
> particularly convoluted. Efficiencies are obtained in C in many
> different and us
On Thu, Jun 7, 2012 at 8:31 PM, Robby Findler
wrote:
> On Thu, Jun 7, 2012 at 6:27 PM, Neil Toronto wrote:
>>> Also, if the algorithms are parallel, you might consider using futures.
>>
>>
>> Good idea. I wonder if anyone has investigated whether it's significantly
>> easier to use futures effect
On Thu, Jun 7, 2012 at 5:31 PM, wrote:
> James is working on a visualizer that will help understand the
> peculiarities of futures and I hope it'll be in a pushable state in
> not too long.
For correct programs, the visualizer will allow one to say
"I have seen your futures, and they work!"
On Thu, Jun 7, 2012 at 6:27 PM, Neil Toronto wrote:
>> Also, if the algorithms are parallel, you might consider using futures.
>
>
> Good idea. I wonder if anyone has investigated whether it's significantly
> easier to use futures effectively in Typed Racket. Its optimizations are
> designed to av
On 06/07/2012 04:29 PM, Robby Findler wrote:
Why not use bytes?
Even if you try to just use bytes, you end up using fixnums:
> (fixnum? (bytes-ref (bytes 0 1 2 3) 3))
#t
What I mean is there's no way to operate on a data type that's exactly 8
bits wide. (Unless you can use the FFI for that,
Why not use bytes?
Also, if the algorithms are parallel, you might consider using futures.
Robby
On Thu, Jun 7, 2012 at 4:25 PM, Neil Toronto wrote:
> On 06/06/2012 03:21 PM, Anurag Mendhekar wrote:
>>
>>
>> I'm considering writing an H.264 encoder/decoder in Racket. Has anyone
>> tried such a
On 06/06/2012 03:21 PM, Anurag Mendhekar wrote:
I'm considering writing an H.264 encoder/decoder in Racket. Has anyone
tried such a thing before?
Codecs require a lot of bit-whacking and the h264 standard is
particularly convoluted. Efficiencies are obtained in C in many
different and usually c
I'm considering writing an H.264 encoder/decoder in Racket. Has anyone tried
such a thing before?
Codecs require a lot of bit-whacking and the h264 standard is particularly
convoluted. Efficiencies are obtained in C in many different and usually
complex ways. Codec experts usually recommend
16 matches
Mail list logo
