Jarrett Billingsley wrote:
On Tue, Feb 24, 2009 at 10:42 PM, Daniel Keep
wrote:
You missed the array literal.
I saw that, but thought that it would be a short[] literal since it's
usually the type of the first argument.
Odd, it works. And properly too.
Could it be because of integer promo
On Tue, Feb 24, 2009 at 10:42 PM, Daniel Keep
wrote:
>>
>> You missed the array literal.
>
> I saw that, but thought that it would be a short[] literal since it's
> usually the type of the first argument.
Odd, it works. And properly too.
I give up on trying to figure out what the compiler does
Jarrett Billingsley wrote:
> On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
> wrote:
>
>> Yup.
>>
>> It's a pity that we don't have, oh I don't know, some sort of efficient
>> iterable interface that doesn't cause a heap allocation that the runtime
>> could use instead *cough*hint*cough*andrei*co
Jarrett Billingsley wrote:
> On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep
> wrote:
>
>> Maybe it's because I just woke up, but I can't see how that code could
>> compile anyway, since you can't pass a short[] to a function expecting
>> an int[].
>
> You missed the array literal.
I saw that,
On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
wrote:
> Yup.
>
> It's a pity that we don't have, oh I don't know, some sort of efficient
> iterable interface that doesn't cause a heap allocation that the runtime
> could use instead *cough*hint*cough*andrei*cough*ranges*cough*.
You can use "foreach
wade wrote:
> Thanks again for all the help. I found what the problem was and it wasn't
> obvious (at least to me):
>
> float[uint] arr;
>
> foreach (uint k; arr.keys)
> {
> ...
> }
>
> Changing this to:
>
> foreach (uint k, float v; arr)
> {
>
> }
>
> fixes the leak. I guess the ke
On Tue, Feb 24, 2009 at 8:04 PM, wade wrote:
> fixes the leak. I guess the keys array is constructed on the fly?
Oh, yes X| .keys and .values of AAs are constructed whenever you use them.
On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep
wrote:
> Maybe it's because I just woke up, but I can't see how that code could
> compile anyway, since you can't pass a short[] to a function expecting
> an int[].
You missed the array literal.
Thanks again for all the help. I found what the problem was and it wasn't
obvious (at least to me):
float[uint] arr;
foreach (uint k; arr.keys)
{
...
}
Changing this to:
foreach (uint k, float v; arr)
{
...
}
fixes the leak. I guess the keys array is constructed on the fly?
wade
Lutger W
TSalm wrote:
> In my case, there's also no possibility to get the wrong type, because
> it is managed by the type of the ColumnMem.
You still have to get the code right. There's a surprising number of
corner cases trying to store arbitrary types.
> And about Object, if I want to store base type
wolftousen wrote:
> I have a function defined as:
>
> some_function(int[] array) { ... }; //this function does not ever modify
> values of array
>
> When I call this function (once every program cycle) from an object using an
> array of type short:
>
> //member variable in an object
> short
I have a function defined as:
some_function(int[] array) { ... }; //this function does not ever modify
values of array
When I call this function (once every program cycle) from an object using an
array of type short:
//member variable in an object
short[] x = new short[4];
//object calls thi
TSalm wrote:
I'm trying to build function which have the hability to convert a
type
to void* and from void*.
First of all, I have to ask: have you looked at std.variant /
tango.core.Variant?
Yes, but it seems that Variant class uses more memory than void* .
The Phobos Variant will use h
Jarrett Billingsley wrote:
> On Tue, Feb 24, 2009 at 12:00 PM, wade Shen wrote:
>> I'm writing some performance sensitive code (real time processing) for
which I've tried to minimize the number of memory allocations by using
preallocated objects pools. Unfortunately, during the course of runni
Reply to wade,
Yes,
this would be a great idea, especially for RT production software.
wade
Denis Koroskin Wrote:
For production software it would get tricky. Are you better of doing the
alloc or just failing?
Yes,
this would be a great idea, especially for RT production software.
wade
Denis Koroskin Wrote:
> On Tue, 24 Feb 2009 20:40:13 +0300, BCS wrote:
>
> > Reply to Jarrett,
> >
> >
> >> Hm, actually..
> >> If you *are* using D2, you might be able to replace the GC interface
> >> with a "debug"
Thanks,
That's helpful. I'm using D 1.0. I've eliminated all array concats, dups,
etc. but there's still a significant amount of memory being allocated that I
can't seem to detect.
Perhaps, I can recompile an instrumented version of phobos...
wade
Jarrett Billingsley Wrote:
> On Tue, Feb 2
On Tue, 24 Feb 2009 20:40:13 +0300, BCS wrote:
Reply to Jarrett,
Hm, actually..
If you *are* using D2, you might be able to replace the GC interface
with a "debug" interface that just forwards calls to the normal GC.
This is a capability druntime inherited from the Tango runtime - the
GC is
Reply to Jarrett,
Hm, actually..
If you *are* using D2, you might be able to replace the GC interface
with a "debug" interface that just forwards calls to the normal GC.
This is a capability druntime inherited from the Tango runtime - the
GC is separated from the rest of the standard library a
On Tue, Feb 24, 2009 at 12:00 PM, wade Shen wrote:
> I'm writing some performance sensitive code (real time processing) for which
> I've tried to minimize the number of memory allocations by using preallocated
> objects pools. Unfortunately, during the course of running, it seems that
> lots o
I'm writing some performance sensitive code (real time processing) for which
I've tried to minimize the number of memory allocations by using preallocated
objects pools. Unfortunately, during the course of running, it seems that lots
of memory is still getting allocated even though all explicit
Lutger schrieb:
I think OpenCL will be easier and work om AMD to boot.
If they ever release it in the next few months ;)
Chris R Miller schrieb:
Trass3r wrote:
Is there any tutorial or code for using CUDA with D?
Short answer: no.
I looked into writing CUDA with D a while back. The problem is that the
CUDA C runtime and the D runtime are 100% incompatible. CUDA works by
taking C-like code and compiling it w
23 matches
Mail list logo
