Re: Idioms you use

[Cauterite via Digitalmars-d]

On Monday, 28 September 2015 at 21:40:45 UTC, Freddy wrote:

Are any D idioms you use that you like to share?


I'm not sure if these fit under the definition of 'idiom', but 
they sort of are… I think.

http://dpaste.dzfl.pl/f66a76a7411f

You could even extend the concept with opDispatch to achieve 
syntax like this:

pinvoke.psapi.GetProcessImageFileNameW!uint(...);

I've used a similar technique (+ caching) to lazily load OpenGL 
extensions. It worked really well.

Re: GuiDub

[ponce via Digitalmars-d]

On Tuesday, 29 September 2015 at 05:17:42 UTC, Jacob wrote:


Does anyone actually maintain all this or use it? Cause surely 
I shouldn't be getting errors like this? I have about 50 
packages in my dub.json and they all came from copying the 
dependency directly(so no mistake on my part).





Some advices:


- do not use the "umbrella" packages like "dplug" but rather the 
sub-packages like "dplug:dsp". This will reduce the number of 
dependencies.


- cut the number of dependencies to the minimum. For example you 
have freeimage AND imaged who overlap quite a bit.
  More dependencies = more problems. Add them one by one IF they 
are needed and after evaluating them.


- before relying on a dependency, check that it looks maintained, 
has travis-ci integration, and build. Without editing anything, 
you can do:


dub test thatpackage

anywhere and it should download and build the tests.

- if given the choice, use a derelict binding vs a statically 
linked dependency. This will make things a tad easier.

Get template parameter value

[rumbu via Digitalmars-d-learn]

Having a template:

struct SomeStruct(int size)
{

}

Is there any language trait returning the value of size template 
parameter for the template instantiation SomeStruct!10?


In fact, I'm interested in an eponymous template to test if some 
type is a template inttantation for SomeStruct(int size).


template isSomeStruct(T)
{
  enum isSomeStruct = ?
}

template getStructSize(T) if (isSomeStruct!T)
{
  enum getStructSize = ?
}


I know that I can do something like this:

struct SomeStruct(int size)
{
   enum internalSize = size;
}

template isSomeStruct(T)
{
  enum isSomeStruct = is (typeof(T.internalSize): int);
}

template getStructSize(T) if (isSomeStruct!T)
{
  enum getStructSize = T.internalSize;
}

but I wonder that if it's not another simple and safe way. This 
approach is not safe because there is a risk to have 
SomeOtherStruct(int size) defined with similar semantics.


Thanks.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Russel Winder via Digitalmars-d-announce]

On Tue, 2015-09-29 at 03:53 +, Sebastiaan Koppe via Digitalmars-d
-announce wrote:
> This library[1] allows you to send multi-part emails with 
> attachments.

This code looks so similar to the equivalent in Python, it is great.
Does it need Vibe underneath it though to work, or is this a package
that can sit separately and just use sockets to connect to the SMTP
server as with Python?

Though I would rather there was no HTML in any email!

> ```
> Mail email = new Mail;
> email.headers["Date"] = Clock.currTime().toRFC822DateTimeString();
> email.headers["Sender"] = "Domain.com Contact Form ";
> email.headers["From"] = "\"Example\" ";
> email.headers["To"] = "\"Bas\" ";
> email.headers["Subject"] = "My subject";
> import std.stdio : File;
> email.setContent(
>  mailMixed(
>  mailRelated(
>  mailAlternative(
>  
> mailHtml("asdfasdfasdf"),
>  mailText("asdfasdfasdf")
>  )
>  ),
>  
> mailAttachment(File("test.png","rb"),"image/png","image.png"),
>  mailAttachment(cast(immutable(ubyte[]))"You are an 
> idiot!","plain/text","text.txt")
>  )
> );
> sendMail(settings, email);
> ```
> 
> [1] http://code.dlang.org/packages/vibemail
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: GuiDub

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 29 September 2015 at 07:47:31 UTC, Sönke Ludwig wrote:

Am 29.09.2015 um 08:20 schrieb Jonathan M Davis:

(...)

What would probably be more interesting is if dub were turned 
into a
library (or at least, if it guts were turned into a library, 
and the
command-line tool, dub, then used that library), and then IDEs 
could
manipulate the spec files via that library as well as do 
builds rather
than having to run a command-line tool, though it's not 
necessarily that
big a deal for an IDE to just parse the json or to run dub via 
the

command-line.



It is usable as a library! The API still needs a review pass 
before it can be declared stable for 1.0.0, though, because it 
wasn't initially considered as an external API and is still 
lacking in some areas, such as documentation.


What is missing for IDE based manipulation is just an SDL 
writer, which is planned for the next release. However, at 
least initially, that would have to be taken with a grain of 
salt, as it wouldn't preserve formatting and comments.


Awesome!

- Jonathan M Davis

Re: GuiDub

[ponce via Digitalmars-d]

On Tuesday, 29 September 2015 at 05:17:42 UTC, Jacob wrote:


"dsfml": "~master",

"std_event": "~master",
"derelict_extras-glib": "~master",
"netstack": "~master",
"luad": "~master",
"three-d": "~master",
"grape": "~master",

"civge": "~master",
"nitro": "~master",
"nitro-gen": "~master",

"process-stats": "~master",
"llvm-d": "~master",


Packages that don't have one version tag are probably 
unmaintained.

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Walter Bright via Digitalmars-d]

On 9/28/2015 11:16 PM, Jonathan M Davis wrote:

Well, I would have thought that it was clearly designed with the idea that you'd
click on the edit button to edit it. And you can copy and paste the data from
the edit dialog.


I should be able to copy any text on the screen.

Re: GuiDub

[Sönke Ludwig via Digitalmars-d]

Am 29.09.2015 um 07:17 schrieb Jacob:

On Tuesday, 29 September 2015 at 04:01:18 UTC, Jacob wrote:

On Tuesday, 29 September 2015 at 03:28:41 UTC, Rikki Cattermole wrote:

On 29/09/15 3:47 PM, Jacob wrote:

Idea:

A gui app for dub that you run, it downloads the package info from the
repository and you can select a project or create a new one and it will
automatically add or remove dependencies?

I'm having to browse the repository then manually add the dependencies
to the dub.json file... so old school!

Also, the app could provide documentation, and other
resources(tutorials, etc) related the packages.

An app probably could be created in a few days and would make the
experience more enjoyable. I'd create it myself but I'm busy at the
moment, and it would probably take a big longer than someone more
informed.


Sounds like something an IDE can be used for.


Could be integrated but not necessary. Something that can maintain and
make it easier to remove, update, and all that. doing it by hand is a
pain when you have a lot of libraries added.


Also:
Error executing command build:
Root package test1 contains reference to invalid package gtk-d

Yet I used exactly what the dub repository says to use.


also

Error executing command build:
Root package test1 contains reference to invalid package derelict-gl3

Error executing command build:
Root package test1 contains reference to invalid package derelict-sdl2

Error executing command build:
Root package test1 contains reference to invalid package gfm:math

Error executing command build:
Root package test1 contains reference to invalid package scid

Error executing command build:
Root package test1 contains reference to invalid package derelict-util

Error executing command build:
Root package test1 contains reference to invalid package gl3n

etc..

It seems like all the packages are invalid!! WTH is going on? I thought
dub was suppose to be easy and work?


Does anyone actually maintain all this or use it? Cause surely I
shouldn't be getting errors like this? I have about 50 packages in my
dub.json and they all came from copying the dependency directly(so no
mistake on my part).


