Can nice D code get a bit slow?
Hi, sorry for the broad and vague question. I have read in some reddit post about benchmarks, that some code didn't use the final keyword on methods in a sense that final would make it faster, I believe. I thought, without any D knowledge, it could be that with shorter code I might create virtual calls by accident. It might in some rare case have an impact on performance, but it might - on the good side - be the optimizer of one of the three compilers that puts that handling of maybe-virtual calls away or whatever might happen. So, having no clue about D (just bought some books), I wanted to ask if nice looking code can become slow, in general. In the mentioned case it's just that I like the packaging of functions into some sort of scope (OOP) versus the flat C and Go stuff. I like OOP for this reason, but now I'm unsure whether I might stay out of creating classes at all. I do like to write 'in' and 'ref' keywords at their places, for maybe creating some little speed benefits and safety, but the 'final' keyword I then might write because I opted in into OOP looks, for just the visual reason. Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of. Kind regards
Re: I want an exception message but my threaded callback just dies or crashes
On Tuesday, 11 June 2019 at 05:15:17 UTC, Markus wrote:
I have cleaned it up, kind of. Just in case you want to compile
it. The Zip contains some DLL from
https://github.com/spatialaudio/portaudio-binaries where you
can find the original if you want.
https://gofile.io/?c=NpUxrJ
I'm in general thinking of buying a Mac. I know it has not much
to do with this, but debugging Swift code in Xcode must be so
"gorgeous" as they say.
1) So, I've made it work. Using a global in the test.d for
sharing between threads was no good idea it seems. It's just that
I tend to do it because you will not end up passing arguments so
much. But the shared keyword forced me to add D-atomic code, so I
gave that up early and made it passing (borrowing?) the
context/custom-data as argument, not being in global scope.
2) Second thing is, I removed collectException, because I was
unable to do with it what it seems to be good for. I replaced it
with another function call to a function that uses a try block,
and assumeNoThrow goes around that function call.
I'm a bit confused but it works (can print Exceptions). :) The
changes look like this:
test.d:
auto stream = start_portaudio(44100, 512,
&on_audio_buffer,cast(void*)sine_sound);
// 1) pass around sine_sound, or anything that looks like a global
portaudio.d:
void on_audio_buffer_2(int frames, float* left, float* right,
paTestData* data)
{
// 2)
try
{
data.callback(
data.frames_per_buffer,
&data.left_buf[0],
&data.right_buf[0],
data.mydata);
}
catch(Throwable e)
{
writefln("e==%s",e.toString);
TerminateProcess(GetCurrentProcess(), 0);
}
}
extern(C) nothrow int patestCallback()
{
// 2) call the function that uses the try block
assumeWontThrow(
on_audio_buffer_2(
data.frames_per_buffer,
&data.left_buf[0],
&data.right_buf[0],
data));
}
Re: I want an exception message but my threaded callback just dies or crashes
I have cleaned it up, kind of. Just in case you want to compile it. The Zip contains some DLL from https://github.com/spatialaudio/portaudio-binaries where you can find the original if you want. https://gofile.io/?c=NpUxrJ I'm in general thinking of buying a Mac. I know it has not much to do with this, but debugging Swift code in Xcode must be so "gorgeous" as they say.
I want an exception message but my threaded callback just dies or crashes
Hi, when you use core.windows and LoadLibrary to load a DLL, and
that DLL will create a new thread and inside that it will call
back into your D app, is there something to special to be aware
of?
I've done it like with the CreateWindow and WndProc, but this
time I'm loading a compiled portaudio DLL and I give it a call
back. And I try to catch errors, but no matter what D Exception
(I tried out of range and null dereferencing) that thread seems
to either die silently (no hints in my console) or somehow fail
to make portaudio go on calling (I don't think so).
I just wanted to ask if you know any pitfall with this... I'll go
on using windbg and looking at things. I guess I should post a
complete project, but I have to clean it up, and you maybe don't
want to execute that portaudio32bit.dll from some unknown github
account.
The function for Portaudio looks like that:
extern(C) nothrow int patestCallback(
const void* inputBuffer,
void* outputBuffer,
uint framesPerBuffer,
const PaStreamCallbackTimeInfo* timeInfo,
PaStreamCallbackFlags statusFlags,
void* userData)
{
auto data = cast(paTestData*)userData;
auto out_ = cast(float*)outputBuffer;
auto ce = collectException(
data.callback(
data.frames_per_buffer,
&data.left_buf[0],
&data.right_buf[0]));
if(ce !is null)
{
assumeWontThrow(writeln(ce.toString));
TerminateProcess(GetCurrentProcess(), 0);
} else
{
assumeWontThrow(writeln("ce is null"));
}
for(uint i = 0; i < framesPerBuffer; ++i)
{
*out_++ = data.left_buf[i];
*out_++ = data.right_buf[i];
}
return PaStreamCallbackResult.paContinue;
}
...
...
I give it to Portaudio like that
{ auto err = Pa_OpenStream(
&stream,
null,
&outputParameters,
frames_per_second,
frames_per_buffer,
paClipOff,
&patestCallback,
&data);
Re: How can I get a backtrace when my WndProc throws?
On Monday, 3 June 2019 at 12:09:18 UTC, Adam D. Ruppe wrote: Don't use just e.msg, that's just the string the constructor sent, use e.toString and see if it works for you. toString works, thanks! :)
How can I get a backtrace when my WndProc throws?
Hi, I'm using core.sys.windows.windows to make a Windows GUI, and
the WindowProc must be nothrow. My code does not provide me a
stack backtrace when some exception is thrown in there. I would
like to have at least the number of the line that caused a throw,
has anyone an idea how to do this? Thanks for reading.
Below is the code for the Windows application. I guess I need to
improve window_procedure_nothrow() somehow.
import std;
import core.sys.windows.windows;
HWND main_window;
LRESULT window_procedure(
HWND hwnd,
uint msg,
WPARAM wparam,
LPARAM lparam)
{
if(msg == WM_CLOSE)
{
PostQuitMessage(0);
return 0;
}
if(msg == WM_KEYDOWN)
{
format("%d", 0.5); // trigger an exception
format("%d", 0.7);
}
return DefWindowProc(hwnd, msg, wparam, lparam);
}
extern(Windows) LRESULT window_procedure_nothrow(
HWND hwnd,
uint msg,
WPARAM wparam,
LPARAM lparam) nothrow
{
// this prints only a line number from within this function
// and some stack backtrace of functions outside the window
procedure
if(0)
{
return assumeWontThrow(window_procedure(hwnd, msg, wparam,
lparam));
}
// this prints no line number at all
// can get only the exception message from
collectException().msg
if(1)
{
LRESULT result;
auto ce = collectException(
window_procedure(hwnd, msg, wparam, lparam),
result);
if(ce !is null)
{
assumeWontThrow(writeln(ce.msg));
TerminateProcess(GetCurrentProcess(), 0);
}
return result;
}
}
void main()
{
WNDCLASSEX wndclassex = {
style: 0,
lpfnWndProc: &window_procedure_nothrow,
lpszClassName: "a",
hInstance: GetModuleHandle(null),
hIcon: LoadIcon(null, MAKEINTRESOURCE(32517)),
hCursor: LoadCursor(null, MAKEINTRESOURCE(32512)) };
ATOM windowclass = RegisterClassEx(&wndclassex);
assert(windowclass != 0);
main_window = CreateWindowEx(
0,
"a",
"test",
WS_OVERLAPPEDWINDOW | WS_VISIBLE,
100,
100,
200,
200,
null,
null,
GetModuleHandle(null),
null);
assert(main_window != null);
for(;;)
{
MSG msg;
int ret = GetMessage(&msg, null, 0, 0);
if(ret == 0) break;
assert(ret != -1);
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
Re: getopt defaultGetoptPrinter is not safe. Is there a reason for that?
On Friday, 17 August 2018 at 08:09:52 UTC, Markus wrote: I wonder what's the reason for that? I wonder why it's not at least @trusted. Literally, can't I trust that method/function?
getopt defaultGetoptPrinter is not safe. Is there a reason for that?
Hi. I'm a big fan of @safe code. But within my first 20 program lines I already run into problems: Error: @safe function D main cannot call @system function std.getopt.defaultGetoptPrinter https://dlang.org/phobos/std_getopt.html#.defaultGetoptPrinter I wonder what's the reason for that? Cheers Markus
Re: Visual D >> TRACKER : error TRK0004: Failed to locate: "FileTracker32.dll". The system cannot find the file specified.
On Tuesday, 21 November 2017 at 04:39:52 UTC, A Guy With a Question wrote: I'm trying to learn D using Visual D in Visual Studio Community 2015. Both dmd and ldc give me this error when building from Visual Studio. Any ideas? I'm able to build C++ projects... I had to update "Visual Studio 2015 Update 2" to "Visual Studio 2015 Update 3" to resolve that issue.
Re: interfacing c++
another indicator (as documented) that GC destructor won't work // extern(C++) classes don't have a classinfo pointer in their vtable so the GC can't finalize them https://github.com/dlang/druntime/blob/3d8d4a45c01832fb657c16a656b6e1566d77fb21/src/rt/lifetime.d#L90 annoying :( Markus
Re: interfacing c++
On Wednesday, 22 November 2017 at 08:43:54 UTC, drug wrote: 22.11.2017 02:12, Markus пишет: What about dtor - you allocate class using D GC but try to destroy it manually - namely this I guess gives you an error in rt_finalize2 because it tries to destroy object that has been destroyed. hmm... I'm not sure. I compiled dmd and it's druntime in debug and I'm stepping through it. Seems there has to be a "ClassInfo" filled with data. In my case it's filled with garbage. So the call ClassInfo.destructor fails, because destructor is an invalid pointer. The GC.collect works, but doesn't call the destructor. https://github.com/dlang/druntime/blob/3d8d4a45c01832fb657c16a656b6e1566d77fb21/src/rt/lifetime.d#L1391 I know constructors and destructors are not supported. And I get that point for move/copy... constructors. But I don't get it for simple construction and destruction. Markus
interfacing c++
hi, im trying to interface a cpp class. I'd like to interface a
bigger library and I'm trying to figure out the minimum effort.
--- c++ part:
#include
class some_class {
public:
static some_class* __ctor();
some_class();
~some_class();
void some_method();
};
some_class* some_class::__ctor() {
auto thiz = new some_class();
std::cout << "hello from __ctor, thiz:" << thiz << std::endl;
return thiz;
}
some_class::some_class() { std::cout << "some_class constructor,
this:" << this << std::endl; }
some_class::~some_class() { std::cout << "some_class destructor,
this:" << this << std::endl; }
void some_class::some_method() {
std::cout << "some_class some_method, this:" << this <<
std::endl;
}
--- d part:
extern (C++) {
class some_class {
final this();
final ~this();
final void some_method();
}
}
void main() {
some_class someClass = new some_class(); // works, __ctor()
gets called, and it calls the constructor.
someClass.some_method; // works
destroy(someClass); // crashes (SIGSEGV) inside lifetime.d
rt_finalize2()
}
---
OS: ubuntu 17.10
compiler: DMD64 D Compiler v2.077.0
I could do the instancing/destruction by functions and write a
custom d class that calls these methods in this()/~this(). But I
was hoping not needing to write a class in D AND in cpp. and i
was hoping to save another step/level of instancing.
Any idea how to make the destructor of cpp compatible with
"~this()"?
Thx in advance
Markus
