Specify rhs at initialisation or assignment of typedef' d variable
Say I have used Typedef! to create some new type and I declare a variable, constant or enum of that type. Is there a way that I can express a literal value on the rhs without having to use casts, as that seems to defeat the point of the nice type safety? I may be asking for the impossible or _illogical_ here. In any case, I still get to keep the nice feature of not being able to mix up types with assignment from one variable to another. Specific example is mac_addr_48_t my_mac_address = 0x112233445566uL; Which now produces a compile time error after I changed to use an alias = Typedef!uint64_t as opposed to just a straight alias = uint64_t earlier with no strong typing.
Re: Specify rhs at initialisation or assignment of typedef' d variable
On Monday, 31 July 2017 at 07:16:25 UTC, Cecil Ward wrote: Say I have used Typedef! to create some new type and I declare a variable, constant or enum of that type. Is there a way that I can express a literal value on the rhs without having to use casts, as that seems to defeat the point of the nice type safety? I may be asking for the impossible or _illogical_ here. In any case, I still get to keep the nice feature of not being able to mix up types with assignment from one variable to another. Specific example is mac_addr_48_t my_mac_address = 0x112233445566uL; Which now produces a compile time error after I changed to use an alias = Typedef!uint64_t as opposed to just a straight alias = uint64_t earlier with no strong typing. If struct + alias this is not strong enough the only solution is see is a helper template à la "octal" or "hexString", i.e a static cally checked string.
Re: Specify rhs at initialisation or assignment of typedef' d variable
On Monday, 31 July 2017 at 07:50:57 UTC, inevzxui wrote: On Monday, 31 July 2017 at 07:16:25 UTC, Cecil Ward wrote: Say I have used Typedef! to create some new type and I declare a variable, constant or enum of that type. Is there a way that I can express a literal value on the rhs without having to use casts, as that seems to defeat the point of the nice type safety? I may be asking for the impossible or _illogical_ here. In any case, I still get to keep the nice feature of not being able to mix up types with assignment from one variable to another. Specific example is mac_addr_48_t my_mac_address = 0x112233445566uL; Which now produces a compile time error after I changed to use an alias = Typedef!uint64_t as opposed to just a straight alias = uint64_t earlier with no strong typing. If struct + alias this is not strong enough the only solution is see is a helper template à la "octal" or "hexString", i.e a static cally checked string. I suspect that I am asking for something that literally makes no sense at all. I wanted to try and avoid opening the door to allowing the following kind of typing error now, eg enum ip_address = 0x11223344; mac_addr_48_t my_mac = cast(mac_addr_48_t) ip_address; as if we are going to the bother of introducing strong type checking with Typedef! then the last thing I want to do is encourage is a proliferation of casts. I realise something else now too - Issue 2: The thing is that I also immediately have to do a lot of work to make the simplest operators work anyway, such as in foreach( addr; base_mac_address .. base_mac_address + range ) where the + operator is producing compile-time errors now. So it just seems that the Typedef! feature immediately make life into a nightmare. I don't know if something based of the physical units module (using 'dimensionless' in this case) would work - perhaps it only handles floating point of various types? Or whether that would also involve a huge amount of work and still have issue 1 mentioned earlier. In any case, I have absolutely no clue how to even begin to start using the units module thing.
Re: Specify rhs at initialisation or assignment of typedef' d variable
On Monday, 31 July 2017 at 08:53:10 UTC, Cecil Ward wrote: On Monday, 31 July 2017 at 07:50:57 UTC, inevzxui wrote: [...] I suspect that I am asking for something that literally makes no sense at all. I wanted to try and avoid opening the door to allowing the following kind of typing error now, eg enum ip_address = 0x11223344; mac_addr_48_t my_mac = cast(mac_addr_48_t) ip_address; as if we are going to the bother of introducing strong type checking with Typedef! then the last thing I want to do is encourage is a proliferation of casts. [...] Actually, it would be really nice to have some kind of safe initialisation helper that checks value ranges, as in this particular case I need to make sure that the literal 64-bit value fits in 48 bits.
Taking the address of an eponymous template
Hi! I want to create a delegate out of a method that happens to be an eponymous (nested) template, like this: ``` class C { void foo() {} void bar(string S)() { } template baz(string S) { void baz()() { } } } void main() { C c = new C(); void delegate() aFoo = &c.foo; void delegate() aBar = &c.bar!"a"; void delegate() aBaz = &c.baz!"a"; // This doesn't compile. } ``` If I try &c.baz!"a".baz it doesn't work either (I get a different error message. Do you know if this works (and if so, what should I do), or if it's supposed to? Of course in this case I don't need to use an eponymous template at all, bit it's just a simplification to try to get everything else out of the way... In case anyone is interested, the real case is something more like this: ``` class C { template baz(args...) if (someCondition!args) { void baz(this T) { } } } ``` As far as I know, that's the only way to combine a "this" template parameter with variadic template parameters. As usual, thanks for the great support, D hast got a great community! P.S.: When the function inside the eponymous template is not templated itself, then it does work: ´´´ class C { template baz(string S) { void baz() { } } } void main() { C c = new C(); auto aBaZ = &c.baz!"a"; } ´´´
Re: Taking the address of an eponymous template
On 07/31/2017 11:44 AM, Arafel wrote: ``` class C { [...] template baz(string S) { void baz()() { } } } void main() { [...] void delegate() aBaz = &c.baz!"a"; // This doesn't compile. } ``` If I try &c.baz!"a".baz it doesn't work either (I get a different error message. Do you know if this works (and if so, what should I do), or if it's supposed to? You'd have to instantiate the inner template, too. Something like `&c.baz!"a".baz!()`, but that doesn't work. I don't know how you could make it work. Of course in this case I don't need to use an eponymous template at all, bit it's just a simplification to try to get everything else out of the way... In case anyone is interested, the real case is something more like this: ``` class C { template baz(args...) if (someCondition!args) { void baz(this T) { } } } ``` (Assuming the inner baz is supposed to be `void baz(this T)() {}`.) You'd still have to instantiate the inner baz in order to get a delegate of it. But even if we figured out how to do that, my guess is you don't want to specify `this T` explicitly. So how about a function literal: void delegate() aBaz = () => c.baz!(int, float)(); As far as I know, that's the only way to combine a "this" template parameter with variadic template parameters. That's right if you want to pass `args` explicitly, but `this` implicitly. If specifying `args` via IFTI is an option, then this works, too: class C { void baz(this T, args...)(args) {} } void main() { C c = new C(); void delegate() aBaz = () => c.baz(1, 2.3, "four"); } A function literal again, because you have to call baz in order to instantiate it (or you have specify `this T` and `args` explicitly). But you can't get a delegate from a call.
Re: Specify rhs at initialisation or assignment of typedef' d variable
On Monday, 31 July 2017 at 08:53:10 UTC, Cecil Ward wrote: [ ... ] I suspect that I am asking for something that literally makes no sense at all. I wanted to try and avoid opening the door to allowing the following kind of typing error now, eg enum ip_address = 0x11223344; [ ... ] Please have a look at the bigEndian function and BigEndian struct in SQLite-D https://github.com/UplinkCoder/sqlite-d/blob/master/source/utils.d The point here is writing your own struct and using alias-this yourself. Then you only need a function to produce constants of the right type. Such a function should be trivially CTFEable
Re: Taking the address of an eponymous template
On 07/31/2017 12:14 PM, ag0aep6g wrote: > > You'd have to instantiate the inner template, too. Something like > `&c.baz!"a".baz!()`, but that doesn't work. I don't know how you could > make it work. > I tried this as well, and couldn't make it work either. Do you know if it's supposed to work? I mean, do the spec mention this? The funny part is that id does work with nested, non-eponymous templates: ``` class A { template foo(string S) { void bar()() { import std.stdio; writeln ("I'm bar"); } void baz(this T)() { import std.stdio; writeln ("I'm baz at class ", typeid(T)); } } } class B : A { } void main() { A a = new A(); B b = new B(); void delegate() aBar = &a.foo!("a").bar!(); aBar(); void delegate() aBaz = &a.foo!("a").baz!(typeof (a)); aBaz(); void delegate() bBaz = &b.foo!("a").baz!(typeof (b)); bBaz(); } ``` OK, not directly with the "this" parameter... those you have to include explicitly. However, this seems to be an unrelated problem: the "this T" parameter seems to be only automatically deducted during function calls. Even this doesn't work: ``` class A { template foo(this T) { void bar() { import std.stdio; writeln(typeid(T)); } } } void main() { A a = new A(); a.foo.bar(); } ``` But I think that's a completely separate issue (would that be a bug, btw?) It's of course a trivial issue here, but it's just an example. What use is it to allow "this T" parameters in raw template declarations if they are not going to be automatically filled? > > (Assuming the inner baz is supposed to be `void baz(this T)() {}`.) > Sure :-) > You'd still have to instantiate the inner baz in order to get a delegate > of it. But even if we figured out how to do that, my guess is you don't > want to specify `this T` explicitly. > > So how about a function literal: > > void delegate() aBaz = () => c.baz!(int, float)(); > Yeah, that's the solution I was thinking about, but I don't know how much of a performance hit the extra function call would be... would the function literal extra indirection layer be eventually optimised out? > That's right if you want to pass `args` explicitly, but `this` > implicitly. If specifying `args` via IFTI is an option, then this works, > too: > > > class C { > void baz(this T, args...)(args) {} > } > > void main() { > C c = new C(); > void delegate() aBaz = () => c.baz(1, 2.3, "four"); > } > > > A function literal again, because you have to call baz in order to > instantiate it (or you have specify `this T` and `args` explicitly). But > you can't get a delegate from a call. This wouldn't work in my case because the arguments ("args") are string themselves, so the function call needs to look like: c.baz!("one","two"); and not: c.baz("one","two"); The reasons for that are a bit more complex, but let's say that in this case I need the strings to be in the template parameters, I use those strings to create an AliasSeq of values of different types that is then sent to a "proper" variadic templated function. Off topic, if anyone knows how to create a va_list dynamically, that would save me a lot of problems!!
Re: D Debug101
gdb wants dwarf debug info, windows uses codeview.
Re: Is std.xml seriously broken, or is it me?
On Sunday, 30 July 2017 at 03:16:35 UTC, Mike wrote: It appears `onStartTag` does not handle the root element. Looks like a bug. Until the module is replaced, bug reports are still accepted for it.
How to test tuple in chain
Hello! If I want testing tuple member in functional manner, what I shoul do? Example: "ls -l".executeShell returns me tuple (int "status", string "output") I want write somthing like: "ls -l".executeShell.smthTestingOperation!"Error: bad status."( res => res.status==0 ).output.writeln; (where "smthTestingOperation" - is function which I want to find in std )
Re: How to test tuple in chain
I read my message. Sorry for my poor english and typos.
Re: It makes me sick!
On Saturday, 29 July 2017 at 21:52:38 UTC, FoxyBrown wrote: On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote: On 28.07.2017 23:30, FoxyBrown wrote: because you didn't want to spend 10 minutes to fix a program. You need to realize that the same thing applies to you. There is no "us" vs "you". I.e. if you know it to only be 10 minutes of work, why don't you just fix it yourself? Mike currently has as many commits in DMD as you do, and he is already busy contributing in other ways. EXACTLY! Your problem is that you are taking the you vs me too literal. I am talking about a mentality people have that think that them saving 10 minutes by not implementing something that will save 10 hours(low estimate) for everyone else is a good thing and criticize people when they say there is a better and try to condemn them and continue the status quo that wastes more time. You should probably start to think about the real reason behind all this. The thing you complain about is DMD being flexible, like any other compiler is too. Try blundering around with the 'include' folder of your favorite C compiler, but don't blame me if nothing works any any more, because your compiler uses that directory as-is as its include directory and does not have an internal whitelist of the files to expect there. The next question is, would like DMD to require a whitelist for every single include directory, which means forcing each dev to write or generate a file list of his library directories?
Re: How to test tuple in chain
On Monday, 31 July 2017 at 12:23:02 UTC, closescreen wrote: I read my message. Sorry for my poor english and typos. use res[0] and res[1] to get res.status and the res.output.
Re: Taking the address of an eponymous template
On 07/31/2017 01:59 PM, Arafel wrote: On 07/31/2017 12:14 PM, ag0aep6g wrote: [...] > You'd have to instantiate the inner template, too. Something like > `&c.baz!"a".baz!()`, but that doesn't work. I don't know how you could > make it work. > I tried this as well, and couldn't make it work either. Do you know if it's supposed to work? I mean, do the spec mention this? I don't think that exact syntax is supposed to work. When you instantiate a non-eponymous template, you get a template instantiation with members which you can access. With an eponymous template, you get the eponymous member, nothing else. There's no way to get the members of the template by name then. Ideally, I'd say this would work: `&c.baz!"a"!()`. But that's not valid syntax. With a free template, you can make an alias of the first instantiation and then use that to instantiate the second time: template baz(string S) { void baz()() {} } alias baz1 = baz!"a"; void function() aBaz = &baz1!(); Could this work when the template is a class member? class C { template baz(string S) { void baz()() {} } } void main() { C c = new C(); alias baz1 = c.baz!"a"; // void delegate() aBaz = &baz1!(); // doesn't work pragma(msg, typeof(&baz1!())); // void function() pure nothrow @nogc @safe } We see that `&baz!()` is a function pointer, not a delegate. Looks like `this` got lost along the way. No idea if this is a bug or expected. It might be possible to hack around the issue by building the delegate manually: C c = new C(); alias baz1 = c.baz!"a"; void delegate() aBaz; aBaz.funcptr = &baz1!(); aBaz.ptr = cast(void*) c; That *seems* to work, but I'm not at all sure if it's actually correct. [...] OK, not directly with the "this" parameter... those you have to include explicitly. However, this seems to be an unrelated problem: the "this T" parameter seems to be only automatically deducted during function calls. Even this doesn't work: ``` class A { template foo(this T) { void bar() { import std.stdio; writeln(typeid(T)); } } } void main() { A a = new A(); a.foo.bar(); } ``` But I think that's a completely separate issue (would that be a bug, btw?) It's of course a trivial issue here, but it's just an example. What use is it to allow "this T" parameters in raw template declarations if they are not going to be automatically filled? I don't think it's a bug. The spec says that "TemplateThisParameters are used in member function templates" [1]. And it only shows the feature working with calls. So that's apparently the only case that has been considered and is expected to work. It might be worthwhile to explore if the feature can be expanded beyond calls. No idea what the difficulties would be. [...] > So how about a function literal: > > void delegate() aBaz = () => c.baz!(int, float)(); > Yeah, that's the solution I was thinking about, but I don't know how much of a performance hit the extra function call would be... would the function literal extra indirection layer be eventually optimised out? I don't know. [1] https://dlang.org/spec/template.html#template_this_parameter
Compile Time versus Run Time
As a rookie in D programming I try to understand the power of templated functions with compile time parameters. With DMD 2.074 a compile time format (auto output = format!("Print this %s")(var);) was introduced, now we all know that very many of this format strings are immutable, so wouldn't it be cool to automatically detect this and use the compile time version? Without the need to think about it and to use an other syntax? Is this theoretically possible? Regards mt.
Re: Compile Time versus Run Time
On Monday, 31 July 2017 at 15:43:21 UTC, Martin Tschierschke wrote: As a rookie in D programming I try to understand the power of templated functions with compile time parameters. With DMD 2.074 a compile time format (auto output = format!("Print this %s")(var);) was introduced, now we all know that very many of this format strings are immutable, so wouldn't it be cool to automatically detect this and use the compile time version? Without the need to think about it and to use an other syntax? Is this theoretically possible? Regards mt. That's what writeln() does. The format is detected for each element of the variadic.
Re: Compile Time versus Run Time
On Monday, 31 July 2017 at 15:46:47 UTC, inevzxui wrote: On Monday, 31 July 2017 at 15:43:21 UTC, Martin Tschierschke wrote: As a rookie in D programming I try to understand the power of templated functions with compile time parameters. With DMD 2.074 a compile time format (auto output = format!("Print this %s")(var);) was introduced, now we all know that very many of this format strings are immutable, so wouldn't it be cool to automatically detect this and use the compile time version? Without the need to think about it and to use an other syntax? Is this theoretically possible? Regards mt. That's what writeln() does. The format is detected for each element of the variadic. But the parameters are not checked at compile-time unless you specifically pass the pattern string as a template parameter. I think its immutability implicitly converting it into a template parameter is what's what he's talking about. import std.stdio; void main(string[] args) { writefln!"%s"(); // compile-time assert writefln("%s"); // runtime exception, though everything needed for a compile-time assert was inferable during compilation }
Re: Compile Time versus Run Time
On 07/31/2017 05:43 PM, Martin Tschierschke wrote: As a rookie in D programming I try to understand the power of templated functions with compile time parameters. With DMD 2.074 a compile time format (auto output = format!("Print this %s")(var);) was introduced, now we all know that very many of this format strings are immutable, so wouldn't it be cool to automatically detect this and use the compile time version? Without the need to think about it and to use an other syntax? Is this theoretically possible? Kinda-sorta, but not really and you have to use the template syntax: string format(alias fmt, A ...)(A args) { import std.format: sformat = format; static if (__traits(compiles, { enum e = fmt; })) return sformat!("(CT) " ~ fmt)(args); else return sformat("(RT) " ~ fmt, args); } void main() { import std.stdio: readln, writeln; // CT writeln(format!"Print this %s"(42)); // RT auto fmt = readln(); writeln(format!fmt(42)); // Can't call it like this: format!(readln())(42); // also still RT auto fmt2 = "Print this %s"; writeln(format!fmt2(42)); // (somewhat surprisingly) CT immutable fmt3 = "Print this %s"; writeln(format!fmt3(42)); }
Re: Compile Time versus Run Time
On Monday, 31 July 2017 at 15:57:28 UTC, Anonymouse wrote: On Monday, 31 July 2017 at 15:46:47 UTC, inevzxui wrote: On Monday, 31 July 2017 at 15:43:21 UTC, Martin Tschierschke wrote: [...] But the parameters are not checked at compile-time unless you specifically pass the pattern string as a template parameter. I think its immutability implicitly converting it into a template parameter is what's what he's talking about. import std.stdio; void main(string[] args) { writefln!"%s"(); // compile-time assert writefln("%s"); // runtime exception, though everything needed for a compile-time assert was inferable during compilation } This is exactly the "use case", I thought about: How to avoid runtime errors, if at compile time the problem might be detected.
Re: Compile Time versus Run Time
Am Mon, 31 Jul 2017 15:43:21 + schrieb Martin Tschierschke : > As a rookie in D programming I try to understand the power of > templated functions with compile time parameters. With DMD 2.074 > a compile time format > (auto output = format!("Print this %s")(var);) > > was introduced, now we all know that very many of this format > strings are immutable, so wouldn't it be cool to automatically > detect this and use the compile time version? > > Without the need to think about it and to use an other syntax? > Is this theoretically possible? I see no way to accomplish this. For the compiler to see the contents of the format string it needs to be a template argument and as soon as you want to also allow runtime values to be accepted there, you need to use an alias, which in turn precludes the use of function results or concatenation. Believe me I've spent quite some time on trying something like this for format strings. > Regards mt. As far as using template arguments for code optimizations go, I know that at least GCC will turn runtime arguments into template arguments of sorts internally, thereby creating duplicates of the function with one or more arguments optimized out. On the other hand, you don't want to drive this too far. While it is nice to have compile-time checks, templates are actually troublesome on some levels. For example, the duplicated code makes it hard to cache the formatting function in the CPU and when writing libraries you always have to provide the full implementation that will get linked into the host application, which is a concern under certain licensing schemes. The benefits of shared libraries, like loading the code into memory once and use it by multiple processes or fixing security issues in one central place and have all programs use the new code without recompilation are also void. I.e. without template arguments, `format()` and all its dependencies (templates as well as regular functions) are compiled right into the Phobos shared library for all programs to use. If there is a security issue, it can be replaced with a patched version. Now with template arguments, `format!()` is compiled into each Dlang application multiple times for each format string and security fixes cannot be applied without recompiling them all. -- Marco
gtk arch issues
how does one allow both gtk x86 and x64 to work side by side seamlessly? I installed x64 first and it seems, because whatever is using the path to find the gtk runtime, it looks for that first even in x86 build. Seems like gtkd's dll resolution is not very intelligent. While I could manually modify the path each time I switch archs, that seems pointless. One of the problems in gtkd is that it has multiple places where it defines libgdk-3-0.dll. I've tried modifying gdkD so that it uses versioning properly by searching for libgdk-3-0.dll and changing all to use an x86 or x64 when appropriate but that doesn't seem to help. Probably have to rebuild gtkD. Anyways, doesn't seem to be a great solution ;/ Any ideas and maybe someone can add an issue to the github page to get this fixed? (I can't do it for a while because of other issues).
Re: gtk arch issues
On Monday, 31 July 2017 at 17:16:32 UTC, Johnson Jones wrote: how does one allow both gtk x86 and x64 to work side by side seamlessly? I installed x64 first and it seems, because whatever is using the path to find the gtk runtime, it looks for that first even in x86 build. Seems like gtkd's dll resolution is not very intelligent. While I could manually modify the path each time I switch archs, that seems pointless. One of the problems in gtkd is that it has multiple places where it defines libgdk-3-0.dll. I've tried modifying gdkD so that it uses versioning properly by searching for libgdk-3-0.dll and changing all to use an x86 or x64 when appropriate but that doesn't seem to help. Probably have to rebuild gtkD. Anyways, doesn't seem to be a great solution ;/ Any ideas and maybe someone can add an issue to the github page to get this fixed? (I can't do it for a while because of other issues). I fixed up gtkd so that it uses x86 and x64 versions of dlls but it doesn't seem to help with x64. I was able to get x86 to compile and run but x64 just loads then quits without any errors ;/ C:\Program Files (x86)\GtkSharp\2.12\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libintl-8.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgobject-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libpango-1.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded. Best I can tell is that something is using the x86 verisons for some reason. Note that all those dll's should be x64 versions, but something outside of gtkD is loading them, I suspect it's Gtk itself, which would require proper versioning ;/ I replaced libgdk_pxbuf in gtkd to version it, i.e., version (Windows) version(X86) static immutable LIBRARY_GDKPIXBUF = ["libgdk_pixbuf-2.0-0x86.dll"]; else static immutable LIBRARY_GDKPIXBUF = ["libgdk_pixbuf-2.0-0x64.dll"]; and rebuilt, but it obviously using using that. It's probably a gtk-runtime dll that is using it that isn't versioned itself ;/ Of course, I want to be able to run my programs in x64 at some point so figuring out what is going on is important. It would be lovely if people would get their act together so things would work properly ;/
Re: gtk arch issues
On Monday, 31 July 2017 at 17:50:08 UTC, Johnson Jones wrote: On Monday, 31 July 2017 at 17:16:32 UTC, Johnson Jones wrote: [...] I fixed up gtkd so that it uses x86 and x64 versions of dlls but it doesn't seem to help with x64. I was able to get x86 to compile and run but x64 just loads then quits without any errors ;/ [...] Also, why is gtkD even using gtksharp? That's for mono and .net!
Re: gtk arch issues
On 31-07-17 19:16, Johnson Jones wrote: how does one allow both gtk x86 and x64 to work side by side seamlessly? I installed x64 first and it seems, because whatever is using the path to find the gtk runtime, it looks for that first even in x86 build. Seems like gtkd's dll resolution is not very intelligent. While I could manually modify the path each time I switch archs, that seems pointless. One of the problems in gtkd is that it has multiple places where it defines libgdk-3-0.dll. I've tried modifying gdkD so that it uses versioning properly by searching for libgdk-3-0.dll and changing all to use an x86 or x64 when appropriate but that doesn't seem to help. Probably have to rebuild gtkD. Anyways, doesn't seem to be a great solution ;/ Any ideas and maybe someone can add an issue to the github page to get this fixed? (I can't do it for a while because of other issues). At startup GtkD searches the Path for "libgtk-3-0.dll", when it finds one it checks the architecture of the library. If it's the correct architecture it calls `SetDllDirectory` so that the directory with the correct architecture will be searched first by `LoadLibrary`. If it's not the correct architecture it continues searching, if no library with the correct architecture is found, we rely on `LoadLibrary` to error out if the libraries are also not in the other locations searched by `LoadLibrary`. -- Mike Wey
Re: gtk arch issues
On 31-07-17 19:53, Johnson Jones wrote: Also, why is gtkD even using gtksharp? That's for mono and .net! We don't. only the (C) Gtk runtime is needed. Where did you see gtksharp? -- Mike Wey
Re: gtk arch issues
On Monday, 31 July 2017 at 20:37:11 UTC, Mike Wey wrote: On 31-07-17 19:16, Johnson Jones wrote: how does one allow both gtk x86 and x64 to work side by side seamlessly? I installed x64 first and it seems, because whatever is using the path to find the gtk runtime, it looks for that first even in x86 build. Seems like gtkd's dll resolution is not very intelligent. While I could manually modify the path each time I switch archs, that seems pointless. One of the problems in gtkd is that it has multiple places where it defines libgdk-3-0.dll. I've tried modifying gdkD so that it uses versioning properly by searching for libgdk-3-0.dll and changing all to use an x86 or x64 when appropriate but that doesn't seem to help. Probably have to rebuild gtkD. Anyways, doesn't seem to be a great solution ;/ Any ideas and maybe someone can add an issue to the github page to get this fixed? (I can't do it for a while because of other issues). At startup GtkD searches the Path for "libgtk-3-0.dll", when it finds one it checks the architecture of the library. If it's the correct architecture it calls `SetDllDirectory` so that the directory with the correct architecture will be searched first by `LoadLibrary`. If it's not the correct architecture it continues searching, if no library with the correct architecture is found, we rely on `LoadLibrary` to error out if the libraries are also not in the other locations searched by `LoadLibrary`. This is not true(at least completely). I have have a fresh windows 10 install with fresh dmd and gtkd and gtk x64 and x86(installed later). When running my app in x64 mode it tried to use the x64 but the app crashed and I didn't know why as no error message and bug in visual D wouldn't allow me to use BP's to find out how far the app was getting. So I decided to install the x86 version. Ran the project in x86 mode but gtkd was trying to load the x64 dlls and told me they were wrong. Remember, now I have both versions on my system. I decided to modify gtkd and using some versioning, in which case this got me to allow x86 to work as it now used *x86.dll's. I noticed that gtksharp was installed in program files (x86). I then tried to build the x64 version and the app just loads then quits but the debug console shows what I pasted and shows that it is trying to load stuff from gtksharp. All I installed as gtk3-runtime_3.22.4_64-bit and gtk3-runtime_3.22.4_32-bit. Now, it may turn out that gtksharp was installed by something else(visual studio? or maybe a few other apps I installed). That seems to be the case as the modified date predates install of gtk3 and seems to correlate to when I installed visual studio 2017 with it's 50+ gigs worth of crap. Why is my x64 app trying to load those files though and specially from the wrong version? the x86 version The files being loaded(I suppose they are, not sure what the unloaded means): C:\Windows\SysWOW64\kernel32.dll unloaded. C:\Windows\SysWOW64\winmmbase.dll unloaded. C:\Windows\SysWOW64\winmmbase.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Windows\SysWOW64\dnsapi.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libpangoft2-1.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk-3-0.dll unloaded. C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.483_none_6dad63fefc436da8\comctl32.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\librsvg-2-2.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libcroco-0.6-3.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libxml2-2.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libxml2-2.dll unloaded. C:\Windows\SysWOW64\winhttp.dll unloaded. C:\Windows\SysWOW64\OnDemandConnRouteHelper.dll unloaded. for x86, for x64 I get C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded. C:\Program Files (x86)\GtkSharp\2.12\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Windows\System32\dwmapi.dll unloaded. C:\Windows\System32\ole32.dll unloaded. C:\Windows\System32\setupapi.dll unloaded. C:\Windows\System32\winmm.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded. The program '[3420] test.exe' has exited with code 1 (0x1). as you can see, some files are loaded that are from x86. Remember, I modified gtk so that it duplicates all the dll's with the x??.dll's and modified gtkd to take those x??.dll's instead, which you can see in the last libgdk-3-0x64. So, those files being loaded are surely not coming from inside gtkd? I modified things like version (Windows) { version(X86) { const string[LIBRARY.max+1] importLibs = [ LIBRARY.ATK:
Adding deprecated to an enum member
I got an error today because I added deprecated to an enum member. Is there a way to achieve this, or am I out of luck? If it isn't doable, should it be? Here's what I want: enum PrimitiveType { Points, Lines, LineStrip, Triangles, TriangleStrip, TriangleFan, Quads, deprecated("Use LineStrip instead.") LinesStrip = LineStrip, deprecated("Use TriangleStrip instead.") TrianglesStrip = TriangleStrip, deprecated("Use TriangleFan instead.") TrianglesFan = TriangleFan } PrimitiveType ptype = LinesStrip; //error, Use LineStrip instead.
Re: Adding deprecated to an enum member
On Tuesday, 1 August 2017 at 01:12:28 UTC, Jeremy DeHaan wrote: I got an error today because I added deprecated to an enum member. Is there a way to achieve this, or am I out of luck? If it isn't doable, should it be? Here's what I want: enum PrimitiveType { Points, Lines, LineStrip, Triangles, TriangleStrip, TriangleFan, Quads, deprecated("Use LineStrip instead.") LinesStrip = LineStrip, deprecated("Use TriangleStrip instead.") TrianglesStrip = TriangleStrip, deprecated("Use TriangleFan instead.") TrianglesFan = TriangleFan } PrimitiveType ptype = LinesStrip; //error, Use LineStrip instead. I did as follows using deprecated may help you to elucidate in relation to this https://pastebin.com/NEHtWiGx
mixin template, extern(C/Windows) and mangled name
I known there is a bug with extern(C) in mixin template: https://issues.dlang.org/show_bug.cgi?id=12575 And I can see SimpleDllMain in core.sys.windows.dll, the mangled name is correct: DllMain But my mixin template has wrong mangled name: mixin template GetMetaData() { extern(Windows) MetaData GetMetaData() { return MetaData(); } } mixin GetMetaData; I can see the mangled name is: _D3app8__mixin911GetMetaDataWZS4zero7plugins8metadata8MetaData
Re: mixin template, extern(C/Windows) and mangled name
On Tuesday, 1 August 2017 at 03:08:30 UTC, Domain wrote: And I can see SimpleDllMain in core.sys.windows.dll, the mangled name is correct: DllMain main, DllMain, and WinMain are special cased... for yours, I think you'll have to hack it with pragma(mangle) mixin template GetMetaData() { pragma(mangle, "GetMetaData") // or whatever maybe @0 ? extern(Windows) MetaData GetMetaData() { return MetaData(); } } mixin GetMetaData; I think.
Re: mixin template, extern(C/Windows) and mangled name
On Tuesday, 1 August 2017 at 03:30:08 UTC, Adam D. Ruppe wrote: On Tuesday, 1 August 2017 at 03:08:30 UTC, Domain wrote: And I can see SimpleDllMain in core.sys.windows.dll, the mangled name is correct: DllMain main, DllMain, and WinMain are special cased... for yours, I think you'll have to hack it with pragma(mangle) mixin template GetMetaData() { pragma(mangle, "GetMetaData") // or whatever maybe @0 ? extern(Windows) MetaData GetMetaData() { return MetaData(); } } mixin GetMetaData; I think. Thanks. Anyone known any plan for issue 12575? It has been 3 years, it looks like not that hard to fix.
Bug in gtkd?
Trying a very simple interface. When I add a notebook I get the following error (test.exe:4504): Gtk-[1;31mERROR[0m **: failed to add UI: C:\Test\Main.Glade:27:43 Invalid property: GtkNotebook.tab_hborder When removing it from the glade file it then crashes with on the homogenous property. Removing that allows it to work but then clicking on the border between causes the app to crash. clicking the link gives (SongPractice.exe:4796): Gtk-[1;33mWARNING[0m **: Couldn't export handle, unsupported windowing system Also, there is no icon on the task bar of the app so no way to find it if the app is minimized. Not sure why that is, but seems like it should be there regardless. The app is int main(string[] args) { gtk.Main.init(args); auto mw = (cast(Window)gtk.builder.getObject("MainWindow")); mw.showAll(); gtk.Main.run(); return 0; } The Main.Glade file is False True True True False gtk-missing-image False True True True True 0 True True False translatable="yes">button True True name="receives_default">True True none name="uri">http://glade.gnome.org True True 0 True False name="xalign">0.4798927116394 1 translatable="yes">Settings False True True