Re: DLL creation fails with undefined symbol error
On Friday, 26 April 2019 at 14:20:24 UTC, dokutoku wrote: Error: linking with LLD failed C:\ldc\bin\ldc2.exe failed with exit code 1. Ok, I have Visual Studio and SDKs installed so it works for me without touching anything else. In your case it is using lld linker instead, and I have no idea what libs it requires.
Re: GtkD slows down visual D keyboard
On Friday, 26 April 2019 at 14:50:17 UTC, Mike Wey wrote:
On 26-04-2019 10:31, Amex wrote:
When debugging under visual D, the keyboard response is slowed
down to the extreme. This is a Gtk issue I believe. It only
has to do with the keyboard.
For example, if I hit F10 to step, it takes the ide about 10
seconds to "respond" and move to the next line... yet the
mouse can access stuff instantaneous.
I believe Gtk or GtkD is slowing down the keyboard input
somehow and for some reason making debugging apps a nightmare
since it literally takes about 100 times longer to debug than
it should.
searching google reveals:
https://github.com/Microsoft/vcpkg/issues/4529
https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html
"You somehow break keyboard shortcuts during debugging in VS
if the application you're debugging is registering a callback
with "SetWindowsHookEx" from user32.dll with hook ID
"WH_KEYBOARD_LL".
Don't call it in debug builds or add "if
(!Debugger.IsAttached)" in front of the call to
"SetWindowsHookEx" if the debugger is attached before the
function is called.
This brings debugging with keyboard back to the same speed as
with the UI buttons for our application."
This seems to be an issue with Gtk. I'm not sure if GtkD can
do anything about it. Maybe somehow reroute the keyboard
handler(first remove it from the hook then call it manually or
reduce the number of calls to it).
I can confirm that gtk call "SetWindowsHookEx" with the
"WH_KEYBOARD_LL" ID upon initialization.
As far as i can tell it doesn't provide a way to skip this.
Could you unhook it and manually call it or simply disable it
when the app is being debugged? essentially just wrap it with a
new hook that selectively calls it.
NewHook()
{
if (notdebugbreak) OldHook
}
Keyboard input doesn't need to happen to the app while in one is
in the debugger so the hook doesn't need to be called.
This requires two things:
1. To be able to get the hook of the function and remove it.
(this might be hard)
2. Know when in debug mode. This should be somewhat easy since
I'm sure Visual Studio sets some flag when broke in to a program.
Alternatively one could add a function that forces disabling
where one could call it in code that they are debugging(which
hopefully doesn't require keyboard input). I rarely am debugging
keyboard stuff so I'd just call it at the start of the program
and benefit from it... and if I have to do keyboard stuff I'll
enable it and suffer... but at least I'll have some control over
the problem.
Re: Does D have a tool like pySnooper?
On Friday, 26 April 2019 at 16:59:15 UTC, H. S. Teoh wrote:
On Fri, Apr 26, 2019 at 02:33:16PM +, Taylor Hillegeist via
Digitalmars-d-learn wrote:
On Friday, 26 April 2019 at 10:22:49 UTC, Bastiaan Veelo wrote:
[...]
> Proofing the concept:
> ---
> mixin(snoop(q{
> int fun(int a, int b)
> {
> int c = 3;
> foreach (i; 1 .. 5)
> {
> a += i;
> }
> int d = a + b + c;
> return d;
> }
> }));
> ---
>
> Output:
> 2019-Apr-26 10:33:46.0935135 executed line 7: int c
> = 3;
> 2019-Apr-26 10:33:46.0936716 executed line 10: a
> += i;
> 2019-Apr-26 10:33:46.0937348 executed line 10: a
> += i;
> 2019-Apr-26 10:33:46.0937963 executed line 10: a
> += i;
> 2019-Apr-26 10:33:46.0938583 executed line 10: a
> += i;
> 2019-Apr-26 10:33:46.0939622 executed line 12: int d
> = a + b +
> c;
Now *this* is some seriously cool stuff.
Thanks!
A limitation is that snoop() needs to be pure. At one time I had
a byLine in there, but for some reason byLine is not pure so that
didn't work. I was almost about to see if I could use libdparse
in it (run.dlang.io supports it) but I should spend my time on
preparing for DConf instead... Feel free to play with it, this
stuff is fun!
Bastiaan.
Re: OSX DStep / Standard Includes
On 2019-04-26 17:14, Robert M. Münch wrote: I'm trying the new DStep version but have some problems with standard include files: => dstep --output ./d -v -I/opt/local/libexec/llvm-5.0/include/c++/v1 myinclude.h clang version 5.0.2 (tags/RELEASE_502/final) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: ignoring nonexistent directory "/usr/include" #include "..." search starts here: #include <...> search starts here: /opt/local/libexec/llvm-5.0/include/c++/v1 /8542414 /usr/local/include /opt/local/libexec/llvm-5.0/lib/clang/5.0.2/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. /opt/local/libexec/llvm-5.0/include/c++/v1/string.h:61:15: fatal error: 'string.h' file not found So I'm wondering what this "'string.h' file not found" means as the file seems to be found... any ideas? You need to install the Xcode command line tools, by running "xcode-select --install". This will create the "/usr/include" directory. I'm guessing this is because DStep is linked against the open source version of Clang and not the one provided by Apple. The one provided by Apple might be built/configured differently. -- /Jacob Carlborg
Re: Does D have a tool like pySnooper?
On Fri, Apr 26, 2019 at 02:33:16PM +, Taylor Hillegeist via
Digitalmars-d-learn wrote:
> On Friday, 26 April 2019 at 10:22:49 UTC, Bastiaan Veelo wrote:
[...]
> > Proofing the concept:
> > ---
> > mixin(snoop(q{
> > int fun(int a, int b)
> > {
> > int c = 3;
> > foreach (i; 1 .. 5)
> > {
> > a += i;
> > }
> > int d = a + b + c;
> > return d;
> > }
> > }));
> > ---
> >
> > Output:
> > 2019-Apr-26 10:33:46.0935135 executed line 7: int c = 3;
> > 2019-Apr-26 10:33:46.0936716 executed line 10: a += i;
> > 2019-Apr-26 10:33:46.0937348 executed line 10: a += i;
> > 2019-Apr-26 10:33:46.0937963 executed line 10: a += i;
> > 2019-Apr-26 10:33:46.0938583 executed line 10: a += i;
> > 2019-Apr-26 10:33:46.0939622 executed line 12: int d = a + b +
> > c;
Now *this* is some seriously cool stuff.
[...]
> [...] Tools like this can really help new users, especially when they
> are doing things the o'l fashion way, printf for debugging.
I debug using printf/writeln too. As Nick would say, it gives you a
fully-rewindable log of what actually happened in the code, and is often
useful where a full debugger wouldn't be able to run (e.g., on embedded
platforms with tight memory/CPU constraints).
That, and also that D debugger support is currently rather anemic; in
gdb, for example, many symbols are not recognized and/or their values
are inaccessible. Stacktraces are supposed to give line numbers, but I
haven't seen those in a while, even with -g. (At least it now gives at
least the (mangled) function names; it used to be just a bunch of hex
addresses that you have to decipher yourself.) I would contribute to
debugger support, but unfortunately I don't actually use debuggers often
enough to warrant the effort.
> I doubt it would be too much help for things like ranges, but one must
> pick their battles.
[...]
If you're talking about UFCS chains, there's std.range.tee that lets you
see what's going on in the middle of the chain without changing the type
required for the next step in the pipeline. It's not as convenient, but
a LOT better than having to split up a long UFCS chain just to insert
debug code.
T
--
Life is complex. It consists of real and imaginary parts. -- YHL
Re: DMD different compiler behaviour on Linux and Windows
On Friday, 26 April 2019 at 15:48:51 UTC, Ron Tarrant wrote: On Thursday, 25 April 2019 at 20:38:31 UTC, Mike Parker wrote: If you compile with -m32 on Windows the error goes away. Not trying to be a but it also works with -m64 on Windows. Yes, thanks. That's a typo. -m32, where size_t is uint, is the default. In -m64, size_t is ulong.
Re: DMD different compiler behaviour on Linux and Windows
On Thursday, 25 April 2019 at 20:38:31 UTC, Mike Parker wrote: If you compile with -m32 on Windows the error goes away. Not trying to be a but it also works with -m64 on Windows.
OSX DStep / Standard Includes
I'm trying the new DStep version but have some problems with standard include files: => dstep --output ./d -v -I/opt/local/libexec/llvm-5.0/include/c++/v1 myinclude.h clang version 5.0.2 (tags/RELEASE_502/final) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: ignoring nonexistent directory "/usr/include" #include "..." search starts here: #include <...> search starts here: /opt/local/libexec/llvm-5.0/include/c++/v1 /8542414 /usr/local/include /opt/local/libexec/llvm-5.0/lib/clang/5.0.2/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. /opt/local/libexec/llvm-5.0/include/c++/v1/string.h:61:15: fatal error: 'string.h' file not found So I'm wondering what this "'string.h' file not found" means as the file seems to be found... any ideas? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: GtkD slows down visual D keyboard
On 26-04-2019 10:31, Amex wrote: When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it). I can confirm that gtk call "SetWindowsHookEx" with the "WH_KEYBOARD_LL" ID upon initialization. As far as i can tell it doesn't provide a way to skip this. -- Mike Wey
Re: Does D have a tool like pySnooper?
On Friday, 26 April 2019 at 10:22:49 UTC, Bastiaan Veelo wrote:
On Friday, 26 April 2019 at 08:35:57 UTC, Bastiaan Veelo wrote:
On Thursday, 25 April 2019 at 08:44:14 UTC, Dennis wrote:
On Monday, 22 April 2019 at 16:24:53 UTC, Taylor Hillegeist
wrote:
Or would this not be easy at all with D?
I don't think so. While there are lots of traits for
introspection of declarations, there is no way to introspect
lines of code. The whole function
would need to be wrapped into a mixin, and the D code would
need to be parsed
at compile time for this to work.
Yes, but I think that might be doable. You wouldn't need a
full blown D parser, just one that can identify statements
(`;` being an important clue). Not sure whether __LINE__ will
be meaningful inside a mixin, though, but that might also be
fixable. It would be an interesting challenge.
Bastiaan.
Proofing the concept:
---
mixin(snoop(q{
int fun(int a, int b)
{
int c = 3;
foreach (i; 1 .. 5)
{
a += i;
}
int d = a + b + c;
return d;
}
}));
---
Output:
2019-Apr-26 10:33:46.0935135 executed line 7: int c = 3;
2019-Apr-26 10:33:46.0936716 executed line 10: a +=
i;
2019-Apr-26 10:33:46.0937348 executed line 10: a +=
i;
2019-Apr-26 10:33:46.0937963 executed line 10: a +=
i;
2019-Apr-26 10:33:46.0938583 executed line 10: a +=
i;
2019-Apr-26 10:33:46.0939622 executed line 12: int d =
a + b + c;
https://run.dlang.io/is/Go97hQ
Bastiaan.
Hey, that's a pretty cool demo. I saw the idea and wondered
rather it could be possible with D. I has some very cool
introspection properties. The Link seems to be broken right now.
But I think this might be worth some development. Tools like this
can really help new users, especially when they are doing things
the o'l fashion way, printf for debugging. I doubt it would be
too much help for things like ranges, but one must pick their
battles.
Thanks.
Re: DLL creation fails with undefined symbol error
On Friday, 26 April 2019 at 12:37:46 UTC, evilrat wrote: On Friday, 26 April 2019 at 05:08:32 UTC, dokutoku wrote: I tried to build a DLL in a Windows 64bit environment. It works well if the compiler is DMD, but in the case of LDC, the build fails with a large number of undefined symbol errors. Is this a DUB or LDC bug? Or do I have to specify some additional arguments to the command? Seems like DMD links some system and/or runtime libs for you, while LDC doesn't. What symbols are missing? It could be just msvcrt and some of the default system libs such as system32 and the like. There was an error like this. ``` Performing "debug" build using C:\ldc\bin\ldc2.exe for x86_64. test ~master: building configuration "library"... lld-link: error: referenced by druntime-ldc.lib(exception.obj):(_d_arrayboundsp) lld-link: error: undefined symbol: __acrt_iob_func referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: __stdio_common_vfwprintf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: __stdio_common_vfwscanf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: __stdio_common_vswprintf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN5) lld-link: error: undefined symbol: __stdio_common_vswscanf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: __stdio_common_vfprintf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: __stdio_common_vfscanf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: __stdio_common_vsprintf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN5) referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN5) lld-link: error: undefined symbol: __stdio_common_vsscanf referenced by legacy_stdio_definitions.lib(legacy_stdio_definitions.obj):($LN3) lld-link: error: undefined symbol: strlen referenced by druntime-ldc.lib(object.obj):(_D6object10ModuleInfo4nameMxFNaNbNdNiZAya) lld-link: error: undefined symbol: malloc referenced by druntime-ldc.lib(lifetime.obj):(_d_newclass) referenced by druntime-ldc.lib(lifetime.obj):(_D2rt8lifetime__T11_d_newclassVbi1ZQsFNbxC14TypeInfo_ClassZC6Object) referenced by druntime-ldc.lib(lifetime.obj):(_d_allocclass) referenced by druntime-ldc.lib(lifetime.obj):(_D2rt8lifetime__T11_d_newclassVbi0ZQsFNbxC14TypeInfo_ClassZC6Object) referenced by druntime-ldc.lib(lifetime.obj):(_D2rt8lifetime10__blkcacheFNbNdZPS4core6memory8BlkInfo_) referenced by druntime-ldc.lib(lifetime.obj):(_D2rt8lifetime12__getBlkInfoFNbPvZPS4core6memory8BlkInfo_) referenced by druntime-ldc.lib(lifetime.obj):(_D2rt8lifetime20__insertBlkInfoCacheFNbS4core6memory8BlkInfo_PQxZv) referenced by druntime-ldc.lib(lifetime.obj):(_d_arrayshrinkfit) referenced by druntime-ldc.lib(lifetime.obj):(_d_arrayshrinkfit) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetcapacity) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetcapacity) referenced by druntime-ldc.lib(lifetime.obj):(_d_delarray_t) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthiT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthiT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthiT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthiT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthiT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arraysetlengthiT) referenced by druntime-ldc.lib(lifetime.obj):(_d_arrayappendcTX)
Re: GTK Scale/Volume Buttons Show Muted Icon on Startup
On Friday, 26 April 2019 at 09:36:04 UTC, Russel Winder wrote: If I remember correctly, you have to set up the volume button, set the initial volume, then set up and add the adjustment, and then reset the initial value via the adjustment to get the icon correct. Memory on this is hazy... Actually, you're memory on this point is fine, Russell. My solution—in an effort to keep is as clear as possible—was to do the initial setting of the new Adjustment to (initialValue + 1), and then do setValue(initialValue).
Re: DLL creation fails with undefined symbol error
On Friday, 26 April 2019 at 05:08:32 UTC, dokutoku wrote: I tried to build a DLL in a Windows 64bit environment. It works well if the compiler is DMD, but in the case of LDC, the build fails with a large number of undefined symbol errors. Is this a DUB or LDC bug? Or do I have to specify some additional arguments to the command? Seems like DMD links some system and/or runtime libs for you, while LDC doesn't. What symbols are missing? It could be just msvcrt and some of the default system libs such as system32 and the like.
gtkDcoding Blog: Post #0030 - A More Practical RadioMenuItem Example
Once again it's Friday and a new blog post is up. And just a room at the Hotel California (any time of year) you can find it here: http://gtkdcoding.com/2019/04/26/0030-radiomenuitem-practical.html
Re: Logging best practices
On Friday, 26 April 2019 at 08:10:33 UTC, Bastiaan Veelo wrote: std.experimental has been already moved to std. Are you sure about that? https://github.com/dlang/phobos/tree/master/std I think you are confusing the package std.experimental.all that moved to std. It means you can now import all of Phobos by doing `import std;` instead of `import std.experimental.all;`. It does not mean that everything below std.experimental moved to std and thereby lost its experimental status. Bastiaan. yes, you're right, I just made a misunderstanding. Thanks!
Re: Does D have a tool like pySnooper?
On Friday, 26 April 2019 at 08:35:57 UTC, Bastiaan Veelo wrote:
On Thursday, 25 April 2019 at 08:44:14 UTC, Dennis wrote:
On Monday, 22 April 2019 at 16:24:53 UTC, Taylor Hillegeist
wrote:
Or would this not be easy at all with D?
I don't think so. While there are lots of traits for
introspection of declarations, there is no way to introspect
lines of code. The whole function
would need to be wrapped into a mixin, and the D code would
need to be parsed
at compile time for this to work.
Yes, but I think that might be doable. You wouldn't need a full
blown D parser, just one that can identify statements (`;`
being an important clue). Not sure whether __LINE__ will be
meaningful inside a mixin, though, but that might also be
fixable. It would be an interesting challenge.
Bastiaan.
Proofing the concept:
---
mixin(snoop(q{
int fun(int a, int b)
{
int c = 3;
foreach (i; 1 .. 5)
{
a += i;
}
int d = a + b + c;
return d;
}
}));
---
Output:
2019-Apr-26 10:33:46.0935135 executed line 7: int c = 3;
2019-Apr-26 10:33:46.0936716 executed line 10: a += i;
2019-Apr-26 10:33:46.0937348 executed line 10: a += i;
2019-Apr-26 10:33:46.0937963 executed line 10: a += i;
2019-Apr-26 10:33:46.0938583 executed line 10: a += i;
2019-Apr-26 10:33:46.0939622 executed line 12: int d = a
+ b + c;
https://run.dlang.io/is/Go97hQ
Bastiaan.
Re: GTK Scale/Volume Buttons Show Muted Icon on Startup
On Thu, 2019-04-25 at 11:36 +, Ron Tarrant via Digitalmars-d-learn wrote: > I've scoured the docs, the wrapper code, the Internet, but can't > come up with an explanation... > > When running this example of a VolumeButton, no matter what the > initial value of the slider, the icon showing is > audio-volume-muted. Experience with Me TV in D/GtkD/GStreamerD and Rust/gtk-rs/gstreamer-rs indicates that volume buttons and adjustments in GTK+ have issues, this is not a GtkD or gtk-rs thing it seems to be a GTK+ thing. If I remember correctly, you have to set up the volume button, set the initial volume, then set up and add the adjustment, and then reset the initial value via the adjustment to get the icon correct. Memory on this is hazy as it was a while ago, I got it working and then left it alone, untouched. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Noob questions
In case you have not solved the 3rd problem yet (your code is
almost there),
it can be fixed by replacing this line:
rawfile.écrire(uncompress(efile_buf2)); // alias for
std.file.write
with this one:
(filename ~ ".out").écrire(uncompress(efile_buf2));
The lines that open files using std.stdio.File are not needed and
can be removed:
File efile = File(filename, "r");
File rawfile = File(filename ~ ".out", "w");
std.file.write works pretty much like this:
void write(string filename, void[] writeThis) {
import std.stdio;
File f = File(filename, "w");
f.rawWrite(writeThis);
f.close();
}
It expects a filename as an argument (not a std.stdio.File
structure representing an open file). std.file.read also expects
a filename, your code is calling that one correctly.
Using std.stdio.File is not necessary here because
std.file.read/write open and close the files on their own.
About your 2nd problem: its hard to tell whats going on without
more complete code. You may want to inspect the problematic
string using something like this:
string correct = "test.txt";
string tricky = std.string.strip(readln());
writeln("c: ", cast(ubyte[]) correct);
writeln("t: ", cast(ubyte[]) tricky);
This is going to print numeric codes of all bytes in the string
and reveal any potentially invisible characters (like spaces,
line-ending markers, tabs etc.), like this:
c: [116, 101, 115, 116, 46, 116, 120, 116]
t: [116, 101, 115, 116, 46, 116, 120, 116, 13]
Re: Does D have a tool like pySnooper?
On Thursday, 25 April 2019 at 08:44:14 UTC, Dennis wrote: On Monday, 22 April 2019 at 16:24:53 UTC, Taylor Hillegeist wrote: Or would this not be easy at all with D? I don't think so. While there are lots of traits for introspection of declarations, there is no way to introspect lines of code. The whole function would need to be wrapped into a mixin, and the D code would need to be parsed at compile time for this to work. Yes, but I think that might be doable. You wouldn't need a full blown D parser, just one that can identify statements (`;` being an important clue). Not sure whether __LINE__ will be meaningful inside a mixin, though, but that might also be fixable. It would be an interesting challenge. Bastiaan.
GtkD slows down visual D keyboard
When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it).
Re: Logging best practices
On Thursday, 25 April 2019 at 10:33:00 UTC, Vladimirs Nordholm wrote: Hello. Is there a current "Best Practices" for logging in D? For the actual logging, I know of `std.experimental.logger`. However, the `experimental` has kept me away from it. Is it good, or are there any better alternatives? Apart from an open issue I have, https://issues.dlang.org/show_bug.cgi?id=15536, I have used std.experimental.logger successfully here: https://github.com/PhilippeSigaud/Pegged/wiki/Grammar-Debugging Bastiaan.
Re: Logging best practices
On Thursday, 25 April 2019 at 15:51:43 UTC, dangbinghoo wrote: On Thursday, 25 April 2019 at 10:33:00 UTC, Vladimirs Nordholm wrote: Hello. Is there a current "Best Practices" for logging in D? For the actual logging, I know of `std.experimental.logger`. However, the `experimental` has kept me away from it. Is it good, or are there any better alternatives? for the latest alpha version of D release, all std.experimental has been already moved to std. Are you sure about that? https://github.com/dlang/phobos/tree/master/std I think you are confusing the package std.experimental.all that moved to std. It means you can now import all of Phobos by doing `import std;` instead of `import std.experimental.all;`. It does not mean that everything below std.experimental moved to std and thereby lost its experimental status. Bastiaan.
Re: How to delete element from array container or dlist?
On Sunday, 18 March 2018 at 16:14:06 UTC, Michael wrote:
On Sunday, 18 March 2018 at 15:42:18 UTC, Andrey Kabylin wrote:
On Sunday, 18 March 2018 at 15:32:47 UTC, Michael wrote:
On Sunday, 18 March 2018 at 14:58:52 UTC, Andrey Kabylin
wrote:
In DList we have method remove, but I can't understand how
this method works, I want write somethink like this:
void unsubscribe(EventsSubscriber subscriber) {
subscribers.remove(subscriber);
}
So I guess you would want something like
subscribers.remove!(a => a == subscriber));
which is the different definition of remove available here:
https://dlang.org/phobos/std_algorithm_mutation.html#.remove.2
Yes this works, thanks!
No problem, glad to help!
Just an FYI:
This didn't work as I expected -- the length of subscribers
didn't change. What I needed here was
subscribers = subscribers.remove!(a => a == subscriber));
Otherwise this sort of behaviour resulted:
// code:
struct A {int i;}
A[] as = [A(1), A(2), A(3)];
writeln("as = ", as);
writeln(remove!(a => a == A(2))(as));
writeln("as = ", as);
writeln(remove!(a => a == A(3))(as));
writeln("as = ", as);
// output:
as = [A(1), A(2), A(3)]
[A(1), A(3)]
as = [A(1), A(3), A(3)]
[A(1)]
as = [A(1), A(3), A(3)]
