Re: How can I use class and wasm?
On Friday, 16 October 2020 at 03:04:25 UTC, Jack wrote: How can I allocate memory for this class? It is possible but not easy without druntime. If you are using -betterC, you can use extern(C++) classes with extern(D) members. The compiler will let you declare that. But then you need to allocate it. `__traits(classInstanceSize, Whatever)` will tell you the size to malloc, but you also need to copy an initializer over before you call the constructor. I have a technique here that works on dmd... http://dpldocs.info/this-week-in-d/Blog.Posted_2020_07_27.html#zero-runtime-classes but ldc is more strict about the type definition and I don't know the magic it expects there... like it should be doable but idk how so this might not be of much use. Personally, I prefer to just not use betterC and make my own mini runtime: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html in particular https://github.com/adamdruppe/webassembly/blob/master/arsd-webassembly/object.d#L74 But that's also not easy, lots of unfinished cases in my thing, but I did manage to make it work... for my specific case.
Re: How can I use class and wasm?
On Friday, 16 October 2020 at 02:43:19 UTC, Paul Backus wrote:
On Thursday, 15 October 2020 at 22:02:11 UTC, Jack wrote:
can I make it work? the code (see below) result in link error:
lld: error: wasm.o: undefined symbol: _D4wasm1C7__ClassZ
lld: error: wasm.o: undefined symbol: _d_allocclass
Error: linking with LLD failed
command line:
ldc2 --d-debug -mtriple=wasm32-unknown-unknown-wasm -betterC
wasm.d
ldc version:
1.24.0-beta1 (DMD v2.094.0, LLVM 11.0.0)
code:
extern(C): // disable D mangling
// seems to be the required entry point
void _start() {}
extern(C)
int g()
{
auto c = new C();
You can't use `new` in betterC.
that's right, my bad but even a custom allocator, using
malloc()/free() wouldn't work either. How can I allocate memory
for this class?
Re: How can I use class and wasm?
On Thursday, 15 October 2020 at 22:02:11 UTC, Jack wrote:
can I make it work? the code (see below) result in link error:
lld: error: wasm.o: undefined symbol: _D4wasm1C7__ClassZ
lld: error: wasm.o: undefined symbol: _d_allocclass
Error: linking with LLD failed
command line:
ldc2 --d-debug -mtriple=wasm32-unknown-unknown-wasm -betterC
wasm.d
ldc version:
1.24.0-beta1 (DMD v2.094.0, LLVM 11.0.0)
code:
extern(C): // disable D mangling
// seems to be the required entry point
void _start() {}
extern(C)
int g()
{
auto c = new C();
You can't use `new` in betterC.
Re: winapi, dll
On Thursday, 15 October 2020 at 20:13:37 UTC, Atmosfear wrote:
On Thursday, 15 October 2020 at 16:32:06 UTC, Imperatorn wrote:
On Thursday, 15 October 2020 at 12:45:42 UTC, Atmosfear wrote:
I didn't find how to call the queryperformancecounter
function. I tried this. Returns errors, doesn't know what
BOOL and LARGE_INTEGER are.
import core.sys.windows.windows;
import core.sys.windows.w32api;
import core.sys.windows.winbase;
pragma(lib, "kernel32");
extern (Windows)
{
BOOL QueryPerformanceCounter(LARGE_INTEGER
*lpPerformanceCount);
}
void main()
{}
It's already defined. Just use QueryPerformanceCounter, (no
extern).
I'm a newby. Can you show me an example? In which module is it?
When you do the import, it include already the function ready to
use, it isn't like C#'s PInvoke system for example, where tou
need to add a function sginature/prototype with the dll where
it's defined.
Re: winapi, dll
On Thursday, 15 October 2020 at 20:59:10 UTC, Atmosfear wrote: I use online DMD. I'll try VS 2019 with the VisualD. That's the issue, then. The online versions of DMD run on Linux. You don't need VisualD for this. Just plain old dmd in a text editor will do.
Re: why do i need an extern(C): here?
On Thu, Oct 15, 2020 at 09:47:16PM +, IGotD- via Digitalmars-d-learn wrote: > On Thursday, 15 October 2020 at 21:29:59 UTC, WhatMeWorry wrote: > > > > I've go a small DLL and a test module both written in D. Why do I > > need to use the extern(C)? Shouldn't both sides be using D name > > wrangling? > > > > You have answered your own question. If you're not using extern(C), D > just like C++ adds a lot of name mangling which is not "addSeven" but > extra characters as well. GetProcAddress which is a Windows call has > no idea about D name mangling and therefore will not find the > function. You can use .mangleof to get the mangled name of a D function that you can then lookup with GetProcAddress. T -- Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.
How can I use class and wasm?
can I make it work? the code (see below) result in link error:
lld: error: wasm.o: undefined symbol: _D4wasm1C7__ClassZ
lld: error: wasm.o: undefined symbol: _d_allocclass
Error: linking with LLD failed
command line:
ldc2 --d-debug -mtriple=wasm32-unknown-unknown-wasm -betterC
wasm.d
ldc version:
1.24.0-beta1 (DMD v2.094.0, LLVM 11.0.0)
code:
extern(C): // disable D mangling
// seems to be the required entry point
void _start() {}
extern(C)
int g()
{
auto c = new C();
return c.f();
}
extern(C++)
{
class C
{
int f() { return 42; }
}
}
Re: why do i need an extern(C): here?
On Thursday, 15 October 2020 at 21:29:59 UTC, WhatMeWorry wrote: I've go a small DLL and a test module both written in D. Why do I need to use the extern(C)? Shouldn't both sides be using D name wrangling? You have answered your own question. If you're not using extern(C), D just like C++ adds a lot of name mangling which is not "addSeven" but extra characters as well. GetProcAddress which is a Windows call has no idea about D name mangling and therefore will not find the function.
Re: why do i need an extern(C): here?
On 10/15/20 2:29 PM, WhatMeWorry wrote:
> name wrangling?
Name mangling. :) I don't know the answer but I can hijack your thread.
> import core.runtime;
> auto mydll = Runtime.loadLibrary("mydll.dll");
Interesting. I've recently done the same by calling dlopen() and dlsym()
directly. Runtime.loadLibrary documentation says "If the library
contains a D runtime it will be integrated with the current runtime."
That would explain why my program seg-faults for my first tester with
the garbage collector signatures in the function call stack. Right?
Thanks! :)
Ali
why do i need an extern(C): here?
I've go a small DLL and a test module both written in D. Why do I
need to use the extern(C)? Shouldn't both sides be using D name
wrangling?
mydll.d
module mydll;
extern(C): // removing or changing to (D): results in error
export
{
int addSeven(int a, int b) { return a+b+7; }
}
user.d
module user;
import core.sys.windows.winbase;
import std.stdio;
void main()
{
alias addSevenFuncSignature = int function(int, int);
addSevenFuncSignature addSeven;
import core.runtime;
auto mydll = Runtime.loadLibrary("mydll.dll");
assert(mydll);
addSeven = cast(addSevenFuncSignature) GetProcAddress(mydll,
"addSeven");
int ret = addSeven(2,3);
writeln("calling addSeven(2,3) = ", addSeven(2,3));
Runtime.unloadLibrary(mydll);
}
--- execution results
--
c:\D\dmd2\samples\d\mydll>dmd -m64 mydll.d -L/DLL -L/NOENTRY
Creating library mydll.lib and object mydll.exp
c:\D\dmd2\samples\d\mydll>dmd -m64 user.d
c:\D\dmd2\samples\d\mydll>user.exe
calling addSeven(2,3) = 12
Re: winapi, dll
On Thursday, 15 October 2020 at 20:47:43 UTC, Imperatorn wrote:
On Thursday, 15 October 2020 at 20:13:37 UTC, Atmosfear wrote:
On Thursday, 15 October 2020 at 16:32:06 UTC, Imperatorn wrote:
[...]
I'm a newby. Can you show me an example? In which module is it?
I see. What Editor/IDE are you using btw?
If you use Visual Studio 2019 with the VisualD extension or
Visual Studio Code with the D Programming Language (code-d)
extension you can get some nice help with these kinds of things.
To the question, try this:
import std.stdio;
import core.sys.windows.winbase;
import core.sys.windows.windef;
import core.sys.windows.windows;
void main()
{
LARGE_INTEGER li;
BOOL b = QueryPerformanceCounter();
//Don't know what you're after. Defined in winnt
writeln(li.QuadPart);
readln();
}
I use online DMD. I'll try VS 2019 with the VisualD.
Re: winapi, dll
On Thursday, 15 October 2020 at 20:13:37 UTC, Atmosfear wrote:
On Thursday, 15 October 2020 at 16:32:06 UTC, Imperatorn wrote:
On Thursday, 15 October 2020 at 12:45:42 UTC, Atmosfear wrote:
I didn't find how to call the queryperformancecounter
function. I tried this. Returns errors, doesn't know what
BOOL and LARGE_INTEGER are.
import core.sys.windows.windows;
import core.sys.windows.w32api;
import core.sys.windows.winbase;
pragma(lib, "kernel32");
extern (Windows)
{
BOOL QueryPerformanceCounter(LARGE_INTEGER
*lpPerformanceCount);
}
void main()
{}
It's already defined. Just use QueryPerformanceCounter, (no
extern).
I'm a newby. Can you show me an example? In which module is it?
I see. What Editor/IDE are you using btw?
If you use Visual Studio 2019 with the VisualD extension or
Visual Studio Code with the D Programming Language (code-d)
extension you can get some nice help with these kinds of things.
To the question, try this:
import std.stdio;
import core.sys.windows.winbase;
import core.sys.windows.windef;
import core.sys.windows.windows;
void main()
{
LARGE_INTEGER li;
BOOL b = QueryPerformanceCounter();
//Don't know what you're after. Defined in winnt
writeln(li.QuadPart);
readln();
}
Re: winapi, dll
On Thursday, 15 October 2020 at 20:13:37 UTC, Atmosfear wrote:
On Thursday, 15 October 2020 at 16:32:06 UTC, Imperatorn wrote:
On Thursday, 15 October 2020 at 12:45:42 UTC, Atmosfear wrote:
I didn't find how to call the queryperformancecounter
function. I tried this. Returns errors, doesn't know what
BOOL and LARGE_INTEGER are.
import core.sys.windows.windows;
import core.sys.windows.w32api;
import core.sys.windows.winbase;
pragma(lib, "kernel32");
extern (Windows)
{
BOOL QueryPerformanceCounter(LARGE_INTEGER
*lpPerformanceCount);
}
void main()
{}
It's already defined. Just use QueryPerformanceCounter, (no
extern).
I'm a newby. Can you show me an example? In which module is it?
Just import core.sys.windows.windows and call the function like
so:
---
import core.sys.windows.windows;
void main() {
LARGE_INTEGER pc;
QueryPerformanceCounter();
}
---
Re: winapi, dll
On 16/10/2020 9:13 AM, Atmosfear wrote: I'm a newby. Can you show me an example? In which module is it? You can search for it on Github and it'll show up. https://github.com/dlang/druntime/search?q=QueryPerformanceCounter
Re: winapi, dll
On Thursday, 15 October 2020 at 16:32:06 UTC, Imperatorn wrote:
On Thursday, 15 October 2020 at 12:45:42 UTC, Atmosfear wrote:
I didn't find how to call the queryperformancecounter
function. I tried this. Returns errors, doesn't know what BOOL
and LARGE_INTEGER are.
import core.sys.windows.windows;
import core.sys.windows.w32api;
import core.sys.windows.winbase;
pragma(lib, "kernel32");
extern (Windows)
{
BOOL QueryPerformanceCounter(LARGE_INTEGER
*lpPerformanceCount);
}
void main()
{}
It's already defined. Just use QueryPerformanceCounter, (no
extern).
I'm a newby. Can you show me an example? In which module is it?
Re: winapi, dll
On Thursday, 15 October 2020 at 12:45:42 UTC, Atmosfear wrote:
I didn't find how to call the queryperformancecounter function.
I tried this. Returns errors, doesn't know what BOOL and
LARGE_INTEGER are.
import core.sys.windows.windows;
import core.sys.windows.w32api;
import core.sys.windows.winbase;
pragma(lib, "kernel32");
extern (Windows)
{
BOOL QueryPerformanceCounter(LARGE_INTEGER
*lpPerformanceCount);
}
void main()
{}
It's already defined. Just use QueryPerformanceCounter, (no
extern).
Re: Why was new(size_t s) { } deprecated in favor of an external allocator?
On Thursday, 15 October 2020 at 06:39:00 UTC, Patrick Schluter wrote: On Wednesday, 14 October 2020 at 20:32:51 UTC, Max Haughton wrote: On Wednesday, 14 October 2020 at 20:27:10 UTC, Jack wrote: What was the reasoning behind this decision? Andrei's std::allocator talk from a few years ago at cppcon covers this (amongst other things) Yes, and what did he say? You seriously don't expect people to search for a random talk from a random event from a random year? It's the first result when you search for "Andrei std::allocator"
Re: Error on dub build - Trying Vibe-d for the first time
On Thursday, 15 October 2020 at 14:26:37 UTC, Steven Schveighoffer wrote: On 10/15/20 10:22 AM, Steven Schveighoffer wrote: On 10/15/20 9:55 AM, Andre Pany wrote: I meant this one: https://github.com/vibe-d/eventcore/pull/154 I testing it at the moment, while there still "leaking" warnings, the ports are released after terminating the application with Ctrl+c. So far I was not able to reproduce the issue with vibe.d 0.9.2 (eventcore 0.9.9). Soo if you try to print a warning it keeps the process alive? I can't understand how this would fix it. It is still printing too, so how could that have fixed the problem? Not fixed. I just did the same test (dub init -t vibe.d) and it fails to kill the process. Still have to kill with -9. -Steve You are right, I only tested it on Windows. Here it is working (stopping with ctrl+c and starting again) except the warnings. Kind regards Andre
Re: malloc(s)[0..s] vs cast(T)malloc(s)
On Thursday, 15 October 2020 at 01:22:54 UTC, Ali Çehreli wrote: On 10/14/20 1:15 PM, Jack wrote: >> auto x = malloc(s)[0..s]; > https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation Note that 'x' is passed to emplace() at that link and emplace() requires a slice. That's why the a slice is made from the pointer returned by malloc(). Ali make sense, thanks
Re: malloc(s)[0..s] vs cast(T)malloc(s)
On Wednesday, 14 October 2020 at 21:12:13 UTC, Paul Backus wrote: On Wednesday, 14 October 2020 at 20:15:39 UTC, Jack wrote: [...] The difference is that the first version gives you a `void[]`, and the second version gives you a `T`. Neither version does any bounds checking. Generally, you'd use the first version if you don't yet know what kind of object is going to be stored in the allocated memory (for example, if you're writing an allocator[1]), and the second version if you do know the type. [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks.html My bad, the first one doesn't perform bounds-checking.So it just depends on context, where you are going to use the result from malloc()
Re: Error on dub build - Trying Vibe-d for the first time
On 10/15/20 10:22 AM, Steven Schveighoffer wrote: On 10/15/20 9:55 AM, Andre Pany wrote: I meant this one: https://github.com/vibe-d/eventcore/pull/154 I testing it at the moment, while there still "leaking" warnings, the ports are released after terminating the application with Ctrl+c. So far I was not able to reproduce the issue with vibe.d 0.9.2 (eventcore 0.9.9). Soo if you try to print a warning it keeps the process alive? I can't understand how this would fix it. It is still printing too, so how could that have fixed the problem? Not fixed. I just did the same test (dub init -t vibe.d) and it fails to kill the process. Still have to kill with -9. -Steve
Re: Error on dub build - Trying Vibe-d for the first time
On 10/15/20 9:55 AM, Andre Pany wrote: I meant this one: https://github.com/vibe-d/eventcore/pull/154 I testing it at the moment, while there still "leaking" warnings, the ports are released after terminating the application with Ctrl+c. So far I was not able to reproduce the issue with vibe.d 0.9.2 (eventcore 0.9.9). Soo if you try to print a warning it keeps the process alive? I can't understand how this would fix it. It is still printing too, so how could that have fixed the problem? -Steve
Re: Error on dub build - Trying Vibe-d for the first time
On Thursday, 15 October 2020 at 13:17:57 UTC, Steven Schveighoffer wrote: On 10/14/20 2:25 PM, Andre Pany wrote: On Wednesday, 14 October 2020 at 18:08:40 UTC, H. S. Teoh wrote: On Wed, Oct 14, 2020 at 05:30:37PM +, Andre Pany via Digitalmars-d-learn wrote: > > [...] [...] > > [...] [...] [...] [...] Yeah, this is a problem. Things like these need to be put in the docs in an easy-to-find way. Like collected in a Troubleshooting page or something. If a bug isn't filed yet, I'd file a bug on vibe.d so that this will get resolved instead of forgotten, and then it will bite the next newcomer all over again. T https://github.com/search?q=VibeHighEventPriority=issues It seems with eventcore 0.9.9 there was some fix, but I do not know whether this solves the bug or s.th. related to the bug. Is this the commit you are talking about? https://github.com/vibe-d/eventcore/pull/122 I haven't tested turning the version definition off. But it probably should be easy enough to do a vanilla vibe-d install and see if it works. I hope this is the fix, because this bug has been a huge problem, especially for people trying vibe for the first time. -Steve I meant this one: https://github.com/vibe-d/eventcore/pull/154 I testing it at the moment, while there still "leaking" warnings, the ports are released after terminating the application with Ctrl+c. So far I was not able to reproduce the issue with vibe.d 0.9.2 (eventcore 0.9.9). Kind regards Andre
Re: Error on dub build - Trying Vibe-d for the first time
On 10/14/20 2:25 PM, Andre Pany wrote: On Wednesday, 14 October 2020 at 18:08:40 UTC, H. S. Teoh wrote: On Wed, Oct 14, 2020 at 05:30:37PM +, Andre Pany via Digitalmars-d-learn wrote: On Wednesday, 14 October 2020 at 16:39:39 UTC, Imperatorn wrote: > On Wednesday, 14 October 2020 at 15:27:46 UTC, Andre Pany > wrote: [...] > > [...] [...] > Where is this documented? I dont know whether it is documented somewhere. It was asked multiple times in the forum therefore I remembered. Maybe it could be documented in the vibe.d github wiki or on the vibe.d website. But hopefully the bug is solved soon. [...] Yeah, this is a problem. Things like these need to be put in the docs in an easy-to-find way. Like collected in a Troubleshooting page or something. If a bug isn't filed yet, I'd file a bug on vibe.d so that this will get resolved instead of forgotten, and then it will bite the next newcomer all over again. T https://github.com/search?q=VibeHighEventPriority=issues It seems with eventcore 0.9.9 there was some fix, but I do not know whether this solves the bug or s.th. related to the bug. Is this the commit you are talking about? https://github.com/vibe-d/eventcore/pull/122 I haven't tested turning the version definition off. But it probably should be easy enough to do a vanilla vibe-d install and see if it works. I hope this is the fix, because this bug has been a huge problem, especially for people trying vibe for the first time. -Steve
winapi, dll
I didn't find how to call the queryperformancecounter function. I
tried this. Returns errors, doesn't know what BOOL and
LARGE_INTEGER are.
import core.sys.windows.windows;
import core.sys.windows.w32api;
import core.sys.windows.winbase;
pragma(lib, "kernel32");
extern (Windows)
{
BOOL QueryPerformanceCounter(LARGE_INTEGER
*lpPerformanceCount);
}
void main()
{}
Re: Why was new(size_t s) { } deprecated in favor of an external allocator?
On Wed, Oct 14, 2020 at 10:30 PM Jack via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > What was the reasoning behind this decision? > https://dlang.org/deprecate.html#Class allocators and deallocators
Re: Why was new(size_t s) { } deprecated in favor of an external allocator?
On Thursday, 15 October 2020 at 06:39:00 UTC, Patrick Schluter wrote: On Wednesday, 14 October 2020 at 20:32:51 UTC, Max Haughton wrote: On Wednesday, 14 October 2020 at 20:27:10 UTC, Jack wrote: What was the reasoning behind this decision? Andrei's std::allocator talk from a few years ago at cppcon covers this (amongst other things) Yes, and what did he say? You seriously don't expect people to search for a random talk from a random event from a random year? It's quite easy to find on youtube. First result searching for "andrei std allocator": https://www.youtube.com/watch?v=LIb3L4vKZ7U The slides are also available here: https://raw.githubusercontent.com/CppCon/CppCon2015/master/Presentations/allocator%20Is%20to%20Allocation%20what%20vector%20Is%20to%20Vexation/allocator%20Is%20to%20Allocation%20what%20vector%20Is%20to%20Vexation%20-%20Andrei%20Alexandrescu%20-%20CppCon%202015.pdf
Re: Why was new(size_t s) { } deprecated in favor of an external allocator?
On Wednesday, 14 October 2020 at 20:32:51 UTC, Max Haughton wrote: On Wednesday, 14 October 2020 at 20:27:10 UTC, Jack wrote: What was the reasoning behind this decision? Andrei's std::allocator talk from a few years ago at cppcon covers this (amongst other things) Yes, and what did he say? You seriously don't expect people to search for a random talk from a random event from a random year?