{
 "name": "test1",
 "description": "A minimal D application.",


Looks quite gigantic for a minimal application ;)


 "copyright": "Copyright © 2015, Jacob",
 "authors": ["Jacob"],
 "dependencies": {
 "gfm:math": "~>3.0",
 "dplug": "~>1.1.34",
 "cerealed": "~>0.6.2",
 "imageformats": "~>5.1.0",
 "pathlib": "~>0.3.0",
 "enumap": "~>0.4.0",
 "mintegrated": "~>0.2.1",
 "speech4d": "~>0.1.0",
 "jsonizer": "~>0.5.1",
 "dgame": "~>0.6.3",
 "desil": "~>0.2.1",


 "derelict-imgui": "~>0.7.0",
 "derelict-sfml2": "~>3.0.1",


 "derelict-steamworks": "~>0.0.3",
 "derelict-util": "~>2.0.3",
 "derelict-lua": "~>1.2.2",
 "derelict-ode": "~>1.1.2",
 "derelict-allegro5": "~>0.0.2",
 "derelict_extras-mantle": "~>0.2.0",
 "derelict_extras-fann": "~>4.0.1",
 "derelict_extras-sndfile": "~>2.0.0",
 "derelict_extras-bass": "~>2.0.0",
 "derelict-cl": "~>2.0.0",
 "derelict-enet": "~>2.0.0",
 "derelict-assimp3": "~>1.0.1",
 "derelict-ft": "~>1.0.2",
 "m3d": "~>0.1.4",
 "derelict-sass": "~>2.0.0",
 "derelict-glfw3": "~>1.1.0",
 "derelict-ogg": "~>1.0.1",
 "derelict-vorbis": "~>1.0.1",
 "wave-d": "~>1.0.2",
 "derelict-physfs": "~>1.0.0",
 "derelict-il": "~>1.0.0",
 "directx-d": "~>0.9.1",
 "freeimage": "~>1.0.1+3.16.0",
 "clfft": "~>0.1.1",
 "lock-free": "~>0.1.1",
 "derelict-alure": "~>1.0.0",
 "dsfml": "~master",

 "std_event": "~master",
 "derelict_extras-glib": "~master",
 "netstack": "~master",
 "luad": "~master",
 "three-d": "~master",
 "grape": "~master",

 "civge": "~master",
 "nitro": "~master",
 "nitro-gen": "~master",

 "process-stats": "~master",
 "llvm-d": "~master",


 "bzip2": "~>0.1.0",
 "simd": "~>0.0.2",
 "cassowary-d": "~>0.0.1",
 "dcheck": "~>0.1.0",

 "d-beard": "~>2.0.0",
 "geneticd": "~>0.1.1",
 "orderedmap": "~>0.0.2",
 "stochastic": "~>0.3.0",
 "maybe-d": "~>0.0.1",
 "pack-d": "~>0.3.0",

 "quack": "~>1.0.0",
 "dshell": "~>0.0.2",
 "dgui": "~>1.0.1",
 "djack": "~>0.0.1",
 "dfl": "~>0.0.1",
 "moggle": "~>0.0.1",
 "libhell": "~>0.1.1",
 "ae": "~>1.0.1",
 "bloom": "~>0.2.1",
 "dash": "~>0.12.0-beta2",
 "dgraph": "~>0.0.1",
 "opencl": "~>1.1.3",
 "lua_d_api": "~>0.0.1",
 "descl": "~>0.5.1",
 "matte": "~>0.1.0",
 "hap": "~>1.0.0-rc.2.1",
 "voxelman": 

OllyDbg

[Cauterite via Digitalmars-d-debugger]

I'm surprised OllyDbg hasn't been mentioned in this group before. 
For 32-bit Windows it's certainly a viable option; vastly 
preferable over WinDBG for sure.


Here's how I have it set up: http://imgur.com/53a4iUS
You can see its support for PDB debugging information, with the 
source listed next to the disassembly. Obviously you'll need to 
use cv2pdb to make use of it though.
(I don't enable the source view very often though, since it makes 
Olly crash fairly regularly on my system.)


When using OllyDbg it's useful to place breakpoints in the source 
code, since the hundreds of pages of disassembly can be hard to 
navigate; DebugBreak() from kernel32.dll serves this purpose.


Lastly, if you're considering using OllyDbg, first consider 
http://x64dbg.com/
I haven't tested it out much, but it seems to have a fairly 
similar feature set to Olly, with additional support for 64-bit 
code. Hopefully it's more stable too.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 06:18:32 UTC, Suliman wrote:

Does it's work with anything except localhost?
Could you add example of sending email with gmail?


It is in the settings variable. Look at 
vibe.mail.SMTPClientSettings. 
http://vibed.org/api/vibe.mail.smtp/SMTPClientSettings


In my tests I used rackspace's mail servers.

```
auto settings = new 
SMTPClientSettings("secure.emailsrvr.com",587);

settings.authType = SMTPAuthType.login;
settings.connectionType = SMTPConnectionType.startTLS;
settings.tlsValidationMode = TLSPeerValidationMode.requireCert;
settings.username = "i...@example.com";
settings.password = "123456789";
```

Replace with whatever gmail has.

The only problem I had was with `settings.tlsValidationMode`. It 
failed with the certificates so I had to set it to `requireCert`. 
But I wouldn't do that.

Re: Go 1.5

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Sunday, 27 September 2015 at 16:54:52 UTC, Martin Nowak wrote:

On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote:
I haven't read the paper, but how does this solve collecting 
things like strings, or other "leaf types" when you use 
separate compilation units?


We'd use runtime typeinfo.


But doesn't that imply a full scan when you are scanning for 
common types that live on leaf nodes in the graph?


The easy thing to do is to use GC locally (like for a fiber) 
and use
move semantics for moving objects from one locality to the 
other

(between fibers).


Though it's challenging to efficiently manage all the GC 
structures for a small scope. Doing this per thread is a proven 
technology (see 
https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc).


That's a good start, but hardware threads range from 1-32 threads 
on current CPUs, so it is likely to affect modelling more than 
doing it on an actor/fiber level. If you could group N actors on 
a single GC heap you could run a simulation across many threads 
and then collect inbetween.


Btw, C++ appears to get the semi-stackless co-routines (no state 
on stack when yielding), which also appears to be the model used 
in Pony-lang. D really should consider a move in that direction 
combined with it's GC strategy.

Re: enum to flags

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 06:08:03 UTC, Cauterite wrote:
On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson 
wrote:
so I have a bunch of enums (0 .. n) that i also want to 
represent as flags ( 1 << n foreach n ). Is there anyway to do 
this other than a string mixin?


You could cheat with operator overloading:

enum blah {
foo,
bar,
baz,
};

struct EnumToFlags(alias E) {
template opDispatch(string Name) {
enum opDispatch = 1 << __traits(getMember, E, Name);
};
};

alias blahFlags = EnumToFlags!blah;

static assert(blahFlags.foo == (1 << blah.foo));
static assert(blahFlags.bar == (1 << blah.bar));
static assert(blahFlags.baz == (1 << blah.baz));


Cheating is always good. I'l probably add some template 
constraints.


Thanks
Nic

Re: GuiDub

[Sönke Ludwig via Digitalmars-d]

Am 29.09.2015 um 08:20 schrieb Jonathan M Davis:

(...)

What would probably be more interesting is if dub were turned into a
library (or at least, if it guts were turned into a library, and the
command-line tool, dub, then used that library), and then IDEs could
manipulate the spec files via that library as well as do builds rather
than having to run a command-line tool, though it's not necessarily that
big a deal for an IDE to just parse the json or to run dub via the
command-line.



It is usable as a library! The API still needs a review pass before it 
can be declared stable for 1.0.0, though, because it wasn't initially 
considered as an external API and is still lacking in some areas, such 
as documentation.


What is missing for IDE based manipulation is just an SDL writer, which 
is planned for the next release. However, at least initially, that would 
have to be taken with a grain of salt, as it wouldn't preserve 
formatting and comments.

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
Grøstad wrote:
What tools can D successfully replace? Give a focused answer to 
that and you can improve on D to a level where it becomes 
attractive.


But keep it real. Fear among programmers is not D's main issue. 
That's just an excuse.


And just to avoid a misundertanding here:

1. That C# and Java programmers end up being disgruntled is not a 
failure of the language, that is a failure of communicating that 
D is a system level programming language. It is not a fear issue, 
they just ended up in the wrong neighbourhood.


2. When people who are looking for a system level programming 
language get disgruntled then you need to pay attention. It is 
still not a fear issue, there are so few system level languages 
to pick from that people looking for alternatives cannot afford 
to be "picky".


D2 is pretty much C++ with a Boehm collector attached to it. So 
to get traction D has to improve on that model significantly OR 
change direction completely.

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 29 September 2015 at 03:33:20 UTC, Walter Bright 
wrote:

On 9/28/2015 6:42 PM, Jonathan M Davis wrote:
On Monday, 28 September 2015 at 23:44:55 UTC, Walter Bright 
wrote:

On 9/28/2015 2:41 PM, rumbu wrote:
Pressing Ctrl-C in any *standard* dialog will copy the text 
to clipboard since

Windows 2000, even captions and buttons.


Nope. Doesn't work in the Environment Variables dialog box. 
Doesn't work in
the Thunderbird about box. Doesn't work in the Notepad about 
box. Doesn't work
in the IE about box. Or any of the IE dialog boxes I tried, 
like Internet

Options.

I haven't found ANY where it works.


Hmmm. I'm don't know what you're doing differently from the 
rest of us.
Certainly, the text in about boxes isn't usually selectable, 
but aren't we
specifically talking about the dialog for editing environment 
variables here? If
I open the environment variable dialog, select Path, and click 
on the edit

button,


Try selecting any text in the dialog box before opening another 
one with the edit button. Or try any of the ones I mentioned.


Well, I would have thought that it was clearly designed with the 
idea that you'd click on the edit button to edit it. And you can 
copy and paste the data from the edit dialog. So, not being able 
to edit the fields in the first dialog really isn't a big deal 
IMHO, though what they give you with the edit dialog really isn't 
any better than simply being able to edit it in the initial 
dialog. So, in that sense, maybe they should have just made it 
editable in the first dialog rather than having to open one 
specifically to edit it, though it would be far better to 
actually make the edit dialog sane rather than just a simple text 
box. Fortunately though, it sounds like the edit dialog is 
finally becoming sane with Windows 10.



> And I can now edit that text and copy it back into the edit
field for the Path variable, which is stupid to have to do but 
is a lot saner than editing the text in the edit box directly.


Surely a dialog box stinks if you have to paste its contents 
into an editor to edit it.


Well, of course, it sucks. Having the PATH be edited via a single 
text field isn't even vaguely user friendly. Copy-pasting to edit 
it just a way to make it slightly more sane. What it really needs 
is to be revamped in a manner similar to what they've apparently 
finally done with Windows 10.


- Jonathan M Davis

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Suliman via Digitalmars-d-announce]

Does it's work with anything except localhost?
Could you add example of sending email with gmail?

Re: This Week in D #37 - forum tutorials and tip on using UDAs

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-09-28 15:03, Adam D. Ruppe wrote:


The tip here is one I've been talking about on irc a little and decided
to write up this time. Using a mixin template to hold the source code of
a thing to be transformed is something I think is kinda cool though
I haven't actually used it in a real project yet. (Actually, I've barely
used UDAs in the real world at all yet. I was so excited for them when
they were new, but it took so long to materialize that I found other
ways to do my stuff and now haven't transitioned!)


