On Mon, Dec 17, 2012 at 9:34 PM, Matthias Felleisen
wrote:
> Okay. I propose we figure out how to allow people programming in Typed Racket,
> and deploy two copies of the code without performance overhead for either T
> or U
> code.
I don't see how we can do this without violating the integrity
On Mon, Dec 17, 2012 at 4:09 PM, Matthew Flatt wrote:
> At Mon, 17 Dec 2012 15:51:38 -0500, Sam Tobin-Hochstadt wrote:
>> On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler
>> wrote:
>> > I've long thought something along these lines is a good idea, but perhaps
>> > what I think is a good idea isn't
I am willing to check the type and to strip the types from the source then.
Meaning:
1. the programer gets only one kind of reassurance, namely, that the module's
type specs are internally consistent
2. the generated untyped file is like any other untyped module in the code
base.
On
How hard would it be to allow flvectors to be passed to foreign
functions as double pointers?
BLAS and LAPACK linear algebra functions primarily accept pointers to
floating-point arrays in row-major order. If we could send flvectors
directly (or at least pointers to their elements), we could r
`flvector->cpointer'?
At Thu, 20 Dec 2012 19:17:13 -0700, Neil Toronto wrote:
> How hard would it be to allow flvectors to be passed to foreign
> functions as double pointers?
>
> BLAS and LAPACK linear algebra functions primarily accept pointers to
> floating-point arrays in row-major order. I
Put the time machine away, Matthew. You're not fooling anybody.
Thanks. :D
On 12/20/2012 07:33 PM, Matthew Flatt wrote:
`flvector->cpointer'?
At Thu, 20 Dec 2012 19:17:13 -0700, Neil Toronto wrote:
How hard would it be to allow flvectors to be passed to foreign
functions as double pointers?
6 matches
Mail list logo
