Re: repl like interface with D app
On Friday, 16 June 2017 at 18:13:33 UTC, Seb wrote:
On Friday, 16 June 2017 at 07:57:46 UTC, Mike B Johnson wrote:
I am developing a D app and I have a need to test things out.
I do not want to have to recompile the app every time I want
to test some functionality out.
[...]
There is drepl, it's not fancy, but works for basic use cases...
https://github.com/drepl/drepl
But that doesn't interface with ones own program? I'm not talking
about a standalone repl but something what can use from their own
program and then use that command line interface of it(or just
send command through text) and interact with the original program:
string foo() { writeln("foo"); }
void main()
{
repl.init();
writeln(repl.exec("foo()"));
writeln(repl.exec(readline()));
repl.OpenInterface(); // <- A new command window is open that
lets us run code from it, code that has access to this programs
code.
}
Or whatever.
Re: repl like interface with D app
On Friday, 16 June 2017 at 18:43:24 UTC, Sameer Pradhan wrote: On Friday, 16 June 2017 at 07:57:46 UTC, Mike B Johnson wrote: [...] Please check out: https://github.com/DlangScience/PydMagic/blob/master/README.md I haven't used it myself, but fits right in the Jupyter/IPython ecosystem. -- Sameer Thanks, not sure if this will work and I don't like python much, but I'll give a look at some point and see. Maybe it can be integrated back in to a D program and then work out well: D->python->D.
Re: Calling delegate in a dll callback fails silently
On Friday, 16 June 2017 at 22:17:07 UTC, Andre Pany wrote: int dgRef = cast(int) &(dg); What is the type of dg there? This looks horribly, horribly wrong to me. If it is type delegate, you took the address of a local variable, which is likely overwritten by the time the callback triggers. Moreover, even if you didn't get a pointer to local, a delegate is twice the size of a pointer and thus wouldn't fit in an int anyway... If it is a direct function reference it might work, though then you might as well just use it directly as the callback. if (auto dg = *cast(NotifyEvent*)cast(void*) reference1) This suggests you got a pointer to the pointer; an escaped reference to a local variable. If the function is called immediately, the local is still in scope and valid, but if called later, the local goes away and gets overwritten, causing the dll thread to jump into nonsense and most likely crash and die. What you want to use is a regular function with a global thing, an object reference kept alive, or a thunk. Here's one fairly simple technique you can use: https://stackoverflow.com/questions/22845175/pass-delegates-to-external-c-functions-in-d
Re: Linking external *.lib files
On Saturday, 17 June 2017 at 00:33:01 UTC, Jolly James wrote: On Saturday, 17 June 2017 at 00:09:41 UTC, Jolly James wrote: Let's assume, I have the following 2 dub packages: pkgBASE: (depends on public DUB package) source/ lib/ pkgAPP: (depends on pkgBASE) source/ I have added pkgBASE via add-path. This wasn't a problem at all. Unfortunately, the public DUB package requires to be linked with the libs from pkgBASE/lib. What do I have to add to pkgBASE's dub.json? Side-note: the lib/ should not be moved for portability reasons if this is possible My bad solution: "lflags": [ "-Llib\\" ], but this requires the lib folder to be part of pkgAPP, not pkgBASE where I would like to have it. Does anyone have an idea?
Re: Linking external *.lib files
On Saturday, 17 June 2017 at 00:09:41 UTC, Jolly James wrote: Let's assume, I have the following 2 dub packages: pkgBASE: (depends on public DUB package) source/ lib/ pkgAPP: (depends on pkgBASE) source/ I have added pkgBASE via add-path. This wasn't a problem at all. Unfortunately, the public DUB package requires to be linked with the libs from pkgBASE/lib. What do I have to add to pkgBASE's dub.json? Side-note: the lib/ should not be moved for portability reasons if this is possible
Re: Linking external *.lib files
Let's assume, I have the following 2 dub packages: pkgBASE: (depends on public DUB package) source/ lib/ pkgAPP: (depends on pkgBASE) source/ I have added pkgBASE via add-path. This wasn't a problem at all. Unfortunately, the public DUB package requires to be linked with the libs from pkgBASE/lib. What do I have to add to pkgBASE's dub.json?
Linking external *.lib files
Let's assume, I have the following 2 dub packages: pkgBASE: source/ lib/ pkgAPP:
Re: GStreamer and D
On Friday, 16 June 2017 at 16:33:56 UTC, Russel Winder wrote: gst-inspect-1.0 is an executable that comes with the installation, however that is done. What are you thinking of when saying "ported"? gst-inspect is a good demonstration of iteration through the available gstreamer elements and their options. I want to modify that code to generate a model that could be used for persisting a pipeline configuration. https://github.com/GStreamer/gstreamer/blob/master/tools/gst-inspect.c So far, I've looked up about 80 calls used in that program, and only these few don't have c aliases in the d interfaces. I haven't looked to see if these are macros, or perhaps I could be looking at an incompatible version of gst-inspect.c. Anyway, looks pretty good so far. gst_plugin_feature_get_name g_list_next g_return_if_fail g_value_get_boolean
Calling delegate in a dll callback fails silently
Hi,
my D application uses a Dll written in another language.
In my D code I retrieve the address of a delegate as integer:
int dgRef = cast(int) &(dg);
This integer I pass to a function in the dll together with the
address of a callback function.
extern(C) static void notifyEventCallback(int reference1)
{
if (auto dg = *cast(NotifyEvent*)cast(void*) reference1)
{
writeln("HERE1");
dg(null);
writeln("HERE2");
}
}
The callback function casts the integer back to the delegate
and execute it.
This scenario is working fine if in the dll function the callback
immediatelly is called. But my real scenario is not working.
The dll shows an UI and the callback should be called on a
button press in the UI.
In this scenario the callback is called, the cast is successful
and HERE1 is shown but neither the dg is called (has a dummy
writeln as coding)
nor HERE2 is shown.
I have no idea why the cast can be succesful but the call to
dg(null) is silently
failing. Do you have any idea? Maybe the UI button press runs in
another thread and causes this issue?
Kind regards
André
Re: Implementing interfaces using alias this
On Friday, 16 June 2017 at 08:34:21 UTC, Biotronic wrote: On Thursday, 15 June 2017 at 18:49:58 UTC, Jesse Phillips wrote: wrap!IDuck Ah, so it does exist in Phobos. I thought it should be there, but didn't find it. Thanks! -- Biotronic Yeah, when Andrei introduced the wrap function I was disappointed it only wrapped classes. But in truth I haven't really been using it for structs either. That may partly be because it can't wrap to the range interface.
Re: repl like interface with D app
On Friday, 16 June 2017 at 07:57:46 UTC, Mike B Johnson wrote: I am developing a D app and I have a need to test things out. I do not want to have to recompile the app every time I want to test some functionality out. Suppose I have an app with some functions like foo, bar, etc... in some module m. I would like to be able to do basic stuff like [...] or [...] etc... This way I can write the functions, compile, then test them out without compiling. e.g., [...] which turns on the 34th light in the house, then [...] which turns it off. This should take about 1-2 seconds to test RATHER than about 1m to do the compilation, running, etc. Having a history buffer would be nice too and even a debugger showing the basic state(nothing fancy). Anything like this out there. Lua has things like this that are very nice to do because they allow for quick testing and prototyping. Please check out: https://github.com/DlangScience/PydMagic/blob/master/README.md I haven't used it myself, but fits right in the Jupyter/IPython ecosystem. -- Sameer
Re: repl like interface with D app
On Friday, 16 June 2017 at 07:57:46 UTC, Mike B Johnson wrote: I am developing a D app and I have a need to test things out. I do not want to have to recompile the app every time I want to test some functionality out. [...] There is drepl, it's not fancy, but works for basic use cases... https://github.com/drepl/drepl
Re: GStreamer and D
On Fri, 2017-06-16 at 16:11 +, Jay Norwood via Digitalmars-d-learn wrote: > On Friday, 16 June 2017 at 06:45:38 UTC, Russel Winder wrote: > > Welcome to the group of people using GStreamer from D. I > > suspect I may be the only other member of that club. > > Looks like gst-inspect hasn't been ported... I'm looking at that > now. gst-inspect-1.0 is an executable that comes with the installation, however that is done. What are you thinking of when saying "ported"? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: GStreamer and D
On Friday, 16 June 2017 at 06:45:38 UTC, Russel Winder wrote: Welcome to the group of people using GStreamer from D. I suspect I may be the only other member of that club. Looks like gst-inspect hasn't been ported... I'm looking at that now.
Re: How can I make typeof(this) return the type of a calling derrived class from a function in a base class?
Thanks for the responses guys :) I ended up using a foo(this T) and it works! Thanks again for your help.
Re: How can I make typeof(this) return the type of a calling derrived class from a function in a base class?
On Friday, 16 June 2017 at 13:46:14 UTC, Lester wrote:
If I have something like the following:
class A {
void foo(){ writeln(typeof(this)); }
try one of these:
http://dlang.org/spec/template.html#TemplateThisParameter
Though note that the this in there is still the static type at
the usage point. So:
B b = new B;
b.foo; // B, because it is called through a B
but
A b = new B;
b.foo; // A, because it is called through the A interface
You can also do runtime stuff with typeid/classinfo (they return
the same thing) or simply override the function in the child
class (often preferred). Depends on exactly what you need it for.
Re: How can I make typeof(this) return the type of a calling derrived class from a function in a base class?
On Friday, 16 June 2017 at 13:46:14 UTC, Lester wrote:
If I have something like the following:
class A {
void foo(){ writeln(typeof(this)); }
...
}
class B : A {
...
}
And I want the results:
A a = new A;
B b = new B;
a.foo(); // prints "A"
b.foo(); // prints "B"
How would I go about doing that? At the moment b.foo() is
printing "A".
What about something like this?
class A {}
class B : A {}
void foo(T)(T object) {
import std.stdio : writeln;
writeln(object.classinfo.toString); // you can use whatever
property you want...
}
void main()
{
A a = new A;
B b = new B;
a.foo(); // prints "test.A"
b.foo(); // prints "test.B"
}
How can I make typeof(this) return the type of a calling derrived class from a function in a base class?
If I have something like the following:
class A {
void foo(){ writeln(typeof(this)); }
...
}
class B : A {
...
}
And I want the results:
A a = new A;
B b = new B;
a.foo(); // prints "A"
b.foo(); // prints "B"
How would I go about doing that? At the moment b.foo() is
printing "A".
Re: Implementing interfaces using alias this
On Thursday, 15 June 2017 at 18:49:58 UTC, Jesse Phillips wrote: wrap!IDuck Ah, so it does exist in Phobos. I thought it should be there, but didn't find it. Thanks! -- Biotronic
repl like interface with D app
I am developing a D app and I have a need to test things out. I do not want to have to recompile the app every time I want to test some functionality out. Suppose I have an app with some functions like foo, bar, etc... in some module m. I would like to be able to do basic stuff like writeln(m.foo()); or auto x = m.bar() + 3; etc... This way I can write the functions, compile, then test them out without compiling. e.g., m.FlipLightSwitch(34); which turns on the 34th light in the house, then m.FlipLightSwitch(34); which turns it off. This should take about 1-2 seconds to test RATHER than about 1m to do the compilation, running, etc. Having a history buffer would be nice too and even a debugger showing the basic state(nothing fancy). Anything like this out there. Lua has things like this that are very nice to do because they allow for quick testing and prototyping.
