Re: CTFE Assignment to anonymous union shows unexpected behavior
On Thu, Apr 22, 2021 at 11:44:51PM +, Rekel via Digitalmars-d-learn wrote: > On Thursday, 22 April 2021 at 23:41:33 UTC, H. S. Teoh wrote: > > On Thu, Apr 22, 2021 at 10:47:17PM +, Rekel via Digitalmars-d-learn > > wrote: > > > I'm not sure why this is happening, but after simplifying my code > > > I traced it back to what the title may suggest. > > > > Keep in mind that CTFE does not support reinterpretation via unions, > > i.e., reading values from a different field in a union than was > > assigned. If you assign field A to a union, then you cannot read field B > > from that union in CTFE. You can only do this at runtime, not in CTFE. [...] > I'm not sure what you mean, > do you mean if i were to read the field during CTFE, or even if i read > the field during runtime after initializing it using CTFE? If you read the field during CTFE. I've never tested initializing a union in CTFE then reading it at runtime, though. Not sure exactly what would happen in that case. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Re: String concatenation segmentation error
On Friday, 23 April 2021 at 00:44:58 UTC, tcak wrote: As far as I see, it is not related to that array or indices at all. The question of where is to see if it was CTFE allocated or runtime allocated. I don't think it should make a difference here but idk. If there is no known situation that would cause this druntime not being initialized is the only situation I know of that causes this directly. Otherwise memory corruption or race condition of some sort, hence why i was wondering about threads. But I don't think it is uninitialized druntime unless that new happened at ctfe or something.
Re: String concatenation segmentation error
On Friday, 23 April 2021 at 00:30:02 UTC, Adam D. Ruppe wrote: On Thursday, 22 April 2021 at 21:15:48 UTC, tcak wrote: "positions" array is defined as auto positions = new float[ 100 ]; So, I am 100% sure, it is not out of range. "ri*dim + 1" is not a big number at all. Oh and *where* is that positions variable defined? I am doing OpenCL programming. CPU side is single threaded. As far as I see, it is not related to that array or indices at all. After running for a short time, if a piece of code does any string/char or byte array concatenation at all, all of them cause segmentation fault with error: _D2gc4impl12conservativeQw3Gcx10smallAllocMFNbmKmkxC8TypeInfoZPv () When I comment out those piece of codes, there is no error. If there is no known situation that would cause this, I will need to update codes to C-style pre-allocate buffer and copy inside it instead of concatenating data.
Re: String concatenation segmentation error
On Thursday, 22 April 2021 at 21:15:48 UTC, tcak wrote: "positions" array is defined as auto positions = new float[ 100 ]; So, I am 100% sure, it is not out of range. "ri*dim + 1" is not a big number at all. Oh and *where* is that positions variable defined?
Re: String concatenation segmentation error
Are there any other threads in your program?
Re: String concatenation segmentation error
In other parts of the code, concatenation operations are all failing with same error. I need guidance to get out of this situation. My assumption was that as long as there is empty heap memory, concatenation operation would succeed always. But, it doesn't seem like so.
Re: CTFE Assignment to anonymous union shows unexpected behavior
On Thursday, 22 April 2021 at 23:41:33 UTC, H. S. Teoh wrote: On Thu, Apr 22, 2021 at 10:47:17PM +, Rekel via Digitalmars-d-learn wrote: I'm not sure why this is happening, but after simplifying my code I traced it back to what the title may suggest. Keep in mind that CTFE does not support reinterpretation via unions, i.e., reading values from a different field in a union than was assigned. If you assign field A to a union, then you cannot read field B from that union in CTFE. You can only do this at runtime, not in CTFE. T I'm not sure what you mean, do you mean if i were to read the field during CTFE, or even if i read the field during runtime after initializing it using CTFE?
Re: CTFE Assignment to anonymous union shows unexpected behavior
On Thu, Apr 22, 2021 at 10:47:17PM +, Rekel via Digitalmars-d-learn wrote: > I'm not sure why this is happening, but after simplifying my code I > traced it back to what the title may suggest. Keep in mind that CTFE does not support reinterpretation via unions, i.e., reading values from a different field in a union than was assigned. If you assign field A to a union, then you cannot read field B from that union in CTFE. You can only do this at runtime, not in CTFE. T -- There are two ways to write error-free programs; only the third one works.
CTFE Assignment to anonymous union shows unexpected behavior
I'm not sure why this is happening, but after simplifying my code
I traced it back to what the title may suggest. The original
cause of my issues being summarized by debug print statements
returning a union as:
Mat([nanf, nanF, . . . .], [[1.0F, 0.0F, . . . .])
Even though the nanF should thus be 1.0, 0.0, etc...
This is example code that describes when this happens:
```d
import std.stdio;
struct Apple(uint size) {
union {
int[size * size] a;
int[size][size] b;
}
static immutable typeof(this) pie = _pie();
private static typeof(this) _pie() pure {
typeof(this) result;
static foreach (i; 0 .. size)
static foreach (j; 0 .. size)
//result.a[i + j * size] = 1; // Works
result.b[i][j] = 1; // Fails
return result;
}
}
void main() {
Apple!(4) a = Apple!(4).pie;
writeln(a.a);
writeln(a.b);
}
```
The working code changes the first integers to 1, the failing
version keeps them at 0.
What's the reason for this? Logically this doesn't seem
troublesome to me, and if assigning to non-initial anonymous
union varialbes isn't possible(?!) that would be pretty bad, and
I'd be in for quite some trouble in my actual code :(
String concatenation segmentation error
string fileContent = "";
...
writeln(ri, ": debug 1");
foreach(i; 0..dim)
{
if( i > 0 ){ fileContent ~= "\t"; }
writeln(ri, ": debug 1.1: ", ri*dim + i, ": ", positions[ ri*dim
+ i ]);
fileContent ~= to!string(positions[ ri*dim + i ]);
writeln(ri, ": debug 1.2: ", ri*dim + i, ": ", positions[ ri*dim
+ i ]);
}
-
On line "fileContent ~= ...", I get a segmentation fault.
"positions" array is defined as auto positions = new float[ 100
]; So, I am 100% sure, it is not out of range. "ri*dim + 1" is
not a big number at all.
...
4: debug 1.1: 9: 0.271075
4: debug 1.2: 9: 0.271075
4: debug 2
4: debug 2.1: 4
4: debug 3
4: debug 4
5: debug 1
5: debug 1.1: 10: 0.884978
5: debug 1.2: 10: 0.884978
5: debug 1.1: 11: 0.813104
Segmentation fault
...
I have compiled the code with "-g" flag and ran it with GNU
debugger. It gives following:
Thread 1 "dataspace" received signal SIGSEGV, Segmentation fault.
0x556ca286 in
_D2gc4impl12conservativeQw3Gcx10smallAllocMFNbmKmkxC8TypeInfoZPv
()
So, there is a problem about small allocation. I remember I had
this problem before in another project.
I have enough free ram. htop shows 3.96 GiB of 8 GiB is used only
and swap is not in use.
DMD64 D Compiler v2.094.0
Is this error related to me? Is it a programmer error? Is it a
bug? Am I doing something wrong? This is a compiler related
operation (string concatenation), and I assume/expect that it
would work without a problem.
Re: Voldemort type "this" pointer
On Wednesday, 21 April 2021 at 15:53:59 UTC, Ali Çehreli wrote:
On 4/21/21 8:37 AM, realhet wrote:
On Wednesday, 21 April 2021 at 10:47:08 UTC, Mike Parker wrote:
On Wednesday, 21 April 2021 at 10:00:51 UTC, realhet wrote:
It has access to the context of its enclosing scope (via an
added hidden field).
Thanks!
So it is unsafe to return a non-static nested struct from a
function. But it is useful to pass it forward into other
functions.
Not at all. (D is good at preventing such bugs anyway.)
The local context that the nested struct object uses becomes
the context of that object.
Wow, this information is really out of the box for me. I have one
misconception less now.
(I never used a language with GC before and this thing requires a
GC for sure.)
/---
auto uiDeclare(void delegate() fun){
struct UiObject{
//void delegate() fun; <- not needed, it captures fun in
the params
void render(){ fun(); }
}
return UiObject();
}
long rec(long a, long c){ return aauto b = [ uiDeclare({ writeln("boop", a); }), uiDeclare({
writeln("boop", a+1); })];
rec(0, 123456); // destroy the stack to make sure
b.each!"a.render";
}
Indeed it's not using the stack. And it also works when a
delegates captures its scope.
In my immediate GUI interface I'm using delegates all the time
with the my misconception of I only allowed to call them from
inside the function I passed them into.
For example: Row({ Text(clBlue, "Hello");
Img(`pictures\pic1.jpg`); }); will call the delegate from inside,
not save it for later use.
And if I save the delegate inside the Row() function (I mark UI
generating functions with a capital letter), it is protected from
the GC and can be used later in rendering time... Too bad, the
data it uses at that later moment is possibly changed already.
Anyways, I've learned a lot now. Thank you!
