Bug in gtkd?

[Johnson Jones via Digitalmars-d-learn]

Trying a very simple interface. When I add a notebook I get the 
following error


(test.exe:4504): Gtk-ERROR **: 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-WARNING **: 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
  

  

  

Re: mixin template, extern(C/Windows) and mangled name

[Domain via Digitalmars-d-learn]

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.

Re: mixin template, extern(C/Windows) and mangled name

[Adam D. Ruppe via Digitalmars-d-learn]

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.

mixin template, extern(C/Windows) and mangled name

[Domain via Digitalmars-d-learn]

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: Adding deprecated to an enum member

[dark777 via Digitalmars-d-learn]

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

Adding deprecated to an enum member

[Jeremy DeHaan via Digitalmars-d-learn]

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: gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

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:  

Re: gtk arch issues

[Mike Wey via Digitalmars-d-learn]

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

[Mike Wey via Digitalmars-d-learn]

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

[Johnson Jones via Digitalmars-d-learn]

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

[Johnson Jones via Digitalmars-d-learn]

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 ;/

gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

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: Compile Time versus Run Time

[Marco Leise via Digitalmars-d-learn]

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

Re: Compile Time versus Run Time

[Martin Tschierschke via Digitalmars-d-learn]

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

[ag0aep6g via Digitalmars-d-learn]

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

[Anonymouse via Digitalmars-d-learn]

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

[inevzxui via Digitalmars-d-learn]

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.

Compile Time versus Run Time

[Martin Tschierschke via Digitalmars-d-learn]

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: Taking the address of an eponymous template

[ag0aep6g via Digitalmars-d-learn]

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
 > `!"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: `!"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 = !();


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 = !(); // doesn't work
pragma(msg, typeof(!()));
// void function() pure nothrow @nogc @safe
}


We see that `!()` 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 = !();
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

Re: How to test tuple in chain

[inevzxui via Digitalmars-d-learn]

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: It makes me sick!

[Grander via Digitalmars-d-learn]

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

[closescreen via Digitalmars-d-learn]

I read my message. Sorry for my poor english and typos.

How to test tuple in chain

[closescreen via Digitalmars-d-learn]

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: Is std.xml seriously broken, or is it me?

[Kagamin via Digitalmars-d-learn]

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.

Re: D Debug101

[Kagamin via Digitalmars-d-learn]

gdb wants dwarf debug info, windows uses codeview.

Re: Taking the address of an eponymous template

[Arafel via Digitalmars-d-learn]

On 07/31/2017 12:14 PM, ag0aep6g wrote:

>
> You'd have to instantiate the inner template, too. Something like
> `!"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").bar!(); aBar();
void delegate() aBaz = !("a").baz!(typeof (a)); aBaz();
void delegate() bBaz = !("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: Specify rhs at initialisation or assignment of typedef' d variable

[Stefan Koch via Digitalmars-d-learn]

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

[ag0aep6g via Digitalmars-d-learn]

On 07/31/2017 11:44 AM, Arafel wrote:

```
class C {

[...]

 template baz(string S) {
 void baz()() {
 }
 }
}

void main() {

[...]

 void delegate() aBaz = !"a"; // This doesn't compile.
}
```

If I try !"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 
`!"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.

Taking the address of an eponymous template

[Arafel via Digitalmars-d-learn]

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 = 
void delegate() aBar = !"a";
void delegate() aBaz = !"a"; // This doesn't compile.
}
```

If I try !"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 = !"a";
}
´´´

Re: Specify rhs at initialisation or assignment of typedef' d variable

[Cecil Ward via Digitalmars-d-learn]

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.

Re: Specify rhs at initialisation or assignment of typedef' d variable

[Cecil Ward via Digitalmars-d-learn]

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

[inevzxui via Digitalmars-d-learn]

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.

Specify rhs at initialisation or assignment of typedef' d variable

[Cecil Ward via Digitalmars-d-learn]

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.