Re: DMD: can't get extern __gshared to work right (vs. LDC)
On Friday, 8 February 2019 at 05:28:30 UTC, DanielG wrote: Is this correct behavior? It's correct for Windows: address of imported data is not known at link time and must use dynamic linkage. AFAIK, export attribute doesn't do much on posix platforms.
Re: Tricky DMD bug, but I have no idea how to report
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote: Does it also work for dub projects? It will work if you can put all the relevant D code in one directory, which is harder for Dub, as it likes to pull dependencies from all over the place. When "dub dustmite" is insufficient (as in this case), the safest way to proceed would be to build with dub in verbose mode, take note of the compiler command lines it's using, then put them in a shell script and all mentioned D files in one directory, then pass that to Dustmite.
Re: Is it possible to modify shared struct array in a function.
On Friday, 8 February 2019 at 04:51:08 UTC, Sudhi wrote:
On Friday, 8 February 2019 at 04:30:23 UTC, Arun Chandrasekaran
wrote:
On Friday, 8 February 2019 at 04:13:39 UTC, Sudhi wrote:
[...]
Works fine for me with DMD64 D Compiler v2.083.1.
https://run.dlang.io/is/RRM8GU
My example code was wrong. Below is the right one.
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata[] met;
int count;
}
shared (Item) item;
void main()
{
updateMetadata();
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
import std.stdio: writeln;
writeln(item);
}
https://run.dlang.io/is/iem0PY
You have to cast away shared:
auto loc_item = cast(Item) item;
loc_item.met ~= m;
item = cast(shared) loc_item;
Just to be clear, this is not threadsafe and require a mutex if
you do this other than as init in main.
Re: Is it possible to modify shared struct array in a function.
On Friday, 8 February 2019 at 04:51:08 UTC, Sudhi wrote:
On Friday, 8 February 2019 at 04:30:23 UTC, Arun Chandrasekaran
wrote:
[...]
My example code was wrong. Below is the right one.
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata[] met;
int count;
}
shared (Item) item;
void main()
{
updateMetadata();
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
import std.stdio: writeln;
writeln(item);
}
https://run.dlang.io/is/iem0PY
`shared struct Metadata` should make it work.
Turtles (shared) all the way down.
Re: DMD: can't get extern __gshared to work right (vs. LDC)
Follow-up: The problem on DMD macOS is the "export" keyword. It ended up in my code during a similar-ish problem last year, when I was having trouble linking against DLL global variables on Windows. If I remove the "export" keyword in the D interface, it will work on macOS but break on Windows. (To reiterate: WITHOUT "export" on Windows, it refuses to link. WITH "export" on Mac, it seems to link but with incorrect results) Is this correct behavior?
Re: Is it possible to modify shared struct array in a function.
On Friday, 8 February 2019 at 04:30:23 UTC, Arun Chandrasekaran
wrote:
On Friday, 8 February 2019 at 04:13:39 UTC, Sudhi wrote:
I have a situation, where i want to modify a shared variable
in a function. Something like below
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata met;
int count;
}
shared (Item) item
void main()
{
updateMetadata()
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
}
Compiler throws me error in last line for appending as below.
"cannot append type Metadata to type shared(Metadata[])".
Please let me know if there is a way to acheive this.
Thanks,
Sudhi
Works fine for me with DMD64 D Compiler v2.083.1.
https://run.dlang.io/is/RRM8GU
My example code was wrong. Below is the right one.
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata[] met;
int count;
}
shared (Item) item;
void main()
{
updateMetadata();
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
import std.stdio: writeln;
writeln(item);
}
https://run.dlang.io/is/iem0PY
Re: Is it possible to modify shared struct array in a function.
On Friday, 8 February 2019 at 04:13:39 UTC, Sudhi wrote:
I have a situation, where i want to modify a shared variable in
a function. Something like below
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata met;
int count;
}
shared (Item) item
void main()
{
updateMetadata()
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
}
Compiler throws me error in last line for appending as below.
"cannot append type Metadata to type shared(Metadata[])".
Please let me know if there is a way to acheive this.
Thanks,
Sudhi
Works fine for me with DMD64 D Compiler v2.083.1.
https://run.dlang.io/is/RRM8GU
Is it possible to modify shared struct array in a function.
I have a situation, where i want to modify a shared variable in a
function. Something like below
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata met;
int count;
}
shared (Item) item
void main()
{
updateMetadata()
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
}
Compiler throws me error in last line for appending as below.
"cannot append type Metadata to type shared(Metadata[])".
Please let me know if there is a way to acheive this.
Thanks,
Sudhi
Re: Tricky DMD bug, but I have no idea how to report
On Thu, Feb 07, 2019 at 10:16:19PM +, JN via Digitalmars-d-learn wrote: [...] > Anyway, I managed to reduce the source code greatly manually: > > https://github.com/helikopterodaktyl/repro_d_release/ > > unfortunately I can't get rid of the dlib dependency. When built with > debug, test outputs [0: Object], with release it outputs [0: null]. > > commenting this line out: > f.rotation = Quaternionf.fromEulerAngles(Vector3f(0.0f, 0.0f, 0.0f)); > or changing it to: > f.rotation = Quaternionf.identity(); > > is enough to make release output [0: Object] as well. I guess dlib is > doing something dodgy with memory layout, but I can't see anything > suspicious :( Hmm. I can't seem to reproduce this in my environment (Linux/x86_64). Tried it with various combinations of `dub -b release|debug|etc.`, manually compiling with `dmd -I~/.dub/packages/dlib-0.15.0/dlib` with various combinations of -release, -debug, etc.. I wonder if you somehow have an ABI mismatch caused by stale cached objects in dub? Perhaps try `dub --force` to force a rebuild of everything? Or, if you're daring, delete the entire dub cache and rebuild, just to be sure there are no stray stale files lying around somewhere. Barring that, one way to narrow this down further is to copy the relevant dlib sources into your own source tree, remove the dub dependency, and then reduce the dlib sources as well. I did a quick and crude test, and discovered that you only need the following files: dlib/math/matrix.d dlib/math/linsolve.d dlib/math/quaternion.d dlib/math/decomposition.d dlib/math/package.d dlib/math/vector.d dlib/math/utils.d dlib/core/package.d dlib/core/tuple.d Replace dlib/core/package.d with an empty file, and edit dlib/math/package.d to import only dlib.math.quaternion and dlib.math.vector. Since you're only using a very small number of functions, you can probably quickly eliminate most of the above files too. Just edit the files directly (since they're your own copy) and delete everything that isn't directly needed by your code. Of course, at the same time check also that deleting doesn't change the bug behaviour. If it does, then whatever you just deleted may possibly be (part of) the cause of the problem. Sorry I can't help you with reproducing the problem, as the bug doesn't seem to show up in my environment. (I suspect it's still there, just that subtle differences in my environment may be masking it somehow.) T -- Political correctness: socially-sanctioned hypocrisy.
Re: Tricky DMD bug, but I have no idea how to report
On Thursday, 7 February 2019 at 03:50:32 UTC, Vladimir Panteleev wrote: On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote: while working on my game engine project, I encountered a DMD codegen bug. It occurs only when compiling in release mode, debug works. Old thread, but FWIW, such bugs can be easily and precisely reduced with DustMite. In your test script, just compile with and without the compiler option which causes the bug to manifest, and check that one works and the other doesn't. I put together a short article on the DustMite wiki describing how to do this: https://github.com/CyberShadow/DustMite/wiki/Reducing-a-bug-with-a-specific-compiler-option Does it also work for dub projects? Anyway, I managed to reduce the source code greatly manually: https://github.com/helikopterodaktyl/repro_d_release/ unfortunately I can't get rid of the dlib dependency. When built with debug, test outputs [0: Object], with release it outputs [0: null]. commenting this line out: f.rotation = Quaternionf.fromEulerAngles(Vector3f(0.0f, 0.0f, 0.0f)); or changing it to: f.rotation = Quaternionf.identity(); is enough to make release output [0: Object] as well. I guess dlib is doing something dodgy with memory layout, but I can't see anything suspicious :(
Re: std.container.rbtree as Interval Tree?
On Tuesday, 5 February 2019 at 19:12:43 UTC, James Blachly wrote: However, even when allowing (pseudo)duplicates, this means the distinct intervals with same start but different end coordinates are not deterministically placed/sorted within the tree, because they are not sortable with the simple `this.start < other.start` less function. I have updated the example with an `opCmp` implementation. https://run.dlang.io/is/ailnsy I believe this is what you are looking for. Cheers, Edi
Re: Submenu Not Responding Until Second Click
On Wednesday, 6 February 2019 at 13:13:44 UTC, Ron Tarrant wrote: On Tuesday, 5 February 2019 at 09:41:06 UTC, Antonio Corbi wrote: It could be so, I'm not using gnome so I can't say. By the way, I'm using gtk3 3.24.5. Yeah, I updated from 3.22 to 3.24, but it made no difference on Windows 10. Still that delay with submenus. I'd rather be running FreeBSD, but ATM I'm using an MSI laptop with two external monitors and I'm still working on getting Xorg configured to recognize even one of those external monitors. So, until then, I guess I'm stuck with this behaviour. Hi Ron, xrandr (and gui interfaces for it like arandr) are your friends here. xrandr -q -> shows your card outputs and then you can use xrandr + options to configure monitors. Or you can use arandr that will do that for you and will allow you to visually spatially-arrange your monitors. Antonio
Re: variant .init value
On Thursday, 7 February 2019 at 07:33:50 UTC, Norm wrote:
Hi,
I'm trying to use Variant in a struct and want a default init
value like so:
---
struct S {
Variant v = Variant(10);
}
void main() {auto s = S();}
but when I try to build this I get the following error:
dmd2/linux/bin64/../../src/phobos/std/variant.d(661): Error:
memcpy cannot be interpreted at compile time, because it has no
available source code
Error: cannot interpret at compile time
---
I don't particularly need or want this to be available at
compile time, I really only want the struct to have a default
value when instantiated at runtime.
Is there a way to do this with a Variant member?
Thanks,
Norm
I know this is not ideal, but here is a "workaround":
struct S {
Variant v;
static S opCall()
{
S s;
s.v = Variant(10);
return s;
}
}
Would have worked better if structs allowed default ctor in D,
but they don't unfortunately.
Re: variant .init value
On Thursday, 7 February 2019 at 07:44:17 UTC, Alex wrote: On Thursday, 7 February 2019 at 07:33:50 UTC, Norm wrote: [...] Hmm... found something similar from 2014... https://issues.dlang.org/show_bug.cgi?id=11864 Thanks, I've added a comment to that bug report. Cheers, Norm
