Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 23:00:08 UTC, Chris M. wrote: On Monday, 2 July 2018 at 21:20:26 UTC, Seb wrote: On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: [...] Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far. I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC? Ah, okay. I'm mostly on Linux so I generally miss anything Windows-related. I was using the following link and figured I'd install DMC as well. https://dlang.org/dmd-windows.html#requirements BTW have you tried using LDC? They might ship a newer version of LLD.
how to create an array of scoped objects ?
e.g A is a class that emits output during destruction
{
auto a = scoped!A();
}
how do I contain it in a container, in the Array struct ?
{
auto a = scoped!A();
Array!( typeof( a ) ) arr;
foreach( i ; 0..3 ) {
arr.insertBack( scoped!A );
}
}
is that how you do it ?
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 23:00:08 UTC, Chris M. wrote: On Monday, 2 July 2018 at 21:20:26 UTC, Seb wrote: I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC? Ah, okay. I'm mostly on Linux so I generally miss anything Windows-related. I was using the following link and figured I'd install DMC as well. So your linker errors show that you're using lld anyway. I'm on my Linux laptop at a Starbucks atm, but I'm pretty sure that the Windows distribution does not ship with any system libraries that are compatible with lld. It only ships with a small set of OMF link libraries that Walter got permission to distribute a couple decades ago and that only work with the DM linker. So anything that relies on the Windows APIs is not going to build without something to link to. You'll probably have no choice but to install the build tools.
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 21:20:26 UTC, Seb wrote: On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: On Monday, July 02, 2018 18:26:27 Chris M. via Digitalmars-d-learn wrote: On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: > [...] Thanks for checking, I have no idea what else to try (short of getting MS Build Tools somehow, but I unfortunately can't in my current environment so I'm stuck with DMC + DMD) How are you compiling for 64-bit without the MS toolchain? - Jonathan M Davis Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far. I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC? Ah, okay. I'm mostly on Linux so I generally miss anything Windows-related. I was using the following link and figured I'd install DMC as well. https://dlang.org/dmd-windows.html#requirements
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, July 02, 2018 21:20:26 Seb via Digitalmars-d-learn wrote: > On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: > > On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: > >> On Monday, July 02, 2018 18:26:27 Chris M. via > >> > >> Digitalmars-d-learn wrote: > >>> On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: > >>> > [...] > >>> > >>> Thanks for checking, I have no idea what else to try (short > >>> of getting MS Build Tools somehow, but I unfortunately can't > >>> in my current environment so I'm stuck with DMC + DMD) > >> > >> How are you compiling for 64-bit without the MS toolchain? > >> > >> - Jonathan M Davis > > > > Downloaded the DMD and DMC zip files, extracted and added to > > PATH. Been working for the most part so far. > > I thought for 64-bit the bundled lld linker and mingw runtime are > used? > https://dlang.org/changelog/2.079.0.html#lld_mingw > So in fact you shouldn't even need DMC? Well, that's a nice improvement. I didn't realize that that was the case now (though I rarely do anything with Windows). - Jonathan M Davis
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: On Monday, July 02, 2018 18:26:27 Chris M. via Digitalmars-d-learn wrote: On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: > [...] Thanks for checking, I have no idea what else to try (short of getting MS Build Tools somehow, but I unfortunately can't in my current environment so I'm stuck with DMC + DMD) How are you compiling for 64-bit without the MS toolchain? - Jonathan M Davis Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far. I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC?
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: On Monday, July 02, 2018 18:26:27 Chris M. via Digitalmars-d-learn wrote: On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: > On Monday, 2 July 2018 at 12:53:19 UTC, Chris M. wrote: >> [...] > > If I don't get around it tonight then I will tomorrow and > see if I can find a solution for you or perhaps figure out > what exactly goes wrong. > > Kinda half important for me too to fix something like this > since I have a framework relying on vibe.d Thanks for checking, I have no idea what else to try (short of getting MS Build Tools somehow, but I unfortunately can't in my current environment so I'm stuck with DMC + DMD) How are you compiling for 64-bit without the MS toolchain? - Jonathan M Davis Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far.
Re: Dynamic arrays / ~= giving an exception...
On Monday, July 02, 2018 14:46:28 Steven Schveighoffer via Digitalmars-d- learn wrote: > It should work. We need more context to try and help figure it out. Even > if you can't post the entire program, maybe more context from mystruct. If the program size is too large to show a good example, then I'd suggest using dustmite to reduce it. That can sometimes take a while, but it should then give us something where we have a chance of diagnosing the problem. - Jonathan M Davis
Re: Dynamic arrays / ~= giving an exception...
On 7/1/18 4:55 PM, Robert M. Münch wrote:
I'm a bit puzzled because I think this is pretty straight forward but
doesn't work...
struct mystruct {
myPtr* root;
opApply(...){
myPtr*[] childs;
childs ~= root;
...
}
}
foreach(node; mystruct(myRoot)){
...
}
It compiles but the line with ~= gives the nice "bing" under Windows and
the application hangs...
What doesn't this work?
It should work. We need more context to try and help figure it out. Even
if you can't post the entire program, maybe more context from mystruct.
In general:
T*[] arr;
arr ~= someTPtr;
should ALWAYS work. There is absolutely no postblits or dangling
pointers happening at THIS point, and you are allocating an array to
hold a pointer.
I suspect that your diagnosis of where the problem is happening is faulty.
-Steve
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, July 02, 2018 18:26:27 Chris M. via Digitalmars-d-learn wrote: > On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: > > On Monday, 2 July 2018 at 12:53:19 UTC, Chris M. wrote: > >> On Friday, 29 June 2018 at 20:08:49 UTC, Chris M. wrote: > >>> On Friday, 29 June 2018 at 19:53:27 UTC, bauss wrote: > On Friday, 29 June 2018 at 19:25:42 UTC, Chris M. wrote: > > [...] > > Are you compiling to 64bit? > > Else the functions will be named GetClassLongA and > SetClassLongA > >>> > >>> Yeah, that's what I'm targeting > >>> > Vibe builds fine on 64bit for me and I think that's > outdated. It hasn't been modified for 4 years. > >>> > >>> Seems to be an issue when I import vibe.core.concurrency > >> > >> Bumping this one back up > > > > If I don't get around it tonight then I will tomorrow and see > > if I can find a solution for you or perhaps figure out what > > exactly goes wrong. > > > > Kinda half important for me too to fix something like this > > since I have a framework relying on vibe.d > > Thanks for checking, I have no idea what else to try (short of > getting MS Build Tools somehow, but I unfortunately can't in my > current environment so I'm stuck with DMC + DMD) How are you compiling for 64-bit without the MS toolchain? - Jonathan M Davis
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: On Monday, 2 July 2018 at 12:53:19 UTC, Chris M. wrote: On Friday, 29 June 2018 at 20:08:49 UTC, Chris M. wrote: On Friday, 29 June 2018 at 19:53:27 UTC, bauss wrote: On Friday, 29 June 2018 at 19:25:42 UTC, Chris M. wrote: [...] Are you compiling to 64bit? Else the functions will be named GetClassLongA and SetClassLongA Yeah, that's what I'm targeting Vibe builds fine on 64bit for me and I think that's outdated. It hasn't been modified for 4 years. Seems to be an issue when I import vibe.core.concurrency Bumping this one back up If I don't get around it tonight then I will tomorrow and see if I can find a solution for you or perhaps figure out what exactly goes wrong. Kinda half important for me too to fix something like this since I have a framework relying on vibe.d Thanks for checking, I have no idea what else to try (short of getting MS Build Tools somehow, but I unfortunately can't in my current environment so I'm stuck with DMC + DMD)
Re: Can I call GC.addRoot from constructor and trigger collection with destroy()?
On 7/1/18 5:59 PM, Robert M. Münch wrote: I'm creating a bunch of objects and need to use these object pointers with C code. Hence I need to protect them from being GC with GC.addRoot. Can this call be made out of a constructor? So that I can protect the objects as earyl as possible? Yes. Could I then unprotect the memory inside the destructor, which I would call explicitly via destroy(...)? Or would a call to destroy be sufficient to tell the GC, now you can collect the memory? If you call destroy, it does nothing for the GC. As long as it's not a class, the GC will actually re-destruct the item when running a collection. And yes, it is possible to removeRoot inside the dtor. However, I'd caution one thing -- addRoot on an already-existing root does not add it again. So you will cause problems if you make copies of the struct that removes the root. The first destructor will remove the root, and then it's free to be collected. -Steve
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 12:53:19 UTC, Chris M. wrote: On Friday, 29 June 2018 at 20:08:49 UTC, Chris M. wrote: On Friday, 29 June 2018 at 19:53:27 UTC, bauss wrote: On Friday, 29 June 2018 at 19:25:42 UTC, Chris M. wrote: [...] Are you compiling to 64bit? Else the functions will be named GetClassLongA and SetClassLongA Yeah, that's what I'm targeting Vibe builds fine on 64bit for me and I think that's outdated. It hasn't been modified for 4 years. Seems to be an issue when I import vibe.core.concurrency Bumping this one back up If I don't get around it tonight then I will tomorrow and see if I can find a solution for you or perhaps figure out what exactly goes wrong. Kinda half important for me too to fix something like this since I have a framework relying on vibe.d
Re: Issues with undefined symbols when using Vibe on Windows
On Friday, 29 June 2018 at 20:08:49 UTC, Chris M. wrote: On Friday, 29 June 2018 at 19:53:27 UTC, bauss wrote: On Friday, 29 June 2018 at 19:25:42 UTC, Chris M. wrote: [...] Are you compiling to 64bit? Else the functions will be named GetClassLongA and SetClassLongA Yeah, that's what I'm targeting Vibe builds fine on 64bit for me and I think that's outdated. It hasn't been modified for 4 years. Seems to be an issue when I import vibe.core.concurrency Bumping this one back up
Re: Delegating constructor and call to super
On Monday, 2 July 2018 at 09:42:36 UTC, Robert M. Münch wrote:
I think it's because of "If a constructor's code contains a
delegate constructor call, all possible execution paths through
the constructor must make exactly one delegate constructor call"
But, how am I supposed to call the super(int) consturctor and
put my common initialization code into a delegating constructor?
class B {
this(){ initialize(); }
this(int a){super(a); initialize(); }
private void initialize() { ... init some stuff for B ...
}
}
Delegating constructor and call to super
class A {
this(){...}
this(int a) {...}
this int a, int b){...}
}
class B {
this(){... init some stuff for B ...}
this(int a){super(a); this();}
}
Error: multiple constructor calls
I think it's because of "If a constructor's code contains a delegate
constructor call, all possible execution paths through the constructor
must make exactly one delegate constructor call"
But, how am I supposed to call the super(int) consturctor and put my
common initialization code into a delegating constructor?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: 0xC0000005: 0x0000000000000000 access violation...
On Sunday, 1 July 2018 at 22:04:05 UTC, Robert M. Münch wrote:
On 2018-07-01 09:05:56 +, Robert M. Münch said:
This one look nasty...
And it was... the problem was, that I kept D allocated pointers
in C code without informing the GC that the memory can't be
collected nor moved. Bridging from D to C and back, is pretty
tricky to not miss any allocated memory.
Couldn't such a problem be mitigated with an annotation like
@externalRef or so, which would add the code to protect such
memory from being GC? It would make the code much more explicit.
An annotation probably won't do it. This might:
struct ExternalRef(T) {
T* ptr;
alias ptr this;
void free() {
import core.stdc.stdlib : free;
free(ptr);
}
}
auto externalRef(T)() {
import core.stdc.stdlib : malloc;
return ExternalRef!T(cast(T*)malloc(T.sizeof));
}
extern(C)
void sendToC(ExternalRef!int p);
extern(C)
ExternalRef!int getFromC();
unittest {
sendToC(externalRef!int());
getFromC().free();
}
This is hardly a production-quality piece of code, but should
give some ideas for what's possible.
--
Simen
