Re: Why D is not popular enough?
On 20/08/16 21:00, Walter Bright wrote: On 8/20/2016 8:25 AM, Shachar Shemesh wrote: Actually, Adam's suggestion on how things should work is precisely how C works No, it's subtly different. Which is my point that one must be very, very careful when proposing different behavior. Can you give an example of an expression that would yield different results in both modes? To frame the discussion in a constructive way, I'll suggest an algorithmic definition of (my interpretation of) Adam's proposal: During static analysis, keep both the "most expanded" and the "least expanded" type of the expression parsed so far. "Least expanded" is the largest type actually used in the expression. Upon use of the value, resolve which type to actually use for it. If the use type requests a type between least and most, use that type for evaluating the entire expression. If the use requests a type outside that range, use the one closest (and, if the use is below the range, complain about narrowing conversion). If more than one use is possible (i.e. - overloading), use the largest one applicable. I believe the above solves my problem, without losing compatibility with C (counter examples welcome, so we can continue the discussion in a productive way), and without foregoing erroring out on narrowing conversions. Shachar
Re: How about a special null template parameter?
On 20.08.2016 21:20, Engine Machine wrote:
That is
It would be nice to have something like
alias Type = Type!();
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
I don't understand how this is related.
The only difference is the alias Type = Type!(); Again, D can't do this
but the point is that it would be nice to have the alias. One can't do
everything as a "library" solution.
...
I see what you are after (but this was not part of the original
requirements :) ). I don't think there's a way to make a symbol act as
both a type and a template.
Trying to expand your code results in some odd behavior:
public template TypeParent(P)
{
import std.traits;
alias T = TemplateArgsOf!P;
alias Seq(T...) = T;
static if (T.length == 0 || is(typeof(T[0]) == typeof(null)))
{
alias TypeParent = Seq!();
}
else
{
alias TypeParent = Seq!(P!(T[0..T.length-1]));
}
}
class Type(T...) : TypeParent!(Type!T)
{
int x;
static if (T.length >= 1 && T[0] is "Animal")
{
int y;
static if (T.length >= 2 && T[1] is "Dog")
{
int z;
static if (T.length >= 3&& T[2] is "Pug")
{
int s;
}
}
}
}
void main()
{
import std.traits;
auto a = new Type!("Animal", "Dog", "Pug")();
Type!("Animal", "Dog") b = a;
Type!("Animal") c = b;
a.s = 1;
b.z = 2;
c.y = 3;
}
b and c are of type P!, not Type!
It seems that this is a compiler bug. Is the problem just with getting a
string representation of the type?
Re: Examples block
On Saturday, 20 August 2016 at 20:39:13 UTC, Engine Machine wrote: We have a unittest, what about an examples? https://dlang.org/spec/unittest.html#documented-unittests
Examples block
We have a unittest, what about an examples? Examples are self contained short programs, each block acts as a "main" function. One can run all the examples and spit out all the output consecutively. It also allows for more robust testing since it adds another layer. It would provide better examples for docs also. Instead of using assert to assert stuff we can see a real program in action. The output of the example could easily be generated and added to the end of the code. Seems like a win win! (maybe examples is not a good keyword, but that is moot)
Re: Auto-testing issue on FreeBSD
I apologize as this might be better in the learn section, but I'm having another issue trying to run tests on FreeBSD. On a 64 bit system (tests ran just fine on a 32 bit system) I'm getting this error on the first test ran: Running runnable tests ... runnable/issue8671.d (-inline -release -g -O -fPIC) Error: module is in file '.d' which cannot be read Any idea what's going on here? I've never seen anything like this before.
Re: How about a special null template parameter?
On Saturday, 20 August 2016 at 10:04:07 UTC, Timon Gehr wrote:
On 20.08.2016 00:07, Engine Machine wrote:
On Friday, 19 August 2016 at 21:07:42 UTC, Timon Gehr wrote:
On 19.08.2016 20:25, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
alias Seq(T...)=T;
template TypeParent(T...) if(T.length==1){
static if(is(typeof(T[0])==typeof(null))) alias
TypeParent = Seq!();
else alias TypeParent = Seq!(Type!null);
}
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
This is a bit verbose
Apart from the workaround for the ridiculous alias template
parameter semantics, I think the length of the code more or
less matches the specificity of the requested behaviour. (There
should be ways to abstract out most of it, in case you need
this really often.)
Yes, it is not too bad. One doesn't need to T.length part so it
is a little shorter. Took me a bit to get used to it.
and not quite right (T is Dog should be something
like T[0], or whatever).
...
('T is Dog' does not work anyway.)
Yes, I use strings, but it doesn't really matter, it can be made
to work.
It does essentially work. My only complaint is that it would
be nice to
be able to export an alias to Type!() = Type; in the namespace
of the
type being created. Doubt that D can do that!? If it can, then
it should
be an adequate solution.
That is
It would be nice to have something like
alias Type = Type!();
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
I don't understand how this is related.
The only difference is the alias Type = Type!(); Again, D can't
do this but the point is that it would be nice to have the alias.
One can't do everything as a "library" solution.
Trying to expand your code results in some odd behavior:
public template TypeParent(P)
{
import std.traits;
alias T = TemplateArgsOf!P;
alias Seq(T...) = T;
static if (T.length == 0 || is(typeof(T[0]) == typeof(null)))
{
alias TypeParent = Seq!();
}
else
{
alias TypeParent = Seq!(P!(T[0..T.length-1]));
}
}
class Type(T...) : TypeParent!(Type!T)
{
int x;
static if (T.length >= 1 && T[0] is "Animal")
{
int y;
static if (T.length >= 2 && T[1] is "Dog")
{
int z;
static if (T.length >= 3&& T[2] is "Pug")
{
int s;
}
}
}
}
void main()
{
import std.traits;
auto a = new Type!("Animal", "Dog", "Pug")();
Type!("Animal", "Dog") b = a;
Type!("Animal") c = b;
a.s = 1;
b.z = 2;
c.y = 3;
}
b and c are of type P!, not Type!
Re: How about a special null template parameter?
On Saturday, 20 August 2016 at 13:45:59 UTC, poliklosio wrote:
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the
above way. Essentially an alias is created for us
automatically)
This syntax would be very confusing to a non-expert. It is a
special case of an existing features (inheritance and
templates), which makes it hard to learn about, as all
resources are going to discuss those other features first, and
only the most detailed readings are going to contain this
detail. Moreover, it does not introduce a keyword or any other
name, so it is almost impossible to Google. Try googling
something like "template class a class b: public
a", and see which result contains "curiously recurring
template pattern". It is hard to find, isn't it?
Moreover, as indicated by another poster, null is already a
valid template parameter, making it even more confusing. Also
it is unclear when the interpretation would be as you propose.
You need to appreciate the difference between write-only code
and code that can be easily read, reviewed and understood.
Dlang has already went too far in inventing pieces of
non-obvious syntax for template features. Lets not make the
situation worse.
Distill what you want to do, see what use cases are covered by
other features and libraries, name your thing accordingly and
then propose.
Do you not realize that if every human endeavor was to bow down
to the lowest common denominator there would be no point?
If Walter had the notion "I have to make D so the beginner can
understand it easily" Then D would be javascript or php?
If you want to be an idiot and use an idiot language, then there
are many out there. Go program in BASIC.
So your arguments appealing to ignorance(not the logical fallacy,
of course) is non-sense. Life is complex, stop trying to reduce
it to something you already can understand. I think, technically,
this is called laziness.
Re: Auto-testing issue on FreeBSD
On Saturday, 20 August 2016 at 17:23:38 UTC, Jeremy DeHaan wrote: Hey All. I'm trying to track down an auto-tester failure on FreeBSD, so I decided to run the same tests myself locally. I encountered the following error: runnable/extra-files/cppb.cpp:297:37: error: 'va_list' has not been declared void myvprintfx(const char* format, va_list); I added #include to the file, and then everything ran fine. Should I have set up my system differently so that I didn't need to edit anything or should this be added to the file anyway? Jeremy The error occurs on my system, too, when I run gcc -c cppb.cpp by hand. IMHO the file needs to be updated. Kai
Re: Why D is not popular enough?
On 8/20/2016 8:25 AM, Shachar Shemesh wrote: Actually, Adam's suggestion on how things should work is precisely how C works No, it's subtly different. Which is my point that one must be very, very careful when proposing different behavior.
Auto-testing issue on FreeBSD
Hey All. I'm trying to track down an auto-tester failure on FreeBSD, so I decided to run the same tests myself locally. I encountered the following error: runnable/extra-files/cppb.cpp:297:37: error: 'va_list' has not been declared void myvprintfx(const char* format, va_list); I added #include to the file, and then everything ran fine. Should I have set up my system differently so that I didn't need to edit anything or should this be added to the file anyway? Jeremy
Re: Why D is not popular enough?
On 20/08/16 00:51, Walter Bright wrote: On 8/18/2016 7:59 PM, Adam D. Ruppe wrote: Alas, C insisted on making everything int all the time and D followed that :( Actually, Adam's suggestion on how things should work is precisely how C works (except it trails off at int). a = b + c; if b and c are both a byte, and a is a byte, the result is unpromoted. If a is a short, the result is promoted. I know the mechanism is completely different than what Adam was suggesting, but the end result is precisely the same. > One would have to be *really* sure of their ground in coming up with > allegedly better rules. > Would "no narrowing implicit casts" be considered such a better rule? :-) Again, I'm not saying it's a bad rule, just that does have consequences. What I'm saying is that we are, already, changing things. Shachar
Re: How about a special null template parameter?
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
This syntax would be very confusing to a non-expert. It is a
special case of an existing features (inheritance and templates),
which makes it hard to learn about, as all resources are going to
discuss those other features first, and only the most detailed
readings are going to contain this detail. Moreover, it does not
introduce a keyword or any other name, so it is almost impossible
to Google. Try googling something like "template class a
class b: public a", and see which result contains "curiously
recurring template pattern". It is hard to find, isn't it?
Moreover, as indicated by another poster, null is already a valid
template parameter, making it even more confusing. Also it is
unclear when the interpretation would be as you propose.
You need to appreciate the difference between write-only code and
code that can be easily read, reviewed and understood.
Dlang has already went too far in inventing pieces of non-obvious
syntax for template features. Lets not make the situation worse.
Distill what you want to do, see what use cases are covered by
other features and libraries, name your thing accordingly and
then propose.
Re: Code signing to help with Windows virus false positives
On Saturday, 20 August 2016 at 13:26:03 UTC, Martin Nowak wrote: On 08/20/2016 03:21 PM, Martin Nowak wrote: On Monday, 15 August 2016 at 20:47:10 UTC, Basile B. wrote: Please share your suggestions for how to help with the false positive issue (or just continue laughing in ignorance based on an assumption of something I never said). If the origin of the problem is NSIS then in a first time it would be worth trying InnoSetup or also a MSI installer. We already had that in our backlog b/c maintaining the NSIS installer is a mess. Let's try to build a proper MSI installer w/ InnoSetup. https://issues.dlang.org/show_bug.cgi?id=15284#c20 http://forum.dlang.org/post/gjdwctcoakpfxzyjd...@forum.dlang.org https://trello.com/c/pDvkBVVZ/70-switch-windows-installer-to-msi-using-innosetup "to MSI using innosetup" ? There's a misunderstanding here. Inno setup doesn't compile to MS installer, it's a complete independant solution.
Re: Code signing to help with Windows virus false positives
On 08/20/2016 03:21 PM, Martin Nowak wrote: > On Monday, 15 August 2016 at 20:47:10 UTC, Basile B. wrote: >>> Please share your suggestions for how to help with the false positive >>> issue (or just continue laughing in ignorance based on an assumption >>> of something I never said). >> >> If the origin of the problem is NSIS then in a first time it would be >> worth trying InnoSetup or also a MSI installer. > > We already had that in our backlog b/c maintaining the NSIS installer is > a mess. > > Let's try to build a proper MSI installer w/ InnoSetup. > https://issues.dlang.org/show_bug.cgi?id=15284#c20 > http://forum.dlang.org/post/gjdwctcoakpfxzyjd...@forum.dlang.org https://trello.com/c/pDvkBVVZ/70-switch-windows-installer-to-msi-using-innosetup
Re: Code signing to help with Windows virus false positives
On Monday, 15 August 2016 at 20:47:10 UTC, Basile B. wrote: Please share your suggestions for how to help with the false positive issue (or just continue laughing in ignorance based on an assumption of something I never said). If the origin of the problem is NSIS then in a first time it would be worth trying InnoSetup or also a MSI installer. We already had that in our backlog b/c maintaining the NSIS installer is a mess. Let's try to build a proper MSI installer w/ InnoSetup. https://issues.dlang.org/show_bug.cgi?id=15284#c20 http://forum.dlang.org/post/gjdwctcoakpfxzyjd...@forum.dlang.org
Re: Code signing to help with Windows virus false positives
On Tuesday, 16 August 2016 at 05:38:00 UTC, Ethan Watson wrote: D code seems to be sufficiently different that virus scanners get confused. Both Windows Defender and F-Secure complained about it being the same trojan in fact. Don't see any F-Secure problem for dmd-2.071.1.exe. https://virustotal.com/en/file/7f7fc5c7707425bcde05cf2e6b5e1f35358061d9adb870bd4e943bf9973f9bbe/analysis/
Re: How about a special null template parameter?
On 20.08.2016 00:07, Engine Machine wrote:
On Friday, 19 August 2016 at 21:07:42 UTC, Timon Gehr wrote:
On 19.08.2016 20:25, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
alias Seq(T...)=T;
template TypeParent(T...) if(T.length==1){
static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!();
else alias TypeParent = Seq!(Type!null);
}
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
This is a bit verbose
Apart from the workaround for the ridiculous alias template parameter
semantics, I think the length of the code more or less matches the
specificity of the requested behaviour. (There should be ways to
abstract out most of it, in case you need this really often.)
and not quite right (T is Dog should be something
like T[0], or whatever).
...
('T is Dog' does not work anyway.)
It does essentially work. My only complaint is that it would be nice to
be able to export an alias to Type!() = Type; in the namespace of the
type being created. Doubt that D can do that!? If it can, then it should
be an adequate solution.
That is
It would be nice to have something like
alias Type = Type!();
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
I don't understand how this is related.
Re: Why D is not popular enough?
On 19 August 2016 at 00:50, John Smith via Digitalmars-d wrote: > Well there are some things I feel could be improved, a lot of the things are > really just minor but what is a deal breaker for me mostly is the compilers. > The GCC and Clang implementations are really far behind in terms of the > version, so they are missing a lot of features. A lot of the features that > I'd want to use D for. This is a constant vicious cycle. Sometimes I wonder of how better it would be for all if D was instead defined by a spec, not an implementation that adds small feature changes in an ad hoc manner as it sees fit.
Re: Why D is not popular enough?
On Saturday, 20 August 2016 at 08:57:48 UTC, Bill Hicks wrote: On Saturday, 20 August 2016 at 06:11:54 UTC, rikki cattermole wrote: And yet it is steadily growing. A brain tumor grows too, until it kills. We might have lost the battles with programming languages such as JavaScript, C++, etc, but we still have a fighting chance against D, and we must do everything we can before it's too late. At this point I'd like to know which non-tumoral language we should all be using... (I know I shouldn't feed the trolls, but I'm truly interested in knowing what's his ideal language).
Re: Why D is not popular enough?
On Saturday, 20 August 2016 at 06:11:54 UTC, rikki cattermole wrote: And yet it is steadily growing. A brain tumor grows too, until it kills. We might have lost the battles with programming languages such as JavaScript, C++, etc, but we still have a fighting chance against D, and we must do everything we can before it's too late.
Re: Why D is not popular enough?
On Saturday, 20 August 2016 at 06:08:21 UTC, Bill Hicks wrote: F*CK, here we go again. Why do you spend your precious time posting these messages? Are you real Batman?
