Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 05:30:21 UTC, Jonathan M Davis wrote: On Monday, April 18, 2016 04:25:25 Jon D via Digitalmars-d-learn wrote: I have an dub config file specifying a targetType of 'executable'. There is only one file, the file containing main(), and no unit tests. When I run 'dub test', dub builds and runs the executable. This is not really desirable. Is there a way to set up the dub configuration file to disable running the test? Note: What I'd really like to do is run a custom shell command when 'dub test' is done, I haven't seen anything suggesting that's an option. However, disabling would still be useful. What's the point of even running dub test if you have no unit tests? Just do dub build, and then use the resulting executable, or if you want to build and run in one command, then use dub run. - Jonathan M Davis I should have supplied more context. A few days ago I announced open-sourcing a D package consisting of several executables. Multiple comments recommended making it available via the Dub repository. I wasn't using Dub to build, and there are a number of loose ends when working with Dub and multiple executables. I've been trying to limit the number of issues others might encounter if they pulled the package and ran typical commands, like 'dub test'. It's not a big deal, but if there's an easy way to provide a handler, I will. Also, the reason for a custom shell command is that there are tests, it's just that they are run against the built executable rather than via the unittest framework. --Jon
Re: Is there a way to disable 'dub test' for applications?
On Monday, April 18, 2016 04:25:25 Jon D via Digitalmars-d-learn wrote: > I have an dub config file specifying a targetType of > 'executable'. There is only one file, the file containing main(), > and no unit tests. > > When I run 'dub test', dub builds and runs the executable. This > is not really desirable. Is there a way to set up the dub > configuration file to disable running the test? > > Note: What I'd really like to do is run a custom shell command > when 'dub test' is done, I haven't seen anything suggesting > that's an option. However, disabling would still be useful. What's the point of even running dub test if you have no unit tests? Just do dub build, and then use the resulting executable, or if you want to build and run in one command, then use dub run. - Jonathan M Davis
Re: Which application is much suited and which is not.
On 04/17/2016 02:33 AM, Suliman wrote: Could you write article about D for Csharp programmers? About D benefits While waiting for that document: :) http://dconf.org/2013/talks/wilson.html Ali
Is there a way to disable 'dub test' for applications?
I have an dub config file specifying a targetType of 'executable'. There is only one file, the file containing main(), and no unit tests. When I run 'dub test', dub builds and runs the executable. This is not really desirable. Is there a way to set up the dub configuration file to disable running the test? Note: What I'd really like to do is run a custom shell command when 'dub test' is done, I haven't seen anything suggesting that's an option. However, disabling would still be useful. --Jon
Re: Anonymous structure
On Monday, 18 April 2016 at 03:57:26 UTC, Tofu Ninja wrote: x,y,and z seem to all be immutable and all have the UDA testUDA. But even odder, it seems that "struct" in there is doing absolutely nothing. The same thing can be done with Yeah, any attribute can be grouped with braces or colons in D, including user-defined ones.
Re: Anonymous structure
On Monday, 18 April 2016 at 03:33:53 UTC, Adam D. Ruppe wrote:
The struct inside union is the main pure-language use case I
know of though.
Actually curiously I found another potential use, applying
attributes/UDAs to multiple members at once.
enum testUDA;
struct T{
@testUDA
immutable struct{
int x;
int y;
int z;
}
}
x,y,and z seem to all be immutable and all have the UDA testUDA.
But even odder, it seems that "struct" in there is doing
absolutely nothing. The same thing can be done with
enum testUDA;
struct T{
@testUDA
immutable{
int x;
int y;
int z;
}
}
So it still seems to be useless other than in the case of
unions...
Re: Anonymous structure
On Monday, 18 April 2016 at 03:33:53 UTC, Adam D. Ruppe wrote: The struct inside union is the main pure-language use case I know of though. I understand the reason for allowing it in a union, I just don't see the reason it was extended to all aggregates as it seems to do nothing.
Re: Anonymous structure
On Monday, 18 April 2016 at 02:42:15 UTC, Nicholas Wilson wrote: IIRC D doesn't allow anonymous structures. They are allowed only if they are inside another aggregate.
Re: Anonymous structure
On Monday, 18 April 2016 at 02:12:24 UTC, Tofu Ninja wrote:
Just out of curiosity, what is the point of the following?
struct a{
struct{
int x;
int y;
int z;
}
}
The grouping matters when it is nested inside a union. Here's a
real world example:
https://github.com/adamdruppe/arsd/blob/master/color.d#L128
The anonymous struct inside the union allows me to say that
r,g,b, and a are NOT supposed to share memory, but rather give
structure to the shared uint or ubyte[4] in the other union
members.
My documentation generator also uses the grouping to add shared
docs for the innards:
http://dpldocs.info/experimental-docs/arsd.color.Color.__anonymous.html
(I'm not terribly happy with giving it the name `__anonymous` in
the docs but I didn't have any better idea yet.)
Though that isn't a feature of D itself, I do find it nice to be
able to group documentation.
The struct inside union is the main pure-language use case I know
of though.
Re: Anonymous structure
On Monday, 18 April 2016 at 02:42:15 UTC, Nicholas Wilson wrote:
On Monday, 18 April 2016 at 02:12:24 UTC, Tofu Ninja wrote:
Just out of curiosity, what is the point of the following?
struct a{
struct{
int x;
int y;
int z;
}
}
As far as I can tell, the anonymous structure does nothing.
How is it different from
struct a{
int x;
int y;
int z;
}
IIRC D doesn't allow anonymous structures.
It does, it compiles...
Accessing x,y,z on the first one with the anonymous struct is the
same as accessing it on the second without the anonymous
struct... Seems to make no difference that it is there, which is
why I am asking.
Also is there a way to have a named substructure, not a nested
structure but something to just add an additional name, maybe
something like
struct a{
struct{
int x;
int y;
int z;
} b;
}
Try adding static:
struct a
{
static struct b
{
}
}
Does not seem to be what I mean, a static nested struct is just a
nested struct without access to the enclosing structure's
members. What I meant was a struct to just add a namespace of
sorts to the struct so that the substructure members would have
to be accessed with a longer more qualified name. Something like
struct a{
int x;
sub_struct b{
int y;
}
}
a v;
v.x = 3;
v.b.y = 7;
// v.y = 7; // does not work
Re: Anonymous structure
On Monday, 18 April 2016 at 02:12:24 UTC, Tofu Ninja wrote:
Just out of curiosity, what is the point of the following?
struct a{
struct{
int x;
int y;
int z;
}
}
As far as I can tell, the anonymous structure does nothing. How
is it different from
struct a{
int x;
int y;
int z;
}
IIRC D doesn't allow anonymous structures.
Also is there a way to have a named substructure, not a nested
structure but something to just add an additional name, maybe
something like
struct a{
struct{
int x;
int y;
int z;
} b;
}
Try adding static:
struct a
{
static struct b
{
}
}
Anonymous structure
Just out of curiosity, what is the point of the following?
struct a{
struct{
int x;
int y;
int z;
}
}
As far as I can tell, the anonymous structure does nothing. How
is it different from
struct a{
int x;
int y;
int z;
}
Also is there a way to have a named substructure, not a nested
structure but something to just add an additional name, maybe
something like
struct a{
struct{
int x;
int y;
int z;
} b;
}
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, 17 April 2016 at 13:56:38 UTC, Jonathan M Davis wrote:
Perhaps, but be aware that Walter Bright thinks that size_t
should stay as-is:
http://forum.dlang.org/post/nevrsb$2ge1$1...@digitalmars.com
Maybe some sort of general change to how aliases work would be
acceptable and would give you what you want. I don't know. But
he's against special casing stuff like size_t.
- Jonathan M Davis
I was just going to make a __traits that returns a tuple of
string lf the types as seen by the parser (i.e. "size_t"). While
size_t and ptrdiff_t are the most common case they are not
special. e.g.
version = B;
version(B)
{
struct b{}
alias A = b*;
}
version(C)
{
struct c{}
alias A = c*;
}
void foo(A a){}
writeln(Parameters!foo);//prints b*
writeln(__traits(whatevericallit,foo);// prints A
Specifying a minimum Phobos version in dub?
Is there a way to specify a minimum Phobos version in a dub package specification? --Jon
Re: .opAssign disabled without @disable
On 17.04.2016 13:00, denizzzka wrote: So, my problem is solved. But nevertheless maybe here is a problem in the compiler too. I've reduced the test case and filed an issue: https://issues.dlang.org/show_bug.cgi?id=15936
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, April 17, 2016 12:07:45 Nicholas Wilson via Digitalmars-d-learn wrote: > On Sunday, 17 April 2016 at 11:47:52 UTC, Jonathan M Davis wrote: > > On Sunday, April 17, 2016 11:00:15 Nicholas Wilson via > > > > Digitalmars-d-learn wrote: > >> On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis > >> > >> wrote: > >> > [...] > >> > >> Sorry for the confusion, I didn't. getting the string "size_t" > >> as the result of a hypothetical StringReturnType is the > >> desired outcome. > > > > Then I very much doubt that it's possible. The compiler doesn't > > distinguish between an alias and the original. As far as it's > > concerned, they're exactly the same thing. The compiler is > > pretty much doing the equivalent of textually replacing all > > instances of an alias with the original. > > > > - Jonathan M Davis > > Then time for some compiler hacking!! Perhaps, but be aware that Walter Bright thinks that size_t should stay as-is: http://forum.dlang.org/post/nevrsb$2ge1$1...@digitalmars.com Maybe some sort of general change to how aliases work would be acceptable and would give you what you want. I don't know. But he's against special casing stuff like size_t. - Jonathan M Davis
Re: Accessing __FILE__ and __LINE__ of caller in combination with varargs?
On Saturday, 16 April 2016 at 12:37:46 UTC, Simen Kjaeraas wrote:
On Saturday, 16 April 2016 at 00:03:59 UTC, Jonathan M Davis
wrote:
On Friday, April 15, 2016 20:52:42 WebFreak001 via
Digitalmars-d-learn wrote:
void assertf(string file = __FILE__, size_t line = __LINE__,
Args...)(lazy bool condition, in string message, Args args) {
Yes, you can do that, but do _not_ do that unless you really
have no other choice. What you need to realize is that because
the file and line number arguments will be unique for every
call to this function, it will generate a new instantiation of
it _every_ time it is called. So, you're going to get a lot of
code bloat. There are rare cases where such bloat would be
acceptable, but in the general case, it's a terrible thing to
do. This particular case might be acceptable given how short
it is, but in general, using __FILE__ or __LINE__ as template
arguments should be avoided like the plague.
A few tricks to reduce this bloat:
[...]
You can also use tuple() to get Args to be a single type, and
.expand it for the format call. But it will naturally still be
one template instantiation per combination of tuple argument
types.
import std.typecons : tuple;
void assertf(Args)(lazy bool condition, string pattern, Args args,
string file = __FILE__, size_t line = __LINE__)
{
import std.format : format;
assert(condition, format("%s:%d | ", file, line) ~
format(pattern, args.expand));
}
void assertf(lazy bool condition, string message, /* no Args */
string file = __FILE__, size_t line = __LINE__)
{
// add a tuple and bounce to the other assertf
assertf(condition, message, tuple(), file, line);
}
void main()
{
assertf(true, "normal message without tuple following it gets
an empty tuple tacked on");
assertf(false, "%d comes after %d, says %s", tuple(1, 2,
"wikipedia"));
}
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, 17 April 2016 at 10:27:10 UTC, Nicholas Wilson wrote:
On Sunday, 17 April 2016 at 10:22:00 UTC, Anonymouse wrote:
On Sunday, 17 April 2016 at 10:12:29 UTC, Nicholas Wilson
wrote:
So currently there is a loss of information when Parameters
Fields and Return type.
i.e. assuming 64 bits
size_t foo(ptrdiff_t) {};
writeln(ReturnType!foo); // prints ulong
Is there any way to get the types as (tuples of) strings of
the the types as they are in the source file?
auto foos = StringReturnType!foo;
static assert(typeof(foos) == string);
pramga(msg, foos); // available at CT, prints size_t
Correct me if I'm wrong but size_t is just an alias of ulong
(assuming 64 bits), so they're the exact same thing. A rose by
any other name etc.
not on 32bits its not. Also consider a Platform specific alias.
The end result is that it is not portable.
"Assuming 64 bits". According to the spec as quoted, it will be
"a type that is large enough to represent an offset into all
addressible memory", versioned to fit the platform. So if
anything, it seems to me that it is there precisely in the spirit
of portability, aliasing an integer type selected to suit the
platform it was compiled for. Having it be different on 32 bits
is the point.
https://github.com/dlang/druntime/blob/master/src/object.d#L32
While string is likewise an alias to immutable(char)[], I think
it's just specialcased to be displayed as "string" anyway in the
majority of messages.
void main() {
string foo;
immutable(char)[] foo_alt;
size_t bar;
ptrdiff_t baz;
assert(typeid(foo).toString == "immutable(char)[]");
assert(typeof(foo).stringof == "string"); // <--
inconsistent
assert(typeid(foo_alt).toString == "immutable(char)[]");
assert(typeof(foo_alt).stringof == "string"); // <--
inconsistent-er
version (D_LP64) {
assert(typeid(bar).toString == "ulong");
assert(typeid(baz).toString == "long");
}
else {
assert(typeid(bar).toString == "uint");
assert(typeid(baz).toString == "int");
}
}
If you want size_t to be represented as a discrete type by that
StringReturnType, I imagine you will have to specialcase size_t
and ptrdiff_t in it to report them as "size_t" and "ptrdiff_t"
explicitly. Bear in mind that this will clobber ulong/uint and
long/int, because they really are the same.
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, 17 April 2016 at 11:47:52 UTC, Jonathan M Davis wrote: On Sunday, April 17, 2016 11:00:15 Nicholas Wilson via Digitalmars-d-learn wrote: On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis wrote: > [...] Sorry for the confusion, I didn't. getting the string "size_t" as the result of a hypothetical StringReturnType is the desired outcome. Then I very much doubt that it's possible. The compiler doesn't distinguish between an alias and the original. As far as it's concerned, they're exactly the same thing. The compiler is pretty much doing the equivalent of textually replacing all instances of an alias with the original. - Jonathan M Davis Then time for some compiler hacking!!
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, April 17, 2016 11:00:15 Nicholas Wilson via Digitalmars-d-learn wrote: > On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis wrote: > > On Sunday, April 17, 2016 10:12:29 Nicholas Wilson via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > I'm actually surprised that you got the compiler to give you > > size_t in any form. size_t is simply an alias to either ulong > > (on 64-bit systems) or uint (on 32-bit systems), and for better > > or worse, aliases pretty much just disappear. As far as the > > compiler is concerned, if it sees > > > > [...] > > Sorry for the confusion, I didn't. getting the string "size_t" as > the result of a hypothetical StringReturnType is the desired > outcome. Then I very much doubt that it's possible. The compiler doesn't distinguish between an alias and the original. As far as it's concerned, they're exactly the same thing. The compiler is pretty much doing the equivalent of textually replacing all instances of an alias with the original. - Jonathan M Davis
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis wrote: On Sunday, April 17, 2016 10:12:29 Nicholas Wilson via Digitalmars-d-learn wrote: [...] I'm actually surprised that you got the compiler to give you size_t in any form. size_t is simply an alias to either ulong (on 64-bit systems) or uint (on 32-bit systems), and for better or worse, aliases pretty much just disappear. As far as the compiler is concerned, if it sees [...] Sorry for the confusion, I didn't. getting the string "size_t" as the result of a hypothetical StringReturnType is the desired outcome.
Re: .opAssign disabled without @disable
As Alex Parrill says, on problem was in const member. But this is one of the problems, and after fix here still was an error. But alphaglosined found another problem! For some unknown reason here it is need to specify an empty postblit constructor. Full patch: https://github.com/denizzzka/r-tree/commit/ca9231df5a8a227aa9a8010b849e2e92a134f8a1 So, my problem is solved. But nevertheless maybe here is a problem in the compiler too.
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, April 17, 2016 10:12:29 Nicholas Wilson via Digitalmars-d-learn
wrote:
> So currently there is a loss of information when Parameters
> Fields and Return type.
> i.e. assuming 64 bits
> size_t foo(ptrdiff_t) {};
>
> writeln(ReturnType!foo); // prints ulong
>
> Is there any way to get the types as (tuples of) strings of the
> the types as they are in the source file?
>
> auto foos = StringReturnType!foo;
> static assert(typeof(foos) == string);
> pramga(msg, foos); // available at CT, prints size_t
I'm actually surprised that you got the compiler to give you size_t in any
form. size_t is simply an alias to either ulong (on 64-bit systems) or uint
(on 32-bit systems), and for better or worse, aliases pretty much just
disappear. As far as the compiler is concerned, if it sees
alias size_t = ulong;
t's basically just replacing all instances of size_t with ulong, and size_t
doesn't even exist. The same goes with any other alias (like ptrdiff_t)
whether you declare it or whether it's in druntime or Phobos. You will never
see size_t in an error message except maybe when you mistype it, and the
compiler is providing a suggestion for what you meant to type. As far as
the compiler is concerned, there is no difference between an alias and what
it's an alias of.
- Jonathan M Davis
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, 17 April 2016 at 10:22:00 UTC, Anonymouse wrote:
On Sunday, 17 April 2016 at 10:12:29 UTC, Nicholas Wilson wrote:
So currently there is a loss of information when Parameters
Fields and Return type.
i.e. assuming 64 bits
size_t foo(ptrdiff_t) {};
writeln(ReturnType!foo); // prints ulong
Is there any way to get the types as (tuples of) strings of
the the types as they are in the source file?
auto foos = StringReturnType!foo;
static assert(typeof(foos) == string);
pramga(msg, foos); // available at CT, prints size_t
Correct me if I'm wrong but size_t is just an alias of ulong
(assuming 64 bits), so they're the exact same thing. A rose by
any other name etc.
not on 32bits its not. Also consider a Platform specific alias.
The end result is that it is not portable.
Re: Dealing with type information loss in Parameters Fields and Return type
On Sunday, 17 April 2016 at 10:12:29 UTC, Nicholas Wilson wrote:
So currently there is a loss of information when Parameters
Fields and Return type.
i.e. assuming 64 bits
size_t foo(ptrdiff_t) {};
writeln(ReturnType!foo); // prints ulong
Is there any way to get the types as (tuples of) strings of the
the types as they are in the source file?
auto foos = StringReturnType!foo;
static assert(typeof(foos) == string);
pramga(msg, foos); // available at CT, prints size_t
Correct me if I'm wrong but size_t is just an alias of ulong
(assuming 64 bits), so they're the exact same thing. A rose by
any other name etc.
size_t is an alias to one of the unsigned integral basic types,
and represents a type that is large enough to represent an
offset into all addressible memory.
ptrdiff_t is an alias to the signed basic type the same size as
size_t.
Dealing with type information loss in Parameters Fields and Return type
So currently there is a loss of information when Parameters
Fields and Return type.
i.e. assuming 64 bits
size_t foo(ptrdiff_t) {};
writeln(ReturnType!foo); // prints ulong
Is there any way to get the types as (tuples of) strings of the
the types as they are in the source file?
auto foos = StringReturnType!foo;
static assert(typeof(foos) == string);
pramga(msg, foos); // available at CT, prints size_t
Re: Which application is much suited and which is not.
On Saturday, 16 April 2016 at 18:13:57 UTC, Bauss wrote: On Saturday, 16 April 2016 at 14:08:05 UTC, newB wrote: Let's say you have decided to use D programming language. For what kind of applications would you choose D programming language and For what kind of applications you won't choose D programming. I use D for pretty much everything. I use for a new website I'm working on using D and my own custom template engine for rendering websites similar to asp.net,'s mvc and razor. I use it for most applications I do, small or big. The only time I don't use D is when I'm at work since I work with a lot of already existing .net code but I'd never start a new project not written in D. The reason is pretty simply; D had everything that could ever need and things it lacks has never been things I couldn't do myself. By using D I have achieved and accomplished things much faster than any other languages that I use/used and it's been performing better too. I haven't had a reason not to use D yet. Could you write article about D for Csharp programmers? About D benefits
Re: .opAssign disabled without @disable
On Sunday, 17 April 2016 at 06:42:39 UTC, denizzzka wrote: Tried to build small test app - is not reproduced. Also tried to reduce source: https://github.com/denizzzka/r-tree/tree/314f7f1cc1b6387915dc56dcb2d3ccbc63e19275/source In this source line 199 causes this error (https://github.com/denizzzka/r-tree/blob/314f7f1cc1b6387915dc56dcb2d3ccbc63e19275/source/package.d#L199) But if I am checkout to master and remove const from debug private const bool isLeafNode = false; It isn't fixes compiling. Second branch: I am removed const from file and add import insted of traits template function: https://github.com/denizzzka/r-tree/blob/4457025efa72a6d8a97429e09c35a3f5520c37d5/source/package.d#L26 If place this import to top of the file @disabled error is gone! Why?
Re: .opAssign disabled without @disable
Tried to build small test app - is not reproduced.
