Re: Passing C++ class to DLL for callbacks from D (Steam)
On Sunday, 10 June 2018 at 01:35:40 UTC, cc wrote: On Saturday, 9 June 2018 at 14:11:13 UTC, evilrat wrote: However steam devs decided to shield actual pointer and return pointer sized integer when C API is used(or they just screw up?). Anyway, the pointers for subsystems returned by context calls on C++ API and mirrored C API calls are different, but they also have some mechanism for filtering this stuff, that way both integer handle and pointer calls the same underlying implementation, but C API call again is shielded so setting up CallResult and CCallback are ignored. So my solution was just to make simple wrapper around C++ context calls and pass that real pointer to D side. I see, thank you for checking it out. Is it only the functions that return the interface pointers e.g. ISteamUserStats that need to be wrapped to use the class-based versions instead of the steam_api_flat versions? Or does the entire callback system need to be handled through the wrapper? Only subsystems getters like SteamUser() or SteamInventory() requires wrapping. I really can't understand why they ever choose to silently ignore registering callbacks received with C API systems handles...
Re: WTF! new in class is static?!?!
On Sunday, 10 June 2018 at 01:27:50 UTC, bauss wrote: On Saturday, 9 June 2018 at 12:40:07 UTC, RealProgrammer wrote: maybe you and others in the D 'community' should start paying attention to the 'opinions' of those who do professional development with professional compilers. I do professional work with a professional compiler aka. The D compiler and I've been doing so for years. Well then, you should like my idea for the dconf '2019' logo... Dman and a bug, holding hands, and the bug saying "I'm not a bug, I'm a feature!".
Re: Passing C++ class to DLL for callbacks from D (Steam)
On Saturday, 9 June 2018 at 14:11:13 UTC, evilrat wrote: However steam devs decided to shield actual pointer and return pointer sized integer when C API is used(or they just screw up?). Anyway, the pointers for subsystems returned by context calls on C++ API and mirrored C API calls are different, but they also have some mechanism for filtering this stuff, that way both integer handle and pointer calls the same underlying implementation, but C API call again is shielded so setting up CallResult and CCallback are ignored. So my solution was just to make simple wrapper around C++ context calls and pass that real pointer to D side. I see, thank you for checking it out. Is it only the functions that return the interface pointers e.g. ISteamUserStats that need to be wrapped to use the class-based versions instead of the steam_api_flat versions? Or does the entire callback system need to be handled through the wrapper?
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 12:40:07 UTC, RealProgrammer wrote: maybe you and others in the D 'community' should start paying attention to the 'opinions' of those who do professional development with professional compilers. I do professional work with a professional compiler aka. The D compiler and I've been doing so for years.
Re: How to task pool in vibe.d?
On Saturday, 9 June 2018 at 15:11:02 UTC, Computermatronic wrote: I'd like to create a bunch of tasks in vibe.d, then wait for them all to complete. Using std.concurrency and std.parallelism this is trivial. I could just spawn a bunch of vibe.d tasks and then iteratively join them, but I would think vibe.d would provide some primitives for task-pooling. Yes. https://vibed.org/api/vibe.core.taskpool/TaskPool
Re: delegates and functions
On 06/09/2018 02:09 PM, OlegZ wrote: On Saturday, 9 June 2018 at 20:55:21 UTC, drug wrote: In fact using `=>` you really define a function returning delegate. I see. Thanks. There is some explanation at the following page, of how the lambda syntax is related to the full syntax: http://ddili.org/ders/d.en/lambda.html#ix_lambda.=%3E Ali
Re: delegates and functions
On Saturday, 9 June 2018 at 20:55:21 UTC, drug wrote: In fact using `=>` you really define a function returning delegate. I see. Thanks.
Re: delegates and functions
On 09.06.2018 23:39, OlegZ wrote:
On Saturday, 9 June 2018 at 20:03:15 UTC, OlegZ wrote:
auto hz = (string s) => { writeln( s ); return cast( int )s.length; }
How I should to write lambda of type "int delegate( string )?
I found one way:
auto hz = delegate int( string s ) { writeln( s ); return cast( int
)s.length; };
but still don't understand why
return cast( int )s.length;
at topmost line returns "int delegate()" not just int?
just remove `=>`, either:
```
auto hz = (string s) { writeln( s ); return cast( int )s.length; }
```
or
```
auto hz = (s) => writeln( s );
```
In fact using `=>` you really define a function returning delegate.
```
auto hz = (string s) => { writeln( s ); return cast( int )s.length; }
```
is equivalent to
```
auto hz = (string s) {
return () {writeln( s ); return cast( int )s.length;}
}
```
Re: delegates and functions
On Saturday, 9 June 2018 at 20:03:15 UTC, OlegZ wrote:
auto hz = (string s) => { writeln( s ); return cast( int
)s.length; }
How I should to write lambda of type "int delegate( string )?
I found one way:
auto hz = delegate int( string s ) { writeln( s ); return cast(
int )s.length; };
but still don't understand why
return cast( int )s.length;
at topmost line returns "int delegate()" not just int?
delegates and functions
I want "int delegate( string )", but hz most probably is "int
function( string )"
auto hz = (string s) => { writeln( s ); return cast( int
)s.length; };
but
pragma (msg, typeid( (string s) => { writeln( s ); return cast(
int )s.length; }));
shows
typeid( int delegate() @safe function(string s) pure nothrow
@safe )
Why my lambda is function(string) that returns int delegate()?
How I should to write lambda of type "int function( string )"?
And how I should to write lambda of type "int delegate( string )"?
Re: WTF! new in class is static?!?!
On Friday, 8 June 2018 at 18:18:27 UTC, Jonathan M Davis wrote:
On Thursday, June 07, 2018 22:43:50 aliak via
Digitalmars-d-learn wrote:
On Thursday, 7 June 2018 at 21:32:54 UTC, Jonathan M Davis
wrote:
> [...]
Is that supposed to compile? -> https://run.dlang.io/is/SjUEOu
Error: cannot use non-constant CTFE pointer in an initializer
&[42][0]
Not necessarily. It's the pointer equivalent of what the OP did
with a mutable class reference, and I was using it for
demonstrative purposes. The mutable class reference case didn't
used to compile (it used to have to be immutable). This example
is just the logic of what happens if it's legal with pointers
too. If it hasn't been changed to be legal with pointers like
it has been with classes, then that's arguably a good thing.
- Jonathan M Davis
Boh, it seems it actually has, just not with primitive types it
seems:
struct A {
int i = 3;
}
struct B {
auto a = new A(3);
}
Above compile fine :o
How to task pool in vibe.d?
I'd like to create a bunch of tasks in vibe.d, then wait for them all to complete. Using std.concurrency and std.parallelism this is trivial. I could just spawn a bunch of vibe.d tasks and then iteratively join them, but I would think vibe.d would provide some primitives for task-pooling.
Re: Passing C++ class to DLL for callbacks from D (Steam)
On Saturday, 9 June 2018 at 03:14:13 UTC, cc wrote:
On Saturday, 9 June 2018 at 03:07:39 UTC, cc wrote:
I've put together a simplified test program here (124KB):
Here is a pastebin of the D source file updated with some
additional comments at the end with the callback class
definitions from the original header files
https://pastebin.com/M8hDXt6L
The proper bare minimum signature for call result callback is
--
extern(C++) abstract class CCallbackBase {
abstract void Run( void *pvParam ) { writeln("Run()"); }
abstract void Run( void *pvParam, bool bIOFailure,
SteamAPICall_t hSteamAPICall );
final int GetICallback() { return m_iCallback; } // this is
actually optional
abstract int GetCallbackSizeBytes();
protected:
uint8 m_nCallbackFlags; // probably can be left for some
specific use cases
int m_iCallback;
}
--
and the rest templates and stuff is purely for C++ convenience.
Run(void*, bool, SteamAPICall_t) is what actually called for call
result, then CallResult<> template overrides it to call
appropriate pointer member in class with void (T::fun)(Data*,
bool bIOFailure) signature. You can mimic it on D side, or just
ignore and make own.
There is one catch however, for it to be called flags should be
equal 1, and iCallback must match struct enum, like
NumberOfCurrentPlayers_t.k_iCallback for
GetNumberOfCurrentPlayers()
However steam devs decided to shield actual pointer and return
pointer sized integer when C API is used(or they just screw up?).
Anyway, the pointers for subsystems returned by context calls on
C++ API and mirrored C API calls are different, but they also
have some mechanism for filtering this stuff, that way both
integer handle and pointer calls the same underlying
implementation, but C API call again is shielded so setting up
CallResult and CCallback are ignored.
So my solution was just to make simple wrapper around C++ context
calls and pass that real pointer to D side.
--- C++ code
// build as static library & link with your project
#ifdef _WIN32
// sorry, I just hardcoded it...
#pragma comment (lib, "steam_api64.lib")
#define _CRT_SECURE_NO_WARNINGS 1
#endif
#include "public/steam/steam_api.h"
#ifdef _WIN32
#define _CRT_SECURE_NO_WARNINGS 1
#endif
extern "C" void* D_GetSteamUserStats()
{
return SteamUserStats();
}
--- D code
// yes, I messed up with the signature to avoid casting, this may
or may not be dangerous
extern(C) ISteamUserStats D_GetSteamUserStats();
This of course involves making C++ wrapper, but I don't really
see other ways because they inlined everything ...
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 13:49:48 UTC, 12345swordy wrote: No, because you been caught making imposter accounts left and right. Which btw we can tell as your poor attempts to imposter me. Well... why ya all r busy havin a go at me, the bugs remains (as do all D'other bugs).
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 13:24:49 UTC, KingJoffrey wrote: On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole wrote: But unlike you "king", Bauss isn't using tor to ban evade. why you wanna ban little old me? is it cause I made a crticism of D? No, because you been caught making imposter accounts left and right. Which btw we can tell as your poor attempts to imposter me.
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole wrote: But unlike you "king", Bauss isn't using tor to ban evade. why you wanna ban little old me? is it cause I made a crticism of D? did i hurt your feelings? ..and everyone I know uses tor - and you should too - whether you're evading something or not - otherwise tor has no value - cause sites will just block tor - and then all those people that use tor for advancing human rights around the world, will lose the platform they need to do that, without being persecuted, cause they criticised something.
Re: WTF! new in class is static?!?!
But unlike you "king", Bauss isn't using tor to ban evade.
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 11:47:54 UTC, bauss wrote: Nobody cares about your opinion. Nobody is forcing you to write code like that. In fact most programs will be written without such code, for good reason. Regardless if it does the "correct" thing or not. Dude. That response is so childish. Don't speak to people like that. And given that no mainstream compiler would allow you to share mutable data like that, maybe you and others in the D 'community' should start paying attention to the 'opinions' of those who do professional development with professional compilers.
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 09:24:48 UTC, KingJoffrey wrote:
On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer
wrote:
Yep, long-standing issue:
https://issues.dlang.org/show_bug.cgi?id=2947
Almost a decade old!
-Steve
Another reason why I still refuse to bring my code to D.
As if the module not respecting class encapsulation was not
enough (see my rants about it elsewhere), D even allows two
class instances to share non static mutable data!!
wtf!
--
import std.stdio;
class A
{
int[] c = [3,3];
}
void main()
{
A ca = new A;
A cb = new A;
ca.c[0] = 44;
writeln(cb.c[0]);
// prints 44 (in C++, Java and C#, this would -
correctly - print 3)
}
---
Nobody cares about your opinion.
Nobody is forcing you to write code like that.
In fact most programs will be written without such code, for good
reason.
Regardless if it does the "correct" thing or not.
Re: Is DWT busted?
On Friday, 8 June 2018 at 05:00:57 UTC, TheGag96 wrote: I'm sorry about bringing this into here instead of DWT's subforum, but it's somewhat dead and hasn't been getting a lot of attention. I decided to finally play around with DWT today and tried to build the example. It's a known bug. I opened it on GitHub for kubuntu.
Re: WTF! new in class is static?!?!
On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer
wrote:
Yep, long-standing issue:
https://issues.dlang.org/show_bug.cgi?id=2947
Almost a decade old!
-Steve
Another reason why I still refuse to bring my code to D.
As if the module not respecting class encapsulation was not
enough (see my rants about it elsewhere), D even allows two class
instances to share non static mutable data!!
wtf!
--
import std.stdio;
class A
{
int[] c = [3,3];
}
void main()
{
A ca = new A;
A cb = new A;
ca.c[0] = 44;
writeln(cb.c[0]);
// prints 44 (in C++, Java and C#, this would - correctly
- print 3)
}
---
Re: Is DWT busted?
On Friday, 8 June 2018 at 05:00:57 UTC, TheGag96 wrote: I'm sorry about bringing this into here instead of DWT's subforum, but it's somewhat dead and hasn't been getting a lot of attention. I decided to finally play around with DWT today and tried to build the example. I got this: Performing "debug" build using /usr/bin/dmd for x86_64. dwt:base 1.0.1+swt-3.4.1: target for configuration "library" is up to date. dwt 1.0.1+swt-3.4.1: target for configuration "linux-gtk" is up to date. main ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. Running ./main Program exited with code -11 I'm on Pop!_OS (basically Ubuntu), x64, DMD 2.079.0. Every library they ask for is installed. I tried cloning the source and building their snippets, and none of them work. Other people have apparently had this same problem for the past few months, and none of them find a solution. What's going on here? IDK if this is any help, but here's the backtrace according to gdb: https://pastebin.com/Xd46YwwP Go to Gtk+ or Qt. They really work.
