On Sunday, 17 May 2015 at 09:25:33 UTC, Namespace wrote:
Is this error an ICE? I think so, because I see the internal
filename, but I'm not sure.
Error: e2ir: cannot cast malloc(length * 8u) of type void* to
type char[]
https://github.com/D-Programming-Language/dmd/pull/4667
On Monday, 18 May 2015 at 16:40:30 UTC, Dennis Ritchie wrote:
On Monday, 18 May 2015 at 12:49:56 UTC, Kagamin wrote:
Filling a buffer is usually done this way:
http://dlang.org/phobos/std_stdio.html#.File.rawRead
Here such example, the task. There is a flow stream,
associated, for example,
On Monday, 18 May 2015 at 18:40:15 UTC, ketmar wrote:
On Mon, 18 May 2015 14:41:19 +, Chris wrote:
On Monday, 18 May 2015 at 14:34:38 UTC, ketmar wrote:
On Mon, 18 May 2015 14:30:42 +, Chris wrote:
The following
string[string] myarray = [key:value];
string entry;
entry =
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
The following
string[string] myarray = [key:value];
string entry;
entry = myarray[key]; // = vgc: indexing an associative
array may cause GC allocation
Why is _accessing_ an assoc treated as indexing it?
No error if you use
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
Why is _accessing_ an assoc treated as indexing it?
Are you sure you understand indexing as we do? It's not like
indexing of databases, it's just accessing by index i.e. using
myarray[some_index].
On Tuesday, 19 May 2015 at 09:43:06 UTC, Chris wrote:
On Tuesday, 19 May 2015 at 09:10:50 UTC, Namespace wrote:
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
The following
string[string] myarray = [key:value];
string entry;
entry = myarray[key]; // = vgc: indexing an associative
array
On Tuesday, 19 May 2015 at 09:10:50 UTC, Namespace wrote:
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
The following
string[string] myarray = [key:value];
string entry;
entry = myarray[key]; // = vgc: indexing an associative
array may cause GC allocation
Why is _accessing_ an assoc
The documentation seems to indicate that partialShuffle:
Partially shuffles the elements of r such that upon returning
r[0..n] is a random subset of r, (which is what I want), but it
seems that partialShuffle actually only shuffles the first subset
of the range (which you could do probably
On Tuesday, 19 May 2015 at 11:08:52 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
Why is _accessing_ an assoc treated as indexing it?
Are you sure you understand indexing as we do? It's not like
indexing of databases, it's just accessing by index i.e.
using
On Tuesday, 19 May 2015 at 23:10:21 UTC, bitwise wrote:
which is why I am asking if there are any plans to
implement something like @nogc for entire modules or classes.
At the top:
@nogc:
stuff here
Gotta do it inside the class too i think.
On Tue, 19 May 2015 19:03:02 -0400, bitwise bitwise@gmail.com wrote:
Maybe I worded that incorrectly, but my point is that when you're
running with the GC disabled, you should only use methods marked with
@nogc if you want to make sure your code doesn't leak right? that's a
lot of
On Tue, 19 May 2015 19:16:14 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 23:10:21 UTC, bitwise wrote:
which is why I am asking if there are any plans to implement
something like @nogc for entire modules or classes.
At the top:
@nogc:
stuff here
On 5/18/15 7:55 PM, Freddy wrote:
How do you allocate an associative array on the heap?
void main(){
alias A=int[string];
auto b=new A;
}
$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays or class
objects, not int[string]'s
Failed: [dmd, -v, -o-,
On Tue, 19 May 2015 11:36:32 +, Chris wrote:
On Tuesday, 19 May 2015 at 11:08:52 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
Why is _accessing_ an assoc treated as indexing it?
Are you sure you understand indexing as we do? It's not like indexing
of
On Monday, 18 May 2015 at 14:34:38 UTC, ketmar wrote:
it can throw out of range error, which is `new`ed.
Array access can also throw RangeError, but -vgc and @nogc don't
mind that:
void main() @nogc
{
int[] a;
auto b = a[0];
}
On Tue, 19 May 2015 13:17:15 +, anonymous wrote:
On Monday, 18 May 2015 at 14:34:38 UTC, ketmar wrote:
it can throw out of range error, which is `new`ed.
Array access can also throw RangeError, but -vgc and @nogc don't mind
that:
void main() @nogc {
int[] a;
auto b =
On Tuesday, 19 May 2015 at 12:41:29 UTC, ketmar wrote:
On Tue, 19 May 2015 11:36:32 +, Chris wrote:
On Tuesday, 19 May 2015 at 11:08:52 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote:
Why is _accessing_ an assoc treated as indexing it?
Are you sure you
On Tuesday, 19 May 2015 at 10:00:33 UTC, BlackEdder wrote:
The documentation seems to indicate that partialShuffle:
Partially shuffles the elements of r such that upon returning
r[0..n] is a random subset of r, (which is what I want), but it
seems that partialShuffle actually only shuffles the
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the same time
and may clean up the class and its members in any
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC
On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x
anonym...@anonymous.com wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May
On Tue, 19 May 2015 17:52:36 -0400, rsw0x anonym...@anonymous.com wrote:
On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
Any idea what the plans are?. Does RefCounted become thread safe?
Correct me if I'm wrong though, but even if RefCounted itself was
thread-safe, RefCounted
On Tuesday, 19 May 2015 at 20:02:07 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
On Tue, 19 May 2015 15:36:21 -0400, rsw0x anonym...@anonymous.com wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for
On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On 5/19/15 5:07 PM, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x anonym...@anonymous.com
wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400,
On 5/19/15 4:16 PM, Namespace wrote:
On Tuesday, 19 May 2015 at 20:02:07 UTC, rsw0x wrote:
After dconf
http://forum.dlang.org/thread/5554d763.1080...@dawg.eu#post-5554D763.1080308:40dawg.eu
I thought the new releases would come faster.
They should. This is an exception. Read the thread
On 5/19/15 5:07 PM, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x anonym...@anonymous.com wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC,
On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC,
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the
same time and may clean up the class and its members in any order.
In C#, it's possible that class members can actually be destroyed before
the containing object.
Example:
class Stuff
{
Class1 thing1;
Class2 thing2;
~Stuff() {
thing1.DoSomeFinalization(); // [1]
}
}
I forget what the exact behavior was, but basically, [1] is
On 5/19/15 2:37 PM, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the same
time and may clean up the
On Tue, 19 May 2015 14:55:55 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On 5/19/15 2:37 PM, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes.
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the
same
33 matches
Mail list logo