This looks pretty cool. Unfortunately the original code needs to be 
contained inside a template :( .


--
/Jacob Carlborg

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

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

On Tuesday, 29 September 2015 at 12:43:19 UTC, Daniel Kozak wrote:

It would be nice to have all of yours stuff on code.dlang.org.


I'm slowly working on it. Got some working just yesterday:
http://code.dlang.org/packages/arsd-official

but the repo doesn't let you show subpackages, argh. dub sucks, 
code.dlang.org sucks.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 12:43:19 UTC, Daniel Kozak wrote:

Adam D.Ruppe píše v Út 29. 09. 2015 v 12:05 +:
If you ever need something in D, ask me first there's a 
good chance I've written it!


https://github.com/adamdruppe/arsd/blob/master/email.d

there's also a good chance I haven't documented it too 
though...




Thanks, I will look at it.

I only look at code.dlang.org. It would be nice to have all of 
yours stuff on code.dlang.org.


While I use some of adam's code, it is often the last place I 
look - if I remember at all. In this case I didn't, and decided 
to write something myself.


Which is sad, since had I remembered to look in adam's repo, I 
probably wouldn't have written this library; and saved myself a 
day or two.


You really need to get your stuff out in the open adam.

Re: GuiDub

[Jacob Carlborg via Digitalmars-d]

On 2015-09-29 09:47, Sönke Ludwig wrote:


It is usable as a library! The API still needs a review pass before it
can be declared stable for 1.0.0, though, because it wasn't initially
considered as an external API and is still lacking in some areas, such
as documentation.


Ideally the library on the application should be more separated. I see 
that the library configuration in the dub.json file only excludes app.d. 
I doubt that the library depends on "dub.commandline", if it does not, 
then it's not a very good separation.


--
/Jacob Carlborg

Re: enum to flags

[Cauterite via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson 
wrote:
so I have a bunch of enums (0 .. n) that i also want to 
represent as flags ( 1 << n foreach n ). Is there anyway to do 
this other than a string mixin?


You could cheat with operator overloading:

enum blah {
foo,
bar,
baz,
};

struct EnumToFlags(alias E) {
template opDispatch(string Name) {
enum opDispatch = 1 << __traits(getMember, E, Name);
};
};

alias blahFlags = EnumToFlags!blah;

static assert(blahFlags.foo == (1 << blah.foo));
static assert(blahFlags.bar == (1 << blah.bar));
static assert(blahFlags.baz == (1 << blah.baz));

Re: GuiDub

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 29 September 2015 at 02:47:32 UTC, Jacob wrote:

Idea:

A gui app for dub that you run, it downloads the package info 
from the repository and you can select a project or create a 
new one and it will automatically add or remove dependencies?


I'm having to browse the repository then manually add the 
dependencies to the dub.json file... so old school!


Also, the app could provide documentation, and other 
resources(tutorials, etc) related the packages.


An app probably could be created in a few days and would make 
the experience more enjoyable. I'd create it myself but I'm 
busy at the moment, and it would probably take a big longer 
than someone more informed.


I expect that most of the folks around here would just as soon 
edit the dub.json file, considering that most of the folks around 
here aren't big fans of IDEs. But if you think that a GUI-based 
tool to edit dub.json files would be useful, then feel free to 
write one. I rather doubt that anyone else is going to though. It 
really isn't that much work to edit a dub.json file, and it's not 
something that you need to do very often for a project.


What would probably be more interesting is if dub were turned 
into a library (or at least, if it guts were turned into a 
library, and the command-line tool, dub, then used that library), 
and then IDEs could manipulate the spec files via that library as 
well as do builds rather than having to run a command-line tool, 
though it's not necessarily that big a deal for an IDE to just 
parse the json or to run dub via the command-line.


- Jonathan M Davis

Re: A new article about working with files in D

[Suliman via Digitalmars-d-announce]

Big thanks! It's very helpful for newcomers. D need extend Phobos 
docs with such examples. Is there any plan to do it, because it's 
often it's hard to understand how to proper use functions.


Also I think you need to add example of getting file list (all 
and with specified extension).


Also some FTP examples maybe very good.

Re: GuiDub

[ponce via Digitalmars-d]

On Tuesday, 29 September 2015 at 07:43:10 UTC, Sönke Ludwig wrote:


I'd say that there simply are version conflicts within this 
huge dependency graph (e.g. "meatbox" requires "gl3n" 1.1.0, 
but another dependency requires 1.0.0). The current dependency 
resolution algorithm (which is planned to be revamped) is quite 
bad at outputting good error messages in many situations 
(technically there often isn't an unambiguous error message, 
but then it often picks one of the less helpful ones).


I think you said once that the dependency resolution is 
NP-complete.


Could you provide a layman description of what is this particular 
problem? Just curiosity.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Daniel Kozak via Digitalmars-d-announce]

Adam D.Ruppe píše v Út 29. 09. 2015 v 12:05 +:
> On Tuesday, 29 September 2015 at 08:54:39 UTC, Daniel Kozak wrote:
> > Wow, I need something like this 3 weeks ago, but I dont have 
> > time to implement this myself, so I end up with phpMailer. Now 
> > I can switch my little e-mailing system to Dlang. Thank you.
> 
> If you ever need something in D, ask me first there's a good 
> chance I've written it!
> 
> https://github.com/adamdruppe/arsd/blob/master/email.d
> 
> there's also a good chance I haven't documented it too 
> though...
> 
> but the way mine works is something like:
> 
> ---
> import arsd.email;
> void main() {
>  auto message = new EmailMessage();
>  message.to ~= "destructiona...@gmail.com";
>  message.from = "t...@arsdnet.net";
>  message.subject = "test";
>  message.setHtmlBody(" />test");
>  message.addAttachment("text/csv", "cool.csv", 
> "whoa,mang");
>  message.addAttachment("text/wtf", "whoa.wtf", "WTF\nMAN");
>  message.addInlineImage("amazing", "image/png", 
> "black.png",
> import("black.png"));
>  message.send();
> }
> ---
> 
> 
> The send method uses std.net.curl to do the actual sending (the 
> smtp connection information is a default argument to the method.
> 
> 
> My lib also has a function:
> 
> void email(string to, string subject, string message, string 
> from, RelayInfo mailServer = RelayInfo("smtp://localhost")) {}
> 
> 
> for sending a plain text email quickly and easily, similar to 
> PHP's mail function.

Thanks, I will look at it.

I only look at code.dlang.org. It would be nice to have all of yours
stuff on code.dlang.org.

Re: enum to flags

[Meta via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson 
wrote:
so I have a bunch of enums (0 .. n) that i also want to 
represent as flags ( 1 << n foreach n ). Is there anyway to do 
this other than a string mixin?


use like:

enum blah
{
foo,
bar,
baz,
}

alias blahFlags = EnumToFlags!blah;

static assert(blahFlags.baz == 1 << blah.baz)


Take a look at the BitFlags template as well. It won't create 
such an enum for you, but will provide a convenient wrapper for 
using it afterword:


http://dlang.org/phobos/std_typecons.html#.BitFlags

Re: enum to flags

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 09:18:52 UTC, John Colvin wrote:
On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson 
wrote:
so I have a bunch of enums (0 .. n) that i also want to 
represent as flags ( 1 << n foreach n ). Is there anyway to do 
this other than a string mixin?


use like:

enum blah
{
foo,
bar,
baz,
}

alias blahFlags = EnumToFlags!blah;

static assert(blahFlags.baz == 1 << blah.baz)


Answering a slightly different question, I just wanted to be 
sure you're aware of this old idiom:


enum blah
{
foo = 0b1;
bar = 0b10;
baz = 0b100;
//and so on...
}

auto fdsa = blah.foo | blah.baz;
assert(fdsa & blah.foo);
assert(fdsa & blah.baz);
assert(!(fdsa & blah.bar));


I am. The reason I wanted was so i could easily reorder them 
(logical groupings etc. ) .


Nic

Re: Moving back to .NET

[John Colvin via Digitalmars-d]

On Tuesday, 29 September 2015 at 11:40:20 UTC, Ola Fosheim 
Grøstad wrote:
On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin 
wrote:
actually use the product. If you can put your theoretical mind 
on hold for a few days and actually immerse yourself in the 
language and its idioms for practical use*, you'd see that D 
has a large feature-overlap with to up-to-date C++, but often 
feels very different in practice.


There is nothing theoretical about this, I am only concerned 
about the language, not the standard library. The same with C++.


One usually don't judge a system level language based on its 
libraries. System level usage of the same system level language 
can be very different because people use different core 
libraries. So there is essentially no reason to complain about 
D's libraries.


If you look for system level programming you also essentially 
agree to writing the libraries you need or create bindings to 
whatever system you intend to build for.  I am not interested 
in Phobos, I am not fond of it and I don't focus on it since I 
don't have to use it. I am interested in the language/runtime, 
not libraries which I understand that I have to do on my own.


Ok, that's fine, but your comments don't generally come with a 
"this observation is limited to very bare-bones code, beyond 
which I am not interested to think about" caveat, the stuff your 
saying is often very wide-ranging. Also, even for the low-level 
work that you specialise in, practice can lead to insights.

Re: Idioms you use

[anonymous via Digitalmars-d]

On Tuesday 29 September 2015 15:06, Cauterite wrote:

> some statements

Buf of course! I totally didn't think of multiple statements. Thanks.

Re: GuiDub

[Jacob Carlborg via Digitalmars-d]

On 2015-09-29 08:20, Jonathan M Davis wrote:


I expect that most of the folks around here would just as soon edit the
dub.json file, considering that most of the folks around here aren't big
fans of IDEs. But if you think that a GUI-based tool to edit dub.json
files would be useful, then feel free to write one. I rather doubt that
anyone else is going to though.


I have actually thought about that. But more to test writing a GUI in D, 
rather than for the functionality.


--
/Jacob Carlborg

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Suliman via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 08:17:42 UTC, Sebastiaan Koppe 
wrote:

On Tuesday, 29 September 2015 at 06:18:32 UTC, Suliman wrote:

Does it's work with anything except localhost?
Could you add example of sending email with gmail?


It is in the settings variable. Look at 
vibe.mail.SMTPClientSettings. 
http://vibed.org/api/vibe.mail.smtp/SMTPClientSettings


In my tests I used rackspace's mail servers.

```
auto settings = new 
SMTPClientSettings("secure.emailsrvr.com",587);

settings.authType = SMTPAuthType.login;
settings.connectionType = SMTPConnectionType.startTLS;
settings.tlsValidationMode = TLSPeerValidationMode.requireCert;
settings.username = "i...@example.com";
settings.password = "123456789";
```

Replace with whatever gmail has.

The only problem I had was with `settings.tlsValidationMode`. 
It failed with the certificates so I had to set it to 
`requireCert`. But I wouldn't do that.


I am asking because I had troubles with vibed 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/25447/

[Issue 15110] pragma(inline) rarely works how I want it to

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15110

yebblies  changed:

   What|Removed |Added

 CC||yebbl...@gmail.com

--- Comment #3 from yebblies  ---
> pragma(inline) rarely works how I want it to

How exactly are you expecting pragma(inline) to work?

--

Re: This Week in D #37 - forum tutorials and tip on using UDAs

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-09-29 14:10, Adam D. Ruppe wrote:


Though, I just had an idea on how that might be simplified don't
recreate them, just alias them!



So, conceptually, you'd do something like:


template transformer(alias member) {
 static if(hasUDA!(member, thing))
 mixin(transformed_version_of_member());
 else
 alias member = member;
}
mixin staticMap!(AllMembers!impl_module, transformer);


This looks even more interesting :)

--
/Jacob Carlborg

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Robert M. Münch via Digitalmars-d-announce]

On 2015-09-29 03:53:44 +, Sebastiaan Koppe said:


This library[1] allows you to send multi-part emails with attachments.

```
Mail email = new Mail;
email.headers["Date"] = Clock.currTime().toRFC822DateTimeString();
email.headers["Sender"] = "Domain.com Contact Form ";
email.headers["From"] = "\"Example\" ";
email.headers["To"] = "\"Bas\" ";
email.headers["Subject"] = "My subject";
import std.stdio : File;
email.setContent(
 mailMixed(
 mailRelated(
 mailAlternative(
 
mailHtml("asdfasdfasdf"),

 mailText("asdfasdfasdf")
 )
 ),
 mailAttachment(File("test.png","rb"),"image/png","image.png"),
 mailAttachment(cast(immutable(ubyte[]))"You are an 
idiot!","plain/text","text.txt")

 )
);
sendMail(settings, email);


Not that I'm to deep into the code nor D but would it be possible to 
write it somehow like this:


Mail email = new Mail;

email.headers = [
"Date" Clock...,
"Sender" ...
]

This would be a much more descriptive approach, which I think makes a 
lot of sense for such things. And it follows the "dont repeat yourself" 
pattern.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Kagamin via Digitalmars-d]

On Monday, 28 September 2015 at 19:44:11 UTC, Walter Bright wrote:
This really blows when you've got a message window with an 
error message in it, and you cannot copy it to google it. You 
cannot copy the "About" dialog box text, either, so you have to 
painfully type in the version/build number when filing a bug 
report.


AFAIK, bugzilla supports simple links that create a bug report 
with prefilled information like program version, so a better way 
is to provide such link in the program interface similar to 
bugreporting scripts in linux that gather all relevant system 
information as an attachment.

Re: Idioms you use

[anonymous via Digitalmars-d]

On Monday 28 September 2015 23:40, Freddy wrote:

> Are any D idioms you use that you like to share?
> Heres one of mine
> ---
> enum ctfe =
> {
>  return 0xdead & 0xbad;
> }();
> ---

Why not just `enum ctfe = 0xdead & 0xbad;`?

Are there cases where `enum foo = {return bar;}();` works but `enum foo = 
bar;` doesn't? And if there are, aren't they compiler bugs?

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 12:26:58 UTC, Robert M. Münch 
wrote:
Not that I'm to deep into the code nor D but would it be 
possible to write it somehow like this:


Mail email = new Mail;

email.headers = [
"Date" Clock...,
"Sender" ...
]

This would be a much more descriptive approach, which I think 
makes a lot of sense for such things. And it follows the "dont 
repeat yourself" pattern.


The Mail class is from vibe.d

I suppose the headers members could accept `string[string]` 
assignment.

Re: Idioms you use

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 29 September 2015 at 12:52:36 UTC, anonymous wrote:
Are there cases where `enum foo = {return bar;}();` works but 
`enum foo = bar;` doesn't? And if there are, aren't they 
compiler bugs?


If it is more complex than just one statement, putting it in a 
function lets you execute multiple lines (including loops and 
stuff) at once.

Re: Idioms you use

[Cauterite via Digitalmars-d]

On Tuesday, 29 September 2015 at 12:52:36 UTC, anonymous wrote:

Why not just `enum ctfe = 0xdead & 0xbad;`?

Are there cases where `enum foo = {return bar;}();` works but 
`enum foo = bar;` doesn't? And if there are, aren't they 
compiler bugs?


I'm pretty sure he's talking about the general use of an 
anonymous function invocation assigned to an enum to force some 
statements to be executed at compile time. His example was not 
very illustrative though.

Parser assertion

[Andrea Fontana via Digitalmars-d]

This (wrong!) code:

struct ExampleStruct(S) { }

template ExampleTemplate(K)
{
enum ExampleTemplate(struct ExampleStruct(K)) = K;
}

void main()
{

}

Trigger a parser error:

dmd: parse.c:4226: Dsymbols* 
Parser::parseAutoDeclarations(StorageClass, const utf8_t*): 
Assertion `token.value == TOKassign' failed.



Should I fill a bug?

Re: Moving back to .NET

[John Colvin via Digitalmars-d]

On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim 
Grøstad wrote:
D2 is pretty much C++ with a Boehm collector attached to it. So 
to get traction D has to improve on that model significantly OR 
change direction completely.


You speak like someone who's read the spec, but doesn't actually 
use the product. If you can put your theoretical mind on hold for 
a few days and actually immerse yourself in the language and its 
idioms for practical use*, you'd see that D has a large 
feature-overlap with to up-to-date C++, but often feels very 
different in practice. Maybe take some of the time you spend 
writing theoretically motivated forum posts and turn it in to 
some practical experience?


P.S. forgive me if I'm wrong and you have done a bunch of serious 
coding in D, it just seemed unlikely seeing as you never seem to 
make specific practical complaints with example code, it's always 
an overarching principle or grand direction problem.

Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?

[Sebastiaan Koppe via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 09:15:29 UTC, ponce wrote:
On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe 
wrote:
I could not find out which redistributable I had to install 
(what version of VS did you have installed / on what version 
of windows are you?). I decided to install them all, but 
couldn't install the one for 2015 (due to 
Windows6.1-KB2999226-x64.msu). After trying some workarounds I 
gave up.




You need the VC++ 2015 64-bit redistributable.


Can you either link statically or try an older version of VC, one 
that is more likely to be found in the wild? (or does ldc require 
2015?)


I really want to try your game :)

