Thanks very much for your help, it seemed to work a treat (I hope
:))! Compiling ldc wasn't too bad, make the changes to
runtime/phobos/std/stdio.d and then just building as normal was
no problem. Unittests are passing and it handles that file
perfectly.
On Tuesday, 15 September 2015 at 16:11
On Tuesday, 15 September 2015 at 15:28:23 UTC, Andrew Brown wrote:
A very naive question: would it be possible in this case to
backport it into gdc/ldc by copying the pull request and
building the compiler from source, or would this get me into a
world of pain?
Cherry-picking should work and
On Tuesday, 15 September 2015 at 14:55:42 UTC, Martin Krejcirik
wrote:
For reference, it was this PR:
https://github.com/D-Programming-Language/phobos/pull/3089
which fixed the same issue for me.
A very naive question: would it be possible in this case to
backport it into gdc/ldc by copying th
For reference, it was this PR:
https://github.com/D-Programming-Language/phobos/pull/3089
which fixed the same issue for me.
On Tuesday, 15 September 2015 at 14:19:13 UTC, Daniel Kozák wrote:
Which OS?
It's CentOS release 6.5 (Final), I tried dmd 2.068.1 and the
problem has disappeared. Thanks very much for the advice, I can
stick to old gdc for speed until ldc catches up to 2.068.
Best
Andrew
On Tuesday, 15 September 2015 at 13:56:37 UTC, Andrwe Brown wrote:
I'm trying to read a file line by line, and I get a
core.exception.InvalidMemoryOperationError@(0), even after
https://issues.dlang.org/show_bug.cgi?id=13856
Try DMD 2.068, it has got fixed byLine implementation.
On Tue, 15 Sep 2015 13:56:36 +
Andrwe Brown via Digitalmars-d-learn
wrote:
> Hi,
>
> I'm trying to read a file line by line, and I get a
> core.exception.InvalidMemoryOperationError@(0), even after
> reducing the program to:
>
> import std.stdio;
>
> vo
Hi,
I'm trying to read a file line by line, and I get a
core.exception.InvalidMemoryOperationError@(0), even after
reducing the program to:
import std.stdio;
void main()
{
File f = File("testfile");
foreach(line; f.byLine)
{
}
}
The file is a simple table of ascii
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
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 narrowed it down to the .array. I am wondering if there
is
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
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 are complete, so I'm
assuming the garba
On Monday, 28 July 2014 at 22:13:56 UTC, Joakim wrote:
On Monday, 28 July 2014 at 13:31:08 UTC, Martin Drasar via
Digitalmars-d-learn wrote:
On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote:
More broadly speaking, it is thrown whenever certain memory
operations
are attempted while the G
On Monday, 28 July 2014 at 13:31:08 UTC, Martin Drasar via
Digitalmars-d-learn wrote:
On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote:
More broadly speaking, it is thrown whenever certain memory
operations
are attempted while the GC is running, 6 in all, as you can
see here:
https://
On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote:
> More broadly speaking, it is thrown whenever certain memory operations
> are attempted while the GC is running, 6 in all, as you can see here:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458
>
>
> I b
On Monday, 28 July 2014 at 09:38:35 UTC, Martin Drasar via
Digitalmars-d-learn wrote:
Hi,
at the end of my program it throws InvalidMemoryOperationError.
Looking
at the documentation and past forum questions I learned that it
is
probably because of allocations in destructors. However, I have
Hi,
at the end of my program it throws InvalidMemoryOperationError. Looking
at the documentation and past forum questions I learned that it is
probably because of allocations in destructors. However, I have no such
thing in my code (at least not intentionally). I am suspecting the
std.logger packa
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
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 almo
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 almo
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 situation so I would
like to try to understand the issue b
43 matches
Mail list logo
