Re: variant .init value
On Thursday, 7 February 2019 at 07:33:50 UTC, Norm wrote:
Hi,
I'm trying to use Variant in a struct and want a default init
value like so:
---
struct S {
Variant v = Variant(10);
}
void main() {auto s = S();}
but when I try to build this I get the following error:
dmd2/linux/bin64/../../src/phobos/std/variant.d(661): Error:
memcpy cannot be interpreted at compile time, because it has no
available source code
Error: cannot interpret at compile time
---
I don't particularly need or want this to be available at
compile time, I really only want the struct to have a default
value when instantiated at runtime.
Is there a way to do this with a Variant member?
Thanks,
Norm
Hmm... found something similar from 2014...
https://issues.dlang.org/show_bug.cgi?id=11864
variant .init value
Hi,
I'm trying to use Variant in a struct and want a default init
value like so:
---
struct S {
Variant v = Variant(10);
}
void main() {auto s = S();}
but when I try to build this I get the following error:
dmd2/linux/bin64/../../src/phobos/std/variant.d(661): Error:
memcpy cannot be interpreted at compile time, because it has no
available source code
Error: cannot interpret at compile time
---
I don't particularly need or want this to be available at compile
time, I really only want the struct to have a default value when
instantiated at runtime.
Is there a way to do this with a Variant member?
Thanks,
Norm
DMD: can't get extern __gshared to work right (vs. LDC)
macOS 12, DMD 2.084.0 / LDC 1.14.0-beta1
I have a C API that exports some global variables, declared like
so:
.h file:
=
extern "C" {
#define PUBLIC_API __attribute__((visibility("default")))
struct __opaqueHandle; typedef __opaqueHandle* opaqueHandle_t;
PUBLIC_API extern const opaqueHandle_t kSomeGlobalValue;
}
.cpp file:
==
const opaqueHandle_t kSomeGlobalValue = (opaqueHandle_t)
kSomeInternalPointer;
.d file:
extern (C):
export extern __gshared opaqueHandle_t kSomeGlobalValue;
I have no issues linking against the resulting .dylib with a
C/C++ program, nor issues with DMD on Windows with the same code.
However with DMD on macOS, the value is coming through
incorrectly. It looks like a valid pointer value (vs. pure
garbage), but it's still incorrect. LDC2 works fine, no issues.
Is there some extra flag I need to pass to DMD on Mac to get it
to see this global properly? It links fine, no errors, but the
value is still wrong. I should also mention that this dylib
exports functions, too, and they are working fine even with DMD.
It's just the globals I'm having problems with.
Re: Tricky DMD bug, but I have no idea how to report
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote: while working on my game engine project, I encountered a DMD codegen bug. It occurs only when compiling in release mode, debug works. Old thread, but FWIW, such bugs can be easily and precisely reduced with DustMite. In your test script, just compile with and without the compiler option which causes the bug to manifest, and check that one works and the other doesn't. I put together a short article on the DustMite wiki describing how to do this: https://github.com/CyberShadow/DustMite/wiki/Reducing-a-bug-with-a-specific-compiler-option
Re: Easiest way to display images
On Thursday, 7 February 2019 at 00:10:50 UTC, Murilo wrote: "information harvesting" I mean Facebook as a whole, not your group specifically. FB is in the business of selling to advertisers, and the users are the product.
Re: Setup help?
On Thursday, 7 February 2019 at 02:55:15 UTC, evilrat wrote: You need C++ tools from Microsoft to debug D code, don't mind the name, its debugger works for any (compatible formats) native code. Then add C++ Windows debug configuration and set your paths. Done. You can debug now. (Though it is possible that it will require Visual Studio Build Tools installation) Of course this will not work for default DMD builds because it is using ancient object files format that is not compatible with VS debugger engine, so using DMD you need to build with -m32mscoff (dub --arch=x86_mscoff) or -m64 (dub --arch=x86_64) flags. Thanks, I'll give it a shot.
Re: Setup help?
On Wednesday, 6 February 2019 at 23:59:07 UTC, Charles wrote: I don't use C++, and I do use Windows, which has me wondering if I'm just missing some normal/exepcted configuration. My most recent attempt I tried to get Native Debug to make VS Code debugging stop on the first line. Instead, it just runs the program, and exits. "Native Debug" is for GDB and looks like it doesn't even works on Windows. But even on Linux I found that C++ tools are much nicer. You need C++ tools from Microsoft to debug D code, don't mind the name, its debugger works for any (compatible formats) native code. Then add C++ Windows debug configuration and set your paths. Done. You can debug now. (Though it is possible that it will require Visual Studio Build Tools installation) Of course this will not work for default DMD builds because it is using ancient object files format that is not compatible with VS debugger engine, so using DMD you need to build with -m32mscoff (dub --arch=x86_mscoff) or -m64 (dub --arch=x86_64) flags.
Re: Tricky DMD bug, but I have no idea how to report
On Wed, Feb 06, 2019 at 10:37:27PM +, JN via Digitalmars-d-learn wrote: [...] > I am not sure if it's a pointer bug. What worries me is that it breaks > at the start of the program, but uncommenting code at the end of the > program influences it. Unless there's some crazy reordering going on, > this shouldn't normally have an effect. As I've said before, this kind of "spooky" action-at-a-distance symptom is exactly the kind of behaviour you'd expect from a pointer bug. Of course, it doesn't mean that it *must* be a pointer bug, but it does look awfully similar to one. > I still believe the bug is on the compiler side, but it's a bit of > code in my case, and if I try to minimize the case, the issue > disappears. Oh well. That's another typical symptom of a pointer bug. It seems less likely to be a codegen bug, because I'd expect a codegen bug to exhibit more consistent symptoms: if a particular code is triggering a compiler codegen bug, then it shouldn't matter what other code is being compiled, the bug should show up in all cases. This kind of sensitivity to minute, unrelated changes is closer to how pointer bugs tend to behave. Of course, it's possible that there's a pointer bug in the *compiler*, so there's that. It's hard to tell either way at this point. Though given how much the compiler is used by so many people on a daily basis, it's also less likely though not impossible. Unless your code just happens to contain a particularly rare combination of language features that causes the compiler to go down a rarely-tested code path that contains the bug. Anyway, given what you said about how moving (or minimizing) seemingly-unrelated code around seems to affect the symptoms, we could do a little educated guesswork to try to narrow it down a little more. You said commenting out code at the end of the program affects whether it crashes at the beginning. Is this in the same function (presumably main()), or is it in different functions? If it's in the same function, one possibility is that you have some local variables that are being overrun by a buffer overflow or some bad pointer. Commenting out code at the end of the function changes the layout of variables on the stack, so it would change what gets overwritten. Possibly, the bug gets hidden by the bad pointer being redirected to some innocuous variable whose value is no longer used, or some such, so the presence of the bug is masked. If the commented-out code is in a different function from the location of the crash, and you're sure that the commented out code is not being run before the crash, then it would appear to be something related to the layout of global variables. Perhaps there's some module static ctor that's being triggered / not triggered, that changes the global state in some way that affects the code at the beginning of the program? If there's a bad pointer that points to some heap location, the action of module ctors running vs. not running could alter the heap state enough to mask the bug in some cases. Another possibility is if you're interfacing with C code and have a non null-terminated D string that's being cast to char*, and the presence of more code in the executable may perturb the data/code segment layout just enough to push the string somewhere that happens to contain a null shortly afterwards. Just some guesses based on my experience with pointer bugs. T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Re: Easiest way to display images
On Wednesday, 6 February 2019 at 04:36:12 UTC, DanielG wrote: On Wednesday, 6 February 2019 at 01:04:43 UTC, Murilo wrote: You should later joing the facebook group Programming in D. The D community is small enough that it's unlikely anybody in that Facebook group, isn't already using the newsgroups / IRC / etc to discuss D. Even the official subreddit barely gets any traffic. What I'm trying to say is, you're not going to have much luck getting that Facebook group off the ground. FB adds nothing to the existing options, and worse it's just an elaborate scheme to harvest personal information which one can safely assume the vast majority of D programmers are privacy-savvy enough to avoid. The facebook group already has 82 members, some of which are experienced users of D. There has been some reasonable amount of discussions going on there in the last weeks. And you don't need to worry about the "information harvesting" if you don't post personal stuff. It is a group to talk about a language and not about your life.
Setup help?
Does anyone know of a video that shows setting up vscode (or another editor with debugging support)? I always feel like I miss a step when I decide to try D out again, and it never ends well. I don't use C++, and I do use Windows, which has me wondering if I'm just missing some normal/exepcted configuration. My most recent attempt I tried to get Native Debug to make VS Code debugging stop on the first line. Instead, it just runs the program, and exits. Debug console output: No symbol table is loaded. Use the "file" command. Running executable [New Thread 10256.0x23d8] [New Thread 10256.0x2d30] [New Thread 10256.0xebc] [New Thread 10256.0x19f4] Edit source/app.d to start your project. [Thread 10256.0xebc exited with code 0] [Thread 10256.0x2d30 exited with code 0] [Thread 10256.0x19f4 exited with code 0] Thanks
Re: Tricky DMD bug, but I have no idea how to report
On Wednesday, 6 February 2019 at 22:22:26 UTC, H. S. Teoh wrote: Of course, I've no clue whether this is the cause of your problems -- it's just one of many possibilities. Pointer bugs are nasty things to debug, regardless of whether or not they've been abstracted away in nicer clothing. I still remember pointer bugs that took literally months just to get a clue on, because it was nigh impossible to track down where they happened -- the symptoms are too far removed from the cause. You pretty much have to take a wild guess and get lucky. They are just as bad as race condition bugs. (Once, a race condition bug took me almost half a year to fix, because it only showed up in the customer's live environment and we could never reproduce it locally. We knew there was a race somewhere, but it was impossible to locate it. Eventually, by pure accident, an unrelated code change subtly altered the timings of certain things that made the bug more likely to manifest under certain conditions -- and only then were we finally able to reliably reproduce the problem and track down its root cause.) T I am not sure if it's a pointer bug. What worries me is that it breaks at the start of the program, but uncommenting code at the end of the program influences it. Unless there's some crazy reordering going on, this shouldn't normally have an effect. I still believe the bug is on the compiler side, but it's a bit of code in my case, and if I try to minimize the case, the issue disappears. Oh well.
Re: Tricky DMD bug, but I have no idea how to report
On Wed, Feb 06, 2019 at 09:50:44PM +, JN via Digitalmars-d-learn wrote: > On Tuesday, 18 December 2018 at 22:56:19 UTC, H. S. Teoh wrote: > > Since no explicit slicing was done, there was no compiler error / > > warning of any sort, and it wasn't obvious from the code what had > > happened. By the time doSomething() was called, it was already long > > past the source of the problem in buggyCode(), and it was almost > > impossible to trace the problem back to its source. > > > > Theoretically, -dip25 and -dip1000 are supposed to prevent this sort > > of problem, but I don't know how fully-implemented they are, whether > > they would catch the specific instance in your code, or whether your > > code even compiles with these options. [...] > No luck. Actually, I avoid in my code pointers in general, I write my > code very "Java-like" with objects everywhere etc. [...] The nasty thing about the implicit static array -> slice conversion is that your code can have no bare pointers in sight, yet you still end up with an invalid reference to an out-of-scope local variable. Some of us have argued that this conversion ought to be be prohibited. But we haven't actually tried going in that direction yet, because it *will* break existing code (though IMO such code is suspect to begin with, and besides, all you have to do is to explicitly slice the static array to get around the newly-introduced compile error). Of course, I've no clue whether this is the cause of your problems -- it's just one of many possibilities. Pointer bugs are nasty things to debug, regardless of whether or not they've been abstracted away in nicer clothing. I still remember pointer bugs that took literally months just to get a clue on, because it was nigh impossible to track down where they happened -- the symptoms are too far removed from the cause. You pretty much have to take a wild guess and get lucky. They are just as bad as race condition bugs. (Once, a race condition bug took me almost half a year to fix, because it only showed up in the customer's live environment and we could never reproduce it locally. We knew there was a race somewhere, but it was impossible to locate it. Eventually, by pure accident, an unrelated code change subtly altered the timings of certain things that made the bug more likely to manifest under certain conditions -- and only then were we finally able to reliably reproduce the problem and track down its root cause.) T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
Re: Tricky DMD bug, but I have no idea how to report
On Tuesday, 18 December 2018 at 22:56:19 UTC, H. S. Teoh wrote: Since no explicit slicing was done, there was no compiler error / warning of any sort, and it wasn't obvious from the code what had happened. By the time doSomething() was called, it was already long past the source of the problem in buggyCode(), and it was almost impossible to trace the problem back to its source. Theoretically, -dip25 and -dip1000 are supposed to prevent this sort of problem, but I don't know how fully-implemented they are, whether they would catch the specific instance in your code, or whether your code even compiles with these options. T No luck. Actually, I avoid in my code pointers in general, I write my code very "Java-like" with objects everywhere etc. I gave up on the issue actually, perhaps I am encountering this bug https://issues.dlang.org/show_bug.cgi?id=16511 in my own code. Anyway, 32-bit and 64-bit debug work, so does LDC. That's good enough for me.
Re: VisualD phobos link error, only when I implement a few simple classes on top of a hello world program.
On Wed, Feb 06, 2019 at 05:53:05PM +, Enjoys Math via Digitalmars-d-learn wrote: > What is this phobos crap? > > I've tried renaming all my modules with an _ (underscore) in case they > were colliding with phobos. > > -- Build started: Project: BasicSimpleTypeTheoryApp, Configuration: > Debug Win32 -- > Building Win32\Debug\BasicSimpleTypeTheoryApp.exe... > LINK : fatal error LNK1104: cannot open file 'phobos32mscoff.lib' > Building Win32\Debug\BasicSimpleTypeTheoryApp.exe failed! > > All I have is two abstract classes essentially with 2 1-line methods, > nothing out-of-the ordinary. [...] It has nothing to do with colliding identifiers. You're missing a path to Phobos. Probably dmd.conf or some other configuration file doesn't have the correct path defined, or you're missing (the correct version of) the Phobos library file(s) for some reason. T -- Verbing weirds language. -- Calvin (& Hobbes)
Re: VisualD phobos link error, only when I implement a few simple classes on top of a hello world program.
I tried re-installing DMD, and now for either 64-bit or x86 build mode, I'm getting the Phobos linker error: -- Build started: Project: BasicSimpleTypeTheoryApp, Configuration: Debug x64 -- Building x64\Debug\BasicSimpleTypeTheoryApp.exe... LINK : fatal error LNK1104: cannot open file 'phobos64.lib' Building x64\Debug\BasicSimpleTypeTheoryApp.exe failed! Details saved as "file://C:\Users\FruitfulApproach\Desktop\_SIMPLE_TYPE_THEORY\BasicSimpleTypeTheoryApp\BasicSimpleTypeTheoryApp\x64\Debug\BasicSimpleTypeTheoryApp.buildlog.html" == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == In other words re-installing didn't help.
VisualD phobos link error, only when I implement a few simple classes on top of a hello world program.
What is this phobos crap? I've tried renaming all my modules with an _ (underscore) in case they were colliding with phobos. -- Build started: Project: BasicSimpleTypeTheoryApp, Configuration: Debug Win32 -- Building Win32\Debug\BasicSimpleTypeTheoryApp.exe... LINK : fatal error LNK1104: cannot open file 'phobos32mscoff.lib' Building Win32\Debug\BasicSimpleTypeTheoryApp.exe failed! All I have is two abstract classes essentially with 2 1-line methods, nothing out-of-the ordinary. Thanks.
Re: VisualD phobos link error, only when I implement a few simple classes on top of a hello world program.
On Wednesday, 6 February 2019 at 17:53:05 UTC, Enjoys Math wrote:
What is this phobos crap?
I've tried renaming all my modules with an _ (underscore) in
case they were colliding with phobos.
-- Build started: Project: BasicSimpleTypeTheoryApp,
Configuration: Debug Win32 --
Building Win32\Debug\BasicSimpleTypeTheoryApp.exe...
LINK : fatal error LNK1104: cannot open file
'phobos32mscoff.lib'
Building Win32\Debug\BasicSimpleTypeTheoryApp.exe failed!
All I have is two abstract classes essentially with 2 1-line
methods, nothing out-of-the ordinary.
Thanks.
Minimal example is now just hello world:
module BasicSimpleTypeTheoryApp;
import std.stdio;
//import _variable;
int main()
{
// auto v = new Variable("v");
writeln("Hello D World!\n");
readln();
return 0;
}
Re: How to use dproto for removing and element from a repeated field
On Wednesday, 6 February 2019 at 14:31:59 UTC, Paul Backus wrote:
On Wednesday, 6 February 2019 at 10:07:06 UTC, Sudhi wrote:
Hi,
I have been using dproto to work with protocol buffers. I have
below proto structure
message Person
{
required string name = 1;
required string id = 2;
repeated string emailId = 3;
}
Where a person can have multiple email ids.
I could add the email id to person using below code
person.emailId ~= "new-email";
However if i want to delete a email id from a person strucure,
how would i do that.
Thanks,
Sudhi
https://dlang.org/phobos/std_algorithm_mutation.html#remove
Thanks, that worked for me.
Re: How to use dproto for removing and element from a repeated field
On Wednesday, 6 February 2019 at 10:07:06 UTC, Sudhi wrote:
Hi,
I have been using dproto to work with protocol buffers. I have
below proto structure
message Person
{
required string name = 1;
required string id = 2;
repeated string emailId = 3;
}
Where a person can have multiple email ids.
I could add the email id to person using below code
person.emailId ~= "new-email";
However if i want to delete a email id from a person strucure,
how would i do that.
Thanks,
Sudhi
https://dlang.org/phobos/std_algorithm_mutation.html#remove
Re: How do I use libraries manually?
On Tuesday, 5 February 2019 at 20:39:50 UTC, Murilo wrote: On Tuesday, 5 February 2019 at 19:46:32 UTC, H. S. Teoh wrote: Thank you very much, I will try what you just explained. And yes I would really appreciate it if people would make single file libraries that I can just import as if it were any other .d file. That doesn't work in the aggregate. Any non-trivial library will need to be split up into packages and modules. There might be tasks to be performed before or after the build. There might be different build configurations. There might be external C library dependencies. The library might have dependencies of its own, so the possible complications are recursive. Just use dub, it's easier. I don't think there's any good reason to not use it.
Re: Singleton in Action?
On Monday, 4 February 2019 at 19:23:26 UTC, Jacob Carlborg wrote: You can call it with or without parentheses. It applies to all functions that don't take any arguments or functions taking a single argument and are called using UFCS [1]. [1] https://dlang.org/spec/function.html#pseudo-member Okay, that explains a few things that I still hadn't caught onto. Thanks.
Re: Submenu Not Responding Until Second Click
On Tuesday, 5 February 2019 at 09:41:06 UTC, Antonio Corbi wrote: It could be so, I'm not using gnome so I can't say. By the way, I'm using gtk3 3.24.5. Yeah, I updated from 3.22 to 3.24, but it made no difference on Windows 10. Still that delay with submenus. I'd rather be running FreeBSD, but ATM I'm using an MSI laptop with two external monitors and I'm still working on getting Xorg configured to recognize even one of those external monitors. So, until then, I guess I'm stuck with this behaviour.
Re: Using Async task with timer
On Wednesday, 6 February 2019 at 05:17:51 UTC, Heromyth wrote: On Wednesday, 6 February 2019 at 05:03:26 UTC, Sudhi wrote: Hi All, I am trying to use an Async task which would run at every interval of time. I could not find any example for this. Can some one enlighten me on this. I did not find much documentation on timers also. Thanks, Sudhi Here is an example, https://github.com/huntlabs/hunt/blob/master/examples/UnitTest/source/test/ScheduledThreadPoolTest.d You can have a try. Thanks you, Example has helped me a lot.
How to use dproto for removing and element from a repeated field
Hi,
I have been using dproto to work with protocol buffers. I have
below proto structure
message Person
{
required string name = 1;
required string id = 2;
repeated string emailId = 3;
}
Where a person can have multiple email ids.
I could add the email id to person using below code
person.emailId ~= "new-email";
However if i want to delete a email id from a person strucure,
how would i do that.
Thanks,
Sudhi
Re: C++ base class needs at least one virtual method
On Wednesday, 6 February 2019 at 07:38:04 UTC, ezneh wrote: Thanks for the trick, I'll try it and see how it goes. Since the class have nothing in them, I just made some "alias otherclass = baseclass" statements and it seems it is working (at least it's compiling, have to really test that too). From what I saw about the code is that those types are just "placeholders" because they aren't used directly by the API. It still might be necessary to add empty struct with 'extern(C++, class)' because alias is, well, just alias, and it needs a real type because C++ signatures do contains parameters types, and obviously there will be no methods that accepts derived class so it will fail to link. That's what that 'alias this' is for. And since this is not direct inheritance it will most likely won't work when object expected to be passed by value (at least not without casting to void* then to base*, i.e. 'someFunc(*cast(baseclass*)cast(void*))')