Re: Get template parameter value

[John Colvin via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 09:53:39 UTC, Kagamin wrote:
On Tuesday, 29 September 2015 at 09:11:15 UTC, John Colvin 
wrote:
Welcome to the weird and wonderful work of  
http://dlang.org/expression.html#IsExpression


No, use template pattern matching instead:

struct A(int s){}
template B(T:A!s, int s){ enum B=s; }
static assert(B!(A!4)==4);


For some reason I never think of template pattern matching. Not 
my favourite feature, although it's probably just the ':' that 
bothers me, I always think of implicit convertibility like in 
is(T : Q). Anyway, you're right, it makes for shorter, neater 
code in simple cases (the static if version is equivalent if you 
just add a template constraint to it).

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

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

On Tuesday, 29 September 2015 at 08:54:39 UTC, Daniel Kozak wrote:
Wow, I need something like this 3 weeks ago, but I dont have 
time to implement this myself, so I end up with phpMailer. Now 
I can switch my little e-mailing system to Dlang. Thank you.


If you ever need something in D, ask me first there's a good 
chance I've written it!


https://github.com/adamdruppe/arsd/blob/master/email.d

there's also a good chance I haven't documented it too 
though...


but the way mine works is something like:

---
import arsd.email;
void main() {
auto message = new EmailMessage();
message.to ~= "destructiona...@gmail.com";
message.from = "t...@arsdnet.net";
message.subject = "test";
message.setHtmlBody("/>test");
message.addAttachment("text/csv", "cool.csv", 
"whoa,mang");

message.addAttachment("text/wtf", "whoa.wtf", "WTF\nMAN");
message.addInlineImage("amazing", "image/png", 
"black.png",

import("black.png"));
message.send();
}
---


The send method uses std.net.curl to do the actual sending (the 
smtp connection information is a default argument to the method.



My lib also has a function:

void email(string to, string subject, string message, string 
from, RelayInfo mailServer = RelayInfo("smtp://localhost")) {}



for sending a plain text email quickly and easily, similar to 
PHP's mail function.

Re: running code on the homepage

[Damian Ziemba via Digitalmars-d]

On Monday, 28 September 2015 at 14:15:18 UTC, ixid wrote:

On Thursday, 17 September 2015 at 14:48:07 UTC, nazriel wrote:
On Wednesday, 16 September 2015 at 20:52:08 UTC, Andrei 
Alexandrescu wrote:

On 09/16/2015 09:49 AM, nazriel wrote:

[...]


That's great, thanks for doing this. What is the current 
status with regard to making the online compilation 
infrastructure publicly accessible and improvable? Ideally 
everything would be


That's the plan.
Currently I am working on upgrading both frontend and backend 
to be up-to-date with current requirements. I am also trying 
to integrate the look of dpaste.dzfl.pl to match the one on 
dlang.org so we could make dpaste part of the *.dlang.org 
fleet.



Hi Damian,

dpaste doesn't seem to produce any console output at the 
moment, I just get 'Result: Success  / Return code: 0' and 
nothing from writeln.


Thanks for the heads up!

I am tinkering with the new backend and even though I double 
check if dlang.org examples still work I missed dpaste itself %)


Anyways, fixed

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 29 September 2015 at 07:29:23 UTC, Walter Bright 
wrote:

On 9/28/2015 11:16 PM, Jonathan M Davis wrote:
Well, I would have thought that it was clearly designed with 
the idea that you'd
click on the edit button to edit it. And you can copy and 
paste the data from

the edit dialog.


I should be able to copy any text on the screen.


Well, I don't know of any operating system where that's possible. 
For instance, clicking on the title bar and dragging the mouse is 
going to result in the window being dragged in every desktop 
environment that I know of, not select the text on it, and it 
would never work for the text on a button to be selectable, since 
any attempt to select it would press the button. Maybe more of 
the text in GUIs should be copyable than is, but that's pretty 
clearly not generally a goal of GUI designers or of how GUI 
toolkits are designed.


There have certainly been times where I've wanted to copy text 
that was not selectable for some reason (or selectable but not 
copyable), but it sounds like you have a much higher expectation 
of text selectability than I do.


- Jonathan M Davis

Re: zip packages to pack modules

[bachmeier via Digitalmars-d]

On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:


Use Case

* Include libraries in a project in one step.
* Versioning is much easier. Programmer creates a library with 
many modules in it. ZIP packs them, and gives a version number 
to it in filename. No more changes will be made on it. (This is 
my #1 reasoning)

* Work of newcomers can be eased.


This could be accomplished by including dub in the default 
installation (already scheduled to happen) and then adding 
something like pragma("dep", ["lib1", "lib2", "lib3"]).


For better or worse, it looks like the decision has been made to 
go with Dub. I think it's a mistake, because (i) it increases the 
learning curve, and (ii) the documentation was not written for 
newcomers (AFAICT the way to learn is to look at existing 
packages and then learn by trial and error). But what I think 
doesn't matter; the decision has been made to use Dub, so there 
is no chance that another approach will be taken.

[Issue 15127] Parser assertion on wrong code

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15127

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com
   Severity|enhancement |normal

--

[Issue 15127] Parser assertion on wrong code

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15127

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5143

--

Re: Get template parameter value

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 07:50:42 UTC, rumbu wrote:

Having a template:

struct SomeStruct(int size)
{

}

Is there any language trait returning the value of size 
template parameter for the template instantiation SomeStruct!10?


Something like this is ok?

struct SomeStruct(int size)
{
enum structSize = size;
}

template isSomeStruct(alias S)
{
void check(alias T)(SomeStruct!T val) { }
enum isSomeStruct = __traits(compiles, check(S));
}

template getStructSize(alias S) if (isSomeStruct!S)
{
enum getStructSize = S.structSize;
}

void main()
{
import std.stdio;
SomeStruct!10 test;
writeln(isSomeStruct!test);
writeln(getStructSize!test);
}

Re: GuiDub

[Kagamin via Digitalmars-d]

On Tuesday, 29 September 2015 at 08:04:57 UTC, ponce wrote:
I think you said once that the dependency resolution is 
NP-complete.


Exponential algorithmic complexity.

Re: Parser assertion

[Andrea Fontana via Digitalmars-d]

On Tuesday, 29 September 2015 at 08:59:35 UTC, Jonathan M Davis 
wrote:
On Tuesday, 29 September 2015 at 08:51:42 UTC, Andrea Fontana 
wrote:

This (wrong!) code:

struct ExampleStruct(S) { }

template ExampleTemplate(K)
{
enum ExampleTemplate(struct ExampleStruct(K)) = K;
}

void main()
{

}

Trigger a parser error:

dmd: parse.c:4226: Dsymbols* 
Parser::parseAutoDeclarations(StorageClass, const utf8_t*): 
Assertion `token.value == TOKassign' failed.



Should I fill a bug?


You should always file a bug when the compiler fails an 
assertion, segfaults, or otherwise crashes.


- Jonathan M Davis


Done: https://issues.dlang.org/show_bug.cgi?id=15127

Re: enum to flags

[John Colvin via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson 
wrote:
so I have a bunch of enums (0 .. n) that i also want to 
represent as flags ( 1 << n foreach n ). Is there anyway to do 
this other than a string mixin?


use like:

enum blah
{
foo,
bar,
baz,
}

alias blahFlags = EnumToFlags!blah;

static assert(blahFlags.baz == 1 << blah.baz)


Answering a slightly different question, I just wanted to be sure 
you're aware of this old idiom:


enum blah
{
foo = 0b1;
bar = 0b10;
baz = 0b100;
//and so on...
}

auto fdsa = blah.foo | blah.baz;
assert(fdsa & blah.foo);
assert(fdsa & blah.baz);
assert(!(fdsa & blah.bar));

Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?

[ponce via Digitalmars-d-learn]

On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe 
wrote:
I could not find out which redistributable I had to install 
(what version of VS did you have installed / on what version of 
windows are you?). I decided to install them all, but couldn't 
install the one for 2015 (due to Windows6.1-KB2999226-x64.msu). 
After trying some workarounds I gave up.




You need the VC++ 2015 64-bit redistributable.

Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?

[Kagamin via Digitalmars-d-learn]

On Monday, 28 September 2015 at 16:36:47 UTC, ponce wrote:
OK, but why does that need to happen? I don't get why does 
linking with MS linker implies a runtime dependency.


I thought we would be left out of these sort of problems when 
using D :(


About universal CRT: 
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

https://support.microsoft.com/en-us/kb/2999226

Re: New blog about D

[Chris via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 04:19:58 UTC, Mike Parker wrote:

On Monday, 28 September 2015 at 14:26:35 UTC, Chris wrote:




I really don't like blog posts that have overly broad titles 
when the subject matter is technical. I think the title should 
be as specific as possible so that I know if it's something I 
care about. If I see a general title about game development 
that refers to something that only touches a specific aspect of 
it, one that I'm not interested in, I'll just feel like I've 
wasted my time. Moreover, when I am doing a search for 
something specific, the blog title is often all I pay attention 
to as I can the search results. A more specific title helps out 
a lot.


It depends on what the blogger in question wants. If s/he wants 
to draw attention to D in general and give examples of how D is 
useful to solve certain problems (e.g. with templates, mixins 
etc), then the title should be more general. The next article 
might be about processing big data in D - then it should have 
"big data" in the title/tag/keywords and not just something that 
refers to one specific aspect of big data handling. The point is 
that if people see D being associated with various aspects of 
programming (games, big data), it gets them interested in D in 
general.


If, however, the blogger only wants to talk about D to people who 
already use D, then s/he might as well be more specific.

Re: std.data.json formal review

[Marc Schütz via Digitalmars-d]

On Monday, 28 September 2015 at 07:02:35 UTC, Marco Leise wrote:

Am Tue, 18 Aug 2015 09:05:32 +
schrieb "Marc Schütz" :

Or, as above, leave it to the end user and provide a `to(T)` 
method that can support built-in types and `BigInt` alike.


You mean the user should write a JSON number parsing routine
on their own? Then which part is responsible for validation of
JSON contraints? If it is the to!(T) function, then it is
code duplication with chances of getting something wrong,
if it is the JSON parser, then the number is parsed twice.
Besides, there is a lot of code to be shared for every T.


No, the JSON type should just store the raw unparsed token and 
implement:


struct JSON {
T to(T) if(isNumeric!T && is(typeof(T("" {
return T(this.raw);
}
}

The end user can then call:

auto value = json.to!BigInt;

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:
actually use the product. If you can put your theoretical mind 
on hold for a few days and actually immerse yourself in the 
language and its idioms for practical use*, you'd see that D 
has a large feature-overlap with to up-to-date C++, but often 
feels very different in practice.


There is nothing theoretical about this, I am only concerned 
about the language, not the standard library. The same with C++.


One usually don't judge a system level language based on its 
libraries. System level usage of the same system level language 
can be very different because people use different core 
libraries. So there is essentially no reason to complain about 
D's libraries.


If you look for system level programming you also essentially 
agree to writing the libraries you need or create bindings to 
whatever system you intend to build for.  I am not interested in 
Phobos, I am not fond of it and I don't focus on it since I don't 
have to use it. I am interested in the language/runtime, not 
libraries which I understand that I have to do on my own.

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Kagamin via Digitalmars-d]

On Monday, 28 September 2015 at 23:44:55 UTC, Walter Bright wrote:

On 9/28/2015 2:41 PM, rumbu wrote:
Pressing Ctrl-C in any *standard* dialog will copy the text to 
clipboard since

Windows 2000, even captions and buttons.


Nope. Doesn't work in the Environment Variables dialog box. 
Doesn't work in the Thunderbird about box. Doesn't work in the 
Notepad about box. Doesn't work in the IE about box. Or any of 
the IE dialog boxes I tried, like Internet Options.


I haven't found ANY where it works.


That applies to error messages that use standard windows message 
box:
This really blows when you've got a message window with an 
error message in it, and you cannot copy it to google it.

Re: Get template parameter value

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 08:44:03 UTC, Andrea Fontana 
wrote:

On Tuesday, 29 September 2015 at 07:50:42 UTC, rumbu wrote:

Having a template:

struct SomeStruct(int size)
{

}

Is there any language trait returning the value of size 
template parameter for the template instantiation 
SomeStruct!10?


Something like this is ok?

struct SomeStruct(int size)
{
enum structSize = size;
}

template isSomeStruct(alias S)
{
void check(alias T)(SomeStruct!T val) { }
enum isSomeStruct = __traits(compiles, check(S));
}

template getStructSize(alias S) if (isSomeStruct!S)
{
enum getStructSize = S.structSize;
}

void main()
{
import std.stdio;
SomeStruct!10 test;
writeln(isSomeStruct!test);
writeln(getStructSize!test);
}


You can also write void check(alias T) as void check(int T), of 
course.

[Issue 15127] New: Parser assertion on wrong code

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15127

  Issue ID: 15127
   Summary: Parser assertion on wrong code
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: tri...@katamail.com

This (wrong!) code:

struct ExampleStruct(S) { }

template ExampleTemplate(K)
{
enum ExampleTemplate(struct ExampleStruct(K)) = K;
}

void main()
{

}

Trigger a parser error:

dmd: parse.c:4226: Dsymbols* Parser::parseAutoDeclarations(StorageClass, const
utf8_t*): Assertion `token.value == TOKassign' failed.

--

Re: Parser assertion

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 29 September 2015 at 08:51:42 UTC, Andrea Fontana 
wrote:

This (wrong!) code:

struct ExampleStruct(S) { }

template ExampleTemplate(K)
{
enum ExampleTemplate(struct ExampleStruct(K)) = K;
}

void main()
{

}

Trigger a parser error:

dmd: parse.c:4226: Dsymbols* 
Parser::parseAutoDeclarations(StorageClass, const utf8_t*): 
Assertion `token.value == TOKassign' failed.



Should I fill a bug?


You should always file a bug when the compiler fails an 
assertion, segfaults, or otherwise crashes.


- Jonathan M Davis

Re: Get template parameter value

[rumbu via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 09:53:39 UTC, Kagamin wrote:
On Tuesday, 29 September 2015 at 09:11:15 UTC, John Colvin 
wrote:
Welcome to the weird and wonderful work of  
http://dlang.org/expression.html#IsExpression


No, use template pattern matching instead:

struct A(int s){}
template B(T:A!s, int s){ enum B=s; }
static assert(B!(A!4)==4);


Thank you, this is perfect.

Re: Get template parameter value

[John Colvin via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 07:50:42 UTC, rumbu wrote:

Having a template:

struct SomeStruct(int size)
{

}

Is there any language trait returning the value of size 
template parameter for the template instantiation SomeStruct!10?


This should do it (untested):

template SomeStructSize(T)
{
static if(is(T == SomeStruct!n, n))
enum SomeStructSize = n;
else static assert(false, T.stringof ~ " is not an instance 
of SomeStruct");

}

Welcome to the weird and wonderful work of  
http://dlang.org/expression.html#IsExpression

Re: Moving back to .NET

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:
On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim 
Grøstad wrote:
D2 is pretty much C++ with a Boehm collector attached to it. 
So to get traction D has to improve on that model 
significantly OR change direction completely.


You speak like someone who's read the spec, but doesn't 
actually use the product. If you can put your theoretical mind 
on hold for a few days and actually immerse yourself in the 
language and its idioms for practical use*, you'd see that D 
has a large feature-overlap with to up-to-date C++, but often 
feels very different in practice. Maybe take some of the time 
you spend writing theoretically motivated forum posts and turn 
it in to some practical experience?


P.S. forgive me if I'm wrong and you have done a bunch of 
serious coding in D, it just seemed unlikely seeing as you 
never seem to make specific practical complaints with example 
code, it's always an overarching principle or grand direction 
problem.


I have no idea what experience with D Ola really has, but I 
wouldn't have expected anyone to say that D2 is C++ with a 
garbage collector. The GC is a such a small part of D, and there 
are so many features that it has that either C++ doesn't or that 
it's improved considerably that it really doesn't make sense to 
try and claim that C++ and D are that similar. C++11 and 14 have 
closed the gap, but the two are still quite distinct. That 
doesn't necessarily mean that D is better in all cases, but D is 
definitely not just C++ with a GC.


- Jonathan M Davis

Re: GuiDub

[wobbles via Digitalmars-d]

On Tuesday, 29 September 2015 at 02:47:32 UTC, Jacob wrote:

Idea:

A gui app for dub that you run, it downloads the package info 
from the repository and you can select a project or create a 
new one and it will automatically add or remove dependencies?


I'm having to browse the repository then manually add the 
dependencies to the dub.json file... so old school!


Also, the app could provide documentation, and other 
resources(tutorials, etc) related the packages.


An app probably could be created in a few days and would make 
the experience more enjoyable. I'd create it myself but I'm 
busy at the moment, and it would probably take a big longer 
than someone more informed.


Do you when you are initialising a dub project you can run it 
like this?

dub init  

e.g. dub init myProj logger vibe-d dexpect
will create a project in myProj that has the latest logger,vibe-d 
and dexpect versions in it's dependencies.


Rather than creating a gui, I'd rather time be spent on creating 
a new command something like

dub update dependencies 
(Maybe 'update' is the wrong word...) that will simply update the 
current dub project with the new deps.


It'd be trivial to tie a GUI into that then.

Re: std.experimental.testing formal review

[Per Nordlöw via Digitalmars-d]

On Wednesday, 9 September 2015 at 15:20:41 UTC, Robert burner 
Schadek wrote:
This post marks the start of the two week review process of 
std.experimental.testing.


Will `runTests` automatically assert that all pure unittests by 
default are parallellized and all non-pure are serialized? If so 
why is the @serial UDA needed?


Will it make use of D's builtin threadpool or will every unittest 
run in its own thread? IMHO, we should strive for threadpool 
usage here.

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 29 September 2015 at 09:12:11 UTC, Jonathan M Davis 
wrote:
C++11 and 14 have closed the gap, but the two are still quite 
distinct. That doesn't necessarily mean that D is better in all 
cases, but D is definitely not just C++ with a GC.


It isn't "just C++", but D as a language is close enough to be 
considered a close relative. So if you are used to implementing 
libraries in C++, the jump to D is not a big jump.


Where D1 was  a move towards creating a more constrained 
environment by adding builtin language features (a design ideal 
that is closer to where Go is, compared to C++), D2 has been and 
IMO still is moving towards features being done in libraries much 
like C++.


There are differences across the board, but they are minor, not 
major differences. Lambdas are done slightly different, 
templating is slightly different, traits are done somewhat 
different, object init is slightly different, exceptions are 
slightly different, operators are done slightly different, but 
you can roughly express the same things in roughly the same way 
with some exceptions.

Re: Threading Questions

[Russel Winder via Digitalmars-d-learn]

On Tue, 2015-09-29 at 03:05 +, bitwise via Digitalmars-d-learn
wrote:
> On Monday, 28 September 2015 at 11:47:38 UTC, Russel Winder wrote:
> > I hadn't answered as I do not have answers to the questions you 
> > ask. My reason: people should not be doing their codes using 
> > these low-level shared memory techniques. Data parallel things 
> > should be using the std.parallelism module. Dataflow-style 
> > things should be using spawn and channels – akin to the way you 
> > do things in Go.
> > 
> > So to give you an answer I would go back a stage, forget 
> > threads, mutexes, synchronized, etc. and ask what do you want 
> > you workers to do? If they are to do something and return a 
> > result then spawn and channel is exactly the right abstraction 
> > to use. Think "farmer–worker", the farmer spawns the workers 
> > and then collects their results. No shared memory anywyere – at 
> > least not mutable.
> 
> https://www.youtube.com/watch?v=S7pGs7JU7eM
> 
>  Bit

What's the tl;dr as text, I very, very rarely watch videos.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Daniel Kozak via Digitalmars-d-announce]

Sebastiaan Koppe píše v Út 29. 09. 2015 v 03:53 +:
> This library[1] allows you to send multi-part emails with 
> attachments.
> 
> ```
> Mail email = new Mail;
> email.headers["Date"] = Clock.currTime().toRFC822DateTimeString();
> email.headers["Sender"] = "Domain.com Contact Form ";
> email.headers["From"] = "\"Example\" ";
> email.headers["To"] = "\"Bas\" ";
> email.headers["Subject"] = "My subject";
> import std.stdio : File;
> email.setContent(
>  mailMixed(
>  mailRelated(
>  mailAlternative(
>  
> mailHtml("asdfasdfasdf"),
>  mailText("asdfasdfasdf")
>  )
>  ),
>  
> mailAttachment(File("test.png","rb"),"image/png","image.png"),
>  mailAttachment(cast(immutable(ubyte[]))"You are an 
> idiot!","plain/text","text.txt")
>  )
> );
> sendMail(settings, email);
> ```
> 
> [1] http://code.dlang.org/packages/vibemail

Wow, I need something like this 3 weeks ago, but I dont have time to
implement this myself, so I end up with phpMailer. Now I can switch my
little e-mailing system to Dlang. Thank you.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 07:24:48 UTC, Russel Winder 
wrote:
This code looks so similar to the equivalent in Python, it is 
great. Does it need Vibe underneath it though to work, or is 
this a package that can sit separately and just use sockets to 
connect to the SMTP server as with Python?


It only depends on vibe's Mail class.

The only function that interacts with the Mail class is this one:

```
void setContent(MailPart)(Mail email, MailPart part)
if (isMailPart!MailPart)
{
foreach(key, value; part.headers)
email.headers[key] = value;

import std.conv : text;
email.bodyText = part.content.text;
}
```

Which is rather trivial to port.

Having said that, I have no need to build my own SMTP client. 
Vibe does a good job. And there is also a more stand-alone 
project on code.dlang.org which I forgot the name of.



Though I would rather there was no HTML in any email!


From 
http://www.networkworld.com/article/2199390/uc-voip/the-mime-guys--how-two-internet-gurus-changed-e-mail-forever.html?page=3


```
While Freed was concerned about the problems occurring when 
content moved from one e-mail system to another, "I wanted to be 
able to send pictures and videos and stuff like that in e-mail," 
Borenstein says. "And by the way, when people would ask me, 'Why 
do you care so much about putting media into e-mail?' I always 
said because someday I'm going to have grandchildren and I want 
to get pictures of them by e-mail. And people's reaction was to 
laugh and laugh."


Borenstein started receiving pictures of his twin grandchildren 
via e-mail in 2009

```

That why we want stuff besides text in our emails.

Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?

[ponce via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 09:44:58 UTC, Sebastiaan Koppe 
wrote:

On Tuesday, 29 September 2015 at 09:15:29 UTC, ponce wrote:
On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe 
wrote:
I could not find out which redistributable I had to install 
(what version of VS did you have installed / on what version 
of windows are you?). I decided to install them all, but 
couldn't install the one for 2015 (due to 
Windows6.1-KB2999226-x64.msu). After trying some workarounds 
I gave up.




You need the VC++ 2015 64-bit redistributable.


Can you either link statically or try an older version of VC, 
one that is more likely to be found in the wild? (or does ldc 
require 2015?)


No, not without rebuilding Phobos/druntime as it stands.
https://github.com/ldc-developers/ldc/issues/1133



I really want to try your game :)


Version 1.7 is still available and is compiled with DMD for 
32-bit Windows.


You can also clone the repo and type "dub": 
https://github.com/p0nce/Vibrant


Given the general speed up with LDC, it would need more 
profiling/optimizing to get back to DMD. Maybe next release.

Re: zip packages to pack modules

[wobbles via Digitalmars-d]

On Tuesday, 29 September 2015 at 10:22:05 UTC, bachmeier wrote:

On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:


Use Case

* Include libraries in a project in one step.
* Versioning is much easier. Programmer creates a library with 
many modules in it. ZIP packs them, and gives a version number 
to it in filename. No more changes will be made on it. (This 
is my #1 reasoning)

* Work of newcomers can be eased.


This could be accomplished by including dub in the default 
installation (already scheduled to happen) and then adding 
something like pragma("dep", ["lib1", "lib2", "lib3"]).


For better or worse, it looks like the decision has been made 
to go with Dub. I think it's a mistake, because (i) it 
increases the learning curve, and (ii) the documentation was 
not written for newcomers (AFAICT the way to learn is to look 
at existing packages and then learn by trial and error). But 
what I think doesn't matter; the decision has been made to use 
Dub, so there is no chance that another approach will be taken.


How does it increase the learning curve?
Absolutely NOTHING will change when dub is included.
dmd and all your other tools will be there, and you don't have to 
use dub if you don't want to.


Including dub just ensures that everyone can have access to all 
the packages on code.dlang.org easily if they want them. And also 
that we're all working on the same page if we want to create new 
packages.


Personally I feel it's a no brainer to go with dub. Nothing to 
lose and lots to gain.

Re: GuiDub

[wobbles via Digitalmars-d]

On Tuesday, 29 September 2015 at 07:59:38 UTC, ponce wrote:

On Tuesday, 29 September 2015 at 05:17:42 UTC, Jacob wrote:


"dsfml": "~master",

"std_event": "~master",
"derelict_extras-glib": "~master",
"netstack": "~master",
"luad": "~master",
"three-d": "~master",
"grape": "~master",

"civge": "~master",
"nitro": "~master",
"nitro-gen": "~master",

"process-stats": "~master",
"llvm-d": "~master",


Packages that don't have one version tag are probably 
unmaintained.


Yeah, might be worthwhile to mark all of those as such?
And maybe send an email to their owners to ask them to update 
them (or even better just create a pull request creating the tag 
automagically?)

Re: zip packages to pack modules

[lobo via Digitalmars-d]

On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:

[snip]




Why not DUB?

I have never use DUB ever, and not planning to use it. Nobody 
else has to use it as well. I don't think anyone should be 
forced for this. The proposed feature allows to simplify 
downloading packages and using them in a projects very quickly 
and easily without needing any tool.


I used to feel this way about DUB too, insisting on my Makefile 
or CMakeD for larger projects. I then tried dub, initially just 
for a quick prototype, but it was so quick, productive and 
seamless to use that I decided to switch immediately.


Now my only regret is that I cannot go back and reclaim the time 
I wasted with other build tools on D projects.


bye,
lobo

Re: Why getting private member fails using getMember trait in a template?

[Alexandru Ermicioi via Digitalmars-d-learn]

On Saturday, 26 September 2015 at 10:10:39 UTC, Alexandru 
Ermicioi wrote:

Suppose we have, two modules:

module testOne;

[...]


So, is this behavior correct?
If yes, then why?

Re: Get template parameter value

[Kagamin via Digitalmars-d-learn]

On Tuesday, 29 September 2015 at 09:11:15 UTC, John Colvin wrote:
Welcome to the weird and wonderful work of  
http://dlang.org/expression.html#IsExpression


No, use template pattern matching instead:

struct A(int s){}
template B(T:A!s, int s){ enum B=s; }
static assert(B!(A!4)==4);

Re: zip packages to pack modules

[bachmeier via Digitalmars-d]

On Tuesday, 29 September 2015 at 10:37:33 UTC, wobbles wrote:

How does it increase the learning curve?


A proper package management system would work as I described. You 
include pragma(dub) at the top of your program and you don't have 
to write your own dub package. dub is a substitute for a 
Makefile, not a package manager.



Absolutely NOTHING will change when dub is included.
dmd and all your other tools will be there, and you don't have 
to use dub if you don't want to.


That's the problem. D still won't have a tool to allow you to 
easily use other libraries. Including dub kills off any chance of 
having a package manager.


Including dub just ensures that everyone can have access to all 
the packages on code.dlang.org easily if they want them. And 
also that we're all working on the same page if we want to 
create new packages.


Again, that's the problem. You shouldn't have to write your own 
dub package in order to use dub, and I shouldn't be forced to 
tell a new D user that this is the documentation to read if they 
want to use D: http://code.dlang.org/package-format?lang=sdl


Personally I feel it's a no brainer to go with dub. Nothing to 
lose and lots to gain.


I'm reminded of trying to use Linux in the late 1990's. They 
didn't understand ease of use or documentation either.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

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

On Tuesday, 29 September 2015 at 09:05:09 UTC, Sebastiaan Koppe 
wrote:

That why we want stuff besides text in our emails.


Attachments do pictures better than html bodies though.

Re: This Week in D #37 - forum tutorials and tip on using UDAs

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

On Tuesday, 29 September 2015 at 07:09:35 UTC, Jacob Carlborg 
wrote:
This looks pretty cool. Unfortunately the original code needs 
to be contained inside a template :( .


Yeah. You could put it in a module too (my original plan was to 
write about "module mything_impl; code here" and "module mything; 
mixin magic_from_mything_impl;" but there's a bit more difficulty 
with that and forwarding all members you don't want to transform.


Though, I just had an idea on how that might be simplified 
don't recreate them, just alias them!




So, conceptually, you'd do something like:


template transformer(alias member) {
static if(hasUDA!(member, thing))
mixin(transformed_version_of_member());
else
alias member = member;
}
mixin staticMap!(AllMembers!impl_module, transformer);



So you bring in the original thing via alias in much the same way 
I brought it in via template mixin, then do the rest basically 
the same.



That *should* work and not even be all that much more code. Then 
you don't need to wrap anymore. Though it does still need to be 
in a separate something, whether input module or struct, from the 
output.

Move Semantics

[Alex via Digitalmars-d-learn]

Another question on move semantics from the cheap seats...

See my code here: http://dpaste.dzfl.pl/995c5af59dd6
There are indeed three questions, all marked in the code, so the 
rest of the text here is maybe redundant... but just in case and 
for summary:


I try to model a inner class of some outer one. Then, as I 
learned from the docu, there is a implicit pointer to the outer 
class from the inner one by ".outer" key word. So far so good.

My outer class has an associative array of the inner objects.
Now, I try to apply a move action to the inner objects between 
two outer objects.


The first (minor) question is:
I have to initialize some dummy inner objects, before I can apply 
the move action. Is this really necessary? It won't be that 
problem I think, if it is so, but it would be nicer, if I could 
just perform the move operation.


The second question is:
Following my code, the inner object I moved does not disappear 
from the array in the source outer object. Why? I tried it 
without, with an empty and with a non empty destructor, the 
result was the same.


And the third, main, question is:
After I moved the inner object to the new outer object, the 
pointer to the outer object remains in the old state, to the 
source outer object. This is not what I expected! Well, yes this 
is some subjective expectation, but shouldn't an implicit pointer 
update itself to not break the logic of what it points to?


The third question has some more meaning in my case: I would like 
to compose some immutable classes, which are inner classes. The 
only mutable value therein should be the pointer to the outer 
class.
I know, I could manage this by some map (+ an array, optionally) 
construct, and I'm on my way to implement this approach. But 
then, I noticed the nested class section and the implicit 
pointers, which are not present in C++, for example, and I wanted 
to try this solution.

Is there maybe an error somewhere in my code?

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 13:10:55 UTC, Adam D. Ruppe 
wrote:

I'm slowly working on it. Got some working just yesterday:
http://code.dlang.org/packages/arsd-official


Good. But why put everything in one package?

A guy on npmjs.com goes the other extreme and he actually has a 
package 
(https://github.com/sindresorhus/negative-zero/blob/master/index.js) that consists of 1 line of code.


In the description you say "or better yet, ditch dub and do 
things the simple, reliable way of dmd *.d" How is that more 
reliable?


I copy/pasted your arsd/dom.d code in a couple of projects. But 
none of them will receive updates unless I do 'm manually. I 
don't see how that is more reliable.


but the repo doesn't let you show subpackages, argh. dub sucks, 
code.dlang.org sucks.


I don't understand your negative stance against dub and 
code.dlang.org. I agree that both require some fine-tuning. Some 
areas more than others. However, the idea of having a 
package-manager is a good idea. If only to serve as documentation 
on the libs you package depends on.

Re: zip packages to pack modules

[ponce via Digitalmars-d]

On Tuesday, 29 September 2015 at 14:24:03 UTC, tcak wrote:


ZIP packages in no way make any change in the language. There 
is no need for pragmas even. There is no this simple (e.g. dmd 
main.d library.zip) substitute for it at the moment.


You can do it with a dmd frontend, if an argument finish in .zip, 
then unzip it in a temporary directory, then call dmd.

Passthrough all other flags.

On the other hand, I can only recommend you to use DUB. It made 
things way more simpler than they were, but you do need to learn 
it.

Re: Moving back to .NET

[Atila Neves via Digitalmars-d]

On Tuesday, 29 September 2015 at 11:53:45 UTC, Ola Fosheim 
Grøstad wrote:
It isn't "just C++", but D as a language is close enough to be 
considered a close relative. So if you are used to implementing 
libraries in C++, the jump to D is not a big jump.


That's as true as saying that D is similar enough to Java that it
wouldn't be a big jump. You'd end up with code that looks like 
C++ or

Java that no seasoned D developer would write.

The difference is actually quite big. If it weren't, why would
any of us bother?

Atila

Re: std.experimental.testing formal review

[Atila Neves via Digitalmars-d]

On Tuesday, 29 September 2015 at 10:45:23 UTC, Per Nordlöw wrote:
On Wednesday, 9 September 2015 at 15:20:41 UTC, Robert burner 
Schadek wrote:
This post marks the start of the two week review process of 
std.experimental.testing.


Will `runTests` automatically assert that all pure unittests by 
default are parallellized and all non-pure are serialized? If 
so why is the @serial UDA needed?


runTests with no optional arguments will run the tests in threads.
There's nothing about purity enforcement there. In fact, I tried
using pure unit tests yesterday with std.experimental.testing
and couldn't. The compiler inferred the functions to not be pure.
I tried adding pure to them and descended into a madness of adding
pure all over phobos until I got fed up. It seems to be something
to do with `format` not being pure, I have no idea why. It really
should be.

@serial is needed to _not_ run tests in threads, which you'd need
if those tests call functions that mutate global state. Even
"thread-global" is bad here since those tests could run in the 
same

or different threads depending on the run.

Will it make use of D's builtin threadpool or will every 
unittest run in its own thread? IMHO, we should strive for 
threadpool usage here.


It uses the thread pool.

Atila

Re: Indicators and traction…

[ponce via Digitalmars-d]

On Wednesday, 23 September 2015 at 15:09:53 UTC, Nick Sabalausky 
wrote:


This is engineering, not fucking fashion. Popularity has no 
place in decision making here. From everything I've seen, 90% 
of the problems that exist in computing technology today can be 
traced back directly to some jackass(es) weighing popularity 
higher than actual technical merit.


Companies use whatever the money-making competition use, and 
often bias their evaluations to favor doing things in the same 
way.


Look at all these stories about Twitter/Facebook/WebStartup 
technology stack. They wouldn't be anything interesting if they 
weren't famous.


But they are visible and make money, so what they use must be the 
right thing.

Re: Indicators and traction…

[Nick Sabalausky via Digitalmars-d]

On 09/29/2015 10:51 AM, ponce wrote:

On Wednesday, 23 September 2015 at 15:09:53 UTC, Nick Sabalausky wrote:


This is engineering, not fucking fashion. Popularity has no place in
decision making here. From everything I've seen, 90% of the problems
that exist in computing technology today can be traced back directly
to some jackass(es) weighing popularity higher than actual technical
merit.


Companies use whatever the money-making competition use, and often bias
their evaluations to favor doing things in the same way.

Look at all these stories about Twitter/Facebook/WebStartup technology
stack. They wouldn't be anything interesting if they weren't famous.

But they are visible and make money, so what they use must be the right
thing.


Yea. I just wish more people understood the fallacy of that (and all the 
other basic, basic fallacies out there). :(


This one is basically what I've seen described as the "Birdmen fallacy":
https://seanmalstrom.wordpress.com/2009/12/01/the-birdmen-dont-fly/

See birds fly. Blindly imitate the feathers, not the physics. Fail. 
Blame anything but the "imitate feathers" approach. Repeat.

Re: zip packages to pack modules

[Atila Neves via Digitalmars-d]

On Tuesday, 29 September 2015 at 12:04:51 UTC, bachmeier wrote:

On Tuesday, 29 September 2015 at 10:37:33 UTC, wobbles wrote:


Again, that's the problem. You shouldn't have to write your own 
dub package in order to use dub


You don't. You have to write your own dub package in order for 
other

people to use your code with dub.


, and I shouldn't be forced to
tell a new D user that this is the documentation to read if 
they want to use D: 
http://code.dlang.org/package-format?lang=sdl


They don't need that either. `dub init myProj dep1 dep2 ...; dub 
build`. Or

just use git submodules, other people do.

Atila

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 September 2015 at 13:37:18 UTC, Suliman wrote:
I am asking because I had troubles with vibed 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/25447/


It's still vibe.d doing the smtp stuff. You might want to look 
into adam's code, or http://code.dlang.org/packages/smtp

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Nick Sabalausky via Digitalmars-d]

On 09/28/2015 03:44 PM, Walter Bright wrote:


The dialog box itself is not an edit box, and copy simply does not work.
(Just tried it again.) You cannot copy ANY text from it, even the
highlighted text.

This really blows when you've got a message window with an error message
in it, and you cannot copy it to google it. You cannot copy the "About"
dialog box text, either, so you have to painfully type in the
version/build number when filing a bug report.

Unbelievable.



That's one of the many reasons I absolutely despise the modern crop of 
mobile OSes. (As opposed to PalmOS which worked REALLY damn well, at 
least aside from the lack of WiFi which wouldn't have been realistic in 
those days anyway. VERY productive and speedy interface. Puts the modern 
smartphones completely to shame.)

Re: Moving back to .NET

[Laeeth Isharc via Digitalmars-d]

On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 28 September 2015 at 09:35:53 UTC, Chris wrote:
In response to Ola:
On Monday, 28 September 2015 at 09:35:53 UTC, Chris wrote:
Yep. What I was talking about was not the fear of a commercial 
failure because of having picked the wrong tool (management). I

was talking about my impression that D might intimidate
programmers /coders.




This logic is very difficult to follow.


Difficult to follow for you, because your mind doesn't work that 
way.  But, as Knuth pointed out, there are many different kinds 
of minds in the world, and one will have an easier time of it if 
one accepts this.


Chris was speaking about human factors, and these are important, 
because programming is still for now a human activity.  It's 
rather well-established that people are funny creatures and are 
influenced by factors that are irrational, or transcend logic, 
depending on your perspective.  Chris's observation is based on 
an empirical view of how the world works; logic doesn't have much 
to do with the observation (although his subsequent conclusion is 
based on impeccable reasoning)




From a project health point of view D2 suffers from the same
issues as C++


That's your assessment, and you are certainly entitled to it.  
Whether it is persuasive to others is an open question, because 
those that have spent time writing significant projects in D tend 
to arrive at different conclusions.  There have been people who 
give up in frustration - this will always happen with something 
new, and may reflect a lack of maturity, or that D wasn't the 
right tool for the job, at least for this person in this 
environment, at this time, and from what I have seen this seems 
to be perhaps less commmon over time as the ecosystem matures.  
We don't give people 'exit interviews' here, but to the extent 
one can tell, the reasons given are rarely that D is too much 
like C++.


As John Colvin points out, someone who hasn't written quite a lot 
of code in D over time (because as you rightly observe, the 
ultimate consequences of choices aren't really observed till the 
code base develops and grows), simply isn't in a position to make 
a judgement about whether this is true.


You come across as someone very able (and I have worked with some 
very bright people over the years, so I don't say this lightly), 
but quite academically minded and theoretical, and I don't know 
how many lines of D you have written.  (Significant lines of D, 
if you prefer).  That matters, because the difference between 
theory and practice is bigger in practice than in theory.



But even after years of polish Go is still perceived as risky:


Of course it's risky.  Yet why do people who are sensible 
commercial people who aren't in the business of gambling use it?  
Because it's a very good tool for certain kinds of job, and the 
benefits outweight the costs, risks being one of those costs.




risk management is at the core of software engineering.


No it's not, any more than it's helpful to say that risk 
management is at the core of investment management.  It's one 
important thing, and if you don't do this reasonably well, life 
will crush you.  But engineering is about using tools to solve 
problems, and you need to consider benefits and opportunity costs 
in aggregate.  Also in terms of optionality, since a small bet 
today may open up future possibilities.



Software process/methods maturity is often quantified in "repeat
success". That is, not that you have one success, but keep
repeating the success over many projects.


Indeed, and rapid iteration is an important part of reducing risk 
and aligning development with the needs of the business.  No 
doubt in some areas there isn't an alternative to waterfall, but 
I have seen this fail in many more cases than succeed in the 
areas I know well - banking and hedge funds.



I've majored in human factors/software engineering, taught it to
students and been with a research group where many focused on
using Latour's actor network theory for understanding
organizations and systems development processes.


It's not a surprise that this approach to understand 
organizations should appeal to you.  That's not the kind of human 
factors I mean, by the way.  Academic approaches can sometimes be 
useful in practice, and sometimes very useful, but when an 
academically-informed perspective clashes with practical 
experience and common sense, one must at least ask why.  My 
impression is that in the domain of software engineering 
practices, it hasn't been the academics that have driven insight 
about what works.




But you seem to assume that  whatever holds for your field
translates well to other fields.


No, because I read widely and talk to people.  And some things 
are clearly universal, whilst others are not.  And I haven't ever 
suggested "every enterprise should use D", but merely said that 
it really depends on the 

Re: zip packages to pack modules

[tcak via Digitalmars-d]

On Tuesday, 29 September 2015 at 10:37:33 UTC, wobbles wrote:

On Tuesday, 29 September 2015 at 10:22:05 UTC, bachmeier wrote:

On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:


Use Case

* Include libraries in a project in one step.
* Versioning is much easier. Programmer creates a library 
with many modules in it. ZIP packs them, and gives a version 
number to it in filename. No more changes will be made on it. 
(This is my #1 reasoning)

* Work of newcomers can be eased.


This could be accomplished by including dub in the default 
installation (already scheduled to happen) and then adding 
something like pragma("dep", ["lib1", "lib2", "lib3"]).


For better or worse, it looks like the decision has been made 
to go with Dub. I think it's a mistake, because (i) it 
increases the learning curve, and (ii) the documentation was 
not written for newcomers (AFAICT the way to learn is to look 
at existing packages and then learn by trial and error). But 
what I think doesn't matter; the decision has been made to use 
Dub, so there is no chance that another approach will be taken.


How does it increase the learning curve?
Absolutely NOTHING will change when dub is included.
dmd and all your other tools will be there, and you don't have 
to use dub if you don't want to.


Including dub just ensures that everyone can have access to all 
the packages on code.dlang.org easily if they want them. And 
also that we're all working on the same page if we want to 
create new packages.


Personally I feel it's a no brainer to go with dub. Nothing to 
lose and lots to gain.


Selecting a few files with mouse, then click right to create a 
ZIP file cannot be compared writing a DUB package JSON file. I 
would be forgetting how to write it million times, and every 
time, time would be wasted.


If you say that "Hey we want to add meta data to packages", then 
a simple command line flag for dmd can be added like "dmd 
sign-the-package my-library-v1.0.zip". Compiler asks questions, 
you answer them, it generates a sign and puts into zip package. 
Only 1 command line to learn.


What is preventing DUB to use ZIP packages also?

ZIP packages in no way make any change in the language. There is 
no need for pragmas even. There is no this simple (e.g. dmd 
main.d library.zip) substitute for it at the moment.

Re: Indicators and traction…

[Nick Sabalausky via Digitalmars-d]

On 09/26/2015 11:34 PM, Manu via Digitalmars-d wrote:

On 24 September 2015 at 01:09, Nick Sabalausky via Digitalmars-d

This is engineering, not fucking fashion.


You're familiar with JS, MongoDB, Ruby on rails, etc, etc? Software
engineers are firmly engaged in fashion.



Oh, I definitely know. And it irritates me to no end :/



We need to appeal in terms of a popularity contest. That's the way forward ;)



Yea, I do agree, just find it really annoying ;)

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 29 September 2015 at 14:24:45 UTC, Atila Neves wrote:
wouldn't be a big jump. You'd end up with code that looks like 
C++ or Java that no seasoned D developer would write.


I don't really see your point. "idiomatic" is a cultural regime, 
not a language and not necessarily an improvement over 
alternative coding styles. System level code isn't "idiomatic", 
you write code the way that makes sense for what you try to 
achieve and set guidelines suitable for your project.


If I want a systems development language and don't like C++ for 
various reasons (syntax bloat, no module system and tedious 
traits) then using D is one of very few potential options. 
Currently some things are better in D, some things are better in 
C++. The primary difference is that D can much more easily change 
for the better overall.


C++ is locked to backwards compatibility in a rather unhealthy 
way, which is why they now try to "change practice" by using 
guidelines. D can avoid all that.

Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

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

On Tuesday, 29 September 2015 at 14:57:13 UTC, Sebastiaan Koppe 
wrote:

Good. But why put everything in one package?


dub forces me to do it that way. It isn't my preference, but 
reorganizing all my files and creating twenty or thirty different 
github repos to house them is unacceptable.


The unit of encapsulation in D is the module. If a module does 
two wildly different and independent things, you would break it 
up. Similarly, and I think this is often neglected, if two 
modules are intertwined and one cannot work without the other, 
they are really one unit and should be merged.


The merged module will present a cleaner interface and be easier 
to maintain since it can handle its own private implementation 
without worry of exposing internals for its friend module nor 
having something change independently of it.


(I wish D would fix that bug where public and private symbols can 
conflict though. So annoying and breaks this beautiful 
encapsulation. You might notice simpledisplay.d has a function 
named toInternal for example. I'd like to name it to, but then it 
would break code that uses std.conv.to, despite that internal 
function being private! Ugh!)


That forms the basis of my general policy: make modules that 
stand alone and do a task as completely as necessary. I only 
split them up when there's a technical requirement and the split 
lowers overall complexity.


And, of course, when possible, I like to make those dependencies 
optional; they aren't required unless you actually use those 
specific features.




Modules in D do a pretty good job at this. They can contain most 
their own metadata, too: write ddoc inline, you can grep it for 
version options (and since D doesn't allow versions to cross 
module boundaries, it is as simple as a grep) and import 
dependencies, and you can even have some control over the linker 
with stuff like pragma(lib), showing system dependencies.



Modules also have a one-to-one correspondence to files, making 
them a natural thing to download, move around, etc. Other 
programs know how to handle files so you can version them and 
such too.



D's modules work! Why does dub reject this model?

A guy on npmjs.com goes the other extreme and he actually has a 
package 
(https://github.com/sindresorhus/negative-zero/blob/master/index.js) that consists of 1 line of code.


Disgusting. Think of all the overhead involved in that package, 
not just for the author, but now for everybody who use it... and 
everyone who uses something that uses it, and so on and so forth 
- right down to the end user!


There needs to be a balance struck between "don't repeat 
yourself" and avoiding dependencies.


It is generally considered a bad idea to do the whole system 
together at once. (though Docker and VMWare appliances and such 
do actually try to do that and have found some success in the 
market) Making changes to that means a lot of extra work that is 
easy to do wrong. (The duplication itself btw isn't a big problem 
to me, computers are good at doing the same thing over and over 
again; it is an easily automated problem, at least until 
something goes wrong.)


In code, we factor common functionality into functions that can 
be used from multiple places instead of copy/pasting the bodies 
everywhere.


It is similarly a bad idea to have a deep web of external 
dependencies. This also makes maintenance harder - where is the 
problem? Where do you make the change? How long will it take to 
get upstreamed? Do you understand what is going on anymore; will 
changing that dependency break some unrelated project somewhere 
else?


In code, we try to write our functions such that they do not use 
global variables. We like pure functions whenever we can. We like 
to use const or immutable to limit the scope of confusing 
changes. We like to use private to limit the function's interface.



Negative zero should be a constant (and probably a private one at 
that, that'd be a bizarre implementation detail to expose to an 
API user). Here, it is instead a public global mutable function 
pointer.



In the description you say "or better yet, ditch dub and do 
things the simple, reliable way of dmd *.d" How is that more 
reliable?


It works the same way every time you do it and exposes all the 
options dmd has without needing wrapper json options which may or 
may not actually be there, or documented, or keep working the 
same way next time you try.


I copy/pasted your arsd/dom.d code in a couple of projects. But 
none of them will receive updates unless I do 'm manually.


That means you don't have to put up with me randomly breaking 
your code! You don't have to wait for me to publish a bug fix. 
You aren't locked in to the way I did things and are free to 
customize it as you wish.


It is very easy to update it too, even if you do customize it 
(git will handle the conflicts, if any) - you can always do a git 
pull from me, then test and push back up to your copy (or, not 

Re: std.data.json formal review

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 29 September 2015 at 11:06:03 UTC, Marc Schütz wrote:

On Monday, 28 September 2015 at 07:02:35 UTC, Marco Leise wrote:

Am Tue, 18 Aug 2015 09:05:32 +
schrieb "Marc Schütz" :

Or, as above, leave it to the end user and provide a `to(T)` 
method that can support built-in types and `BigInt` alike.


You mean the user should write a JSON number parsing routine
on their own? Then which part is responsible for validation of
JSON contraints? If it is the to!(T) function, then it is
code duplication with chances of getting something wrong,
if it is the JSON parser, then the number is parsed twice.
Besides, there is a lot of code to be shared for every T.


No, the JSON type should just store the raw unparsed token and 
implement:


struct JSON {
T to(T) if(isNumeric!T && is(typeof(T("" {
return T(this.raw);
}
}

The end user can then call:

auto value = json.to!BigInt;




I was just speaking to Sonke about another aspect of this.  It's 
not just numbers where this might be the case - dates are also 
often in a weird format (because the data comes from some ancient 
mainframe, for example).  And similarly for enums where the field 
is a string but actually ought to fit in a fixed set of 
categories.


I forgot the original context to this long thread, so hopefully 
this point is relevant.  It's more relevant for the layer that 
will go on top where you want to be able to parse a json array or 
object as a D array/associative array of structs, as you can do 
in vibe.d currently.  But maybe needs to be considered in lower 
level - I forget at this point.

Re: Moving back to .NET

[Kagamin via Digitalmars-d]

On Friday, 25 September 2015 at 21:46:35 UTC, Laeeth Isharc wrote:
I was speaking about the general case, but since you made it a 
personal reference - if I spent time to step back and admire my 
handiwork, I wouldn't at this point have time to finish the 
broader project as its at the limit of what's possible.


Priorities are understandable, but I meant the boredom argument, 
which I usually hear:
creative people don't like doing boring things like write 
documentation


On Saturday, 26 September 2015 at 00:28:19 UTC, Jonathan M Davis 
wrote:
A lot of folks write code because they want to get something 
done and simply because they like coding. Most programmers 
consider documentation to be a chore, even when they're really 
excited about what they did. In general, I wouldn't expect 
someone to even open source something if the problem was that 
they were ashamed about how they did it.


If the objective is to get thing done, then even if code is 
horrible, it's worth to share, because it gets thing done. This 
is also the reason for commercial open source: they free each 
other from the nightmare of software development by sharing the 
source. It's understandable why one doesn't want to see this 
nightmare second time.

Re: Help from the compiler when debugging failing template constraints - a pull request

[Dmitry Olshansky via Digitalmars-d]

On 28-Sep-2015 23:25, Atila Neves wrote:

I've mentioned this many times before: template constraints are like
unittest blocks with asserts in D: great that they're built-in easy to
use. But when they fail, there's no help in figuring out why.


[snip]


I created an input range, verified it compiled, then added a 't' to the
end of `front`. With `models` I got this for both UDA and static assert
versions:

/home/atila/coding/d/dlang/phobos/std/range/primitives.d(182): Error:
template std.range.primitives.front cannot deduce function from argument
types !()(Foo), candidates are:
/home/atila/coding/d/dlang/phobos/std/range/primitives.d(2219):
std.range.primitives.front(T)(T[] a) if (!isNarrowString!(T[]) &&
!is(T[] == void[]))
/home/atila/coding/d/dlang/phobos/std/range/primitives.d(2247):
std.range.primitives.front(T)(T[] a) if (isNarrowString!(T[]))
/home/atila/coding/d/dlang/phobos/std/traits.d-mixin-6771(6771): Error:
template instance std.range.primitives.checkInputRange!(Foo) error
instantiating
concepts.d(81):instantiated from here: models!(Foo, isInputRange)
Failed: ["dmd", "-unittest", "-main", "-v", "-o-", "concepts.d", "-I."]


With `static assert(isInputRange!Foo)`, I get this:

concepts.d(87): Error: static assert  (isInputRange!(Foo)) is false
Failed: ["dmd", "-unittest", "-main", "-v", "-o-", "concepts.d", "-I."]

I prefer the first one. How about you?

Atila


Certainly the first one.


--
Dmitry Olshansky

Re: Help from the compiler when debugging failing template constraints - a pull request

[Steven Schveighoffer via Digitalmars-d]

On 9/28/15 4:25 PM, Atila Neves wrote:

I've mentioned this many times before: template constraints are like
unittest blocks with asserts in D: great that they're built-in easy to
use. But when they fail, there's no help in figuring out why.

I've had many a debugging session (with pragma(msg) of course, since my
bugs were of the compile-time variety and there's no debugger for that)
due to failing to satisfy a template constraint that I thought I'd
implemented the correct functions for. It'd be nice if the compiler told
me why. I did a PR a while back with an idea from Adam's book but it
didn't work in the context of Phobos and interfaces. I've come up with a
PR (https://github.com/D-Programming-Language/phobos/pull/3677) that
will let users type this:

 @models!(MyStruct, isInputRange)
 struct MyStruct { ... }

Or this:

 struct MyStruct {
 ...
 static assert(models!(MyStruct, isInputRange));
 }

When the template constraint isn't satisfied, the compiler will
dutifully tell you why. The only requirement is that there be a checkXXX
function for an isXXX template constraint. I've updated the original PR
for `isInputRange` to make the above code possible. I chose the name
`models` because I just got back from CppCon and concepts might have
tainted my brain. It's unfortunate to have to specify the type in the
UDA version, but it's what the language as it is now will allow me to do.

I created an input range, verified it compiled, then added a 't' to the
end of `front`. With `models` I got this for both UDA and static assert
versions:

/home/atila/coding/d/dlang/phobos/std/range/primitives.d(182): Error:
template std.range.primitives.front cannot deduce function from argument
types !()(Foo), candidates are:
/home/atila/coding/d/dlang/phobos/std/range/primitives.d(2219):
std.range.primitives.front(T)(T[] a) if (!isNarrowString!(T[]) &&
!is(T[] == void[]))
/home/atila/coding/d/dlang/phobos/std/range/primitives.d(2247):
std.range.primitives.front(T)(T[] a) if (isNarrowString!(T[]))
/home/atila/coding/d/dlang/phobos/std/traits.d-mixin-6771(6771): Error:
template instance std.range.primitives.checkInputRange!(Foo) error
instantiating
concepts.d(81):instantiated from here: models!(Foo, isInputRange)
Failed: ["dmd", "-unittest", "-main", "-v", "-o-", "concepts.d", "-I."]


With `static assert(isInputRange!Foo)`, I get this:

concepts.d(87): Error: static assert  (isInputRange!(Foo)) is false
Failed: ["dmd", "-unittest", "-main", "-v", "-o-", "concepts.d", "-I."]

I prefer the first one. How about you?


Yes. I also prefer that the compiler do this. I've definitely run into 
this before: http://forum.dlang.org/post/m4mdsk$bgs$1...@digitalmars.com


-Steve

Re: Get template parameter value

[Artur Skawina via Digitalmars-d-learn]

On 09/29/15 12:13, rumbu via Digitalmars-d-learn wrote:
> On Tuesday, 29 September 2015 at 09:53:39 UTC, Kagamin wrote:
>> On Tuesday, 29 September 2015 at 09:11:15 UTC, John Colvin wrote:
>>> Welcome to the weird and wonderful work of  
>>> http://dlang.org/expression.html#IsExpression
>>
>> No, use template pattern matching instead:
>>
>> struct A(int s){}
>> template B(T:A!s, int s){ enum B=s; }
>> static assert(B!(A!4)==4);
> 
> Thank you, this is perfect.

There's always room for improvement... ;)

   enum B(T:A!s, int s) = s;

artur