On Tuesday, 23 June 2015 at 18:49:59 UTC, David DeWitt wrote:
On Monday, 22 June 2015 at 20:30:40 UTC, David DeWitt wrote:
I am getting an core.exception.InvalidMemoryOperationError@(0)
auto recs = f // Open for reading
.byLineCopy();
On Monday, 22 June 2015 at 20:30:40 UTC, David DeWitt wrote:
I am getting an core.exception.InvalidMemoryOperationError@(0)
auto recs = f // Open for reading
.byLineCopy();
.array; //Here is where is appears
to be happening.
[...]
On Monday, 22 June 2015 at 20:30:40 UTC, David DeWitt wrote:
I am getting an core.exception.InvalidMemoryOperationError@(0)
auto recs = f // Open for reading
.byLineCopy();
.array; //Here is where is appears
to be happening.
I have
Where is your code found? InvalidMemoryOperationError usually
props up in code running from a destructor.
If the call to .array isn't in a destructor, it might also be
that the array is triggering a GC cycle... which calls something
in a destructor.
Since that's so commonly the cause I encou
On Tue, 27 Jan 2015 06:46:20 +, Bayan Rafeh wrote:
> This is the first serious project I do with D
and now you're lost to other C-like languages, methinks. ;-)
signature.asc
Description: PGP signature
but please, take my words with a grain of salt. i'm in no way a
representative of D devs. that is how *i* understand
invariants. it seems to be consistent with the cases where
invariant works,
This is the first serious project I do with D, so I'm kind of
discovering the language as I write
On Mon, 26 Jan 2015 11:37:12 +, Bayan Rafeh wrote:
>> you are trying to use invariants for the things that invariants can't
>> (and must not) check. invariants are meant for checking *internal*
>> *object* *consistency*. NOT correctness. NOT applicability. ONLY
>> consistency. object can be in
On Monday, 26 January 2015 at 15:54:12 UTC, Bayan Rafeh wrote:
I apologize, I thought the point of invariant was to ensure
correctness of the
object's state
It is simply matter of "internal correctness" vs "in-program
correctness". Sorry, documentation should probably mention that
explicitly.
Bug report at https://issues.dlang.org/show_bug.cgi?id=14051
you are trying to use invariants for the things that invariants
can't
(and must not) check. invariants are meant for checking
*internal*
*object* *consistency*. NOT correctness. NOT applicability. ONLY
consistency. object can be in "inapplicable" state, but still
consistent.
Then I must have
On Mon, 26 Jan 2015 05:25:48 +, Bayan Rafeh wrote:
> There are 2 problems here:
>
> 1. By definition, after the destructor is called the object state is
> destroyed. It makes no sense to check the invariant after the destructor
> is called because there is no state for us to check.
i agree th
the thing is that your invariant is not a correct invariant at
all.
invariants are meant to check *internal* object consistency,
not external
conditions. compiler is free to call invariant block at any
time after
object is properly initialised (i.e. after ctor is complete)
and is not
executin
On Sun, 25 Jan 2015 22:06:26 +, Bayan Rafeh wrote:
p.s. yet creating new `File` in invariant is wrong nevertheless, as it
changes the program state. invariant checks SHOULD NEVER CHANGE THE
PROGRAM STATE.
signature.asc
Description: PGP signature
On Sun, 25 Jan 2015 22:06:26 +, Bayan Rafeh wrote:
> This is another problematic example program:
> import std.stdio;
>
> void main(){
> auto a = new A("/tmp/invalid");
> }
>
> class A {
> File f;
> string path;
>
> this(string path) {
> this.path = path;
> //
On Sunday, 25 January 2015 at 22:46:56 UTC, Ali Çehreli wrote:
On 01/25/2015 02:06 PM, Bayan Rafeh wrote:
is invariant() called during the destruction phase?
Something is fishy.
import std.stdio;
void main(){
writeln("entered main");
auto a = new A();
writeln("leaving main");
}
On 01/25/2015 02:06 PM, Bayan Rafeh wrote:
is invariant() called during the destruction phase?
Something is fishy.
import std.stdio;
void main(){
writeln("entered main");
auto a = new A();
writeln("leaving main");
}
class A {
File file;
this() {
writeln("this");
On Sunday, 25 January 2015 at 19:15:54 UTC, ketmar wrote:
On Sun, 25 Jan 2015 08:41:24 +, Bayan Rafeh wrote:
I tried what you said and I think I see the problem. I
managed to
create an example program that duplicates the problem:
import std.stdio;
class A {
string path;
this(st
On Sun, 25 Jan 2015 08:41:24 +, Bayan Rafeh wrote:
>> I tried what you said and I think I see the problem. I managed to
>> create an example program that duplicates the problem:
>>
>>
>> import std.stdio;
>>
>> class A {
>> string path;
>>
>> this(string p) {
>> path = p;
>>
On Sunday, 25 January 2015 at 08:41:25 UTC, Bayan Rafeh wrote:
The solution was just to remove the "delete a" from the
destructor if someone comes across this later. Could someone
tell me why though?
The "non-reentrant" bit applies to all GC operations, really -
not just allocations. Explicit
On Sunday, 25 January 2015 at 08:39:42 UTC, Bayan Rafeh wrote:
On Sunday, 25 January 2015 at 00:43:43 UTC, Vladimir Panteleev
wrote:
On Saturday, 24 January 2015 at 12:16:38 UTC, Bayan Rafeh
wrote:
This problem is a tough one. I've been getting this error
when I run my unittests, and apparently
On Sunday, 25 January 2015 at 00:43:43 UTC, Vladimir Panteleev
wrote:
On Saturday, 24 January 2015 at 12:16:38 UTC, Bayan Rafeh wrote:
This problem is a tough one. I've been getting this error when
I run my unittests, and apparently it is caused by attempting
an allocation in the destructor fro
On Saturday, 24 January 2015 at 12:16:38 UTC, Bayan Rafeh wrote:
This problem is a tough one. I've been getting this error when
I run my unittests, and apparently it is caused by attempting
an allocation in the destructor from what little I could find
online about the subject.
The error is tr
On Saturday, 24 January 2015 at 22:42:51 UTC, Ali Çehreli wrote:
The allocations may be indirect. For example, formatting a
string to log a message may allocate. Try marking your
destructors as @nogc to see whether the compiler agrees.
I am not sure whether it would cause the same error but an
On 01/24/2015 04:16 AM, Bayan Rafeh wrote:
This problem is a tough one. I've been getting this error when I run my
unittests, and apparently it is caused by attempting an allocation in
the destructor from what little I could find online about the subject.
The error is triggered once all my tests
On Friday, 11 July 2014 at 11:43:44 UTC, Joakim wrote:
On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio
wrote:
A code I'm working on stops working and starts printing an
infinite loop of
core.exception.InvalidMemoryOperationError
to the command line output. The code is quite compl
On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio
wrote:
A code I'm working on stops working and starts printing an
infinite loop of
core.exception.InvalidMemoryOperationError
to the command line output. The code is quite complex and the
bug seems to present itself almost in random
On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio
wrote:
A code I'm working on stops working and starts printing an
infinite loop of
core.exception.InvalidMemoryOperationError
to the command line output. The code is quite complex and the
bug seems to present itself almost in random
27 matches
Mail list logo
